codebyplan 1.13.24 → 1.13.25

package/dist/cli.js

@@ -14,7 +14,7 @@ var VERSION, PACKAGE_NAME;
 var init_version = __esm({
   "src/lib/version.ts"() {
     "use strict";
-    VERSION = "1.13.24";
+    VERSION = "1.13.25";
     PACKAGE_NAME = "codebyplan";
   }
 });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codebyplan",
-  "version": "1.13.24",
+  "version": "1.13.25",
   "description": "CLI for CodeByPlan — AI-powered development planning and tracking",
   "type": "module",
   "bin": {
@@ -14,7 +14,7 @@
   "scripts": {
     "build": "tsc --project tsconfig.build.json",
     "build:npm": "node esbuild.npm.mjs",
-    "prepublishOnly": "npm run build:npm",
+    "prepare": "node -e \"const v=process.env.CI;process.exit(v&&v!=='false'&&v!=='0'?0:1)\" || node esbuild.npm.mjs",
     "lint": "eslint",
     "lint:fix": "eslint --fix",
     "format": "prettier --write \"src/**/*.ts\"",

package/templates/agents/cbp-cc-executor.md

@@ -1,7 +1,7 @@
 ---
 scope: org-shared
 name: cbp-cc-executor
-description: Authoring executor for `.claude/` infrastructure. Applies approved changes across rules, skills, agents, context, CLAUDE.md, settings, hooks, and auto-memory — with update-first discipline, scope-marker enforcement, and length-limit awareness. Callable by the main conversation and `/cbp-checkpoint-end`. NEVER called by `round-executor`.
+description: Authoring executor for `.claude/` infrastructure. Applies approved changes across rules, skills, agents, context, CLAUDE.md, settings, hooks, and auto-memory — with update-first discipline, scope-marker enforcement, and length-limit awareness. Callable by the main conversation, `/cbp-checkpoint-end`, and `round-executor` (for in-scope `.claude/` infra deliverables).
 tools: Read, Write, Edit, Glob, Grep, Skill, Task, AskUserQuestion, mcp__codebyplan__create_task
 model: sonnet
 effort: xhigh
@@ -28,15 +28,16 @@ One reusable primitive for applying batches of approved `.claude/` changes. Cent
 | ---------------------------- | ----------------------------------------------------- | -------------------------------------------------- |
 | Main conversation            | User directly asks Claude to update a rule/skill/etc. | Claude spawns the agent instead of editing by hand |
 | `/cbp-checkpoint-end` | Post-ship documentation / CLAUDE.md updates           | Future                                             |
+| `round-executor`             | A round's planned deliverables include `.claude/` infra | Executor delegates the batch here (`source: 'round-executor'`) instead of looping `/cbp-build-cc-*` per file |
 
-**`round-executor` NEVER calls this agent.** Round execution stays code-only. Infrastructure needs discovered mid-round are captured as tasks per `rules/immediate-issue-capture.md`, addressed through fix or a subsequent task.
+**`round-executor` MAY call this agent** to apply IN-SCOPE `.claude/` infrastructure deliverables — paths already in the round's approved `files_to_modify[]`. This is distinct from the immediate-issue-capture path: infrastructure needs *discovered* mid-round that fall OUTSIDE the round's scope are still captured as tasks per `cbp-task-create` Step 3.5 "Immediate Issue Capture Contract" — never routed through this agent.
 
 ## Input Contract
 
 ```yaml
 input:
   repo_id: string
-  source: 'main' | 'checkpoint-end'  # additional internal sources may exist in your CBP setup; extend as needed
+  source: 'main' | 'checkpoint-end' | 'round-executor'  # additional internal sources may exist in your CBP setup; extend as needed
   changes:
     - id: string | number
       type: 'rule' | 'skill' | 'agent' | 'context' | 'architecture' | 'CLAUDE.md' | 'settings' | 'hook' | 'memory'
@@ -102,7 +103,7 @@ For each change in `input.changes`, pre-flight in order:
 
    | `source`                  | Expected                        | On missing/generic                                                                                                                     |
    | ------------------------- | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
-   | `main` / `checkpoint-end` | Often absent — caller is ad-hoc | Derive them here: use Phase 1 inventory to list candidates, and fill `why_not_existing` with the agent's own reasoning. Do not reject. |
+   | `main` / `checkpoint-end` / `round-executor` | Often absent — caller is ad-hoc or plan-driven | Derive them here: use Phase 1 inventory to list candidates, and fill `why_not_existing` with the agent's own reasoning. Do not reject. |
 
 4. **Length pre-flight** — for `update`, read current length; reject if the requested change would exceed the block limit in `validate-structure-lengths.sh`. Offer a split proposal via `AskUserQuestion` instead.
 
@@ -134,7 +135,7 @@ Record every applied change with `authored_via` and `status`.
 
 - **Downgrade `create` → `update`** — apply silently, note in output.
 - **Unclear fit between two existing files** — `AskUserQuestion` with the two candidates and their descriptions.
-- **Change exceeds this invocation's scope** (e.g. proposal implies a broader refactor) — create a task via MCP `create_task` per `rules/immediate-issue-capture.md`, record in `deferred_changes` with `task_id_created`.
+- **Change exceeds this invocation's scope** (e.g. proposal implies a broader refactor) — create a task via MCP `create_task` per `cbp-task-create` Step 3.5 "Immediate Issue Capture Contract", record in `deferred_changes` with `task_id_created`.
 - **Hook or settings change with cross-environment implications** — require explicit `scope` field from caller; if missing or ambiguous, ask.
 
 ### Phase 5: Post-Apply Sanity
@@ -204,8 +205,7 @@ Block-limit violations are non-negotiable — split before applying.
 
 ## Integration
 
-- **Spawned by**: main conversation (ad-hoc), `/cbp-checkpoint-end` (future)
-- **Never spawned by**: `round-executor` (round execution stays code-only)
+- **Spawned by**: main conversation (ad-hoc), `/cbp-checkpoint-end` (future), `round-executor` (in-scope `.claude/` infra deliverables, `source: 'round-executor'`)
 - **Reads**: `.claude/` inventory, `validate-structure-lengths.sh`, target files
 - **Writes**: `.claude/` files (via `/cbp-build-cc-*` skills for creates, direct Edit for updates)
 - **Calls skills**: `/cbp-build-cc-rule`, `/cbp-build-cc-skill`, `/cbp-build-cc-claude-file`, `/cbp-build-cc-settings`, `/cbp-build-cc-memory`

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

@@ -237,9 +237,9 @@ For each issue found:
 **Corrective-depth advisory**: Before emitting findings, check `round.number` and round provenance:
 - IF `round.number >= 3` AND the round is corrective (round requirements contain improvement/correction verbs: "fix", "address", "correct", "resolve" against a prior finding)
 - THEN prepend to the Phase 6 output: `> [advisory] This is round N. Each successive corrective round increases ship-delay risk; consider deferring low/medium findings to a follow-up TASK in the current checkpoint (not a standalone task). Findings still listed in full — your call.`
-- Findings remain unchanged; this is informational only. Pairs with `rules/planner-spawn-threshold.md` Path B (which keeps trivial corrective rounds cheap) — together they bound corrective-chain depth.
+- Findings remain unchanged; this is informational only. Pairs with the planner's Path B trivial-corrective bypass (which keeps trivial corrective rounds cheap) — together they bound corrective-chain depth.
 
-**Scope-routing recommendation**: For each finding that exceeds the current round's scope, populate `finding.routing_recommendation` per `rules/immediate-issue-capture.md` "How to Capture":
+**Scope-routing recommendation**: For each finding that exceeds the current round's scope, populate `finding.routing_recommendation` per `cbp-task-create` Step 3.5 "Immediate Issue Capture Contract — How to Capture":
 
 | Finding shape | `routing_recommendation` |
 |---------------|--------------------------|

package/templates/agents/cbp-round-executor.md

@@ -2,7 +2,7 @@
 scope: org-shared
 name: cbp-round-executor
 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
+tools: Read, Write, Edit, Glob, Grep, Bash, TaskUpdate, AskUserQuestion, Skill, Task
 model: sonnet
 effort: xhigh
 ---
@@ -94,6 +94,7 @@ output:
 | TaskUpdate | Mark todos as complete |
 | AskUserQuestion | **Critical** - Ask user when blocked or need decisions |
 | Skill | **Required** - Invoke routing commands for managed files |
+| Task | Spawn sub-executor agents (Step 3.5): `cbp-database-agent`, `general-purpose`, `cbp-cc-executor` — NEVER `cbp-e2e-*` (orchestrator-owned) |
 
 **Key Principle:** If something is unclear or you're blocked, ASK the user. Don't make assumptions.
 
@@ -140,6 +141,8 @@ Action: {Use Skill tool for routing / Proceed with direct edits}
 
 **Critical:** If ANY file requires routing, you MUST use the Skill tool. NEVER use Edit/Write on managed files.
 
+**Batch alternative:** when `files_to_modify[]` contains MULTIPLE `.claude/` infra files, you MAY delegate the whole batch to `cbp-cc-executor` (Step 3.5) instead of looping the build-cc skills here — cc-executor applies the same routing with centralized update-first / scope-marker / length discipline. Single-file managed edits stay on the Skill-tool routing above.
+
 #### Step 0.1: Scope-Leak Guard (MANDATORY)
 
 Before ANY Write/Edit invocation during execution, the target path MUST appear in the active scope. When running in wave mode (`wave` input is present), the scope is `wave.files[]`; otherwise it is `approved_plan.files_to_modify[].path`. Silent absorption of an out-of-scope file is forbidden — every absorbed file dilutes the round's diff and erodes plan-as-contract guarantees.
@@ -183,7 +186,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 | Executor's tools list (Read/Write/Edit/Glob/Grep/Bash/TaskUpdate/AskUserQuestion/Skill) does NOT include the `Task` / Agent tool. E2E execution is owned by the `cbp-e2e-*` specialist agents (dispatched per `context/testing/e2e.md`), spawned by `/cbp-round-execute` Step 5 (parallel with `cbp-testing-qa-agent`) and is invoked by the orchestrator. | 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-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. |
 
 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.
 
@@ -305,6 +308,7 @@ When the approved plan includes specialized work, delegate to sub-executor agent
 |-----------|-------|-----------------|
 | Supabase migrations, RLS, types | `cbp-database-agent` | Plan includes DB schema changes, RLS policies, or type generation |
 | Batch identical-structure file writes (≥4 files) | `general-purpose` (background) | Plan has 4+ independent files, no shared state, no ordered dependency |
+| `.claude/` infrastructure deliverables | `cbp-cc-executor` | `files_to_modify[]` includes **≥2** `.claude/` files (rules, skills, agents, context, hooks, settings, CLAUDE.md). A single `.claude/` file edit stays on Step 0 Skill-tool routing |
 
 **How to delegate to `cbp-database-agent`:**
 1. Collect all DB-related steps from the plan
@@ -316,6 +320,18 @@ When the approved plan includes specialized work, delegate to sub-executor agent
 - Simple Supabase queries in application code (executor handles these)
 - Only delegate schema/migration/RLS/type generation work
 
+**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.
+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.
+
+**When NOT to delegate to `cbp-cc-executor`:**
+- A single `.claude/` file edit — the Step 0 build-cc routing (Skill tool) handles it; reserve cc-executor for multi-file batches or when its centralized update-first / scope / length discipline adds value.
+- Infra needs *discovered* mid-round that are OUTSIDE `files_to_modify[]` — those become tasks per `cbp-task-create` Step 3.5, NEVER a cc-executor call.
+
 #### Background General-Purpose Delegation
 
 **Trigger** — all of the following must hold:
@@ -585,7 +601,7 @@ Which would you prefer?
 - **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)
-- **May spawn**: `cbp-database-agent` as sub-executor for Supabase operations. (NOT any `cbp-e2e-*` specialist — those are owned by the `cbp-e2e-*` specialist agents (dispatched per `context/testing/e2e.md`), spawned by `/cbp-round-execute` Step 5 per 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.)
 
 ## Structure Knowledge
 
@@ -603,4 +619,4 @@ improvements_noted:
     suggestion: 'Add [pattern] to [skill-name] or create new skill'
 ```
 
-**Do NOT edit rules/skills during execution** - `cbp-improve-claude` handles `.claude/` updates after task completion.
+**Do NOT make self-directed rules/skills edits based on gaps you discover mid-execution** — those go through `cbp-improve-claude` after task completion. This is distinct from approved `.claude/` deliverables already in `files_to_modify[]`, which ARE applied this round via the Step 3.5 `cbp-cc-executor` delegation path (or Step 0 Skill-tool routing for a single file).

package/templates/agents/cbp-testing-qa-agent.md

@@ -300,11 +300,11 @@ Mandatory dependency vulnerability scan:
 
 ### Phase 3.8: Capture Unrelated Issues — Default to Current Scope
 
-For each entry in `unrelated_issues[]` with severity `warning` or `critical`, route per `immediate-issue-capture.md` "How to Capture" — DO NOT default to standalone task creation.
+For each entry in `unrelated_issues[]` with severity `warning` or `critical`, route per `cbp-task-create` Step 3.5 "Immediate Issue Capture Contract — How to Capture" — DO NOT default to standalone task creation.
 
 **Routing logic** (walk top-down; use the first row that fits):
 
-1. **Trivial inline fix** (≤5 min, mechanical, scope-clean per `infra-issue-absorption.md` Trivial-Resolution Exception) — leave the issue in `unrelated_issues[]` with `routing: "inline"` and let the orchestrator absorb it into the current round before `/cbp-round-end`.
+1. **Trivial inline fix** (≤5 min, mechanical, scope-clean per `cbp-round-end` reference `findings-presentation.md` "Infra Issue Absorption Contract — Trivial-Resolution Exception") — leave the issue in `unrelated_issues[]` with `routing: "inline"` and let the orchestrator absorb it into the current round before `/cbp-round-end`.
 
 2. **Related to current task's domain** (most cases) — emit the finding in `unrelated_issues[]` with `routing: "new_round_in_current_task"`. The agent does NOT call `create_task`. `/cbp-round-end` consumes these and includes them as requirements for the next round of the current task.
 
@@ -318,7 +318,7 @@ For routings 1-4, include each finding in `unrelated_issues[]` with the routing
 
 The agent's job is **classification + recommendation**, not unilateral task creation. Standalone creation outside the timed-re-check case requires explicit user confirmation at `/cbp-round-end`.
 
-This aligns with `immediate-issue-capture.md` (resolve-in-current-scope by default; standalone is rare) and `infra-issue-absorption.md` (absorb-by-default since the flip from defer-by-default).
+This aligns with `cbp-task-create` Step 3.5 "Immediate Issue Capture Contract" (resolve-in-current-scope by default; standalone is rare) and `cbp-round-end` reference `findings-presentation.md` "Infra Issue Absorption Contract" (absorb-by-default since the flip from defer-by-default).
 
 ### Phase 4: QA Generation
 

package/templates/hooks/validate-structure-patterns.sh

@@ -38,7 +38,7 @@ if match_path '^/\.claude/docs/stack/' \
 fi
 
 # Notation consistency (warn-only): flag bare-colon command notation in .claude/ markdown
-# See: /.claude/rules/notation-consistency.md — all command refs must use /cbp-* form
+# See: cbp-round-start Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary" — all command refs must use /cbp-* form
 if match_path '^/\.claude/(rules|skills|agents)/' && match_path '\.md$'; then
   CONTENT=$(read_input_content)
   [ -z "$CONTENT" ] && [ -f "$FILE_PATH" ] && CONTENT=$(cat "$FILE_PATH" 2>/dev/null || true)

package/templates/skills/cbp-checkpoint-check/SKILL.md

@@ -120,11 +120,11 @@ Aggregate the files touched across all tasks (reusing Step 4's deduplicated tabl
    Continue to Step 6.
 
 5. **On fail** (any framework `f`: `e2e_outputs[f].status === 'failed'` OR `e2e_outputs[f].test_results.failed > 0`): build a failure summary from `e2e_outputs[*].test_results.failures[]` aggregated and grouped by `category`. Surface via `AskUserQuestion`:
-   - **(a) Create fix-task in CHK-{NNN} (recommended)** — invoke MCP `create_task` with `checkpoint_id=current_checkpoint_id`, `title="Fix checkpoint-level e2e failures (CHK-{NNN})"`, `requirements` containing the detailed failure breakdown (category counts, files involved, pages broken, screenshot paths from `e2e_outputs[*].screenshots[]`), AND `context: { source_checkpoint_id, e2e_failure_summary: { category_counts, pages_broken, screenshot_paths }, fix_type: "checkpoint_e2e" }` so downstream `cbp-task-planner` can verify failure premises. Per `infra-issue-absorption.md` "Resolve-in-Current-Scope by Default", checkpoint-level e2e failures absorb into the active checkpoint — not standalone.
+   - **(a) Create fix-task in CHK-{NNN} (recommended)** — invoke MCP `create_task` with `checkpoint_id=current_checkpoint_id`, `title="Fix checkpoint-level e2e failures (CHK-{NNN})"`, `requirements` containing the detailed failure breakdown (category counts, files involved, pages broken, screenshot paths from `e2e_outputs[*].screenshots[]`), AND `context: { source_checkpoint_id, e2e_failure_summary: { category_counts, pages_broken, screenshot_paths }, fix_type: "checkpoint_e2e" }` so downstream `cbp-task-planner` can verify failure premises. Per `cbp-round-end` reference `findings-presentation.md` "Infra Issue Absorption Contract — Resolve-in-Current-Scope by Default", checkpoint-level e2e failures absorb into the active checkpoint — not standalone.
    - **(b) Surface as warning only — proceed to checkpoint-end** — append `| Checkpoint E2E | warning | N failures (deferred) |` to Step 5 QA Summary; continue to Step 6.
    - **(c) Halt — review manually** — STOP and wait for the user.
 
-   See `infra-issue-absorption.md` Catalog row "Checkpoint-level e2e failure" for the routing rationale.
+   See `cbp-round-end` reference `findings-presentation.md` "Infra Issue Absorption Contract — Infra-Class Issue Catalog" row "Checkpoint-level e2e failure" for the routing rationale.
 
 ### Step 6: User Discussion
 

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

@@ -47,13 +47,13 @@ Given the parse from Step 0.5:
 
 ### Step 2: Verify Checkpoint End Has Run
 
-Check `checkpoint.context.shipment` — must exist with at least `feat_to_dev.merged: true`.
+Check `checkpoint.context.shipment` — must exist with at least `feat_to_base.merged: true`.
 
 If not:
 ```
 ## Cannot Complete Checkpoint
 
-Checkpoint has not been shipped yet. Run `/cbp-checkpoint-end` first to merge feat branch to development.
+Checkpoint has not been shipped yet. Run `/cbp-checkpoint-end` first to merge the feat branch to the base branch.
 ```
 Stop here.
 

package/templates/skills/cbp-merge-main/SKILL.md

@@ -96,7 +96,7 @@ Supabase migrations are version-keyed by their numeric filename prefix. Two file
 
    - **Rename HEAD-side (Recommended when a main migration is already applied to a shared remote)** — rename the local file to a fresh, sequential timestamp that respects existing apply-order dependencies (probe `supabase migration list --db-url <preview>` if a preview branch exists, or inspect FK references in surrounding migrations). The orchestrator runs `git mv <old> <new>` itself; the rename lands in the git index and is picked up by the re-probe at step 5.
    - **Rename main-side (manual, OUT-OF-SKILL)** — only when the main file definitely has not been applied anywhere yet AND the user has write access to `{BASE}`. This skill does NOT touch the main branch: it runs on a feat branch (Step 0 enforces this) and the Key Rules below forbid any push from this skill. The user must, in a separate terminal: `git checkout {BASE} && git mv <old> <new> && git commit -m "fix(migration): rename to resolve collision with feat/..." && git push origin {BASE}`. After that push is confirmed remote-side, re-invoke `/cbp-merge-main` — Step 1 will fetch the updated main tip and Step 1.5 will re-probe with the rename in place.
-   - **Defer to a new task in the active checkpoint** — `git merge --abort` is unnecessary because Step 2 has not started. Create a CHK-bound task per `infra-issue-absorption.md` "Resolve-in-Current-Scope by Default" and STOP `/cbp-merge-main`. Resume after the task completes.
+   - **Defer to a new task in the active checkpoint** — `git merge --abort` is unnecessary because Step 2 has not started. Create a CHK-bound task per `cbp-round-end` reference `findings-presentation.md` "Infra Issue Absorption Contract — Resolve-in-Current-Scope by Default" and STOP `/cbp-merge-main`. Resume after the task completes.
    - **Abort merge** — STOP the skill. User decides later.
 
 5. After any HEAD-side rename action, re-execute Step 1.5 (collisions may chain — fixing one can expose another). The HEAD-side probe at step 1 uses `git ls-files` rather than `git ls-tree HEAD`, so the freshly-staged `git mv` is visible without requiring a commit. Main-side renames require a fresh `/cbp-merge-main` invocation (the user manually fetched and re-ran per option 2 above), not an in-skill loop.

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

@@ -5,27 +5,6 @@ description: Summary wrap-up after testing phase completes
 effort: high
 ---
 
-## Kind Detection
-
-Inspect the resolved identifier from argument parsing to determine the task kind:
-
-| Identifier shape | KIND |
-|-----------------|------|
-| `{task}-{round}` (2-segment, e.g. `45-2`) | `standalone` |
-| `{chk}-{task}-{round}` (3-segment, e.g. `141-3-1`) | `checkpoint` |
-| _(empty / free-text)_ | Check `get_current_standalone_task` first; if found → `standalone`. Else → `checkpoint` via `get_current_task`. |
-
-Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
-
-| Operation | `checkpoint` KIND | `standalone` KIND |
-|-----------|------------------|-------------------|
-| Get task | `get_current_task(repo_id)` | `get_current_standalone_task(repo_id)` |
-| Get rounds | `get_rounds(task_id)` | `get_standalone_rounds(standalone_task_id)` |
-| Add round | `add_round(task_id, ...)` | `add_standalone_round(standalone_task_id, ...)` |
-| Update round | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
-| Complete round | `complete_round(round_id, duration_minutes?)` | `complete_standalone_round(standalone_round_id, duration_minutes?, caller_worktree_id)` ⚠️ `caller_worktree_id` is REQUIRED for standalone |
-| Update task | `update_task(task_id, ...)` | `update_standalone_task(standalone_task_id, ...)` |
-
 # Round End Command
 
 Summary phase — presents what was done, then runs code quality review to catch bugs and logic errors that automated checks miss.
@@ -42,16 +21,14 @@ See `reference/inline-fallback.md` for full trigger table, procedure, and covera
 
 ## Identifier Notation
 
-This skill operates on the **active** task/round resolved via MCP and does not accept a positional identifier argument. Canonical chk-task-round notation — used in prose, error messages, and cross-references — follows `.claude/rules/notation-consistency.md` "CHK / TASK / ROUND Identifier Notation": `108-1` (CHK-108 TASK-1), `45` (standalone TASK-45), `108-1-2` (round 2 of CHK-108 TASK-1), `45-2` (round 2 of standalone TASK-45).
+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".
 
 ## Instructions
 
 ### Step 1: Get Current Task and Round
 
-Use Kind Detection above to set KIND. Then:
-
-- **checkpoint KIND**: MCP `get_current_task(repo_id)` (pass `checkpoint_id` if known) to find the active task. MCP `get_rounds(task_id)` to find the in-progress round.
-- **standalone KIND**: MCP `get_current_standalone_task(repo_id)` to find the active task. MCP `get_standalone_rounds(standalone_task_id)` to find the in-progress round.
+Use MCP `get_current_task` with repo_id (pass `checkpoint_id` if known to avoid disambiguation) to find the active task.
+Use MCP `get_rounds` for the task to find the in-progress round.
 
 Load round context with all outputs (executor_output, testing_qa_output, reviewer_output).
 
@@ -93,11 +70,11 @@ Merge with previous rounds (supersede items for re-modified files, preserve veri
 
 ### Step 4: Update Task Files and QA
 
-Update via MCP using KIND-appropriate tools:
+Update via MCP:
 
-- `update_task(task_id, files_changed: [...])` / `update_standalone_task(standalone_task_id, files_changed: [...])` — merge with existing
-- `update_round(round_id, files_changed: [...], qa: {items: [auto_qa items + default_checklist items]})` / `update_standalone_round(standalone_round_id, ...)` — round-specific
-- `update_task(task_id, qa: {items: [auto_qa items + default_checklist items]})` / `update_standalone_task(standalone_task_id, qa: {items: [auto_qa items + default_checklist items]})` — aggregated
+- `update_task(task_id, files_changed: [...])` — merge with existing
+- `update_round(round_id, files_changed: [...], qa: {items: [auto_qa items + default_checklist items]})` — round-specific
+- `update_task(task_id, qa: {items: [auto_qa items + default_checklist items]})` — aggregated
 
 ### Step 5: Present Summary
 
@@ -160,8 +137,8 @@ Example tables and the `inline` option gating spec: see `reference/findings-pres
 - Auto-accept ALL findings into `improve_round_findings[]` regardless of severity (the user opted into the loop).
 - Skip the polish-spiral stop-gate (auto-loop has its own cap-exhausted termination).
 - Skip the user findings-decision prompt.
-- Save findings via `update_round` / `update_standalone_round` per KIND exactly as in manual mode.
-- Auto-trigger `/cbp-round-update` immediately. round-update Step 4 will decide whether to spawn another round or exit clean (see cbp-round-update SKILL.md Step 4).
+- Save findings via `update_round` exactly as in manual mode.
+- Auto-trigger `/cbp-round-update` immediately. round-update Step 6 will decide whether to spawn another round or exit clean (see cbp-round-update SKILL.md Step 6).
 
 **Else (manual mode — flag absent or false):**
 
@@ -169,7 +146,7 @@ Run the existing flow:
 
 1. After round 2+, surface the polish-spiral stop-gate per `polish-spiral-stop-gate.md` (defer-to-followups vs continue).
 2. Surface the findings-decision AskUserQuestion (with optional `inline` per the gating rules in `reference/findings-presentation.md`).
-3. Save accepted/rejected findings to round context via MCP `update_round` / `update_standalone_round` per KIND:
+3. Save accepted/rejected findings to round context via MCP `update_round`:
    ```json
    {
      "context": {
@@ -190,7 +167,7 @@ Run the existing flow:
 ## Integration
 
 - **Triggered by**: `/cbp-round-execute` (auto, after all waves + testing complete)
-- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND), round context
-- **Writes**: MCP `update_round` / `update_standalone_round`, `update_task` / `update_standalone_task` (files_changed, qa, findings) — per KIND
+- **Reads**: MCP `get_current_task`, `get_rounds`, round context
+- **Writes**: MCP `update_round`, `update_task` (files_changed, qa, findings)
 - **Spawns**: `cbp-improve-round` (code quality review)
 - **Triggers**: `/cbp-round-update` (auto, after findings handled)

package/templates/skills/cbp-round-end/reference/findings-presentation.md

@@ -29,16 +29,89 @@ Which findings should be fixed?
 - "all" — fix all findings in a new round
 - "1,2" — fix specific findings by number
 - "none" — skip all, proceed to round-update
-- "inline" — fix in THIS round before proceeding (only offered when all findings qualify under `infra-issue-absorption.md` Trivial-Resolution Exception)
+- "inline" — fix in THIS round before proceeding (only offered when all findings qualify under the Trivial-Resolution Exception below)
 - Or explain why specific findings are not issues
 ```
 
 ## "inline" option gating
 
-Only present the "inline" option when ALL pending findings simultaneously satisfy:
+Only present the "inline" option when ALL pending findings simultaneously qualify under the **Trivial-Resolution Exception** (see subsection below):
 
 1. Diff is comment-only, annotation-only, banner-only, or single-value rename — no logic, no control flow
 2. Each fix is under ~5 minutes of executor time
 3. Verification is automatic — the existing test/lint/audit pipeline confirms the change
 
-If any finding fails these gates, omit the "inline" option entirely (revert to the 3-option prompt). When inline is chosen, apply the edits via direct `Edit`, re-run the verification commands (hook syntax check + `testing-qa-agent` scoped to modified files) and proceed to `/cbp-round-update` without spawning a new round. Document the decision in `round.context.inline_fix_log = { findings: [ids], rationale: "trivial-resolution exception", applied_at: <ISO> }` (mirrors the `bypass_log` shape from `infra-issue-absorption.md` "Pipeline Bypass for Trivial-Resolution Rounds").
+If any finding fails these gates, omit the "inline" option entirely (revert to the 3-option prompt). When inline is chosen, apply the edits via direct `Edit`, re-run the verification commands (hook syntax check + `cbp-testing-qa-agent` scoped to modified files) and proceed to `/cbp-round-update` without spawning a new round. Document the decision in `round.context.inline_fix_log = { findings: [ids], rationale: "trivial-resolution exception", applied_at: <ISO> }` (mirrors the `bypass_log` shape from the Pipeline Bypass subsection below).
+
+---
+
+## Infra Issue Absorption Contract
+
+### Resolve-in-Current-Scope by Default
+
+When `/cbp-round-execute` Step 5 (per-wave `cbp-testing-qa-agent`) or `/cbp-task-testing` surfaces a pre-existing infra-class issue (critical/high CVE, broken ESLint config-load, Playwright env-loading gap, dead CI pipeline, etc.), the default response is **absorb into current scope** — NOT create a standalone task.
+
+Order of preference for routing a finding:
+
+1. **Trivial-resolution inline** (no new round) — fix qualifies for the exception below
+2. **New round in the current task** — finding is related to the task's domain
+3. **New task in the current checkpoint** — finding belongs to the checkpoint goal but is a separate concern
+4. **Standalone task** — only when the finding is truly off-axis from the active checkpoint AND the user has explicitly confirmed standalone routing
+
+### Trivial-Resolution Exception
+
+Resolve inline in the CURRENT round (no new round, no new task) when ALL hold:
+
+1. The fix is **fully mechanical** — no design decision, no tradeoff, no naming question
+   - **1a. Unambiguous scope**: no decision about sweep extent required
+   - **1b. Pattern soundness verified** at each target site before propagating
+2. The fix takes **under ~5 minutes** of executor time
+3. The fix's diff stays **scoped to its own concern** and won't dilute the round's primary diff
+4. Verification is automatic (existing test/lint/audit pipeline confirms it)
+
+Examples that qualify:
+
+| Finding | Inline action |
+|---------|---------------|
+| Pre-existing prettier drift in N files | `prettier --write` on those files |
+| Single transitive CVE with a known-good `pnpm.overrides` line | Add the override, re-audit |
+| One-line hook tweak (add a filename to an exemption list) | Edit the hook |
+| Non-breaking patch bump on a build-tool | Update package.json, lockfile |
+| In-module sibling violations (≤2) with canonical 2-line fix | Apply inline, document in adoption row |
+| Homogeneous-pattern mass migration (single rule, single shape, fully mechanical, verifiable by grep) | Apply across all sites in one round |
+
+Examples that do NOT qualify — route to a new round in the current task:
+
+| Finding | Why |
+|---------|-----|
+| Diacritical fix in R1 i18n blocks with potentially 80+ unrelated sites elsewhere | Scope decision required |
+| `.update().single()` violations in 22 sites across 9 modules | Cross-module sweep requires coordinated audit |
+| Auth-guard sweep across multiple feature modules | Multi-module; needs dedicated round |
+
+### Pipeline Bypass for Trivial-Resolution Rounds
+
+When the trivial-resolution exception qualifies, the orchestrator MAY bypass these pipeline stages — document in `round.context.bypass_log`:
+
+| Stage | Bypass allowed when | Document as |
+|-------|--------------------|-------------|
+| `cbp-round-executor` | Single-file Edit fully specified by prior reviewer output | `bypass_log.executor: "single-file edit, used direct Edit"` |
+| `cbp-testing-qa-agent` | Edit is non-code (comment, doc, type-annotation) AND existing test coverage protects the area | `bypass_log.testing_qa: "non-code edit, existing tests cover area"` |
+| `cbp-improve-round` | Diff is ≤5 lines AND no logic changed | `bypass_log.improve_round: "≤5 lines non-logic, skipped"` |
+| `cbp-task-planner` | Path B (the planner's trivial-corrective bypass that keeps repeat fix-rounds cheap) already qualifies | `bypass_log.planner: "Path B trivial-corrective bypass"` |
+
+**ALL four bypasses simultaneously** is acceptable for ≤5-line non-logic corrective edits where every premise was verified by a prior reviewer.
+
+**Do NOT bypass** when: round modifies behaviour; round changes test assertions; round touches more than one file; round is the FIRST round of the task.
+
+### Infra-Class Issue Catalog
+
+These categories surface from per-wave `cbp-testing-qa-agent` or from `/cbp-task-testing`. Default routing for each is in-scope absorption unless genuinely off-axis from the active checkpoint.
+
+| Category | Examples |
+|----------|----------|
+| Vulnerability | `pnpm audit` critical/high advisories |
+| Dead build tooling | ESLint config fails to load, Prettier crashes, tsc OOM |
+| Test infra gaps | Playwright `.env.local` not loaded, CI env var missing |
+| Dependency drift | Major version behind on non-breaking peer dep |
+| Config registry drift | Port allocation missing, turbo pipeline missing entry |
+| Checkpoint-level e2e failure | Whole-checkpoint e2e run (`/cbp-checkpoint-check` Step 5b) reports failures — absorb into the active checkpoint as a fix-task, never standalone |

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

@@ -5,27 +5,6 @@ description: Execute the approved plan from /cbp-round-start — runs per-wave e
 effort: xhigh
 ---
 
-## Kind Detection
-
-Inspect the resolved identifier from argument parsing to determine the task kind:
-
-| Identifier shape | KIND |
-|-----------------|------|
-| `{task}-{round}` (2-segment, e.g. `45-2`) | `standalone` |
-| `{chk}-{task}-{round}` (3-segment, e.g. `141-3-1`) | `checkpoint` |
-| _(empty / free-text)_ | Check `get_current_standalone_task` first; if found → `standalone`. Else → `checkpoint` via `get_current_task`. |
-
-Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
-
-| Operation | `checkpoint` KIND | `standalone` KIND |
-|-----------|------------------|-------------------|
-| Get task | `get_current_task(repo_id)` | `get_current_standalone_task(repo_id)` |
-| Get rounds | `get_rounds(task_id)` | `get_standalone_rounds(standalone_task_id)` |
-| Add round | `add_round(task_id, ...)` | `add_standalone_round(standalone_task_id, ...)` |
-| Update round | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
-| Complete round | `complete_round(round_id, duration_minutes?)` | `complete_standalone_round(standalone_round_id, duration_minutes?, caller_worktree_id)` ⚠️ `caller_worktree_id` is REQUIRED for standalone |
-| Update task | `update_task(task_id, ...)` | `update_standalone_task(standalone_task_id, ...)` |
-
 # Round Execute 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`.
@@ -38,16 +17,14 @@ Execution and validation phase. Receives the approved plan from `/cbp-round-star
 
 ## Identifier Notation
 
-This skill operates on the **active** task/round resolved via MCP and does not accept a positional identifier argument. Canonical chk-task-round notation — used in prose, error messages, and cross-references — follows `.claude/rules/notation-consistency.md` "CHK / TASK / ROUND Identifier Notation": `108-1` (CHK-108 TASK-1), `45` (standalone TASK-45), `108-1-2` (round 2 of CHK-108 TASK-1), `45-2` (round 2 of standalone TASK-45).
+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".
 
 ## Instructions
 
 ### Step 1: Get Current Task and Round
 
-Use Kind Detection above to set KIND. Then:
-
-- **checkpoint KIND**: MCP `get_current_task(repo_id)` (pass checkpoint_id if known) to find the active task. MCP `get_rounds(task_id)` to find the in-progress round.
-- **standalone KIND**: MCP `get_current_standalone_task(repo_id)` to find the active task. MCP `get_standalone_rounds(standalone_task_id)` to find the in-progress round.
+Use MCP `get_current_task` with repo_id (pass checkpoint_id if known) to find the active task.
+Use MCP `get_rounds` for the task to find the in-progress round.
 
 If no in-progress round: `No active round. Run /cbp-round-start first.`
 
@@ -184,35 +161,11 @@ Input contracts: `cbp-testing-qa-agent` receives `executor_output`, `testing_pro
 
 ### Step 5b: Post-E2E Screenshot Review (cbp-frontend-ui Phase 6.5)
 
-Aggregate across ALL specialists that ran:
-
-```js
-screenshots = Object.values(round.context.e2e_outputs ?? {}).flatMap(o => o.screenshots ?? []);
-e2e_gallery  = Object.values(round.context.e2e_outputs ?? {}).flatMap(o => o.e2e_gallery  ?? []);
-```
-
-**Auto-new baseline handling**: for each entry in `e2e_gallery` where `is_new === true`, the
-specialist has already run `git add <committed_path>`. No additional user gate is needed.
-**Changed-baseline handling**: entries where `is_new === false` AND `baseline_diff_pct > threshold`
-are `visual_regression` — do NOT auto-accept; surface as blocking gate at Step 7.
-
-Persist `e2e_gallery` to `round.context.e2e_gallery` (additive alongside existing
-`round.context.e2e_outputs`). This field is consumed by TASK-3 / checkpoint-end for DB upload.
-Note: `e2e_gallery[]` is aggregated and persisted regardless of whether `cbp-frontend-ui` runs — the empty-gallery enforcement lives in `cbp-task-check` Phase 4, while the `screenshots[]` visual review (frontend-ui Phase 6.5) is a separate concern gated on `screenshots[]` being non-empty.
-
-When the aggregated `screenshots` 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 at Step 3.8.
+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'`.
 
-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; changed 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).
+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).
 
-**Skip** when `round.context.e2e_outputs` is absent/empty, the aggregated `screenshots` list
-is empty, or `testing_profile === 'claude_only'`.
+**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
 
@@ -225,7 +178,7 @@ Per-wave hard-fail signal — true when ANY hold:
 **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 MCP `update_round` / `update_standalone_round` per KIND; auto-trigger `/cbp-round-input`. STOP.
+- **Structural OR already re-triggered once OR e2e preflight aborts OR `e2e_eligible_skipped`** → save failure context via MCP `update_round`; auto-trigger `/cbp-round-input`. STOP.
 
 ## Inline execution fallback
 
@@ -237,11 +190,11 @@ When `cbp-testing-qa-agent` spawn fails OR the resolved `testing_profile` is `cl
 
 ### Step 7: Save Executor Output
 
-Update round context via MCP `update_round` / `update_standalone_round` per KIND:
+Update round context via MCP `update_round`:
 
-- `context`: { ...existing, executor_output, testing_qa_output, e2e_eligible, e2e_outputs, e2e_gallery, frontend_ui_review }
+- `context`: { ...existing, executor_output, testing_qa_output, e2e_eligible, e2e_outputs, frontend_ui_review }
 
-`e2e_outputs` (a framework-keyed map of specialist outputs, e.g. `{ playwright: {...}, maestro: {...} }`), `e2e_gallery` (aggregated flat array of committed-PNG entries across all specialists — consumed by TASK-3 / checkpoint-end for DB upload), and `frontend_ui_review` are present only when the gates above admitted them (≥1 eligible framework ran AND Step 5b ran). `e2e_eligible[]` records which frameworks were eligible this round and drives the Step 6 `e2e_eligible_skipped` check.
+`e2e_outputs` (a framework-keyed map of specialist outputs, e.g. `{ playwright: {...}, maestro: {...} }`) and `frontend_ui_review` are present only when the gates above admitted them (≥1 eligible framework ran AND Step 5b ran). `e2e_eligible[]` records which frameworks were eligible this round and drives the Step 6 `e2e_eligible_skipped` check.
 
 ### Step 8: Auto-trigger Round End
 
@@ -258,13 +211,13 @@ Trigger `/cbp-round-end`.
 - `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`)
-- Step 5b (cbp-frontend-ui Phase 6.5) runs only when e2e produced screenshots — gated on the aggregated `e2e_outputs[*].screenshots[]` being non-empty; `e2e_gallery[]` is always aggregated and persisted when any specialist ran
+- Step 5b (cbp-frontend-ui Phase 6.5) runs only when e2e produced screenshots — gated on the aggregated `e2e_outputs[*].screenshots[]` being non-empty
 - Claude NEVER git adds files in round commands
 
 ## Integration
 
-- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND)
-- **Writes**: MCP `update_round` / `update_standalone_round` (context with executor_output + testing_qa_output + e2e_eligible + e2e_outputs + e2e_gallery + frontend_ui_review) — per KIND
+- **Reads**: MCP `get_current_task`, `get_rounds`
+- **Writes**: MCP `update_round` (context with executor_output + testing_qa_output + e2e_eligible + e2e_outputs + frontend_ui_review)
 - **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-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)

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

@@ -58,7 +58,9 @@ Inline-fallback is NOT a quality downgrade trapdoor — Phase 1.5 row-by-row ver
 
 ### Step 0: Parse `$ARGUMENTS` shape
 
-Disambiguate the argument up front. Three input shapes (see `.claude/rules/notation-consistency.md` "CHK / TASK / ROUND Identifier Notation"):
+Disambiguate the argument up front. Three input shapes:
+
+### CHK / TASK / ROUND Identifier Notation Vocabulary
 
 | Shape | Regex | Meaning |
 |-------|-------|---------|

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

@@ -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 `.claude/rules/notation-consistency.md`):
+Parse the argument using the canonical chk-task-round notation (see `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
 
 | Shape | Regex | Resolves to |
 |-------|-------|-------------|

package/templates/skills/cbp-ship-configure/SKILL.md

@@ -62,7 +62,7 @@ References:
 **Supabase — branching integration** (run AFTER Step 5 — Verify completes for the
 supabase surface; do NOT invoke during Steps 1–4): once Step 5 has finished and
 `shipment.surfaces.supabase` is persisted, run
-`jq '.shipment.surfaces.supabase.branching_configured // empty' .codebyplan.json`.
+`jq '.shipment.surfaces.supabase.branching_configured // empty' .codebyplan/shipment.json`.
 If empty, invoke `/cbp-supabase-setup` (GitHub integration, required-status-check,
 persistent branch). Delegate fully — do NOT duplicate steps inline. If already set,
 note as already-done in the Step 6 report.

package/templates/skills/cbp-ship-configure/reference/supabase.md

@@ -174,11 +174,11 @@ project_id = "xyzwabcd"   # 8-char ref from `supabase --experimental branches li
 ```
 
 Replace `development` and `xyzwabcd` with the actual integration branch name and project
-ref for this repo (confirmed in `.codebyplan.json` `branch_config.integration`).
+ref for this repo (confirmed in `.codebyplan/git.json` `branch_config.integration`).
 
 ### Idempotency marker
 
-Written to `.codebyplan.json` after setup completes:
+Written to `.codebyplan/shipment.json` after setup completes:
 
 ```json
 {

package/templates/skills/cbp-ship-main/SKILL.md

@@ -54,6 +54,8 @@ Pass `--dry-run` through if the skill was invoked with a dry-run arg.
 
 Parse JSON from Step 3. Report `pr_url`, `merge_commit`, `branch_deleted`. If `checks_failed: true`, surface `checks_failure_reason` and stop.
 
+> **gh false-negative workaround.** `codebyplan ship` can report `checks_failed: true` when the underlying `gh` query reads a stale/mismatched check field (it queries `conclusion`/`state` and the GitHub API can lag). Before treating the stop as final, verify the real status: `gh pr checks <PR> --watch`. If every required check is green, merge manually with `gh pr merge <PR> --merge` — add `--admin` ONLY to escape a transient secondary-rate-limit loop, never to bypass a genuinely-failing gate. Never auto-merge silently on a `checks_failed` report; this verification is a manual decision.
+
 If `bumps[]` is present with any non-skipped entry, surface a **Version bumps** line per package — `<name>: <currentVersion> → <nextVersion>` — so the user sees what this PR will publish on merge.
 
 If `branch_deleted === true`, run a conditional Supabase preview-branch teardown for the feat branch that was just merged:

package/templates/skills/cbp-standalone-task-create/SKILL.md

@@ -17,7 +17,7 @@ Create a new standalone task — independent of any checkpoint. Gathers user con
 
 ## Identifier Notation
 
-Standalone tasks use a bare number (e.g. `45` = standalone TASK-45). There is no checkpoint segment. Canonical notation follows `.claude/rules/notation-consistency.md`.
+Standalone tasks use a bare number (e.g. `45` = standalone TASK-45). There is no checkpoint segment. Canonical notation follows `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary".
 
 ## Instructions
 

package/templates/skills/cbp-task-check/SKILL.md

@@ -35,7 +35,7 @@ Inline-fallback is NOT a quality downgrade trapdoor — every Phase from the age
 
 ### Step 1: Parse `$ARGUMENTS`
 
-Parse the argument using the canonical chk-task-round notation (see `.claude/rules/notation-consistency.md`):
+Parse the argument using the canonical chk-task-round notation (see `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
 
 | Shape | Regex | Resolves to |
 |-------|-------|-------------|

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

@@ -14,7 +14,7 @@ Complete the current task. Auto-triggered by `/cbp-task-testing` when all tests
 
 ### Step 1: Parse `$ARGUMENTS`
 
-Parse the argument using the canonical chk-task-round notation (see `.claude/rules/notation-consistency.md`):
+Parse the argument using the canonical chk-task-round notation (see `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
 
 | Shape | Regex | Resolves to |
 |-------|-------|-------------|

package/templates/skills/cbp-task-create/SKILL.md

@@ -17,7 +17,7 @@ Create a new task within the active checkpoint. Gathers user context, analyzes e
 
 ## Identifier Notation
 
-This skill operates on the **active** checkpoint resolved via MCP `get_current_task` and does not accept a positional identifier argument. The task it creates gets its `number` from the next-available slot within the active checkpoint (checkpoint-bound). Canonical chk-task-round notation — used in prose, error messages, and cross-references — follows `.claude/rules/notation-consistency.md` "CHK / TASK / ROUND Identifier Notation": `108-1` (CHK-108 TASK-1), `108-1-2` (round 2 of CHK-108 TASK-1).
+This skill operates on the **active** checkpoint resolved via MCP `get_current_task` and does not accept a positional identifier argument. The task it creates gets its `number` from the next-available slot within the active checkpoint (checkpoint-bound). Canonical chk-task-round notation — used in prose, error messages, and cross-references — follows `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary": `108-1` (CHK-108 TASK-1), `108-1-2` (round 2 of CHK-108 TASK-1).
 
 **Bare-number argument**: if a bare number (e.g. `42`) is provided with no checkpoint context, this skill cannot resolve it to a checkpoint-bound task:
 
@@ -61,6 +61,55 @@ Use MCP `get_tasks` for the checkpoint. Review:
 - Task statuses (completed, in_progress, pending)
 - Dependencies between tasks
 
+### Step 3.5: Immediate Issue Capture Contract
+
+#### Default to Current Scope
+
+Discovered issues MUST be captured. The default target is current scope (round → task → checkpoint); standalone tasks are RARE.
+
+#### How to Capture (top-down routing — use the first row that fits)
+
+| Situation | Action |
+|-----------|--------|
+| Trivial inline fix (≤5 min, mechanical, scope-clean) | Apply in the CURRENT round per `cbp-round-end` reference `findings-presentation.md` "Trivial-Resolution Exception" |
+| Related to the current task's domain | Create a new ROUND in the current task |
+| Fits the current checkpoint goal but is meaningfully separate | Create a new TASK in the current checkpoint via `create_task(checkpoint_id)` |
+| Large enough to need multiple tasks AND fits no current checkpoint | Create a NEW CHECKPOINT via `create_checkpoint` |
+| Genuinely orphan work — off-axis from all active checkpoints AND user has explicitly confirmed standalone | Create a STANDALONE task via `create_task(repo_id)` — rare |
+| Timed re-check waiting on upstream fix | Standalone task with `context.re_check_date` |
+
+Standalone routing requires explicit user confirmation — silence is NOT confirmation.
+
+#### Consolidation Before Creation (MANDATORY)
+
+Before calling `create_task` for a finding, run a two-step dedup + bundle check:
+
+**Step 1 — Dedup against pending standalone tasks:**
+
+```
+mcp__codebyplan__get_tasks(repo_id, standalone=true, status="pending")
+```
+
+Compare the proposed task to each pending standalone task on these match dimensions:
+
+| Match dimension | Action if matched |
+|-----------------|-------------------|
+| Same target file(s) | STOP — `update_task` to append, do not create new |
+| Same feature / module | STOP — `update_task` to append, do not create new |
+| Same root cause (e.g. "prettier drift", "router bug") | STOP — `update_task` to append, do not create new |
+| Same dependency / advisory | STOP — `update_task` to append, do not create new |
+
+If a match is found, surface it to the user before appending:
+
+```
+Found existing pending task TASK-[N]: [title]
+This finding overlaps on [dimension]. Append to TASK-[N] instead of creating new? (yes / no — create separately)
+```
+
+Default to append. Only create a separate task if the user explicitly says no, OR if the existing task is in_progress / completed (in which case use `context.related_task_ids[]` on the new task to cross-reference).
+
+**Step 2 — Bundle within the same agent invocation:** If a single agent run surfaces 2+ findings that share any match dimension, MERGE them into a SINGLE `create_task` call. Do NOT loop and create one task per finding.
+
 ### Step 4: Analyze Codebase Context
 
 Brief inline analysis:

package/templates/skills/cbp-task-start/SKILL.md

@@ -15,7 +15,7 @@ Start a task by loading context from the database and preparing for work.
 
 ### Step 1: Parse `$ARGUMENTS`
 
-Parse the argument using the canonical chk-task-round notation (see `.claude/rules/notation-consistency.md`):
+Parse the argument using the canonical chk-task-round notation (see `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
 
 | Shape | Regex | Resolves to |
 |-------|-------|-------------|
@@ -158,7 +158,7 @@ Skip this step if the task title and requirements contain no CVE ID (`CVE-YYYY-N
 1. Run `pnpm audit --json` from the monorepo root. If it fails (network, registry), surface the error and stop — do NOT start a CVE task without a clean snapshot.
 2. Parse the advisory list from the JSON output.
 3. Call MCP `get_tasks(repo_id)`; for each advisory, match by ID in task title/requirements.
-4. For every advisory with no matching open task, call MCP `create_task` per `immediate-issue-capture.md`.
+4. For every advisory with no matching open task, call MCP `create_task` per `cbp-task-create` Step 3.5 "Immediate Issue Capture Contract".
 5. Report the sweep result:
    ```
    ## CVE/GHSA Audit Sweep

package/templates/skills/cbp-task-testing/SKILL.md

@@ -25,7 +25,7 @@ Per-wave `testing-qa-agent` runs inside `/cbp-round-execute` Step 5. This skill
 
 ### Step 1: Parse `$ARGUMENTS`
 
-Parse the argument using the canonical chk-task-round notation (see `.claude/rules/notation-consistency.md`):
+Parse the argument using the canonical chk-task-round notation (see `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
 
 | Shape | Regex | Resolves to |
 |-------|-------|-------------|
@@ -170,7 +170,7 @@ For each finding, record: `{category, file, description, severity: 'low'|'medium
 
 Findings with severity `medium` or `high` feed the Step 9 problem classification. `low` findings are recorded in `task_testing_output` for the record but do not block.
 
-If any finding points to a need that exceeds task scope (e.g. a utility worth extracting for the wider codebase, a convention the repo should adopt globally), route per `immediate-issue-capture.md` "How to Capture" — default to a NEW TASK in the current checkpoint, not a standalone task. Standalone routing applies only when the finding is genuinely off-axis from every active checkpoint AND the user has confirmed standalone routing.
+If any finding points to a need that exceeds task scope (e.g. a utility worth extracting for the wider codebase, a convention the repo should adopt globally), route per `cbp-task-create` Step 3.5 "Immediate Issue Capture Contract — How to Capture" — default to a NEW TASK in the current checkpoint, not a standalone task. Standalone routing applies only when the finding is genuinely off-axis from every active checkpoint AND the user has confirmed standalone routing.
 
 ### Step 7: Separate Claude-Testable vs User-Testable
 

package/templates/skills/cbp-todo/SKILL.md

@@ -44,7 +44,7 @@ With `USER_ID` resolved, call MCP `get_todos({ repo_id, user_id, worktree_id })`
 
 - The head carries `command`, `instructions`, `state`, `metadata`, `worktree_id`, `checkpoint_id`, `task_id`.
 - The routing context (checkpoint/task) lives in **`rows[0].metadata`**.
-- `get_todos` is **pure-read** — `apps/todo-worker` is the sole regen authority. NEVER call `regenerate_todos_for_repo`.
+- `get_todos` is **pure-read** — `apps/todo-worker` is the sole regen authority. NEVER call `get_next_action` or `regenerate_todos_for_repo`.
 - Empty array, or `USER_ID` unavailable → go to Step 3 (empty-queue fallback).
 
 Queue `command` values may use the `/codebyplan:<name>` plugin-namespace form (e.g. `/codebyplan:round-start`); treat each as the matching `/cbp-<name>` skill for the Step 2 matrix.
@@ -76,6 +76,39 @@ Options:
 
 `<short-uuid>` = first 8 chars of the worktree UUID. Caller unresolved → render "this one" as `(unresolved / —)`. Name lookup miss → show the UUID alone. Wait for the user. NEVER propose reassigning the checkpoint to the caller worktree.
 
+### Step 1.55: Stale-Entity Guard
+
+Ownership passed (Step 1.5). Now guard against a lagging queue routing into already-finished work — the queue head (`rows[0]`) is produced by the todo-worker and can be stale (`health_check.todos_freshness_ok === false` is the signal), so a head command may target a checkpoint or task that was completed/cancelled since the queue was last regenerated. Reuse the `status` + task statuses already loaded in Step 1.5 — no extra reads, and NEVER call `get_next_action` or `regenerate_todos_for_repo` (an empty/stale queue is reconciled by the todo-worker, never re-derived here).
+
+Reject the auto-trigger when EITHER holds:
+
+- The target checkpoint's `status` is `completed` or `cancelled`.
+- Every task returned by `get_tasks(checkpoint_id)` (loaded in Step 1.5) has status `completed` or `cancelled` — no actionable task remains.
+
+On reject, surface the mismatch — naming the head command and the stale entity — then **STOP** (do not auto-trigger the head command). Use the variant matching the trigger condition:
+
+- Checkpoint itself `completed`/`cancelled`:
+
+```
+⚠ Stale queue head: <command> targets CHK-<NNN> which is <status>.
+The todo queue has not caught up. Options:
+  A) /cbp-todo — re-resolve the queue
+  B) /cbp-checkpoint-create — start new work
+  C) /cbp-session-end
+```
+
+- Checkpoint still active but every task `completed`/`cancelled`:
+
+```
+⚠ Stale queue head: <command> targets CHK-<NNN> — all tasks are completed/cancelled, no actionable work remains.
+The todo queue has not caught up. Options:
+  A) /cbp-todo — re-resolve the queue
+  B) /cbp-checkpoint-create — start new work
+  C) /cbp-session-end
+```
+
+Skip this gate when the routing target has no checkpoint (idle — see Step 3) or the command is `/cbp-session-start`.
+
 ### Step 1.6: Checkpoint Planning Gate
 
 Ownership passed (Step 1.5). Now gate on the checkpoint's planning + activation state — reusing the `plan` + `status` + task count loaded in Step 1.5 — so work never starts on a half-baked or un-activated checkpoint. Evaluate two rules in order (Rule A wins if both could match):
@@ -154,11 +187,11 @@ Wait for the user. Do not auto-trigger `/cbp-session-end` — session wrap-up is
 
 ### Step 4: Display and Auto-trigger
 
-Reached only when the Step 1.5 ownership gate allowed routing to continue and the Step 1.6 planning gate fell through (no hand-off). Show `rows[0].instructions` (so the user sees what is happening), then auto-trigger `rows[0].command` (its `/cbp-<name>` form).
+Reached only when the Step 1.5 ownership gate allowed routing to continue, the Step 1.55 stale-entity guard did not reject, and the Step 1.6 planning gate fell through (no hand-off). Show `rows[0].instructions` (so the user sees what is happening), then auto-trigger `rows[0].command` (its `/cbp-<name>` form).
 
 ## Integration
 
 - **Called by**: `/cbp-session-start`, `/cbp-task-complete`, `/cbp-checkpoint-complete`, manual, after `/clear`
 - **Resolves**: `npx codebyplan resolve-worktree --json` (worktree id + distress signal), `npx codebyplan whoami --json` (user id)
 - **Reads**: MCP `get_todos`, `get_current_task`, `get_rounds`, `get_checkpoints`, `get_tasks`, `get_worktrees`
-- **Triggers**: `rows[0].command` (auto, after the Step 1.5 ownership gate); Step 1.6 overrides to `/cbp-checkpoint-plan` (unplanned) or `/cbp-checkpoint-start` (planned-but-pending)
+- **Triggers**: `rows[0].command` (auto, after the Step 1.5 ownership gate and Step 1.55 stale-entity guard pass, and the Step 1.6 planning gate falls through); Step 1.55 overrides to STOP (stale completed/cancelled entity); Step 1.6 overrides to `/cbp-checkpoint-plan` (unplanned) or `/cbp-checkpoint-start` (planned-but-pending)

package/templates/skills/cbp-todo/qa-regression.md

@@ -12,8 +12,9 @@ Repo under test: `2ff6d405-39c5-47b8-a6d1-59f998ac0537`. Resolve a real `user_id
 
 ## Preconditions
 
-- `get_todos` is the only Step 1 read — confirm no `regenerate_todos_for_repo` call remains (`grep -n 'regenerate_todos_for_repo' SKILL.md` → no hits).
+- `get_todos` is the only Step 1 read — confirm no `get_next_action` / `regenerate_todos_for_repo` call remains (`grep -n 'get_next_action\|regenerate_todos_for_repo' SKILL.md` → no hits).
 - Step 0 uses `resolve-worktree --json` and `whoami --json`.
+- Step 1.55 (Stale-Entity Guard) must NOT call `get_next_action` or `regenerate_todos_for_repo` when rejecting a stale head — it reuses the checkpoint `status` + task statuses already loaded in Step 1.5 (the same grep above covers it).
 
 ## Scenario A — caller owns the work → auto-trigger
 
@@ -40,6 +41,12 @@ Repo under test: `2ff6d405-39c5-47b8-a6d1-59f998ac0537`. Resolve a real `user_id
 2. Step 3 fallback: `get_current_task({ repo_id, worktree_id })` / `get_checkpoints({ repo_id, worktree_id, status: 'active' })` surface a checkpoint whose `worktree_id` differs from the caller.
 3. **Expected**: the Step 1.5 ownership gate (applied to the fallback target) blocks the discovered work with the same "Work mismatch" message. NO auto-trigger. `regenerate_todos_for_repo` is never called.
 
+## Scenario D — stale queue head for a completed/cancelled entity → halt
+
+1. Caller owns the active checkpoint (Scenario A ownership holds), but the todo-worker queue is lagging — `health_check.todos_freshness_ok === false`. The `get_todos` head targets a checkpoint (or task) that has since been completed or cancelled.
+2. Step 1.5 loads the target checkpoint `status` + `get_tasks(checkpoint_id)` (already required for the ownership/planning gates — no extra reads).
+3. **Expected**: Step 1.55 rejects the auto-trigger — target checkpoint `status` is `completed`/`cancelled` (or every task is `completed`/`cancelled`) — surfaces the "Stale queue head" message naming the command + `CHK-NNN`[ `TASK-N`] + status, and STOPS. NO auto-trigger. NO `get_next_action` / `regenerate_todos_for_repo` call.
+
 ## Edge — both null
 
 Caller `WORKTREE_ID` empty AND target checkpoint `worktree_id` `null` → legitimate main-repo / unassigned work → auto-trigger allowed.