aw-spec-cli 0.1.18 → 0.1.19

package/assets/.appweaver/scripts/python/aw-inventory.py

@@ -991,8 +991,9 @@ def _read_frontmatter(path):
 
 def cmd_concept(args):
     """Resolve the OKF bundle concept for an aggregate → its path + source_files
-    (the code that IS the slice). The index adopt reverse-engineers spec.md +
-    design.md FROM. Matches on title/filename slug; prefers an Aggregate type."""
+    (the code that IS the slice). The index adopt reverse-engineers spec.md, the
+    context's domain-model.md and the lane plans FROM. Matches on title/filename
+    slug; prefers an Aggregate type."""
     bundle = os.path.abspath(args.bundle)
     want = _slug(args.aggregate)
     best = None

package/assets/.appweaver/templates/design-template.md

@@ -4,7 +4,9 @@
 
 **Plan home**: `specs/[Aggregate]/backend-plan.md`
 
-**Source spec**: `specs/[Aggregate]/spec.md`
+**Source spec**: `specs/[Aggregate]/spec.md`   <!-- behaviour: what the system must DO -->
+
+**Source model**: `specs/[Context]/domain-model.md`   <!-- structure: what the domain IS -->
 
 **Version**: v1.0   <!-- moves in lockstep with the spec; every applied change request bumps this — see Change History -->
 
@@ -19,20 +21,26 @@
   behaviour, and decisions — enough for ANY capable LLM to generate correct,
   spec-satisfying code on ANY target stack, but no complete method bodies.
 
-    spec.md  ──▶  backend-plan.md  ──▶  code (+ tests)
-    behaviour     structure &       generated by `implement`
-    (FR/BR/US/SC) decisions (HLD)    (stack-bound at generation time)
+    domain-model.md ─┐
+    structure        ├─▶  backend-plan.md  ──▶  code (+ tests)
+    (BR-nnn)         │    structure &          generated by `implement`
+    spec.md        ──┘    decisions (HLD)       (stack-bound at generation time)
+    behaviour
+    (FR/US/SC/CN/DC/IC)
 
   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 (see §6 Traceability). No design element
-    without a spec reason; no spec requirement without a design home.
-  - THE SPEC IS THE ONLY DOMAIN INPUT. Design reads the spec + the technical/
-    architecture standards — NOT the domain rule files. The domain reached this doc
-    only as spec ids: business invariants (BR-), domain-derived constraints (CN- —
-    retention/immutability/audit/limits), data classification (DC-), and interop
-    obligations (IC-). Realise each of those; invent no domain rule the spec omits
-    (if one seems missing, record it as an Assumption in §7, never smuggle it in).
+  - Every design element traces UP to an id — behaviour ids (FR-/US-/SC-/CN-/DC-/IC-)
+    from the spec, invariant ids (BR-) from the context's domain-model.md — and the
+    whole spec is covered DOWN here (see §6 Traceability). No design element without
+    a reason in one of those two; no spec requirement without a design home.
+  - TWO AUTHORITIES, NOT ONE. Structure comes from the MODEL, behaviour from the SPEC.
+    domain-model.md fixes the aggregate's entities, value objects, boundary and
+    invariants; spec.md says what the system must DO with them and cites each invariant
+    by id. Design reads BOTH, plus the technical/architecture standards — but NOT the
+    domain rule files: a domain rule reaches this doc only as an id already lifted into
+    one of the two (BR- in the model; CN-/DC-/IC- in the spec). Realise each of those;
+    invent no entity, value object or rule that neither states (if one seems missing,
+    record it as an Assumption in §7, never smuggle it in).
   - Feature = aggregate. Commands (CreateOrder, UpdateOrder…) are USER STORIES,
     not features. One aggregate = one backend-plan.md = one owning design for its code
     files. A later requirement is a delta on THIS doc, never a new one.
@@ -111,9 +119,11 @@ trade-off. Layering follows the project architecture standard (constitution).]
                                   performance-as-a-limit land in §4 Infra / §5 Cross-Cutting.)
   You MAY add design-level structure — domain events, state machines, behaviour
   signatures — but ONLY to REALISE spec behaviour. Do NOT invent an entity, value
-  object, or rule the spec does not state, and do NOT contradict it. If a genuinely
-  new concept is unavoidable, record it as an Assumption (§7, DA-n) and flag it —
-  never smuggle it in. Pure business model: no framework, no persistence, no I/O.
+  object, or invariant THE MODEL does not define, do NOT invent behaviour THE SPEC
+  does not state, and do NOT contradict either. If a genuinely new concept is
+  unavoidable, record it as an Assumption (§7, DA-n) and flag it — never smuggle it
+  in: a missing entity or invariant is a gap in the model, which /appweaver specify
+  owns and this document may not close. Pure business model: no framework, no persistence, no I/O.
   Model this section on a rich DDD reference (entities, VOs, events, state machines,
   invariants, behaviours). Repeat the blocks as the aggregate needs.
 -->
@@ -138,7 +148,7 @@ trade-off. Layering follows the project architecture standard (constitution).]
 <!--
   Per entity: attributes (conceptual types), lifecycle state machine if it has one,
   behaviours as SIGNATURE + pre/post/invariant/raises pseudocode (the most LLM-guidable,
-  stack-neutral form), and the invariants it enforces (each = a spec BR-nnn).
+  stack-neutral form), and the invariants it enforces (each = a BR-nnn THE MODEL defines).
 -->
 
 #### `[Entity]` [(Aggregate Root)]
@@ -162,13 +172,14 @@ trade-off. Layering follows the project architecture standard (constitution).]
 ```
 [Entity].[Behaviour]([params])
   Pre-condition:  [required state / inputs]
-  Invariant:      [what must hold — maps to a spec BR-nnn]
+  Invariant:      [what must hold — maps to a BR-nnn in the domain model]
   Post-condition: [resulting state / outputs]
   Raises:         [DomainEvent]
   Serves:         FR-00X · US-Y · BR-00Z
 ```
 
-**Invariants** *(always-true; each maps to a spec BR-nnn — do not add rules absent from the spec)*
+**Invariants** *(always-true; each cites a BR-nnn the domain model defines — never restate its
+text, and do not add a rule the model does not carry)*
 
 - [Invariant statement] — **BR-00X**
 
@@ -320,22 +331,22 @@ trade-off. Layering follows the project architecture standard (constitution).]
 
 <!--
   The two-way guarantee: every FR/BR/CN/DC/IC/US/SC has a design home, and every
-  design element has a spec reason. This is what makes impact analysis exact and lets
-  the analyze gate verify coverage. Keep it complete — EVERY CN-/DC-/IC- in the spec
+  design element has a reason in one of the two authorities. This is what makes impact
+  analysis exact and lets the analyze gate verify coverage. Keep it complete — EVERY CN-/DC-/IC- in the spec
   MUST appear as a row here (that is how the analyze gate proves no lifted constraint
   was dropped). The Domain rows MUST match the domain model's entities and BR-nnn
   invariants exactly.
 -->
 
-| Spec id | Type | Design element(s) | Layer |
-|---|---|---|---|
-| FR-001 | requirement | `[Root].[Behaviour]`, `[Command]`, `[VERB /route]` | Domain·App·API |
-| BR-001 | invariant | `[Root]` invariant / `[VO]` validation | Domain |
-| CN-001 | constraint | [where realised — §1 invariant / §4 persistence / §5 cross-cutting] | [layer] |
-| DC-001 | classification | [exposure enforcement — §2 projection / §5 data-protection] | App·Infra |
-| IC-001 | contract | [adapter/port realising it — §4.2] | Infra |
-| US-1 | story | [end-to-end elements realising it] | all |
-| SC-001 | success | [where it is met + how verified] | [layer] |
+| Id | Source | Type | Design element(s) | Layer |
+|---|---|---|---|---|
+| FR-001 | spec | requirement | `[Root].[Behaviour]`, `[Command]`, `[VERB /route]` | Domain·App·API |
+| BR-001 | model | invariant | `[Root]` invariant / `[VO]` validation | Domain |
+| CN-001 | spec | constraint | [where realised — §1 invariant / §4 persistence / §5 cross-cutting] | [layer] |
+| DC-001 | spec | classification | [exposure enforcement — §2 projection / §5 data-protection] | App·Infra |
+| IC-001 | spec | contract | [adapter/port realising it — §4.2] | Infra |
+| US-1 | spec | story | [end-to-end elements realising it] | all |
+| SC-001 | spec | success | [where it is met + how verified] | [layer] |
 
 ## 7. Assumptions (to clarify later)
 

package/assets/.appweaver/templates/spec-template.md

@@ -289,10 +289,13 @@
 
 <!--
   The living-truth ledger. Every applied change request appends a row here, carrying
-  the version it ships as. finalize-delta writes the row when it merges the delta;
-  close-delta then archives the CR, bumps the minor version in active_version.json and
-  stamps that same number into this document's **Version** header — one mechanism, one
-  stage, so header, row and active_version.json never disagree. Newest last.
+  the version it ships as. finalize-delta writes the row when it MERGES the delta, with
+  the CR id and `(pending)` in the Version cell — at that point the number does not exist
+  yet. close-delta then archives the CR, bumps the minor version in active_version.json,
+  and stamps that same number into this document's **Version** header AND into the pending
+  cell — one mechanism, one stage, so header, row and active_version.json never disagree.
+  A row still reading `(pending)` is a change that merged and has not closed. The model
+  never writes a version here or anywhere; scripts stamp it. Newest last.
 -->
 
 | Version | Date | Change | User stories | CR |

package/assets/.appweaver/templates/ui-design-template.md

@@ -32,9 +32,13 @@
   - UX- LIVES HERE AND ONLY HERE. The spec's Experience Standards are this
     document's to realise — backend-plan.md deliberately excludes them, so a UX- that
     reaches neither design is a dropped requirement.
-  - THE SPEC IS THE ONLY DOMAIN INPUT — the same rule backend-plan.md keeps. This
-    document reads the spec + the lane's own standards, never the domain rule
-    files. A domain rule the spec omits is an §8 assumption, never an invention.
+  - THE SPEC IS THE ONLY DOMAIN INPUT for this lane. This document reads the spec
+    + the lane's own standards, never the domain rule files. A domain rule the
+    spec omits is an §8 assumption, never an invention. (The SERVICE lane reads a
+    second authority, the context's domain-model.md, because it realises the
+    aggregate's structure. This lane does not: it consumes the published surface
+    at §5, not the domain, so the model is not in its context and an entity or
+    invariant is never this document's to state.)
   - THE SERVICE LANE ENTERS ONLY AT §5. Cite the operations this surface
     consumes; never restate, re-derive or contradict the service design, and
     never place server-side behaviour here.

package/assets/guardrails/domain/healthcare/auditing.domain.md

@@ -2,7 +2,7 @@
 
 > Technology base: [[auditing]]. NON-NEGOTIABLE. Consumed by `/aw-spec-specify` (LIFTS the
 > auditing requirement into the spec) and `/aw-spec-gate` (VALIDATES the spec/design realise it).
-> `/aw-spec-design` and `/aw-spec-implement` never load this file — auditing reaches them through
+> `/aw-spec-plan` and `/aw-spec-implement` never load this file — auditing reaches them through
 > the spec's **declared audit level per aggregate**, and the enablement mechanics live in the
 > technical base [[auditing]]. Keep this file technology-agnostic (levels + rules, **no code**).
 
@@ -24,7 +24,7 @@ audit interceptor populates every audit field automatically (handlers NEVER assi
 
 > Code realisation — marker interfaces (Basic = `IAuditedObject` / `IFullAuditedObject`; Advanced =
 > `+ IFieldAudited`), the one-time composition, and the audit query API — lives in the technical
-> base. See [[auditing]]; `/aw-spec-design` and `/aw-spec-implement` get the HOW from there.
+> base. See [[auditing]]; `/aw-spec-plan` and `/aw-spec-implement` get the HOW from there.
 
 ## Aggregate assignment rule (how specify decides the level)
 
@@ -35,7 +35,7 @@ spec as an explicit, developer-editable declaration:
   history requires field-level before/after).
 - **Supporting aggregates** (collaborating/referenced roots, no PHI) → **Basic** by default.
 - A developer MAY raise or lower a level afterwards by editing the spec declaration — the level is
-  a **spec** decision, never a design or implementation one. `/aw-spec-design` then follows the
+  a **spec** decision, never a design or implementation one. `/aw-spec-plan` then follows the
   declared level.
 
 Lift it as one line the gate can check, e.g. under Constraints:

package/assets/guardrails/domain/pharma/auditing.domain.md

@@ -2,7 +2,7 @@
 
 > Technology base: [[auditing]]. NON-NEGOTIABLE. Consumed by `/aw-spec-specify` (LIFTS the
 > auditing requirement into the spec) and `/aw-spec-gate` (VALIDATES the spec/design realise it).
-> `/aw-spec-design` and `/aw-spec-implement` never load this file — auditing reaches them through
+> `/aw-spec-plan` and `/aw-spec-implement` never load this file — auditing reaches them through
 > the spec's **declared audit level per aggregate**, and the enablement mechanics live in the
 > technical base [[auditing]]. Keep this file technology-agnostic (levels + rules, **no code**).
 
@@ -22,7 +22,7 @@ audit field automatically (handlers NEVER assign audit fields):
 
 > Code realisation — marker interfaces (Basic = `IAuditedObject` / `IFullAuditedObject`; Advanced =
 > `+ IFieldAudited`), the one-time composition, and the audit query API — lives in the technical
-> base. See [[auditing]]; `/aw-spec-design` and `/aw-spec-implement` get the HOW from there.
+> base. See [[auditing]]; `/aw-spec-plan` and `/aw-spec-implement` get the HOW from there.
 
 ## Aggregate assignment rule (how specify decides the level)
 
@@ -32,7 +32,7 @@ spec as an explicit, developer-editable declaration:
 - The **main aggregate** of the requirement (the aggregate root the story is about) → **Advanced**.
 - **Supporting aggregates** (collaborating/referenced roots) → **Basic** by default.
 - A developer MAY raise or lower a level afterwards by editing the spec declaration — the level is
-  a **spec** decision, never a design or implementation one. `/aw-spec-design` then follows the
+  a **spec** decision, never a design or implementation one. `/aw-spec-plan` then follows the
   declared level.
 
 Lift it as one line the gate can check, e.g. under Constraints:

package/assets/guardrails/technology/dotnet-webapi/api-versioning.md

@@ -1,6 +1,6 @@
 # API Versioning Policy
 
-> Pure technology (domain-agnostic) — domain (e.g. FHIR) versioning in [[api-versioning.domain]]. Commands: `/aw-spec-design`.
+> Pure technology (domain-agnostic) — domain (e.g. FHIR) versioning in [[api-versioning.domain]]. Commands: `/aw-spec-plan`.
 
 ## REST versioning
 

package/assets/guardrails/technology/dotnet-webapi/auditing.md

@@ -1,6 +1,6 @@
 # Auditing & Observability Standards
 
-> Pure technology (domain-agnostic) — domain audit additions in [[auditing.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-design`.
+> Pure technology (domain-agnostic) — domain audit additions in [[auditing.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan`.
 
 ## Observability baseline
 

package/assets/guardrails/technology/dotnet-webapi/authorization.md

@@ -1,6 +1,6 @@
 # Authorization Standards
 
-> Pure technology (domain-agnostic) — domain roles & matrix in [[authorization.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-design`.
+> Pure technology (domain-agnostic) — domain roles & matrix in [[authorization.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan`.
 
 ## Authorization model
 

package/assets/guardrails/technology/dotnet-webapi/clean-architecture.md

@@ -1,6 +1,6 @@
 # Clean Architecture Standards
 
-> Pure technology (domain-agnostic). NON-NEGOTIABLE. Commands: `/aw-spec-design`, `/aw-spec-build`.
+> Pure technology (domain-agnostic). NON-NEGOTIABLE. Commands: `/aw-spec-plan`, `/aw-spec-build`.
 
 ## Dependency direction
 

package/assets/guardrails/technology/dotnet-webapi/cqrs.md

@@ -1,6 +1,6 @@
 # CQRS + Mediator Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[cqrs.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-design`.
+> Pure technology (domain-agnostic) — domain additions in [[cqrs.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan`.
 
 ## Command / query patterns
 

package/assets/guardrails/technology/dotnet-webapi/data-classification.md

@@ -1,6 +1,6 @@
 # Data Classification Standards
 
-> Pure technology (domain-agnostic) — domain data categories in [[data-classification.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-design`.
+> Pure technology (domain-agnostic) — domain data categories in [[data-classification.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan`.
 
 ## Classification framework
 

package/assets/guardrails/technology/dotnet-webapi/eventing.md

@@ -1,6 +1,6 @@
 # Eventing Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[eventing.domain]]. Commands: `/aw-spec-design`.
+> Pure technology (domain-agnostic) — domain additions in [[eventing.domain]]. Commands: `/aw-spec-plan`.
 
 ## Domain events
 

package/assets/guardrails/technology/dotnet-webapi/folder-structure.md

@@ -1,6 +1,6 @@
 # Mandatory Folder Structure
 
-> Pure technology (domain-agnostic) — domain additions (Interop adapters, conformance tests, fixtures) in [[folder-structure.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-design`, `/aw-spec-implement`, `/aw-spec-implement-delta`.
+> Pure technology (domain-agnostic) — domain additions (Interop adapters, conformance tests, fixtures) in [[folder-structure.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan`, `/aw-spec-implement`, `/aw-spec-implement-delta`.
 >
 > Replace `<SampleProjectName>` with the project name (e.g. `Acme.Billing`).
 

package/assets/guardrails/technology/dotnet-webapi/modular-monolith.md

@@ -1,6 +1,6 @@
 # Modular Monolith Standards
 
-> Pure technology (domain-agnostic). NON-NEGOTIABLE where marked. Commands: `/aw-spec-design`.
+> Pure technology (domain-agnostic). NON-NEGOTIABLE where marked. Commands: `/aw-spec-plan`.
 
 ## Module boundaries
 

package/assets/guardrails/technology/dotnet-webapi/persistence.md

@@ -1,6 +1,6 @@
 # Persistence Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[persistence.domain]]. NON-NEGOTIABLE where marked. Commands: `/aw-spec-design`, `/aw-spec-run`.
+> Pure technology (domain-agnostic) — domain additions in [[persistence.domain]]. NON-NEGOTIABLE where marked. Commands: `/aw-spec-plan`, `/aw-spec-run`.
 
 ## EF Core conventions
 

package/assets/guardrails/technology/dotnet-webapi/vertical-slices.md

@@ -1,6 +1,6 @@
 # Vertical Slice Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[vertical-slices.domain]]. Commands: `/aw-spec-design`.
+> Pure technology (domain-agnostic) — domain additions in [[vertical-slices.domain]]. Commands: `/aw-spec-plan`.
 
 ## Feature organization
 

package/assets/guardrails/technology/dotnet-webapi/zero-trust.md

@@ -1,6 +1,6 @@
 # Zero-Trust Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[zero-trust.domain]]. NON-NEGOTIABLE where marked. Commands: `/aw-spec-design`.
+> Pure technology (domain-agnostic) — domain additions in [[zero-trust.domain]]. NON-NEGOTIABLE where marked. Commands: `/aw-spec-plan`.
 
 ## Transport security (mTLS / TLS)
 

package/assets/guardrails/technology/nextjs/accessibility-implementation.md

@@ -1,7 +1,7 @@
 # Accessibility Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE.
-> Commands: `/aw-spec-design-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
 > Detail layer under `constitution.ui.md` UX-I (accessibility floor).
 
 UX-I makes the floor non-negotiable; this file is what meeting it means in practice. The

package/assets/guardrails/technology/nextjs/api-integration.dotnet-webapi.md

@@ -2,7 +2,7 @@
 
 > The CROSS-LANE pairing rules: how the `nextjs` frontend lane consumes an
 > `dotnet-webapi` service lane. NON-NEGOTIABLE where marked.
-> Commands: `/aw-spec-design-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
 > Detail layer under `constitution.ui.md` UX-IV (the contract is the only server input).
 
 This file is named for the service lane it pairs with, and a project maps it through the

package/assets/guardrails/technology/nextjs/api-integration.java-spring.md

@@ -2,7 +2,7 @@
 
 > The CROSS-LANE pairing rules: how the `nextjs` frontend lane consumes a `java-spring`
 > (Spring Boot) service lane. NON-NEGOTIABLE where marked.
-> Commands: `/aw-spec-design-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
 > Detail layer under `constitution.ui.md` UX-IV (the contract is the only server input).
 
 This file is named for the service lane it pairs with, and a project maps it through the

package/assets/guardrails/technology/nextjs/auth-session.md

@@ -1,7 +1,7 @@
 # Authentication & Session Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE.
-> Commands: `/aw-spec-design-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
 > Detail layer under `constitution.ui.md` UX-VIII (client state carries no secret) and
 > UX-IV (the contract is the only server input).
 

package/assets/guardrails/technology/nextjs/component-architecture.md

@@ -1,6 +1,6 @@
 # Component Architecture Standards — nextjs (frontend lane)
 
-> Pure technology (domain-agnostic). Commands: `/aw-spec-design-ui`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-ui`.
 > Detail layer under `constitution.ui.md` UX-II (design system) and UX-III (server components).
 
 The rules the UI design author composes a feature's `§3 Component Structure` from. They

package/assets/guardrails/technology/nextjs/design-system.md

@@ -1,7 +1,7 @@
 # Design System Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE.
-> Commands: `/aw-spec-design-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
 > Detail layer under `constitution.ui.md` UX-II (the design system is the only source of
 > visual truth).
 

package/assets/guardrails/technology/nextjs/error-handling.md

@@ -1,6 +1,6 @@
 # Interaction & Error State Standards — nextjs (frontend lane)
 
-> Pure technology (domain-agnostic). Commands: `/aw-spec-design-ui`, `/aw-spec-implement-ui`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
 > Detail layer under `constitution.ui.md` UX-V (every interaction state is specified).
 
 The rules behind `design.ui.md §4 Interaction & Flow` — the section a backend-shaped

package/assets/guardrails/technology/nextjs/forms-and-validation.md

@@ -1,7 +1,7 @@
 # Forms & Validation Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE where marked.
-> Commands: `/aw-spec-design-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
 > Detail layer under `constitution.ui.md` UX-V (every interaction state is specified) and
 > UX-VII (mutations flow through one path).
 

package/assets/guardrails/technology/nextjs/i18n.md

@@ -1,6 +1,6 @@
 # Internationalization Standards — nextjs (frontend lane)
 
-> Pure technology (domain-agnostic). Commands: `/aw-spec-design-ui`, `/aw-spec-implement-ui`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
 > Detail layer under `constitution.ui.md` UX-X (internationalization is structural).
 
 Internationalization is structural: it is cheap while the surface is being designed and

package/assets/guardrails/technology/nextjs/performance-budgets.md

@@ -1,7 +1,7 @@
 # Performance Budget Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE.
-> Commands: `/aw-spec-design-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
 > Detail layer under `constitution.ui.md` UX-IX (the performance budget is a gate).
 
 A budget that is not enforced is an aspiration. Core Web Vitals thresholds and a per-route

package/assets/guardrails/technology/nextjs/routing-navigation.md

@@ -1,6 +1,6 @@
 # Routing & Navigation Standards — nextjs (frontend lane)
 
-> Pure technology (domain-agnostic). Commands: `/aw-spec-design-ui`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-ui`.
 > Detail layer under `constitution.ui.md` UX-III (server components) and UX-V (every
 > interaction state specified).
 

package/assets/guardrails/technology/nextjs/state-management.md

@@ -1,6 +1,6 @@
 # Client State Standards — nextjs (frontend lane)
 
-> Pure technology (domain-agnostic). Commands: `/aw-spec-design-ui`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-ui`.
 > Detail layer under `constitution.ui.md` UX-VI (caching declared), UX-VII (one mutation
 > path) and UX-VIII (client state carries no secret).
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "aw-spec-cli",
-  "version": "0.1.18",
+  "version": "0.1.19",
   "description": "AppWeaver Spec-Driven Development CLI - scaffolds projects with vertical slices, DDD, CQRS, and agent skills",
   "type": "module",
   "main": "dist/index.js",