@haposoft/cafekit 0.16.0-rc.7 → 0.16.0

package/src/claude/skills/debug/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: hapo:debug
+name: cf:debug
 description: "Use before fixing any bug, failing test, CI/CD failure, production incident, performance issue, UI regression, flaky test, or unexpected behavior. Diagnostic-only root-cause workflow with evidence, hypotheses, blast-radius mapping, and verification plan."
 user-invocable: true
 when_to_use: "Invoke for evidence-first root-cause diagnosis before any fix."
@@ -23,8 +23,15 @@ Debugging is diagnosis, not repair. Find the source of the failure before changi
 
 Default: systematic diagnosis with no product-code edits, scout first.
 
+## Proportional depth
+
+- **Quick/local:** one deterministic syntax, lint, type, or isolated-test failure. Keep the six-step flow, but omit an incident timeline and recurrence analysis when they cannot change the diagnosis or handoff.
+- **Incident/deep:** production impact, multiple components, intermittent behavior, data/security risk, environment drift, concurrency, or two refuted hypotheses. Add a cross-source timeline, explicit elimination path, trigger/root-cause/contributing-factor separation, and recurrence-prevention gaps.
+
+Depth changes evidence breadth, never the diagnostic-only gate or root-cause standard. Do not make a routine local failure perform incident ceremony merely because more tools are available.
+
 <DIAGNOSTIC-ONLY-GATE>
-`hapo:debug` is read-only for product code.
+`cf:debug` is read-only for product code.
 Do NOT edit product code, apply fixes, create migrations, or add regression tests as implementation.
 Do NOT change config, dependency versions, generated assets, or test snapshots to make the failure disappear.
 Temporary instrumentation is allowed only when it is the minimal way to observe hidden state; record the file/line, capture the proof, remove it before finishing, and report `Temporary instrumentation: removed`.
@@ -48,30 +55,30 @@ Do not ask generic questions before this step unless the issue cannot be located
 Do NOT recommend a fix until the root-cause contract is complete.
 Do NOT stop at the first plausible explanation. Test hypotheses against evidence.
 If 2+ hypotheses are refuted, change strategy before continuing.
-If evidence is insufficient, report `Root cause: unknown`, `Missing Evidence`, and `Next Diagnostic Action`; do not hand off to `hapo:hotfix` as ready.
+If evidence is insufficient, report `Root cause: unknown`, `Missing Evidence`, and `Next Diagnostic Action`; do not hand off to `cf:fix` as ready.
 Answer each item in one concrete sentence.
 If any answer contains 'probably', 'I think', 'something with', or 'maybe' — it is not an answer; gather evidence instead.
 </ROOT-CAUSE-GATE>
 
-If the user asks to fix while still inside `hapo:debug`, finish the debug report first. Then hand off only the completed root-cause contract to `hapo:hotfix`.
+If the user asks to fix while still inside `cf:debug`, finish the debug report first. Then hand off only the completed root-cause contract to `cf:fix`.
 
 ## Process Flow
 
 ```mermaid
 flowchart TD
-    A[Issue Input] --> B[Step 1: Scout via hapo:inspect]
+    A[Issue Input] --> B[Step 1: Scout via cf:scout]
     B --> C[Step 2: Capture Evidence]
     C --> D[Step 3: Pattern Analysis]
     D --> E[Step 4: Hypothesis Tests]
     E --> F[Step 5: Root Cause Trace]
-    F --> G[Step 6: Blast Radius + Verification Plan]
+    F --> G[Step 6: Verification + Prevention Handoff]
     G --> H[Diagnostic Report]
     H --> I{Fix requested?}
-    I -->|Yes| J[Hand off to hapo:hotfix]
+    I -->|Yes| J[Hand off to cf:fix]
     I -->|No| K[Stop after diagnosis]
 ```
 
-**This diagram is the authoritative workflow.** `hapo:debug` stops at diagnosis unless the user explicitly asks to fix.
+**This diagram is the authoritative workflow.** `cf:debug` stops at diagnosis unless the user explicitly asks to fix.
 
 ---
 
@@ -79,8 +86,8 @@ flowchart TD
 
 Understand the affected code before forming hypotheses.
 
-**Action:** Activate `hapo:inspect` for the relevant scope.
-If `hapo:inspect` is unavailable, use direct read-only reconnaissance (`rg`, file reads, test discovery, and `git log`) and state that fallback.
+**Action:** Activate `cf:scout` for the relevant scope.
+If `cf:scout` is unavailable, use direct read-only reconnaissance (`rg`, file reads, test discovery, and `git log`) and state that fallback.
 
 **Checklist:**
 - [ ] Project type, language, framework, runtime, and test runner identified
@@ -107,6 +114,8 @@ Create a baseline that can later prove whether the issue changed.
 - Environment facts: runtime, dependency versions, OS, browser, CI runner, config
 - Whether the issue reproduces consistently or intermittently
 
+For Incident/deep work, build an `Evidence Timeline` from timestamped facts across relevant sources. Normalize timezones, preserve request/trace/run IDs, and distinguish observed ordering from inferred causation. Quick/local work records `Timeline: skipped - local deterministic failure`.
+
 For frontend issues, use `.claude/references/debugger/frontend-verification.md`.
 For CI/log issues, use `.claude/references/debugger/log-ci-analysis.md`.
 For performance issues, use `.claude/references/debugger/performance-diagnostics.md`.
@@ -147,6 +156,7 @@ Rules:
 - Prefer read-only evidence: logs, grep, stack traces, DB queries, browser traces.
 - For flaky async tests, use `.claude/references/debugger/condition-based-waiting.md`.
 - If 2+ hypotheses are refuted, use inversion: ask what evidence would make the current explanation impossible.
+- Preserve an elimination path: for every confirmed, refuted, or inconclusive hypothesis, cite the observation and explain why it changes the candidate set.
 
 **Output:** `✓ Step 4: Hypotheses tested - [confirmed/refuted counts]`
 
@@ -167,18 +177,22 @@ Symptom
 - Symptom: exact observable failure
 - Reproduction: command/user flow/log trigger
 - Expected vs actual behavior
+- Trigger: event or input that activated the failure, or `unknown`
 - Root cause: file:line or config/env source
+- Contributing factors: conditions that increased likelihood or impact but are not sufficient causes, or `none evidenced`
 - Why now: recent change, data state, dependency, environment, timing, or load factor
 - Evidence chain: observations that prove this cause
 - Blast radius: files/modules/tests/users/workflows affected
 
+Do not collapse correlation into causation. The root cause must explain the mechanism from trigger to symptom and identify the earliest owned invariant whose correction would prevent recurrence. Read `.claude/references/debugger/root-cause-tracing.md` for deep call/data flow or test-pollution cases.
+
 **Output:** `✓ Step 5: Root cause traced - [file:line/config/env]`
 
 ---
 
-## Step 6: Blast Radius + Verification Plan
+## Step 6: Blast Radius + Verification And Prevention Plan
 
-Prepare the handoff to `hapo:hotfix` or the user.
+Prepare the handoff to `cf:fix` or the user.
 
 **Verification plan must include:**
 - Original failing command or reproduction path
@@ -188,6 +202,8 @@ Prepare the handoff to `hapo:hotfix` or the user.
 - UI screenshot/console/network checks when relevant
 - Side-effect sweep from `.claude/references/debugger/side-effect-gate.md`
 
+For Incident/deep work, add recurrence-prevention candidates: missing invariant or validation layer, observability/alerting gap, and one regression scenario. These are evidence-backed handoff directions only; `cf:debug` does not implement them.
+
 **Output:** `✓ Step 6: Verification planned - [commands/scenarios]`
 
 ---
@@ -206,19 +222,32 @@ Prepare the handoff to `hapo:hotfix` or the user.
 - Reproduction:
 - Expected:
 - Actual:
+- Trigger:
 - Root cause:
+- Contributing factors:
 - Why now:
 - Evidence chain:
 - Blast radius:
 
+### Evidence Timeline
+- skipped: [reason] | [timestamp/source/id/event]
+
 ### Hypotheses Tested
 1. [confirmed/refuted/inconclusive] [hypothesis] - [evidence]
 
+### Elimination Path
+- [candidate removed or retained] - [decisive observation]
+
 ### Verification Plan
 - Original reproduction:
 - Regression guard:
 - Side-effect sweep:
 
+### Recurrence-Prevention Handoff
+- Missing invariant/validation:
+- Monitoring or alerting gap:
+- Regression scenario:
+
 ### Temporary Instrumentation
 - none | removed: [file:line, purpose, proof captured]
 
@@ -235,21 +264,21 @@ Prepare the handoff to `hapo:hotfix` or the user.
 - [Only if any]
 ```
 
-## Relationship To Hotfix
+## Relationship To Fix
 
-- Use `hapo:debug` to determine what is wrong.
-- Use `hapo:hotfix` to change code only after the root-cause contract is complete.
-- A `Root cause: unknown` report is not ready for hotfix; continue diagnosis or ask for the missing artifact.
-- If `hapo:hotfix` verification fails, return to `hapo:debug` with the new evidence.
+- Use `cf:debug` to determine what is wrong.
+- Use `cf:fix` to change code only after the root-cause contract is complete.
+- A `Root cause: unknown` report is not ready for Fix; continue diagnosis or ask for the missing artifact.
+- If `cf:fix` verification fails, return to `cf:debug` with the new evidence.
 
 ## References
 
 Load as needed:
 - `.claude/references/debugger/core-philosophy.md` - Anti-guessing discipline
 - `.claude/references/debugger/root-cause-tracing.md` - Backward trace to origin
-- `.claude/references/debugger/verification-protocol.md` - Fresh evidence requirements
+- `.claude/references/debugger/verification-protocol.md` - Diagnostic baseline and proof handoff ownership
 - `.claude/references/debugger/log-ci-analysis.md` - Logs and CI/CD failure analysis
-- `.claude/references/debugger/parallel-agent-hydration.md` - Parallel reconnaissance
+- `.claude/references/debugger/parallel-agent-hydration.md` - Permission-gated parallel reconnaissance
 - `.claude/references/debugger/frontend-verification.md` - Browser/UI verification
 - `.claude/references/debugger/performance-diagnostics.md` - Performance investigation
 - `.claude/references/debugger/condition-based-waiting.md` - Flaky async test diagnosis

package/src/claude/skills/delegate/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: hapo:delegate
+name: cf:delegate
 description: "Delegate implementation tasks from Claude Code to external CLI agents (Codex or Grok). Covers task-brief authoring, non-interactive dispatch, permission setup, background monitoring, resume, and independent verification of the returned work."
 user-invocable: true
 when_to_use: "Invoke when the user asks to assign/offload a coding task to codex or grok, or to run work on an external agent CLI."

package/src/claude/skills/develop/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: hapo:develop
+name: cf:develop
 description: "Implement an explicitly requested process-first feature or task, run its real verification, and close it with one evidence owner. Also supports existing legacy Specs packets."
 user-invocable: true
 when_to_use: "Use to implement a ready feature packet, one named task, or a clear low-risk change."
@@ -13,19 +13,19 @@ metadata:
 # Develop — implement, prove, synchronize
 
 Implement only the explicitly requested scope. For a process-first feature,
-`plan.md` and flat tasks are the durable packet; one closeout owner coordinates verification, review, sync, and docs impact without borrowing evidence.
-
+`plan.md` and flat tasks are the durable packet; one closeout owner coordinates
+verification, review, sync, and docs impact without borrowing evidence.
 Develop never starts merely because Specs finished. The user invokes it.
 
 ## Usage and pre-state guard
 
 ```text
-/hapo:develop <feature>
-/hapo:develop specs/<feature>
-/hapo:develop <feature> task-02-<slug>.md
-/hapo:develop <feature> --flash
-/hapo:develop <feature> --parallel [N]
-/hapo:develop <feature> --notes
+/cf:develop <feature>
+/cf:develop specs/<feature>
+/cf:develop <feature> task-02-<slug>.md
+/cf:develop <feature> --flash
+/cf:develop <feature> --parallel [N]
+/cf:develop <feature> --notes
 ```
 
 `--notes` is opt-in. Only then load `references/implementation-notes-template.html`;
@@ -43,20 +43,50 @@ The pair exits `2` before a task edit, receipt, worktree, subagent, or commit. D
 
 1. Resolve one `specs/<feature>/plan.md` plus flat `task-NN-*.md`; an explicit task path wins.
 2. Read C1 scope, exclusions, acceptance mapping, ownership, and task order.
-3. A task is unblocked only when every named dependency is done with a valid inline Receipt.
-4. Full-feature mode selects one unblocked task at a time, in plan order.
-   Specific-task mode implements only that task and then stops.
-5. Without a packet, work directly only when the change is clear, isolated, reversible, and low-risk.
+3. A task is unblocked only when every named dependency is `done` with a valid current inline Receipt.
+4. Without a packet, work directly only when the change is clear, isolated, reversible, and low-risk.
 
 Ambiguity, overlapping ownership, a dependency cycle, or a missing Verification Plan is a blocker. Do not guess.
 
+### Accepted process-first fast path
+
+When line two is `Specs-Contract: process-first-ready-v1`, reuse the accepted C1/C2.
+Perform only a narrow freshness scout for target revision, scope drift, ownership
+conflict, and dependency/state changes. Reopen C1 only for evidenced scope drift;
+do not research, replan, or add a routine user gate before a real blocker or C3.
+This is a source instruction contract, not a parser/runtime or live-model guarantee;
+live-model adherence is `[UNVERIFIED]` without a host invocation.
+
+Load the plan index into working context once. Later byte rereads are narrow drift
+checks; load only the active task's referenced coverage-profile rows, Outcome,
+Scope, Ownership, Acceptance, Dependencies, Verification Plan, owned code, and consumers.
+
+## Current-byte selection
+
+Reread current plan/task bytes before each selection and controller write. Concurrent
+Develop invocations are unsupported; detected state, task, or owned-path drift stops
+before any Status or Receipt write.
+
+| Current bytes | Feature mode | Explicit task mode |
+|---|---|---|
+| More than one `in_progress` | Fail-stop; name every active task. | Fail-stop; do not choose among them. |
+| Exactly one `in_progress` | Resume exactly that task. | Recover it only when it is the exact target; otherwise stop. |
+| Next row is `paused` | `paused` stops chaining; report and stop, never skip past it. | Report the target and stop. |
+| Row is `blocked` or has a bad dependency | Never select it; `blocked` is not dependency-valid. | Report the blocker and stop. |
+| Target is `done` | Continue queue selection only after validating its Receipt. | Report terminal state without mutation and stop. |
+| No task is active | Select the first dependency-valid `pending` row in `plan.md` order. | Start only the exact pending target when dependencies are valid. |
+| Status is missing, duplicate, or unknown | Stop as malformed state. | Stop as malformed state. |
+
+Feature mode repeats this selection only after the current task closes. Specific-task
+mode never touches a sibling and returns after its successful sync without chaining or C3.
+
 ## Modes
 
 ### Sequential feature or specific task
 
-Set the selected task's single `Status:` field to `in_progress`. Implement its
-Outcome and Acceptance only. Do not start the next task until proof, review,
-and sync for the current task finish. A specific-task invocation never chains.
+The controller sets the selected task's single `Status:` to `in_progress`.
+Implement its Outcome and Acceptance only. Keep one unblocked task at a time;
+never start the next before proof, review, and sync finish for the current task.
 
 ### Parallel (`--parallel [N]`)
 
@@ -70,82 +100,79 @@ Flash is an explicit speed trade-off, never completion:
 - run only an available cheap syntax, typecheck, or compile preflight;
 - skip dedicated tests, extended manual checks, and review retry loops;
 - keep `Status: in_progress` and record `FLASH_UNVERIFIED` plus blocker
-  `awaiting /hapo:test <feature>`;
-- do not unblock dependents or report Test PASS, Evidence PASS,
-  production-ready, or done;
-- promotion later requires a fresh canonical PASS receipt through the trusted
-  sync-finalize path.
+  `awaiting /cf:test <feature>`;
+- do not unblock dependents or report Test PASS, Evidence PASS, production-ready, or done;
+- stop this invocation without chaining.
 
-Never weaken, delete, or rewrite tests to make Flash look complete.
+Only a later explicit non-Flash invocation may recover the task. It treats Flash
+output as ephemeral, inspects current bytes and the owned diff, and obtains fresh
+canonical proof through the trusted sync-finalize path. Never weaken, delete, or
+rewrite tests to make Flash look complete.
 
 ## Task cycle
 
 ### 1. Scout
 
 Trace entrypoints, callers, dependents, registration, errors, and owned files.
-Compilation does not prove an unmounted UI, unregistered route, uncalled service, or missing consumer.
+Compilation does not prove an unmounted UI, unregistered route, uncalled service,
+or missing consumer.
+
+For an interrupted `in_progress` task, preserve and inspect current owned changes;
+discard ephemeral, remembered, or prior-attempt proof; compare unmet Acceptance
+against current task bytes and owned diff. Do not blindly replay a non-idempotent
+mutation. Resume only unmet work, then run fresh verification.
 
 ### 2. Implement
 
 Honor Scope, Ownership, Acceptance, and Dependencies. Do not silently replace named contracts;
 scope expansion requires evidence and a return to C1, not implementation convenience.
+Load `references/subagent-patterns.md` when dispatch helps; only the controller writes Status or Receipt.
 
-### 3. Verify and review once
-
-The test owner executes the exact Verification Plan and records real output.
-The review owner, when risk or repository policy requires review, evaluates
-correctness, security, scope, and reachability but does not manufacture proof.
-Use `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`; only literal PASS can close.
-
-Load `references/quality-gate.md` for the closeout contract. Remediate an
-observed failure, then rerun only affected proof and review. Do not blind-retry
-a blocked environment. After three failed repair rounds, stop and ask the user.
-
-### 4. Write the inline Receipt and sync
-
-After a real pass, append or replace the task's final `## Receipt` with:
+### 3. Verify, review, and close
 
-- `Verification: PASS`;
-- the exact `Command:` and `Exit: 0`;
-- runtime-derived `Base:` and `Head:`;
-- a non-empty fenced block containing current command output;
-- required negative, reachability, and artifact proof from the task.
+The test owner executes each exact Verification Plan and records real output. The
+review owner evaluates correctness, security, scope, and reachability without
+manufacturing proof. Use `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`; only literal PASS can close.
 
-Then set `Status: done`, update only implemented checkboxes, and recompute the
-queue. Missing, stale, contradictory, zero-test, placeholder, or marker-only
-proof leaves the task unfinished.
+Load `references/quality-gate.md`. Remediate an observed failure, then rerun only
+affected proof/review. Do not blind-retry a blocked environment. After three failed
+repair rounds, stop and ask the user.
 
-### 5. Finish the requested boundary
+After a real pass, the controller writes the task's final inline `## Receipt` with
+`Verification: PASS`, exact `Command`, `Exit: 0`, runtime-derived `Base:` and `Head:`,
+non-empty current output, and required negative/reachability/artifact proof; then it
+sets `Status: done` and only implemented checkboxes. Missing, stale, contradictory,
+zero-test, placeholder, marker-only, skipped, or remembered proof is unfinished.
 
-Specific-task mode stops after its sync. Full-feature mode continues one task
-at a time, then runs the feature-level integration command and reachability
-check named by the repository or plan. Show current evidence and limitations at
-C3; the user decides completion.
+### 4. Finish the requested boundary
 
-Evaluate docs impact from the behavior actually changed:
+Reread the task after sync and recompute the queue from current bytes. Specific-task
+mode has already returned. Full-feature mode continues one task at a time, then runs
+the named feature-level integration and reachability checks. Before C3, apply the
+quality-gate final-Head fixed point; show current evidence and limitations, and let
+the user decide completion.
 
-- `none`: report it and make no docs edit;
-- `minor` or `major`: update only affected existing docs through the docs flow.
+Evaluate docs impact from behavior actually changed: `none` means report only;
+`minor` or `major` updates only affected existing docs through the docs flow.
 
 ## Definition of done
 
-Done requires satisfied acceptance, reachable behavior, current executable
-proof, correct Base/Head binding, resolved blocking review findings, and no
-scope substitution. `PASS_WITH_WARNINGS`, `NO_TESTS`, `FLASH_UNVERIFIED`, or a
-review-only pass cannot close work.
+Done requires satisfied acceptance, reachable behavior, current executable proof,
+stable Base/Head binding, resolved blocking review findings, and no scope substitution.
+`PASS_WITH_WARNINGS`, `NO_TESTS`, `FLASH_UNVERIFIED`, or review-only pass cannot close.
 
 ## Attached references
 
-- `references/quality-gate.md` — proof and review ownership.
+- `references/quality-gate.md` — proof, review, final-Head, and shared-run ownership.
 - `references/parallel-waves.md` — opt-in isolated worktree waves.
+- `references/subagent-patterns.md` — task-local briefs and controller-only handoff.
 - `references/implementation-notes-template.html` — only with `--notes`.
 
 ## Legacy workflow compatibility
 
-If the selected feature contains `spec.json`, use its persisted
-`workflow_policy`, `task_registry`, nested task paths, typed boundaries,
-separate task receipts, and feature closeout receipt exactly as the legacy
-adapters require. Preserve `planning_depth`, `assurance_level`, derived lane,
-and read-only `execution_tier`; do not project these fields into a new v3
-packet. Keep JSON and Markdown status synchronized, and use the existing
-completion-authority path for final closeout.
+If the selected feature contains `spec.json`, use its persisted `workflow_policy`,
+`task_registry`, nested task paths, typed boundaries, separate task receipts, and
+feature closeout receipt exactly as legacy adapters require. Preserve `planning_depth`,
+`assurance_level`, derived lane, and read-only `execution_tier`; do not project these
+fields into a new v3 packet. Keep JSON and Markdown status synchronized, and use the
+existing completion-authority path for final closeout.

package/src/claude/skills/develop/references/parallel-waves.md

@@ -1,102 +1,75 @@
-# Parallel waves — `hapo:develop --parallel`
+# Parallel waves — `cf:develop --parallel`
 
-Load this reference only for explicit parallel execution. The goal is bounded
-concurrency with immutable provenance and one state writer.
+Load this reference only for explicit parallel execution. The goal is bounded concurrency with immutable provenance and one state writer.
 
 ## Preconditions
 
-1. Confirm the work context is a Git repository and worktree isolation is
-   available. Otherwise state why and fall back to the sequential loop.
+1. Confirm Git and isolated worktree support; otherwise state why and fall back to the sequential loop.
 2. Respect `.claude/runtime.json` `develop.parallel: false` when present.
 3. Clamp `--parallel N` to 1..5; default to 3.
-4. Require a clean destination and record its exact `base_sha`. Stop without
-   mutation if cleanliness or base compatibility fails.
-5. Confirm whether the user's parallel consent also authorizes worker commits
-   and controller cherry-picks before creating worktrees.
+4. Require a clean destination; record exact `base_sha` and stop on incompatible bases.
+5. Confirm consent for worker commits and controller cherry-picks before creating worktrees.
 
-Every task receipt for a wave records:
+Range facts belong only in controller handoff metadata, never the inline Receipt:
 
 ```text
 base_sha: <destination commit before dispatch>
-head_sha: <worker or integrated commit>
+head_sha: <worker commit at handoff>
 branch: <worker branch>
-worktree_path: <path>
+worktree_path: <isolated worktree>
 commit_range: <base_sha>..<head_sha>
 retention: retained|released
 cleanup_authorization: pending|explicit-discard|merged-release
 ```
 
-Test and review commands inspect `git diff <base_sha>..<head_sha>`, never an
-ambient working-tree diff. A fix creates a new commit and advances Head.
+The final inline Receipt instead receives fresh runtime Base/Head, exact command, exit, and output after integration; handoff metadata cannot substitute for it.
 
-## Build a wave
+## Build and dispatch a wave
 
-Read dependencies from the plan task table and each flat task's
-`## Dependencies`. A candidate is ready only when all named dependencies are
-done with valid Receipts.
+Read dependencies from the plan table and each task. A candidate is ready only when every named dependency is `done` with a valid current Receipt.
+Add tasks in plan order up to the cap. Exclude normalized path overlap or a shared mutable registry, lockfile, manifest, generated output, migration, or export barrel.
+Uncertain overlap is a conflict. One file has one writer per wave.
 
-Add ready tasks in plan order up to the cap, excluding a task when it shares a
-write target with an earlier task or touches the same mutable registry,
-lockfile, manifest, generated output, migration, or export barrel. Normalize
-paths. Uncertain overlap is a conflict, not an invitation to guess.
+Each worker receives the complete task-local brief from `subagent-patterns.md`, exact owned paths, worktree, acceptance, proof command, and these constraints:
 
-One file has one writer per wave. If no safe wave remains, use the sequential
-loop and state the dependency or ownership conflict.
-
-## Dispatch
-
-Each worker receives the complete task packet, work context, exact owned paths,
-acceptance, Verification Plan, dependencies, and these constraints:
-
-1. Work only in the assigned isolated worktree.
-2. Do not edit `plan.md`, task Status, or `## Receipt`; the controller owns
-   state and evidence synchronization.
-3. Do not touch a path outside granted ownership or undo another worker's edit.
-4. Run task-local prechecks and report exact commands and exits.
-5. Commit only when the user's authorization covers worker commits.
-6. Return status plus branch, worktree, Base, Head, range, and retention.
+1. Edit only granted paths in the assigned worktree; never undo another worker.
+2. Do not edit `plan.md`, Status, or `## Receipt`; only the controller writes state/proof.
+3. Report exact precheck commands/exits; commit only with user authorization.
+4. Return status plus branch, worktree, Base, Head, complete range, owned-path tree, and retention.
 
 A blocked or failed worker keeps its identifiable worktree and branch. Never
 force-delete it without merge success or explicit discard authorization.
 
-## Verify before integration
+## Prove the full handoff
 
-Inside each worktree, run the task's proof through `quality-gate.md` against the
-immutable commit range. A task with missing proof, overlap, or unresolved High
-or Critical finding is not eligible to integrate. Three failed repair rounds
-collapse only that task; siblings may finish but do not erase its blocker.
+Before integration, enumerate every commit with `git rev-list --reverse <base_sha>..<head_sha>`
+and the complete changed tree with `git diff --name-status <base_sha>..<head_sha>`.
+Reject an empty, discontinuous, partial, or base-incompatible range; duplicate/missing commits; and every path outside Ownership.
+Test/review the complete immutable range through `quality-gate.md`; unresolved High/Critical findings block that task.
 
 ## Integrate sequentially
 
-Apply accepted worker commits one at a time in plan order:
+In plan order, apply every enumerated worker commit, in range order:
 
 ```bash
-git cherry-pick <worker-commit>
+git cherry-pick <next-worker-commit>
 ```
 
-On conflict, abort the cherry-pick, mark the task blocked, and retain its
-worktree/branch. After success, update the receipt range to the integrated Head.
-Release a worktree only after recording `cleanup_authorization: merged-release`.
+After each pick, verify the destination contains that source commit's patch. After the last, compare the integrated owned-path tree with the worker tree.
+Any missing/extra commit or path stops before post-merge proof. On conflict, abort the pick, block that task, and retain its branch/worktree.
+Release only after recording `cleanup_authorization: merged-release` in handoff metadata.
 
 ## Post-merge proof
 
-After the wave's last integration, run an affected integration command derived
-from the tasks and repository contract. Record command, exit, Base, Head,
-range, and output. Failure blocks the next wave.
-
-Classify a failure before acting:
-
-- `baseline`: reproduces from the recorded Base;
-- `environment`: required tool, service, permission, or dependency unavailable;
-- `spec`: acceptance or evidence contract is wrong or incomplete;
-- `code`: implementation or integration regression.
-
-Do not blind-retry. Fix code/spec with a new commit and rerun affected proof;
-record baseline/environment as blockers.
+Only after complete range/tree integration, run the affected integration command
+against the fresh runtime Base/Head. Failure blocks the next wave; classify it as
+`baseline`, `environment`, `spec`, or `code`. Do not blind-retry: code/spec repair
+creates a new commit and repeats the full range/tree audit; other classes remain blockers.
 
-After the final wave, run the feature-level integration and reachability proof.
-The controller then writes inline Receipts and Status updates one task at a
-time. Worker reports are evidence inputs, not permission to claim done.
+After the final wave, run feature integration and reachability proof. The controller
+then writes inline Receipts and Status one task at a time. Worker reports and range
+metadata are inputs, not completion authority; incomplete workers cannot be hidden
+by successful siblings.
 
 ## Legacy workflow compatibility
 

package/src/claude/skills/develop/references/quality-gate.md

@@ -33,6 +33,16 @@ Before completion, verify:
 zero-test, stale, copied, or marker-only proof is unfinished. A review PASS
 cannot replace execution evidence.
 
+## Shared captured runs
+
+A shared command may prove several tasks only from one fresh captured run. For
+each task, map the exact command, current Head, required proof level, oracle, one
+uniquely named probe, and that probe's executed/pass count. Every mapped probe
+must execute at least once and all executions must pass. Duplicate probe names,
+ambiguous ownership/counts, skip, skipped, todo, cancel, canceled, cancelled, or
+remembered output cannot close any mapped task. Source, installed, and live proof
+levels remain distinct; never promote evidence from a lower level.
+
 ## Review focus
 
 Check task Outcome, Scope, Acceptance, Dependencies, Verification Plan, changed
@@ -62,6 +72,22 @@ after three failed repair rounds: stop and request user direction
 unfinished for state synchronization. Never retry an unchanged environment to
 manufacture a green result.
 
+## Final-Head fixed point
+
+Before C3, repeat within the same three-round repair cap:
+
+1. Capture runtime Head and list every `done` task whose Receipt is stale or
+   bound to a different Head.
+2. Run each stale task's exact proof freshly and let only the controller replace
+   its inline Receipt. If proof changes any non-Specs byte, stop as BLOCKED;
+   remediation must settle those bytes before proof can bind them.
+3. Capture runtime Head again and rescan all `done` Receipts.
+
+Stop only when consecutive Head captures are identical and every `done` Receipt
+names that current Head. A single pass, remembered result, copied Receipt, or
+proof promoted from another level is not a fixed point. If Head keeps moving or
+the repair cap is reached, report the blocker instead of opening C3.
+
 ## Flash gate
 
 With explicit `--flash`, run only a cheap available preflight and a basic
@@ -72,12 +98,13 @@ Mode: --flash
 Tests: skipped by user request
 Evidence: FLASH_UNVERIFIED
 Status: in_progress
-Blocker: awaiting /hapo:test <feature>
+Blocker: awaiting /cf:test <feature>
 ```
 
-Flash does not write a PASS receipt, mark done, unblock dependents, or report
-production readiness. Trusted sync-finalize may promote only after fresh proof
-passes the same receipt contract above.
+Flash does not write a PASS receipt, mark done, unblock dependents, chain, or
+report production readiness. Only a later explicit non-Flash invocation may
+recover it: discard Flash output as canonical evidence, inspect current bytes
+and the owned diff, and run fresh proof under the same sync-finalize contract.
 
 ## Docs impact and C3