yaaw-se 0.3.7 → 0.3.8

package/dist/payload/skills/yaaw-prd/SKILL.md

@@ -2,9 +2,13 @@
 name: yaaw-prd
 description: Create or continue YAAW product definition, challenge material product assumptions, and route clarification or revision work.
 ---
-# YAAW PRD
+# yaaw-prd
 ROLE: `prd`
 WORKFLOW: `prd.route`
+INTENT: `CONTINUE_PRODUCT`
 
 ## Execute
-Load `.yaaw-core/system/roles/prd.md`, resolve `prd.route` through `.yaaw-core/system/registries/workflows.json`, then execute that canonical workflow. Keep semantic behavior in `.yaaw-core/system/`; this skill is only an entrypoint.
+Resolve the YAAW workspace root, then invoke:
+`node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT> --invoke-skill yaaw-prd`
+
+Follow `orchestration.route` until `PRODUCT_READY` is satisfied or a human-input, BLOCKED, or framework stop occurs. Do not execute prd semantics directly from this wrapper; every semantic execution requires the exact runtime handoff.

package/dist/payload/skills/yaaw-refine-prd/SKILL.md

@@ -2,9 +2,13 @@
 name: yaaw-refine-prd
 description: Improve clarity and completeness of a YAAW product artifact without changing accepted product meaning.
 ---
-# YAAW Refine PRD
+# yaaw-refine-prd
 ROLE: `prd`
 WORKFLOW: `prd.refine`
+INTENT: `REFINE_PRODUCT`
 
 ## Execute
-Load `.yaaw-core/system/roles/prd.md`, resolve `prd.refine` through `.yaaw-core/system/registries/workflows.json`, then execute that canonical workflow. Keep semantic behavior in `.yaaw-core/system/`; this skill is only an entrypoint.
+Resolve the YAAW workspace root, then invoke:
+`node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT> --invoke-skill yaaw-refine-prd`
+
+Follow `orchestration.route` until `PRODUCT_REFINED` is satisfied or a human-input, BLOCKED, or framework stop occurs. Do not execute prd semantics directly from this wrapper; every semantic execution requires the exact runtime handoff.

package/dist/payload/skills/yaaw-repair/SKILL.md

@@ -2,9 +2,13 @@
 name: yaaw-repair
 description: Repair a YAAW ticket in REPAIR_REQUIRED state while preserving its accepted product and engineering contract.
 ---
-# YAAW Repair
+# yaaw-repair
 ROLE: `implementer`
 WORKFLOW: `implementation.repair-ticket`
+INTENT: `REPAIR`
 
 ## Execute
-Load `.yaaw-core/system/roles/implementer.md`, resolve `implementation.repair-ticket` through `.yaaw-core/system/registries/workflows.json`, then execute that canonical workflow. Keep semantic behavior in `.yaaw-core/system/`; this skill is only an entrypoint.
+Resolve the YAAW workspace root, then invoke:
+`node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT> --invoke-skill yaaw-repair`
+
+Follow `orchestration.route` until `TICKET_REVIEW_REQUIRED` is satisfied or a human-input, BLOCKED, or framework stop occurs. Do not execute implementer semantics directly from this wrapper; every semantic execution requires the exact runtime handoff.

package/dist/payload/skills/yaaw-review/SKILL.md

@@ -2,9 +2,13 @@
 name: yaaw-review
 description: Independently review actual YAAW implementation and classify PASS, REPAIR, REPLAN, or BLOCKED against current evidence.
 ---
-# YAAW Review
+# yaaw-review
 ROLE: `reviewer`
 WORKFLOW: `review.review-ticket`
+INTENT: `REVIEW`
 
 ## Execute
-Load `.yaaw-core/system/roles/reviewer.md`, resolve `review.review-ticket` through `.yaaw-core/system/registries/workflows.json`, then execute that canonical workflow. Keep semantic behavior in `.yaaw-core/system/`; this skill is only an entrypoint.
+Resolve the YAAW workspace root, then invoke:
+`node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT> --invoke-skill yaaw-review`
+
+Follow `orchestration.route` until `TICKET_REVIEW_APPLIED` is satisfied or a human-input, BLOCKED, or framework stop occurs. Do not execute reviewer semantics directly from this wrapper; every semantic execution requires the exact runtime handoff.

package/dist/payload/skills/yaaw-revise-prd/SKILL.md

@@ -2,9 +2,13 @@
 name: yaaw-revise-prd
 description: Change accepted YAAW product intent and invalidate downstream engineering contracts whose basis became stale.
 ---
-# YAAW Revise PRD
+# yaaw-revise-prd
 ROLE: `prd`
 WORKFLOW: `prd.revise`
+INTENT: `REVISE_PRODUCT`
 
 ## Execute
-Load `.yaaw-core/system/roles/prd.md`, resolve `prd.revise` through `.yaaw-core/system/registries/workflows.json`, then execute that canonical workflow. Keep semantic behavior in `.yaaw-core/system/`; this skill is only an entrypoint.
+Resolve the YAAW workspace root, then invoke:
+`node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT> --invoke-skill yaaw-revise-prd`
+
+Follow `orchestration.route` until `PRODUCT_REVISION_ADVANCED` is satisfied or a human-input, BLOCKED, or framework stop occurs. Do not execute prd semantics directly from this wrapper; every semantic execution requires the exact runtime handoff.

package/dist/payload/yaaw-core/system/core/dispatch-execution.md

@@ -1,65 +1,28 @@
 # Dispatch execution contract
 
-Dispatch is a semantic request to execute exactly one already-selected YAAW handoff using the strongest context-isolation mechanism the active host can safely provide.
+Dispatch executes exactly one already-selected semantic handoff.
 
 ## Canonical rules
-1. Orchestrator selects exactly one canonical workflow.
-2. Orchestrator persists one valid `.yaaw-core/runtime/handoff.json`.
-3. Under orchestrated operation, a non-Orchestrator semantic role should execute in a fresh isolated worker when the host provides that capability.
-4. The worker receives minimal bootstrap context: workspace root, semantic role, handoff path, and instructions to resolve the canonical role/workflow from YAAW registries.
-5. The worker reads durable YAAW state instead of depending on inherited planning conversation.
-6. One dispatch executes exactly one handoff.
-7. A worker may not route, spawn, or command another YAAW authority role.
-8. The worker persists the required durable artifact/state/evidence before returning.
-9. The worker returns only a legal typed result from the handoff/workflow contract.
-10. A worker message is an execution signal, not project truth.
-11. After worker completion, failure, interruption, or lost response, Orchestrator re-enters `orchestration.inspect-state` before selecting another semantic workflow.
-12. If the preferred execution mechanism is unavailable, the active host adapter may use an alternate mechanism only when it can preserve the configured effective authority execution profile; otherwise dispatch fails closed.
+1. Public skills first become durable runtime intent.
+2. Orchestrator validates framework health, applies at most one reconciliation, validates source currency, and persists one exact handoff.
+3. A non-Orchestrator authority executes that handoff using the active host adapter's supported isolation/profile mechanism.
+4. The authority writes its durable semantic output and returns one allowed typed result.
+5. A worker message is an execution signal, not project truth. After success, failure, interruption, or lost response, Orchestrator observes reality again before routing.
 
-## Direct invocation
-A user who directly invokes PRD, Planner, Implementer, or Reviewer has intentionally selected that role/workflow and may execute it in the current context. Isolation policy here governs **Orchestrator dispatch**, not the existence of direct public entrypoints.
-
-## Execution-context policy
-`.yaaw-core/system/registries/execution-policy.json` declares one of:
-- `ROOT_ONLY`: run in the active root Orchestrator context.
-- `ISOLATED_PREFERRED`: prefer a fresh worker; host fallback may run through another mechanism only when the adapter establishes execution-profile equivalence. A deliberately selected host `inline` mode is an explicit opt-out from per-role isolation.
-- `INLINE_ALLOWED`: current-context execution is explicitly acceptable.
-
-A future `ISOLATED_REQUIRED` value may be introduced only with a schema/version update. Host adapters may still expose a stricter local runtime mode that blocks instead of falling back.
+## Public invocation
+Direct public invocation does not bypass Orchestrator. For example, `yaaw-implement` means desired outcome `IMPLEMENT`; missing product/planning/spec/ticket prerequisites are resolved first, and the shortcut completes at `REVIEW_REQUIRED` rather than automatically reviewing.
 
 ## Fresh-context invariant
-An orchestrated Implementer execution context must never become the Reviewer execution context for the same work. Reviewer acceptance is an independent dispatch.
-
-## Failure and retry invariant
-If a worker started and later failed or disappeared, do not blindly start the same authority worker again. Inspect durable reality first because the worker may already have mutated the repository or written evidence.
-
-## Capability fallback invariant
-For Implementer and Reviewer only, a host adapter may declare a bounded capability fallback after repeated **execution** failures. This is not a semantic reroute.
-
-The Orchestrator owns `.yaaw-core/runtime/dispatch-failures.json` and updates it only after re-entering reality inspection. A failure counts only when:
-- a child started and failed, was interrupted, returned no response, or returned an unusable/illegal result;
-- post-failure inspection shows no durable progress attributable to that attempt; and
-- role, workflow, active artifact, source revisions, transition sequence, and repository basis are unchanged.
-
-Legal workflow results such as `REPAIR`, `REPLAN`, `BLOCKED`, or a real precondition result do not count as execution failures. Any durable progress or basis change resets the counter.
-
-When a configured threshold is reached, the next attempt may use the host's stronger fallback execution profile while preserving the exact role and handoff. The fallback receives one attempt on an unchanged basis. If that attempt also fails with no progress, stop with `BLOCKED:AUTHORITY_EXECUTION_FAILED` rather than entering an unbounded retry loop.
+An orchestrated Implementer execution context must never become the Reviewer execution context for the same work. A dead worker is not retried blindly; durable progress is inspected first.
 
 ## Authority execution profile fidelity invariant
-A host adapter owns provider/model execution selection, but it may not silently substitute a different effective authority profile.
-
-- The canonical handoff remains provider-neutral: role, workflow, artifacts, basis, and allowed results do not carry provider model identifiers.
-- Before dispatch, the adapter resolves the required effective execution profile for the selected authority and, when applicable, the configured capability-fallback variant.
-- Changing named worker -> generic worker is legal only when the generic path is already profile-equivalent or every mismatched profile dimension can be authoritatively corrected by the active spawn mechanism.
-- Changing worker -> inline execution is legal only when the current/root execution profile is provably equivalent to the required authority profile. A user-selected host inline mode is the explicit exception because it deliberately opts out of per-role model isolation.
-- Model and reasoning dimensions are compared independently. A matching dimension needs no override; a mismatched dimension requires an authoritative override for that dimension.
-- Unknown inherited values remain symbolic. The adapter may treat two paths as equivalent when both resolve through the same `HOST_INHERIT` chain, but it must never guess that a concrete value equals an unknown inherited value.
-- If isolation exists but the host cannot guarantee the configured model/reasoning profile, stop with `BLOCKED:HOST_EXECUTION_PROFILE_UNAVAILABLE`.
-- If strict isolation is required and the host cannot create any isolated worker at all, stop with `BLOCKED:HOST_ISOLATION_UNAVAILABLE`.
-- A profile/isolation stop that occurs before child creation is a host precondition failure, not an authority execution failure. It must not increment `.yaaw-core/runtime/dispatch-failures.json` or trigger capability escalation.
-- Capability fallback uses the same resolver and fidelity rules as primary execution. If fallback selects a stronger profile, that exact effective profile must be preserved or dispatch blocks.
+Provider/model execution selection belongs to the active host adapter, but changing execution mechanism may not silently change the configured effective authority profile.
 
-The Orchestrator may route a configured profile through the adapter; it may not invent, weaken, or replace that profile.
+- `HOST_INHERIT` remains symbolic; unknown inherited model/reasoning values are never guessed.
+- If an execution mechanism exists but cannot guarantee the required profile, return `BLOCKED:HOST_EXECUTION_PROFILE_UNAVAILABLE`.
+- If strict isolation is required and no isolated mechanism exists, return `BLOCKED:HOST_ISOLATION_UNAVAILABLE`.
+- A profile/isolation stop before child creation means no authority worker ran and must not increment the execution-failure ledger.
+- Implementer/Reviewer capability fallback preserves the exact semantic role and handoff and is subject to the same profile-fidelity rule.
 
 ## Provider boundary
-This contract is provider-neutral. Names of host tools, agent types, provider directories, model identifiers, and provider-specific spawning schemas belong only to integration adapters.
+Provider/model mechanics remain adapter-owned. The canonical semantic path is provider-neutral and identical across supported host adapters.

package/dist/payload/yaaw-core/system/core/invalidation.md

@@ -1,44 +1,13 @@
 # Invalidation propagation
 
-Accepted artifacts are historical records, not eternally valid truth. Prior reviews remain immutable historical evidence; current authority may become `STALE` without rewriting history.
+Prior reviews remain immutable historical evidence; current authority may become STALE without rewriting history.
 
-## Permanent rule
+## Contract staleness
+For executable ticket states `READY`, `IN_PROGRESS`, `REVIEW_REQUIRED`, `REPAIR_REQUIRED`, and `PASS`, compare ticket product/engineering/spec revisions to current adopted sources before dispatch. Stable causes are `PRODUCT_SOURCE_STALE`, `ENGINEERING_SOURCE_STALE`, `SPEC_SOURCE_STALE`, `TICKET_SOURCE_STALE`, and `CONTRACT_INVALIDATED`. Their route is read from `routing-policy.json`; the current contract route is `REPLAN_REQUIRED`, and Orchestrator does not hard-code a second destination.
 
-**A stale contract and stale acceptance are not the same thing.**
+## Acceptance staleness
+When source meaning remains current but current PASS verification/review repository identity is missing, stale, or legacy-unverifiable, preserve history and return current lifecycle authority to `REVIEW_REQUIRED`. Stable causes are `REVIEW_MISSING`, `REVIEW_REPOSITORY_STALE`, `VERIFICATION_MISSING`, `VERIFICATION_REPOSITORY_STALE`, and `LEGACY_IDENTITY_UNVERIFIABLE`.
 
-## Acceptance invalidation
-If product/engineering/spec/ticket meaning remains current but review or verification proof is missing, repository-stale, or cannot be reproduced, preserve historical reviews and reconcile current acceptance to `REVIEW_REQUIRED`.
+Repository identity mismatch alone never proves an architecture replan is required.
 
-Repository identity mismatch alone does not establish `REPLAN_REQUIRED`. Reviewer may return `PASS`, `REPAIR`, `REPLAN`, or `BLOCKED`.
-
-Stable acceptance causes: `REVIEW_MISSING`, `REVIEW_REPOSITORY_STALE`, `VERIFICATION_MISSING`, `VERIFICATION_REPOSITORY_STALE`, `LEGACY_IDENTITY_UNVERIFIABLE`.
-
-## Framework integrity is not project invalidation
-Package-managed framework drift is neither contract invalidation nor acceptance invalidation. It means the execution engine is untrusted. Stop orchestration with the typed framework failure and use installer repair. Do not route framework drift to Planner or Reviewer and do not change ticket lifecycle state to encode it.
-
-Result: `PASS -> REPLAN_REQUIRED`.
-
-Next semantic owner: Planner.
-
-### Acceptance invalidation
-The source contract remains current, but review or verification proof is missing, repository-stale, or cannot be reproduced under the canonical identity algorithm.
-
-Result: `PASS -> REVIEW_REQUIRED`.
-
-Next semantic owner: Reviewer.
-
-Repository identity mismatch alone does not establish `REPLAN_REQUIRED`. The Orchestrator may mechanically invalidate trust, but it must not decide that current code satisfies the contract or that architecture is invalid.
-
-Reviewer may then return `PASS`, `REPAIR`, `REPLAN`, or `BLOCKED`.
-
-## Stable cause IDs
-
-Contract causes: `PRODUCT_SOURCE_STALE`, `ENGINEERING_SOURCE_STALE`, `SPEC_SOURCE_STALE`, `TICKET_SOURCE_STALE`, `CONTRACT_INVALIDATED`.
-
-Acceptance causes: `REVIEW_MISSING`, `REVIEW_REPOSITORY_STALE`, `VERIFICATION_MISSING`, `VERIFICATION_REPOSITORY_STALE`, `LEGACY_IDENTITY_UNVERIFIABLE`.
-
-Every invalidation records a stable cause plus human-readable evidence. Runtime-looking paths are not automatically acceptance-irrelevant.
-
-## Framework integrity is not acceptance invalidation
-
-Package-managed framework drift is neither contract invalidation nor acceptance invalidation. It means the execution engine is not trusted. Stop orchestration with the typed framework failure and use installer repair. Do not route framework drift to Planner or Reviewer and do not change ticket lifecycle state to encode it.
+Framework drift is neither contract nor acceptance invalidation. It stops orchestration fail-closed for installer repair.

package/dist/payload/yaaw-core/system/core/io-contract.md

@@ -1,56 +1,23 @@
 # Role I/O and communication contract
 
-YAAW roles communicate through durable artifacts, exact Orchestrator handoffs, and typed results. Roles do not privately command peer roles.
+YAAW roles communicate through durable artifacts, exact Orchestrator handoffs, and typed results. Roles never privately command peer roles.
 
 ## Machine truth
-- `.yaaw-core/system/registries/artifacts.json` defines canonical artifact classes, locations, durability, and semantic ownership.
-- `.yaaw-core/system/registries/role-io.json` defines each role's default read/write authority.
-- `.yaaw-core/system/registries/workflows.json` maps canonical workflow IDs to one role/workflow contract.
-- `.yaaw-core/system/registries/execution-policy.json` defines repository requirements, execution-context policy, and context/research admission for every workflow.
-- `.yaaw-core/runtime/handoff.json` resolves those contracts to one exact dispatch.
-- `.yaaw-core/runtime/intent.json` may preserve the public entrypoint's desired destination while prerequisites are resolved.
+Registries define artifact ownership, role I/O, workflow mapping, execution policy, public intent, reconciliation policy, and exact handoff construction.
 
-## Dispatch contract
-Every semantic-role handoff records exact reads, writes, forbidden writes, current revisions, selected expertise, repository requirement/basis, desired intent, expected durable output, and allowed result vocabulary.
-
-The role reads the handoff, then its role contract, resolves `handoff.workflow` through the workflow registry, and only then loads the selected workflow and exact admitted context.
-
-A role must not search the repository for alternate YAAW artifact locations when a canonical input is missing. Missing or stale canonical prerequisites produce a typed result to Orchestrator.
-
-Host execution transport is separate from semantic communication. A semantic role may run in another fresh host context, but authority still flows only through durable YAAW artifacts and typed results.
+## Public-entry invariant
+Every public skill is an intent entrypoint. It invokes `orchestration-runtime.mjs --invoke-skill <skill>`; it does not execute semantic role logic directly. Intent may prefer a destination, but it never bypasses framework health, reconciliation, source-current checks, repository policy, or handoff construction.
 
 ## Communication topology
 ```text
-PRD / Planner / Implementer / Reviewer
-        ↓ durable output + typed result
-     Orchestrator
-        ↓ inspect reality
-        ↓ exactly one next dispatch
+public intent
+   -> Orchestrator observes/reconciles
+   -> one exact handoff
+   -> PRD / Planner / Implementer / Reviewer durable output
+   -> Orchestrator observes again
 ```
 
-Roles never spawn or command peer roles. **Roles report reality; Orchestrator decides routing.**
-
-A worker's textual success message is not semantic truth. Orchestrator verifies the expected artifact, revision, repository/evidence basis, and legal state transition after every dispatched execution.
-
-## Typed results
-Common results include `SUCCESS`, `READY`, `HUMAN_INPUT_REQUIRED`, `PRECONDITION_UNSATISFIED`, `REVIEW_REQUIRED`, `REPLAN_REQUIRED`, `BLOCKED`, `PASS`, `REPAIR`, `REPLAN`, and `COMPLETE`.
-
-Framework-level stop results are `FRAMEWORK_INTEGRITY_VIOLATION`, `FRAMEWORK_INTEGRITY_UNKNOWN`, and `FRAMEWORK_CONTRACT_INCONSISTENCY`. They are installation/runtime trust failures, not ticket lifecycle states, and must not be represented by fabricating a ticket transition.
-
-Host-execution stop results are `HOST_ISOLATION_UNAVAILABLE`, `HOST_EXECUTION_PROFILE_UNAVAILABLE`, and `AUTHORITY_EXECUTION_FAILED`. They describe execution transport/capability failures, not semantic workflow outcomes or ticket lifecycle states.
-
-- `HOST_ISOLATION_UNAVAILABLE`: strict isolation was required, but the host could not create an isolated worker.
-- `HOST_EXECUTION_PROFILE_UNAVAILABLE`: an execution mechanism existed, but the host could not guarantee the configured effective authority model/reasoning profile.
-- `AUTHORITY_EXECUTION_FAILED`: the correct authority execution actually started and failed under the bounded retry/fallback policy.
-
-A host isolation/profile stop raised before child creation is a pre-execution host failure: no authority worker ran, so it must not be counted as an authority execution failure.
-
-`PRECONDITION_UNSATISFIED` includes a reason such as `NO_PRODUCT`, `PLANNING_UNREADY`, `SPEC_MISSING`, `NO_READY_TICKET`, `STALE_SOURCE`, or `REPOSITORY_IDENTITY_UNAVAILABLE`.
-
-A missing ticket never authorizes Implementer to create one. Implementer returns `PRECONDITION_UNSATISFIED:NO_READY_TICKET`; Orchestrator routes Planner.
-
-## Framework write invariant
-No semantic-role handoff may admit `.yaaw-core/system/**` as a write surface. If a role discovers a contradiction in the package-managed framework, it returns a typed framework failure to Orchestrator. Installer repair is the only supported package mutation path.
+Worker text is an execution signal, not project truth. Filesystem access never grants semantic authority.
 
-## Authority invariant
-Filesystem access never grants semantic authority. A role may detect an invalid upstream contract but returns control to its owner instead of rewriting it.
+## Host-execution typed stops
+`HOST_EXECUTION_PROFILE_UNAVAILABLE` means an execution mechanism existed, but it could not guarantee the configured authority profile. `HOST_ISOLATION_UNAVAILABLE` means strict isolation was required but unavailable. When either stop happens before child creation, no authority worker ran, so it is not an authority execution failure.

package/dist/payload/yaaw-core/system/core/lifecycle.md

@@ -1,28 +1,21 @@
 # Lifecycle contract
 
-YAAW advances only through evidence-backed workflow boundaries.
+YAAW advances only through durable facts adopted by Orchestrator.
 
 ```text
 product missing/unready -> PRD
 product ready, planning unresolved -> Planner
-planning ready, spec missing -> create spec
-spec accepted, tickets missing -> create tickets
-READY -> Implementer
-IN_PROGRESS -> recovery/continue
-REVIEW_REQUIRED -> Reviewer
-REPAIR_REQUIRED -> Implementer repair -> REVIEW_REQUIRED
-REPLAN_REQUIRED -> Planner
-PASS -> next admitted work
-all accepted scope current -> COMPLETE
+planning ready, spec missing -> create/adopt spec
+spec accepted, tickets missing -> create/register tickets
+READY -> implementation_start fact -> IN_PROGRESS
+IN_PROGRESS -> PASS verification fact -> REVIEW_REQUIRED
+REVIEW_REQUIRED -> immutable Reviewer result -> PASS | REPAIR_REQUIRED | REPLAN_REQUIRED | BLOCKED
+REPAIR_REQUIRED -> fresh PASS verification -> REVIEW_REQUIRED
+PASS + scope_status OPEN/UNKNOWN -> Planner
+all current tickets PASS/CANCELLED + scope_status COMPLETE -> COMPLETE
 ```
 
-## Accepted-but-stale
-A historical `PASS` whose source contract is still current but whose acceptance proof is stale becomes `REVIEW_REQUIRED`, not `REPLAN_REQUIRED`.
-
-## PASS meaning
-`PASS` means the currently observed repository/worktree state satisfies the current accepted ticket contract according to an independent Reviewer.
-
-It does not inherently mean committed, pushed, merged, or deployed. When accepted state is dirty, reporting must distinguish acceptance from persistence and disclose that the review basis is the current worktree.
+One reconciliation is applied per observation cycle; recovery never jumps directly from `READY` to `REVIEW_REQUIRED`.
 
 ## Fresh-context invariant
-Every workflow must be resumable from durable artifacts and repository evidence without previous chat history.
+Conversation may disappear at any point. Durable artifacts and repository evidence must still identify the correct next boundary.

package/dist/payload/yaaw-core/system/core/recovery.md

@@ -1,29 +1,15 @@
-# Recovery policy
+# Recovery contract
 
-Recovery compares claimed state with observed reality and returns to the last trustworthy boundary.
+Recovery reconstructs the last trustworthy durable boundary; conversation loss is never permission to repeat semantic work.
 
-## Framework precondition
-Framework integrity is checked before project recovery. If `.yaaw-core/system/core/framework-integrity.md` is not `HEALTHY`, stop with `FRAMEWORK_INTEGRITY_VIOLATION`, `FRAMEWORK_INTEGRITY_UNKNOWN`, or `FRAMEWORK_CONTRACT_INCONSISTENCY` as appropriate. Do not repair project lifecycle state while the governing package is untrusted, and never edit package-managed framework files as a recovery action. Resolve the workspace root first and use only root-anchored, workspace-scoped repository evidence from `.yaaw-core/system/core/execution-context.md`.
+- Accepted current spec not reflected in state -> adopt exactly that spec; multiple candidates block.
+- Current ticket file absent from state -> register one ticket per reconciliation cycle.
+- `READY` plus valid implementation-start evidence -> `IN_PROGRESS`.
+- `IN_PROGRESS` plus current PASS verification -> `REVIEW_REQUIRED`.
+- `IN_PROGRESS` plus start evidence but no PASS verification -> `implementation.verify-ticket`.
+- `REVIEW_REQUIRED` plus a valid current immutable review -> adopt its result before another Reviewer dispatch.
+- Source drift -> use routing-policy invalidation, normally `REPLAN_REQUIRED`.
+- Source-current acceptance/repository drift -> `REVIEW_REQUIRED`.
+- Missing proof -> exact `BLOCKED`, never guessing.
 
-## Evidence authority
-- Product intent: current accepted `product.md` revision.
-- Engineering decisions: current `engineering.md` decisions and accepted non-stale specs.
-- Implementation reality: repository contents plus repository identity/diff history.
-- Acceptance: fresh review evidence tied to the exact ticket/spec revisions and repository identity.
-- Routing cache: `state.json`, reconciled against stronger evidence.
-
-## Rules
-- Never reimplement solely because state is stale.
-- `IN_PROGRESS` + implementation + required verification evidence + no review -> reconcile to `REVIEW_REQUIRED`.
-- `READY` + implementation already present -> inspect/recover rather than duplicate the change.
-- `PASS` + source/contract revision mismatch -> reconcile to `REPLAN_REQUIRED`.
-- `PASS` + source-current missing/stale/unreproducible review or verification basis -> reconcile to `REVIEW_REQUIRED`.
-- Repository identity mismatch alone invalidates acceptance proof, not planning meaning. Never route a source-current PASS to Planner solely because repository identity changed.
-- A stale `.yaaw-core/runtime/handoff.json` is discarded, not executed.
-- If repository identity is required but status is not `READY`, return `PRECONDITION_UNSATISFIED:REPOSITORY_IDENTITY_UNAVAILABLE` or `BLOCKED` with exact missing proof.
-- If a dispatched worker ends unexpectedly, returns no response, loses its context, or its response is lost, treat that as an ordinary context interruption: inspect durable artifacts/repository/evidence and route from reality.
-- Never blindly retry a worker that was successfully created; first determine whether it already produced durable effects.
-- Do not persist host worker/session IDs into durable project memory. Replaceable coordination data, if ever required, belongs under `.yaaw-core/runtime/`.
-- If the last trustworthy boundary cannot be proven, return `BLOCKED` with exact missing proof.
-
-Every reconciliation uses a legal transition and records its reason/evidence in state provenance.
+Each observation applies at most one legal reconciliation and increments transition provenance once.

package/dist/payload/yaaw-core/system/core/routing.md

@@ -1,36 +1,21 @@
 # Routing contract
 
-Routing chooses exactly one next canonical workflow from observed reality. Explicit state beats broad heuristics. Workflow selection is metadata-first; target workflow bodies are loaded only after selection.
+Routing chooses exactly one next canonical workflow from observed durable reality. Production semantics live in `.yaaw-core/system/tools/orchestration-engine.mjs`; `orchestration-runtime.mjs` is the filesystem/CLI shell.
 
-The machine implementation of this precedence is `.yaaw-core/system/tools/orchestration-runtime.mjs`, driven by `.yaaw-core/system/registries/routing-policy.json`. Orchestrator consumes the tool's typed route instead of manually replaying the precedence with shell commands or model reasoning.
-
-Before any semantic routing, require framework integrity `HEALTHY` under `.yaaw-core/system/core/framework-integrity.md`. Framework drift is not repository drift and never routes to Planner, Implementer, or Reviewer. It stops execution until installer repair restores the package boundary.
-
-Before dispatch, enforce the selected workflow repository requirement from `.yaaw-core/system/registries/execution-policy.json`. `IDENTITY` workflows require repository status `READY`; `INSPECT` workflows may represent an `UNVERSIONED` workspace; `NONE` workflows do not require Git.
+Before semantic routing:
+1. framework integrity must be `HEALTHY`;
+2. apply at most one highest-priority reconciliation, then observe again;
+3. validate ticket source currency;
+4. enforce repository requirement;
+5. consider public intent only as a destination preference.
 
 ## Priority
-1. Stop on unhealthy/unknown framework integrity or canonical framework-contract inconsistency.
-2. Resolve material state inconsistency or incomplete recovery before creating a semantic handoff.
-3. If accepted product intent is missing or newly invalidated, route to PRD.
-4. If a ticket is `REPLAN_REQUIRED`, route to `planning.replan`.
-5. If current engineering frontier is unresolved, route through `planning.route`.
-6. If a ready frontier lacks an accepted spec, route to `planning.create-spec`.
-7. If an accepted spec lacks executable tickets, route to `planning.create-tickets`.
-8. If a ticket is `REPAIR_REQUIRED`, route to `implementation.repair-ticket`.
-9. If a ticket is `REVIEW_REQUIRED`, route to `review.review-ticket`.
-10. If a ticket is `IN_PROGRESS`, use recovery evidence to continue safely or reconcile to the next proven boundary; never restart blindly.
-11. If a dependency-satisfied ticket is `READY`, route to `implementation.implement-ticket`.
-12. If all current tickets are `PASS`/`CANCELLED` but accepted product scope remains, route to `planning.route` for the next frontier.
-13. Declare `COMPLETE` only when the durable phase is complete and accepted scope is covered by fresh, non-stale acceptance evidence.
-
-## Tie breaking
-- Never review a `REPAIR_REQUIRED` ticket before repair.
-- Never implement a `REPLAN_REQUIRED` ticket.
-- Never preserve `PASS` after its acceptance basis becomes stale.
-- Never convert repository drift into replan without independent contract invalidation evidence.
-- When evidence is insufficient to choose safely, route to recovery and ultimately `BLOCKED` rather than guessing.
-
-## Conformance rule
-Behavioral fixtures and the deterministic runtime may reconcile/route only transitions explicitly justified by durable/repository evidence. They must never make product or architecture decisions.
-
-The Orchestrator selects/consumes the route; the target role owns semantic work inside it.
+1. If a ticket is `REPLAN_REQUIRED`, route Planner.
+2. If a ticket is `REPAIR_REQUIRED`, route bounded repair.
+3. If a ticket is `REVIEW_REQUIRED`, route Reviewer unless a valid durable review result must first be adopted.
+4. If a ticket is `IN_PROGRESS`, current PASS verification is adopted; otherwise valid start evidence routes standalone verification, never blind reimplementation.
+5. If a dependency-satisfied ticket is `READY`, route Implementer.
+6. Missing current spec/tickets route Planner prerequisites.
+7. When all current tickets are `PASS`/`CANCELLED`, `scope_status COMPLETE` permits completion; `OPEN` or `UNKNOWN` routes Planner.
+
+Intent never skips these rules. `yaaw-implement` from an idea-only project can therefore route PRD -> planning -> spec -> tickets -> implementation while preserving desired outcome IMPLEMENT.

package/dist/payload/yaaw-core/system/core/state-model.md

@@ -1,34 +1,14 @@
 # State model
 
-Canonical machine-readable project state is `.yaaw-core/project/state.json` using `yaaw.project-state/v1`.
+Canonical project state is `.yaaw-core/project/state.json` using `yaaw.project-state/v2`.
 
-State is a routing cache and claim ledger. It is never trusted blindly over stronger domain evidence.
-
-## Lifecycle authority
-For routing and workflow preconditions, `.yaaw-core/project/state.json` `tickets[TASK-NNN]` is the current lifecycle ledger. Ticket frontmatter `status` is artifact metadata/admission history and may retain an earlier value after later lifecycle transitions; it does not override the reconciled state ledger.
-
-Roles whose workflow depends on lifecycle status must receive `state` in their read set. Orchestrator reconciles the ledger against stronger artifact, review, evidence, and repository reality before dispatch.
+State is a routing/adoption ledger, not semantic authority. Ticket frontmatter is admission/history metadata and never overrides the reconciled ticket lifecycle value in state.
 
 ## State writer
-Orchestrator is the physical writer of `state.json`. A transition's role owner remains the semantic decision authority. Reviewer decides `PASS`/`REPAIR`/`REPLAN`/`BLOCKED` in an immutable review; Orchestrator validates that durable result and records exactly the corresponding lifecycle transition and provenance. Orchestrator may not substitute its own acceptance judgment.
-
-## Ticket states
-`DRAFT`, `READY`, `IN_PROGRESS`, `REVIEW_REQUIRED`, `REPAIR_REQUIRED`, `REPLAN_REQUIRED`, `BLOCKED`, `PASS`, `CANCELLED`.
-
-## Project phases
-`product`, `planning`, `implementation`, `complete`, `blocked`.
-
-## Required provenance
-Every mutation increments `transition_sequence` and writes `last_transition` with:
-- subject (`project` or `TASK-NNN`);
-- from/to state;
-- canonical workflow ID;
-- reason;
-- evidence references;
-- observed repository commit when available.
-
-`BLOCKED` state records a blocker summary and exact missing evidence/decision.
+Orchestrator is the only physical writer of `state.json`. Semantic roles create durable facts: Planner creates engineering/spec/ticket facts, Implementer creates start/verification evidence, Reviewer creates immutable review results. Orchestrator validates and adopts those facts through legal transitions.
 
-`.yaaw-core/runtime/observed-state.json` and `.yaaw-core/runtime/handoff.json` are replaceable caches used to survive interruption inside orchestration. Their bases must be revalidated before use.
+## Planning completion
+`planning.scope_status` mirrors Planner-owned `engineering.md`: `UNKNOWN`, `OPEN`, or `COMPLETE`. Orchestrator never infers COMPLETE from absence of runnable tickets.
 
-Legal transitions are defined in `core/transitions.md`.
+## Provenance
+Every adopted mutation increments `transition_sequence` and records subject, from/to, workflow, reason, evidence, and observed commit.