codebyplan 1.5.1 → 1.9.0

package/templates/skills/cbp-build-cc-skill/examples/knowledge-skill.md

@@ -0,0 +1,25 @@
+---
+name: legacy-payments
+description: Background context for the legacy payments module. Loads automatically when editing anything under src/payments/legacy/.
+user-invocable: false
+paths:
+  - "src/payments/legacy/**"
+---
+
+# Legacy Payments Context
+
+The legacy payments module predates our current Stripe integration. It handles:
+
+- Authorize.net transactions (pre-2021 customers only)
+- Manual ACH reconciliation via nightly CSV imports
+- A custom currency-conversion table that does not use the FX service
+
+## Constraints
+
+- Do not rewrite in TypeScript — this module is scheduled for deprecation in Q3
+- All new payment features go in `src/payments/stripe/` instead
+- Bug fixes are allowed but must include a regression test in `tests/payments/legacy/`
+
+## Why it's still here
+
+Customers on grandfathered contracts cannot be migrated without manual outreach. Product has a migration plan in `docs/migrations/payments-2026.md`.

package/templates/skills/cbp-build-cc-skill/examples/task-skill.md

@@ -0,0 +1,29 @@
+---
+name: commit
+description: Stage and commit the current changes
+disable-model-invocation: true
+allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *) Bash(git diff *)
+argument-hint: [commit message]
+---
+
+Stage and commit the current working directory changes.
+
+## Context
+
+- Status: !`git status --short`
+- Staged diff: !`git diff --cached --stat`
+- Unstaged diff: !`git diff --stat`
+
+## Your task
+
+Based on the status and diffs above, create a commit with message:
+
+```
+$ARGUMENTS
+```
+
+Steps:
+1. Stage relevant files with `git add`
+2. Verify staging with `git status`
+3. Commit with the message above
+4. Show the resulting commit with `git log -1`

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

@@ -0,0 +1,157 @@
+---
+scope: org-shared
+---
+
+# Skill Authoring Quality
+
+Quality expectations and structure for `/.claude/skills/{name}/SKILL.md` files. This file adds CBP-specific constraints on top of the official Claude Code skills spec.
+
+## Required CBP Frontmatter
+
+Every skill MUST have `scope:` in addition to the Claude Code native fields:
+
+```yaml
+---
+scope: org-shared # structural marker: org-shared | project-shared | repo-only:<repo-name>
+name: cbp-skill-name
+description: One sentence — shown in skill list and used for auto-matching
+---
+```
+
+`scope:` is a CBP structural marker — not read by Claude Code itself. Missing `scope:` fails validation (`validate-skill.sh` / `validate-structure-scope.sh`).
+
+## What Skills Are
+
+Skills are user-invocable commands that run in the main conversation. They follow a step-by-step workflow, can spawn agents, call MCP tools, and interact with the user.
+
+Skills are NOT agents — they don't run in isolation. They have access to the full conversation context and auto-loaded rules.
+
+## Required Sections
+
+Every skill MUST have these sections:
+
+| Section               | Purpose                                       | Skip When              |
+| --------------------- | --------------------------------------------- | ---------------------- |
+| **Frontmatter**       | name, description, triggers, argument-hint    | Never                  |
+| **Title + one-liner** | What this skill does                          | Never                  |
+| **Instructions**      | Numbered steps with clear actions             | Never                  |
+| **Integration**       | Triggered by, reads, writes, spawns, triggers | Never                  |
+| Pipeline              | Visual flow showing command chain             | No chain exists        |
+| Arguments             | Parameter table                               | No arguments accepted  |
+| When to Use           | Activation conditions                         | Obvious from name      |
+| Key Rules             | Constraints specific to this skill            | No special constraints |
+
+## Frontmatter
+
+```yaml
+---
+name: cbp-skill-name
+description: One sentence — shown in skill list
+triggers: [cbp-followup-command]
+argument-hint: [optional args description]
+---
+```
+
+- `name:` — must match folder name, kebab-case
+- `triggers:` — skills this skill auto-triggers (not skills that trigger it)
+- `argument-hint:` — shown to user, describes expected arguments
+
+## Quality Expectations
+
+### Max Lines: 300
+
+If a skill exceeds 300 lines, it's doing too much. Options:
+
+1. Extract complex logic to a spawned agent
+2. Move reference data to a context file
+3. Split into multiple skills in a pipeline
+
+### Steps Must Be Concrete
+
+Each step should be a single action with a clear outcome. No multi-paragraph explanations.
+
+| Bad                                                                                        | Good                                                                  |
+| ------------------------------------------------------------------------------------------ | --------------------------------------------------------------------- |
+| "Analyze the situation and determine the best course of action based on the current state" | "Use MCP `get_current_task` with repo_id. If no task: show error."    |
+| "Process the results appropriately"                                                        | "Save to task context via MCP `update_task(task_id, context: {...})`" |
+
+### One Responsibility Per Skill
+
+A skill should do one thing in the pipeline. If a skill both plans AND executes, split it.
+
+| Wrong                                   | Right                                                        |
+| --------------------------------------- | ------------------------------------------------------------ |
+| `/cbp-round` (plans + executes + tests) | `/cbp-round-start` → `/cbp-round-execute` → `/cbp-round-end` |
+
+### Pipeline Clarity
+
+If the skill is part of a chain, show it:
+
+```
+/cbp-round-start (planning) → [user approval] → /cbp-round-execute (auto)
+```
+
+### Approval Gates
+
+Skills that need user input before proceeding must:
+
+1. Present the information clearly
+2. End with a `Reply with:` block listing options
+3. Wait — never auto-proceed past an approval gate
+
+### Auto-Trigger vs Wait
+
+| Situation                    | Action                          |
+| ---------------------------- | ------------------------------- |
+| Next step is deterministic   | Auto-trigger the next skill     |
+| User approval needed         | Wait with `Reply with:` options |
+| User must do external action | Wait with instructions          |
+| Multiple valid paths         | Present options, wait           |
+
+## Command Follow-Up Format
+
+When a skill stops and waits:
+
+```markdown
+---
+
+**Next:**
+Run `/cbp-command-name` to:
+- Action 1
+- Action 2
+
+---
+
+Waiting for user to run [command-name].
+```
+
+## When to Create vs Update a Skill
+
+| Situation                                 | Action                                                   |
+| ----------------------------------------- | -------------------------------------------------------- |
+| Existing skill covers the workflow        | Update its SKILL.md                                      |
+| New workflow, no existing skill covers it | Create new skill                                         |
+| Existing skill is too large (>300 lines)  | Extract agent or context, keep skill as orchestrator     |
+| Pattern seen < 5 times                    | Don't create a skill yet — wait for pattern to stabilize |
+
+## Integration Section Format
+
+```markdown
+## Integration
+
+- **Triggered by**: [what invokes this skill]
+- **Reads**: [MCP tools and files read]
+- **Writes**: [MCP tools and files written]
+- **Spawns**: [agents spawned]
+- **Triggers**: [next skill in chain]
+```
+
+## Common Mistakes
+
+| Mistake                                       | Fix                                                         |
+| --------------------------------------------- | ----------------------------------------------------------- |
+| Hardcoding file paths                         | Use paths from structure rules                              |
+| Skipping MCP calls, using conversation memory | Always read from DB — it's the source of truth              |
+| Steps that say "if needed" without criteria   | Define the criteria explicitly                              |
+| Mixing planning and execution in one skill    | Split into separate skills with auto-trigger                |
+| No error handling for MCP failures            | Add "If no X found: show error message" after each MCP call |

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

@@ -0,0 +1,35 @@
+# Skill Frontmatter Reference
+
+Source: official Claude Code skills spec. All fields are optional; `description` is recommended.
+
+| Field | Purpose |
+|-------|---------|
+| `name` | Display name — becomes `/slash-command`. Lowercase, digits, hyphens, max 64 chars. Defaults to directory name |
+| `description` | What the skill does and when to use it. Claude matches against this |
+| `when_to_use` | Additional trigger phrases. Appended to `description` in the listing |
+| `argument-hint` | Autocomplete hint, e.g. `[issue-number]` |
+| `arguments` | Named positional args, e.g. `[file mode]` → `$file`, `$mode` |
+| `disable-model-invocation` | `true` → only user can invoke (via `/name`) |
+| `user-invocable` | `false` → hidden from `/` menu, Claude-only |
+| `allowed-tools` | Pre-approve tools while the skill is active |
+| `model` | Override model for this skill's turn. **Plugin skills authored in CBP MUST set this explicitly** — `inherit` is not permitted; defaults to `sonnet`. See [/cbp-build-cc-mode](../../build-cc-mode/SKILL.md) for the canonical matrix |
+| `effort` | Override effort level (`low`/`medium`/`high`/`xhigh`/`max`). **Plugin skills authored in CBP MUST set this explicitly** (no commented-out placeholder); defaults to `xhigh`. See [/cbp-build-cc-mode](../../build-cc-mode/SKILL.md) for the matrix |
+| `context` | `fork` → run in a subagent |
+| `agent` | Subagent type when `context: fork` — built-in or custom |
+| `hooks` | Hooks scoped to this skill's lifecycle |
+| `paths` | Globs that auto-load the skill when matching files are in play |
+| `shell` | `bash` (default) or `powershell` for `!`-commands |
+
+## Character budget
+
+Combined `description` + `when_to_use` truncates at **1,536 characters** in the skill listing. Front-load the key use case.
+
+Total skill-description budget in context: 1% of the context window (fallback 8,000 chars). Raise with `SLASH_COMMAND_TOOL_CHAR_BUDGET` env var.
+
+## Invocation × loading matrix
+
+| Frontmatter | You can invoke | Claude can invoke | When loaded |
+|-------------|----------------|-------------------|-------------|
+| (default) | Yes | Yes | Description in context; body loads on invoke |
+| `disable-model-invocation: true` | Yes | No | Description NOT in context; body loads on user invoke |
+| `user-invocable: false` | No | Yes | Description in context; body loads on auto-invoke |

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

@@ -0,0 +1,60 @@
+# Skill String Substitutions
+
+Source: official Claude Code skills spec.
+
+| Placeholder | Expands to |
+|-------------|------------|
+| `$ARGUMENTS` | Full argument string as typed |
+| `$ARGUMENTS[N]` | Nth positional arg (0-indexed, shell-quoted) |
+| `$N` | Shorthand for `$ARGUMENTS[N]` |
+| `$name` | Named arg declared in `arguments:` frontmatter |
+| `${CLAUDE_SESSION_ID}` | Current session ID |
+| `${CLAUDE_SKILL_DIR}` | Skill's own directory (use to reference bundled files) |
+
+## Quoting rules
+
+Indexed args use shell-style quoting. Wrap multi-word values:
+
+```
+/my-skill "hello world" second
+```
+
+- `$0` → `hello world`
+- `$1` → `second`
+- `$ARGUMENTS` → the full raw string
+
+## Named args example
+
+```yaml
+---
+name: migrate-component
+arguments: [component, source, target]
+---
+
+Migrate $component from $source to $target.
+```
+
+Invocation: `/migrate-component SearchBar React Vue`
+
+## Fallback
+
+If the user passes arguments but the body has no placeholder, Claude Code appends `ARGUMENTS: <input>` to the end of the content.
+
+## Dynamic context (preprocessing)
+
+The `` !`<cmd>` `` syntax runs *before* Claude sees the skill:
+
+```markdown
+- Status: !`git status --short`
+```
+
+Multi-line fenced form:
+
+```markdown
+```!
+node --version
+pnpm test -- --listFailingTests
+```
+```
+
+Output replaces the placeholder. Claude only sees the rendered prompt, not the raw command. Can be disabled globally with `disableSkillShellExecution: true` in settings.

package/templates/skills/cbp-build-cc-skill/scripts/validate-skill.sh

@@ -0,0 +1,90 @@
+#!/bin/bash
+# Validate a Claude Code skill file.
+# Usage: validate-skill.sh <path-to-SKILL.md>
+# Exit 0 = valid, exit 1 = invalid (errors printed to stderr).
+
+set -euo pipefail
+
+FILE="${1:?Usage: validate-skill.sh <path-to-SKILL.md>}"
+
+if [ ! -f "$FILE" ]; then
+  echo "ERROR: file not found: $FILE" >&2
+  exit 1
+fi
+
+errors=0
+err() { echo "  - $1" >&2; errors=$((errors + 1)); }
+
+# Must be named SKILL.md
+if [ "$(basename "$FILE")" != "SKILL.md" ]; then
+  err "file must be named SKILL.md (got $(basename "$FILE"))"
+fi
+
+# Directory name should match name field
+dir=$(basename "$(dirname "$FILE")")
+
+if ! head -1 "$FILE" | grep -qE '^---\s*$'; then
+  err "missing YAML frontmatter opener '---'"
+fi
+
+fm=$(awk '/^---[[:space:]]*$/{n++; next} n==1{print} n==2{exit}' "$FILE")
+
+# Name: if present, must be kebab-case and match directory
+if grep -qE '^name:\s*' <<< "$fm"; then
+  name=$(grep -E '^name:' <<< "$fm" | head -1 | sed -E 's/^name:[[:space:]]*//; s/[[:space:]]*$//; s/^"(.*)"$/\1/')
+  if ! [[ "$name" =~ ^[a-z0-9]+(-[a-z0-9]+)*$ ]]; then
+    err "name must be lowercase kebab-case (got '$name')"
+  fi
+  if [ ${#name} -gt 64 ]; then
+    err "name exceeds 64 chars (got ${#name})"
+  fi
+  if [ "$name" != "$dir" ]; then
+    err "name '$name' does not match directory '$dir'"
+  fi
+fi
+
+# Description recommended
+grep -qE '^description:\s*' <<< "$fm" || echo "  WARN: no description — Claude will use first paragraph" >&2
+
+# CBP scope required
+grep -qE '^scope:\s*' <<< "$fm" || err "missing CBP required field: scope (org-shared|project-shared|repo-only:<repo-name>)"
+
+# Model (if present)
+model=$(grep -E '^model:' <<< "$fm" | head -1 | sed -E 's/^model:[[:space:]]*//; s/[[:space:]]*$//; s/^"(.*)"$/\1/' || true)
+if [ -n "$model" ] && [[ ! "$model" =~ ^(sonnet|opus|haiku|inherit|claude-.+)$ ]]; then
+  err "model invalid: '$model'"
+fi
+
+# Effort (if present)
+effort=$(grep -E '^effort:' <<< "$fm" | head -1 | sed -E 's/^effort:[[:space:]]*//; s/[[:space:]]*$//; s/^"(.*)"$/\1/' || true)
+if [ -n "$effort" ] && [[ ! "$effort" =~ ^(low|medium|high|xhigh|max)$ ]]; then
+  err "effort invalid: '$effort'"
+fi
+
+# Context (if present)
+ctx=$(grep -E '^context:' <<< "$fm" | head -1 | sed -E 's/^context:[[:space:]]*//; s/[[:space:]]*$//; s/^"(.*)"$/\1/' || true)
+if [ -n "$ctx" ] && [ "$ctx" != "fork" ]; then
+  err "context only supports 'fork' (got '$ctx')"
+fi
+
+# Warn if context: fork without a task body
+if [ "$ctx" = "fork" ]; then
+  body=$(awk '/^---[[:space:]]*$/{n++; next} n>=2{print}' "$FILE")
+  if [ -z "$(echo "$body" | tr -d '[:space:]')" ]; then
+    err "context: fork requires an actionable body; the skill body is empty"
+  fi
+fi
+
+# Line count advisory
+lines=$(wc -l < "$FILE")
+if [ "$lines" -gt 300 ]; then
+  echo "  WARN: SKILL.md is $lines lines (CBP recommends <300; hard limit 600 enforced by validate-structure-lengths.sh). Consider moving reference material to reference/*.md" >&2
+fi
+
+if [ "$errors" -gt 0 ]; then
+  echo "validation FAILED ($errors issue(s)) for $FILE" >&2
+  exit 1
+fi
+
+echo "validation OK: $FILE"
+exit 0

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

@@ -0,0 +1,51 @@
+---
+scope: org-shared  # CBP sync marker: org-shared | project-shared | repo-only:<repo-name>
+name: skill-name
+description: What this skill does and when to use it. Front-load the key use case — this is how Claude matches.
+# when_to_use: Additional trigger phrases and example requests
+# argument-hint: [file] [mode]
+# arguments: [file, mode]  # named positional args -> $file, $mode
+# disable-model-invocation: false  # true = only user can invoke via /name
+# user-invocable: true  # false = only Claude can invoke (hidden from / menu)
+# allowed-tools: Read, Grep, Glob, Bash(git status *)
+# review with /cbp-build-cc-mode if defaults don't fit this skill's purpose
+model: sonnet
+effort: xhigh
+# context: fork  # runs in a forked subagent
+# agent: Explore  # subagent type: Explore | Plan | general-purpose | <custom>
+# paths:  # glob patterns that scope auto-loading
+#   - "src/**/*.ts"
+# shell: bash  # bash | powershell (requires CLAUDE_CODE_USE_POWERSHELL_TOOL=1)
+# hooks:
+#   PreToolUse:
+#     - matcher: "Bash"
+#       hooks:
+#         - type: command
+#           command: "./scripts/validate.sh"
+---
+
+# Skill title
+
+One-line purpose.
+
+## When to use
+
+- [Trigger 1]
+- [Trigger 2]
+
+## Instructions
+
+1. [First concrete step]
+2. [Second step]
+3. [Third step]
+
+## Arguments
+
+`$ARGUMENTS` — [what the user passes]
+
+(Or named: `$file` is the first arg, `$mode` is the second.)
+
+## Additional resources
+
+- Template: [templates/example.md](templates/example.md)
+- Reference: [reference/fields.md](reference/fields.md)

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

@@ -0,0 +1,156 @@
+---
+scope: org-shared
+name: cbp-checkpoint-check
+description: Full re-evaluation of a checkpoint with before/after comparison
+argument-hint: [CHK-NNN]
+effort: xhigh
+---
+
+# Checkpoint Check Command
+
+Full re-evaluation: compares initial ideas vs delivered work, aggregates files across all tasks, checkpoint-level file approval, final QA, user discussion.
+
+## Instructions
+
+### Step 1: Identify Checkpoint
+
+**If arguments provided:** Parse `$ARGUMENTS` for CHK-NNN format, extract number. Use MCP `get_checkpoints` to find by number.
+
+**If NO arguments:** Use MCP `get_current_task` to get the active checkpoint.
+
+If no checkpoint found, show error and stop.
+
+### Step 2: Load All Data
+
+1. Get checkpoint details (context, research, qa, ideas, goal, user_context)
+2. Use MCP `get_tasks` for the checkpoint
+3. For each task, use MCP `get_rounds` to get all rounds
+
+### Step 3: Before/After Comparison
+
+Compare the checkpoint's initial state vs delivered work:
+
+```
+## Before/After: CHK-[NNN]
+
+### Initial Ideas
+[List checkpoint.ideas descriptions]
+
+### Initial Goal
+[checkpoint.goal]
+
+### Delivered Work
+| Task | Title | Status | Rounds | Key Outcome |
+|------|-------|--------|--------|-------------|
+| TASK-[N] | [title] | [status] | [round count] | [brief from task.context.check_verdict] |
+
+### Alignment
+- [For each idea: was it addressed? By which task(s)?]
+- [Any ideas not addressed?]
+- [Any scope additions not in original ideas?]
+```
+
+### Step 4: Aggregate Files Changed
+
+Collect ALL files_changed across ALL tasks (deduplicated, latest action wins):
+
+```
+### Shared File Tracking ([N] total files)
+| File | Tasks Modified In | Final Status | User Approved |
+|------|-------------------|--------------|---------------|
+| [path] | TASK-1, TASK-3 | approved | yes/no |
+```
+
+**Checkpoint-level approval rules:**
+- Completed task/round file approvals CANNOT be changed
+- If user marks a file unapproved at checkpoint level → must create new task to fix
+- One file can appear in multiple tasks
+
+### Step 5: Final QA
+
+Aggregate QA from all tasks and rounds:
+
+```
+### QA Summary
+| Check | Status | Source |
+|-------|--------|--------|
+| Build | pass/fail | Last round of TASK-[N] |
+| Lint | pass/fail | Last round of TASK-[N] |
+| Types | pass/fail | Last round of TASK-[N] |
+
+### Task-Level QA
+| Task | Check Verdict | Testing Status | Fix Rounds |
+|------|---------------|----------------|------------|
+| TASK-[N] | READY | all_pass | [N] |
+```
+
+Re-run build/lint/types on current codebase to verify nothing regressed across tasks.
+
+### Step 5b: Whole-Checkpoint E2E
+
+Aggregate the files touched across all tasks (reusing Step 4's deduplicated table) and run e2e once against the union of pages they affect.
+
+1. **Build `pages_affected`** — derive from Step 4's `files_changed` union using the same heuristic as `cbp-test-e2e-agent` Step 5.1 (Next.js: `app/<route>/page.tsx` chains; Expo: screen files; Tauri: route components; fallback: directory-based grouping). Deduplicate by route / screen.
+
+2. **Spawn `cbp-test-e2e-agent`** via the Agent tool with:
+
+   `test_strategy` is intentionally omitted — the agent auto-detects per-app via its Step 1.5 DB tech-stack lookup (`get_repos`) and Step 2 filesystem reconciliation. Mixed-framework monorepos disambiguate via `tech_stack.apps[]`; pre-pass `test_strategy` only when DB tech_stack is empty AND filesystem probe is ambiguous.
+
+   ```yaml
+   input:
+     repo_id: [from .codebyplan/repo.json]
+     round_number: 0                  # sentinel — "whole checkpoint"
+     whole_checkpoint_mode: true      # skips R2+ filter; runs full union
+     files_changed: [union across tasks]
+     pages_affected: [aggregated]
+     has_auth: [boolean, from .codebyplan/server.json + repo]
+     dev_server_port: [from .codebyplan/server.json]
+   ```
+
+3. **Wait for completion.** The agent's output carries `whole_checkpoint_aggregated: true` confirming whole-checkpoint formatting.
+
+4. **On pass** (`e2e_output.status === 'completed'` AND `e2e_output.test_results.failed === 0`): append a row to the Step 5 QA Summary table:
+   ```
+   | Checkpoint E2E | pass | aggregated |
+   ```
+   Continue to Step 6.
+
+5. **On fail** (`e2e_output.status === 'failed'` OR `e2e_output.test_results.failed > 0`): build a failure summary from `e2e_output.test_results.failures[]` grouped by `category`. Surface via `AskUserQuestion`:
+   - **(a) Create fix-task in CHK-{NNN} (recommended)** — invoke MCP `create_task` with `checkpoint_id=current_checkpoint_id`, `title="Fix checkpoint-level e2e failures (CHK-{NNN})"`, `requirements` containing the detailed failure breakdown (category counts, files involved, pages broken, screenshot paths from `e2e_output.screenshots[]`), AND `context: { source_checkpoint_id, e2e_failure_summary: { category_counts, pages_broken, screenshot_paths }, fix_type: "checkpoint_e2e" }` so downstream `cbp-task-planner` Phase 1.5 can verify failure premises programmatically without re-parsing the requirements text. Per `infra-issue-absorption.md` "Resolve-in-Current-Scope by Default", checkpoint-level e2e failures absorb into the active checkpoint — not standalone.
+   - **(b) Surface as warning only — proceed to checkpoint-end** — append `| Checkpoint E2E | warning | N failures (deferred) |` to Step 5 QA Summary; continue to Step 6.
+   - **(c) Halt — review manually** — STOP and wait for the user.
+
+   See `infra-issue-absorption.md` Catalog row "Checkpoint-level e2e failure" for the routing rationale.
+
+### Step 6: User Discussion
+
+Present findings and discuss with user:
+
+```
+### Assessment
+
+**All ideas addressed**: [yes/no — list gaps if any]
+**All files approved**: [yes/no — list unapproved if any]
+**All QA passed**: [yes/no — list failures if any]
+**Production ready**: [yes/no — reasoning]
+```
+
+If unapproved files exist:
+- Suggest creating a new task to address them
+- **STOP** — wait for user decision
+
+### Step 7: Save Results
+
+Update checkpoint via MCP `update_checkpoint`:
+- `qa`: aggregated QA results
+- `context`: add `check_results` with before/after, file summary, assessment
+
+### Step 8: Route
+
+If all clear, auto-trigger `/cbp-checkpoint-end`.
+
+## Integration
+
+- **Reads**: MCP `get_checkpoints`, `get_tasks`, `get_rounds`, `get_current_task`
+- **Writes**: MCP `update_checkpoint` (qa, context)
+- **Triggers**: `/cbp-checkpoint-end` (auto, if ready) or STOPS for `/cbp-task-create` (if issues)