@haposoft/cafekit 0.18.0 → 0.18.1

package/src/claude/skills/agent-browser/SKILL.md

@@ -236,7 +236,7 @@ agent-browser snapshot -i
 agent-browser fill @e1 "user@example.com"
 agent-browser fill @e2 "password123"
 agent-browser click @e3  # Submit button
-agent-browser wait url "/dashboard"
+agent-browser wait --url "/dashboard"
 ```
 
 ### State Persistence (Auth)

package/src/claude/skills/chrome-devtools/SKILL.md

@@ -52,8 +52,7 @@ Browser visibility is resolved automatically by `resolveHeadless()` in `lib/brow
 
 Override with `--headless true` or `--headless false` on any script.
 
-- Run multiple scripts/sessions in parallel to simulate real user interactions.
-- Run multiple scripts/sessions in parallel to simulate different device types (mobile, tablet, desktop).
+Scripts share one browser and its first tab through `.browser-session.json`, so run them one at a time; parallel runs drive the same page.
 
 ## ARIA Snapshot (Element Discovery)
 
@@ -104,7 +103,6 @@ node "$SKILL_DIR/aria-snapshot.js" --url https://example.com --output ./packages
 
 ### Interact by Ref
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 Use `select-ref.js` to interact with elements by their ref:
 
 ```bash
@@ -129,7 +127,6 @@ node "$SKILL_DIR/select-ref.js" --ref e5 --action hover
 
 ### Store Snapshots
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 Store snapshots for analysis in `<project>/packages/spec/src/claude/chrome-devtools/snapshots/`:
 
 ```bash
@@ -162,7 +159,6 @@ node "$SKILL_DIR/aria-snapshot.js" --url https://example.com --output packages/s
 
 ## Local HTML Files
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 **IMPORTANT**: Never browse local HTML files via `file://` protocol. Always serve via local server:
 **Why**: `file://` protocol blocks many browser features (CORS, ES modules, fetch API, service workers). Local server ensures proper HTTP behavior.
 
@@ -176,7 +172,7 @@ python -m http.server 3000 --directory ./dist &
 node "$SKILL_DIR/navigate.js" --url http://localhost:3000
 ```
 
-**Note**: when port 3000 is busy, find an available port with `lsof -i :3000` and use a different one.
+**Note**: when port 3000 is busy, find its owner with `lsof -i :3000`; stop it if you started it, otherwise ask the user. Do not move to another port (`rules/process-management.md`).
 
 ## Quick Start
 
@@ -207,11 +203,10 @@ chrome-devtools auto-detects Chrome at standard OS paths and uses it automatical
 
 ### Manual Configuration
 
-To force a specific Chrome installation, copy `.env.example` to `.env` and set `CHROME_EXECUTABLE_PATH`:
+To force a specific Chrome installation, export `CHROME_EXECUTABLE_PATH` (or `PUPPETEER_EXECUTABLE_PATH`) in the shell that runs the scripts; they read the environment, not a `.env` file:
 
 ```bash
-cp "$SKILL_DIR/.env.example" "$SKILL_DIR/.env"
-# Edit .env and set CHROME_EXECUTABLE_PATH to your Chrome executable
+export CHROME_EXECUTABLE_PATH="/path/to/chrome"
 ```
 
 ### Skip Chromium Download
@@ -249,7 +244,6 @@ node "$SKILL_DIR/navigate.js" --url about:blank --close true
 
 ## Available Scripts
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 All in `packages/spec/src/claude/skills/chrome-devtools/scripts/`:
 
 | Script | Purpose |
@@ -281,15 +275,14 @@ All in `packages/spec/src/claude/skills/chrome-devtools/scripts/`:
 
 ## Writing Custom Test Scripts
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
-For complex automation, write scripts to `<project>/packages/spec/src/claude/chrome-devtools/tmp/`:
+For complex automation, write scripts to `$SKILL_DIR/../tmp/` (beside `scripts/`, so the `../scripts/lib/browser.js` import resolves):
 
 ```bash
 # Create tmp directory for test scripts
-mkdir -p $SKILL_DIR/packages/spec/src/claude/chrome-devtools/tmp
+mkdir -p "$SKILL_DIR/../tmp"
 
 # Write a test script
-cat > $SKILL_DIR/packages/spec/src/claude/chrome-devtools/tmp/login-test.js << 'EOF'
+cat > "$SKILL_DIR/../tmp/login-test.js" << 'EOF'
 import { getBrowser, getPage, disconnectBrowser, outputJSON } from '../scripts/lib/browser.js';
 
 async function loginTest() {
@@ -315,7 +308,7 @@ loginTest();
 EOF
 
 # Run the test
-node $SKILL_DIR/packages/spec/src/claude/chrome-devtools/tmp/login-test.js
+node "$SKILL_DIR/../tmp/login-test.js"
 ```
 
 **Key principles for custom scripts**:
@@ -327,11 +320,7 @@ node $SKILL_DIR/packages/spec/src/claude/chrome-devtools/tmp/login-test.js
 
 ## Screenshots
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
-
-**IMPORTANT:** Store browser artifacts in a project-local screenshots or reports folder and include exact output paths in the final report.
-
-Store screenshots for analysis in `<project>/packages/spec/src/claude/chrome-devtools/screenshots/`:
+Store screenshots in `<project>/packages/spec/src/claude/chrome-devtools/screenshots/` and give their exact output paths in the final report:
 
 ```bash
 # Basic screenshot
@@ -356,15 +345,13 @@ node "$SKILL_DIR/screenshot.js" --url https://example.com --output ./packages/sp
 node "$SKILL_DIR/screenshot.js" --url https://example.com --output ./packages/spec/src/claude/chrome-devtools/screenshots/page.png --max-size 3
 
 # Disable compression
-node "$SKILL_DIR/screenshot.js" --url https://example.com --output ./packages/spec/src/claude/chrome-devtools/screenshots/page.png --no-compress
+node "$SKILL_DIR/screenshot.js" --url https://example.com --output ./packages/spec/src/claude/chrome-devtools/screenshots/page.png --no-compress true
 ```
 
 Store screenshots for analysis in `<project>/packages/spec/src/claude/chrome-devtools/screenshots/`.
 
 ## Console Log Collection & Analysis
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
-
 ### Capture Logs
 
 ```bash
@@ -407,7 +394,6 @@ node "$SKILL_DIR/console.js" --url https://example.com --types error --duration
 
 ## Finding Elements
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 Use `snapshot.js` to discover selectors before interacting:
 
 ```bash
@@ -423,12 +409,11 @@ node "$SKILL_DIR/snapshot.js" --url https://example.com | jq '.elements[] | sele
 
 ## Error Recovery
 
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
 If script fails:
 
 ```bash
 # 1. Capture current state (without navigating to preserve state)
-node "$SKILL_DIR/screenshot.js" --output ./packages/spec/src/claude/skills/chrome-devtools/screenshots/debug.png
+node "$SKILL_DIR/screenshot.js" --output ./packages/spec/src/claude/chrome-devtools/screenshots/debug.png
 
 # 2. Get console errors
 node "$SKILL_DIR/console.js" --url about:blank --types error --duration 1000
@@ -469,22 +454,20 @@ node "$SKILL_DIR/performance.js" --url https://example.com | jq '.vitals'
 All scripts support:
 - `--headless true/false` - Override auto-detected headless mode (default: auto by OS)
 - `--close true` - Close browser completely (default: stay running)
-- `--timeout 30000` - Set timeout (ms)
-- `--wait-until networkidle2` - Wait strategy
+- `--wait-until networkidle2` - Wait strategy when the script loads `--url`
+- `--timeout <ms>` - read by the scripts that load a page or wait for one (`navigate.js`, `click.js`, `fill.js`, `connect-chrome.js`, `import-cookies.js`, `inject-auth.js`)
 
 `navigate.js` additionally supports:
 - `--wait-for-login <pattern>` - Interactive login: open headed, wait for URL regex match
 - `--login-timeout <ms>` - Max wait for login completion (default: 300000 = 5 min)
 
 ## Troubleshooting
-Skills can exist in **project-scope** or **user-scope**. Priority: project-scope > user-scope.
-
 | Error | Solution |
 |-------|----------|
 | `Cannot find package 'puppeteer'` | Run `npm install` in scripts directory |
 | `libnss3.so` missing (Linux) | Run `./install-deps.sh` |
 | Element not found | Use `snapshot.js` to find correct selector |
-| Script hangs | Use `--timeout 60000` or `--wait-until load` |
+| Script hangs | Use `--wait-until load`, or `--timeout 60000` on a script that reads it |
 | Screenshot >5MB | Auto-compressed; use `--max-size 3` for lower |
 | Session stale | Delete `.browser-session.json` and retry |
 

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

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

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

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

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

@@ -12,10 +12,7 @@ metadata:
 ---
 # Develop — implement, prove, synchronize
 
-Implement only the explicitly requested scope. For a process-first feature,
-`plan.md` and flat tasks are the durable packet; one closeout owner coordinates
-verification, review, sync, and docs impact without borrowing evidence.
-Develop never starts merely because Specs finished. The user invokes it.
+Implement only the explicitly requested scope. For a process-first feature, `plan.md` and flat tasks are the durable packet; one closeout owner coordinates verification, review, sync, and docs impact without borrowing evidence. Develop never starts merely because Specs finished. The user invokes it.
 
 ## Usage and pre-state guard
 
@@ -28,8 +25,7 @@ Develop never starts merely because Specs finished. The user invokes it.
 /cf:develop <feature> --notes
 ```
 
-`--notes` is opt-in. Only then load `references/implementation-notes-template.html`;
-record decisions, scope exceptions, risks, gaps, and verification limits. Never create it by default.
+`--notes` is opt-in. Only then load `references/implementation-notes-template.html`; record decisions, scope exceptions, risks, gaps, and verification limits. Never create it by default.
 
 Before any state mutation, reject `--flash` combined with `--parallel`:
 
@@ -41,31 +37,22 @@ The pair exits `2` before a task edit, receipt, worktree, subagent, or commit. D
 
 ## Resolve the work packet
 
-1. Resolve one `specs/<feature>/plan.md` plus flat `task-NN-*.md`; an explicit task path wins.
-2. Read GATE-SCOPE scope, exclusions, acceptance mapping, ownership, and task order.
-3. A task is unblocked only when every named dependency is `done` with a valid current inline Receipt.
-4. Without a packet, work directly only when the change is clear, isolated, reversible, and low-risk.
+- Resolve one `specs/<feature>/plan.md` plus flat `task-NN-*.md`; an explicit task path wins.
+- Read GATE-SCOPE scope, exclusions, acceptance mapping, ownership, and task order.
+- A task is unblocked only when every named dependency is `done` with a valid current inline Receipt.
+- Without a packet, work directly only when the change is clear, isolated, reversible, and low-risk.
 
 Ambiguity, overlapping ownership, a dependency cycle, or a missing Verification Plan is a blocker. Do not guess.
 
 ### Accepted process-first fast path
 
-When line two is `Specs-Contract: process-first-ready-v1`, reuse the accepted GATE-SCOPE/GATE-REVIEW.
-Perform only a narrow freshness scout for target revision, scope drift, ownership
-conflict, and dependency/state changes. Reopen GATE-SCOPE only for evidenced scope drift;
-do not research, replan, or add a routine user gate before a real blocker or GATE-DONE.
-This is a source instruction contract, not a parser/runtime or live-model guarantee;
-live-model adherence is `[UNVERIFIED]` without a host invocation.
+When line two is `Specs-Contract: process-first-ready-v1`, reuse the accepted GATE-SCOPE/GATE-REVIEW. Perform only a narrow freshness scout for target revision, scope drift, ownership conflict, and dependency/state changes. Reopen GATE-SCOPE only for evidenced scope drift; do not research, replan, or add a routine user gate before a real blocker or GATE-DONE. This is a source instruction contract, not a parser/runtime or live-model guarantee; live-model adherence is `[UNVERIFIED]` without a host invocation.
 
-Load the plan index into working context once. Later byte rereads are narrow drift
-checks; load only the active task's referenced coverage-profile rows, Outcome,
-Scope, Ownership, Steps, Acceptance, Dependencies, Verification Plan, Failure Protocol, owned code, and consumers.
+Load the plan index into working context once. Later byte rereads are narrow drift checks; load only the active task's referenced coverage-profile rows, Outcome, Scope, Ownership, Steps, Acceptance, Dependencies, Verification Plan, Failure Protocol, owned code, and consumers.
 
 ## Current-byte selection
 
-Reread current plan/task bytes before each selection and controller write. Concurrent
-Develop invocations are unsupported; detected state, task, or owned-path drift stops
-before any Status or Receipt write.
+Reread current plan/task bytes before each selection and controller write. Concurrent Develop invocations are unsupported; detected state, task, or owned-path drift stops before any Status or Receipt write.
 
 | Current bytes | Feature mode | Explicit task mode |
 |---|---|---|
@@ -77,89 +64,54 @@ before any Status or Receipt write.
 | No task is active | Select the first dependency-valid `pending` row in `plan.md` order. | Start only the exact pending target when dependencies are valid. |
 | Status is missing, duplicate, or unknown | Stop as malformed state. | Stop as malformed state. |
 
-Feature mode repeats this selection only after the current task closes. Specific-task
-mode never touches a sibling and returns after its successful sync without chaining or GATE-DONE.
+Feature mode repeats this selection only after the current task closes. Specific-task mode never touches a sibling and returns after its successful sync without chaining or GATE-DONE.
 
 ## Modes
 
 ### Sequential feature or specific task
 
-The controller sets the selected task's single `Status:` to `in_progress`.
-Implement its Outcome and Acceptance only. Keep one unblocked task at a time;
-never start the next before proof, review, and sync finish for the current task.
+The controller sets the selected task's single `Status:` to `in_progress`. Implement its Outcome and Acceptance only. Keep one unblocked task at a time; never start the next before proof, review, and sync finish for the current task.
 
 ### Parallel (`--parallel [N]`)
 
-Load `references/parallel-waves.md`. Require disjoint writes, satisfied dependencies,
-isolated worktrees, a bounded wave, and one controller writer; otherwise work sequentially.
+Load `references/parallel-waves.md`. Require disjoint writes, satisfied dependencies, isolated worktrees, a bounded wave, and one controller writer; otherwise work sequentially.
 
 ### Flash (`--flash`)
 
-Load `references/quality-gate.md`. Flash is an explicit speed trade-off, never completion: run a
-cheap preflight, skip dedicated tests, keep `Status: in_progress` with `FLASH_UNVERIFIED` and the
-blocker `awaiting /cf:test <feature>`, do not unblock dependents or report PASS, and
-stop this invocation without chaining.
-Only a later explicit non-Flash invocation may recover the task.
-It treats Flash output as ephemeral, inspects current bytes and the owned diff, and obtains fresh
-canonical proof through the trusted sync-finalize path. Never weaken, delete, or rewrite tests to make Flash look complete.
+Load `references/quality-gate.md`. Flash is an explicit speed trade-off, never completion: run a cheap preflight, skip dedicated tests, keep `Status: in_progress` with `FLASH_UNVERIFIED` and the blocker `awaiting /cf:test <feature>`, do not unblock dependents or report PASS, and stop this invocation without chaining. Only a later explicit non-Flash invocation may recover the task. It treats Flash output as ephemeral, inspects current bytes and the owned diff, and obtains fresh canonical proof through the trusted sync-finalize path. Never weaken, delete, or rewrite tests to make Flash look complete.
 
 ## Task cycle
 
 ### 1. Scout
 
-Trace entrypoints, callers, dependents, registration, errors, and owned files.
-Read the test or probe that will judge this task before implementing against it.
-Compilation does not prove an unmounted UI, unregistered route, uncalled service,
-or missing consumer.
+Trace entrypoints, callers, dependents, registration, errors, and owned files. Read the test or probe that will judge this task before implementing against it. Compilation does not prove an unmounted UI, unregistered route, uncalled service, or missing consumer.
 
-For an interrupted `in_progress` task, preserve and inspect current owned changes;
-discard ephemeral, remembered, or prior-attempt proof; compare unmet Acceptance
-against current task bytes and owned diff. Do not blindly replay a non-idempotent
-mutation. Resume only unmet work, then run fresh verification.
+For an interrupted `in_progress` task, preserve and inspect current owned changes; discard ephemeral, remembered, or prior-attempt proof; compare unmet Acceptance against current task bytes and owned diff. Do not blindly replay a non-idempotent mutation. Resume only unmet work, then run fresh verification.
 
 ### 2. Implement
 
 Unless under `--flash` or the command costs money or writes artifacts, run the task's exact Verification Plan command once before changing anything and expect it to fail; this pre-change run is not a repair round.
 Passing before any change, outside a resumed task, means the plan cannot judge the work and is a blocker; so is a failure naming something other than the unmet Acceptance, which is a blocker to raise, not a defect to work around while implementing. A failure from the command itself — a wrong path, a missing tool or module, the environment — is BLOCKED, not FAIL, even when the runner reports `not ok` and even when the Acceptance or a test file shows the right command: set the task's single `Status:` to `blocked` with a `Blocker:` line naming the command and its error, write no Receipt, revert any edit made in this run, and report; you may suggest a corrected command for the plan, but never run it as proof.
 
-Honor Scope, Ownership, Acceptance, and Dependencies. Do not silently replace named contracts;
-scope expansion requires evidence and a return to GATE-SCOPE, not implementation convenience.
-Load `references/subagent-patterns.md` when dispatch helps; only the controller writes Status or Receipt.
+Honor Scope, Ownership, Acceptance, and Dependencies. Do not silently replace named contracts; scope expansion requires evidence and a return to GATE-SCOPE, not implementation convenience. Load `references/subagent-patterns.md` when dispatch helps; only the controller writes Status or Receipt.
 
 ### 3. Verify, review, and close
 
-The test owner executes each exact Verification Plan and records real output. The
-review owner evaluates correctness, security, scope, and reachability without
-manufacturing proof. Use `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`; only literal PASS can close.
+The test owner executes each exact Verification Plan and records real output. The review owner evaluates correctness, security, scope, and reachability without manufacturing proof. Use `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`; only literal PASS can close.
 
-Load `references/quality-gate.md`. Remediate an observed failure (a blocked Command is not a failure to remediate), then rerun only
-affected proof/review. Do not blind-retry a blocked environment. One repair round is one
-observed failure plus its repair and rerun, from proof or from review alike. After three
-failed repair rounds, stop and ask the user.
+Load `references/quality-gate.md`. Remediate an observed failure (a blocked Command is not a failure to remediate), then rerun only affected proof/review. Do not blind-retry a blocked environment. One repair round is one observed failure plus its repair and rerun, from proof or from review alike. After three failed repair rounds, stop and ask the user.
 
-**The Receipt is written last, after proof and review have both passed**; writing it earlier
-and reopening the task is a defect, not a shortcut. After a real pass, the controller writes the task's final inline `## Receipt` with
-`Verification: PASS`, exact `Command`, `Exit: 0`, `Base:` and `Head:` copied from the `Base` and `Head` fields of `node .claude/scripts/provenance.cjs --project-root . --specs-root specs --spec-file <task file> --feature-name <feature> --session <any label> --json` run after the last change outside the specs root (never typed or computed by hand),
-non-empty current output, and required negative/reachability/artifact proof; then it
-sets `Status: done` and only implemented checkboxes. Missing, stale, contradictory,
-zero-test, placeholder, marker-only, skipped, or remembered proof is unfinished.
+**The Receipt is written last, after proof and review have both passed**; writing it earlier and reopening the task is a defect, not a shortcut. After a real pass, the controller writes the task's final inline `## Receipt` with `Verification: PASS`, exact `Command`, `Exit: 0`, `Base:` and `Head:` copied from the `Base` and `Head` fields of `node .claude/scripts/provenance.cjs --project-root . --specs-root specs --spec-file <task file> --feature-name <feature> --session <any label> --json` run after the last change outside the specs root (never typed or computed by hand), non-empty current output in a fenced block, and required negative/reachability/artifact proof; then it sets `Status: done` and only implemented checkboxes. Missing, stale, contradictory, zero-test, placeholder, marker-only, skipped, or remembered proof is unfinished.
 
 ### 4. Finish the requested boundary
 
-Reread the task after sync and recompute the queue from current bytes. Specific-task
-mode has already returned. Full-feature mode continues one task at a time, then runs
-the named feature-level integration and reachability checks. Before GATE-DONE, apply the
-quality-gate final-Head fixed point; show current evidence and limitations, and let
-the user decide completion.
+Reread the task after sync and recompute the queue from current bytes. Specific-task mode has already returned. Full-feature mode continues one task at a time, then runs the named feature-level integration and reachability checks. Before GATE-DONE, apply the quality-gate final-Head fixed point; show current evidence and limitations, and let the user decide completion.
 
-Evaluate docs impact from behavior actually changed: `none` means report only;
-`minor` or `major` updates only affected existing docs through the docs flow.
+Evaluate docs impact from behavior actually changed: `none` means report only; `minor` or `major` updates only affected existing docs through the docs flow.
 
 ## Definition of done
 
-Done requires satisfied acceptance, reachable behavior, current executable proof,
-stable Base/Head binding, resolved blocking review findings, and no scope substitution.
-`PASS_WITH_WARNINGS`, `NO_TESTS`, `FLASH_UNVERIFIED`, or review-only pass cannot close.
+Done requires satisfied acceptance, reachable behavior, current executable proof, stable Base/Head binding, resolved blocking review findings, and no scope substitution. `PASS_WITH_WARNINGS`, `NO_TESTS`, `FLASH_UNVERIFIED`, or review-only pass cannot close.
 
 ## Attached references
 

package/src/claude/skills/develop/references/subagent-patterns.md

@@ -50,9 +50,3 @@ After interruption, preserve the owned diff but discard ephemeral handoffs and
 remembered proof. Do not tell an implementation worker to repeat a non-idempotent
 action blindly; scope the resumed brief to unmet Acceptance and require fresh
 verification. Concurrent invocations remain unsupported, so drift blocks handoff.
-
-## Legacy workflow compatibility
-
-When the selected packet is legacy, include its persisted lane snapshot and
-obligations in the dispatch, but do not let workers edit that state or infer an
-independent result from a role label.