@haposoft/cafekit 0.16.7 → 0.18.1

package/src/claude/skills/code-review/SKILL.md

@@ -12,83 +12,50 @@ metadata:
 ---
 # Code Review — correctness and compliance owner
 
-Review evaluates correctness, security, scope, architecture, and specification
-compliance. It does not execute the test suite, create a canonical execution
-receipt, or turn a missing test result into a review-owned proof. `cf:test`
-owns execution proof; the single closeout owner combines both results.
+Review evaluates correctness, security, scope, architecture, and specification compliance. It does not execute the test suite, create a canonical execution receipt, or turn a missing test result into a review-owned proof. `cf:test` owns execution proof; the single closeout owner combines both results.
 
 ## Input and depth
 
-With no argument, review the pending diff. Supported targets are a PR, commit,
-pending changes, or an explicit path. Load only current target bytes and needed
-references. For a valid process-first target, read `plan.md`, the active flat
-`task-NN-*.md`, and the controller-validated `test-proof-v1` handoff. Mixed,
-orphaned, malformed, symlinked, nonregular, or identity-conflicting packet state
-is `BLOCKED`; review never migrates it.
+With no argument, review the pending diff. Supported targets are a PR, commit, pending changes, or an explicit path. Load only current target bytes and needed references. For a valid process-first target, read `plan.md`, the active flat `task-NN-*.md`, and the controller-validated `test-proof-v1` handoff. Orphaned, malformed, symlinked, nonregular, or identity-conflicting packet state is `BLOCKED`; review never migrates it.
 
-For process-first proof consumption, this skill's `## Execution-proof boundary`
-is authoritative. Do not load or follow legacy separate-receipt paragraphs from
-references; they apply only after the Legacy route below is selected.
+For proof consumption, this skill's `## Execution-proof boundary` is authoritative.
 
-Select review depth from `assurance_level`, risk, and blast radius. Lane is a
-derived view:
+Select review depth from risk and blast radius: for a process-first task, its coverage-profile Risk/evidence. Lane is a derived view:
 
 - Direct: targeted correctness/security/spec check;
 - Standard: bounded feature review at closeout;
 - Critical: independent, adversarial review covering every required obligation.
 
-Do not use file count as the depth selector. `execution_tier` is a read-only
-legacy adapter and cannot choose a review sequence. The review contract has no
-fixed Light/Standard/Deep sequence.
+Do not use file count as the depth selector. The review contract has no fixed Light/Standard/Deep sequence.
 
-## Review stages
+## Standards
 
-### 1. Specification compliance
+**Specification compliance.** For process-first work, compare the diff with current plan scope and the active task's Outcome, Scope, Coverage, Ownership, Acceptance, Dependencies, Verification Plan, and declared runtime reachability. Identify missing behavior, unjustified extras, contract substitution, orphaned outputs, and incorrect completion claims. If a design image or document carries requirements, load its multimodal reference only when needed; do not guess from a filename.
 
-For process-first work, compare the diff with current plan scope and the active
-task's Outcome, Scope, Coverage, Ownership, Acceptance, Dependencies,
-Verification Plan, and declared runtime reachability. Identify missing behavior,
-unjustified extras, contract substitution, orphaned outputs, and incorrect
-completion claims. If a design image or document carries requirements, load its
-multimodal reference only when needed; do not guess from a filename.
+**Correctness and security.** Trace changed entrypoints and callers. Check boundary validation, error paths, resource handling, race assumptions, secrets, authorization, persistence, and failure recovery in proportion to risk. Apply YAGNI/KISS/DRY as maintainability signals, not as a numeric score.
 
-### 2. Correctness and security
+**Adversarial checks.** Try empty, malformed, unauthorized, duplicate, stale, boundary, and concurrent inputs where the changed contract makes them relevant. For Critical obligations, review the required independent evidence and provenance. A marker such as `Audit: PASS` is not independent evidence.
 
-Trace changed entrypoints and callers. Check boundary validation, error paths,
-resource handling, race assumptions, secrets, authorization, persistence, and
-failure recovery in proportion to risk. Apply YAGNI/KISS/DRY as maintainability
-signals, not as a numeric score.
+## Test-run boundary
 
-### 3. Adversarial checks
+Review reads code; it does not run tests. Never run the project's test suite or a test file, not even as a sanity check. A read-only run of the reviewed code (for example `node -e` on the changed function) may reproduce a defect; cite it as a reproduction, never as test evidence. Never report a test result, pass count, or exit code as the review's evidence. Without a `test-proof-v1` handoff, write the proof line exactly as `**Execution proof:** unavailable (owned by cf:test)` and do not otherwise say whether tests pass; the review still returns its correctness verdict.
 
-Try empty, malformed, unauthorized, duplicate, stale, boundary, and concurrent
-inputs where the changed contract makes them relevant. For Critical obligations,
-review the required independent evidence and provenance. A marker such as
-`Audit: PASS` is not independent evidence.
+## Execution-proof boundary
 
-The independent-audit proof must be a durable object with exactly
-`schema_version: "1"`, distinct concrete `reviewer_session_id` and
-`implementation_session_id`, `expected_provenance: { base, head }` matching the
-runtime binding, concrete `evidence`, and literal `verdict: "PASS"`.
-`independent: true`, `PASS_WITH_WARNINGS`, missing binding, or reused session
-provenance is insufficient.
+For process-first work, consume only the controller-validated `test-proof-v1` handoff. Require its exact closed schema, stable digest, current Base/Head, target task, exact command, exit/counts, raw output, reachability, proof level, artifacts, branches, and redactions. Unknown keys/verdicts, duplicate or missing branches, stale provenance, zero execution, required skips, unsafe redaction, or `PASS_WITH_WARNINGS` remain unfinished. Never create or search for a separate process-first receipt; Develop alone writes Status and inline `## Receipt` after proof and review are both literal `PASS`.
 
-## Execution-proof boundary
+Never rerun commands to manufacture proof. If execution proof is missing or invalid, write the proof line from the test-run boundary and leave closeout unfinished; do not claim feature PASS from review alone. A review may still return a correctness verdict when its review inputs are complete, but that verdict is not execution proof or GATE-DONE approval.
+
+## Severity
+
+Rate each finding by its production impact. Write the labels `Critical`, `High`, `Medium`, and `Low` verbatim in English, whatever language the report uses.
 
-For process-first work, consume only the controller-validated `test-proof-v1`
-handoff. Require its exact closed schema, stable digest, current Base/Head,
-target task, exact command, exit/counts, raw output, reachability, proof level,
-artifacts, branches, and redactions. Unknown keys/verdicts, duplicate or missing
-branches, stale provenance, zero execution, required skips, unsafe redaction, or
-`PASS_WITH_WARNINGS` remain unfinished. Never create or search for a separate
-process-first receipt; Develop alone writes Status and inline `## Receipt` after
-proof and review are both literal `PASS`.
-
-Never rerun commands to manufacture proof. If execution proof is missing or
-invalid, say `execution proof unavailable` and leave closeout unfinished; do not
-claim feature PASS from review alone. A review may still return a correctness
-verdict when its review inputs are complete, but that verdict is not execution
-proof or C3 approval.
+- Critical: a concrete failure a user or operator hits that loses or corrupts data, breaks security, or stops the product (a login bypass).
+- High: a concrete wrong result a user or operator hits (an order exactly at a tier boundary priced with the wrong discount).
+- Medium: a real risk with a failure scenario that has not reached users (a changed boundary with no test; a leftover debug log).
+- Low: cleanup, clarity, or a question (a naming nit; a behavior the change's README or docs state as intended).
+
+A leftover debug log is at most Medium; if it prints a secret or credential, report that exposure as a separate security finding at its own severity. A behavior the change's README or docs state as intended is not a Medium or heavier defect; raise it as Low or a question. Task and spec compliance findings are Critical only when a task or spec is supplied, and there `UNVERIFIED` means supplied proof that failed, never proof that is unavailable. A blocking Medium is one with a concrete failure before merge. A review whose heaviest remaining finding is a non-blocking Medium returns `PASS_WITH_WARNINGS`; one with only Low findings returns `PASS`.
 
 ## Verdict
 
@@ -96,15 +63,9 @@ Use the shared adapter surface exactly:
 
 `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`
 
-Legacy adapter inputs may include `PASS | FAIL | BLOCKED`, but they are
-normalized to the shared surface and no second enum is allowed. `PASS` means no
-Critical/High correctness, security, or compliance finding. `PASS_WITH_WARNINGS`
-means only documented non-blocking findings remain. `FAIL` requires remediation;
-`PASS` also requires no blocking Medium finding. `PASS_WITH_WARNINGS` may carry
-documented non-blocking findings. Finding count never selects depth or overrides
-missing execution proof. A review `PASS_WITH_WARNINGS` remains an unfinished
-closeout result; only literal `PASS` can finish a task. `BLOCKED` means the review input or a user-owned
-decision is unavailable.
+No second verdict enum is allowed. `PASS` means no Critical, High, or Medium finding remains; Low findings may remain. `PASS_WITH_WARNINGS` means the heaviest remaining finding is a non-blocking Medium. `FAIL` means a Critical, High, or blocking Medium finding requires remediation. Finding count never selects depth or overrides missing execution proof. A review `PASS_WITH_WARNINGS` remains an unfinished closeout result; only literal `PASS` can finish a task. `BLOCKED` means the review input or a user-owned decision is unavailable.
+
+Copy the header line `# Code Review Results [cf:code-review]`, the field labels, and the severity labels verbatim in English; write the content in the user's language.
 
 ```markdown
 # Code Review Results [cf:code-review]
@@ -124,23 +85,10 @@ decision is unavailable.
 - Reachability/provenance review: PASS | WARN | FAIL
 ```
 
-Do not add a test command, a fabricated receipt, or an `Audit: PASS` marker to
-make the review look complete. Return unresolved questions at the end.
-
-## Legacy workflow compatibility
-
-For a valid legacy packet only, retain its current spec/task resolution,
-separate `receipts/<task-basename>.md` fallback, feature receipt, persisted audit
-obligations, and legacy verdict normalization. If separate and embedded legacy
-proof identities conflict, fail closed. Never copy that adapter into a flat
-process-first packet.
+Do not add a test command, a fabricated receipt, or an `Audit: PASS` marker to make the review look complete. Return unresolved questions at the end.
 
 ## References
 
-- `references/spec-compliance-review.md` — load only its detailed scope checks;
-  its separate-receipt paragraph is Legacy-only.
+- `references/spec-compliance-review.md` — load for its detailed scope checks.
 - `references/pre-landing-checklists.md` — load for the selected risk surface.
 - `references/adversarial-review.md` — load for Critical/adversarial depth.
-- `references/verification-gate.md` — Legacy separate-receipt consumption only;
-  process-first proof uses this skill's execution-proof boundary. Execution
-  always stays with `cf:test`.

package/src/claude/skills/code-review/references/spec-compliance-review.md

@@ -24,16 +24,12 @@ Do not attempt a standard text-based review if the project includes Visual Specs
    - requirement bullets
    - task `Outcome`, `Scope`, `Anchors and Ownership`, `Changes`, `Acceptance`,
      `Dependencies`, and `Verification Plan`
-   - typed `coordination.boundaries` as the only ownership/DAG/proof/parallel authority
-   - task `Verification Plan`
-   - canonical contracts/invariants from `design.md`
+   - the plan's acceptance criteria and coverage profile rows the task references
    Then verify the changed files against those concrete obligations.
 
-Execution proof is separate from the task plan. Consume
-`receipts/<task-basename>.md` first and legacy `## Evidence` only as fallback;
-conflicting proof identities fail closed. At final integration, consume
-`feature-receipt.md`. Review never creates either receipt and never treats a
-receipt as approval, readiness, audit status, or semantic judgment.
+Execution proof is separate from the task plan and lives only in the task's
+inline `## Receipt`. Review never creates a receipt and never treats a receipt as
+approval, readiness, audit status, or semantic judgment.
 
 ## 3. Verdict Scale
 

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
@@ -12,10 +12,7 @@ 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.
-Develop never starts merely because Specs finished. The user invokes it.
+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. Develop never starts merely because Specs finished. The user invokes it.
 
 ## Usage and pre-state guard
 
@@ -28,8 +25,7 @@ Develop never starts merely because Specs finished. The user invokes it.
 /cf:develop <feature> --notes
 ```
 
-`--notes` is opt-in. Only then load `references/implementation-notes-template.html`;
-record decisions, scope exceptions, risks, gaps, and verification limits. Never create it by default.
+`--notes` is opt-in. Only then load `references/implementation-notes-template.html`; record decisions, scope exceptions, risks, gaps, and verification limits. Never create it by default.
 
 Before any state mutation, reject `--flash` combined with `--parallel`:
 
@@ -41,31 +37,22 @@ 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.
-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.
+- Resolve one `specs/<feature>/plan.md` plus flat `task-NN-*.md`; an explicit task path wins.
+- Read GATE-SCOPE scope, exclusions, acceptance mapping, ownership, and task order.
+- A task is unblocked only when every named dependency is `done` with a valid current inline Receipt.
+- 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.
+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 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.
+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, Steps, Acceptance, Dependencies, Verification Plan, Failure Protocol, 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.
+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 |
 |---|---|---|
@@ -77,89 +64,54 @@ before any Status or Receipt write.
 | 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.
+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 GATE-DONE.
 
 ## Modes
 
 ### Sequential feature or specific task
 
-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.
+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]`)
 
-Load `references/parallel-waves.md`. Require disjoint writes, satisfied dependencies,
-isolated worktrees, a bounded wave, and one controller writer; otherwise work sequentially.
+Load `references/parallel-waves.md`. Require disjoint writes, satisfied dependencies, isolated worktrees, a bounded wave, and one controller writer; otherwise work sequentially.
 
 ### 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.
-Compilation does not prove an unmounted UI, unregistered route, uncalled service,
-or missing consumer.
+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.
 
-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.
+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.
+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 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
 
-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.
+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.
 
-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:`,
-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.
+**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 in a fenced block, 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.
 
 ### 4. Finish the requested boundary
 
-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.
+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 GATE-DONE, apply the quality-gate final-Head fixed point; show current evidence and limitations, and let the user decide completion.
 
-Evaluate docs impact from behavior actually changed: `none` means report only;
-`minor` or `major` updates 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,
-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.
+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
 
@@ -167,12 +119,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.