codebyplan 1.13.24 → 1.13.26

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codebyplan",
-  "version": "1.13.24",
+  "version": "1.13.26",
   "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/settings.project.base.json

@@ -188,6 +188,8 @@
       "Bash(npx codebyplan tech-stack:*)",
       "Bash(codebyplan eslint:*)",
       "Bash(npx codebyplan eslint:*)",
+      "Bash(codebyplan lsp:*)",
+      "Bash(npx codebyplan lsp:*)",
       "Bash(codebyplan round:*)",
       "Bash(npx codebyplan round:*)",
       "Bash(codebyplan help:*)",

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 |
 |-------|-------|-------------|