@haposoft/cafekit 0.18.0 → 0.18.1

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

@@ -12,17 +12,13 @@ metadata:
 ---
 # Research — proportional evidence for a decision
 
-Return a decision-ready answer, not a search diary or an unsorted option list.
-Research evaluates choices; it does not implement them or invent certainty.
+Return a decision-ready answer, not a search diary or an unsorted option list. Research evaluates choices; it does not implement them or invent certainty.
 
-## 1. Frame the decision
+## Frame the decision
 
-Restate the decision, project constraints, affected consumers, and what evidence
-would change the answer. Inspect current repository sources first whenever local
-fit matters. Ask the user only when a missing choice materially changes scope or
-safety; otherwise label bounded assumptions and continue.
+Restate the decision, project constraints, affected consumers, and what evidence would change the answer. Inspect current repository sources first whenever local fit matters. Ask the user only when a missing choice materially changes scope or safety; otherwise label bounded assumptions and continue.
 
-## 2. Select depth
+## Select depth
 
 Choose the smallest depth that can support the decision:
 
@@ -32,56 +28,29 @@ Choose the smallest depth that can support the decision:
 | Standard | Several viable options or a material integration choice | Verify material claims across at least two independent authoritative sources where available; compare fit and tradeoffs. |
 | Deep | High blast radius, hard-to-reverse architecture, security/compliance, substantial cost, or conflicting evidence | Complete Standard, then run a separate contradiction-and-gap round; use at least three independent sources for disputed material claims where available. |
 
-Escalate depth when evidence conflicts, a primary source is missing, or a finding
-changes the decision boundary. Do not inflate source counts with mirrors or
-articles that repeat the same upstream claim. Stop when new evidence no longer
-changes the ranking, limitations, or unresolved gaps.
+Escalate depth when evidence conflicts, a primary source is missing, or a finding changes the decision boundary. Do not inflate source counts with mirrors or articles that repeat the same upstream claim. Stop when new evidence no longer changes the ranking, limitations, or unresolved gaps.
 
-## 3. Gather evidence
+## Gather evidence
 
 - Repository claims: cite a resolvable `path:line` anchor from current bytes.
-- External claims: prefer current official documentation, standards, research
-  papers, maintainer material, and release notes. Browse when facts may have
-  changed; record the source date or applicable version.
-- For each material claim record: claim, URL or repository anchor, authority,
-  date/version, applicability to this project, and status
-  `confirmed | inferred | unresolved`.
-- A source count is not confidence. Explain conflicts, missing primary evidence,
-  version mismatch, and why a source does or does not apply.
-
-Use delegated researchers only as optional acceleration when two or more
-independent evidence tracks can be bounded. The controller owns the question,
-source reconciliation, and final recommendation. If delegation is unavailable,
-unauthorized, or not useful, research sequentially with the same evidence bar.
-When a researcher's report feeds the answer, keep its `Depth:` line, its status labels and its `path:line` anchors, reconciled with your own evidence.
-
-## 4. Synthesize
-
-For comparisons, rank only viable options and name a winner when evidence and
-project fit support one. For every ranked option include fit, decisive evidence,
-tradeoffs, adoption/operational risks, and limitations. If evidence cannot choose
-a winner, return `unresolved` plus the smallest fact or experiment that would.
-
-Use the four mandatory H2 sections from
-`.claude/skills/specs/templates/research.md`. Keep claim records and comparisons
-inside `## Evidence Summary`; do not add or reorder mandatory H2 headings.
-
-## 5. Output and persistence
-
-Default to a concise answer in chat. Persist only when:
-
-1. one explicitly resolved active Spec requires durable `research.md`; save to
-   that exact `specs/<feature>/research.md`, preserving its existing lifecycle; or
-2. the user explicitly requests a durable report and approves its destination.
-
-Do not create a Spec or `_shared` archive merely to save an answer. The
-controller performs any authorized write after reviewing and redacting the
-output; delegated researchers never write reports or task state. Always state
-depth used, decisive evidence, recommendation, limitations, and unresolved gaps.
-Give every material claim in the answer its status in parentheses — `(confirmed)`, `(inferred)` or `(unresolved)` — in English whatever the answer's language.
+- External claims: prefer current official documentation, standards, research papers, maintainer material, and release notes. Browse when facts may have changed; record the source date or applicable version.
+- For each material claim record: claim, URL or repository anchor, authority, date/version, applicability to this project, and status `confirmed | inferred | unresolved`.
+- A source count is not confidence. Explain conflicts, missing primary evidence, version mismatch, and why a source does or does not apply.
+
+Use delegated researchers only as optional acceleration when two or more independent evidence tracks can be bounded. The controller owns the question, source reconciliation, and final recommendation. If delegation is unavailable, unauthorized, or not useful, research sequentially with the same evidence bar. When a researcher's report feeds the answer, keep its `Depth:` line, its status labels and its `path:line` anchors, reconciled with your own evidence.
+
+## Synthesize
+
+For comparisons, rank only viable options and name a winner when evidence and project fit support one. For every ranked option include fit, decisive evidence, tradeoffs, adoption/operational risks, and limitations. If evidence cannot choose a winner, return `unresolved` plus the smallest fact or experiment that would.
+
+Use the four mandatory H2 sections from `.claude/skills/specs/templates/research.md`. Keep claim records and comparisons inside `## Evidence Summary`; do not add or reorder mandatory H2 headings.
+
+## Output and persistence
+
+Default to a concise answer in chat. Persist only when: one explicitly resolved active Spec requires durable `research.md`; save to that exact `specs/<feature>/research.md`, preserving its existing lifecycle; or the user explicitly requests a durable report and approves its destination.
+
+Do not create a Spec or `_shared` archive merely to save an answer. The controller performs any authorized write after reviewing and redacting the output; delegated researchers never write reports or task state. Always state depth used, decisive evidence, recommendation, limitations, and unresolved gaps. Give every material claim in the answer its status in parentheses — `(confirmed)`, `(inferred)` or `(unresolved)` — in English whatever the answer's language.
 
 ## Handoff boundary
 
-Research may recommend Brainstorm or Specs when a material product/design choice
-remains. It never starts Develop, edits implementation code, claims user approval,
-or presents source/installed evidence as live-system proof.
+Research may recommend Brainstorm or Specs when a material product/design choice remains. It never starts Develop, edits implementation code, claims user approval, or presents source/installed evidence as live-system proof.

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

@@ -12,9 +12,7 @@ metadata:
 ---
 # Sync — file-state synchronization
 
-Synchronize only observed state. For the primary process-first layout, the
-single `Status:` field and inline `## Receipt` in each flat task file are the
-state. Never infer proof, approval, review independence, or product readiness.
+Synchronize only observed state. For the primary process-first layout, the single `Status:` field and inline `## Receipt` in each flat task file are the state. Never infer proof, approval, review independence, or product readiness.
 
 ## Commands
 
@@ -28,45 +26,25 @@ state. Never infer proof, approval, review independence, or product readiness.
 /cf:sync
 ```
 
-Resolve one regular direct-child task inside `specs/<feature>/`. Reject path
-escape, symlink, ambiguity, missing `plan.md`, duplicate Status fields, and
-unsupported status values.
+Resolve one regular direct-child task inside `specs/<feature>/`. Reject path escape, symlink, ambiguity, missing `plan.md`, duplicate Status fields, and unsupported status values.
 
 ## Task synchronization
 
-1. Read the task Outcome, Acceptance, Dependencies, Verification Plan, current
-   Status, and Receipt before editing.
-2. Starting or resuming changes only Status to `in_progress`. Update only
-   checkboxes whose implementation is real.
-3. Blocking changes Status to `blocked` and records a concrete blocker; it does
-   not create proof.
-4. Done requires a current inline Receipt with `Verification: PASS`, exact
-   Command, `Exit: 0`, runtime-bound Base/Head, non-empty fenced output, and any
-   required negative/reachability/artifact proof.
-5. Write or replace the Receipt before changing Status to `done`. Missing,
-   stale, contradictory, placeholder, failure, or zero-test evidence keeps the
-   task `in_progress` or `blocked`.
-6. Re-read the file after the surgical edit and confirm exactly one Status and
-   one Receipt section.
+- Read the task Outcome, Acceptance, Dependencies, Verification Plan, current Status, and Receipt before editing.
+- Starting or resuming changes only Status to `in_progress`. Update only checkboxes whose implementation is real.
+- Blocking changes Status to `blocked` and records a concrete blocker; it does not create proof.
+- Done requires a current inline Receipt with `Verification: PASS`, exact Command, `Exit: 0`, runtime-bound Base/Head, non-empty fenced output, and any required negative/reachability/artifact proof.
+- Write or replace the Receipt before changing Status to `done`. Missing, stale, contradictory, placeholder, failure, or zero-test evidence keeps the task `in_progress` or `blocked`.
+- Re-read the file after the surgical edit and confirm exactly one Status and one Receipt section.
 
-`sync-finalize` is the only promotion path for `FLASH_UNVERIFIED`. It requires
-fresh canonical PASS proof, revalidates Base/Head and artifacts, clears the
-flash blocker, then derives `done`. Caller-supplied promotion booleans and a
-marker alone have no authority.
+`sync-finalize` is the only promotion path for `FLASH_UNVERIFIED`. It requires fresh canonical PASS proof, revalidates Base/Head and artifacts, clears the flash blocker, then derives `done`. Caller-supplied promotion booleans and a marker alone have no authority.
 
 ## Audit
 
-Scan only `specs/<feature>/task-*.md` beside `plan.md`. Compare plan task rows,
-task filenames, dependencies, Status, acceptance mapping, and Receipts. Report
-missing files, unknown rows, cycles, duplicate fields, done-without-proof,
-proof-on-unfinished-task, and overlapping ownership.
+Scan only `specs/<feature>/task-*.md` beside `plan.md`. Compare plan task rows, task filenames, dependencies, Status, acceptance mapping, and Receipts. Report missing files, unknown rows, cycles, duplicate fields, done-without-proof, proof-on-unfinished-task, and overlapping ownership.
 
-An audit writes nothing until the user confirms the named changes; then repair
-deterministic formatting drift only and never pick a winner in a semantic conflict.
-Read `references/rebind-and-audit.md` before a rebind, a bare call, or a file
-report, and `references/sync-protocols.md` for surgical update and audit rules.
+An audit writes nothing until the user confirms the named changes; then repair deterministic formatting drift only and never pick a winner in a semantic conflict. Read `references/rebind-and-audit.md` before a rebind, a bare call, or a file report, and `references/sync-protocols.md` for surgical update and audit rules.
 
 ## Docs impact
 
-When a task becomes done, report `Docs impact: none|minor|major`. Create no docs
-work for `none`; update only affected existing docs for minor or major.
+When a task becomes done, report `Docs impact: none|minor|major`. Create no docs work for `none`; update only affected existing docs for minor or major.

package/src/claude/skills/sync/references/rebind-and-audit.md

@@ -46,8 +46,8 @@ Never archive, move, rename, or delete a packet, change the specs root, or edit
 ## Bare call
 
 `/cf:sync` without arguments audits every process-first packet under the specs
-root and writes nothing. Report legacy (`spec.json`) and archived packets
-without touching them. End by asking with `AskUserQuestion` when the host has
+root and writes nothing. Report archived packets, and packet directories without
+`plan.md` that CafeKit no longer reads, without touching them. End by asking with `AskUserQuestion` when the host has
 it, otherwise ask in text and stop. Only a reply that arrives after the report
 and names the changes counts as confirmation; an instruction given before the
 report, such as "close everything", does not.

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

@@ -12,57 +12,36 @@ metadata:
 ---
 # Test — execution proof owner
 
-`cf:test` executes the smallest adequate real verification and owns the
-canonical execution result. For process-first work it returns one typed proof
-handoff to the controller; it never writes task state or the inline Receipt.
-Review consumes validated proof and never invents or duplicates execution.
+`cf:test` executes the smallest adequate real verification and owns the canonical execution result. For process-first work it returns one typed proof handoff to the controller; it never writes task state or the inline Receipt. Review consumes validated proof and never invents or duplicates execution.
 
 ## Usage
-
 ```text
-/cf:test
-/cf:test --full
+/cf:test [--full]
 /cf:test <scope-or-path>
 /cf:test <feature-name>
-/cf:test specs/<feature>
-/cf:test specs/<feature>/task-NN-<slug>.md
-/cf:test --ui <url>
-/cf:test --ui-auth <url>
-/cf:test --ui-flow <url>
+/cf:test specs/<feature>[/task-NN-<slug>.md]
+/cf:test --ui|--ui-auth|--ui-flow <url>
 ```
-
 ## Hard gates
-
 - Never claim a pass without executing the exact relevant command.
 - Never mock, weaken, delete, or skip a failing assertion to obtain green.
-- Missing tooling, a missing command, nonzero exit, or zero executed tests is
-  never `PASS`. Do not auto-install project-local tooling during proof.
-- Preserve exact commands, counts, output, reachability, proof level, Base,
-  Head, artifact hashes, and redaction labels.
-- Source, installed, and live proof are distinct. Live adherence is
-  `[UNVERIFIED]` without a host invocation.
-- Use only `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`. Unknown, malformed,
-  partial, contradictory, duplicate, skipped, or stale proof fails closed.
-
+- Missing tooling, a missing command, nonzero exit, or zero executed tests is never `PASS`. Do not auto-install project-local tooling during proof.
+- Preserve exact commands, counts, output, reachability, proof level, Base, Head, artifact hashes, and redaction labels.
+- Source, installed, and live proof are distinct. Live adherence is `[UNVERIFIED]` without a host invocation.
+- Use only `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`. Unknown, malformed, partial, contradictory, duplicate, skipped, or stale proof fails closed.
 ## Target routing
-
-Classify current filesystem bytes before selecting tests. Use `lstat` so broken
-links count as markers. Never migrate or repair packet state while testing.
+Classify current filesystem bytes before selecting tests. Use `lstat` so broken links count as markers. Never migrate or repair packet state while testing.
 
 | Observed state | Route |
 |---|---|
-| Valid regular `plan.md` with `Specs-Contract: process-first-ready-v1`, one or more valid regular flat `task-NN-*.md`, and no legacy marker | Process-first |
-| Any flat marker that is orphaned, malformed, duplicated, symlinked, nonregular, or mixed with a legacy marker | `BLOCKED` |
-| Valid regular legacy root resolving every nested task and separate receipt, with no flat marker | Legacy adapter |
-| Orphan, malformed, symlinked, nonregular, identity-conflicting, or mixed legacy state | `BLOCKED` |
-| No flat or legacy marker | Ordinary non-Spec testing |
+| Valid regular `plan.md` with `Specs-Contract: process-first-ready-v1` and one or more valid regular flat `task-NN-*.md` | Process-first |
+| Any flat marker that is orphaned, malformed, duplicated, symlinked, or nonregular | `BLOCKED` |
+| A packet directory with no `plan.md` that holds the old JSON planning state | `BLOCKED`: CafeKit no longer reads it; move the work to a `plan.md` packet |
+| No flat marker | Ordinary non-Spec testing |
 
-A flat marker is a direct-child `plan.md` or `task-NN-*.md`. A legacy marker is
-`spec.json`, a nested legacy task, or a separate legacy receipt. See
-`references/execution-strategy.md` for the complete validation truth table.
+A flat marker is a direct-child `plan.md` or `task-NN-*.md`. See `references/execution-strategy.md` for the complete validation truth table.
 
 ## Spec-Aware Mode
-
 <SCOPE-GATE>
 For a feature target, test only current accepted scope, the active task's exact
 Verification Plan, and reachable runtime surfaces. Missing or orphaned
@@ -70,37 +49,19 @@ reachability fails even when a command exits successfully.
 </SCOPE-GATE>
 
 For a process-first feature:
-
-1. Read current `plan.md` and flat task bytes. Select only a contained regular
-   task whose dependencies allow proof.
-2. Use the task's exact `Command`, exact unique `Named probes`, `Reachability`,
-   `Oracle`, `Counterexample`, required proof level, and artifact declaration.
-3. Run the smallest adequate proof. `--full` expands scope but cannot weaken
-   the Verification Plan or substitute unrelated green tests.
-4. Return exactly one canonical `test-proof-v1` object. Do not edit `plan.md`,
-   `Status:`, the task's `## Receipt`, or any sibling task.
-5. The Develop controller validates the payload, recomputes its digest, checks
-   current provenance, and alone writes process-first Status and inline Receipt.
-
+- Read current `plan.md` and flat task bytes. Select only a contained regular task whose dependencies allow proof.
+- Use the task's exact `Command`, exact unique `Named probes`, `Reachability`, `Oracle`, `Counterexample`, required proof level, and artifact declaration.
+- Run the smallest adequate proof. `--full` expands scope but cannot weaken the Verification Plan or substitute unrelated green tests.
+- Return exactly one canonical `test-proof-v1` object. Do not edit `plan.md`, `Status:`, the task's `## Receipt`, or any sibling task.
+- The Develop controller validates the payload, recomputes its digest, checks current provenance, and alone writes process-first Status and inline Receipt.
 ## Execution
-
-1. Detect commands from task and repository files; never invent them.
-2. Run a cheap compile or typecheck precheck when the project provides one.
-3. Execute the exact task command and all named probes with real counts.
-4. For Ordinary non-Spec testing, before any `PASS` or `PASS_WITH_WARNINGS`,
-   read the tests that cover the target or changed code (every test file when
-   the suite is small). When an assertion or its pass condition depends on a
-   nondeterministic source — the clock, randomness, the network, shared
-   filesystem state or test order — the verdict is `FAIL`, naming the source,
-   even when every run passes. When only setup depends on one, rerun just the
-   suspect tests at least twice more; any differing outcome is `FAIL` as flaky.
-   A single green run of such a test is not `PASS`. This step does not apply to
-   process-first Named probes, which run exactly once.
-5. Inspect negative paths, runtime reachability, and declared artifacts.
-6. Capture tracked, untracked, and ignored project-command drift separately
-   from runtime Head. Never silently clean or hide project changes.
-7. Redact sensitive material, validate the complete proof object, then return a
-   concise human report separately from the machine handoff.
+- Detect commands from task and repository files; never invent them.
+- Run a cheap compile or typecheck precheck when the project provides one.
+- Execute the exact task command and all named probes with real counts.
+- For Ordinary non-Spec testing, before any `PASS` or `PASS_WITH_WARNINGS`, read the tests that cover the target or changed code (every test file when the suite is small). When an assertion or its pass condition depends on a nondeterministic source — the clock, randomness, the network, shared filesystem state or test order — the verdict is `FAIL`, naming the source, even when every run passes. When only setup depends on one, rerun just the suspect tests at least twice more; any differing outcome is `FAIL` as flaky. A single green run of such a test is not `PASS`. This step does not apply to process-first Named probes, which run exactly once.
+- Inspect negative paths, runtime reachability, and declared artifacts.
+- Capture tracked, untracked, and ignored project-command drift separately from runtime Head. Never silently clean or hide project changes.
+- Redact sensitive material, validate the complete proof object, then return a concise human report separately from the machine handoff.
 
 Required proof follows the behavior:
 
@@ -113,45 +74,23 @@ Required proof follows the behavior:
 | layout, focus, labels, keyboard | viewport/visual/accessibility check |
 | regression | reproduction before fix plus passing regression |
 | security/performance | only when requirement, risk, or boundary requires it |
-
 ## Process-first proof handoff
-
 The machine payload is canonical UTF-8 JSON with exact top-level keys:
-
 ```text
-schema_version, target, verdict, command, exit, counts, provenance,
-proof_level, expected, observed, reachability, artifacts, branches,
-raw_output, redactions, payload_sha256
+schema_version, target, verdict, command, exit, counts, provenance, proof_level, expected, observed, reachability, artifacts, branches, raw_output, redactions, payload_sha256
 ```
 
-`schema_version` is exactly `test-proof-v1`; unknown keys block. Branch IDs map
-one-to-one to exact unique Named probes. The digest is lowercase SHA-256 of
-stable JSON excluding only `payload_sha256`. Exact field shapes, nullable
-pre-execution `BLOCKED` rules, and aggregation live in
-`references/execution-strategy.md`.
-
-Only all required branches passing with exact command, exit 0, executed > 0,
-failed/skipped 0, matching Base/Head, `reachability.status: PASS`, valid artifact
-hashes, and safe redaction can aggregate `PASS`. Aggregate in this order:
-`FAIL` > `BLOCKED` > `PASS_WITH_WARNINGS` > `PASS`.
+`schema_version` is exactly `test-proof-v1`; unknown keys block. Branch IDs map one-to-one to exact unique Named probes. The digest is lowercase SHA-256 of stable JSON excluding only `payload_sha256`. Exact field shapes, nullable pre-execution `BLOCKED` rules, and aggregation live in `references/execution-strategy.md`.
 
+Only all required branches passing with exact command, exit 0, executed > 0, failed/skipped 0, matching Base/Head, `reachability.status: PASS`, valid artifact hashes, and safe redaction can aggregate `PASS`. Aggregate in this order: `FAIL` > `BLOCKED` > `PASS_WITH_WARNINGS` > `PASS`.
 ## Persistent-write and authentication boundary
-
-- `.hapo/test-memory.json` is optional read-only context. Hash absent/present
-  bytes before and after; never create, merge, or update it during proof.
-- Put only Test-owned temporary files outside the project and clean them.
-  Never create Test-owned reports, caches, lazy installs, or auth state.
-- For authenticated UI proof, prefer the project's own auth helper. Otherwise
-  use only an explicitly selected user-controlled profile bound to a confirmed
-  HTTPS or localhost origin, identity, permissions, and action scope.
-- Block cross-origin redirects and destructive production actions without fresh
-  consent. Never ask for, export, paste, or persist cookies or tokens.
-- Redact Authorization, Cookie, Set-Cookie, session tokens, credentials, and
-  scoped PII from commands, headers/bodies, logs, screenshots, and reports.
-  If safe proof is impossible, return `BLOCKED`.
+- `.hapo/test-memory.json` is optional read-only context. Hash absent/present bytes before and after; never create, merge, or update it during proof.
+- Put only Test-owned temporary files outside the project and clean them. Never create Test-owned reports, caches, lazy installs, or auth state.
+- For authenticated UI proof, prefer the project's own auth helper. Otherwise use only an explicitly selected user-controlled profile bound to a confirmed HTTPS or localhost origin, identity, permissions, and action scope.
+- Block cross-origin redirects and destructive production actions without fresh consent. Never ask for, export, paste, or persist cookies or tokens.
+- Redact Authorization, Cookie, Set-Cookie, session tokens, credentials, and scoped PII from commands, headers/bodies, logs, screenshots, and reports. If safe proof is impossible, return `BLOCKED`.
 
 ## Verdict and report
-
 ```markdown
 ## Test Verdict
 
@@ -170,35 +109,12 @@ hashes, and safe redaction can aggregate `PASS`. Aggregate in this order:
 - [controller handoff, exact failure, or changed prerequisite]
 ```
 
-Do not place the full JSON payload, secrets, verbose raw logs, or screenshots in
-the concise report. `PASS_WITH_WARNINGS` remains unfinished; only literal
-validated `PASS` may be synchronized by the controller.
-
-When the target's task can be read — a process-first packet, or a packet
-`BLOCKED` while it is classified that still holds exactly one regular flat task
-with a readable `Command` and `Named probes` — end the final message with the
-concise report, then a `### Machine handoff (test-proof-v1)` heading and exactly
-one fenced `json` block holding the validated payload. The handoff block follows
-the report and is not part of it. No further fenced block follows it. A
-pre-execution `BLOCKED` takes the same placement; its shape is in
-`references/execution-strategy.md` §4. For any other target, end with the
-report and the line `No payload: target not identifiable.`
-
-## Legacy workflow compatibility
-
-A valid legacy packet keeps the v2.1 adapter, legacy task resolution, and its
-separate receipt path. Do not write process-first inline proof into it. If
-legacy proof identities conflict or the packet is mixed/malformed, return
-`BLOCKED`; never choose one source or migrate it during unrelated testing.
-
-Flash legacy behavior remains proof-only: testing may make a current
-`FLASH_UNVERIFIED` task eligible for trusted sync-finalize, but never promotes
-state or unblocks dependents itself. Only explicit trusted sync-finalize may
-promote it.
+Do not place the full JSON payload, secrets, verbose raw logs, or screenshots in the concise report. `PASS_WITH_WARNINGS` remains unfinished; only literal validated `PASS` may be synchronized by the controller.
 
+When the target's task can be read — a process-first packet, or a packet `BLOCKED` while it is classified that still holds exactly one regular flat task with a readable `Command` and `Named probes` — end the final message with the concise report, then a `### Machine handoff (test-proof-v1)` heading and exactly one fenced `json` block holding the validated payload. The handoff block follows the report and is not part of it. No further fenced block follows it. A pre-execution `BLOCKED` takes the same placement; its shape is in `references/execution-strategy.md` §4. For any other target, end with the report and the line `No payload: target not identifiable.`
+## Flash proof
+Flash behavior remains proof-only: testing may make a current `FLASH_UNVERIFIED` task eligible for trusted sync-finalize, but never promotes state or unblocks dependents itself. Only explicit trusted sync-finalize may promote it.
 ## References
-
-- `references/execution-strategy.md` — routing, payload schema, aggregation,
-  blast radius, UI safety, and report separation.
+- `references/execution-strategy.md` — routing, payload schema, aggregation, blast radius, UI safety, and report separation.
 - `references/failure-triage.md` — failure classification and four verdicts.
 - `references/test-memory.md` — optional read-only historical context.

package/src/claude/skills/test/references/execution-strategy.md

@@ -20,27 +20,20 @@ marker. Resolve all accepted paths inside the target feature directory.
   marker, malformed or duplicate task fields, symlink, directory, device, or
   other nonregular flat marker returns `BLOCKED`.
 
-### Legacy markers
+### Packets the runtime no longer reads
 
-- Legacy markers are `spec.json`, nested legacy tasks, or separate legacy
-  receipts. Detect them even when orphaned or broken.
-- Legacy is selected only when a regular schema-valid `spec.json` has one
-  consistent identity and registry resolving every contained nested task and
-  receipt, and no flat marker exists.
-- Orphan nested tasks/receipts, absent or schema-invalid root, conflicting
-  identities, symlinks, nonregular markers, or unresolved/out-of-root entries
-  return `BLOCKED`.
+- A packet directory with no `plan.md` that holds the old JSON planning state is not
+  read by CafeKit. Return `BLOCKED` and name it; never migrate it while testing.
+- Other files beside a valid `plan.md` do not change its classification.
 
 ### Precedence truth table
 
-| Flat state | Legacy state | Result |
+| Flat state | Old planning state without `plan.md` | Result |
 |---|---|---|
-| valid | absent | process-first |
-| absent | valid | legacy adapter |
+| valid | any | process-first |
+| invalid | any | `BLOCKED` |
+| absent | present | `BLOCKED`: unsupported, move the work to a `plan.md` packet |
 | absent | absent | ordinary non-Spec scope |
-| any marker | any marker | `BLOCKED` mixed state |
-| invalid | absent | `BLOCKED` |
-| absent | invalid | `BLOCKED` |
 
 Do not infer that an invalid marker is absent. Testing never repairs, migrates,
 renames, deletes, or chooses between conflicting packet identities.
@@ -181,7 +174,7 @@ packet failed classification after the repository had a commit:
   },
   "proof_level": "source",
   "expected": "both Named probes pass under `node --test test/login.test.js`",
-  "observed": "BLOCKED before execution: specs/user-auth also holds spec.json, a legacy marker",
+  "observed": "BLOCKED before execution: specs/user-auth/task-01-login.md is a symlink",
   "reachability": {
     "status": "BLOCKED",
     "evidence": [
@@ -287,9 +280,5 @@ Do not paste verbose raw output, full JSON, credentials, PII, or screenshots int
 the report. Do not write a report file during proof. Process-first Status and
 inline `## Receipt` remain controller-only.
 
-## Legacy workflow compatibility
-
-After a valid legacy route, preserve its v2.1 task/receipt adapter and existing
-proof rules. Separate legacy receipts remain legacy-only. Never search for or
-create a separate receipt for a process-first task, and never copy a legacy
-receipt into a flat task.
+Proof for a process-first task lives only in its inline `## Receipt`; never
+search for or create a receipt file beside it.

package/src/claude/skills/ui-ux/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: cf:ui-ux
-description: "Build, review, or redesign an in-app screen (dashboard, list, table, form, settings, modal) the way a designer works: brief, 2–3 wireframes, the user picks, then build with the project's own components and measure the page with a browser probe. Other routes on request: review an existing UI ('xem giúp', 'review', 'nhìn rối', 'what's wrong'), rebuild keeping the brand ('giữ brand', 'keep the brand'), rebuild in the skill's own style ('bỏ style cũ'), refactor keeping the look ('chuyển sang Tailwind'), build right away ('dựng luôn', 'just build it'), design system first ('UI kit', 'component library'), a simple logo ('làm logo', 'design a logo'), or fix one component. Triggers: 'dựng màn', 'thiết kế', 'làm UI cho đẹp', 'làm lại UX', 'build a page', 'design this screen', 'redesign', 'make it look good', 'ecommerce', 'ui-ux', 'evon'. Landing pages, storefronts and blogs are not covered (it still builds them, with a warning)."
+description: "Build, review, or redesign an in-app screen (dashboard, list, table, form, settings, modal) the way a designer works: brief, 2–3 wireframes, the user picks, then build with the project's own components and measure the page with a browser probe. On request it also reviews an existing UI, rebuilds with or without the current brand, refactors styling while keeping the look, builds immediately without wireframes, builds a design system or component kit first, makes a simple logo, or fixes one component, for Vietnamese or English requests ('dựng màn', 'thiết kế', 'làm UI cho đẹp', 'làm lại UX', 'xem giúp', 'nhìn rối', 'giữ brand', 'bỏ style cũ', 'dựng luôn', 'làm logo', 'build a page', 'redesign', 'ui-ux', 'evon'). Landing pages, storefronts and blogs are not covered (it still builds them, with a warning)."
 license: MIT
 user-invocable: true
 when_to_use: "Invoke to build, review, or redesign an app screen with wireframes and a measured probe; for palette, font, or UX-guideline lookups use cf:ui-ux-pro-max."