Skip to content

Enhance apply --plan with dependency chain status #270

Description

@renanfranca

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 . --plan

the output should include a dependency plan.

For each dependency, show:

  • dependency type: module or feature
  • dependency slug
  • status:
    • already applied
    • pending
    • pending choice
    • satisfied 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions