Repository navigation
Description
Goal
Enhance seed4j apply <module> --plan so it shows the module dependency chain before applying changes.
The plan should explain which dependencies are already satisfied by the current project history, which direct module dependencies are still pending, and which feature dependencies require an explicit user choice.
Context
The current --plan output only resolves module parameters and their sources:
- explicit CLI input
- project history
- default value
It also reports missing required parameters, and does not apply changes, create commits, or append project history.
This is useful, but it does not help users or LLM agents understand whether the target module can be safely applied in the current project state.
Required behavior
When running:
seed4j apply <module> --project-path . --planthe output should include a dependency plan.
For each dependency, show:
- dependency type:
moduleorfeature - dependency slug
- status:
already appliedpendingpending choicesatisfied by <module>
- recommended next action when applicable
Dependency rules
Direct module dependency
A direct module dependency has a unique path.
If the dependency is not already present in project history, the plan may mark it as pending and explain that it can be inferred as a required module.
Example:
○ module:java-base
Status: pending
Resolution: can be applied because this is a direct module dependency
Feature dependency
A feature dependency must not be auto-selected blindly.
A feature is usually composed of multiple modules, so the user must explicitly choose which module from that feature should satisfy the dependency.
The plan should consider a feature dependency satisfied when at least one module belonging to that feature has already been applied in the project.
If no module from the feature has been applied, the plan should show a pending explicit choice and list the candidate modules.
Example:
○ feature:springdoc
Status: pending choice
Resolution: choose one module from this feature explicitly
Candidates:
- springdoc-openapi
- springdoc-scalar
Example output
Plan for module: sample-feature
Project path: .
Dependency plan:
✓ module:init
Status: already applied
○ module:java-base
Status: pending
Resolution: direct module dependency
○ feature:springdoc
Status: pending choice
Resolution: choose one module from this feature explicitly
Candidates:
- springdoc-openapi
- springdoc-scalar
Target module:
○ module:sample-feature
Status: pending
Resolved parameters:
...
No changes were applied.
Implementation notes
Use project history to determine already applied modules.
Use the module landscape/resources to inspect:
- direct module dependencies
- feature dependencies
- modules grouped under each feature
Be careful not to treat feature dependencies the same way as direct module dependencies.
The plan should remain read-only:
- no files changed
- no commits created
- no project history appended
Activity