codebyplan 1.13.41 → 1.13.43

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

package/package.json

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

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

@@ -212,6 +212,16 @@ If modifying managed files (`.claude/*`, `.claude/docs/architecture/*`, etc.):
 
 **Why:** Routing commands do this automatically. If you bypass routing, you MUST do source consultation manually. Skills contain coding patterns and conventions that must be followed.
 
+### Step 2.4: Architecture Map Consultation
+
+For ANY module you are about to edit (app code or managed files), check for a pre-computed architecture map:
+
+1. For each path in `files_to_modify`, derive its module and Glob `.claude/architecture/<module-slug>.md`.
+2. If a map exists, read it BEFORE Step 3 — it surfaces the module's boundaries, internal structure, dependencies, and where-things-live landmarks, reducing broad file-system scans.
+3. If `.claude/architecture/` is absent or the module has no map, proceed without it (not a blocker).
+
+See `.claude/context/architecture-map.md` for the full consultation contract. Unlike Step 2 (managed files only), this step fires for every round regardless of file type.
+
 ### Step 2.5: Search Before Creating
 
 For each file with action `create` in `files_to_modify`:

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

@@ -376,6 +376,11 @@ delegation_hint:
 
 Read `.claude/rules/*.md` and relevant architecture docs.
 
+If `.claude/architecture/` contains map file(s) for the target module(s), read them before
+finalizing scope — they provide pre-computed structural context (boundaries, dependencies,
+landmarks) that reduces the need for broad file-system scans. See
+`.claude/context/architecture-map.md` for the consultation contract.
+
 ### Phase 4: Clarify Requirements (Context-First)
 
 Before any AskUserQuestion call, check (1) `checkpoint.context`, (2) `task.context`, (3) codebase via Grep/Glob/Read. Only ask if all three fail. When asking, prefix with `Checked: [sources]. Not found. Asking: [question]`. If a question IS answered in context, use that answer directly — do not re-ask.

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

@@ -76,6 +76,14 @@ Pick the pattern that fits. This drives frontmatter choices:
 
 Concrete templates: [examples/task-skill.md](examples/task-skill.md), [examples/knowledge-skill.md](examples/knowledge-skill.md), [examples/fork-skill.md](examples/fork-skill.md), [examples/dynamic-context.md](examples/dynamic-context.md).
 
+#### Convention: User-only / permission-gated finalizer
+
+A Task-pattern skill that must only run on explicit user confirmation is a **permission-gated finalizer**:
+
+- MUST carry `disable-model-invocation: true` — the model cannot invoke it; only the user can (via `/skill-name`).
+- Any upstream skill that auto-triggers it MUST instead emit a `Next: /skill-name` directive and STOP — model invocation of a `disable-model-invocation` skill is blocked at the runtime level.
+- Canonical example: `/cbp-round-complete` (the round finalizer). `/cbp-round-update` routes a clean triage via a `Next: /cbp-round-complete` directive and stops — it cannot invoke round-complete directly.
+
 ### Step 5 — Fill the frontmatter
 
 Read `${CLAUDE_SKILL_DIR}/templates/skill.md` as the canonical frontmatter. Fill only the fields you need — every field except `description` is optional, and even `description` falls back to the first markdown paragraph.

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

@@ -9,7 +9,7 @@ Source: official Claude Code skills spec. All fields are optional; `description`
 | `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`) |
+| `disable-model-invocation` | `true` → only user can invoke (via `/name`). Upstream skills that auto-trigger this skill MUST emit a `Next: /name` directive instead — model invocation is blocked by the runtime; see SKILL.md Step 4 "Convention: User-only / permission-gated finalizer" |
 | `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. **CBP skills normally OMIT this** so the skill inherits the active session model. Pinning a model (e.g. `sonnet`) forces that model and can carry the session's 1M `[1m]` context tier onto the skill, triggering "usage credits required for 1M context". Set it only as a deliberate, documented exception — see [/cbp-build-cc-mode](../../build-cc-mode/SKILL.md) |
@@ -33,3 +33,5 @@ Total skill-description budget in context: 1% of the context window (fallback 8,
 | (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 |
+
+> **Upstream-directive rule**: a skill with `disable-model-invocation: true` cannot be invoked by another skill. Any upstream skill that auto-triggers it MUST emit a `Next: /skill-name` close-out directive and stop. See "Convention: User-only / permission-gated finalizer" in SKILL.md Step 4 for the full pattern and canonical example.

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

@@ -3,6 +3,7 @@ scope: org-shared
 name: cbp-round-complete
 description: Reconcile user git-add approvals, complete the round, and route to the next step
 argument-hint: [chk-task-round | task-round]
+disable-model-invocation: true
 triggers: [cbp-task-check, cbp-standalone-task-check, cbp-round-input]
 effort: low
 ---
@@ -28,9 +29,9 @@ Set `KIND` for the rest of this skill. MCP tool names vary by KIND:
 
 # Round Complete Command
 
-The **permission-gated finalizer** for a round that `/cbp-round-update` triaged as clean. It reconciles which files the **user** approved via `git add`, completes the round, and routes to the next step.
+The **user-invoked finalizer** for a round that `/cbp-round-update` triaged as clean. round-complete carries `disable-model-invocation: true`, so the model cannot invoke it — `/cbp-round-update` *directs* the user here with a `Next: /cbp-round-complete` directive, and the user runs it. It reconciles which files the **user** approved via `git add`, completes the round, and routes to the next step.
 
-This skill is gated by an `ask`-tier `Skill(cbp-round-complete)` permission rule in `settings.json`. **The permission prompt IS the user confirmation** — there is NO AskUserQuestion inside this skill. If the user declines the permission, the skill does not run: nothing is synced, no round is completed, and the user can stage files and re-invoke (directly or by re-running `/cbp-round-update`) when ready.
+This skill is gated by an `ask`-tier `Skill(cbp-round-complete)` permission rule in `settings.json`. **The permission prompt IS the user confirmation** on the user's direct invoke — there is NO AskUserQuestion inside this skill. If the user declines the permission, the skill does not run: nothing is synced, no round is completed, and the user can stage files and re-invoke `/cbp-round-complete` when ready.
 
 ## HARD GATE — Every Step Must Execute
 
@@ -153,16 +154,16 @@ Payload: `round.context.round_complete = { staged_count, unstaged_count, route,
 
 ## Key Rules
 
-- **Permission prompt = confirmation** — gated by `ask`-tier `Skill(cbp-round-complete)`. NEVER add an AskUserQuestion to confirm running; the harness prompt is the gate. A declined permission is a clean no-op.
+- **User-invoked only** — round-complete carries `disable-model-invocation: true`, so the model cannot invoke it. `/cbp-round-update` *directs* the user here on a clean triage (a `Next: /cbp-round-complete` directive); the user runs the skill.
+- **Permission prompt = confirmation** — gated by `ask`-tier `Skill(cbp-round-complete)`. Because the skill is `disable-model-invocation: true`, this gate applies to the user's **direct** `/cbp-round-complete` invocation. NEVER add an AskUserQuestion to confirm running; the harness prompt is the gate. A declined permission is a clean no-op.
 - **Step 2 (CLI) must exit 0** — if it fails, STOP before `complete_round`. The merge semantics are enforced by the CLI.
 - **NEVER ask the user to git add files** — Step 2 only reads staging status. **NEVER stage files** — Claude does not touch the git staging area; the user's `git add` is the approval signal.
 - **standalone KIND Step 3**: `caller_worktree_id` is REQUIRED for `complete_standalone_round` — always resolve and pass it.
-- **Auto-triggered by `/cbp-round-update`** (clean triage), or run manually by the user.
 
 ## Integration
 
-- **Gates**: `ask`-tier `Skill(cbp-round-complete)` permission prompt — the harness confirms before the skill runs; a decline makes NO writes. There is no in-skill AskUserQuestion.
-- **Triggered by**: `/cbp-round-update` (auto, clean triage), or user manually
+- **Gates**: `ask`-tier `Skill(cbp-round-complete)` permission prompt on the user's direct invoke — the harness confirms before the skill runs; a decline makes NO writes. There is no in-skill AskUserQuestion.
+- **Invoked by**: the user only — round-complete carries `disable-model-invocation: true`, so the model cannot invoke it. `/cbp-round-update` *directs* the user here on a clean triage (a `Next: /cbp-round-complete` directive) but does not invoke it.
 - **Reads (checkpoint KIND)**: `.codebyplan/state/checkpoints/<id>.json`, `.codebyplan/state/checkpoints/<id>/tasks/<id>.json`, `.codebyplan/state/checkpoints/<id>/tasks/<id>/rounds/<id>.json` (local-first; run `npx codebyplan sync` if missing; break-glass: MCP `get_current_task` / `get_rounds`). Delegates git+approval sync to `npx codebyplan round sync-approvals`.
 - **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 complete` (Step 3); `codebyplan round update` (Step 4 breadcrumb). Break-glass: MCP `complete_round` / `update_round`. Round+task `files_changed` written by the CLI sync-approvals.

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

@@ -141,7 +141,7 @@ Example tables and the in-scope/out-of-scope classification: see `reference/find
 - Skip the polish-spiral stop-gate (auto-loop has its own cap-exhausted termination).
 - Skip Step 7's inline auto-apply (findings are deferred to the next loop round, not applied this round).
 - Save findings via `update_round` exactly as in manual mode.
-- Auto-trigger `/cbp-round-update` immediately. round-update triages the round and either routes to `/cbp-round-input` (spawn another round) or `/cbp-round-complete` (clean exit) — see cbp-round-update SKILL.md Step 2/3.
+- Auto-trigger `/cbp-round-update` immediately. round-update triages the round and either routes to `/cbp-round-input` (spawn another round) or **directs the user to run** `/cbp-round-complete` on a clean exit — see cbp-round-update SKILL.md Step 2/3.
 
 **Else (manual mode — flag absent or false):**
 
@@ -156,7 +156,7 @@ Step 7 already auto-applied in-scope findings and logged them to `round.context.
      }
    }
    ```
-3. Auto-trigger `/cbp-round-update`. round-update triages the round: if out-of-scope findings (or a hard-fail) remain it routes to `/cbp-round-input` (which picks up the findings from round context and includes them in the new round's requirements automatically); if the round is clean it routes to `/cbp-round-complete` (the permission-gated finalizer that reconciles the user's `git add`s and completes the round).
+3. Auto-trigger `/cbp-round-update`. round-update triages the round: if out-of-scope findings (or a hard-fail) remain it routes to `/cbp-round-input` (which picks up the findings from round context and includes them in the new round's requirements automatically); if the round is clean it **directs the user to run** `/cbp-round-complete` (the user-invoked finalizer that reconciles the user's `git add`s and completes the round).
 
 ## Key Rules
 

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

@@ -1,9 +1,9 @@
 ---
 scope: org-shared
 name: cbp-round-update
-description: Triage a finished round (Claude-only) and route to round-complete or round-input
+description: Triage a finished round (Claude-only); direct user to run round-complete on a clean round, or trigger round-input when more work is needed
 argument-hint: [chk-task-round | task-round]
-triggers: [cbp-round-complete, cbp-round-input]
+triggers: [cbp-round-input]
 effort: low
 ---
 
@@ -35,7 +35,7 @@ The completion + file-approval reconcile (`sync-approvals`, `complete_round` / `
 
 ## Routing in one line
 
-- **Round is clean** → trigger `/cbp-round-complete` (the permission-gated finalizer reconciles your `git add`s and completes the round).
+- **Round is clean** → **direct the user to run** `/cbp-round-complete` (the user-invoked finalizer reconciles your `git add`s and completes the round; round-update cannot invoke it — round-complete is `disable-model-invocation: true`).
 - **Round needs more work** → trigger `/cbp-round-input` (more changes / planning).
 
 ## Instructions
@@ -93,7 +93,7 @@ Display a one-line triage summary, e.g. `"ROUND-N triage: clean"` or `"ROUND-N t
 
 ### Step 3: Route
 
-**3a — Clean → `/cbp-round-complete`.** Auto-trigger `/cbp-round-complete`. round-complete is `ask`-tier: the harness shows a permission prompt (the user's confirmation to finalize the round). round-complete then reconciles the user's `git add`s, completes the round, and routes onward (all files staged → task-check; some withheld → round-input). round-update writes nothing here beyond the Step 2 summary. In `auto_loop_mode`, a clean triage is the loop's success exit — the loop continues only via the not-clean path in 3b; round-complete owns the degenerate clean-but-unstaged guard.
+**3a — Clean → direct the user to `/cbp-round-complete`.** STOP and surface the directive: `Round clean. Next: run /cbp-round-complete to reconcile your git adds and finalize.` round-update does NOT invoke round-complete — round-complete carries `disable-model-invocation: true`, so only the user can run it (its `ask`-tier permission prompt is the user's confirmation on that direct invoke). Once the user runs it, round-complete reconciles the `git add`s, completes the round, and routes onward (all files staged → task-check; some withheld → round-input). round-update writes nothing here beyond the Step 2 summary. In `auto_loop_mode`, a clean triage is the loop's success exit — the directive applies here too (the user invokes round-complete to finalize); the loop continues only via the not-clean path in 3b, and round-complete owns the degenerate clean-but-unstaged guard.
 
 **3b — Not clean → `/cbp-round-input`.** More changes or planning are needed. Routing is **independent of git staging** — round-input is reachable whether or not the user has staged anything (it performs its own deep analysis of the unapproved files). Two sub-cases:
 
@@ -104,7 +104,7 @@ Display a one-line triage summary, e.g. `"ROUND-N triage: clean"` or `"ROUND-N t
 
 ## Key Rules
 
-- **Autonomous + Claude-only** — round-update never prompts before running. It is auto-triggered by `/cbp-round-end`. The confirmation step is `/cbp-round-complete`'s `ask`-tier permission prompt, not an AskUserQuestion here. (The auto-loop cap-exhausted AskUserQuestion in Step 3b is a genuine user decision, not a run gate.)
+- **Autonomous + Claude-only** — round-update never prompts before running. It is auto-triggered by `/cbp-round-end`. On a clean triage it **directs** the user to run `/cbp-round-complete` — it cannot invoke that skill (`disable-model-invocation: true`); the confirmation step is round-complete's own `ask`-tier permission prompt on the user's direct invoke, not an AskUserQuestion here. (The auto-loop cap-exhausted AskUserQuestion in Step 3b is a genuine user decision, not a run gate.)
 - **Triage, never finalize** — round-update does NOT call `sync-approvals`, `complete_round`, or `complete_standalone_round`, and does NOT write file approvals. All of that is `/cbp-round-complete`.
 - **Never touches git** — round-update reads `claude_approved` from the DB only; it never reads staging, asks the user to `git add`, or stages files.
 - **git-add independence** — the "needs more work" route to `/cbp-round-input` fires regardless of whether files are staged. There is no clean-but-unstaged dead-end.
@@ -117,4 +117,5 @@ Display a one-line triage summary, e.g. `"ROUND-N triage: clean"` or `"ROUND-N t
 - **Reads (standalone KIND)**: MCP `get_current_standalone_task`, `get_standalone_rounds` — standalone still uses MCP
 - **Writes (checkpoint KIND)**: `codebyplan round update` — audit only (`auto_loop_decision` / `auto_loop_cap_exhausted`; break-glass: MCP `update_round`). No completion, no file-approval writes.
 - **Writes (standalone KIND)**: MCP `update_standalone_round` — audit only — standalone still uses MCP
-- **Triggers**: `/cbp-round-complete` (clean triage — `ask`-tier permission prompt is the user confirmation), `/cbp-round-input` (not-clean triage: outstanding findings, hard-fail, or unapproved Claude checks — fires independent of git staging; also the auto-loop dirty spawn), cap-exhausted prompt routes from Step 3b (any of the three options)
+- **Triggers**: `/cbp-round-input` (not-clean triage: outstanding findings, hard-fail, or unapproved Claude checks — fires independent of git staging; also the auto-loop dirty spawn), cap-exhausted prompt routes from Step 3b (any of the three options)
+- **Directs the user to**: `/cbp-round-complete` (clean triage) — round-update cannot invoke it (`disable-model-invocation: true`); it emits a `Next: /cbp-round-complete` directive and the user runs it (its `ask`-tier permission prompt is the confirmation)

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

@@ -12,7 +12,7 @@ Activate the session, open a fresh session log, and surface the previous log's p
 
 ## Instructions
 
-Run Steps 0 through 5.8 silently (no intermediate output) — except Step 0 aborts the session on MCP failure, Step 1.4 may surface a one-line fast-forward note or warning, Step 1.5 may surface a one-line infra-drift nudge, Step 1.6 may run an install-and-halt path, Step 1.7 may surface a one-line LSP binary nudge, Step 4.5 may auto-resume a handoff and exit session-start entirely (no Step 6 output), and Step 5.7 may surface an approval gate. (Step numbers are organizational labels; execution order is 0 → 1 → 1.4 → 1.5 → 1.6 → 1.7 → 3 → 4 → 4.5 → 5 → 5.7 → 5.8 → 6 → 7.) Produce ONE output block at Step 6, then auto-trigger or stop per Step 7.
+Run Steps 0 through 5.8 silently (no intermediate output) — except Step 0 aborts the session on MCP failure, Step 1.4 may surface a one-line fast-forward note or warning, Step 1.5 may surface a one-line infra-drift nudge, Step 1.55 may surface a one-line architecture-map drift nudge, Step 1.6 may run an install-and-halt path, Step 1.7 may surface a one-line LSP binary nudge, Step 4.5 may auto-resume a handoff and exit session-start entirely (no Step 6 output), and Step 5.7 may surface an approval gate. (Step numbers are organizational labels; execution order is 0 → 1 → 1.4 → 1.5 → 1.55 → 1.6 → 1.7 → 3 → 4 → 4.5 → 5 → 5.7 → 5.8 → 6 → 7.) Produce ONE output block at Step 6, then auto-trigger or stop per Step 7.
 
 ### Step 0: MCP Health Gate
 
@@ -91,9 +91,37 @@ Surface — never block — when this worktree's source-monorepo `.claude/` infr
 
 Fully non-blocking; every failure path falls through with no output.
 
+### Step 1.55: Architecture-Map Drift Check
+
+Surface — never block — when this repo's generated `.claude/architecture/` maps have
+gone stale (a mapped module's source was committed past the SHA stamped in
+`.codebyplan/architecture.json`). Runs after the infra-drift check (Step 1.5) and may add
+one line to the Step 6 output. This is the freshness nudge for the architecture-map
+pipeline (mirrors the infra-drift pattern; the analog for first-party code maps):
+
+- **No manifest** — `.codebyplan/architecture.json` absent → skip silently (the repo has
+  no maps yet; nothing to drift-check).
+- **Manifest present** — run the drift probe best-effort and count drifted modules:
+
+  ```bash
+  npx codebyplan arch-map drift 2>/dev/null | grep -c '^[[:space:]]*DRIFTED' || true
+  ```
+
+  If the count is `> 0`, hold this single line for Step 6:
+
+  ```
+  ⚠ .claude/architecture is N module(s) stale — run /cbp-refresh-arch-map
+  ```
+
+  A count of `0` (all maps fresh, no stamped modules, or any probe failure) emits nothing.
+
+Fully non-blocking; every failure path falls through with no output. The `arch-map` CLI is
+itself hook-safe (exits 0 on any internal error), so a missing or too-old `codebyplan`
+binary simply yields a zero count and no line.
+
 ### Step 1.6: Package Freshness Gate
 
-Check whether a newer `codebyplan` is published and safe to auto-install on this worktree's current branch. Runs AFTER the infra-drift check (Step 1.5) and BEFORE session activation (Step 3).
+Check whether a newer `codebyplan` is published and safe to auto-install on this worktree's current branch. Runs AFTER the architecture-map drift check (Step 1.55) and BEFORE session activation (Step 3).
 
 ```bash
 VERSION_JSON=$(npx codebyplan version-status 2>/dev/null)
@@ -231,6 +259,9 @@ Session active | Worktree: [worktree_id or "unregistered"]
 
 [⚠ resolve-worktree: <error_kind> — local state is broken; routing may be unreliable. Run `npx codebyplan setup` to repair. — only when error_kind is non-null and not tuple_miss]
 
+[⚠ .claude/ infra is N behind — run /cbp-refresh-infra — only when Step 1.5 found drift]
+[⚠ .claude/architecture is N module(s) stale — run /cbp-refresh-arch-map — only when Step 1.55 found drift]
+
 Previous session: [title or "none"]
   Pending: [pending items from previous log, or "—"]
 
@@ -257,7 +288,7 @@ Three-branch gate using `owned_count` and `total_count` from Step 5.8:
 
 - **Triggered by**: user invocation, `/clear` recovery
 - **Resolves**: `npx codebyplan resolve-worktree --json` (worktree id + distress signal; non-tuple-miss distress is non-blocking at session-start)
-- **Reads**: `.codebyplan/repo.json`, `.codebyplan/git.json` (`branch_config.production` for the Step 1.4 home-branch fast-forward), MCP `health_check` (Step 0 hard gate — stays MCP unconditionally); local-first reads (with `npx codebyplan sync` + MCP break-glass): `.codebyplan/state/session/current.json` (Step 4 previous log + Step 4.5 handoff probe), `.codebyplan/state/checkpoints/<id>.json` / `tasks/<id>.json` / `rounds/<id>.json` (Step 4.5 freshness probe), `.codebyplan/state/todos.json` (Step 5.7 active-task lookup); MCP `get_checkpoints({ repo_id, status: 'active' })` (Step 5.8 ownership partition — MCP only, no local mirror for active-filter query); `scripts/infra-drift.mjs` + a best-effort `git fetch` (Step 1.5 monorepo drift); `npx codebyplan version-status` (Step 1.6 package-freshness gate); `npx codebyplan lsp --check` (Step 1.7 LSP binary nudge — reads `.codebyplan/lsp.json`, non-blocking). Reads at Step 3 and later do NOT fire on a Step 0 MCP hard-fail or the Step 1.6 update-and-halt path
+- **Reads**: `.codebyplan/repo.json`, `.codebyplan/git.json` (`branch_config.production` for the Step 1.4 home-branch fast-forward), MCP `health_check` (Step 0 hard gate — stays MCP unconditionally); local-first reads (with `npx codebyplan sync` + MCP break-glass): `.codebyplan/state/session/current.json` (Step 4 previous log + Step 4.5 handoff probe), `.codebyplan/state/checkpoints/<id>.json` / `tasks/<id>.json` / `rounds/<id>.json` (Step 4.5 freshness probe), `.codebyplan/state/todos.json` (Step 5.7 active-task lookup); MCP `get_checkpoints({ repo_id, status: 'active' })` (Step 5.8 ownership partition — MCP only, no local mirror for active-filter query); `scripts/infra-drift.mjs` + a best-effort `git fetch` (Step 1.5 monorepo drift); `npx codebyplan arch-map drift` + `.codebyplan/architecture.json` presence (Step 1.55 architecture-map drift nudge, non-blocking); `npx codebyplan version-status` (Step 1.6 package-freshness gate); `npx codebyplan lsp --check` (Step 1.7 LSP binary nudge — reads `.codebyplan/lsp.json`, non-blocking). Reads at Step 3 and later do NOT fire on a Step 0 MCP hard-fail or the Step 1.6 update-and-halt path
 - **Writes**: `codebyplan session create-log` (Step 5 — CLI write-through; break-glass: MCP `create_session_log`), `codebyplan session update-state --action activate` (Step 3 — CLI write-through to `.codebyplan/state/session/state.json`; break-glass: MCP `update_session_state`) — both SKIPPED on a Step 0 MCP hard-fail and on the Step 1.6 update-and-halt path
 - **Spawns**: none
 - **Triggers**: `/cbp-git-commit` (conditional, on user approval at Step 5.7 or the Step 1.6 update path), `handoff.command` (on fresh handoff hit at Step 4.5), `/cbp-todo` (auto fall-through when owned_count >= 1 or total_count === 0; STOPS with no trigger when total_count >= 1 AND owned_count === 0; NOT triggered on a Step 0 hard-fail or the Step 1.6 update-and-halt path)