Sub-plans and dependencies
When work belongs in this plan, when it needs its own sub-plan, and how to say one thing needs another first.
There is one rule for deciding whether new work belongs in the plan you are in or in a sub-plan of its own, and it is about Context, not about size.
Same context, same plan. Its own context, its own sub-plan.
Specs share their plan's Context. So work that needs its own background material (its own regulation, its own vendor API docs, its own research) belongs in a sub-plan, because a sub-plan is the thing that can hold sources.
A plan about checkout that grows a section on tax compliance is the usual example. The tax work needs the tax rules attached; the checkout work does not want them in every prompt. That is a sub-plan, not five more Specs.
What a sub-plan gets
A sub-plan is a plan in every respect. It has its own conversation, its own status, its own Specs, and it pushes to your issue tracker on its own schedule.
It inherits its ancestors' Context automatically and read-only, so you never re-attach the same document twice.
Sibling sub-plans cannot see each other
Two sub-plans of the same parent are isolated. Neither one's conversation knows the other exists, and that is deliberate: a plan that can see its siblings starts making claims about work you did not ask it to think about.
The one exception is when you create a dependency between them, below.
Needs first
Any plan or Spec can declare that it needs another one first. That is how you say "the API has to exist before the UI can call it".
Dependencies do three things:
- They order the work, and the order survives the push to your issue tracker as issue relations.
- They are cycle-checked. A dependency that would create a loop is refused when you make it, not discovered later.
- At plan level, a needs-first edge also imports that plan's Context and Specs, so the dependent plan can actually see what it is waiting on.
That import is direct only. If A needs B and B needs C, A sees B, not C.