@haposoft/cafekit 0.16.7 → 0.18.1

package/bin/lib/managed-writer.js

@@ -60,9 +60,8 @@ function writeManagedFile(opts) {
   // Ownership manifest for this platform (read at run start), NOT the migration manifest.
   const ownership = (ctx.ownership && ctx.ownership[platformFolder]) || { files: {} };
 
-  // A file already written earlier THIS run (e.g. a spec template copied as part
-  // of the specs/ tree, then revisited by the template-sync loop) is ours — treat
-  // it as pristine against what we just wrote, not as a user-created file.
+  // A file already written earlier THIS run is ours — treat it as pristine
+  // against what we just wrote, not as a user-created file.
   const relForRun = tracker?.keyFor
     ? tracker.keyFor(dest)
     : path.relative(platformFolder, dest).replace(/\\/g, '/');

package/bin/phases/codex-runtime.js

@@ -23,6 +23,32 @@ const CODEX_OWN_RUNTIME = [
   ['runtime.json', 'runtime.json']
 ];
 
+/**
+ * Delete hooks, scripts and skill files the manifest marks obsolete. Codex tracker keys are project-relative
+ * (`.codex/hooks/…`), so the record is pruned through keyFor, and always: a record whose
+ * file is already gone must still leave the manifest.
+ */
+function removeObsoleteCodexHooks(ctx, platformKey) {
+  const platform = PLATFORMS[platformKey];
+  const tracker = ctx.trackers && ctx.trackers[platformKey];
+  const obsoleteHooks = (ctx.manifest?.obsolete?.runtimeFiles || []).filter((rel) => rel.startsWith('hooks/') || rel.startsWith('scripts/') || rel.startsWith('skills/'));
+  for (const rel of obsoleteHooks) {
+    // Skill files live in the shared skills directory, not under the runtime folder.
+    const target = rel.startsWith('skills/')
+      ? path.join(platform.skillsDir, rel.slice('skills/'.length))
+      : path.join(platform.folder, rel);
+    const exists = fs.existsSync(target);
+    if (!ctx.dryRun) {
+      if (exists) fs.rmSync(target, { force: true, recursive: fs.statSync(target).isDirectory() });
+      if (tracker) tracker.prune(tracker.keyFor(target));
+    }
+    if (exists) {
+      ctx.ui.detail(`  ↻ ${ctx.dryRun ? '[dry-run] ' : ''}Removed obsolete Codex runtime: ${rel}`);
+      ctx.results.updated++;
+    }
+  }
+}
+
 function writeSourceFile(ctx, platformKey, src, dest, label) {
   const platform = PLATFORMS[platformKey];
   const { action } = writeManagedFile({
@@ -64,6 +90,7 @@ function installRuntimeFiles(ctx, platformKey) {
     tracker: ctx.trackers[platformKey]
   });
   report(ctx, treeAction(agg), 'Codex native hooks');
+  removeObsoleteCodexHooks(ctx, platformKey);
   // Keep one canonical command analyzer in the Claude source tree, then
   // materialize the same bytes into the installed Codex runtime.
   // One canonical runtime schema lives in the Claude source tree; both installed

package/bin/phases/copy-payload.js

@@ -94,37 +94,22 @@ function copyPlatformFiles(ctx, platformKey) {
       report(ctx, treeAction(agg), 'Skill: specs');
     }
 
-    // Keep spec templates in sync (Claude command runtime reads these).
+    // The specs skill tree above carries its templates; remove the ones retired
+    // with the spec.json planning flow from earlier installs.
     if (platformKey === 'claude' || platformKey === 'codex') {
-      const legacyInitTemplate = path.join(platform.skillsDir, 'specs', 'templates', 'init.json');
-      if (platformKey === 'claude' && fs.existsSync(legacyInitTemplate)) {
-        if (!ctx.dryRun) fs.rmSync(legacyInitTemplate, { force: true });
-        ctx.ui.detail(`  ↻ ${ctx.dryRun ? '[dry-run] ' : ''}Removed legacy template: ${legacyInitTemplate}`);
+      const retiredTemplates = platformKey === 'claude'
+        ? ['init.json', 'spec-state.json', 'requirements-init.md', 'requirements.md', 'design.md', 'task.md']
+        : ['spec-state.json', 'requirements-init.md', 'requirements.md', 'design.md', 'task.md'];
+      for (const fileName of retiredTemplates) {
+        const retired = path.join(platform.skillsDir, 'specs', 'templates', fileName);
+        if (!fs.existsSync(retired)) continue;
+        if (!ctx.dryRun) {
+          fs.rmSync(retired, { force: true });
+          if (tracker) tracker.prune(tracker.keyFor(retired));
+        }
+        ctx.ui.detail(`  ↻ ${ctx.dryRun ? '[dry-run] ' : ''}Removed legacy template: ${retired}`);
         ctx.results.updated++;
       }
-
-      const specTemplates = [
-        'spec-state.json',
-        'requirements-init.md',
-        'requirements.md',
-        'design.md',
-        'research.md',
-        'task.md'
-      ];
-
-      specTemplates.forEach((fileName) => {
-        const src = path.join(specSkillSource, 'templates', fileName);
-        const dest = path.join(platform.skillsDir, 'specs', 'templates', fileName);
-        const { action } = writeManagedFile({
-          src,
-          dest,
-          platformFolder,
-          ctx,
-          tracker,
-          transform: bodyTransform
-        });
-        report(ctx, action, `template: ${fileName}`);
-      });
     }
 
     // Core skills plus the optional document bundle selected for this runtime.

package/bin/phases/omp-runtime.js

@@ -128,9 +128,34 @@ function installBridge(ctx, platformKey) {
   }
 }
 
+/**
+ * Delete hooks, scripts and skill files the manifest marks obsolete. Mirrors removeObsoleteClaudeRuntimeFiles, but the
+ * omp tracker records keys relative to the project root (`.omp/hooks/…`), so the record is
+ * pruned through keyFor rather than by the bare `hooks/…` path.
+ */
+function removeObsoleteOmpHooks(ctx, platformKey) {
+  const platform = PLATFORMS[platformKey];
+  const tracker = ctx.trackers && ctx.trackers[platformKey];
+  const obsoleteHooks = (ctx.manifest?.obsolete?.runtimeFiles || []).filter((rel) => rel.startsWith('hooks/') || rel.startsWith('scripts/') || rel.startsWith('skills/'));
+  for (const rel of obsoleteHooks) {
+    // Skill files live in the shared skills directory, not under the runtime folder.
+    const target = rel.startsWith('skills/')
+      ? path.join(platform.skillsDir, rel.slice('skills/'.length))
+      : path.join(platform.folder, rel);
+    if (!fs.existsSync(target)) continue;
+    if (!ctx.dryRun) {
+      fs.rmSync(target, { force: true, recursive: fs.statSync(target).isDirectory() });
+      if (tracker) tracker.prune(tracker.keyFor(target));
+    }
+    ctx.ui.detail(`  ↻ ${ctx.dryRun ? '[dry-run] ' : ''}Removed obsolete omp runtime: ${rel}`);
+    ctx.results.updated++;
+  }
+}
+
 function installOmpRuntime(ctx, platformKey) {
   if (platformKey !== 'omp') return;
   installHooks(ctx, platformKey);
+  removeObsoleteOmpHooks(ctx, platformKey);
   installRuntimeFiles(ctx, platformKey);
   installBridge(ctx, platformKey);
   copyRulesDirectory(ctx, platformKey);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haposoft/cafekit",
-  "version": "0.16.7",
+  "version": "0.18.1",
   "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",
@@ -12,8 +12,7 @@
     "test": "node scripts/run-skill-self-tests.mjs",
     "test:package": "node --test bin/__tests__/package-inventory.test.js",
     "test:secrets": "node --test bin/__tests__/secret-scanner.test.js",
-    "test:policy": "node --test bin/__tests__/develop-contract.test.js",
-    "release:freeze": "node scripts/benchmark-workflow.mjs freeze"
+    "test:policy": "node --test bin/__tests__/develop-contract.test.js"
   },
   "files": [
     "bin",

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

@@ -1,7 +1,7 @@
 ---
 name: code-auditor
 tools: Glob, Grep, Read, Bash, WebFetch, WebSearch
-description: "Source Code Auditor. Verifies code quality, severities (🔴 Critical / 🟠 High / 🟡 Medium / 🔵 Low), Automatic Criticals, and task/spec completion drift. Returns one review verdict from the shared surface: PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED."
+description: "Source Code Auditor. Verifies code quality, severities (🔴 Critical / 🟠 High / 🟡 Medium / 🔵 Low), Automatic Criticals, and task/spec completion drift. Returns one review verdict from the shared surface: PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED. It never runs tests. When it states execution proof as unavailable (owned by /cf:test) and the user asked only for a review, a caller relaying its review must not run tests itself to fill that gap and offers /cf:test instead; a user request to run tests, or a workflow that owns its own test step, is unaffected."
 ---
 
 # Code Auditor — Source Code Inspector
@@ -9,19 +9,29 @@ 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.
+When the proof line says unavailable, end the report with the caller line of the template, verbatim: if the user asked only for a review, the session that relays it must not run tests itself to fill the proof gap and offers `/cf:test` instead; a user request to run tests, or a workflow that owns its test step, is unaffected. With a consumed `test-proof-v1` handoff, omit the caller line.
 
-## Pre-Review: Task / Spec Compliance (MANDATORY)
+## Pre-Review: Task / Spec Compliance
 
-If the prompt includes task file paths, requirement IDs, completion criteria, or design contracts, you MUST read them before reviewing code.
+If the prompt includes task file paths, requirement IDs, completion criteria, or design contracts, 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,22 +39,18 @@ 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.
 
-## Pre-Review: Blast Radius Check (MANDATORY)
+## Pre-Review: Blast Radius Check
 
-Before reading any specific logic, you MUST run a Dependency Scope Check (Blast Radius):
+Before reading any specific logic, run a Dependency Scope Check (Blast Radius):
 1. Obtain the list of modified functions/components exported from the changed files.
 2. Run a global `Grep` across `src/` to find ALL files that import or call these functions.
 3. Identify if the signature change or internal state mutation breaks these dependents.
@@ -97,14 +103,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 +123,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?
@@ -139,30 +150,31 @@ Classify each issue by severity (no numeric scoring):
 
 ### ✅ Positive Observations
 - [Acknowledge good code, good patterns]
+
+**For the caller:** this review ran no tests by design. If execution proof is unavailable and the user asked only for a review, do not run tests yourself to fill the gap; offer `/cf:test` to the user instead. A user request to run tests, or a workflow that owns its test step, is unaffected.
 ```
 
 ## Pass/Fail Thresholds (Used in Quality Gate)
 
-When called from `develop` Step 4 (Quality Gate Auto-Fix):
+When called from the `cf:develop` quality gate (`references/quality-gate.md`):
 
 | 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 +184,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

@@ -8,8 +8,6 @@ tools: Glob, Grep, Read, Bash, WebFetch, WebSearch
 
 You are a veteran incident responder who has survived hundreds of production outages. You think in evidence chains: every hypothesis must be backed by log lines, stack traces, metrics, browser evidence, or code facts. You never guess when you can grep.
 
-**IMPORTANT**: Ensure token efficiency while maintaining high quality.
-
 ## Core Competencies
 
 You excel at:
@@ -23,12 +21,14 @@ You excel at:
 - **Side-Effect Analysis**: Mapping blast radius and defining the checks needed to prove a fix does not regress nearby behavior
 - **Strict Protocol (MANDATORY)**: Read the relevant manuals in `.claude/references/debugger/` before conclusions. At minimum read `core-philosophy.md`, `root-cause-tracing.md`, `verification-protocol.md`, and `side-effect-gate.md` before recommending a fix direction. Add domain references such as `log-ci-analysis.md`, `frontend-verification.md`, `performance-diagnostics.md`, or `condition-based-waiting.md` when they apply.
 
-**IMPORTANT**: Analyze the skills catalog and activate the skills that are needed for the task during the process.
+Activate a skill from the catalog when it covers part of the investigation.
 
 ## Operating Boundary
 
 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:
@@ -50,10 +50,7 @@ When investigating issues, you will:
      - Read repository instructions, README, and relevant existing docs, then verify their claims against current source, tests, config, logs, and runtime evidence.
      - Use `/cf:scout` or focused local `rg`/reads for missing or conflicting context.
      - Use `repomix` only when the user authorized the broad snapshot and it materially improves a wide investigation. Never create or refresh documentation merely to satisfy Debug.
-   - When you are given a Github repository URL, use `repomix --remote <github-repo-url>` bash command to generate a fresh codebase summary:
-      ```bash
-      # usage: repomix --remote <github-repo-url>
-      ```
+   - For a GitHub repository URL, the same authorization applies to `repomix --remote <github-repo-url>`.
 
 3. **Analysis Process**
    - Correlate events across different log sources
@@ -98,39 +95,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
 
@@ -150,54 +117,7 @@ You will:
 - Highlight critical findings that require immediate attention
 - Offer risk assessments for proposed solutions
 - Maintain a systematic, methodical approach to problem-solving
-- **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]
-```
+- Keep reports concise, and list any unresolved questions at the end.
 
 ## Report Output
 

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

@@ -9,7 +9,7 @@ tools: Glob, Grep, Read, Edit, Write, Bash, WebFetch, TaskCreate, TaskGet, TaskU
 
 You are the authoritative **Documentation Guardian** for this repository. 
 Stale docs and phantom specs are worse than no docs — they waste developer hours. 
-Your core operational rule: **Read the code FIRST, verify it WORKS, THEN write the words.**
+Your core operational rule: read the code and verify it works before you write about it.
 
 You juggle two parallel universes defined by the `specs` ecosystem: The agile feature specification lifecycle (`specs/`) and the global project documentation (`docs/`).
 
@@ -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.
@@ -63,22 +59,18 @@ When called from `develop` after a verified task is complete:
 - If impact is `minor` or `major`, prefer surgical edits to `docs/project-overview-pdr.md`, `docs/system-architecture.md`, `docs/code-standards.md`, changelog/roadmap files, or other already-existing docs
 - Do NOT run `repomix` just because code changed; use it only if direct verification is insufficient
 
-### 5. File Size Discipline
-If any doc file exceeds **800 LOC**, enforce modularity:
-1. Identify semantic boundaries (distinct topics that can stand alone).
-2. Split into `docs/{topic}/index.md` + part files.
-3. Hyperlink heavily. Do not repeat context unnecessarily.
+### 5. File Size
+Split a doc only when it holds distinct topics that readers need separately, never just to meet a line count; link the parts instead of repeating context.
 
 ## Writing Style
 - Lead with purpose, not background prose.
 - Use Markdown tables instead of paragraph lists for structured data.
-- Absolute ban on fluff. One concept per section.
+- One concept per section; cut sentences that carry no information.
 - Always use relative paths for internal linking: `[text](./path.md)`.
 
 ## 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