@haposoft/cafekit 0.16.0-rc.5 → 0.16.0-rc.7

package/src/claude/skills/develop/references/parallel-waves.md

@@ -1,194 +1,107 @@
-# Parallel Waves — hapo:develop `--parallel` operating procedure
-
-Normative protocol for executing independent spec tasks concurrently. Loaded by
-`develop/SKILL.md` when Full-Spec mode runs with `--parallel [N]`. Verified against
-live worktree-subagent behavior (spec `develop-parallel-wave`,
-`reports/worktree-spike.md`, 2026-07-19).
-
-## 1. Preconditions (check before anything else)
-
-1. `.claude/runtime.json` → `develop.parallel` is not `false` (escape hatch; missing
-   key = allowed). If `false`: refuse `--parallel`, tell the user the hatch is active
-   and which key controls it, then run the standard sequential loop.
-2. The work context is a git repository and worktree isolation is available.
-   Otherwise: state the reason ("not a git repo" / "isolation unavailable") and run
-   the standard **sequential fallback**.
-3. `--parallel N`: **wave cap** = N clamped to 1..5; default 3. Never exceed 5 —
-   each subagent carries a ~200K context budget (orchestrator.md resource rule).
-4. The destination tree must be clean (`git status --porcelain` is empty) and
-   compatible with the selected base before dispatch. Record the destination
-   `base_sha` and stop without mutation when cleanliness, repository, or base
-   compatibility checks fail.
-5. Before dispatch, state whether `--parallel` consent authorizes worker commits
-   and orchestrator cherry-picks. If that consent is not explicit, obtain the
-   separate confirmation before creating worktrees or asking workers to commit.
-
-### Receipt contract (required per wave/task)
-
-Every task and wave receipt records these exact fields:
+# Parallel waves — `hapo:develop --parallel`
+
+Load this reference only for explicit parallel execution. The goal is bounded
+concurrency with immutable provenance and one state writer.
+
+## Preconditions
+
+1. Confirm the work context is a Git repository and worktree isolation is
+   available. Otherwise state why and fall back to the sequential loop.
+2. Respect `.claude/runtime.json` `develop.parallel: false` when present.
+3. Clamp `--parallel N` to 1..5; default to 3.
+4. Require a clean destination and record its exact `base_sha`. Stop without
+   mutation if cleanliness or base compatibility fails.
+5. Confirm whether the user's parallel consent also authorizes worker commits
+   and controller cherry-picks before creating worktrees.
+
+Every task receipt for a wave records:
 
 ```text
 base_sha: <destination commit before dispatch>
-head_sha: <latest worker/integration commit>
+head_sha: <worker or integrated commit>
 branch: <worker branch>
-worktree_path: <retained or merged worktree path>
+worktree_path: <path>
 commit_range: <base_sha>..<head_sha>
 retention: retained|released
 cleanup_authorization: pending|explicit-discard|merged-release
 ```
 
-Reviewer and tester commands MUST inspect `git diff <base_sha>..<head_sha>` (or
-`git diff --stat <base_sha>..<head_sha>`), never an ambient working-tree diff.
-Every fix is a new commit: advance `head_sha`, replace `commit_range`, and rerun
-only affected gates plus the wave integration check. A receipt without these
-fields is incomplete.
+Test and review commands inspect `git diff <base_sha>..<head_sha>`, never an
+ambient working-tree diff. A fix creates a new commit and advances Head.
 
-## 2. Wave planning (normative)
-
-```
-ready(t) = t.status == "pending" AND every dep in task_registry[t].dependencies
-           has status == "done"
-candidates = ready tasks in task_registry order
-wave = first ≤cap candidates, EXCLUDING any task that conflicts with an
-       earlier task already in the wave under the conflict graph below
-```
+## Build a wave
 
-**Conflict graph.** A pair conflicts when either task writes the same exact file,
-one writes a directory another writes, or either touches a shared mutable surface:
-lockfiles, manifests/export barrels, migrations/registries, generated artifacts,
-or shared state writers. `Create`/`Modify`/`Delete` rows are writers; `Read` rows
-are still conflicts when they consume a mutable generated or registry surface.
-Normalize paths before comparison. If overlap is uncertain, classify it as a
-conflict and defer the task to the sequential fallback; never guess that two
-writers are independent.
+Read dependencies from the plan task table and each flat task's
+`## Dependencies`. A candidate is ready only when all named dependencies are
+done with valid Receipts.
 
-**Single writer per file per wave** remains absolute. Read-only tasks can still
-be deferred when they inspect a directory or shared generated state that a sibling
-writes.
+Add ready tasks in plan order up to the cap, excluding a task when it shares a
+write target with an earlier task or touches the same mutable registry,
+lockfile, manifest, generated output, migration, or export barrel. Normalize
+paths. Uncertain overlap is a conflict, not an invitation to guess.
 
-If the wave is empty but pending tasks remain, dependencies or conflicts are
-unsatisfiable in parallel — finish them with the sequential loop and say so.
+One file has one writer per wave. If no safe wave remains, use the sequential
+loop and state the dependency or ownership conflict.
 
-### Worked example
+## Dispatch
 
-Registry: A (deps: –), B (deps: –), C (deps: A), D (deps: – but shares
-`src/api/users.ts` Modify with B). Cap 3.
+Each worker receives the complete task packet, work context, exact owned paths,
+acceptance, Verification Plan, dependencies, and these constraints:
 
-- Wave 1 = A, B (D excluded: path collision with B; C excluded: dep on A)
-- Wave 2 = C, D (A done unblocks C; B done releases D's path)
+1. Work only in the assigned isolated worktree.
+2. Do not edit `plan.md`, task Status, or `## Receipt`; the controller owns
+   state and evidence synchronization.
+3. Do not touch a path outside granted ownership or undo another worker's edit.
+4. Run task-local prechecks and report exact commands and exits.
+5. Commit only when the user's authorization covers worker commits.
+6. Return status plus branch, worktree, Base, Head, range, and retention.
 
-## 3. Dispatch (one implementer per wave task)
+A blocked or failed worker keeps its identifiable worktree and branch. Never
+force-delete it without merge success or explicit discard authorization.
 
-Every dispatch uses worktree isolation + background execution and a
-self-contained prompt per `rules/orchestrator.md` (task file content, design and
-requirements excerpts, work-context/specs/docs paths, acceptance criteria) plus
-these mandatory lines:
+## Verify before integration
 
-1. "You are in an isolated git worktree. Implement ONLY this task."
-2. "Do NOT edit `spec.json` or any `tasks/*.md` — the orchestrator owns spec state."
-3. "Write only exact targets granted by this task's `Anchors and Ownership`
-   table and typed ownership/parallel boundaries."
-4. "When done, `git add` your changes and `git commit -m \"task(<id>): <title>\"` —
-   an uncommitted worktree cannot be merged."
-5. End with the standard `Status: DONE|CONCERNS|BLOCKED|NEEDS_INFO` block, plus
-   the receipt fields from §1, including worktree path, branch, and commit range.
-6. If a worker fails or blocks, do not remove its worktree or delete its branch.
-   Mark `retention: retained` and `cleanup_authorization: pending` until merge
-   succeeds or the user gives explicit discard authorization.
+Inside each worktree, run the task's proof through `quality-gate.md` against the
+immutable commit range. A task with missing proof, overlap, or unresolved High
+or Critical finding is not eligible to integrate. Three failed repair rounds
+collapse only that task; siblings may finish but do not erase its blocker.
 
-The orchestrator records `base_sha` immediately before dispatch. The worker's
-first accepted commit becomes `head_sha`; no receipt may use a moving ambient
-HEAD as a substitute. The Agent result returns `worktreePath` and
-`worktreeBranch`; record both in the receipt.
+## Integrate sequentially
 
-## 4. Quality gate — inside the worktree, before merge
-
-Run the unchanged Stage A + Stage B gate (`references/quality-gate.md`) per task
-**with the task's worktree as working directory**. Before reviewing, tester and
-reviewer commands must inspect the receipt's immutable range:
+Apply accepted worker commits one at a time in plan order:
 
 ```bash
-git diff --stat "$BASE_SHA..$HEAD_SHA"
-git diff "$BASE_SHA..$HEAD_SHA"
+git cherry-pick <worker-commit>
 ```
 
-Do not replace this range with `git diff`, `git status`, or another ambient
-working-tree view. Gate evidence from that run feeds the task receipt. Three
-failed rounds → COLLAPSE protocol for that task only; sibling tasks in the wave
-keep running. Any fix creates a new commit and updates `head_sha`/`commit_range`
-before affected gates rerun.
+On conflict, abort the cherry-pick, mark the task blocked, and retain its
+worktree/branch. After success, update the receipt range to the integrated Head.
+Release a worktree only after recording `cleanup_authorization: merged-release`.
 
-## 5. Merge protocol (spike-verified — do not improvise)
+## Post-merge proof
 
-⚠️ Spike finding: worktree branches are based on **`origin/<default-branch>`**
-(`worktree.baseRef: "fresh"` default), NOT the session HEAD. On repos whose origin
-default diverges, `git merge <agent-branch>` explodes into unrelated conflicts.
+After the wave's last integration, run an affected integration command derived
+from the tasks and repository contract. Record command, exit, Base, Head,
+range, and output. Failure blocks the next wave.
 
-Therefore, for each gate-passed task, sequentially (one at a time, registry order):
+Classify a failure before acting:
 
-```bash
-git cherry-pick <agent-commit>       # base-agnostic: applies only the agent's diff
-# conflict? → git cherry-pick --abort
-#   → task_registry[task].status = "blocked", blocker = one-line conflict summary
-#   → retain the worktree/branch; receipt says retention=retained
-```
+- `baseline`: reproduces from the recorded Base;
+- `environment`: required tool, service, permission, or dependency unavailable;
+- `spec`: acceptance or evidence contract is wrong or incomplete;
+- `code`: implementation or integration regression.
 
-A successful merge may release the worktree and branch only after the receipt
-records `head_sha` at the merge result, the new `commit_range`, and
-`cleanup_authorization: merged-release`:
+Do not blind-retry. Fix code/spec with a new commit and rerun affected proof;
+record baseline/environment as blockers.
 
-```bash
-git worktree remove .claude/worktrees/agent-<id>
-git branch -d worktree-agent-<id>
-```
+After the final wave, run the feature-level integration and reachability proof.
+The controller then writes inline Receipts and Status updates one task at a
+time. Worker reports are evidence inputs, not permission to claim done.
+
+## Legacy workflow compatibility
 
-Never use `--force` cleanup for failed or blocked work. Retain its identifiable
-worktree and branch for inspect/resume until the merge succeeds or the user
-explicitly authorizes discard; record `cleanup_authorization: explicit-discard`
-when that happens. Optionally set `worktree.baseRef: "head"` in settings;
-cherry-pick remains the recipe regardless.
-
-## 6. Post-merge integration check (per wave)
-
-After the wave's last cherry-pick, run an affected integration command derived
-from the task's `Verification Plan` and repository contract (build or affected test
-subset; never the full suite mid-flight). Record command, `base_sha`, `head_sha`,
-range, and result in the wave receipt. Failure blocks the next wave.
-
-After the final wave, run an explicit feature/full integration command derived
-from the repository contract — for example the feature's exact verification suite
-or the repository's documented full test/build command. A final scout is not a
-substitute. On PASS, the test owner creates `feature-receipt.md` once; task
-receipts alone cannot close the feature. Classify every failure before acting as exactly one of:
-
-- `baseline` — reproduces from the recorded destination `base_sha`;
-- `environment` — tool, dependency, permission, or service unavailable;
-- `spec` — requirement, acceptance, or evidence contract mismatch;
-- `code` — implementation or integration regression.
-
-Do not blind-retry. Fix `code`/`spec` failures with a new commit and affected
-gates; record `baseline`/`environment` blockers and escalate or use the
-sequential fallback according to the task contract.
-
-## 7. State sync — orchestrator is the single writer
-
-Only the orchestrator writes `spec.json` and task markdown, after each task's
-cherry-pick: registry `status`/`completed_at`/`last_updated_at`, task-md `Status`,
-checkbox ticks, and a canonical `receipts/<task-basename>.md` citing the
-worktree gate evidence plus the post-merge check result. Never append execution
-proof to task Markdown. The Stop completion gate (`spec-gate.cjs`) applies
-unchanged — a receipt-less done blocks the turn. After syncing the wave, recompute
-§2 and continue until no pending tasks remain.
-
-## 8. Failure summary
-
-| Event | Action |
-|---|---|
-| Escape hatch on / not a git repo / no isolation | Sequential fallback + stated reason |
-| Same-wave path collision | Defer the later task to next wave (§2) |
-| Gate fails 3× for a task | COLLAPSE for that task; retain worktree/branch and receipt; wave continues |
-| Worker failure or blocked task | Retain identifiable worktree/branch; no force-remove; classify and await resume or explicit discard |
-| Cherry-pick conflict | Abort pick; task `blocked` + conflict blocker; retain worktree/branch; wave continues |
-| Post-merge check fails | Classify baseline/environment/spec/code; no next wave until resolved or explicitly blocked |
-| Final integration fails | Record failure class and stop; do not claim completion from a final scout |
-| Empty wave, tasks pending | Sequential loop for the remainder + notice |
+For an existing `spec.json` feature, readiness and dependencies come from the
+persisted `task_registry` and typed `coordination.boundaries`. Workers still do
+not edit that state. The controller writes the legacy separate task receipt,
+synchronizes registry plus nested task Markdown, and creates the required final
+feature receipt only after integrated proof.

package/src/claude/skills/develop/references/quality-gate.md

@@ -1,99 +1,71 @@
-# Quality Gate — one closeout, separate proof and review
+# Quality gate — one closeout, separate proof and review
 
-This reference is loaded at develop closeout. It is an executable contract, not
-a fixed actor checklist. Canonical v2.1 policy input is authoritative; lane and
-`execution_tier` are derived/read-only compatibility views.
+Load this reference when closing a task or direct change. It defines ownership
+and evidence, not a fixed agent sequence.
 
-## Inputs and ownership
+## Ownership
 
-The single closeout owner receives the current scope, assurance, risk signals, blast
-radius, exact evidence commands, and the current diff. It calls the test owner
-once, then the review owner once when required. No parallel path, review path,
-or sync hook runs a duplicate hidden gate.
+- **Test owner:** executes the named commands and is the sole producer of
+  execution proof.
+- **Review owner:** evaluates correctness, security, scope, and reachability;
+  consumes proof but never creates it.
+- **Closeout owner:** normalizes both results, writes the task Receipt and
+  Status, and reports docs impact.
 
-- **Test owner:** executes commands and creates the canonical execution receipt.
-- **Review owner:** evaluates correctness, security, scope, and spec compliance;
-  consumes the receipt but never creates or claims execution proof.
-- **Closeout owner:** combines both results and performs one state/docs sync.
+Use `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`. Only literal PASS plus all
+required proof can close. Review depth follows risk, blast radius, and repository
+policy, not file count.
 
-Review depth follows assurance, risk, and blast radius, not the number of files or
-tasks. There is no fixed Light/Standard/Deep agent sequence. The shared verdict
-surface is `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`; all adapters must use
-the same normalizer.
-
-## Working directory (parallel mode)
-
-When an opt-in wave is active, each command runs in its task worktree. A
-collapse of one task does not cancel other in-flight tasks; merge and state
-synchronization remain single-writer operations.
-
-## Required evidence
+## Required proof
 
 Before completion, verify:
 
-1. compile/typecheck precheck and every exact command named by the active
-   `Verification Plan`;
-2. real runtime reachability and declared artifact inspection;
-3. canonical `receipts/<task-basename>.md` with task identity/path, non-empty
-   exact command, successful exit/result, expected versus observed behavior,
-   applicable negative/reachability proof, both provenance anchors bound to the
-   runtime's expected Base/Head pair, and required SHA-256 declarations;
-4. correctness/security/spec review at the selected depth;
-5. a real independent audit when `needsIndependentAudit` is persisted. The
-   audit must use schema version `1`, distinct reviewer and implementation
-   session IDs, matching expected Base/Head binding, concrete evidence, and
-   literal `verdict: "PASS"`.
-
-`PRECHECK_FAIL` outranks no-tests. Missing, pending, marker-only, contradictory,
-or placeholder proof is unfinished. `Audit: PASS` is not an independent audit.
-`NO_TESTS` may be retained as a legacy diagnostic input, but it can never become
-the shared completion verdict `PASS`.
+1. applicable compile/typecheck and every exact task command;
+2. at least one real test when automated tests are required;
+3. runtime reachability through the declared entrypoint or consumer;
+4. negative/failure behavior named by Acceptance;
+5. artifact bytes and SHA-256 when the task declares an artifact;
+6. an inline `## Receipt` with `Verification: PASS`, exact `Command`, `Exit: 0`,
+   runtime-bound Base/Head, and non-empty fenced command output;
+7. correctness/security/scope review at the required depth.
 
-## Spec compliance review
+`PRECHECK_FAIL` outranks no-tests. Missing, pending, placeholder, contradictory,
+zero-test, stale, copied, or marker-only proof is unfinished. A review PASS
+cannot replace execution evidence.
 
-Check scope lock, requirements, design contracts, task Acceptance, Verification
-Plan, runtime reachability, and artifact/provenance boundaries. A missing or orphaned
-runtime deliverable is a failure even when compilation succeeds.
+## Review focus
 
-**Specific-task mode:** review exactly the requested task and its diff, then
-stop. Do not select a next task.
+Check task Outcome, Scope, Acceptance, Dependencies, Verification Plan, changed
+diff, and actual consumers. Treat an unmounted UI, unregistered route, uncalled
+service, disconnected worker, missing export, or unconsumed artifact as a
+reachability failure even when compilation passes.
 
-**Full-feature mode:** use the cumulative feature scope only at its closeout;
-intermediate synchronization does not claim feature completion. Run the Final
-Integration Scout when runtime-facing surfaces exist.
+Apply security checks relevant to the touched boundary: auth and tenant scope,
+input validation, secret redaction, path containment and symlinks, atomic writes,
+concurrency, cleanup, and safe error behavior. Do not add unrelated ceremony.
 
-## Correctness and security review
+Specific-task mode reviews only that task and stops. Full-feature mode uses
+cumulative scope only for the final integration check.
 
-Apply only the checks relevant to the touched boundary. For logging/redaction,
-check safe identifiers, quoted schemes, idempotence, and receipt secrecy. For
-filesystem writes, check lexical and canonical containment, symlink rejection,
-atomic same-directory replacement, cleanup, and canonical return paths. Add
-auth, persistence, provider, or concurrency checks only when scope/risk requires.
-
-## Quality cycle
+## Repair cycle
 
 ```text
-retry_count = 0
-while closeout is not PASS:
-  test owner executes required proof once
-  if proof is BLOCKED: stop without blind retry
-  review owner evaluates correctness/security/spec once
-  if FAIL: fix only the affected scope and rerun affected proof/review
-if retry_count reaches 3: stop and request user intervention
+test owner runs required proof once
+if BLOCKED: record prerequisite and stop
+if FAIL: repair the observed cause and rerun affected proof
+review owner evaluates the proven diff once
+if review FAIL: repair affected scope and rerun affected proof/review
+after three failed repair rounds: stop and request user direction
 ```
 
-Only `FAIL` enters remediation. `BLOCKED` is terminal until its prerequisite
-changes. `PASS_WITH_WARNINGS` is a review result only and remains unfinished;
-only literal `PASS` may close when all execution and policy obligations are
-complete.
-
-## Flash Gate (`--flash`)
+`PASS_WITH_WARNINGS` may report non-blocking observations but remains
+unfinished for state synchronization. Never retry an unchanged environment to
+manufacture a green result.
 
-Use only when the flag is explicit. Skip dedicated tests, full evidence
-execution, extended UI/manual checks, and review retry loops. Still perform a
-cheap preflight and scope/reachability sanity check.
+## Flash gate
 
-The flash record must contain exactly the unfinished semantics:
+With explicit `--flash`, run only a cheap available preflight and a basic
+scope/reachability check. Record:
 
 ```text
 Mode: --flash
@@ -101,54 +73,22 @@ Tests: skipped by user request
 Evidence: FLASH_UNVERIFIED
 Status: in_progress
 Blocker: awaiting /hapo:test <feature>
-Next verification: /hapo:test <feature>
-```
-
-The persisted flash input must also contain `dependencyBlocked: true`,
-`unblocks: false`, and a non-placeholder blocker, and must omit
-`readyForSync`, `flashTransition`, and `promotionReceipt`. Sync-finalize
-rejects minimal or caller-pre-promoted states.
-
-Terminal log:
-
-```text
-⚡ Step 4 Flash Gate: tests skipped by --flash; preflight=<pass|skipped>; evidence=FLASH_UNVERIFIED
 ```
 
-Do not report `Test PASS`, `Evidence PASS`, `Auto-Approved`, or
-`production-ready`. Flash never sets `done`, unblocks dependents, or promotes
-from a marker. Trusted sync-finalize alone may consume a fresh canonical PASS
-receipt and derive promotion.
-
-## Closeout and docs impact
-
-After the test receipt and review verdict are both available, the closeout owner
-uses the policy adapter and synchronizes state. A review-only pass cannot close
-missing execution proof. Evaluate docs impact from the actual behavior change:
-
-- `none`: record no docs edit and stop;
-- `minor` or `major`: update only affected existing docs through the normal docs
-  workflow.
-
-Do not run a docs checkpoint merely because a task completed. Do not refresh the
-whole repository for a local change.
-
-After every task receipt is valid, final integration execution creates
-`feature-receipt.md` once. A task-bearing feature cannot close without all task
-receipts and the feature receipt. A taskless Compact/Full feature closes from a
-valid feature receipt; absence before final closeout is not a failure. Receipts
-never supply or imply approval, readiness, audit status, or product semantics.
+Flash does not write a PASS receipt, mark done, unblock dependents, or report
+production readiness. Trusted sync-finalize may promote only after fresh proof
+passes the same receipt contract above.
 
-## Review threshold
+## Docs impact and C3
 
-`PASS` requires no Critical or High correctness/security/spec finding and no
-blocking Medium finding. `PASS_WITH_WARNINGS` may carry documented non-blocking
-findings. Finding count never selects review depth or overrides missing proof.
-Any missing proof, unresolved obligation, scope drift, contract substitution, or
-reachability failure remains unfinished regardless of review severity.
+After proof and review, classify docs impact as `none`, `minor`, or `major`.
+Update only affected existing docs when impact is not none. Show the user the
+current command evidence and limitations at C3; do not infer approval from a
+receipt.
 
-### Reachability Failure
+## Legacy workflow compatibility
 
-An unmounted UI, unregistered route, uncalled service/loader, disconnected
-worker/command/provider/reducer, missing artifact consumer, or other orphaned
-runtime-facing output is a review failure.
+Existing kernel packets keep their separate `receipts/<task-basename>.md`, task
+identity/path metadata, final `feature-receipt.md`, persisted independent-audit
+obligations, and completion-authority checks. The same proof/review ownership
+applies. Do not copy that storage shape into a flat process-first task.

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

@@ -1,51 +1,44 @@
 # Capability dispatch patterns
 
-This reference is optional. Load it only when the persisted lane requires
-independent capability work. Role names are runtime configuration, not workflow
-policy: resolve them from the installed catalog instead of hardcoding an actor
-name or a sequence in a skill.
+Load this optional reference only when a task benefits from independent
+inspection, implementation, verification, review, or docs capability. Runtime
+role names are configuration, not workflow policy.
 
-## Dispatch contract
+## Dispatch packet
 
-Every dispatch prompt includes:
+Every dispatch includes:
 
-- Work context: the git root of the primary files;
-- Reports path: `<work-context>/plans/reports/`;
-- Plans path: `<work-context>/plans/`;
-- exact task/scope and owned files;
-- lane snapshot, risk/blast-radius obligations, and stop conditions;
-- required output, evidence, and status.
+- work context and reports/plans paths;
+- exact task outcome, scope, acceptance, and dependencies;
+- owned read/write paths and explicit exclusions;
+- risk, blast radius, stop conditions, and required evidence;
+- expected status and handoff format.
 
-Use a capability request such as:
-
-```text
-dispatch(capability="inspection|implementation|verification|review|docs",
-  work_context="<root>",
-  scope="<task or feature>",
-  owned_files=["<paths>"],
-  obligations=["<persisted obligations>"],
-  output="<required packet and evidence>")
-```
-
-The runtime may map a capability to a local role. That mapping must not change
-the lane, add ceremony, or become a new persisted policy field.
+Use one capability per concrete responsibility. The runtime may map it to an
+available local role, but that mapping cannot add scope or weaken proof.
 
 ## Independence and ownership
 
-- Inspection may report entrypoints and blast radius but does not edit source.
-- Implementation edits only the active task scope and does not sync state.
-- Verification is the sole producer of canonical execution proof.
-- Review consumes proof and reports correctness/security/spec findings only.
-- Documentation work is invoked only after a real docs-impact decision.
+- Inspection traces entrypoints and risks without editing source.
+- Implementation edits only granted paths and does not write task state.
+- Verification is the sole producer of executable proof.
+- Review consumes proof and reports findings without claiming execution.
+- Documentation starts only after a real docs-impact decision.
+- The controller alone writes Status and inline Receipt.
 
-Specific-task mode ends after one task. Full-feature mode may continue only
-after the closeout owner synchronizes the current task and finds another
-unblocked task. A capability result marked `PENDING`, `BLOCKED`, or lacking
-provenance cannot be converted into PASS by the controller.
+A specific-task invocation ends after that task. Full-feature execution may
+continue only after the current task is synchronized and the next dependency
+set is recomputed.
 
 ## Safe fallback
 
-If the required capability or isolated workspace is unavailable, keep the
-workflow in `BLOCKED` or run the permitted main-session check. Do not substitute
-a model, profile, or actor silently, and do not claim an independent result
-without an actually independent execution.
+If a required capability or isolated workspace is unavailable, record BLOCKED
+or run only a permitted main-session check. Never silently substitute an actor
+for an independence requirement. A PENDING, BLOCKED, or provenance-free result
+cannot be normalized to PASS.
+
+## 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.

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

@@ -73,7 +73,7 @@ If `unclear`, ask one focused follow-up with the minimum choices needed.
 
 Repo evidence priority:
 1. `README.md`, `AGENTS.md`, `CLAUDE.md`
-2. relevant `docs/`, `specs/`, `.claude/`, `.opencode/`
+2. relevant `docs/`, `specs/`, `.claude/`
 3. source files, tests, scripts, package manifests, config files
 4. git history only when the question asks about changes or provenance