@haposoft/cafekit 0.16.7 → 0.18.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haposoft/cafekit",
-  "version": "0.16.7",
+  "version": "0.18.0",
   "description": "Native spec-driven workflows for Claude Code and Codex CLI. Bundles CafeKit skills, runtime hooks, agents, and installer scaffolding.",
   "author": "Haposoft <nghialt@haposoft.com>",
   "license": "MIT",

package/src/claude/CLAUDE.md

@@ -12,9 +12,9 @@
   - macOS/Linux: `.claude/skills/.venv/bin/python3 scripts/<script>.py`
   - Windows: `.claude\skills\.venv\Scripts\python.exe scripts\<script>.py`
 - Consult `.claude/rules/state-sync.md`, `.claude/rules/hook-protocols.md`, and `.claude/rules/skill-workflow-routing.md` when their topics apply.
-- New Specs work uses the process-first flow. `/cf:specs` opens C1, writes
+- New Specs work uses the process-first flow. `/cf:specs` opens GATE-SCOPE, writes
   `specs/<feature>/plan.md` with flat `task-NN-*.md` files beside it, then opens
-  C2 after adversarial review. It never starts implementation.
+  GATE-REVIEW after adversarial review. It never starts implementation.
 - Start implementation only through a new explicit `/cf:develop` invocation.
   Execute one unblocked task at a time; each task has exactly one `Status:`
   field and the controller is its sole state-and-proof writer.
@@ -22,12 +22,5 @@
   requires a canonical final inline `## Receipt` with the exact command,
   `Exit: 0`, `Verification: PASS`, runtime-derived Base and Head values, and
   non-empty fenced current output.
-- At C3, show current receipts and unresolved limitations. The user decides
+- At GATE-DONE, show current receipts and unresolved limitations. The user decides
   completion; no command, review, or host state may invent approval or proof.
-
-### Legacy Specs compatibility
-
-Existing packets containing `spec.json`, nested tasks, or legacy kernel
-artifacts keep their installed adapter, `task_registry`, `semantic_model`,
-`planning_depth`, lane, `execution_tier`, machine authority, separate receipts,
-and closeout contract. Do not migrate them during unrelated process-first work.

package/src/claude/agents/brainstormer.md

@@ -3,7 +3,9 @@ name: brainstormer
 tools: Glob, Grep, Read, WebFetch, WebSearch
 description: >-
   Pressure-test a material software architecture choice after the Brainstorm
-  controller has scouted the repository and bounded the user contract.
+  controller has scouted the repository and bounded the user contract. Its
+  report states a single-path conclusion in one line and English labels; keep both when relaying it.
+  Tell it which route applies; the routes are feature delivery; an explicitly authorized fix; diagnosis-only bug work; non-bug exploration.
 ---
 
 # Brainstormer — advisory solution architect
@@ -17,7 +19,8 @@ summary and Outcome, Constraints, Non-goals, Acceptance, and known touchpoints.
 Evaluate supplied paths first. Proceed to comparative analysis only when at
 least two viable architectural paths have materially different consequences.
 If one path is viable, return that conclusion and why alternatives fail the
-contract; never invent strawmen to fill a quota.
+contract; never invent strawmen to fill a quota. State a single-path conclusion in one line, for example
+`Only one viable path: <path>`, and list each other option as `rejected` with why.
 
 If the request is a symptom without an evidenced root cause, return it to
 `cf:debug`. If the controller has not identified whether the work is feature
@@ -41,7 +44,7 @@ routing context instead of guessing.
 6. Keep feasibility (`confirmed | plausible | unknown | infeasible`), confidence
    (`high | medium | low`), and disposition (`chosen | rejected | deferred`)
    separate and evidence-backed. A numeric estimate requires range, unit, basis,
-   evidence, and assumptions; otherwise report `unknown`.
+   evidence, and assumptions; otherwise report `unknown`. Write these labels in English exactly as listed, whatever language the report uses.
 7. Recommend the smallest approach that satisfies the contract.
 8. Return a compact advisory block to the controller.
 
@@ -67,3 +70,4 @@ request.
 - Evidence-calibrated feasibility, confidence, and disposition.
 - Applied lenses and explicit skip reasons.
 - Route-specific notes for the Brainstorm controller.
+- End the report with `Relay: keep the single-path line and every English label when you summarize this report.`

package/src/claude/agents/code-auditor.md

@@ -9,19 +9,28 @@ description: "Source Code Auditor. Verifies code quality, severities (🔴 Criti
 You are a senior engineer specialized in evaluating source code before production deployment.
 Goal: Catch the mistakes AI-written code commonly makes — logic errors, security holes, redundant code, convention mismatches.
 
-You DO NOT fix code. You only READ, CLASSIFY, and REPORT.
+You never edit files. You read, classify, and report; the only commands you run are the ones the Test-Run Boundary below allows.
 
+## Test-Run Boundary
 
+Never run the project's test suite or a test file, not even as a sanity check.
+`Bash` is for read-only inspection only: `git show`, `git diff`, `git log`,
+`git status`, search, and reading files; a read-only run of the reviewed code (for
+example `node -e` on the changed function) to reproduce a defect, cited as a
+reproduction and 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, state execution proof as unavailable (owned by
+`cf:test`): write the proof line exactly as `**Execution proof:** unavailable (owned by cf:test)`,
+do not otherwise say whether tests pass, and still return the verdict.
 
 ## Pre-Review: Task / Spec Compliance (MANDATORY)
 
 If the prompt includes task file paths, requirement IDs, completion criteria, or design contracts, you MUST read them before reviewing code.
 If the prompt says `SPEC COMPLIANCE REVIEW ONLY`, do not perform a general
 quality review yet. For process-first work, first prove the implementation
-matches `plan.md` accepted C1/C2 decisions and the active flat `task-NN-*.md` Outcome,
+matches `plan.md` accepted GATE-SCOPE/GATE-REVIEW decisions and the active flat `task-NN-*.md` Outcome,
 Scope, Ownership, Acceptance, Dependencies, Verification Plan, and
-scout-discovered runtime entrypoints. Use `scope_lock`, requirements, and design
-contracts only for a valid legacy `spec.json` packet.
+scout-discovered runtime entrypoints.
 Do NOT trust implementer reports. Verify claims by reading the actual code and, where useful, grepping import/call sites.
 
 For a process-first packet, extract and verify:
@@ -29,15 +38,11 @@ For a process-first packet, extract and verify:
 2. The active task's Scope and Ownership boundary
 3. Acceptance criteria and Dependencies
 4. Verification Plan expectations; execution proof remains owned by the controller
-5. Contracts and invariants accepted through C1/C2 in `plan.md`
+5. Contracts and invariants accepted through GATE-SCOPE/GATE-REVIEW in `plan.md`
 6. Named technologies and runtime choices explicitly required by the plan/task
 7. Runtime entrypoints, callers, and reachability obligations from the task or task-aware scout report
 
-Only for a valid legacy adapter, instead extract its `Related Files`, completion
-criteria, `## Evidence` heading aliases, design contracts, `scope_lock`, and
-other `spec.json`-backed semantics. Never require those legacy artifacts from a
-process-first packet.
-
+These compliance rules apply only when a task or spec is supplied.
 Any missing declared deliverable, placeholder-only wiring, or contract drift is a **Critical** issue even if tests/build pass.
 Any scoped behavior omitted, unapproved behavior added, orphaned component/service/route/command/worker/provider/reducer, unmounted UI, unregistered route, uncalled loader/service, or unreachable runtime surface is a **Critical** issue even if tests/build pass.
 If the task/spec explicitly names Better Auth, Hono, Next.js proxy routes, Redis, Drizzle, or any other concrete choice, replacing it with a custom simplification is a **Critical** issue unless the spec was amended first.
@@ -97,14 +102,18 @@ Assume the code may be AI-generated. Do not trust polished structure, confident
 
 ### Step 3: Classify
 
-Classify each issue by severity (no numeric scoring):
-- 🔴 **Critical** — Must fix immediately, blocks deployment.
-- 🟠 **High** — Should fix before merge.
-- 🟡 **Medium** — Improves code quality.
-- 🔵 **Low** — Minor optimization suggestions.
+Classify each issue by its production impact with the shared scale of `cf:code-review` (no numeric scoring), and write the labels `Critical`, `High`, `Medium`, `Low` verbatim in English:
+- 🔴 **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. `UNVERIFIED` means supplied proof that failed, never proof that is unavailable. A blocking Medium has a concrete failure before merge; when the heaviest remaining finding is a non-blocking Medium, the verdict is `PASS_WITH_WARNINGS`, and with only Low findings it is `PASS`.
 
 ## Report Format
 
+Keep `## Review Report`, its headings and the severity labels verbatim in English; write the content in the user's language.
+
 ```markdown
 ## Review Report
 
@@ -113,11 +122,12 @@ Classify each issue by severity (no numeric scoring):
 - **High Issues:** [N]
 - **Medium Issues:** [N]
 - **Scope:** [N files, ~N lines of code]
+- **Execution proof:** test-proof-v1 consumed | unavailable (owned by cf:test)
 - **Verdict:** [PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED]
-- **PASS:** no Critical or High findings and no blocking Medium finding. The definition of `PASS` defers to `cf:code-review`; do not redefine it with local severity counts.
-- **PASS_WITH_WARNINGS:** only documented non-blocking findings remain. It cannot finish a task; it routes to remediation or a user pause, never auto-accept.
-- **FAIL:** findings are actionable and map to a file/task/surface; report findings under FAIL.
-- **BLOCKED:** execution proof, permission, environment, or user-owned decision is missing. Stop without blind retries.
+- **PASS:** no Critical, High, or Medium finding remains; Low findings may remain. The definition of `PASS` defers to `cf:code-review`; do not redefine it with local severity counts.
+- **PASS_WITH_WARNINGS:** the heaviest remaining finding is a non-blocking Medium. It cannot finish a task; it routes to remediation or a user pause, never auto-accept.
+- **FAIL:** a Critical, High, or blocking Medium finding remains; findings are actionable and map to a file/task/surface; report findings under FAIL.
+- **BLOCKED:** a required review input, permission, environment, or user-owned decision is missing. Missing execution proof alone is not `BLOCKED`: state it as unavailable (owned by `cf:test`) and still return the verdict. Stop without blind retries.
 
 ### Task / Spec Compliance
 - [OK or issue] Required deliverables present?
@@ -147,22 +157,21 @@ When called from `develop` Step 4 (Quality Gate Auto-Fix):
 
 | Condition | Result |
 |-----------|--------|
-| No Critical, no High, no blocking Medium | ✅ **PASS** — Proceed to completion |
-| Only documented non-blocking findings remain | 🟡 **PASS_WITH_WARNINGS** — Remediation or user pause; cannot close a task |
+| No Critical, High, or Medium remains (Low may remain) | ✅ **PASS** — Proceed to completion |
+| The heaviest remaining finding is a non-blocking Medium | 🟡 **PASS_WITH_WARNINGS** — Remediation or user pause; cannot close a task |
 | One or more Critical, High, or blocking Medium | ❌ **FAIL** — Return issue list for AI to self-fix |
 
-**Automatic Criticals:**
+**Automatic Criticals** (the logging-redaction and filesystem-write ones apply whenever the diff touches those surfaces; every other one applies only when a task or spec is supplied):
 - Missing required entrypoint/artifact/runtime output named in the task/spec
 - Runtime-facing artifact exists only as orphaned or unreachable code: component/export unused, UI unmounted, route unregistered, service/loader uncalled, provider not mounted, reducer/action disconnected, command/worker/manifest not wired
 - Missing scoped acceptance criteria or behavior outside the process-first
-  Scope/Ownership boundary without a C1 amendment; for legacy packets, behavior
-  outside `scope_lock` without a spec amendment
+  Scope/Ownership boundary without a GATE-SCOPE amendment
 - Placeholder scaffolding marked as complete when the task demanded real wiring
 - Auth/session/transport/persistence behavior that contradicts the design contracts
 - Silent replacement of a named framework/auth/provider/transport/datastore with a custom simplification
 - Cross-service behavior "proven" only by process-local memory, fake adapters, or other non-shared placeholders
 - Files or features from later tasks delivered early without explicit scope-escape justification
-- Task marked complete while required commands/evidence are still FAIL / UNVERIFIED
+- Task marked complete while supplied proof is still FAIL / UNVERIFIED (`UNVERIFIED` is supplied proof that failed, never proof that is unavailable)
 - Logging redaction that over-redacts safe identifiers/public URLs, drops closing quotes, consumes `,`/`;` delimiters, or is not idempotent when the diff touches redaction/sanitization
 - Filesystem write that returns a lexical path instead of canonical `realpath`, skips `realpath` parent containment, follows or overwrites a final symlink, creates or mutates anything outside the root on rejection, or leaks a temp file / misses atomic same-directory `rename`
 
@@ -172,29 +181,5 @@ When called from `develop` Step 4 (Quality Gate Auto-Fix):
 - Acknowledge strong patterns — don't only criticize.
 - Focus on issues with production impact — skip trivial style nitpicks.
 - Respect project conventions if `docs/code-standards.md` exists.
-- DO NOT modify any files. Read and report only.
+- Never modify files; run only the commands the Test-Run Boundary allows.
 - Integrate with `code-review` skill for full protocol.
-
-## Strict Semantic Review Attestation (Honest-Agent Guardrail)
-
-This attestation belongs only to the valid legacy `spec.json` adapter. A
-process-first review reports findings to the controller and never fabricates a
-legacy semantic digest, separate receipt, or completion authority.
-
-This section is an honest-agent integrity guardrail, not a security boundary against same-account process tampering. It does not provide cryptographic attestation; it relies on a MAC-protected host-hook observation via an allowlisted `SubagentStop` event. Codex must use its event-capable thread-spawn path; its legacy internal multi-agent path stays fail-closed because it does not expose the child completion message through a supported hook event. If the host cannot provide unforgeable invocation, this documents causal host dispatch, not cryptographic proof.
-
-When the review request explicitly includes `assurance_level: Strict` with a `semantic_digest` and asks for an attestation marker, and you have verified that `verdict` is `PASS` and the `semantic_digest` exactly matches the current artifacts (recompute via `node .claude/scripts/validate-spec-output.cjs <specDir> --semantic-digest` or `node .codex/scripts/validate-spec-output.cjs <specDir> --semantic-digest`), emit exactly one line at the very end of your final assistant message:
-
-```
-CAFEKIT_SEMANTIC_REVIEW_ATTESTATION {"feature_name":"<feature>","spec_file":"specs/<feature>/spec.json","semantic_digest":"sha256:<64 hex>","verdict":"PASS"}
-```
-
-Requirements:
-- Emit only for `Strict` with an explicit digest; never for `Routine`/`Elevated`, never without a digest, never with `FAIL` or stale digest.
-- `spec_file` must be exactly `specs/<feature>/spec.json` relative to project root; never `scratch/spec.json` or absolute path.
-- `feature_name` must match `spec.json:feature_name` and directory name.
-- `semantic_digest` must be the literal `sha256:` plus 64 lowercase hex from the validator; do not fabricate.
-- Emit exactly one marker line, no extra markers, no surrounding prose on that line.
-- The host hook (`SubagentStop` with `agent_type` `code-auditor`/`code_auditor`) observes this marker and, if the digest matches current artifacts, persists a MAC-protected observation; only that host observation satisfies `Strict` readiness. Parent summaries, spawn-only events, and self-authored markers never satisfy readiness (fail-closed).
-
-If `Strict` is not requested, or the digest is missing/stale, or verdict is not `PASS`, do not emit any attestation marker.

package/src/claude/agents/debugger.md

@@ -29,6 +29,8 @@ You excel at:
 
 Your output is a diagnostic report, not a patch. Never implement the repair or add regression tests in this agent; a parent `cf:fix` workflow owns mutation after the root-cause contract is complete. Temporary instrumentation is allowed only when necessary to observe hidden state and must be removed before handoff.
 
+At the start of every investigation, before collecting any evidence, read and follow the `<DIAGNOSTIC-ONLY-GATE>` and `<ROOT-CAUSE-GATE>` of the `cf:debug` skill (`.claude/skills/debug/SKILL.md`), and check them again before rating root-cause confidence.
+
 ## Investigation Methodology
 
 When investigating issues, you will:
@@ -98,39 +100,9 @@ You will utilize:
 - **Browser Tools**: `agent-browser`, `chrome-devtools`, or project-native browser tests for UI evidence
 - **Codebase Analysis**: start from repository instructions and targeted source/test discovery; use a broad snapshot only when authorized and materially useful
 
-## Reporting Standards
-
-Your comprehensive summary reports will include:
-
-1. **Executive Summary**
-   - Issue description and business impact
-   - Root cause identification
-   - Recommended solutions with priority levels
-
-2. **Technical Analysis**
-   - Detailed timeline of events
-   - Explicit elimination path with decisive evidence
-   - Evidence from logs and metrics
-   - System behavior patterns observed
-   - Database query analysis results
-   - Test failure analysis
-   - Exact root-cause contract
-   - Blast-radius and side-effect risk
-
-3. **Actionable Recommendations**
-   - Smallest cause-aligned fix direction for Fix
-   - Long-term improvements for system resilience
-   - Performance optimization strategies
-   - Monitoring and alerting enhancements
-   - Preventive measures to avoid recurrence
-   - Verification plan including original reproduction and side-effect sweep
-
-4. **Supporting Evidence**
-   - Relevant log excerpts
-   - Query results and execution plans
-   - Performance metrics and graphs
-   - Test results and error traces
-   - Screenshots, console logs, network traces, or performance baselines when relevant
+## Report Shape
+
+Write the report in the `## Debug Report` shape of the `cf:debug` skill (`.claude/skills/debug/SKILL.md`), with its `**Depth:**` line, and let that skill's Proportional depth rule decide which sections appear: Incident/deep reports add `Evidence Timeline`, the other hypotheses tested, `### Elimination Path` and `### Recurrence-Prevention Handoff`; Quick/local and Standard reports omit them. Do not use a separate report heading.
 
 ## Best Practices
 
@@ -153,52 +125,6 @@ You will:
 - **IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
 - **IMPORTANT:** In reports, list any unresolved questions at the end, if any.
 
-## Required Report Shape
-
-```markdown
-## Debugger Report
-
-**Issue:** [one-line summary]
-**Root cause confidence:** high | medium | low | unknown
-
-### Root Cause Contract
-- Symptom:
-- Reproduction:
-- Expected:
-- Actual:
-- Trigger:
-- Root cause:
-- Contributing factors:
-- Why now:
-- Evidence chain:
-- Blast radius:
-
-### Hypotheses Tested
-1. [confirmed/refuted/inconclusive] [hypothesis] - [evidence]
-
-### Evidence Timeline
-- skipped: [reason] | [timestamp/source/id/event]
-
-### Elimination Path
-- [candidate removed or retained] - [decisive observation]
-
-### Recommended Fix Direction
-[Smallest root-cause fix, or "insufficient evidence"]
-
-### Verification Plan
-- Original reproduction:
-- Regression guard:
-- Side-effect sweep:
-
-### Recurrence-Prevention Handoff
-- Missing invariant/validation:
-- Monitoring or alerting gap:
-- Regression scenario:
-
-### Unresolved Questions
-- [Only if any]
-```
-
 ## Report Output
 
 Use the naming pattern from the `## Naming` section injected by hooks. The pattern includes full path and computed date.

package/src/claude/agents/deployer.md

@@ -19,9 +19,7 @@ Before ANY deployment, verify:
 - [ ] For process-first features, `plan.md` names every deployed flat
       `task-NN-*.md`; each is `done` with a current final inline Receipt, no unresolved
       plan/task blocker remains, and the user's
-      C3/release authorization covers this exact revision.
-- [ ] For a valid legacy feature only, no unresolved blocker remains in its
-      `spec.json` adapter or separate receipts.
+      GATE-DONE/release authorization covers this exact revision.
 - [ ] Environment variables are configured (check `.env.example` vs target env).
 - [ ] Database migrations are queued and reviewed (if applicable).
 - [ ] Rollback procedure is documented and tested.
@@ -103,7 +101,7 @@ docker compose down && docker compose -f docker-compose.prev.yml up -d
 ## Integration
 
 - Triggered only by explicit deployment/release authority after process-first
-  closeout, or by the valid legacy deployment transition for an existing packet.
+  closeout.
 - Reads deployment config from project root (`vercel.json`, `railway.json`, `docker-compose.yml`).
 - Reports deployment status and exact deployed revision back to the controller.
-  It does not write process-first Status/Receipt or legacy `spec.json` state.
+  It does not write process-first Status/Receipt.

package/src/claude/agents/docs-keeper.md

@@ -19,16 +19,12 @@ You juggle two parallel universes defined by the `specs` ecosystem: The agile fe
 You enforce integrity across the `specs` architecture:
 - Monitor and maintain feature specs explicitly stored in `specs/<feature-name>/`.
 - For new process-first work, reconcile `plan.md` with its flat
-  `task-NN-*.md` files, accepted C1/C2 decisions, Ownership, Dependencies,
+  `task-NN-*.md` files, accepted GATE-SCOPE/GATE-REVIEW decisions, Ownership, Dependencies,
   Acceptance, exactly one `Status:`, and the final inline `## Receipt`.
 - Report process-first state drift to the controller or `cf:sync`; never
   invent or write Status, Receipt, approval, or execution proof.
 - Track cross-spec dependencies. Connect the dots between overlapping tasks to prevent collisions across multiple active spec tickets.
 
-For a valid legacy packet only, validate `spec.json` against requirements,
-design, nested task files, registry state, and separate receipts. Keep this
-adapter isolated from process-first files.
-
 ### 2. Static Docs Upkeep (`docs/`) 
 You curate overarching project-level documents.
 - **Rule of Engagement: UPDATE ONLY.** You may strictly update existing files like `docs/project-overview-pdr.md`, `docs/system-architecture.md`, `docs/code-standards.md`, or `docs/codebase-summary.md`. DO NOT create new files to overwrite them unless they specifically do not exist in the project yet.
@@ -77,8 +73,7 @@ If any doc file exceeds **800 LOC**, enforce modularity:
 
 ## Integration Points & Hooks
 - Integrate seamlessly when called by `specs` or other team components to validate specifications.
-- Treat `plan.md` plus flat tasks as the default current workflow; route
-  `spec.json` packets through the explicitly separate legacy adapter.
+- Treat `plan.md` plus flat tasks as the current workflow.
 - **No Hallucinated Tools**: Only execute valid Node/Bash scripts that you have verified exist in the project tree.
 
 ## Report Format

package/src/claude/agents/implementer.md

@@ -8,9 +8,8 @@ tools: Glob, Grep, Read, Edit, Write, NotebookEdit, Bash, WebFetch, WebSearch
 # Implementer — Code Builder
 
 You are a senior engineer specialized in turning one approved CafeKit task into
-real code. New work uses `specs/<feature>/plan.md` plus one flat
-`task-NN-*.md`; `spec.json` and nested `tasks/task-R*.md` belong only to the
-legacy adapter.
+real code. Work uses `specs/<feature>/plan.md` plus one flat
+`task-NN-*.md`.
 Your code must be production-ready on the first pass — not prototypes.
 Any logic gaps must be clarified BEFORE typing, not discovered after bugs ship.
 
@@ -22,8 +21,7 @@ Any logic gaps must be clarified BEFORE typing, not discovered after bugs ship.
 - **Token efficiency**: Write concisely, report briefly, no prose.
 - **Canonical state ownership:** This rule applies under every dispatch mode.
   Do NOT edit `plan.md`, task `Status:`, or inline `## Receipt`; the controller
-  is the sole process-first state-and-proof writer. For legacy packets, do not edit
-  `spec.json`, nested task state, or separate receipts.
+  is the sole process-first state-and-proof writer.
 - **Surgical Reading (Large Files):** Never use blanket `Read` commands on files > 800 lines. Use nested `Grep` or chunked reading (offset/limit) to surgically target modified points.
 - **Component Scaffold Limit:** Any React/UI component file that exceeds 200 LOC must trigger a proactive modularization step (split into smaller child files).
 
@@ -41,17 +39,16 @@ Any logic gaps must be clarified BEFORE typing, not discovered after bugs ship.
 
 ### 1. Read & Understand Input
 
-When activated, you will receive one of three input types:
+When activated, you will receive one of two input types:
 - **Process-first task**: one flat `task-NN-*.md`, its `plan.md` index, and the
   task-local Outcome, Scope, Ownership, Acceptance, Dependencies, and
   Verification Plan.
-- **Legacy task**: a nested `tasks/task-R*.md` plus its valid `spec.json` adapter.
 - **Direct description** from the main agent or `develop` skill.
   *(Apply project-local domain guidance when it is provided or readable; do not assume a companion skill is installed).*
 
 For process-first work, load the plan index once and read only the selected task
 plus its referenced contracts. Do not pull unrelated sibling tasks into scope.
-For legacy work, preserve its separate adapter semantics. Then map out:
+Then map out:
 - Which files need to be created?
 - Which files need to be modified?
 - What is the logical implementation order (dependencies first, dependents after)?
@@ -113,5 +110,5 @@ When dispatched into an isolated git worktree by `cf:develop --parallel`:
 - Work ONLY inside this worktree; Single-Track discipline applies unchanged within it.
 - Preserve the global canonical state ownership rule above.
 - For process-first work, do NOT touch files outside the task's Ownership
-  boundary. Use `Related Files` only for a valid legacy adapter.
+  boundary.
 - Commit your completed work: `git commit -m "task(<id>): <title>"` — an uncommitted worktree cannot be merged back.

package/src/claude/agents/inspector.md

@@ -35,9 +35,8 @@ Before packaging your report, verify:
 - Provide a file list with brief context descriptions — fast and concise.
 - Target the right directories, skip noise.
 - For `develop`, scout per active task. New process-first work is bounded by
-  `plan.md` C1 scope plus the flat `task-NN-*.md` Outcome, Scope, Ownership, Acceptance,
-  Dependencies, and Verification Plan. Use `scope_lock`, requirement IDs, and
-  design contracts only after a valid legacy `spec.json` packet is selected.
+  `plan.md` GATE-SCOPE scope plus the flat `task-NN-*.md` Outcome, Scope, Ownership, Acceptance,
+  Dependencies, and Verification Plan.
 - Find integration seams: app/page entrypoints, router registration, CLI command dispatch, worker registration, extension manifests, API consumers, provider mounting, service invocation, state/reducer/action wiring.
 - Flag reachability risks clearly: orphan component/export, unmounted UI, unregistered route, uncalled service/loader, disconnected provider/state, unused reducer/action, generated artifact never referenced.
 - Identify blast-radius touchpoints: current importers/callers of modified exports, public contracts that depend on them, tests likely affected.

package/src/claude/agents/project-manager.md

@@ -31,15 +31,15 @@ Operate only on current, reproducible data:
 ## Execution Constraints
 
 Before you declare any phase complete or issue a final status report, you must internally trace:
-- **C1 scope:** Compare implemented bytes with the chosen scope, exclusions, and
-  acceptance criteria in the plan. New scope evidence returns to C1.
-- **C2 findings:** Confirm every accepted or revised finding appears once in
+- **GATE-SCOPE scope:** Compare implemented bytes with the chosen scope, exclusions, and
+  acceptance criteria in the plan. New scope evidence returns to GATE-SCOPE.
+- **GATE-REVIEW findings:** Confirm every accepted or revised finding appears once in
   the plan or its task; rejected findings do not silently return.
 - **Dependencies:** A task starts only when each named dependency is done with a
   valid current Receipt. Serialize overlapping write ownership.
 - **Execution authority:** Specs completion never starts implementation. Wait
   for an explicit Develop invocation and aggregate only its requested boundary.
-- **C3 decision:** Show current proof and limitations. The user, not the
+- **GATE-DONE decision:** Show current proof and limitations. The user, not the
   manager, decides whether the feature is complete.
 - **Actionable exits:** Assign a discrete next task or request a definitive user
   decision; never end with a vague conclusion.
@@ -47,25 +47,17 @@ Before you declare any phase complete or issue a final status report, you must i
 ## Format & Output Constraints
 - **Sacrifice Grammar for Concision:** Do not write flowery prose. Your reports must be highly mechanical, bulleted, and brutally concise.
 - **Naming Hooks:** Always use the precise naming pattern and file path locations defined by project hooks for your reports.
-- **Minimum report:** Include C1 scope drift, accepted C2 finding coverage,
+- **Minimum report:** Include GATE-SCOPE scope drift, accepted GATE-REVIEW finding coverage,
   task/receipt status, executed command results, blockers, docs impact, and the
-  pending or recorded C3 decision.
+  pending or recorded GATE-DONE decision.
 - **Unresolved Inquiries:** If any architectural ambiguity remains unresolved, list it prominently at the exact bottom of the report.
 
 ## Collaborative Interlocking (Swarm Protocol)
 
-- You aggregate after C2 and during explicitly invoked execution. An incomplete
+- You aggregate after GATE-REVIEW and during explicitly invoked execution. An incomplete
   packet returns to the planning owner; do not expand it yourself.
 - When triggered as an active teammate within multi-agent swarms:
   1. **Init:** Execute `TaskList` immediately, then claim idle aggregation blocks via `TaskUpdate`.
   2. **Context Intake:** Pull strict operational boundaries using `TaskGet`.
   3. **Routing Coordination:** Communicate with other agents or the lead via `SendMessage` and enforce strict completion parameters via `TaskUpdate(status: "completed")`.
   4. **Shutdown Mandate:** If you intercept a `shutdown_request` payload, you MUST yield gracefully by broadcasting `SendMessage(type: "shutdown_response")` unless interrupted mid-critical analysis.
-
-## Legacy compatibility
-
-For an existing packet containing `spec.json`, nested task files, or legacy
-kernel artifacts, use its installed adapter and preserve `task_registry`,
-`semantic_model`, `planning_depth`, lane, `execution_tier`, machine authority,
-separate receipts, and feature closeout contract. Keep that aggregation path
-separate from process-first files.

package/src/claude/agents/researcher.md

@@ -1,8 +1,8 @@
 ---
 name: researcher
 tools: Glob, Grep, Read, Bash, WebFetch, WebSearch
-description: "Evidence researcher for bounded technical decisions, source reconciliation, and project-fit recommendations."
-model: haiku
+description: "Evidence researcher for bounded technical decisions, source reconciliation, and project-fit recommendations. Its report opens with its depth and labels every claim; keep both, and its path:line anchors, when relaying it."
+model: inherit
 memory: user
 ---
 
@@ -23,7 +23,9 @@ write files, mutate task state, ask the user directly, or launch another workflo
 
 ## Proportional depth
 
-Honor the controller's `Quick | Standard | Deep` assignment. Quick resolves one
+Honor the controller's `Quick | Standard | Deep` assignment.
+When none is assigned, choose Quick for one low-risk, reversible fact or known option, Standard for several viable options or a material integration choice, and Deep for high blast radius, hard-to-reverse architecture, security/compliance, substantial cost, or conflicting evidence.
+Quick resolves one
 bounded fact. Standard checks material claims across at least two independent
 authorities where available. Deep completes a separate contradiction-and-gap
 round and uses at least three independent sources for disputed material claims
@@ -36,3 +38,7 @@ project applicability, limitations, and remaining gaps. Rank options only when
 the assigned track contains a comparison, and explain the decisive tradeoff.
 The controller reconciles tracks, chooses the final recommendation, and owns any
 authorized persistence.
+
+Open the report with one line, `Depth: Quick`, `Depth: Standard` or `Depth: Deep`, followed by `(assigned)` or, when no depth was assigned, by `(chosen: <reason>)`. End every material claim with its status in parentheses — `(confirmed)`, `(inferred)` or `(unresolved)` — in English whatever the report's language, and give every repository claim its `path:line` anchor. Close the report with this line:
+
+Relay: keep the Depth line, every status label and every path:line anchor when you summarize this report.

package/src/claude/agents/spec-maker.md

@@ -19,7 +19,7 @@ removes product decisions from implementation. The output is Markdown under
 
 Read `skills/specs/SKILL.md` and `skills/specs/references/templates.md` before
 routing; they are the canonical risk and coverage authority. Do not duplicate
-their taxonomy here. Apply their risk-first route before C1 and stop when the
+their taxonomy here. Apply their risk-first route before GATE-SCOPE and stop when the
 request qualifies for direct work; hand off when it requires Brainstorm-only exploration.
 
 ## Required process
@@ -30,7 +30,7 @@ Find current entrypoints, reusable code, callers, tests, docs, and runtime
 registration. Cite concrete `path:line` evidence. Mark facts that cannot be
 verified as `[UNVERIFIED]` and state what would settle them.
 
-### 2. Open C1 once
+### 2. Open GATE-SCOPE once
 
 Summarize what exists, the minimum change set, and expansion signals. Ask the
 user to EXPAND, KEEP, or CUT. Record the answer and explicit exclusions. Do not
@@ -46,15 +46,15 @@ specs/<feature>/task-01-<slug>.md
 specs/<feature>/task-NN-<slug>.md
 ```
 
-Keep tasks flat beside the plan. Each task owns one outcome, normally no more
-than about five files, explicit acceptance IDs, dependencies, and a runnable
-Verification Plan. Every criterion maps to at least one task and one proof.
+Keep tasks flat beside the plan. Each task owns one outcome, a priority, normally no more
+than about five files, explicit acceptance IDs, dependencies, ordered Steps, a runnable
+Verification Plan, and a Failure Protocol. Every criterion maps to at least one task and one proof.
 Use EARS sentences; each task references its canonical `CP-NN` rows instead of
 copying their kinds, surfaces, risk, or proof obligations.
 
 Do not create implementation files, receipts, approval records, generated
 registries, readiness claims, or empty supporting documents. Keep every new
-task `Status: blocked` while C2 is open, and keep its `## Receipt` empty.
+task `Status: blocked` while GATE-REVIEW is open, and keep its `## Receipt` empty.
 
 ### 4. Review from fresh context
 
@@ -63,13 +63,13 @@ and give them only the plan packet plus repository access. Require a severity,
 plan location, concrete failure, current `path:line` evidence, and smallest
 repair for every finding.
 
-Deduplicate and cap findings at 15. Open C2 so the user can accept, reject, or
+Deduplicate and cap findings at 15. Open GATE-REVIEW so the user can accept, reject, or
 revise each one. Apply only accepted changes and run the full consistency sweep
 after every edit. Rederive affected CP rows using the canonical delta list in
 the templates. Then derive every task
 state, not only the first candidate:
 `pending` means semantically ready for the dependency-aware queue. Keep a task
-`blocked` while a C1/C2 decision, accepted finding, or `UNKNOWN` closure remains
+`blocked` while a GATE-SCOPE/GATE-REVIEW decision, accepted finding, or `UNKNOWN` closure remains
 open. A named task dependency alone does not make it blocked; write dependencies
 as exact flat task basenames and let the resolver derive the next pending task.
 Move `blocked` to `pending` only when current evidence closes every non-dependency
@@ -77,7 +77,7 @@ blocker. Stop after two paper rounds; later findings need runtime evidence.
 
 ### 5. Hand off without dispatch
 
-Report the created files, C1 decision, accepted C2 findings, remaining
+Report the created files, GATE-SCOPE decision, accepted GATE-REVIEW findings, remaining
 uncertainties, every task status, and the first pending task.
 Do not start Develop or treat dispatchability as user authorization. The user
 chooses when execution begins.
@@ -100,8 +100,8 @@ End with:
 ```text
 Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
 Files: <plan and task paths>
-C1: <decision>
-C2: <accepted/rejected/revised counts>
+GATE-SCOPE: <decision>
+GATE-REVIEW: <accepted/rejected/revised counts>
 Next: <first `Status: pending` task or blocker>
 Unresolved questions: <none or concise list>
 ```

package/src/claude/hooks/__tests__/fixtures/statusline-default.golden

@@ -1 +1 @@
-🤖 TestModel  ▰▰▰▰▰▰▱▱▱▱▱▱ 53%  📁 /fixture/dir
+◆ TestModel  ◑ 53%