yaaw-se 0.3.11 → 0.3.13

package/dist/payload/yaaw-core/system/workflows/orchestration/route.md

@@ -1,27 +0,0 @@
-# Orchestration main loop
-
-## Purpose
-Continuously restore project reality and execute one safe canonical workflow at a time until the active intent is satisfied or a real stop occurs.
-
-## Deterministic preparation
-For normal continuation:
-```text
-node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT>
-```
-
-For a public shortcut:
-```text
-node .yaaw-core/system/tools/orchestration-runtime.mjs --workspace <WORKSPACE_ROOT> --invoke-skill <skill-id>
-```
-
-## Procedure
-Repeat:
-1. run deterministic preparation once;
-2. on `FRAMEWORK_STOP`, stop without lifecycle mutation;
-3. on `RECONCILE_REQUIRED`, apply exactly one reconciliation with `--reconcile-one`, then observe again;
-4. on `ROOT_ACTION`, execute only the returned Orchestrator recovery workflow, then observe again; `ROOT_ACTION` is reserved for evidence-backed interruption recovery, never ordinary `DRAFT` admission;
-5. on `DISPATCH_READY`, execute exactly the persisted handoff once; a dependency-satisfied current `DRAFT` routes to Planner admission, not recovery;
-6. after any worker outcome or disappearance, discard worker text as authority and observe durable reality again;
-7. on `INTENT_COMPLETE`, `TERMINAL`, `BLOCKED`, or human input, stop.
-
-No worker-to-worker authority chain exists. Every semantic successor is selected after reality reconstruction.

package/dist/payload/yaaw-core/system/workflows/planning/create-spec.md

@@ -1,21 +0,0 @@
-# Create specification
-
-## Purpose
-Materialize one coherent ready engineering frontier as a durable implementation contract.
-
-## Preconditions
-Current frontier readiness is `PASS`; its product/engineering revisions remain current; all blocking research is `RESOLVED`; the bounded frontier sections are complete.
-
-## Procedure
-1. Allocate the next `SPEC-NNN` and only now load/create from the canonical spec template.
-2. Record metadata: revision, product revision, engineering revision, frontier ID, decision IDs, and status.
-3. Write goal, repository context, boundaries, behavior, data/state, interfaces, failure modes, security, UX/accessibility, tests, observability, migration/compatibility, non-goals, risks, and acceptance conditions as relevant.
-4. Reference `ENG-*` decisions and material `RSH-*` provenance rather than copying planning history.
-5. Validate required metadata/sections and confirm no unresolved material decision was invented.
-6. Mark spec `ACCEPTED`; otherwise leave `DRAFT`/route back to planning.
-
-## Output
-One current accepted spec or an explicit planning gap.
-
-## Adoption
-Planner writes the accepted spec only. Orchestrator detects the unique current accepted spec and adopts it into state on the next observation. Planner never writes `state.json`.

package/dist/payload/yaaw-core/system/workflows/planning/create-tickets.md

@@ -1,50 +0,0 @@
-# Create tickets
-
-## Purpose
-Create bounded dependency-aware implementation contracts for one current accepted spec, and re-evaluate already-registered `DRAFT` tickets when their admission prerequisites may have changed.
-
-## Preconditions
-Source spec is `ACCEPTED`, product/engineering revisions remain current, planning status is `ready` with readiness `PASS`, and repository requirement `IDENTITY` is satisfied with repository status `READY`.
-
-## Existing-ticket rule
-Before allocating any new `TASK-NNN` ID, inspect current tickets for the active spec. A current `DRAFT` is an admission candidate, not evidence that ticket creation must start over.
-
-Never duplicate an existing ticket merely because it is still `DRAFT`.
-
-## Procedure
-1. If exact repository identity is unavailable, return `PRECONDITION_UNSATISFIED:REPOSITORY_IDENTITY_UNAVAILABLE`; do not admit executable tickets.
-2. Inspect current ticket artifacts and reconciled lifecycle state for the active spec before creating anything.
-3. If routing supplied a current `DRAFT` ticket, re-evaluate that ticket first.
-4. A `DRAFT` may become `READY` only when:
-   - its product, engineering, spec, and ticket revisions are current;
-   - planning remains `ready` with readiness `PASS`;
-   - every declared dependency is `PASS` in reconciled state;
-   - repository identity is current and trustworthy;
-   - its acceptance contract remains implementable without inventing product or engineering decisions; and
-   - any explicit execution prerequisite recorded in its status rationale is currently satisfied.
-5. If the contract itself must change, do not disguise that as admission. Route through `planning.replan`, revise the contract with proper revision/invalidation semantics, then reassess admission.
-6. If the contract is unchanged and admission now passes, update only the ticket artifact status from `DRAFT` to `READY`. Do not rewrite history and do not increment ticket revision solely for the lifecycle admission bit.
-7. If dependencies are not yet `PASS`, keep the ticket `DRAFT`. Normal orchestration should continue the prerequisite ticket rather than repeatedly invoking Planner.
-8. For genuinely missing work, split the accepted spec into coherent `TASK-NNN` units sized for a fresh Implementer.
-9. Apply `.yaaw-core/system/rules/changeability.md` while defining boundaries.
-10. Each ticket metadata records source spec/revision, product revision, engineering decision IDs, dependencies, expertise, ticket revision, and status.
-11. Body records product requirements, relevant areas, required behavior, allowed scope, non-goals, acceptance criteria, required tests, relevant engineering/changeability constraints, and a precise status rationale when left `DRAFT`.
-12. Ensure supporting refactors are admitted only when necessary for safe implementation or verification.
-13. Validate ticket template/metadata before returning success.
-
-## Durable admission fact
-Planner owns the semantic decision that a ticket artifact is `READY`. Planner still never writes `state.json`.
-
-After Planner persists `DRAFT -> READY` in the current ticket artifact, Orchestrator must observe that fact, validate the legal transition and current sources/dependencies/repository identity, then adopt exactly one `TICKET_ADMISSION` reconciliation into state.
-
-Ticket frontmatter therefore does not directly override state. It proposes a Planner-owned durable fact that Orchestrator may adopt only when the admission contract is still valid.
-
-## Output
-Dependency-aware tickets requiring no planning-chat memory, plus one of:
-- newly-created current ticket artifacts;
-- an existing current `DRAFT` promoted to `READY`;
-- an unchanged `DRAFT` with an exact prerequisite reason; or
-- a typed prerequisite/blocker/replan result.
-
-## Registration
-Planner writes ticket artifacts only. Orchestrator registers new current tickets and adopts later Planner admission facts into `state.json` one reconciliation at a time, preventing duplicate ticket creation and preventing lifecycle jumps.

package/dist/payload/yaaw-core/system/workflows/planning/decision-frontier.md

@@ -1,33 +0,0 @@
-# Decision frontier
-
-## Purpose
-Own the canonical partition of known decisions, current implementation frontier, product gaps, blocking external research, and future fog.
-
-## Inputs
-Current product/engineering state, repository evidence/capability, research metadata, and `.yaaw-core/system/rules/assumption-challenge.md` plus `.yaaw-core/system/rules/research-admission.md`.
-
-## Procedure
-For each candidate decision or fact:
-1. Are prerequisites settled?
-2. Is it materially relevant to the next bounded implementation slice?
-3. Can repository evidence answer it without the human?
-4. Is it a product gap that must return to PRD/human authority?
-5. Is it a routine reversible Planner decision that should be resolved internally?
-6. Does it contradict an accepted `ENG-*` decision or repository fact?
-7. Is it based on an unsupported assumption?
-8. Is an external fact genuinely required now? If so, does it have a valid research-admission basis?
-
-Persist exactly:
-- **Known decisions**: settled and reusable.
-- **Current frontier**: one bounded next slice with Goal, Included scope, Explicitly deferred work, Preconditions, Repository facts, Blocking engineering decisions, Blocking external research, Product gaps, and Readiness basis.
-- **Future fog**: issues dependent on later evidence.
-
-When a material external fact blocks the frontier, allocate/update one `RSH-NNN` from the research template with its admission basis. Do not perform the research in this workflow.
-
-Assign/update a stable frontier ID. Only current-frontier decisions/research/product gaps may block readiness.
-
-## Output
-Durable bounded frontier plus zero or more admitted research artifacts. The next route is research, question-round, PRD, readiness, or READY as the persisted partition requires.
-
-## Scope completion signal
-Maintain `engineering.scope_status` on every meaningful frontier update. Use `UNKNOWN` when completion is not proven, `OPEN` when accepted product scope remains after this frontier, and `COMPLETE` only when durable product/planning evidence proves no accepted scope remains. Future ideas/non-goals do not keep accepted scope open.

package/dist/payload/yaaw-core/system/workflows/planning/discover.md

@@ -1,21 +0,0 @@
-# Planning discovery
-
-## Purpose
-Establish workspace/repository-backed engineering facts before asking technical questions or performing vendor-specific research.
-
-## Inputs
-Current product revision, existing engineering artifact, project rules, observed repository capability, relevant specs/tickets, repository/application files when available, and `.yaaw-core/system/rules/assumption-challenge.md`.
-
-## Procedure
-- resolve workspace/repository context through `.yaaw-core/system/core/execution-context.md`;
-- when repository status is `READY`, inspect with root-anchored, workspace-scoped commands;
-- when status is `UNVERSIONED`, inspect filesystem/application reality without inventing Git history and record that limitation explicitly;
-- inspect structure, language/framework/tooling, existing interfaces/data boundaries, tests, deployment/migration constraints, and relevant implementation areas;
-- distinguish observed facts from assumptions;
-- identify product requirements that interact with existing system constraints;
-- apply the assumption-challenge rule to identify contradictions and challenge candidates;
-- do not ask the user anything yet;
-- do not perform vendor/framework web research yet; admission belongs to `planning.decision-frontier`.
-
-## Output
-Repository/system observations, assumptions, contradictions/constraints, challenge candidates, capability limitations, and evidence references for `planning.write-understanding`.

package/dist/payload/yaaw-core/system/workflows/planning/question-round.md

@@ -1,22 +0,0 @@
-# Engineering question round
-
-## Purpose
-Resolve material engineering decisions at the current frontier without forcing fake precision into future fog.
-
-## Inputs
-Current product/engineering revisions, repository observations/evidence relevant to the current frontier, `.yaaw-core/system/rules/assumption-challenge.md`, and `.yaaw-core/system/rules/question-format.md`.
-
-## Procedure
-1. Load only the current decision frontier plus the accepted product/engineering revisions and evidence needed to reason about it.
-2. Apply the assumption-challenge rule to detect contradictions, unsupported engineering assumptions, premature architecture, and material scenario/failure/data/security/migration/testing/operability gaps.
-3. Eliminate questions answerable from repository facts.
-4. Eliminate routine reversible implementation decisions the Planner owns.
-5. Eliminate questions whose prerequisites are unresolved or that belong in future fog.
-6. If a question is actually a missing product decision, return it to PRD/human authority rather than inventing product intent.
-7. Do not reopen settled `ENG-*` decisions without new evidence, contradiction, changed upstream intent, or explicit request.
-8. Ask only currently answerable material engineering questions; prefer fewer high-leverage questions over a full batch.
-9. Format at most 10 using `question-format.md`; include recommendation plus a short reason when analysis supports one and accept free-form alternatives.
-10. Stop for human input.
-
-## Output
-A bounded current-frontier question round awaiting human answers.

package/dist/payload/yaaw-core/system/workflows/planning/readiness-review.md

@@ -1,33 +0,0 @@
-# Planning readiness review
-
-## Purpose
-Use a fresh planning-review context to decide whether the next bounded frontier is implementable without invention.
-
-## Inputs
-Current product/engineering revisions, target frontier ID, relevant repository evidence/capability, all research artifacts referenced as blocking by the frontier, current project rules, and `.yaaw-core/system/rules/assumption-challenge.md`.
-
-## Primary question
-Could a fresh Implementer execute the next frontier without inventing material product or architecture decisions?
-
-## Supporting checks
-- Is the frontier bounded and durably explicit?
-- Does the contract depend on an untested material assumption?
-- Is any blocking `RSH-*` still `PENDING`, `BLOCKED`, or stale?
-- Does accepted engineering contradict repository evidence?
-- Is terminology ambiguous enough to produce materially different implementations?
-- Is an important failure or state transition undefined?
-- Did Planning accidentally convert a product gap into an engineering decision?
-- Are there hidden dependencies between current-frontier decisions?
-- If the next route will create executable tickets, can trustworthy repository identity be obtained? If not, readiness cannot claim immediate implementation admission.
-
-Apply the assumption-challenge rule without expanding scope or reopening settled decisions gratuitously.
-
-## Results
-- `PASS`: bounded frontier executable and no blocking research/product/engineering gap remains;
-- `MISSING_DECISIONS`: Planner must resolve engineering questions;
-- `PRODUCT_GAP`: return to PRD/human authority;
-- `REPLAN`: accepted planning conflicts with later evidence;
-- `BLOCKED`: required evidence/repository capability unavailable.
-
-## Mutations
-Record result, frontier ID, source revisions, reason, and evidence durably in `engineering.md`/state. A PASS is stale if its product/engineering/research basis changes.

package/dist/payload/yaaw-core/system/workflows/planning/record-decisions.md

@@ -1,19 +0,0 @@
-# Record engineering decisions
-
-## Purpose
-Convert accepted engineering answers into durable, independently resumable decisions.
-
-## Inputs
-Current engineering artifact, latest accepted engineering answers, current product authority, repository evidence, resolved research referenced by the frontier, and `.yaaw-core/system/rules/assumption-challenge.md`.
-
-## Procedure
-1. Validate the accepted answer against current repository facts and role authority.
-2. If the answer changes or supplies missing product meaning, return `PRODUCT_GAP` to PRD/human authority.
-3. If it conflicts with an accepted `ENG-*` decision, supersede that decision explicitly and execute invalidation/replan semantics.
-4. Otherwise create/update `ENG-NNN` entries with Status, Decision, Reason, material rejected alternatives, implications, and product/repository/research provenance.
-5. Increment engineering revision for material contract changes.
-6. Record durable conclusions rather than the challenge/question transcript.
-7. Mark the current frontier/readiness stale and return to `planning.route`; `planning.decision-frontier` must recompute the canonical frontier before another question round or readiness check.
-
-## Output
-Updated `engineering.md` with stable decision IDs/provenance and a stale frontier requiring recomputation.

package/dist/payload/yaaw-core/system/workflows/planning/replan.md

@@ -1,24 +0,0 @@
-# Replan
-
-## Purpose
-Repair an invalid engineering contract without erasing prior decisions or acceptance history.
-
-## Preconditions
-Repository evidence, product revision, review finding, or invalidation has made current planning materially insufficient.
-
-## Procedure
-1. Identify exact evidence and affected `ENG-*`/spec/ticket assumptions.
-2. Mark superseded decisions explicitly; never overwrite their history.
-3. Make new engineering decisions within current product authority and increment engineering revision.
-4. Execute invalidation propagation to dependent specs/tickets/reviews.
-5. Rebuild current decision frontier and rerun readiness before implementation resumes.
-6. Revised tickets move through `DRAFT`/`READY` using legal transitions; never jump directly back to PASS.
-
-## Output
-Current engineering contract plus updated downstream admission state.
-
-## Admission guard
-
-Repository identity change alone is not sufficient reason to replan. Require stale source/contract revisions or Reviewer `REPLAN` evidence.
-
-Planner may revise engineering/spec/ticket artifacts but never writes lifecycle state directly. Orchestrator observes the durable revised contract and applies legal admission/invalidation transitions.

package/dist/payload/yaaw-core/system/workflows/planning/research.md

@@ -1,20 +0,0 @@
-# Planning research
-
-## Purpose
-Resolve exactly one admitted external engineering fact that blocks the current decision frontier.
-
-## Inputs
-Exact current `.yaaw-core/project/research/RSH-NNN.md`, current product/engineering revisions, current frontier ID, only relevant repository context, `.yaaw-core/system/rules/research-admission.md`, and selected expertise when admitted.
-
-## Procedure
-1. Require the research artifact status to be `PENDING` and its product/engineering/frontier basis to remain current.
-2. Verify its vendor/framework/platform scope has a valid admission basis from `research-admission.md`.
-3. Prefer official documentation, specifications, upstream source, first-party APIs, authoritative release notes, and package-registry metadata.
-4. Source every material claim. Record version/date for version-sensitive facts and record conflicts rather than choosing silently.
-5. If evidence is insufficient, mark the artifact `BLOCKED` and state exactly what proof is missing.
-6. If resolved, record findings/source ledger and mark `RESOLVED`.
-7. Do not create an `ENG-*` decision merely because research finished. Return to `planning.decision-frontier` so a fresh Planner promotes only relevant verified facts through normal planning.
-8. Planner never spawns a research peer; this is a Planner workflow.
-
-## Output
-One durable `RESOLVED` or `BLOCKED` research artifact and a typed result to Orchestrator.

package/dist/payload/yaaw-core/system/workflows/planning/route.md

@@ -1,28 +0,0 @@
-# Planner route
-
-## Purpose
-Choose and execute the next canonical planning workflow from durable product/planning/repository state.
-
-## Inputs
-Current product/engineering metadata, research/spec/ticket metadata, project rules, observed repository capability, current intent, and repository reality needed only for route selection.
-
-## Progressive selection
-Do not open candidate planning workflow bodies before one route is selected.
-
-## Priority
-1. missing/stale repository understanding -> execute `planning.discover`, then `planning.write-understanding`;
-2. missing/stale decision frontier after understanding/decision changes -> `planning.decision-frontier`;
-3. `REPLAN_REQUIRED` or invalidated contract -> `planning.replan`;
-4. accepted human answers not yet recorded -> `planning.record-decisions`;
-5. current frontier has admitted `PENDING` external research -> `planning.research`;
-6. unresolved human-owned engineering decisions -> `planning.question-round`;
-7. readiness not current -> `planning.readiness-review`;
-8. readiness PASS but no current accepted spec -> `planning.create-spec`;
-9. accepted spec lacks tickets, or a current dependency-satisfied `DRAFT` needs admission re-evaluation -> `planning.create-tickets`;
-10. current `DRAFT` tickets whose dependencies are not yet `PASS` do not preempt runnable implementation/review work; normal orchestration continues their prerequisites;
-11. otherwise return planning frontier `READY`.
-
-After each selected workflow persists durable output, return to routing before loading another workflow.
-
-## Execution
-Resolve and execute selected workflow IDs through `.yaaw-core/system/registries/workflows.json`; do not merely report which one would run.

package/dist/payload/yaaw-core/system/workflows/planning/write-understanding.md

@@ -1,26 +0,0 @@
-# Write engineering understanding
-
-## Purpose
-Create the durable repository-backed checkpoint from which a fresh Planner can continue.
-
-## Inputs
-Product interpretation, discovery observations, repository capability, and `.yaaw-core/system/rules/assumption-challenge.md` results.
-
-## Procedure
-Update `.yaaw-core/project/engineering.md` using existing semantic sections:
-- repository observations -> Existing system;
-- unsupported beliefs -> Assumptions;
-- actual unresolved decisions -> Unresolved questions;
-- future-dependent issues -> Future fog;
-- material dangers -> Risks;
-- accepted engineering solutions -> `ENG-*` decisions;
-- compatibility-critical structure -> Architecture spine.
-
-Preserve repository capability limitations explicitly. Never store challenge/debate transcripts. Do not create vendor-specific research simply from available host skills.
-
-Increment engineering revision when durable engineering understanding materially changes. Record provenance for repository observations and product dependencies.
-
-After the durable write, mark the frontier as needing recomputation and return to `planning.route`; `planning.decision-frontier` owns the canonical partition.
-
-## Output
-Updated engineering artifact requiring frontier analysis or normal continuation.

package/dist/payload/yaaw-core/system/workflows/prd/create.md

@@ -1,22 +0,0 @@
-# Create PRD
-
-## Purpose
-Initialize product memory and drive product discovery until the current frontier is ready or needs human answers.
-
-## Inputs
-Human's product goal, product template, current state, and `.yaaw-core/system/rules/assumption-challenge.md`.
-
-## Procedure
-1. If the canonical YAAW layout is incomplete, create missing `.yaaw-core/project/`, `.yaaw-core/runtime/`, and required durable artifacts from `.yaaw-core/system/templates/`; never overwrite existing project memory.
-2. If `product.md` is absent inside an existing `.yaaw-core/project/`, create it from the canonical template and set product state to `draft`.
-3. Capture the supplied goal without technicalizing it.
-4. Identify the highest-value unresolved product questions by applying the assumption-challenge rule to the supplied goal and any already-accepted product context.
-5. Execute `prd.question-round`; do not create a second interrogation loop in this workflow.
-6. After every human response execute `prd.record-decisions` before asking more.
-7. Execute `prd.readiness` when no material product ambiguity blocks the next engineering frontier.
-
-## Mutations
-Product artifact, product status, bootstrap state when required, and state-transition provenance.
-
-## Output
-Updated product artifact plus either human questions or a readiness result.

package/dist/payload/yaaw-core/system/workflows/prd/question-round.md

@@ -1,20 +0,0 @@
-# PRD question round
-
-## Purpose
-Resolve only the material product unknowns visible at the current frontier.
-
-## Inputs
-Current `product.md`, unresolved product questions, `.yaaw-core/system/rules/assumption-challenge.md`, and `.yaaw-core/system/rules/question-format.md`.
-
-## Procedure
-1. Apply the assumption-challenge rule to accepted product truth and the unresolved product frontier.
-2. Detect material contradictions, ambiguous terminology, unsupported product assumptions, premature abstractions, and important scenario/failure/edge gaps.
-3. Exclude questions whose prerequisites remain unresolved.
-4. Exclude engineering-only questions unless the human explicitly made implementation a product constraint.
-5. Rank only material current-frontier product questions; prefer fewer high-leverage questions over a full batch.
-6. Format at most 10 questions using `question-format.md`; use options, recommendation, and a short reason when useful.
-7. Treat free-form answers as first-class and never force the offered options.
-8. Stop for human answers.
-
-## Output
-A bounded question round awaiting human answers. Do not mutate accepted decisions before answers arrive.

package/dist/payload/yaaw-core/system/workflows/prd/readiness.md

@@ -1,22 +0,0 @@
-# PRD readiness
-
-## Purpose
-Decide whether a fresh Planner can safely begin the next engineering frontier.
-
-## Inputs
-Current `product.md`, current accepted scope, and `.yaaw-core/system/rules/assumption-challenge.md`.
-
-## Decision
-Ask both:
-1. Can a fresh Planner understand the goal, users, expected behavior, scope, constraints, non-goals, and remaining product unknowns without the original chat?
-2. Are there any material product assumptions, contradictions, or ambiguous terms in the current engineering frontier that would force a fresh Planner to invent product intent?
-
-Return:
-- `READY` when intent is sufficient for the next engineering frontier and the second answer is no;
-- `NEEDS_QUESTIONS` when material current-frontier product ambiguity remains;
-- `BLOCKED` when required human/product evidence is unavailable.
-
-Future fog is allowed. Readiness does not require every future product question to be solved.
-
-## Mutations
-On `READY`, mark product/state ready with current product revision. Do not claim every future requirement is known.

package/dist/payload/yaaw-core/system/workflows/prd/record-decisions.md

@@ -1,20 +0,0 @@
-# Record PRD decisions
-
-## Purpose
-Turn human answers into durable product truth before conversation continues.
-
-## Inputs
-Current product artifact, latest human answers, and `.yaaw-core/system/rules/assumption-challenge.md`.
-
-## Procedure
-1. Interpret only what the answers support and validate the conclusion against PRD product authority.
-2. Persist supported meaning in the relevant product sections and accepted product decisions; record conclusions rather than challenge/question transcripts.
-3. Remove settled questions and check the accepted answer for impact on previous accepted product decisions, scope, constraints, behavior, and non-goals.
-4. Preserve explicit corrections and non-goals; if a contradiction/correction changes accepted meaning, update product truth explicitly rather than silently merging both meanings.
-5. Increment product `revision` and record provenance only when accepted product meaning materially changes.
-6. If downstream planning/spec/ticket artifacts already depend on changed intent, execute the invalidation policy in `.yaaw-core/system/core/invalidation.md`.
-7. Reapply the assumption-challenge rule to discover newly exposed questions and recompute the unresolved current product frontier.
-8. Only after the durable write and frontier recomputation may another question round begin.
-
-## Output
-Updated `product.md`, product revision/status, recomputed unresolved product frontier, and any invalidation result.

package/dist/payload/yaaw-core/system/workflows/prd/refine.md

@@ -1,15 +0,0 @@
-# Refine PRD
-
-## Purpose
-Improve clarity/completeness without changing accepted product meaning.
-
-## Inputs
-Current product artifact, requested clarification/cleanup, and `.yaaw-core/system/rules/assumption-challenge.md`.
-
-## Procedure
-Consolidate duplicates, sharpen language, organize behavior/non-goals, and surface unresolved questions. Apply assumption challenging only to distinguish wording ambiguity from a genuine semantic contradiction. Preserve semantic meaning and product revision.
-
-If assumption challenging exposes a genuine semantic contradiction or an edit would change accepted behavior, scope, constraints, or non-goals, do not silently resolve it during refinement; stop refinement and execute `prd.revise` instead.
-
-## Output
-Clearer product artifact with unchanged semantic revision unless the workflow switches to revision.

package/dist/payload/yaaw-core/system/workflows/prd/revise.md

@@ -1,18 +0,0 @@
-# Revise PRD
-
-## Purpose
-Change already accepted product intent while preserving history and invalidating stale downstream trust.
-
-## Inputs
-Current accepted product revision, explicit human-requested change, and `.yaaw-core/system/rules/assumption-challenge.md`.
-
-## Procedure
-1. Identify the exact old requirement and requested new intent.
-2. Apply the assumption-challenge rule to the requested intent: test impact on accepted behavior, scope/non-goals, constraints, contradictions, and newly exposed product questions.
-3. Resolve only product-semantic issues under PRD/human authority; do not convert the revision into engineering design.
-4. Update `product.md`, increment product revision, and record the change/provenance.
-5. Execute `.yaaw-core/system/core/invalidation.md` against dependent engineering decisions, specs, tickets, and reviews.
-6. Mark product `draft` if new material current-frontier questions remain; otherwise run `prd.readiness`.
-
-## Boundary
-Assumption challenging does not bypass explicit revision semantics. Do not rewrite engineering decisions yourself; invalidate their basis and return ownership to Planner.

package/dist/payload/yaaw-core/system/workflows/prd/route.md

@@ -1,23 +0,0 @@
-# PRD route
-
-## Purpose
-Choose and execute the next product-definition workflow from current product state and the human's request.
-
-## Inputs
-`.yaaw-core/project/product.md` if present, `.yaaw-core/project/state.json`, current request, and relevant accepted product history.
-
-## Procedure
-1. Classify exactly one route:
-   - missing product -> `prd.create`;
-   - draft product with unresolved questions -> `prd.question-round`;
-   - clarity-only cleanup requested -> `prd.refine`;
-   - accepted intent change requested -> `prd.revise`;
-   - sufficient current intent -> terminal PRD result `READY`.
-2. For a workflow route, resolve the canonical ID through `.yaaw-core/system/registries/workflows.json` and execute it; do not stop after classification.
-3. After the workflow writes durable output, re-evaluate product state or return control to Orchestrator.
-
-## Output
-Either one executed canonical PRD workflow or `READY` with the current product revision.
-
-## Stop conditions
-Stop for human answers when material product ambiguity remains. Never infer engineering implementation choices as product intent.

package/dist/payload/yaaw-core/system/workflows/review/classify-findings.md

@@ -1,17 +0,0 @@
-# Classify findings
-
-## Purpose
-Convert concrete review evidence into one authoritative outcome.
-
-## Classification
-- `PASS`: current contract satisfied with adequate evidence.
-- `REPAIR`: implementation defect; ticket/spec remain valid. This includes bounded changeability defects supported by concrete engineering impact.
-- `REPLAN`: ticket/spec/engineering contract is materially invalid or insufficient.
-- `BLOCKED`: required evidence is unavailable.
-
-## Findings
-Assign durable `F-NNN` IDs and severity. Each finding records category, concrete evidence, expected behavior/property, actual behavior/implementation, and required repair/replan action.
-
-For changeability findings, also record the violated principle and why the issue is more than a style preference. Valid categories include `CORRECTNESS`, `SECURITY`, `REGRESSION`, `CONTRACT`, `CHANGEABILITY`, `TESTING`, `COMPATIBILITY`, and `UX`.
-
-Do not choose `REPAIR` when satisfying the finding requires changing accepted product/architecture meaning. Do not fail a review for personal style preference alone.

package/dist/payload/yaaw-core/system/workflows/review/inspect-change.md

@@ -1,20 +0,0 @@
-# Inspect change
-
-## Purpose
-Build an evidence-grounded view of the actual implementation to review.
-
-## Inputs
-Current ticket/spec/product/engineering revisions, repository status `READY` plus exact workspace-scoped identity, actual repository state, project rules, verification evidence, and relevant expertise.
-
-## Procedure
-1. If repository status is not `READY`, return `BLOCKED`/`PRECONDITION_UNSATISFIED:REPOSITORY_IDENTITY_UNAVAILABLE`; do not review against ambiguous identity.
-2. Revalidate source revisions and reject stale review inputs.
-3. Compute/record repository identity using `rules/repository-identity.md` and the canonical utility.
-4. Inspect actual diff/files/tests/evidence; ignore implementation summaries when they conflict with observed work.
-5. Identify acceptance criteria, failure paths, regressions, and domain-specific requirements that must be checked.
-
-## Output
-Review inspection tied to exact repository and contract identity.
-
-## Repository basis
-Obtain repository identity from `.yaaw-core/system/tools/repository-identity.mjs`. Do not whitelist `.codex`, `.agents`, provider directories, or project/application files merely by path ownership. Only replaceable `.yaaw-core/runtime/**` coordination caches are excluded by the canonical identity algorithm so orchestration cannot invalidate its own handoff basis.

package/dist/payload/yaaw-core/system/workflows/review/record-review.md

@@ -1,19 +0,0 @@
-# Record review
-
-## Purpose
-Persist immutable Reviewer-owned acceptance history and return the authorized lifecycle outcome to Orchestrator without writing the state ledger directly.
-
-## Procedure
-1. Create the next immutable `.yaaw-core/project/reviews/TASK-NNN-RK.md` from the review template.
-2. Frontmatter records ticket/review round, result, ticket/spec revisions, reviewed repository identity, and evidence references.
-3. Body records findings, verification, evidence interpretation, and next action.
-4. Never overwrite prior review rounds.
-5. Select exactly one legal semantic outcome:
-   - `PASS` authorizes target ticket state `PASS`;
-   - `REPAIR` authorizes `REPAIR_REQUIRED`;
-   - `REPLAN` authorizes `REPLAN_REQUIRED`;
-   - `BLOCKED` authorizes `BLOCKED`.
-6. Reviewer writes only the immutable review artifact and returns the typed result. Reviewer does not edit `.yaaw-core/project/state.json`.
-7. Orchestrator re-inspects the new review, validates source/repository/evidence freshness, and records exactly the authorized transition plus provenance in `state.json`. Orchestrator may not substitute a different acceptance outcome.
-
-A prior PASS remains historical but becomes stale when repository/source revisions invalidate its basis.

package/dist/payload/yaaw-core/system/workflows/review/review-ticket.md

@@ -1,24 +0,0 @@
-# Review ticket
-
-## Purpose
-Independently determine whether current implementation satisfies the current ticket contract.
-
-## Preconditions
-`.yaaw-core/project/state.json` is admitted read-only context. Its `tickets[TASK-NNN]` lifecycle value is authoritative for workflow admission and is `REVIEW_REQUIRED`, unless Orchestrator explicitly admitted a source-current stale-`PASS` acceptance revalidation.
-
-Ticket frontmatter `status` is artifact metadata/admission history and may still say `READY` or another earlier value after later lifecycle transitions. It does not override the reconciled state ledger. Source revisions and evidence must still be current enough to review.
-
-If state and stronger source/repository/evidence reality materially conflict, return `BLOCKED` with the exact conflict for Orchestrator reconciliation. Do not edit state.
-
-## Procedure
-1. Use a fresh review context when practical.
-2. Execute `review.inspect-change`.
-3. Check every acceptance criterion and required test/evidence.
-4. Inspect regressions, failure paths, security, UX/accessibility, migration, and compatibility when relevant.
-5. Apply `.yaaw-core/system/rules/changeability.md` to the changed surface. Assess only materially relevant principles and distinguish concrete engineering defects from style preferences.
-6. For any blocking changeability finding, record the principle, concrete location/evidence, expected property, actual implementation, engineering impact, and bounded repair/replan action.
-7. Execute `review.classify-findings`.
-8. Execute `review.record-review`.
-
-## Output
-Exactly one result: `PASS`, `REPAIR`, `REPLAN`, or `BLOCKED`. Style preference alone cannot produce a failing result.