@haposoft/cafekit 0.16.7 → 0.18.0

package/src/claude/skills/{inspect → scout}/references/internal-inspection.md

@@ -1,6 +1,6 @@
 # Conditional Discovery with Explore Subagents
 
-Use native Explore agents only after the `SKILL.md` Delegation Gate passes.
+Use native Explore agents only after the delegation gate in `SKILL.md` ("Delegate only when …") passes.
 Focused discovery stays in the main agent even when Explore is available.
 
 ## Delegation Preconditions
@@ -15,6 +15,17 @@ All are required:
 If any precondition fails, use scoped `rg`, file listing, and targeted reads in
 the main agent. Do not request extra authority for an ordinary focused scout.
 
+## Two-Phase Broad Scout
+
+Use when the scope is broad; delegate only when the gate is open.
+
+1. **Structure map** (main agent, or one Explore agent once the gate is open): list the scope
+   root's immediate children and monorepo markers, estimate files per directory, and return a
+   division plan of 1–10 sub-scopes (path or glob, estimated files, focus).
+2. **Parallel scout**: merge sub-scopes under 10 files and split those over 100; spawn Explore agents
+   on distinct sub-scopes, or scout them sequentially in the main agent when the gate is closed; then
+   aggregate into the findings `SKILL.md` asks for.
+
 ## Agent Tool Configuration
 
 ```
@@ -28,13 +39,18 @@ Quickly search {DIRECTORY} for files related to: {USER_PROMPT}
 
 Instructions:
 - Search for relevant files matching the task (Glob/Grep)
-- List files with brief descriptions; timeout 3 minutes; skip if timed out
+- Read-only: do not edit, write, or run anything that changes state
+- Report each relevant file as `path:line` with one clause on why
 
 Report format:
-## Found Files
-- `path/file.ext` - description
-## Patterns
-- Key patterns observed
+## Relevant Files
+- `path/file.ext:line` - why it matters
+## Entrypoint and Call Path
+- where the behavior starts, then each hop
+## Blast Radius
+- callers, tests, config a change would touch
+## Unknowns
+- what this scope could not settle
 ```
 
 ## Spawning Strategy
@@ -53,12 +69,12 @@ distinct and non-overlapping.
 | ≥ 3    | Yes |
 
 Use the live task or plan surface when available. Record scope and ownership
-before spawn, then completion or timeout after collection. Do not create task
+before spawn, then completion or non-response after collection. Do not create task
 state solely for one or two short probes.
 
-## Timeout, Aggregation, Reading
+## Aggregation and Reading
 
-- 3 min/agent; skip non-responders; do not restart; dedupe paths; note gaps in Unresolved Questions
+- Skip agents that do not respond; do not restart them; dedupe paths; note gaps under Unknowns
 - Stay under ~150K tokens; ~500 lines/chunk; max 3–5 small files or 1 large file chunked (`chunks = ceil(total_lines / 500)`); Read with offset/limit
 
 ## Scope Discipline
@@ -67,4 +83,4 @@ Start from concrete directories (not repo root); prefer scoped globs; skip `NO_S
 
 ## Output Contract
 
-Return: file paths, brief description per file, notable relationships/patterns, unresolved questions.
+Return the findings `SKILL.md` names — relevant files as `path:line`, entrypoint and call path, blast radius, patterns, unknowns — for the controller to merge and fold into the caller's report.

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

@@ -1,6 +1,6 @@
 ---
 name: cf:specs
-description: "Turn a substantial or risk-elevated feature idea into a bounded, reviewed plan and executable flat task files, with human decisions at scope, findings, and completion. Use when work needs durable coordination or is not eligible for direct work; skip only when a change is clear, isolated, reversible, routine, and likely limited to one or two files."
+description: "Plan a feature before anyone implements it. Use the moment a user asks to add, build, implement, or change a capability: a payment flow, an external integration, a schema change, anything touching more than one or two files. Auth, data, or money risk comes here first even when the request is clear, urgent, or says to just do it now; do not implement it yourself. A short or vague request belongs here too: the scope gate asks what is still undecided in one turn and prevents a wrong build, so a hurry is no reason to skip it. Reach for cf:brainstorm instead only when the outcome is already agreed and two designs genuinely compete. It produces a bounded plan and flat task files with human decisions at scope, findings, and completion; it never writes code. Use when work needs durable coordination or is not eligible for direct work; answer directly when the user only wants to be told or shown something, and skip only when a change is clear, isolated, reversible, routine, and likely limited to one or two files."
 user-invocable: true
 argument-hint: "<feature-description>"
 metadata:
@@ -14,6 +14,7 @@ Quality comes from a short decision process; honesty comes from evidence. Keep t
 ## Step 0 — classify risk before routing
 
 Classify material risk before choosing a workflow; user wording never lowers an observed floor.
+Request size is not a risk signal; a one-line request that touches a shared contract is `elevated`.
 
 - `critical`: auth/secrets/privacy; destructive/irreversible work or possible data loss/corruption; money/privilege/safety; production-state mutation.
 - `elevated`: cross-component contracts, compatibility, concurrency, external integration, or installed/runtime behavior.
@@ -21,7 +22,7 @@ Classify material risk before choosing a workflow; user wording never lowers an
 
 Work directly only when the cause and change are clear, isolated, reversible,
 `routine`, and likely limited to one or two files. Route unresolved user-owned
-observable choices to C1/C2 first; after they settle, route material competing
+observable choices to GATE-SCOPE/GATE-REVIEW first; after they settle, route material competing
 technical designs through Brainstorm. Split three or more independent
 subsystems; otherwise use one Specs packet for any material work that does not qualify for direct work or Brainstorm-only exploration. A subsystem is independent only when its outcome, boundary, and verification/deployment path can move through the lifecycle separately.
 
@@ -31,11 +32,11 @@ Do not create a plan merely because documentation mentions this skill; the user
 
 | Gate | Timing | Human decision |
 |---|---|---|
-| C1 — Scope | before writing the plan | EXPAND, KEEP, or CUT the proposed minimum change |
-| C2 — Findings | after adversarial review | accept, reject, or revise each deduplicated finding |
-| C3 — Done | after execution | accept completion from current command output and receipts |
+| GATE-SCOPE | before writing the plan | EXPAND, KEEP, or CUT the proposed minimum change |
+| GATE-REVIEW | after adversarial review | accept, reject, or revise each deduplicated finding |
+| GATE-DONE | after execution | accept completion from current command output and receipts |
 
-Ask once at each gate. Do not ask for routine implementation choices between them. New evidence that invalidates scope returns to C1.
+Ask once at each gate. Do not ask for routine implementation choices between them. New evidence that invalidates scope returns to GATE-SCOPE.
 
 ## Primary output layout
 
@@ -52,7 +53,7 @@ Task files are flat beside `plan.md`. Do not create a nested task directory. Use
 
 ## Flow
 
-### 1. Challenge scope, then open C1
+### 1. Challenge scope, then open GATE-SCOPE
 
 Inspect the repository before drafting. Answer three questions with current `path:line` evidence:
 
@@ -60,12 +61,12 @@ Inspect the repository before drafting. Answer three questions with current `pat
 2. What is the smallest change set that delivers the requested outcome?
 3. What signals expansion: more than eight touched files, more than two new services/classes, or three or more independently deliverable subsystems?
 
-Present the answers and ask the user to EXPAND, KEEP, or CUT. Record the chosen
-scope and explicit exclusions in `plan.md`.
+Ask GATE-SCOPE in one message: list every `decision-needed` item (the ambiguity action in `references/templates.md`) as `[NEEDS CLARIFICATION: <question>]`, offer EXPAND, KEEP, and CUT together, and never choose a product outcome on the user's behalf; if an answer leaves an item unsettled, re-ask only that item.
+Record the chosen scope and explicit exclusions in `plan.md`.
 
 ### 2. Write the plan and task packets
 
-Keep `plan.md` as the short index: C1 decision, EARS criteria, exclusions, and task table. Give every criterion a stable ID mapped by task rows.
+Keep `plan.md` as the short index: GATE-SCOPE decision, EARS criteria, exclusions, and task table. Give every criterion a stable ID mapped by task rows.
 
 For a Specs route, persist the canonical `## Coverage profile` from
 `references/templates.md`: one `CP-NN` row per observable outcome; tasks reference IDs instead of copying it.
@@ -73,15 +74,17 @@ For a Specs route, persist the canonical `## Coverage profile` from
 Each task has one usable outcome, normally at most about five owned files, explicit dependencies, measurable acceptance, and a runnable verification command; no preparation-only tasks.
 
 Author exact state: `pending` means semantically ready for the dependency-aware queue.
-Use `blocked` while a C1/C2 decision, accepted finding, or `UNKNOWN` closure remains
+Use `blocked` while a GATE-SCOPE/GATE-REVIEW decision, accepted finding, or `UNKNOWN` closure remains
 open. Dependencies alone do not change `pending`; the resolver queues them. Promote only after current evidence closes every non-dependency blocker; keep pre-execution Receipts empty.
 
 `Required proof` is planned, not executed evidence. Unknown command/caller/environment
 reachability blocks `pending`; known unrun proof does not. Missing, failed, or unavailable
-required evidence blocks `done`/C3; levels never promote. Rederive affected CP rows after accepted scope, outcome, criteria, ownership, dependency, risk, or proof deltas, before status.
+required evidence blocks `done`/GATE-DONE; levels never promote. Rederive affected CP rows after accepted scope, outcome, criteria, ownership, dependency, risk, or proof deltas, before status.
 Source/static checks prove the written contract, not live-model adherence.
 
-### 3. Review adversarially, then open C2
+### 3. Review adversarially, then open GATE-REVIEW
+
+Before GATE-REVIEW, re-run a sample of the plan's `path:line` citations sized by the claim budget in `review.md`; relabel any stale citation `[UNVERIFIED]`.
 
 Read [`references/review.md`](references/review.md) and run its fresh-context review. Require reproducible `path:line` plus a failure scenario; deduplicate, rank, and cap at 15.
 
@@ -89,16 +92,13 @@ Ask the user to accept, reject, or revise each finding; apply only accepted deci
 
 ### 4. Execute one task at a time
 
-An implementation workflow owns execution. It selects one unblocked task with
-`Status: pending`, changes its single `Status:` field to `in_progress`, respects
-owned paths, runs the task's verification, and appends a real inline `## Receipt`
-only after the command finishes.
+An implementation workflow owns execution. It selects one unblocked task with `Status: pending`, changes its single `Status:` field to `in_progress`, respects owned paths, runs the task's verification, and appends a real inline `## Receipt` only after the command finishes.
 
 Parallel work is allowed only for tasks with disjoint write ownership and
 satisfied dependencies. One file has one writer in a wave. The controller is
 the sole writer of task status and receipts.
 
-### 5. Prove completion, then open C3
+### 5. Prove completion, then open GATE-DONE
 
 A task may say `Status: done` only when its inline receipt contains the exact
 command, `Exit: 0`, `Verification: PASS`, runtime-bound Base and Head values,
@@ -106,12 +106,12 @@ and a non-empty fenced command-output block. Placeholder or remembered output
 is not evidence.
 
 Show the user the current evidence and unresolved limitations. The user decides
-at C3 whether the feature is done. A passing command proves only what it ran;
+at GATE-DONE whether the feature is done. A passing command proves only what it ran;
 it does not invent product approval, review independence, or runtime coverage.
 
 ## Ten operating laws
 
-1. **A1 — Scope once.** Raise scope pressure at C1; reopen only with new proof.
+1. **A1 — Scope once.** Raise scope pressure at GATE-SCOPE; reopen only with new proof.
 2. **A2 — Small packets.** One task, one outcome, one owner, one proof command.
 3. **A3 — One fact, one home.** Reference decisions; never copy mutable lists.
 4. **A4 — Files are state.** Markdown is canonical; indexes are disposable.
@@ -131,17 +131,10 @@ done Receipt, binding Base and Head to the live runtime only while the task file
 committed copy it no longer matches; work elsewhere in the tree never reopens it. It detects drift
 between a receipt and the tree, not invention: a valid pair costs one command and no
 verification run, so a receipt for a command that never ran satisfies it in either
-mode. C3 is where a human weighs the evidence. These checks are a final safety net,
-not a substitute for C1-C3 judgment. Do not add a new schema, approval field,
+mode. GATE-DONE is where a human weighs the evidence. These checks are a final safety net,
+not a substitute for human judgment at the three gates. Do not add a new schema, approval field,
 readiness bit, or review state to make the Markdown look more authoritative.
 
-## Legacy compatibility
-
-Existing features that contain `spec.json`, nested task files, or separate
-receipt files stay on the installed legacy adapters. Do not migrate or rewrite
-them while authoring an unrelated v3 feature. New Specs output always uses the
-flat layout above and never requires the legacy kernel.
-
 ## Maintenance
 
 Keep this entrypoint focused on routing and invariants. Put templates and

package/src/claude/skills/specs/references/review.md

@@ -1,4 +1,4 @@
-# Plan review — evidence, adversarial lenses, and C2
+# Plan review — evidence, adversarial lenses, and GATE-REVIEW
 
 Review exists to find costly errors before code. It is not a prose-quality
 score. Every accepted finding must be reproducible from current repository
@@ -72,13 +72,15 @@ Apply these to the relevant boundary:
 
 Each finding must describe an observable failure, not a preference.
 
-## Aggregate before C2
+## Aggregate before GATE-REVIEW
+
+Before GATE-REVIEW the author re-runs a sample of the plan's citations sized by the claim budget above and relabels `[UNVERIFIED]` every citation whose cited text is no longer at that line.
 
 Normalize duplicate findings by root cause. Preserve the strongest evidence and
 smallest counterexample. Sort Critical, High, then Medium. Cap the presented
 list at 15; a larger useful set means the plan should be split.
 
-Present C2 as a table:
+Present GATE-REVIEW as a table:
 
 | ID | Severity | Plan location | Failure scenario | Evidence | Proposed repair | Decision |
 |---|---|---|---|---|---|---|
@@ -88,7 +90,7 @@ decision. Record the result in the plan review log.
 
 ## Accepted-repair closure
 
-After applying an accepted C2 finding, a fresh-context closure pass records and
+After applying an accepted GATE-REVIEW finding, a fresh-context closure pass records and
 freshly replays its original counterexample after the repair under this exact review-log header:
 
 | ID | Decision | Original counterexample | Repaired at | Proved at | Replay | Closure |
@@ -97,7 +99,7 @@ freshly replays its original counterexample after the repair under this exact re
 `Repaired at` cites the repair edit; `Proved at` must cite distinct evidence from the fresh replay, never the repair-edit citation.
 An accepted finding transitions `accepted → repaired → PASS|FAIL|UNKNOWN`.
 Only `PASS` closes it; `FAIL` remains open for the remaining paper-review round; `UNKNOWN` blocks implementation handoff.
-A repair that adds user semantics or scope returns to C1.
+A repair that adds user semantics or scope returns to GATE-SCOPE.
 
 ## B3 — consistency sweep
 
@@ -119,7 +121,7 @@ Any unresolved contradiction keeps the plan unready.
 - Round three requires runtime evidence: an executed test, command output, or
   observed host behavior. More paper argument is not a new finding.
 - A repair round should not grow the plan unless evidence proves missing scope.
-- Two add-only rounds trigger a split, deferral, or return to C1.
+- Two add-only rounds trigger a split, deferral, or return to GATE-SCOPE.
 - Stop early when remaining findings are duplicates, preferences, or already
   covered by one acceptance criterion and one verification command.
 

package/src/claude/skills/specs/references/templates.md

@@ -1,14 +1,6 @@
 # Process-first plan, task, and receipt templates
 
-Use these as compact starting points. Remove unused examples and placeholders
-before C2. The primary layout is always flat:
-
-```text
-specs/<feature>/
-├── plan.md
-├── task-01-<slug>.md
-└── task-NN-<slug>.md
-```
+Use these as compact starting points. Remove unused examples and placeholders before GATE-REVIEW. The primary layout is always flat: `specs/<feature>/` holds `plan.md` beside `task-01-<slug>.md` through `task-NN-<slug>.md`, with no task subdirectory.
 
 ## `plan.md` template
 
@@ -18,7 +10,7 @@ Keep the plan short enough to scan as one index, normally under 100 lines.
 # <Feature name>
 Specs-Contract: process-first-ready-v1
 
-## Scope decision (C1 — YYYY-MM-DD)
+## Scope decision (GATE-SCOPE — YYYY-MM-DD)
 - Existing: <reusable code with path:line>
 - Minimum change: <required behavior>
 - Expansion signals: <none or evidence>
@@ -27,6 +19,11 @@ Specs-Contract: process-first-ready-v1
 ## Out of scope
 - <deliberate exclusion>
 
+## Decisions
+| ID | Chosen | Rejected | Why | Load-bearing assumption | Break signal → response |
+|---|---|---|---|---|---|
+| D-01 | <chosen path> | <rejected alternative> | <evidence-backed reason> | <assumption that must hold> | <observable signal> → <pre-decided response> |
+
 ## Coverage profile
 | ID | Outcome | Change kinds | Material surfaces | Ambiguity/action | Risk/evidence | Required proof |
 |---|---|---|---|---|---|---|
@@ -38,9 +35,9 @@ Specs-Contract: process-first-ready-v1
 | AC-01 | When <trigger>, the system shall <response>. | `<command>` |
 
 ## Tasks
-| # | Task | Criteria | Primary ownership | Dependencies | Status |
-|---|---|---|---|---|---|
-| 01 | <one outcome> | AC-01 | `src/example.ts` | - | blocked |
+| # | Task | Priority | Criteria | Primary ownership | Dependencies | Status |
+|---|---|---|---|---|---|---|
+| 01 | <one outcome> | P1 | AC-01 | `src/example.ts` | - | blocked |
 
 ## Review log
 - Round 1: <findings accepted/rejected/revised>; sweep <result>.
@@ -48,6 +45,7 @@ Specs-Contract: process-first-ready-v1
 
 Each acceptance ID must map to at least one task and one proof. A task with no
 criterion is scope drift; a criterion with no task or proof is not executable.
+`Priority`: P1 means the outcome is unusable without it, P2 is needed for acceptance, P3 improves it. Number tasks in priority order so the plan table, the filename order, and the queue agree.
 
 ## `task-NN-*.md` template
 
@@ -73,6 +71,9 @@ Status: blocked
 - Create: `test/a.test.ts`
 - Read: `src/caller.ts`
 
+## Steps
+1. <ordered action on one owned file → expected observation>
+
 ## Acceptance
 - AC-01: <task-local measurable condition>
 
@@ -87,6 +88,9 @@ Status: blocked
 - Counterexample: <material alternative behavior that must make this proof fail>
 - Artifacts: <required artifact path plus digest algorithm/comparison rule, or explicitly ephemeral with cleanup rule>
 
+## Failure Protocol
+On a failed Step or Verification Plan run: stop; do not widen scope, change the Command, or weaken a test; record observed versus expected; repair only the cited cause; after three failed rounds, stop and ask the user.
+
 ## Receipt
 <!-- Fill only after execution; see canonical form below. -->
 ````
@@ -94,18 +98,20 @@ Status: blocked
 Trace `Command → Named probe → Reachability → Oracle`. Aggregate suites name the
 owning concrete probe. `Required proof` is a planned level set, not execution
 evidence: known but unrun proof may be `pending`; `UNKNOWN` reachability blocks
-`pending`; missing, failed, or unavailable required evidence blocks `done`/C3.
+`pending`; missing, failed, or unavailable required evidence blocks `done`/GATE-DONE.
 Levels stay separate and never promote one another. Run mutation or destructive
 negative controls only on disposable copies under a verified temporary root,
 never tracked worktree or canonical source bytes.
 For every required level in each referenced CP row, map its named probe and
 reachability here; one command may own several explicitly named level probes.
+Verification compares observed output with the Oracle; a judgment such as "looks right" is not a verification.
+Example failure: the Command exits 1 with `expected 3 files, found 2` → record observed versus expected, add the missing writer, and rerun the same Command; never delete the assertion.
 
 ## Status matrix
 
 | Status condition | Persisted state |
 |---|---|
-| C1/C2 decision open | `blocked` |
+| GATE-SCOPE/GATE-REVIEW decision open | `blocked` |
 | accepted finding open or `UNKNOWN` reachability | `blocked` |
 | every non-dependency blocker closed | `pending` |
 | named task dependency not done | keep `pending`; queue gates it |
@@ -138,16 +144,13 @@ bare PASS claim without the command output.
 
 ## EARS sentence patterns
 
-Use the narrowest pattern that describes observable behavior:
-
 1. **Ubiquitous:** `The <system> shall <response>.`
 2. **Event-driven:** `When <trigger>, the <system> shall <response>.`
 3. **State-driven:** `While <state>, the <system> shall <response>.`
 4. **Unwanted behavior:** `If <fault>, the <system> shall <response>.`
 5. **Optional feature:** `Where <feature is enabled>, the <system> shall <response>.`
 
-Avoid implementation detail unless it is a user-approved contract. Replace
-"fast", "robust", and "works" with a measurable threshold or observation.
+Use the narrowest pattern that describes observable behavior. Avoid implementation detail unless it is a user-approved contract. Replace "fast", "robust", and "works" with a measurable threshold or observation.
 
 ## Example Mapping rule
 
@@ -157,7 +160,7 @@ Classify ambiguity in every affected CP row:
 |---|---|
 | `none` | proceed |
 | `examples-needed` | add two or three examples only for an already decided rule; promote to `decision-needed` if an example changes observable behavior |
-| `decision-needed` | ask the user at C1/C2 and keep affected tasks blocked |
+| `decision-needed` | ask the user at GATE-SCOPE/GATE-REVIEW and keep affected tasks blocked |
 | `design-needed` | after user-owned decisions settle, route material competing technical designs through Brainstorm |
 
 Do not let examples choose a product outcome: retention of 30 versus 90 days is
@@ -165,7 +168,7 @@ Do not let examples choose a product outcome: retention of 30 versus 90 days is
 
 ## No-invention and conditional boundary contracts
 
-Before implementation handoff, apply the **no-invention gate**: if two implementations conform to the packet text yet can produce different externally observable output, state, error, security, or compatibility behavior, surface the missing choice as an explicit C1 or C2 question and block handoff.
+Before implementation handoff, apply the **no-invention gate**: if two implementations conform to the packet text yet can produce different externally observable output, state, error, security, or compatibility behavior, surface the missing choice as an explicit GATE-SCOPE or GATE-REVIEW question and block handoff.
 
 For a Specs route, `plan.md` owns one `## Coverage profile` row per externally observable outcome; direct and Brainstorm-only routes do not persist it. Change kinds are multi-valued (`add`, `modify`, `fix`, `refactor`, `remove`, `migrate`, `integrate`), and unfamiliar kinds or surfaces use `other:<verbatim>` rather than disappearing. Each task references its CP IDs; authoring, review, edge, and proof obligations union only inside affected rows/tasks. Rederive affected CP rows after any accepted scope, outcome, criteria, ownership, dependency, risk, or proof delta before task status.
 
@@ -186,15 +189,11 @@ For every required row, name each listed choice exactly; labels such as “JSON
 
 ## Twelve edge-case dimensions
 
-For each material boundary, select relevant dimensions rather than filling a
-ceremonial matrix:
+For each material boundary, select relevant dimensions rather than filling a ceremonial matrix:
 
-- Input shape, identity, state, order: malformed/duplicate/bounds, wrong actor,
-  partial/stale state, replay/reordering.
-- Concurrency, dependency, failure, recovery: races/cancellation, version drift,
-  timeout/nonzero exit, retry/rollback/cleanup.
-- Persistence, integration, security/privacy, observability/proof: partial
-  writes, registration/reachability, traversal/secrets, artifacts/provenance.
+- Input shape, identity, state, order: malformed/duplicate/bounds, wrong actor, partial/stale state, replay/reordering.
+- Concurrency, dependency, failure, recovery: races/cancellation, version drift, timeout/nonzero exit, retry/rollback/cleanup.
+- Persistence, integration, security/privacy, observability/proof: partial writes, registration/reachability, traversal/secrets, artifacts/provenance.
 
 `Crash` means abrupt unhandled termination before the claimed catch point; a catchable failure returns/raises an error or exits nonzero. Never use them interchangeably.
 
@@ -203,17 +202,11 @@ verification probe. Do not duplicate it across all three.
 
 ## Quality and saturation checks
 
-Before C2 confirm:
+Before GATE-REVIEW confirm:
 
-- every repository fact has current evidence or `[UNVERIFIED]`;
-- every acceptance criterion maps to task and proof;
-- task ownership does not overlap within a proposed parallel wave;
-- dependencies are acyclic and refer to real task numbers;
-- commands are runnable from the named work context;
-- negative, recovery, and reachability probes exist where risk requires them;
-- every ambiguity follows its required action; examples only clarify decided rules;
-- the latest consistency sweep reports zero unresolved contradictions.
+- evidence: every repository fact has a current citation or `[UNVERIFIED]`, and the sampled citations were re-run;
+- mapping: each acceptance criterion reaches a task and a proof; ownership does not overlap inside one parallel wave; dependencies are acyclic and name real task files;
+- proof: commands run from the named work context, and negative, recovery, and reachability probes exist where risk requires them;
+- closure: each ambiguity followed its required action, examples only clarify decided rules, and the latest consistency sweep reports zero unresolved contradictions.
 
-Stop expanding when a fresh reviewer finds no new material failure with new
-evidence, the 12 dimensions yield no uncovered relevant boundary, and every
-accepted C2 finding is represented exactly once.
+Stop expanding when a fresh reviewer finds no new material failure with new evidence, the 12 dimensions yield no uncovered relevant boundary, and each accepted GATE-REVIEW finding is represented exactly once.

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

@@ -1,11 +1,11 @@
 ---
 name: cf:sync
-description: "Synchronize process-first task Status and inline Receipts without inventing proof; also preserves existing legacy Specs state."
+description: "Synchronize process-first task Status and inline Receipts without inventing proof."
 user-invocable: true
 when_to_use: "Invoke after implementation or verification changes a task's real state, or to audit a feature packet for drift."
 category: utilities
 keywords: [sync, state, tracking, consistency]
-argument-hint: "<feature> <task-file> <pending|in_progress|paused|blocked|done|sync-finalize> [blocker] | audit <feature>"
+argument-hint: "<feature> <task-file> <pending|in_progress|paused|blocked|done|sync-finalize> [blocker] | audit <feature> | rebind <feature> [task-file] | (none: audit all, write nothing)"
 metadata:
   author: haposoft
   version: "3.0.0"
@@ -24,6 +24,8 @@ state. Never infer proof, approval, review independence, or product readiness.
 /cf:sync <feature> <task-NN-slug.md> done
 /cf:sync <feature> <task-NN-slug.md> sync-finalize
 /cf:sync audit <feature>
+/cf:sync rebind <feature> [<task-NN-slug.md>]
+/cf:sync
 ```
 
 Resolve one regular direct-child task inside `specs/<feature>/`. Reject path
@@ -59,21 +61,12 @@ 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.
 
-Repair deterministic formatting drift only. A semantic conflict, missing
-evidence, or ownership decision requires user or implementation input; do not
-pick a winner. After any edit, report exact files changed and unresolved items.
-
-Read `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.
-
-## Legacy workflow compatibility
-
-If `specs/<feature>/spec.json` exists, use the legacy adapter instead: preserve
-its machine authority, `task_registry`, nested `tasks/task-R*.md`, timestamps,
-typed topology, separate receipts, `workflow_policy`, `planning_depth`, lane,
-and `execution_tier`. Keep JSON and Markdown synchronized, retain the exact
-legacy sync-finalize contract, and require its feature receipt at closeout.

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

@@ -0,0 +1,59 @@
+# Rebind, bare call, and the changed-files report
+
+Read this before a rebind, a call without arguments, or any report of files
+changed. Every rule here exists because a past sync run broke it.
+
+## Snapshot first
+
+Before the first edit, record `git status --porcelain -uall` and the sha256 of
+every path it lists. A file that was already modified is not yours to claim.
+
+## Rebind
+
+`/cf:sync rebind <feature> [<task-NN-slug.md>]` refreshes the Receipt of tasks
+that are already `done`. Any other Status is reported and not written.
+
+1. Take each task's Command exactly as the validator does: the last top-level
+   `- Command:` of its Verification Plan before the first `###` sub-heading,
+   or, when there is none at top level, the last `- Command:` under the
+   sub-headings. That one Command is the one you run and write.
+2. Run every selected Command verbatim, each once as one shell, so stdout,
+   stderr and the exit code cover the whole command. Never pipe it through
+   `| tail`, never redirect only its last `&&` link to a log, never edit it.
+3. A Command that exits non-zero, prints a failure marker, or runs zero
+   required tests never yields PASS. Set `Status: blocked` and, right under
+   the `Status:` line, add one line
+   `Blocker: rebind <date>: <Command> exited <code> (<failing test line>)`;
+   keep the old Receipt, and put this line directly under its `## Receipt`
+   heading:
+   `Not current proof: the rebind run of this Command exited <code>; the record below is historical.`
+4. After all Commands have run, run the provenance command once, exactly as
+   Develop names it:
+   `node .claude/scripts/provenance.cjs --project-root . --specs-root specs --spec-file <task file> --feature-name <feature> --session <any label> --json`
+   Copy its `Base` and `Head` fields into each passing Receipt. Never type,
+   compute, shorten, or `sed`-edit Base or Head, and never write a Receipt
+   from output that a run in this call did not print.
+5. Run the provenance command again. If Head moved, say so and do not claim
+   the receipts current.
+6. Re-read each edited task: exactly one `Status:` and one `## Receipt`.
+
+## Never silence the gate
+
+A Stop-gate block is answered with fresh evidence or with a reported blocker.
+Never archive, move, rename, or delete a packet, change the specs root, or edit
+`.claude/` (including `runtime.json`) or any hook so the gate goes quiet.
+
+## 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
+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.
+
+## Report files from git
+
+After the last edit, take the snapshot again and report every path whose
+status line or sha256 changed. List changes that were already there before the
+first edit apart from your own. Never write "no files changed" from memory.

package/src/claude/skills/sync/references/sync-protocols.md

@@ -40,23 +40,14 @@ provenance, and path or artifact mismatch.
 
 - Plan row without task file: report missing; do not synthesize scope.
 - Task file without plan row: report unknown; do not silently adopt it.
-- Done without valid Receipt: downgrade only when the repair is deterministic,
-  otherwise block and request direction.
+- Done without valid Receipt: after the user confirms, downgrade when the repair is deterministic,
+  otherwise report and request direction.
 - Receipt on unfinished task: preserve it only if it is clearly historical;
   otherwise report the conflict.
-- Missing or cyclic dependency: block affected tasks.
-- Overlapping write ownership in one proposed wave: serialize or request an
+- Missing or cyclic dependency: report; block affected tasks only after the user confirms.
+- Overlapping write ownership in one proposed wave: report and request an
   ownership decision.
 - Acceptance ID not mapped both ways: report traceability drift.
 
 After a repair, re-read every changed file and print a concise mismatch/fix/
 unresolved summary. Never claim execution proof from the audit itself.
-
-## Legacy workflow compatibility
-
-For `spec.json` packets, resolve exact `task_registry` paths and synchronize
-registry timestamps plus nested task Markdown. Validate the canonical separate
-receipt (with legacy inline Evidence only as the supported fallback), reject
-conflicting proof identities, preserve classified minimum and planning_depth,
-and use the installed legacy policy for lane, execution_tier, Flash promotion,
-and final feature closeout.

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

@@ -87,10 +87,19 @@ For a process-first feature:
 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. Inspect negative paths, runtime reachability, and declared artifacts.
-5. Capture tracked, untracked, and ignored project-command drift separately
+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.
-6. Redact sensitive material, validate the complete proof object, then return a
+7. Redact sensitive material, validate the complete proof object, then return a
    concise human report separately from the machine handoff.
 
 Required proof follows the behavior:
@@ -165,6 +174,16 @@ 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