yaaw-se 0.1.0-dev.35745937645.1

package/dist/payload/yaaw-core/core/artifact-model.md

@@ -0,0 +1,35 @@
+# Artifact model
+
+Canonical durable project root: `.yaaw-core/project/`.
+
+Ownership is separated by subdirectory under one YAAW root:
+
+- `.yaaw-core/core/`, `roles/`, `workflows/`, `expertise/`, `rules/`, `registries/`, `schemas/`, and `templates/`: package-managed framework content.
+- `.yaaw-core/project/`: durable project-owned semantic memory.
+- `.yaaw-core/runtime/`: replaceable coordination state.
+- `.yaaw-core/install/`: installer metadata only.
+
+Durable project artifacts:
+
+- `product.md`: human-approved product intent and unresolved product questions.
+- `engineering.md`: durable engineering understanding, `ENG-*` decisions, assumptions, risks, frontier, fog, and readiness.
+- `specs/SPEC-*.md`: coherent engineering contracts referencing product/decision revisions.
+- `tickets/TASK-*.md`: bounded implementation contracts.
+- `reviews/TASK-*-R*.md`: immutable review rounds tied to exact source and repository revisions.
+- `evidence/*.json`: machine-readable verification evidence tied to repository identity.
+- `rules/`: project-specific reusable invariants promoted from real evidence.
+- `state.json`: reconstructable routing cache and last transition provenance.
+
+Replaceable runtime artifacts:
+
+- `.yaaw-core/runtime/observed-state.json`: observed orchestration snapshot.
+- `.yaaw-core/runtime/handoff.json`: dispatch contract.
+- `.yaaw-core/runtime/intent.json`: optional current intent cache.
+
+Installer metadata:
+
+- `.yaaw-core/install/manifest.json`: package/integration ownership and version state. It is never semantic project truth.
+
+Markdown artifacts use YAML frontmatter for machine-readable identity/revision/status and a human-readable body for durable reasoning. Schemas validate metadata; core validation rules define required Markdown sections.
+
+Conversation is never an artifact of record. Package update logic must never treat `.yaaw-core/project/` as replaceable framework content.

package/dist/payload/yaaw-core/core/authority.md

@@ -0,0 +1,15 @@
+# Authority model
+
+Authority is semantic, not hierarchical.
+
+| Role | Owns | Must not own |
+|---|---|---|
+| Human / PRD | product goal, behavior, scope, non-goals | engineering architecture |
+| Planner | technical design, engineering decisions, specs, ticket contracts | product-intent changes |
+| Implementer | code within an admitted ticket | architecture changes outside admitted scope; acceptance |
+| Reviewer | independent acceptance, findings, repair-vs-replan classification | implementation authorship during review |
+| Orchestrator | routing, continuity, reconciliation, invalidation/recovery coordination | product, architecture, coding, self-approval |
+
+Expertise modules never grant authority. They may advise a role but cannot override the role contract.
+
+A downstream role may detect that an upstream contract is invalid, but it must return control to the owning role rather than silently rewriting that contract.

package/dist/payload/yaaw-core/core/context-loading.md

@@ -0,0 +1,23 @@
+# Context loading
+
+Load the smallest durable context needed for the current judgment:
+
+```text
+role contract
++ workflow contract
++ active artifact and revision
++ directly referenced decisions
++ relevant product constraints
++ relevant project rules
++ relevant repository files/diff
++ selected expertise
++ prior review finding when repairing
++ current handoff/repository identity when dispatched
+```
+
+Do not automatically load every PRD revision, ticket, review, expertise module, or the full repository.
+
+## Handoff freshness
+A handoff names exact artifact paths, revisions, selected expertise, expected output, and the repository identity observed when it was created. Before executing it, verify those bases still match current reality. If they do not, discard the stale handoff and re-enter orchestration inspection.
+
+Runtime handoffs and observed-state snapshots live under `.yaaw-core/runtime/`; they are coordination caches, not semantic sources of truth.

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

@@ -0,0 +1,20 @@
+# Invalidation propagation
+
+Accepted artifacts are historical records, not eternally valid truth. When an upstream basis changes, preserve history and invalidate downstream trust explicitly.
+
+## Product revision change
+1. Increment `product.md` revision and record the changed requirement.
+2. Identify `ENG-*` decisions whose product provenance depends on the changed requirement.
+3. Mark affected decisions superseded/invalidated in `engineering.md`; move planning readiness to unresolved.
+4. Mark dependent specs `STALE` rather than rewriting them in place.
+5. Move dependent tickets, including prior `PASS` tickets when behavior is affected, to `REPLAN_REQUIRED` using the transition contract.
+6. Prior reviews remain immutable historical evidence but no longer establish current acceptance.
+
+## Engineering decision change
+Apply the same propagation from affected `ENG-*` decisions -> specs -> tickets -> reviews.
+
+## Repository drift
+A review becomes stale when the reviewed repository identity no longer matches the relevant implementation state. Route to review if the contract remains valid; route to replan when drift invalidates the contract.
+
+## No silent cascade
+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.

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

@@ -0,0 +1,33 @@
+# Lifecycle contract
+
+YAAW advances only through evidence-backed workflow boundaries.
+
+```text
+product missing/unready -> PRD
+product ready, planning unresolved -> Planner
+planning frontier ready, spec missing -> create spec
+spec accepted, tickets missing -> create tickets
+READY -> Implementer
+IN_PROGRESS -> recover/continue only when evidence proves the boundary
+REVIEW_REQUIRED -> Reviewer
+REPAIR_REQUIRED -> repair same ticket -> REVIEW_REQUIRED
+REPLAN_REQUIRED -> Planner
+PASS -> next admitted work
+frontier complete but accepted scope remains -> Planner reassesses frontier
+all accepted scope complete with fresh acceptance -> COMPLETE
+```
+
+## Fresh-context invariant
+Every workflow must be resumable from durable artifacts and repository evidence without previous chat history.
+
+## Admission invariant
+Implementation may begin only for a bounded `READY` ticket whose source spec/frontier is currently valid.
+
+## Acceptance invariant
+A ticket is accepted only by a fresh review tied to the exact repository identity and the current ticket/spec revisions.
+
+## Transition invariant
+Every state transition follows `core/transitions.md`, records provenance in `.yaaw-core/project/state.json`, and cites the evidence or artifact that justified it.
+
+## Invalidation invariant
+Changed product intent or engineering decisions propagate through `core/invalidation.md`; historical artifacts are preserved but stale acceptance is never treated as current.

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

@@ -0,0 +1,20 @@
+# Recovery policy
+
+Recovery compares claimed state with observed reality and returns to the last trustworthy boundary.
+
+## 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` + missing/stale review, source revision mismatch, or repository identity mismatch -> invalidate current PASS and route to review/replan as appropriate.
+- A stale `.yaaw-core/runtime/handoff.json` is discarded, not executed.
+- 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.

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

@@ -0,0 +1,30 @@
+# Routing contract
+
+Routing chooses exactly one next canonical workflow from observed reality. Explicit state beats broad heuristics.
+
+The machine-readable precedence used by conformance tests lives in `.yaaw-core/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.
+
+## Priority
+1. Resolve material state inconsistency or incomplete recovery.
+2. If accepted product intent is missing or newly invalidated, route to PRD.
+3. If a ticket is `REPLAN_REQUIRED`, route to `planning.replan`.
+4. If current engineering frontier is unresolved, route through `planning.route`.
+5. If a ready frontier lacks an accepted spec, route to `planning.create-spec`.
+6. If an accepted spec lacks executable tickets, route to `planning.create-tickets`.
+7. If a ticket is `REPAIR_REQUIRED`, route to `implementation.repair-ticket`.
+8. If a ticket is `REVIEW_REQUIRED`, route to `review.review-ticket`.
+9. If a ticket is `IN_PROGRESS`, use recovery evidence to continue safely or reconcile to the next proven boundary; never restart blindly.
+10. If a dependency-satisfied ticket is `READY`, route to `implementation.implement-ticket`.
+11. If all current tickets are `PASS` but accepted product scope remains, route to `planning.route` for the next frontier.
+12. Declare `COMPLETE` only when 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 source revision or repository identity invalidates its review.
+- When evidence is insufficient to choose safely, route to recovery and ultimately `BLOCKED` rather than guessing.
+
+## Conformance rule
+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.
+
+The Orchestrator selects the workflow; the target role owns semantic work inside it.

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

@@ -0,0 +1,26 @@
+# State model
+
+Canonical machine-readable project state is `.yaaw-core/project/state.json` using `yaaw.project-state/v1`.
+
+State is a routing cache and claim ledger. It is never trusted blindly over stronger domain evidence.
+
+## 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.
+
+`.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.
+
+Legal transitions are defined in `core/transitions.md`.

package/dist/payload/yaaw-core/core/transitions.md

@@ -0,0 +1,34 @@
+# State transition contract
+
+State names are not enough; only the transitions below are legal unless an explicit recovery rule documents a narrower evidence-backed exception.
+
+The machine-readable transition table used by conformance tests lives in `.yaaw-core/registries/transitions.json`. This document remains the human-readable explanation and CI checks the registry against workflow IDs and the project-state schema.
+
+## Ticket transitions
+| From | To | Owner/workflow | Required basis |
+|---|---|---|---|
+| DRAFT | READY | Planner | current spec/frontier valid; dependencies satisfied |
+| DRAFT | CANCELLED | Planner/Human | scope removed |
+| READY | IN_PROGRESS | Implementer | ticket selected; source revisions still current |
+| READY | REPLAN_REQUIRED | Orchestrator/Planner | source invalidation or contradictory evidence |
+| IN_PROGRESS | REVIEW_REQUIRED | Implementer or recovery | implementation exists; required verification evidence recorded |
+| IN_PROGRESS | REPLAN_REQUIRED | Implementer/Reviewer/Orchestrator | material contract gap |
+| IN_PROGRESS | BLOCKED | active role | required external evidence/permission unavailable |
+| REVIEW_REQUIRED | PASS | Reviewer | fresh PASS review tied to current repository/ticket/spec revisions |
+| REVIEW_REQUIRED | REPAIR_REQUIRED | Reviewer | implementation defect; contract remains valid |
+| REVIEW_REQUIRED | REPLAN_REQUIRED | Reviewer | contract/architecture invalid or insufficient |
+| REVIEW_REQUIRED | BLOCKED | Reviewer | review evidence unavailable |
+| REPAIR_REQUIRED | REVIEW_REQUIRED | Implementer | required repair applied and reverified |
+| REPAIR_REQUIRED | REPLAN_REQUIRED | Implementer | repair would change accepted contract |
+| REPLAN_REQUIRED | DRAFT | Planner | contract revised but not yet re-admitted |
+| REPLAN_REQUIRED | READY | Planner | revised contract passes readiness and dependencies |
+| BLOCKED | DRAFT/READY/IN_PROGRESS/REVIEW_REQUIRED/REPAIR_REQUIRED/REPLAN_REQUIRED | owning role | blocker resolved and prior valid boundary proven |
+| PASS | REPLAN_REQUIRED | Orchestrator/Planner | upstream revision invalidates current acceptance |
+| PASS | CANCELLED | Human/Planner | accepted scope explicitly removed; history preserved |
+
+Forbidden examples: `DRAFT -> PASS`, `READY -> PASS`, `REPAIR_REQUIRED -> PASS`, or Implementer-authored `PASS`.
+
+## Project transitions
+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.
+
+Every transition increments `transition_sequence` and writes `last_transition` in `.yaaw-core/project/state.json`.

package/dist/payload/yaaw-core/expertise/changeability/MODULE.md

@@ -0,0 +1,58 @@
+# Changeability expertise
+
+Use this module when a ticket, design, or review has non-trivial maintainability implications. The canonical mandatory policy is `.yaaw-core/rules/changeability.md`; this module provides deeper reasoning and examples, not additional authority.
+
+## Goal
+Optimize the changed surface for future comprehension, modification, verification, and rollback while preserving the current product/spec/ticket contract and repository conventions.
+
+## Reasoning sequence
+1. Identify the actual domain behavior being changed.
+2. Identify the minimum authorized code surface needed to implement it safely.
+3. Locate relevant boundaries, state models, decision logic, errors, and tests.
+4. Apply only the changeability principles that materially affect that surface.
+5. Prefer the smallest design that removes concrete ambiguity/coupling/risk.
+6. Verify behavior and the relevant structural property.
+7. Leave unrelated cleanup out of scope.
+
+## Principle heuristics
+
+### Visible main path
+Ask whether a fresh engineer can identify the success path quickly. Consider guard clauses, decomposition, or clearer branching when exceptional cases bury the operation. Avoid style-only rewrites.
+
+### Domain naming
+Ask whether important names expose what the value or operation means in this application. Generic names are acceptable for genuinely generic/local mechanics; they are weak when they hide a known domain concept.
+
+### External boundaries
+Look for provider SDK types, remote field names, transport objects, ORM/persistence records, or protocol-specific errors escaping into business code. Prefer adapters/mappers/ports where the accepted architecture benefits from containment.
+
+### Invalid states
+Look for broad optional structures, boolean combinations, unchecked sentinel values, or repeated `if value exists` logic that represent domain states poorly. Prefer explicit state variants, constructors, validators, schemas, or invariants when they materially reduce impossible combinations.
+
+### Decisions versus actions
+Look for important policy mixed into database/network/email/filesystem operations. Extracting decision logic is valuable when it improves deterministic tests and clarity; do not force a functional style where side effects are the actual domain operation.
+
+### Useful failures
+Prefer stable error identity plus human-readable meaning and safe context. Preserve local error conventions. Never improve diagnostics by exposing secrets or sensitive payloads.
+
+### Focused changes
+Treat scope control as the limiter on every other principle. A discovered smell is not automatically part of the ticket. Supporting refactors must be necessary for safe implementation or verification of the authorized behavior.
+
+## Common agent failure modes
+- mechanically replacing all nesting with guard clauses;
+- renaming large surfaces without ticket need;
+- creating abstraction layers for hypothetical future providers;
+- over-modeling trivial states with excessive types/classes;
+- extracting tiny pure functions that make navigation worse without improving tests;
+- inventing a new error taxonomy instead of following project conventions;
+- converting a feature ticket into a broad refactor because nearby code looks untidy;
+- rejecting code based on personal style rather than concrete engineering impact.
+
+## Review guidance
+A reviewer should classify a changeability issue as `REPAIR` when the accepted contract remains valid and a bounded implementation correction resolves the problem. Use `REPLAN` only when satisfying the concern requires changing accepted architecture/spec meaning. Non-blocking style preferences should not create a review failure.
+
+## Verification examples
+- External boundary: adapter mapping tests prove provider fields do not become application contract fields.
+- Invalid states: tests prove invalid combinations cannot be constructed/admitted through the boundary.
+- Decision/action separation: pure decision tests exercise policy without invoking side effects.
+- Useful errors: tests assert stable error code/shape and safe context.
+- Focused changes: diff inspection shows unrelated modules were not rewritten.

package/dist/payload/yaaw-core/expertise/frontend-design/MODULE.md

@@ -0,0 +1,16 @@
+# Expertise: frontend-design
+
+## Description
+Specialist UI interaction, responsive behavior, accessibility, state-feedback, and component-boundary guidance. It grants no workflow authority.
+
+## Required context
+Relevant UI files, existing design-system/project rules, user-facing acceptance criteria, and current component patterns.
+
+## Rules
+Planner defines interaction states, responsive behavior, component boundaries, accessibility constraints, and testable acceptance. Implementer preserves local design-system conventions and complete loading/error/empty/disabled/focus states. Reviewer verifies the actual behavior across states and viewport/keyboard conditions.
+
+## Anti-patterns
+Inventing visual requirements, redesigning unrelated surfaces, treating desktop-only behavior as complete, or ignoring semantics/focus/labels.
+
+## Verification expectations
+State coverage, responsive behavior, semantic structure, keyboard/focus behavior, labels/errors, and regressions.

package/dist/payload/yaaw-core/expertise/python/MODULE.md

@@ -0,0 +1,16 @@
+# Expertise: python
+
+## Description
+Repository-aware Python design, typing, runtime, IO/error, async, tooling, and review guidance. It grants no workflow authority.
+
+## Required context
+`pyproject.toml`/tool configuration, supported Python version, relevant package boundaries, target files, and project test/lint/type conventions.
+
+## Rules
+Always prefer repository rules over generic preferences. Planner accounts for package/API boundaries and runtime compatibility. Implementer follows local idioms, preserves typing/error contracts, and manages resources correctly. Reviewer checks behavior, exceptions, typing assumptions, async/sync boundaries, and tooling compliance.
+
+## Anti-patterns
+Overriding local conventions, broad exception swallowing, unexamined sync/async mixing, unnecessary abstraction, or assuming a Python/tool version without inspecting the repo.
+
+## Verification expectations
+Relevant project tooling passes; error/resource behavior is exercised; typing/runtime assumptions are compatible with the repository.

package/dist/payload/yaaw-core/expertise/security/MODULE.md

@@ -0,0 +1,16 @@
+# Expertise: security
+
+## Description
+Specialist authentication, authorization, trust-boundary, secret, input-validation, and abuse-case guidance. It grants no workflow authority.
+
+## Required context
+Relevant trust boundaries, sensitive data paths, authentication/authorization mechanisms, project security rules, and changed interfaces.
+
+## Rules
+Planner identifies trust boundaries and security invariants. Implementer enforces server-side authorization/input handling and avoids secret/data exposure. Reviewer checks negative paths and actual enforcement rather than assuming the intended control exists.
+
+## Anti-patterns
+Client-only authorization, security by convention, logging secrets/tokens, broad trust of external input, or silently weakening an accepted invariant.
+
+## Verification expectations
+Negative authorization cases, boundary/input failure cases, secret/data exposure review, and regression evidence for security-sensitive behavior.

package/dist/payload/yaaw-core/expertise/testing/MODULE.md

@@ -0,0 +1,16 @@
+# Expertise: testing
+
+## Description
+Specialist test design, regression strategy, verification scope, and evidence-quality guidance. It grants no workflow authority.
+
+## Required context
+Ticket acceptance criteria, changed surface, project test tooling/conventions, existing relevant tests, and known failure modes.
+
+## Rules
+Planner makes acceptance verifiable. Implementer runs required tests and adds targeted coverage justified by the change. Reviewer checks evidence quality and may run/require additional focused checks when acceptance cannot otherwise be established.
+
+## Anti-patterns
+Tests that only mirror implementation details, skipping failure paths, treating an unrun test suite as passing, or expanding into unrelated test cleanup.
+
+## Verification expectations
+Required tests executed, meaningful failure/regression coverage, reproducible commands/results, and evidence tied to repository identity.

package/dist/payload/yaaw-core/registries/expertise.json

@@ -0,0 +1,47 @@
+{
+  "frontend-design": {
+    "path": ".yaaw-core/expertise/frontend-design/MODULE.md",
+    "description": "UI interaction, responsive behavior, accessibility, state feedback, and component-boundary guidance.",
+    "signals": ["UI", "layout", "component", "responsive", "interaction", "accessibility"],
+    "usable_by": ["planner", "implementer", "reviewer"],
+    "required_context": ["relevant UI files", "design-system/project rules", "user-facing acceptance criteria"],
+    "anti_patterns": ["inventing visual requirements", "ignoring keyboard/focus states", "rewriting unrelated components"],
+    "verification_expectations": ["state coverage", "responsive behavior", "semantics and keyboard/focus behavior"]
+  },
+  "security": {
+    "path": ".yaaw-core/expertise/security/MODULE.md",
+    "description": "Authentication, authorization, trust-boundary, secret, input, and abuse-case guidance.",
+    "signals": ["auth", "authorization", "secret", "input", "permission", "security"],
+    "usable_by": ["planner", "implementer", "reviewer"],
+    "required_context": ["trust boundaries", "sensitive data paths", "relevant auth/project rules"],
+    "anti_patterns": ["security by assumption", "client-only authorization", "logging secrets"],
+    "verification_expectations": ["negative authorization cases", "input/failure paths", "secret/data exposure review"]
+  },
+  "testing": {
+    "path": ".yaaw-core/expertise/testing/MODULE.md",
+    "description": "Test design, verification strategy, regression coverage, and evidence quality guidance.",
+    "signals": ["test", "verification", "regression", "acceptance"],
+    "usable_by": ["planner", "implementer", "reviewer"],
+    "required_context": ["ticket acceptance", "project test tooling", "changed surface"],
+    "anti_patterns": ["tests that restate implementation", "ignoring failure paths", "claiming PASS from unrun tests"],
+    "verification_expectations": ["required tests executed", "targeted regressions", "reproducible evidence"]
+  },
+  "python": {
+    "path": ".yaaw-core/expertise/python/MODULE.md",
+    "description": "Repository-aware Python design, typing, runtime, IO/error, async, tooling, and review guidance.",
+    "signals": ["Python", "pyproject.toml", "pytest", "ruff", "typing"],
+    "usable_by": ["planner", "implementer", "reviewer"],
+    "required_context": ["pyproject/tool config", "supported Python version", "relevant package/test files"],
+    "anti_patterns": ["overriding local conventions", "unexamined sync/async mixing", "broad exception swallowing"],
+    "verification_expectations": ["project tooling passes", "error/resource behavior checked", "typing/runtime assumptions validated"]
+  },
+  "changeability": {
+    "path": ".yaaw-core/expertise/changeability/MODULE.md",
+    "description": "Maintainability guidance for visible control flow, domain naming, external boundaries, valid-state modeling, decision/side-effect separation, useful errors, and focused changes.",
+    "signals": ["maintainability", "refactor", "boundary", "adapter", "state model", "error contract", "complex control flow", "coupling"],
+    "usable_by": ["planner", "implementer", "reviewer"],
+    "required_context": ["current ticket/spec contract", "changed surface", "repository conventions", "changeability policy"],
+    "anti_patterns": ["style-only rewrites", "speculative abstractions", "unrelated refactor creep", "subjective review failures"],
+    "verification_expectations": ["relevant structural property checked", "targeted behavior/regression tests", "scope remains focused"]
+  }
+}

package/dist/payload/yaaw-core/registries/paths.json

@@ -0,0 +1,15 @@
+{
+  "schema": "yaaw.paths/v1",
+  "core_root": ".yaaw-core",
+  "project_root": ".yaaw-core/project",
+  "runtime_root": ".yaaw-core/runtime",
+  "install_root": ".yaaw-core/install",
+  "product": ".yaaw-core/project/product.md",
+  "engineering": ".yaaw-core/project/engineering.md",
+  "state": ".yaaw-core/project/state.json",
+  "specs": ".yaaw-core/project/specs",
+  "tickets": ".yaaw-core/project/tickets",
+  "reviews": ".yaaw-core/project/reviews",
+  "evidence": ".yaaw-core/project/evidence",
+  "project_rules": ".yaaw-core/project/rules"
+}

package/dist/payload/yaaw-core/registries/routing-policy.json

@@ -0,0 +1,16 @@
+{
+  "schema": "yaaw.routing-policy/v1",
+  "product_unready_workflow": "prd.route",
+  "planning_unready_workflow": "planning.route",
+  "missing_spec_workflow": "planning.create-spec",
+  "missing_tickets_workflow": "planning.create-tickets",
+  "next_frontier_workflow": "planning.route",
+  "complete_terminal": "COMPLETE",
+  "ticket_state_precedence": [
+    {"state": "REPLAN_REQUIRED", "workflow": "planning.replan"},
+    {"state": "REPAIR_REQUIRED", "workflow": "implementation.repair-ticket"},
+    {"state": "REVIEW_REQUIRED", "workflow": "review.review-ticket"},
+    {"state": "IN_PROGRESS", "workflow": "orchestration.recover-interruption"},
+    {"state": "READY", "workflow": "implementation.implement-ticket"}
+  ]
+}

package/dist/payload/yaaw-core/registries/skills.json

@@ -0,0 +1,14 @@
+{
+  "yaaw-orchestrator": {"role": "orchestrator", "workflow_id": "orchestration.route", "description": "Continue or recover a YAAW project by reconstructing reality and dispatching the next safe workflow."},
+  "yaaw-prd": {"role": "prd", "workflow_id": "prd.route", "description": "Create or continue YAAW product definition, challenge material product assumptions, and route clarification or revision work."},
+  "yaaw-revise-prd": {"role": "prd", "workflow_id": "prd.revise", "description": "Change accepted YAAW product intent and invalidate downstream engineering contracts whose basis became stale."},
+  "yaaw-refine-prd": {"role": "prd", "workflow_id": "prd.refine", "description": "Improve clarity and completeness of a YAAW product artifact without changing accepted product meaning."},
+  "yaaw-planner": {"role": "planner", "workflow_id": "planning.route", "description": "Continue repository-backed YAAW engineering planning, challenge material technical assumptions, and advance decisions, readiness, specifications, or tickets."},
+  "yaaw-planning-review": {"role": "planner", "workflow_id": "planning.readiness-review", "description": "Freshly assess whether the current YAAW engineering frontier is ready for implementation without material invention."},
+  "yaaw-create-spec": {"role": "planner", "workflow_id": "planning.create-spec", "description": "Create the next YAAW specification from an engineering frontier whose readiness is currently PASS."},
+  "yaaw-create-ticket": {"role": "planner", "workflow_id": "planning.create-tickets", "description": "Create bounded YAAW implementation ticket contracts from the current accepted specification."},
+  "yaaw-create-tickets": {"role": "planner", "workflow_id": "planning.create-tickets", "description": "Create dependency-aware bounded YAAW implementation tickets from the current accepted specification."},
+  "yaaw-implement": {"role": "implementer", "workflow_id": "implementation.implement-ticket", "description": "Implement one admitted READY YAAW ticket and produce repository-identity-bound verification evidence."},
+  "yaaw-repair": {"role": "implementer", "workflow_id": "implementation.repair-ticket", "description": "Repair a YAAW ticket in REPAIR_REQUIRED state while preserving its accepted product and engineering contract."},
+  "yaaw-review": {"role": "reviewer", "workflow_id": "review.review-ticket", "description": "Independently review actual YAAW implementation and classify PASS, REPAIR, REPLAN, or BLOCKED against current evidence."}
+}

package/dist/payload/yaaw-core/registries/transitions.json

@@ -0,0 +1,29 @@
+{
+  "schema": "yaaw.transitions/v1",
+  "ticket_states": ["DRAFT", "READY", "IN_PROGRESS", "REVIEW_REQUIRED", "REPAIR_REQUIRED", "REPLAN_REQUIRED", "BLOCKED", "PASS", "CANCELLED"],
+  "legal": [
+    {"from": "DRAFT", "to": "READY", "owner": "planner", "workflow": "planning.create-tickets"},
+    {"from": "DRAFT", "to": "CANCELLED", "owner": "planner", "workflow": "planning.replan"},
+    {"from": "READY", "to": "IN_PROGRESS", "owner": "implementer", "workflow": "implementation.implement-ticket"},
+    {"from": "READY", "to": "REPLAN_REQUIRED", "owner": "planner", "workflow": "planning.replan"},
+    {"from": "IN_PROGRESS", "to": "REVIEW_REQUIRED", "owner": "implementer", "workflow": "implementation.verify-ticket"},
+    {"from": "IN_PROGRESS", "to": "REPLAN_REQUIRED", "owner": "planner", "workflow": "planning.replan"},
+    {"from": "IN_PROGRESS", "to": "BLOCKED", "owner": "implementer", "workflow": "implementation.implement-ticket"},
+    {"from": "REVIEW_REQUIRED", "to": "PASS", "owner": "reviewer", "workflow": "review.record-review"},
+    {"from": "REVIEW_REQUIRED", "to": "REPAIR_REQUIRED", "owner": "reviewer", "workflow": "review.record-review"},
+    {"from": "REVIEW_REQUIRED", "to": "REPLAN_REQUIRED", "owner": "reviewer", "workflow": "review.record-review"},
+    {"from": "REVIEW_REQUIRED", "to": "BLOCKED", "owner": "reviewer", "workflow": "review.record-review"},
+    {"from": "REPAIR_REQUIRED", "to": "REVIEW_REQUIRED", "owner": "implementer", "workflow": "implementation.repair-ticket"},
+    {"from": "REPAIR_REQUIRED", "to": "REPLAN_REQUIRED", "owner": "planner", "workflow": "planning.replan"},
+    {"from": "REPLAN_REQUIRED", "to": "DRAFT", "owner": "planner", "workflow": "planning.replan"},
+    {"from": "REPLAN_REQUIRED", "to": "READY", "owner": "planner", "workflow": "planning.replan"},
+    {"from": "PASS", "to": "REPLAN_REQUIRED", "owner": "planner", "workflow": "planning.replan"},
+    {"from": "PASS", "to": "CANCELLED", "owner": "planner", "workflow": "planning.replan"}
+  ],
+  "blocked_exit_targets": ["DRAFT", "READY", "IN_PROGRESS", "REVIEW_REQUIRED", "REPAIR_REQUIRED", "REPLAN_REQUIRED"],
+  "forbidden": [
+    {"from": "DRAFT", "to": "PASS"},
+    {"from": "READY", "to": "PASS"},
+    {"from": "REPAIR_REQUIRED", "to": "PASS"}
+  ]
+}

package/dist/payload/yaaw-core/registries/workflows.json

@@ -0,0 +1,37 @@
+{
+  "prd.route": {"role": "prd", "workflow": ".yaaw-core/workflows/prd/route.md"},
+  "prd.create": {"role": "prd", "workflow": ".yaaw-core/workflows/prd/create.md"},
+  "prd.question-round": {"role": "prd", "workflow": ".yaaw-core/workflows/prd/question-round.md"},
+  "prd.record-decisions": {"role": "prd", "workflow": ".yaaw-core/workflows/prd/record-decisions.md"},
+  "prd.revise": {"role": "prd", "workflow": ".yaaw-core/workflows/prd/revise.md"},
+  "prd.refine": {"role": "prd", "workflow": ".yaaw-core/workflows/prd/refine.md"},
+  "prd.readiness": {"role": "prd", "workflow": ".yaaw-core/workflows/prd/readiness.md"},
+
+  "planning.route": {"role": "planner", "workflow": ".yaaw-core/workflows/planning/route.md"},
+  "planning.discover": {"role": "planner", "workflow": ".yaaw-core/workflows/planning/discover.md"},
+  "planning.write-understanding": {"role": "planner", "workflow": ".yaaw-core/workflows/planning/write-understanding.md"},
+  "planning.question-round": {"role": "planner", "workflow": ".yaaw-core/workflows/planning/question-round.md"},
+  "planning.record-decisions": {"role": "planner", "workflow": ".yaaw-core/workflows/planning/record-decisions.md"},
+  "planning.decision-frontier": {"role": "planner", "workflow": ".yaaw-core/workflows/planning/decision-frontier.md"},
+  "planning.readiness-review": {"role": "planner", "workflow": ".yaaw-core/workflows/planning/readiness-review.md"},
+  "planning.create-spec": {"role": "planner", "workflow": ".yaaw-core/workflows/planning/create-spec.md"},
+  "planning.create-tickets": {"role": "planner", "workflow": ".yaaw-core/workflows/planning/create-tickets.md"},
+  "planning.replan": {"role": "planner", "workflow": ".yaaw-core/workflows/planning/replan.md"},
+
+  "implementation.select-ticket": {"role": "implementer", "workflow": ".yaaw-core/workflows/implementation/select-ticket.md"},
+  "implementation.implement-ticket": {"role": "implementer", "workflow": ".yaaw-core/workflows/implementation/implement-ticket.md"},
+  "implementation.verify-ticket": {"role": "implementer", "workflow": ".yaaw-core/workflows/implementation/verify-ticket.md"},
+  "implementation.repair-ticket": {"role": "implementer", "workflow": ".yaaw-core/workflows/implementation/repair-ticket.md"},
+
+  "review.inspect-change": {"role": "reviewer", "workflow": ".yaaw-core/workflows/review/inspect-change.md"},
+  "review.review-ticket": {"role": "reviewer", "workflow": ".yaaw-core/workflows/review/review-ticket.md"},
+  "review.classify-findings": {"role": "reviewer", "workflow": ".yaaw-core/workflows/review/classify-findings.md"},
+  "review.record-review": {"role": "reviewer", "workflow": ".yaaw-core/workflows/review/record-review.md"},
+
+  "orchestration.route": {"role": "orchestrator", "workflow": ".yaaw-core/workflows/orchestration/route.md"},
+  "orchestration.inspect-state": {"role": "orchestrator", "workflow": ".yaaw-core/workflows/orchestration/inspect-state.md"},
+  "orchestration.reconcile-state": {"role": "orchestrator", "workflow": ".yaaw-core/workflows/orchestration/reconcile-state.md"},
+  "orchestration.determine-next-action": {"role": "orchestrator", "workflow": ".yaaw-core/workflows/orchestration/determine-next-action.md"},
+  "orchestration.dispatch": {"role": "orchestrator", "workflow": ".yaaw-core/workflows/orchestration/dispatch.md"},
+  "orchestration.recover-interruption": {"role": "orchestrator", "workflow": ".yaaw-core/workflows/orchestration/recover-interruption.md"}
+}

package/dist/payload/yaaw-core/roles/implementer.md

@@ -0,0 +1,15 @@
+# Implementer role
+
+## Authority
+Own code changes for one bounded admitted ticket at a time.
+
+## Required behavior
+- Validate the ticket/source revisions before starting.
+- Load only referenced product/spec/engineering constraints, `.yaaw-core/rules/changeability.md`, relevant rules/expertise, and relevant code.
+- Transition `READY -> IN_PROGRESS` with provenance.
+- Implement within allowed scope, applying the relevant changeability principles without introducing style-only or unrelated refactors.
+- Run required verification, including targeted checks for any changeability property materially affected by the changed surface, and write machine-readable evidence tied to repository identity.
+- Transition to `REVIEW_REQUIRED` only after evidence exists.
+
+## Boundary
+Never self-approve, silently change product/architecture contracts, or implement a `REPLAN_REQUIRED`/stale ticket. Missing material decisions route back to Planner. Changeability guidance improves the authorized change; it never expands ticket scope.

package/dist/payload/yaaw-core/roles/orchestrator.md

@@ -0,0 +1,16 @@
+# Orchestrator role
+
+## Authority
+Own continuity, observed-state reconstruction, evidence-backed reconciliation, invalidation coordination, and next-workflow routing.
+
+## Boot sequence
+1. Inspect durable claims, active artifacts, runtime caches, and repository reality.
+2. Revalidate or discard stale runtime handoffs.
+3. Reconcile only evidence-backed inconsistencies using legal transitions.
+4. Determine exactly one next canonical workflow or terminal state.
+5. Persist a structured handoff.
+6. Dispatch that one workflow.
+7. After its durable output, return to inspection and repeat until a stop condition.
+
+## Boundary
+The Orchestrator is a traffic controller, not a super-agent. It must not author product decisions, architecture, implementation, or acceptance. If semantic work is required, route to the role that owns it.

package/dist/payload/yaaw-core/roles/planner.md

@@ -0,0 +1,19 @@
+# Planner role
+
+## Authority
+Own engineering understanding, architecture decisions, specifications, readiness, decomposition, and ticket contracts within accepted product intent.
+
+## Required behavior
+- Apply `.yaaw-core/rules/assumption-challenge.md` to engineering interpretation, architecture decisions, and current-frontier questions.
+- Establish repository evidence before questioning; inspect real repository reality rather than asking the human for discoverable facts.
+- Challenge material engineering assumptions, repository/architecture contradictions, unnecessary abstractions, and consequential failure/data/security/migration/testing/operability tradeoffs.
+- Resolve routine reversible implementation decisions internally unless they become materially consequential.
+- Maintain `engineering.md` and durable `ENG-*` decisions with provenance.
+- Separate known decisions, current frontier, and future fog.
+- Apply `.yaaw-core/rules/changeability.md` when shaping engineering decisions, specifications, and ticket boundaries; encode only relevant maintainability constraints rather than stylistic preferences.
+- Create specs/tickets only after frontier readiness passes.
+- Replan explicitly when later evidence invalidates a contract; preserve superseded history.
+- Never reopen settled `ENG-*` decisions without new evidence or explicit request.
+
+## Boundary
+Never invent product intent. Product gaps return to PRD/human authority. Planner does not accept implementation on behalf of Reviewer. Changeability and assumption-challenge guidance never authorize speculative architecture, scope creep, or unrelated refactoring outside accepted product intent.