aw-spec-cli 0.1.16 → 0.1.18

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

@@ -1,14 +1,14 @@
-# UI Design: [AGGREGATE]
+# Frontend Plan: [AGGREGATE]
 
 **Aggregate (feature)**: `[Aggregate]`  <!-- the feature = the aggregate, e.g. Order -->
 
-**Design home**: `specs/[Aggregate]/frontend-plan.md`  <!-- the frontend lane; the service twin is backend-plan.md, owned by /appweaver plan -->
+**Plan home**: `specs/[Aggregate]/frontend-plan.md`
 
 **Source spec**: `specs/[Aggregate]/spec.md`
 
 **Lane**: `[lane id]` — the frontend lane declared in `.appweaver/stacks.json`
 
-**Version**: v1.0   <!-- SCRIPT-OWNED: plan-stamp sets this to the spec version this plan derives from. Never edit it by hand. -->
+**Version**: v1.0   <!-- moves in lockstep with spec.md and backend-plan.md; one change closes on ONE bump -->
 
 **Status**: Draft
 
@@ -16,35 +16,22 @@
   WHAT THIS DOCUMENT IS
   =====================
   The single, living High-Level Design for ONE feature's EXPERIENCE — the
-  FEATURE-LEVEL ARCHITECTURAL CONFIRMATION for the frontend lane, twin of
-  backend-plan.md. It is the MEDIATOR between spec.md (WHAT/WHY, tech-agnostic)
-  and the frontend code `implement-ui` generates. It carries screens, navigation,
-  client state, composition, interaction and the service binding. It is NOT code,
-  and it is NOT a visual comp.
+  frontend lane's twin of backend-plan.md. It is the MEDIATOR between spec.md
+  (WHAT/WHY, tech-agnostic) and the frontend code `implement` generates in this lane.
+  It carries screens, navigation, client state, composition, interaction and
+  the service binding. It is NOT code, and it is NOT a visual comp.
 
-    spec.md  ──▶  frontend-plan.md  ──▶  story-frontend-plan.md  ──▶  frontend code (+ tests)
-    behaviour     structure &           the story's slice           generated by `implement-ui`
-    (UX/FR/CN/SC) decisions             (concrete, ephemeral)
-
-  It is LONG-LIVED and moves FORWARD with the spec: /appweaver plan-ui authors it,
-  and conforms it whenever the spec's Change History says something it realises has
-  moved. Story designs READ it and never write back — nothing merges into it.
+    spec.md  ──▶  frontend-plan.md  ──▶  frontend code (+ tests)
+    behaviour     structure &          generated by `implement`, frontend lane
+    (UX/US/FR/SC) decisions            (framework bound at generation time)
 
   ANCHORING RULES
-  - Every element traces UP to a spec id (UX-/FR-/CN-/DC-/IC-/SC-) and the spec's
-    experience obligations are covered DOWN here (§7 Traceability). No screen
-    without a spec reason; no requirement without a screen home.
-  - NO STORY IDS ANYWHERE IN THIS DOCUMENT. Stories live in stories/ and cite the
-    requirement ids they deliver; this plan traces to UX-/FR-, which is what keeps
-    it stable while the backlog churns.
-  - THE CODE IS THE WHAT-EXISTS INPUT, and it is a different authority from the
-    spec. Where a frontend already realises this feature, ADJUST to the composition,
-    naming and state handling that are actually there rather than to an idealised
-    shape. The code never overrides the spec on required behaviour; a deliberate
-    divergence is a §9 WA-n.
+  - Every element traces UP to a spec id (UX-/US-/FR-/CN-/DC-/IC-/SC-) and the
+    spec's experience obligations are covered DOWN here (§7 Traceability). No
+    screen without a spec reason; no user story without a screen home.
   - 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 plan is a dropped requirement.
+    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.
@@ -62,16 +49,16 @@
     approach. Describe a component by its RESPONSIBILITY, its INPUTS (props /
     params as field shapes), the EVENTS it raises and the STATES it can be in.
     The same design must be realisable on another frontend stack without edits.
-    The framework binds at `implement-ui` from constitution.ui.md + that
-    command's rule set.
+    The framework binds in `implement`'s frontend lane, from constitution.ui.md
+    + that lane's rule set.
 
   WHAT LIVES ELSEWHERE (do NOT repeat it here — it is identical for every feature)
   - The lane's folder structure, naming conventions, forbidden patterns and CI
     gates are constitution.ui.md's. This document uses them; it does not restate
     them.
   - HOW to turn this design into components (file placement, one-component-per-
-    file, test pairing, client generation) is a solution-wide rule applied at
-    `implement-ui`.
+    file, test pairing, client generation) is a solution-wide rule applied in
+    `implement`'s frontend lane.
   - The app shell, global layout and the design system belong to no single
     feature. Cite them; do not claim them here.
 
@@ -116,7 +103,7 @@
 
 | Screen | Purpose | Entered from | Leads to | Serves |
 |---|---|---|---|---|
-| `[Screen]` | [the decision made here] | [entry point] | [next screens] | FR-[nnn] · UX-[n] |
+| `[Screen]` | [the decision made here] | [entry point] | [next screens] | US-[n] · FR-[nnn] |
 
 **Route / navigation shape**: [how screens are addressed and nested, stated
 conceptually — a path pattern, a stack, a tab set — never named after a router.]
@@ -161,7 +148,7 @@ anything the service alone may decide. Cite the DC-/CN- id.]
 
 | Component | Responsibility | Inputs (field shape) | Events raised | Serves |
 |---|---|---|---|---|
-| `[Component]` | [single responsibility] | [field: type, …] | `[event]` | FR-[nnn] · UX-[n] |
+| `[Component]` | [single responsibility] | [field: type, …] | `[event]` | FR-[nnn] · US-[n] |
 
 ### 3.n [COMPOSITION AXIS NAME]
 
@@ -183,7 +170,7 @@ decision recorded in §8.]
 
 | Interaction | States | What the user sees | Serves |
 |---|---|---|---|
-| `[interaction]` | [idle → in-flight → success / error / empty / denied] | [per-state behaviour] | FR-[nnn] · UX-[n] |
+| `[interaction]` | [idle → in-flight → success / error / empty / denied] | [per-state behaviour] | US-[n] · FR-[nnn] |
 
 **Validation & feedback**: [when validation runs and how failures are surfaced,
 citing the BR-/FR- ids being echoed. A client-side check NEVER replaces the
@@ -200,33 +187,22 @@ a lost connection mid-flight.]
 ## 5. Contract Binding
 
 <!-- THE LANE BOUNDARY. One row per service operation this feature's UI depends
-     on. Bind against the service's PUBLISHED SURFACE — the entries in
-     `interfaces.md` (cited by IF- id) and the spec's IC- ids — and never against
-     the service's internals: no table, no handler, no persistence assumption
-     crosses this line. An interface the experience needs and the service does not
-     publish is raised back to the service lane, never worked around in the client. -->
-
-| Screen / component | Operation | IF- id | Sends (field shape) | Receives (field shape) | Failure handling | Serves |
-|---|---|---|---|---|---|---|
-| `[Screen]` | `[operation]` | IF-00n | [field: type, …] | [field: type, …] | [the §4 state it produces] | FR-[nnn] · IC-[nnn] |
-| `[Screen]` | `[operation]` | (unpublished) | [field: type, …] | [field: type, …] | [the §4 state it produces] | FR-[nnn] |
+     on. Bind against the service's PUBLISHED SURFACE — the spec's IC- ids and
+     the API contracts backend-plan.md states — and never against the service's
+     internals: no table, no handler, no persistence assumption crosses this
+     line. An interface the experience needs and the service does not offer is a
+     CONTRACT DELTA raised back to the service lane, never a workaround in the
+     client. -->
+
+| Screen / component | Operation | Sends (field shape) | Receives (field shape) | Failure handling | Serves |
+|---|---|---|---|---|---|
+| `[Screen]` | `[operation]` | [field: type, …] | [field: type, …] | [the §4 state it produces] | FR-[nnn] · IC-[nnn] |
 
 **Write semantics**: [per mutating operation — optimistic or pessimistic, what
 it invalidates, and how an optimistic update rolls back.]
 
-**Contract gaps to raise**: [every row above whose IF- id reads `(unpublished)` —
-what the experience needs that `interfaces.md` does not yet carry. These are raised
-back to the service lane, which publishes them by running /appweaver plan; this lane
-never writes the log. Or `None`.]
-
-<!-- WHERE THE CONTRACT LIVES. The service lane's published surface is
-     `specs/[Aggregate]/interfaces.md` — the APPEND-ONLY interface log /appweaver plan
-     publishes. Bind to the LATEST entry per interface (an entry naming an earlier id
-     in `supersedes:` replaces it) and CITE IT BY IF- id in the rows above; never
-     restate the contract here, and NEVER write to the log — this lane consumes it.
-     An entry at `status: proposed` is the designed contract and is bindable. Where
-     the log does not exist yet (the service lane has not planned this feature), bind
-     from the spec's IC- ids and record a §8 DA-n saying so. -->
+**Contract deltas needed**: [anything the experience requires that the service
+surface does not offer, raised back to the service lane. Or `None`.]
 
 ## 6. Cross-Cutting
 
@@ -251,13 +227,13 @@ never writes the log. Or `None`.]
 <!-- The two-way guarantee for the lane: every experience obligation in the spec
      has a home here, and every UI element has a spec reason. The last column
      names THIS document's own sections.
-     An FR- with a UI surface and no screen is a coverage failure. A UX- with no row
-     is a dropped requirement — backend-plan.md does not carry them, so this is their
-     only home. -->
+     A US- with no screen is a coverage failure. A UX- with no row is a dropped
+     requirement — backend-plan.md does not carry them, so this is their only home. -->
 
 | Spec id | Type | UI element(s) | Section |
 |---|---|---|---|
 | UX-[n] | experience standard | [where realised] | [§] |
+| US-[n] | story | [screens + flow realising it] | [§ refs] |
 | FR-[nnn] | requirement | [screen / component / state] | [§] |
 | CN-[nnn] | constraint | [where honoured in the UI] | [§] |
 | DC-[nnn] | classification | [what is withheld from the client] | §6 |
@@ -288,18 +264,13 @@ never writes the log. Or `None`.]
 
 ## Change History
 
-<!-- The living-truth ledger, in lockstep with spec.md — MANDATORY, and the one
-     section whose loss is refused rather than absorbed: plan-stamp writes no baseline
-     at all if it went missing, so a dropped ledger can never be silently stamped over.
-
-     SCRIPT-OWNED. `plan-stamp` is the only writer: one row per update naming the
-     requirement ids conformed, and the **Version** header moved to the spec version
-     this plan now derives from. The model writes NO version and NO row, ever.
-     Newest last.
-
-     Three columns, matching exactly what the stamp writes: the derived spec version,
-     the date, and what changed (the conformed ids are carried in that cell). -->
+<!-- A row is appended when this plan is RE-DERIVED to carry a change: this document is
+     derived from spec.md (its UX- Experience Standards) and the context's domain-model.md,
+     and finalize-delta merges a change into those two, never into this one. close-delta
+     bumps the ONE version both lanes share and stamps it into the header, so a header
+     ahead of the newest row below means the plan has not been re-derived since that
+     version. Newest last. -->
 
-| Version | Date | Change |
-|---------|------|--------|
-| v1.0 | [DATE] | Initial UI design |
+| Version | Date | Change | User stories | CR |
+|---------|------|--------|--------------|-----|
+| v1.0 | [DATE] | Initial UI design | US-1 | — |

package/assets/guardrails/projects/dotnet-default-project/domain-rule-bindings.md

@@ -71,21 +71,14 @@ through the spec/design (as CN-/DC-/IC- ids).
 - guardrails/domain/healthcare/vertical-slices.domain.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, for the same reason: domain
-reaches frontend-plan.md as spec ids (UX-/CN-/DC-/IC-). Stated rather than left absent, because
-an absent heading and an empty one behave identically and only one of them is a decision._
+_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 backend-plan.md and
-the story's design pass. Framework
+_None — implement loads no domain file. Domain reaches implement only through design.md. Framework
 components are added separately via `/appweaver add-component`._
 
 ## /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 the
      output. Domain re-enters here as a check, never as authoring input. -->
 - guardrails/domain/healthcare/persistence.domain.md
@@ -112,14 +105,10 @@ components are added separately via `/appweaver add-component`._
 | /aw-spec-constitution | 14 | domain principles (XVI+) — the industry constitution + standard industry rules + the project's own requirements |
 | /aw-spec-specify | 19 | author into spec (lift → CN-/DC-/IC-) |
 | /aw-spec-plan | 0 | none — spec is the only domain input |
-| /aw-spec-plan-ui | 0 | none — spec is the only domain input |
 | /aw-spec-implement | 0 | none — design is the only domain input |
 | /aw-spec-gate | 14 | conformance checklist (validate, don't author) |
 
-> Retired in the orchestrator pipeline: `/aw-spec-tasks`, `/aw-spec-taskplan`, `/aw-spec-clarify`,
-> `/aw-spec-analyze` (clarify folds into specify; tasks into the design phase). The collapsed tiers
-> `/aw-spec-fast-implement` and `/aw-spec-minimal-implementation` are pending a ruling.
->
-> `/aw-spec-plan` is NOT retired. The name was once a dead phase and is now the LIVE service-lane
-> design command (`design` was renamed to `plan`, `design-ui` to `plan-ui`); its heading above is
-> current, and `/appweaver story-plan` reads the same slot.
+> Retired in the orchestrator pipeline: the prose `/aw-spec-plan` phase, `/aw-spec-tasks`,
+> `/aw-spec-taskplan`, `/aw-spec-clarify`, `/aw-spec-analyze` (clarify folded into specify; the
+> prose plan/tasks pair into the design phase, which is now itself named `/aw-spec-plan`). The
+> collapsed tiers `/aw-spec-fast-implement` and `/aw-spec-minimal-implementation` are pending a ruling.

package/assets/guardrails/projects/dotnet-default-project/tech-rule-bindings.md

@@ -76,15 +76,8 @@ NOT listed here — every consumer refers to it directly, as-is.
 
 ## /aw-spec-plan
 <!-- The technical/architecture rule files the design author works from (alongside the
-     spec and constitution.technical.md), each followed by its worked example. Also read by
-     /appweaver story-plan, which reuses this slot deliberately: a story's execution design
-     answers to the same HOW rules as the feature plan it derives from.
-
-     NO DOMAIN-TIER FILE HERE — the domain reaches design only as spec ids (BR-/CN-/DC-/IC-).
-     The one bullet under guardrails/domain/ is not an exception to that: TIER IS DECIDED BY
-     THE MAP THAT LISTS A FILE, NOT BY THE FOLDER IT SITS IN, so ihe-conformance.md is bound
-     here as a TECHNICAL interop rule (the wire-level conformance the design must realise),
-     not as domain authoring input. Nothing from domain-rule-bindings reaches this phase. -->
+     spec and constitution.technical.md), each followed by its worked example. NO domain file
+     here — domain reaches design only as spec ids (BR-/CN-/DC-/IC-). -->
 - guardrails/technology/dotnet-webapi/clean-architecture.md
 - guardrails/technology/dotnet-webapi/cqrs.md
 - guardrails/technology/dotnet-webapi/eventing.md
@@ -111,12 +104,12 @@ NOT listed here — every consumer refers to it directly, as-is.
 - guardrails/technology/dotnet-webapi/examples/auditing.md
 
 ## /aw-spec-plan-ui
-<!-- The FRONTEND LANE's design phase — /appweaver plan-ui, authoring frontend-plan.md. Its
-     own heading, not a branch of ## /aw-spec-plan: the two lanes are governed by different
-     constitution halves and own disjoint source paths, so keying the map on this command name
-     gives the lane its own rule set for zero mechanism change. NO domain file here — the
-     domain reaches frontend-plan.md as spec ids, exactly as it reaches backend-plan.md. The
-     lane's ratified base (constitution.ui.md) is referred to directly and is NOT mapped.
+<!-- The FRONTEND LANE's design phase. Its own heading, not a branch of ## /aw-spec-plan:
+     the two lanes are governed by different constitution halves and own disjoint source
+     paths, so keying the map on this command name gives the lane its own rule set for zero
+     mechanism change. NO domain file here — the domain reaches design.ui.md as spec ids,
+     exactly as it reaches design.md. The lane's ratified base (constitution.ui.md) is
+     referred to directly and is NOT mapped.
 
      THE SERVICE LANE ENTERS THROUGH ONE FILE. api-integration.{{backend_stack}}.md is the
      CROSS-LANE pairing rule set — what the service guarantees (paging shape, concurrency
@@ -126,10 +119,8 @@ NOT listed here — every consumer refers to it directly, as-is.
      api-integration.java-spring.md in a Spring repo — both authored — and to a REPORTED
      missing file for a backend whose pairing nobody has written yet, rather than silently
      loading one stack's assumptions into another. A repo with no backend lane skips the
-     bullet entirely. No other service-lane file is mapped here, and none is needed: the
-     service's published surface reaches this lane as DATA, not as rules — specs/<F>/
-     interfaces.md, the append-only interface log /appweaver plan publishes, which
-     frontend-plan.md §5 binds to by IF- id. Never the service's internals. -->
+     bullet entirely. No other service-lane file is mapped here: design.ui.md consumes the
+     published surface, never the service's internals. -->
 - guardrails/technology/nextjs/component-architecture.md
 - guardrails/technology/nextjs/routing-navigation.md
 - guardrails/technology/nextjs/state-management.md
@@ -143,10 +134,10 @@ NOT listed here — every consumer refers to it directly, as-is.
 - guardrails/technology/nextjs/api-integration.{{backend_stack}}.md
 
 ## /aw-spec-implement
-<!-- The FRAMEWORK / code-generation rule files the code generator builds against
-     (alongside backend-plan.md, the story's design pass and constitution.technical.md).
-     NO domain file — domain reaches implement only through those. clean-architecture/cqrs are design
-     concerns; component wiring is a separate /appweaver add-component step. -->
+<!-- The FRAMEWORK / code-generation rule files the SERVICE lane's generator builds against
+     (alongside backend-plan.md and constitution.technical.md), on the BOOTSTRAP path.
+     NO domain file — domain reaches implement only through the plan. clean-architecture/cqrs
+     are planning concerns; component wiring is a separate /appweaver add-component step. -->
 - guardrails/technology/dotnet-webapi/coding-standards.md
 - guardrails/technology/dotnet-webapi/dependency-policy.md
 - guardrails/technology/dotnet-webapi/folder-structure.md
@@ -154,10 +145,11 @@ NOT listed here — every consumer refers to it directly, as-is.
 - guardrails/technology/dotnet-webapi/PACKAGING.md
 
 ## /aw-spec-implement-ui
-<!-- The FRONTEND LANE's code-generation set — the HOW the UI generator builds against,
-     alongside frontend-plan.md and constitution.ui.md. NO domain file: domain reached the
-     lane through spec -> frontend-plan.md. NO service-lane file beyond the pairing rules
-     below — this phase never writes outside the lane's declared source path.
+<!-- The FRONTEND LANE's code-generation set — the HOW that lane of `implement` builds
+     against, alongside frontend-plan.md and constitution.ui.md. It is loaded on BOTH paths,
+     master and delta, because the lane never had a separate delta heading. NO domain file
+     (domain reached the lane through spec -> frontend-plan.md), and NO service-lane file
+     beyond the pairing rules below — this lane never writes outside its declared source path.
 
      EIGHT FILES ARE MAPPED FOR BOTH LANE PHASES on purpose. error-handling,
      forms-and-validation, auth-session, design-system, accessibility-implementation, i18n,
@@ -180,9 +172,12 @@ NOT listed here — every consumer refers to it directly, as-is.
 - guardrails/technology/nextjs/frontend-testing.md
 
 ## /aw-spec-implement-delta
-<!-- The CR analog of implement — same FRAMEWORK / code-generation set (HOW to build).
-     The delta's code is generated against the master backend-plan.md + delta-design.md; no
-     domain file (domain reached the delta via delta-spec → delta-design). -->
+<!-- The SERVICE lane's set on the DELTA path — same FRAMEWORK / code-generation rules (HOW
+     to build). `implement` is one command for both paths and both lanes: it keys this
+     heading while generating a change's delta-backend-plan.md and `## /aw-spec-implement`
+     while generating the master, so keep the two identical unless a change deliberately
+     needs different rules. The delta's code is generated against the master backend-plan.md
+     + the delta plan; no domain file (domain reached the delta via delta-spec → delta plan). -->
 - guardrails/technology/dotnet-webapi/coding-standards.md
 - guardrails/technology/dotnet-webapi/dependency-policy.md
 - guardrails/technology/dotnet-webapi/folder-structure.md
@@ -199,7 +194,7 @@ NOT listed here — every consumer refers to it directly, as-is.
 - guardrails/technology/dotnet-webapi/examples/clean-architecture.md
 
 ## /aw-spec-analyze-slice
-<!-- The spec↔code conformance gate's TECHNICAL checklist: the code + tests are
+<!-- The design↔code conformance gate's TECHNICAL checklist: the code + tests are
      validated against these (alongside the DOMAIN gate overlays, loaded separately via
      resolve-domain `## /aw-spec-gate`). Validation input only — never authoring. -->
 - guardrails/technology/dotnet-webapi/testing.md
@@ -255,18 +250,18 @@ NOT listed here — every consumer refers to it directly, as-is.
 | Command | Technical rule files | Role |
 |---|---|---|
 | /aw-spec-specify | 6 | the modelling methodology the spec is expressed in: DDD for the domain model (+ its example), and the four ux/ rules for the experience model it lifts as UX- ids — no technology |
-| /aw-spec-plan | 24 | architecture/security/interop the design author mediates the spec against, each with its example (also read by story-plan) |
-| /aw-spec-plan-ui | 11 | the frontend lane's design set — composition, routing, client state, interaction states, forms, auth surface, design system, accessibility, i18n, performance, and the cross-lane API pairing the UI design author works from (from spec.md + interfaces.md) |
-| /aw-spec-implement | 5 | governance/architecture the code generator builds against (from backend-plan.md + the story's design pass) |
-| /aw-spec-implement-ui | 13 | the frontend lane's code-generation set the UI generator builds against (from frontend-plan.md) — conventions, the generated client + its service pairing, auth, client security, states, forms, design system, accessibility, i18n, performance, observability and testing |
-| /aw-spec-implement-delta | 5 | same code-generation set, scoped to the open change's delta-design |
+| /aw-spec-plan | 24 | architecture/security/interop the design author mediates the spec against, each with its example |
+| /aw-spec-plan-ui | 11 | the frontend lane's design set — composition, routing, client state, interaction states, forms, auth surface, design system, accessibility, i18n, performance, and the cross-lane API pairing the UI design author works from (from spec.md) |
+| /aw-spec-implement | 5 | governance/architecture the SERVICE lane builds against (from backend-plan.md), master path |
+| /aw-spec-implement-ui | 13 | the FRONTEND lane's code-generation set (from frontend-plan.md), both paths — conventions, the generated client + its service pairing, auth, client security, states, forms, design system, accessibility, i18n, performance, observability and testing |
+| /aw-spec-implement-delta | 5 | the same set as /aw-spec-implement, for the service lane when implement is generating a change's delta plan |
 | /aw-spec-build | 3 | layering + coding rules the compile-fixer respects, + the layering example |
-| /aw-spec-analyze-slice | 2 | testing + coding rules the spec↔code gate validates against |
+| /aw-spec-analyze-slice | 2 | testing + coding rules the design↔code gate validates against |
 | /aw-spec-constitution | 17 | what the technical half ratifies — the technology base, the standard technical rules, and the project team's technical-requirements.md |
 | /aw-spec-ui-constitution | 2 | what the frontend lane's half ratifies — the UI base + the project team's ui-requirements.md — and the signal that the lane exists |
 | /aw-spec-run | 2 | persistence rules the execution / data-migration step generates against, + its example |
 
-> All migrated workflows are on this map. The conformance-gate workflows **analyze-design**
-> and **analyze-delta-design** are intentionally NOT here — they validate design/delta
+> All migrated workflows are on this map. The conformance-gate workflows **analyze-plan**
+> and **analyze-plan-delta** are intentionally NOT here — they validate the plans / the delta
 > against the spec + DOMAIN gate overlays only (domain-rule-bindings `## /aw-spec-gate`), with no
 > technical gate checklist.

package/assets/guardrails/requirement-spec.txt

@@ -16,9 +16,9 @@ Acceptance:
 - A product missing a required attribute, an active ingredient, or a packaging configuration is rejected.
 - The creation is recorded in the audit trail.
 
-/appweaver design 
+/appweaver plan
 
-/appweaver analyze-design
+/appweaver analyze-plan
 
 /appweaver implement
 

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

@@ -1,6 +1,6 @@
 # Testing Standards
 
-> Pure technology (domain-agnostic) — domain additions in [[testing.domain]]. Commands: `/aw-spec-design`, `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-analyze-slice`.
+> Pure technology (domain-agnostic) — domain additions in [[testing.domain]]. Commands: `/aw-spec-plan`, `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-analyze-slice`.
 
 ## Test-first engineering
 

package/package.json

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

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

@@ -1,105 +0,0 @@
-# =============================================================================
-# delta-design (orchestrator module) — author the DESIGN-side DELTA of a change
-#
-# Included by /appweaver design on its DELTA branch (design.md already exists).
-# This is the DESIGN half of the former standalone `cr` capture, relocated here.
-# JOIN-or-OPEN the change: if one is already open (specify opened it via delta-spec)
-# JOIN it; otherwise OPEN one here (a DESIGN-ONLY change — the design's realisation of
-# EXISTING spec ids changes without a spec delta). It then authors the DELTA-DESIGN
-# ONLY — it does NOT touch the master design.md. The change stays OPEN; finalize-delta
-# merges the delta into design.md later in the chain and close-delta closes it at the
-# end. No version bump here, no code (that is /appweaver implement-delta).
-#
-# Runs in the CALLER's context (include semantics): shares vars + the sticky standards
-# (design's TECHNICAL/architecture set) + the caller's scripts map + replay cache.
-# EXPECTS caller vars: feature_dir, spec_file, design_doc, has_change, active_change,
-#   need_new_change (design_mode==delta AND no change open yet), USER_INPUT.
-# PRODUCES: active_change, delta_spec, delta_design, downstream_count, impact_report.
-# =============================================================================
-
-name: delta-design
-dialect: aw-spec.orchestrator/v1
-
-# Scripts this module invokes. A module's scripts EXTEND the caller's map (setdefault, so
-# the caller's refs WIN at runtime — these are inert when design already supplies them);
-# declaring both keeps the module self-contained + validatable on its own. `actions` mirrors
-# the caller's (design's) ref; `xref` (the OKF cross-reference substrate) is ADDED for the
-# advisory blast-radius step below, which design does not otherwise provide.
-scripts:
-  actions:
-    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
-    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
-  xref:
-    sh:  .appweaver/scripts/bash/aw-xref.sh
-    ps1: .appweaver/scripts/powershell/aw-xref.ps1
-
-workflow:
-
-  # OPEN a change only when none is open (a design-only change). cr-setup refuses if
-  # one is already open, so the JOIN case (specify opened it) SKIPS this and keeps the
-  # caller's active_change. cr-setup also scaffolds delta-design.md from its template.
-  - id: open_change
-    condition: "{{need_new_change}} == true"
-    action: execute_script
-    script: { ref: actions }
-    subcommand: cr-setup
-    args: ["--feature-dir", "{{feature_dir}}", "--title", "{{USER_INPUT}}"]
-    outputs:
-      - { name: active_change, from: "$.cr_id" }     # the design-opened change becomes the active one
-      - { name: delta_spec,    from: "$.delta_spec" }
-      - { name: delta_design,  from: "$.delta_design" }
-
-  # Resolve the delta doc paths from the active change (covers the JOIN case, where
-  # open_change was skipped; recomputes the same paths on the OPEN case — harmless).
-  - id: paths
-    action: set
-    vars:
-      delta_design: "{{feature_dir}}/changes/{{active_change}}/delta-design.md"
-      delta_spec:   "{{feature_dir}}/changes/{{active_change}}/delta-spec.md"
-
-  - id: ctx
-    action: build_context
-    context:
-      - { path: "{{delta_design}}" }            # the delta-design template to fill
-      - { path: "{{delta_spec}}" }              # the spec-side change (from specify/delta-spec)
-      - { path: "{{spec_file}}" }
-      - { path: "{{design_doc}}" }              # the current master design.md (READ ONLY — never amended here)
-      - { path: .appweaver/DESIGN-FORMAT.md }
-  - id: author
-    action: agent_author                          # design's technical standards stay ON (default) — correct here
-    output_target: { type: file, path: "{{delta_design}}" }
-    task: |
-      Fill the delta-design record (target in context) for this change, from the
-      delta-spec and the CURRENT master design.md (both in context) — the DELTA ONLY.
-      Do NOT edit design.md: finalize-delta merges the delta into the master later.
-      Classify every change to the design as ADDED / MODIFIED / REMOVED against the
-      master, per the master's OWN section structure (whatever sections it actually has
-      — do not assume a fixed layering), plus the cross-section impact, the regression
-      targets, and any new assumption (DA-n) or workaround (WA-n) the change introduces.
-      Stay technology-agnostic (no code). A shared element (e.g. the aggregate root) is
-      MODIFIED in place, never duplicated.
-      TWO CASES — decide from the delta-spec in context:
-        • SPEC-DRIVEN — the delta-spec lists ADDED/MODIFIED/REMOVED spec items: realise
-          them; every changed design element serves one of those spec ids.
-        • DESIGN-ONLY — the delta-spec is an unfilled stub (no spec delta): this change
-          refines HOW the EXISTING spec is realised (an architectural / decision change)
-          driven by the guidance below. The spec is unchanged, so every changed element
-          MUST still trace to an EXISTING spec id (FR-/BR-/CN-/DC-/IC-/US-/SC-) — you are
-          changing the realisation, never inventing a requirement.
-      Guidance: {{USER_INPUT}}
-
-  # ADVISORY blast radius (restored from the retired `cr`): who currently depends on THIS
-  # aggregate (its Cross-References in the OKF bundle). A change here may ripple to them —
-  # surfaced now, at delta-review time, and written to the change dir (impact.md) for the
-  # record. Read-only + on_error: continue: it INFORMS how to scope the change; the actual
-  # downstream-green enforcement is finalize-delta's job. Uses the change's own id
-  # ({{active_change}}) — the JOIN case inherits it from specify, the OPEN case sets it above.
-  - id: xref_impact
-    action: execute_script
-    on_error: continue
-    script: { ref: xref }
-    subcommand: list
-    args: ["--feature-dir", "{{feature_dir}}", "--out", "{{feature_dir}}/changes/{{active_change}}/impact.md"]
-    outputs:
-      - { name: downstream_count, from: "$.count" }
-      - { name: impact_report,    from: "$.impact_report" }

package/assets/.appweaver/orchestrator/modules/spec-state-gate.orch.yaml

@@ -1,87 +0,0 @@
-# =============================================================================
-# spec-state-gate (orchestrator) — the ledger tripwire, gated on STATE
-#
-# Included by every phase that READS spec.md as an oracle and does not stamp it.
-# It answers one question before that phase starts doing work:
-#
-#     is spec.md's version an honest name for spec.md's contents?
-#
-# WHY THE `ok` BOOLEAN IS NOT ENOUGH. spec-check's decisive branch asks only "is
-# there a version ROW above the version the kit last recorded", and never opens the
-# body. Two of its states are therefore ok:true with a body nobody has re-baselined:
-#
-#   ledgered_edit   a row exists above the recorded version — the edit was RECORDED,
-#                   but the kit has not re-hashed, so every LATER edit lands inside
-#                   the same window and passes the same test. Verified: a requirement
-#                   DELETED with no row naming it passes.
-#   header_behind   the same, with the document's header not yet caught up.
-#
-# Both are legitimate transient states and both have the same remedy — spec-stamp,
-# which re-baselines the hash and closes the window. That remedy is already named in
-# these phases' own refusal messages and in SPEC-EDIT-PROTOCOL.md.
-#
-# WHY NOT FLIP `ok` INSTEAD. Because specify is the stamper. It MUST keep accepting
-# both states — it is the command that resolves them — so making spec-check refuse
-# them would wedge the one workflow that can fix them. The distinction belongs at the
-# consumer, which is what this module is.
-#
-# WHAT IT DOES NOT DO. It never stamps, never edits and never repairs. Every state
-# spec-check already refuses (unrowed_edit, unledgered_edit, rollback, no_ledger,
-# delta_open) still stops on `ok`, with spec-check's own message.
-#
-# Inputs (via include `with`):
-#   command  — the phase being gated, quoted back in the failure message
-#
-# Produces: spec_ok / spec_state (the raw answers) and spec_current (true when the
-# state is one this phase may read from), for a caller that wants to say more.
-# =============================================================================
-
-name: spec-state-gate
-dialect: aw-spec.orchestrator/v1
-
-scripts:
-  actions:
-    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
-    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
-
-workflow:
-
-  - id: spec_guard_read
-    action: execute_script
-    script: { ref: actions }
-    subcommand: spec-check
-    args: ["--feature-dir", "{{feature_dir}}"]
-    outputs:
-      - { name: spec_ok,    from: "$.ok" }
-      - { name: spec_state, from: "$.state" }
-
-  # The states spec-check itself refuses. Kept first and kept separate: its own error
-  # text says which one and why, and this module has nothing to add to it.
-  - id: spec_guard
-    action: verify_context
-    require_true: spec_ok
-    on_false: stop
-    on_false_message: "{{command}} cannot run: spec.md has moved outside the ledger (state: {{spec_state}}), so its version no longer names its contents and nothing read from it can be trusted. Record what changed in a Change History row naming the ids, then re-run spec-stamp to re-baseline — or, when the edit touched no requirement at all, spec-stamp alone (see .appweaver/SPEC-EDIT-PROTOCOL.md)."
-
-  # The two states that pass `ok` and still leave the body un-baselined. Ordered sets
-  # rather than a compound condition — the evaluator takes single comparisons only, so
-  # the refusal is the default and each acceptable state lifts it.
-  - id: spec_state_default
-    action: set
-    vars: { spec_current: "false" }
-  - id: spec_state_clean
-    condition: "{{spec_state}} == clean"
-    action: set
-    vars: { spec_current: "true" }
-  # A pre-ledger spec the kit has never stamped. Legitimate: nothing has been recorded
-  # against it, so there is no window between a row and a baseline to fall into.
-  - id: spec_state_unstamped
-    condition: "{{spec_state}} == unstamped"
-    action: set
-    vars: { spec_current: "true" }
-
-  - id: spec_state_gate
-    action: verify_context
-    require_true: spec_current
-    on_false: stop
-    on_false_message: "{{command}} cannot run: spec.md is in state '{{spec_state}}' — the edit is recorded in a Change History row, but the kit has not re-baselined the document, so its recorded hash still describes the text before the edit. Until it does, every FURTHER edit passes the same tripwire unnoticed, including a requirement deleted with no row naming it. Run /appweaver specify (which stamps), or re-run spec-stamp to re-baseline directly, then re-run {{command}}."