codebyplan 1.13.48 → 1.13.50

package/dist/cli.js

@@ -39,7 +39,7 @@ var VERSION, PACKAGE_NAME;
 var init_version = __esm({
   "src/lib/version.ts"() {
     "use strict";
-    VERSION = "1.13.48";
+    VERSION = "1.13.50";
     PACKAGE_NAME = "codebyplan";
   }
 });
@@ -639,6 +639,7 @@ var init_gitignore_block = __esm({
       ".codebyplan/statusline.local.json",
       ".codebyplan/worktree.local.json",
       ".codebyplan/state/",
+      ".codebyplan/clear/",
       ".codebyplan/todo/",
       ".codebyplan/claude-status.local.json",
       ".codebyplan.local.json"

package/package.json

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

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

@@ -239,18 +239,13 @@ When the executor received a `wave` input with a non-empty `wave.skill_preloads[
 For each entry in `wave.skill_preloads[]`, invoke the named skill via the Skill tool BEFORE Step 3 (Execute). Invoke in order:
 
 1. `cbp-frontend-design` — if present, invoke FIRST (aesthetic direction before code)
-2. `cbp-frontend-a11y` — if present, invoke AFTER `cbp-frontend-design` (accessibility obligations)
-3. Any other skill preload — invoke in list order
+2. Any other skill preload — invoke in list order
 
 Record completion:
 ```yaml
 round.context.frontend_design_loaded: true   # if cbp-frontend-design was preloaded
-round.context.frontend_a11y_loaded: true     # if cbp-frontend-a11y was preloaded
-round.context.frontend_a11y_checklist: [items from cbp-frontend-a11y/SKILL.md Phase 6 output]  # only when cbp-frontend-a11y was preloaded for this wave
 ```
 
-When cbp-frontend-a11y is preloaded, capture its Phase 6 per-component checklist output verbatim into `round.context.frontend_a11y_checklist`. Step 3 reads this for accessibility enforcement during code emission.
-
 If `wave` is absent or `wave.skill_preloads[]` is empty, skip this step — Step 2.7 handles the non-wave UI pre-read path.
 
 **Why step 2.6 and 2.7 coexist**: Step 2.7 fires for non-wave rounds when the executor detects UI files directly. Step 2.6 fires for wave rounds where the planner already determined the preloads. They cover the same skill but via different trigger paths; the round.context recording is identical so downstream steps behave uniformly.
@@ -315,6 +310,7 @@ When the approved plan includes specialized work, delegate to sub-executor agent
 | Work Type | Agent | When to Delegate |
 |-----------|-------|-----------------|
 | Supabase migrations, RLS, types | `cbp-database-agent` | Plan includes DB schema changes, RLS policies, or type generation |
+| Stripe integration (Checkout, webhooks, subscriptions, customer portal) | `cbp-stripe-agent` | Plan includes Stripe work (files under `stripe/`, or steps referencing `payment`, `checkout`, `webhook`, `subscription`, or `approved_plan.stripe_work === true`) |
 | Batch identical-structure file writes (≥4 files) | `general-purpose` (background) | Plan has 4+ independent files, no shared state, no ordered dependency |
 | `.claude/` infrastructure deliverables | `cbp-cc-executor` | `files_to_modify[]` includes **≥2** `.claude/` files (rules, skills, agents, context, hooks, settings, CLAUDE.md). A single `.claude/` file edit stays on Step 0 Skill-tool routing |
 
@@ -324,6 +320,12 @@ When the approved plan includes specialized work, delegate to sub-executor agent
 3. Wait for completion, merge files_changed into executor output
 4. Continue with remaining non-DB steps
 
+**How to delegate to `cbp-stripe-agent`:**
+1. Collect all Stripe-related steps from the plan
+2. Spawn `cbp-stripe-agent` via Agent tool with those steps and `files_changed_scope` set to the executor's current `files_to_modify[]` paths
+3. Wait for completion, merge files_changed into executor output
+4. Continue with remaining non-Stripe steps
+
 **When NOT to delegate:**
 - Simple Supabase queries in application code (executor handles these)
 - Only delegate schema/migration/RLS/type generation work

package/templates/agents/cbp-stripe-agent.md

@@ -0,0 +1,173 @@
+---
+scope: org-shared
+name: cbp-stripe-agent
+description: Stripe integration specialist. Writes Stripe code (Checkout, webhooks, subscriptions, customer portal) in the consuming app and optionally drives live Stripe via MCP. Spawned as sub-executor by round-executor when the plan includes Stripe work.
+tools: Read, Write, Edit, Glob, Grep, Bash, AskUserQuestion
+model: sonnet
+effort: xhigh
+---
+
+# Stripe Agent
+
+Stripe integration specialist for payments, billing, webhooks, Connect, Tax, and Treasury.
+
+## Purpose
+
+Handles Stripe integration work when a round's plan includes payment code. Spawned by
+round-executor as a sub-executor, not directly by `/cbp-round-start`. Two operating modes:
+
+- **Primary (always)** — writes/modifies Stripe integration code in the consuming app using
+  the current Stripe Node SDK, guided by the `cbp-stripe` skill's API-selection routing.
+- **Optional (opt-in)** — when a Stripe MCP server is configured AND a restricted/test key is
+  present, scaffolds live test data (products, prices, payment links) via that server. Absent
+  either, it degrades silently to code-only — never a hard failure.
+
+## Input Contract
+
+```yaml
+input:
+  stripe_tasks: [{step_number, description, type}]  # Stripe-related plan steps
+  files_changed_scope: string[]                     # paths the round is allowed to touch
+  repo_id: string
+  context:
+    checkpoint_goal: string
+    task_requirements: string
+```
+
+## Output Contract
+
+```yaml
+output:
+  status: 'completed' | 'blocked' | 'failed'
+  live_path_used: boolean                # true only when the optional MCP path ran
+  files_changed:
+    - path: string
+      action: 'created' | 'modified' | 'deleted'
+  stripe_resources_created:              # populated only when live_path_used === true
+    - type: string                       # e.g. 'product' | 'price' | 'payment_link'
+      id: string
+      mode: 'test'                       # ALWAYS test — live mode is never scaffolded here
+  issues_encountered: string[]
+```
+
+## Workflow
+
+### Pre-flight: Load Guidance + Resolve Live-Path Availability
+
+Run both checks before writing any code:
+
+1. **Load the `cbp-stripe` skill** for API-selection routing and security rules. Invoke the
+   `cbp-stripe` Skill (or Read `.claude/skills/cbp-stripe/SKILL.md` and the relevant
+   `reference/*.md` when Skill dispatch is unavailable). This is the source of truth for
+   which Stripe API to use per intent — do not select APIs from memory.
+
+2. **Resolve live-path availability.** The optional MCP path runs ONLY when ALL hold:
+   - `STRIPE_SECRET_KEY` (or an equivalent restricted-key env var) is present AND is a
+     **test-mode** key. Check presence + prefix WITHOUT printing the secret (never `echo` or
+     `printenv` the raw value):
+
+     ```bash
+     case "${STRIPE_SECRET_KEY:-}" in
+       sk_test_*|rk_test_*) echo "live path: eligible (test key)" ;;
+       sk_live_*|rk_live_*) echo "live path: refused (live-mode key)" ;;
+       "")                  echo "live path: skipped (no key)" ;;
+       *)                   echo "live path: refused (unknown prefix ${STRIPE_SECRET_KEY:0:8})" ;;
+     esac
+     ```
+
+     Only `sk_test_`/`rk_test_` enable the live path; live-mode keys (`sk_live_`, `rk_live_`)
+     are refused so a dev round never scaffolds real Stripe data.
+   - A Stripe MCP server is reachable. Stripe MCP tools (`mcp__stripe__*`) are NOT listed in
+     this agent's frontmatter because the server is optional and absent by default; discover
+     them at runtime via `ToolSearch` (query `mcp__stripe`). Setup is documented in
+     `.claude/skills/cbp-stripe/reference/stripe-mcp-setup.md`.
+
+   If any condition fails, set `live_path_used = false` and proceed code-only. Record the
+   reason in `issues_encountered[]` (e.g. `live path skipped: no STRIPE_SECRET_KEY`). This is
+   a normal outcome, NOT a block.
+
+### Step 1: Analyze Stripe Tasks
+
+Read `stripe_tasks` and categorize by type, mapping each to the `cbp-stripe` routing table:
+
+- **One-time payments** → Checkout Sessions (`reference/payments.md`)
+- **Custom payment UI** → Checkout Sessions + Payment Element (`reference/payments.md`)
+- **Saving a payment method** → Setup Intents (`reference/payments.md`)
+- **Subscriptions / recurring billing** → Billing APIs + Checkout Sessions, Customer Portal
+  (`reference/billing.md`)
+- **Webhooks** → signed event handler (`reference/security.md`)
+- **Marketplace / platform** → Connect Accounts v2 (`reference/connect.md`)
+- **Tax** → Stripe Tax (`reference/tax.md`); **embedded finance** → Treasury
+  (`reference/treasury.md`)
+
+### Step 2: Write Stripe Integration Code (PRIMARY)
+
+For each task, write or modify code in `files_changed_scope` using the current Stripe Node SDK:
+
+1. **Honor the critical rules from the skill**: never pass `payment_method_types` except for
+   the documented Terminal and Treasury-bank-account exceptions; prefer dynamic payment
+   methods.
+2. **Server-side key handling**: read the key from `process.env` only; never hardcode or log
+   it. Prefer a restricted key (`rk_`) over a secret key.
+3. **Next.js API routes that import `stripe` MUST export `export const dynamic =
+   'force-dynamic'`** at the top of the file (the SDK reads a runtime env var; static analysis
+   at build time fails without it). Source: `.claude/skills/cbp-frontend-design/reference/nextjs-scss.md`
+   Rule 6.
+4. **Webhook routes** must verify the signature with `stripe.webhooks.constructEvent(rawBody,
+   sig, secret)` against the raw (unparsed) body, and guard the `stripe-signature` header
+   (it is typed `string | string[] | undefined`) before use.
+5. Match the consuming app's existing conventions (error handling, response shape, file
+   layout). Verify the installed `stripe` major version (`grep '"stripe"' package.json`) and
+   write code for that version — the skill notes the latest API version, but consumer repos
+   may pin an older SDK.
+
+### Step 3: Scaffold Live Test Data (OPTIONAL — only when Pre-flight enabled the live path)
+
+When `live_path_used` is eligible AND a task explicitly needs live test data (e.g. "create a
+test product + price for the checkout demo"):
+
+1. Re-confirm the key prefix is `sk_test_` or `rk_test_` immediately before the first call.
+   Abort the live path on any live-mode key (`sk_live_` or `rk_live_`).
+2. Use the discovered Stripe MCP tools to create only what the task requires (products,
+   prices, payment links, test customers). Record each in `stripe_resources_created[]`.
+3. On ANY MCP error (server unreachable, auth rejected, rate limit), fall back to code-only:
+   set `live_path_used = false`, record the error in `issues_encountered[]`, and continue —
+   never block the round on the optional path.
+
+### Step 4: Verify
+
+1. For each changed `.ts`/`.tsx` file, run a scoped `npx tsc --noEmit` (or the app's
+   typecheck) on the changed set and confirm no new type errors.
+2. Confirm every API route importing `stripe` exports `dynamic = 'force-dynamic'`
+   (`grep -L "force-dynamic"` across the changed route files).
+3. Confirm no secret was committed: `grep -rE 'sk_live_|rk_live_|sk_test_[A-Za-z0-9]{16,}|rk_test_[A-Za-z0-9]{16,}'`
+   over the changed files returns nothing real. Live-key prefixes (`sk_live_`, `rk_live_`)
+   match with no length floor — a committed live key is never acceptable; test-key prefixes
+   carry a `{16,}` floor so doc placeholders like `sk_test_…` don't false-positive.
+
+### Step 5: Return Output
+
+Populate all output-contract fields. Include every file changed. Report the live-path outcome
+(used / skipped + reason) in `issues_encountered[]` for the audit trail.
+
+## When NOT to Use This Agent
+
+- Non-payment application code (round-executor handles these).
+- Reading Stripe data for display only with no integration change.
+- Designing the payment UX/visual layer — that is the frontend skills' job; this agent writes
+  the Stripe wiring beneath it.
+- Production / live-mode Stripe operations (`sk_live_`, `rk_live_`) — this agent refuses
+  live-mode keys by design; only test-mode keys enable the optional live path.
+
+## Integration
+
+- **Spawned by**: `round-executor` (as sub-executor when the plan includes Stripe work — see
+  `cbp-round-executor` Step 3.5 and `/cbp-round-execute` Step 3b-stripe dispatch).
+- **Returns to**: `round-executor` (merges `files_changed[]` into the round output).
+- **Loads**: the `cbp-stripe` skill (`.claude/skills/cbp-stripe/SKILL.md` + `reference/*.md`)
+  for API selection and security rules.
+- **Optional tools**: Stripe MCP (`mcp__stripe__*`) discovered at runtime via `ToolSearch`
+  when a server is configured per `.claude/skills/cbp-stripe/reference/stripe-mcp-setup.md` —
+  intentionally absent from frontmatter because the server is opt-in.
+- **Rule**: never commit Stripe secrets; restricted/test keys only; degrade to code-only when
+  the live path is unavailable.

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

@@ -533,7 +533,7 @@ After Phase 5 (solution design) and before Phase 6 (context summary), decompose
 1. **Identify natural cut points**: look for cross-app boundaries (files in `apps/web/` vs `apps/backend/` vs `apps/desktop/`), packages with no shared state, or dependency ordering (DB migration must precede app code using the new schema).
 2. **Check disjoint-files invariant**: no file may appear in two waves. If a shared file is needed by two waves, assign it to the earlier wave and make the later wave `depends_on` the earlier.
 3. **Check DAG invariant**: `depends_on[]` must be acyclic. Any cycle is a plan error — resolve by merging the cyclic waves.
-4. **Populate `skill_preloads[]`**: for each wave whose `files[]` contains UI-bearing paths (`*.tsx`, `*.jsx`, `*.scss`, etc.), add `"frontend-design"` and `"frontend-a11y"` to `skill_preloads[]` (in that order).
+4. **Populate `skill_preloads[]`**: for each wave whose `files[]` contains UI-bearing paths (`*.tsx`, `*.jsx`, `*.scss`, etc.), add `"frontend-design"` to `skill_preloads[]`.
 5. **Single-wave default**: if no independence is found, produce ONE wave covering all files. Parallel waves add orchestration overhead — only decompose when the benefit is clear.
 6. **15-file cap**: after decomposition (including the single-wave default), count files in each wave. If any wave would exceed 15 files, auto-split it using the proximity-split algorithm in priority order: (a) **shared directory subtree** — split at the deepest common ancestor that produces two groups each ≥3 files; (b) **shared module** — split at the next directory level below the common ancestor; (c) **arbitrary boundary** — split at the 15-file boundary and add a one-line `note` on the continuation wave explaining the boundary. Split siblings are **independent**: do NOT add `depends_on` between them unless a real shared-file or data dependency requires ordering. **Tail rule**: choose boundaries so every resulting wave holds 3–15 files. A split must never leave a wave with <3 files; rebalance the boundary rather than absorbing a tail into a sibling in a way that pushes it above 15. The 3–15 range is a hard invariant — there is no exception above 15. **Apply the cap iteratively**: after a split, re-check each resulting wave and split again any that still exceeds 15 — a 40-file single-concern plan therefore yields ≥3 waves. When no natural boundary yields groups each ≥3 files, take the smallest ≥3-file prefix as one wave and apply the same procedure to the remainder. The single-wave default is itself subject to this cap. See `rules/parallel-waves.md` for the full algorithm and invariants.
 
@@ -559,7 +559,7 @@ printf '%s' "$PLAN_JSON" | codebyplan validate-waves --json
 
 (`$PLAN_JSON` is the `{ "waves": [...] }` structure; pass a file path as the first argument instead of stdin if preferred.) Exit 0 = invariants I–III satisfied. Exit non-zero = one or more violations — the `--json` `violations[]` array names the failing invariant (`I`/`II`/`III`) and offending wave/file; fix the decomposition and re-run before emitting the plan. The validator does NOT check invariant IV (UI skill preloads) — that remains a manual step:
 
-- [ ] UI-bearing waves have `frontend-design` + `frontend-a11y` in `skill_preloads[]` (invariant IV — not covered by `validate-waves`)
+- [ ] UI-bearing waves have `frontend-design` in `skill_preloads[]` (invariant IV — not covered by `validate-waves`)
 
 ### Phase 6: Build Context Summary
 

package/templates/hooks/cbp-skill-context-guard.sh

@@ -0,0 +1,52 @@
+#!/bin/bash
+# @scope: org-shared
+# Hook: PreToolUse (Skill)
+# Purpose: Deny heavy close-out skills when context window > CBP_CONTEXT_WARN_TOKENS (default 200000).
+#          Reads transcript_path from stdin, sums the latest assistant message.usage — same logic
+#          as cbp-context-window-notify.sh. If total exceeds threshold AND the skill is in the
+#          heavy close-out allowlist, emits hookSpecificOutput.permissionDecision=deny directing
+#          Claude to run /cbp-clear-prep. Always exits 0 — fail-open.
+
+set -euo pipefail
+
+INPUT=$(cat)
+SKILL_NAME=$(echo "$INPUT" | jq -r '.tool_input.skill // .tool_input.skill_name // ""' 2>/dev/null) || SKILL_NAME=""
+TRANSCRIPT=$(echo "$INPUT" | jq -r '.transcript_path // ""' 2>/dev/null) || TRANSCRIPT=""
+
+# Fast-path: no transcript → pass through
+[ -z "$TRANSCRIPT" ] && exit 0
+[ ! -f "$TRANSCRIPT" ] && exit 0
+
+THRESHOLD="${CBP_CONTEXT_WARN_TOKENS:-200000}"
+
+# Heavy close-out allowlist (cbp-clear-prep + cbp-clear-continue deliberately excluded so
+# they always run even when context > threshold).
+HEAVY_SKILLS="cbp-round-execute cbp-task-testing cbp-standalone-task-testing cbp-checkpoint-check cbp-checkpoint-end"
+
+# Cheap allowlist check before summing tokens
+IS_HEAVY=false
+for heavy in $HEAVY_SKILLS; do
+  if [ "$SKILL_NAME" = "$heavy" ]; then
+    IS_HEAVY=true
+    break
+  fi
+done
+[ "$IS_HEAVY" = "false" ] && exit 0
+
+# Token sum — same logic as cbp-context-window-notify.sh
+TOTAL=$(tail -n 400 "$TRANSCRIPT" \
+  | jq -rR 'fromjson? | select(.message.usage != null)
+      | (.message.usage
+         | ((.input_tokens // 0) + (.cache_creation_input_tokens // 0) + (.cache_read_input_tokens // 0)))' \
+  2>/dev/null | tail -1) || TOTAL=0
+TOTAL="${TOTAL:-0}"
+
+if [ "$TOTAL" -ge "$THRESHOLD" ] 2>/dev/null; then
+  jq -n \
+    --argjson tokens "$TOTAL" \
+    --argjson threshold "$THRESHOLD" \
+    --arg skill "$SKILL_NAME" \
+    '{hookSpecificOutput:{permissionDecision:"deny",permissionDecisionReason:("Context window at \($tokens) tokens (threshold \($threshold)) is too large to safely run /\($skill). Run /cbp-clear-prep now to capture a handoff, then /clear, then /cbp-clear-continue to resume.")}}'
+fi
+
+exit 0

package/templates/hooks/cbp-test-hooks.sh

@@ -527,6 +527,150 @@ fi
 
 echo ""
 
+# ===== HOOK SMOKE TESTS — cbp-skill-context-guard =====
+echo "## Hook Smoke Tests — cbp-skill-context-guard (CHK-217)"
+
+GUARD_HOOK="$HOOKS_DIR/cbp-skill-context-guard.sh"
+FIXTURES_GUARD="$HOOKS_DIR/__test-fixtures__/cbp-context-window-notify"
+
+if [ ! -f "$GUARD_HOOK" ]; then
+  test_result "cbp-skill-context-guard.sh present" "passed" "missing"
+else
+
+  # Case 1: over-threshold + cbp-round-execute (heavy) → permissionDecision=deny
+  STDIN=$(jq -n \
+    --arg t "$FIXTURES_GUARD/over-threshold.jsonl" \
+    --arg s "cbp-round-execute" \
+    '{transcript_path:$t,tool_input:{skill:$s}}')
+  OUTPUT=$(echo "$STDIN" | CBP_CONTEXT_WARN_TOKENS=200000 bash "$GUARD_HOOK" 2>/dev/null)
+  EXIT_CODE=$?
+  if [ "$EXIT_CODE" = "0" ] \
+     && echo "$OUTPUT" | jq -e '.hookSpecificOutput.permissionDecision == "deny"' >/dev/null 2>&1; then
+    test_result "cbp-skill-context-guard.sh over-threshold + cbp-round-execute → deny" "passed" "passed"
+  else
+    test_result "cbp-skill-context-guard.sh over-threshold + cbp-round-execute → deny" "passed" "failed (exit=$EXIT_CODE output=$(echo "$OUTPUT" | head -c 80))"
+  fi
+
+  # Case 2: over-threshold + cbp-clear-prep (exempt) → empty stdout, exit 0
+  STDIN=$(jq -n \
+    --arg t "$FIXTURES_GUARD/over-threshold.jsonl" \
+    --arg s "cbp-clear-prep" \
+    '{transcript_path:$t,tool_input:{skill:$s}}')
+  OUTPUT=$(echo "$STDIN" | CBP_CONTEXT_WARN_TOKENS=200000 bash "$GUARD_HOOK" 2>/dev/null)
+  EXIT_CODE=$?
+  if [ "$EXIT_CODE" = "0" ] && [ -z "$OUTPUT" ]; then
+    test_result "cbp-skill-context-guard.sh over-threshold + cbp-clear-prep (exempt) → empty stdout" "passed" "passed"
+  else
+    test_result "cbp-skill-context-guard.sh over-threshold + cbp-clear-prep (exempt) → empty stdout" "passed" "failed (exit=$EXIT_CODE)"
+  fi
+
+  # Case 3: over-threshold + cbp-clear-continue (exempt) → empty stdout, exit 0
+  STDIN=$(jq -n \
+    --arg t "$FIXTURES_GUARD/over-threshold.jsonl" \
+    --arg s "cbp-clear-continue" \
+    '{transcript_path:$t,tool_input:{skill:$s}}')
+  OUTPUT=$(echo "$STDIN" | CBP_CONTEXT_WARN_TOKENS=200000 bash "$GUARD_HOOK" 2>/dev/null)
+  EXIT_CODE=$?
+  if [ "$EXIT_CODE" = "0" ] && [ -z "$OUTPUT" ]; then
+    test_result "cbp-skill-context-guard.sh over-threshold + cbp-clear-continue (exempt) → empty stdout" "passed" "passed"
+  else
+    test_result "cbp-skill-context-guard.sh over-threshold + cbp-clear-continue (exempt) → empty stdout" "passed" "failed (exit=$EXIT_CODE)"
+  fi
+
+  # Case 4: under-threshold + cbp-round-execute → empty stdout, exit 0
+  STDIN=$(jq -n \
+    --arg t "$FIXTURES_GUARD/under-threshold.jsonl" \
+    --arg s "cbp-round-execute" \
+    '{transcript_path:$t,tool_input:{skill:$s}}')
+  OUTPUT=$(echo "$STDIN" | CBP_CONTEXT_WARN_TOKENS=200000 bash "$GUARD_HOOK" 2>/dev/null)
+  EXIT_CODE=$?
+  if [ "$EXIT_CODE" = "0" ] && [ -z "$OUTPUT" ]; then
+    test_result "cbp-skill-context-guard.sh under-threshold + cbp-round-execute → empty stdout" "passed" "passed"
+  else
+    test_result "cbp-skill-context-guard.sh under-threshold + cbp-round-execute → empty stdout" "passed" "failed (exit=$EXIT_CODE)"
+  fi
+
+  # Case 5: empty skill_name → empty stdout, exit 0
+  STDIN=$(jq -n \
+    --arg t "$FIXTURES_GUARD/over-threshold.jsonl" \
+    '{transcript_path:$t,tool_input:{}}')
+  OUTPUT=$(echo "$STDIN" | CBP_CONTEXT_WARN_TOKENS=200000 bash "$GUARD_HOOK" 2>/dev/null)
+  EXIT_CODE=$?
+  if [ "$EXIT_CODE" = "0" ] && [ -z "$OUTPUT" ]; then
+    test_result "cbp-skill-context-guard.sh empty skill_name → empty stdout" "passed" "passed"
+  else
+    test_result "cbp-skill-context-guard.sh empty skill_name → empty stdout" "passed" "failed (exit=$EXIT_CODE)"
+  fi
+
+  # Case 6: missing transcript_path → empty stdout, exit 0 (fast-path)
+  STDIN=$(jq -n --arg s "cbp-round-execute" '{tool_input:{skill:$s}}')
+  OUTPUT=$(echo "$STDIN" | CBP_CONTEXT_WARN_TOKENS=200000 bash "$GUARD_HOOK" 2>/dev/null)
+  EXIT_CODE=$?
+  if [ "$EXIT_CODE" = "0" ] && [ -z "$OUTPUT" ]; then
+    test_result "cbp-skill-context-guard.sh missing transcript_path → empty stdout" "passed" "passed"
+  else
+    test_result "cbp-skill-context-guard.sh missing transcript_path → empty stdout" "passed" "failed (exit=$EXIT_CODE)"
+  fi
+
+fi
+
+# ===== STRUCTURAL ASSERTIONS — cbp-clear-* skills (CHK-217) =====
+echo ""
+echo "## Structural Assertions — cbp-clear-* skills (CHK-217)"
+
+# cbp-clear-prep/SKILL.md: scope: org-shared + references handoff.md
+CLEAR_PREP_SKILL="$(dirname "$HOOKS_DIR")/skills/cbp-clear-prep/SKILL.md"
+if [ -f "$CLEAR_PREP_SKILL" ]; then
+  if grep -q 'scope: org-shared' "$CLEAR_PREP_SKILL"; then
+    test_result "cbp-clear-prep/SKILL.md has scope: org-shared" "passed" "passed"
+  else
+    test_result "cbp-clear-prep/SKILL.md has scope: org-shared" "passed" "missing"
+  fi
+  if grep -q 'handoff\.md' "$CLEAR_PREP_SKILL"; then
+    test_result "cbp-clear-prep/SKILL.md references handoff.md" "passed" "passed"
+  else
+    test_result "cbp-clear-prep/SKILL.md references handoff.md" "passed" "missing"
+  fi
+else
+  test_result "cbp-clear-prep/SKILL.md structural checks (file absent — skipped)" "passed" "passed"
+fi
+
+# cbp-clear-continue/SKILL.md: scope: org-shared + references handoff.md + has rm of handoff
+CLEAR_CONTINUE_SKILL="$(dirname "$HOOKS_DIR")/skills/cbp-clear-continue/SKILL.md"
+if [ -f "$CLEAR_CONTINUE_SKILL" ]; then
+  if grep -q 'scope: org-shared' "$CLEAR_CONTINUE_SKILL"; then
+    test_result "cbp-clear-continue/SKILL.md has scope: org-shared" "passed" "passed"
+  else
+    test_result "cbp-clear-continue/SKILL.md has scope: org-shared" "passed" "missing"
+  fi
+  if grep -q 'handoff\.md' "$CLEAR_CONTINUE_SKILL"; then
+    test_result "cbp-clear-continue/SKILL.md references handoff.md" "passed" "passed"
+  else
+    test_result "cbp-clear-continue/SKILL.md references handoff.md" "passed" "missing"
+  fi
+  if grep -Eq 'rm -f.*handoff' "$CLEAR_CONTINUE_SKILL"; then
+    test_result "cbp-clear-continue/SKILL.md has rm -f of handoff.md" "passed" "passed"
+  else
+    test_result "cbp-clear-continue/SKILL.md has rm -f of handoff.md" "passed" "missing"
+  fi
+else
+  test_result "cbp-clear-continue/SKILL.md structural checks (file absent — skipped)" "passed" "passed"
+fi
+
+# .gitignore contains .codebyplan/clear/
+REPO_GITIGNORE="${CLAUDE_PROJECT_DIR:-}/.gitignore"
+if [ -n "${CLAUDE_PROJECT_DIR:-}" ] && [ -f "$REPO_GITIGNORE" ]; then
+  if grep -q '\.codebyplan/clear/' "$REPO_GITIGNORE"; then
+    test_result ".gitignore contains .codebyplan/clear/" "passed" "passed"
+  else
+    test_result ".gitignore contains .codebyplan/clear/" "passed" "missing"
+  fi
+else
+  test_result ".gitignore check skipped (CLAUDE_PROJECT_DIR unset or no .gitignore)" "passed" "passed"
+fi
+
+echo ""
+
 # ===== SUMMARY =====
 echo "=== TEST SUMMARY ==="
 echo -e "Passed: ${GREEN}$PASSED${NC}"

package/templates/hooks/hooks.json

@@ -52,6 +52,15 @@
           }
         ]
       },
+      {
+        "matcher": "Skill",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/cbp-skill-context-guard.sh"
+          }
+        ]
+      },
       {
         "matcher": "mcp__codebyplan__(update_task|complete_task|update_checkpoint|create_checkpoint|create_task)",
         "hooks": [

package/templates/rules/model-invocation-convention.md

@@ -0,0 +1,40 @@
+# Model Invocation Convention
+
+CBP skills are **model-invocable by default**. Authors must omit `disable-model-invocation` unless
+a skill is strictly user-only (i.e. it must never auto-trigger from another skill).
+
+## Default: omit `disable-model-invocation`
+
+The absence of `disable-model-invocation` (or `disable-model-invocation: false`) is the normal
+state. It allows the skill to be auto-triggered via the Skill tool from within other skills —
+which is how the auto-trigger close-out flow works (e.g. `cbp-task-check` → `cbp-task-testing`,
+`cbp-task-testing` → `cbp-task-complete`).
+
+## The sole exception: `cbp-round-complete`
+
+`cbp-round-complete` sets `disable-model-invocation: true`. It is the permission-gated round
+finalizer: the user must explicitly run it after their own `git add` selections, so it must
+never auto-fire from within another skill. The `ask`-tier permission prompt on
+`Skill(cbp-round-complete)` is a secondary gate on top of this; the frontmatter flag is the
+primary model-invocation block.
+
+No other skill in the CBP framework sets this flag. Do NOT add it to new skills without a
+clear "user-only" rationale.
+
+## Human gates for auto-triggering skills
+
+For auto-trigger skills, the human checkpoint is expressed via two complementary mechanisms —
+not via `disable-model-invocation`:
+
+1. **`ask`-tier permission entry** in `settings.json` — the harness permission prompt is the
+   lightweight confirm gate. Skills in `ask` auto-fire silently ONLY after the user confirms.
+2. **Routing prose** inside the triggering skill — states explicitly which skill fires next and
+   under what condition, so the intent is auditable and overridable.
+
+See `.claude/skills/cbp-build-cc-settings/reference/cbp-permission-policy.md` for the full
+`allow` vs `ask` split and the auto-trigger + 200K context-guard model.
+
+## Related
+
+- `rules/scope-vocabulary.md` — scope marker conventions for managed vs user-created files
+- `cbp-build-cc-settings/reference/cbp-permission-policy.md` — allow/ask tiers

package/templates/rules/parallel-waves.md

@@ -33,7 +33,7 @@ Each entry in `plan.waves[]` carries these fields (source: `.claude/agents/cbp-t
   - Above 15: apply the proximity-split algorithm below.
   - Sole exception — trivially small plans are exempt from the lower bound: a plan with fewer than 3 total files uses one single wave, and a single-app plan with ≤5 total files MAY skip decomposition entirely (one wave, or `waves[]` omitted — see `cbp-task-planner` Phase 5.6). Zero waves (omitted `waves[]`) trivially satisfies this invariant.
 
-**(IV) UI skill preloads** — for each wave whose `files[]` contains UI-bearing paths (`*.tsx`, `*.jsx`, `*.scss`, etc.), add `"frontend-design"` and `"frontend-a11y"` to `skill_preloads[]` in that order (source: `.claude/agents/cbp-task-planner.md` Phase 5.6 step "Populate `skill_preloads[]`").
+**(IV) UI skill preloads** — for each wave whose `files[]` contains UI-bearing paths (`*.tsx`, `*.jsx`, `*.scss`, etc.), add `"frontend-design"` to `skill_preloads[]` (source: `.claude/agents/cbp-task-planner.md` Phase 5.6 step "Populate `skill_preloads[]`").
 
 ## Proximity-Split Algorithm
 

package/templates/rules/task-routing-recommendation.md

@@ -45,7 +45,7 @@ After task completion, routes use single-directive form (never A/B/C menus):
 
 **Checkpoint-bound task complete:**
 - More tasks in checkpoint → auto-triggers next task (same context)
-- Last task in checkpoint → `Next: /clear, then /cbp-checkpoint-check`
+- Last task in checkpoint → auto-triggers `cbp-checkpoint-check` (ask-tier permission prompt is the human gate; the 200K context guard handles oversized contexts)
 
 **Standalone task complete:**
 - Always → `Next: /cbp-session-end` (or `/cbp-standalone-task-create` for new work)

package/templates/settings.project.base.json

@@ -68,6 +68,18 @@
       "mcp__codebyplan__delete_session_log",
       "mcp__codebyplan__delete_worktree",
       "mcp__codebyplan__release_assignment",
+      "mcp__stripe__create_customer",
+      "mcp__stripe__create_product",
+      "mcp__stripe__create_price",
+      "mcp__stripe__create_payment_link",
+      "mcp__stripe__create_invoice",
+      "mcp__stripe__create_subscription",
+      "mcp__stripe__update_subscription",
+      "mcp__stripe__create_refund",
+      "mcp__stripe__list_customers",
+      "mcp__stripe__list_products",
+      "mcp__stripe__list_prices",
+      "mcp__stripe__list_invoices",
       "Bash(codebyplan setup:*)",
       "Bash(npx codebyplan setup:*)",
       "Bash(codebyplan create-org:*)",
@@ -104,7 +116,8 @@
       "Skill(cbp-build-cc-skill)",
       "Skill(cbp-checkpoint-plan)",
       "Skill(cbp-checkpoint-update)",
-      "Skill(cbp-frontend-a11y)",
+      "Skill(cbp-clear-continue)",
+      "Skill(cbp-clear-prep)",
       "Skill(cbp-frontend-design)",
       "Skill(cbp-frontend-ui)",
       "Skill(cbp-frontend-ux)",
@@ -127,6 +140,7 @@
       "Skill(cbp-ship-configure)",
       "Skill(cbp-standalone-task-check)",
       "Skill(cbp-standalone-task-testing)",
+      "Skill(cbp-stripe)",
       "Skill(cbp-supabase-branch-check)",
       "Skill(cbp-supabase-migrate)",
       "Skill(cbp-supabase-setup)",

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

@@ -45,6 +45,48 @@ The pre-existing dangerous-`rm -rf` blocks. This policy does not alter `deny` se
 
 When you add a skill / MCP tool / CLI subcommand, add its matching rule (`Skill(<name>)`, `mcp__codebyplan__<name>`, or `Bash(codebyplan <sub>:*)` + `Bash(npx codebyplan <sub>:*)`) to `allow` or `ask` in `templates/settings.project.base.json` — and mirror it into any dogfooding `.claude/settings.json`.
 
+## Auto-trigger + allow/ask gating model
+
+The CBP close-out flow uses **auto-triggers** instead of manual "Next: /cbp-X" directives.
+A skill invokes the next skill via the Skill tool at the appropriate routing branch.
+
+### How the human gate works
+
+- **`allow`-tier** skill: the harness auto-fires it silently when the triggering skill invokes it.
+  No permission prompt. Use for safe, routine-flow skills (e.g. `cbp-task-testing`,
+  `cbp-round-input`) where the trigger condition already encodes the human intent.
+- **`ask`-tier** skill: the harness pauses and shows a permission prompt before the skill runs.
+  **That prompt IS the human gate** — it replaces the old "Next: /cbp-X, run it yourself"
+  manual directive. Use for lifecycle/state-transition skills (e.g. `cbp-task-complete`,
+  `cbp-checkpoint-check`) where a deliberate confirmation is still desirable.
+
+This means:
+- A skill in `allow` that is auto-triggered fires silently — do NOT claim "the ask-tier prompt
+  is the gate" for it in routing prose.
+- A skill in `ask` that is auto-triggered shows a permission prompt — that prompt is the gate;
+  say so in the routing prose.
+
+### The 200K context guard
+
+The `cbp-skill-context-guard.sh` PreToolUse hook denies heavy close-out skills when the
+context window exceeds `CBP_CONTEXT_WARN_TOKENS` (default 200 000 tokens). The heavy allowlist
+is: `cbp-round-execute`, `cbp-task-testing`, `cbp-standalone-task-testing`,
+`cbp-checkpoint-check`, `cbp-checkpoint-end`.
+
+When the guard fires, it directs the model to run `/cbp-clear-prep` instead. The flow is:
+`cbp-clear-prep` (captures a handoff) → `/clear` (user command) → `cbp-clear-continue`
+(re-invokes the blocked skill in the fresh context).
+
+`cbp-clear-prep` and `cbp-clear-continue` are **excluded** from the guard's allowlist so they
+always run regardless of context size.
+
+Routing prose in triggering skills should NOT mandate an unconditional `/clear` before a heavy
+skill — the guard handles oversized contexts automatically. Drop "Run /clear first" directives
+from auto-trigger paths; only note the guard mechanism so the author understands when it fires.
+
+See `rules/model-invocation-convention.md` for the `disable-model-invocation` convention —
+authors must omit it on all skills except `cbp-round-complete`.
+
 ## Scope
 
 `scope: org-shared` — CBP-framework infrastructure that lands identically in every consuming repo via the `codebyplan` package.