codebyplan 1.13.28 → 1.13.29

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.28";
+    VERSION = "1.13.29";
     PACKAGE_NAME = "codebyplan";
   }
 });

package/package.json

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

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

@@ -279,6 +279,6 @@ Return findings sorted by severity (critical first). If no findings, return `sta
 ## Integration
 
 - **Spawned by**: `/cbp-round-end` (Step 6)
-- **Returns to**: `/cbp-round-end` which presents findings to user
+- **Returns to**: `/cbp-round-end` which auto-applies in-scope findings inline and routes out-of-scope findings to `/cbp-round-update`
 - **Does NOT**: Apply any changes
 - **Reads**: Changed files, task requirements, round context

package/templates/agents/cbp-task-check.md

@@ -9,7 +9,7 @@ effort: xhigh
 
 # Task Check Agent
 
-AI-driven production readiness review with user satisfaction discussion. Verifies all task requirements are met, checkpoint goals are aligned, and work is production-ready.
+AI-driven production readiness review with user satisfaction discussion. This is the **cross-round double-check** layer: per-round QA (build/lint/types per app, the `console.log`/debug scan, the OWASP/secret grep, API auth-enforcement curls, `pnpm audit`) already ran inside each round's `testing-qa-agent` — this agent does NOT re-run it. Its unique value is holistic: verifying all task requirements are met, checkpoint goals are aligned, the aggregated work is shippable, and — for tasks that span many rounds where scope can shift as new ideas/problems surface — detecting scope drift that should update the checkpoint or task rather than re-running per-round checks.
 
 **Numeric-claim verification (Proposal P6)**: when round summaries assert numeric facts (file counts, package counts, percentage changes, line counts, version numbers), verify each via direct count: `find ... | wc -l`, `grep -c`, `wc -l <file>`. Do NOT accept narrative numbers without a verification command. Mismatches between asserted and actual counts indicate documentation drift; flag as a finding requiring a fix.
 
@@ -95,14 +95,16 @@ Check `task.files_changed`:
 - List unapproved files
 - Determine if unapproved files block completion
 
-### Phase 6: Code Review
+### Phase 6: Code Review (holistic spot-check)
 
-Read ALL changed files and verify:
-- No obvious bugs or regressions
-- No security issues (hardcoded secrets, SQL injection, XSS)
-- No leftover debug code (console.log, TODO from this task)
-- Error handling present where needed
-- Consistent with existing codebase patterns
+Per-round QA already ran the line-level checks — the `console.log`/debug scan (round `testing-qa-agent` Phase 3.5), the OWASP secret/injection grep (Phase 5), the API auth-enforcement curl (Phase 3.55), and `pnpm audit` (Phase 3.7). Do NOT re-run them here. Phase 6 is a light holistic spot-check across the aggregated diff for what a single round cannot see:
+
+- No obvious bugs or regressions that emerge only when all rounds' changes are read together
+- No cross-round integration gaps (a field/contract introduced in one round that a later round broke)
+- Error handling present where needed at the feature boundary
+- Consistent with existing codebase patterns across the full task diff
+
+If the aggregated diff surfaces an obvious issue per-round QA missed, flag it as a finding — but the per-round scans are authoritative for line-level concerns.
 
 ### Phase 7: Shippable Feature Gate
 
@@ -125,6 +127,8 @@ Update `round_outcome_analysis` with findings.
 
 ### Phase 9: User Satisfaction Discussion
 
+For tasks that ran many rounds, scope drift accumulates quietly — each round may have absorbed a new idea or problem without the checkpoint/task requirements being updated. The satisfaction discussion is where that drift surfaces; treat the scope-divergence scan below as a first-class output, not an afterthought.
+
 Present findings to user via AskUserQuestion:
 
 ```

package/templates/hooks/cbp-mcp-round-sync.sh

@@ -5,6 +5,15 @@
 #          staging-status flip, and web-UI flag sync to the codebyplan CLI.
 #          Replaces the inline jq merge + curl PATCH with a single CLI call.
 #
+# Trigger context (CHK-197): complete_round is now called by /cbp-round-complete
+# (the permission-gated finalizer), which already runs `sync-approvals` once
+# BEFORE completing the round. This hook firing afterward is the expected
+# post-complete safety net — it catches approval drift between that pre-complete
+# sync and the approval_locked write; it is NOT a duplicate run to remove.
+# NOTE: this hook matches complete_round only; complete_standalone_round is NOT
+# covered, so standalone rounds rely solely on /cbp-round-complete's pre-complete
+# sync (pre-existing coverage gap, documented here intentionally — not fixed).
+#
 # Delegates to: npx codebyplan round sync-approvals
 #   - Git-diff drift merge (in/not-in DB vs git)
 #   - Staging-status → user_approved flip

package/templates/settings.project.base.json

@@ -55,7 +55,8 @@
       "Skill(cbp-checkpoint-create)",
       "Skill(cbp-checkpoint-check)",
       "Skill(cbp-checkpoint-complete)",
-      "Skill(cbp-round-update)",
+      "Skill(cbp-round-complete)",
+      "Skill(cbp-round-execute)",
       "Skill(cbp-session-end)",
       "Skill(cbp-task-complete)",
       "Skill(cbp-standalone-task-create)",
@@ -114,9 +115,9 @@
       "Skill(cbp-refresh-infra)",
       "Skill(cbp-round-check)",
       "Skill(cbp-round-end)",
-      "Skill(cbp-round-execute)",
       "Skill(cbp-round-input)",
       "Skill(cbp-round-start)",
+      "Skill(cbp-round-update)",
       "Skill(cbp-session-start)",
       "Skill(cbp-setup-e2e)",
       "Skill(cbp-setup-eslint)",

package/templates/skills/cbp-build-cc-mode/SKILL.md

@@ -31,19 +31,20 @@ Fifteen of the 16 authoring agents take the default (`cbp-cc-executor`, `cbp-dat
 
 | skill             | model  | effort | reason                                                                                                            |
 | ----------------- | ------ | ------ | ----------------------------------------------------------------------------------------------------------------- |
-| cbp-round-end         | sonnet | high   | Spawns cbp-improve-round agent; skill body summarises + presents user findings-decision — lighter than xhigh suffices |
+| cbp-round-end         | sonnet | high   | Spawns cbp-improve-round agent; auto-applies in-scope findings + routes out-of-scope to round-update — lighter than xhigh suffices |
 | cbp-task-check        | sonnet | high   | Thin orchestrator over spawned cbp-task-check agent; inline-fallback path keeps Opus for safety                       |
 | cbp-checkpoint-update | sonnet | high   | Status updates + context patches mostly; lighter than xhigh                                                       |
 | cbp-ship-main         | sonnet | high   | Production-impacting PR creation; keep Opus reasoning but drop effort                                             |
 | cbp-merge-main        | sonnet | high   | Long-lived-branch integration merge — surgical conflict resolution, no authoring                                  |
 
-### Haiku-low skills (9)
+### Haiku-low skills (10)
 
 `model: haiku` + `effort: low`. Pure mechanical / dispatch / templated work.
 
 | skill                  | model | effort | reason                                                                                   |
 | ---------------------- | ----- | ------ | ---------------------------------------------------------------------------------------- |
-| cbp-round-update           | haiku | low    | Pure mechanical: read git status, check approvals, route per rules                       |
+| cbp-round-update           | haiku | low    | Pure mechanical: triage round state (claude_approved/findings/hard_fail), route to round-complete or round-input |
+| cbp-round-complete         | haiku | low    | Pure mechanical: sync-approvals git-add reconcile, complete round, route per unapproved count |
 | cbp-round-check            | haiku | low    | Run build/lint/types commands, parse output, update QA                                   |
 | cbp-todo                   | haiku | low    | Dispatch: single MCP call + route to next command                                        |
 | cbp-checkpoint-complete    | haiku | low    | Pure finalization — mark completed, write summary; judgment happened in checkpoint-check |

package/templates/skills/cbp-build-cc-settings/reference/cbp-permission-policy.md

@@ -22,7 +22,7 @@ Precedence is `deny > ask > allow`; arrays union across scopes (managed/user/pro
 
 ### `allow` — the autonomous workflow surface
 
-- **Non-lifecycle, non-shipment `/cbp-*` skills** — authoring (`cbp-build-cc-*`), frontend (`cbp-frontend-*`), git (`cbp-git-*`, `cbp-merge-main`, `cbp-refresh-infra`), round work (`cbp-round-check`/`-end`/`-execute`/`-input`/`-start`), setup/configure (`cbp-setup-*`, `cbp-ship-configure`, `cbp-supabase-*`), task prep (`cbp-task-check`/`-create`/`-start`/`-testing`, `cbp-standalone-task-check`/`-testing`), planning (`cbp-checkpoint-plan`/`-update`), plus `cbp-session-start` and `cbp-todo`. Invoking a skill is the intended mode of operation; the gated side effects happen inside via the Bash/MCP tools the skill calls, which carry their own tiering. The lifecycle/state-transition skills are the exception — they live in `ask` (next section).
+- **Non-lifecycle, non-shipment `/cbp-*` skills** — authoring (`cbp-build-cc-*`), frontend (`cbp-frontend-*`), git (`cbp-git-*`, `cbp-merge-main`, `cbp-refresh-infra`), round work (`cbp-round-check`/`-end`/`-input`/`-start`/`-update` — `cbp-round-update` is autonomous triage that only reads round state and routes to `cbp-round-complete` or `cbp-round-input`, so it runs without a prompt), setup/configure (`cbp-setup-*`, `cbp-ship-configure`, `cbp-supabase-*`), task prep (`cbp-task-check`/`-create`/`-start`/`-testing`, `cbp-standalone-task-check`/`-testing`), planning (`cbp-checkpoint-plan`/`-update`), plus `cbp-session-start` and `cbp-todo`. Invoking a skill is the intended mode of operation; the gated side effects happen inside via the Bash/MCP tools the skill calls, which carry their own tiering. The lifecycle/state-transition and plan-approval skills are the exception — they live in `ask` (next section).
 - **All `mcp__codebyplan__*` reads** (`get_*`, `list_*`, `search_*`, `health_check`, `lookup_symbol`, `resolve_library_id`, `get_chunk`).
 - **Routine workflow-write MCP tools** the pipeline calls many times per task: create/update/complete checkpoint, task, and round; session log + session-state writes; `create_worktree`, `add_library`, `flag_stale_chunk`, `update_server_config`, `update_eslint_repo_config`, `update_task_template`. Gating these with `ask` would make the autonomous workflow unusable.
 - **Read/safe CLI commands** (both `codebyplan X` and `npx codebyplan X`): `whoami`, `resolve-worktree`, `statusline`, `ports`, `tech-stack`, `eslint`, `round`, `help`, `--version`.
@@ -30,7 +30,8 @@ Precedence is `deny > ask > allow`; arrays union across scopes (managed/user/pro
 ### `ask` — the deliberate confirm-gate
 
 - **Production-shipment skills**: `cbp-ship`, `cbp-ship-main`, `cbp-checkpoint-end` — these promote/deploy to production, so they prompt even in an otherwise auto-allowed setup.
-- **Lifecycle / state-transition skills**: `cbp-checkpoint-start`, `cbp-checkpoint-create`, `cbp-checkpoint-check`, `cbp-checkpoint-complete`, `cbp-round-update`, `cbp-session-end`, `cbp-task-complete`, `cbp-standalone-task-create`, `cbp-standalone-task-start`, `cbp-standalone-task-complete` — these open or close checkpoints, tasks, rounds, and sessions (advancing workflow state in the database), so they stop for explicit confirmation rather than running autonomously.
+- **Lifecycle / state-transition skills**: `cbp-checkpoint-start`, `cbp-checkpoint-create`, `cbp-checkpoint-check`, `cbp-checkpoint-complete`, `cbp-round-complete`, `cbp-session-end`, `cbp-task-complete`, `cbp-standalone-task-create`, `cbp-standalone-task-start`, `cbp-standalone-task-complete` — these open or close checkpoints, tasks, rounds, and sessions (advancing workflow state in the database), so they stop for explicit confirmation rather than running autonomously. `cbp-round-complete` is the permission-gated round finalizer (reconciles the user's `git add`s, completes the round, routes onward); its `ask` prompt replaces the in-skill confirmation that used to live in `cbp-round-update` — which is now an autonomous, `allow`-tier triage step.
+- **Plan-approval gate**: `cbp-round-execute` — the round plan is approved by confirming this `ask` prompt rather than via an in-skill AskUserQuestion. `cbp-round-start` runs its planning Q&A, then hands off to `cbp-round-execute`; the permission prompt is the user's go/no-go on the plan.
 - **Destructive / admin MCP tools**: `delete_session_log`, `delete_worktree`, `create_repo`, `release_assignment`. (The launch and member-admin tools were dropped from the MCP surface in CHK-180 — those concerns are web-app only now.)
 - **Mutating / external / clobber-risk CLI commands** (both prefixes): `setup`, `login`, `logout`, `upgrade-auth`, `config` (can overwrite committed `.codebyplan/` files), `branch` (rewrites branch config), `ship`, `claude` (`install`/`update`/`uninstall` overwrite `.claude/`).
 

package/templates/skills/cbp-build-cc-skill/reference/cbp-quality.md

@@ -88,7 +88,7 @@ A skill should do one thing in the pipeline. If a skill both plans AND executes,
 If the skill is part of a chain, show it:
 
 ```
-/cbp-round-start (planning) → [user approval] → /cbp-round-execute (auto)
+/cbp-round-start (planning) → /cbp-round-execute (ask-tier permission = plan approval)
 ```
 
 ### Approval Gates

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

@@ -42,7 +42,7 @@ Triggered by `/cbp-task-start` (Step 3.6, optional stale-check), `/cbp-task-comp
      - **Cancel** — abort the skill.
    - `unstaged_dirty=false AND staged_present=true` → print one informational line and proceed to Step 1:
      `Staged changes detected — proceeding with merge.`
-     (Pre-staged files will be included in the merge commit at Step 2 — this is intentional; the caller already approved them via /cbp-round-update.)
+     (Pre-staged files will be included in the merge commit at Step 2 — this is intentional; the caller already approved them via /cbp-round-complete.)
    - `unstaged_dirty=false AND staged_present=false` → proceed silently to Step 1.
    - Either `git diff` command exits with code ≥ 2 (git hard error — not-a-repo, detached HEAD with no commits, index lock, corrupt object store): surface the raw error output and STOP. Do NOT proceed to Step 1.
 

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

@@ -0,0 +1,164 @@
+---
+scope: org-shared
+name: cbp-round-complete
+description: Reconcile user git-add approvals, complete the round, and route to the next step
+argument-hint: [chk-task-round | task-round]
+triggers: [cbp-task-check, cbp-standalone-task-check, cbp-round-input]
+effort: low
+---
+
+## 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)` |
+| 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 |
+
+# Round Complete Command
+
+The **permission-gated finalizer** for a round that `/cbp-round-update` triaged as clean. It reconciles which files the **user** approved via `git add`, completes the round, and routes to the next step.
+
+This skill is gated by an `ask`-tier `Skill(cbp-round-complete)` permission rule in `settings.json`. **The permission prompt IS the user confirmation** — there is NO AskUserQuestion inside this skill. If the user declines the permission, the skill does not run: nothing is synced, no round is completed, and the user can stage files and re-invoke (directly or by re-running `/cbp-round-update`) when ready.
+
+## HARD GATE — Every Step Must Execute
+
+Step 2 (sync-approvals CLI) MUST exit 0. If it fails, do NOT proceed to Step 3. Before completing the round, verify:
+
+- [ ] `codebyplan round sync-approvals` exited 0
+
+If this is false: DO NOT proceed to Step 3.
+
+## Instructions
+
+### Step 1: Parse `$ARGUMENTS`
+
+Parse the argument using the canonical chk-task-round notation (see `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary"):
+
+| Shape | Regex | Resolves to |
+|-------|-------|-------------|
+| `{chk}-{task}-{round}` (e.g. `108-1-2`) | `^[0-9]+-[0-9]+-[0-9]+$` | Checkpoint-bound: CHK-{chk} TASK-{task} ROUND-{round} |
+| `{task}-{round}` (e.g. `45-2`) | `^[0-9]+-[0-9]+$` | Standalone: standalone TASK-{task} ROUND-{round} |
+| _(empty)_ | — | Use Kind Detection to find active task and latest round |
+
+Anything else is malformed — surface this error and stop:
+
+```
+round-complete: invalid argument `{value}`. Expected:
+  108-1-2  → CHK-108 TASK-1 ROUND-2 (checkpoint-bound)
+  45-2     → standalone TASK-45 ROUND-2
+  (empty)  → active task and latest round
+```
+
+Note that `108-1` is **valid** here — it resolves to standalone TASK-108 ROUND-1 per the 2-segment task-round form. To target a checkpoint-bound round, use the 3-segment form `108-1-2`.
+
+### Step 1.5: Get Current Task and Round
+
+Given the parse from Step 1:
+
+| Parse | Resolution path |
+|-------|-----------------|
+| `{chk}-{task}-{round}` | MCP `get_checkpoints(repo_id)` → filter `number === {chk}`. MCP `get_tasks(checkpoint_id)` → filter `number === {task}`. MCP `get_rounds(task_id)` → filter `number === {round}`. |
+| `{task}-{round}` | MCP `get_standalone_rounds` via `get_current_standalone_task` or direct task lookup → filter `number === {round}`. |
+| _(empty)_ | Use Kind Detection: checkpoint KIND → MCP `get_current_task(repo_id)` + `get_rounds(task_id)`; standalone KIND → MCP `get_current_standalone_task(repo_id)` + `get_standalone_rounds(standalone_task_id)`. |
+
+If no task found: `No active task. Nothing to complete.`
+
+### Step 2: Sync git diff + approvals via CLI
+
+Reconcile which files the user has approved by staging them. Run:
+
+```
+npx codebyplan round sync-approvals --round-id <round_id> --task-id <task_id>
+```
+
+The CLI auto-resolves the caller worktree id with the following precedence:
+1. `--caller-worktree-id <uuid>` override (if passed — skips all resolution)
+2. Per-device branch-keyed cache (`.codebyplan/worktree.local.json`)
+3. In-process tuple API call: `POST /worktrees/resolve` using `(device_id, repo_path, branch)`
+
+On the write path (non `--dry-run`), if the worktree id cannot be resolved the CLI **hard-fails with exit 1** and prints an actionable message. To pre-populate the cache:
+
+```
+npx codebyplan resolve-worktree --cache
+```
+
+If this worktree is not yet registered, run `npx codebyplan setup` first, then re-run `/cbp-round-complete`.
+
+The CLI parses `git status --short`, merges drift + staging + web-UI flag, and writes both round and task (forwarding `caller_worktree_id` on both writes so the server honors the feat-worktree lock). A **cleanly staged** file (`git add`-ed, no further unstaged changes) becomes `user_approved: true`.
+
+Read the stdout JSON: `{ added, stale_marked, reactivated, total_files }`.
+
+If the command exits non-zero, surface the stderr and STOP. Do NOT proceed to Step 3.
+
+This is the **single** explicit reconcile owned by this skill. (The `cbp-mcp-round-sync.sh` PostToolUse hook fires again right after Step 3's `complete_round` — see the note below — but that is the existing post-complete safety net, not a duplicate run to schedule here.)
+
+### Step 3: Complete the Round
+
+Calculate duration from the round's `started_at` to now in minutes.
+
+- **checkpoint KIND**: MCP `complete_round(round_id, duration_minutes)`.
+- **standalone KIND**: MCP `complete_standalone_round(standalone_round_id, duration_minutes, caller_worktree_id)`. ⚠️ `caller_worktree_id` is REQUIRED — resolve via `CALLER_WT=$(npx codebyplan resolve-worktree 2>/dev/null)`. If `CALLER_WT` is empty, surface this warning and ask the user to confirm before proceeding:
+
+  ```
+  Warning: could not resolve caller_worktree_id (npx codebyplan resolve-worktree returned empty).
+  The complete_standalone_round call may be rejected by the pre-guard. Proceed anyway? (yes / no)
+  ```
+
+  If the user confirms yes, proceed with `caller_worktree_id: ""`. If no, stop.
+
+`complete_round` / `complete_standalone_round` sets the round `completed`, locks all `file_changes` for the round (`approval_locked: true`), and returns `unapproved_files[]` + `unapproved_count`. Hold those for routing.
+
+> **PostToolUse hook note**: completing the round fires the `cbp-mcp-round-sync.sh` PostToolUse hook (matcher `mcp__codebyplan__complete_round`), which runs `sync-approvals` once more as a post-complete safety net for any approval drift between Step 2 and the lock. This is **expected** and is not double-processing — Step 2 is the pre-complete reconcile that makes `unapproved_count` accurate for routing; the hook is the existing catch-up. Note the hook matches `complete_round` only — `complete_standalone_round` is **not** covered by it (a pre-existing gap), so standalone rounds rely solely on this skill's Step 2 reconcile.
+
+### Step 4: Route
+
+**4a — Count files** — Display: `"Round N complete — Files: X total, Y approved, Z pending"`.
+
+**4b — Route on `unapproved_count`** (from Step 3's `complete_round` response):
+
+- **`unapproved_count === 0`** (every file user-approved): the user has signed off on the whole round.
+  - checkpoint KIND → auto-trigger `/cbp-task-check`.
+  - standalone KIND → auto-trigger `/cbp-standalone-task-check`.
+- **`unapproved_count > 0`** (user withheld approval on some files): the unstaged files are the signal that more work is wanted on them. Auto-trigger `/cbp-round-input` — its Step 2 deep analysis reads exactly those `user_approved === false` files and formulates the next round's requirements. This route is **independent of how many files are staged**; round-input is reachable even when zero files were staged.
+
+  - **Degenerate auto-loop guard**: if the just-completed round had `round.context.auto_loop_mode === true` AND it was a clean exit (no `improve_round_findings[]`, no hard-fail — which is why `/cbp-round-update` triaged it to round-complete in the first place), do NOT auto-trigger `/cbp-round-input`. Its auto-loop path transcribes the prior round's findings verbatim, and a clean round has none — auto-triggering would spin on an empty input. Instead surface the clean-exit note below and STOP; the user stages the pending files and re-invokes (or runs `/cbp-round-input` manually). Persist `round.context.round_complete.degenerate_auto_loop_exit = true`.
+
+    ```
+    ## Round N Complete — Auto-loop finished clean
+
+    **Files**: X total, Y approved, Z pending
+
+    Pending files passed all checks; they are just not staged. Stage them
+    (`git add <path>`) to finish the task, or run /cbp-round-input to start
+    another round.
+    ```
+
+Persist a breadcrumb on the round via `update_round` / `update_standalone_round` per KIND: `round.context.round_complete = { staged_count, unstaged_count, route, decided_at }`.
+
+## Key Rules
+
+- **Permission prompt = confirmation** — gated by `ask`-tier `Skill(cbp-round-complete)`. NEVER add an AskUserQuestion to confirm running; the harness prompt is the gate. A declined permission is a clean no-op.
+- **Step 2 (CLI) must exit 0** — if it fails, STOP before `complete_round`. The merge semantics are enforced by the CLI.
+- **NEVER ask the user to git add files** — Step 2 only reads staging status. **NEVER stage files** — Claude does not touch the git staging area; the user's `git add` is the approval signal.
+- **standalone KIND Step 3**: `caller_worktree_id` is REQUIRED for `complete_standalone_round` — always resolve and pass it.
+- **Auto-triggered by `/cbp-round-update`** (clean triage), or run manually by the user.
+
+## Integration
+
+- **Gates**: `ask`-tier `Skill(cbp-round-complete)` permission prompt — the harness confirms before the skill runs; a decline makes NO writes. There is no in-skill AskUserQuestion.
+- **Triggered by**: `/cbp-round-update` (auto, clean triage), or user manually
+- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND); delegates git+approval sync to `npx codebyplan round sync-approvals`
+- **Writes**: MCP `complete_round` / `complete_standalone_round` (per KIND); `update_round` / `update_standalone_round` (`round_complete` breadcrumb); round+task `files_changed` written by the CLI
+- **Triggers**: `/cbp-task-check` (checkpoint KIND, all files approved), `/cbp-standalone-task-check` (standalone KIND, all files approved), `/cbp-round-input` (some files unapproved — fires independent of staging count)

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

@@ -16,7 +16,7 @@ See `reference/inline-fallback.md` for full trigger table, procedure, and covera
 ## Pipeline
 
 ```
-/cbp-round-execute → /cbp-round-end → [code review + user decisions] → /cbp-round-update
+/cbp-round-execute → /cbp-round-end → [code review + auto-apply in-scope] → /cbp-round-update
 ```
 
 ## Identifier Notation
@@ -126,9 +126,13 @@ Wait for agent to complete. If the spawn fails for any reason, apply the inline-
 
 **If `status: 'no_findings'`:** show `### Code Review\nNo issues found. Code looks good.` and skip to Step 8.
 
-**If findings exist**, present them grouped by severity (table + per-finding details), then ask the user via AskUserQuestion which to fix: `all`, `1,2` (specific numbers), `none`, or `inline` (only when all findings qualify under the Trivial-Resolution Exception).
+**If findings exist**, present them grouped by severity (table + per-finding details).
 
-Example tables and the `inline` option gating spec: see `reference/findings-presentation.md`.
+**Under `auto_loop_mode === true`**: do NOT auto-apply here — Step 8's auto-loop path accepts all findings into `improve_round_findings[]` and defers the fixes to the next loop round. Skip straight to Step 8.
+
+**Manual mode**: **auto-apply all in-scope findings inline**. A finding is *in-scope* when every file it references is within the round's `files_changed[]`. The round-end orchestrator (main context — it has Edit/Write) applies these fixes directly; the `cbp-improve-round` agent stays read-only/advisory and never writes. Record each applied fix in `round.context.inline_fix_log` (findings indices, rationale, `fixes[]`, applied_at). After applying, re-run the verification scoped to the modified files (hook syntax check for `.sh`; `cbp-testing-qa-agent` for code) per `reference/findings-presentation.md`; if it fails, do NOT record the fix — treat the finding as out-of-scope instead. Findings that reference files OUTSIDE `files_changed[]` are **out-of-scope** — do NOT apply them; save them to `improve_round_findings[]` so Step 8 routes them to `/cbp-round-input` or a new task. There is no findings-decision AskUserQuestion — the round was already approved at the `/cbp-round-execute` permission prompt. The baseline-regression gate above is the ONLY user decision in this step.
+
+Example tables and the in-scope/out-of-scope classification: see `reference/findings-presentation.md`.
 
 ### Step 8: Route Based on Decisions
 
@@ -136,33 +140,31 @@ 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.
+- Skip Step 7's inline auto-apply (findings are deferred to the next loop round, not applied this round).
 - 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).
+- Auto-trigger `/cbp-round-update` immediately. round-update triages the round and either routes to `/cbp-round-input` (spawn another round) or `/cbp-round-complete` (clean exit) — see cbp-round-update SKILL.md Step 2/3.
 
 **Else (manual mode — flag absent or false):**
 
-Run the existing flow:
+Step 7 already auto-applied in-scope findings and logged them to `round.context.inline_fix_log`. Now record any out-of-scope findings and route:
 
-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`:
+1. **Polish-spiral stop-gate** (round 2+ only): if this is round 2 or later AND the prior round also ended with code-review fixes, surface a one-line stop-gate via AskUserQuestion — *defer remaining polish to a follow-up task* vs *continue with another round*. This is a genuine user decision about scope (it guards against endless low-value polish loops), not a flow-control prompt. Skip on round 1.
+2. Save out-of-scope findings (those NOT auto-applied in Step 7) to round context via MCP `update_round`:
    ```json
    {
      "context": {
-       "improve_round_findings": [accepted findings],
-       "improve_round_rejected": [rejected findings with user reasons]
+       "improve_round_findings": [out-of-scope findings]
      }
    }
    ```
-4. Auto-trigger `/cbp-round-update`. round-update will see unapproved files and route to `/cbp-round-input`; `/cbp-round-input` picks up the findings from round context and includes them in the new round's requirements automatically.
+3. Auto-trigger `/cbp-round-update`. round-update triages the round: if out-of-scope findings (or a hard-fail) remain it routes to `/cbp-round-input` (which picks up the findings from round context and includes them in the new round's requirements automatically); if the round is clean it routes to `/cbp-round-complete` (the permission-gated finalizer that reconciles the user's `git add`s and completes the round).
 
 ## Key Rules
 
-- Claude NEVER git adds files — user does code review
+- Claude NEVER git adds files — user approval is via git staging at `/cbp-round-complete`
 - Auto-triggers `/cbp-round-update` after findings are handled
 - `/cbp-round-end` is auto-triggered by `/cbp-round-execute` (user does not call it directly)
-- Findings are **presented for user decision** — never auto-fix without user consent
+- In-scope findings are **auto-applied inline** by the round-end orchestrator (the round was already approved at the `/cbp-round-execute` permission); out-of-scope findings route to `/cbp-round-input`. `cbp-improve-round` stays read-only/advisory. Baseline-regression accept (Step 7 gate) stays a user decision — baselines are NEVER auto-accepted.
 
 ## Integration
 

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

@@ -1,6 +1,6 @@
 # Findings Presentation in `/cbp-round-end` Step 7
 
-When `improve-round` returns findings, Step 7 presents them grouped by severity and asks the user how to proceed.
+When `improve-round` returns findings, Step 7 presents them grouped by severity, then **auto-applies in-scope findings inline** (manual mode) or defers them to the next loop round (auto-loop mode). There is no findings-decision prompt.
 
 ## Example output
 
@@ -22,26 +22,16 @@ When `improve-round` returns findings, Step 7 presents them grouped by severity
 [description + suggested fix from agent]
 ```
 
-## AskUserQuestion options
+## Auto-apply model (manual mode)
 
-```
-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 the Trivial-Resolution Exception below)
-- Or explain why specific findings are not issues
-```
-
-## "inline" option gating
+Step 7 auto-applies all **in-scope** findings inline — no user prompt. A finding is *in-scope* when every file it references is within the round's `files_changed[]`; it is *out-of-scope* otherwise.
 
-Only present the "inline" option when ALL pending findings simultaneously qualify under the **Trivial-Resolution Exception** (see subsection below):
+- **In-scope** → the round-end orchestrator (main context, has Edit/Write) applies the fix directly via `Edit` / `Write`, re-runs the verification commands (hook syntax check + `cbp-testing-qa-agent` scoped to modified files), and records it in `round.context.inline_fix_log = { findings: [ids], rationale, fixes: [...], applied_at: <ISO> }`. The `cbp-improve-round` agent stays read-only/advisory and never writes.
+- **Out-of-scope** → saved to `round.context.improve_round_findings[]`; Step 8 routes them to `/cbp-round-input` (next round) or a new task per the Infra Issue Absorption Contract 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
+The only user decision in Step 7 is the **baseline-regression accept** gate (baselines are NEVER auto-accepted). Under `auto_loop_mode`, Step 7 does not auto-apply — all findings are accepted into `improve_round_findings[]` and deferred to the next loop round.
 
-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).
+The **Trivial-Resolution Exception** below still governs the deeper bypass cases (skipping executor / testing-qa / improve-round for ≤5-line non-logic corrective rounds); it is referenced by `/cbp-round-execute` and `/cbp-task-testing` for infra-issue absorption.
 
 ---
 

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

@@ -15,6 +15,10 @@ Execution and validation phase. Receives the approved plan from `/cbp-round-star
 /cbp-round-start → /cbp-round-execute → /cbp-round-end (auto)
 ```
 
+## Approval Model
+
+The `ask`-tier `Skill(cbp-round-execute)` permission prompt (configured in `settings.json`) is the **plan-approval gate** handed off from `/cbp-round-start`: confirming the permission approves the plan; declining it returns control to `/cbp-round-start` (re-plan with feedback) or `/cbp-round-input` (wrong direction). Once execution begins, the executors (`cbp-round-executor`, `cbp-mechanical-edits`) and the 3-INLINE / 3-SURVEY paths apply edits **automatically** — there is NO in-skill AskUserQuestion for approval. The only downstream user decisions are genuine ones: the dev-server start prompt (Step 4) and the baseline-regression accept gate (`/cbp-round-end` Step 7).
+
 ## Identifier Notation
 
 This skill operates on the **active** task/round resolved via MCP `get_current_task` / `get_rounds` and does not accept a positional identifier argument. Canonical chk-task-round notation is defined in `cbp-round-start` Step 0 "CHK / TASK / ROUND Identifier Notation Vocabulary".

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

@@ -24,7 +24,6 @@ Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
 | 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 Input Command
@@ -33,7 +32,7 @@ Gathers input for a new round. Performs deep analysis of unapproved files, requi
 
 ## When Used
 
-- After `/cbp-round-update` routes here (unapproved files)
+- After `/cbp-round-update` triages a round as not-clean and routes here, or `/cbp-round-complete` routes here (files left unapproved after completing the round)
 - After `/cbp-round-execute` Step 6 routes here (structural failure or retry-exhausted hard-fail)
 - After `/clear` + `/cbp-todo` reloads context and triggers this
 - When user wants to start a new round with specific changes
@@ -78,8 +77,9 @@ If the argument matches the numeric regex, resolve the target task/round from DB
 **2f:** Extract testing-qa failures from latest round context (`context.testing_qa_output`)
 
 **2g:** Extract code review findings from latest round context (`context.improve_round_findings`).
-These are user-accepted findings from `improve-round` agent — bugs, logic errors, edge cases
-that the user agreed should be fixed. Include them as high-priority requirements.
+These are out-of-scope findings from the `improve-round` agent — bugs, logic errors, edge cases
+that round-end could not auto-apply inline (they reference files outside the prior round's
+`files_changed[]`). Include them as high-priority requirements.
 
 **2h:** Identify root causes — not "file X is wrong" but "requirement Y was not met because Z"
 
@@ -175,12 +175,12 @@ If this command is triggered **directly** (not via `/cbp-todo`) and no context i
 - **Deep analysis is MANDATORY** — always runs, even if arguments provided (for context)
 - **Analysis reads from DB (MCP)**, not conversation history
 - **Follow-up rounds get same depth as round 1** — no quick-fix behavior
-- **Never ask to git add** — file approval is handled by `/cbp-round-update`
+- **Never ask to git add** — user file approval (git staging) is reconciled by `/cbp-round-complete`
 - **Update all context locations** — task, checkpoint, and round should all have consistent information
 
 ## Integration
 
-- **Triggered by**: `/cbp-round-update` (auto, unapproved files), `/cbp-round-execute` (auto, on hard-fail after retry exhausted), `/cbp-todo` (after /clear), user manually
+- **Triggered by**: `/cbp-round-update` (auto, not-clean triage), `/cbp-round-complete` (auto, files left unapproved after completing the round), `/cbp-round-execute` (auto, on hard-fail after retry exhausted), `/cbp-todo` (after /clear), user manually
 - **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND), file contents (Read tool)
 - **Writes**: MCP `update_task` / `update_standalone_task` (context), `update_checkpoint` (context, if checkpoint KIND and needed)
 - **Triggers**: `/cbp-round-start` (auto)

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

@@ -30,7 +30,7 @@ Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
 
 # Round Start Command
 
-Planning phase for a new round. Analyzes context, creates plan, gets user approval. NO execution or testing — those are separate commands.
+Planning phase for a new round. Analyzes context, creates a plan, then auto-triggers `/cbp-round-execute` — the `ask`-tier permission prompt on that skill IS the user's plan approval. NO execution or testing — those are separate commands.
 
 ## Inline-Fallback for Planner Spawn Failure
 
@@ -42,17 +42,17 @@ Procedure summary (pointer back to canonical):
 2. Walk the planner's documented Phase 0-8 checklist inline using `Read` / `Grep` / `Bash` / MCP `get_*` — `agents/cbp-task-planner.md` is the inline script. Phase 1.5 (Requirement Premise Verification) and Phase 4.7 (Migration Shape-Distribution Pre-Flight) are MANDATORY in fallback mode — these are the gates the agent uniquely enforces; skipping them produces unverified plans.
 3. Populate the planner's output contract (`approved_plan` shape: `files_to_modify[]`, `deliverables`, `specialist_needs`, `round_type`, `shape_distribution` if applicable, `context_summary`) with `mode: 'inline_fallback'`.
 4. Apply the pre-emptive-skip rule: when the same failure class fired in the previous spawn of this session, skip the spawn attempt entirely and go straight to inline.
-5. Continue the skill — do NOT abort. The plan still requires user approval at Step 9.
+5. Continue the skill — do NOT abort. Step 9 auto-triggers `/cbp-round-execute`; the `ask`-tier permission prompt on that skill is the user's plan approval (see Step 8).
 
 Inline-fallback is NOT a quality downgrade trapdoor — Phase 1.5 row-by-row verification is mandatory. A fallback plan that skipped premise verification is a regression caught by the next session's cbp-improve-round.
 
 ## Pipeline
 
 ```
-/cbp-round-start (planning) → [user approval] → /cbp-round-execute (auto)
+/cbp-round-start (planning) → /cbp-round-execute (ask-tier permission = plan approval)
 ```
 
-**Auto-loop mode**: when `round.context.auto_loop_mode === true` flows in from `/cbp-round-input`, Step 6 (Q&A) and Step 8 (user approval) skip user prompts. See cbp-round-update SKILL.md Step 4 (auto-loop decision) and cbp-round-end SKILL.md Step 8 for the full contract.
+**Auto-loop mode**: when `round.context.auto_loop_mode === true` flows in from `/cbp-round-input`, Step 6 (Q&A) is skipped and Step 8's `/cbp-round-execute` permission is auto-approved. See cbp-round-update SKILL.md Step 3b (auto-loop decision) and cbp-round-end SKILL.md Step 8 for the full contract.
 
 ## Instructions
 
@@ -176,7 +176,7 @@ input:
 
 Wait for planner output.
 
-### Step 8: User Approval
+### Step 8: Present Plan
 
 Present the plan to user:
 
@@ -208,24 +208,21 @@ Present the plan to user:
 
 Single-wave plans present the existing flat plan view (no wave table) — backward compatible.
 
-**If `auto_loop_mode === true`**: skip the AskUserQuestion below; auto-approve the plan. Log `round.context.plan_approval = { mode: "auto_loop", auto_approved_at: <ISO> }`. Surface a one-line note in the chat output: `"Auto-approved under auto_loop_mode (round N of cap C)"` so the user can see the loop is active. Proceed to Step 9.
+**Plan approval is the `ask`-tier `Skill(cbp-round-execute)` permission prompt** — there is NO approve/needs-changes/wrong AskUserQuestion here. After presenting the plan, proceed to Step 9, which auto-triggers `/cbp-round-execute`; the harness then shows the `ask`-tier permission prompt, and confirming it IS the user's go-ahead on the plan.
 
-**Else (manual mode)**, ask user via AskUserQuestion with explicit options:
+**Denied-execute handling** — if the user declines the `/cbp-round-execute` permission, the plan does not run. Treat the decline as "the plan must change":
 
-1. **Yes** — approve and start execution
-2. **No — needs changes** — user provides feedback, revise the plan (re-run Step 7 with feedback)
-3. **No — totally wrong** — discard plan, return to `/cbp-round-input` for new requirements
+- **Minor changes**: collect the user's feedback, re-spawn `cbp-task-planner` with it as a constraint (re-run Step 7), present the revised plan, and re-trigger `/cbp-round-execute`.
+- **Wrong direction**: save the rejection reason to round context and auto-trigger `/cbp-round-input` for new requirements.
 
-**If "Yes"**: proceed to Step 9.
-**If "Needs changes"**: collect user feedback, re-spawn `cbp-task-planner` with feedback as constraint, present revised plan, ask again.
-**If "Totally wrong"**: save rejection reason to round context, auto-trigger `/cbp-round-input`.
+**If `auto_loop_mode === true`**: the loop auto-approves — log `round.context.plan_approval = { mode: "auto_loop", auto_approved_at: <ISO> }`, surface a one-line note `"Auto-approved under auto_loop_mode (round N of cap C)"`, and proceed to Step 9 (the `/cbp-round-execute` permission is auto-approved under the loop).
 
 ### Step 9: Auto-trigger Round Execute
 
-On approval, save planner output to round context via MCP `update_round` / `update_standalone_round` per KIND, then trigger `/cbp-round-execute`.
+Save planner output to round context via MCP `update_round` / `update_standalone_round` per KIND, then trigger `/cbp-round-execute`. The `ask`-tier permission prompt on `/cbp-round-execute` is the user's plan approval (see Step 8).
 
 ```
-Plan approved. Starting execution phase...
+Starting execution phase...
 ```
 
 ## Key Rules

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

@@ -1,9 +1,9 @@
 ---
 scope: org-shared
 name: cbp-round-update
-description: Check file approvals, complete round, and route to next step
+description: Triage a finished round (Claude-only) and route to round-complete or round-input
 argument-hint: [chk-task-round | task-round]
-triggers: [cbp-round-input, cbp-task-check, cbp-standalone-task-check]
+triggers: [cbp-round-complete, cbp-round-input]
 effort: low
 ---
 
@@ -17,28 +17,24 @@ Inspect the resolved identifier from argument parsing to determine the task kind
 | `{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:
+Set `KIND` for the rest of this skill. round-update is **read + triage only** — it reads round state and routes; it never completes the round or writes file approvals. MCP read/audit 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, ...)` |
+| Update round (audit only) | `update_round(round_id, ...)` | `update_standalone_round(standalone_round_id, ...)` |
 
-# Round Update Command
-
-Checks file approval status, completes the round, and routes to next step. NEVER asks the user to git add or stage anything — it only reads current state.
+The completion + file-approval reconcile (`sync-approvals`, `complete_round` / `complete_standalone_round`) now lives in `/cbp-round-complete`.
 
-## HARD GATE — Every Step Must Execute
+# Round Update Command
 
-Step 2 (sync-approvals CLI) MUST exit 0. If it fails, do NOT proceed to Step 3. Before completing the round, verify:
+**Claude-only, autonomous triage.** round-update inspects a finished round's automated state — which files Claude approved (`claude_approved`), whether testing-QA hard-failed, and whether `improve-round` left outstanding findings — and routes to exactly one next step. It makes **no writes** beyond an audit breadcrumb and **never prompts the user**: it is auto-triggered by `/cbp-round-end` and runs without a confirmation gate. The user-facing confirmation has moved to `/cbp-round-complete` (an `ask`-tier permission prompt). round-update NEVER reads or touches git staging — user approval is reconciled later by `/cbp-round-complete`.
 
-- [ ] `codebyplan round sync-approvals` exited 0
+## Routing in one line
 
-If this is false: DO NOT proceed to Step 3.
+- **Round is clean** → trigger `/cbp-round-complete` (the permission-gated finalizer reconciles your `git add`s and completes the round).
+- **Round needs more work** → trigger `/cbp-round-input` (more changes / planning).
 
 ## Instructions
 
@@ -82,147 +78,39 @@ Given the parse from Step 1:
 
 If no task found: `No active task. Nothing to update.`
 
-### Step 1.6: Permission Gate
-
-Step 1 (parse) and Step 1.5 (resolve task + round) are read-only. Step 2 onward mutates state — the `sync-approvals` CLI write, `complete_round`, and the auto-trigger of the next step. Before any of that, confirm the user wants this skill to run.
-
-This gate fires on **every** invocation — manual, auto-triggered by `/cbp-round-end`, and on every iteration of the Step 4 auto-loop. There is no bypass. It sits **before** and is independent of the top-of-file HARD GATE (which governs Step 2's exit code, not user consent), and it is distinct from the Branch A clean-exit route choice in Step 5 (that one picks where to go next; this one authorizes running at all).
-
-Ask via AskUserQuestion, naming the resolved round and disclosing the actions:
-
-> Update ROUND-{N} of TASK-{M}?
-> This will sync the git diff + file approvals, complete the round, and route to the next step (which may auto-start a new round).
->
-> - **Proceed** — run the skill
-> - **Cancel** — do nothing
-
-- **Proceed** → continue to Step 2.
-- **Cancel** → abort cleanly: make NO writes (no `sync-approvals`, no `complete_round`, no auto-trigger) and exit with one line: `Cancelled by user — ROUND-{N} not updated.`
-
-### Step 2: Sync git diff + approvals via CLI
-
-Run:
-
-```
-npx codebyplan round sync-approvals --round-id <round_id> --task-id <task_id>
-```
-
-The CLI auto-resolves the caller worktree id with the following precedence:
-1. `--caller-worktree-id <uuid>` override (if passed — skips all resolution)
-2. Per-device branch-keyed cache (`.codebyplan/worktree.local.json`)
-3. In-process tuple API call: `POST /worktrees/resolve` using `(device_id, repo_path, branch)`
-
-On the write path (non `--dry-run`), if the worktree id cannot be resolved the CLI **hard-fails with exit 1** and prints an actionable message. To pre-populate the cache:
-
-```
-npx codebyplan resolve-worktree --cache
-```
-
-If this worktree is not yet registered, run `npx codebyplan setup` first, then re-run `/cbp-round-update`.
-
-The CLI parses `git status --short`, merges drift + staging + web-UI flag, and writes both round and task (forwarding `caller_worktree_id` on both writes so the server honors the feat-worktree lock).
-
-Read the stdout JSON: `{ added, stale_marked, reactivated, total_files }`.
-
-If the command exits non-zero, surface the stderr and STOP. Do NOT proceed to Step 3.
-
-### Step 3: Complete Round
-
-Calculate duration from `started_at` to now in minutes.
-
-- **checkpoint KIND**: MCP `complete_round(round_id, duration_minutes)`.
-- **standalone KIND**: MCP `complete_standalone_round(standalone_round_id, duration_minutes, caller_worktree_id)`. ⚠️ `caller_worktree_id` is REQUIRED — resolve via `CALLER_WT=$(npx codebyplan resolve-worktree 2>/dev/null)`. If `CALLER_WT` is empty, surface this warning and ask user to confirm before proceeding:
-
-  ```
-  Warning: could not resolve caller_worktree_id (npx codebyplan resolve-worktree returned empty).
-  The complete_standalone_round call may be rejected by the pre-guard. Proceed anyway? (yes / no)
-  ```
+This step is **read-only**. There is no permission gate — round-update is autonomous (see the Key Rules below).
 
-  If user confirms yes, proceed with `caller_worktree_id: ""`. If no, stop.
+### Step 2: Triage the Round
 
-### Step 4: Auto-Loop Decision
+Read the latest round's context: `round.context.testing_qa_output.totals.hard_fail`, `round.context.improve_round_findings[]`, `round.context.round_type`, and `round.files_changed[]` (each entry's `claude_approved`). Compute a single `clean` verdict:
 
-Read the latest round's `improve_round_findings[]` and `testing_qa_output.totals.hard_fail`. If EITHER is non-clean (findings non-empty OR `hard_fail === true`), the auto-loop must spawn the next round automatically.
+- **Survey round** (`round.context.round_type === 'survey'`): no file diff exists, so QA/approval predicates do not apply. `clean = improve_round_findings[]` is empty.
+- **Normal round**: `clean = (every file in files_changed[] has claude_approved === true) AND testing_qa_output.totals.hard_fail === false AND improve_round_findings[]` is empty.
 
-Procedure:
+Display a one-line triage summary, e.g. `"ROUND-N triage: clean"` or `"ROUND-N triage: N findings / hard_fail=true → needs another round"`. round-update reads `claude_approved` only — it does **not** read git staging or `user_approved`; those belong to `/cbp-round-complete`.
 
-1. Compute `next_index = (round.context.auto_loop_index ?? 0) + 1`.
-2. **If `next_index > (round.context.auto_loop_cap ?? 5)`**: surface the cap-exhausted prompt via AskUserQuestion (options: extend cap, stop loop / drop into round-input, close task as-is). Persist `round.context.auto_loop_cap_exhausted = { user_choice, decided_at }` and route per choice.
-3. **Otherwise**: persist `round.context.auto_loop_decision = { spawned_next: true, next_index, decided_at }` on the CURRENT round via `update_round` / `update_standalone_round` per KIND (audit trail), then auto-trigger `/cbp-round-input` with NO AskUserQuestion. Pass `auto_loop_mode: true`, `auto_loop_index: next_index`, `auto_loop_cap: (prior cap ?? 5)` forward — round-start Step 4 persists them on the new round.
+### Step 3: Route
 
-> **Permission-gate note**: the "NO AskUserQuestion" in item 3 governs only the auto-loop's decision to spawn `/cbp-round-input` — it does not add a prompt for that hand-off. It is NOT a bypass of the Step 1.6 permission gate: when the spawned round eventually re-enters `/cbp-round-update`, Step 1.6 prompts again (the gate always fires, including inside the auto-loop).
-
-If BOTH signals are clean, fall through to Step 5 (exit routing).
-
-### Step 5: Exit Routing
-
-**5a: Count files** — Display: `"Files: X total, Y approved, Z pending"`
-
-**5b: Route with four branches** (Step 4 already handled the dirty-loop case; Step 5 is the clean-exit path).
-
-**Branch D — IF `round.context.round_type === 'survey'` (checked FIRST):**
-
-Survey rounds produce no file diff; A/B/C predicates assume `files_changed[]` non-empty. Survey routing is decided by `improve_round_findings[]` instead:
-
-- `improve_round_findings[]` non-empty → auto-trigger `/cbp-round-input`
-- `improve_round_findings[]` empty → checkpoint KIND: auto-trigger `/cbp-task-check`; standalone KIND: auto-trigger `/cbp-standalone-task-check`
-
-Output: `"## Round [N] Complete — Survey Round"` with duration, files=0, findings count, routing message. Skip Branches A/B/C.
-
-**Branch A — ELSE IF all files have `user_approved: true`:**
-
-```
-## Round [N] Complete - All Files Approved
-
-**Duration**: [N] minutes
-**Files**: [X] total, [X] approved, 0 pending
-```
-
-Surface AskUserQuestion (clean-exit user-gate):
-
-- **(a) close & complete round** → checkpoint KIND: auto-trigger `/cbp-task-check`; standalone KIND: auto-trigger `/cbp-standalone-task-check`
-- **(b) start new round** → auto-trigger `/cbp-round-input`
-
-Persist `round.context.auto_loop_exit = { staged_count, unstaged_count, route, decided_at }`.
-
-**Branch B — ELSE IF unapproved files exist AND every unapproved file has `claude_approved: true` AND `testing_qa_output.totals.hard_fail: false` AND no `improve_round_findings[]`:**
-
-The clean-but-unstaged staging-gate case. Mode-dependent:
-
-- **Auto-loop exit** (the completed round had `auto_loop_mode === true` on its context AND Step 4 fell through here with BOTH signals clean): surface the Branch A clean-exit user-gate — do NOT auto-trigger `/cbp-round-input`. Branch B's entry condition already requires `no improve_round_findings[]`, so the auto-loop's verbatim-from-findings procedure has no input to formulate requirements from; auto-triggering round-input would loop on an empty input. Persist `round.context.auto_loop_exit.degenerate_empty_findings: true` (degenerate sub-case: no findings to feed round-input, so surface the clean-exit user-gate above instead of auto-triggering).
-- **Manual round**: emit staging-gate prompt and STOP. User stages files (never-git-add rule) and re-invokes; command then falls into Branch A.
-
-Manual-mode prompt:
-
-```
-## Round [N] Complete — Files Pending Staging
-
-**Files**: [X] total, [Y] approved, [Z] pending
-
-### Pending (passed all checks; not yet staged):
-- [path]
-
-Stage them (`git add <path>`) and re-run `/cbp-round-update` to proceed.
-Waiting for user to stage files.
-```
+**3a — Clean → `/cbp-round-complete`.** Auto-trigger `/cbp-round-complete`. round-complete is `ask`-tier: the harness shows a permission prompt (the user's confirmation to finalize the round). round-complete then reconciles the user's `git add`s, completes the round, and routes onward (all files staged → task-check; some withheld → round-input). round-update writes nothing here beyond the Step 2 summary. In `auto_loop_mode`, a clean triage is the loop's success exit — the loop continues only via the not-clean path in 3b; round-complete owns the degenerate clean-but-unstaged guard.
 
-**Branch C — ELSE (unapproved AND outstanding findings or `claude_approved: false`):**
+**3b — Not clean → `/cbp-round-input`.** More changes or planning are needed. Routing is **independent of git staging** — round-input is reachable whether or not the user has staged anything (it performs its own deep analysis of the unapproved files). Two sub-cases:
 
-Unreachable in the auto-loop path — Step 4 catches it first. Retained for MANUAL invocation. Output `## Round [N] Complete - [Z] Files Pending` with file counts and list of unapproved paths; auto-trigger `/cbp-round-input`.
+- **Auto-loop** (`round.context.auto_loop_mode === true`): compute `next_index = (round.context.auto_loop_index ?? 0) + 1`.
+  - If `next_index > (round.context.auto_loop_cap ?? 5)`: surface the cap-exhausted prompt via AskUserQuestion (a genuine multi-option user decision — keep it). Options: extend cap, stop loop / drop into round-input, close task as-is. Persist `round.context.auto_loop_cap_exhausted = { user_choice, decided_at }` and route per choice.
+  - Otherwise: persist `round.context.auto_loop_decision = { spawned_next: true, next_index, decided_at }` on the current round via `update_round` / `update_standalone_round` (audit trail), then auto-trigger `/cbp-round-input` with NO prompt. Pass `auto_loop_mode: true`, `auto_loop_index: next_index`, `auto_loop_cap: (prior cap ?? 5)` forward — round-start Step 4 persists them on the new round.
+- **Manual round**: auto-trigger `/cbp-round-input` directly (no prompt).
 
 ## Key Rules
 
-- **Step 1.6 permission gate fires first** — every invocation (incl. auto-trigger and the Step 4 auto-loop) asks the user to confirm before any write; **Cancel** is a clean abort (no `sync-approvals`, no `complete_round`, no auto-trigger).
-- **Step 2 (CLI) must exit 0** — if it fails, STOP. The merge semantics are enforced by the CLI.
-- **Step 4 owns the dirty-loop case**; Step 5 owns the clean-exit case. Step 5 Branch C is for manual invocation only.
-- **NEVER ask user to git add files** — only reads staging status. **NEVER stage files** — Claude does not touch git staging area.
-- Auto-triggered by `/cbp-round-end`, or run manually by user.
-- **standalone KIND Step 3**: `caller_worktree_id` is REQUIRED for `complete_standalone_round` — always resolve and pass it.
+- **Autonomous + Claude-only** — round-update never prompts before running. It is auto-triggered by `/cbp-round-end`. The confirmation step is `/cbp-round-complete`'s `ask`-tier permission prompt, not an AskUserQuestion here. (The auto-loop cap-exhausted AskUserQuestion in Step 3b is a genuine user decision, not a run gate.)
+- **Triage, never finalize** — round-update does NOT call `sync-approvals`, `complete_round`, or `complete_standalone_round`, and does NOT write file approvals. All of that is `/cbp-round-complete`.
+- **Never touches git** — round-update reads `claude_approved` from the DB only; it never reads staging, asks the user to `git add`, or stages files.
+- **git-add independence** — the "needs more work" route to `/cbp-round-input` fires regardless of whether files are staged. There is no clean-but-unstaged dead-end.
+- **standalone parity** — KIND detection governs which read/audit tools are used; the clean→`/cbp-round-complete` and not-clean→`/cbp-round-input` routing is identical for both KINDs (round-complete and round-input self-detect KIND).
 
 ## Integration
 
-- **Gates**: Step 1.6 permission gate — asks the user to confirm before any side effect; **Cancel** aborts cleanly with no writes. Fires on every invocation incl. the Step 4 auto-loop; sits before and independent of the top-of-file Step 2 hard gate.
 - **Triggered by**: `/cbp-round-end` (auto), or user manually
-- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND); delegates git+approval sync to `npx codebyplan round sync-approvals`
-- **Writes**: MCP `update_round` / `update_standalone_round` (auto_loop_decision / auto_loop_exit / auto_loop_cap_exhausted); `complete_round` / `complete_standalone_round` (per KIND); round+task files_changed written by CLI
-- **Triggers**: `/cbp-round-input` (Step 4 dirty-loop spawn; Branch A 'b' choice; Branch B auto-loop-exit; Branch C manual), `/cbp-task-check` (Branch A 'a' choice per checkpoint KIND; Branch D survey-clean per checkpoint KIND), `/cbp-standalone-task-check` (Branch A 'a' choice per standalone KIND; Branch D survey-clean per standalone KIND), staging-gate stop (Branch B manual mode), cap-exhausted prompt routes from Step 4 (any of the three options)
+- **Reads**: MCP `get_current_task` / `get_current_standalone_task`, `get_rounds` / `get_standalone_rounds` (per KIND); round context (`testing_qa_output`, `improve_round_findings`, `round_type`, `files_changed[].claude_approved`)
+- **Writes**: MCP `update_round` / `update_standalone_round` — audit only (`auto_loop_decision` / `auto_loop_cap_exhausted`). No completion, no file-approval writes.
+- **Triggers**: `/cbp-round-complete` (clean triage — `ask`-tier permission prompt is the user confirmation), `/cbp-round-input` (not-clean triage: outstanding findings, hard-fail, or unapproved Claude checks — fires independent of git staging; also the auto-loop dirty spawn), cap-exhausted prompt routes from Step 3b (any of the three options)

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

@@ -17,7 +17,7 @@ If the `cbp-task-check` agent spawn fails for any reason, follow the canonical i
 
 ## When Used
 
-- After all rounds complete and all files approved (auto-triggered by `/cbp-round-update`)
+- After all rounds complete and all files approved (auto-triggered by `/cbp-round-complete`)
 - Before `/cbp-standalone-task-testing`
 - Never skippable
 
@@ -149,4 +149,4 @@ Suggest: Approve files, then re-run `/cbp-standalone-task-check {task}`. Stop
 - **Reads**: MCP `get_current_standalone_task`, `get_standalone_tasks`, `get_standalone_rounds`, all changed files (via agent)
 - **Writes**: MCP `update_standalone_task` (context.check_verdict)
 - **Triggers**: emits directive `Next: /clear, then /cbp-standalone-task-testing {task}` on READY + satisfied
-- **Triggered by**: `/cbp-round-update` (auto, when all files approved)
+- **Triggered by**: `/cbp-round-complete` (auto, when all files approved)

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

@@ -10,6 +10,8 @@ effort: xhigh
 
 Complete a standalone task. Auto-triggered by `/cbp-standalone-task-testing` when all tests pass. Can also be run manually.
 
+This skill is gated by an `ask`-tier `Skill(cbp-standalone-task-complete)` permission rule in `settings.json` (shipped templates). **The permission prompt IS the user confirmation** — there is NO completion-confirmation AskUserQuestion inside this skill (the Step 7.5 `caller_worktree_id` guard is a separate environmental safety prompt, not a flow-control confirmation). A declined permission is a clean no-op (nothing committed, merged, pushed, or completed).
+
 ## Instructions
 
 ### Step 1: Parse `$ARGUMENTS`
@@ -84,9 +86,7 @@ Load `task.qa` and `task.files_changed`:
 1. **QA**: count items by status (pass / fail / pending / skipped). If any item has status `fail` or `pending`, warn the user.
 2. **Files**: list any file with `user_approved === false` and warn.
 
-**If issues exist**, AskUserQuestion: `Complete anyway` / `Run QA first` / `Cancel`. On `Run QA first` or `Cancel`, stop. On `Complete anyway`, continue.
-
-**If no issues**, AskUserQuestion to confirm: `Ready to complete standalone TASK-[N]: [title] — [N] rounds, [N] files. Proceed?`
+If any QA item is `fail`/`pending` or any file is unapproved, **surface the warnings in the output and continue** — record them for the Step 9 summary. There is NO confirmation AskUserQuestion here: `Skill(cbp-standalone-task-complete)` is `ask`-tier, so the harness permission prompt that gated this skill IS the user's confirmation to complete. The hard gates in Steps 2–2.6 (all rounds completed, ≥1 round has `testing_qa_output`, `check_verdict` READY, `task_testing_output.all_passed`) already block completion when prerequisites are unmet; these QA / file-approval items are warnings, not blockers.
 
 ### Step 4: Aggregate Files Changed
 
@@ -169,6 +169,7 @@ Apply the `cleanup` skill inline to remove orphan references to deleted/modified
 **Files**: [N] changed
 **Commit**: [hash]
 **Branch merged**: [feat-branch] → {PRODUCTION}
+**Warnings**: [any QA / file-approval warnings from Step 3, or "none"]
 ```
 
 #### Route (single directive — never a menu)

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

@@ -9,7 +9,7 @@ effort: xhigh
 
 # Standalone Task Testing Command
 
-Comprehensive task-level testing for standalone tasks — runs all automated tests and walks the user through manual testing one-by-one. Tests the entire delivered feature holistically after all rounds are complete. Runs inline — no sub-agent.
+Comprehensive task-level testing for standalone tasks — the **cross-round double-check** run once after all rounds complete. Per-round QA (per-app build/lint/types, the `console.log`/debug scan, the OWASP/secret grep, `pnpm audit`) is owned by each round's `testing-qa-agent`; this skill does NOT re-run it. It tests the entire delivered feature holistically across the full task diff — catching cross-package and cross-round problems no single round can see. Runs inline — no sub-agent.
 
 ## When Used
 
@@ -19,7 +19,7 @@ Comprehensive task-level testing for standalone tasks — runs all automated tes
 
 ## Scope vs Round-Level Validation
 
-Per-wave `testing-qa-agent` runs inside `/cbp-round-execute` Step 5. This skill adds the cross-cutting layer visible only across the full task diff: full-repo lint, workspace tsc, full test suite, `pnpm audit`, and full-diff security scan.
+Per-wave `testing-qa-agent` runs inside `/cbp-round-execute` Step 5 and **owns per-round QA**: per-app build/lint/types, the `console.log`/debug scan, the OWASP/secret full-diff grep, and `pnpm audit`. This skill does NOT repeat them. It adds only the cross-round layer invisible within a single round: workspace-wide lint, workspace tsc, and the full test suite (which catch cross-package breakage), plus the cross-round code review (Step 6.5) and the user manual walkthrough (Step 8).
 
 ## Instructions
 
@@ -93,9 +93,9 @@ Capture stdout and stderr for each check.
 | Full-repo lint | `pnpm -w lint` | Always |
 | Full-repo types | `pnpm exec tsc --noEmit` | Source files changed |
 | Full-repo unit tests | `pnpm test --run` | Source files in aggregated_files |
-| Full-repo audit | `pnpm audit` | Always |
 | Per-package E2E | `pnpm --filter <pkg> e2e:test` | UI files in aggregated_files |
-| Full-diff security scan | inline grep or `security-agent` | Always |
+
+These are the workspace-wide / cross-package checks only — per-app build/lint/types, the `console.log`/debug scan, the OWASP/secret grep, and `pnpm audit` already ran per-round inside `testing-qa-agent` and are NOT repeated here.
 
 **Soft tests** (report, don't block):
 

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

@@ -9,7 +9,7 @@ effort: high
 
 # Task Check Command
 
-AI-driven production readiness review. Spawns the `cbp-task-check` agent for thorough verification including user satisfaction discussion. This command is a thin orchestrator — the agent does the heavy lifting.
+AI-driven production readiness review. Spawns the `cbp-task-check` agent for thorough verification including user satisfaction discussion. This command is a thin orchestrator — the agent does the heavy lifting. It is the **cross-round double-check**: rounds already own per-round QA (debug scan, security grep, audit, per-app build/lint/types), so this layer focuses on holistic concerns visible only across the full task diff — requirements traceability, checkpoint alignment, shippability, holistic code review, and scope drift — never re-running per-round checks.
 
 ## Inline-Fallback for Spawn Failure
 
@@ -27,7 +27,7 @@ Inline-fallback is NOT a quality downgrade trapdoor — every Phase from the age
 
 ## When Used
 
-- After all rounds complete and all files approved (auto-triggered by `/cbp-round-update`)
+- After all rounds complete and all files approved (auto-triggered by `/cbp-round-complete`)
 - Before `/cbp-task-testing`
 - `/cbp-task-check` is NEVER skippable
 
@@ -163,4 +163,4 @@ Suggest: Approve files, then re-run `/cbp-task-check`. **STOP HERE** — wait fo
 - **Reads**: MCP `get_current_task`, `get_rounds`, all changed files (via agent)
 - **Writes**: MCP `update_task` (context.check_verdict)
 - **Triggers**: emits directive `Next: /clear, then /cbp-task-testing {chk-task}` on READY + satisfied (cross-context — testing is heavyweight, fresh context helps)
-- **Triggered by**: `/cbp-round-update` (auto, when all files approved)
+- **Triggered by**: `/cbp-round-complete` (auto, when all files approved)

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

@@ -10,6 +10,8 @@ effort: xhigh
 
 Complete the current task. Auto-triggered by `/cbp-task-testing` when all tests pass. Can also be run manually.
 
+This skill is gated by an `ask`-tier `Skill(cbp-task-complete)` permission rule in `settings.json`. **The permission prompt IS the user confirmation** — there is NO AskUserQuestion inside this skill. A declined permission is a clean no-op (nothing committed, merged, pushed, or completed).
+
 ## Instructions
 
 ### Step 1: Parse `$ARGUMENTS`
@@ -90,12 +92,10 @@ Stop here.
 
 Load `task.qa` and `task.files_changed`:
 
-1. **QA**: count items by status (pass / fail / pending / skipped) across all types. If any item has status `fail` or `pending` (including default checklists), warn the user.
-2. **Files**: list any file with `user_approved === false` and warn.
-
-**If issues exist**, AskUserQuestion: `Complete anyway` / `Run QA first` (suggest `/cbp-task-check`) / `Cancel`. On `Run QA first` or `Cancel`, stop. On `Complete anyway`, continue.
+1. **QA**: count items by status (pass / fail / pending / skipped) across all types.
+2. **Files**: list any file with `user_approved === false`.
 
-**If no issues**, AskUserQuestion to confirm: `Ready to complete TASK-[N]: [title] — [N] rounds, [N] files. Proceed?`
+If any QA item is `fail`/`pending` or any file is unapproved, **surface the warnings in the output and continue** — record them for the Step 9 summary. There is NO confirmation AskUserQuestion here: `Skill(cbp-task-complete)` is `ask`-tier, so the harness permission prompt that gated this skill IS the user's confirmation to complete. The hard gates in Steps 2–2.6 (all rounds completed, ≥1 round has `testing_qa_output`, `check_verdict` READY, `task_testing_output.all_passed`) already block completion when prerequisites are unmet; these QA / file-approval items are warnings, not blockers.
 
 ### Step 4: Aggregate Files Changed
 
@@ -142,7 +142,7 @@ Call `complete_task(task_id)`. The server resolves the caller's worktree identit
 
 Apply the `cleanup` skill inline to remove orphan references to deleted/modified files. Then apply `migration` to propagate renames/moves to consumers. Both run without sub-agent spawns. Skip cleanup if no deletions/modifications; skip migration if cleanup handled everything.
 
-### Step 9: Show Result and Route (User-Confirmed)
+### Step 9: Show Result and Route
 
 Show the completion summary:
 
@@ -153,6 +153,7 @@ Show the completion summary:
 **Rounds**: [N] completed
 **Files**: [N] changed
 **Commit**: [hash]
+**Warnings**: [any QA / file-approval warnings from Step 3, or "none"]
 ```
 
 Then route. Same-context transitions (next task in this checkpoint) auto-trigger via the Skill tool. Cross-context transitions (checkpoint done → /cbp-checkpoint-check, session end) surface as a single directive 'Next: /clear, then /cbp-X' for the user to invoke after refreshing context.

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

@@ -9,7 +9,7 @@ effort: xhigh
 
 # Task Testing Command
 
-Comprehensive task-level testing — runs all automated tests and walks the user through manual testing one-by-one. Distinct from round-level testing (`testing-qa-agent`): this tests the **entire delivered feature holistically** after all rounds are complete. Runs inline — no sub-agent.
+Comprehensive task-level testing — the **cross-round double-check** run once after all rounds complete. Per-round QA (per-app build/lint/types, the `console.log`/debug scan, the OWASP/secret grep, `pnpm audit`) is owned by each round's `testing-qa-agent`; this skill does NOT re-run it. Instead it tests the **entire delivered feature holistically** across the full task diff — catching cross-package and cross-round problems no single round can see. Runs inline — no sub-agent.
 
 ## When Used
 
@@ -19,7 +19,7 @@ Comprehensive task-level testing — runs all automated tests and walks the user
 
 ## Scope vs Round-Level Validation
 
-Per-wave `testing-qa-agent` runs inside `/cbp-round-execute` Step 5. This skill adds the cross-cutting layer that is only visible across the full task diff: full-repo lint, workspace tsc, full test suite, `pnpm audit`, and full-diff security scan — each run once here, not per-round.
+Per-wave `testing-qa-agent` runs inside `/cbp-round-execute` Step 5 and **owns per-round QA**: per-app build/lint/types, the `console.log`/debug scan, the OWASP/secret full-diff grep, and `pnpm audit`. This skill does NOT repeat them. It adds only the cross-round layer invisible within a single round: workspace-wide lint, workspace tsc, and the full test suite (which catch cross-package breakage), plus the cross-round code review (Step 6.5), the autonomous sim screenshot loop (Step 6.x), and the user manual walkthrough (Step 8).
 
 ## Instructions
 
@@ -109,11 +109,9 @@ Capture stdout and stderr for each check.
 | Full-repo lint          | `pnpm -w lint`                  | Always                           |
 | Full-repo types         | `pnpm exec tsc --noEmit`        | Source files changed             |
 | Full-repo unit tests    | `pnpm test --run`               | Source files in aggregated_files |
-| Full-repo audit         | `pnpm audit`                    | Always                           |
 | Per-package E2E         | `pnpm --filter <pkg> e2e:test`  | UI files in aggregated_files     |
-| Full-diff security scan | inline grep or `security-agent` | Always                           |
 
-Per-file lint + format are enforced by `lint-format-on-edit.sh` hook per edit. This step catches cross-package issues invisible to per-wave checks.
+These are the workspace-wide / cross-package checks only — per-app build/lint/types, the `console.log`/debug scan, the OWASP/secret grep, and `pnpm audit` already ran per-round inside `testing-qa-agent` and are NOT repeated here. Per-file lint + format are enforced by `lint-format-on-edit.sh` per edit. This step catches cross-package issues invisible to per-wave checks.
 
 **Soft tests** (report, don't block):
 

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

@@ -133,7 +133,7 @@ Once the gates pass, load the context the head command needs. This ensures `/cle
 | `/cbp-checkpoint-start` | Load checkpoint via MCP `get_checkpoints` + `get_tasks(checkpoint_id)`. Display checkpoint title, status, claim state, first pending task |
 | `/cbp-task-start [N]` | Load via MCP `get_current_task`. Display checkpoint title + task title/requirements summary |
 | `/cbp-round-start` | Load via MCP `get_current_task` + `get_rounds(task_id)`. Display checkpoint + task + round count + last round summary |
-| `/cbp-round-update` | Load via MCP `get_current_task` + `get_rounds(task_id)`. Display checkpoint + task + files_changed approval summary |
+| `/cbp-round-update` | Load via MCP `get_current_task` + `get_rounds(task_id)`. Display checkpoint + task + files_changed triage summary (claude_approved, findings, hard_fail) |
 | `/cbp-round-input` | **Full context load** (see Step 2b) |
 | `/cbp-task-check` | Load via MCP `get_current_task`. Display checkpoint + task + files summary |
 | `/cbp-task-testing` | Load via MCP `get_current_task` + `get_rounds(task_id)`. Display checkpoint + task + testing status summary |