aw-spec-cli 0.1.7 → 0.1.9

package/assets/.appweaver/orchestrator/rev-templates/ai-rules.reference.md

@@ -0,0 +1,40 @@
+<!--
+  rev-templates/ai-rules.reference.md — domain-agnostic AI OPERATING rules for
+  the reverse-engineering authors. Unlike the other files in this folder this is
+  NOT a shape skeleton — it is genuine, generic operating guidance (how to
+  behave), and it asserts NO project principle, NO domain content, and NO tech
+  stack. It is safe to load directly. Kept here (not in the greenfield guardrails/
+  tree) so the brownfield reverse-engineering authors are self-contained on a real
+  brownfield repo.
+-->
+# AI Operational Rules (reverse-engineering)
+
+> Pure operating rules — domain-agnostic, stack-agnostic. Applies to every brownfield
+> reverse-engineering authoring step (onboard's constitution + rule-set authors, adopt).
+
+The **code, the deterministic scan, and any adopted spec.md / design.md / source-map.md + the
+OKF bundle are ground truth.** Author only what they evidence; they override any pre-trained
+habit and any greenfield template ideal.
+
+## Evidence discipline
+
+- Author a principle / rule ONLY for a trait the adopted docs actually evidence. If the code does
+  not show it, it is not a rule here.
+- CITE the concrete proof inline (a design section, a named type / port / config, a spec id). An
+  assertion you cannot ground does not belong in the output.
+- State partial / stubbed / optional behaviour AT THE LEVEL THE CODE REACHES — never the ideal.
+  Route unmet ideals / stubs / deferrals to the as-built debt list, never assert them.
+
+## Format vs content
+
+- The skeletons in this folder are SHAPE ONLY. Copy their headings, frontmatter, and tone; never
+  copy a bracketed token or an example concept as if it were this project's value.
+- Do NOT import a concept, identifier, terminology, regulatory claim, or rule that this project's
+  code / specs / designs do not evidence.
+
+## Operating envelope
+
+- Write ONLY the declared output target (or, for a rule set, only inside the project folder). No
+  drive-by edits to unrelated files.
+- No secrets, connection strings, or production hostnames in any authored file.
+- Preserve the rule partition: design and implement receive no domain file.

package/assets/.appweaver/orchestrator/rev-templates/delta-design-template.skeleton.md

@@ -0,0 +1,101 @@
+<!--
+  ═══════════════════════════════════════════════════════════════════════════
+  rev-templates/delta-design-template.skeleton.md — SHAPE-ONLY reference.
+
+  This file is the FORMAT reference for the reverse-engineered DELTA-design
+  TEMPLATE that onboard installs at
+  .appweaver/templates/overrides/delta-design-template.md. It carries the neutral
+  bones of a change record — the classification triple, the impact and
+  regression sections, the two ledgers, the close contract — and NOTHING ELSE.
+
+  IT NAMES NO LAYERING AND NO TECHNOLOGY. The "Section" column below is a SLOT:
+  it is filled with the ACTUAL sections of the master design template generated
+  alongside this one, whatever the code turned out to be organised into. A
+  greenfield delta template's example rows name its four layers; naming any
+  layer here would re-import exactly the assumption onboard exists to displace.
+
+  MIRRORS THE MASTER, ALWAYS. The delta-design module classifies changes "per
+  the master's OWN section structure", so this template is derived FROM the
+  generated master design template rather than from a fixed list. If the master
+  has axes A, B and C, the example rows here name A, B and C. That coupling is
+  the point: a change is classified against the document it amends.
+
+  DISCIPLINE THIS SKELETON ENFORCES (structurally — there is no project content
+  here to leak):
+    • ONE MASTER — a change amends specs/<Aggregate>/design.md; it never opens a
+      second design document.
+    • ADDED / MODIFIED / REMOVED — the complete classification. A shared element
+      is MODIFIED in place, never duplicated into the change.
+    • EVERY ROW SERVES A SPEC ID — the delta reads the spec, never the domain
+      rule files.
+    • TECHNOLOGY-AGNOSTIC — signatures and field shapes, no code, exactly as in
+      the master.
+  ═══════════════════════════════════════════════════════════════════════════
+-->
+# Delta Design — [CR-ID]: [TITLE]
+
+**Feature (aggregate)**: [Aggregate]
+
+**Base version**: [vX.Y]
+
+<!--
+  This delta applies to the SINGLE master design at specs/[Aggregate]/design.md
+  — never a new design doc. Classify every design change ADDED / MODIFIED /
+  REMOVED against the current master, per the MASTER'S OWN SECTIONS, in the same
+  technology-agnostic form: behaviour as signatures + pre/post/invariant/raises,
+  contracts as field shapes, no code. A new command is a new USER STORY realised
+  as delta elements, not a new feature. After this delta is applied,
+  `implement-delta` regenerates the touched slice and regression re-tests the
+  dependents of every shared element.
+-->
+
+## Change summary
+
+[One paragraph: what the design change is and which user story / spec delta it serves.]
+
+## ADDED — new design elements
+
+<!-- New elements and the realisation of any new spec constraint, classification
+     or contract. "Section" names a section of THIS project's master design —
+     the same section titles the generated design template carries. -->
+
+| Section (§ in design.md) | Element | Kind | Serves |
+|---|---|---|---|
+| [§ of the master's own structure] | `[element]` | [kind] | US-[n] · FR-[nnn] |
+
+## MODIFIED — existing design elements
+
+<!-- Edits to elements the master already defines. A shared element is modified
+     here, in place — never copied into the change. -->
+
+| Section (§ in design.md) | Element | What changes | Why |
+|---|---|---|---|
+| [§ of the master's own structure] | `[element]` | [the edit] | US-[n] |
+
+## REMOVED
+
+- [design element removed + why] — or `None`
+
+## Cross-section impact
+
+[Which of the master's sections ripple; shared elements touched; whether a data
+migration is needed (yes/no); any contract change other systems couple to.]
+
+## Regression targets
+
+[Existing user stories / behaviours to re-verify because a shared element
+changed.]
+
+## New assumptions / deviations (from this change)
+
+<!-- Anything this change defers — folds into the master's DA-n / WA-n ledgers
+     on apply. -->
+
+- **DA-[n]**: [assumption to clarify later] — or `None`
+- **WA-[n]**: [deviation to clear later] — or `None`
+
+## On close
+
+`finalize-delta` merges this record into the master design.md and appends the
+Change History row; `close-delta` bumps the version and archives the change
+under `changes/archive/`.

package/assets/.appweaver/orchestrator/rev-templates/design-template.skeleton.md

@@ -0,0 +1,245 @@
+<!--
+  ═══════════════════════════════════════════════════════════════════════════
+  rev-templates/design-template.skeleton.md — SHAPE-ONLY reference.
+
+  This file is the FORMAT reference for the reverse-engineered DESIGN TEMPLATE
+  that onboard installs at .appweaver/templates/overrides/design-template.md. It
+  carries the neutral bones every design document has — the header block, the
+  authoring contract, the traceability spine, the two deferral ledgers, the
+  Change History — and the section skeleton, and NOTHING ELSE.
+
+  IT NAMES NO LAYERING, NO ARCHITECTURE STYLE AND NO TECHNOLOGY — not the one a
+  greenfield template would assume, and not an alternative to it either, because
+  naming any of them hands the generator an answer to the single question it
+  exists to ask the code. The §2 axes below are SLOTS, discovered from the repo's
+  own folders, projects and modules. Every [BRACKET] token is filled FROM THE
+  CODE, never copied.
+
+  THIS IS A TEMPLATE OF A TEMPLATE. What onboard generates from it is not a
+  filled design — it is the project's design TEMPLATE, which the forward
+  `design` phase and `adopt` then fill once per feature. So the generated file
+  keeps [PLACEHOLDER] tokens and authoring comments; what onboard replaces is
+  the STRUCTURE (which sections exist, what they are called), not the content.
+
+  WHAT IS PINNED, AND WHY (DESIGN-FORMAT.md § Brownfield variant is the
+  authority — these are the only fixed points, and each earns it by being
+  something a tool keys on):
+    • §1.2 is the DOMAIN / DATA MODEL. `aw-xref` reads it for `<Other>Id`
+      reference edges, so its position is machinery, not taste.
+    • Exactly one §2 subsection's heading contains the word "Integration".
+      `aw-xref` matches it by keyword to extract contract edges, which is what
+      lets a derived layout and the greenfield layout be read by one tool.
+    • The traceability spine (§4) and both ledgers (§5 DA-n, §6 WA-n) survive
+      every layout — the analyze gates read them.
+    • The §0–§6 numbering itself: the forward `design` bootstrap_bf branch
+      names those sections in its prompt.
+  Everything else — how many §2 axes there are, what they are called, what
+  lives in each — is the code's answer, not the kit's.
+
+  DISCIPLINE THIS SKELETON ENFORCES (structurally — there is no project content
+  here to leak):
+    • AS-BUILT — describe the structural convention the code ACTUALLY follows,
+      confirmed by reading source, never a convention it ought to follow.
+    • ONE AXIS PER RECURRING STRUCTURE — a component the code has that fits no
+      textbook layer gets its own section; a layer the code lacks does not
+      appear at all, and its absence is not a gap.
+    • NOT DEBT — being organised unlike a reference architecture is the as-built
+      shape, recorded in §1.1. The §6 ledger takes only debt the code itself
+      evidences.
+    • TECHNOLOGY-AGNOSTIC — the generated template stays language-free even
+      though it was derived from a real stack: signatures + pre/post/invariant/
+      raises, contracts as field shapes. The stack binds at `implement`.
+  ═══════════════════════════════════════════════════════════════════════════
+-->
+# Design: [AGGREGATE]
+
+**Aggregate (feature)**: `[Aggregate]`
+
+**Design home**: `specs/[Aggregate]/design.md`
+
+**Source spec**: `specs/[Aggregate]/spec.md`
+
+**Version**: v1.0
+
+**Status**: Draft
+
+<!--
+  WHAT THIS DOCUMENT IS
+  =====================
+  The single, living High-Level Design for ONE aggregate — the MEDIATOR between
+  spec.md (WHAT/WHY) and the generated code (HOW). It carries structure,
+  contracts, behaviour and decisions; it is not code.
+
+  ANCHORING RULES
+  - Every design element traces UP to a spec id (FR-/BR-/CN-/DC-/IC-/US-/SC-)
+    and the whole spec is covered DOWN here (§4). No element without a spec
+    reason; no requirement without a design home.
+  - THE SPEC IS THE ONLY DOMAIN INPUT. Design reads the spec + the technical
+    standards, never the domain rule files. A domain rule the spec omits is
+    recorded as a §5 assumption, never smuggled in.
+  - Feature = aggregate. A later requirement is a DELTA on this document.
+
+  STRUCTURE FOLLOWS THIS PROJECT'S CODE
+  - [GENERATED_STRUCTURE_NOTE] — form: one or two sentences naming the
+    structural convention this repo actually follows and the dependency
+    direction it observes, with the folders/projects that evidence it. This
+    stands where a greenfield template would state a standing layering rule.
+
+  TECHNOLOGY-AGNOSTIC (mandatory)
+  - Express behaviour as SIGNATURES + pre/post/invariant/raises and contracts
+    as field shapes — never language code. Conceptual types only
+    (string, int, decimal, enum, list<T>, set<T>, id<T>, money, date). The same
+    design must be generatable on another stack without edits.
+
+  HOW TO AUTHOR
+  - Fill every [PLACEHOLDER]; keep the section order. Omit a §2 subsection only
+    when this feature genuinely has nothing there (say why); never "N/A".
+  - §5 and §6 are MANDATORY ledgers. Empty reads "None (as of vX.Y)", never a
+    deletion.
+  - GROUND each filled section in the ACTUAL CODE and the reverse-engineered
+    governance — cite real file/folder paths and the technical-constitution
+    principle the decision rests on. Never a greenfield assumption.
+  - Delete these authoring comments as you fill each section.
+-->
+
+## 0. Design Overview
+
+<!-- One paragraph: the shape of this aggregate and the 3–5 decisions that
+     matter most. The project's standing structural convention is NOT restated
+     here — it is §1.1. -->
+
+[The architectural essence of this aggregate in 3–6 sentences.]
+
+### Ubiquitous Language (design delta)
+
+<!-- Only the terms this design introduces or sharpens beyond the spec. These
+     become code identifiers. -->
+
+| Term | Meaning in this design |
+|---|---|
+| [Port / concept name] | [precise definition] |
+
+## 1. Architecture Context & Domain Model
+
+### 1.1 As-Built Architecture
+
+[AS_BUILT_ARCHITECTURE_CONTENT]
+<!-- Form: the structural convention THIS repo follows — its real
+     folder/project/module names, what each holds, the dependency direction
+     between them, and the technology base from constitution.technical.md —
+     each with a representative code path. A new feature ALIGNS to this rather
+     than introducing a second convention. State an inconsistency as an
+     inconsistency and name the dominant form; do not pick a winner the code
+     has not picked. -->
+
+### 1.2 Domain / Data Model
+
+<!-- PINNED ANCHOR — follow spec.md exactly. Entities & value objects are the
+     spec's Key Entities (SAME names); invariants are its Business Rules
+     (BR-nnn, cite each); the boundary is its Aggregate Boundary; states are its
+     lifecycle. Cross-slice references are BY ID and live here — the
+     cross-reference tool reads this section for those edges. -->
+
+| Element | Kind | Fields / shape | Invariants (BR-) |
+|---|---|---|---|
+| `[Entity]` | entity [(root)] | [field: type, …] | BR-00X |
+| `[ValueObject]` | value object | [field: type, …] | BR-00X |
+
+**Lifecycle / states**: [states + transitions, or `None`]
+
+**References to other aggregates**: [`<Other>Id` — by id only, or `None`]
+
+## 2. Component & Behaviour Design
+
+<!-- ONE `### 2.n` SUBSECTION PER RECURRING STRUCTURAL AXIS THIS PROJECT USES,
+     each TITLED with the project's OWN folder/tier/module name. The count and
+     the titles are the code's answer — the slots below are illustrative
+     positions, not a required set. In each: the components that live there,
+     their behaviour in signature form, and the contracts they expose or
+     require. -->
+
+### 2.1 [PROJECT_STRUCTURAL_AXIS_NAME]
+
+<!-- [What this axis holds in this codebase + the representative path that
+     evidences it.] -->
+
+| Component | Behaviour (signature) | Pre / Post / Raises | Serves |
+|---|---|---|---|
+| `[Component]` | `[operation](args) -> result` | [pre / post / raises] | FR-00X · US-Y |
+
+### 2.n [PROJECT_STRUCTURAL_AXIS_NAME]
+
+<!-- … one per axis the code actually shows, then stop … -->
+
+### 2.[N] External Integrations
+
+<!-- PINNED ANCHOR — the heading MUST contain the word "Integration"; the
+     cross-reference tool matches it by keyword to extract contract edges. One
+     row per IC- the spec names, realised as the port/adapter this project's
+     own structure puts it in. Empty only if the spec has no IC-. -->
+
+| Integration | Direction | Contract (field shape) | Realised in | Serves |
+|---|---|---|---|---|
+| `[External system]` | [in / out] | [request/response shape] | [§2.n component] | IC-00X |
+
+## 3. Cross-Cutting Concerns
+
+<!-- One row per concern this feature must honour. "Serves" is a spec id, or a
+     §5 DA-n where the technical constitution mandates the element and no
+     per-feature spec id exists — never a fabricated CN-. Keep only the rows
+     this project's governance actually carries. -->
+
+| Concern | Design decision | Serves |
+|---|---|---|
+| [Concern from constitution.technical.md / the spec] | [where enforced] | [spec id / DA-n] |
+
+## 4. Traceability (the spine)
+
+<!-- The two-way guarantee: every FR/BR/CN/DC/IC/US/SC has a design home, and
+     every design element has a spec reason. EVERY CN-/DC-/IC- in the spec MUST
+     appear as a row. The last column names THIS project's own sections. -->
+
+| Spec id | Type | Design element(s) | Section |
+|---|---|---|---|
+| FR-001 | requirement | `[element]` | [§ refs in this document's own structure] |
+| BR-001 | invariant | [invariant home] | §1.2 |
+| CN-001 | constraint | [where realised] | [§] |
+| DC-001 | classification | [exposure enforcement] | [§] |
+| IC-001 | contract | [port/adapter] | [§ Integrations] |
+| US-1 | story | [end-to-end elements] | [§] |
+| SC-001 | success | [where met + how verified] | [§] |
+
+## 5. Assumptions (to clarify later)
+
+<!-- MANDATORY LEDGER. Every default or open interpretation this design commits
+     to so it can proceed without blocking — including any cross-cutting element
+     the technical constitution mandates that has no per-feature spec id (state
+     the basis as "per Const. §<n>", which is what lets the analyze gate accept
+     it). Empty → "None (as of vX.Y)". -->
+
+| id | Assumption | Why deferred | Impact if wrong | Owner / resolve-by |
+|---|---|---|---|---|
+| DA-1 | [what was assumed] | [why not clarified now] | [blast radius] | [role / phase] |
+
+## 6. Deviations & Deferred Decisions (to clear later)
+
+<!-- MANDATORY LEDGER. Structural debt KNOWINGLY taken — a shortcut, a temporary
+     coupling, a deferred split — with the proper end-state and the trigger that
+     forces the cleanup. AS-BUILT DISCIPLINE: this ledger records only debt the
+     CODE evidences. Being organised unlike a reference architecture is NOT a
+     deviation — that is the as-built shape and it belongs in §1.1.
+     Empty → "None (as of vX.Y)". -->
+
+| id | Deviation taken | Proper end-state | Trigger to revisit | Serves / caused by |
+|---|---|---|---|---|
+| WA-1 | [the shortcut/coupling] | [the clean design] | [what forces it] | [FR / constraint] |
+
+## Change History
+
+<!-- In lockstep with spec.md. finalize-delta appends the row when it merges a
+     delta; close-delta bumps the version and stamps it into the header. A
+     change is a DELTA on this document, never a new design doc. Newest last. -->
+
+| Version | Date | Change | User stories | CR |
+|---------|------|--------|--------------|-----|
+| v1.0 | [DATE] | Initial design | US-1 | — |

package/assets/.appweaver/orchestrator/rev-templates/domain-constitution.skeleton.md

@@ -0,0 +1,63 @@
+<!--
+  rev-templates/domain-constitution.skeleton.md — SHAPE-ONLY reference for the
+  domain-constitution SOURCE (guardrails/projects/[project]/domain/domain-constitution.md),
+  the human-readable
+  charter the domain half is authored from (so the normal /appweaver
+  constitution can re-derive it later). It shows the Project-Identity + Domain-
+  Principle shape ONLY. No principle set to inherit; every principle is
+  discovered from the adopted specs and cited.
+
+  THIS IS A PROJECT CHARTER, NOT AN AGGREGATE SPEC. Even with one adopted
+  aggregate, describe the domain / bounded context AS A WHOLE — the adopted
+  aggregate(s) are the current evidence, never the subject.
+-->
+# [PROJECT_NAME] Domain Constitution (as-built)
+
+> `origin: reverse-engineered` · [YYYY-MM-DD]. Domain addenda to the technology base — compose
+> with the technical half; not ratified on its own.
+
+## Project Identity
+
+- **Project name:** [PROJECT_NAME] (from the OKF overview).
+- **Mission:** [from the OKF overview Purpose].
+- **Bounded contexts / aggregate map:** [list the adopted aggregate(s) AND named external
+  references / ports as not-yet-adopted contexts — from the overview's aggregate map + index].
+- **Architecture posture:** [as-built posture named from the designs — not an ideal].
+
+## Domain Principles
+
+<!-- Numbered to CONTINUE the technology base, which is authored later and is evidenced-only (do
+     NOT assume it ends at any fixed numeral). Use a stable "D1, D2, …" convention here — this is
+     the human charter, not a constitution half; the domain half's author reads the finished
+     technical half and assigns the roman numerals there. TITLE each by its DOMAIN CONCERN,
+     never by an aggregate name. State each as a rule that would still hold if a second aggregate
+     entered the same context; cite the aggregate(s) + spec ids as the evidence it generalises. -->
+
+### D1 — [DOMAIN-CONCERN TITLE] [(NON-NEGOTIABLE)?]
+[The rule the code ACTUALLY enforces — as-built, testable. Note an observed gap as a plain
+principle, not a target.]
+Extends technology [principle ref]. Evidence: [BR-/CN-/DC-/IC-/FR- ids]. → [rule file(s)]
+
+### D2 — [DOMAIN-CONCERN TITLE] [(NON-NEGOTIABLE)?]
+[…]
+Extends technology [principle ref]. Evidence: [ids]. → [rule file(s)]
+
+<!-- … one per domain concern the specs evidence … -->
+
+## Folder Structure Additions
+
+- [Only domain-specific additions the module actually uses; otherwise "none beyond the base".]
+
+## Security & Governance Addenda
+
+- [As-built posture: auditability, authorization surface, classification — named from evidence.]
+- [Stub/permissive adapters recorded as migration debt, not claimed as satisfied ideals.]
+
+## Governance Overrides
+
+- [Domain change-authority / mandatory approvers — observed or TODO(GOVERNANCE): assign.]
+- Base amendment procedure and SemVer policy in the technical half still apply.
+
+## Domain Requirements Pointer
+
+→ guardrails/projects/[project]/domain/domain-requirements.md

package/assets/.appweaver/orchestrator/rev-templates/domain-requirements.skeleton.md

@@ -0,0 +1,48 @@
+---
+origin: reverse-engineered
+generated_by: aw-spec-onboard/[VERSION]
+---
+<!--
+  rev-templates/domain-requirements.skeleton.md — SHAPE-ONLY reference for the
+  project's domain/domain-requirements.md: a PROJECT-LEVEL overview of the domain the project
+  governs (not a single-aggregate spec). It opens with a bounded-context /
+  module map (from the OKF overview + aggregate index), then per-subsection
+  pointers to the generated rule files, platform topology, and governance
+  overrides. Fill the map from the ACTUAL adopted aggregates + named external
+  references; add a subsection pointer ONLY for a file you generated.
+-->
+# DOMAIN REQUIREMENTS — [PROJECT_NAME] (project-level)
+
+> Project-level enumeration and headline profiles for the **[PROJECT_NAME]** domain. Detailed
+> domain rules are expanded in the sibling files in this folder. Reverse-engineered, as-built.
+
+=====================================================================
+[DOMAIN: Bounded Contexts / Modules]
+=====================================================================
+- [Context / module] — aggregate root: **[Aggregate]** (adopted — current evidence); owns
+  [entities] and the value objects ([named VOs]). See [[domain-driven-design.domain]].
+- [Named external reference / port] — [role]; not adopted as an aggregate.
+- [… list each bounded context observed in the OKF overview / aggregate index …]
+
+=====================================================================
+[DOMAIN: subsection pointers]
+=====================================================================
+[DOMAIN: <subsection>]        -> guardrails/projects/[project]/domain/[generated-file].md
+[DOMAIN: <subsection>]        -> guardrails/projects/[project]/domain/[generated-file].md
+[DOMAIN: Platform Topology]   -> below
+
+=====================================================================
+[DOMAIN: Platform Topology]
+=====================================================================
+- [Runtime / external dependencies AS INVENTORIED — from the OKF overview/platform note, not an ideal.]
+- [Only what the platform actually declares; unknowns are Open Questions, not assumed capabilities.]
+
+=====================================================================
+[DOMAIN: Governance Overrides]
+=====================================================================
+- [Approvers / change-authority observed or TODO(GOVERNANCE): assign at ratification.]
+- [Any domain-specific review trigger the code/specs evidence.]
+
+## Related
+
+- [[domain-driven-design.domain]] · [[<generated siblings>]]

package/assets/.appweaver/orchestrator/rev-templates/domain-rule-bindings.skeleton.md

@@ -0,0 +1,59 @@
+<!--
+  rev-templates/domain-rule-bindings.skeleton.md — SHAPE-ONLY reference for the project's
+  domain-rule-bindings.md (resolve-domain reads it by that exact name — the symmetric
+  twin of tech-rule-bindings.md, which resolve-tech reads). It shows the five per-command headings, the RULE PARTITION (design +
+  implement get NO domain file), the bullet shape, and the quick-reference
+  table. It lists NO real rule files — every bullet is a placeholder for a file
+  the author actually generated from THIS project's evidence.
+
+  Wire ONLY files you generated. Never list a file you did not write.
+-->
+# [PROJECT_NAME] Domain — Command → Rule-File Map
+
+Per-command list of the **[PROJECT_NAME] domain** rule files loaded (via `resolve-domain` +
+`domain-select`, into the sticky standards set) for the spec-anchored orchestrator pipeline.
+
+**The model (see `.appweaver/RULE-PARTITION.md`):** domain files feed only three
+consumers — **specify** (authors them into the spec as FR/BR/CN-/DC-/IC-), **constitution** (the
+domain principles), and the **gates** (conformance checklist). **design** and **implement** load
+**NO** domain file — the domain reaches them solely through the spec/design ids. This is the rule
+partition; preserve it exactly.
+
+- All paths are workspace-relative and live in `guardrails/projects/[project]/domain/`.
+- `resolve-domain --command <name>` collects the `- ` bullets under `## /<name>`.
+
+---
+
+## /aw-spec-constitution
+<!-- Domain identity / regulatory / interop sources that become domain principles in
+     constitution.domain.md. -->
+- guardrails/projects/[project]/domain/[identity-or-requirements-file].md
+- guardrails/projects/[project]/domain/[each generated domain-principle source].md
+
+## /aw-spec-specify
+<!-- The FULL generated domain set. Specify models the domain and LIFTS the overlay constraints
+     into the spec's CN-/DC-/IC- (design/implement never see these files). -->
+- guardrails/projects/[project]/domain/[each generated domain rule file].md
+
+## /aw-spec-design
+_None — design loads no domain file. Domain reaches design only through the spec (BR-/CN-/DC-/IC-)._
+
+## /aw-spec-implement
+_None — implement loads no domain file. Domain reaches implement only through design.md._
+
+## /aw-spec-gate
+<!-- Conformance checklist for the gates (analyze-design · analyze-slice): the domain-derived
+     constraints design/implement were NOT given as authoring input, VALIDATED against output. -->
+- guardrails/projects/[project]/domain/[each *.domain.md overlay to validate against].md
+
+---
+
+## Quick reference (command → domain file count)
+
+| Command | Domain rule files | Role |
+|---|---|---|
+| /aw-spec-constitution | [n] | domain principles |
+| /aw-spec-specify | [n] | author into spec (lift → CN-/DC-/IC-) |
+| /aw-spec-design | 0 | none — spec is the only domain input |
+| /aw-spec-implement | 0 | none — design is the only domain input |
+| /aw-spec-gate | [n] | conformance checklist (validate, don't author) |

package/assets/.appweaver/orchestrator/rev-templates/domain-rule-file.skeleton.md

@@ -0,0 +1,39 @@
+---
+origin: reverse-engineered
+generated_by: aw-spec-onboard/[VERSION]
+concern: "[concern-slug]"
+---
+<!--
+  rev-templates/domain-rule-file.skeleton.md — SHAPE-ONLY reference for ONE
+  generated `<concern>.domain.md` overlay in the project's domain/ folder. Write one such file per
+  concern the adopted specs/designs ACTUALLY exhibit (evidenced-only, lean) —
+  e.g. domain-driven-design, persistence, auditing, authorization, cqrs,
+  eventing, data-classification, api-versioning, or a domain reference file for
+  an identifier/vocabulary the code uses.
+
+  Every rule below MUST trace to a BR-/CN-/DC-/IC-/FR- id, a named value object
+  / port / entity, or the OKF overview. No rule the code does not evidence.
+  Keep the frontmatter (origin + generated_by + concern). Copy the SHAPE only.
+-->
+# [Concern] — [PROJECT_NAME] Domain Addenda
+
+> Technology base: [[<technical-base-concern>]]. Commands: [the commands this file feeds, per the partition].
+
+> [One-line framing of what this concern IS in this project — from evidence, not an ideal.]
+
+## [Section — e.g. Categories / Rules / Invariants]
+
+- [As-built rule the code enforces.] (evidence: [BR-/CN-/DC-/IC-/FR- id or named type])
+- [As-built rule.] (evidence: […])
+
+## [Section — e.g. Exposure & logging / Constraints / Lifecycle]
+
+- [As-built rule.] (evidence: […])
+
+<!-- Where the code's behaviour is a stub / partial / permissive, STATE IT AS-BUILT and note that
+     the CONTRACT still stands (stub behaviour is migration debt, not a waiver) — do not upgrade a
+     stub into a satisfied ideal. -->
+
+## Related
+
+- [[<sibling generated overlay>]] · [[<technical-base-concern>]]

package/assets/.appweaver/orchestrator/rev-templates/frontend-rule-file.skeleton.md

@@ -0,0 +1,63 @@
+---
+origin: reverse-engineered
+generated_by: aw-spec-onboard/[VERSION]
+concern: "[concern-slug]"
+---
+<!--
+  rev-templates/frontend-rule-file.skeleton.md — SHAPE-ONLY reference for ONE
+  generated FRONTEND LANE rule file in the project's frontend/ folder
+  (guardrails/projects/[project]/frontend/<concern>.md). It is the lane's twin of
+  technical-rule-file.skeleton.md, and it exists separately because the lane is a
+  different tier: these files are ratified by constitution.ui.md's UX-* series,
+  not by the technical half's numerals, and they govern only the code under the
+  lane's own root.
+
+  Write one file per EXPERIENCE concern the UI CODE ACTUALLY exhibits
+  (evidenced-only, lean) — e.g. ui-constitution, component-model, routing-and-
+  navigation, state-and-data, styling-and-design-system, accessibility,
+  interaction-states, forms-and-validation, internationalization, performance,
+  ui-testing. NOT per domain concern (those are the *.domain.md overlays), NOT
+  per service-tier concern (those are service/), and NOT per greenfield ideal.
+
+  ONE file in this set is the lane's BASE and is always written where a lane
+  exists: `ui-constitution.md` — the detail layer under the whole UX-* series,
+  and the file the project's `## /aw-spec-ui-constitution` heading maps first. It
+  declares the lane (id, what it is built with, the root it owns) so a later
+  /appweaver constitution run can re-ratify the half from the mapped set alone.
+
+  This skeleton names NO framework, router, component library, design system,
+  styling approach or conformance standard — deliberately, for the same reason
+  the UI constitution skeleton does not. Copy the SHAPE only.
+
+  Every rule below MUST cite a CODE COORDINATE (a real component / route / store /
+  stylesheet / config path) and, where it maps, the UX-* principle it details.
+  This is the DETAIL layer under constitution.ui.md — the thin ratified principle
+  points here; here is the enforceable rule. State what the UI DOES (quirks,
+  inconsistencies, gaps included), never a greenfield assumption.
+-->
+# [Concern] — [PROJECT_NAME] Frontend Rule (as-built)
+
+> Ratified by: constitution.ui.md principle UX-[N] ([short principle title]).
+> Lane: [LANE_ID] at [ROOT].
+> Commands: [the lane commands this file feeds — today, ui-constitution].
+
+> [One-line framing of what this concern IS in this codebase's UI — from the code, not an ideal.]
+
+## [Section — e.g. Structure / Composition / Rules / Contracts]
+
+- [As-built rule the UI follows.] (code: [real component/route/store/stylesheet path]; UX-[N])
+- [As-built rule.] (code: […])
+
+## [Section — e.g. Conventions / Constraints / Forbidden patterns]
+
+- [As-built rule.] (code: […])
+
+<!-- Where the UI's behaviour is inconsistent across the app, state the DOMINANT convention as
+     the rule and record the divergence with its coordinates — do NOT pick a winner the code has
+     not picked, and do NOT upgrade a partial into a satisfied greenfield ideal. A concern the UI
+     shows none of is simply omitted here (modernization is a separate later phase, not this
+     set's concern). -->
+
+## Related
+
+- [[<sibling generated frontend rule>]] · constitution.ui.md principle UX-[N]