Support safe multi-module application from the Seed4J CLI

[renanfranca]

Goal

Allow users and automation tools to apply a set of Seed4J modules through a single CLI operation while preserving deterministic execution, beginner-friendly dependency validation, and clear failure behavior.

Context

The current CLI exposes each available module as a dynamically generated subcommand:

seed4j apply <module>

This design works well for applying one module because the CLI can build the command options from that module's properties.

The Seed4J core already supports applying a collection of module slugs through Seed4JModulesToApply. The modules are ordered according to the landscape and then applied sequentially.

However, exposing this capability directly through the CLI requires additional design and validation because:

• the selected modules may require different properties;
• shared properties must be represented only once;
• dependencies may be satisfied by the project history or by another module in the requested set;
• feature dependencies must continue to require an explicit provider choice;
• predictable validation errors should be detected before the first project mutation;
• the current core flow may apply changes, update history, and create commits one module at a time;
• a failure after one or more successful modules may leave a partially applied set.

Proposed direction

Introduce a dedicated command for applying a module set instead of changing the existing single-module apply syntax immediately.

Proposed command:

seed4j apply-set init maven-java prettier --plan

After validating the plan:

seed4j apply-set init maven-java prettier

The existing command must remain supported:

seed4j apply <module>

Design principles

• Preserve the current beginner-friendly dependency validation.
• Do not automatically select a module to satisfy a feature dependency.
• Consider a dependency satisfied when it is already in project history or explicitly included in the requested set.
• Validate the complete set before applying the first module whenever the failure can be predicted.
• Use a deterministic module order derived from the Seed4J landscape.
• Reuse the same validated plan during execution instead of independently resolving the set again.
• Clearly report which modules succeeded, failed, or were not executed.
• Keep the existing single-module behavior backward compatible.
• Protect user-visible behavior with CLI integration tests.

Work breakdown

Complete this feature through the following sub-issues:

• Add a read-only plan for applying multiple modules #296
• Define transaction, commit, and partial-failure semantics for multi-module application #297
• Apply multiple modules after successful preflight validation #298
• Apply Seed4J presets from the CLI #299
• Add module slug autocomplete for apply-set #301

Replace the checklist entries with issue references after creating the sub-issues.

Related work

• Block apply when required module dependencies are missing #200
• Enhance apply --plan with dependency chain status #270

The multi-module flow must preserve the dependency rules established by these issues.

Acceptance criteria

• The expected multi-module CLI experience is documented.
• The read-only planning behavior is implemented before mutation support.
• Dependency validation considers both project history and the requested module set.
• Feature dependencies are never resolved through an implicit provider choice.
• Commit and partial-failure behavior is explicitly defined.
• A validated module set can be applied in deterministic order.
• Presets can reuse the multi-module infrastructure without duplicating their definitions in the CLI.
• The existing seed4j apply <module> behavior remains compatible.
• CLI integration tests protect the main success and failure scenarios.

Out of scope

• Automatically selecting a provider for a feature dependency.
• Replacing the existing single-module apply command.
• User-defined presets.
• Parallel module application.