@event4u/agent-config 5.10.1 → 6.0.0

package/dist/agent-src/commands/review-routing.md

@@ -0,0 +1,125 @@
+---
+model_tier: high
+name: review-routing
+pack: meta
+tier: 2
+skills: [review-routing, reviewer-awareness]
+description: Compute reviewer roles and matched historical bug patterns for the current diff, using project-local ownership-map.yml and historical-bug-patterns.yml
+suggestion:
+  eligible: true
+  trigger_description: "who should review this, suggest reviewers for this PR"
+  trigger_context: "PR open without assigned reviewers"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# review-routing
+
+> **Intentionally a command, not a skill** (ADR-057, road-to-6.2.0 Step 7b).
+> Meta-tool that debugs task-routing itself. A skill reached only by
+> description-match cannot debug a broken description-matcher (circular
+> dependency); the explicit `/review-routing` command is the guaranteed
+> debug-bypass. Skill-conversion gate **declined**; the `review-routing` skill
+> remains the implementation this command dispatches to.
+
+## Instructions
+
+Produce a review-routing block for the current diff — owner-mapped
+reviewer roles plus any matched historical bug patterns — so the author
+knows *who* to request and *what* to test before opening a PR.
+
+Dispatches to [`review-routing`](../skills/review-routing/SKILL.md) for
+the core resolution logic. The rule
+[`reviewer-awareness`](../rules/reviewer-awareness.md) governs reviewer
+choice, routing, and data handling.
+
+### 1. Gather the diff
+
+- **Default** — use `git diff --name-only origin/main...HEAD` (or the
+  configured trunk branch from `.agent-settings.yml`).
+- **Explicit** — if the user provides a base and head ref, honour them.
+- **Empty diff** — stop with _"no changes, routing skipped"_.
+
+### 2. Dispatch to the skill
+
+Invoke [`review-routing`](../skills/review-routing/SKILL.md) with the
+changed-file list. The skill:
+
+1. Loads `ownership-map.yml` and `historical-bug-patterns.yml` (both
+   optional, package-agnostic paths).
+2. Matches every file against ownership globs (first match wins).
+3. Walks every pattern against the diff.
+4. Computes overall severity (`high` wins).
+5. Returns the structured block.
+
+If neither data file exists, the skill returns the generic fallback
+from [`reviewer-awareness`](../rules/reviewer-awareness.md). That is
+valid output — do not invent owners.
+
+### 3. Present the result
+
+Paste the skill's structured block verbatim under a short header:
+
+```
+## Review Routing (from project data)
+```
+
+Append, if present:
+
+- **Staleness warning** — ownership map > 6 months old.
+- **Required tests** — extracted from matched historical patterns, as a
+  follow-up checklist the author must honour before claiming completion
+  ([`verify-before-complete`](../rules/verify-before-complete.md)).
+
+### 4. Decide next step
+
+After the block, ask:
+
+```
+> 1. Add this routing block to my PR description
+> 2. Request these reviewers now (via gh / GitLab CLI)
+> 3. Re-run after I update the ownership map
+> 4. Stop here — routing block is the deliverable
+```
+
+- On **1**: hand off to
+  [`create-pr-description`](../skills/create-pr:description-only/SKILL.md).
+- On **2**: respect CODEOWNERS — request the *roles* resolved to people
+  by the consumer's own mapping, never invent usernames.
+- On **3**: the user wants to curate the map first. Stop.
+- On **4**: save the block, stop.
+
+## Use this command when
+
+- About to open a PR and unsure who should review it.
+- Preparing a PR description and want owner-mapped reviewers in it.
+- Running a sanity check against historical patterns before claiming
+  completion.
+- CI needs the routing block for a sticky PR comment.
+
+## Do NOT
+
+- NEVER invent owners for paths not in the ownership map — use the
+  generic fallback and say so.
+- NEVER emit individual GitHub usernames in the routing block; the
+  block contains **roles**, CODEOWNERS contains **people**.
+- NEVER downgrade a historical-pattern match because "the author said
+  it's fine" — pattern severity is set in the YAML, not negotiated per
+  PR.
+- NEVER modify `ownership-map.yml` or `historical-bug-patterns.yml` as
+  a side effect of this command.
+- NEVER run this command on a PR with zero changed files — it produces
+  meaningless noise.
+
+## See also
+
+- [`review-routing`](../skills/review-routing/SKILL.md) — the resolver
+- [`reviewer-awareness`](../rules/reviewer-awareness.md) — role vocabulary + data-source rules
+- [`review-routing-data-format`](../docs/guidelines/agent-infra/review-routing-data-format.md)
+  — YAML schemas
+- [`create-pr-description`](../skills/create-pr:description-only/SKILL.md) —
+  consumes the routing block
+- [`verify-before-complete`](../rules/verify-before-complete.md) —
+  consumes the `required_test` list

package/dist/agent-src/commands/roadmap/ai-council.md

@@ -0,0 +1,189 @@
+---
+model_tier: inherit
+name: roadmap-ai-council
+pack: product-basic
+tier: 2
+cluster: roadmap
+sub: ai-council
+skills: [ai-council, agent-docs-writing, roadmap-management]
+description: Challenge a roadmap with the AI council (deep tier) and refactor from convergence findings. Wraps `/council default` pinned to `--input-mode roadmap --depth deep`; patches surface as numbered options.
+council_depth: deep
+suggestion:
+  eligible: true
+  trigger_description: "council on roadmap, challenge this roadmap, stress-test the plan, refactor roadmap from council findings"
+  trigger_context: "existing agents/roadmaps/*.md the user wants reviewed before execution"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# /roadmap:ai-council
+
+Council-driven challenge + refactor scope of the
+[`/roadmap`](../roadmap.md) cluster. Pins the input mode to
+`roadmap` and the depth tier to `deep` (architecture / refactor
+artefact), then drives the user through applying convergence
+findings as numbered patches against the roadmap file.
+
+**Source of truth:** `.agent-src.uncondensed/` — never read or edit
+`dist/agent-src/` or `.augment/` directly.
+
+## Instructions
+
+### 1. Resolve the target roadmap
+
+Parse the argument as a roadmap path or filename:
+
+- `/roadmap:ai-council agents/roadmaps/<name>.md` — explicit path.
+- `/roadmap:ai-council <name>` — fuzzy match against
+  `agents/roadmaps/*.md`; if multiple match, list and ask
+  (one question per turn per `ask-when-uncertain`).
+- No argument → list `agents/roadmaps/*.md` and ask.
+
+Capture the **original ask** verbatim — the user's framing sentence
+that triggered this council run (e.g. *"review this roadmap before
+I execute it"*). This flows into `--original-ask`.
+
+### 2. Run the `/council default` flow with these pinned flags
+
+Follow [`/council default`](../council/default.md) Steps 2–4
+**verbatim**, with these arguments fixed:
+
+- `--input-mode roadmap`
+- `--depth deep` (this command declares `council_depth: deep` in
+  frontmatter; the host translates it into `--depth deep`)
+- `--output agents/runtime/council/responses/<roadmap-stem>-roadmap.json`
+  (overwrite if it exists; the previous run is the predecessor for
+  this iteration)
+- `--original-ask "<captured-ask>"`
+
+`--depth deep` floors rounds at
+`max(ai_council.deep_min_rounds, ai_council.min_rounds)` (default
+`3`). Do **not** pass `--rounds` unless the user explicitly asked
+for a different count.
+
+The cost gate from `/council default` Step 3 still applies — billable
+members require user confirmation **even under `personal.autonomy: on`**
+(per the deep tier surcharge — typical cost ~$0.05–0.13 vs. ~$0.02
+for the standard tier).
+
+### 3. Render the report
+
+Run `./agent-config council:render <output.json>` and write the
+**Convergence / Divergence** section per
+[`/council default § Render`](../council/default.md). Do **not** end
+with `/council default`'s generic numbered-options block — the
+refactor flow in Step 4 replaces it.
+
+### 4. Append a Council review block to the roadmap
+
+Open the roadmap file and append (do **not** overwrite existing
+content):
+
+```markdown
+
+## Council review (<UTC date>)
+
+<Convergence section verbatim>
+
+### Convergence findings
+
+1. **<Finding 1 title>** — <one-line summary> · trace: §<member-section>
+2. **<Finding 2 title>** — <one-line summary> · trace: §<member-section>
+…
+
+### Divergences (no consensus)
+
+- **<Topic>** — <Member A says X, Member B says Y; user decides>
+
+### Predecessor council trace
+
+`agents/runtime/council/responses/<roadmap-stem>-roadmap.json` (this run).
+```
+
+Run `./agent-config roadmap:progress` after the append. The block
+adds no `[ ]` checkboxes, so the dashboard counts stay flat.
+
+### 5. Apply the critical-evaluation lens, then surface verdicted patches
+
+Before drafting any patch, run every finding from Step 4 through the
+*Critical evaluation* checklist from the
+[`ai-council` skill](../../skills/ai-council/SKILL.md#critical-evaluation--convener-skeptic-stance):
+
+- **Codebase fit** — does the finding match the actual roadmap content, file paths, scripts, contracts cited in the roadmap? (`view` / `codebase-retrieval`)
+- **Locked-decision conflict** — does it contradict an ADR (`docs/decisions/`), a contract (`docs/contracts/`), a kernel rule, or an earlier locked decision in **this** roadmap?
+- **Already addressed** — is the finding already covered by an existing step, AC, or phase in the roadmap?
+- **Cost / benefit** — does the patch's scope vs. roadmap value clear the bar?
+- **Hallucination** — does the finding cite a file, function, phase, or step that does not exist?
+
+For every finding, attach a verdict — **`accept`**, **`accept-with-modification`**, **`reject`**, or **`needs-input`** — with a one-line reason citing host evidence (file:line, ADR, contract, roadmap step).
+
+Append a **Host verdict** sub-block under the Council review block in the roadmap:
+
+```markdown
+### Host verdict
+
+| # | Finding | Verdict | Reason |
+|---|---|---|---|
+| 1 | <one-line> | `accept` | matches `agents/roadmaps/<this>.md` Phase X step Y |
+| 2 | <one-line> | `accept-with-modification` | narrow scope to phase Z — global change contradicts AC §N |
+| 3 | <one-line> | `reject` | contradicts ADR `docs/decisions/<adr>.md` |
+| 4 | <one-line> | `needs-input` | open question — user picks below |
+```
+
+Then surface a single numbered-options block per [`user-interaction`](../../rules/user-interaction.md), carrying the verdict per option:
+
+> 1. `[accept]` Apply finding 1 — <one-line patch summary>
+> 2. `[accept-with-modification]` Apply finding 2 (modified) — <one-line patch summary + adjustment>
+> 3. `[reject]` Skip finding 3 — <one-line reason> (override available below)
+> 4. `[needs-input]` <open question for finding 4>
+> …
+> N. Apply all `accept` findings (recommended only if non-conflicting)
+> N+1. Override host verdict — apply a finding the host rejected (specify number)
+> N+2. Skip — leave Council review block + Host verdict as advisory only
+
+The user picks one or more numbers (`1,3,5` is allowed). Apply each selected patch via `str-replace-editor` against the roadmap, then re-run `./agent-config roadmap:progress` once at the end so the dashboard reflects the new step / AC count.
+
+**Verdict ≠ filter.** Every finding stays visible in the Host verdict block with its verdict and reason — the user can override at any time. The host filters its **own** recommendation; it does not hide council output.
+
+### 6. Hard floor — text + roadmap edits only
+
+`/roadmap:ai-council` may:
+
+- write `agents/runtime/council/responses/<…>.json`
+- append the Council review block to the named roadmap
+- apply user-picked patches to the same roadmap
+- regenerate `agents/roadmaps-progress.md`
+
+It does **NOT**:
+
+- edit any other roadmap, command, rule, or skill file
+- commit, push, or open a PR
+- run `git` beyond `git diff` (read-only)
+
+## Rules
+
+- **One roadmap per invocation.** Re-run for the next file.
+- **Critical evaluation is mandatory** — every council finding gets
+  a host verdict (`accept` / `accept-with-modification` / `reject` /
+  `needs-input`) with one-line evidence before any patch is drafted.
+  Convergence ≠ correctness; the council never saw the codebase. See
+  [`ai-council § Critical evaluation`](../../skills/ai-council/SKILL.md#critical-evaluation--convener-skeptic-stance).
+- **Decline = silence** ([`scope-control`](../../rules/scope-control.md)) —
+  if the user picks "Skip — advisory only", the Council review block
+  + Host verdict stay in the roadmap, but no patches are applied. Do
+  not re-ask the question on the same task.
+- **Cost gate is non-negotiable** — the deep tier costs more than
+  standard; confirm before every billable run, even with
+  `personal.autonomy: on`.
+- **No commit.** Patches land in the working tree only; commit
+  decisions stay with the user per
+  [`commit-policy`](../../rules/commit-policy.md).
+
+## See also
+
+- [`/roadmap`](../roadmap.md) — cluster orchestrator
+- [`/council default`](../council/default.md) — base flow this command wraps
+- [`ai-council`](../../skills/ai-council/SKILL.md) — neutrality, redaction, deep tier
+- [`scripts/council_cli.py`](../../../scripts/council_cli.py) — CLI entry point

package/dist/agent-src/commands/roadmap/create.md

@@ -0,0 +1,214 @@
+---
+model_tier: inherit
+name: roadmap-create
+pack: product-basic
+tier: 2
+cluster: roadmap
+sub: create
+skills: [agent-docs-writing]
+description: Interactively create a new roadmap file in agents/roadmaps/
+suggestion:
+  eligible: true
+  trigger_description: "create a roadmap for X, plan this work as a roadmap"
+  trigger_context: "multi-phase work without an existing agents/roadmaps/*.md"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# /roadmap create
+## Instructions
+
+### 1. Determine location
+
+Ask the user (in their language) where the roadmap should be created:
+
+> 1. Project root (`agents/roadmaps/`)
+> 2. In a module (`{module_root}/{Name}/{agent_folder}/roadmaps/`)
+
+If the user picks a module → resolve module roots via
+`scripts/_lib/agent_settings.py::enumerate_modules()`, list available
+modules from `modules.root_paths`, and ask which one. The target
+directory is `{module_path}/{modules.agent_folder}/roadmaps/`
+(default `agent_folder` = `agents`).
+Create the `roadmaps/` directory if it doesn't exist at the chosen location.
+
+### 2. Read the roadmap template
+
+- Read `.augment/templates/roadmaps.md` for the roadmap structure.
+- Use its structure as the basis for the new roadmap.
+
+### 3. Gather content interactively
+
+Ask the user (in their language) step by step:
+
+1. **Title / goal**: What is the goal of this roadmap? (one sentence)
+2. **Context**: What context is important? (module, affected classes, Jira tickets, etc.)
+3. **Phases**: What phases does the roadmap have? (e.g. "Phase 1: Preparation, Phase 2: Migration, Phase 3: Cleanup")
+4. For each phase → What steps belong in Phase {N}?
+
+After each input, show what you've captured and ask the user (in their language) to confirm or adjust.
+
+**Important:** The user may answer in any language, but the roadmap file must be written in **English**.
+Translate user input to English when writing the file.
+
+### 4. Build the roadmap file
+
+Use the template structure:
+
+```markdown
+# Roadmap: {title}
+
+> {One sentence goal}
+
+## Prerequisites
+
+- [ ] Read `AGENTS.md` and relevant module docs
+- [ ] {any specific prerequisites}
+
+## Context
+
+{Context from user input}
+
+## Phase 1: {name}
+
+- [ ] **Step 1:** {description}
+- [ ] **Step 2:** {description}
+- [ ] ...
+
+## Phase 2: {name}
+
+- [ ] **Step 1:** {description}
+- [ ] ...
+
+## Acceptance Criteria
+
+- [ ] {criteria}
+- [ ] All quality gates pass (PHPStan, Rector, tests)
+
+## Notes
+
+{Optional notes}
+```
+
+### 5. Review loop
+
+Show the complete roadmap to the user and ask (in their language) if anything should be added or changed.
+
+- If yes → apply changes, show again.
+- Repeat until the user says it's done.
+
+### 6. Save the file
+
+- Generate a filename from the title: kebab-case, e.g. `optimize-webhook-jobs.md`.
+
+**Before saving, check for filename collisions across the entire
+roadmap namespace** — active, `archive/`, `skipped/`, and any nested
+subdirs (e.g. `agent-memory/`). A new roadmap that shadows an
+archived or skipped one silently buries history; never overwrite,
+never auto-suffix without the user's pick.
+
+```bash
+NAME="<kebab-case-name>.md"
+# Project-root roadmaps:
+find agents/roadmaps -type f -iname "$NAME" 2>/dev/null
+# Module-scoped roadmaps (only if step 1 picked a module):
+# resolve <ModuleRoot>/<Module>/<AgentFolder>/roadmaps/ via enumerate_modules()
+find <ModuleRoot>/<Module>/<AgentFolder>/roadmaps -type f -iname "$NAME" 2>/dev/null
+```
+
+Use `-iname` (case-insensitive) so case-only differences still count
+as a collision on case-sensitive filesystems.
+
+If the search returns one or more hits → **STOP**. Show the matches
+and ask (in the user's language):
+
+> Found N existing roadmap(s) with this name:
+>   - `agents/roadmaps/archive/<file>.md` (archived)
+>   - `agents/roadmaps/skipped/<file>.md` (skipped)
+>
+> 1. Pick a different name — suggest `<name>-v2`, `<name>-<scope>`, or `<name>-<YYYY-MM>`
+> 2. Open the existing file first — revival or extension may be the right move
+> 3. Abort creation
+
+- **1** → re-prompt for name, re-run the collision check, repeat until clean.
+- **2** → read the existing roadmap, summarize state, hand back to the user.
+- **3** → stop without writing anything.
+
+Only when the search is empty: save to the chosen location and show the final path.
+
+### 7. Update the progress dashboard
+
+Regenerate `agents/roadmaps-progress.md` so the new roadmap shows up:
+
+```bash
+./agent-config roadmap:progress
+```
+
+Mention the new overall count to the user.
+
+### 8. Offer council review (B1 hook, verbosity-gated)
+
+Read `verbosity.offer_council_in_delivery` from `.agent-settings.yml`
+(default `false`):
+
+- `false` (default): skip the prompt silently. When `ai_council.enabled:
+  true` AND at least one member enabled, emit one line: `→ council
+  skipped (set verbosity.offer_council_in_delivery: true to enable, or
+  run /council roadmap:<path> directly)`. Otherwise emit nothing.
+- `true`: when `ai_council.enabled: true` **and** at least one member
+  enabled (`anthropic` or `openai`), ask (in the user's language):
+
+  > 1. Run the council on this roadmap before execution? (billable)
+  > 2. Skip council review
+
+  Also suppress when `personal.autonomy: on` (council is billable; see
+  `road-to-ai-council.md` Decision 3 / Q47).
+
+If the user picks **1**:
+
+- Run `/council roadmap:<path>` with the user's original ask captured
+  in step 1 as `original_ask` (the handoff preamble carries it
+  verbatim, see `scripts/ai_council/prompts.py`).
+- Append the council findings as a `## Council review (<UTC date>)`
+  section at the bottom of the roadmap. Include the trace path to
+  `agents/runtime/council/sessions/<timestamp>/raw-text.md` so future readers
+  can audit.
+- Do **not** rewrite the roadmap based on the findings — surface them,
+  let the user decide what to act on.
+
+If the user picks **2** → continue.
+
+### 9. Offer execution
+
+After saving (and any council review), ask the user (in their language) whether to start executing the roadmap immediately.
+
+If yes → switch to [`/roadmap:process-phase`](process-phase.md) with
+the newly created file (the default execution scope of the `/roadmap`
+cluster). Offer [`process-step`](process-step.md) and
+[`process-full`](process-full.md) as alternatives. The legacy
+`/roadmap execute` command was removed — autonomous execution is the
+only path now.
+
+### Rules
+
+- **Do NOT auto-generate content** — always ask the user for input.
+- **Do NOT commit or push.**
+- **Do NOT include commit steps in the roadmap** unless the user explicitly
+  requested them. See [`commit-policy`](../rules/commit-policy.md#never-write-commit-steps-into-roadmaps-unsolicited).
+  Roadmaps plan **work**; commits are a separate delivery decision.
+- **Every phase MUST contain at least one `- [ ]` checkbox.** A roadmap
+  without checkboxes is invisible to `agents/roadmaps-progress.md` and
+  violates [`roadmap-progress-sync`](../rules/roadmap-progress-sync.md)
+  Iron Law #2.
+- **Status is binary: `ready` (default) or `draft`.** Create new
+  roadmaps as **ready** — no `status:` field needed.
+  Only mark `status: draft` (in YAML frontmatter) when the
+  user explicitly says it should be hidden from the dashboard (still
+  being authored, awaiting upstream decisions, capture-only synthesis
+  without executable phases). If the user wants draft, ask once at
+  step 3 — do not infer it.
+- Follow the roadmap template from `.augment/templates/roadmaps.md`; write in English (project convention).
+- Keep the file focused: 500–1000 lines max. If larger, suggest splitting.
+- **Never overwrite an existing roadmap.** Step 6 scans `active/`, `archive/`, `skipped/` (+ subdirs); on collision → STOP, present rename / open / abort. Auto-suffix requires explicit pick.

package/dist/agent-src/commands/roadmap/process-full.md

@@ -0,0 +1,109 @@
+---
+model_tier: medium
+name: roadmap-process-full
+pack: product-basic
+tier: 2
+cluster: roadmap
+sub: process-full
+skills: [agent-docs-writing, ai-council, roadmap-management]
+description: Autonomously process every open step across every phase of a roadmap until the file is fully closed. Largest execution scope of the /roadmap cluster — runs continuously across phase boundaries.
+suggestion:
+  eligible: true
+  trigger_description: "process the whole roadmap, finish the roadmap, komplette roadmap abarbeiten"
+  trigger_context: "existing agents/roadmaps/*.md and user wants the entire file done end-to-end"
+workspaces:
+  - agent-config-maintainer
+packs:
+  - meta
+---
+
+# /roadmap:process-full
+
+Whole-roadmap execution scope of the [`/roadmap`](../roadmap.md)
+cluster. Same canonical loop as
+[`/roadmap:process-phase`](process-phase.md), but does **not** stop at
+phase boundaries — continues until every step is closed (or a halt
+condition fires).
+
+## Instructions
+
+Run the canonical loop in
+[`contexts/execution/roadmap-process-loop`](../../contexts/execution/roadmap-process-loop.md)
+with the **scope delta below**.
+
+## Scope delta
+
+- **Working set:** every open step across every phase, in document
+  order. Phase-internal annotations like `(deferred)` / `(optional)` /
+  "gated on Phase N" do not narrow the working set.
+- **Stop after:** the entire roadmap reaches `count_open == 0`, or a
+  halt condition fires (Hard-Floor, council-off + ambiguity,
+  security-sensitive, scope-out-of-roadmap, test/quality red).
+- **Phase boundary handling:** at every phase boundary, run the
+  per-phase quality pipeline when `quality_cadence: per_phase` (or
+  `per_step`). On red → stop, surface, do **not** silently roll into
+  the next phase.
+- **Final archival:** when the roadmap is fully closed, run the
+  archival check from
+  [`roadmap-process-loop § 6`](../../contexts/execution/roadmap-process-loop.md#6-final-report-and-archival).
+
+## Iron Law — Full is Full
+
+```
+/roadmap:process-full PROCESSES EVERY OPEN STEP IN THE FILE.
+PHASE-INTERNAL "(DEFERRED)" / "(OPTIONAL)" / "GATED ON PHASE X"
+NOTES DO NOT NARROW THE WORKING SET. ONLY THE FIVE HALT CONDITIONS
+STOP THE RUN.
+```
+
+Phase-internal `(deferred)` / `(optional)` / `gated on Phase N` tags are
+authoring annotations, not execution gates. `/roadmap:process-full`
+ignores them by construction. If the user wants narrower execution they
+invoke `/roadmap:process-phase` (scope = single phase) or
+`/roadmap:process-step` (scope = single step) instead.
+
+Time-boxed plate / horizon framing is opt-in via
+`roadmap.horizon_weeks` in `.agent-settings.yml` (default `0` =
+forbidden, per template rule 16 in `templates/roadmaps.md`). If a
+roadmap carries such phrasing — whether by legacy or by an opt-in
+setting — treat it as ordinary prose during execution, never as a
+gate. Phase ordering and explicit dependency gates govern the loop.
+
+## Iron Law — Real-time dashboard
+
+```
+EVERY DONE STEP FLIPS [ ] → [x] BEFORE THE LOOP MOVES TO THE NEXT STEP.
+DASHBOARD REGENERATES IN THE SAME REPLY THAT FLIPPED THE BOX.
+NO BATCH FLIP AT THE ARCHIVE COMMIT. NO "I'LL DO IT AT THE END."
+```
+
+`/roadmap:process-full` is the worst offender for batching because it
+runs continuously across many steps. Flipping all 13 boxes in the
+single archive commit defeats the dashboard's purpose — the user
+loses progress visibility for the entire run. Per Iron Law 2 of
+[`roadmap-progress-sync`](../../rules/roadmap-progress-sync.md): the
+flip + regen pair is atomic with the step's work, executed inside
+[`roadmap-process-loop § 5`](../../contexts/execution/roadmap-process-loop.md#5-step-loop)
+step 5.
+
+## Rules
+
+- **No silent acceleration past a halt.** Every halt condition stops
+  the run; the user resumes on the next turn.
+- **No silent stop at an authoring annotation.** Encountering
+  "gated on Phase N", "deferred", "optional", or any equivalent
+  phase-internal annotation is **not** a halt condition. Continue.
+- **No silent batch flip.** Each step's checkbox flips in the same
+  reply that lands its work — never deferred to the archive commit.
+- **Phase quality pipeline runs at every phase boundary** when cadence
+  is `per_phase` or `per_step`. `end_of_roadmap` skips per-phase and
+  runs only at the final archival check.
+- All other rules from
+  [`process-phase § Rules`](process-phase.md#rules) apply unchanged.
+
+## See also
+
+- [`/roadmap`](../roadmap.md) — cluster orchestrator
+- [`/roadmap:process-step`](process-step.md) — single-step variant
+- [`/roadmap:process-phase`](process-phase.md) — default scope, single phase
+- [`roadmap-process-loop`](../../contexts/execution/roadmap-process-loop.md) — canonical mechanics