@warpgogol/forge 5.3.4 → 6.2.0

package/skills/fo/fo-handoff/SKILL.md

@@ -52,6 +52,8 @@ Include:
   - **Change** — what was done (the key changes made during the session)
   - **After** — state N+1 after the session (what the system looks like now)
 - **Resulting Architecture** — optional Mermaid diagram of the system state AFTER changes, following the diagram selection rules from `_shared/fo-session-summary.md`. If no diagram is warranted, state: "No diagram: this session did not change system structure."
+- **Unclosed items** — mandatory tri-state list of open items, each `{ item, state: closed | unclosed | undecidable }`, or an explicit "none". An item absent from the list is treated as `undecidable` — absence is never read as success. If three or more entries would be `undecidable`, escalate to the operator instead of writing the handoff. See `_shared/fo-pipeline-conventions.md` §Tri-state closure marking.
+- **Continuation entry point** — mandatory: the exact file, command, or skill the next agent starts from (e.g. `docs/plans/plan-rfc-xxxx.md` step 3, `werkstatt run <command>`, `/fo-fix`). Never leave the re-entry point implicit.
 - **Next steps** — concrete, actionable items the next agent should pick up.
 - **Memory layer pointer** — tell the next agent to read `.agents/memory/MEMORY.md` and recent `.agents/memory/daily/` files for project context.
 
@@ -67,11 +69,7 @@ If the operator passed arguments, treat them as a description of what the next s
 
 ### 4. Commit
 
-Commit the handoff document via `ecosystem.commit` so it survives stash operations and is available to the next session.
-
-```sh
-rtk pnpm exec werkstatt run ecosystem.commit --message "docs: add handoff document"
-```
+Commit the handoff document so it survives stash operations and is available to the next session. Delegate the commit mechanics to `fo-step-commit` (it resolves the project's commit command and staging rules); where the project has no such skill, use its declared ecosystem commit command.
 
 ### 5. Report
 
@@ -80,7 +78,7 @@ Tell the operator the absolute path of the handoff document and suggest opening
 ## Constraints
 
 - **Save to `docs/handoffs/`** (or the directory resolved from `forge.yaml` `paths.handoffsDir`). Never save to `/tmp/` or other temporary directories.
-- **Commit the handoff document** via `ecosystem.commit` after saving.
+- **Commit the handoff document** after saving (via `fo-step-commit` or the project's ecosystem commit command).
 - **Do not duplicate existing artifacts.** Reference them by path or URL.
 - **Redact sensitive information.** API keys, passwords, PII.
 - **Stage only the handoff file.** See `_shared/fo-pipeline-conventions.md` §Commit discipline.

package/skills/fo/fo-idea-create-rfc/SKILL.md

@@ -9,7 +9,7 @@ languagePolicy: ref(PREFERENCES.md)
 bindings:
   requires: [commands.validateRfc]
   optional: [paths.invariantsFile]
-triggerPhrases: ["draft an RFC", "create a full RFC", "scaffold an RFC from template"]
+triggerPhrases: ["подготовим RFC", "draft an RFC", "create a full RFC", "scaffold an RFC from template"]
 ---
 
 <!--
@@ -23,6 +23,7 @@ triggerPhrases: ["draft an RFC", "create a full RFC", "scaffold an RFC from temp
   <item>RFC-1097: sweep — SKILL.md headers + classification fixes
 
 Sweep batch 1: add Compass v2 headers to 45 SKILL.md files (purpose derived from frontmatter description). Fix non-skill-markdown exclusion to check filename not workspace-relative path (packages/AGENTS.md escaped it). Add .coverage to ignoredDirs.</item>
+  <item>RFC-1247: triggerPhrases vocabulary sync — mined operator phrasing applied to this skill's trigger set.</item>
 </CHANGE_SUMMARY>
 -->
 

package/skills/fo/fo-idea-enhance/SKILL.md

@@ -20,9 +20,24 @@ triggerPhrases: ["enhance this RFC", "fix audit findings in RFC", "improve RFC b
 </non-goals>
 </MODULE_CONTRACT>
 <CHANGE_SUMMARY>
+  <item>RFC-1250: collect/finalize contract — step 5 emits ledger entries +
+  PENDING DECISION markers under orchestrated runs; grilling runs in emit mode;
+  enhancedAt gated on zero open ledger entries.</item>
   <item>RFC-1097: sweep — SKILL.md headers + classification fixes
 
 Sweep batch 1: add Compass v2 headers to 45 SKILL.md files (purpose derived from frontmatter description). Fix non-skill-markdown exclusion to check filename not workspace-relative path (packages/AGENTS.md escaped it). Add .coverage to ignoredDirs.</item>
+  <item>RFC-1250: review wave — QUEUE-07 gates un-parked opens only, ledger binding checks, fail-closed loader
+
+REVIEW-RFC-1250-01 findings: QUEUE-07 no longer fires on parked entries
+(the park is the containment — a parked queue stays resumable and the
+decision window arbitrates it); loader fails open only on ENOENT —
+other read errors are QUEUE-01; ledger gains queue/id-stem binding
+(QUEUE-02), Q-N uniqueness (QUEUE-05), and QUEUE-08 hygiene warnings
+(missing answers, foreign doc ids); next excludes QUEUE-07-blocked
+items; top-level decision totals added. Orchestrator pre-flight treats
+QUEUE-07 as the window agenda — structural errors still stop the batch;
+maturation skips parked/deferred items; uncovered imperative ask sites
+gain collect riders (ADR code-trace, NC markers, audit-verdict guard).</item>
 </CHANGE_SUMMARY>
 -->
 
@@ -63,6 +78,8 @@ When multiple RFCs are identified, **loop through each one** and run the full en
 
 **Exception:** Step 5 (resolve audit questions and grill the design) is inherently interactive — it may require user responses for questions the AI could not answer itself. This is not a "pause between RFCs" but a required step within one RFC's enhancement. Resolve all questions for the current RFC before proceeding to step 6, then continue to the next RFC without additional pauses.
 
+**Collect mode:** when this skill runs inside an orchestrator-driven queue run (the caller passes a queue manifest / ledger path), step 5 runs in `collect` mode per `_shared/fo-pipeline-conventions.md` §Collect and finalize contract — questions emit into `docs/queues/<id>.decisions.yaml` as `open` entries instead of `ask_user_question` calls, and `PENDING DECISION: Q-N` markers mark the unresolved spots. The single decision window happens later, orchestrated. Standalone invocations keep `interview` behavior.
+
 Read the full RFC file at `docs/rfcs/rfc-XXXX-*.md` for the first RFC to process.
 
 ### 2. Find the audit
@@ -100,13 +117,13 @@ Read every finding from the audit report. For each, classify it as one of:
 - **Direct fix** — the RFC text can be edited to address it: fill a placeholder section, add a missing edge case, fix a DNA reference, tighten a contract, add a failure mode, etc.
 - **New RFC** — the finding reveals a topic that is too large or too distinct for this RFC. Examples: a new package, a new DNA invariant, a new governance policy, a new external contract. Splitting it out keeps the RFC focused and follows the ecosystem's one-decision-per-RFC principle.
 - **Out of scope** — the finding is valid but belongs to a different RFC or a future effort. Add it to this RFC's `nonGoals` with a brief explanation and, if applicable, a `related` reference to where it will be addressed.
-- **NC (Needs Clarification)** — Unresolved `NEEDS CLARIFICATION` markers in the RFC body. Resolution: ask the operator the question, replace the marker line with the operator's answer in the RFC body. If the operator defers, the marker remains and the RFC cannot transition to `reviewing`.
+- **NC (Needs Clarification)** — Unresolved `NEEDS CLARIFICATION` markers in the RFC body. Resolution: ask the operator the question, replace the marker line with the operator's answer in the RFC body. If the operator defers, the marker remains and the RFC cannot transition to `reviewing`. **Collect mode:** each NC marker emits a ledger entry (`stage: enhance`, `status: open`, recommended option) instead of asking — the marker stays until the resolution phase integrates the window's answer.
 
 Record the classification for every finding — the summary in step 8 reports it.
 
 ### 5. Resolve audit questions and grill the design
 
-This step is **blocking** — the enhance skill must not proceed to step 6 until all audit questions are resolved and grilling is complete. Skipping unresolved audit questions defeats the purpose of the audit and is **not permitted**.
+This step is **blocking** — the enhance skill must not proceed to step 6 until all audit questions are resolved and grilling is complete. Skipping unresolved audit questions defeats the purpose of the audit and is **not permitted**. In **collect mode** (orchestrated runs), "resolved" means emitted to the decision ledger — no inline asking; the questions are consumed at the decision window and finalized in the resolution phase.
 
 #### 5a. Extract and resolve audit questions
 
@@ -114,7 +131,7 @@ Read the "Questions for the author" section from the audit report. For each ques
 
 1. **Search the ecosystem** — explore existing code, DNA invariants, AGENTS.md rules, existing RFCs, package contracts, and command surfaces. If the answer is determined by existing artifacts, use it. Note it as "resolved from ecosystem: <explanation>" in the summary. Do not ask the user what can be found by exploring.
 2. **Reason from existing patterns** — if the answer is not directly stated but follows unambiguously from existing conventions, architecture decisions, or established patterns in the codebase, derive it. Note it as "resolved by inference: <explanation>" in the summary.
-3. **Ask only if you could not find a confident answer** — if after a genuine attempt you cannot find or derive the answer, ask the user via `ask_user_question`. Present the question with a recommended option first, marked "(recommended)". Ask one question at a time, waiting for the answer before continuing to the next question.
+3. **Ask only if you could not find a confident answer** — if after a genuine attempt you cannot find or derive the answer, ask the user via `ask_user_question`. Present the question with a recommended option first, marked "(recommended)". Ask one question at a time, waiting for the answer before continuing to the next question. **Collect mode:** instead of asking, append a ledger entry (`id: Q-N`, `doc`, `stage: enhance`, `question`, `resolutionPath` = the last rung exhausted per §Self-resolution ladder, `options` with `recommended`, `status: open`) and leave a `> PENDING DECISION: Q-N — <question>` marker where the answer matters.
 
 Do not ask the user a question you could have answered yourself. Do not skip a question you genuinely could not answer — that defeats the audit.
 
@@ -122,7 +139,7 @@ If the audit has no "Questions for the author" section or the section is empty,
 
 #### 5b. Grill the design
 
-After all audit questions are answered, invoke the `grilling` skill to stress-test the RFC's design beyond the audit questions. Use the `skill` tool with `SkillName: "grilling"` to load the grilling instructions, then follow them: ask questions one at a time, provide a recommended answer for each, and wait for the user's response before continuing.
+After all audit questions are answered, invoke the `grilling` skill to stress-test the RFC's design beyond the audit questions. Use the `skill` tool with `SkillName: "grilling"` to load the grilling instructions, then follow them: ask questions one at a time, provide a recommended answer for each, and wait for the user's response before continuing. **Collect mode:** run grilling in `emit` mode — generated questions land in the ledger with recommended answers, no interview.
 
 The grilling questions should probe the RFC's design decisions, edge cases, and integration points that the audit may not have covered. Focus on areas the audit flagged as "Needs revision" or where the answers to 5a revealed uncertainty.
 
@@ -166,6 +183,8 @@ Set the `enhancedAt` field in the RFC's frontmatter to today's date (YYYY-MM-DD)
 
 This step is mandatory even if the audit verdict was "Approved" and zero direct fixes were applied — the stamp confirms the audit was reviewed and no changes were needed, which is distinct from "enhance was never run".
 
+**Collect mode gate:** under an orchestrated run, stamp `enhancedAt` only when the decision ledger carries zero `open` entries for this document. If open entries remain, leave `enhancedAt` unset — the resolution phase finalizes enhance and stamps after the answers land.
+
 ### 8. Validate
 
 Run mechanical validation on all modified and created RFCs:

package/skills/fo/fo-idea-i-just-want-to-see-the-result/SKILL.md

@@ -6,7 +6,7 @@ category: fo
 concerns: code-mutation
 dependsOn: ['my-preferences']
 languagePolicy: ref(PREFERENCES.md)
-triggerPhrases: ["I just want to see the result", "run the full pipeline automatically", "implement this end-to-end without pauses"]
+triggerPhrases: ["по полному пайплайну", "на результат", "реализуй RFC", "I just want to see the result", "implement this end-to-end without pauses"]
 ---
 
 <!--
@@ -17,15 +17,25 @@ triggerPhrases: ["I just want to see the result", "run the full pipeline automat
 </non-goals>
 </MODULE_CONTRACT>
 <CHANGE_SUMMARY>
-  <item>RFC-1097: sweep — SKILL.md headers + classification fixes
-
-Sweep batch 1: add Compass v2 headers to 45 SKILL.md files (purpose derived from frontmatter description). Fix non-skill-markdown exclusion to check filename not workspace-relative path (packages/AGENTS.md escaped it). Add .coverage to ignoredDirs.</item>
-  <item>RFC-1140: step 5 — queue-mode section in orchestrator SKILL.md
-
-Add Queue mode section (pre-flight queue.validate, loop semantics, failure handling, manifest immutability) to fo-idea-i-just-want-to-see-the-result SKILL.md, sync .agents copy, add forgeQueueModule row to forge AGENTS.md.</item>
   <item>RFC-1140: queue mode — materialize manifest at invocation from pasted doc list
 
 When the invocation carries >=2 RFC/ADR ids without a manifest path, the orchestrator builds docs/queues/session-<timestamp>.yaml from the pasted order, runs queue.validate, then processes queue mode. Unresolvable ids are named explicitly.</item>
+  <item>RFC-1247: regen agents-generate golden fixture, add fo-handoff route row, PREFERENCES pipeline-intent caveat (RFC-1247)</item>
+  <item>RFC-1250: review wave — QUEUE-07 gates un-parked opens only, ledger binding checks, fail-closed loader
+
+REVIEW-RFC-1250-01 findings: QUEUE-07 no longer fires on parked entries
+(the park is the containment — a parked queue stays resumable and the
+decision window arbitrates it); loader fails open only on ENOENT —
+other read errors are QUEUE-01; ledger gains queue/id-stem binding
+(QUEUE-02), Q-N uniqueness (QUEUE-05), and QUEUE-08 hygiene warnings
+(missing answers, foreign doc ids); next excludes QUEUE-07-blocked
+items; top-level decision totals added. Orchestrator pre-flight treats
+QUEUE-07 as the window agenda — structural errors still stop the batch;
+maturation skips parked/deferred items; uncovered imperative ask sites
+gain collect riders (ADR code-trace, NC markers, audit-verdict guard).</item>
+  <item>RFC-1250: re-review wave — blocked dependsOn cascade, manifest-failure gating, generated artifacts</item>
+  <item>RFC-1250: re-review round 3 — transitive skip wording, cascade test hardening</item>
+  <history>RFC-1097, RFC-1140, RFC-1250</history>
 </CHANGE_SUMMARY>
 -->
 
@@ -41,26 +51,47 @@ This skill is a **pure orchestrator** — it delegates every step to the appropr
 
 This orchestrator supports a `stopAfter` parameter that limits how far the pipeline runs:
 
-- **`stopAfter: plan`** — execute steps 0–3 only (idea, audit, enhance, plan). Do not run implement (step 4), which now includes review and fix. After step 3 completes, report the summary and stop.
+- **`stopAfter: plan`** — run phases 1–3 of the queue model (maturation, decision window, resolution; see §Queue mode — the four-phase model). Do not run execution (implement, which includes review and fix). After resolution completes, report the summary and stop.
 - **`stopAfter: null` (default)** — run the full pipeline through implement (which includes review and fix).
 
-When `stopAfter: plan` is set and the document is an **ADR**, the ADR pipeline skips audit/enhance/plan. Stop after step 0 (idea creation) with the message: "ADR does not require a plan. Run `/fo-idea-implement` to implement."
+When `stopAfter: plan` is set and the document is an **ADR**, the ADR pipeline skips audit/enhance/plan — it contributes no maturation questions and joins the decision window only if ledger entries exist for it. Stop after the resolution phase with the message: "ADR does not require a plan. Re-invoke `/fo-idea-i-just-want-to-see-the-result` with the same manifest to execute."
 
-When resuming with `stopAfter: plan`, if the plan file already exists in `docs/plans/plan-rfc-XXXX-*.md`, stop immediately — do not proceed to implement.
+When resuming with `stopAfter: plan`, if the plan file already exists in `docs/plans/plan-rfc-XXXX-*.md` and carries no `PENDING DECISION` markers, stop immediately — do not proceed to execution.
 
 ## Preconditions
 
+### Intent routing (front door)
+
+This skill is the operator's single front door. Before document-id detection, classify the invocation — not every first message is a pipeline request:
+
+| Intent signal (examples) | Route |
+| --- | --- |
+| RFC/ADR ids, queue manifest, plan list, «реализуй», «по полному пайплайну», «на результат» | the existing pipeline flow below (unchanged) |
+| «проверим всё ли сделали», «проверь изменения», "review this session" | `fo-review` → optional `fo-fix`; do not enter implement |
+| «исправим», "fix all", persisted review findings | `fo-fix`; do not enter implement |
+| Session-end phrases («завершаем сессию», «протокол завершения») | `fo-session-retro` contract — never a pipeline |
+| Commit intent («закоммитим», "commit this", staged-step commit requests) | `fo-step-commit` |
+| Handoff intent ("create a handoff", "compact conversation", "prepare handoff") | `fo-handoff` |
+| Open-mission / Sternsystem work («работаем над миссией», `wg-*` names) | the named `wg-*` skill |
+| «нам надо закрыть открытые вопросы», exploratory ideas | `fo-explore` or `fo-idea` (existing step 0) |
+| Ambiguous | ask the operator — never default to implement on ambiguity |
+
+**Misroute guard:** once classified as a non-pipeline intent, do NOT silently re-enter the pipeline; if the routed skill's output reveals the request was actually a pipeline intent, surface that in the report instead. Phrase collisions resolve by intent described, not single-word match — a collision that cannot be resolved asks the operator, never guesses into a mutating skill.
+
+### Accepted inputs
+
 The operator may provide either:
 
 - **A raw idea** — natural-language description of a feature, change, or decision. The skill will invoke `fo-idea` as step 0 to create the RFC/ADR first.
 - **An existing RFC/ADR id** — e.g. `RFC-XXXX` or `ADR-XXXX`. The skill skips idea creation and starts the pipeline from the appropriate step.
-- **A queue manifest** — `--queue <path>` or a `docs/queues/*.yaml` path in the invocation text. The skill enters queue mode (see §Queue mode) and processes the manifest's `items[]` in order.
-- **A pasted document list** — >=2 `RFC-XXXX`/`ADR-XXXX` ids in the invocation text (e.g. another agent's ordered implementation plan). The skill materializes a session manifest (see §Queue mode → Manifest materialization) and enters queue mode.
+- **A queue manifest** — `--queue <path>` or a `docs/queues/*.yaml` path in the invocation text. The skill loads it as the run's manifest (see §Queue mode — the four-phase model) and processes the manifest's `items[]` in order.
+- **A pasted document list** — >=2 `RFC-XXXX`/`ADR-XXXX` ids in the invocation text (e.g. another agent's ordered implementation plan). The skill materializes a session manifest (see §Queue mode → Manifest materialization).
+- **A single document id** — materializes a one-item manifest; the same four-phase model applies (the decision window still fires, usually small).
 - **Nothing** — if neither is provided, check session context and IDE for a recently created document. If none found, ask the operator: "Какую идею реализуем? Опишите идею или укажите RFC-XXXX / ADR-XXXX."
 
-## Queue mode
+## Queue mode — the four-phase model
 
-The orchestrator runs in **queue mode** when the invocation carries `--queue <path>`, a `docs/queues/*.yaml` path, OR a pasted document list (>=2 `RFC-XXXX`/`ADR-XXXX` ids — e.g. another agent's ordered implementation plan).
+**Every orchestrator run is a queue run.** The invocation carrying `--queue <path>`, a `docs/queues/*.yaml` path, a pasted document list, or a single `RFC-XXXX`/`ADR-XXXX` id all enter the same four-phase model; a single document materializes a one-item manifest. There is exactly one execution model — operator decisions are front-loaded into a single decision window, then execution runs uninterrupted.
 
 **Manifest materialization (mandatory when no manifest path is given):** Build the manifest from the invocation text before anything else:
 
@@ -79,21 +110,54 @@ The orchestrator runs in **queue mode** when the invocation carries `--queue <pa
 
 3. If the paste mixes ids with prose, ignore the prose — only the id sequence matters. Do not invent items that are not in the text.
 
-**Pre-flight (mandatory):** Run `pnpm exec werkstatt run queue.validate --file <manifest> --json`. If the command exits non-zero (schema errors, unknown ids, duplicates, id↔filename mismatch), do NOT start the batch — report the errors and stop. When a pasted list references ids that do not resolve (QUEUE-04), name them explicitly — the operator must create those documents first or fix the list.
+**Decision ledger:** the queue owns `docs/queues/<id>.decisions.yaml` — the durable, append-only record of every operator-facing decision (`_shared/fo-pipeline-conventions.md` §Decision ledger). Create it when maturation emits its first question. The rendered `docs/queues/<id>.briefing.md` is generated from the ledger for the decision window.
+
+**Pre-flight (mandatory):** Run `pnpm exec werkstatt run queue.validate --file <manifest> --json`. Interpret diagnostics by kind:
+
+- **Structural errors** (QUEUE-01..06 — schema, unknown ids, duplicates, id↔filename mismatches, ledger load/binding failures) — do NOT start the batch; report the errors and stop. When a pasted list references ids that do not resolve (QUEUE-04), name them explicitly — the operator must create those documents first or fix the list.
+- **QUEUE-07 diagnostics** — implementable items carrying un-parked `open` decisions. This is NOT a stop signal: those entries are precisely the decision window's agenda. The run proceeds — phase 1 finishes any incomplete maturation, then phase 2 arbitrates them. This is the designed resume path after a crash between collect and window, and after runs that parked items for arbitration.
+- **QUEUE-08 warnings** — ledger hygiene (resolved entries missing `answer`, decisions targeting foreign doc ids); report them in the batch summary, continue.
+
+Re-run `queue.validate` between resolution and execution: items still carrying un-parked `open` entries after the window are excluded from `next`, skipped by execution, and listed in the report — never implemented.
 
 **Batch plan preview:** Emit the existing batch plan preview per `_shared/fo-pipeline-conventions.md` §Batch plan preview, listing items in manifest order.
 
-**Loop semantics:** Process `items[]` in manifest order with no pauses between items:
+### Phase 1 — Maturation (no operator)
 
-1. **Skip terminal items** — items whose derived status is `implemented` or `skipped` (rejected/superseded frontmatter) are recorded in the batch summary and skipped.
+Process `items[]` in manifest order. Per item, run the existing per-doc pipeline up to but not including implementation, with every skill in **collect mode** (`_shared/fo-pipeline-conventions.md` §Collect and finalize contract):
+
+1. **Skip terminal and parked items** — items whose derived status is `implemented` or `skipped` (rejected/superseded frontmatter), and items parked by `deferred` entries or `open`+`parked: true` entries (plus their `dependsOn` dependents) are recorded in the batch summary and skipped — maturation never re-collects questions for a parked item.
 2. **Resume mid-pipeline items** — an `in-progress` item resumes at its derived `pipelineStep`, not from step 1.
-3. **Run the existing per-doc pipeline** — RFC items run audit → enhance → plan → implement; ADR items run implement only. All skill-internal interactions (grilling) stay inside the invoked skills.
+3. **Run the collect-mode pipeline** — RFC items run audit → enhance(collect) → plan(collect); ADR items skip maturation stages. Questions emit into the ledger as `open` entries carrying `resolutionPath` and recommended options; autonomous work applies and commits; `enhancedAt` stamps only when zero `open` entries remain for the document; the plan persists as a draft carrying `> PENDING DECISION: Q-N` markers. No `ask_user_question` calls inside any pipeline step — every question materializes in the ledger first.
 4. **Batch-item checkpoint** — after each item, emit the context checkpoint per `_shared/fo-pipeline-conventions.md` §Context checkpoint between batch items.
 5. **Clean-tree gate** — before starting the next item, verify the working tree has no uncommitted leftovers from the completed item; warn and stop if dirty.
 
-**Failure:** If an item fails after its error checkpoint, stop the batch. The report names the blocked item id and the remaining item count. `blocked` is in-session report language only — never persist it into frontmatter, manifests, or files. Resume = re-invoke with the same manifest; `queue.validate` derives where to continue.
+### Phase 2 — Decision window (the single operator interaction)
+
+Render `docs/queues/<id>.briefing.md` from the ledger per `_shared/fo-pipeline-conventions.md` §Decision window and present it: batch policies, per-document decision blocks with recommended options, the resolved-by-inference list, and the parked-items section — every `open`+`parked: true` entry is arbitration the operator owes here. The operator answers in one batch — free-text codes (`Q-03: B`, `all — per recommendations`, `Q-07: defer`); `ask_user_question` is legal only for ≤4 highest-risk decisions. The answered window IS the batch acceptance act.
+
+### Phase 3 — Resolution (no operator)
+
+Apply answers to the ledger (`status: answered`, `answeredAt`), then finalize each document in manifest order: integrate answers into the RFC/plan body, lift `PENDING DECISION` markers, stamp `enhancedAt` where pending, and commit the `draft → accepted` transition per document (`fo-idea-plan` owns the transition mechanics). One bounded follow-up window is permitted only when an answer invalidates a drafted plan and surfaces a genuinely new trade-off — then proceed.
+
+### Phase 4 — Execution (no operator)
+
+Process items in manifest order — RFC items run `implement` (which includes review → fix), ADR items run `implement` only:
+
+1. **Skip terminal, parked, and blocked items** — `implemented`/`skipped`, items with `deferred` ledger entries or `open`+`parked: true` entries, QUEUE-07-blocked items (un-parked `open` entries surviving the window), and items with any excluded item upstream in their `dependsOn` chain (transitive cascade). `queue.validate`'s `next` encodes the same skipping.
+2. **Ledger-bound implementation** — `fo-idea-implement` reads the ledger at prerequisites: `answered` entries bind; emergent questions auto-resolve and append `auto-resolved` entries; only the enumerated hard-stop class parks the item (§Auto-resolve and log).
+3. **Batch-item checkpoint** — after each item, emit the context checkpoint; **clean-tree gate** before the next item.
+4. **`stopAfter: plan`** — run phases 1–3 (maturation + window + resolution), stop before execution.
+
+**Failure:** If an item fails after its error checkpoint, stop the batch. The report names the blocked item id and the remaining item count. `blocked` is in-session report language only — never persist it into frontmatter, manifests, or files. Resume = re-invoke with the same manifest; `queue.validate` derives where to continue and the ledger carries answered decisions across sessions.
+
+**Blocking review verdicts:** when a review inside an item's pipeline returns a blocking verdict —
+
+- `blockLevel: soft-block` — **pause only the current item**: record it in the batch summary as `awaiting operator arbitration`, append the arbitration question to the ledger (`status: open`, `stage: review`, `parked: true` — the system parked it, so QUEUE-07 treats it as contained rather than a gate violation), then continue with the next item. Never auto-resolve an arbitration question. A parked item resumes by re-invoking the orchestrator with the same manifest — parking never strands an item without a defined re-entry path.
+- `blockLevel: hard-block` — **stop the item before stamping and record it as blocked in the batch report; the batch continues.** A parked hard-block item requires the fix and then a **full** re-review on resume (not a delta re-check); at most two fix→re-review cycles, then the hard-stop class escalates the item for arbitration (§Auto-resolve and log).
+- The batch summary MUST list every paused/blocked item with its ledger question ids — accumulation is visible, never silent.
 
-**Manifest immutability:** Do not edit `items[]` or the manifest during a queue run. Reordering requires stopping the batch and re-validating.
+**Manifest immutability:** Do not edit `items[]` or the manifest during a queue run. The ledger — not the manifest — carries decision state. Reordering requires stopping the batch and re-validating.
 
 ## Process
 
@@ -115,7 +179,7 @@ Before starting the pipeline, perform a pre-pipeline checkpoint per `_shared/fo-
 
 ### 2. Run the pipeline
 
-For each document, run the full pipeline inline. The pipeline differs for RFCs and ADRs.
+For each document, run the full pipeline inline — under the four-phase queue model (§Queue mode), per-document steps run in collect/finalize phases. The pipeline differs for RFCs and ADRs.
 
 **Between batch items:** After completing one document's pipeline and before starting the next, perform a context checkpoint per `_shared/fo-pipeline-conventions.md` §Context checkpoint between batch items. Emit the checkpoint block, release completed-item context, and start the next item with a fresh read phase. This does not pause for operator input — the checkpoint is an agent-internal context management step, not a user interaction.
 
@@ -231,7 +295,7 @@ If the session was interrupted (agent stopped, context limit, crash, checkpoint
 
 - **Pure orchestrator.** Delegate every step to the appropriate skill — this orchestrator does not implement code, write RFCs/ADRs, or run validation commands directly.
 - **No pauses between pipeline steps.** The operator's invocation is the instruction to run the entire pipeline. Proceed automatically.
-- **Interactive steps within skills.** Some skills (enhance, plan) have interactive sub-steps (grilling, resolving open questions). Those interactions happen inside the invoked skill.
+- **No inline questions inside orchestrated steps.** Under the four-phase model, pipeline steps run in collect mode — every operator-facing question materializes in the queue's decision ledger (`_shared/fo-pipeline-conventions.md` §Collect and finalize contract), and the single decision window is the only scheduled interaction. Standalone skill invocations keep interview behavior.
 - **Review and fix are inside implement.** `fo-idea-implement` runs `fo-review` and `fo-fix` internally. Do not invoke them as separate orchestrator steps.
 - **Fallback verification is MANDATORY.** After `fo-idea-implement` returns, always check that a review report exists in `docs/reviews/code/` for this session. If missing, invoke `fo-review` and `fo-fix` as a fallback. This ensures review and fix are never skipped.
 - **Commit only your own files** — see `_shared/fo-pipeline-conventions.md` §Commit discipline. Each invoked skill stages only its own files.

package/skills/fo/fo-idea-implement/SKILL.md

@@ -20,10 +20,25 @@ triggerPhrases: ["implement this RFC", "execute the implementation plan", "reali
 </non-goals>
 </MODULE_CONTRACT>
 <CHANGE_SUMMARY>
+  <item>RFC-1250: ledger-bound implementation — answered entries bind at
+  prerequisites; emergent questions auto-resolve with auto-resolved log
+  entries; closed hard-stop enumeration parks the item (dependsOn cascade).</item>
   <item>RFC-1097: sweep — SKILL.md headers + classification fixes
 
 Sweep batch 1: add Compass v2 headers to 45 SKILL.md files (purpose derived from frontmatter description). Fix non-skill-markdown exclusion to check filename not workspace-relative path (packages/AGENTS.md escaped it). Add .coverage to ignoredDirs.</item>
   <item>RFC-1224: preserve operator forge.yaml content on upgrade, promote adrImplementStamp binding</item>
+  <item>RFC-1250: review wave — QUEUE-07 gates un-parked opens only, ledger binding checks, fail-closed loader
+
+REVIEW-RFC-1250-01 findings: QUEUE-07 no longer fires on parked entries
+(the park is the containment — a parked queue stays resumable and the
+decision window arbitrates it); loader fails open only on ENOENT —
+other read errors are QUEUE-01; ledger gains queue/id-stem binding
+(QUEUE-02), Q-N uniqueness (QUEUE-05), and QUEUE-08 hygiene warnings
+(missing answers, foreign doc ids); next excludes QUEUE-07-blocked
+items; top-level decision totals added. Orchestrator pre-flight treats
+QUEUE-07 as the window agenda — structural errors still stop the batch;
+maturation skips parked/deferred items; uncovered imperative ask sites
+gain collect riders (ADR code-trace, NC markers, audit-verdict guard).</item>
 </CHANGE_SUMMARY>
 -->
 
@@ -78,12 +93,24 @@ Before running the implementation on each RFC, perform these checks **in order**
 
 If all checks pass, proceed to step 4.2.
 
+**Decision-ledger read:** when this skill runs inside an orchestrator-driven queue run (the caller passes a queue manifest / ledger path), first load `docs/queues/<id>.decisions.yaml` — every `answered` entry for this document binds the implementation (apply the recorded answer, never re-ask). An `open` entry that survived to execution means the gate was bypassed — treat it as an error checkpoint, not a question.
+
 #### 4.2. Read the RFC and related context
 
 Read the RFC fully and all RFCs listed in its `amends[]`, `related[]`, and `supersedes[]`. Read the plan fully. Read the closest `AGENTS.md` for each impacted package. Read `ref(forge.yaml bindings.paths.invariantsFile)` entries for every DNA invariant in `satisfies[]`.
 
 If the plan or RFC has genuine ambiguities that would cause wrong implementation, ask the user **before starting implementation**. Use `ask_user_question` with a recommended option first. Once implementation begins, stop asking — make autonomous decisions.
 
+**Orchestrated runs — auto-resolve and log:** under a queue manifest, never call `ask_user_question` for pipeline questions. An emergent question that survives the self-resolution ladder (§Self-resolution ladder) is auto-resolved: apply the recommended option and append a ledger entry `status: auto-resolved` (append-only evidence, disputable post-factum). Only the **hard-stop** class parks the item instead — a closed enumeration:
+
+1. DNA-invariant changes or conflicts.
+2. Security or privacy impact.
+3. External-contract changes (Verbund, third-party APIs, published interfaces).
+4. Irreversible or data-destructive operations.
+5. Hard-block review verdicts surviving two fix→re-review cycles.
+
+A hard-stop appends `status: open` + `parked: true`, parks the item (and cascade-parks `dependsOn` dependents), and execution continues with the next item — the parked item surfaces in the batch report for arbitration.
+
 #### 4.3. Implement step by step
 
 Execute the plan's step sequence in order. For each step:
@@ -112,6 +139,7 @@ Stage only the files touched by this step. Do not stage unrelated changes — an
   - For oversized new files, decompose into focused modules and import them.
   - Retry the operation with the adjusted approach immediately. The operator's default answer to "Shall I proceed?" is always "yes" — so proceed without asking.
 - **Commit only your own work.** If the working tree has changes from another session or agent, stage only the files relevant to the current step.
+- **Falsified-routes ledger.** Before choosing or changing a step's approach, read the plan's `## Falsified routes` section — a `Forbidden retry: yes` row rejects the approach unless you can state a new fact that invalidates its root cause. A plan-prescribed route matching a forbidden row counts as an approach change — the consult applies even when the route was chosen by a previous session. When an approach is abandoned after a real attempt, append a row (route, root cause, falsified-at evidence) before moving on. See `_shared/fo-pipeline-conventions.md` §Falsified-routes ledger.
 - **Compass scaffolding.** New non-trivial source files in `apps/` or `packages/` must carry `MODULE_CONTRACT` and `CHANGE_SUMMARY` scaffolding. Check the project's invariants file for the canonical Compass markup rule.
 - **Compass terminology.** Use Compass (not GRACE) in all new code, documentation, and log messages.
 
@@ -178,6 +206,8 @@ If any check in step 4.4 fails, fix every error:
    ```
 
 6. If the error is pre-existing (not caused by this RFC's implementation) and is in an impacted workspace, fix it. If the error is in an unimpacted workspace, skip it — it is not this RFC's responsibility.
+7. **Ledger on abandon** — if the failure kills the current approach, append a `## Falsified routes` row to the plan file before switching approaches (route, root cause, falsified-at evidence).
+8. **Blind-spot pass after two failures on one approach** — after two failed attempts on the same approach within this work item (step execution or fix loop), and before the next retry or pivot, run the clean-context blind-spot pass defined in `_shared/fo-pipeline-conventions.md` §Blind-spot pass.
 
 Continue until all impacted checks pass.
 
@@ -290,7 +320,7 @@ Stage only the regenerated `AGENTS.md` files. If no agent-facing contracts chang
 
 #### 4.9. Documentation audit (fo-doc-audit)
 
-After implementation is complete and all checks pass, invoke `fo-doc-audit` via the `skill` tool. It analyzes the session's changes, checks all documentation surfaces (AGENTS.md, README, Compass XML, architecture-dna.md, templates, generated artifacts, COMMANDS.md/PACKAGE_GRAPH.md), applies needed updates, and commits them separately. Wait for it to complete.
+After implementation is complete and all checks pass, invoke `fo-doc-audit` via the `skill` tool. It analyzes the session's changes, checks all documentation surfaces (AGENTS.md, README, Compass XML, architecture-dna.md, templates, generated artifacts, generated command docs (COMMANDS.md, ecosystem.generated.yaml)), applies needed updates, and commits them separately. Wait for it to complete.
 
 If `fo-doc-audit` reports that no updates are needed, proceed to the next step.
 
@@ -299,19 +329,29 @@ If `fo-doc-audit` reports that no updates are needed, proceed to the next step.
 After the documentation audit, invoke `fo-review` via the `skill` tool. It performs a cross-session fitness check of the code diff against Forge standards (DNA, forward-only, Compass, agent clarity, pragmatism). The review covers all code changes made in this session since the first implementation commit.
 
 1. Determine the diff range: `git diff <merge-base-of-session>...HEAD` — where merge-base is the commit before the first `implement:` commit for this RFC.
-2. Invoke `fo-review` with the diff range. Wait for it to complete (persist + commit the review report in `docs/reviews/code/`).
-3. Read the review report. If the verdict is `approved` **and** the report contains zero findings across all axes, proceed to step 4.12.
-4. If the review has **any** findings — even a single cosmetic observation on any axis — proceed to step 4.11 (fix). Do not interpret an `approved` verdict as "no findings" — read the axis sections and count every finding, including ones labelled "minor" or "cosmetic".
+2. Invoke `fo-review` with the diff range **in `independent` mode** (pipeline-invoked reviews default to clean-context dispatch; artifacts-only inputs). Wait for it to complete (persist + commit the review report in `docs/reviews/code/`).
+3. Read the review report. **Check `blockLevel` first, before the generic findings→fix routing:** a `blockLevel: hard-block` report requires the fix and then a **full** re-review before stamping — not a delta re-check of the flagged point (queue mode: park the item before stamping — fix + full re-review happen on resume); a `blockLevel: soft-block` report pauses the item for operator arbitration (interactive: structured question; queue mode: park + continue, per `_shared/fo-pipeline-conventions.md` §Review blocking semantics).
+4. If the verdict is `approved` (`blockLevel: pass`) **and** the report contains zero findings across all axes, proceed to step 4.12.
+5. If the review has **any** findings — even a single cosmetic observation on any axis — proceed to step 4.11 (fix). Do not interpret an `approved` verdict as "no findings" — read the axis sections and count every finding, including ones labelled "minor" or "cosmetic".
 
 **This step is MANDATORY.** Do not skip it, even if the implementation seems clean. The review is the quality gate that catches DNA misalignment, forward-only violations, Compass drift, and agent clarity issues that implementation authors miss.
 
+#### 4.10b. Checkpoint review (T2 trigger)
+
+Trigger map T2: invoke `fo-review` **mid-implementation**, scoped to the step diff and preferring `independent` mode, when either condition fires:
+
+- a step checkpoint records an **approach change** vs. the plan (different mechanism, different file set, different contract than planned), or
+- a plan step consumed **>2 fix iterations** (repeated test/typecheck/review-fix cycles on the same step).
+
+A T2 review that returns `pass`/`warning` is recorded and the step continues; `soft-block`/`hard-block` follow the blocking semantics in `_shared/fo-pipeline-conventions.md`. T2 does not replace the mandatory T3 review at step 4.10.
+
 #### 4.11. Fix review findings (fo-fix)
 
 If `fo-review` (step 4.10) reported **any** findings (even cosmetic ones on axes A/C/F/G), invoke `fo-fix` via the `skill` tool. It applies the review findings iteratively: fix → typecheck → commit → re-check.
 
 1. Invoke `fo-fix` with the review report. Wait for it to complete.
 2. After `fo-fix` returns, re-run `fo-review` to confirm all findings are resolved.
-3. If new findings appear, repeat the fix cycle. Maximum 3 iterations.
+3. If new findings appear, repeat the fix cycle. Maximum 3 iterations (a `hard-block` caps at 2 cycles, then escalates to the operator regardless).
 4. If findings persist after 3 iterations, stop and report to the operator.
 
 If `fo-review` reported truly zero findings (the report explicitly states "No issues." on every axis), skip this step. An `approved` verdict with any finding text on any axis does NOT qualify as zero findings.
@@ -455,6 +495,8 @@ If any check fails, fix every error:
    <one-line description of the root cause and fix>.
    ```
 
+The falsified-routes ledger and blind-spot rules from step 4.3/4.5 apply identically here: consult the plan's `## Falsified routes` before switching approaches, append a row on abandon, and run the clean-context blind-spot pass per `_shared/fo-pipeline-conventions.md` §Blind-spot pass after two failures on one approach (when the work item carries a plan file — otherwise record falsified routes in the session output).
+
 Continue until all impacted checks pass.
 
 #### 5.6. Documentation audit (fo-doc-audit)
@@ -488,9 +530,10 @@ Stage only the regenerated `AGENTS.md` files. If no agent-facing contracts chang
 After the documentation audit, invoke `fo-review` via the `skill` tool. It performs a cross-session fitness check of the code diff against Forge standards. The review covers all code changes made in this session.
 
 1. Determine the diff range: `git diff <merge-base-of-session>...HEAD`.
-2. Invoke `fo-review` with the diff range. Wait for it to complete (persist + commit the review report).
-3. Read the review report. If the verdict is `approved` **and** the report contains zero findings across all axes, proceed to step 5.9.
-4. If the review has **any** findings — even a single cosmetic observation on any axis — proceed to step 5.8 (fix). Do not interpret an `approved` verdict as "no findings" — read the axis sections and count every finding.
+2. Invoke `fo-review` with the diff range **in `independent` mode** (pipeline-invoked reviews default to clean-context dispatch; artifacts-only inputs). Wait for it to complete (persist + commit the review report).
+3. Read the review report. **Check `blockLevel` first, before the generic findings→fix routing:** `hard-block` → fix then **full** re-review (2-cycle cap, then escalate; queue mode: park before stamping, fix + re-review on resume); `soft-block` → pause for operator arbitration per `_shared/fo-pipeline-conventions.md` §Review blocking semantics.
+4. If the verdict is `approved` (`blockLevel: pass`) **and** the report contains zero findings across all axes, proceed to step 5.9.
+5. If the review has **any** findings — even a single cosmetic observation on any axis — proceed to step 5.8 (fix). Do not interpret an `approved` verdict as "no findings" — read the axis sections and count every finding.
 
 **This step is MANDATORY.** Do not skip it.
 
@@ -500,7 +543,7 @@ If `fo-review` (step 5.7) reported **any** findings (even cosmetic ones), invoke
 
 1. Invoke `fo-fix` with the review report. Wait for it to complete.
 2. After `fo-fix` returns, re-run `fo-review` to confirm all findings are resolved.
-3. If new findings appear, repeat the fix cycle. Maximum 3 iterations.
+3. If new findings appear, repeat the fix cycle. Maximum 3 iterations (2 for `hard-block`, then escalate to the operator).
 4. If findings persist after 3 iterations, stop and report to the operator.
 
 If `fo-review` reported truly zero findings (the report explicitly states "No issues." on every axis), skip this step. An `approved` verdict with any finding text on any axis does NOT qualify as zero findings.
@@ -528,7 +571,7 @@ Before stamping `implemented`, verify that the ADR is mentioned in the codebase
 
    - Proceed to step 5.10.
 
-4. **If the relevant file(s) cannot be identified** — ask the operator: `ADR-XXXX was implemented but no code mention was found. Please point to the file(s) where this ADR's decision was applied so I can add a trace reference.` After the operator provides the file(s), add the trace as described in step 3, commit, and proceed.
+4. **If the relevant file(s) cannot be identified** — ask the operator: `ADR-XXXX was implemented but no code mention was found. Please point to the file(s) where this ADR's decision was applied so I can add a trace reference.` After the operator provides the file(s), add the trace as described in step 3, commit, and proceed. **Orchestrated runs:** never ask — the codebase rung of the self-resolution ladder is already exhausted by reaching this step, so append an `auto-resolved` ledger entry (`stage: implement`, `resolutionPath: codebase`, `answer: "no code site found — trace omitted"`) recording that the ADR's decision has no identifiable code surface, and continue. The omission is disputable post-factum via the ledger, never silent.
 
 **For already-implemented ADRs** (if this step is reached for an ADR that was already `implemented`): this check is informational — attempt to find the trace and add it if missing, but do not block on it.
 

package/skills/fo/fo-idea-plan/SKILL.md

@@ -20,9 +20,25 @@ triggerPhrases: ["plan the implementation for this RFC", "create implementation
 </non-goals>
 </MODULE_CONTRACT>
 <CHANGE_SUMMARY>
+  <item>RFC-1250: collect-mode contract — open questions and grilling emit to
+  the decision ledger; draft plan carries PENDING DECISION markers;
+  draft-to-accepted transition deferred to the resolution phase (window =
+  acceptance act).</item>
   <item>RFC-1097: sweep — SKILL.md headers + classification fixes
 
 Sweep batch 1: add Compass v2 headers to 45 SKILL.md files (purpose derived from frontmatter description). Fix non-skill-markdown exclusion to check filename not workspace-relative path (packages/AGENTS.md escaped it). Add .coverage to ignoredDirs.</item>
+  <item>RFC-1250: review wave — QUEUE-07 gates un-parked opens only, ledger binding checks, fail-closed loader
+
+REVIEW-RFC-1250-01 findings: QUEUE-07 no longer fires on parked entries
+(the park is the containment — a parked queue stays resumable and the
+decision window arbitrates it); loader fails open only on ENOENT —
+other read errors are QUEUE-01; ledger gains queue/id-stem binding
+(QUEUE-02), Q-N uniqueness (QUEUE-05), and QUEUE-08 hygiene warnings
+(missing answers, foreign doc ids); next excludes QUEUE-07-blocked
+items; top-level decision totals added. Orchestrator pre-flight treats
+QUEUE-07 as the window agenda — structural errors still stop the batch;
+maturation skips parked/deferred items; uncovered imperative ask sites
+gain collect riders (ADR code-trace, NC markers, audit-verdict guard).</item>
 </CHANGE_SUMMARY>
 -->
 
@@ -71,7 +87,11 @@ If all checks pass, proceed to step 0.3.
 
 #### 0.3. Transition draft → accepted
 
-If the RFC is `draft` or `reviewing` and has `enhancedAt` — the user's instruction to plan IS the architecture acceptance. Transition the RFC to `accepted`:
+If the RFC is `draft` or `reviewing` and has `enhancedAt` — the user's instruction to plan IS the architecture acceptance. Transition the RFC to `accepted`.
+
+**Collect mode exception:** inside an orchestrator-driven queue run the `draft → accepted` transition moves to the resolution phase — the answered decision window IS the acceptance act. In collect mode this skill persists the plan as a draft carrying `PENDING DECISION` markers and does NOT transition the RFC; the orchestrator's resolution phase finalizes (integrate answers, lift markers, transition + commit) after the window.
+
+Standalone/interview-mode flow:
 
 1. Set `status: accepted`.
 2. Set `reviewers` — if the operator specified a reviewer at invocation, use that. Otherwise, read the default reviewer(s) from the `reviewers` field comment in `docs/rfcs/rfc-0000-template.md`. Set all listed default reviewers.
@@ -93,7 +113,7 @@ Then proceed to step 1.
 **Inherited acceptance.** If the RFC has a `specRef` frontmatter field pointing to a spec with `status: accepted`, the acceptance inheritance path applies:
 
 1. Check the audit report for this RFC — if the audit verdict is `approved`, the RFC MAY transition `draft → accepted` without a separate human acceptance ceremony. Record `reviewers` from the spec's `reviewers` field and note `via spec acceptance <spec-id>` in the commit message.
-2. If the audit verdict is `needs-revision` or `rejected`, inheritance is void — a human decision is required. Do not transition; ask the operator.
+2. If the audit verdict is `needs-revision` or `rejected`, inheritance is void — a human decision is required. Do not transition; ask the operator. **Collect mode:** instead of asking, append an `open` ledger entry (`stage: plan`) recording the audit verdict and the inheritance question, leave a `> PENDING DECISION: Q-N` marker in the draft plan, and do not transition — the window arbitrates whether the RFC proceeds or returns to enhance.
 3. If the `specRef` points to a spec with `status: vendored` (not yet accepted), the RFC cannot progress past `draft` — V-SPEC-03 blocks it.
 
 ### 1. Read the RFC
@@ -125,13 +145,15 @@ Verify the RFC's claims about affected artifacts. Check:
 
 After exploring, identify decisions the RFC leaves open — ambiguities, trade-offs, unspecified boundaries, conflicting constraints. These are **decisions**, not facts: if a fact can be found by exploring the codebase, look it up instead of asking.
 
-Walk the user through each question **one at a time**. For each:
+**Collect mode:** under an orchestrated run, never call `ask_user_question` — climb the self-resolution ladder (`_shared/fo-pipeline-conventions.md` §Self-resolution ladder); genuine trade-offs append to the queue's decision ledger as `open` entries (`stage: plan`) with recommended options, and `> PENDING DECISION: Q-N` markers land in the draft plan at the steps that depend on the answer.
+
+Interview mode: walk the user through each question **one at a time**. For each:
 
 1. **Short context** — what the question is, why the plan needs it resolved, what changes depending on the answer.
 2. **Options** — list 2-4 concrete options, **recommended option first**. Mark it with "(recommended)". Each option is a short label plus one line explaining the trade-off.
 3. **Wait** — present the question and stop. Do not batch multiple questions; asking several at once is bewildering.
 
-Use the `ask_user_question` tool when available, with the recommended option as the first entry. Otherwise, present the question inline and wait for the answer.
+Use the `ask_user_question` tool when available (interview mode only), with the recommended option as the first entry. Otherwise, present the question inline and wait for the answer.
 
 Typical questions that arise:
 
@@ -146,7 +168,7 @@ If exploration surfaces no open questions, skip this step and proceed directly t
 
 ### 4. Draft the plan
 
-Copy `docs/plans/plan-0000-template.md` and fill it, incorporating the user's answers from step 3. Each step must have a **completion criterion** — a checkable condition that tells the agent the step is done.
+Copy `docs/plans/plan-0000-template.md` and fill it, incorporating the user's answers from step 3. Each step must have a **completion criterion** — a checkable condition that tells the agent the step is done. Keep the template's `## Falsified routes` ledger section — implementing skills append to it when an approach is abandoned after a real attempt (see `_shared/fo-pipeline-conventions.md` §Falsified-routes ledger).
 
 Step ordering follows the contract-first pattern:
 
@@ -168,7 +190,7 @@ Mark **human review points** on steps that:
 
 ### 5. Grill the plan
 
-Invoke the `/grilling` skill to stress-test the draft plan before persisting. This is **mandatory**, not optional — every plan goes through grilling.
+Invoke the `/grilling` skill to stress-test the draft plan before persisting. This is **mandatory**, not optional — every plan goes through grilling. **Collect mode:** grilling runs in `emit` mode — questions land in the ledger (`stage: plan`) with recommended answers; no interview.
 
 The grilling checks: