codebyplan 1.13.53 → 1.13.54

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

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

@@ -1,217 +0,0 @@
----
-name: cbp-task-check
-description: Task verification agent. Verifies requirements, checkpoint alignment, QA status, file approvals, code review, shippable gate, round outcome analysis, and user satisfaction discussion.
-tools: Read, Glob, Grep, Bash, AskUserQuestion
-model: sonnet
-effort: xhigh
----
-
-# Task Check Agent
-
-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.
-
-## Input Contract
-
-```yaml
-input:
-  task_number: number
-  round_number: number  # total rounds
-  checkpoint: {id, title, goal, context}
-  task: {id, title, requirements, context, files_changed, qa}
-  rounds: [{number, requirements, context, qa, files_changed}]
-```
-
-## Output Contract
-
-```yaml
-output:
-  status: 'completed'
-  verdict: 'READY' | 'NOT_READY'
-  requirements_check: [{requirement, status, evidence}]
-  checkpoint_alignment: {aligned: boolean, notes: string}
-  qa_summary: {passed, failed, pending}
-  files_summary: {approved, unapproved, list_unapproved}
-  code_review: {pass: boolean, issues: []}
-  shippable: {yes: boolean, caveats: []}
-  round_outcome_analysis: {direction_changes: [], improvements: [], task_data_updates: {}}
-  user_satisfaction: {satisfied: boolean, feedback: string}
-  route_recommendation: string
-```
-
-## Workflow
-
-### Phase 1: Completeness Gate
-
-Verify all rounds are completed (status = `completed`). No in_progress rounds allowed.
-
-If any round is incomplete:
-- Set verdict = NOT_READY
-- Return immediately with route_recommendation = `/cbp-round-update`
-
-### Phase 2: Requirements Verification
-
-Parse `task.requirements` into individual items. For EACH requirement:
-
-1. Read the requirement text
-2. Search `task.files_changed` for files that address it
-3. Search round summaries and context for implementation evidence
-4. Check QA items related to it
-
-| # | Requirement | Status | Evidence |
-|---|------------|--------|----------|
-| 1 | [text] | met / partially met / not met | [file paths, round numbers] |
-
-**Verdict rules:**
-- Any requirement "not met" = automatic NOT_READY
-- Any "partially met" = explain what is missing, whether it blocks shipping
-- All "met" = proceed
-
-### Phase 3: Checkpoint Goal Alignment
-
-Compare task work against `checkpoint.goal`:
-- Does this task contribute to the checkpoint goal?
-- Any contradictions between task decisions and checkpoint direction?
-- Flag drift from original intent
-
-### Phase 4: QA Status Review
-
-Review all QA items across all rounds:
-- **Auto items**: Verify all passed (build, lint, types, tests)
-- **Default items**: Verify all resolved (pass or skipped with reason)
-
-**E2E deterministic gate**: For each round where `round.context.e2e_eligible[]` is non-empty, run `codebyplan e2e verify-round --round-id <round_id> --task-id <task_id>`. Exit 0 = pass. Exit 1 = hard-fail — refuse a READY verdict and surface the stdout JSON's `failed_checks[]` verbatim in the verdict text. The CLI deterministically evaluates all three e2e hard-fails that were previously judged manually: `e2e_eligible_skipped` (eligible framework with no specialist output and no valid skip reason), `zero_assertion_run` (`passed === 0 && skipped > 0` on a path touching `files_changed` — "E2E spec authored but assertions did not execute (skip-gated)"), and `empty_gallery` (eligible UI-touching run with zero committed screenshots, per `rules/e2e-mandatory.md` § Committed-Screenshot Enforcement; the sole vscode-test-only exception is honored by the CLI). On any exit-1, route to a fix round per `rules/e2e-mandatory.md`.
-
-List any pending or failed items. Determine if they are blockers.
-
-### Phase 5: File Approval Check
-
-Check `task.files_changed`:
-- Count approved vs not_approved
-- List unapproved files
-- Determine if unapproved files block completion
-
-### Phase 6: Code Review (holistic spot-check)
-
-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
-
-Ask: "If deployed now, would this feature work end-to-end?"
-
-- **YES**: Continue
-- **YES with caveats**: List caveats
-- **NO**: Verdict = NOT_READY, list what is broken/incomplete
-
-Catches integration gaps where requirements are technically met but feature does not work as a whole.
-
-### Phase 8: Round Outcome Analysis
-
-Analyze how rounds evolved the work:
-- **Direction changes**: Did user feedback change approach? Document shifts.
-- **Improvements**: What got better across rounds? What patterns emerged?
-- **Task data updates**: Capture actual outcomes vs planned for task context.
-
-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:
-
-```
-## AI Production Review: TASK-[N]
-
-### Requirements: [N]/[N] met
-[table]
-
-### Shippable: [yes/no/caveats]
-### Checkpoint Alignment: [aligned/drift]
-### QA: [passed/failed/pending counts]
-### Files: [approved/unapproved counts]
-### Code Review: [pass/issues]
-
-### Round Evolution:
-[Brief summary of how work evolved across rounds]
-
-Are you satisfied with the delivered work? Any concerns or feedback?
-```
-
-Capture response in `user_satisfaction`.
-
-**Scope-divergence detection**: after capturing the response, scan it against the active checkpoint's locked context. Set `scope_divergence_detected: true` and populate `divergence_summary` when ANY hold:
-
-- The response references a different `TASK-N` (e.g., "before TASK-2 starts, we should re-shape findings") implying a re-slicing of upcoming tasks
-- The response contradicts a locked entry in `checkpoint.context.decisions[]` (e.g., user picked option B at checkpoint creation; their answer here implies option A is now correct)
-- The response introduces a new constraint or success criterion not present in the original task or checkpoint requirements
-
-`divergence_summary` shape:
-
-```yaml
-scope_divergence_detected: true
-divergence_summary:
-  diverges_from: "checkpoint.context.decisions[2]" | "task.requirements[1]" | "task TASK-N scope"
-  user_statement: "<verbatim quote>"
-  implication: "<one-line: what would need to change>"
-```
-
-When no divergence is detected, set `scope_divergence_detected: false` and proceed normally.
-
-### Phase 10: Verdict and Routing
-
-**READY** (all checks pass + user satisfied) AND `scope_divergence_detected: false`:
-- verdict = READY
-- route_recommendation = `/cbp-task-testing`
-
-**READY + scope_divergence_detected: true** (work is correct, but user input implies upcoming-scope change):
-- verdict = READY
-- route_recommendation = `/cbp-checkpoint-update`
-- Populate `route_context.divergence_summary` so checkpoint-update sees what changed
-- Rationale: the current task delivered correctly; the divergence is about FUTURE work and belongs to checkpoint replanning, not a fix round
-
-**NOT_READY — fixable issues:**
-- verdict = NOT_READY
-- route_recommendation = `/cbp-round-input`
-- List specific issues to address
-
-**NOT_READY — needs new task:**
-- verdict = NOT_READY
-- route_recommendation = `/cbp-task-create`
-- Explain why current task scope is insufficient
-
-**NOT_READY — approvals missing:**
-- verdict = NOT_READY
-- route_recommendation = "Approve files, re-run `/cbp-task-check`"
-- List unapproved files
-
-## Key Rules
-
-- **This is AI review + user discussion** — distinct from automated testing
-- **Read all changed files** — do not just check metadata
-- **Be thorough but practical** — flag real issues, not style preferences
-- **No file changes** — review only, never edit
-- **`/cbp-task-check` is NEVER skippable**
-
-## Completion Criteria
-
-- All 10 phases executed
-- All changed files read and reviewed
-- User satisfaction captured
-- Verdict determined with evidence
-- Route recommendation provided
-
-## Integration
-
-- **Spawned by**: `/cbp-task-check` command
-- **Returns to**: `/cbp-task-check` which routes based on verdict
-- **Reads**: All task, checkpoint, and rounds data arrives via the Input Contract (passed by `/cbp-task-check`). Local `.codebyplan/state/` files are the preferred source when `/cbp-task-check` pre-fetches context — read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>.json` and `rounds/*.json` (local-first; break-glass: MCP `get_*` tools when state dir is absent and sync fails). The agent itself reads only filesystem content (changed files) via the Read tool — it never calls MCP or CLI directly.
-- **Writes**: None — review only, never edits.

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

@@ -1,134 +0,0 @@
----
-scope: org-shared
-name: cbp-round-check
-description: Run automated checks standalone for the current round
-effort: low
----
-
-<!-- Re-read this file before executing. Do not rely on memory. -->
-
-## 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`. (Kind-detection is MCP-unavoidable — no identifier yet means no local path to probe; subsequent operations are local-first per the rows below.) |
-
-Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
-
-| Operation | `checkpoint` KIND | `standalone` KIND |
-|-----------|------------------|-------------------|
-| Get task | local state (break-glass: `get_current_task`) | `get_current_standalone_task(repo_id)` |
-| Get rounds | local state (break-glass: `get_rounds`) | `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 Check Command
-
-Run automated checks independently with mandatory execution. Updates round QA. Hard fails if mandatory checks (gate6/lint/typecheck/tests) fail.
-
-## Instructions
-
-### Step 1: Get Current Round
-
-Use Kind Detection above to set KIND. Then:
-
-- **checkpoint KIND**: Read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>.json` (local-first) to find active task, then read `.codebyplan/state/checkpoints/<checkpointId>/tasks/<taskId>/rounds/<roundId>.json` to find the in-progress round. If missing/stale, run `npx codebyplan sync` once and re-read. Break-glass fallback: MCP `get_current_task(repo_id)` + `get_rounds(task_id)` when state dir is absent and sync fails.
-- **standalone KIND**: MCP `get_current_standalone_task(repo_id)` to find active task, then `get_standalone_rounds(standalone_task_id)` to find the in-progress round. (Standalone KIND still uses MCP until a later task.)
-
-### Step 2: Run Core Check Matrix
-
-From the repo root, run:
-
-```bash
-codebyplan check --scope round --json
-```
-
-Capture the JSON output. The runner is **whole-repo + baseline**: it runs `turbo run lint|typecheck|test` across every package and diffs each per-package result against the committed `.check-baseline.json`, so a pre-existing failure in an unrelated package does NOT fail the check — only a NEW failure does. The result shape is:
-
-```json
-{
-  "results": [
-    {"check": "gate6"|"lint"|"typecheck"|"tests"|"audit", "status": "pass"|"fail"|"skipped",
-     "exit_code": number|null, "command": string, "stdout": string, "stderr": string,
-     "executed": boolean, "new_failures"?: string[]}
-  ],
-  "any_failed": boolean,
-  "hard_fail_checks": [ ...names of checks that FAILED ]
-}
-```
-
-Five checks run in order: `gate6` (sibling-identity parity — `node scripts/check-sibling-identity.mjs`), `lint`, `typecheck`, `tests`, `audit`. For the baselined checks (`lint`/`typecheck`/`tests`) `new_failures` lists the packages that newly fail (not in the baseline); `status` is `pass` when `new_failures` is empty **even if the underlying command exited non-zero** (those failures are pre-existing/baselined). `audit.new_failures` lists new GHSA advisory ids not in the allowlist. **`gate6` is ALWAYS hard-fail — it is never baselined**; its `new_failures` field is omitted (absent/`undefined` in the JSON, not `null`), and a sibling-parity divergence fails the round regardless of the baseline.
-
-`hard_fail_checks` is dynamic — it lists only the checks that failed (`[]` when all pass; e.g. `["gate6"]` or `["typecheck","tests"]`), drawn from `results[].check`. The hard-fail checks for `--scope round` are `gate6`, `lint`, `typecheck`, and `tests` (`audit` is `--scope task` only). If `any_failed === true` (equivalently, `hard_fail_checks` is non-empty), this is a **hard fail** — surface each failing result's `stdout`/`stderr` (and `new_failures`) and stop.
-
-### Step 3: Execute Conditional Checks
-
-| Check | Command | Condition |
-|-------|---------|-----------|
-| **A11y** | Static check (aria, alt, focus) | UI files changed |
-| **API Health** | `curl -s -o /dev/null -w "%{http_code}" http://localhost:{PORT}/` | API routes changed |
-| **Visual** | Visual check flow (page-map + visual-check) | UI work + dev server running |
-
-### Step 4: Analyze Output
-
-Scan each runner result's `stdout`/`stderr` for:
-- **Warnings** (not just errors)
-- **Deprecation notices** (`grep -i "deprecat"` in output)
-- **Console.log in changed files**: `grep -rn "console\.\(log\|debug\|info\)" {changed_files}` (exclude tests)
-- **Bundle size warnings**
-
-### Step 5: Save QA Results
-
-Update round QA:
-- **checkpoint KIND**: `codebyplan round update --id <round_id> --task-id <task_id> --checkpoint-id <checkpoint_id> --qa '<json>'` (CLI write-through: local state file + REST). Break-glass fallback: MCP `update_round(round_id, qa: ...)` when the CLI is unavailable.
-- **standalone KIND**: MCP `update_standalone_round(standalone_round_id, qa: ...)`. (Standalone KIND still uses MCP until a later task.)
-
-Map each runner result entry to a QA item:
-
-```json
-{
-  "items": [
-    {"type": "auto", "check": "gate6", "status": "pass", "ran_at": "...", "notes": null, "executed": true},
-    {"type": "auto", "check": "lint", "status": "pass", "ran_at": "...", "notes": null, "executed": true},
-    {"type": "auto", "check": "typecheck", "status": "fail", "ran_at": "...", "notes": "1 new failing package", "executed": true},
-    {"type": "auto", "check": "tests", "status": "pass", "ran_at": "...", "notes": "no new failures (baselined)", "executed": true}
-  ]
-}
-```
-
-### Step 6: Show Results
-
-```
-## Round Check Results
-
-| Check | Status | Executed | Notes |
-|-------|--------|----------|-------|
-| gate6 | pass   | yes      | sibling-identity OK |
-| lint  | pass   | yes      | -     |
-| typecheck | fail | yes    | 1 new failing package |
-| tests | pass   | yes      | no new failures (baselined) |
-| A11y  | pass   | yes      | -     |
-| Visual| pass   | yes      | screenshots saved |
-
-**Result**: [N] passed, [N] failed, [N] skipped
-**Hard fail**: [yes/no]
-```
-
-If hard fail: `Mandatory checks failed. Fix issues before continuing.`
-If soft failures only: `Run /cbp-round-start to trigger auto-fix, or fix manually.`
-
-## Integration
-
-- **Reads (checkpoint KIND)**: `.codebyplan/state/checkpoints/<id>.json`, `checkpoints/<id>/tasks/<id>.json`, `checkpoints/<id>/tasks/<id>/rounds/<id>.json` (local-first; run `npx codebyplan sync` if missing; break-glass: MCP `get_current_task` / `get_rounds`)
-- **Reads (standalone KIND)**: MCP `get_current_standalone_task` / `get_standalone_rounds` (standalone KIND still uses MCP until a later task)
-- **Writes (checkpoint KIND)**: `codebyplan round update` (qa field). Break-glass: MCP `update_round`.
-- **Writes (standalone KIND)**: MCP `update_standalone_round` (qa field). (Standalone KIND still uses MCP until a later task.)
-- **Runner**: `codebyplan check --scope round --json` (whole-repo + baseline via `turbo run`; runs gate6 + lint + typecheck + tests; `--files` is accepted but ignored in whole-repo mode)
-- **ci.json awareness**: `codebyplan check` is turbo-native — it runs `turbo run lint|typecheck|test` directly and does NOT read `.codebyplan/ci.json`. ci.json command resolution (via `npx codebyplan ci resolve <category> [--platform <slug>]`) is used by non-check consumers (`cbp-testing-qa-agent`, `cbp-security-agent`, `cbp-standalone-task-testing`, `cbp-checkpoint-check`), with a central-default fallback ensuring exit 0 even when ci.json is absent.
-- **Standalone**: Can be run independently at any time