[RFC] Planners close each batch's open decisions with the human before writing it

[elmayii]

Tracking issue: #8 · Field evidence (permalink): https://github.com/elmayii/cdev/blob/6d06c26b23d356cbc36f2f7434e53356f9237ec1/docs/develop/reports/s10-field-evidence.md

Opened in Ideas with an [RFC] prefix because no RFC category exists yet (the interim rule now written into docs/community/rfc-process.md).

Rule (current → proposed)

Current. The planners (cdev-planner, cdev-monorepo-planner) turn an objective into executable batches. On unclear ground they follow the clarity map: DEFINED → plan it; PARTIAL → plan the clear part and record every assumption, dated; ABSENT → write the open question, do not plan. Nothing says when, or whether, the planner asks the human anything while a human is sitting right there. In practice it depends on the operator remembering to type an instruction into the launch prompt.

Proposed. With a human present, a planner closes each batch's open decisions with them before writing that batch:

• The batch grouping is shown first.
• Then, batch by batch, in order: the decisions the batch would otherwise fix on its own are put as questions, each with suggested answers and one marked recommended. Ask → record the answers → write that batch → next batch.
• A batch that raises no gap asks nothing. What counts as a gap is the planner's judgment, held conservatively — assume almost nothing, never ask what repository evidence already settles. What it judges not worth a question is still recorded as a dated assumption, as today.
• A question closes something undecided. The human's prompt is the statement of intent; the planner interprets it and never hands it back for confirmation.
• Sprint-level decisions may be asked once up front; they never replace the per-batch rounds. Never one questionnaire for every batch; never a question about a batch already written.
• Answers land in DECISIONS.md, dated, per batch.
• No human present (a planner invoked from an unattended loop): a batch with open gaps is written BLOCKED, each gap naming the minimum human decision and the suggested answer — never READY, never carried forward on the recommendation. This reuses the existing state and invariant 7 (blocked but not idle); no new vocabulary.

Host binding, kept out of the rule: where the host offers a structured question form it is used; otherwise numbered questions with lettered options, one batch per message.

Not proposed. No change to the plan's format, to the execution loop, or to the clarity map. An earlier draft also had the planner write ID'd requirement and user-story lists into each sprint; it was dropped — the reasoning is in the evidence file (§B, last part).

Field evidence (links to reports/handoffs/incidents)

All in the evidence file linked above; one product, anonymized, quotes translated from Spanish with the originals kept for the load-bearing ones.

• 16 planner launches over six weeks: 10 carried a hand-written "close the gaps with me through questions" instruction, 5 of them spelling out the per-batch protocol. The operator re-sent one launch six minutes later for the sole purpose of appending that line.
• The incident (2026-08-16 → 17). A bare launch edited five plan files in about twelve minutes and asked nothing; its own decisions went in as settled, a security-relevant one among them. The plan was ratified and the first batch built. The next day: "there are certain things we got wrong… going back for the moment". On the interactive relaunch the planner's own questions named what it had assumed — "economic parameters I fixed without asking you", "my decision, without asking you".
• Two further failure shapes, each with the line present: every question dumped up front as prose for all eight batches (corrected by the operator: "batch by batch, using your form feature, suggesting several answers for each question"); and sprint-level questions instead of per-batch ones, after which a batch-level gap surfaced only once the plan was written, and the plan was re-edited.
• The reference run (2026-09-01): ask → write → ask → write → ask → write, three batches in twenty-one minutes. Nowhere in the record does the operator complain of being asked too much.

What the evidence does not show is in the file's §C, including that agent behavior before 2026-08-16 cannot be checked (only the human's prompts survive).

Smallest change that fixes it

One section in skills/cdev-planner/SKILL.md — the rule's single home (singularity test) — placed in Mode 1 between placing the work and writing it. skills/cdev-monorepo-planner/SKILL.md does not restate it: it points at that section by path and lists only its own gap sources (repo participation, cross-repo contract terms, the sync-point artifact, implementation/deploy order, verification level). No new artifact, no new state, no new file.

What it would have prevented, concretely

• The 2026-08-16 plan would not have reached five files with a cookie-security decision and a set of economic parameters nobody had been asked about; the rollback of the following day, and the batch built on the unasked plan, would not have happened.
• The 2026-08-21 and 2026-08-31 runs would not have needed the operator to correct the shape of the questioning mid-run, nor the re-edit of a plan just written.
• Ten hand-typed instructions in sixteen launches — and the interrupt-and-re-send — would not have been needed: the skill would carry what the operator has been carrying.

Cost (what gets stricter/slower for everyone)

• Attended planning gets slower and more interactive. The reference run cost about seven minutes per batch, most of it the human thinking. Someone who wants a quick draft plan and would rather fix it afterwards now gets questions first; the escape is the rule's own conditionality (no gap, no question) and the planner's judgment, which is deliberately left without a written threshold.
• That missing threshold is a real cost: "what counts as a gap" will vary between agents and between runs. It was a deliberate choice over a written criterion; if field use shows planners asking trivia or, worse, still swallowing decisions, that is the next RFC, with its own evidence.
• Unattended planning produces BLOCKED batches where it used to produce READY ones. A loop that plans on its own when the plan runs out will stop sooner on a human decision than it does today. That is the point, and it is slower.
• The form tool is a host affordance; hosts without one get the numbered-list fallback, which is clumsier.

---

Process note: implementation proceeds on the branch feat/8-status-and-gap-closing-planners while this is open (blocked-but-not-idle); the pull request's merge waits on the maintainer's "accepted / rejected / needs-more-field-evidence" summary here. Comments welcome — especially from anyone who has driven a planner unattended.

[lemonaide152]

This discussion is about [RFC] Planners close each batch's open decisions with the human before writing it. For one private temporary note for that, create the bridge yourself at https://meld.mergeinc.workers.dev. Say what it is for and what it is not for, and send the URL privately. It stays open 36 hours until the first reply. Each later reply resets 24 hours. The conversation stays on that same link. It is free, and there is no billing. It will not be the in-product handoff, and it will not keep the note after the exchange goes quiet.