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

package/src/claude/skills/specs/templates/spec-state.json

@@ -1,106 +1,56 @@
 {
-  "schema_version": "2.0",
+  "schema_version": "2.1",
   "feature_name": "{{FEATURE_NAME}}",
   "created_at": "{{TIMESTAMP}}",
   "updated_at": "{{TIMESTAMP}}",
   "language": "en",
   "status": "in_progress",
-  "phase": "initialized",
-  "current_phase": "init",
-  "priority": "P2",
-  "effort": null,
-  "tags": [],
-  "approvals": {
-    "requirements": {
-      "generated": false,
-      "agent_validated": false,
-      "user_approved": false
-    },
-    "design": {
-      "generated": false,
-      "agent_validated": false,
-      "user_approved": false
-    },
-    "tasks": {
-      "generated": false,
-      "agent_validated": false,
-      "user_approved": false
-    }
-  },
   "scope_lock": {
     "source": "{{PROJECT_DESCRIPTION}}",
     "in_scope": [],
     "out_of_scope": [],
     "expansion_policy": "requires-user-approval"
   },
-  "dependencies": {
-    "blockedBy": [],
-    "blocks": []
-  },
-  "task_files": [],
-  "task_registry": {},
-  "blocker": null,
-  "progress": {
-    "init": "done",
-    "requirements": "pending",
-    "research": "pending",
-    "design": "pending",
-    "tasks": "pending",
-    "code": "pending",
-    "test": "pending",
-    "review": "pending"
-  },
-  "timestamps": {
-    "init": "{{TIMESTAMP}}",
-    "requirements_done": null,
-    "research_done": null,
-    "design_done": null,
-    "tasks_done": null,
-    "code_done": null,
-    "test_done": null,
-    "review_done": null,
-    "validation_done": null
+  "authoring": {
+    "requirements": "draft",
+    "design": "draft",
+    "research": "absent",
+    "tasks": "absent"
   },
-  "design_context": {
-    "discovery_mode": null,
-    "discovery_reason": null,
-    "validation_recommended": false
+  "coordination": {
+    "boundaries": []
   },
   "validation": {
     "status": "not-run",
-    "session_count": 0,
-    "questions_asked": 0,
-    "last_validated_at": null
-  },
-  "translation": {
-    "enabled": false,
-    "language": null,
-    "language_code": null,
-    "dir": null,
-    "sync": "always",
-    "last_synced_at": null
+    "semantic_review": {
+      "status": "not-run",
+      "semantic_digest": null,
+      "verdict": null,
+      "lifecycle_disposition": null,
+      "findings": [],
+      "unresolved_decisions": [],
+      "graph_coverage": [],
+      "repair_round": 0,
+      "reviewed_criteria": [],
+      "counterexamples": [],
+      "reviewer_evidence": null
+    },
+    "semantic_review_history": {
+      "lineage_id": "{{LINEAGE_ID}}",
+      "entries": []
+    },
+    "authoring_validation": null
   },
+  "semantic_model": null,
   "ready_for_implementation": false,
   "workflow_policy": {
-    "version": "1",
-    "lane": "Standard",
-    "automatic_lane": "Standard",
-    "risks": [],
-    "artifact_profile": "bounded",
-    "proof_obligations": [
-      "needsInspection",
-      "needsExecutionProof"
-    ],
-    "actor_needs": [
-      {
-        "capability": "inspection",
-        "independence": "same-session"
-      },
-      {
-        "capability": "execution-proof",
-        "independence": "same-session"
-      }
-    ],
-    "override_receipt": null
+    "version": "2.1",
+    "planning_depth": "Compact",
+    "assurance_level": "Routine",
+    "classified_minimum": {
+      "planning_depth": "Compact",
+      "assurance_level": "Routine"
+    },
+    "risks": []
   }
 }

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

@@ -1,119 +1,47 @@
 # Task R{{REQ_NUMBER}}-{{SEQ}}: {{TITLE}}
-
-**Requirement:** R{{REQ_NUMBER}} — {{REQUIREMENT_TITLE}}
 **Status:** pending
-**Priority:** {{PRIORITY}}
-**Estimated Effort:** {{EFFORT}}
-**Dependencies:** {{DEPENDENCIES}}
-**Spec:** specs/{{FEATURE_NAME}}/
-
-The owning `spec.json.workflow_policy` snapshot is authoritative for this task.
-`needsInspection` and `needsExecutionProof` are separate capabilities; Standard
-requires both, while Direct requires execution proof. Do not encode an agent
-chain in this task. The canonical verdicts are `PASS`, `PASS_WITH_WARNINGS`,
-`FAIL`, and `BLOCKED`. Legacy diagnostic inputs `PARTIAL` and `NO_TESTS` are
-normalized to unfinished `BLOCKED`; they are not canonical verdicts.
-
-## Context
-
-- **Why**: {{Business/user reason this task exists}}
-- **Current state**: {{Relevant existing files, route, model, API, screen, or "greenfield"}}
-- **Target outcome**: {{Observable behavior after this task is done}}
-
-## Constraints
-
-- **MUST**: {{Non-negotiable requirement or technical constraint}}
-- **SHOULD**: {{Recommended approach or optimization}}
-- **MUST NOT**: {{Explicitly forbidden action or approach}}
-- **SCOPE**: Implement only the behavior mapped to R{{REQ_NUMBER}} and the approved `scope_lock`; do not add out-of-scope features or leave scoped acceptance criteria unwired.
-
-## Steps
-
-- [ ] 1. {{Actionable step with exact file/path/contract}}
-  - {{Business intent: what user/system behavior this enables}}
-  - {{Code detail: schema/API/component/function/route and validation rules}}
-  - _Requirements: {{REQ_NUMBER}}.{{X}}_
-
-- [ ] 2. {{Next actionable step}}
-  - {{Business intent}}
-  - {{Code detail, edge case, or integration contract}}
-  - _Requirements: {{REQ_NUMBER}}.{{Y}}_
-
-- [ ] 3. Verification implementation
-  - {{Unit/integration/e2e test or explicit manual verification hook}}
-  - _Requirements: {{REQ_NUMBER}}_
-
-## Requirements
-
-- {{REQ_NUMBER}}.{{X}} — {{Acceptance criterion or requirement covered}}
-- {{REQ_NUMBER}}.{{Y}} — {{Acceptance criterion or requirement covered}}
 
-## Related Files
+## Outcome
 
-| Path | Action | Description |
-|---|---|---|
-| `{{FILE_PATH_1}}` | Create / Modify / Delete | {{DESCRIPTION_1}} |
-| `{{FILE_PATH_2}}` | Create / Modify / Delete | {{DESCRIPTION_2}} |
+{{Concrete observable vertical outcome, named entrypoint, and resulting state delivered by this task.}}
 
-### Optional artifact declaration
+## Scope
 
-If this task produces a hashable compiled or generated output, the producer MUST add
-`task_registry[path].artifacts` as a non-empty JSON array of safe relative path
-strings. Omit the field when the task has no such artifact. A `Related Files`
-row (`Create`, `Modify`, `Delete`, or `Read`) is not an artifact declaration by
-itself. The receipt must declare each artifact path with its own `SHA-256:` value
-containing exactly 64 hexadecimal characters.
+- **In scope:** {{Exact behavior owned by this task}}
+- **Out of scope:** {{Explicit exclusions or delegated behavior}}
 
-## Completion Criteria
+## Anchors and Ownership
 
-- [ ] {{Criteria 1 — observable output or artifact, maps to acceptance criteria R{{REQ_NUMBER}}}}
-- [ ] {{Criteria 2 — measurable behavior or negative-path outcome}}
-- [ ] {{Criteria 3 — maps directly to acceptance criteria from requirements.md and can be proven below}}
-- [ ] {{Criteria 4 — no orphaned component/service/route/command; created runtime-facing work is reachable from the declared entrypoint or explicitly deferred to a named integration task}}
-- [ ] Completion decision is canonical: only literal `PASS` may complete after a canonical execution receipt bound to the runtime's expected Base/Head pair and every `workflow_policy.proof_obligations` proof; `PASS_WITH_WARNINGS` stays unfinished, `FAIL` needs fix-and-rerun, and `BLOCKED` plus legacy diagnostics record the blocker or missing proof.
+<!-- Compact core: one owned anchor is enough; proof artifact/owner exists only for a typed proof boundary (see Verification Plan). -->
+| ID | Type | Target | Role | Access | Action |
+|---|---|---|---|---|---|
+| A-R{{REQ_NUMBER}}-{{SEQ}}-01 | file | `{{exact/path/to/file}}` | owner | write | modify |
+<!-- For a typed proof boundary, add: | A-R{{REQ_NUMBER}}-{{SEQ}}-02 | file | `{{exact/path/to/test-file}}` | proof | write | create | and set Task role accordingly; otherwise omit. Every executable task must own a concrete test file/artifact anchor or share proof via that typed boundary; bare command is not ownership. -->
 
-## Evidence
+## Changes
 
-This section is both the task-level test plan and the proof checklist. Keep it short, exact, and executable.
-Select the proof by task risk; do not run every test type for every task.
+<!-- Every checkbox maps exact RN.M IDs; the set must equal Acceptance below. -->
+- [ ] {{Implement behavior at the exact owned boundary.}} _Requirements: {{REQ_NUMBER}}.{{X}}_
+- [ ] {{Handle the concrete negative or recovery path.}} _Requirements: {{REQ_NUMBER}}.{{Y}}_
 
-Verification: PENDING
-Canonical verdict: PASS | PASS_WITH_WARNINGS | FAIL | BLOCKED
-Legacy diagnostic input: PARTIAL | NO_TESTS -> unfinished BLOCKED
+## Acceptance
 
-- Logic/data/validator task: include unit tests.
-- Stateful UI/component task: include component or integration tests.
-- Cross-module/API/state flow task: include integration tests.
-- User-facing end-to-end workflow: include E2E/UI flow verification.
-- Layout/theme/responsive task: include visual/runtime viewport checks.
-- Interactive UI task: include accessibility checks when keyboard, focus, labels, or ARIA can regress.
-- Scaffold/release task: include smoke build/test/dev-server checks.
-- Performance/security checks are required only when the requirement, risk, or touched surface calls for them.
+<!-- Declare each mapped RN.M once with a measurable output/state and negative behavior. -->
+- **R{{REQ_NUMBER}}.{{X}}:** {{Measurable observable outcome}}
+- **R{{REQ_NUMBER}}.{{Y}}:** {{Concrete negative or recovery outcome}}
 
-- [ ] Automated verification (unit/component/integration/E2E as applicable)
-  - Command(s): `{{TYPECHECK / TEST / BUILD COMMANDS OR N/A}}`
-  - Expected proof: {{What output, exit code, or report proves success}}
-  - Runtime binding: `policy.createReceiptBinding({ base, head })` must be supplied to completion/flash adapters; a valid-length receipt pair without expected binding is not proof of identity.
-- [ ] Artifact / runtime verification
-  - Inspect: `{{artifact path | route | UI state | DB object | manifest entry}}`
-  - Expect: {{Observable result that proves the task is really wired}}
-- [ ] Runtime reachability verification
-  - Entrypoint/caller: `{{App.tsx | route file | CLI command | worker registration | manifest | API consumer}}`
-  - Expect: {{Created component/service/route/worker/loader is imported, mounted, registered, or invoked from the runtime path; if deferred, name the later integration task}}
-- [ ] Contract / negative-path verification
-  - Check: {{Unauthorized path, validation error, permission omission, missing env behavior, deletion effect, etc.}}
-  - Expect: {{Concrete failure mode or contract-preserving behavior}}
+## Dependencies
 
-## Risk Assessment
+- {{DEPENDENCIES}}
 
-| Risk | Severity | Mitigation |
-|---|---|---|
-| {{RISK_1}} | High/Medium/Low | {{MITIGATION_1}} |
-| {{RISK_2}} | High/Medium/Low | {{MITIGATION_2}} |
+## Verification Plan
 
----
+<!-- Ownership invariant: a bare npm test command without a concrete file/artifact anchor is not ownership; shared proof must use a typed proof boundary. -->
+- **Verification ref:** {{V reference whose structured subject/proof owner matches this task}}
+- **Task role:** {{subject | verifier}}
+- **Command:** `{{Exact project command}}`
+- **Expected:** {{Exit, output, state, artifact, or UI result}}
+- **Negative path:** {{Contract-preserving failure check}}
+- **Reachability:** `{{Real entrypoint/caller or generated artifact}}`
 
-> **Parallel marker**: Append `(P)` to the title if this task can run concurrently with another (usually when serving different requirements).
-> **Test note**: If a test coverage sub-task can be deferred post-MVP, mark it with `- [ ]*`.
-> **Requirement mapping**: Every sub-task MUST end with `_Requirements: X.X_`. No mapping = invalid task file.
-> **Evidence rule**: No `## Evidence` section = invalid task file. Use `## Evidence` (legacy heading aliases still parse).
+<!-- The table above is the only task anchor/ownership table. Access read requires Action read. Access write requires create, modify, or delete. Targets are exact; globs and parent-directory claims are invalid. A verifier must not repeat the subject's Acceptance criterion. Specs-only never creates or updates docs and never fabricates execution proof; record doc impact as a brief recommendation only. -->

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

@@ -14,19 +14,28 @@ metadata:
 
 This skill safely bridges the gap between active development state and physical documentation files (`spec.json` + `task_registry` + `tasks/task-R*.md`). Instead of relying on risky raw AI edits, this skill executes precise contextual replacements.
 
-## Lane-aware synchronization
+## v2.1 authority-aware synchronization
 
-Read lane policy before mutating state:
+Read canonical policy before mutating state. Lane is a derived view:
 
 ```bash
 node .claude/scripts/workflow-policy.cjs --classify-lane --task-json '<task JSON>' --json
 ```
 
-- Direct may have no spec/state/registry; sync only concrete targeted evidence and never invents approval state.
-- Standard stores one bounded spec and one canonical feature receipt; a combined closeout review is required only when the persisted policy says an independent audit is needed.
+- Direct may have no spec/state/registry; sync only concrete targeted evidence
+  and never invents proof, readiness, approval, or audit state.
+- Standard stores one bounded spec; final integration creates one canonical
+  feature receipt. A combined closeout review is required only when the
+  persisted policy says an independent audit is needed.
 - Critical requires strict durable evidence and the persisted capability obligations; choose available actors or the main session according to required capability and independence, never a fixed actor sequence.
-- `generated`, `agent_validated`, and `user_approved` are independent. Missing `user_approved` stays false; sync never auto-approves user-owned state.
-- Explicit lane overrides must preserve automatic classification and warning in receipt/state output, especially Critical downgrades.
+- Authoring states are only `draft`, `validated`, or `absent`. Legacy approval
+  fields are readable but inert.
+- Preserve `classified_minimum`. Reclassification happens before persistence;
+  after persistence, the same-feature baseline is monotonic and no downgrade is
+  supported until a trusted issuer exists.
+- `spec.json` is machine authority. Task status/checkboxes, dependencies, and
+  ownership Markdown are projections. Typed `coordination.boundaries` are the
+  only topology authority.
 
 ## Supported Commands
 ### 1. Task Synchronization
@@ -52,10 +61,17 @@ Scans the `spec.json` against all physical `task-R*.md` files to detect mismatch
 
 1. **Precision Edits:** Never overwrite the entire `spec.json` string blindly. Update only the required keys, while keeping JSON valid.
 2. **Machine + Human Sync:** Every task status update MUST modify both `spec.json.task_registry[...]` and the matching markdown task file header/status section.
-3. **Markdown Integrity:** When marking a task `done`, only then turn `[ ]` into `[x]` inside `## Steps` / `## Implementation Steps` and relevant `Completion Criteria` / `Evidence` checkboxes that have actual proof. Use `## Evidence` (legacy heading aliases still parse).
-4. **Verification Receipt Rule:** `done` is illegal without a human-readable verification receipt already present in `## Evidence` (legacy heading aliases still parse) (commands executed, artifact/runtime proof, or equivalent concrete evidence). If proof is missing, keep the task `in_progress` or `blocked`.
+3. **Markdown Integrity:** Task Markdown is a plan plus `**Status:**`. Update
+   Status and `Changes` checkboxes only when their implementation is real; never
+   insert Base/Head, verdicts, command outcomes, or receipt proof into the plan.
+4. **Verification Receipt Rule:** `done` is illegal without a valid canonical
+   `receipts/<task-basename>.md`, or a readable legacy `## Evidence` receipt.
+   Prefer the separate receipt; if both exist and proof identity conflicts,
+   refuse completion. If proof is missing, keep the task `in_progress` or
+   `blocked`.
 5. **Task Docs Hook:** When `hapo:sync` marks a task as `done`, assess actual documentation impact and report `Docs impact: major|minor|none`; do not create a docs update request when impact is `none`.
-6. **Phase Prompt Rule:** When the final pending task becomes `done`, a phase-advance prompt may mention documentation only when the impact assessment found affected docs; otherwise continue without a docs ceremony.
+6. **Topology Rule:** Never infer dependency or parallel state from `(P)`,
+   `task_triggers`, `Related Files`, or prose; project typed boundaries instead.
 
 ### 4. Explicit Flash Finalization
 
@@ -72,9 +88,16 @@ not authorize finalization.
 
 ### Flash implementation state
 
-Executable policy source: `.claude/scripts/workflow-policy.cjs` (source: `src/claude/scripts/workflow-policy.cjs`). Trusted sync-finalize invokes `promoteFlashTask` only after exact task Evidence and reachability return PASS; test PASS itself only supplies canonical proof and leaves the persisted task blocked in progress. FAIL, BLOCKED, and NO_TESTS remain blocked in progress.
+Executable policy source: `.claude/scripts/workflow-policy.cjs` (source: `src/claude/scripts/workflow-policy.cjs`). Trusted sync-finalize invokes `promoteFlashTask` only after the exact task Verification Plan and reachability return PASS; test PASS itself only supplies canonical proof and leaves the persisted task blocked in progress. FAIL, BLOCKED, and NO_TESTS remain blocked in progress.
 
 `FLASH_UNVERIFIED` is storage for implemented-but-unverified work, not a completion status. Store it as `status: "in_progress"` with `dependencyBlocked: true`, `unblocks: false`, a concrete blocker, and no promotion fields; do not unblock dependencies. `/hapo:test` may produce canonical proof, but the supported sync-finalize boundary must receive explicit `--verdict PASS` and `--proof`, require the runtime Base/Head binding, revalidate the receipt/artifact, derive the transition, and only then set `done`. FAIL, BLOCKED, NO_TESTS, marker-only proof, minimal state, and pre-promoted caller JSON remain `in_progress`.
 
+After the last task is done, sync does not synthesize proof. Test/Develop must
+run final integration and create `feature-receipt.md` once. Task-bearing
+completion requires all task receipts plus the feature receipt. Taskless
+Compact/Full completion requires the feature receipt only; its absence before
+final closeout is normal. No receipt grants or infers approval, readiness, or
+audit status.
+
 ## References
 Read `references/sync-protocols.md` for exact Search/Replace regex patterns and JSON schema expectations before acting on the files.

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

@@ -4,19 +4,29 @@ The following guidelines dictate exactly how `hapo:sync` should interact with fi
 
 **Flash implementation state:** `FLASH_UNVERIFIED` MUST remain the exact stored form: `status: "in_progress"`, `dependencyBlocked: true`, `unblocks: false`, a concrete blocker, and no `readyForSync`, `flashTransition`, or `promotionReceipt` fields. It never unblocks dependencies. The supported sync-finalize adapter must pass the current task, `--verdict PASS`, and canonical `--proof` to `workflow-policy.cjs`; the policy derives promotion, requires a runtime `createReceiptBinding({ base, head })` match for both receipt anchors, revalidates receipt/artifact requirements, and rejects caller-supplied promotion fields before setting `done`. FAIL, BLOCKED, NO_TESTS, marker-only proof, minimal state, and pre-promoted caller JSON stay `in_progress`.
 
-**Lane state rule:** classify Direct/Standard/Critical before sync. Direct may omit spec/state/registry for clear, reversible low-risk work; Standard uses one bounded spec and one feature receipt; Critical requires strict durable evidence. Explicit overrides must retain automatic lane, risk signals, and warning. `generated`, `agent_validated`, and `user_approved` are independent booleans; never infer or write `user_approved: true` from agent fields.
+**Policy state rule:** read the v2.1 policy input before sync. Direct/Standard/
+Critical are derived views. Preserve `classified_minimum`, risks, and explicit
+override receipt. Authoring states are only `draft`, `validated`, or `absent`;
+legacy approval fields are inert.
+
+**Authority rule:** `spec.json` is machine authority. Markdown is a projection.
+Typed `coordination.boundaries` own dependency, ownership, transition, proof,
+and parallel semantics; never infer them from `(P)`, `task_triggers`, `Related
+Files`, or prose.
 
 ## 1. Updating `spec.json`
 
-*   **JSON Modification Rule:** Do not output whole files. Instead, load the JSON structure, apply the update to `status`, `current_phase`, `blocker` (if any), `task_files`, and the relevant `task_registry` entry, then overwrite the file cleanly.
+*   **JSON Modification Rule:** Do not output whole files. Load the JSON,
+    update only lifecycle fields and the relevant registry entry, then write
+    valid JSON without changing semantic topology.
 *   **Task Registry Rule:** Resolve the incoming task reference to a single relative path in `task_registry`. Accept either:
     - compact task ID like `R0-02`
     - full filename like `task-R0-02-extension-shell.md`
     - full relative path like `tasks/task-R0-02-extension-shell.md`
 *   **Status Update:** If a task changes to `blocked`, the matching `task_registry[path].status` must become `"blocked"`, `task_registry[path].blocker` must record the reason, and `spec.json.status` / `spec.json.blocker` must reflect the top-level block if work is globally blocked.
 *   **Timestamp Rule:** Update `task_registry[path].started_at`, `completed_at`, and `last_updated_at` consistently with the new state. Also refresh `spec.json.updated_at`.
-*   **Done-State Rule:** Never set `task_registry[path].status = "done"` unless the matching markdown task file already contains a verification receipt in `## Evidence` (legacy heading aliases still parse), or the caller explicitly provides proof that can be written there first.
-*   **Receipt Integrity Rule:** A valid verification receipt must include the exact commands run, their outcomes, and artifact/runtime proof. Receipts containing `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, or explicit "placeholder / simplified for MVP / production later" contract deviations are not eligible for `done`.
+*   **Done-State Rule:** Never set `task_registry[path].status = "done"` unless `receipts/<task-basename>.md` is valid, or a legacy `## Evidence` receipt is valid. Write proof to the separate receipt first; never add execution evidence to a new-format task plan.
+*   **Receipt Integrity Rule:** A valid task receipt includes task identity/path, exact commands and outcomes, expected versus observed behavior, applicable negative/reachability/artifact proof, and Base/Head binding. If separate and legacy receipts both exist with conflicting proof identity, refuse `done`. `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, placeholders, and contract substitutions are not eligible.
 *   **Contract Fidelity Rule:** If the task file notes or evidence show that a named framework/auth/runtime choice from the spec was silently replaced, sync MUST refuse `done` until the spec is amended or the implementation is corrected.
 *   **Task Docs Rule:** After a task is moved to `done`, assess actual documentation impact and report `Docs impact: major|minor|none`. Only affected docs receive a follow-up checkpoint.
 
@@ -27,19 +37,18 @@ The structure of `tasks/task.md` relies heavily on exact keyword markers. Follow
 ### A. Completing a Task
 When `/hapo:sync <feature> <task-id> done`:
 1. Find: `**Status:** pending` (or `in_progress` / `blocked`).
-2. Inspect `## Evidence` (legacy heading aliases still parse) first. If it has no explicit proof lines (commands run, artifact proof, runtime proof, or blockers cleared), STOP and refuse to mark the task done.
+2. Resolve `receipts/<task-basename>.md` first, with legacy `## Evidence` as fallback. If neither has valid proof, STOP and refuse to mark the task done.
 3. Refuse completion if the receipt contains any non-passing marker such as `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, or an explicit note that the implementation substituted a named contract with a placeholder/custom simplification.
 4. Replace with: `**Status:** done`.
-5. Locate block: `## Steps` or `## Implementation Steps`.
-6. Convert `- [ ]` into `- [x]` strictly within that section.
-7. Update relevant checkboxes in `## Completion Criteria` and `## Evidence` (legacy heading aliases still parse) only when the caller provides or the file already contains real proof.
-8. Surface `Docs impact: major|minor|none`; if impact is not `none`, name the affected docs and the follow-up checkpoint.
+5. Update only implemented checkboxes under `## Changes`; never append receipt fields to the task plan.
+6. Surface `Docs impact: major|minor|none`; if impact is not `none`, name the affected docs and the follow-up checkpoint.
 
 ### B. Blocking a Task
 When `/hapo:sync <feature> <task-id> blocked "API error"`:
 1. Find: `**Status:** <anything>`.
 2. Replace with: `**Status:** blocked`.
-3. Ensure that an entry under `## Blocker Log` exists recording the explicit reason (e.g. `API error`) and timestamp.
+3. Record the reason and timestamp in `task_registry[path].blocker`; do not add
+   a non-canonical task section.
 
 ### C. Starting / Resuming a Task
 When `/hapo:sync <feature> <task-id> in_progress`:
@@ -57,9 +66,18 @@ When `/hapo:sync audit <feature>` is activated:
 4. **Reconciliation Rules:**
    - Missing registry entry → create it
    - Missing disk file referenced in registry → remove or flag it
-   - Markdown says `done` but registry not done → registry wins only if evidence already exists; otherwise downgrade markdown or flag conflict
-   - Registry says `done` but markdown still pending → update markdown only if evidence exists
-   - Either side says `done` but `## Evidence` (legacy heading aliases still parse) has no concrete proof → downgrade to `in_progress` or flag conflict instead of preserving fake completion
+   - Markdown says `done` but registry not done → registry wins only if a canonical separate or legacy receipt exists; otherwise downgrade markdown or flag conflict
+   - Registry says `done` but markdown still pending → update markdown only if a canonical separate or legacy receipt exists
+   - Either side says `done` but neither receipt source has concrete proof → downgrade to `in_progress` or flag conflict instead of preserving fake completion
+   - Both receipt sources exist with conflicting proof identity → fail closed and require manual reconciliation
    - Either side says `done` but the receipt contains `PRECHECK_FAIL`, `FAIL`, `UNVERIFIED`, or explicit contract-substitution notes → downgrade to `in_progress` or flag conflict
 5. **Correction Alert:** Output a brief markdown alert detailing mismatches fixed and any unresolved conflicts requiring manual review.
 6. **Task Docs Alert:** If audit reveals tasks newly marked `done`, include the actual docs impact; do not emit a generic docs-sync request when no docs are affected.
+
+## 4. Feature closeout
+
+- Before all tasks are done, missing `feature-receipt.md` is normal.
+- After all tasks are done, require final integration execution and one valid
+  `feature-receipt.md`; never derive it from task status alone.
+- A taskless Compact/Full spec uses the same final feature receipt and does not
+  require a synthetic registry entry.

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

@@ -41,14 +41,15 @@ receipt, or claim execution proof.
 - Preserve the exact command, exit result, provenance, and artifact hashes
   required by the canonical receipt schema.
 
-## Scope and lane
+## Scope and policy
 
 For a feature target, load `spec.json`, `requirements.md`, `design.md`, and
-task evidence only when that target exists. Compare actual execution against
+the active task's exact seven v2.1 sections and typed coordination boundaries
+when that target exists. Compare actual execution against
 `scope_lock`, contracts, completion criteria, runtime reachability, and
 negative-path obligations.
 
-Choose depth from the persisted lane, risk, and blast radius:
+Choose depth from `assurance_level`, risk, and blast radius. Lane is derived:
 
 - Direct: targeted commands and diff/runtime self-check;
 - Standard: bounded affected suite and feature receipt;
@@ -79,8 +80,10 @@ requirements. Use UI checks only when a reachable UI surface is in scope.
    performance, or security proof for the changed surface.
 4. Inspect runtime reachability and declared artifacts when the task creates
    runtime-facing or generated output.
-5. Preserve raw outcomes and write one canonical receipt. A receipt must not
-   contain secrets or placeholder provenance.
+5. Preserve raw outcomes and, only after real execution, write one canonical
+   receipt. For a task use `receipts/<task-basename>.md`; never append execution
+   evidence to the task plan. A receipt must not contain secrets or placeholder
+   provenance.
 
 Required proof type follows the behavior, not ceremony:
 
@@ -98,7 +101,9 @@ Required proof type follows the behavior, not ceremony:
 ## Canonical receipt
 
 The receipt is execution evidence, not a status marker. It must contain the
-actual command, a successful exit result, both provenance anchors (`Base` and
+task identity and canonical `tasks/task-*.md` path for task receipts, the actual
+command, a successful exit/result, expected versus observed behavior, applicable
+negative-path and reachability proof, both provenance anchors (`Base` and
 `Head`, or their canonical aliases), and any declared artifact SHA-256. Reject
 `Exit: 1`, conflicting outcomes, empty commands, placeholders, missing
 provenance, zero execution, and failure summaries. No-artifact tasks remain
@@ -112,6 +117,11 @@ pass `receipt_binding: binding` to `completionDecision` or include the binding's
 compares both receipt anchors before completion or flash promotion.
 
 For a normal closeout, emit a receipt that the shared policy validator accepts.
+Legacy task `## Evidence` remains readable, but prefer the separate receipt. If
+both exist and their proof identities conflict, report `FAIL` and do not choose
+one. After all task receipts pass, execute final integration and create
+`feature-receipt.md` exactly once. Taskless Compact/Full specs create that file
+only at final closeout; absence before closeout is normal.
 For `--flash`, emit proof for the current `FLASH_UNVERIFIED` task only. Only explicit trusted sync-finalize may promote it. The
 receipt may make the task eligible for trusted sync-finalize, but it must not
 promote the task, unblock dependents, or fabricate a done state.
@@ -161,7 +171,7 @@ security, and spec compliance against this proof.
 ## Flash proof
 
 When the target contains an in-progress `FLASH_UNVERIFIED` task, test only its
-exact Evidence and reachability obligations. On pass, keep the task
+exact Verification Plan and reachability obligations. On pass, keep the task
 `in_progress`, keep `FLASH_UNVERIFIED`, `dependencyBlocked: true`, and
 `unblocks: false`; return canonical proof to trusted sync-finalize. On failure,
 blocker, or no tests, do not promote any task.

package/src/codex/AGENTS.md

@@ -8,6 +8,12 @@
 - CafeKit agents live in `.codex/agents/*.toml` and are auto-discovered after the repository is trusted.
 - Runtime support lives in `.codex/rules/`, `.codex/scripts/`, `.codex/references/`, and `.codex/runtime.json`.
 - Project hooks live in `.codex/hooks.json`; review trusted hooks with `/hooks`.
+- Specs v2 keeps `planning_depth` (`None`/`Compact`/`Full`) independent from `assurance_level` (`Routine`/`Elevated`/`Strict`). Any risk has an Elevated automatic floor; Strict is opt-in only for an explicit user/project independent-audit requirement or a user-confirmed scope-specific audit decision, never a keyword or severity label. Run the artifact router before discovery: None has no durable spec; Compact/Full share the bounded `spec.json` + `requirements.md` + `design.md` core. Research requires material unresolved uncertainty, an external-current fact, or an explicit request; tasks require typed coordination topology. Full/Strict never create either automatically.
+- In v2.1, `spec.json` is machine authority and Markdown is a human projection. Task plans have exactly seven sections: `Outcome`, `Scope`, `Anchors and Ownership`, `Changes`, `Acceptance`, `Dependencies`, `Verification Plan`; the only ownership table is `ID | Type | Target | Role | Access | Action`.
+- Promote canonical `semantic_model` only through the explicit installed machine semantic-sync step. A semantic Markdown edit requires resynchronization and round-trip validation; never hand-author the machine shape.
+- `coordination.boundaries` typed as ownership/dependency/transition/proof/parallel is topology authority. Legacy trigger fields, priority markers, related-file lists, approval fields, and prose are inert compatibility inputs, never canonical authoring.
+- Canonical lifecycle is exactly `in_progress`, `paused`, `blocked`, or `done`. Technical readiness differs from closeout; authors cannot self-declare readiness, review authority, execution proof, or final `done`.
+- Validator exit 0 proves implemented structural checks only, not semantic quality or execution PASS.
 
 ## Codex caveats