aw-spec-cli 0.1.16 → 0.1.17

package/assets/.appweaver/orchestrator/modules/delta-spec.orch.yaml

@@ -1,34 +1,37 @@
 # =============================================================================
 # delta-spec (orchestrator module) — author the SPEC-side DELTA of a change
 #
-# ORPHANED — INCLUDED BY NO WORKFLOW. specify v3.0.0 removed the delta branch this module
-# was written for: a later requirement is now an edit to the living spec.md plus a computed
-# Change History row, not a delta document merged back later. Nothing else includes it, so
-# NOTHING AUTHORS A DELTA-SPEC TODAY — the delta-spec.md that cr-setup still scaffolds for
-# every change is an untouched template copy, which is why specify's delta_open guard tests
-# whether one was authored rather than whether a change is open.
+# Included by /appweaver specify on its DELTA branch (spec.md already exists).
+# A later requirement is a new user story on the SAME aggregate. This module opens the
+# change (cr-setup) and authors the change's TWO documents:
+#   • changes/<cr-id>/delta-spec.md          — BEHAVIOUR: what the system must now do
+#   • <context>/domain-model.<cr-id>.delta.md — STRUCTURE: what the domain now is
+# and touches NEITHER master. The change stays OPEN; finalize-delta merges both into
+# spec.md and domain-model.md later in the chain, and close-delta closes it at the end.
+# No version bump here, no plan (that is /appweaver plan → delta-plan).
 #
-# Kept, not deleted, because the sibling half is still live: /appweaver design includes
-# delta-design on its own delta branch, and finalize-delta / analyze-slice / close-delta
-# still run. Retiring this file is a decision about the delta FAMILY, not about this module.
+# WHY BOTH IN ONE RUN: the aggregate root lives in the context's domain model, not in
+# the spec, so a requirement that needs a new entity or invariant has a model dependency
+# the same moment it is written. Authoring the model half here means the model is never
+# behind the spec that relies on it, and never waits for the plan or the implementation.
 #
-# What follows describes it as it was written to be included by specify.
-#
-# This is the SPEC half of the former standalone `cr` capture, relocated here: a
-# later requirement is a new user story on the SAME aggregate. It opens the change
-# (cr-setup — single-active-change guarded; also scaffolds delta-spec AND delta-design)
-# and authors the DELTA-SPEC ONLY. It does NOT touch the master spec.md — the change
-# stays OPEN; finalize-delta merges the delta into spec.md later in the chain and
-# close-delta closes it at the end. No version bump here, no design (that is
-# /appweaver design → delta-design).
+# WHY THE MODEL DELTA SITS BESIDE THE MASTER, not inside changes/<cr-id>/: many changes
+# may be open at once, and each one's proposed model change has to be VISIBLE to the
+# others while they are being authored. A delta that can see its neighbours is designed
+# around them; one that cannot discovers the overlap at merge time, when the work is
+# already spent. WAVE is the ordering that follows from that: same wave = independent
+# and developable in parallel, higher wave = after the lower waves land.
 #
 # Runs in the CALLER's context (include semantics): shares vars + the sticky standards
 # (specify's DDD authority + the selected domain rule files) + the caller's scripts map
 # + replay cache.
-# EXPECTS caller vars: feature_dir, spec_file, USER_INPUT.
-# PRODUCES: cr_id, cr_dir, delta_spec (and, via cr-setup, an OPEN change + a scaffolded
-#           delta-design.md for the design phase to fill). cr_dir is what lets the
-#           caller's quality loop target THIS change (create-checklist --kind delta).
+# EXPECTS caller vars: feature_dir, spec_file, USER_INPUT, domain_model,
+#                      pending_model_files.
+# PRODUCES: cr_id, cr_dir, delta_spec, delta_model, wave, open_count (and, via cr-setup,
+#           an OPEN change). The change's LANE PLANS are scaffolded by `plan`, per declared
+#           lane — the spec phase does not know which lanes exist.
+#           cr_dir is what lets the caller's quality loop target THIS change
+#           (create-checklist --kind delta).
 # =============================================================================
 
 name: delta-spec
@@ -45,23 +48,39 @@ scripts:
 
 workflow:
 
-  # Open the change (sets active_version.json.active_change) + scaffold the two delta
-  # docs from their templates. Refuses if a change is already open on this aggregate.
+  # Open the change + scaffold its THREE documents: delta-spec and delta-design under
+  # changes/<cr-id>/, and the model delta BESIDE the context's master model. Many
+  # changes may be open at once — every specify call on an established feature opens
+  # its own, and the wave is what orders them.
   - id: cr_setup
     action: execute_script
     script: { ref: actions }
     subcommand: cr-setup
     args: ["--feature-dir", "{{feature_dir}}", "--title", "{{USER_INPUT}}"]
     outputs:
-      - { name: cr_id,      from: "$.cr_id" }
-      - { name: cr_dir,     from: "$.cr_dir" }
-      - { name: delta_spec, from: "$.delta_spec" }
+      - { name: cr_id,       from: "$.cr_id" }
+      - { name: cr_dir,      from: "$.cr_dir" }
+      - { name: delta_spec,  from: "$.delta_spec" }
+      - { name: delta_model, from: "$.delta_model" }
+      - { name: wave,        from: "$.wave" }
+      - { name: open_count,  from: "$.open_count" }
 
   - id: ctx
     action: build_context
+    context_from: pending_model_files      # EVERY other open delta's model change, so this
+                                           # one is authored around them rather than into a
+                                           # collision discovered at merge time. Empty on the
+                                           # first concurrent change, which is the common case.
     context:
       - "{{delta_spec}}"                     # the delta-spec template to fill
+      - "{{delta_model}}"                    # the model-delta template to fill
       - "{{spec_file}}"                      # the current master spec (READ ONLY — never amended here)
+      - { path: "{{domain_model}}", optional: true }
+                                             # The context's CANONICAL model — the aggregate root,
+                                             # its entities and its invariants live here, not in the
+                                             # spec. REQUIRED in spirit but declared optional: a
+                                             # feature adopted before the model existed has none yet,
+                                             # and announcing that on every delta would be noise.
       - .appweaver/memory/constitution.domain.md      # the DOMAIN authority — specify's frame. Declared
                                                      # REQUIRED (bare string, not `optional: true`) ON PURPOSE:
                                                      # specify is the ONLY phase that reads the domain rules and
@@ -95,7 +114,7 @@ workflow:
         delta, not a code change.
       - A UX- delta states the STANDARD only — accessibility conformance, interaction-state
         coverage, content and language, journey integrity, responsiveness-as-a-limit — never
-        a screen, page, layout or component, which the prototype and design.ui.md settle. A
+        a screen, page, layout or component, which the prototype and frontend-plan.md settle. A
         change to this aggregate's own interaction BEHAVIOUR is an FR- delta; only a change
         to the standard governing every such behaviour is a UX- delta. A bound the SERVICE
         must meet stays a CN-, because the service-side gates trace CN- and never read the
@@ -103,11 +122,61 @@ workflow:
       - The new operation is a NEW USER STORY — assign the next id after the highest US-n
         in the master — never a new feature/aggregate. Record the regression risk (shared
         behaviour that must still hold).
-      - Model the delta strictly in DDD terms (→ the modelling-methodology standard + the
-        domain's own DDD overlay, both in the sticky standards): keep the
-        ubiquitous language, respect the aggregate boundary and its root, entities vs
-        value objects, and aggregate-owned invariants — domain MODEL, never code.
-        Business-facing and testable; NO implementation mechanics (an external interop
-        OBLIGATION is a requirement → an IC- item, but never the adapter design); NO
-        design docs (that is the design phase).
+      - STRUCTURE IS NOT YOURS TO WRITE HERE. A new entity or value object, a changed
+        aggregate boundary, a new domain event, or a new or amended invariant (BR-n) is a
+        MODEL change and belongs in this change's domain-model delta — the next step
+        authors it. In THIS document, CITE invariants by id and state BEHAVIOUR only.
+        Fill "## Model changes" with the aggregates touched and the ids involved, or
+        "None — behaviour only" when the model does not move.
+      - Express the delta in the context's ubiquitous language (the domain model is in
+        context) — the same terms, no synonyms. Business-facing and testable; NO
+        implementation mechanics (an external interop OBLIGATION is a requirement → an
+        IC- item, but never the adapter design); NO design docs (that is the design phase).
+      - OTHER OPEN DELTAS may be in context (their model deltas). Read them: if one
+        touches the same aggregate or the same FR ids, say so under "Other open deltas"
+        in Impact. If THIS change only makes sense after one of them lands, say so in the
+        Wave rationale — that is a wave dependency, and the wave must then be RAISED above
+        that delta's (report it; `cr-wave` applies it). Do not silently assume their
+        changes: until merged they are proposals, not the master.
+      - Do NOT edit the Wave / Created / Base version headers — scripts stamp those.
+      Change request: {{USER_INPUT}}
+
+  # The MODEL half of the same change, authored in the same run so the model can never
+  # lag the spec that depends on it. It does NOT touch domain-model.md — finalize-delta
+  # merges this file into the master, one `## Aggregate:` section at a time.
+  - id: author_model
+    action: agent_author
+    include_standards: true
+    output_target: { type: file, path: "{{delta_model}}" }
+    task: |
+      The MODEL half of change {{cr_id}} (wave {{wave}}). Fill the delta-domain-model
+      (the output target, in context) relative to the context's current domain-model.md
+      (in context, when it exists). Do NOT edit domain-model.md — finalize-delta merges
+      this delta into it one `## Aggregate:` section at a time.
+
+      This document carries STRUCTURE; the delta-spec you just wrote carries BEHAVIOUR.
+      - Record ONLY what the delta-spec's requirements actually need from the model: a new
+        aggregate, entity or value object; a changed boundary; a new domain event; a new or
+        amended invariant (BR-n) or cross-aggregate invariant (XBR-n). If the change needs
+        nothing new from the model, say so — "None — behaviour only" is a correct and
+        common answer, and inventing model churn to fill the template is worse than an
+        empty delta.
+      - Classify every item ADDED / MODIFIED / REMOVED, and NAME THE AGGREGATE each
+        belongs to. A MODIFIED item states the BEFORE and the AFTER — the merge needs both
+        to be unambiguous.
+      - List every aggregate you touched under "Aggregates touched" in the header. That
+        list is exactly what finalize-delta merges, so an omission silently drops a change
+        and an extra entry claims a section this delta never wrote.
+      - Model strictly in DDD terms (→ the modelling-methodology standard + the domain's
+        own DDD overlay, both in the sticky standards): ubiquitous language, aggregate
+        boundary and root, entities vs value objects, aggregate-owned invariants,
+        cross-aggregate references BY ID ONLY. Technology-agnostic — no types, no
+        persistence, no framework. WHERE an invariant is enforced is a plan concern.
+      - Fill "## Impact": which specs in this context reference the aggregates touched,
+        and which OTHER OPEN DELTAS (in context) touch the same aggregate. Two deltas on
+        one aggregate is the case the wave ordering exists to sequence — name it here.
+      - "## Depends on": other OPEN deltas whose model changes this one builds on. Every
+        entry MUST sit in a LOWER wave than this delta ({{wave}}). "None" when it stands
+        alone. Reading another delta is NOT depending on it — only assuming its changes is.
+      - Do NOT edit the Wave / Created / Base context version headers — scripts stamp those.
       Change request: {{USER_INPUT}}

package/assets/.appweaver/orchestrator/orchestrator.py

@@ -704,9 +704,10 @@ class Orchestrator:
         return [c for c in extra if isinstance(c, (str, dict))]
 
     def _step_read_tools(self, step):
-        """The read tools an `agent_author` / `agent_query` step declares.
+        """The read tools an `agent_author` / `agent_query` / `agent_review`
+        step declares.
 
-        The default is NONE — those two actions are payload-only, and the
+        The default is NONE — those three actions are payload-only, and the
         interpreter inlines every file the workflow mapped. A step whose task
         names files by PATH rather than inlining them declares `tools:` and gets
         exactly that set. The brownfield reversals are the reason it exists:
@@ -1131,7 +1132,7 @@ class Orchestrator:
         for i, o in enumerate(options, 1):
             print(f"  {i}) {o}")
         if multi:
-            print("  (pick any: numbers or names, comma-separated \u2014 "
+            print("  (pick any: numbers or names, comma-separated — "
                   "'all', or blank for none)")
         try:
             raw = input("> ").strip()
@@ -1143,7 +1144,7 @@ class Orchestrator:
             return raw if raw in options else None
         # A multi-select answer is a SET, and a set has no single-token spelling. Read by
         # the single-select parser, "1,3" was neither a number in range nor an option, so it
-        # returned None and the run stopped as "question cancelled" \u2014 leaving exactly two
+        # returned None and the run stopped as "question cancelled" — leaving exactly two
         # reachable answers, "the first one" and "abort". act_ask splits the string it gets
         # back on commas, so returning one is all that is needed here.
         if raw.lower() in ("all", "*"):

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

@@ -2,85 +2,142 @@
   ═══════════════════════════════════════════════════════════════════════════
   rev-templates/delta-design-template.skeleton.md — SHAPE-ONLY reference.
 
-  This file is the FORMAT reference for the reverse-engineered DELTA-design
+  This file is the FORMAT reference for the reverse-engineered DELTA BACKEND PLAN
   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.
+  bones of a change record — the classification triple, the model bridge, the
+  wave discipline, the impact and regression sections, the two ledgers, the merge
+  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
+  it is filled with the ACTUAL sections of the master plan 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.
+  MIRRORS THE MASTER, ALWAYS. The delta-plan module classifies changes "per the
+  master's OWN section structure", so this template is derived FROM the generated
+  master plan 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.
+    • ONE MASTER PER LANE — a change amends
+      specs/<Context>/<Feature>/backend-plan.md; it never opens a second plan
+      document, and it never edits the master itself.
     • 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.
+    • EVERY ROW SERVES A SPEC ID — the delta reads the delta-spec and the domain
+      model, never the domain rule files.
+    • STRUCTURE IS NOT PLANNED HERE — entities, events and invariants (BR-n) live
+      in the context's domain model. This document plans where each is ENFORCED.
+    • WAVE ORDERS THE OPEN CHANGES — a lower wave may be built on, a same wave is
+      visible but never assumed.
     • TECHNOLOGY-AGNOSTIC — signatures and field shapes, no code, exactly as in
       the master.
   ═══════════════════════════════════════════════════════════════════════════
 -->
-# Delta Design — [CR-ID]: [TITLE]
+# Delta Backend Plan — [CR-ID]: [TITLE]
 
-**Feature (aggregate)**: [Aggregate]
+**Feature (aggregate slice)**: [Feature]
+
+**Lane**: backend
+
+**Wave**: [N]   <!-- script-stamped; same wave = developable in parallel, higher wave = after -->
 
 **Base version**: [vX.Y]
 
+**Delta spec**: `changes/[CR-ID]/delta-spec.md`
+
+**Model delta**: `specs/[Context]/domain-model.[CR-ID].delta.md`   <!-- "none" when behaviour-only -->
+
 <!--
-  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.
+  This delta applies to the SINGLE master plan at
+  specs/[Context]/[Feature]/backend-plan.md — never a new plan doc, and never the
+  master itself: finalize-delta merges it later in the chain.
+
+  IT PLANS AGAINST THE EFFECTIVE MODEL — the master domain-model.md, this change's
+  own model delta, and the PREDECESSOR deltas (the open ones in a LOWER wave,
+  committed to landing first). Same-wave deltas are visible but are not
+  predecessors: read them to avoid a collision, never assume them.
+
+  Classify every plan 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. `implement` generates the touched slice from this document 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.]
+[One paragraph: what the plan change is and which delta-spec items it realises.]
+
+## Model changes this plan realises
+
+<!-- One row per item the domain-model delta ADDED / MODIFIED / REMOVED, saying
+     WHERE the change lands in this codebase's own structure. An item in the model
+     delta with no row here is a structural change nothing implements.
+     "None — behaviour only" when this change does not move the model. -->
+
+| Model item | Kind | Realised in | Enforced at |
+|---|---|---|---|
+| `[entity / event / BR-nnn]` | [added / amended / removed] | `[element]` | `[where the rule is checked]` |
+
+## Depends on
 
-## ADDED — new design elements
+<!-- Other OPEN changes this plan builds on. Every entry MUST be in a LOWER wave.
+     "None — stands alone" is the common and preferred answer. -->
+
+- `[CR-ID]` (wave [N-1]) — [what this plan assumes from it]
+
+## ADDED — new plan 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. -->
+     or contract. "Section" names a section of THIS project's master plan —
+     the same section titles the generated plan template carries. -->
 
-| Section (§ in design.md) | Element | Kind | Serves |
+| Section (§ in backend-plan.md) | Element | Kind | Serves |
 |---|---|---|---|
 | [§ of the master's own structure] | `[element]` | [kind] | US-[n] · FR-[nnn] |
 
-## MODIFIED — existing design elements
+## MODIFIED — existing plan 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 |
+| Section (§ in backend-plan.md) | Element | What changes | Why |
 |---|---|---|---|
 | [§ of the master's own structure] | `[element]` | [the edit] | US-[n] |
 
 ## REMOVED
 
-- [design element removed + why] — or `None`
+- [plan 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.]
 
+## Contract deltas for the frontend lane
+
+<!-- What this change adds to or alters in the service's PUBLISHED surface — the
+     only part of this document the frontend lane may bind against. `None` when
+     the surface is unchanged. Omit the section entirely where the code has no
+     frontend lane. -->
+
+| Contract | Change | Shape | Serves |
+|---|---|---|---|
+| `[contract]` | [added / changed] | [request → response field shapes] | IC-[nnn] |
+
+## Other open deltas
+
+<!-- Which OTHER open changes touch the same elements, read from the model deltas
+     beside the master model. `None` when this change stands clear. -->
+
+- `[CR-ID]` (wave [N]) — [what overlaps, and how this plan stays clear of it]
+
 ## Regression targets
 
 [Existing user stories / behaviours to re-verify because a shared element
@@ -89,13 +146,14 @@ changed.]
 ## New assumptions / deviations (from this change)
 
 <!-- Anything this change defers — folds into the master's DA-n / WA-n ledgers
-     on apply. -->
+     on merge. -->
 
 - **DA-[n]**: [assumption to clarify later] — or `None`
 - **WA-[n]**: [deviation to clear later] — or `None`
 
-## On close
+## On merge
 
-`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/`.
+`finalize-delta` merges this record into the master backend-plan.md alongside the
+spec and domain-model merges and leaves the change OPEN; `close-delta` bumps the
+version, writes the Change History rows and archives the change under
+`changes/archive/`.

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

@@ -55,7 +55,7 @@
 
 **Aggregate (feature)**: `[Aggregate]`
 
-**Design home**: `specs/[Aggregate]/design.md`
+**Plan home**: `specs/[Context]/[Feature]/backend-plan.md`
 
 **Source spec**: `specs/[Aggregate]/spec.md`
 

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

@@ -0,0 +1,115 @@
+<!--
+  ═══════════════════════════════════════════════════════════════════════════
+  rev-templates/domain-model-template.skeleton.md — SHAPE-ONLY reference.
+
+  This file is the FORMAT reference for the reverse-engineered DOMAIN MODEL
+  TEMPLATE that onboard installs at
+  .appweaver/templates/overrides/domain-model-template.md. It carries the neutral
+  bones every context domain model has — the header block, the ubiquitous
+  language, one repeatable `## Aggregate:` section, the cross-aggregate
+  invariants, the context map and the Change History — and NOTHING ELSE.
+
+  IT NAMES NO AGGREGATE, NO ENTITY AND NO TECHNOLOGY. Naming one would hand the
+  generator an answer to the single question it exists to ask the code. 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 model — it is the project's domain-model TEMPLATE, which `specify`
+  (forward) and `adopt` (brownfield, per feature) then fill. So the generated
+  file keeps [PLACEHOLDER] tokens and authoring comments; what onboard replaces
+  is the STRUCTURE — which sections exist and what they are called — never the
+  content.
+
+  WHAT IS PINNED, AND WHY (each earns it by being something a tool or a gate
+  keys on):
+    • `## Aggregate: <Name>` is the MERGE UNIT. finalize-delta merges a delta
+      one such section at a time, so the heading form is machinery, not taste.
+      Repeat the whole block per root; never collapse two roots into one.
+    • `### Invariants` carries STABLE BR-nnn ids. Specs cite those ids and the
+      conformance gates trace them, so the id class cannot be renamed per
+      project.
+    • `**Serving specs**:` is what makes a cross-spec aggregate visible from the
+      model side — the reverse of each spec's Domain Model Reference.
+    • The Change History table is the model's version ledger; close-delta
+      appends to it and stamps the context version. The model never writes its
+      own version.
+
+  BROWNFIELD DERIVATION — where each part comes from in an existing codebase:
+    • Aggregate roots: the entity types other types reference by id but never
+      navigate into; the transaction boundaries the persistence layer commits.
+    • Entities vs value objects: identity. A type compared by id is an entity; a
+      type compared by value is a value object.
+    • Invariants: the guards, and the constraint checks in the persistence layer.
+      A rule enforced in code IS an invariant, whether or not anyone wrote it
+      down — record it, and record that the CODE is its current authority.
+    • Ubiquitous language: the names the code actually uses. Where the code and
+      the business disagree, record BOTH and flag it — do not silently pick one.
+  ═══════════════════════════════════════════════════════════════════════════
+-->
+
+# Domain Model — [BOUNDED CONTEXT]
+
+**Bounded context**: `[Context]`
+
+**Model home**: `specs/[Context]/domain-model.md`
+
+**Context version**: v1.0   <!-- script-stamped -->
+
+**Derived from**: code — [what was scanned]   <!-- brownfield provenance; the code is the oracle -->
+
+## Ubiquitous Language
+
+| Term | Means in this context | Not to be confused with |
+|---|---|---|
+| [TERM] | [meaning as the CODE uses it] | [the term it is confused with, and where] |
+
+## Aggregate: [Root]
+
+**Serving specs**: [features that reference this aggregate]
+
+**Last changed**: v1.0 · initial (reverse-engineered)
+
+### Boundary
+
+- **Owns**: [types inside the consistency boundary — from the code]
+- **References (by id, not owned)**: [<Other>Id fields found in the code]
+- **Out of scope / non-goals**: [what the code shows this aggregate does NOT own]
+
+### Entities
+
+- **[Root]** *(aggregate root)*: [what it represents; key attributes; observed lifecycle/states]
+- **[Entity]**: [what it represents; relationship to the root]
+
+### Value objects
+
+- **[VO]**: [what it represents; compared by value in the code]
+
+### Domain events
+
+| Event | Raised by | Trigger | Key payload |
+|---|---|---|---|
+| [EVENT] | [type] | [what causes it] | [fields] |
+
+### Invariants
+
+<!-- STABLE BR-nnn ids. In brownfield the CODE is the current authority for each rule — record what it enforces, not what it ought to. -->
+
+- **BR-001**: [the rule as the code enforces it] *(source: [where it is enforced])*
+
+## Cross-Aggregate Invariants
+
+<!-- Rules spanning two or more aggregates. "None (as of v1.0)" when there are none — never delete the section. -->
+
+- **XBR-001**: [the rule] — or `None (as of v1.0)`
+
+## Context Map
+
+| Other context | Direction | Pattern | What crosses |
+|---|---|---|---|
+| [CONTEXT] | [upstream/downstream] | [pattern] | [what crosses the boundary] |
+
+## Change History
+
+| Context version | Date | Aggregate | Change | Feature | CR |
+|---|---|---|---|---|---|
+| v1.0 | [DATE] | [Root] | Initial model (reverse-engineered) | [Feature] | — |

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

@@ -36,20 +36,13 @@ partition; preserve it exactly.
 - guardrails/projects/[project]/domain/[each generated domain rule file].md
 
 ## /aw-spec-plan
-_None — the service lane's design loads no domain file. Domain reaches it only through the spec
-(BR-/CN-/DC-/IC-)._
-
-## /aw-spec-plan-ui
-_None — the frontend lane's design loads no domain file either: domain reaches frontend-plan.md
-as spec ids (UX-/CN-/DC-/IC-). Written out rather than left absent, because an absent heading and
-an empty one behave identically and only one of them is a decision. Keep this heading even in a
-backend-only repo — it costs nothing and records the partition._
+_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
+<!-- Conformance checklist for the gates (analyze-plan · 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