codebyplan 1.13.53 → 1.13.55

package/templates/skills/{cbp-round-execute → cbp-round-build}/SKILL.md

@@ -1,26 +1,52 @@
 ---
-name: cbp-round-execute
-description: Execute the approved plan from /cbp-round-start — runs per-wave executors, inline testing-qa per wave, and routes to /cbp-round-end
+name: cbp-round-build
+description: Execute the approved plan from /cbp-round-plan — runs per-wave builders, inline testing-qa per wave, and auto-triggers /cbp-verify
+triggers: [cbp-verify]
 effort: xhigh
 ---
 
-# Round Execute Command
+# Round Build Command
 
-Execution and validation phase. Receives the approved plan from `/cbp-round-start`, dispatches wave executors, runs per-wave `cbp-testing-qa-agent` in parallel, and routes to `/cbp-round-end`.
+Execution phase. Receives the approved plan from `/cbp-round-plan`, dispatches wave builders, runs per-wave `cbp-testing-qa-agent` in parallel during execution, and auto-triggers `/cbp-verify` (scope=round) when execution completes. The deterministic gates, real-execution proof, and fresh-context review live in `/cbp-verify` — this skill builds; verify judges.
 
 ## Pipeline
 
 ```
-/cbp-round-start → /cbp-round-execute → /cbp-round-end (auto)
+/cbp-round-plan → /cbp-round-build → /cbp-verify (scope=round, auto)
 ```
 
 ## Approval Model
 
-The `ask`-tier `Skill(cbp-round-execute)` permission prompt (configured in `settings.json`) is the **plan-approval gate** handed off from `/cbp-round-start`: confirming the permission approves the plan; declining it returns control to `/cbp-round-start` (re-plan with feedback) or `/cbp-round-input` (wrong direction). Once execution begins, the executors (`cbp-round-executor`, `cbp-mechanical-edits`) and the 3-INLINE / 3-SURVEY paths apply edits **automatically** — there is NO in-skill AskUserQuestion for approval. The only downstream user decisions are genuine ones: the dev-server start prompt (Step 4) and the baseline-regression accept gate (`/cbp-round-end` Step 7).
+The `ask`-tier `Skill(cbp-round-build)` permission prompt (configured in `settings.json`) is the **plan-approval gate** handed off from `/cbp-round-plan`: confirming the permission approves the plan; declining it returns control to `/cbp-round-plan` (re-plan with feedback, or its deep-analysis path for a wrong-direction restart). Once execution begins, the builders (`cbp-round-builder`, `cbp-mechanical-edits`) and the 3-INLINE / 3-SURVEY paths apply edits **automatically** — there is NO in-skill AskUserQuestion for approval. The only downstream user decision in this skill is the genuine one: the dev-server start prompt (Step 4). The baseline-regression accept gate is owned by `/cbp-verify`.
 
 ## Identifier Notation
 
-This skill operates on the **active** task/round resolved via MCP `get_current_task` / `get_rounds` and does not accept a positional identifier argument. Canonical chk-task-round notation is defined in `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary".
+This skill operates on the **active** task/round resolved from local state (break-glass: MCP `get_current_task` / `get_rounds`) and does not accept a positional identifier argument. Canonical chk-task-round notation is defined in `cbp-round-plan` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary".
+
+## Builder Spawn Failure Is A Gate Failure
+
+A `cbp-round-builder` (or `cbp-testing-qa-agent`) spawn failure — the agent could not run, or died
+before emitting its output contract (provider 5xx, monthly Agent usage cap, rate limit, context
+overflow at spawn, billing block) — is a **HARD GATE FAILURE** per
+`rules/spawn-failure-is-gate-failure.md`. The orchestrator does **NOT** walk the builder's phases
+inline and self-certify the build. STOP and surface the retry directive verbatim:
+
+```
+## Build blocked — builder could not spawn
+
+The round builder (cbp-round-builder) failed to spawn: <class> — <verbatim error>.
+This is a hard gate failure, not a completed build. Retry when capacity returns:
+  Next: /cbp-round-build
+```
+
+Record `round.context.builder_findings.spawn_failure = { class, error_message, decided_at }`. Do NOT
+continue to Step 8 (verify) without a real build.
+
+The **two carve-outs are NOT inline fallback** (`rules/spawn-failure-is-gate-failure.md` §Carve-Out):
+the 3-INLINE / 3-SURVEY paths (Step 3) have no builder to spawn by design — `.claude/`-only edits and
+empty-files surveys are first-class deterministic paths the orchestrator runs directly. The
+`claude_only` testing path (Step 5) likewise has no `cbp-testing-qa-agent` to spawn by design; its
+proof is the deterministic command set. Neither is a substitute for a failed agent spawn.
 
 ## Instructions
 
@@ -30,11 +56,11 @@ Read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>.json` (local-f
 
 Read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/<roundId>.json` (local-first) to find the in-progress round. Same sync / break-glass pattern (MCP `get_rounds` as fallback).
 
-If no in-progress round: `No active round. Run /cbp-round-start first.`
+If no in-progress round: `No active round. Run /cbp-round-plan first.`
 
 ### Step 2: Load Approved Plan
 
-Read the plan from round context (`context.planner_output`). If no plan: `No approved plan in round context. Run /cbp-round-start first.`
+Read the plan from round context (`context.planner_output`). If no plan: `No approved plan in round context. Run /cbp-round-plan first.`
 
 Read effective testing profile: `round.context.testing_profile_override` if set (user override for this round only), else `task.context.testing_profile` (set by planner Phase 4.8), else default `'web'`. Pass the effective profile to all per-wave `cbp-testing-qa-agent` spawns.
 
@@ -44,14 +70,14 @@ Inspect `approved_plan.files_to_modify[]` and `approved_plan.round_type`. Four e
 
 | Condition                                                                        | Path                                                                                                             |
 | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
-| `files_to_modify[]` empty AND `round_type === 'survey'`                          | **3-SURVEY** — orchestrator executes inline; constructs executor-equivalent output; NEVER spawn `cbp-round-executor` |
-| Every entry under `.claude/**`                                                   | **3-INLINE** — orchestrator applies via build-cc skills or direct Edit; NEVER spawn `cbp-round-executor`             |
+| `files_to_modify[]` empty AND `round_type === 'survey'`                          | **3-SURVEY** — orchestrator executes inline; constructs builder-equivalent output; NEVER spawn `cbp-round-builder` |
+| Every entry under `.claude/**`                                                   | **3-INLINE** — orchestrator applies via build-cc skills or direct Edit; NEVER spawn `cbp-round-builder`             |
 | At least one entry outside `.claude/**` AND `approved_plan.waves[]` has ≥2 waves | **3-WAVE** — dispatch per-wave per schema in `approved_plan.waves[]`                                             |
-| At least one entry outside `.claude/**` (single wave or no waves field)          | **3-AGENT** — spawn single `cbp-round-executor`                                                                      |
+| At least one entry outside `.claude/**` (single wave or no waves field)          | **3-AGENT** — spawn single `cbp-round-builder`                                                                      |
 
 #### Step 3-SURVEY: Empty-Files Survey Path
 
-Execute the survey instructions inline using Read/Grep/Bash. Save to `round.context.survey_output`. Build executor-equivalent output object with `round_type: 'survey'`. Skip to Step 3c.
+Execute the survey instructions inline using Read/Grep/Bash. Save to `round.context.survey_output`. Build builder-equivalent output object with `round_type: 'survey'`. Skip to Step 3c.
 
 `round_type: 'survey'` MUST be set in `round.context` so Step 4 (dev-server probe) and downstream skills short-circuit correctly.
 
@@ -67,36 +93,36 @@ For each entry, route per `rules/file-routing.md`:
 - `.claude/context/**`, `.claude/docs/**` → direct Edit
 - `.claude/hooks/{name}.sh` → direct Write/Edit
 
-Build executor-equivalent output object inline. Skip to Step 3c.
+Build builder-equivalent output object inline. Skip to Step 3c.
 
 #### Step 3-WAVE: Multi-Wave Dispatch
 
 When `approved_plan.waves[]` is present and has ≥2 entries:
 
 1. Topological-sort waves by `depends_on[]` to determine dispatch order.
-2. For each wave whose `depends_on[]` names are all complete, spawn the wave executor:
-   - `agent_type: 'cbp-round-executor'` → spawn `cbp-round-executor` with wave-scoped input (see `agents/cbp-round-executor.md` wave input contract)
+2. For each wave whose `depends_on[]` names are all complete, spawn the wave builder:
+   - `agent_type: 'cbp-round-builder'` → spawn `cbp-round-builder` with wave-scoped input (see `agents/cbp-round-builder.md` wave input contract)
    - `agent_type: 'inline'` → execute inline as 3-INLINE path, scoped to `wave.files[]`
-3. After each wave completes, spawn `cbp-testing-qa-agent` against `wave.files[]` with `testing_profile` from Step 2. Run this testing spawn in PARALLEL with the next wave's executor when dependency order allows.
-4. After all waves complete, merge all `files_changed[]` into a single executor output.
+3. After each wave completes, spawn `cbp-testing-qa-agent` against `wave.files[]` with `testing_profile` from Step 2. Run this testing spawn in PARALLEL with the next wave's builder when dependency order allows.
+4. After all waves complete, merge all `files_changed[]` into a single builder output.
 
-#### Step 3-AGENT: Single `cbp-round-executor` Spawn
+#### Step 3-AGENT: Single `cbp-round-builder` Spawn
 
 #### Mechanical-Edits Delegation Gate
 
-Before spawning `cbp-round-executor`, inspect `task.context.work_mode` (set by cbp-task-planner Phase 4.1).
+Before spawning `cbp-round-builder`, inspect `task.context.work_mode` (set by cbp-round-planner Phase 4.1).
 
-| Value              | Action                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
-| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `mechanical`       | Spawn `cbp-mechanical-edits` instead of `cbp-round-executor`. Derive the spec (renames / substitutions / frontmatter_edits / index_regen) from `approved_plan.files_to_modify[]` + the task's deliverables; pass it via the prompt body per the agent's Input Contract. After the agent returns, verify `git status --porcelain` reflects only expected paths AND `validation.orphaned_refs` is empty. Skip the rest of Step 3-AGENT and proceed to Step 3b.                                                                                                                                                                                                         |
-| `mixed`            | Read `task.context.mechanical_files[]` (populated by cbp-task-planner Phase 4.1 per its partition rule). Spawn `cbp-round-executor` for the AUTHORED portion FIRST — the executor's `files` input is `files_to_modify[]` MINUS `mechanical_files[]`. After it returns, spawn `cbp-mechanical-edits` against ONLY `mechanical_files[]` — derive the spec (renames / substitutions / frontmatter_edits / index_regen) from those entries' purpose strings. Merge both `files_changed[]` results into a single output for Step 5. If `mechanical_files[]` is absent or empty when `work_mode === 'mixed'`, halt with a planner-output error (Phase 4.1 contract violation). |
-| `design` or absent | Proceed with the existing `cbp-round-executor` spawn below (no change in behaviour).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| Value              | Action                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `mechanical`       | Spawn `cbp-mechanical-edits` instead of `cbp-round-builder`. Derive the spec (renames / substitutions / frontmatter_edits / index_regen) from `approved_plan.files_to_modify[]` + the task's deliverables; pass it via the prompt body per the agent's Input Contract. After the agent returns, verify `git status --porcelain` reflects only expected paths AND `validation.orphaned_refs` is empty. Skip the rest of Step 3-AGENT and proceed to Step 3b.                                                                                                                                                                                                         |
+| `mixed`            | Read `task.context.mechanical_files[]` (populated by cbp-round-planner Phase 4.1 per its partition rule). Spawn `cbp-round-builder` for the AUTHORED portion FIRST — the builder's `files` input is `files_to_modify[]` MINUS `mechanical_files[]`. After it returns, spawn `cbp-mechanical-edits` against ONLY `mechanical_files[]` — derive the spec (renames / substitutions / frontmatter_edits / index_regen) from those entries' purpose strings. Merge both `files_changed[]` results into a single output for Step 5. If `mechanical_files[]` is absent or empty when `work_mode === 'mixed'`, halt with a planner-output error (Phase 4.1 contract violation). |
+| `design` or absent | Proceed with the existing `cbp-round-builder` spawn below (no change in behaviour).                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
 
-**Universal postcondition for both `mechanical` and `mixed`:** if any spawned `cbp-mechanical-edits` reports `validation.orphaned_refs.length > 0`, treat as a hard-fail signal and route through Step 6 (regardless of whether the executor also ran in the `mixed` path).
+**Universal postcondition for both `mechanical` and `mixed`:** if any spawned `cbp-mechanical-edits` reports `validation.orphaned_refs.length > 0`, treat as a hard-fail signal and route through Step 6 (regardless of whether the builder also ran in the `mixed` path).
 
-This gate is distinct from Phase 2.95's `execution_mode` parallelism hint (consumed downstream by `cbp-round-executor` Step 3.5 for batch-create scenarios). Both gates can fire on the same task.
+This gate is distinct from Phase 2.95's `execution_mode` parallelism hint (consumed downstream by `cbp-round-builder` Step 3.5 for batch-create scenarios). Both gates can fire on the same task.
 
-Spawn `cbp-round-executor` with the approved plan and full context:
+Spawn `cbp-round-builder` with the approved plan and full context:
 
 ```yaml
 input:
@@ -108,7 +134,7 @@ input:
   resources: [merged from checkpoint.resources + task.resources]
 ```
 
-Wait for executor output.
+Wait for builder output. **If the spawn fails, STOP per "Builder Spawn Failure Is A Gate Failure" above.**
 
 ### Step 3b: Database Work (if plan includes DB changes)
 
@@ -116,21 +142,21 @@ If the approved plan includes database schema changes, RLS policies, or type gen
 
 1. Spawn `cbp-database-agent` with DB-related steps from the plan
 2. Wait for completion
-3. Merge `files_changed` into executor output
+3. Merge `files_changed` into builder output
 
 ### Step 3b-stripe: Stripe Work (if plan includes Stripe integration)
 
 If the approved plan includes Stripe integration work (files under `stripe/`, or plan steps referencing `payment`, `checkout`, `webhook`, `subscription`, or an explicit `stripe_work: true` flag from the planner):
 
-1. Spawn `cbp-stripe-agent` with Stripe-related steps from the plan and `files_changed_scope` from the executor output
+1. Spawn `cbp-stripe-agent` with Stripe-related steps from the plan and `files_changed_scope` from the builder output
 2. Wait for completion
-3. Merge `files_changed` into executor output
+3. Merge `files_changed` into builder output
 
 ### Step 3c: Completion Check
 
 - `status: 'completed'` and all deliverables done → proceed to Step 4
-- `status: 'blocked'` → present blocker to user via AskUserQuestion, resolve, re-spawn executor with remaining work
-- Deliverables incomplete → re-spawn executor with remaining deliverables (max 3 re-triggers). After 3 re-triggers, save partial output and proceed.
+- `status: 'blocked'` → present blocker to user via AskUserQuestion, resolve, re-spawn builder with remaining work
+- Deliverables incomplete → re-spawn builder with remaining deliverables (max 3 re-triggers). After 3 re-triggers, save partial output and proceed.
 
 ### Step 4: Dev-Server Probe (rounds 2+, web/desktop profile)
 
@@ -150,14 +176,14 @@ Skip this probe for `testing_profile === 'claude_only'` or `'backend'`.
 
 Read `task.context.testing_profile` (already loaded in Step 2).
 
-**claude_only profile**: run inline checks only (no `cbp-testing-qa-agent` spawn):
+**claude_only profile** (deterministic-only path — no `cbp-testing-qa-agent` spawn by design, NOT a fallback): run inline checks only:
 
 1. `bash -n <hook-file>` for each modified `.sh` in `files_changed`
 2. Verify each modified/created SKILL.md ≤300 lines (warn threshold; hook blocks at 600); `scope:` marker present; no `/cbp-*` notation
 
-On pass, synthesise `testing_qa_output` inline per the procedure in `reference/inline-fallback.md` "Validation fallback" section (output shape defined in `agents/cbp-testing-qa-agent.md` Output Contract) and persist to `round.context.testing_qa_output` at Step 7.
+On pass, synthesise `testing_qa_output` inline (output shape defined in `agents/cbp-testing-qa-agent.md` Output Contract; mark `mode: 'inline_synthesised_for_claude_only_profile'`) and persist to `round.context.testing_qa_output` at Step 7. This is the documented happy path for the `claude_only` profile — the agent was never expected to spawn.
 
-**All other profiles**: spawn `cbp-testing-qa-agent` against the wave's `files[]` (or full executor output in single-wave mode), and dispatch e2e specialists **config-driven** in parallel — all Agent calls in the same message:
+**All other profiles**: spawn `cbp-testing-qa-agent` against the wave's `files[]` (or full builder output in single-wave mode), and dispatch e2e specialists **config-driven** in parallel — all Agent calls in the same message:
 
 1. **Short-circuit hints** (applied *before* reading `e2e.json`, emit no `e2e_eligible_skipped` signal): if `testing_profile === 'backend'` OR `round.context.round_type === 'survey'`, dispatch `cbp-testing-qa-agent` alone and skip e2e entirely. (The `claude_only` branch above already skips all agent spawns.)
 2. Read `.codebyplan/e2e.json`. If the file is absent or `frameworks` is missing/empty, no framework is eligible — skip e2e entirely (no `e2e_eligible_skipped` signal) and run `cbp-testing-qa-agent` alone.
@@ -165,78 +191,70 @@ On pass, synthesise `testing_qa_output` inline per the procedure in `reference/i
 4. For every eligible framework, spawn the matching `cbp-e2e-*` specialist (per the `context/testing/e2e.md` dispatch routing table) IN PARALLEL with `cbp-testing-qa-agent` and with each other. Inject `framework`, `app`, `platforms`, and `credential_vars` from `e2e.json` — the config is authoritative; agents do not auto-detect.
 5. `has_ui_work` and `testing_profile` are **hints only** beyond the short-circuit above — they never suppress an eligible framework. Pure `.claude/`-only and docs-only rounds match no configured `app` path and are therefore not eligible.
 
-This realises the opt-out contract in `rules/e2e-mandatory.md`: an eligible framework whose specialist does not run — without a recorded valid skip reason — is an `e2e_eligible_skipped` hard-fail at Step 6.
+This realises the opt-out contract in `rules/e2e-mandatory.md`. The deterministic `e2e_eligible_skipped` gate is owned by `/cbp-verify` Phase 3 (Tier-1 execution proof via `codebyplan e2e verify-round`); this skill records `e2e_eligible[]` / `e2e_outputs` so verify can evaluate it.
 
 Input contracts: `cbp-testing-qa-agent` receives `executor_output`, `testing_profile`, `has_ui_work` (see `agents/cbp-testing-qa-agent.md` Input Contract). The `cbp-e2e-*` specialist receives `repo_id`, `round_number`, `files_changed`, `prior_round_files_changed` (full task aggregate when round_number ≥ 2), `whole_checkpoint_mode: false`, `framework`, `app`, `platforms`, `credential_vars`, `test_strategy`, `pages_affected`, `has_auth`, `dev_server_port` (see `context/testing/e2e.md` Input Contract for the full shape). `test_strategy` is injected here in per-round mode; `/cbp-checkpoint-check` Step 5b omits it (the specialist self-resolves from `e2e.json` + DB in `whole_checkpoint_mode`).
 
-**Independence**: neither agent reads the other's output. Baseline-regression findings surface as a BLOCKING gate at `/cbp-round-end` Step 7 (an explicit accept-or-fix user decision; baselines are NEVER auto-accepted). Per-wave spawns MAY run in parallel with the next wave's executor when dependency order allows. The `cbp-e2e-*` specialists are parallel siblings of `cbp-testing-qa-agent` — they do not share state.
+**Independence**: neither agent reads the other's output. Baseline-regression findings surface as a BLOCKING gate at `/cbp-verify` (an explicit accept-or-fix user decision; baselines are NEVER auto-accepted). Per-wave spawns MAY run in parallel with the next wave's builder when dependency order allows. The `cbp-e2e-*` specialists are parallel siblings of `cbp-testing-qa-agent` — they do not share state.
 
 ### Step 5b: Post-E2E Screenshot Review (cbp-frontend-ui Phase 6.5)
 
-Aggregate screenshots across ALL specialists that ran: `screenshots = Object.values(round.context.e2e_outputs ?? {}).flatMap(o => o.screenshots ?? [])`. When the aggregated list is non-empty, invoke the `cbp-frontend-ui` skill with `phase: 'screenshot_review'` (input: `files_changed`, `e2e_screenshots: <aggregated screenshots>`, `context: { checkpoint_goal, round_requirements }`). Under this phase the skill runs only Phase 6.5 (Rendered-Output Visual Review) + 7 + 8 — Phases 1-6 (style) already ran inline at executor Step 3.8 with `phase: 'style_only'`.
+Aggregate screenshots across ALL specialists that ran: `screenshots = Object.values(round.context.e2e_outputs ?? {}).flatMap(o => o.screenshots ?? [])`. When the aggregated list is non-empty, invoke the `cbp-frontend-ui` skill with `phase: 'screenshot_review'` (input: `files_changed`, `e2e_screenshots: <aggregated screenshots>`, `context: { checkpoint_goal, round_requirements }`). Under this phase the skill runs only Phase 6.5 (Rendered-Output Visual Review) + 7 + 8 — Phases 1-6 (style) already ran inline at builder Step 3.8 with `phase: 'style_only'`.
 
-Persist findings to `round.context.frontend_ui_review` (merge with Step 3.8's style-only output if present). Baseline-regression findings surface as a BLOCKING gate at `/cbp-round-end` Step 7 (an explicit accept-or-fix user decision; baselines are NEVER auto-accepted); rendered_visual critical findings are surfaced in the Step 7 findings presentation. Neither auto-fails the round. cbp-testing-qa-agent does NOT read these findings (full independence per Step 5).
+Persist findings to `round.context.frontend_ui_review` (merge with Step 3.8's style-only output if present). Baseline-regression findings surface as a BLOCKING gate at `/cbp-verify` (an explicit accept-or-fix user decision; baselines are NEVER auto-accepted); rendered_visual critical findings are carried into verify. Neither auto-fails the round here. cbp-testing-qa-agent does NOT read these findings (full independence per Step 5).
 
 **Skip** when `round.context.e2e_outputs` is absent/empty, the aggregated `screenshots` list is empty, or `testing_profile === 'claude_only'`.
 
-### Step 6: Hard-Fail Routing
+### Step 6: In-Execution Hard-Fail Retry
 
-Per-wave hard-fail signal — true when ANY hold:
+During execution, the per-wave `cbp-testing-qa-agent` may report a hard fail it can fix in-loop. The
+final pass/fail verdict (deterministic gates, e2e proof, fresh-context review) belongs to `/cbp-verify`;
+this step only handles the cheap in-execution retry so a trivially-broken wave is fixed before verify.
+
+Per-wave in-execution hard-fail signal — true when ANY hold:
 
 - `testing_qa_output.totals.hard_fail === true`.
 - For any framework `f` in `round.context.e2e_outputs`: `e2e_outputs[f].status === 'failed'` OR `e2e_outputs[f].test_results?.failed > 0`.
-- **E2E deterministic gate** (replaces the former judgment-based `e2e_eligible_skipped` evaluation): when `round.context.e2e_eligible[]` is non-empty, first persist `e2e_eligible` / `e2e_outputs` to round context via MCP `update_round` (the Step 7 write, pulled forward — the CLI reads the round row from the DB), then run:
-
-  ```bash
-  codebyplan e2e verify-round --round-id <round_id> --task-id <task_id>
-  ```
-
-  Exit 0 = e2e pass. Exit 1 = one or more deterministic hard-fails — the stdout JSON's `failed_checks[]` identifies which (`e2e_eligible_skipped`, `zero_assertion_run`, `empty_gallery`); the `rules/e2e-mandatory.md` valid-skip list and the vscode-test empty-gallery exception are honored by the CLI. When `e2e_eligible[]` is empty, skip the CLI call — nothing to verify.
-
-**All waves hard_fail: false** → proceed to Step 7. **Any wave hard_fail: true**:
 
-- **Simple fixes** (type errors, lint, missing imports, test assertion fixes, e2e `real`-category with clear code-side root cause, no prior re-trigger this round) → save failure details to round context; retrigger the failing wave's executor; re-run testing-qa AND the eligible `cbp-e2e-*` specialists for that wave.
-- **Structural OR already re-triggered once OR e2e preflight aborts OR `e2e_eligible_skipped`** → save failure context via `codebyplan round update` (break-glass: MCP `update_round`); auto-trigger `/cbp-round-input`. STOP.
+**All waves clear** → proceed to Step 7. **Any wave hard_fail: true**:
 
-## Inline execution fallback
+- **Simple fixes** (type errors, lint, missing imports, test assertion fixes, e2e `real`-category with clear code-side root cause, no prior re-trigger this round) → save failure details to round context; retrigger the failing wave's builder; re-run testing-qa AND the eligible `cbp-e2e-*` specialists for that wave.
+- **Structural OR already re-triggered once OR e2e preflight aborts** → save failure context via `codebyplan round update` (break-glass: MCP `update_round`) and STILL proceed to Step 7 → Step 8 (`/cbp-verify`). Verify owns the authoritative verdict and the fix-round routing; it will route to `/cbp-round-plan` for a fix round. Do NOT self-route to a fix round here.
 
-When `cbp-round-executor` spawn fails (per `agent-spawn-failure-fallback.md` triggers), fall through to the 3-INLINE branch in Step 3 above for `.claude/`-only edits. For non-`.claude/` edits, walk `agents/cbp-round-executor.md` Phase 1–4 inline using Read / Edit / Write / Bash. Full procedure: `reference/inline-fallback.md` "Execution fallback" section.
-
-## Inline validation fallback
-
-When `cbp-testing-qa-agent` spawn fails OR the resolved `testing_profile` is `claude_only` (in which case the agent isn't spawned by design), run validation inline. Apply the profile gate matrix in `agents/cbp-testing-qa-agent.md` Phase 3 to determine in-scope checks. Full procedure + per-profile shape: `reference/inline-fallback.md` "Validation fallback" section.
-
-### Step 7: Save Executor Output
+### Step 7: Save Builder Output
 
 `codebyplan round update --id <round-id> --task-id <uuid> --checkpoint-id <uuid> --context <json>` (CLI write-through: local state at `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/<roundId>.json` + REST). Break-glass fallback: MCP `update_round` when the CLI is unavailable.
 
-- `context`: { ...existing, executor_output, testing_qa_output, e2e_eligible, e2e_outputs, frontend_ui_review } — when e2e ran, `e2e_eligible` / `e2e_outputs` were already persisted by the Step 6 pull-forward write; re-include them in this merge payload (the `update_round` REPLACE contract requires re-sending every field that should remain — this is a consolidating merge, not a second write of new data).
+- `context`: { ...existing, executor_output, testing_qa_output, e2e_eligible, e2e_outputs, frontend_ui_review } — the `update_round` REPLACE contract requires re-sending every field that should remain (a consolidating merge, not a partial write).
+
+`e2e_outputs` (a framework-keyed map of specialist outputs, e.g. `{ playwright: {...}, maestro: {...} }`) is present when ≥1 eligible framework ran. `frontend_ui_review` is present only when ≥1 eligible framework ran AND Step 5b ran (non-empty screenshots). `e2e_eligible[]` records which frameworks were eligible this round and drives `/cbp-verify` Phase 3's Tier-1 e2e gate.
 
-`e2e_outputs` (a framework-keyed map of specialist outputs, e.g. `{ playwright: {...}, maestro: {...} }`) is present when ≥1 eligible framework ran. `frontend_ui_review` is present only when ≥1 eligible framework ran AND Step 5b ran (non-empty screenshots). `e2e_eligible[]` records which frameworks were eligible this round and drives the Step 6 E2E deterministic gate.
+### Step 8: Auto-trigger Verify (scope=round)
 
-### Step 8: Auto-trigger Round End
+Execution complete. Hand the round to the unified verify stage — a SINGLE directive, never an A/B/C menu (`feedback-close-out-routing.md`). `/cbp-verify` runs the deterministic gates, real-execution proof, and the fresh-context `cbp-verify-reviewer`, then routes (fix round → `/cbp-round-plan`; clean last round → escalate to task scope; clean round → `/cbp-round-complete`).
 
 ```
-Execution and validation complete. Starting round wrap-up...
+Build complete. Starting verify...
 ```
 
-Trigger `/cbp-round-end`.
+Trigger `/cbp-verify` (scope=round).
 
 ## Key Rules
 
-- **Code + test writing + inline validation** — planning lives in `round-start`, summary in `round-end`
-- Per-wave `cbp-testing-qa-agent` AND the `cbp-e2e-*` specialist run in parallel (both against the same wave's `files[]`); they may also run in parallel with the NEXT wave's executor when dependency order allows
+- **Build only** — planning lives in `cbp-round-plan`; the pass/fail verdict + gates + proof + review live in `/cbp-verify`
+- Per-wave `cbp-testing-qa-agent` AND the `cbp-e2e-*` specialist run in parallel during execution (both against the same wave's `files[]`); they may also run in parallel with the NEXT wave's builder when dependency order allows
 - `testing_profile` from `task.context` governs which checks run — read it once in Step 2; pass to every testing-qa + e2e specialist spawn
-- `claude_only` profile skips all agent spawns (testing-qa AND `cbp-e2e-*`); runs hook syntax and skill structure checks inline
-- E2E dispatch is **config-driven and opt-out** (`.codebyplan/e2e.json`), not gated on `has_ui_work`/`testing_profile` — an eligible framework that silently does not run is an `e2e_eligible_skipped` hard-fail (`rules/e2e-mandatory.md`)
+- `claude_only` profile is the deterministic-only path (no testing-qa AND no `cbp-e2e-*` spawn by design); runs hook syntax and skill structure checks inline — NOT an inline fallback
+- E2E dispatch is **config-driven and opt-out** (`.codebyplan/e2e.json`), not gated on `has_ui_work`/`testing_profile`; the `e2e_eligible_skipped` deterministic gate is enforced by `/cbp-verify` Phase 3
 - Step 5b (cbp-frontend-ui Phase 6.5) runs only when e2e produced screenshots — gated on the aggregated `e2e_outputs[*].screenshots[]` being non-empty
+- Builder / testing-qa spawn failure is a HARD GATE FAILURE — STOP + retry directive, NEVER self-certify the build inline (`rules/spawn-failure-is-gate-failure.md`)
 - Claude NEVER git adds files in round commands
 
 ## Integration
 
 - **Reads**: `.codebyplan/state/checkpoints/<id>/tasks/<id>.json`, `checkpoints/<id>/tasks/<id>/rounds/<id>.json` (local-first; `npx codebyplan sync` on miss; MCP `get_current_task` / `get_rounds` as break-glass)
-- **Writes**: `codebyplan round update --id <uuid> --task-id <uuid> --checkpoint-id <uuid>` (Steps 6+7 — context with executor_output + testing_qa_output + e2e_eligible + e2e_outputs + frontend_ui_review; break-glass: MCP `update_round`)
-- **Spawns**: `cbp-round-executor` (per wave or single), `cbp-testing-qa-agent` (per wave, parallel sibling of the `cbp-e2e-*` specialists), the `cbp-e2e-*` specialists (config-driven dispatch per `context/testing/e2e.md`, one per eligible framework in `.codebyplan/e2e.json`), `cbp-database-agent` (if DB work), `cbp-stripe-agent` (if Stripe work), `cbp-security-agent` (if security review needed)
+- **Writes**: `codebyplan round update --id <uuid> --task-id <uuid> --checkpoint-id <uuid>` (Step 7 — context with executor_output + testing_qa_output + e2e_eligible + e2e_outputs + frontend_ui_review; break-glass: MCP `update_round`)
+- **Spawns**: `cbp-round-builder` (per wave or single; spawn failure = hard gate failure → STOP), `cbp-testing-qa-agent` (per wave, parallel sibling of the `cbp-e2e-*` specialists), the `cbp-e2e-*` specialists (config-driven dispatch per `context/testing/e2e.md`, one per eligible framework in `.codebyplan/e2e.json`), `cbp-database-agent` (if DB work), `cbp-stripe-agent` (if Stripe work), `cbp-security-agent` (if security review needed)
 - **Skill invocations**: `cbp-frontend-ui` at Step 5b with `phase: 'screenshot_review'` (post-e2e)
-- **Triggers**: `/cbp-round-end` (auto)
-- **Triggered by**: `/cbp-round-start` (auto, after plan approval)
+- **Triggers**: `/cbp-verify` (auto, scope=round)
+- **Triggered by**: `/cbp-round-plan` (auto, after plan approval)

package/templates/skills/cbp-round-complete/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: cbp-round-complete
-description: Reconcile user git-add approvals, complete the round, and route to the next step
+description: Reconcile user git-add approvals and complete the round (the ask-tier human git-add finalizer)
 argument-hint: [chk-task-round | task-round]
 disable-model-invocation: true
-triggers: [cbp-task-check, cbp-standalone-task-check, cbp-round-input]
+triggers: [cbp-round-plan]
 effort: low
 ---
 
@@ -28,7 +28,7 @@ Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
 
 # Round Complete Command
 
-The **user-invoked finalizer** for a round that `/cbp-round-update` triaged as clean. round-complete carries `disable-model-invocation: true`, so the model cannot invoke it — `/cbp-round-update` *directs* the user here with a `Next: /cbp-round-complete` directive, and the user runs it. It reconciles which files the **user** approved via `git add`, completes the round, and routes to the next step.
+The **user-invoked git-add finalizer** for a round that `/cbp-verify` (scope=round) passed clean. round-complete carries `disable-model-invocation: true`, so the model cannot invoke it — `/cbp-verify` Phase 6 *directs* the user here with a `Next: /cbp-round-complete` directive, and the user runs it. The verify gates, execution proof, and fresh-context review already passed (`/cbp-verify` owns them); this skill's sole job is to reconcile which files the **user** approved via `git add` and complete the round. It does NOT re-run any gate.
 
 This skill is gated by an `ask`-tier `Skill(cbp-round-complete)` permission rule in `settings.json`. **The permission prompt IS the user confirmation** on the user's direct invoke — there is NO AskUserQuestion inside this skill. If the user declines the permission, the skill does not run: nothing is synced, no round is completed, and the user can stage files and re-invoke `/cbp-round-complete` when ready.
 
@@ -44,7 +44,7 @@ If this is false: DO NOT proceed to Step 3.
 
 ### Step 1: Parse `$ARGUMENTS`
 
-Parse the argument using the canonical chk-task-round notation (see `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
+Parse the argument using the canonical chk-task-round notation (see `cbp-round-plan` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
 
 | Shape | Regex | Resolves to |
 |-------|-------|-------------|
@@ -126,14 +126,14 @@ Calculate duration from the round's `started_at` to now in minutes.
 
 **4a — Count files** — Display: `"Round N complete — Files: X total, Y approved, Z pending"`.
 
-**4b — Route on `unapproved_count`** (from Step 3's `complete_round` response):
+**4b — Route on `unapproved_count`** (from Step 3's `complete_round` response). `/cbp-verify` already
+passed this round clean (gates + proof + review) and routed here; this step only acts on the user's
+git-add signal:
 
-- **`unapproved_count === 0`** (every file user-approved): the user has signed off on the whole round.
-  - checkpoint KIND → auto-trigger `/cbp-task-check`.
-  - standalone KIND → auto-trigger `/cbp-standalone-task-check`.
-- **`unapproved_count > 0`** (user withheld approval on some files): the unstaged files are the signal that more work is wanted on them. Auto-trigger `/cbp-round-input` — its Step 2 deep analysis reads exactly those `user_approved === false` files and formulates the next round's requirements. This route is **independent of how many files are staged**; round-input is reachable even when zero files were staged.
+- **`unapproved_count === 0`** (every file user-approved): the user has signed off on the whole round. The task may now be complete. Surface the single directive `Next: /cbp-verify` so verify re-enters at task scope (its Phase 1 escalation) to run the whole-repo gate, the holistic reviewer, and the one batched human walkthrough, then route to `/cbp-finalize`. (Verify already escalated automatically on the last clean round before routing here; this directive is the manual entry when the user finishes staging out of band.)
+- **`unapproved_count > 0`** (user withheld approval on some files): the unstaged files are the signal that more work is wanted on them. Auto-trigger `/cbp-round-plan` — its Step 3D deep analysis reads exactly those `user_approved === false` files and formulates the next round's requirements. This route is **independent of how many files are staged**; round-plan is reachable even when zero files were staged.
 
-  - **Degenerate auto-loop guard**: if the just-completed round had `round.context.auto_loop_mode === true` AND it was a clean exit (no `improve_round_findings[]`, no hard-fail — which is why `/cbp-round-update` triaged it to round-complete in the first place), do NOT auto-trigger `/cbp-round-input`. Its auto-loop path transcribes the prior round's findings verbatim, and a clean round has none — auto-triggering would spin on an empty input. Instead surface the clean-exit note below and STOP; the user stages the pending files and re-invokes (or runs `/cbp-round-input` manually). Persist `round.context.round_complete.degenerate_auto_loop_exit = true`.
+  - **Degenerate auto-loop guard**: if the just-completed round had `round.context.auto_loop_mode === true` AND it was a clean exit (no blocking verify findings, no hard-fail — which is why `/cbp-verify` routed it to round-complete in the first place), do NOT auto-trigger `/cbp-round-plan`. Its auto-loop path transcribes the prior round's findings verbatim, and a clean round has none — auto-triggering would spin on an empty input. Instead surface the clean-exit note below and STOP; the user stages the pending files and re-invokes (or runs `/cbp-round-plan` manually). Persist `round.context.round_complete.degenerate_auto_loop_exit = true`.
 
     ```
     ## Round N Complete — Auto-loop finished clean
@@ -141,7 +141,7 @@ Calculate duration from the round's `started_at` to now in minutes.
     **Files**: X total, Y approved, Z pending
 
     Pending files passed all checks; they are just not staged. Stage them
-    (`git add <path>`) to finish the task, or run /cbp-round-input to start
+    (`git add <path>`) to finish the task, or run /cbp-round-plan to start
     another round.
     ```
 
@@ -153,7 +153,7 @@ Payload: `round.context.round_complete = { staged_count, unstaged_count, route,
 
 ## Key Rules
 
-- **User-invoked only** — round-complete carries `disable-model-invocation: true`, so the model cannot invoke it. `/cbp-round-update` *directs* the user here on a clean triage (a `Next: /cbp-round-complete` directive); the user runs the skill.
+- **User-invoked only** — round-complete carries `disable-model-invocation: true`, so the model cannot invoke it. `/cbp-verify` (scope=round, Phase 6) *directs* the user here on a clean round (a `Next: /cbp-round-complete` directive); the user runs the skill.
 - **Permission prompt = confirmation** — gated by `ask`-tier `Skill(cbp-round-complete)`. Because the skill is `disable-model-invocation: true`, this gate applies to the user's **direct** `/cbp-round-complete` invocation. NEVER add an AskUserQuestion to confirm running; the harness prompt is the gate. A declined permission is a clean no-op.
 - **Step 2 (CLI) must exit 0** — if it fails, STOP before `complete_round`. The merge semantics are enforced by the CLI.
 - **NEVER ask the user to git add files** — Step 2 only reads staging status. **NEVER stage files** — Claude does not touch the git staging area; the user's `git add` is the approval signal.
@@ -162,9 +162,10 @@ Payload: `round.context.round_complete = { staged_count, unstaged_count, route,
 ## Integration
 
 - **Gates**: `ask`-tier `Skill(cbp-round-complete)` permission prompt on the user's direct invoke — the harness confirms before the skill runs; a decline makes NO writes. There is no in-skill AskUserQuestion.
-- **Invoked by**: the user only — round-complete carries `disable-model-invocation: true`, so the model cannot invoke it. `/cbp-round-update` *directs* the user here on a clean triage (a `Next: /cbp-round-complete` directive) but does not invoke it.
+- **Invoked by**: the user only — round-complete carries `disable-model-invocation: true`, so the model cannot invoke it. `/cbp-verify` (scope=round, Phase 6) *directs* the user here on a clean round (a `Next: /cbp-round-complete` directive) but does not invoke it.
 - **Reads (checkpoint KIND)**: `.codebyplan/state/checkpoints/<id>.json`, `.codebyplan/state/checkpoints/<id>/tasks/<id>.json`, `.codebyplan/state/checkpoints/<id>/tasks/<id>/rounds/<id>.json` (local-first; run `npx codebyplan sync` if missing; break-glass: MCP `get_current_task` / `get_rounds`). Delegates git+approval sync to `npx codebyplan round sync-approvals`.
 - **Reads (standalone KIND)**: MCP `get_current_standalone_task` / `get_standalone_rounds` (standalone KIND still uses MCP until a later task).
 - **Writes (checkpoint KIND)**: `codebyplan round complete` (Step 3); `codebyplan round update` (Step 4 breadcrumb). Break-glass: MCP `complete_round` / `update_round`. Round+task `files_changed` written by the CLI sync-approvals.
 - **Writes (standalone KIND)**: MCP `complete_standalone_round` / `update_standalone_round` (standalone KIND still uses MCP until a later task).
-- **Triggers**: `/cbp-task-check` (checkpoint KIND, all files approved), `/cbp-standalone-task-check` (standalone KIND, all files approved), `/cbp-round-input` (some files unapproved — fires independent of staging count)
+- **Triggered by**: `/cbp-verify` (scope=round, Phase 6 — directs the user here on a clean round; does not invoke)
+- **Triggers**: `/cbp-verify` (all files approved — re-enters at task scope for the whole-repo gate + finalize), `/cbp-round-plan` (some files unapproved — its Step 3D deep analysis; fires independent of staging count)