yaaw-se 0.1.0-dev.35745937645.1

package/dist/payload/yaaw-core/templates/product.md

@@ -0,0 +1,26 @@
+---
+schema: yaaw.product/v1
+revision: 1
+status: draft
+---
+# Product
+
+## Goal
+
+## Target users
+
+## User problems
+
+## Expected behavior
+
+## Important flows
+
+## Constraints
+
+## Scope
+
+## Non-goals
+
+## Accepted product decisions
+
+## Unresolved product questions

package/dist/payload/yaaw-core/templates/project-state.json

@@ -0,0 +1,13 @@
+{
+  "schema": "yaaw.project-state/v1",
+  "phase": "product",
+  "product": {"artifact": ".yaaw-core/project/product.md", "status": "missing", "revision": 0},
+  "planning": {"artifact": ".yaaw-core/project/engineering.md", "status": "missing", "revision": 0, "current_frontier": null, "readiness": "pending", "active_spec": null},
+  "active_ticket": null,
+  "tickets": {},
+  "transition_sequence": 0,
+  "last_transition": null,
+  "blocker": null,
+  "last_observed_commit": null,
+  "last_workflow": null
+}

package/dist/payload/yaaw-core/templates/review.md

@@ -0,0 +1,28 @@
+---
+schema: yaaw.review/v1
+ticket: TASK-XXX
+round: 1
+result: RESULT
+ticket_revision: 1
+spec_revision: 1
+reviewed_head_commit: COMMIT
+reviewed_dirty: true
+reviewed_worktree_digest: DIGEST
+evidence: []
+---
+# REVIEW-TASK-XXX-R1
+
+## Result rationale
+
+## Reviewed state
+
+## Findings
+
+## Changeability assessment
+Record only materially relevant principles. Use `PASS`, `FAIL`, or `NOT_APPLICABLE`; do not use subjective scores. Blocking failures must cite concrete engineering impact rather than style preference.
+
+## Verification
+
+## Evidence
+
+## Next action

package/dist/payload/yaaw-core/templates/spec.md

@@ -0,0 +1,29 @@
+---
+schema: yaaw.spec/v1
+id: SPEC-XXX
+revision: 1
+status: DRAFT
+product_revision: 1
+engineering_revision: 1
+frontier_id: FRONTIER-001
+decision_ids: []
+---
+# SPEC-XXX
+
+## Goal
+## Product source
+## Repository context
+## Engineering decisions
+## Architecture / boundaries
+## Expected behavior
+## Data / state changes
+## Interfaces
+## Failure modes
+## Security considerations
+## UX / accessibility requirements
+## Testing expectations
+## Observability
+## Migration / compatibility
+## Non-goals
+## Open risks
+## Acceptance conditions

package/dist/payload/yaaw-core/templates/ticket.md

@@ -0,0 +1,28 @@
+---
+schema: yaaw.ticket/v1
+id: TASK-XXX
+revision: 1
+spec: SPEC-XXX
+spec_revision: 1
+product_revision: 1
+engineering_revision: 1
+status: DRAFT
+dependencies: []
+decision_ids: []
+expertise: []
+---
+# TASK-XXX
+
+## Goal
+## Source specification
+## Product requirements
+## Engineering decisions
+## Relevant files / areas
+## Required behavior
+## Allowed scope
+## Explicit non-goals
+## Acceptance criteria
+## Required tests
+## Dependencies
+## Expertise hints
+## Status rationale

package/dist/payload/yaaw-core/workflows/implementation/implement-ticket.md

@@ -0,0 +1,21 @@
+# Implement ticket
+
+## Purpose
+Implement one admitted bounded ticket and produce reviewable evidence.
+
+## Preconditions
+Ticket is `READY`, dependencies pass, source revisions are current, and repository state is consistent.
+
+## Procedure
+1. Load the ticket, referenced product/spec/decisions, `.yaaw-core/rules/changeability.md`, relevant rules/expertise, and relevant code only.
+2. Record `READY -> IN_PROGRESS` with transition provenance and repository identity.
+3. Establish the minimum authorized implementation surface before editing.
+4. Implement strictly within allowed scope while applying only the changeability principles relevant to the changed surface: visible main path, domain naming, external boundaries, valid-state modeling, decision/side-effect separation, useful failures, and focused change scope.
+5. Do not perform style-only rewrites, speculative abstractions, or unrelated cleanup. If a discovered maintainability issue is not necessary for safe ticket completion, leave it unchanged and surface it as a future planning candidate when materially valuable.
+6. If a material missing decision appears, transition to `REPLAN_REQUIRED` or `BLOCKED`; do not invent it.
+7. Execute `implementation.verify-ticket`, including targeted verification for materially affected changeability properties.
+8. Persist evidence tied to ticket/spec revisions and repository identity.
+9. Transition `IN_PROGRESS -> REVIEW_REQUIRED` only when required evidence exists.
+
+## Output
+Reviewable implementation plus evidence, or explicit replan/blocker state.

package/dist/payload/yaaw-core/workflows/implementation/repair-ticket.md

@@ -0,0 +1,18 @@
+# Repair ticket
+
+## Purpose
+Correct implementation defects while keeping the accepted ticket/spec contract unchanged.
+
+## Preconditions
+Ticket is `REPAIR_REQUIRED` and latest review result is `REPAIR` against the same current contract revisions.
+
+## Procedure
+1. Load the same ticket contract, `.yaaw-core/rules/changeability.md`, latest review findings, and relevant code/evidence.
+2. Repair only what is needed to satisfy the unchanged plan and the concrete review findings; do not broaden scope into adjacent cleanup.
+3. Apply the relevant changeability principles when they are part of the defect or needed for a safe repair.
+4. If repair requires product/architecture contract changes, transition to `REPLAN_REQUIRED` and stop.
+5. Rerun relevant verification, including any previously failed changeability check, and append a new evidence record.
+6. Transition `REPAIR_REQUIRED -> REVIEW_REQUIRED` with provenance.
+
+## Output
+Repaired reviewable implementation or replan/blocker result.

package/dist/payload/yaaw-core/workflows/implementation/select-ticket.md

@@ -0,0 +1,16 @@
+# Select ticket
+
+## Purpose
+Choose exactly one safe implementation unit.
+
+## Inputs
+Ticket states, dependencies, current source revisions, repository reality, and optional specifically requested ticket.
+
+## Procedure
+1. If state/repository disagree, route to orchestration recovery first.
+2. Reject `DRAFT`, `BLOCKED`, `REPLAN_REQUIRED`, `REPAIR_REQUIRED`, `REVIEW_REQUIRED`, `PASS`, or stale-source tickets for normal implementation.
+3. Choose the specifically requested eligible ticket, otherwise the next dependency-satisfied `READY` ticket.
+4. Revalidate source spec/product/engineering revisions immediately before admission.
+
+## Output
+One admitted `READY` ticket or no-ticket/blocker result.

package/dist/payload/yaaw-core/workflows/implementation/verify-ticket.md

@@ -0,0 +1,17 @@
+# Verify ticket
+
+## Purpose
+Produce reproducible implementation evidence without self-accepting the ticket.
+
+## Inputs
+Ticket requirements/tests, changed surface, project tooling/rules, current repository identity.
+
+## Procedure
+1. Run every test/check required by the ticket.
+2. Add targeted regression checks justified by the changed surface.
+3. For each materially relevant changeability principle from `.yaaw-core/rules/changeability.md`, verify the concrete property rather than a style preference. Examples include boundary mapping behavior, invalid-state rejection, decision logic independent of side effects, stable error identity, and focused-diff inspection.
+4. Record commands, exit/result, relevant checks (including relevant changeability checks), ticket/spec revisions, and exact repository identity in `.yaaw-core/project/evidence/EVIDENCE-TASK-NNN-VK.json` using the evidence schema.
+5. Preserve failed evidence; do not rewrite it as success.
+
+## Output
+Evidence record(s). Verification never transitions a ticket to PASS; only Reviewer can accept.

package/dist/payload/yaaw-core/workflows/orchestration/determine-next-action.md

@@ -0,0 +1,16 @@
+# Determine next action
+
+## Purpose
+Turn reconciled observed reality into one explicit, fresh dispatch contract.
+
+## Inputs
+Current observed-state snapshot, reconciled state, `core/routing.md`, workflow/expertise registries.
+
+## Procedure
+1. Choose exactly one next canonical workflow or terminal state using explicit routing precedence.
+2. Select only expertise relevant to that workflow/artifact.
+3. Write `.yaaw-core/runtime/handoff.json` conforming to the handoff schema with role, workflow ID, active artifact, exact references/revisions, selected expertise, expected output, repository identity, and transition sequence basis.
+4. If the result is human-input, BLOCKED, or COMPLETE, write no executable handoff and return the stop result.
+
+## Boundary
+Do not perform target role semantic work here.

package/dist/payload/yaaw-core/workflows/orchestration/dispatch.md

@@ -0,0 +1,17 @@
+# Dispatch one handoff
+
+## Purpose
+Execute exactly one already-selected canonical workflow. This file is not the orchestration loop.
+
+## Inputs
+`.yaaw-core/runtime/handoff.json` created by `orchestration.determine-next-action`.
+
+## Procedure
+1. Validate handoff schema, workflow registry entry, role, source artifact revisions, transition-sequence basis, and repository identity.
+2. If any basis is stale, discard the handoff and return `STALE_HANDOFF` to `orchestration.route`; do not execute it.
+3. Load target role contract, target workflow contract, exact references, selected expertise, and minimal relevant repository context.
+4. Execute the target workflow once.
+5. Require its expected durable output/state/evidence or an explicit stop result.
+6. Mark/remove the consumed runtime handoff and return control to `orchestration.route`.
+
+Never recursively dispatch `orchestration.dispatch` as its own target.

package/dist/payload/yaaw-core/workflows/orchestration/inspect-state.md

@@ -0,0 +1,17 @@
+# Inspect state
+
+## Purpose
+Create a non-mutating observed-reality snapshot that separates claims from evidence.
+
+## Inputs
+`.yaaw-core/project/state.json`, product/engineering artifacts, current specs/tickets/reviews/evidence/runtime files, project rules, and repository status/diff/log/branch.
+
+## Procedure
+1. Compute current repository identity.
+2. Read machine-readable artifact metadata and active durable artifacts.
+3. Compare state claims with artifact/repository/review evidence without repairing yet.
+4. List inconsistencies, stale artifacts/handoffs, blockers, and candidate next states.
+5. Write replaceable `.yaaw-core/runtime/observed-state.json` conforming to the observed-state schema.
+
+## Output
+Observed-state snapshot only; no semantic or ticket-state mutation.

package/dist/payload/yaaw-core/workflows/orchestration/reconcile-state.md

@@ -0,0 +1,16 @@
+# Reconcile state
+
+## Purpose
+Repair only evidence-backed state inconsistencies before routing semantic work.
+
+## Inputs
+Current observed-state snapshot, state claims, artifact revisions, repository/evidence/review identity.
+
+## Procedure
+- apply `core/recovery.md`, `core/transitions.md`, and `core/invalidation.md`;
+- examples: `IN_PROGRESS` + implementation + passing verification + no review -> `REVIEW_REQUIRED`; stale `PASS` -> `REPLAN_REQUIRED` or `REVIEW_REQUIRED` according to cause; `READY` + implementation already present -> recover/inspect rather than duplicate;
+- never change product/architecture meaning during reconciliation;
+- every repaired state records transition reason/evidence and increments transition sequence.
+
+## Output
+Reconciled state or `BLOCKED` when the last trustworthy boundary cannot be proven.

package/dist/payload/yaaw-core/workflows/orchestration/recover-interruption.md

@@ -0,0 +1,17 @@
+# Recover interruption
+
+## Purpose
+Resume safely after context/session failure without duplicating already-completed work.
+
+## Inputs
+Active/recent artifact, state claims, runtime caches, repository identity/history/diff, verification/review evidence.
+
+## Procedure
+1. Discard stale runtime handoffs/snapshots.
+2. Identify the last trustworthy completed boundary.
+3. If implementation exists, prefer verification/review over reimplementation when evidence supports it.
+4. Reconcile only via legal transitions with provenance.
+5. If the boundary cannot be proven, return `BLOCKED` with exact missing evidence.
+6. Return control to `orchestration.route` for normal next-action selection.
+
+Never repeat destructive work merely because a context ended.

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

@@ -0,0 +1,20 @@
+# Orchestration main loop
+
+## Purpose
+Continuously restore project reality and execute one safe canonical workflow at a time until a true stop condition.
+
+## Procedure
+Repeat:
+1. execute `orchestration.inspect-state`;
+2. execute `orchestration.reconcile-state` when inconsistencies exist;
+3. execute `orchestration.determine-next-action`;
+4. if terminal/blocked/human-input stop condition is returned, stop;
+5. execute `orchestration.dispatch` for the one persisted handoff;
+6. require the dispatched workflow to persist its artifact/state/evidence output;
+7. discard the consumed handoff and return to step 1.
+
+## Loop safety
+If the same repository identity, state, handoff, and expected output repeat without any durable mutation/evidence change, stop as `BLOCKED` with `no_progress` rather than spinning.
+
+## Stop conditions
+Human product/engineering answer required; evidence/permission unavailable; host requires approval for consequential action; or accepted scope is terminal `COMPLETE`.

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

@@ -0,0 +1,18 @@
+# Create specification
+
+## Purpose
+Materialize one coherent ready engineering frontier as a durable implementation contract.
+
+## Preconditions
+Current frontier readiness is `PASS` and its product/engineering revisions still match.
+
+## Procedure
+1. Allocate the next `SPEC-NNN` and create from the canonical 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 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.

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

@@ -0,0 +1,19 @@
+# Create tickets
+
+## Purpose
+Translate one current accepted spec into bounded dependency-aware implementation contracts.
+
+## Preconditions
+Source spec is `ACCEPTED` and its product/engineering revisions remain current.
+
+## Procedure
+1. Split work into coherent `TASK-NNN` units sized for a fresh Implementer.
+2. Apply `.yaaw-core/rules/changeability.md` while defining boundaries. Encode only changeability constraints that are materially relevant to the ticket; do not turn stylistic preferences or speculative refactors into requirements.
+3. Each ticket metadata records source spec/revision, product revision, engineering decision IDs, dependencies, expertise, ticket revision, and status.
+4. Body records product requirements, relevant areas, required behavior, allowed scope, non-goals, acceptance criteria, required tests, and relevant engineering/changeability constraints when needed.
+5. Ensure scope remains focused: supporting refactors are admitted only when necessary for safe implementation or verification of the ticket behavior; unrelated cleanup remains outside the ticket.
+6. Validate ticket template/metadata.
+7. Set `READY` only when dependencies and planning admission are satisfied; otherwise `DRAFT`.
+
+## Output
+Dependency-aware tickets that require no planning-chat memory and preserve focused, reviewable change boundaries.

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

@@ -0,0 +1,27 @@
+# Decision frontier
+
+## Purpose
+Prevent giant-planner behavior by separating what is known, answerable now, and legitimately unknown.
+
+## Inputs
+Current product/engineering state, repository evidence, and `.yaaw-core/rules/assumption-challenge.md`.
+
+## Procedure
+Before partitioning each candidate decision, apply the assumption-challenge rule and ask:
+1. Are its prerequisites settled?
+2. Is it materially relevant to the next implementation slice?
+3. Can repository evidence answer it without the human?
+4. Is it actually a product gap that must return to PRD/human authority?
+5. Is it only a routine reversible Planner decision that should be resolved internally?
+6. Does it contradict an accepted `ENG-*` decision or repository fact?
+7. Is the apparent decision based on an unsupported assumption?
+
+Then preserve the three-way partition exactly:
+- **Known decisions**: settled and reusable;
+- **Current frontier**: material decisions answerable now that block the next implementation slice;
+- **Future fog**: questions dependent on future implementation/evidence.
+
+Assign/update a stable frontier ID in engineering metadata. Only current-frontier decisions may block readiness for the next slice. Dependent questions with unsettled prerequisites remain outside the current frontier.
+
+## Output
+Updated known decisions/frontier/fog and the bounded scope subject to readiness review.

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

@@ -0,0 +1,17 @@
+# Planning discovery
+
+## Purpose
+Establish repository-backed engineering facts before asking technical questions.
+
+## Inputs
+Current product revision, existing engineering artifact, project rules, relevant specs/tickets, repository, and `.yaaw-core/rules/assumption-challenge.md`.
+
+## Procedure
+- inspect repository 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 between accepted product requirements and repository reality, architecture constraints, unsupported assumptions, and potential challenge candidates;
+- do not ask the user anything yet.
+
+## Output
+Repository/system observations, assumptions, contradictions/constraints, challenge candidates, and evidence references for `planning.write-understanding`.

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

@@ -0,0 +1,22 @@
+# 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/rules/assumption-challenge.md`, and `.yaaw-core/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/workflows/planning/readiness-review.md

@@ -0,0 +1,32 @@
+# Planning readiness review
+
+## Purpose
+Use a fresh planning-review context to decide whether the next frontier is implementable without invention.
+
+## Inputs
+Current product/engineering revisions, target frontier ID, relevant repository evidence, current project rules, and `.yaaw-core/rules/assumption-challenge.md`.
+
+## Primary question
+Could a fresh Implementer execute the next frontier without inventing material product or architecture decisions?
+
+## Supporting checks
+- Does the contract depend on an untested material assumption?
+- Does accepted engineering contradict repository evidence?
+- Is terminology ambiguous enough to produce multiple materially valid 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?
+
+Apply the assumption-challenge rule to these checks without expanding scope or reopening settled decisions gratuitously.
+
+## Results
+- `PASS`: frontier executable;
+- `MISSING_DECISIONS`: Planner must resolve engineering questions;
+- `PRODUCT_GAP`: return to PRD/human authority;
+- `REPLAN`: accepted planning conflicts with later evidence;
+- `BLOCKED`: required evidence unavailable.
+
+Do not add a challenge-specific readiness result.
+
+## Mutations
+Record result, frontier ID, source revisions, reason, and evidence durably in `engineering.md`/state. A PASS is stale if its product/engineering basis changes.

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

@@ -0,0 +1,20 @@
+# 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, and `.yaaw-core/rules/assumption-challenge.md`.
+
+## Procedure
+1. Validate the accepted answer against current repository facts and role authority before recording it.
+2. If the answer changes or supplies missing product meaning, return `PRODUCT_GAP` to PRD/human authority rather than encoding it as engineering truth.
+3. If it conflicts with an accepted `ENG-*` decision, supersede that decision explicitly and execute invalidation/replan semantics; never silently overwrite history.
+4. Otherwise create/update `ENG-NNN` entries with Status, Decision, Reason, material rejected alternatives, implications, and product/repository provenance.
+5. Increment engineering revision for material contract changes.
+6. Reapply the assumption-challenge rule to recompute assumptions, risks, unresolved questions, current frontier, future fog, and architecture spine.
+7. Record durable conclusions rather than the challenge/question transcript.
+8. Only after recording and recomputation may another question round begin.
+
+## Output
+Updated `engineering.md` with stable decision IDs, provenance, and recomputed assumptions/frontier/fog.

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

@@ -0,0 +1,18 @@
+# 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.

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

@@ -0,0 +1,20 @@
+# Planner route
+
+## Purpose
+Choose and execute the next canonical planning workflow from durable product/planning/repository state.
+
+## Inputs
+Current `product.md`, `engineering.md` if present, `.yaaw-core/project/state.json`, relevant specs/tickets, project rules, and repository reality.
+
+## Priority
+1. missing/stale repository understanding -> execute `planning.discover`, then `planning.write-understanding`, then re-evaluate;
+2. `REPLAN_REQUIRED` or invalidated contract -> `planning.replan`;
+3. accepted human answers not yet recorded -> `planning.record-decisions`;
+4. unresolved current decision frontier -> `planning.question-round`;
+5. readiness not current -> `planning.readiness-review`;
+6. readiness PASS but no current accepted spec -> `planning.create-spec`;
+7. accepted spec lacks admitted tickets -> `planning.create-tickets`;
+8. otherwise return planning frontier `READY`.
+
+## Execution
+Resolve and execute selected workflow IDs through `registries/workflows.json`; do not merely report which one would run.

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

@@ -0,0 +1,24 @@
+# Write engineering understanding
+
+## Purpose
+Create the durable checkpoint from which a fresh Planner can continue.
+
+## Inputs
+Product interpretation, discovery observations, and `.yaaw-core/rules/assumption-challenge.md` results.
+
+## Procedure
+Update `.yaaw-core/project/engineering.md` using existing semantic sections rather than adding a challenge log:
+- repository observations -> Existing system;
+- unsupported beliefs -> Assumptions;
+- actual unresolved decisions -> Unresolved questions / Current decision frontier;
+- future-dependent issues -> Future fog;
+- material dangers -> Risks;
+- accepted engineering solutions -> `ENG-*` decisions;
+- compatibility-critical structure -> Architecture spine.
+
+Also preserve product interpretation and engineering constraints. Never store challenge/debate transcripts.
+
+Increment engineering revision when the durable engineering contract/understanding materially changes. Record provenance for repository observations and product dependencies.
+
+## Output
+Updated engineering artifact ready for frontier analysis or questioning.

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

@@ -0,0 +1,22 @@
+# 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/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/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/workflows/prd/question-round.md

@@ -0,0 +1,20 @@
+# PRD question round
+
+## Purpose
+Resolve only the material product unknowns visible at the current frontier.
+
+## Inputs
+Current `product.md`, unresolved product questions, `.yaaw-core/rules/assumption-challenge.md`, and `.yaaw-core/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/workflows/prd/readiness.md

@@ -0,0 +1,22 @@
+# 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/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/workflows/prd/record-decisions.md

@@ -0,0 +1,20 @@
+# Record PRD decisions
+
+## Purpose
+Turn human answers into durable product truth before conversation continues.
+
+## Inputs
+Current product artifact, latest human answers, and `.yaaw-core/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 `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.