yaaw-se 0.3.11 → 0.3.13

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

@@ -1,110 +0,0 @@
-{
-  "yaaw-orchestrator": {
-    "role": "orchestrator",
-    "workflow_id": "orchestration.route",
-    "destination_role": "orchestrator",
-    "requested_workflow": "orchestration.route",
-    "desired_outcome": "CONTINUE",
-    "completion_kind": "CONTINUE_UNTIL_STOP",
-    "description": "Continue or recover a YAAW project by reconstructing reality and dispatching the next safe workflow."
-  },
-  "yaaw-prd": {
-    "role": "prd",
-    "workflow_id": "prd.route",
-    "destination_role": "prd",
-    "requested_workflow": "prd.route",
-    "desired_outcome": "CONTINUE_PRODUCT",
-    "completion_kind": "PRODUCT_READY",
-    "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",
-    "destination_role": "prd",
-    "requested_workflow": "prd.revise",
-    "desired_outcome": "REVISE_PRODUCT",
-    "completion_kind": "PRODUCT_REVISION_ADVANCED",
-    "description": "Change accepted YAAW product intent and invalidate downstream engineering contracts whose basis became stale."
-  },
-  "yaaw-refine-prd": {
-    "role": "prd",
-    "workflow_id": "prd.refine",
-    "destination_role": "prd",
-    "requested_workflow": "prd.refine",
-    "desired_outcome": "REFINE_PRODUCT",
-    "completion_kind": "PRODUCT_REFINED",
-    "description": "Improve clarity and completeness of a YAAW product artifact without changing accepted product meaning."
-  },
-  "yaaw-planner": {
-    "role": "planner",
-    "workflow_id": "planning.route",
-    "destination_role": "planner",
-    "requested_workflow": "planning.route",
-    "desired_outcome": "CONTINUE_PLANNING",
-    "completion_kind": "PLANNING_READY",
-    "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",
-    "destination_role": "planner",
-    "requested_workflow": "planning.readiness-review",
-    "desired_outcome": "PLANNING_REVIEW",
-    "completion_kind": "PLANNING_READINESS_DECIDED",
-    "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",
-    "destination_role": "planner",
-    "requested_workflow": "planning.create-spec",
-    "desired_outcome": "CREATE_SPEC",
-    "completion_kind": "CURRENT_SPEC_ACCEPTED",
-    "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",
-    "destination_role": "planner",
-    "requested_workflow": "planning.create-tickets",
-    "desired_outcome": "CREATE_TICKETS",
-    "completion_kind": "CURRENT_TICKETS_REGISTERED",
-    "description": "Create bounded YAAW implementation ticket contracts from the current accepted specification."
-  },
-  "yaaw-create-tickets": {
-    "role": "planner",
-    "workflow_id": "planning.create-tickets",
-    "destination_role": "planner",
-    "requested_workflow": "planning.create-tickets",
-    "desired_outcome": "CREATE_TICKETS",
-    "completion_kind": "CURRENT_TICKETS_REGISTERED",
-    "description": "Create dependency-aware bounded YAAW implementation tickets from the current accepted specification."
-  },
-  "yaaw-implement": {
-    "role": "implementer",
-    "workflow_id": "implementation.implement-ticket",
-    "destination_role": "implementer",
-    "requested_workflow": "implementation.implement-ticket",
-    "desired_outcome": "IMPLEMENT",
-    "completion_kind": "TICKET_REVIEW_REQUIRED",
-    "description": "Implement one admitted READY YAAW ticket and produce repository-identity-bound verification evidence."
-  },
-  "yaaw-repair": {
-    "role": "implementer",
-    "workflow_id": "implementation.repair-ticket",
-    "destination_role": "implementer",
-    "requested_workflow": "implementation.repair-ticket",
-    "desired_outcome": "REPAIR",
-    "completion_kind": "TICKET_REVIEW_REQUIRED",
-    "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",
-    "destination_role": "reviewer",
-    "requested_workflow": "review.review-ticket",
-    "desired_outcome": "REVIEW",
-    "completion_kind": "TICKET_REVIEW_APPLIED",
-    "description": "Independently review actual YAAW implementation and classify PASS, REPAIR, REPLAN, or BLOCKED against current evidence."
-  }
-}

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

@@ -1,178 +0,0 @@
-{
-  "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",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "DRAFT",
-      "to": "CANCELLED",
-      "owner": "planner",
-      "workflow": "planning.replan",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "READY",
-      "to": "IN_PROGRESS",
-      "owner": "implementer",
-      "workflow": "implementation.implement-ticket",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "READY",
-      "to": "REPLAN_REQUIRED",
-      "owner": "planner",
-      "workflow": "planning.replan",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "IN_PROGRESS",
-      "to": "REVIEW_REQUIRED",
-      "owner": "implementer",
-      "workflow": "implementation.verify-ticket",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "IN_PROGRESS",
-      "to": "REPLAN_REQUIRED",
-      "owner": "planner",
-      "workflow": "planning.replan",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "IN_PROGRESS",
-      "to": "BLOCKED",
-      "owner": "implementer",
-      "workflow": "implementation.implement-ticket",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "REVIEW_REQUIRED",
-      "to": "PASS",
-      "owner": "reviewer",
-      "workflow": "review.record-review",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "REVIEW_REQUIRED",
-      "to": "REPAIR_REQUIRED",
-      "owner": "reviewer",
-      "workflow": "review.record-review",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "REVIEW_REQUIRED",
-      "to": "REPLAN_REQUIRED",
-      "owner": "reviewer",
-      "workflow": "review.record-review",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "REVIEW_REQUIRED",
-      "to": "BLOCKED",
-      "owner": "reviewer",
-      "workflow": "review.record-review",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "REPAIR_REQUIRED",
-      "to": "REVIEW_REQUIRED",
-      "owner": "implementer",
-      "workflow": "implementation.repair-ticket",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "REPAIR_REQUIRED",
-      "to": "REPLAN_REQUIRED",
-      "owner": "planner",
-      "workflow": "planning.replan",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "REPLAN_REQUIRED",
-      "to": "DRAFT",
-      "owner": "planner",
-      "workflow": "planning.replan",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "REPLAN_REQUIRED",
-      "to": "READY",
-      "owner": "planner",
-      "workflow": "planning.replan",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "PASS",
-      "to": "CANCELLED",
-      "owner": "planner",
-      "workflow": "planning.replan",
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "PASS",
-      "to": "REVIEW_REQUIRED",
-      "owner": "orchestrator",
-      "workflow": "orchestration.reconcile-state",
-      "causes": [
-        "REVIEW_MISSING",
-        "REVIEW_REPOSITORY_STALE",
-        "VERIFICATION_MISSING",
-        "VERIFICATION_REPOSITORY_STALE",
-        "LEGACY_IDENTITY_UNVERIFIABLE"
-      ],
-      "state_writer": "orchestrator"
-    },
-    {
-      "from": "PASS",
-      "to": "REPLAN_REQUIRED",
-      "owner": "orchestrator",
-      "workflow": "orchestration.reconcile-state",
-      "causes": [
-        "PRODUCT_SOURCE_STALE",
-        "ENGINEERING_SOURCE_STALE",
-        "SPEC_SOURCE_STALE",
-        "TICKET_SOURCE_STALE",
-        "CONTRACT_INVALIDATED"
-      ],
-      "state_writer": "orchestrator"
-    }
-  ],
-  "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/system/registries/workflows.json

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

package/dist/payload/yaaw-core/system/rules/artifact-writing.md

@@ -1,10 +0,0 @@
-# Artifact writing rules
-
-- Prefer concise durable facts over chat transcripts.
-- Markdown artifacts use YAML frontmatter for schema/id/revision/status metadata and Markdown body for reasoning.
-- Reference decision/artifact IDs instead of duplicating planning history.
-- Keep product language product-focused.
-- Separate repository observations from assumptions.
-- Include provenance when a decision depends on a product requirement, prior decision, spec, observed code, or review finding.
-- Reviews are append-only rounds; never overwrite prior findings.
-- Stale/superseded artifacts remain readable and explicitly marked; do not silently rewrite history.

package/dist/payload/yaaw-core/system/rules/assumption-challenge.md

@@ -1,109 +0,0 @@
-# Assumption challenge
-
-## Purpose
-Improve decision quality inside PRD and Planning without creating a new role, workflow, lifecycle state, artifact, or authority layer.
-
-A challenge is warranted only when resolving it could materially change product intent, engineering design, frontier readiness, scope, failure behavior, or downstream implementation.
-
-## Applicability
-This rule is consumed by PRD and Planner workflows only.
-
-- **PRD** uses it to challenge product assumptions while preserving Human/PRD authority over product intent.
-- **Planner** uses it to challenge engineering assumptions while preserving Planner authority over engineering decisions and Human/PRD authority over product meaning.
-- **Orchestrator** does not challenge the user semantically; it routes to the role that owns the decision.
-- **Implementer** does not use challenge behavior to reopen accepted product or engineering contracts. Missing material decisions return to Planner or PRD through existing routing.
-- **Reviewer** scrutinizes implementation and contracts through independent review outcomes; Reviewer does not substitute for PRD/Planning by interrogating the user.
-
-This rule does not introduce a public skill, `*.grill` workflow, lifecycle state, readiness result, schema field, or durable challenge artifact.
-
-## Core principles
-
-### Facts before questions
-Establish inspectable facts before asking the human. Repository-answerable facts are the active role's responsibility. Planner must gather repository evidence before questioning about frameworks, existing capabilities, system boundaries, or code support.
-
-### Material challenge triggers
-Challenge material assumptions only when there is a concrete reason, such as:
-- conflict with an accepted decision;
-- conflict with repository evidence;
-- ambiguous terminology;
-- an unsupported or unproven assumption;
-- a material tradeoff or difficult-to-reverse choice;
-- a material failure, edge-case, security, data/state, migration, scope, or compatibility implication;
-- a user-flow contradiction or a premature abstraction.
-
-Do not generate filler merely to demonstrate rigor.
-
-### Attack ambiguity, not people
-Challenge the claim or model, never the person. State the concrete implication or contradiction, identify what must be resolved, and keep the tone analytical rather than adversarial.
-
-### Stress-test concrete scenarios
-When material, stress-test the proposed product behavior or engineering design with concrete success, failure, edge, state-transition, security, migration, operability, and compatibility scenarios. Do not invent irrelevant scenarios simply to expand the question count.
-
-### Decision dependencies and current frontier
-Respect decision dependencies. Never ask a dependent question while a prerequisite remains unresolved.
-
-Work only the current frontier:
-- settled reusable conclusions remain known decisions;
-- material questions answerable now belong to the current frontier;
-- issues that depend on future evidence remain future fog.
-
-Questions whose prerequisites are unknown stay out of the current round.
-
-### Recommendations and user ownership
-When meaningful alternatives exist and analysis supports a direction, include a `Recommendation:` and a short reason that exposes the actual tradeoff. Free-form answers remain first-class; options are never a forced menu.
-
-A recommendation must not become confirmation bias. If the tradeoff is preference-dependent or evidence is weak, say so rather than disguising uncertainty.
-
-### Do not delegate owned decisions
-Do not hand decisions back to the human merely because alternatives exist. The active role resolves decisions it owns when repository evidence, accepted constraints, and normal professional judgment are sufficient.
-
-Planner owns routine reversible implementation decisions such as local naming, helper decomposition, obvious repository-convention reuse, routine test organization, and other minor implementation details unless they become materially consequential.
-
-### Persistence and fresh-context recovery
-Persist accepted conclusions rather than a conversation transcript. Durable artifacts record the supported decision, reason, material rejected alternatives where relevant, implications, provenance, remaining assumptions, and unresolved frontier/fog.
-
-Do not persist `User said...`, `Assistant asked...`, debate history, or challenge wording merely because a challenge occurred.
-
-### Recompute after meaningful answers
-After accepted answers are durably recorded, recompute the frontier. Re-evaluate contradictions, assumptions, risks, newly exposed questions, and downstream invalidation before asking another round.
-
-### Stop when the next owner can proceed
-Stop challenging when the next owner can proceed without inventing a material product or engineering decision. Zero questions is valid.
-
-Do not challenge a settled decision merely to demonstrate rigor.
-
-Do not reopen accepted decisions without new evidence, contradiction, changed intent, or explicit human request.
-
-## PRD specialization
-PRD challenges whether the product meaning is sufficiently coherent and intentional. It may challenge:
-- product abstractions that are broader than the demonstrated need;
-- user, scope, behavior, flow, constraint, and non-goal assumptions;
-- contradictions between accepted product statements;
-- ambiguous domain/product terminology;
-- material failure behavior and edge cases;
-- premature product abstractions such as generic roles/permissions when only one concrete capability distinction is established.
-
-PRD must not decide engineering implementation decisions such as transport, database, framework, queue, cache, rendering architecture, ORM, or protocol unless the human explicitly made that method a product constraint. PRD may recommend a product interpretation, but it must not silently reinterpret human product intent.
-
-## Planner specialization
-Planner challenges whether accepted product intent is being interpreted and designed correctly against repository reality. It may challenge:
-- proposed architecture that exceeds the accepted requirement;
-- engineering assumptions contradicted by repository evidence;
-- unnecessary abstractions and new infrastructure;
-- material architecture/data/interface/failure/security/migration/testing/operability tradeoffs;
-- conflicts with accepted `ENG-*` decisions or known future constraints.
-
-Planner must use repository evidence before questioning, must not ask the human to decide routine reversible implementation decisions, and must never invent product intent. A true product gap returns to PRD/human authority through the existing readiness/routing results.
-
-Prefer the smallest architecture justified by accepted product requirements, repository constraints, known future constraints, and material quality requirements. Assumption challenging is not permission for speculative architecture or scope creep.
-
-## Prohibited behaviors
-- creating `@yaaw-grill`, `@yaaw-challenge`, `prd.grill`, or `planning.grill` as parallel semantic implementations;
-- treating the maximum question count as a target;
-- asking repository-answerable facts;
-- asking dependent questions before prerequisites are settled;
-- reopening accepted decisions without a valid trigger;
-- converting a newly discovered adjacent idea into current scope automatically;
-- storing challenge/debate transcripts as durable project memory;
-- allowing PRD to choose architecture or Planner to invent product meaning;
-- allowing Orchestrator, Implementer, or Reviewer to take over PRD/Planner user-question authority.

package/dist/payload/yaaw-core/system/rules/changeability.md

@@ -1,38 +0,0 @@
-# Changeability policy
-
-The governing principle is: **make the next correct change easier without expanding the current authorized change.**
-
-This policy is mandatory for Planner, Implementer, and Reviewer whenever software design or code is being shaped. It governs the quality of work already authorized by product/spec/ticket contracts; it never authorizes unrelated cleanup or speculative refactoring.
-
-## 1. Keep the main path visible
-Prefer control flow where the primary successful operation is easy to identify. Use guard clauses, extraction, or other simplifications when they reduce unnecessary nesting or branching. Do not flatten structure mechanically when nesting communicates real domain structure.
-
-## 2. Name by domain meaning
-Prefer names that expose business/domain meaning over generic containers such as `data`, `item`, `result`, or `obj` when a more specific concept is known. Names should reduce lookup/detective work without becoming needlessly verbose.
-
-## 3. Contain external systems behind boundaries
-Provider-specific schemas, field names, SDK types, transport details, and failure semantics should remain at the integration boundary unless the accepted architecture explicitly requires otherwise. Translate external representations into application/domain concepts at a narrow boundary so provider changes do not ripple through unrelated code.
-
-## 4. Make invalid states harder to represent
-When the domain distinguishes materially different valid states, prefer types, constructors, schemas, invariants, or validation boundaries that make impossible/invalid combinations difficult to create. Do not create type complexity unless it removes meaningful runtime uncertainty.
-
-## 5. Separate decisions from actions
-Keep important business decisions independently understandable and testable when practical. Separate policy/decision logic from database, network, filesystem, notification, or other side effects so rules can be verified without triggering the actions they control.
-
-## 6. Make failures useful
-Errors should provide useful human meaning plus stable machine-readable identity when the surrounding contract supports it. Preserve diagnostic context needed to investigate failures, but never log or expose passwords, authentication/session tokens, API keys, credentials, or sensitive payloads that are not explicitly safe to record.
-
-## 7. Keep changes focused
-A ticket should produce one coherent, reviewable change. A maintainability issue discovered during implementation does not automatically enter scope. Make a supporting change only when it is necessary to satisfy the admitted ticket safely; otherwise leave it unchanged and surface it as a future planning/refactoring candidate when materially valuable.
-
-## Applicability
-Not every principle produces a required code change on every ticket. Apply only the principles relevant to the changed surface and accepted architecture. `NOT_APPLICABLE` is a valid assessment when a principle has no meaningful bearing on the change.
-
-## Review threshold
-A preference is not a defect. A changeability finding is blocking only when concrete evidence shows one of the following:
-- the current implementation violates an accepted engineering/architecture constraint;
-- the design materially increases coupling, ambiguity, invalid-state risk, side-effect entanglement, failure opacity, or review/recovery risk in the changed surface;
-- the change includes unrelated scope that weakens reviewability or rollback safety;
-- the violation prevents adequate testing or makes the ticket contract materially harder to verify.
-
-Review findings must cite the principle, concrete location/evidence, expected property, actual implementation, and required repair or replan action.

package/dist/payload/yaaw-core/system/rules/durable-memory.md

@@ -1,9 +0,0 @@
-# Durable memory rules
-
-1. Conversation is never the only location of an accepted decision.
-2. Record accepted product/engineering decisions before another question round.
-3. Every accepted artifact carries machine-readable identity/revision metadata.
-4. Keep task-specific mistakes in ticket/review history.
-5. Promote only reusable project invariants into `.yaaw-core/project/rules/`.
-6. Preserve superseded/stale artifacts; invalidate their authority instead of deleting history.
-7. A fresh context unable to continue from artifacts indicates incomplete documentation.

package/dist/payload/yaaw-core/system/rules/question-format.md

@@ -1,20 +0,0 @@
-# Question format
-
-Before formatting a PRD or Planning question round, the active role applies `.yaaw-core/system/rules/assumption-challenge.md` to determine which questions belong on the current frontier. This file owns presentation and sequencing only; contradiction detection, stress testing, facts-before-questions, terminology analysis, and role authority remain canonical in the assumption-challenge and authority contracts.
-
-Question rounds contain at most 10 meaningful questions and never filler. The maximum is not a target; zero questions is valid when the active role can safely proceed.
-
-Preferred structure:
-
-```text
-1. Question?
-A. Option
-B. Option
-C. Option
-Recommendation: B
-Reason: ...
-```
-
-Use options and recommendations where useful. Free-form answers are first-class and must never be forced into the offered choices. New unknowns discovered from an answer belong in the next round unless they block recording the current answer safely.
-
-Before presenting another round, persist the accepted answers and update unresolved questions/frontier.

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

@@ -1,9 +0,0 @@
-# Recovery evidence rules
-
-State files are claims. Observed repository evidence is stronger for implementation reality.
-
-Safe reconciliation requires enough evidence to identify the last trustworthy boundary and exact repository identity. Use evidence records, current artifact revisions, git history/diff, and review records together.
-
-When the boundary cannot be established, preserve evidence, avoid destructive re-execution, and return `BLOCKED` with exact missing proof.
-
-Never execute a runtime handoff whose repository or source-revision basis is stale.

package/dist/payload/yaaw-core/system/rules/repository-identity.md

@@ -1,42 +0,0 @@
-# Repository capability and identity
-
-Repository capability and repository identity are related but distinct.
-
-## Capability
-Resolve the YAAW workspace root using `.yaaw-core/system/core/execution-context.md`, then inspect Git only through the canonical utility.
-
-No semantic workflow may independently calculate `worktree_digest`. All repository identity used in handoff, verification, recovery, or review must originate from:
-
-```text
-node .yaaw-core/system/tools/repository-identity.mjs --workspace <WORKSPACE_ROOT>
-```
-
-The tool emits machine-readable JSON on stdout, diagnostics on stderr, and exits non-zero when exact identity cannot be produced. The algorithm identifier is `yaaw-worktree-v2`. Roles and workflows **must not reimplement** it.
-
-## Canonical digest inputs
-All commands execute with `git -C <WORKSPACE_ROOT>` and remain workspace-scoped:
-
-1. `git status --porcelain=v1 -z --untracked-files=all -- . <control-output exclusions>`
-2. `git diff --binary --no-ext-diff --no-textconv HEAD -- . <control-output exclusions>`
-3. `git diff --cached --binary --no-ext-diff --no-textconv HEAD -- . <control-output exclusions>`
-4. `git ls-files --others --exclude-standard -z -- . <control-output exclusions>`
-
-Hash raw stdout bytes. Never hash stderr, warnings, timestamps, absolute paths, ambient CWD, PIDs, or hostnames.
-
-Untracked paths are slash-normalized and sorted. Regular files are hashed from exact bytes. Symlinks are hashed from their exact link-target representation. Unsupported or unreadable objects produce `IDENTITY_FAILED`; they are never silently omitted.
-
-The final digest is SHA-256 over stable canonical UTF-8 JSON containing algorithm, workspace-relative scope, HEAD, component hashes, the explicit exclusions, and the sorted untracked manifest.
-
-## Lifecycle-output exclusions
-`yaaw-worktree-v2` excludes only YAAW files whose normal lifecycle write would otherwise invalidate the repository basis that the file itself records:
-
-- `.yaaw-core/runtime/**` — replaceable observation/handoff/intent/failure caches;
-- `.yaaw-core/project/state.json` — Orchestrator lifecycle ledger;
-- `.yaaw-core/project/evidence/**` — immutable verification attestations;
-- `.yaaw-core/project/reviews/**` — immutable acceptance attestations.
-
-This prevents circular freshness: writing an observation, handoff, state transition, evidence record, or review cannot by itself make the implementation repository identity stale. These artifacts remain governed by their own schemas, revisions, immutability rules, transition sequence, and handoff references.
-
-The exclusion deliberately does **not** cover product, engineering, research, specs, tickets, project rules, `.yaaw-core/install/**`, package-managed `.yaaw-core/system/**`, application files, `.codex/`, `.agents/`, `.claude/`, `.gemini/`, `.cline/`, or other provider/project paths. Changes to those continue to change repository identity.
-
-When the Git top-level is an ancestor, unrelated sibling changes remain outside identity because all commands are scoped to the active workspace.

package/dist/payload/yaaw-core/system/rules/research-admission.md

@@ -1,30 +0,0 @@
-# Research admission
-
-## Purpose
-Keep external research and host-provided expertise evidence-driven rather than letting available tools silently choose architecture.
-
-## Admission basis
-Vendor-, framework-, package-, or platform-specific research is allowed only when at least one basis is explicit in the current durable frontier:
-1. observed repository technology;
-2. accepted product constraint;
-3. accepted `ENG-*` decision;
-4. an explicit current-frontier candidate under evaluation.
-
-Availability of a Codex/host skill is not an admission basis.
-
-## Candidate-neutral rule
-When architecture itself is unresolved, establish decision criteria before vendor-specific research. Compare only candidates that satisfy current product/repository constraints. Do not load a Next.js, Vercel, Supabase, database, framework, or provider skill merely because it exists and then treat that availability as architectural evidence.
-
-## Source quality
-Prefer primary sources: official documentation, specifications, upstream source, first-party APIs, authoritative release notes, and package-registry metadata. Record version/date for version-sensitive claims. Secondary sources may help discover primary evidence but do not replace it for material decisions.
-
-## Durable research
-A material external fact that blocks the current frontier belongs in `.yaaw-core/project/research/RSH-NNN.md`. One artifact answers one bounded question. Research may resolve facts, uncertainty, or conflicts; it does not itself create an `ENG-*` decision.
-
-Planner promotes verified research into engineering truth only through normal decision recording with provenance.
-
-## Host expertise
-YAAW expertise in `.yaaw-core/system/registries/expertise.json` is canonical shared guidance. Provider/host skills are optional advisory expertise and may be loaded only after a research-admission basis exists. Host expertise never grants workflow authority or expands artifact writes.
-
-## Stop rule
-Do not research future fog. If a fact is not needed to make the next bounded frontier implementable, defer it.

package/dist/payload/yaaw-core/system/rules/review-independence.md

@@ -1,11 +0,0 @@
-# Review independence
-
-Reviewer evaluates actual repository work against the current ticket/spec/product/engineering contract and verification evidence.
-
-- Do not accept an Implementer's summary as proof.
-- Tie every review to repository identity plus ticket/spec revisions.
-- Only Reviewer may transition `REVIEW_REQUIRED -> PASS`.
-- A later source revision or repository drift can make prior PASS evidence stale without deleting the historical review.
-- Reviewer may classify `REPLAN`, but Planner owns the resulting contract change.
-- Under orchestrated operation, Reviewer must execute in a different fresh authority context from the Implementer whose work is being accepted. Never role-switch an Implementer worker into Reviewer.
-- Independence is semantic, not a host depth/concurrency setting; it remains required even when a host falls back to inline execution.

package/dist/payload/yaaw-core/system/rules/ticket-sizing.md

@@ -1,9 +0,0 @@
-# Ticket sizing
-
-A ticket is correctly sized when one fresh Implementer can complete one coherent engineering change and verify a concrete outcome without inventing material product or architecture decisions.
-
-Too large: multiple unrelated subsystems, major architecture rediscovery, vague behavior, missing acceptance, or many unverified intermediate states.
-
-Too small: bookkeeping with no coherent independently verifiable outcome.
-
-A ticket cannot be `READY` unless its source spec/frontier is current and dependency states satisfy admission.

package/dist/payload/yaaw-core/system/schemas/project-state.schema.json

@@ -1,12 +0,0 @@
-{
-  "$schema": "https://json-schema.org/draft/2020-12/schema",
-  "$id": "yaaw.project-state",
-  "oneOf": [
-    {
-      "$ref": "project-state-v1.schema.json"
-    },
-    {
-      "$ref": "project-state-v2.schema.json"
-    }
-  ]
-}