Lesson 24 — Decomposition and simple dependencies

Outcome

Turn an approved Feature Plan into an editable proposed Task set, confirm it, and persist simple acyclic dependencies.

Why this comes now

Plans become useful when they create executable work, but automatic decomposition should remain a proposal until a human confirms it.

Understand

A planner can propose Tasks plus dependsOn relationships. Forge shows the proposal, lets you edit it, validates the graph, then commits Tasks/dependencies idempotently. Dependency edges do not mean Forge needs a general workflow/DAG engine.

Decomposition is an action against an approved Plan Revision, not a new Plan status that erases “approved.”

Build the real project

1. Add decomposition proposal/result model.
2. Use Fake Planner or first real adapter to produce structured proposed Tasks.
3. Build preview/edit UI.
4. Validate no self-edge, missing target, or cycle (simple DFS/topological check is enough).
5. Confirm in one transaction: Tasks + criteria + dependency edges + decomposition record/idempotency key.
6. Support requires task execution plan as a Task property/policy if useful without changing Task status.

Completion gate

Reject a cyclic proposal. Confirming the same decomposition twice does not duplicate Tasks. Human can edit titles/descriptions/dependencies before commit.

Pitfalls to avoid

Do not let planner output write directly into production tables before confirmation. Do not build Airflow. Do not infer dependency completion from branch names.

References

Directed acyclic graph basics, original Plan loop archive: docs/archive/00-original-agent-task-orchestrator.md.

Checkpoint

M9 is complete when a reviewed Feature Plan can create real work without bypassing human confirmation.