Delivery Flow and Scaffold Reliability Iteration Coordination
Decision: Shared V4.3 iteration
The accepted delivery-flow work and Issue #197 scaffold-lifecycle work belong in one implementation iteration. Their authorities remain separate: delivery owns prompt-level coordination, verification, and review contracts; scaffold lifecycle owns executable CLI generation, update/check, projection, and recovery behavior.
Baseline-delivered shared scaffold guidance has accepted whole-file ownership for this iteration. The scaffold capability, archive, reader, and ownership slice is authoritative in the accepted scaffold specification; existing native graphs remain unchanged.
This record defines accepted placement; provider execution is established by separate reconciliation readback. Rename milestone 36fa9ecc-0bbe-46c7-873b-1947a4487838 to V4.3 Delivery Flow and Scaffold Reliability. Keep initiatives IP-442 and IP-456, epics IP-443 and IP-457, and their existing internal blocker graphs. Keep delivery stories IP-444–IP-446 and tasks IP-447–IP-455; move scaffold stories IP-458–IP-462 and tasks IP-463–IP-471 from V4.4 into this milestone. Add no blanket cross-epic blockers and no new product requirements.
| Seam | Coordination rule |
|---|---|
| Verification | Delivery IP-451 preserves verifier evidence and boundaries; scaffold IP-463 supplies artifact obligations and IP-467 preserves legacy behavior. Each task proves its own accepted preservation contract; combined-version verification occurs before iteration completion. |
| Source and context | Delivery IP-455 keeps source-first synchronization compatible; scaffold IP-468 separates authoring and activation contracts from content identity, and IP-469 proves projection and post-command continuity. |
| Handoffs | Delivery IP-454 covers delivery workflow continuity. Scaffold IP-469 covers remaining CLI post-command work. Delivery Context Packets remain disposable; scaffold receipts and recovery evidence remain durable proof. |
| Contract changes | Reauthor only when an explicit contract, selected scope, or dependency changes. An ordinary Markdown edit alone does not trigger broad reauthoring. |
| Execution ownership | create-plan establishes disjoint write scopes and records declared read dependencies and shared-runtime conflicts; read scopes may overlap. The parent orchestrator delegates implementation; one owner handles any canonical shared-skill revision and synchronization receipt. |
| Validation | Exercise each owning task's accepted seam contract and verify the combined versions before iteration completion, with no automatic cross-epic wait. Preserve delivery AC-044–AC-048 and use the scaffold command-preservation, no-op, and recovery checks already accepted for the scaffold lifecycle. Match frozen CLI/runtime conditions when comparing results. |
The user's Markdown-versus-code distinction is useful for planning but incomplete: scaffold generates and projects Markdown and context, while delivery preserves executable verifier contracts and evidence. No extra experiments or admission gates are introduced. Main-based branch intent remains explicit; this decision implies no stack or pull-request merge order. The historical V4.4 receipt remains historical and is superseded only for current milestone placement.
Sources: delivery specification at 57f4fdfa0ae4f6a9a04c74f0f8ffbaffea0489cf; scaffold specification at d2ce164aee1f59755fce84cbff40afed9e4ed087; historical scaffold backlog receipt at 4403e1095c22a4bc8f2e9a63bcec60e45cb8c4f8.