@haposoft/cafekit 0.16.6 → 0.18.0

package/src/claude/skills/{question → ask}/SKILL.md

@@ -24,6 +24,7 @@ metadata:
 
 <ANSWER-ONLY-GATE>
 Do NOT implement, scaffold, refactor, modify files, generate full specs, or make final architecture decisions.
+This holds even when the question itself asks for a change ("and fix it", "rồi đổi luôn cho tôi"): answer the cause with evidence, edit nothing, and point to `cf:fix` for the change, or to `cf:debug` when the cause is not yet known.
 The output is an answer, evidence, confidence, and a follow-up only when needed.
 </ANSWER-ONLY-GATE>
 
@@ -43,10 +44,7 @@ Do not use it when:
 - The user asks to implement, fix, debug, test, commit, or publish.
 - The user wants ideation/tradeoff exploration; use `cf:brainstorm`.
 - The user wants a formal spec; use `cf:specs`.
-- The user wants full legacy documentation reconstruction: use
-  `cf:docs --reconstruct` when the optional document bundle is installed;
-  otherwise use `cf:scout` plus source evidence, or explain how to install the
-  bundle with `npx @haposoft/cafekit --with-document-skills`.
+- The user wants full legacy documentation reconstruction: use `cf:docs --reconstruct` when the optional document bundle is installed; otherwise use `cf:scout` plus source evidence, or explain how to install the bundle with `npx @haposoft/cafekit --with-document-skills`.
 - The user wants root-cause diagnosis for a failure; use `cf:debug`.
 
 ## Modes
@@ -60,50 +58,19 @@ Do not use it when:
 
 If modes conflict, prefer the most explicit source mode in this order: `--both`, `--repo`, `--web`, then default. Apply `--brief` or `--deep` as output depth modifiers.
 
-## Workflow
+## Standards
 
-### 1. Classify The Question
+**Unclear questions.** If `unclear`, ask one focused follow-up with the minimum choices needed.
 
-Pick one primary answer type:
+**Repo evidence priority:** `README.md`, `AGENTS.md`, `CLAUDE.md`; then relevant `docs/`, `specs/`, `.claude/`; then source files, tests, scripts, package manifests, config files; git history only when the question asks about changes or provenance. Use focused search (`rg`, targeted file reads) instead of broad scans. Use `cf:scout` when the user asks where something lives or the source surface is unclear.
 
-```text
-source-code behavior | config/version | spec/docs consistency | dependency/library | workflow/process | external/current knowledge | unclear
-```
-
-If `unclear`, ask one focused follow-up with the minimum choices needed.
-
-### 2. Gather Evidence
-
-Repo evidence priority:
-1. `README.md`, `AGENTS.md`, `CLAUDE.md`
-2. relevant `docs/`, `specs/`, `.claude/`
-3. source files, tests, scripts, package manifests, config files
-4. git history only when the question asks about changes or provenance
-
-Use focused search (`rg`, targeted file reads) instead of broad scans. Use `cf:scout` when the user asks where something lives or the source surface is unclear.
-
-External evidence:
-- Use external/current docs when repo evidence is absent, stale, or not authoritative.
-- Prefer official docs, standards, source repositories, or primary vendor docs.
-- State clearly when an answer is inferred from external docs rather than confirmed in the repo.
+**External evidence.** Use external/current docs when repo evidence is absent, stale, or not authoritative. Prefer official docs, standards, source repositories, or primary vendor docs. State clearly when an answer is inferred from external docs rather than confirmed in the repo.
 
-### 3. Decide Whether To Answer Or Ask Back
+**Broad questions.** When the question names no aspect or target — "Is this system stable?", "Is the code good?" — ask back before gathering evidence, offering 2-3 aspects (for example code and tests, runtime reliability, deploy readiness), even when a cautious answer would be possible.
 
-Answer directly when at least one of these is true:
-- repo evidence answers the question,
-- external/current evidence answers the non-project part,
-- a cautious answer can separate known facts from inference.
+**Answer or ask back.** Answer directly when at least one of these is true: repo evidence answers the question, external/current evidence answers the non-project part, or a cautious answer can separate known facts from inference. Ask back when the target system/module is not named and multiple targets are plausible, the needed file/source is blocked or private, the question requires business/domain judgment not present in source, the answer would require guessing customer intent, or the question bundles multiple unrelated topics. Ask only one follow-up question. Include 2-3 concrete options if helpful.
 
-Ask back when:
-- the target system/module is not named and multiple targets are plausible,
-- the needed file/source is blocked or private,
-- the question requires business/domain judgment not present in source,
-- the answer would require guessing customer intent,
-- the question bundles multiple unrelated topics.
-
-Ask only one follow-up question. Include 2-3 concrete options if helpful.
-
-### 4. Output Contract
+## Output Contract
 
 Default output:
 
@@ -135,36 +102,3 @@ Use `templates/question.md` when the user asks to save or document the answer.
 - Keep the answer proportional: concise for simple questions, structured for complex ones.
 - If external sources were used, include source links or names.
 - If no evidence exists, say "no evidence found in the current source" and explain what was checked.
-
-## Examples
-
-### Source Question
-
-```text
-/cf:ask "In this system, which file does cafekit use to toggle skill routing?"
-```
-
-Expected behavior:
-- read runtime/config/install files,
-- answer with exact config file and relevant keys,
-- say whether it is runtime-driven or hard-coded.
-
-### Mixed Source + Web Question
-
-```text
-/cf:ask "Which React version does this project use, and does that version still match current best practice?" --both
-```
-
-Expected behavior:
-- read `package.json` or lockfile,
-- check current React docs/release info if needed,
-- separate local version from external recommendation.
-
-### Ask Back
-
-```text
-/cf:ask "Is this system stable?"
-```
-
-Expected behavior:
-- ask one narrowing question because "stable" could mean architecture, security, performance, UX, tests, or deploy readiness.

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

@@ -1,8 +1,8 @@
 ---
 name: cf:brainstorm
-description: "Turn unresolved product or architecture intent into a bounded decision contract, with proportional routing, evidence, and safe handoff."
+description: "Shape an unsettled piece of work into a decided one before anyone builds it. Use when the outcome is already agreed but two or more approaches would each satisfy it with meaningfully different consequences — setup cost, migration, failure behaviour, who carries the work afterwards; use it too when an idea still wants exploring, or when only one approach is viable but the contract and the candidate design still need a decision. It weighs viable approaches against a bounded contract of Outcome, Constraints, Non-goals and Acceptance, records what was chosen and what was rejected and why, and stops there; it writes no code and carries nothing onward by itself. Skip it for a direct factual answer, skip it for a bug or failure that still needs its root cause, and skip it when the request needs a plan and its tasks rather than a choice between designs."
 user-invocable: true
-when_to_use: "Use when material product, scope, or architecture choices remain; skip direct factual answers and already-concrete Specs work."
+when_to_use: "Use when an outcome is agreed and designs compete, an idea wants exploring, or a candidate needs a decision; skip direct factual answers, undiagnosed bugs, and requests that need a plan and its tasks."
 category: utilities
 keywords: [ideation, tradeoffs, decisions, scope]
 argument-hint: "<idea_or_problem>"
@@ -12,9 +12,7 @@ metadata:
 ---
 # Brainstorm — proportional pre-delivery design
 
-Turn unresolved intent into a bounded contract without turning clear work into
-an interview. `cf:brainstorm` owns the workflow; `brainstormer` is an optional
-specialist for real architectural trade-offs.
+Turn unresolved intent into a bounded contract without turning clear work into an interview. `cf:brainstorm` owns the workflow; `brainstormer` is an optional specialist for real architectural trade-offs.
 
 <HARD-GATE>
 Brainstorm never writes implementation, invokes Develop, or treats approval as
@@ -24,64 +22,32 @@ for a new explicit `cf:specs` invocation; it never starts Specs implicitly.
 
 ## Control flags
 
-Parse controls only from the leading consecutive token segment. Accept
-`--deep`, `--visual`, and `--advice` in any order, each at most once. `--` ends
-the control segment. After it or the first content token, every token is user
-content. An unknown or duplicate `--*` inside the leading segment returns usage
-and performs no scout, question, tool call, write, or workflow action.
+Parse controls only from the leading consecutive token segment. Accept `--deep`, `--visual`, and `--advice` in any order, each at most once. `--` ends the control segment. After it or the first content token, every token is user content. An unknown or duplicate `--*` inside the leading segment returns usage and performs no scout, question, tool call, write, or workflow action.
 
-Parsing identifies controls but does not apply them. Route Direct first, then
-apply controls only to requests that remain in Brainstorm. `--deep` may raise
-non-direct analysis depth but never lower a gate; `--visual` changes presentation
-only; and no control grants persistence, approval, dispatch, or implementation
-authority. Use `-- --dry-run` when literal flag-like content leads the prompt.
+Parsing identifies controls but does not apply them. Route Direct first, then apply controls only to requests that remain in Brainstorm. `--deep` may raise non-direct analysis depth but never lower a gate; `--visual` changes presentation only; and no control grants persistence, approval, dispatch, or implementation authority. Use `-- --dry-run` when literal flag-like content leads the prompt.
 
 ## Front-door routing — before scout or questions
 
 Classify intent first. This routing never waives safety or permission rules.
 
-1. **Direct request:** for a factual answer, a specific command, or an explicitly
-   different workflow, leave Brainstorm before scout, questions, approval, or
-   persistence. Read-only product or architecture exploration is not direct merely
-   because it writes no files.
-2. **Hydrate the contract, then keep routing:** for every request that remains,
-   reuse accepted Outcome, Constraints, Non-goals, and Acceptance field by field
-   only when current user text or an approved artifact binds them to the same
-   target and revision. Preserve current non-conflicting fields; treat missing,
-   stale, or conflicting fields as gaps. Never infer approval. Hydration is not a
-   terminal route; continue to exactly one intent route below.
-3. **Bug or failure:** before diagnosis, capture the repaired-behavior Outcome,
-   Constraints, Non-goals, and Acceptance evidence. Then use `cf:debug` until
-   root cause is evidenced. Do not brainstorm fixes from a symptom. If at least
-   two cause-aligned remedies remain, compare 2–3 here. Hand off to `cf:fix`
-   only when the user explicitly requested a fix; diagnosis-only work returns the
-   root-cause report and stops.
-4. **Non-bug exploration only:** inspect enough evidence, give a chat
-   recommendation, and stop. Do not request design approval, persist a report, or
-   invoke another workflow without a new explicit request.
-5. **Feature or documentation delivery:** continue through the design workflow.
+1. **Direct request:** for a factual answer, a specific command, or an explicitly different workflow, leave Brainstorm before scout, questions, approval, or persistence. Read-only product or architecture exploration is not direct merely because it writes no files.
+2. **Plan-and-tasks request:** when the user asks for a plan, a task list, or work split into tasks rather than a choice between designs, leave Brainstorm before scout or questions: say in one or two sentences that Specs owns plans and tasks, and ask the user to invoke `cf:specs` in a new request. Do not interview, compare options, write the list, or start Specs. Open this answer with `Route: plan-and-tasks · Depth: Standard`.
+3. **Hydrate the contract, then keep routing:** for every request that remains, reuse accepted Outcome, Constraints, Non-goals, and Acceptance field by field only when current user text or an approved artifact binds them to the same target and revision. Preserve current non-conflicting fields; treat missing, stale, or conflicting fields as gaps. Never infer approval. Hydration is not a terminal route; continue to exactly one intent route below.
+4. **Bug or failure:** before diagnosis, capture the repaired-behavior Outcome, Constraints, Non-goals, and Acceptance evidence. Then use `cf:debug` until root cause is evidenced. Do not brainstorm fixes from a symptom. If at least two cause-aligned remedies remain, compare 2–3 here. Hand off to `cf:fix` only when the user explicitly requested a fix; diagnosis-only work returns the root-cause report and stops.
+5. **Non-bug exploration only:** inspect enough evidence, give a chat recommendation, and stop. Do not request design approval, persist a report, or invoke another workflow without a new explicit request.
+6. **Feature or documentation delivery:** continue through the design workflow.
 
 ## Adaptive analysis depth
 
-For every non-direct request, choose the smallest adequate depth from current
-evidence and material risk:
+For every non-direct request, choose the smallest adequate depth from current evidence and material risk:
 
 - **Standard:** bounded single-surface work with no material risk signal.
-- **Deep:** critical safety/security risk; public compatibility or data migration;
-  cross-service state or concurrency; costly or irreversible rollback; or
-  unresolved feasibility at a material boundary.
-- With no Deep signal, use Standard. `--deep` raises Standard to Deep. If three
-  or more subsystems are independently deliverable, split them instead of using
-  Deep as a monolithic substitute.
-
-Deep is selective, not a checklist. Apply a lens only when its trigger is
-present and otherwise record `skipped: <reason>`: feasibility for an unresolved
-material boundary; stakeholders for externally affected roles; system boundaries
-for cross-component state; failure isolation for partial or cascading failure
-across boundaries; reversibility and recovery for costly or irreversible failure;
-operability for runtime ownership; migration/rollback for data or public
-compatibility; testability for a material proof gap; and second-order effects
-for downstream behavior or incentives.
+- **Deep:** critical safety/security risk; public compatibility or data migration; cross-service state or concurrency; costly or irreversible rollback; or unresolved feasibility at a material boundary.
+- With no Deep signal, use Standard. `--deep` raises Standard to Deep. If three or more subsystems are independently deliverable, split them instead of using Deep as a monolithic substitute.
+
+Open every non-direct answer with one line naming its route and depth, for example `Route: feature delivery · Depth: Standard`. When the answer is a `cf:debug` report, that report's heading comes first and this line follows it.
+
+Deep is selective, not a checklist. Apply a lens only when its trigger is present and otherwise record `skipped: <reason>`: feasibility for an unresolved material boundary; stakeholders for externally affected roles; system boundaries for cross-component state; failure isolation for partial or cascading failure across boundaries; reversibility and recovery for costly or irreversible failure; operability for runtime ownership; migration/rollback for data or public compatibility; testability for a material proof gap; and second-order effects for downstream behavior or incentives.
 
 ## Contract and evidence
 
@@ -92,118 +58,64 @@ For feature/docs delivery and every bug/failure, resolve four user-owned fields:
 - **Non-goals:** nearby work excluded from this delivery.
 - **Acceptance:** observable evidence that proves completion.
 
-After front-door routing, run `cf:scout` or a narrow equivalent before
-technical design. Inspect relevant modules, patterns, docs/plans, contracts, and
-runtime constraints; summarize only useful findings in 3–6 bullets.
+After front-door routing, run `cf:scout` or a narrow equivalent before technical design. Inspect relevant modules, patterns, docs/plans, contracts, and runtime constraints; summarize only useful findings in 3–6 bullets.
 
-For supplied images, video, PDFs, or mockups, use `cf:ai-multimodal` when the
-optional document bundle is installed; otherwise use the runtime's available
-multimodal capability or report the evidence gap. Add a diagram only when it
-clarifies a material choice or flow.
+For supplied images, video, PDFs, or mockups, use `cf:ai-multimodal` when the optional document bundle is installed; otherwise use the runtime's available multimodal capability or report the evidence gap. Add a diagram only when it clarifies a material choice or flow.
 
-Derive technical touchpoints from repository evidence. Ask the user about a
-touchpoint only when its ownership or scope boundary is a product decision that
-cannot be discovered. Keep intent separate from current-state evidence.
+Derive technical touchpoints from repository evidence. Ask the user about a touchpoint only when its ownership or scope boundary is a product decision that cannot be discovered. Keep intent separate from current-state evidence.
 
-On every route, keep feasibility (`confirmed | plausible | unknown |
-infeasible`), confidence (`high | medium | low`), and disposition (`chosen |
-rejected | deferred`) separate and cite evidence or basis. Missing evidence
-forces feasibility `unknown` and confidence `low`. A numeric estimate requires
-range, unit, basis, evidence, and assumptions; otherwise report `unknown`.
+On every route, keep feasibility (`confirmed | plausible | unknown | infeasible`), confidence (`high | medium | low`), and disposition (`chosen | rejected | deferred`) separate and cite evidence or basis. Missing evidence forces feasibility `unknown` and confidence `low`. A numeric estimate requires range, unit, basis, evidence, and assumptions; otherwise report `unknown`.
 
-If the request spans three or more independently deliverable subsystems, split
-it. A subsystem is independent only when its outcome, boundary, and verification
-or deployment path can move through the lifecycle separately.
+If the request spans three or more independently deliverable subsystems, split it. A subsystem is independent only when its outcome, boundary, and verification or deployment path can move through the lifecycle separately.
 
 ## Discovery Question Framework
 
-Load `references/question-framework.md` before the first discovery question.
-Generate questions from scout evidence, user intent, contract gaps, applicable
-domain guidance, and risk surfaces. Never ask the user for a technical fact that
-code, docs, or trusted current research can answer.
+Load `references/question-framework.md` before the first discovery question. Generate questions from scout evidence, user intent, contract gaps, applicable domain guidance, and risk surfaces. Never ask the user for a technical fact that code, docs, or trusted current research can answer.
+
+Use the runtime's native structured user-input tool when available. Ask one highest-impact question by default; batch at most three independent questions only when none depends on an earlier answer. Record confirmed decisions, assumptions, and open questions separately in the decision register.
 
-Use the runtime's native structured user-input tool when available. Ask one
-highest-impact question by default; batch at most three independent questions
-only when none depends on an earlier answer. Record confirmed decisions,
-assumptions, and open questions separately in the decision register.
+Stop asking when remaining details have safe implementation defaults. Do not force questions merely to consume a budget.
 
-Stop asking when remaining details have safe implementation defaults. Do not
-force questions merely to consume a budget.
+When the user delegates a choice ("pick whichever is fastest"), choose from the recorded evidence, say that you chose on the user's behalf and why, record it in the Decision register as a delegated choice, and ask only for the approvals its route requires.
 
 ## Options and specialist use
 
-A material design choice exists only when at least two viable paths would satisfy
-the contract with meaningfully different consequences.
+A material design choice exists only when at least two viable paths would satisfy the contract with meaningfully different consequences.
 
-- For a material choice, compare 2–3 mechanically distinct viable approaches by
-  setup cost, runtime complexity, maintenance, UX/DX, compatibility/migration,
-  risk, and time-to-value.
-- With one viable path, present it and explain briefly why alternatives would be
-  artificial or fail the contract. Never create strawman options.
+- For a material choice, compare 2–3 mechanically distinct viable approaches by setup cost, runtime complexity, maintenance, UX/DX, compatibility/migration, risk, and time-to-value.
+- With one viable path, present it and explain briefly why alternatives would be artificial or fail the contract. Never create strawman options.
 - Recommend the smallest path that satisfies the contract.
 
-Call `brainstormer` only for a material architectural choice that benefits from
-deeper pressure-testing. Use researcher only for current external facts the
-repository cannot establish. The controller remains responsible for questions,
-approval, persistence, and handoff.
+Unless the user names `brainstormer`, call it only for a material architectural choice that benefits from deeper pressure-testing. When the user names `brainstormer`, call it; tell it which route applies; the routes are feature delivery; an explicitly authorized fix; diagnosis-only bug work; non-bug exploration. Pass the contract with it; it may return a single-path conclusion. Use researcher only for current external facts the repository cannot establish. The controller remains responsible for questions, approval, persistence, and handoff.
 
-`--visual` may present inline Mermaid or ASCII for any non-direct analysis and
-falls back to equivalent text when rendering is unavailable. Durable or external
-rendering requires explicit user authority before invocation. `--advice` invokes
-`brainstormer` only after the material-choice gate; if advice is unavailable or
-fails, label it unavailable and continue with controller analysis. Before an
-external visual tool or adviser handoff, minimize context and redact secrets,
-credentials, private keys, access tokens, and unnecessary PII. Neither overlay
-writes, approves, persists, dispatches, or completes work.
+`--visual` may present inline Mermaid or ASCII for any non-direct analysis and falls back to equivalent text when rendering is unavailable. Durable or external rendering requires explicit user authority before invocation. `--advice` invokes `brainstormer` only after the material-choice gate; if advice is unavailable or fails, label it unavailable and continue with controller analysis. Before an external visual tool or adviser handoff, minimize context and redact secrets, credentials, private keys, access tokens, and unnecessary PII. Neither overlay writes, approves, persists, dispatches, or completes work.
 
 ## Delivery design and approval
 
 For feature or documentation delivery:
 
-1. Draft one coherent candidate scaled to the work: architecture, data flow,
-   interfaces/UX, error behavior, verification, and rollout only when material.
+1. Draft one coherent candidate scaled to the work: architecture, data flow, interfaces/UX, error behavior, verification, and rollout only when material.
 2. Run the internal 4-point review before presentation:
    - remove placeholders and vague instructions;
    - reconcile contradictory behavior;
    - remove scope creep;
    - make observable behavior and proof concrete.
 3. Present the reviewed candidate.
-4. Before final approval, require a separate explicit section decision when
-   the design changes auth/secrets/privacy, destructive or irreversible behavior
-   or data-loss risk, money/privilege/safety, or production-state mutation.
-5. After critical section decisions and revisions, request one final approval by
-   default.
+4. Before final approval, require a separate explicit section decision when the design changes auth/secrets/privacy, destructive or irreversible behavior or data-loss risk, money/privilege/safety, or production-state mutation.
+5. After critical section decisions and revisions, request one final approval by default.
 
-Revise material disagreement before handoff. An already accepted, current
-contract is not re-approved unless new evidence changes it.
+Revise material disagreement before handoff. An already accepted, current contract is not re-approved unless new evidence changes it.
 
 ## Persistence and handoff
 
-Persist only approved decisions and semantics, only with user authority, and
-only when they must survive the session or feed Specs. Use the repository's
-configured report path and naming convention. Do not create a report merely to
-satisfy this skill. Before writing, redact live secrets, credentials, private
-keys, access tokens, and unnecessary PII; preserve exact approved meaning with a
-safe placeholder and ownership reference instead of copying the sensitive value.
-
-The default handoff stays in chat Markdown. Use these exact headings:
-`Target and evidence freshness`, `Outcome`, `Constraints`, `Non-goals`,
-`Acceptance`, `Touchpoints`, `Direction and alternatives`, `Relevant impacts
-and failure behavior`, `Rollout and recovery`, `Proof mapping`, `Decision
-register`, `Assumptions`, and `Open questions`. The first section records target
-identity, current source revision and worktree state or `[UNVERIFIED]`, an
-evidence-as-of value, and what change invalidates the brief. Durable file output
-requires explicit authority and creates no readiness, approval, proof, or
-execution state.
-
-- Feature/docs delivery: provide the approved summary and ask the user to invoke
-  `cf:specs` explicitly in a new request.
+Persist only approved decisions and semantics, only with user authority, and only when they must survive the session or feed Specs. Use the repository's configured report path and naming convention. Do not create a report merely to satisfy this skill. Before writing, redact live secrets, credentials, private keys, access tokens, and unnecessary PII; preserve exact approved meaning with a safe placeholder and ownership reference instead of copying the sensitive value.
+
+The default handoff stays in chat Markdown. Use these exact headings: `Target and evidence freshness`, `Outcome`, `Constraints`, `Non-goals`, `Acceptance`, `Touchpoints`, `Direction and alternatives`, `Relevant impacts and failure behavior`, `Rollout and recovery`, `Proof mapping`, `Decision register`, `Assumptions`, and `Open questions`. The first section records target identity, current source revision and worktree state or `[UNVERIFIED]`, an evidence-as-of value, and what change invalidates the brief. Durable file output requires explicit authority and creates no readiness, approval, proof, or execution state.
+
+- Feature/docs delivery: provide the approved summary and ask the user to invoke `cf:specs` explicitly in a new request.
 - Diagnosed bug: follow the fix-authority rule in front-door routing.
 - Non-bug exploration: recommendation already returned in chat; stop.
 
 ## Completion bar
 
-Brainstorm is complete when the selected route is explicit, current evidence is
-separated from intent, every material user-owned gap is resolved or named, and
-the route-specific output has been returned without unauthorized persistence or
-implementation. Never claim live behavior from this written contract alone.
+Brainstorm is complete when the selected route is explicit, current evidence is separated from intent, every material user-owned gap is resolved or named, and the route-specific output has been returned without unauthorized persistence or implementation. Never claim live behavior from this written contract alone.

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

@@ -28,7 +28,7 @@ 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.
+references; they apply only to a legacy packet.
 
 Select review depth from `assurance_level`, risk, and blast radius. Lane is a
 derived view:
@@ -73,6 +73,17 @@ runtime binding, concrete `evidence`, and literal `verdict: "PASS"`.
 `independent: true`, `PASS_WITH_WARNINGS`, missing binding, or reused session
 provenance is insufficient.
 
+## Test-run boundary
+
+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.
+
 ## Execution-proof boundary
 
 For process-first work, consume only the controller-validated `test-proof-v1`
@@ -85,10 +96,34 @@ 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
+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 C3 approval.
+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.
+
+- 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
 
@@ -98,14 +133,18 @@ Use the shared adapter surface exactly:
 
 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
+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]
 
@@ -127,14 +166,6 @@ decision is unavailable.
 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.
-
 ## References
 
 - `references/spec-compliance-review.md` — load only its detailed scope checks;

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

@@ -31,9 +31,8 @@ Do not attempt a standard text-based review if the project includes Visual Specs
 
 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.
+conflicting proof identities fail closed. 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/code-review/references/verification-gate.md

@@ -1,46 +1,41 @@
 ---
 name: verification-gate
-description: The Iron Law of Proof. Prohibits reporting a 'PASS' status without providing concrete execution proofs (like exit code 0 or successfully passing tests).
+description: Legacy proof consumption. Defines what supplied execution proof contains when a review of a legacy packet consumes it; the reviewer never produces that proof.
 ---
 
-# Verification Gate: The Iron Law of Proof
+# Verification Gate: legacy proof consumption
 
-In the Hapo ecosystem, words are cheap. Code that "looks right" to an AI can easily break in production. This reference defines the strictest, most uncompromising rule for Code Review.
+This reference applies only to a legacy packet. A
+review never runs tests, builds, or linters to produce proof; `cf:test` owns
+execution, and the test-run boundary in `SKILL.md` applies here as well.
 
-## 1. The Iron Law
-**You MUST NOT issue a final verdict of PASS unless you hold concrete, verifiable execution proof.**
+## 1. What supplied proof contains
 
-## 2. Hallucination Block
-Never use the following phrases or implications to assess code functionality:
-- "The code looks good."
-- "The logic seems sound."
-- "This should work as expected."
-- "There are no obvious errors."
+Proof reaches the review from the test owner, never from the review itself. It
+may be:
 
-If you have not compiled it, ran it, or seen it pass tests, **you do not know if it works**.
-
-## 3. Accepted Proofs of Execution
-To clear the Verification Gate, you must cite one of the following concrete proofs in your report:
-
-- **Test Suite Logs:** Output showing tests ran and passed (e.g., `PASS src/components/Login.test.tsx`).
-- **Compilation/Build Status:** Terminal output proving the typescript compiler (`tsc`) or bundler succeeded with `Exit code: 0`.
-- **Linter Completion:** Output proving no syntax errors exist.
-- **Multimodal Visual Evidence:** `cf:ai-multimodal` when installed, or another available runtime visual capability; otherwise report visual parity as `UNPROVEN`.
+- **Test suite logs:** output showing which tests ran and their result.
+- **Compilation or build status:** compiler or bundler output with its exit code.
+- **Linter completion:** output showing the lint run and its result.
+- **Multimodal visual evidence:** `cf:ai-multimodal` when installed, or another
+  available runtime visual capability; otherwise visual parity is `UNPROVEN`.
 
 For Specs v2, accepted proof must be persisted by the test owner at
 `receipts/<task-basename>.md`; legacy `## Evidence` remains fallback-only. The
 receipt includes identity/path, exact command, exit/result, expected versus
 observed behavior, applicable negative/reachability/artifact proof, and bound
-Base/Head. Final integration uses `feature-receipt.md`. Missing final receipt is
-normal before closeout, but mandatory at closeout. Neither receipt grants
-approval, readiness, audit status, or product semantics.
+Base/Head. Closing a legacy `spec.json` packet that has no `schema_version` still
+requires `feature-receipt.md`. A receipt never grants approval, readiness, audit
+status, or product semantics.
 
 For v2.1, the semantic receipt is reviewed input, not execution proof. It binds
 exact criteria and counterexamples shaped as `criterion`, `case_kind`,
 `scenario`, `expected`, `decision_refs`, and `verification_ref`. Deterministic
 validator success is never a semantic-review verdict.
 
-## 4. How to Handle Missing Proof
-If you are asked to review a PR or commit and no execution proof is available:
-1. **Return `BLOCKED`** and name missing commands, artifacts, permissions, or environment access.
-2. Do not issue `PASS`, do not downgrade to a tentative pass, and do not blind-retry. Resume only after proof arrives.
+## 2. When supplied proof is missing or failed
+
+A missing legacy receipt leaves the closeout unfinished: the review still
+returns its correctness verdict and states execution proof as unavailable (owned
+by `cf:test`). Supplied proof that failed is a finding the review reports. Never
+rerun or retry anything to fill the gap.