goal-driven-delivery

Topics in the source

• Goal-driven delivery
• When to Use
• Stage order — fixed, no skipping
• Roles — authoring vs inspection
• Phase 0 — the dispatch contract
• Phase 1 — branch and dispatch
• Phase 2 — verify before believing anything
• Phase 3 — simplify, then apply

One written increment (a goal), authored by a coding agent, verified and landed by the operator, with the loop running end to end and no per-step approval. This file is the protocol and nothing else. Repo facts live in a project profile — a profile is deltas only and may never restate or override the protocol. Transport mechanics live in references/transport.md. Language- and stack-specific build knowledge lives in its own skill. One fact, one home. "Start the next goal", "run the goal-driven flow", "finish this the usual way". 中文同义说法同样触发：开始下一个 goal、推进 goal driven 流程、按老流程把这个做完。 Any multi-hour repo increment: a feature, a research-feasibility study, a migration, a docs rewrite — anything with a written completion contract and machine-checkable gates. A repo where the operator delegates end to end, including the merge. Not for: one-line fixes, exploratory poking with no acceptance criteria, or work whose result no machine can check. Both two-phase steps are mandatory: an unapplied report or an unfixed review does not close a stage. Caps: implement 2 recovery attempts, simplify 2 rounds, review→fix 2 rounds. On a third round, stop and report — do not burn budget in silence. The agent

This is an excerpt. Refer to the complete source and its current requirements.