yaaw-se 0.3.3 → 0.3.4

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (52) hide show
  1. package/dist/cli/commands/install.js +1 -1
  2. package/dist/cli/commands/install.js.map +1 -1
  3. package/dist/installer/status.js +74 -0
  4. package/dist/installer/status.js.map +1 -1
  5. package/dist/installer/verify.d.ts +2 -1
  6. package/dist/installer/verify.js +6 -2
  7. package/dist/installer/verify.js.map +1 -1
  8. package/dist/integrations/codex-runtime.d.ts +39 -0
  9. package/dist/integrations/codex-runtime.js +89 -0
  10. package/dist/integrations/codex-runtime.js.map +1 -1
  11. package/dist/integrations/codex.js +103 -16
  12. package/dist/integrations/codex.js.map +1 -1
  13. package/dist/payload/integrations/codex/yaaw-runtime.md +38 -10
  14. package/dist/payload/payload-files.json +95 -55
  15. package/dist/payload/payload.json +1 -1
  16. package/dist/payload/yaaw-core/system/core/context-loading.md +12 -8
  17. package/dist/payload/yaaw-core/system/core/dispatch-execution.md +18 -2
  18. package/dist/payload/yaaw-core/system/core/execution-context.md +31 -23
  19. package/dist/payload/yaaw-core/system/core/invalidation.md +29 -12
  20. package/dist/payload/yaaw-core/system/core/io-contract.md +8 -0
  21. package/dist/payload/yaaw-core/system/core/lifecycle.md +11 -16
  22. package/dist/payload/yaaw-core/system/core/routing.md +7 -7
  23. package/dist/payload/yaaw-core/system/core/transitions.md +2 -5
  24. package/dist/payload/yaaw-core/system/registries/handoff-policy.json +85 -0
  25. package/dist/payload/yaaw-core/system/roles/orchestrator.md +16 -14
  26. package/dist/payload/yaaw-core/system/rules/repository-identity.md +31 -17
  27. package/dist/payload/yaaw-core/system/schemas/evidence-v1.schema.json +28 -0
  28. package/dist/payload/yaaw-core/system/schemas/evidence-v2.schema.json +19 -0
  29. package/dist/payload/yaaw-core/system/schemas/evidence.schema.json +20 -31
  30. package/dist/payload/yaaw-core/system/schemas/repository-identity.schema.json +47 -0
  31. package/dist/payload/yaaw-core/system/schemas/review-v1.schema.json +19 -0
  32. package/dist/payload/yaaw-core/system/schemas/review-v2.schema.json +17 -0
  33. package/dist/payload/yaaw-core/system/schemas/review.schema.json +26 -13
  34. package/dist/payload/yaaw-core/system/templates/evidence.json +19 -2
  35. package/dist/payload/yaaw-core/system/templates/handoff.json +9 -15
  36. package/dist/payload/yaaw-core/system/templates/observed-state.json +13 -1
  37. package/dist/payload/yaaw-core/system/templates/review.md +14 -5
  38. package/dist/payload/yaaw-core/system/tools/orchestration-runtime.mjs +689 -0
  39. package/dist/payload/yaaw-core/system/tools/repository-identity.mjs +92 -0
  40. package/dist/payload/yaaw-core/system/workflows/implementation/implement-ticket.md +4 -0
  41. package/dist/payload/yaaw-core/system/workflows/implementation/repair-ticket.md +4 -0
  42. package/dist/payload/yaaw-core/system/workflows/implementation/verify-ticket.md +3 -0
  43. package/dist/payload/yaaw-core/system/workflows/orchestration/determine-next-action.md +15 -15
  44. package/dist/payload/yaaw-core/system/workflows/orchestration/dispatch.md +22 -16
  45. package/dist/payload/yaaw-core/system/workflows/orchestration/inspect-state.md +12 -15
  46. package/dist/payload/yaaw-core/system/workflows/orchestration/recover-interruption.md +4 -0
  47. package/dist/payload/yaaw-core/system/workflows/orchestration/route.md +19 -11
  48. package/dist/payload/yaaw-core/system/workflows/planning/replan.md +4 -0
  49. package/dist/payload/yaaw-core/system/workflows/review/inspect-change.md +4 -1
  50. package/dist/tui/configuration-updates.js +12 -1
  51. package/dist/tui/configuration-updates.js.map +1 -1
  52. package/package.json +1 -1
@@ -3,16 +3,14 @@
3
3
  Load the smallest authoritative context needed for the current judgment.
4
4
 
5
5
  ## Progressive-disclosure invariant
6
- Workflow selection is metadata-first.
7
-
8
- A router may load its role contract, router workflow, workflow/execution registries, state/artifact metadata, and the minimum evidence needed to select one route. It must not preload sibling or downstream workflow bodies, their templates, or their expertise merely because they might be needed later.
6
+ Workflow selection is metadata-first. Normal Orchestrator preparation is performed by `.yaaw-core/system/tools/orchestration-runtime.mjs`, which reads only durable metadata and the machine registries needed to produce one typed route/handoff. The Orchestrator consumes that result and **must not preload sibling or downstream workflow bodies**, templates, or expertise merely because they might be needed later.
9
7
 
10
8
  After exactly one workflow is selected:
11
9
  1. resolve that workflow through `.yaaw-core/system/registries/workflows.json`;
12
10
  2. load its body;
13
- 3. load only its declared/current artifact references and applicable rules;
11
+ 3. load only handoff-declared/current artifact references and applicable rules;
14
12
  4. load selected expertise only after relevance is established;
15
- 5. load a template only when the selected workflow is actually going to create that artifact.
13
+ 5. load a template only when the selected workflow will create that artifact.
16
14
 
17
15
  After durable output, return to routing before opening another workflow contract.
18
16
 
@@ -44,9 +42,15 @@ role contract
44
42
  Do not automatically load every PRD revision, research artifact, ticket, review, expertise module, template, or the full repository.
45
43
 
46
44
  ## Canonical artifact discovery
47
- Exact YAAW reads come from the handoff/registries. Roles do not grep for alternate YAAW artifact locations. Repository/application exploration is allowed only when the selected workflow admits it.
45
+ Exact YAAW reads come from the deterministic handoff and registries. Roles do not grep for alternate YAAW artifact locations.
48
46
 
49
47
  ## Handoff freshness
50
- A handoff names exact artifact paths/revisions, read/write sets, selected expertise, repository requirement, observed repository basis, and transition sequence. Before executing it, verify those bases still match current reality. If they do not, discard the stale handoff and re-enter orchestration inspection.
48
+ A handoff binds exact artifact revisions, read/write sets, selected expertise, repository requirement, canonical repository identity, transition sequence, installed YAAW version, installation/project-state schema versions, and manifest digest.
49
+
50
+ Immediately before dispatch, run:
51
+
52
+ ```text
53
+ node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT> --check-handoff
54
+ ```
51
55
 
52
- Runtime handoffs, intent, and observed-state snapshots live under `.yaaw-core/runtime/`; they are coordination caches, not semantic sources of truth.
56
+ Only `HANDOFF_FRESH` may execute. A stale result discards the handoff and returns to orchestration preparation. Runtime handoffs, intent, and observed-state snapshots are coordination caches, not semantic sources of truth.
@@ -14,7 +14,7 @@ Dispatch is a semantic request to execute exactly one already-selected YAAW hand
14
14
  9. The worker returns only a legal typed result from the handoff/workflow contract.
15
15
  10. A worker message is an execution signal, not project truth.
16
16
  11. After worker completion, failure, interruption, or lost response, Orchestrator re-enters `orchestration.inspect-state` before selecting another semantic workflow.
17
- 12. If isolated execution is unavailable, the active host adapter applies its configured fallback policy.
17
+ 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.
18
18
 
19
19
  ## Direct invocation
20
20
  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.
@@ -22,7 +22,7 @@ A user who directly invokes PRD, Planner, Implementer, or Reviewer has intention
22
22
  ## Execution-context policy
23
23
  `.yaaw-core/system/registries/execution-policy.json` declares one of:
24
24
  - `ROOT_ONLY`: run in the active root Orchestrator context.
25
- - `ISOLATED_PREFERRED`: prefer a fresh worker; host fallback may run inline.
25
+ - `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.
26
26
  - `INLINE_ALLOWED`: current-context execution is explicitly acceptable.
27
27
 
28
28
  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.
@@ -45,5 +45,21 @@ Legal workflow results such as `REPAIR`, `REPLAN`, `BLOCKED`, or a real precondi
45
45
 
46
46
  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.
47
47
 
48
+ ## Authority execution profile fidelity invariant
49
+ A host adapter owns provider/model execution selection, but it may not silently substitute a different effective authority profile.
50
+
51
+ - The canonical handoff remains provider-neutral: role, workflow, artifacts, basis, and allowed results do not carry provider model identifiers.
52
+ - Before dispatch, the adapter resolves the required effective execution profile for the selected authority and, when applicable, the configured capability-fallback variant.
53
+ - 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.
54
+ - 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.
55
+ - Model and reasoning dimensions are compared independently. A matching dimension needs no override; a mismatched dimension requires an authoritative override for that dimension.
56
+ - 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.
57
+ - If isolation exists but the host cannot guarantee the configured model/reasoning profile, stop with `BLOCKED:HOST_EXECUTION_PROFILE_UNAVAILABLE`.
58
+ - If strict isolation is required and the host cannot create any isolated worker at all, stop with `BLOCKED:HOST_ISOLATION_UNAVAILABLE`.
59
+ - 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.
60
+ - 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.
61
+
62
+ The Orchestrator may route a configured profile through the adapter; it may not invent, weaken, or replace that profile.
63
+
48
64
  ## Provider boundary
49
65
  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.
@@ -1,16 +1,15 @@
1
1
  # Execution context
2
2
 
3
3
  ## Purpose
4
- Define the runtime boundary for every YAAW workflow so provider shell state, ambient working directory, and repository layout cannot silently change semantic behavior.
4
+ Define one runtime boundary for every YAAW workflow so ambient shell state and provider layout cannot silently change semantics.
5
5
 
6
6
  ## Canonical workspace root
7
7
  The **workspace root** is the consumer directory that owns the active YAAW installation. Resolve it before repository or application inspection by walking from the provider's current location toward ancestors until `.yaaw-core/install/manifest.json` is found. During recovery of a damaged installation, `.yaaw-core/system/registries/paths.json` may be used as a fallback marker.
8
8
 
9
- The process current working directory is never authoritative. `.yaaw-core/project/` is the **project memory root**, not the workspace root.
9
+ The process CWD is never authoritative. `.yaaw-core/project/` is project memory, not the workspace root.
10
10
 
11
11
  ## Framework integrity
12
-
13
- After resolving the workspace and before semantic project recovery, run:
12
+ After resolving the workspace and before semantic project recovery, run only the canonical package-owned integrity gate:
14
13
 
15
14
  ```text
16
15
  node .yaaw-core/system/tools/framework-integrity.mjs --workspace <WORKSPACE_ROOT>
@@ -18,36 +17,45 @@ node .yaaw-core/system/tools/framework-integrity.mjs --workspace <WORKSPACE_ROOT
18
17
 
19
18
  Only `HEALTHY` permits semantic routing. Package drift, missing framework files, local framework overrides, or an invalid manifest produce a typed framework stop and invalidate executable handoffs. Orchestrator reports the condition; it never repairs package-managed files itself.
20
19
 
21
- ## Repository capability
22
- Repository capability is observed independently from workflow semantics:
20
+ There is no second framework-integrity implementation outside `.yaaw-core/system/tools/`.
21
+
22
+ ## Deterministic orchestration preparation
23
+ Normal Orchestrator routing uses one deterministic preparation entrypoint:
24
+
25
+ ```text
26
+ node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT>
27
+ ```
23
28
 
24
- - `READY`: Git is available and the workspace is inside a repository; trustworthy identity can be computed.
25
- - `UNVERSIONED`: the workspace is valid but is not inside a Git repository.
26
- - `UNAVAILABLE`: Git cannot be executed or repository inspection is prohibited by the host.
27
- - `ROOT_MISMATCH`: repository ownership cannot be reconciled safely with the resolved workspace.
28
- - `IDENTITY_FAILED`: a repository exists but exact identity cannot be established.
29
+ That one invocation performs the framework gate, canonical repository identity, durable metadata inspection, routing, and handoff construction from one basis. The Orchestrator consumes its typed result; it must not reimplement repository hashing, routing precedence, artifact discovery, or handoff serialization in ad-hoc shell/Python code.
29
30
 
30
- A raw Git failure is evidence to classify; it is never permission to continue as though repository identity succeeded.
31
+ Compatibility/debug inspection may use `--inspect-only`. Dispatch freshness uses `--check-handoff` immediately before execution.
32
+
33
+ ## Repository capability
34
+ - `READY`: repository exists and exact identity is trustworthy.
35
+ - `UNVERSIONED`: valid workspace, no Git repository.
36
+ - `UNAVAILABLE`: Git or host permission unavailable.
37
+ - `ROOT_MISMATCH`: repository/workspace ownership cannot be reconciled.
38
+ - `IDENTITY_FAILED`: repository exists but exact identity failed.
31
39
 
32
40
  ## Root-anchored command rule
33
- Every YAAW Git command is explicitly scoped to the resolved workspace:
41
+ Every Git command is explicitly scoped:
34
42
 
35
43
  ```text
36
44
  git -C <WORKSPACE_ROOT> ...
37
45
  ```
38
46
 
39
- Never rely on ambient CWD for `git status`, `git diff`, `git log`, `git rev-parse`, or verification commands.
47
+ When Git top-level is an ancestor, inspection and identity remain workspace-scoped with `-- .`; unrelated sibling changes must not contaminate the active workspace identity.
40
48
 
41
- When the Git top-level is an ancestor of the workspace, repository inspection and worktree hashing are path-scoped to the workspace using the equivalent of `-- .` from `git -C <WORKSPACE_ROOT>`. Unrelated sibling work in a monorepo must not automatically contaminate the workspace identity.
49
+ ## Canonical identity execution
50
+ For repository identity, every semantic workflow invokes or consumes output originating from:
42
51
 
43
- ## Workflow requirements
44
- The machine policy in `.yaaw-core/system/registries/execution-policy.json` assigns one repository requirement to every workflow:
52
+ ```text
53
+ node .yaaw-core/system/tools/repository-identity.mjs --workspace <WORKSPACE_ROOT>
54
+ ```
45
55
 
46
- - `NONE`: repository capability is not a prerequisite.
47
- - `INSPECT`: inspect repository/workspace reality when available; `UNVERSIONED` is representable and does not by itself block the workflow.
48
- - `IDENTITY`: exact repository identity is mandatory; dispatch is blocked unless repository status is `READY`.
56
+ No role or workflow may independently compute or reserialize `worktree_digest`. Copy the returned repository identity into state, handoff, evidence, and review records.
49
57
 
50
- PRD work normally uses `NONE`. Planning discovery uses `INSPECT`. Implementation, code review, and implementation recovery use `IDENTITY`.
58
+ ## Workflow requirements
59
+ The machine policy in `.yaaw-core/system/registries/execution-policy.json` assigns one repository requirement to every workflow.
51
60
 
52
- ## Provider invariant
53
- Provider adapters may point to this contract but must not duplicate it. Codex, Claude Code, Gemini CLI, and Cline all execute against the same workspace-root and repository-capability semantics.
61
+ Provider adapters point to this contract; Codex, Claude Code, Gemini CLI, and Cline do not fork repository semantics.
@@ -1,17 +1,10 @@
1
1
  # Invalidation propagation
2
2
 
3
- Accepted artifacts are historical records, not eternally valid truth. When an upstream basis changes, preserve history and invalidate downstream trust explicitly.
3
+ Accepted artifacts are historical records, not eternally valid truth. Prior reviews remain immutable historical evidence; current authority may become `STALE` without rewriting history.
4
4
 
5
- ## Product revision change
6
- 1. Increment `product.md` revision and record the changed requirement.
7
- 2. Identify `ENG-*` decisions whose product provenance depends on the changed requirement.
8
- 3. Mark affected decisions superseded/invalidated in `engineering.md`; move planning readiness to unresolved.
9
- 4. Mark dependent specs `STALE` rather than rewriting them in place.
10
- 5. Move dependent tickets, including prior `PASS` tickets when behavior is affected, to `REPLAN_REQUIRED` using the transition contract.
11
- 6. Prior reviews remain immutable historical evidence but no longer establish current acceptance.
5
+ ## Permanent rule
12
6
 
13
- ## Engineering decision change
14
- Apply the same propagation from affected `ENG-*` decisions -> specs -> tickets -> reviews.
7
+ **A stale contract and stale acceptance are not the same thing.**
15
8
 
16
9
  ## Acceptance invalidation
17
10
  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`.
@@ -23,5 +16,29 @@ Stable acceptance causes: `REVIEW_MISSING`, `REVIEW_REPOSITORY_STALE`, `VERIFICA
23
16
  ## Framework integrity is not project invalidation
24
17
  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.
25
18
 
26
- ## No silent cascade
27
- Every invalidated artifact records why it became stale and which upstream revision/decision caused it. Never delete prior decisions/specs/reviews merely to make current state look clean.
19
+ Result: `PASS -> REPLAN_REQUIRED`.
20
+
21
+ Next semantic owner: Planner.
22
+
23
+ ### Acceptance invalidation
24
+ The source contract remains current, but review or verification proof is missing, repository-stale, or cannot be reproduced under the canonical identity algorithm.
25
+
26
+ Result: `PASS -> REVIEW_REQUIRED`.
27
+
28
+ Next semantic owner: Reviewer.
29
+
30
+ 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.
31
+
32
+ Reviewer may then return `PASS`, `REPAIR`, `REPLAN`, or `BLOCKED`.
33
+
34
+ ## Stable cause IDs
35
+
36
+ Contract causes: `PRODUCT_SOURCE_STALE`, `ENGINEERING_SOURCE_STALE`, `SPEC_SOURCE_STALE`, `TICKET_SOURCE_STALE`, `CONTRACT_INVALIDATED`.
37
+
38
+ Acceptance causes: `REVIEW_MISSING`, `REVIEW_REPOSITORY_STALE`, `VERIFICATION_MISSING`, `VERIFICATION_REPOSITORY_STALE`, `LEGACY_IDENTITY_UNVERIFIABLE`.
39
+
40
+ Every invalidation records a stable cause plus human-readable evidence. Runtime-looking paths are not automatically acceptance-irrelevant.
41
+
42
+ ## Framework integrity is not acceptance invalidation
43
+
44
+ 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.
@@ -37,6 +37,14 @@ Common results include `SUCCESS`, `READY`, `HUMAN_INPUT_REQUIRED`, `PRECONDITION
37
37
 
38
38
  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.
39
39
 
40
+ 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.
41
+
42
+ - `HOST_ISOLATION_UNAVAILABLE`: strict isolation was required, but the host could not create an isolated worker.
43
+ - `HOST_EXECUTION_PROFILE_UNAVAILABLE`: an execution mechanism existed, but the host could not guarantee the configured effective authority model/reasoning profile.
44
+ - `AUTHORITY_EXECUTION_FAILED`: the correct authority execution actually started and failed under the bounded retry/fallback policy.
45
+
46
+ 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.
47
+
40
48
  `PRECONDITION_UNSATISFIED` includes a reason such as `NO_PRODUCT`, `PLANNING_UNREADY`, `SPEC_MISSING`, `NO_READY_TICKET`, `STALE_SOURCE`, or `REPOSITORY_IDENTITY_UNAVAILABLE`.
41
49
 
42
50
  A missing ticket never authorizes Implementer to create one. Implementer returns `PRECONDITION_UNSATISFIED:NO_READY_TICKET`; Orchestrator routes Planner.
@@ -5,29 +5,24 @@ YAAW advances only through evidence-backed workflow boundaries.
5
5
  ```text
6
6
  product missing/unready -> PRD
7
7
  product ready, planning unresolved -> Planner
8
- planning frontier ready, spec missing -> create spec
8
+ planning ready, spec missing -> create spec
9
9
  spec accepted, tickets missing -> create tickets
10
10
  READY -> Implementer
11
- IN_PROGRESS -> recover/continue only when evidence proves the boundary
11
+ IN_PROGRESS -> recovery/continue
12
12
  REVIEW_REQUIRED -> Reviewer
13
- REPAIR_REQUIRED -> repair same ticket -> REVIEW_REQUIRED
13
+ REPAIR_REQUIRED -> Implementer repair -> REVIEW_REQUIRED
14
14
  REPLAN_REQUIRED -> Planner
15
15
  PASS -> next admitted work
16
- frontier complete but accepted scope remains -> Planner reassesses frontier
17
- all accepted scope complete with fresh acceptance -> COMPLETE
16
+ all accepted scope current -> COMPLETE
18
17
  ```
19
18
 
20
- ## Fresh-context invariant
21
- Every workflow must be resumable from durable artifacts and repository evidence without previous chat history.
22
-
23
- ## Admission invariant
24
- Implementation may begin only for a bounded `READY` ticket whose source spec/frontier is currently valid.
19
+ ## Accepted-but-stale
20
+ A historical `PASS` whose source contract is still current but whose acceptance proof is stale becomes `REVIEW_REQUIRED`, not `REPLAN_REQUIRED`.
25
21
 
26
- ## Acceptance invariant
27
- A ticket is accepted only by a fresh review tied to the exact repository identity and the current ticket/spec revisions.
22
+ ## PASS meaning
23
+ `PASS` means the currently observed repository/worktree state satisfies the current accepted ticket contract according to an independent Reviewer.
28
24
 
29
- ## Transition invariant
30
- Every state transition follows `core/transitions.md`, records provenance in `.yaaw-core/project/state.json`, and cites the evidence or artifact that justified it.
25
+ 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.
31
26
 
32
- ## Invalidation invariant
33
- Changed product intent or engineering decisions propagate through `core/invalidation.md`; historical artifacts are preserved but stale acceptance is never treated as current.
27
+ ## Fresh-context invariant
28
+ Every workflow must be resumable from durable artifacts and repository evidence without previous chat history.
@@ -2,15 +2,15 @@
2
2
 
3
3
  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.
4
4
 
5
+ 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.
6
+
5
7
  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.
6
8
 
7
9
  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.
8
10
 
9
- The machine-readable precedence used by conformance tests lives in `.yaaw-core/system/registries/routing-policy.json`. This document explains the same semantics; CI must fail if the machine contract drifts from the workflow registry or lifecycle fixtures.
10
-
11
11
  ## Priority
12
12
  1. Stop on unhealthy/unknown framework integrity or canonical framework-contract inconsistency.
13
- 2. Resolve material state inconsistency or incomplete recovery.
13
+ 2. Resolve material state inconsistency or incomplete recovery before creating a semantic handoff.
14
14
  3. If accepted product intent is missing or newly invalidated, route to PRD.
15
15
  4. If a ticket is `REPLAN_REQUIRED`, route to `planning.replan`.
16
16
  5. If current engineering frontier is unresolved, route through `planning.route`.
@@ -20,8 +20,8 @@ The machine-readable precedence used by conformance tests lives in `.yaaw-core/s
20
20
  9. If a ticket is `REVIEW_REQUIRED`, route to `review.review-ticket`.
21
21
  10. If a ticket is `IN_PROGRESS`, use recovery evidence to continue safely or reconcile to the next proven boundary; never restart blindly.
22
22
  11. If a dependency-satisfied ticket is `READY`, route to `implementation.implement-ticket`.
23
- 12. If all current tickets are `PASS` but accepted product scope remains, route to `planning.route` for the next frontier.
24
- 13. Declare `COMPLETE` only when accepted scope is covered by fresh, non-stale acceptance evidence.
23
+ 12. If all current tickets are `PASS`/`CANCELLED` but accepted product scope remains, route to `planning.route` for the next frontier.
24
+ 13. Declare `COMPLETE` only when the durable phase is complete and accepted scope is covered by fresh, non-stale acceptance evidence.
25
25
 
26
26
  ## Tie breaking
27
27
  - Never review a `REPAIR_REQUIRED` ticket before repair.
@@ -31,6 +31,6 @@ The machine-readable precedence used by conformance tests lives in `.yaaw-core/s
31
31
  - When evidence is insufficient to choose safely, route to recovery and ultimately `BLOCKED` rather than guessing.
32
32
 
33
33
  ## Conformance rule
34
- Behavioral fixtures may reconcile only transitions explicitly justified by durable/repository evidence. They must never make product or architecture decisions. The conformance oracle is test infrastructure, not a second runtime orchestrator.
34
+ 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.
35
35
 
36
- The Orchestrator selects the workflow; the target role owns semantic work inside it.
36
+ The Orchestrator selects/consumes the route; the target role owns semantic work inside it.
@@ -1,6 +1,6 @@
1
1
  # State transition contract
2
2
 
3
- State names are not enough; only the transitions below are legal unless an explicit recovery rule documents a narrower evidence-backed exception.
3
+ Only transitions represented by the machine registry are legal.
4
4
 
5
5
  In the machine registry, `owner` is the semantic decision authority and `state_writer` is the role permitted to persist the resulting lifecycle mutation. Project-state ledger writes are performed by Orchestrator after validating the durable basis. This does not transfer product, planning, implementation, or acceptance authority to Orchestrator.
6
6
 
@@ -33,7 +33,4 @@ Repository identity mismatch alone does not establish `REPLAN_REQUIRED`.
33
33
 
34
34
  Forbidden examples: `DRAFT -> PASS`, `READY -> PASS`, `REPAIR_REQUIRED -> PASS`, or Implementer-authored `PASS`.
35
35
 
36
- ## Project transitions
37
- Normal phase order is `product -> planning -> implementation -> complete`. `blocked` may be entered from any phase and exited only when its blocker is resolved. A new accepted product revision may move `complete` back to `product` or `planning`; historical completion evidence remains immutable.
38
-
39
- Every transition increments `transition_sequence` and writes `last_transition` in `.yaaw-core/project/state.json`.
36
+ Every transition increments `transition_sequence` and records a stable cause plus evidence. Historical PASS reviews remain immutable even when their authority becomes stale.
@@ -0,0 +1,85 @@
1
+ {
2
+ "schema": "yaaw.handoff-policy/v1",
3
+ "workflows": {
4
+ "prd.route": {
5
+ "desired_intent": "CONTINUE_PRODUCT",
6
+ "active_artifact": "product",
7
+ "reads": ["product", "state"],
8
+ "writes": ["product"],
9
+ "required_expertise": [],
10
+ "ticket_expertise": false,
11
+ "expected_output": "Current product intent or an explicit human-input/blocker result.",
12
+ "result_vocabulary": ["READY", "HUMAN_INPUT_REQUIRED", "BLOCKED"]
13
+ },
14
+ "planning.route": {
15
+ "desired_intent": "CONTINUE_PLANNING",
16
+ "active_artifact": "engineering",
17
+ "reads": ["product", "engineering", "engineering_research", "spec", "ticket", "project_rule", "repository"],
18
+ "writes": ["engineering", "engineering_research", "spec", "ticket", "project_rule"],
19
+ "required_expertise": [],
20
+ "ticket_expertise": false,
21
+ "expected_output": "Current engineering frontier readiness or one typed planning stop/result.",
22
+ "result_vocabulary": ["READY", "HUMAN_INPUT_REQUIRED", "REPLAN", "BLOCKED"]
23
+ },
24
+ "planning.create-spec": {
25
+ "desired_intent": "CREATE_SPEC",
26
+ "active_artifact": "engineering",
27
+ "reads": ["product", "engineering", "engineering_research", "project_rule", "repository"],
28
+ "writes": ["spec"],
29
+ "required_expertise": [],
30
+ "ticket_expertise": false,
31
+ "expected_output": "One accepted specification for the current frontier or a typed prerequisite/stop result.",
32
+ "result_vocabulary": ["SUCCESS", "PRECONDITION_UNSATISFIED", "BLOCKED"]
33
+ },
34
+ "planning.create-tickets": {
35
+ "desired_intent": "CREATE_TICKETS",
36
+ "active_artifact": "spec",
37
+ "reads": ["product", "engineering", "engineering_research", "spec", "project_rule", "repository"],
38
+ "writes": ["ticket"],
39
+ "required_expertise": [],
40
+ "ticket_expertise": false,
41
+ "expected_output": "Dependency-aware executable tickets for the accepted specification or a typed prerequisite/stop result.",
42
+ "result_vocabulary": ["SUCCESS", "PRECONDITION_UNSATISFIED", "BLOCKED"]
43
+ },
44
+ "planning.replan": {
45
+ "desired_intent": "REPLAN",
46
+ "active_artifact": "ticket",
47
+ "reads": ["product", "engineering", "engineering_research", "spec", "ticket", "project_rule", "repository"],
48
+ "writes": ["engineering", "engineering_research", "spec", "ticket", "project_rule"],
49
+ "required_expertise": [],
50
+ "ticket_expertise": true,
51
+ "expected_output": "Updated engineering contract and downstream admission state for the invalidated work.",
52
+ "result_vocabulary": ["READY", "HUMAN_INPUT_REQUIRED", "BLOCKED"]
53
+ },
54
+ "implementation.implement-ticket": {
55
+ "desired_intent": "IMPLEMENT",
56
+ "active_artifact": "ticket",
57
+ "reads": ["product", "engineering", "engineering_research", "spec", "ticket", "project_rule", "repository", "evidence", "review", "application_files"],
58
+ "writes": ["application_files", "evidence"],
59
+ "required_expertise": ["changeability"],
60
+ "ticket_expertise": true,
61
+ "expected_output": "Bounded implementation plus verification evidence and one legal lifecycle result.",
62
+ "result_vocabulary": ["REVIEW_REQUIRED", "REPLAN_REQUIRED", "PRECONDITION_UNSATISFIED", "BLOCKED"]
63
+ },
64
+ "implementation.repair-ticket": {
65
+ "desired_intent": "REPAIR",
66
+ "active_artifact": "ticket",
67
+ "reads": ["product", "engineering", "engineering_research", "spec", "ticket", "project_rule", "repository", "evidence", "review", "application_files"],
68
+ "writes": ["application_files", "evidence"],
69
+ "required_expertise": ["changeability"],
70
+ "ticket_expertise": true,
71
+ "expected_output": "Bounded repair plus fresh verification evidence and one legal lifecycle result.",
72
+ "result_vocabulary": ["REVIEW_REQUIRED", "REPLAN_REQUIRED", "BLOCKED"]
73
+ },
74
+ "review.review-ticket": {
75
+ "desired_intent": "REVIEW",
76
+ "active_artifact": "ticket",
77
+ "reads": ["product", "engineering", "engineering_research", "spec", "ticket", "project_rule", "repository", "evidence", "review", "application_files", "state"],
78
+ "writes": ["review"],
79
+ "required_expertise": ["testing", "changeability"],
80
+ "ticket_expertise": true,
81
+ "expected_output": "One immutable independent review round tied to the current contract and repository basis.",
82
+ "result_vocabulary": ["PASS", "REPAIR", "REPLAN", "BLOCKED"]
83
+ }
84
+ }
85
+ }
@@ -1,23 +1,25 @@
1
1
  # Orchestrator role
2
2
 
3
3
  ## Authority
4
- Own continuity, workspace/repository reconstruction, evidence-backed reconciliation, invalidation coordination, and next-workflow routing.
4
+ Own continuity, evidence-backed reconciliation, invalidation coordination, and next-workflow dispatch. Deterministic workspace/repository reconstruction, routing, and handoff serialization are delegated to the canonical runtime tool rather than improvised by the model.
5
5
 
6
6
  ## Boot sequence
7
7
  1. Resolve the YAAW workspace root using `.yaaw-core/system/core/execution-context.md`; never assume provider CWD.
8
- 2. Run the read-only framework integrity gate from `.yaaw-core/system/core/framework-integrity.md`. If status is not `HEALTHY`, invalidate executable handoffs, report the typed framework failure and installer repair instruction, and stop without project lifecycle mutation.
9
- 3. Inspect repository capability with root-anchored commands and record `READY`, `UNVERSIONED`, `UNAVAILABLE`, `ROOT_MISMATCH`, or `IDENTITY_FAILED`.
10
- 4. Inspect durable claims, active artifacts, runtime caches, and repository/application reality.
11
- 5. Revalidate or discard stale runtime handoffs.
12
- 6. Reconcile only evidence-backed inconsistencies using legal transitions.
13
- 7. Determine exactly one next canonical workflow or terminal state.
14
- 8. Populate a structured handoff from `role-io.json`, `execution-policy.json`, exact artifact references, and current repository basis.
15
- 9. Dispatch exactly one canonical workflow using the host execution mechanism defined by `.yaaw-core/system/core/dispatch-execution.md`. Prefer a fresh isolated worker for non-Orchestrator semantic roles when available.
16
- 10. After any worker completion, failure, interruption, or lost response, return to `orchestration.inspect-state` before selecting another semantic workflow. For Implementer/Reviewer execution failures, update or reset the replaceable dispatch-failure ledger only after confirming durable progress and the current handoff basis.
17
- 11. Apply any configured host capability fallback only through `orchestration.dispatch`; never change semantic role or bypass fresh-context review independence.
18
- 12. Repeat until a real stop condition.
8
+ 2. Execute `node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT>` exactly once for the current basis.
9
+ 3. Consume the typed result:
10
+ - `FRAMEWORK_STOP` -> report the typed framework failure/repair instruction and stop without lifecycle mutation;
11
+ - `RECONCILE_REQUIRED` -> execute only `orchestration.reconcile-state`, then run the deterministic preparation again;
12
+ - `ROOT_ACTION` -> execute the selected Orchestrator recovery workflow, then prepare again;
13
+ - `TERMINAL`/`BLOCKED` -> stop with that result;
14
+ - `DISPATCH_READY` -> use the persisted handoff exactly as produced.
15
+ 4. Do not independently recalculate worktree digests, grep for alternate artifact locations, replay routing precedence, or hand-serialize `observed-state.json`/`handoff.json`.
16
+ 5. Dispatch exactly one canonical workflow using `.yaaw-core/system/workflows/orchestration/dispatch.md`. The host adapter resolves the configured authority execution profile; Orchestrator never invents or substitutes provider/model settings.
17
+ 6. Permit a change of execution mechanism only through the host adapter and only when the adapter establishes execution-profile equivalence or authoritative per-dimension correction under the configured policy.
18
+ 7. After any worker completion, failure, interruption, or lost response, return to deterministic preparation before selecting another semantic workflow. For Implementer/Reviewer execution failures, update or reset the replaceable dispatch-failure ledger only after confirming durable progress and the current handoff basis. A pre-execution host isolation/profile stop never increments that ledger.
19
+ 8. Apply any configured host capability fallback only through `orchestration.dispatch`; preserve the exact semantic role/handoff and require the adapter to preserve the configured fallback profile.
20
+ 9. Repeat until a real stop condition.
19
21
 
20
22
  ## Boundary
21
- The Orchestrator is a traffic controller, not a super-agent. Package integrity is an execution precondition, not something Orchestrator may repair by editing YAAW. The Orchestrator never creates, edits, deletes, or weakens package-managed `.yaaw-core/system/**` content in a consumer run. It must not author product decisions, architecture, implementation, research conclusions, or acceptance. Roles never privately delegate to peers; every successor is chosen here.
23
+ The Orchestrator is a traffic controller, not a super-agent. It may verify and route the execution profile selected by host configuration, but it has no authority to choose arbitrary models or reasoning levels. Framework integrity is an execution precondition, not something Orchestrator may repair by editing YAAW. The Orchestrator never creates, edits, deletes, or weakens package-managed `.yaaw-core/system/**` content in a consumer run. It must not author product decisions, architecture, implementation, research conclusions, or acceptance. Roles never privately delegate to peers; every successor is chosen here.
22
24
 
23
- Child/worker text is not project truth. Durable artifacts, repository evidence, accepted reviews, and legal state transitions are authoritative.
25
+ Child/worker text is not project truth. Durable artifacts, repository evidence, accepted reviews, legal state transitions, and deterministic runtime output are authoritative.
@@ -3,26 +3,40 @@
3
3
  Repository capability and repository identity are related but distinct.
4
4
 
5
5
  ## Capability
6
- Resolve the YAAW workspace root using `.yaaw-core/system/core/execution-context.md`, then inspect Git with root-anchored commands.
6
+ Resolve the YAAW workspace root using `.yaaw-core/system/core/execution-context.md`, then inspect Git only through the canonical utility.
7
7
 
8
- Record one status:
9
- - `READY`: Git repository exists and exact workspace identity is trustworthy.
10
- - `UNVERSIONED`: workspace is valid but not versioned.
11
- - `UNAVAILABLE`: Git or required host permission is unavailable.
12
- - `ROOT_MISMATCH`: workspace/repository ownership cannot be reconciled safely.
13
- - `IDENTITY_FAILED`: repository exists but identity calculation failed.
8
+ No semantic workflow may independently calculate `worktree_digest`. All repository identity used in handoff, verification, recovery, or review must originate from:
14
9
 
15
- Also record `workspace_scope`, `git_root_relation` (`same`, `ancestor`, `none`, or `unknown`), and a safe diagnostic in `error` when status is not `READY`.
10
+ ```text
11
+ node .yaaw-core/system/tools/repository-identity.mjs --workspace <WORKSPACE_ROOT>
12
+ ```
16
13
 
17
- ## Identity
18
- When status is `READY`, record `head_commit`, `dirty`, and `worktree_digest`.
14
+ The tool emits machine-readable JSON on stdout, diagnostics on stderr, and exits non-zero when exact identity cannot be produced. The algorithm identifier is `yaaw-worktree-v2`. Roles and workflows **must not reimplement** it.
19
15
 
20
- Recommended digest inputs, always executed with `git -C <WORKSPACE_ROOT>`:
21
- 1. `git status --porcelain=v1 -z -- .`;
22
- 2. `git diff --binary HEAD -- .`;
23
- 3. `git diff --cached --binary HEAD -- .`;
24
- 4. sorted untracked paths inside the workspace scope and their byte hashes where accessible.
16
+ ## Canonical digest inputs
17
+ All commands execute with `git -C <WORKSPACE_ROOT>` and remain workspace-scoped:
25
18
 
26
- When the Git top-level is an ancestor, unrelated sibling changes are outside the identity scope unless the active ticket explicitly includes them.
19
+ 1. `git status --porcelain=v1 -z --untracked-files=all -- . <control-output exclusions>`
20
+ 2. `git diff --binary --no-ext-diff --no-textconv HEAD -- . <control-output exclusions>`
21
+ 3. `git diff --cached --binary --no-ext-diff --no-textconv HEAD -- . <control-output exclusions>`
22
+ 4. `git ls-files --others --exclude-standard -z -- . <control-output exclusions>`
27
23
 
28
- If trustworthy identity cannot be produced for a workflow requiring `IDENTITY`, return a typed prerequisite/blocker rather than pretending the state is uniquely identified.
24
+ Hash raw stdout bytes. Never hash stderr, warnings, timestamps, absolute paths, ambient CWD, PIDs, or hostnames.
25
+
26
+ Untracked paths are slash-normalized and sorted. Regular files are hashed from exact bytes. Symlinks are hashed from their exact link-target representation. Unsupported or unreadable objects produce `IDENTITY_FAILED`; they are never silently omitted.
27
+
28
+ The final digest is SHA-256 over stable canonical UTF-8 JSON containing algorithm, workspace-relative scope, HEAD, component hashes, the explicit exclusions, and the sorted untracked manifest.
29
+
30
+ ## Lifecycle-output exclusions
31
+ `yaaw-worktree-v2` excludes only YAAW files whose normal lifecycle write would otherwise invalidate the repository basis that the file itself records:
32
+
33
+ - `.yaaw-core/runtime/**` — replaceable observation/handoff/intent/failure caches;
34
+ - `.yaaw-core/project/state.json` — Orchestrator lifecycle ledger;
35
+ - `.yaaw-core/project/evidence/**` — immutable verification attestations;
36
+ - `.yaaw-core/project/reviews/**` — immutable acceptance attestations.
37
+
38
+ This prevents circular freshness: writing an observation, handoff, state transition, evidence record, or review cannot by itself make the implementation repository identity stale. These artifacts remain governed by their own schemas, revisions, immutability rules, transition sequence, and handoff references.
39
+
40
+ The exclusion deliberately does **not** cover product, engineering, research, specs, tickets, project rules, `.yaaw-core/install/**`, package-managed `.yaaw-core/system/**`, application files, `.codex/`, `.agents/`, `.claude/`, `.gemini/`, `.cline/`, or other provider/project paths. Changes to those continue to change repository identity.
41
+
42
+ When the Git top-level is an ancestor, unrelated sibling changes remain outside identity because all commands are scoped to the active workspace.
@@ -0,0 +1,28 @@
1
+ {
2
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
3
+ "$id": "yaaw.evidence/v1",
4
+ "type": "object",
5
+ "required": ["schema","id","ticket","ticket_revision","spec_revision","kind","repository","workflow","commands","checks"],
6
+ "properties": {
7
+ "schema": {"const": "yaaw.evidence/v1"},
8
+ "id": {"type": "string"},
9
+ "ticket": {"type": "string", "pattern": "^TASK-[0-9]+$"},
10
+ "ticket_revision": {"type": "integer", "minimum": 0},
11
+ "spec_revision": {"type": "integer", "minimum": 0},
12
+ "kind": {"type": "string"},
13
+ "repository": {
14
+ "type": "object",
15
+ "required": ["head_commit","dirty","worktree_digest"],
16
+ "properties": {
17
+ "head_commit": {"type": ["string","null"]},
18
+ "dirty": {"type": ["boolean","null"]},
19
+ "worktree_digest": {"type": ["string","null"]}
20
+ },
21
+ "additionalProperties": false
22
+ },
23
+ "workflow": {"type": "string"},
24
+ "commands": {"type": "array"},
25
+ "checks": {"type": "array"}
26
+ },
27
+ "additionalProperties": false
28
+ }
@@ -0,0 +1,19 @@
1
+ {
2
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
3
+ "$id": "yaaw.evidence/v2",
4
+ "type": "object",
5
+ "required": ["schema","id","ticket","ticket_revision","spec_revision","kind","repository","workflow","commands","checks"],
6
+ "properties": {
7
+ "schema": {"const": "yaaw.evidence/v2"},
8
+ "id": {"type": "string"},
9
+ "ticket": {"type": "string", "pattern": "^TASK-[0-9]+$"},
10
+ "ticket_revision": {"type": "integer", "minimum": 0},
11
+ "spec_revision": {"type": "integer", "minimum": 0},
12
+ "kind": {"type": "string"},
13
+ "repository": {"$ref": "repository-identity.schema.json"},
14
+ "workflow": {"type": "string"},
15
+ "commands": {"type": "array"},
16
+ "checks": {"type": "array"}
17
+ },
18
+ "additionalProperties": false
19
+ }