@haposoft/cafekit 0.16.6 → 0.18.0

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

@@ -16,164 +16,61 @@ Debugging is diagnosis, not repair. Find the source of the failure before changi
 
 ## Arguments
 
-- `--quick` - Abbreviated path for syntax, lint, type, or single-test failures with obvious local scope
-- `--ci` - Focus on CI/CD logs, runner environment, dependency versions, and pipeline setup
-- `--frontend` - Include browser console, screenshot, accessibility tree, network, and responsive checks
-- `--perf` - Include baseline measurements, bottleneck layer, profiling, and before/after targets
+- `--quick` - obvious local syntax, lint, type, or single-test failure
+- `--ci` - CI/CD logs, runner environment, dependency versions, pipeline setup
+- `--frontend` - browser console, screenshot, accessibility tree, network, responsive checks
+- `--perf` - baseline measurements, bottleneck layer, profiling, before/after targets
 
-Default: systematic diagnosis with no product-code edits, scout first.
+Flags are optional hints. Without one, choose the depth yourself from the evidence below.
 
 ## 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.
+- **Quick/local:** one deterministic syntax, lint, type, or isolated-test failure.
+- **Standard:** a reproducible failure inside one component or service that fits neither other depth.
 - **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.
+Quick/local and Standard reports write the root-cause contract, the confirmed hypothesis, the verification plan, and the fix direction; when the root cause is unknown, they list every hypothesis tested instead. Only Incident/deep reports add `Evidence Timeline`, the other hypotheses tested, `### Elimination Path`, and `### Recurrence-Prevention Handoff`. A shorter report omits those sections; it does not write them as skipped.
+
+Depth changes evidence breadth and report length, never the standards below, the diagnostic-only gate, or the root-cause standard. Do not make a routine local failure perform incident ceremony merely because more tools are available.
 
 <DIAGNOSTIC-ONLY-GATE>
 `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.
+Do NOT run heavy or costly reads — table scans, bulk exports, load or stress runs — against shared staging or production without the user's explicit permission; prefer local or fixture data.
 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`.
 </DIAGNOSTIC-ONLY-GATE>
 
 <HARD-GATE-SCOUT-FIRST>
 Before hypotheses, inspect the actual codebase context.
-You must identify:
-- project type, language, framework, runtime, and test runner
-- affected files/modules and exact symptom location
-- direct callers, dependents, and data/config boundaries
-- related tests and reproduction commands
-- recent commits touching affected paths
-- adjacent known-good implementation patterns
-
+You must identify the project type, language, framework, runtime, and test runner; the affected files/modules and exact symptom location; direct callers, dependents, and data/config boundaries; related tests and reproduction commands; recent commits touching affected paths; and adjacent known-good implementation patterns.
 After scout, provide a 3-6 bullet codebase-context summary before evidence capture.
 Do not ask generic questions before this step unless the issue cannot be located from the prompt or repository.
 </HARD-GATE-SCOUT-FIRST>
 
 <ROOT-CAUSE-GATE>
 Do NOT recommend a fix until the root-cause contract is complete.
-Do NOT stop at the first plausible explanation. Test hypotheses against evidence.
+Do NOT stop at the first plausible explanation unless evidence directly confirms it. 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 `cf:fix` as ready.
+Report confidence `high` only when the cause was reproduced or observed at runtime — the failing command run, a log or probe read. From static reading alone, report at most `medium`.
 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 `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 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: Verification + Prevention Handoff]
-    G --> H[Diagnostic Report]
-    H --> I{Fix requested?}
-    I -->|Yes| J[Hand off to cf:fix]
-    I -->|No| K[Stop after diagnosis]
-```
-
-**This diagram is the authoritative workflow.** `cf:debug` stops at diagnosis unless the user explicitly asks to fix.
-
----
-
-## Step 1: Scout
-
-Understand the affected code before forming hypotheses.
-
-**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
-- [ ] Affected files and modules identified
-- [ ] Direct dependencies and call paths mapped
-- [ ] Inputs/outputs, data boundaries, and config/env boundaries mapped
-- [ ] Related tests located
-- [ ] Recent changes checked: `git log --oneline -10 -- <affected-files>`
-- [ ] Existing working examples or adjacent patterns identified
-
-**Output:** `✓ Step 1: Scouted - [N] files, [M] deps, [K] tests` plus a 3-6 bullet context summary.
-
----
+`cf:debug` stops at diagnosis unless the user explicitly asks to fix. 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`.
 
-## Step 2: Capture Evidence
+## Standards
 
-Create a baseline that can later prove whether the issue changed.
+**Scout.** Invoke the `scout` skill (`cf:scout`) for the affected scope and fold its findings into the codebase-context summary the scout-first gate requires, including `git log --oneline -10 -- <affected-files>`. If `cf:scout` is not installed, use direct read-only reconnaissance (`rg`, file reads, test discovery, and `git log`) and say so.
 
-**Capture:**
-- Exact command, URL, user flow, or trigger
-- Exact error message, stack trace, failing assertion, or visual symptom
-- Expected vs actual behavior
-- Relevant logs with timestamps
-- 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`.
-
-**Output:** `✓ Step 2: Evidence captured - baseline command/symptom recorded`
-
----
-
-## Step 3: Pattern Analysis
-
-Before proposing a cause, compare against known-good patterns.
-
-**Check:**
-- Similar implementation that works
-- Similar tests that pass
-- Recent code that changed the same contract
-- Config/env differences between passing and failing contexts
-- Dependency/API contract changes
-
-**Output:** `✓ Step 3: Patterns compared - [working reference] vs [failing path]`
-
----
+**Evidence baseline.** Capture what can later prove whether the issue changed: the exact command, URL, user flow, or trigger; the exact error, stack trace, failing assertion, or visual symptom; expected vs actual behavior; relevant logs with timestamps; environment facts (runtime, dependency versions, OS, browser, CI runner, config); and whether it 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. When no source carries timestamps, the timeline says so in one line and names the sources checked. For frontend issues, use `.claude/references/debugger/frontend-verification.md`; for CI/log issues, `.claude/references/debugger/log-ci-analysis.md`; for performance issues, `.claude/references/debugger/performance-diagnostics.md`.
 
-## Step 4: Hypothesis Tests
+**Known-good comparison.** Before proposing a cause, compare against known-good patterns: a similar implementation that works, similar tests that pass, recent code that changed the same contract, config/env differences between passing and failing contexts, and dependency/API contract changes.
 
-Create 2-3 competing hypotheses. Test one variable at a time.
+**Hypotheses.** When evidence does not directly confirm the first explanation, create 2-3 competing hypotheses. Test one variable at a time, each stated as `Hypothesis:`, `Confirm if:` (evidence that proves it), `Refute if:` (evidence that disproves it), `Quick test:` (command/search/log/query), and `Result: confirmed | refuted | inconclusive`. Never batch unrelated changes as a test. 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. Quick/local and Standard reports fold it into the confirmed hypothesis's evidence; only Incident/deep reports write it under `### Elimination Path`.
 
-```text
-Hypothesis: [statement]
-Confirm if: [evidence that proves it]
-Refute if: [evidence that disproves it]
-Quick test: [command/search/log/query]
-Result: confirmed | refuted | inconclusive
-```
-
-Rules:
-- Never batch unrelated changes as a test.
-- 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]`
-
----
-
-## Step 5: Root Cause Trace
-
-Trace backward from symptom to origin.
-
-```text
-Symptom
-  <- immediate cause
-    <- contributing factor
-      <- ROOT CAUSE
-```
-
-**Exact root-cause contract:**
+**Root cause.** Trace backward from the symptom through the immediate cause and contributing factors to the root cause, and complete the exact root-cause contract:
 - Symptom: exact observable failure
 - Reproduction: command/user flow/log trigger
 - Expected vs actual behavior
@@ -186,35 +83,18 @@ Symptom
 
 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 And Prevention Plan
-
-Prepare the handoff to `cf:fix` or the user.
-
-**Verification plan must include:**
-- Original failing command or reproduction path
-- Targeted regression test or scenario
-- Affected-module tests
-- Typecheck/lint/build commands when relevant
-- 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]`
-
----
+**Verification and prevention plan.** Prepare the handoff to `cf:fix` or the user. Verification plan must include: the original failing command or reproduction path; a targeted regression test or scenario; affected-module tests; typecheck/lint/build commands when relevant; UI screenshot/console/network checks when relevant; and the 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.
 
 ## Diagnostic Report Format
 
+Open the final answer with `## Debug Report` in this shape, keeping only the sections its depth requires under Proportional depth. Write `Temporary Instrumentation` only when instrumentation was added, and `Missing Evidence` and `Next Diagnostic Action` only when the root cause is unknown.
+
 ```markdown
 ## Debug Report
 
 **Issue:** [one-line summary]
 **Mode:** quick | standard | ci | frontend | perf
+**Depth:** quick/local | standard | incident/deep
 **Root cause confidence:** high | medium | low | unknown
 
 ### Root Cause Contract
@@ -229,12 +109,12 @@ For Incident/deep work, add recurrence-prevention candidates: missing invariant
 - Evidence chain:
 - Blast radius:
 
-### Evidence Timeline
-- skipped: [reason] | [timestamp/source/id/event]
-
 ### Hypotheses Tested
 1. [confirmed/refuted/inconclusive] [hypothesis] - [evidence]
 
+### Evidence Timeline
+- [timestamp/source/id/event]
+
 ### Elimination Path
 - [candidate removed or retained] - [decisive observation]
 
@@ -249,7 +129,7 @@ For Incident/deep work, add recurrence-prevention candidates: missing invariant
 - Regression scenario:
 
 ### Temporary Instrumentation
-- none | removed: [file:line, purpose, proof captured]
+- removed: [file:line, purpose, proof captured]
 
 ### Recommended Fix Direction
 [Smallest root-cause fix, or "insufficient evidence"]

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

@@ -1,6 +1,6 @@
 ---
 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."
+description: "Implement an explicitly requested process-first feature or task, run its real verification, and close it with one evidence owner."
 user-invocable: true
 when_to_use: "Use to implement a ready feature packet, one named task, or a clear low-risk change."
 category: utilities
@@ -42,7 +42,7 @@ The pair exits `2` before a task edit, receipt, worktree, subagent, or commit. D
 ## Resolve the work packet
 
 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.
+2. Read GATE-SCOPE scope, exclusions, acceptance mapping, ownership, and task order.
 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.
 
@@ -50,16 +50,16 @@ Ambiguity, overlapping ownership, a dependency cycle, or a missing Verification
 
 ### Accepted process-first fast path
 
-When line two is `Specs-Contract: process-first-ready-v1`, reuse the accepted C1/C2.
+When line two is `Specs-Contract: process-first-ready-v1`, reuse the accepted GATE-SCOPE/GATE-REVIEW.
 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.
+conflict, and dependency/state changes. Reopen GATE-SCOPE only for evidenced scope drift;
+do not research, replan, or add a routine user gate before a real blocker or GATE-DONE.
 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.
+Scope, Ownership, Steps, Acceptance, Dependencies, Verification Plan, Failure Protocol, owned code, and consumers.
 
 ## Current-byte selection
 
@@ -78,7 +78,7 @@ before any Status or Receipt write.
 | 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.
+mode never touches a sibling and returns after its successful sync without chaining or GATE-DONE.
 
 ## Modes
 
@@ -95,25 +95,20 @@ isolated worktrees, a bounded wave, and one controller writer; otherwise work se
 
 ### Flash (`--flash`)
 
-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 /cf:test <feature>`;
-- do not unblock dependents or report Test PASS, Evidence PASS, production-ready, or done;
-- stop this invocation without chaining.
-
-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.
+Load `references/quality-gate.md`. Flash is an explicit speed trade-off, never completion: run a
+cheap preflight, skip dedicated tests, keep `Status: in_progress` with `FLASH_UNVERIFIED` and the
+blocker `awaiting /cf:test <feature>`, do not unblock dependents or report PASS, and
+stop this invocation without chaining.
+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.
+Read the test or probe that will judge this task before implementing against it.
 Compilation does not prove an unmounted UI, unregistered route, uncalled service,
 or missing consumer.
 
@@ -124,8 +119,11 @@ mutation. Resume only unmet work, then run fresh verification.
 
 ### 2. Implement
 
+Unless under `--flash` or the command costs money or writes artifacts, run the task's exact Verification Plan command once before changing anything and expect it to fail; this pre-change run is not a repair round.
+Passing before any change, outside a resumed task, means the plan cannot judge the work and is a blocker; so is a failure naming something other than the unmet Acceptance, which is a blocker to raise, not a defect to work around while implementing. A failure from the command itself — a wrong path, a missing tool or module, the environment — is BLOCKED, not FAIL, even when the runner reports `not ok` and even when the Acceptance or a test file shows the right command: set the task's single `Status:` to `blocked` with a `Blocker:` line naming the command and its error, write no Receipt, revert any edit made in this run, and report; you may suggest a corrected command for the plan, but never run it as proof.
+
 Honor Scope, Ownership, Acceptance, and Dependencies. Do not silently replace named contracts;
-scope expansion requires evidence and a return to C1, not implementation convenience.
+scope expansion requires evidence and a return to GATE-SCOPE, not implementation convenience.
 Load `references/subagent-patterns.md` when dispatch helps; only the controller writes Status or Receipt.
 
 ### 3. Verify, review, and close
@@ -134,12 +132,14 @@ The test owner executes each exact Verification Plan and records real output. Th
 review owner evaluates correctness, security, scope, and reachability without
 manufacturing proof. Use `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`; only literal PASS can close.
 
-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.
+Load `references/quality-gate.md`. Remediate an observed failure (a blocked Command is not a failure to remediate), then rerun only
+affected proof/review. Do not blind-retry a blocked environment. One repair round is one
+observed failure plus its repair and rerun, from proof or from review alike. After three
+failed repair rounds, stop and ask the user.
 
-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:`,
+**The Receipt is written last, after proof and review have both passed**; writing it earlier
+and reopening the task is a defect, not a shortcut. After a real pass, the controller writes the task's final inline `## Receipt` with
+`Verification: PASS`, exact `Command`, `Exit: 0`, `Base:` and `Head:` copied from the `Base` and `Head` fields of `node .claude/scripts/provenance.cjs --project-root . --specs-root specs --spec-file <task file> --feature-name <feature> --session <any label> --json` run after the last change outside the specs root (never typed or computed by hand),
 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.
@@ -148,7 +148,7 @@ zero-test, placeholder, marker-only, skipped, or remembered proof is unfinished.
 
 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
+the named feature-level integration and reachability checks. Before GATE-DONE, apply the
 quality-gate final-Head fixed point; show current evidence and limitations, and let
 the user decide completion.
 
@@ -167,12 +167,3 @@ stable Base/Head binding, resolved blocking review findings, and no scope substi
 - `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 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

@@ -70,11 +70,3 @@ After the final wave, run feature integration and reachability proof. The contro
 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
-
-For an existing `spec.json` feature, readiness and dependencies come from the
-persisted `task_registry` and typed `coordination.boundaries`. Workers still do
-not edit that state. The controller writes the legacy separate task receipt,
-synchronizes registry plus nested task Markdown, and creates the required final
-feature receipt only after integrated proof.

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

@@ -26,7 +26,10 @@ Before completion, verify:
 4. negative/failure behavior named by Acceptance;
 5. artifact bytes and SHA-256 when the task declares an artifact;
 6. an inline `## Receipt` with `Verification: PASS`, exact `Command`, `Exit: 0`,
-   runtime-bound Base/Head, and non-empty fenced command output;
+   runtime-bound Base/Head, and non-empty fenced command output; take Base and Head
+   from the `Base` and `Head` fields printed by
+   `node .claude/scripts/provenance.cjs --project-root . --specs-root specs --spec-file <task file> --feature-name <feature> --session <any label> --json`,
+   run after the last change outside the specs root, and never type, abbreviate, or compute them by hand;
 7. correctness/security/scope review at the required depth.
 
 `PRECHECK_FAIL` outranks no-tests. Missing, pending, placeholder, contradictory,
@@ -74,19 +77,25 @@ manufacture a green result.
 
 ## Final-Head fixed point
 
-Before C3, repeat within the same three-round repair cap:
+Before GATE-DONE, 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;
+   its inline Receipt. A Receipt that declares artifacts with `sha256` may instead be
+   rebound to the current Head once every declared hash is recomputed and matches, and only
+   when no file the proof reads changed between its recorded Head and the current one and
+   every claim in the Receipt is derived from those artifacts; matching bytes prove the
+   artifacts did not move, not that the proof would still produce them. Otherwise, and for a
+   Receipt with no artifact, re-run; only the controller rebinds.
+   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.
+the repair cap is reached, report the blocker instead of opening GATE-DONE.
 
 ## Flash gate
 
@@ -106,16 +115,9 @@ 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
+## Docs impact and GATE-DONE
 
 After proof and review, classify docs impact as `none`, `minor`, or `major`.
 Update only affected existing docs when impact is not none. Show the user the
-current command evidence and limitations at C3; do not infer approval from a
+current command evidence and limitations at GATE-DONE; do not infer approval from a
 receipt.
-
-## Legacy workflow compatibility
-
-Existing kernel packets keep their separate `receipts/<task-basename>.md`, task
-identity/path metadata, final `feature-receipt.md`, persisted independent-audit
-obligations, and completion-authority checks. The same proof/review ownership
-applies. Do not copy that storage shape into a flat process-first task.

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

@@ -125,7 +125,7 @@ Create the standard project docs set from the current source code.
 Use when:
 - the repository has code but no useful docs
 - the user asks to create project docs
-- SessionStart docs-sync reports missing documentation
+- `echo '{}' | node .claude/hooks/docs-sync.cjs` reports missing documentation
 
 Load:
 - `references/standard-docs-workflow.md`
@@ -138,7 +138,7 @@ Refresh existing docs after code changes.
 Use when:
 - docs exist and source code changed
 - the user asks to update or refresh docs
-- docs-sync reports stale docs
+- `echo '{}' | node .claude/hooks/docs-sync.cjs` reports stale docs
 
 Load:
 - `references/standard-docs-workflow.md`

package/src/claude/skills/docs/references/update-workflow.md

@@ -24,7 +24,7 @@ Refresh existing living docs after code or project-state changes without rewriti
 4. Identify update focus:
    - user-named module or doc
    - recent source diff
-   - docs-sync stale hash signal
+   - docs-sync stale hash signal (run `echo '{}' | node .claude/hooks/docs-sync.cjs` from the project root)
    - a full docs refresh only when user asks for it
 
 ### Phase 1: Source Change Scout