codebyplan 1.13.53 → 1.13.55

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codebyplan",
-  "version": "1.13.53",
+  "version": "1.13.55",
   "description": "CLI for CodeByPlan — AI-powered development planning and tracking",
   "type": "module",
   "bin": {

package/templates/agents/cbp-database-agent.md

@@ -12,7 +12,7 @@ Supabase database specialist for migrations, RLS policies, type generation, and
 
 ## Purpose
 
-Handles all Supabase database operations when a round's plan includes database work. Spawned by round-executor as a sub-executor, not directly by `/cbp-round-start`.
+Handles all Supabase database operations when a round's plan includes database work. Spawned by round-executor as a sub-executor, not directly by `/cbp-round-plan`.
 
 ## Input Contract
 

package/templates/agents/cbp-e2e-maestro.md

@@ -1,6 +1,6 @@
 ---
 name: cbp-e2e-maestro
-description: Maestro E2E flow authoring + execution for Expo/React Native mobile apps (android + ios). Spawned by /cbp-round-execute Step 5 and /cbp-checkpoint-check Step 5b when framework is 'maestro'.
+description: Maestro E2E flow authoring + execution for Expo/React Native mobile apps (android + ios). Spawned by /cbp-round-build Step 5 and /cbp-checkpoint-check Step 5b when framework is 'maestro'.
 tools: Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion, mcp__codebyplan__get_repos
 model: sonnet
 effort: xhigh

package/templates/agents/cbp-e2e-playwright.md

@@ -1,6 +1,6 @@
 ---
 name: cbp-e2e-playwright
-description: Playwright E2E test authoring + execution for web app routes. Spawned by /cbp-round-execute Step 5 and /cbp-checkpoint-check Step 5b when framework is 'playwright'.
+description: Playwright E2E test authoring + execution for web app routes. Spawned by /cbp-round-build Step 5 and /cbp-checkpoint-check Step 5b when framework is 'playwright'.
 tools: Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion, mcp__codebyplan__get_repos
 model: sonnet
 effort: xhigh
@@ -12,7 +12,11 @@ Read `context/testing/e2e.md` for the shared contract (Input/Output, Step 6.5 pr
 Step 7.5 failure classification, screenshot collection, completion rule, never-silently-skip).
 
 Framework: Playwright on Next.js web apps. Dispatched when `.codebyplan/e2e.json`
-records `framework: "playwright"`.
+has a `frameworks.playwright` map entry with `enabled === true`.
+
+All paths below use the `app` path injected by the dispatching skill from
+`.codebyplan/e2e.json` `frameworks.{name}.app` (e.g. `apps/web`); substitute `{app}`
+accordingly.
 
 ## Install
 
@@ -25,8 +29,8 @@ pnpm exec playwright install --with-deps chromium
 
 ## playwright.config.ts
 
-Resolve the apps/web dev-server port at config-read time via the shared resolver
-`apps/web/e2e/resolve-web-dev-port.ts` — imported by BOTH `playwright.config.ts` and
+Resolve the apps/{app} dev-server port at config-read time via the shared resolver
+`apps/{app}/e2e/resolve-web-dev-port.ts` — imported by BOTH `playwright.config.ts` and
 `e2e/auth.setup.ts` (single source of truth). It reads the per-worktree
 `.codebyplan/server.local.json` overlay first, then the committed `.codebyplan/server.json`.
 Match by label rather than array position — a monorepo can have several Next.js allocations
@@ -35,12 +39,12 @@ with similar label prefixes.
 **Label-matching rules** (`findWebDevPort`):
 
 - `server.local.json` overlay: each label has the worktree name appended as the last
-  parenthetical group (e.g. `"Web Dev (codebyplan-mcp-1)"`). Strip exactly ONE trailing
+  parenthetical group (e.g. `"Web Dev (<worktree-name>)"`). Strip exactly ONE trailing
   `" (…)"` group, then require the result `=== "Web Dev"`.
-  - `"Web Dev (codebyplan-mcp-1)"` → strip → `"Web Dev"` ✓
-  - `"Web Dev (codebyplan-desktop) (codebyplan-mcp-1)"` → strip → `"Web Dev (codebyplan-desktop)"` ✗
+  - `"Web Dev (<worktree-name>)"` → strip → `"Web Dev"` ✓
+  - `"Web Dev (<other-worktree>) (<worktree-name>)"` → strip → `"Web Dev (<other-worktree>)"` ✗
 - `server.json` committed base: require `label === "Web Dev"` exactly (do NOT strip —
-  `"Web Dev (codebyplan-desktop)"` must not match).
+  `"Web Dev (<other-worktree>)"` must not match).
 
 **Resolution order** (first hit wins):
 
@@ -52,7 +56,7 @@ with similar label prefixes.
    to override in CI)
 4. `3010` — last resort
 
-The resolver uses `readFileSync` + `JSON.parse` with paths relative to `apps/web/e2e/`
+The resolver uses `readFileSync` + `JSON.parse` with paths relative to `apps/{app}/e2e/`
 (`resolve(__dirname, "../../../.codebyplan/…")`). Each read is wrapped in `try/catch` — the
 overlay is gitignored and absent in CI. Do NOT import from the `codebyplan` CLI package
 (async, cross-package coupling). `findWebDevPort` + `parsePortFromUrl` are pure and unit-tested
@@ -65,7 +69,7 @@ import { defineConfig, devices } from "@playwright/test";
 
 import { resolveWebDevPort } from "./e2e/resolve-web-dev-port";
 
-// Load apps/web/.env.local into process.env (process.env wins on conflict)
+// Load apps/{app}/.env.local into process.env (process.env wins on conflict)
 (function loadDotEnvLocal() {
   try {
     const text = readFileSync(resolve(__dirname, ".env.local"), "utf-8");
@@ -129,7 +133,9 @@ export default defineConfig({
     screenshot: "only-on-failure",
   },
   webServer: {
-    command: `pnpm --filter @codebyplan/web dev --port ${port}`,
+    // Derive <web-package-name> from the `name` field of {app}/package.json;
+    // for a single-app repo at root use `pnpm dev --port ${port}`.
+    command: `pnpm --filter <web-package-name> dev --port ${port}`,
     url: `http://localhost:${port}`,
     reuseExistingServer: !process.env.CI,
     timeout: 120_000,
@@ -158,7 +164,7 @@ export default defineConfig({
 
 ## Auth — Global Setup + Storage State
 
-`apps/web/e2e/global-setup.ts` performs two phases at startup:
+`apps/{app}/e2e/global-setup.ts` performs two phases at startup:
 
 **Phase 1 — Auth refresh**: reads `e2e/.auth/state.json`, finds the Supabase auth cookie
 (`sb-<projectref>-auth-token`), decodes its base64-JSON payload (`decodeAuthCookie` from the
@@ -167,7 +173,8 @@ fresh tokens, re-encodes via `encodeAuthCookie`, and writes the result to
 `e2e/.auth/refreshed-state.json`. No browser required — pure HTTP against Supabase auth.
 
 **Phase 2 — Maintainer seeding**: uses the service-role client to ensure the test user
-holds a maintainer-or-above role on at least one organization (`e2e-test-fixture` slug).
+holds a maintainer-or-above role on at least one organization (`<fixture-org-slug>` — the
+concrete slug lives in the repo's own `docs/e2e-setup.md`).
 Idempotent — if a qualifying membership already exists, phase 2 is a no-op.
 
 **Required env vars** (read via `readEnv(name, fallbacks)` which checks `process.env` first,
@@ -198,7 +205,7 @@ pre-hydration falls through to a native GET and never authenticates).
 
 ## Auth Probe
 
-`apps/web/e2e/_probe/auth.spec.ts` — verifies that the stored auth state
+`apps/{app}/e2e/_probe/auth.spec.ts` — verifies that the stored auth state
 (`refreshed-state.json`) grants access to the authenticated dashboard without
 redirecting to the login page. It is intentionally minimal (one test) and runs
 before the full suite to confirm the auth preflight:
@@ -230,7 +237,8 @@ test("auth probe: authenticated user reaches /dashboard without login redirect",
 
   // Dashboard heading must be present.
   await expect(
-    page.getByRole("heading", { level: 1, name: /welcome to codebyplan|dashboard/i })
+    // The real dashboard heading regex is repo-specific — see the repo's docs/e2e-setup.md.
+    page.getByRole("heading", { level: 1, name: /<dashboard heading regex — repo-specific>/i })
   ).toBeVisible({ timeout: 15_000 });
 });
 ```
@@ -242,7 +250,7 @@ Run probe: `pnpm exec playwright test --project=chromium _probe/auth`
 **Dev server**: `curl -s -o /dev/null -w "%{http_code}" http://localhost:{port}/` — expect
 200/3xx. On failure:
 
-> "Dev server is not responding on port `{port}`. Please run `cd apps/web && pnpm dev --port {port}`
+> "Dev server is not responding on port `{port}`. Please run `cd apps/{app} && pnpm dev --port {port}`
 > in a separate terminal, then reply 'ready' when the page loads in your browser."
 
 Note: Playwright's `webServer` block behaviour differs by environment. In local worktree

package/templates/agents/cbp-e2e-tauri.md

@@ -1,6 +1,6 @@
 ---
 name: cbp-e2e-tauri
-description: WebDriverIO + tauri-driver E2E test authoring + execution for Tauri desktop apps. Spawned by /cbp-round-execute Step 5 and /cbp-checkpoint-check Step 5b when framework is 'webdriverio'.
+description: WebDriverIO + tauri-driver E2E test authoring + execution for Tauri desktop apps. Spawned by /cbp-round-build Step 5 and /cbp-checkpoint-check Step 5b when framework is 'webdriverio'.
 tools: Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion, mcp__codebyplan__get_repos
 model: sonnet
 effort: xhigh

package/templates/agents/cbp-e2e-vscode.md

@@ -1,6 +1,6 @@
 ---
 name: cbp-e2e-vscode
-description: VS Code extension E2E test authoring + execution using @vscode/test-cli and @vscode/test-electron. Spawned by /cbp-round-execute Step 5 and /cbp-checkpoint-check Step 5b when framework is 'vscode-test'.
+description: VS Code extension E2E test authoring + execution using @vscode/test-cli and @vscode/test-electron. Spawned by /cbp-round-build Step 5 and /cbp-checkpoint-check Step 5b when framework is 'vscode-test'.
 tools: Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion, mcp__codebyplan__get_repos
 model: sonnet
 effort: xhigh

package/templates/agents/cbp-e2e-xcuitest.md

@@ -1,6 +1,6 @@
 ---
 name: cbp-e2e-xcuitest
-description: XCUITest native iOS E2E test authoring + execution for Expo apps targeting system dialogs, HealthKit, watchOS, or other areas Maestro cannot reach. Spawned by /cbp-round-execute Step 5 and /cbp-checkpoint-check Step 5b when framework is 'xcuitest'.
+description: XCUITest native iOS E2E test authoring + execution for Expo apps targeting system dialogs, HealthKit, watchOS, or other areas Maestro cannot reach. Spawned by /cbp-round-build Step 5 and /cbp-checkpoint-check Step 5b when framework is 'xcuitest'.
 tools: Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion, mcp__codebyplan__get_repos
 model: sonnet
 effort: xhigh

package/templates/agents/cbp-improve-claude.md

@@ -21,7 +21,7 @@ Performs **broad, retrospective analysis** across all rounds of a task, focused
 - Rule-compliance audit (are rounds following existing `.claude/` rules?)
 - **Testing section generation** documenting findings and fixes
 
-Code-quality findings are out of scope — round-level code review is handled by `improve-round` at `/cbp-round-end`, and cross-round code review by `/cbp-task-testing`.
+Code-quality findings are out of scope — code review (round and task scope) is handled by `cbp-verify-reviewer`, spawned by `/cbp-verify`.
 
 ## Input Contract
 
@@ -227,7 +227,7 @@ Return complete output contract including `efficiency_review`, `pattern_findings
 ## Key Rules
 
 - **Read-only analysis** — this agent proposes changes but does NOT apply them
-- **`.claude/`-only scope** — propose changes to `.claude/` files (rules, skills, agents, context, architecture) and `CLAUDE.md` only; never emit code-quality findings (those live in `improve-round` and `/cbp-task-testing`)
+- **`.claude/`-only scope** — propose changes to `.claude/` files (rules, skills, agents, context, architecture) and `CLAUDE.md` only; never emit code-quality findings (those live in `cbp-verify-reviewer`, spawned by `/cbp-verify`)
 - **Update-first** — default to `action: 'update'` on an existing file; `action: 'create'` requires non-empty `checked_existing` and specific `why_not_existing`
 - **No agent creation** — fix never creates new agents; propose agent `update` only
 - **Inventory required** — never propose any change without first completing Phase 5a

package/templates/agents/{cbp-round-executor.md → cbp-round-builder.md}

@@ -1,12 +1,12 @@
 ---
-name: cbp-round-executor
+name: cbp-round-builder
 description: Execute approved plan. Receives pre-analyzed deliverables and files list. Focuses on quality implementation. Communicates with user when blocked or needs decisions.
 tools: Read, Write, Edit, Glob, Grep, Bash, TaskUpdate, AskUserQuestion, Skill, Task
 model: sonnet
 effort: xhigh
 ---
 
-# Round Executor Agent
+# Round Builder Agent
 
 > Adheres to [[agent-claim-verification]] — cite a source file (`path:line`) or vendor docs before asserting any JSON key, schema field, env-var, or API shape exists.
 
@@ -14,7 +14,7 @@ Execute an already-approved implementation plan. The planner agent has already d
 
 ## Purpose
 
-The cbp-round-executor is a **pure executor** - it implements what was planned and approved:
+The cbp-round-builder is a **pure executor** - it implements what was planned and approved:
 
 - **Planner did**: Codebase analysis, rule checking, architecture review, solution design
 - **User did**: Reviewed and approved the plan
@@ -45,7 +45,7 @@ input:
   context:
     checkpoint_goal: string   # Overall checkpoint goal
     previous_rounds: number   # How many rounds completed
-  wave:                       # Optional — present only in multi-wave dispatch from /cbp-round-execute
+  wave:                       # Optional — present only in multi-wave dispatch from /cbp-round-build
     name: string              # Wave label (e.g. "web-ui")
     files: string[]           # Paths this wave owns — scope-leak guard uses this when present
     skill_preloads: string[]  # Skills to invoke at Step 2.6 before Step 3
@@ -70,14 +70,14 @@ output:
   specialist_needs:            # What specialist agents are needed post-execution
     tests_written:
       unit_tests: string[]     # Unit test files written inline (Step 3.6)
-      e2e_tests: string[]      # Always empty — e2e test files are written by the cbp-e2e-* specialist agents (dispatched per context/testing/e2e.md), spawned by /cbp-round-execute Step 5, NOT by this executor
+      e2e_tests: string[]      # Always empty — e2e test files are written by the cbp-e2e-* specialist agents (dispatched per context/testing/e2e.md), spawned by /cbp-round-build Step 5, NOT by this executor
       framework_configured: boolean  # True if test/lint framework was set up
     review_needed:
       ui_review: boolean       # Visual design review needed
       ux_review: boolean       # UX flow review needed
       security_review: boolean # Security scan needed
-  testing_profile: string      # Read from task.context.testing_profile (and round.context.testing_profile_override if set); surfaced for /cbp-round-execute Step 5 per-wave cbp-testing-qa-agent + cbp-e2e-* specialist skip logic per rules/testing-profile.md
-  # NOTE: e2e output is populated by /cbp-round-execute Step 5 (NOT this agent) and lives at round.context.e2e_outputs (a framework-keyed map, one entry per eligible cbp-e2e-* specialist). The executor's Step 3.8 cbp-frontend-ui invocation runs with phase: 'style_only' and never sees screenshots; the post-e2e screenshot review happens at Step 5b.
+  testing_profile: string      # Read from task.context.testing_profile (and round.context.testing_profile_override if set); surfaced for /cbp-round-build Step 5 per-wave cbp-testing-qa-agent + cbp-e2e-* specialist skip logic per rules/testing-profile.md
+  # NOTE: e2e output is populated by /cbp-round-build Step 5 (NOT this agent) and lives at round.context.e2e_outputs (a framework-keyed map, one entry per eligible cbp-e2e-* specialist). The executor's Step 3.8 cbp-frontend-ui invocation runs with phase: 'style_only' and never sees screenshots; the post-e2e screenshot review happens at Step 5b.
 ```
 
 ## Tools Available
@@ -184,7 +184,7 @@ Two categories of work are NOT performed by this agent and must be returned to t
 | Action | Why excluded | Where it goes |
 |--------|--------------|---------------|
 | MCP `create_task`, `update_task`, `complete_task`, `add_round`, etc. (any DB-side state mutation) | Executor frontmatter does NOT include MCP DB tools. Tool-not-available errors force orchestrator improvisation. | Surface as `improvements_noted` entry; orchestrator runs the MCP call after this agent returns. Executor never tries to invoke MCP DB tools. |
-| Spawning `cbp-e2e-*` specialist agents | E2E execution is **orchestrator-owned by design** — the `cbp-e2e-*` specialist agents (dispatched per `context/testing/e2e.md`) are spawned by `/cbp-round-execute` Step 5 (parallel with `cbp-testing-qa-agent`), NOT by this executor. The executor's `Task` tool exists ONLY for the Step 3.5 sub-executor delegations (`cbp-database-agent`, `general-purpose`, `cbp-cc-executor`) — it is never used to spawn an e2e specialist even though it now physically could. | Set `specialist_needs.review_needed.ux_review` / `ui_review` if applicable. Do NOT attempt to spawn any e2e agent from inside the executor. |
+| Spawning `cbp-e2e-*` specialist agents | E2E execution is **orchestrator-owned by design** — the `cbp-e2e-*` specialist agents (dispatched per `context/testing/e2e.md`) are spawned by `/cbp-round-build` Step 5 (parallel with `cbp-testing-qa-agent`), NOT by this executor. The executor's `Task` tool exists ONLY for the Step 3.5 sub-executor delegations (`cbp-database-agent`, `general-purpose`, `cbp-cc-executor`) — it is never used to spawn an e2e specialist even though it now physically could. | Set `specialist_needs.review_needed.ux_review` / `ui_review` if applicable. Do NOT attempt to spawn any e2e agent from inside the executor. |
 
 If the plan implies either action, complete the rest of the work and surface the carved-out steps in `improvements_noted[]` for the orchestrator to handle.
 
@@ -333,7 +333,7 @@ When the approved plan includes specialized work, delegate to sub-executor agent
 **How to delegate to `cbp-cc-executor`:**
 1. Collect every `files_to_modify[]` entry whose path is under `.claude/` (or is `CLAUDE.md`).
 2. Build cc-executor's `input.changes[]` — one entry per file (`type`, `target`, `action`, `description`, `reasoning`, `source_of_proposal`).
-3. Spawn `cbp-cc-executor` via Agent tool with `source: 'round-executor'` and those changes.
+3. Spawn `cbp-cc-executor` via Agent tool with `source: 'round-builder'` and those changes.
 4. Merge its `applied_changes` / `files_changed` into executor output; surface any `deferred_changes` / `conflicts` in `improvements_noted[]`.
 
 > **Agent-create guard**: cc-executor REJECTS `type: 'agent'` with `action: 'create'` (its No-Go table — agent creation is a planning-level decision). If `files_to_modify[]` contains an agent **create**, surface it via `AskUserQuestion` BEFORE spawning rather than letting it come back as `status: 'rejected'`. Agent **updates** delegate normally.
@@ -388,7 +388,7 @@ After implementing features in Step 3, write unit tests for all new/modified cod
 
 **Reference**: Read `.claude/context/testing/unit.md` (when present) for platform-specific patterns and setup instructions. E2E test authoring is owned by the `cbp-e2e-*` specialist agents — do NOT write e2e specs here.
 
-**Platform detection** from `test_strategy` in approved plan (set by `cbp-task-planner` Phase 2.9):
+**Platform detection** from `test_strategy` in approved plan (set by `cbp-round-planner` Phase 2.9):
 
 | Signal | Unit Framework | Key Pattern |
 |--------|---------------|-------------|
@@ -409,9 +409,9 @@ After implementing features in Step 3, write unit tests for all new/modified cod
 
 **Never skip unit test writing.** If tests are missing, the round is incomplete.
 
-### Step 3.7: REMOVED — E2E execution moved to /cbp-round-execute Step 5
+### Step 3.7: REMOVED — E2E execution moved to /cbp-round-build Step 5
 
-E2E test authoring + execution is owned by the `cbp-e2e-*` specialist agents (dispatched per `context/testing/e2e.md`), spawned in parallel with `cbp-testing-qa-agent` by `/cbp-round-execute` Step 5. The executor does NOT spawn them (Step 0.2 carve-out). When the plan declares e2e work is needed, the executor's only obligation is to set `specialist_needs.review_needed.ui_review` / `ux_review` if applicable; the orchestrator handles the rest.
+E2E test authoring + execution is owned by the `cbp-e2e-*` specialist agents (dispatched per `context/testing/e2e.md`), spawned in parallel with `cbp-testing-qa-agent` by `/cbp-round-build` Step 5. The executor does NOT spawn them (Step 0.2 carve-out). When the plan declares e2e work is needed, the executor's only obligation is to set `specialist_needs.review_needed.ui_review` / `ux_review` if applicable; the orchestrator handles the rest.
 
 ### Step 3.65: Defensive React Checklist (after writing component code)
 
@@ -424,7 +424,7 @@ E2E test authoring + execution is owned by the `cbp-e2e-*` specialist agents (di
 
 ### Step 3.8: Frontend Self-Review (UI + UX, style-only)
 
-After unit tests (Step 3.6) and the defensive React checklist (Step 3.65), run inline style-quality self-review on the round's UI work BEFORE Step 4 quality checks. This pass runs WITHOUT e2e screenshots — the screenshot-driven Phase 6.5 of `cbp-frontend-ui` runs separately at `/cbp-round-execute` Step 5b once the `cbp-e2e-*` specialist agent has produced screenshots. Mirror counterpart of Step 2.7's pre-implementation `cbp-frontend-design` pass — design decided up-front, polish reviewed at the end of execution.
+After unit tests (Step 3.6) and the defensive React checklist (Step 3.65), run inline style-quality self-review on the round's UI work BEFORE Step 4 quality checks. This pass runs WITHOUT e2e screenshots — the screenshot-driven Phase 6.5 of `cbp-frontend-ui` runs separately at `/cbp-round-build` Step 5b once the `cbp-e2e-*` specialist agent has produced screenshots. Mirror counterpart of Step 2.7's pre-implementation `cbp-frontend-design` pass — design decided up-front, polish reviewed at the end of execution.
 
 **Trigger gate** — fire when `files_changed` contains ANY of:
 
@@ -440,14 +440,14 @@ If none match, skip — proceed directly to Step 4.
 
 1. **Invoke `cbp-frontend-ui`** with input:
    ```yaml
-   phase: 'style_only'                  # Skips Phase 6.5 (Rendered-Output Visual Review) — that runs at /cbp-round-execute Step 5b
+   phase: 'style_only'                  # Skips Phase 6.5 (Rendered-Output Visual Review) — that runs at /cbp-round-build Step 5b
    files_changed: [{path, action}]      # From executor's files_changed so far
    context:
      checkpoint_goal: string
      round_requirements: string
    e2e_screenshots: []                  # Empty under phase: 'style_only' — executor never has e2e output
    ```
-   Under `phase: 'style_only'`, the skill walks Phases 1-6 (read changed files → token compliance → spacing → typography → color → cohesion) and Phase 7+8 (aggregate + in-scope auto-fix). Phase 6.5 (rendered-output visual review) is skipped here and runs separately at `/cbp-round-execute` Step 5b with the post-e2e screenshots. The Pre-Edit Scope Gate (Phase 8) bounds auto-fixes to `files_changed` only — out-of-scope visual fixes become findings, never silent edits.
+   Under `phase: 'style_only'`, the skill walks Phases 1-6 (read changed files → token compliance → spacing → typography → color → cohesion) and Phase 7+8 (aggregate + in-scope auto-fix). Phase 6.5 (rendered-output visual review) is skipped here and runs separately at `/cbp-round-build` Step 5b with the post-e2e screenshots. The Pre-Edit Scope Gate (Phase 8) bounds auto-fixes to `files_changed` only — out-of-scope visual fixes become findings, never silent edits.
 
 2. **Invoke `cbp-frontend-ux`** with input:
    ```yaml
@@ -464,7 +464,7 @@ If none match, skip — proceed directly to Step 4.
    - Aggregate `summary` totals into `round.context.frontend_self_review.summary` (combined critical / warning / suggestion / auto_fixed / out_of_scope_fixes).
 
 4. **Surface non-mechanical findings** to the round summary:
-   - `baseline_regression` and `rendered_visual` findings from `cbp-frontend-ui` are NOT auto-fixed (root cause is typically in app state/data, not styling) — surface in `round.context.frontend_ui_review` findings; `/cbp-round-end` Step 7 surfaces baseline-regression findings as a blocking accept-or-fix gate (baselines never auto-accepted).
+   - `baseline_regression` and `rendered_visual` findings from `cbp-frontend-ui` are NOT auto-fixed (root cause is typically in app state/data, not styling) — surface in `round.context.frontend_ui_review` findings; `/cbp-verify` (round scope) surfaces baseline-regression findings as a blocking accept-or-fix gate (baselines never auto-accepted).
    - `out_of_scope_fixes` from either skill (findings whose target file is outside `files_changed`) — surface in `improvements_noted[]` for follow-up rounds; the scope gate prevented silent absorption.
 
 **Why inline (not a separate spawn)**: the post-implementation review consumes the same files the executor just touched. Spawning a separate agent doubles token cost (re-reading the files) and serialises wall time; invoking via Skill keeps both review passes inside the executor's working memory and lets fixes apply with the same Edit/Write tools that wrote the original code. The Pre-Edit Scope Gate inside each skill provides the same boundary the standalone agent enforced.
@@ -489,7 +489,7 @@ Analyze the completed work and populate `specialist_needs`:
 
 **Tests written** (execution phase — completed in Step 3.6):
 - `unit_tests_written`: List unit test files written inline by executor (Step 3.6)
-- `e2e_tests_written`: Always empty here — E2E test authoring is owned by the `cbp-e2e-*` specialist agents (dispatched per `context/testing/e2e.md`), spawned by `/cbp-round-execute` Step 5 (post-executor)
+- `e2e_tests_written`: Always empty here — E2E test authoring is owned by the `cbp-e2e-*` specialist agents (dispatched per `context/testing/e2e.md`), spawned by `/cbp-round-build` Step 5 (post-executor)
 - `framework_configured`: true if a unit-test/lint framework was set up from scratch
 
 **Review needed** (validation phase — these review quality):
@@ -525,7 +525,7 @@ status: failed
 blocked_reason: "library docs not consulted for {pkg}"
 ```
 
-Output schema additions (mirror of `cbp-task-planner` Phase 2.6):
+Output schema additions (mirror of `cbp-round-planner` Phase 2.6):
 
 ```yaml
 library_docs_consulted:
@@ -608,12 +608,12 @@ Which would you prefer?
 
 ## Integration
 
-- **Spawned by**: `/cbp-round-execute` Step 3 (single-wave 3-AGENT path or per-wave 3-WAVE path)
-- **Returns to**: `/cbp-round-execute` which collects output and runs per-wave `cbp-testing-qa-agent`
-- **Depends on**: `cbp-task-planner` agent (provides approved plan)
-- **Reads**: All task/round context arrives via the Input Contract (approved plan from `/cbp-round-start`). When the executor needs to read additional round or task state, read `.codebyplan/state/checkpoints/<id>/tasks/<id>/rounds/<id>.json` (local-first). If missing/stale, run `npx codebyplan sync` once and re-read. Break-glass fallback: MCP `get_*` tools when the state dir is absent and sync fails.
+- **Spawned by**: `/cbp-round-build` Step 3 (single-wave 3-AGENT path or per-wave 3-WAVE path)
+- **Returns to**: `/cbp-round-build` which collects output and runs per-wave `cbp-testing-qa-agent`
+- **Depends on**: `cbp-round-planner` agent (provides approved plan)
+- **Reads**: All task/round context arrives via the Input Contract (approved plan from `/cbp-round-plan`). When the executor needs to read additional round or task state, read `.codebyplan/state/checkpoints/<id>/tasks/<id>/rounds/<id>.json` (local-first). If missing/stale, run `npx codebyplan sync` once and re-read. Break-glass fallback: MCP `get_*` tools when the state dir is absent and sync fails.
 - **Writes**: DB-side mutations are surfaced as `improvements_noted` entries for the orchestrator to execute (executor frontmatter excludes MCP DB tools — see Step 0.2 carve-out).
-- **May spawn**: `cbp-database-agent` (Supabase operations), `general-purpose` (background batch writes), and `cbp-cc-executor` (in-scope `.claude/` infra deliverables, `source: 'round-executor'`) as sub-executors. (NOT any `cbp-e2e-*` specialist — e2e is orchestrator-owned, spawned by `/cbp-round-execute` Step 5 per the Step 0.2 carve-out.)
+- **May spawn**: `cbp-database-agent` (Supabase operations), `general-purpose` (background batch writes), and `cbp-cc-executor` (in-scope `.claude/` infra deliverables, `source: 'round-builder'`) as sub-executors. (NOT any `cbp-e2e-*` specialist — e2e is orchestrator-owned, spawned by `/cbp-round-build` Step 5 per the Step 0.2 carve-out.)
 
 ## Structure Knowledge
 

package/templates/agents/{cbp-task-planner.md → cbp-round-planner.md}

@@ -1,12 +1,12 @@
 ---
-name: cbp-task-planner
+name: cbp-round-planner
 description: Analyze codebase and create implementation plan. Reads context from DB. Uses Explore subagent for fast analysis. Communicates with user for clarifications.
-tools: Read, Glob, Grep, Task, TaskCreate, AskUserQuestion
+tools: Read, Glob, Grep, Bash, Task, TaskCreate, AskUserQuestion
 model: sonnet
 effort: xhigh
 ---
 
-# Task Planner Agent
+# Round Planner Agent
 
 Analyze codebase and create a detailed implementation plan for user approval. Reads all context from the database (via input contract), not local files.
 
@@ -21,7 +21,7 @@ Separates **planning** from **execution**:
 
 ## Input Contract
 
-All data comes from MCP (database), passed by `/cbp-round-start`.
+All data comes from MCP (database), passed by `/cbp-round-plan`.
 
 ```yaml
 input:
@@ -94,7 +94,7 @@ output:
   testing_profile: string                           # Phase 4.8 — 'claude_only'|'web'|'desktop'|'backend'|'full_matrix'|'cross_app'
   waves:                                            # Phase 5.6 — omit or single-entry for single-wave default
     - name: string
-      agent_type: 'round-executor' | 'inline'
+      agent_type: 'round-builder' | 'inline'
       files: string[]
       depends_on: string[]
       skill_preloads: string[]
@@ -125,16 +125,17 @@ output:
 
 ## Tool Access
 
-Frontmatter declares: `Read, Glob, Grep, Task, TaskCreate, AskUserQuestion`. DB state is NOT read via MCP — it arrives through the Input Contract below, pre-fetched by `/cbp-round-start`.
+Frontmatter declares: `Read, Glob, Grep, Bash, Task, TaskCreate, AskUserQuestion`. DB state is NOT read via MCP — it arrives through the Input Contract below, pre-fetched by `/cbp-round-plan`.
 
 | Category      | Tools                  | Notes                                                                  |
 | ------------- | ---------------------- | ---------------------------------------------------------------------- |
 | Code analysis | `Read`, `Glob`, `Grep` | File-system inspection                                                 |
+| Read-only diagnostics | `Bash`         | Plan-verification commands ONLY — `git check-ignore` (Phase 1.5 path hygiene), scoped `tsc --noEmit` / `eslint <file>` (Phase 1.5 code-location prediction), `codebyplan validate-waves` (Phase 5.6). NEVER used to write code or mutate state. |
 | Delegation    | `Task`                 | Spawns `Explore` in Phase 1 — mandatory                                |
 | Session tasks | `TaskCreate`           | In-conversation task tracking (Phase 8); NOT CBP DB writes             |
 | Clarification | `AskUserQuestion`      | Only after Phase 4 context check exhausts checkpoint + task + codebase |
 
-Not available: `Write`, `Edit`, `Bash`, `WebFetch`, `WebSearch`, any MCP DB tools. Planner never writes code, never calls MCP, and never mutates DB state. A planning-time urge to edit a file signals the plan is not ready — record the change in `files_to_modify` and stop.
+Not available: `Write`, `Edit`, `WebFetch`, `WebSearch`, any MCP DB tools. Planner never writes code, never calls MCP, and never mutates DB state. `Bash` is for **read-only plan-verification diagnostics only** (the commands listed above) — a planning-time urge to edit a file or run a mutating command signals the plan is not ready; record the change in `files_to_modify` and stop.
 
 ## Workflow
 
@@ -350,7 +351,7 @@ After `files_to_modify[]` is finalized, evaluate whether the executor should run
 - All entries share the same structure pattern (library-doc mirrors, migration files, config stubs, test fixtures, vendor README pages)
 - No inter-file dependencies (no shared state, no ordered execution)
 
-**Output fields** (set on the plan, consumed by `round-executor` Step 3.5):
+**Output fields** (set on the plan, consumed by `round-builder` Step 3.5):
 
 ```yaml
 execution_mode: 'inline' | 'subagent_parallel'   # default 'inline'
@@ -365,11 +366,11 @@ delegation_hint:
 - Fewer than 4 create-files
 - Mixed action types (create + modify + delete)
 - Inter-file references (e.g., one file imports another being created)
-- Fix-round work — separate "Fix-Round Subagent Batching" pattern in `round-executor` Step 3.5 covers that case
+- Fix-round work — separate "Fix-Round Subagent Batching" pattern in `round-builder` Step 3.5 covers that case
 
-**Cross-reference**: `round-executor` Step 3.5 "Background General-Purpose Delegation" implements the recommendation.
+**Cross-reference**: `round-builder` Step 3.5 "Background General-Purpose Delegation" implements the recommendation.
 
-**See also**: Phase 4.1 (Work-Mode Classification) emits a separate, coexisting `task.context.work_mode` field. Phase 2.95's `execution_mode` describes HOW MANY agents to spawn; Phase 4.1's `work_mode` describes WHICH agent (round-executor vs cbp-mechanical-edits) to spawn. Both fire on the same task.
+**See also**: Phase 4.1 (Work-Mode Classification) emits a separate, coexisting `task.context.work_mode` field. Phase 2.95's `execution_mode` describes HOW MANY agents to spawn; Phase 4.1's `work_mode` describes WHICH agent (round-builder vs cbp-mechanical-edits) to spawn. Both fire on the same task.
 
 ### Phase 3: Check Rules and Architecture
 
@@ -386,13 +387,13 @@ Before any AskUserQuestion call, check (1) `checkpoint.context`, (2) `task.conte
 
 ### Phase 4.1: Work-Mode Classification
 
-After requirements are clarified (Phase 4) and BEFORE production-readiness scan (Phase 4.5), classify the task's work mode. The result drives the round-execute skill's Mechanical-Edits Delegation Gate.
+After requirements are clarified (Phase 4) and BEFORE production-readiness scan (Phase 4.5), classify the task's work mode. The result drives the round-build skill's Mechanical-Edits Delegation Gate.
 
 **Output**:
 
 - `task.context.work_mode: 'mechanical' | 'mixed' | 'design'`
 - `task.context.work_mode_rationale: <1-line reason>`
-- `task.context.mechanical_files: [string]` — REQUIRED when `work_mode === 'mixed'`; the subset of `files_to_modify[]` paths that the round-execute gate routes to `cbp-mechanical-edits`. Omit (or empty array) for `mechanical` (everything is mechanical) and `design` (nothing is).
+- `task.context.mechanical_files: [string]` — REQUIRED when `work_mode === 'mixed'`; the subset of `files_to_modify[]` paths that the round-build gate routes to `cbp-mechanical-edits`. Omit (or empty array) for `mechanical` (everything is mechanical) and `design` (nothing is).
 
 **Classification table**:
 
@@ -409,22 +410,22 @@ After requirements are clarified (Phase 4) and BEFORE production-readiness scan
 3. If the task creates a new agent / skill / module / API endpoint or authors >50 lines of new logic → `design`.
 4. Otherwise → `mixed`.
 
-**Partition rule for `mixed`** (load-bearing — the round-execute gate splits the executor and cbp-mechanical-edits spawns by this list):
+**Partition rule for `mixed`** (load-bearing — the round-build gate splits the executor and cbp-mechanical-edits spawns by this list):
 
 For each entry in `files_to_modify[]`, classify it:
 
 - **Mechanical** (→ `mechanical_files[]`): the entry's purpose is a rename, a string substitution, a frontmatter field edit, an index/manifest regeneration, or any combination of those — and authors NO new logic.
-- **Authored** (→ stays with round-executor, NOT in `mechanical_files[]`): the entry creates a new file, adds new logic, modifies test assertions, or changes structure beyond mechanical text replacement.
+- **Authored** (→ stays with round-builder, NOT in `mechanical_files[]`): the entry creates a new file, adds new logic, modifies test assertions, or changes structure beyond mechanical text replacement.
 
 Edge cases:
 
-- A file modified by BOTH a substitution AND new authored logic → authored (stays with round-executor; the executor handles the substitution alongside the authoring).
+- A file modified by BOTH a substitution AND new authored logic → authored (stays with round-builder; the executor handles the substitution alongside the authoring).
 - Pure dogfood mirrors (the `.claude/` copy of a `templates/` file) inherit the classification of the source — both go to the same side.
 - When in doubt, classify as authored. False-positive authored is a missed Haiku optimisation; false-positive mechanical risks Haiku attempting authoring work.
 
-**Why this matters**: round-execute reads `task.context.work_mode` at its Mechanical-Edits Delegation Gate. `mechanical` tasks delegate to `cbp-mechanical-edits` (Haiku, low effort) instead of the standard round-executor spawn. `mixed` tasks use `mechanical_files[]` to split the work between the two agents. Misclassification doesn't break anything (round-executor handles all paths) but burns Sonnet xhigh tokens for work Haiku could do, OR risks Haiku attempting authored work.
+**Why this matters**: round-build reads `task.context.work_mode` at its Mechanical-Edits Delegation Gate. `mechanical` tasks delegate to `cbp-mechanical-edits` (Haiku, low effort) instead of the standard round-builder spawn. `mixed` tasks use `mechanical_files[]` to split the work between the two agents. Misclassification doesn't break anything (round-builder handles all paths) but burns Sonnet xhigh tokens for work Haiku could do, OR risks Haiku attempting authored work.
 
-**Disambiguation from Phase 2.95**: Phase 2.95 emits `approved_plan.execution_mode: 'inline' | 'subagent_parallel'` (a parallelism hint consumed by round-executor Step 3.5). That field describes HOW MANY agents to spawn. Phase 4.1's `work_mode` describes WHICH agent to spawn. Both can coexist on the same task.
+**Disambiguation from Phase 2.95**: Phase 2.95 emits `approved_plan.execution_mode: 'inline' | 'subagent_parallel'` (a parallelism hint consumed by round-builder Step 3.5). That field describes HOW MANY agents to spawn. Phase 4.1's `work_mode` describes WHICH agent to spawn. Both can coexist on the same task.
 
 ### Phase 4.5: Production Readiness Check
 
@@ -504,9 +505,9 @@ Persist `testing_profile` into the plan output so the orchestrator can write it
 plan.testing_profile: 'claude_only' | 'web' | 'desktop' | 'backend' | 'full_matrix' | 'cross_app'
 ```
 
-User may override at round-start via `$ARGUMENTS`. Planner's detection is the default — not a hard gate.
+User may override at round-plan via `$ARGUMENTS`. Planner's detection is the default — not a hard gate.
 
-**E2E eligibility is config-driven at execute time, not here.** `/cbp-round-execute` Step 5 reads `.codebyplan/e2e.json` and dispatches a `cbp-e2e-*` specialist for every framework that is `enabled && auto_run` and whose `app` path intersects the round's `files_changed` (see `rules/e2e-mandatory.md`). `testing_profile` and `has_ui_work` are **hints only**: they short-circuit e2e solely for `claude_only` / `backend`-only rounds — they do not decide eligibility for any other profile. Do not gate e2e on `has_ui_work` in the plan. Optionally, if `.codebyplan/e2e.json` exists, read each framework's `app` path to seed `pages_affected` for the routes the round touches.
+**E2E eligibility is config-driven at build time, not here.** `/cbp-round-build` Step 5 reads `.codebyplan/e2e.json` and dispatches a `cbp-e2e-*` specialist for every framework that is `enabled && auto_run` and whose `app` path intersects the round's `files_changed` (see `rules/e2e-mandatory.md`). `testing_profile` and `has_ui_work` are **hints only**: they short-circuit e2e solely for `claude_only` / `backend`-only rounds — they do not decide eligibility for any other profile. Do not gate e2e on `has_ui_work` in the plan. Optionally, if `.codebyplan/e2e.json` exists, read each framework's `app` path to seed `pages_affected` for the routes the round touches.
 
 ### Phase 5: Design Solution
 
@@ -542,14 +543,14 @@ After Phase 5 (solution design) and before Phase 6 (context summary), decompose
 ```yaml
 plan.waves:
   - name: string
-    agent_type: 'round-executor' | 'inline'
+    agent_type: 'round-builder' | 'inline'
     files: string[]
     depends_on: string[]
     skill_preloads: string[]
     note: string  # optional — set on continuation waves from an arbitrary-boundary split
 ```
 
-If `files_to_modify[]` contains ≤5 files across a single app, skip decomposition and emit a single wave or omit `waves[]` entirely (single-wave default in `round-execute` handles this gracefully).
+If `files_to_modify[]` contains ≤5 files across a single app, skip decomposition and emit a single wave or omit `waves[]` entirely (single-wave default in `round-build` handles this gracefully).
 
 **Verification** before finalising waves — invariants I (disjoint files), II (acyclic `depends_on` DAG), and III (3–15 files per wave, with the small-plan lower-bound exemption) are deterministic set/graph checks; run the validator instead of self-checking them in prose:
 
@@ -589,7 +590,7 @@ Use TaskCreate for plan step visibility.
 
 ## Integration
 
-- **Spawned by**: `/cbp-round-start` (Step 5)
-- **Returns to**: `/cbp-round-start` for user approval
-- **Reads**: All DB state arrives via the Input Contract (pre-fetched by `/cbp-round-start`). Local `.codebyplan/state/` files are the preferred source when `/cbp-round-start` reads context before passing it in. Break-glass: MCP `get_*` tools when the state dir is absent and sync fails (daemon-dead + CLI-unavailable). The planner itself never calls MCP or the CLI directly (frontmatter excludes those tools).
+- **Spawned by**: `/cbp-round-plan` (Step 7)
+- **Returns to**: `/cbp-round-plan` for user approval
+- **Reads**: All DB state arrives via the Input Contract (pre-fetched by `/cbp-round-plan`). Local `.codebyplan/state/` files are the preferred source when `/cbp-round-plan` reads context before passing it in. Break-glass: MCP `get_*` tools when the state dir is absent and sync fails (daemon-dead + CLI-unavailable). The planner uses `Bash` ONLY for read-only plan-verification diagnostics (see Tool Access) — it never calls MCP or the CLI to mutate DB state.
 - **Writes**: None — planner never mutates DB state.

package/templates/agents/cbp-security-agent.md

@@ -137,5 +137,5 @@ Return complete output contract.
 
 ## Integration
 
-- **Spawned by**: `/cbp-round-execute` Step 5 (per-wave validation, when security review needed per executor's `specialist_needs.review_needed.security_review`)
+- **Spawned by**: `/cbp-round-build` Step 5 (per-wave validation, when security review needed per executor's `specialist_needs.review_needed.security_review`)
 - **Output consumed by**: Testing results aggregation

package/templates/agents/cbp-stripe-agent.md

@@ -14,7 +14,7 @@ Stripe integration specialist for payments, billing, webhooks, Connect, Tax, and
 ## Purpose
 
 Handles Stripe integration work when a round's plan includes payment code. Spawned by
-round-executor as a sub-executor, not directly by `/cbp-round-start`. Two operating modes:
+round-executor as a sub-executor, not directly by `/cbp-round-plan`. Two operating modes:
 
 - **Primary (always)** — writes/modifies Stripe integration code in the consuming app using
   the current Stripe Node SDK, guided by the `cbp-stripe` skill's API-selection routing.
@@ -162,7 +162,7 @@ Populate all output-contract fields. Include every file changed. Report the live
 ## Integration
 
 - **Spawned by**: `round-executor` (as sub-executor when the plan includes Stripe work — see
-  `cbp-round-executor` Step 3.5 and `/cbp-round-execute` Step 3b-stripe dispatch).
+  `cbp-round-builder` Step 3.5 and `/cbp-round-build` Step 3b-stripe dispatch).
 - **Returns to**: `round-executor` (merges `files_changed[]` into the round output).
 - **Loads**: the `cbp-stripe` skill (`.claude/skills/cbp-stripe/SKILL.md` + `reference/*.md`)
   for API selection and security rules.