claude-code-pilot 3.2.0 → 3.3.0

package/src/pilot/references/planner-graphify-auto-update.md

@@ -0,0 +1,67 @@
+# Graphify Auto-Update — Status Surfacing
+
+> Documents how `ccp-planner` and `ccp-phase-researcher` surface the opt-in graphify auto-update state (issue #3347). The status surface lives inside `graphifyStatus()` in `pilot/bin/lib/graphify.cjs`; no planner-side prompt changes are required.
+
+## Why this exists
+
+The graph at `.planning/graphs/graph.json` is consumed automatically (every `ccp-planner` and `ccp-phase-researcher` step) but produced manually (`/ccp:graphify build` per session at best). Without auto-update, the producer-consumer gap silently widens with every commit. The existing `stale: true` annotation tells the consumer the mtime is old; it cannot tell the consumer whether the auto-build hook has been running, just failed, or is in flight.
+
+When `graphify.auto_update: true`, the bundled `hooks/ccp-graphify-update.sh` PostToolUse hook fires after HEAD-advancing git operations on the default branch and dispatches `graphify update .` in a detached subprocess. The hook writes a status file synchronously before detach; the detached process rewrites it on completion.
+
+## The status file
+
+`.planning/graphs/.last-build-status.json`:
+
+```json
+{
+  "ts": "2026-05-15T14:02:23Z",
+  "status": "running" | "ok" | "failed",
+  "exit_code": null | <int>,
+  "duration_ms": null | <int>,
+  "head_at_build": "<commit-sha>",
+  "graphify_version": null | "<version>"
+}
+```
+
+The hook writes `status: "running"` synchronously **before** detach, so the next planner invocation can see the in-flight signal even if `graphify update .` has not finished. The detached `hooks/lib/ccp-graphify-rebuild.sh` rewrites the file to `ok` or `failed` on completion (with `exit_code` and `duration_ms`).
+
+## How the planner surfaces it (zero new prompt content)
+
+`graphifyStatus()` in `pilot/bin/lib/graphify.cjs` reads `.last-build-status.json` and folds the `running` / `failed` states into the existing `stale: true` signal:
+
+```javascript
+const autoUpdateStale =
+  lastBuildAutoUpdate &&
+  (lastBuildAutoUpdate.status === 'failed' || lastBuildAutoUpdate.status === 'running');
+
+return {
+  ...
+  stale: age > STALE_MS || Boolean(autoUpdateStale),
+  ...
+  last_build_auto_update: lastBuildAutoUpdate || null,
+};
+```
+
+The planner and researcher already run `node ... graphify status` inside their `<step name="load_graph_context">` blocks and already have the rule:
+
+> If the status response has `stale: true`, note for later: "Graph is `{age_hours}h` old — treat semantic relationships as approximate."
+
+That rule now fires correctly in three additional cases:
+
+| Trigger | What user sees |
+|---------|----------------|
+| Auto-build status = `failed` | Existing "treat as approximate" note fires (because `stale: true`). The full `last_build_auto_update` object is in the JSON for callers that want exit-code / duration / commit-sha context. |
+| Auto-build status = `running` | Same — the next planner invocation knows the graph is mid-rebuild and treats it as approximate until the detached process completes. |
+| Auto-build status = `ok` AND mtime < 24h | Annotation is silent — the graph is fresh and the most recent auto-build succeeded. |
+
+The file-missing case is silent (the operator either has not opted in or has not yet triggered a HEAD-advancing git op since enabling).
+
+## Why this design
+
+- **No planner-side prompt changes.** Folding into `stale: true` reuses the existing rule, which means no new content in `agents/ccp-planner.md` (which is already at the `< 48K` decomposition limit per `DEFECT.AGENT-FILE-SIZE-CAP-BREACH`).
+- **Tests catch regressions on the seam.** `tests/feat-3347-graphify-auto-update-config.test.cjs` pins `graphifyStatus` behavior for status=`failed` / `running` / `ok` / file-missing.
+- **Backwards compatible.** Callers that don't read `last_build_auto_update` see the same shape as before, with `stale` reflecting both mtime AND auto-build state. No consumer breakage.
+
+## Opt-in reminder
+
+The auto-update mechanism is opt-in (`graphify.auto_update: false` by default per issue #3347). Users who haven't opted in will never produce this file. `graphifyStatus()` returns `last_build_auto_update: null` and falls back to the mtime-only `stale` rule.

package/src/pilot/references/planner-human-verify-mode.md

@@ -0,0 +1,57 @@
+# Planner — Human Verification Mode
+
+> Loaded by `ccp-planner` when deciding whether to emit `<task type="checkpoint:human-verify">` tasks. Read `workflow.human_verify_mode` from `.planning/config.json` (default `end-of-phase` since #3309).
+
+## The two modes
+
+### `end-of-phase` (default — issue #3309)
+
+Do **not** emit any `<task type="checkpoint:human-verify">` tasks. Every mid-flight halt costs a full executor cold-start (CLAUDE.md, MEMORY.md, STATE.md, plan re-read on respawn) because subagent context is discarded across the pause; a plan with N human-verify checkpoints pays the cold-start cost N+1 times — measured at "tens of thousands of tokens" per round-trip on real projects. This is the default for that reason.
+
+Instead, fold each would-be verification step into the relevant `auto` task using a `<verify><human-check>` sub-block:
+
+```xml
+<task type="auto">
+  <name>Wire dashboard route</name>
+  <files>app/dashboard/page.tsx, app/api/dashboard/route.ts</files>
+  <action>...</action>
+  <verify>
+    <automated>npm test -- --filter=dashboard</automated>
+    <human-check>
+      <test>Visit http://localhost:3000/dashboard</test>
+      <expected>Sidebar left, content right on desktop &gt;1024px; collapses to hamburger at 768px</expected>
+      <why_human>Visual layout — grep cannot verify breakpoint behavior</why_human>
+    </human-check>
+  </verify>
+  <done>Layout renders correctly across breakpoints</done>
+</task>
+```
+
+The verifier (Step 8) harvests every `<verify><human-check>` block at end-of-phase and consolidates them into the existing `human_needed` → HUMAN-UAT.md path in `workflows/execute-phase.md`. The user reviews everything in one batch instead of paying a cold-start cost per item.
+
+### `mid-flight` (opt-back-in — pre-#3309 behavior)
+
+Set `ccp config-set workflow.human_verify_mode mid-flight` to restore the canonical mid-flight pattern: emit `<task type="checkpoint:human-verify">` tasks at the points where human confirmation is required, and the executor halts at each one to ask the user.
+
+```xml
+<task type="checkpoint:human-verify" gate="blocking">
+  <what-built>Dev server running at http://localhost:3000</what-built>
+  <how-to-verify>
+    1. Visit /dashboard
+    2. Sidebar collapses at 768px
+  </how-to-verify>
+  <resume-signal>"approved" or describe issues</resume-signal>
+</task>
+```
+
+Choose `mid-flight` when you genuinely need the work to stop before any subsequent task runs (e.g., the next task depends on visual confirmation of the previous one), and you accept the cold-start cost as the price of that hard barrier.
+
+## What is *not* affected
+
+`checkpoint:decision` and `checkpoint:human-action` tasks are still emitted in `end-of-phase` mode. Those gate the work itself (a choice the executor needs from the user, or an auth step only the user can perform), not post-hoc verification of completed work. Only `checkpoint:human-verify` is suppressed.
+
+## Compatibility with other modes
+
+- **`workflow.tdd_mode`**: orthogonal. TDD tasks still emit `tdd="true"` and `<behavior>`; the `<verify>` block carries the human-check sub-element when `human_verify_mode = end-of-phase`.
+- **`MVP_MODE`**: orthogonal. Vertical-slice ordering is unchanged. The first task remains a failing end-to-end test; later auto tasks may carry `<verify><human-check>` instead of standalone checkpoint tasks.
+- **`workflow.auto_advance` / `_auto_chain_active`**: in mid-flight mode these auto-approve checkpoint:human-verify halts. In end-of-phase mode there are no halts to auto-approve, so the flags have no effect on this code path.

package/src/pilot/references/planner-mvp-mode.md

@@ -0,0 +1,53 @@
+# Planner — MVP Mode (Vertical Slice Strategy)
+
+> Loaded by `ccp-planner` only when `MVP_MODE=true`. Standard horizontal-layer planning rules continue to apply for all other phases.
+
+## Core Rule
+
+**Decompose by feature slice, not by technical layer.** Every task must move the user-facing capability forward. After each task, a real user can click through more of the feature than they could before.
+
+**Forbidden** in MVP mode:
+- "Create the database schema" as a standalone task
+- "Build the API layer" as a standalone task
+- "Wire up the UI" as a final integration task
+
+**Required** in MVP mode:
+- The first non-test task produces a working end-to-end path. Stubs are allowed for non-critical branches; the happy path must be real.
+- Each subsequent task either adds a new slice OR refines an existing slice (validation, error states, edge cases).
+- The phase goal is framed as a user story: "**As a** [user], **I want to** [do X], **so that** [Y]."
+
+## Task Order Pattern
+
+For a feature `F`:
+
+1. **Failing end-to-end test** for the happy path of `F`.
+2. **Thinnest viable slice** — UI form → API endpoint → DB read/write — that makes the test pass. Hard-coded values, missing validation, no error states are fine here.
+3. **Real data layer** — replace any stubs from Task 2 with real queries.
+4. **Validation + error states** — invalid input, network failure, empty states.
+5. **Production polish** — loading indicators, edge cases, accessibility checks.
+
+Tasks 3-5 are not always all needed; gate by the phase's acceptance criteria.
+
+## Walking Skeleton Mode (`WALKING_SKELETON=true`)
+
+When the orchestrator sets `WALKING_SKELETON=true` (Phase 1 of a new project under `--mvp`), the plan changes shape:
+
+- The "feature" is the application itself. Pick the smallest meaningful capability that proves the full stack works (e.g., "user can sign up and see their name on a dashboard").
+- The plan **must include**:
+  - Project scaffold (framework init, routing, build, lint)
+  - One real DB read/write
+  - One real UI interaction wired to the API
+  - Deployment to a dev environment (or a documented local-run command that exercises the full stack)
+- The plan **must produce** `SKELETON.md` in the phase directory alongside `PLAN.md`. Use the template at `@~/.claude/pilot/references/skeleton-template.md`. `SKELETON.md` records the architectural decisions that subsequent phases will build on (chosen framework, DB, deployment target, auth approach, directory layout).
+
+`SKELETON.md` is the architectural backbone for every later vertical slice; treat it as a contract, not a scratchpad.
+
+## Anti-Patterns to Reject
+
+- **Layer cake disguised as slices.** Three "vertical" tasks where Task 1 is "all the schemas", Task 2 is "all the endpoints", Task 3 is "all the UI" — that is horizontal planning with new labels. Reject.
+- **Skeleton bloat.** Walking Skeleton is the *thinnest* working stack, not "Phase 1 of a normal app." If Skeleton has more than ~5 tasks, you are not skeletonizing.
+- **Premature SPIDR splitting.** SPIDR splitting is the `mvp-phase` command's job (Phase 2 of the PRD), not the planner's. If the phase scope feels too large, surface it via the verification loop, do not split silently.
+
+## Acceptance Test for Your Plan
+
+Before emitting the plan, ask: **after Task N completes, can a real user *do* something they could not do after Task N-1?** If the answer is "no, but the foundation is laid", you have a horizontal task disguised as a slice. Restructure.

package/src/pilot/references/skeleton-template.md

@@ -0,0 +1,48 @@
+# SKELETON.md Template
+
+> Emitted by `ccp-planner` when `WALKING_SKELETON=true` (Phase 1 + `--mvp` + new project). Records the architectural decisions the rest of the project will build on.
+
+```markdown
+# Walking Skeleton — [Project Name]
+
+**Phase:** 1
+**Generated:** {ISO date}
+
+## Capability Proven End-to-End
+
+> One sentence: the smallest user-visible capability that exercises the full stack.
+
+Example: "A signed-in user can view their email on a dashboard page served by the deployed app."
+
+## Architectural Decisions
+
+| Decision | Choice | Rationale |
+|---|---|---|
+| Framework | (e.g., Next.js 15 App Router) | Why this fits the project |
+| Data layer | (e.g., Postgres + Drizzle) | Why |
+| Auth | (e.g., session cookies + bcrypt) | Why |
+| Deployment target | (e.g., Vercel preview) | Why |
+| Directory layout | (e.g., feature-folders under src/features/*) | Why |
+
+## Stack Touched in Phase 1
+
+- [ ] Project scaffold (framework, build, lint, test runner)
+- [ ] Routing — at least one real route
+- [ ] Database — at least one real read AND one real write
+- [ ] UI — at least one interactive element wired to the API
+- [ ] Deployment — running on dev environment OR documented local full-stack run command
+
+## Out of Scope (Deferred to Later Slices)
+
+> Anything that is *not* in the skeleton. Be explicit — this list prevents future phases from re-litigating Phase 1's minimalism.
+
+- (e.g., password reset, email verification, multi-tenancy)
+
+## Subsequent Slice Plan
+
+Each later phase adds one vertical slice on top of this skeleton without altering its architectural decisions:
+
+- Phase 2: [next user capability]
+- Phase 3: [next user capability]
+- ...
+```

package/src/pilot/references/spidr-splitting.md

@@ -0,0 +1,69 @@
+# SPIDR Story Splitting Rules
+
+> Used by `mvp-phase` workflow when the user-supplied story is too large for a single phase. Per PRD decision Q3, SPIDR runs as a **full interactive flow** — not a lightweight check.
+
+## When SPIDR triggers
+
+Trigger SPIDR splitting if **any** of these size signals fire on the user story:
+
+1. **Compound capabilities.** The story names two or more independent user actions joined by "and" (e.g., "register **and** log in **and** reset their password"). Each "and" is a candidate split point.
+2. **Multi-actor.** The story names more than one `[user role]` (e.g., "As a user or admin..."). Each role is a candidate split.
+3. **Length.** The assembled story exceeds ~120 chars on a single line.
+4. **Vague capability.** The capability is a noun phrase, not a verb-noun pair (e.g., "I want to use the dashboard" — needs to specify *which interaction* with the dashboard).
+
+If none of these fire, skip SPIDR entirely and proceed to ROADMAP write.
+
+## The five SPIDR axes
+
+For each axis, ask one targeted question. The user picks the axis that best fits their story; only one axis is applied per split.
+
+### Spike
+
+> "Is there an unknown that needs research before this can be implemented? If so, the spike is its own phase."
+
+If yes: split out a research phase (no acceptance criteria except "we know enough to plan the rest"). The remaining story becomes a follow-up phase.
+
+### Paths
+
+> "Does this feature have a happy path and one or more error/edge paths?"
+
+If yes: split happy path into the first phase, edge paths into follow-ups. Order: happy path first (it proves the slice works), then progressively edge cases.
+
+### Interfaces
+
+> "Does this feature need to work on more than one interface (web, mobile, API, CLI)?"
+
+If yes: split by interface. Web first if user-facing; API first if integration-driven; mobile last unless it's the primary platform.
+
+### Data
+
+> "Does this feature touch multiple data scopes (one user vs. many, single team vs. multi-tenant, small CSV vs. large dataset)?"
+
+If yes: split by scope. Smallest scope first (one user, single team, small data), then expand.
+
+### Rules
+
+> "Does this feature have multiple business rules that could be added incrementally (basic validation first, then complex policy)?"
+
+If yes: split by rule complexity. Minimum viable rules first; complex policy in follow-ups.
+
+## Workflow
+
+When SPIDR triggers, the workflow:
+
+1. Restates the user-supplied story.
+2. Asks "Which SPIDR axis fits best?" with the five options above.
+3. Walks through the chosen axis interactively (one focused question), produces a split proposal: "Phase N (this one): X. Phase N+1: Y. Phase N+2: Z."
+4. Confirms the split with the user.
+5. On accept: writes the FIRST phase's story to the current ROADMAP entry; defers creating new phases for the splits to a follow-up step (the workflow surfaces a list of `/ccp:add-phase` invocations the user can run after `mvp-phase` completes — but does not run them automatically, to preserve user control over phase numbering).
+6. On reject: proceeds with the original story unchanged.
+
+## Anti-patterns to reject
+
+- **Splitting by technical layer.** "Phase 1: schema. Phase 2: API. Phase 3: UI." That's horizontal planning. Reject.
+- **Pre-splitting before the user even sees the original.** Always show the user-supplied story first; only offer split if it triggers a size signal.
+- **Splitting more than one axis at once.** SPIDR is one axis per split. If a story needs splitting on two axes (e.g., paths AND data), do paths first, then re-evaluate the resulting smaller stories.
+
+## Reference
+
+See [Mike Cohn — Five Simple But Powerful Ways to Split User Stories](https://www.mountaingoatsoftware.com/blog/five-simple-but-powerful-ways-to-split-user-stories).

package/src/pilot/references/user-story-template.md

@@ -0,0 +1,58 @@
+# User Story Template (MVP Mode)
+
+> Used by `mvp-phase` workflow and `ccp-planner` agent when `MVP_MODE=true`. Defines the canonical "As a / I want to / So that" format and the rules for converting it into the `**Goal:**` line in ROADMAP.md.
+
+## Canonical format
+
+```
+As a [user role], I want to [capability], so that [outcome].
+```
+
+Three required components:
+
+| Slot | Question | Examples |
+|---|---|---|
+| `[user role]` | Who is the actor? | "new user", "admin", "signed-in customer", "API consumer" |
+| `[capability]` | What can they do? | "register and log in", "upload a CSV", "see my dashboard" |
+| `[outcome]` | Why does it matter? | "I can access my account", "I can bulk-import contacts", "I can see at a glance what needs attention" |
+
+All three must be present. Refuse to assemble a partial story.
+
+## How it lands in ROADMAP.md
+
+The full user story replaces the existing `**Goal:**` line in the phase section:
+
+**Before:**
+```
+### Phase 1: User Auth MVP
+**Goal:** Users can register and log in
+```
+
+**After:**
+```
+### Phase 1: User Auth MVP
+**Goal:** As a new user, I want to register and log in, so that I can access my dashboard.
+**Mode:** mvp
+```
+
+Two structural rules:
+1. The `**Goal:**` line stays on a single line (no line breaks inside the story). If the story is longer than ~120 chars, it should be split into multiple phases via SPIDR (see `spidr-splitting.md`).
+2. The `**Mode:** mvp` line is added immediately below `**Goal:**`. If `**Mode:**` already exists, it is replaced (not duplicated).
+
+## How it lands in PLAN.md
+
+The `ccp-planner` agent (with MVP_MODE=true) emits the user story as the first content under the phase header in `PLAN.md`:
+
+```markdown
+## Phase Goal
+
+**As a** new user, **I want to** register and log in, **so that** I can access my dashboard.
+
+## Acceptance Criteria
+- [ ] ...
+
+## MVP Slice Tasks
+...
+```
+
+Note the bold-keyword formatting (`**As a**`, `**I want to**`, `**so that**`) is for the PLAN.md emit only. The ROADMAP.md `**Goal:**` line uses prose form (the keywords are not bolded inside the goal line, since the goal is itself a single bolded label).

package/src/pilot/references/verify-mvp-mode.md

@@ -0,0 +1,85 @@
+# Verify-Work — MVP Mode UAT Framing
+
+> Loaded by `verify-work` workflow and `ccp-verifier` agent only when the phase under verification has `mode: mvp` in ROADMAP.md. Reframes UAT generation from technical checks to user-flow walk-throughs.
+
+## Core rule
+
+**Show expected, ask if reality matches** — same philosophy as standard verify-work (from `workflows/verify-work.md`). The MVP-mode change is WHAT gets shown:
+
+- **Standard verify-work:** "The API endpoint at /users/register returns 201 with the new user's ID." → user confirms.
+- **MVP verify-work:** "Open the registration page. Fill in 'name', 'email', 'password'. Click Submit. You should see your dashboard with your name in the header." → user confirms.
+
+The user-flow form mirrors what a real user does: open, fill, click, see. No HTTP verbs, no JSON shapes, no error codes.
+
+## When this framing applies
+
+The framing fires when:
+- The phase under verification has `**Mode:** mvp` in ROADMAP.md (extracted by reading the Phase block from `.planning/ROADMAP.md` and locating its `**Mode:**` line).
+- AND the phase has a user-story-formatted goal (set by `/ccp:mvp-phase` per Phase 2): "As a [user role], I want to [capability], so that [outcome]."
+
+If the phase has `mode: mvp` but the goal is NOT in user-story format, the verifier surfaces this as a discrepancy and asks the user to run `/ccp:mvp-phase` to reformat the goal — same pattern as the planner agent under MVP_MODE (per `references/planner-mvp-mode.md`).
+
+## Generated UAT script structure under MVP mode
+
+The UAT script generated by `verify-work` under MVP mode has THREE sections, in this exact order:
+
+### 1. User-flow walk-through (always first, always required)
+
+Derive ordered steps from the phase's user-story goal:
+
+1. The first step opens the entry point ("Open the app", "Navigate to /register", "Run `ccp mvp-phase 1`").
+2. Each subsequent step is one user action: fill, click, type, observe.
+3. The final step asserts the user-visible outcome from the `[outcome]` clause of the user story.
+
+Format each step as: "**Step N: [action]** — Expected: [what the user should see]". The user responds with one of:
+- `yes` / `y` / `next` / empty → step passes
+- Anything else → step is logged as an issue, and the script halts (do not proceed to step N+1 with a broken N).
+
+If ALL user-flow steps pass, advance to section 2. If any step fails, the verdict is FAIL — do not run technical checks.
+
+### 2. Technical checks (only if section 1 passes)
+
+After the user flow passes, run the technical checks that would normally run in non-MVP mode:
+- API endpoint schema verification (if the phase shipped APIs)
+- Error state behavior (4xx, 5xx codes; invalid input handling)
+- Edge cases (empty data, large data, concurrent requests if applicable)
+- Cross-browser / cross-runtime checks (if applicable)
+
+These are the same checks `verify-work` would run without MVP mode — just deferred until the user flow proves the slice actually works for a user.
+
+### 3. Coverage check (always last, always required)
+
+Verify that the user-story `[outcome]` clause is observably true in the codebase:
+- If the outcome is "I can access my dashboard", verify a dashboard route exists and renders for an authenticated user.
+- If the outcome is "I can bulk-import contacts", verify the import path produces persisted records.
+
+Coverage is a goal-backward check: "did this phase deliver what its user story promised?" — sourced from the existing `ccp-verifier` agent's goal-backward methodology, narrowed to the user story.
+
+## Anti-patterns to reject under MVP mode
+
+- **Lead with technical checks.** "Step 1: GET /api/users/me returns 200." Reject. The user does not see API endpoints. Reorder so a user action comes first.
+- **Schema-as-feature.** "User has a `name` field on the User model." Reject. The user does not see database fields. Express the same check as a user-visible outcome ("the user's name appears in the dashboard header").
+- **Skip user flow because the test passed.** The unit test passing in CI is not evidence that the user flow works. The user-flow walk-through is mandatory under MVP mode even when all unit tests are green.
+
+## Compatibility with existing verify-work philosophy
+
+The "show expected, ask if reality matches" model is preserved. The user still types `yes` / `next` / empty to advance. The UAT.md state file format is unchanged. Only the WHAT changes — under MVP mode, the "expected" is a user-visible outcome rather than a technical assertion.
+
+## Output: VERIFICATION.md changes under MVP mode
+
+The `ccp-verifier` agent produces `VERIFICATION.md`. Under MVP mode, the report adds a top-level "User Flow Coverage" section that maps each step of the user story to evidence in the codebase:
+
+```markdown
+## User Flow Coverage
+
+User story: «As a new user, I want to register and log in, so that I can access my dashboard.»
+
+| Step | Expected | Evidence | Status |
+|------|----------|----------|--------|
+| Register | Form at /register accepts name/email/password | src/app/register/page.tsx:12 (form component) | ✓ |
+| Submit | Persists user, redirects to /dashboard | src/api/register/route.ts:34 (db.insert + redirect) | ✓ |
+| See dashboard | Dashboard page renders, shows user's name | src/app/dashboard/page.tsx:8 (greeting line) | ✓ |
+| Outcome | "Access my dashboard" — user lands on a populated page | dashboard route + greeting both verified above | ✓ |
+```
+
+Standard technical-check sections of VERIFICATION.md remain (API verification, error handling, etc.) but are appended below "User Flow Coverage", not above.

package/src/pilot/references/worktree-path-safety.md

@@ -0,0 +1,89 @@
+# Worktree Path Safety
+
+Guards for executor agents running inside Claude Code worktrees. Three checks
+must run before any staging, Edit, or Write operation in worktree mode.
+
+---
+
+## Worktree branch check (run once at spawn-time)
+
+FIRST ACTION: HEAD assertion MUST run before any reset/checkout. Worktrees
+spawned by Claude Code's `isolation="worktree"` use the `worktree-agent-<id>`
+namespace. If HEAD is on a protected ref (main/master/develop/trunk/release/*)
+or detached, HALT — do NOT self-recover by force-rewinding via `git update-ref`,
+that destroys concurrent commits in multi-active scenarios (#2924). Only after
+this passes is `git reset --hard` safe (#2015 — affects all platforms).
+
+```bash
+HEAD_REF=$(git symbolic-ref --quiet HEAD || echo "DETACHED")
+ACTUAL_BRANCH=$(git rev-parse --abbrev-ref HEAD)
+if [ "$HEAD_REF" = "DETACHED" ] || echo "$ACTUAL_BRANCH" | grep -Eq '^(main|master|develop|trunk|release/.*)$'; then
+  echo "FATAL: worktree HEAD on '$ACTUAL_BRANCH' (expected worktree-agent-*); refusing to self-recover via 'git update-ref' (#2924)." >&2
+  exit 1
+fi
+if ! echo "$ACTUAL_BRANCH" | grep -Eq '^worktree-agent-[A-Za-z0-9._/-]+$'; then
+  echo "FATAL: worktree HEAD '$ACTUAL_BRANCH' is not in the worktree-agent-* namespace; refusing to commit (#2924)." >&2
+  exit 1
+fi
+ACTUAL_BASE=$(git merge-base HEAD {EXPECTED_BASE})
+if [ "$ACTUAL_BASE" != "{EXPECTED_BASE}" ]; then
+  git reset --hard {EXPECTED_BASE}
+  [ "$(git rev-parse HEAD)" != "{EXPECTED_BASE}" ] && { echo "ERROR: could not correct worktree base"; exit 1; }
+fi
+```
+
+Per-commit HEAD assertion: `agents/ccp-executor.md` `<task_commit_protocol>` step 0.
+
+---
+
+## cwd-drift sentinel — step 0a (#3097)
+
+A prior Bash call may have `cd`'d out of the worktree into the main repo. When
+that happens `[ -f .git ]` is false (main repo's `.git` is a directory), silently
+skipping all worktree guards. The sentinel captures the spawn-time toplevel and
+detects drift before every commit.
+
+```bash
+if [ -f .git ]; then  # we are in a worktree
+  WT_GIT_DIR=$(git rev-parse --git-dir 2>/dev/null)
+  case "$WT_GIT_DIR" in
+    *.git/worktrees/*)
+      SENTINEL="$WT_GIT_DIR/ccp-spawn-toplevel"
+      [ ! -f "$SENTINEL" ] && git rev-parse --show-toplevel > "$SENTINEL" 2>/dev/null
+      EXPECTED_TL=$(cat "$SENTINEL" 2>/dev/null)
+      ACTUAL_TL=$(git rev-parse --show-toplevel 2>/dev/null)
+      if [ -n "$EXPECTED_TL" ] && [ "$ACTUAL_TL" != "$EXPECTED_TL" ]; then
+        echo "FATAL: cwd drifted from spawn-time worktree root (#3097)" >&2
+        echo "  Spawn-time: $EXPECTED_TL" >&2
+        echo "  Current:    $ACTUAL_TL" >&2
+        echo "RECOVERY: cd \"$EXPECTED_TL\" before staging, then re-run this commit." >&2
+        exit 1
+      fi
+      ;;
+  esac
+fi
+```
+
+---
+
+## Absolute-path guard — step 0b (#3099)
+
+Edit/Write calls using absolute paths constructed from the **orchestrator's** `pwd`
+(main repo root) will resolve to the main repo, not the worktree. Writes land in
+the wrong directory; `git commit` from the worktree sees a clean tree and the work
+is silently lost.
+
+Before any Edit or Write using an absolute path:
+
+```bash
+WT_ROOT=$(git rev-parse --show-toplevel 2>/dev/null)
+# Fail fast if ABS_PATH resolves outside the worktree
+if [[ "$ABS_PATH" != "$WT_ROOT"* ]]; then
+  echo "WARNING: $ABS_PATH is outside the worktree ($WT_ROOT)" >&2
+  echo "Use a relative path or recompute the absolute path from WT_ROOT." >&2
+fi
+```
+
+**Prefer relative paths** for all Edit/Write operations. When an absolute path is
+unavoidable, always derive it from `git rev-parse --show-toplevel` run inside the
+worktree — never from `pwd` captured in the orchestrator context.

package/src/pilot/workflows/help.md

@@ -47,6 +47,7 @@ These commands manage the full project lifecycle: initialization, planning, exec
 | `/ccp:discuss-phase <N>` | Gather phase context through adaptive questioning before planning |
 | `/ccp:research-phase <N>` | Research how to implement a phase (standalone ecosystem research) |
 | `/ccp:plan-phase <N>` | Create detailed phase plan (PLAN.md) with verification loop |
+| `/ccp:mvp-phase <N>` | Plan a phase as a vertical MVP slice -- user story, SPIDR splitting, then plan-phase |
 | `/ccp:validate-phase <N>` | Retroactively audit and fill Nyquist validation gaps for a completed phase |
 | `/ccp:list-phase-assumptions <N>` | Surface Claude's assumptions about a phase approach before planning |
 
@@ -107,6 +108,7 @@ These commands manage the full project lifecycle: initialization, planning, exec
 | `/ccp:plant-seed [idea]` | Capture a forward-looking idea with trigger conditions |
 | `/ccp:ship [phase]` | Create PR, run review, and prepare for merge after verification |
 | `/ccp:pr-branch [target]` | Create a clean PR branch by filtering out .planning/ commits |
+| `/ccp:pr-ecc [base]` | Create a GitHub PR from the current branch's unpushed commits (no .planning/ filtering, unlike pr-branch) |
 | `/ccp:session-report` | Generate a session report with token usage, summary, and outcomes |
 | `/ccp:milestone-summary` | Generate a comprehensive project summary from milestone artifacts |
 
@@ -129,6 +131,7 @@ These are utility commands for day-to-day development: code quality, testing, bu
 | Command | Description |
 |---------|-------------|
 | `/ccp:code-review` | Comprehensive security and quality review of uncommitted changes |
+| `/ccp:security-scan` | Scan your `.claude/` config for security issues via AgentShield (external, opt-in via `npx`) |
 | `/ccp:tdd` | Enforce TDD workflow -- scaffold interfaces, generate tests first, then implement |
 | `/ccp:test-coverage` | Analyze test coverage, identify gaps, and generate missing tests for 80%+ |
 | `/ccp:refactor-clean` | Safely identify and remove dead code with test verification at every step |
@@ -150,6 +153,7 @@ These are utility commands for day-to-day development: code quality, testing, bu
 | Command | Description |
 |---------|-------------|
 | `/ccp:plan` | Restate requirements, assess risks, and create step-by-step implementation plan |
+| `/ccp:plan-prd` | Generate a lean, problem-first PRD and hand off to `/ccp:plan` for implementation planning |
 | `/ccp:orchestrate` | Sequential and tmux/worktree guidance for multi-agent workflows |
 | `/ccp:aside` | Answer a quick side question without losing context from the current task |
 | `/ccp:context-budget` | Analyze context window usage and find optimization opportunities |
@@ -169,6 +173,7 @@ These are utility commands for day-to-day development: code quality, testing, bu
 | Command | Description |
 |---------|-------------|
 | `/ccp:eval` | Manage eval-driven development workflow |
+| `/ccp:cost-report` | Generate a local Claude Code cost report from a cost-tracker SQLite database |
 | `/ccp:harness-audit` | Run a deterministic repository harness audit and return a scorecard |
 | `/ccp:skill-create` | Analyze git history to extract coding patterns and generate SKILL.md files |
 | `/ccp:skill-health` | Show skill portfolio health dashboard with charts and analytics |