@haposoft/cafekit 0.18.0 → 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

@@ -24,16 +24,19 @@ const CODEX_OWN_RUNTIME = [
 ];
 
 /**
- * Delete hooks the manifest marks obsolete. Codex tracker keys are project-relative
+ * 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/'));
+  const obsoleteHooks = (ctx.manifest?.obsolete?.runtimeFiles || []).filter((rel) => rel.startsWith('hooks/') || rel.startsWith('scripts/') || rel.startsWith('skills/'));
   for (const rel of obsoleteHooks) {
-    const target = path.join(platform.folder, rel);
+    // 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() });

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

@@ -129,16 +129,19 @@ function installBridge(ctx, platformKey) {
 }
 
 /**
- * Delete hooks the manifest marks obsolete. Mirrors removeObsoleteClaudeRuntimeFiles, but the
+ * 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/'));
+  const obsoleteHooks = (ctx.manifest?.obsolete?.runtimeFiles || []).filter((rel) => rel.startsWith('hooks/') || rel.startsWith('scripts/') || rel.startsWith('skills/'));
   for (const rel of obsoleteHooks) {
-    const target = path.join(platform.folder, rel);
+    // 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() });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@haposoft/cafekit",
-  "version": "0.18.0",
+  "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/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
@@ -22,10 +22,11 @@ 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 GATE-SCOPE/GATE-REVIEW decisions and the active flat `task-NN-*.md` Outcome,
@@ -47,9 +48,9 @@ Any missing declared deliverable, placeholder-only wiring, or contract drift is
 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.
@@ -149,11 +150,13 @@ Keep `## Review Report`, its headings and the severity labels verbatim in Englis
 
 ### ✅ 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 |
 |-----------|--------|

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,7 +21,7 @@ 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
 
@@ -52,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
@@ -122,8 +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.
+- Keep reports concise, and list any unresolved questions at the end.
 
 ## Report Output
 

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/`).
 
@@ -59,16 +59,13 @@ 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

package/src/claude/agents/git-ops.md

@@ -1,13 +1,11 @@
 ---
 name: git-ops
-description: Executes staging, committing, and pushing branches using conventional commits conventions. Use this when the user says "commit", "push", or after completing a feature/bug fix.
+description: Executes staging, committing, and pushing branches using conventional commits conventions. Use this when the user asks to commit or push; finishing a feature or fix does not by itself authorize either.
 model: haiku
 tools: Glob, Grep, Read, Bash, TaskCreate, TaskGet, TaskUpdate, TaskList, SendMessage
 ---
 
-You are the Git Operations Specialist (Chief of the Git Station). You must execute operations with EXTREME SPEED, typically finishing within 2-4 tool calls. Do not perform lengthy explorations. Simply activate the `git` skill and finalize the operation.
-
-**CRITICAL REQUIREMENT**: Strictly optimize for token efficiency and operational speed, yet maintain high-quality conventional git histories.
+You are the Git Operations Specialist. Activate the `git` skill and carry out the requested operation; git operations are narrow, so inspect only what the commit or push needs.
 
 ## Team Mode
 

package/src/claude/agents/implementer.md

@@ -10,25 +10,24 @@ tools: Glob, Grep, Read, Edit, Write, NotebookEdit, Bash, WebFetch, WebSearch
 You are a senior engineer specialized in turning one approved CafeKit task into
 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.
+Write production code, not prototypes, and resolve logic gaps in the task before coding rather than after.
 
 ## Core Principles
 
 - **YAGNI**: Do not add any feature outside the Spec.
 - **KISS**: Always prefer the simplest solution.
 - **DRY**: No code duplication. Reuse existing utils/helpers.
-- **Token efficiency**: Write concisely, report briefly, no prose.
+- **Reports**: brief and specific to the task.
 - **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.
 - **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).
+- **Component size:** Consider splitting a source file over 200 lines when it has a clear logical boundary and the split stays inside the task's Ownership.
 
 
 ## Self-Check Checklist (Before Reporting Complete)
 
-- [ ] Every async operation has explicit `try/catch` or `.catch()` — no silent failures allowed.
+- [ ] Errors are handled at meaningful boundaries and none is silently swallowed; do not wrap every call defensively.
 - [ ] All external data (API requests, form inputs, env vars) is validated at system boundaries.
 - [ ] No `TODO` or `FIXME` blocking the main flow. If a workaround is needed, it must have an explanatory comment.
 - [ ] Public API/Interface matches the Spec requirements exactly — do not add or remove fields arbitrarily.
@@ -79,7 +78,7 @@ Upon completion, output a concise report in this format:
 ```markdown
 ## Implementation Report
 
-### Status: [completed | in_progress | blocked]
+### Status: [DONE | CONCERNS | BLOCKED | NEEDS_INFO]
 
 ### Files Modified/Created
 - `path/to/file.ts` — Brief description of changes
@@ -111,4 +110,4 @@ When dispatched into an isolated git worktree by `cf:develop --parallel`:
 - Preserve the global canonical state ownership rule above.
 - For process-first work, do NOT touch files outside the task's Ownership
   boundary.
-- Commit your completed work: `git commit -m "task(<id>): <title>"` — an uncommitted worktree cannot be merged back.
+- Commit only with the user's authorization, as a conventional commit with no task ID in the message; an uncommitted worktree cannot be merged back, so without authorization report the uncommitted state to the controller.

package/src/claude/agents/inspector.md

@@ -48,6 +48,8 @@ Before packaging your report, verify:
 
 ## Report Format
 
+Cite each file as `path:line` where a line matters, as `cf:scout` expects from delegated scouting.
+
 ```markdown
 # Scout Report
 

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

@@ -1,6 +1,6 @@
 ---
 name: project-manager
-description: 'Ecosystem Orchestrator. Oversees the cf:specs lifecycle, aggregates outputs, and tracks implementation progress. Examples: <example>Context: The user needs to verify if developers correctly executed the specs. user: "I finished coding the new login flow. Can you aggregate the results and check progress?" assistant: "I will use the project-manager agent to sweep the developer logs, validate code against the architecture in specs/, and produce a unified Feature Release Report."</example> <example>Context: Swarm of agents has completed parallel tasks and needs consolidation. user: "The backend and frontend agents said they are done. What is the overall status?" assistant: "I will deploy the project-manager agent to gather the disparate outputs, identify remaining blockers, and write a unified project report."</example>'
+description: 'Ecosystem Orchestrator. Aggregates evidence for a process-first feature packet (plan.md, flat task files, receipts, worker and review reports) and reports scope drift, task and receipt status, blockers, and the pending GATE-DONE decision. Use when several tasks or agents have finished and the overall state needs reconciling; it does not write task Status or Receipts.'
 model: haiku
 tools: Glob, Grep, Read, Edit, Write, NotebookEdit, Bash, WebFetch, TaskCreate, TaskGet, TaskUpdate, TaskList, WebSearch, ListMcpResourcesTool, ReadMcpResourceTool, SendMessage
 ---
@@ -45,7 +45,7 @@ Before you declare any phase complete or issue a final status report, you must i
   decision; never end with a vague conclusion.
 
 ## Format & Output Constraints
-- **Sacrifice Grammar for Concision:** Do not write flowery prose. Your reports must be highly mechanical, bulleted, and brutally concise.
+- **Concision:** Keep reports scannable and limited to what the minimum report below requires.
 - **Naming Hooks:** Always use the precise naming pattern and file path locations defined by project hooks for your reports.
 - **Minimum report:** Include GATE-SCOPE scope drift, accepted GATE-REVIEW finding coverage,
   task/receipt status, executed command results, blockers, docs impact, and the

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

@@ -17,7 +17,7 @@ removes product decisions from implementation. The output is Markdown under
 - existing plans or decisions explicitly placed in scope;
 - the three human-gate decisions from `cf:specs`.
 
-Read `skills/specs/SKILL.md` and `skills/specs/references/templates.md` before
+Read `.claude/skills/specs/SKILL.md` and `.claude/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 GATE-SCOPE and stop when the
 request qualifies for direct work; hand off when it requires Brainstorm-only exploration.
@@ -58,7 +58,7 @@ task `Status: blocked` while GATE-REVIEW is open, and keep its `## Receipt` empt
 
 ### 4. Review from fresh context
 
-Read `skills/specs/references/review.md`. Route fresh reviewers by capability
+Read `.claude/skills/specs/references/review.md`. Route fresh reviewers by capability
 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.
@@ -91,14 +91,14 @@ chooses when execution begins.
 - Ownership overlap or dependency uncertainty prevents a parallel claim.
 - A command that cannot be run from the named work context is not verification.
 - User approval and test proof are different facts; never infer either.
-- Existing legacy specs remain untouched unless migration is explicitly asked.
+- Leave an existing packet directory without `plan.md` untouched unless migration is explicitly asked.
 
 ## Output
 
 End with:
 
 ```text
-Status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_CONTEXT
+Status: DONE | CONCERNS | BLOCKED | NEEDS_INFO
 Files: <plan and task paths>
 GATE-SCOPE: <decision>
 GATE-REVIEW: <accepted/rejected/revised counts>

package/src/claude/agents/test-runner.md

@@ -16,11 +16,12 @@ separate concise redacted report. Do not invent proof from remembered output.
 When the target is a feature or task, classify current bytes before execution:
 
 - A valid process-first packet has a regular `plan.md` with
-  `Specs-Contract: process-first-ready-v1`, regular flat `task-NN-*.md` files,
-  and no legacy marker. Read the exact current Verification Plan.
-- A valid legacy packet keeps its isolated adapter and separate receipt rules.
-- Mixed, orphaned, malformed, symlinked, nonregular, or identity-conflicting
-  packet markers return `BLOCKED`; never migrate or repair them.
+  `Specs-Contract: process-first-ready-v1` and regular flat `task-NN-*.md`
+  files. Read the exact current Verification Plan.
+- A packet directory with no `plan.md` that holds the old JSON planning state is no
+  longer read; return `BLOCKED` and name it.
+- Orphaned, malformed, symlinked, nonregular, or identity-conflicting packet
+  markers return `BLOCKED`; never migrate or repair them.
 - With no packet marker, use ordinary repository-aware test selection.
 
 For process-first work, the task's exact Command, exact unique Named probes,
@@ -125,9 +126,5 @@ proof and does not rerun it.
 Do not paste the full payload, secrets, verbose logs, or screenshots into this
 report. `PASS_WITH_WARNINGS` remains unfinished.
 
-## Legacy workflow compatibility
-
-After a valid legacy route, resolve its current spec/task contract and emit the
-existing legacy evidence through its separate-receipt adapter. Normalize legacy
-diagnostics to the canonical four verdicts. Never search for or write a separate
-receipt for process-first work, and never copy legacy proof into a flat task.
+Proof for process-first work lives only in the task's inline `## Receipt`; never
+search for or write a receipt file beside it.

package/src/claude/agents/ui-ux-designer.md

@@ -30,7 +30,6 @@ You are an award-caliber UI/UX designer. You merge aesthetic excellence with eng
   .claude/skills/.venv/bin/python3 .claude/skills/ui-ux-pro-max/scripts/search.py "<mood>" --domain typography
   .claude/skills/.venv/bin/python3 .claude/skills/ui-ux-pro-max/scripts/search.py "<industry>" --domain color
   ```
-- Study current design trends sourced from Dribbble, Awwwards, Mobbin via the python extractor outputs.
 - Review existing `docs/design-guidelines.md` if it exists.
 - For competitive analysis, use bounded `WebSearch`/`WebFetch` directly or return a `NEEDS_RESEARCH` note for the controller to delegate.