@haposoft/cafekit 0.16.0-rc.3 → 0.16.0-rc.4

package/src/claude/settings/settings.json

@@ -124,6 +124,10 @@
     "SubagentStop": [
       {
         "hooks": [
+          {
+            "type": "command",
+            "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/semantic-review-authority.cjs\""
+          },
           {
             "type": "command",
             "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/state.cjs\""

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

@@ -23,7 +23,8 @@ With no argument, review the pending diff. Supported targets are a PR, commit,
 pending changes, or an explicit path. Load only the spec and references needed
 for the target.
 
-Select review depth from the persisted lane, risk, and blast radius:
+Select review depth from `assurance_level`, risk, and blast radius. Lane is a
+derived view:
 
 - Direct: targeted correctness/security/spec check;
 - Standard: bounded feature review at closeout;
@@ -38,7 +39,9 @@ fixed Light/Standard/Deep sequence.
 ### 1. Specification compliance
 
 Compare the diff with `scope_lock`, requirements, design contracts, active task
-criteria, and declared runtime reachability. Identify missing behavior,
+Outcome/Scope/Anchors and Ownership/Changes/Acceptance/Dependencies/
+`Verification Plan`, typed `coordination.boundaries`, and declared
+runtime reachability. Identify missing behavior,
 unjustified extras, contract substitution, orphaned outputs, and incorrect
 completion claims. If a design image or document carries requirements, load its
 multimodal reference only when needed; do not guess from a filename.
@@ -73,6 +76,12 @@ closeout to the test owner; do not claim PASS on the feature from review alone.
 A review can still return a correctness verdict when its review inputs are
 complete.
 
+For new tasks, read proof from `receipts/<task-basename>.md`; use legacy task
+`## Evidence` only as fallback. If both exist and their proof identities
+conflict, fail closed. At feature closeout also consume `feature-receipt.md`.
+Receipt validity never supplies approval, readiness, audit status, or product
+semantics.
+
 ## Verdict
 
 Use the shared adapter surface exactly:
@@ -94,7 +103,7 @@ decision is unavailable.
 
 **Verdict:** PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED
 **Target:** [PR | Commit | Path]
-**Lane / risk:** [snapshot and relevant signals]
+**Assurance / risk:** [canonical policy input and relevant signals]
 **Execution proof:** consumed | unavailable (owned by hapo:test)
 
 ## Findings

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

@@ -23,11 +23,19 @@ Do not attempt a standard text-based review if the project includes Visual Specs
    - *Prompt:* "Hey `hapo:ai-multimodal`, please look at this design mockup/document and compare it with the layout/logic described in this Code. Are there any discrepancies?"
 3. If NO (Markdown Spec only): Read the spec directly and extract:
    - requirement bullets
-   - task `Completion Criteria`
-   - task `## Evidence` (legacy heading aliases still parse)
+   - task `Outcome`, `Scope`, `Anchors and Ownership`, `Changes`, `Acceptance`,
+     `Dependencies`, and `Verification Plan`
+   - typed `coordination.boundaries` as the only ownership/DAG/proof/parallel authority
+   - task `Verification Plan`
    - canonical contracts/invariants from `design.md`
    Then verify the changed files against those concrete obligations.
 
+Execution proof is separate from the task plan. Consume
+`receipts/<task-basename>.md` first and legacy `## Evidence` only as fallback;
+conflicting proof identities fail closed. At final integration, consume
+`feature-receipt.md`. Review never creates either receipt and never treats a
+receipt as approval, readiness, audit status, or semantic judgment.
+
 ## 3. Verdict Scale
 
 Each Requirement in the Spec must return 1 of 3 states:

package/src/claude/skills/code-review/references/verification-gate.md

@@ -27,6 +27,19 @@ To clear the Verification Gate, you must cite one of the following concrete proo
 - **Linter Completion:** Output proving no syntax errors exist.
 - **Multimodal Visual Evidence:** `hapo:ai-multimodal` confirming that the visual rendering perfectly matches the design layout.
 
+For Specs v2, accepted proof must be persisted by the test owner at
+`receipts/<task-basename>.md`; legacy `## Evidence` remains fallback-only. The
+receipt includes identity/path, exact command, exit/result, expected versus
+observed behavior, applicable negative/reachability/artifact proof, and bound
+Base/Head. Final integration uses `feature-receipt.md`. Missing final receipt is
+normal before closeout, but mandatory at closeout. Neither receipt grants
+approval, readiness, audit status, or product semantics.
+
+For v2.1, the semantic receipt is reviewed input, not execution proof. It binds
+exact criteria and counterexamples shaped as `criterion`, `case_kind`,
+`scenario`, `expected`, `decision_refs`, and `verification_ref`. Deterministic
+validator success is never a semantic-review verdict.
+
 ## 4. How to Handle Missing Proof
 If you are asked to review a PR or commit and no execution proof is available:
 1. **Return `BLOCKED`** and name missing commands, artifacts, permissions, or environment access.

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

@@ -1,6 +1,6 @@
 ---
 name: hapo:develop
-description: "Implement an approved or explicitly low-risk change with lane-proportional evidence and one closeout owner."
+description: "Implement an explicitly invoked ready or low-risk change with policy-proportional evidence and one closeout owner."
 user-invocable: true
 when_to_use: "Use to implement a ready spec, a specific task, or a Direct low-risk change."
 category: utilities
@@ -12,9 +12,12 @@ metadata:
 ---
 # Develop — implementation and closeout contract
 
-Implement the requested scope, then close it with one canonical execution owner. Keep the lane, not a legacy tier or fixed actor sequence, as authority.
-
-The executable policy source is `src/claude/scripts/workflow-policy.cjs`; the persisted workflow-policy snapshot is the contract (installed as `.claude/scripts/workflow-policy.cjs`). It owns `workflow_policy`, escalation, approvals, verdict adaptation, receipt validation, and flash promotion.
+Implement the requested scope, then close it with one canonical execution owner.
+For a durable spec, `spec.json` is machine authority and Markdown is a human
+projection. The v2.1 policy snapshot persists minimum input; lane, label,
+artifact profile, and ceremony are derived views. The executable policy source
+is `src/claude/scripts/workflow-policy.cjs` (installed as
+`.claude/scripts/workflow-policy.cjs`).
 
 ## Usage and pre-state guard
 
@@ -43,7 +46,12 @@ Remediation: run `/hapo:develop <feature> --flash` or `/hapo:develop <feature> -
 No spec state, task receipt, worktree, subagent, or commit was created.
 ```
 
-## Lane authority
+## Policy authority
+
+For durable specs, persisted `workflow_policy` authority is the v2.1 minimum.
+Canonical authoring supplies `planning_depth`, `assurance_level`,
+`classified_minimum`, and normalized `risks`; lane and ceremony remain derived
+views.
 
 Classify before spec/state mutation:
 
@@ -51,45 +59,35 @@ Classify before spec/state mutation:
 node .claude/scripts/workflow-policy.cjs --classify-lane --task-json '<task JSON>' --json
 ```
 
-- **Direct**: clear, isolated, reversible, low-risk. Skip spec/state/registry
-  ceremony and run targeted verification with proportional evidence.
-- **Standard**: use the bounded spec profile and focused inspection. A small
-  feature need not have a task registry or task bundle. Close once at the
-  feature boundary.
-- **Critical**: require the approved strict profile. Add durable task state,
-  registry/DAG, research, or independent audit only when the persisted
-  `proof_obligations` require each one.
+- **Direct**: clear, isolated, reversible, low-risk. Skip spec/state/registry ceremony and run targeted verification with proportional evidence.
+- **Standard**: use the bounded spec profile and focused inspection. A small feature needs no task registry/bundle and closes once at the feature boundary.
+- **Critical**: derived Strict view. Add durable task state, research, or review
+  only when actual topology, uncertainty, or assurance requires it.
+
+Risk can raise the classified minimum. Reclassify before persistence. After
+persistence, a per-feature baseline is monotonic and no downgrade is supported
+until a trusted issuer exists; the baseline applies only to that feature.
+Legacy approval fields and caller booleans have zero authority.
 
-Risk can escalate but cannot downgrade the persisted lane. A downgrade without a
-trusted runtime-issued receipt is blocked; `user_approved` requires explicit user
-approval, and `userAuthorized` plus similar booleans are not authorization.
+Develop starts only from the user's explicit Develop invocation. Technical
+`ready_for_implementation` never dispatches Develop, and Specs must never
+auto-chain into this workflow.
 
-`execution_tier` (`Light | Standard | Deep`) is a read-only legacy adapter
-(`Direct | Standard | Critical`). It cannot emit policy, create obligations,
-select a workflow, or override the lane. Do not branch on it for new behavior.
+`execution_tier` (`Light | Standard | Deep`) is a read-only legacy adapter (`Direct | Standard | Critical`). It cannot emit policy, create obligations, select a workflow, or override the lane. Do not branch on it for new behavior.
 
 ## Modes
 
 ### Specific task
 
-Load exactly one task packet, implement only its scope, run its evidence, and
-stop after synchronization. Specific-task mode never selects or chains into the
-next task, even when another task is pending.
+Load exactly one task packet, implement only its scope, run its evidence, and stop after synchronization. Specific-task mode never selects or chains into another pending task.
 
 ### Full feature
 
-For a task-bearing policy, resolve one unblocked task at a time, complete its
-cycle, synchronize, and recompute the queue. A bounded Standard feature without
-tasks runs one feature-level cycle. Stop on the first unresolved block or
-missing proof. Run a final integration check only when the feature has no more
-pending tasks.
+For a task-bearing policy, resolve one unblocked task at a time, complete its cycle, synchronize, and recompute the queue. A bounded Standard feature without tasks runs one feature-level cycle. Stop on the first unresolved block or missing proof; run final integration only after all pending tasks finish.
 
 ### Parallel (opt-in)
 
-Load `references/parallel-waves.md` only when `--parallel` is present. It may
-use isolated worktrees and a bounded wave, but lane obligations, single-writer
-rules, immutable provenance, and the final integration check remain in force.
-Without `--parallel`, process one unblocked task at a time.
+Load `references/parallel-waves.md` only with `--parallel`. It may use isolated worktrees and a bounded wave, but lane obligations, single-writer rules, immutable provenance, and final integration remain in force. Otherwise process one unblocked task at a time.
 
 ### 3. Flash Mode (`--flash`)
 Flash is an explicit speed trade-off, not a completion shortcut:
@@ -104,12 +102,7 @@ Flash is an explicit speed trade-off, not a completion shortcut:
 - never claim `Test PASS`, `Evidence PASS`, `Auto-Approved`, or
   `production-ready`.
 
-Only trusted sync-finalize may promote a flash task. It must receive the current
-`FLASH_UNVERIFIED` task plus explicit `--verdict PASS` and a canonical proof;
-caller-supplied promotion fields are ignored/rejected. A marker-only proof
-never promotes or finalizes. Stored state keeps `in_progress`,
-`FLASH_UNVERIFIED`, `dependencyBlocked: true`, `unblocks: false`, and a concrete
-blocker, omits promotion fields, and binds proof to expected Base/Head anchors.
+Only trusted sync-finalize may promote a current `FLASH_UNVERIFIED` task with explicit `--verdict PASS` and canonical proof; caller promotion fields are ignored/rejected, and marker-only proof never promotes. Stored state remains `in_progress`/`FLASH_UNVERIFIED`, dependency-blocked with a concrete blocker, omits promotion fields, and binds proof to expected Base/Head anchors.
 ## Workflow
 `Classify lane → load lane artifacts → scout obligations → implement current
 scope → one closeout owner → test receipt → review → docs-impact sync.`
@@ -117,46 +110,46 @@ scope → one closeout owner → test receipt → review → docs-impact sync.`
 ### Step 1 — Load and scope
 
 - Direct does not create a spec, state, registry, task bundle, or notes file.
-- Standard requires its bounded artifacts and explicit approval, but not a
+- Standard requires its bounded validated artifacts, but not a
   registry when the scope is small and no task obligation is persisted.
 - Critical requires only the artifacts named by its snapshot obligations.
 - For task-bearing work, load one requested task or one unblocked task and
-  extract scope, requirements, contracts, completion criteria, and exact
-  evidence commands.
+  extract the exact seven v2.1 sections: `Outcome`, `Scope`, `Anchors and Ownership`,
+  `Changes`, `Acceptance`, `Dependencies`, and `Verification Plan`.
+  Use typed `coordination.boundaries` for ownership/DAG/proof/parallel authority.
+- Before implementation, transition `pending` to `in_progress` in task Markdown `**Status:**` and `spec.json.task_registry[path]` with synchronized timestamps. Never write execution proof into the task plan.
 - A spec-ready execution-evidence or independent-audit slot may be `PENDING`
   before implementation; pending is not proof and cannot close the feature.
 
 ### Step 2 — Scout
 
-Scout depth follows the persisted lane, risk, and blast radius. Identify real
-entrypoints/callers, integration points, dependent files, reachability risks,
-and safe scope. Do not use file count as a proxy for review depth. If a runtime
-entrypoint cannot be grounded, stop.
+Scout depth follows assurance, risk, and blast radius. Identify real
+entrypoints/callers, integration points, dependents, reachability risks, and
+safe scope. File count is not review depth; stop if a runtime entrypoint cannot
+be grounded.
 
 ### Step 3 — Implement
 
-Implement only the approved scope and named contracts. Do not silently replace
+Implement only the scoped behavior and named contracts. Do not silently replace
 frameworks, auth, transport, storage, or runtime boundaries. Do not mark a
 runtime-facing file complete while it is orphaned, unmounted, unregistered, or
 uncalled. A specific-task request ends after that task; no automatic chain.
 
 <SCOPE-FIDELITY>
-The approved `scope_lock`, requirements, design contracts, and active task are
+The `scope_lock`, requirements, design contracts, and active task are
 the implementation contract. Scope escape requires a concrete reachability or
 compile reason and must not deliver a later task early.
 </SCOPE-FIDELITY>
 
 ### Step 4 — Closeout owner
 
-The controller assigns exactly one closeout owner for the current task or
-feature. That owner invokes the test workflow once, receives its result, then
-invokes the review workflow once when the lane requires it. No other phase
-re-runs the same test or review as a hidden gate.
+The controller assigns exactly one closeout owner for the current task or feature. It invokes testing once, then review once when required; no phase re-runs either as a hidden gate.
 
-- The test owner executes commands and creates the canonical execution receipt.
+- For task-bearing work, the test owner executes the Verification Plan and writes the canonical execution receipt to `receipts/<task-basename>.md` only after real execution.
 - The review owner evaluates correctness, security, and spec compliance; it
   consumes existing proof but never creates or claims execution proof.
-- Review depth follows lane, risk, and blast radius. It does not follow the
+- Review depth follows `assurance_level`, risk, and blast radius. Lane is only
+  a derived view, and depth does not follow the
   number of files changed.
 - Finding count never selects review depth or overrides missing execution proof.
 - Use the shared adapter surface: `PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED`.
@@ -167,11 +160,7 @@ fixed Light/Standard/Deep agent sequence.
 
 ### Step 5 — Sync and docs checkpoint
 
-Only a canonical execution receipt with command, exit result, bound provenance,
-and required artifact hashes can close a task/feature. Missing, pending,
-marker-only, or contradictory evidence stays unfinished. Critical audits need
-distinct session IDs, expected Base/Head binding, concrete evidence, and literal
-`verdict: "PASS"`; `Audit: PASS` is not evidence.
+Only a canonical receipt with task identity/path, exact command/result, expected versus observed behavior, bound provenance, applicable negative/reachability proof, and required artifact hashes can close a task. Prefer `receipts/<task-basename>.md`; legacy task `## Evidence` is read-compatible, but conflicting proof identities fail closed. Missing, pending, marker-only, or contradictory evidence stays unfinished. Critical audits need distinct session IDs, expected Base/Head binding, concrete evidence, and literal `verdict: "PASS"`; `Audit: PASS` is not evidence.
 After verification, synchronize status/timestamps/task state. Then evaluate
 actual docs impact:
 
@@ -188,9 +177,7 @@ a receipt bound to expected Base/Head, and every lane obligation. Only literal
 `PASS` can complete; `PASS_WITH_WARNINGS` remains unfinished.
 `--flash` records only `FLASH_UNVERIFIED` and never done.
 
-For a full feature, after the last task run the **Final Integration Scout** when
-runtime-facing surfaces exist; compare reachability and scope before reporting
-completion. For a specific task, stop after its synchronized result.
+For a full feature, after the last task run the **Final Integration Scout** for runtime-facing surfaces and compare reachability/scope before completion. The same test owner creates `feature-receipt.md` exactly once from final integration proof. Task-bearing closeout requires every task receipt plus that feature receipt; taskless Compact/Full creates only the feature receipt at closeout. Its earlier absence is normal. A specific task stops after synchronization and creates no feature receipt unless it also completes the full integration boundary.
 
 ## Attached references
 

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

@@ -86,7 +86,8 @@ these mandatory lines:
 
 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. "Do NOT touch files outside this task's `Related Files`."
+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
@@ -150,14 +151,15 @@ 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 `## Evidence` and repository contract (build or affected test
+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 Evidence suite
+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. Classify every failure before acting as exactly one of:
+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;
@@ -172,8 +174,9 @@ sequential fallback according to the task contract.
 
 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 verification receipt citing the worktree gate evidence plus
-the post-merge check result. The Stop completion gate (`spec-gate.cjs`) applies
+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.
 

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

@@ -1,12 +1,12 @@
 # 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. The lane snapshot is authoritative; `execution_tier`
-is only a legacy read adapter.
+a fixed actor checklist. Canonical v2.1 policy input is authoritative; lane and
+`execution_tier` are derived/read-only compatibility views.
 
 ## Inputs and ownership
 
-The single closeout owner receives the current scope, lane, risk signals, blast
+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.
@@ -16,7 +16,7 @@ or sync hook runs a duplicate hidden gate.
   consumes the receipt but never creates or claims execution proof.
 - **Closeout owner:** combines both results and performs one state/docs sync.
 
-Review depth follows lane, risk, and blast radius, not the number of files or
+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.
@@ -32,11 +32,12 @@ synchronization remain single-writer operations.
 Before completion, verify:
 
 1. compile/typecheck precheck and every exact command named by the active
-   Evidence section;
+   `Verification Plan`;
 2. real runtime reachability and declared artifact inspection;
-3. canonical receipt with non-empty command, successful exit result, both
-   provenance anchors bound to the runtime's expected Base/Head pair, and
-   required SHA-256 declarations;
+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
@@ -50,8 +51,8 @@ the shared completion verdict `PASS`.
 
 ## Spec compliance review
 
-Check scope lock, requirements, design contracts, completion criteria, evidence,
-runtime reachability, and artifact/provenance boundaries. A missing or orphaned
+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.
 
 **Specific-task mode:** review exactly the requested task and its diff, then
@@ -67,7 +68,7 @@ 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 lane/risk requires.
+auth, persistence, provider, or concurrency checks only when scope/risk requires.
 
 ## Quality cycle
 
@@ -83,7 +84,7 @@ if retry_count reaches 3: stop and request user intervention
 
 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 lane obligations are
+only literal `PASS` may close when all execution and policy obligations are
 complete.
 
 ## Flash Gate (`--flash`)
@@ -132,6 +133,12 @@ missing execution proof. Evaluate docs impact from the actual behavior change:
 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.
+
 ## Review threshold
 
 `PASS` requires no Critical or High correctness/security/spec finding and no