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

package/src/claude/skills/specs/rules/design-discovery-full.md

@@ -1,45 +0,0 @@
-# Full design discovery
-
-Load this rule only after the artifact router selects `Full`. Full controls
-design detail; it does not select research, web access, tasks, or ceremony.
-
-## Discovery boundary
-
-Inspect only facts needed to remove an implementation-significant ambiguity:
-
-1. map scoped requirements to existing entrypoints and behavior owners;
-2. inspect reusable contracts, data flows, dependencies, and recovery paths;
-3. identify decisions whose alternatives would change observable behavior;
-4. ground each chosen decision to repository anchors or, when needed, a
-   primary external source; and
-5. stop when the routed design can be implemented without a product decision.
-
-Do not inventory unrelated architecture, compare fashionable patterns, or
-collect findings merely because they are available. Repository scouting is
-normal design work and does not by itself create `research.md`.
-
-## Research gate
-
-Create `research.md` only when the router has found at least one of:
-
-- unresolved material uncertainty that can change requirements or design;
-- an external-current fact that must be grounded; or
-- an explicit user request for durable research.
-
-If none applies, research is absent: do not load the research template, invoke
-a researcher, search the web, or create a placeholder. When external-current
-facts matter, prefer primary authoritative sources and capture only evidence
-that resolves the named uncertainty. General best-practice browsing is not a
-research trigger.
-
-## Projection
-
-Put settled behavior, contracts, invariants, negative paths, and grounded
-anchors in `design.md`. If research was selected, keep `research.md` minimal:
-named uncertainty, relevant evidence, resulting decision, and remaining gaps.
-Synchronize every promoted semantic decision into `spec.json`; research notes
-that do not affect semantics remain supporting evidence, not authority.
-
-Full may add flow, data, error/recovery, security/privacy, migration, or proof
-detail only when the scoped topology activates that section. Delete unused
-sections rather than reserving them for implementation.

package/src/claude/skills/specs/rules/design-discovery-light.md

@@ -1,28 +0,0 @@
-# Compact design discovery
-
-Load this rule only after the artifact router selects `Compact`. The goal is a
-bounded durable design, not a reduced version of a default research process.
-
-## Focus
-
-1. locate the real entrypoint and existing behavior owner;
-2. inspect the smallest set of contracts and dependencies touched by scope;
-3. record compatibility, negative-path, and verification constraints; and
-4. ground the selected anchors and stop.
-
-Keep the result in `design.md`. File lists without behavior ownership, generic
-best practices, and broad architecture inventories are not useful discovery.
-
-## Research gate
-
-Research remains absent unless there is unresolved material uncertainty, an
-external-current fact that must be grounded, or an explicit user request. A new
-library is not automatically a trigger: inspect repository declarations first;
-consult primary external documentation only when a current fact can change the
-decision. When the gate opens, create the minimal uncertainty-to-evidence-to-
-decision projection and retain any honest remaining gap.
-
-If discovery reveals cross-boundary behavior needing materially more design
-detail, reclassify planning depth before persistence. If the Compact baseline
-is already persisted, expand monotonically to Full; do not silently downgrade
-or create optional artifacts merely to resemble Full.

package/src/claude/skills/specs/rules/design-principles.md

@@ -1,138 +0,0 @@
-# Adaptive design principles
-
-The design exists to remove implementation guesses. It defines behavior-owning
-boundaries and stable contracts without prescribing incidental code.
-
-## Detail by planning depth
-
-### Compact
-
-Keep only:
-
-1. boundary and responsibilities;
-2. typed source anchors;
-3. decisions, named contracts, and invariants needed for consistency; and
-4. verification, including relevant negative paths.
-
-Delete every unused heading. Compact is a complete durable design, not a teaser
-for a later Full document.
-
-### Full
-
-Start from Compact. Add only relevant sections for:
-
-- cross-boundary contracts and flows;
-- data ownership, schema, consistency, and concurrency;
-- error classification and recovery;
-- security/privacy boundaries;
-- migration, compatibility, rollback, or deployment transition; and
-- proof that spans owners or runtime surfaces.
-
-Do not add a section because the template contains it. Empty tables, generic
-best practices, and restated requirements form a template cemetery and must be
-deleted.
-
-## Boundaries and typed anchors
-
-A boundary names what owns, reads, writes, calls, registers, or exposes the
-behavior. “Service”, “module”, or “layer” without a grounded target is invalid.
-
-Design and task anchors use the same closed six-column machine model:
-`ID | Type | Target | Role | Access | Action`. Every implementation-facing
-anchor has:
-
-| Field | Rule |
-|---|---|
-| ID | Unique across the entire spec. Design-owned anchors use `A-D-NN`; task-owned anchors use `A-R{requirement}-{sequence}-NN`. |
-| Type | `file`, `symbol`, `command`, `route`, `schema`, `contract`, `artifact`, or `external`. |
-| Target | Exact path, identifier, command, route, schema object, contract ID, artifact path, or primary source. |
-| Role | Why the target matters: owner, consumer, entrypoint, proof, constraint, or reference. |
-| Access | `read` or `write`. |
-| Action | `read` for read access; `create`, `modify`, or `delete` for write access. |
-
-Files-first is canonical. List `file` anchors before symbols, routes, schemas,
-or contracts they contain. A symbol anchor names its file. A command anchor is
-an exact project command. An external anchor states which decision it grounds.
-Role is descriptive only and never implies Action; words such as create,
-planned, new, producer, or output in prose have zero machine authority. Never
-reuse an anchor ID, even in another task. A task that consumes a canonical
-design anchor references its `A-D-NN` ID and does not redefine the same target in
-its task-scoped namespace.
-
-## Named contracts and invariants
-
-- Give every implementation-significant contract and invariant a stable ID,
-  such as `C1` or `I1`.
-- Define the canonical body once in `design.md`.
-- Task files reference IDs; they do not copy contract bodies.
-- Name one implementation owner before any cross-task consumer. Consumers
-  depend directly or transitively on the owner.
-- If implementation needs a different contract, revise and explicitly approve
-  the design before changing consumers.
-
-Contracts are required when drift could change auth/session, transport, API or
-event shape, persistence/schema, deletion/retention, generated artifacts,
-runtime entrypoints, or recovery behavior. Do not invent contract ceremony for
-local details that cannot drift across a boundary.
-
-For any public, replay, or operator surface contract, specify method, route,
-auth, required headers, request schema, success response, error semantics, and
-idempotency/concurrency behavior in one place; a partial contract is not a
-contract.
-
-## Decision quality
-
-Record a decision only when another reasonable implementation would behave
-differently. For each decision state:
-
-- chosen behavior and boundary;
-- relevant alternative or ambiguity rejected;
-- invariant or negative path that constrains implementation; and
-- anchor or evidence that makes it feasible.
-
-Use explicit types for public inputs, outputs, states, and errors. Avoid generic
-`any`, `object`, or unbounded maps unless the contract explains why they are
-intentional.
-
-## Conditional detail
-
-- Flow: include only for branching, asynchronous, or multi-party behavior.
-- Data: include only when shape, ownership, consistency, or lifecycle changes. Any retention/lifecycle policy must state clock anchor, clock source, timezone/precision, cutoff comparator/inclusivity, enforcement boundary, and a wrong-clock/boundary counterexample; domain-generic.
-- Error/recovery: include concrete triggers, responses, retry/rollback, and
-  terminal states only when relevant.
-- Security/privacy: include trust boundary, authorization, sensitive data, and
-  retention decisions only when touched.
-- Migration: include compatibility window, ordering, rollback trigger, and
-  verification only when existing state or public contracts change.
-- Diagrams: use plain Mermaid only when the relationship is materially clearer
-  than prose; do not duplicate the diagram in text.
-
-## Traceability and verification
-
-Every acceptance criterion has exactly one implementation owner and maps to a
-boundary, contract/invariant, or explicit verification definition. Keep exactly
-one visible `## Verification Definitions`
-section. The validator's canonical grammar is a single line per definition:
-
-```markdown
-- **V1**: Criteria R1.1; Owner A-D-01; Decision refs D1, I1, C1; Method command `npm test`; Expected exit 0 and the persisted state; Negative/failure invalid input returns the named error; Reachability/grounding entrypoint `src/entry.js` via A-D-01.
-```
-
-Do not use a V table, `### V1` heading, or prose-only “see verification” alias;
-the semantic-review parser recognizes the bold V-ID line above. Each line names
-every exact `RN.M` it covers, all applicable `D`/`I`/`C` refs, a command or anchored
-inspection, observable expected result, concrete negative/failure case, and
-runtime reachability plus grounding expectation.
-
-For a typed proof boundary, extend the same line after Owner with `Proof criteria
-R1.2; Proof owner A-D-02; Evidence anchor A-D-02;`. Both criteria remain
-single-owner; without that boundary, omit the extension.
-
-Validator success proves structure only. The author and reviewer still test the
-design against concrete counterexamples and check that an implementer can act
-without choosing unspecified product behavior.
-
-For task-bearing specs, typed `spec.json.coordination.boundaries` are the only
-authority for ownership, dependencies, transitions, proof separation, and
-parallel eligibility. Design prose explains semantics but cannot replace those
-typed edges.

package/src/claude/skills/specs/rules/design-review.md

@@ -1,55 +0,0 @@
-# Design review contract
-
-Review the complete routed artifact graph for implementation-blocking semantic
-gaps. Concise presentation is encouraged; inventory size is never capped.
-
-## Coverage
-
-For every `RN.M` criterion:
-
-1. trace the exact implementation owner, boundary, applicable `D`/`I`/`C`
-   definitions, and canonical `V` definition;
-2. construct a concrete counterexample or failure scenario;
-3. confirm the expected result rejects or handles that scenario;
-4. confirm referenced anchors are reachable and grounded; and
-5. record every unresolved contradiction, ambiguity, missing owner, broken
-   dependency, unreachable proof, or scope violation as a blocker.
-
-Also review cross-criterion contracts, state transitions, concurrency,
-authorization, recovery, compatibility, and rollback where scope activates
-them. Do not perform broad technology research during review; return an exact
-uncertainty to the artifact router when new material uncertainty is discovered.
-
-## Finding shape
-
-Each blocker states:
-
-- affected criterion and design/verification refs;
-- concrete counterexample;
-- observed conflicting or missing artifact content;
-- impact on implementation or proof; and
-- smallest semantic decision or correction required.
-
-Group duplicates for readability without dropping distinct blockers. Positive
-observations are optional and never displace a blocker.
-
-## Decision
-
-- `PASS`: the full routed graph is coherent, grounded, and every criterion's
-  counterexample is resolved.
-- `FAIL`: at least one semantic or structural blocker is actionable now.
-- `BLOCKED`: required product input, trusted capability, or external evidence
-  is unavailable.
-
-Routine and Elevated require semantic review but no reviewer ceremony. Strict
-requires an independent allowlisted reviewer capability observed by the host
-hook. An author, task marker, receipt text, or claimed role cannot self-attest
-that capability. Risk alone has an Elevated floor; Strict is opt-in only for an
-explicit user/project audit requirement or a user-confirmed, scope-specific
-audit decision. If the host event is unavailable, pause once rather than retry,
-downgrade, or simulate authority. Deterministic validation checks implemented
-structure and grounding; it never replaces this semantic judgment.
-
-Readiness stays false until the complete blocker inventory is resolved and all
-required machine gates pass. Review does not claim implementation execution,
-approval, closeout, or lifecycle completion.

package/src/claude/skills/specs/rules/ears-format.md

@@ -1,42 +0,0 @@
-# EARS authoring rules
-
-Use EARS to make behavior testable, not to fill a template.
-
-## Canonical IDs
-
-- Top-level headings: `Requirement N: <outcome>`.
-- Acceptance criteria: literal `RN.M` (`R1.1`, `R1.2`, ...).
-- Task mappings: numeric `N.M` only.
-- Do not emit `REQ-01`, `NFR-1`, alphabetic IDs, or bare numbered criteria.
-
-## Patterns
-
-| Need | Pattern |
-|---|---|
-| Event | `When <event>, the <system> shall <observable response>.` |
-| State | `While <state>, the <system> shall <observable response>.` |
-| Negative/error | `If <invalid or failure condition>, the <system> shall <observable response or recovery>.` |
-| Optional scope | `Where <feature is enabled>, the <system> shall <observable response>.` |
-| Always true | `The <system> shall <observable property>.` |
-
-Combine conditions only when they describe one behavior. Split criteria that
-have independent triggers, outcomes, or proof.
-
-## Quality gate
-
-Every criterion must be singular, unambiguous, observable, and testable. Name a
-concrete subject and replace words such as “fast”, “safe”, “graceful”, or “some”
-with an observable result or threshold. Use `shall` for mandatory behavior.
-
-Add a negative/error criterion when invalid input, missing permission,
-unavailable dependency, conflict, timeout, retry, rollback, or partial failure
-is relevant. Add a concrete example when values, ordering, boundaries, or
-transformation rules would otherwise admit multiple interpretations.
-
-User Story, rationale, scenario narrative, and role framing are optional. Keep
-them only when they explain a product decision not already clear from the
-outcome and criteria.
-
-Non-functional requirements are not a standard appendix. Add one only for a
-feature-specific measurable performance, security, privacy, accessibility,
-reliability, or compatibility constraint, continuing the same numeric sequence.

package/src/claude/skills/specs/rules/phase-decision-matrix.md

@@ -1,56 +0,0 @@
-# Task and phase decision matrix
-
-Tasks and phases are conditional structure, not mandatory planning ceremony.
-
-## Task gate
-
-Create a task only when at least one boundary is real:
-
-| Boundary | Create a separate task when |
-|---|---|
-| Ownership | A distinct owner can change the files or contract without overlap. |
-| Dependency | One durable output must exist before another consumer can begin. |
-| Transition | Stateful, migration, async, retry, or recovery behavior needs one named owner. |
-| Proof | The outcome needs proof that cannot coherently live with the implementation slice. |
-| Parallel coordination | Independent work can proceed with disjoint ownership and no hidden shared resource. |
-
-Do not create tasks from estimated effort, requirement count, architectural
-layers, risk labels, or a desire for uniform files.
-
-When the gate passes, encode the real reason as one or more typed
-`coordination.boundaries` entries. Legacy trigger fields, priority markers,
-related-file lists, and free-form declarations are not authority.
-
-## Split preference
-
-Start with one vertical outcome slice that reaches a real user or runtime
-entrypoint. Split horizontally only because dependency, ownership, or proof
-requires it.
-
-- Foundation: only when two or more consumers need the same owned prerequisite.
-- Spike: only for a named uncertainty with a time-box and go/no-go output.
-- Integration: only when earlier outputs are not already proven reachable.
-- Verification: only when separate ownership or evidence is genuinely required.
-- Release/packaging: only when explicitly in `scope_lock`.
-
-Merge slices that touch the same files, share one proof, or would otherwise
-produce an orphaned intermediate output.
-
-## Owner-before-consumer
-
-Every cross-task contract, invariant, schema transition, or recovery authority
-has exactly one owner task. All consumers reference its stable ID and depend
-directly or transitively on the owner. The typed dependency boundary is machine
-authority; Markdown and `task_registry.dependencies` are projections that must
-agree with it.
-
-## Lightweight phases
-
-Use phases only for a complex `Full` task graph where grouping materially helps
-navigation or sequencing. Persist them as lightweight task-ID groups in
-`spec.json`.
-
-- Never create `phase-*.md` files.
-- Never copy requirement, design, or task prose into a phase.
-- A phase does not replace dependency edges or ownership.
-- Compact specs and simple Full graphs omit phases.

package/src/claude/skills/specs/rules/task-scoring-rubric.md

@@ -1,52 +0,0 @@
-# Task Scoring Rubric (optional advisory)
-
-Load this rubric only when the persisted policy requires a task bundle and the
-decomposition has a real split/merge or dependency question. It is not a lane
-classifier, readiness gate, approval gate, or reason to create a task bundle.
-
-## Candidate dimensions
-
-Score each candidate from 0–3 only when the score will change a task decision:
-
-| Dimension | 0 | 1 | 2 | 3 |
-|---|---|---|---|---|
-| Dependency criticality | standalone | one predecessor | one slice blocked | core path blocked |
-| Implementation risk | routine | known pattern | complex integration | unproven/security |
-| Blast radius | isolated | feature-local | shared contract | critical boundary |
-| User value | internal | enables work | visible improvement | acceptance/launch |
-| Evidence confidence | proven | mostly proven | partial | low/no evidence |
-| Test burden | unit/smoke | component/integration | workflow | security/rollback |
-| File conflict | none | minor | shared module | overlapping ownership |
-| Scope creep | none | interpretation | adjacent behavior | unapproved contract |
-
-## Use of the result
-
-Use the result only to explain priority, split/merge, dependency order,
-parallel ownership, or proof depth. Prefer one task when one boundary and one
-proof path are enough. Split only for a real dependency, ownership boundary, or
-independent proof path.
-
-- Scope-creep score 3: stop and ask for scope approval.
-- Low evidence plus risk ≥2: consider a time-boxed spike, but do not create one
-  solely because a Cynefin label says `Complex`.
-- Blast radius 3: include rollback/negative-path proof.
-- File conflict ≥2: parallel eligibility remains false unless a typed parallel
-  boundary proves isolated ownership and disjoint resources.
-- High value plus dependency ≥2: schedule early only after real prerequisites.
-
-Cynefin is advisory discovery language. It may suggest a spike or research
-question; it never changes Direct/Standard/Critical, adds registry/DAG
-ceremony, or decides readiness.
-
-## Compact task metadata
-
-Do not copy the raw table into task files. Record only decisions that affect
-execution:
-
-- why the task is split or merged;
-- why it is early or deferred;
-- why it is or is not parallel;
-- why a spike or deeper proof is useful;
-- exact dependencies and evidence.
-
-If no decision changes, omit scoring entirely and keep the task packet compact.

package/src/claude/skills/specs/rules/tasks-generation.md

@@ -1,189 +0,0 @@
-# Task generation rules
-
-Load this file only after the task gate passes. Compact durable specs are
-taskless by default, but may have a task bundle and matching registry when a real
-ownership, dependency, durable transition, separate proof, or parallel
-coordination boundary activates the same gate used by Full specs. Full depth
-does not activate the gate by itself.
-
-## Generation gate
-
-A task must represent at least one real boundary: distinct ownership, a durable
-dependency, a state transition, separate proof, or parallel coordination. If no
-boundary exists, keep behavior in requirements/design and generate no task.
-
-Persist the audited topology only in typed `spec.json.coordination.boundaries`:
-
-- `ownership`: disjoint task write sets;
-- `dependency`: producer, consumer, and exact deliverable;
-- `transition`: owner/consumers plus pre/post/failure/recovery semantics;
-- `proof`: subject, verifier, verification ref, and verifier-owned artifact anchor;
-- `parallel`: independent tasks and exact resources.
-
-A task bundle requires at least one complete boundary. Legacy trigger fields,
-coordination flags, artifact flags, priority markers, and prose labels are
-read compatibility inputs and forbidden in schema 2.1 authoring. Optional
-phases may group task IDs but must reference a typed owner boundary.
-
-Use `phase-decision-matrix.md` only when split/merge boundaries remain unclear.
-Use the scoring rubric only as advisory input; scores, effort estimates, risk
-labels, and requirement count never make a task mandatory.
-
-## Default decomposition
-
-Prefer a vertical outcome slice that implements behavior through its real
-runtime entrypoint and proves the result. Split horizontally only when:
-
-- one owner must produce a contract, schema, or transition before consumers;
-- file or contract ownership must be disjoint;
-- a proof surface has a different durable owner; or
-- parallel work has no dependency or shared resource contention.
-
-Do not create foundation, integration, spike, testing, or release tasks by
-habit. A support output must be consumed by a named later task or identified as
-internal to the same vertical slice.
-
-## Task shape
-
-Each task contains exactly the information an implementer needs:
-
-1. **Outcome** — observable behavior delivered by the task.
-2. **Scope** — exact in/out behavior boundary.
-3. **Anchors and Ownership** — one six-column ownership projection.
-4. **Changes** — behavior and code changes, including relevant negative paths.
-5. **Acceptance** — measurable requirement IDs and task-local outcomes.
-6. **Dependencies** — projection of typed dependency boundaries or `none`.
-7. **Verification Plan** — command/inspection, expected result, negative path,
-   runtime reachability, exact design `V` ID, and task role when applicable.
-
-Do not add estimated effort, empty risk tables, receipt fields, Base/Head,
-verdicts, provenance, agent chains, or generic completion ceremony.
-
-`**Status:**` is the canonical files-first lifecycle projection for each task.
-Its value must stay byte-for-byte equivalent in meaning to
-`spec.json.task_registry[path].status`; use the same exact canonical token in
-both places. Allowed values are `pending`, `in_progress`, `blocked`, and `done`.
-Authoring initializes tasks as `pending`. A later lifecycle transition updates
-the task Markdown and registry together. `done` proof remains owned by execution
-closeout; do not add receipts, Evidence sections, Base/Head bindings, verdicts,
-or provenance to the task plan.
-
-## Typed anchors
-
-The task's only ownership table is `ID | Type | Target | Role | Access |
-Action`. IDs are unique across the spec. `Access` is `read` or `write`; read
-requires `Action=read`, while write requires `create`, `modify`, or `delete`.
-Targets are exact and grounded, never globs or parent-directory claims. Allowed
-types are `file`, `symbol`, `command`, `route`, `schema`, `contract`, `artifact`,
-and `external`.
-
-- Files-first: list exact `file` anchors before anchors contained by those files.
-- Task-owned anchors use `A-R{requirement}-{sequence}-NN`, populated from the
-  canonical task ID; their counter is local to that namespace, not globally
-  reused as an unnamespaced counter.
-- When the task only consumes a target already anchored by design, reference the
-  canonical `A-D-NN` anchor instead of creating another anchor for that target.
-- `Modify`, `Delete`, and `Read` paths must exist when authored; `Create` paths
-  need a grounded parent/boundary.
-- A symbol target names or references its containing file.
-- A command target is copied from real project tooling, not invented.
-- A contract anchor references its stable design ID; never copy the contract
-  body into the task.
-- Duplicate IDs anywhere in design or tasks block readiness.
-
-## Contracts, ownership, and dependencies
-
-Each cross-task contract, invariant, schema transition, or recovery authority
-has exactly one owner task. Every consumer:
-
-- references the named contract/invariant ID;
-- depends directly or transitively on the owner; and
-- does not redefine the canonical body.
-
-Each `RN.M` has exactly one implementation owner. A proof boundary means its
-subject implements the product criterion and its verifier verifies the referenced
-`V` definition through a separately owned proof criterion/artifact. The verifier
-must not repeat the subject's criterion in `Acceptance`; sharing a proof boundary
-does not create a second implementation owner. Their shared V definition names
-both exact criteria so subject, verifier, and proof boundary resolve to one
-verification contract.
-
-Task Markdown and `spec.json.task_registry[path]` must keep both `status` and
-`dependencies` synchronized. Derive task ID from
-`tasks/task-R{N}-{SEQ}-<slug>.md`; use two-digit `SEQ`. Do not create shorthand
-filenames.
-
-Parallel eligibility exists only when a typed `parallel` boundary proves exact
-disjoint resources, no dependency path, and no shared transition/proof
-authority. Do not author a parallel-priority marker.
-
-## Changes and acceptance
-
-Describe product behavior and the code boundary together. Name exact validation,
-state, route, schema, error, and integration behavior only when relevant. Keep
-all work inside `scope_lock`; an expansion pauses for explicit user approval.
-
-Map acceptance to numeric `N.M` IDs from `requirements.md`. Include negative or
-error outcomes where invalid input, missing permission, failure, conflict,
-timeout, retry, rollback, or recovery is relevant. Do not add vague acceptance
-such as “works”, “safe”, or “performant”.
-
-## Verification plan
-
-Choose proportional proof for the changed surface:
-
-- exact command-shaped invocation or justified `N/A`;
-- expected exit, output, state, artifact, or UI result;
-- contract-preserving negative-path check when relevant; and
-- real entrypoint/caller for runtime-facing work, or the exact dependent task
-  that will establish reachability.
-
-Declare exactly `Verification ref: Vn` and `Task role: subject` or `Task role:
-verifier`. The V definition lives once in `design.md` using the canonical
-single-line bold-ID syntax. The task references it and does not copy its body.
-
-Every executable implementation task must declare concrete test ownership: at
-least one `file` or `artifact` anchor with `write` `create` or `modify` that is
-the focused test, or share proof through a typed `proof` boundary whose
-verifier owns the separate proof artifact. A generic `npm test` string alone
-is not ownership; shared proof without a typed boundary is not ownership.
-
-Access/action reachability is deterministic:
-
-| Access | Allowed Action | Grounding meaning |
-|---|---|---|
-| `read` | `read` | Exact target already exists and is inspected/consumed. |
-| `write` | `modify` or `delete` | Exact target already exists and is owned by this task. |
-| `write` | `create` | Exact target is absent and its parent/boundary is grounded. |
-
-Commands, symbols, contracts, routes, schemas, artifacts, and external targets
-also receive their type-specific grounding check. Grounding is mandatory before
-readiness; the deterministic validator/grounder recompute facts and never create
-an extra receipt or claim semantic judgment.
-
-Build success alone is not behavior proof. Static validation may check command
-shape and anchors, but execution owns actual runtime proof.
-
-`feature-receipt.md` is created only during execution closeout. Never create or
-reference it as a spec-ready requirement.
-
-Every physical task participates in at least one justified typed boundary.
-Ownership and parallel resource maps are keyed exactly by their participants,
-contain non-empty unique exact targets, and equal the task write anchors they
-claim. An ownership boundary is truthful only when at least two physical tasks
-have distinct, non-overlapping exact write anchors. A dependency boundary must match
-the registry DAG and producer-write/consumer-read anchors. Proof, transition,
-and parallel boundaries must satisfy their typed fields; labels never suffice.
-
-## Task graph and phases
-
-When a task bundle exists:
-
-- cover every scoped acceptance criterion exactly where it is implemented or
-  proven;
-- keep owner-before-consumer ordering explicit;
-- rebuild registry inventory from physical task files before readiness; and
-- use optional phases only as compact task-ID groups in `spec.json` for a
-  complex Full graph.
-
-Never create phase files or repeat task prose in phase metadata.

package/src/opencode/AGENTS.md

@@ -1,41 +0,0 @@
-Primary operating instructions for OpenCode using the CafeKit runtime.
-
-## OpenCode Runtime Mapping
-
-- Project instructions live in `AGENTS.md`.
-- CafeKit commands live in `.opencode/commands/` and use OpenCode-native slash names.
-- CafeKit agents live in `.opencode/agents/` using OpenCode frontmatter.
-- CafeKit skills live in `.opencode/skills/` and are read natively by OpenCode; edit project-local skills there.
-- Run Python skill scripts with the project venv:
-  - macOS/Linux: `.opencode/skills/.venv/bin/python3 scripts/<script>.py`
-  - Windows: `.opencode\\skills\\.venv\\Scripts\\python.exe scripts\\<script>.py`
-- Support files live in `.opencode/rules/`, `.opencode/scripts/`, `.opencode/references/`, and `.opencode/runtime.json`.
-- OpenCode config is merged into `opencode.json`; keep project model/provider choices there.
-
-## Command surface
-
-Use these OpenCode commands without the `hapo:` prefix:
-
-- `/question <question>`: answer from repository evidence first.
-- `/brainstorm <idea-or-problem>`: narrow unclear ideas before specs.
-- `/specs <feature-or-spec-command>`: create, update, validate, or approve specs.
-- `/develop <feature> [task-file] [--flash]`: implement approved spec tasks.
-- `/test [scope|--full]`: verify implementation and collect evidence.
-- `/code-review [scope|--pending]`: review correctness and regressions.
-- `/debug <issue>` and `/hotfix <issue>`: diagnose, then apply narrow fixes.
-
-The underlying CafeKit skills are still named `hapo:*` in their documentation.
-
-## OpenCode limits
-
-Claude Code hooks, statusline, and settings do not run in OpenCode. Map Claude-only tools to OpenCode built-ins: `TodoWrite` → `todowrite`, `AskUserQuestion` → `question`, `Task` → the agent/subtask flow. The installed plugins under `.opencode/plugins/` provide the privacy, inspect-scope, spec-state, scaffold-guard, session-state, and docs-sync gates; other Claude runtime behavior has no OpenCode equivalent.
-
-The installed `spec-gate` plugin uses the cancellable `tool.execute.before` hook to hard-block supported completion/state tools (`task`, `taskupdate`, and `todowrite`) with a controlled `CAFEKIT_SPEC_GATE_BLOCKED` result when shared policy/resolver or receipt evidence is invalid or unavailable. Receipt-repair tools remain available where the host boundary permits correction.
-
-OpenCode does not expose a cancellable `session.idle`/Stop hook or final assistant-turn cancellation boundary. Those event and prompt-injection paths are observational only; do not claim full-turn parity with Claude/Codex.
-
-## Combined-install boundary
-
-OpenCode's native project instruction surface is root `AGENTS.md`. Combined installs keep this OpenCode block there because CafeKit has not proven a separate project instruction entrypoint for OpenCode. Other runtimes may read the same root file; this shared-root trade-off is intentional and must not be treated as filesystem isolation.
-
-**Ownership / ignore contract (fail-safe):** This OpenCode block is owned by OpenCode only. If you are Claude Code, Codex CLI, or any other runtime, ignore this entire OpenCode block and consume only CORE plus your native block. If you cannot determine which block is yours, treat the file as CORE-only. Do not treat another runtime's block as instructions.