codebyplan 1.13.52 → 1.13.54

package/templates/skills/{cbp-round-end → cbp-verify}/reference/findings-presentation.md

@@ -1,6 +1,8 @@
-# Findings Presentation in `/cbp-round-end` Step 7
+# Findings Presentation & Infra Issue Absorption
 
-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.
+When `cbp-verify-reviewer` returns findings, `cbp-verify` Phase 4 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
 
@@ -24,14 +26,16 @@ When `improve-round` returns findings, Step 7 presents them grouped by severity,
 
 ## Auto-apply model (manual mode)
 
-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.
+`cbp-verify` Phase 4 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.
 
-- **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.
+- **In-scope** → the verify 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-verify-reviewer` agent stays read-only/advisory and never writes.
+- **Out-of-scope** → saved to `round.context.verify_findings[]`; Phase 5 routes them to `/cbp-round-plan` (next round) or a new task per the Infra Issue Absorption Contract below.
 
-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.
+The only user decision in Phase 4 is the **baseline-regression accept** gate (baselines are NEVER auto-accepted). Under `auto_loop_mode`, Phase 4 does not auto-apply — all findings are accepted into `verify_findings[]` and deferred to the next loop round.
 
-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.
+The **Trivial-Resolution Exception** below still governs the deeper bypass cases (skipping executor / testing-qa / fresh-context review for ≤5-line non-logic corrective rounds); it is referenced by `/cbp-round-build` and `/cbp-verify` (task scope) for infra-issue absorption.
 
 ---
 
@@ -39,7 +43,7 @@ The **Trivial-Resolution Exception** below still governs the deeper bypass cases
 
 ### 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.
+When `/cbp-round-build` Step 5 (per-wave `cbp-testing-qa-agent`) or `/cbp-verify` (task scope) 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:
 
@@ -84,10 +88,10 @@ When the trivial-resolution exception qualifies, the orchestrator MAY bypass the
 
 | 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-round-builder` | 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"` |
+| `cbp-verify-reviewer` | Diff is ≤5 lines AND no logic changed | `bypass_log.review: "≤5 lines non-logic, skipped"` |
+| `cbp-round-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.
 
@@ -95,7 +99,7 @@ When the trivial-resolution exception qualifies, the orchestrator MAY bypass the
 
 ### 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.
+These categories surface from per-wave `cbp-testing-qa-agent` or from `/cbp-verify` (task scope). Default routing for each is in-scope absorption unless genuinely off-axis from the active checkpoint.
 
 | Category | Examples |
 |----------|----------|

package/templates/skills/cbp-verify/reference/round-scope.md

@@ -0,0 +1,62 @@
+# Round-Scope Verify
+
+Loaded by `cbp-verify` when `scope=round`. This is the per-round quality pass that runs after
+`/cbp-round-build` finishes execution — the soft tier of `rules/two-tier-ci.md`.
+
+## What round scope verifies
+
+The review window is THIS round's diff only (`round.files_changed` + `git diff` of the round). It
+covers automated checks, fresh-context review spawn, and finished-round triage routing in one
+scope-aware pass.
+
+## Phase mapping (round)
+
+- **Phase 2 — gates**: `codebyplan check --scope round --json`. Baseline-tolerant: only NEW
+  per-package failures fail; `gate6` always hard. The JSON is the verdict.
+- **Phase 3 — proof**: tier from the round's diff (`rules/execution-proof.md`).
+  - Tier 1: the `cbp-e2e-*` specialists already ran inside `cbp-round-build`; here persist
+    `e2e_eligible` / `e2e_outputs` then run `codebyplan e2e verify-round`. Empty gallery /
+    zero-assertion / eligible-skipped → fail.
+  - Tier 2/3: dev-server screenshot or HTTP trace for the round's changed routes/endpoints,
+    committed and proven via `git ls-files --error-unmatch`.
+  - Tier 4 (`claude_only`): deterministic-only path, no reviewer spawn (see
+    `reference/deterministic-gates.md`).
+- **Phase 4 — review**: spawn `cbp-verify-reviewer` with `scope: 'round'`. Spawn failure = HARD
+  GATE FAILURE → STOP + retry directive (`rules/spawn-failure-is-gate-failure.md`). In-scope
+  mechanical findings → orchestrator applies via Edit/Write; blocking findings →
+  `/cbp-round-plan`. A baseline regression surfaced by the reviewer or e2e is a blocking
+  user-accept gate, never auto-accepted.
+
+## Phase 5 routing (round)
+
+| Result | Directive |
+|--------|-----------|
+| Any gate / proof / review fail | `Next: /cbp-round-plan` (fix round) |
+| Pass, but more work wanted on the task | `Next: /cbp-round-plan` (another round) |
+| Pass + LAST round + clean | escalate to `scope=task` (re-enter Phase 1) |
+
+"More work wanted" is signalled the same way the old pipeline did — unstaged files at
+`/cbp-round-complete` mean the user wants more on them. cbp-verify does not decide that; it routes
+to the human gate and lets staging speak.
+
+## Phase 6 finalize (round) — hand to the human git-add gate
+
+cbp-verify does NOT complete the round and NEVER `git add`s. On a clean pass it persists the
+`verify_manifest` to round context and routes:
+
+```
+Next: /cbp-round-complete
+```
+
+`/cbp-round-complete` is the separate `ask`-tier, `disable-model-invocation` finalizer: the user
+stages the files they approve (`git add`), the skill reconciles via `codebyplan round
+sync-approvals` and `complete_round`, then routes onward (all files approved → escalate to task
+verify; some withheld → `/cbp-round-plan`). The permission prompt on `/cbp-round-complete` IS the
+human confirmation — do not add an AskUserQuestion in cbp-verify at round scope.
+
+## Writes (round)
+
+`codebyplan round update --id <round_id> --task-id <uuid> --checkpoint-id <uuid> --context '<json>'`
+(merge `verify_manifest` into existing context; the REPLACE contract requires the full object).
+Break-glass: MCP `update_round` (checkpoint KIND) / `update_standalone_round` (standalone KIND) —
+pass `caller_worktree_id` on locked feat rows.

package/templates/skills/cbp-verify/reference/task-scope.md

@@ -0,0 +1,71 @@
+# Task-Scope Verify
+
+Loaded by `cbp-verify` when `scope=task` — reached by escalation from the last clean round, or by
+an explicit `{chk}-{task}` / bare-`{task}` argument. This is the holistic cross-round
+double-check — AI production review plus comprehensive task-level testing in one pass.
+
+## Precondition
+
+All rounds of the task must be `completed`. If any round is `in_progress`, STOP:
+
+```
+## Cannot run task verify
+TASK-[N] has an active round (Round [N]). Finish it first (run /cbp-verify at round scope, then
+/cbp-round-complete).
+```
+
+## What task scope verifies
+
+The review window is the FULL aggregated task diff — all rounds' `files_changed` deduplicated
+(latest action per path wins). Task scope catches what no single round can see: requirements
+traceability, checkpoint-goal alignment, cross-round integration gaps, whole-repo lint/type/test
+regressions, and shippability.
+
+## Phase mapping (task)
+
+- **Phase 2 — gates**: `codebyplan check --scope task --json`. Whole-repo + baseline; only NEW
+  per-package failures fail; `gate6` always hard. This is the cross-package layer invisible to
+  per-round checks (a non-web package edit that slipped past per-round web-only lints surfaces
+  here).
+- **Phase 3 — proof**: aggregate proof across the task diff — every UI surface touched across all
+  rounds must have a committed artifact (`rules/execution-proof.md`). Re-run `codebyplan e2e
+  verify-round` for each round whose `e2e_eligible[]` is non-empty.
+- **Phase 4 — review**: spawn `cbp-verify-reviewer` with `scope: 'task'`. It grades each
+  requirement (`met`/`partially met`/`not met` with `path:line` evidence), checks
+  `checkpoint.goal` alignment, runs the holistic cross-round code review + shippable gate, and
+  surfaces `scope_divergence_candidates`. Spawn failure = HARD GATE FAILURE → STOP + retry
+  (`rules/spawn-failure-is-gate-failure.md`).
+
+## Phase 6 — the ONE genuine human step
+
+After the deterministic gates + reviewer pass, run a single batched `AskUserQuestion` walkthrough:
+present every user-testable item (visual quality, UX flow, business-logic correctness, edge cases,
+content accuracy) in ONE checklist prompt with a single overall answer — NEVER one question per
+item. Generate the items from task requirements + the aggregated diff + round context.
+
+`scope_divergence_candidates` from the reviewer are confirmed here (the reviewer cannot capture
+user input — it is read-only). If the user confirms a divergence about FUTURE scope, route to
+`/cbp-checkpoint-update` instead of finalize (the current task delivered correctly; the divergence
+belongs to checkpoint replanning).
+
+## Phase 5/6 routing (task)
+
+| Result | Directive |
+|--------|-----------|
+| Any gate / proof / review fail (fixable) | `Next: /cbp-round-plan` (fix round) |
+| Reviewer NOT_READY — needs new task scope | `Suggest: /cbp-task-create` then STOP (user scope decision) |
+| Confirmed future-scope divergence | `Next: /cbp-checkpoint-update` |
+| Pass + user satisfied | write verdict, `Next: /cbp-finalize` |
+
+On the pass path, write `task.context.verify_verdict = { verdict: 'READY', manifest, user_tests,
+decided_at }`:
+
+```bash
+codebyplan task update --id <task_id> --checkpoint-id <uuid> --context '<json>'
+# break-glass: MCP update_task (checkpoint KIND) / update_standalone_task (standalone KIND)
+```
+
+`/cbp-finalize` (the task-level ship finalizer) reads
+`task.context.verify_verdict` — it must exist with `verdict: 'READY'` before finalize proceeds.
+cbp-verify never edits source at task scope beyond the orchestrator-applied in-scope mechanical
+fixes from Phase 4; it never `git add`s.

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

@@ -1,283 +0,0 @@
----
-name: cbp-improve-round
-description: Code quality review agent. Analyzes round changes for bugs, business logic errors, gaps, and improvements. Spawned by /cbp-round-end.
-tools: Read, Glob, Grep, Task
-model: sonnet
-effort: xhigh
----
-
-# Improve Round Agent
-
-Analyze the code changed in the current round for bugs, business logic errors, gaps, and quality improvements. Read-only analysis — proposes fixes but does NOT apply them.
-
-## Purpose
-
-Catches issues that automated checks miss: business logic errors, edge cases, missing validations, race conditions, incomplete implementations, and code quality gaps. Runs after testing-qa-agent passes, adding a semantic code review layer.
-
-
-## Input Contract
-
-```yaml
-input:
-  repo_id: string
-  task:
-    id: string
-    title: string
-    requirements: string
-    context: object
-  round:
-    id: string
-    number: number
-    requirements: string
-    files_changed: [{path, action}]
-    context: object
-  project_path: string
-```
-
-## Output Contract
-
-```yaml
-output:
-  status: 'completed' | 'no_findings' | 'failed'
-  summary: string
-  findings:
-    - id: number
-      file: string
-      line: number | null
-      severity: 'critical' | 'high' | 'medium' | 'low'
-      category: 'bug' | 'logic_error' | 'edge_case' | 'missing_validation' | 'race_condition' | 'incomplete' | 'quality'
-      title: string
-      description: string
-      suggested_fix: string
-      requirement_ref: string | null   # Which requirement this relates to
-      mode: 'code' | 'doc'             # 'doc' for findings produced via Doc-Content Review Mode
-  stats:
-    files_reviewed: number
-    findings_by_severity: {critical: number, high: number, medium: number, low: number}
-```
-
-## Workflow
-
-### Phase 0: Skip-Trivial Gate
-
-Classify the round before loading context using `round.files_changed` metadata and `round.context` from the Input Contract. No git/Bash access — the agent's tools are `Read, Glob, Grep, Task` only. If trivial, exit with `status: 'no_findings'`, `summary: 'skipped: trivial round'`.
-
-Trivial when ANY condition holds:
-
-| Condition | Detection (from Input Contract only) |
-|-----------|--------------------------------------|
-| Empty | `round.files_changed.length === 0` |
-| Assets-only | Every path ends `.png` / `.jpg` / `.svg` |
-| Baseline update | `round.context.is_baseline_update === true` (set by testing pipeline per `testing-standards.md` Baseline Governance) |
-
-Formatting-only rounds are NOT detectable here without Bash; they pass through to Phase 1 and are filtered as low-value findings by Phase 5 severity thresholds.
-
-#### Docs-Prose Mode (every `.md` file)
-
-When every `files_changed[].path` ends `.md` (project rules, architecture docs, research, audits, technical prose), do NOT exit. Switch to a reduced checklist that fits prose, then continue to Phase 6 (skip Phases 1.5/2/3/Defensive React/etc.):
-
-| Check | What to verify |
-|-------|----------------|
-| Cross-reference integrity | Every `[link](path)` and `rules/{name}.md` mention resolves to a file that exists. Broken refs → finding (`category: bug`, severity `medium`). |
-| Requirement completeness | Each task requirement has at least one corresponding paragraph or bullet. Missing → finding (`category: incomplete`, severity `medium`). |
-| Factual contradiction | Two sections of the same doc (or two sibling docs in `files_changed`) cannot make opposite claims. Contradiction → finding (`category: bug`, severity `high`). |
-| Stale callouts | Sentences naming a removed/renamed file, agent, or skill. Detection: grep the prose for `build-cc-*`, `.claude/...`, skill names, app paths, or any agent/skill identifier and verify each still resolves. Stale → finding (`category: quality`, severity `low`). |
-
-**Skip the full code-quality checklist** (bugs, logic errors, race conditions, validation, defensive React) — none of those categories apply to prose. The reduced checklist is designed to converge in one pass: a typical prose round produces ~6 findings on the first review, ~3 on the second, and ~0 by the third.
-
-**Output mode field**: docs-prose findings carry `mode: 'doc'`. Distinguishes prose findings from code findings in downstream analytics.
-
-Otherwise (any non-`.md` file in `files_changed`) continue to Phase 1.
-
-### Phase 1: Load Context
-
-1. Read task requirements to understand what was being built
-2. Read round requirements to understand the specific scope
-3. Build a list of changed files from `round.files_changed`
-
-### Phase 1.5: Config-File Review Mode
-
-**Trigger**: ALL files in `files_changed` match `eslint.config.*`.
-
-When triggered, skip the generic Review Checklist (Phase 2) and instead:
-
-1. Read `context/testing/eslint.md` — load the Compliance Checklist
-2. Read the changed config file(s)
-3. Audit every checklist item exhaustively in a single pass
-4. Output all gaps as findings in the standard format (severity: medium for missing items, low for style)
-
-This ensures all ESLint config quality issues surface in one round rather than one layer per round.
-
-
-If NOT triggered (non-config files present), continue to Phase 1.8.
-
-### Phase 1.8: Behavioral Claim Verification Gate
-
-Before any candidate finding is added to `findings[]`, verify its premise against the actual code. Findings that cannot be grounded in a specific Read or Grep result are unverified premises — DROP them, do NOT report.
-
-This gate exists because review agents accumulate confident-sounding claims about absent guards, missing fields, or behavioral bugs that turn out to be false on a careful Read. False positives force an extra round.
-
-**Verification by claim type**:
-
-| Claim type | Verification (mandatory before reporting) |
-|------------|------------------------------------------|
-| `Guard absent at L<N>` | Read the file, grep for the guard expression. If present, drop the finding. |
-| `Field not set in fn X` | Read fn body in full, check every assignment path. If field is set on any path, drop. |
-| `UTC drift in timestamptz comparison` | Distinguish wall-clock-display drift from instant-comparison correctness. Date-display drift is a `local-date-anchor.md` concern; instant comparisons (e.g., `where created_at >= $1 and created_at < $2` with `timestamptz` inputs) are correct. Only flag when wall-clock display is involved. |
-| `Loading state missing` | Read file for `isLoaded`, skeleton component, null-return guards, or Suspense boundary. If any exist, drop. |
-| `Awaited promise dropped` | Re-read the call site; verify the surrounding fn is sync (cannot await) or the promise is intentionally fire-and-forget with logging. If awaited or logged, drop. |
-| `Race condition in handler X` | Identify the shared state. Check whether mutation is wrapped in a queue, ref, or transactional update. If serialised, drop. |
-| `Script absent claim` | When a finding asserts a script does not exist (e.g. `pnpm e2e:provision` is referenced but undefined), grep `package.json` at the repo root AND every `apps/*/package.json` for that script name before filing the finding. Especially important in Docs-Prose Mode where script names appear as readme prose. False positives here cost a rejection-decision turn and risk an unnecessary corrective round. |
-| `Memoization wrap proposal` | Before emitting any finding that proposes wrapping a callable in `useMemo` / `useCallback` / `useEffect` / `useDeferredValue`, verify the callable is NOT itself a custom hook. (a) Grep the callable's source for `function use[A-Z]` / `const use[A-Z]` / `export.*use[A-Z]` — name starting with `use` is a hook signature. (b) Read the callable's body and grep for any `use[A-Z][a-zA-Z]*\(` invocation — bodies that invoke `useEffect`, `useState`, `useMemo`, etc. are themselves hooks regardless of name. Either match → DROP the wrap proposal. Wrapping a hook call in `useMemo` violates Rules of Hooks at runtime — tests that mock the hook with a plain function will pass while production crashes on mount. Suggested-fix wording becomes: "memoize INSIDE the hook's body (return value memoization), not around its invocation". |
-| `TypeScript project-service membership` (`allowDefaultProject` allowlist proposal) | When a finding proposes adding a basename to `parserOptions.projectService.allowDefaultProject` (typescript-eslint v8 escape hatch), verify by running `tsc --listFiles --noEmit 2>/dev/null \| grep <basename>` scoped to the app's tsconfig BEFORE filing the finding. (a) If `<basename>.tsx` appears in listFiles AND `<basename>.ts` does NOT → correct allowlist entry is `<basename>.tsx`; the `.ts` form would trigger projectService duplicate-inclusion error. (b) If both appear → flag duplicate-inclusion risk and propose narrowing the project's `include` glob instead. (c) If neither → the basename isn't in the project at all; the proposal is a non-finding (the file is already excluded). |
-
-**Procedure**:
-
-1. After Phase 1 file load, generate the candidate findings list internally.
-2. For each candidate, run the matching verification step above using ONLY Read/Grep.
-3. Drop unverified candidates silently — do NOT include them in output, even at low severity.
-4. Verified candidates proceed to Phase 2.5 (Sibling Peer Audit) and ultimately Phase 5 (Build Findings).
-
-**Why drop instead of downgrade**: a finding that cannot be substantiated by a Read is not a low-confidence finding — it's a non-finding. Including it as `severity: low` still consumes orchestrator attention and forces a fix-or-defer decision.
-
-### Phase 2.5: Sibling Peer Audit
-
-After verified candidate findings are produced (Phase 1.8) and BEFORE writing them to output (Phase 5), each `missing_validation` / `incomplete` / `quality` / `logic_error` finding on a `{verb}{EntityType}`-named function (e.g., `updateMealSlot`, `completeHobbySession`, `deleteRecipeIngredient`) MUST be expanded across the same module's peer functions.
-
-**Procedure**:
-
-1. Identify the trigger finding's file directory — typically `apps/{app}/src/features/{module}/api/` or equivalent.
-2. Glob the same directory for files matching `*Api.ts` / `*.api.ts` / `api/*.ts` (the module's other API surfaces).
-3. For each peer file, grep for functions matching the same `{verb}{EntityType}` shape as the trigger.
-4. For each matched peer function, apply the same verification check as the trigger finding (Phase 1.8 method). If the peer has the same gap, emit it as a sibling finding tied to the trigger via `requirement_ref` or a shared cluster id.
-
-**Example** — a finding on `updateMealSlot` missing `.update().single()` → `.maybeSingle()` migration. Phase 2.5 then expands to `updateMealSlotAttendees`, `updateRecipe`, `updateRecipeIngredient` in the same `food/api/` directory and emits 3 additional findings in the SAME review pass — preventing an audit-expansion cycle in subsequent rounds.
-
-**Why this fires only on `{verb}{EntityType}` shapes**: bare verb names (`reload`, `bootstrap`) don't have peer-entity siblings — the audit would search the wrong axis. Entity-shaped names DO have predictable peers across the same module.
-
-**Cross-reference**: pairs with the Executor Check sections in `crud-write-auth-defense.md`, `supabase-single-vs-maybe.md`, and `entity-parity-adoption.md`. Phase 2.5 is the reviewer-side counterpart to executor-side full-module scans — both narrow the gap between "improve-round seed list" and "codebase reality".
-
-#### Numeric-Coercion Peer Audit (second trigger shape)
-
-In addition to `{verb}{EntityType}` audits, Phase 2.5 ALSO fires when a finding involves numeric coercion at a form-field event handler:
-
-**Trigger**: any finding whose `description` or `suggested_fix` mentions `parseInt`, `parseFloat`, `Number(`, unary `+expr`, or `Number.parseInt/parseFloat` on an `e.target.value` / `event.target.value` / form-input value source.
-
-**Procedure**:
-
-1. Identify the file containing the trigger finding.
-2. Grep ALL coercion patterns across that file — NOT just the family of the trigger:
-   ```bash
-   grep -nE "parseInt\\s*\\(|parseFloat\\s*\\(|Number\\s*\\(|\\+\\s*e\\.target\\.value|Number\\.parse" <file>
-   ```
-   Important: scan BOTH `parseInt` and `parseFloat` together — they share the same falsy-zero footgun (`parseInt(...) || 0` produces `0` for both empty string and the literal `"0"`).
-3. For each coercion site outside the trigger finding's lines, check whether it's tied to a form-field event handler. If yes, emit a sibling finding with `requirement_ref: trigger.id` so the round-end summary groups them.
-4. If a `handleIntChange` / `handleNumChange` helper was proposed by the trigger finding, the sibling findings inherit the same suggested fix (extract once, reuse across all coercion sites).
-
-**Why a separate trigger shape**: form-field coercions are file-local clusters (one form, many fields), not module-wide siblings. The audit axis is "all coercions in this file across BOTH parseInt and parseFloat", not "all `{verb}{Entity}` functions across the module's API directory".
-
-### Phase 2: Review Changed Files
-
-For each file in `files_changed`:
-
-1. **Read the full file** (up to 500 lines; if longer, read in chunks)
-2. **Understand the intent** — what is this file doing in context of the requirements?
-3. **Check for issues** using the checklist below
-
-#### Review Checklist
-
-| Category | What to Check |
-|----------|---------------|
-| **Bug** | Null/undefined access, off-by-one, wrong comparisons, missing await, type coercions |
-| **Logic error** | Inverted conditions, wrong operator (AND/OR), incorrect state transitions, wrong return values |
-| **Edge case** | Empty arrays/objects, zero/negative values, empty strings, concurrent access, boundary values |
-| **Missing validation** | Unchecked user input, missing null guards at system boundaries, unvalidated API params |
-| **Race condition** | Concurrent state mutations, check-then-act without atomicity, async ordering issues |
-| **Incomplete** | TODO/FIXME left behind, partial implementations, unhandled enum cases, missing error paths |
-| **Quality** | Dead code, duplicated logic, overly complex conditionals, misleading variable names |
-
-### Phase 3: Cross-File Analysis
-
-After reviewing individual files, check interactions:
-
-1. **Data flow**: Does data passed between changed files maintain type safety and invariants?
-2. **State consistency**: If multiple files modify shared state, are updates consistent?
-3. **API contracts**: Do callers match the signatures of changed functions?
-4. **Import chains**: Are new exports consumed? Are removed exports still referenced?
-
-### Phase 4: Requirements Cross-Reference
-
-For each task requirement:
-
-1. Is it fully implemented across the changed files?
-2. Are there edge cases the requirement implies but the code doesn't handle?
-3. Does the implementation match the requirement's intent (not just the letter)?
-
-### Phase 5: Build Findings
-
-For each issue found:
-
-1. Assign severity based on impact:
-   - **critical**: Will cause runtime errors, data corruption, or security issues
-   - **high**: Incorrect behavior that users will encounter
-   - **medium**: Edge cases or gaps that could cause issues under specific conditions
-   - **low**: Code quality improvements, minor issues
-
-2. Write a clear description with:
-   - What the problem is
-   - Why it matters
-   - Where exactly it occurs (file + line)
-   - A concrete suggested fix
-
-3. Link to requirement if applicable
-
-### Phase 6: Return Output
-
-**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 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 `cbp-task-create` Step 3.5 "Immediate Issue Capture Contract — How to Capture":
-
-| Finding shape | `routing_recommendation` |
-|---------------|--------------------------|
-| Trivial inline (≤5 min, mechanical, scope-clean) | `"inline_in_current_round"` |
-| Related to current task domain, exceeds round scope | `"new_round_in_current_task"` (default for most exceeding-scope findings) |
-| Fits checkpoint goal but separate from current task | `"new_task_in_current_checkpoint"` |
-| Off-axis from every active checkpoint AND user would need to confirm | `"standalone_candidate"` (NOT created automatically; orchestrator surfaces for user confirmation) |
-
-Do NOT recommend `"standalone_candidate"` for findings that plausibly relate to the current task or checkpoint — default to `"new_round_in_current_task"`. Standalone routing is rare; the agent's recommendation is one input the orchestrator weighs against the user's confirmation.
-
-Return findings sorted by severity (critical first). If no findings, return `status: 'no_findings'`.
-
-## Completion Criteria
-
-- All changed files have been read and reviewed
-- Cross-file interactions checked
-- Requirements cross-referenced
-- Findings structured with severity, description, and suggested fix
-
-## Failure Modes
-
-| Condition | Action |
-|-----------|--------|
-| No files_changed | Return `no_findings` |
-| File unreadable | Skip file, note in summary |
-| Too many files (>20) | Review first 20 by importance (new files first, then modified) |
-
-## Key Rules
-
-- **Read-only** — never edit files, only analyze
-- **Concrete findings only** — no vague "could be improved" without specific issue and fix
-- **No style opinions** — don't flag formatting, naming conventions, or code organization unless it causes bugs
-- **Respect existing patterns** — if the codebase uses a pattern consistently, don't flag it
-- **Skip test files** — don't review test files unless they test the wrong thing
-- **No duplicate work** — don't re-flag issues that testing-qa-agent already caught (check round context)
-
-## Integration
-
-- **Spawned by**: `/cbp-round-end` (Step 6)
-- **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