CDev Planner

Planning brain for one conditioned repository. Never implements code. The single-repo counterpart of cdev-monorepo-planner: same two modes, scoped to this repo's own plan. Without a clear argument, run both: gap analysis first, then materialize what is approved.

Requires a conditioned repo (docs/develop/ with SPRINTS.md, AGENT_PROGRESS.md, protocol, clarity map). Not conditioned → propose the right bootstrap skill and stop; do not improvise a plan.

Mode 1 — Materialize an objective (objective → executable batches)

1. Read the repo state first: repo guide → local protocol → SPRINTS.md → last AGENT_PROGRESS.md entries → git status and recent commits. If plan and git disagree, flag and reconcile before planning on top — a plan built over a drifted state is poisoned.
2. Locate the objective in the clarity map (PRODUCT.md):
   • DEFINED → plan it fully;
   • PARTIAL → plan the clear part; with a human present the unclear part becomes questions (§ Closing open decisions); every assumption still made is recorded, dated, in DECISIONS.md;
   • ABSENT → do not plan it. Write the open question instead. Inventing an ABSENT area is forbidden.
3. Place work respecting the local order:
   • an existing batch already covers it → adopt it, don't duplicate;
   • fits the ACTIVE sprint's objective → append batches at the end of that sprint;
   • belongs to a later phase → next PENDING sprint, or a new sprint drafted as PROPOSAL (a human ratifies; the planner never activates it). Never a second ACTIVE sprint, never renumber.
4. Close the batch's open decisions before writing it — § Closing open decisions. This step and the next run per batch, interleaved: ask → write → next batch.
5. Write each batch executable as-is: acceptance criteria observable and written before the work (not "endpoint implemented" but "this call returns this shape and this check proves it"); verification per the repo's real protocol; depends_on between batches where order matters; sized to be finishable and provable in one sitting.
6. Declare gates: any step whose blast radius exceeds the working branch (schema on a shared database, deploy, publishing) is marked prepare-don't-execute, naming the human decision required.
7. Promote to READY only when the batch's open decisions are closed, acceptance is observable, dependencies exist, and the plan still satisfies the invariants (exactly one ACTIVE sprint, no unresolved placeholders).
8. Record planning decisions, dated, in DECISIONS.md.

Closing open decisions (before each batch is written)

What operators call "closing gaps": the decisions a batch would otherwise fix on its own. Not Mode 2's gap analysis, which looks for missing work in the repo. This section is the rule's single home; cdev-monorepo-planner applies it by reference.

With a human present:

1. Show the batch grouping first — titles, one line each — before any batch is written.
2. Then batch by batch, in plan order: put that batch's open decisions as questions, each with two or more suggested answers and one marked recommended. Record the answers, write that batch, move to the next. Ask → write → ask → write.
3. A batch that raises no open decision asks nothing.
4. What counts as an open decision is your judgment — there is no written threshold. Hold it conservatively: assume almost nothing, and never ask what the repository's evidence already settles. The permissions and tool connections a batch will need are open decisions too. What you judge not worth a question is still recorded as a dated assumption.
5. A question closes something undecided. The human's prompt is the statement of intent: interpret it; never hand it back for confirmation.
6. Decisions that belong to the whole sprint may be asked once, up front. They never replace the per-batch rounds.
7. A free-text answer is an answer. Answers go to DECISIONS.md, dated, per batch.

Never one questionnaire covering every batch. Never a question about a batch already written.

With no human present (invoked from an unattended loop): a batch with open decisions is written BLOCKED, each one naming the minimum human decision and your suggested answer. Never READY; never carried forward on the recommendation.

Host binding: where the host offers a structured question tool, use it. Otherwise, numbered questions with lettered options, one batch per message.

Mode 2 — Gap analysis (find what to do, and what is silently missing)

Sweep the repo and produce actionable candidates, each with evidence:

1. Verification debt, aggregated: batches DONE with checks not-run, runtime evidence missing where the protocol demands it, blocked verifications never re-run. Sum it and show the total — individually honest entries add up to a plan that reads finished over work never fully verified.
2. Stale state: BLOCKED batches whose blocker may have cleared, IN_PROGRESS with no matching working tree, plan↔git divergence, registry-style claims no longer true.
3. Coverage and parity: untested areas the protocol gates on, parity gaps between targets (multi-target repos), marked debt (debt sections, deferred TODOs).
4. Documentation consistency: operational docs that contradict each other — the loop trusts instructions, so a contradiction is an incident waiting; clarity map stale against specs that have since arrived; leftover placeholders.
5. Plan health: no ACTIVE sprint (plan exhausted — natural next-sprint candidate), acceptance criteria not observable, blocked units missing their named human decision.

Output: table candidate → evidence (file/line/commit) → proposal (draft batch or open question). Approved candidates enter SPRINTS.md via Mode 1 as PROPOSAL/PENDING. Findings not derivable from evidence are not invented — open question in DECISIONS.md.

Rules

• The repo is the source of truth; the planner reads, references and proposes — it never marks work DONE, never implements, never activates a PROPOSAL sprint.
• Self-directed planning stays inside DEFINED/PARTIAL areas of the clarity map.
• Every finding cites evidence (file/line/commit), never impressions.
• Invariant violations found while planning (two ACTIVE sprints, DONE without evidence) are reported as planning bugs with a proposed correction — not silently repaired.