Ticket-Driven Development

Act as the controller. Convert an approved directory of Markdown tickets into a tested integration branch without expanding worker context unnecessarily. Keep scheduling, integration, state, and final acceptance in the controller; give each guide, implementation, or review worker one bounded assignment.

Non-negotiable invariants

1. Work from one isolated integration branch; the user's primary branch and dirty checkout stay untouched.
2. Treat tickets as a dependency graph, not a list. Dispatch only tickets whose blockers have passed the required checkpoint.
3. Parallelize only confidently independent tickets. Concurrent writers get separate checkouts.
4. Give each worker one ticket and file pointers, not the parent conversation or every ticket.
5. Only the controller dispatches guide, implementation, review, or conflict-resolution workers — workers never recurse.
6. Require durable report files and compact returns: full diffs and detailed reports stay in files, reaching the controller as pointers.
7. Use deterministic Git commands for clean integration; a conflict agent is used only after Git demonstrates a conflict.
8. Cap ticket repair at two rounds, then stop, split, escalate, or ask for a decision.
9. Persist state.json and an append-only ledger.md as the run database — conversation memory is not durable.
10. Mark a ticket complete only after its change is reachable from the integration branch and its applicable checkpoint passes. Terminal statuses are canonical — a ticket with a commit ends integrated; artifact-only output ends verified with its report as evidence. Checkpoint outcomes and review verdicts are recorded in the ledger, never by restamping a status (references/recovery.md holds the full contract).
11. A source status claiming completion is a claim, not evidence: corroborate it against the repository before trusting it. Corroborated work is never redispatched.
12. Mutate the repository only when open work exists. When corroboration leaves no incomplete ticket, end the run with zero repository changes.
13. Pair medium- and high-risk implementation tickets: a senior guide plans from repository evidence, a junior implementer executes the plan. Review tier follows risk: high-risk tickets get one plan-aware review verifying both the plan's soundness and the diff's adherence; medium-risk tickets get a quick review on the fast tier with the guidance as an input pointer, escalating to the plan-aware review when the diff is beyond its depth (gate in references/verification-policy.md). Guidance is a durable, base-pinned artifact, never conversation memory.