aw-spec-cli 0.1.27 → 0.1.28

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

@@ -254,10 +254,13 @@ text, and do not add a rule the model does not carry)*
   per the constitution — adapt for gRPC/GraphQL/CLI if the stack differs), NOT as
   controller code. Pin route, verb, auth, request/response shape, status codes, and
   the error contract. Delegates to an Application use-case; no business logic here.
+  The OPERATION ID is the endpoint's name in the published API document, unique across
+  the service: the frontend plan cites it, and implement gives the endpoint exactly it.
 -->
 
 ### `[VERB] [/route]` — [purpose] · Serves US-Y · FR-00X
 
+- **Operation id**: `[OperationId]`
 - **Auth**: [required role/scope]
 - **Request**: `[path/query params]` + body `{ [field]: [type], … }`
 - **Success**: `2xx` → `{ [response shape] }`

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

@@ -76,7 +76,7 @@ CN-/DC-/IC-) it realises. "Realisation only — no spec delta" for a plan-only c
 | Navigation & Screens (§1) | `[screen]` | screen | US-[n] |
 | Component Structure (§3) | `[component]` | component | US-[n] · FR-[nnn] |
 | Client State (§2) | `[state]` | state | FR-[nnn] · DC-[nnn] |
-| Contract Binding (§5) | `[VERB] [/route]` | binding | IC-[nnn] |
+| Contract Binding (§5) | `[OperationId]` · `[VERB] [/route]` | binding | IC-[nnn] |
 
 ## MODIFIED — existing experience elements
 

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

@@ -196,11 +196,13 @@ a lost connection mid-flight.]
      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. -->
+     client. The OPERATION ID is the one backend-plan.md §3 gives the endpoint —
+     the name implement finds it by in the exported API document, and checks
+     before generating. `—` when no service plan names it yet, with a §8 DA-n. -->
 
-| 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] |
+| Screen / component | Operation id | Operation | Sends (field shape) | Receives (field shape) | Failure handling | Serves |
+|---|---|---|---|---|---|---|
+| `[Screen]` | `[OperationId]` | `[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.]

package/assets/foundations/dotnet/ModularMonolith/ModularMonolith.lane.json

@@ -0,0 +1,6 @@
+{
+  "format": "aw-spec-pack-lane/v1",
+  "note": "How this pack's service is started on its own to export its API document. The AppHost (the lane's run command) needs Docker for its infrastructure; the API project alone runs on the local infrastructure. Development keeps HTTPS redirection off so the document is served over http. The pack's configuration carries no ConnectionStrings:SqliteConnection, which the local infrastructure reads, so the command supplies one.",
+  "contract_run": "dotnet run --project src/AppWeaver.ModularMonolith.API -- --environment Development --urls http://localhost:5000 --ConnectionStrings:SqliteConnection \"Data Source=App_Data/app.db\"",
+  "contract": "http://localhost:5000/swagger/v1/swagger.json"
+}

package/assets/foundations/dotnet/VerticalSlice/VerticalSlice.lane.json

@@ -0,0 +1,6 @@
+{
+  "format": "aw-spec-pack-lane/v1",
+  "note": "How this pack's service is started on its own to export its API document. The AppHost (the lane's run command) needs Docker for Postgres and Redis; the Service project alone runs on SQLite. Development keeps HTTPS redirection off so the document is served over http. The pack's configuration carries no ConnectionStrings:SqliteConnection, which the local infrastructure reads, so the command supplies one.",
+  "contract_run": "dotnet run --project src/AppWeaver.VerticalSlice.Service -- --environment Development --urls http://localhost:5000 --ConnectionStrings:SqliteConnection \"Data Source=App_Data/app.db\"",
+  "contract": "http://localhost:5000/swagger/v1/swagger.json"
+}

package/assets/foundations/foundation.spec.template.txt

@@ -1,6 +1,8 @@
 # kind: backend
 # profiles: dotnet-webapi
 # title: <one line shown in the /appweaver foundation pick list>
+# contract-run: dotnet run --project src/<App>.Api -- --environment Development --urls http://localhost:5000
+# contract: http://localhost:5000/swagger/v1/swagger.json
 #
 # ─────────────────────────────────────────────────────────────────────────────
 # FOUNDATION SPEC TEMPLATE — how to describe a base project for /appweaver foundation
@@ -22,6 +24,21 @@
 #                Vue, SvelteKit and the Express backend alike)
 #   # title:     the label in the pick list
 #
+# Three more header lines carry the API CONTRACT between the lanes. /appweaver foundation
+# records them on the lane in .appweaver/stacks.json once the project is built, and
+# /appweaver implement uses them to export the service's OpenAPI document and generate the
+# frontend's client from it before it generates the frontend. A spec that leaves one out
+# is asked for it at the end of the build; leaving the answer empty keeps the stack
+# profile's default.
+#
+#   # contract-run:  (backend) the command that starts the API ON ITS OWN — no
+#                    orchestration host, nothing it needs that is not on this machine —
+#                    run in the lane root folder. <App> stands for the app name given
+#                    at /appweaver foundation
+#   # contract:      (backend) the URL that running API serves its OpenAPI document at
+#   # client:        (frontend) the command that generates the API client from that
+#                    document; {{contract}} in it stands for the document's path
+#
 # The header is the leading block of `#` lines; the first line that does not start with
 # `#` ends it. Everything after this header block is the spec itself, written for the
 # agent that builds the project — be concrete. The same shape works for a spec given at
@@ -64,10 +81,18 @@ middleware, a sample test that proves the test project runs.
 Settings files, environment variables, ports, connection strings (placeholders, never
 secrets).
 
+## API document
+Backend: the API serves its OpenAPI document at the `# contract:` URL, and the
+`# contract-run:` command starts it on its own on the port that URL names — over http, with
+every setting it needs to start present in its configuration (a local database file, not a
+container). Frontend: say which tool the `# client:` command runs, so it is installed as a
+development dependency.
+
 ## Tests
 The test project(s): framework, where they live (the lane's test path), and the one test that
 must pass on a fresh scaffold.
 
 ## Done when
 How to confirm the scaffold works — the lane's build passes, the test command passes, the app
-starts and answers a named URL.
+starts and answers a named URL (for a backend, the `# contract:` URL, started with the
+`# contract-run:` command).

package/assets/foundations/java/Hexagonal/Hexagonal.lane.json

@@ -0,0 +1,6 @@
+{
+  "format": "aw-spec-pack-lane/v1",
+  "note": "How this pack's service is started on its own to export its API document. It is one Maven module on a local H2 file database, so the Maven wrapper starts it as it is; springdoc serves the OpenAPI document at /v3/api-docs. The port is pinned so the URL below is where it answers.",
+  "contract_run": "./mvnw spring-boot:run -Dspring-boot.run.arguments=--server.port=8080",
+  "contract": "http://localhost:8080/v3/api-docs"
+}

package/assets/foundations/java/Hexagonal/Hexagonal.pack.txt

@@ -657,6 +657,13 @@ Write-Output "MVN_CMD=$MAVEN_HOME/bin/$MVN_CMD"
 			<artifactId>spring-boot-starter-web</artifactId>
 		</dependency>
 
+		<!-- OpenAPI document at /v3/api-docs and Swagger UI at /swagger-ui.html -->
+		<dependency>
+			<groupId>org.springdoc</groupId>
+			<artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
+			<version>3.1.1</version>
+		</dependency>
+
 		<dependency>
 			<groupId>org.springframework.boot</groupId>
 			<artifactId>spring-boot-starter-data-jpa</artifactId>

package/assets/guardrails/project-specific/domain-rule-bindings.md

@@ -74,12 +74,22 @@ through the spec/design (as CN-/DC-/IC- ids).
 - guardrails/domain/healthcare/api-versioning.domain.md
 - guardrails/domain/healthcare/vertical-slices.domain.md
 
-## /aw-spec-plan
-_None — design loads no domain file. Domain reaches design only through the spec (BR-/CN-/DC-/IC-)._
+## /aw-spec-plan-backend
+_None — the service lane of plan loads no domain file. Domain reaches it only through the spec
+(BR-/CN-/DC-/IC-) and the context's domain-model.md._
 
-## /aw-spec-implement
-_None — implement loads no domain file. Domain reaches implement only through design.md. Framework
-components are added separately via `/appweaver add-component`._
+## /aw-spec-plan-frontend
+_None — the frontend lane of plan loads no domain file. Domain reaches it only through the spec
+and the context's domain-model.md._
+
+## /aw-spec-implement-backend
+_None — the service lane of implement loads no domain file. Domain reaches it only through
+backend-plan.md and the context's domain-model.md. Framework components are added separately via
+`/appweaver add-component`._
+
+## /aw-spec-implement-frontend
+_None — the frontend lane of implement loads no domain file. Domain reaches it only through
+frontend-plan.md and the context's domain-model.md._
 
 ## /aw-spec-gate
 <!-- Conformance checklist for the gates (analyze-plan · analyze-slice): the domain-derived
@@ -106,10 +116,12 @@ components are added separately via `/appweaver add-component`._
 
 | Command | Domain rule files | Role |
 |---|---|---|
-| /aw-spec-constitution | 14 | domain principles (XVI+) — the industry constitution + standard industry rules + the project's own requirements |
+| /aw-spec-constitution | 16 | 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-implement | 0 | none — design is the only domain input |
+| /aw-spec-plan-backend | 0 | none — the spec and the domain model carry the domain |
+| /aw-spec-plan-frontend | 0 | none — the spec and the domain model carry the domain |
+| /aw-spec-implement-backend | 0 | none — backend-plan.md and the domain model carry the domain |
+| /aw-spec-implement-frontend | 0 | none — frontend-plan.md and the domain model carry the domain |
 | /aw-spec-gate | 14 | conformance checklist (validate, don't author) |
 
 > Retired in the orchestrator pipeline: the prose `/aw-spec-plan` phase, `/aw-spec-tasks`,

package/assets/guardrails/project-specific/tech-rule-bindings.md

@@ -15,11 +15,12 @@ NOT listed here — every consumer refers to it directly, as-is.
   `guardrails/technology/{{frontend_stack}}/` (the frontend lane). Both are **standard rules
   shared by every project that maps them**, and neither is domain-specific. The frontend corpus is
   read by four headings — `## /aw-spec-ui-constitution` ratifies the lane's base,
-  `## /aw-spec-plan-ui` / `## /aw-spec-implement-ui` carry the detail rules under it, and
-  `## /aw-spec-foundation-frontend` is what a spec-built scaffold of the lane follows.
-- `## /aw-spec-foundation-backend` and `## /aw-spec-foundation-frontend` are keyed per lane
-  KIND, not per command: `foundation` scaffolds both lanes in one run and loads one set or
-  the other for each, and only when the lane is built from a spec — a pack is unpacked as-is.
+  `## /aw-spec-plan-frontend` / `## /aw-spec-implement-frontend` carry the detail rules under
+  it, and `## /aw-spec-foundation-frontend` is what a spec-built scaffold of the lane follows.
+- `plan`, `implement` and `foundation` are keyed per lane KIND, not per command: each runs
+  both lanes in one run and loads one set or the other for each — `## /aw-spec-<command>-backend`
+  for the service lane, `## /aw-spec-<command>-frontend` for the frontend lane. `foundation`
+  loads its set only when the lane is built from a spec — a pack is unpacked as-is.
 - The two files this project authors — `service/technical-requirements.md` and
   `frontend/ui-requirements.md` — live beside this map. They are the only mapped technical
   files expected to differ between two projects on the same stacks.
@@ -68,7 +69,7 @@ NOT listed here — every consumer refers to it directly, as-is.
 
      ⚠ The ux/ files sit in a DOMAIN corpus folder but are TECHNICAL-tier inputs: a file's
      tier is the map that lists it, not the folder it lives in. guardrails/domain/healthcare/
-     ihe-conformance.md under ## /aw-spec-plan is the same pattern. Unmapping them does not
+     ihe-conformance.md under ## /aw-spec-plan-backend is the same pattern. Unmapping them does not
      make the spec's Experience Standards section disappear — the section is unconditional and
      resolves to "None" — it removes the methodology specify fills it from. -->
 - guardrails/technology/{{backend_stack}}/domain-driven-design.md
@@ -78,7 +79,7 @@ NOT listed here — every consumer refers to it directly, as-is.
 - guardrails/domain/healthcare/ux/accessibility-standards.md
 - guardrails/domain/healthcare/ux/content-design.md
 
-## /aw-spec-plan
+## /aw-spec-plan-backend
 <!-- The technical/architecture rule files the design author works from (alongside the
      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-). -->
@@ -107,10 +108,10 @@ NOT listed here — every consumer refers to it directly, as-is.
 - guardrails/technology/{{backend_stack}}/examples/authorization.md
 - guardrails/technology/{{backend_stack}}/examples/auditing.md
 
-## /aw-spec-plan-ui
-<!-- The FRONTEND LANE's design phase. Its own heading, not a branch of ## /aw-spec-plan:
+## /aw-spec-plan-frontend
+<!-- The FRONTEND LANE's design phase. Its own heading, not a branch of ## /aw-spec-plan-backend:
      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
+     paths, so keying the map on a heading of its own 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.
@@ -137,11 +138,13 @@ NOT listed here — every consumer refers to it directly, as-is.
 - guardrails/technology/{{frontend_stack}}/performance-budgets.md
 - guardrails/technology/{{frontend_stack}}/api-integration.{{backend_stack}}.md
 
-## /aw-spec-implement
+## /aw-spec-implement-backend
 <!-- 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. -->
+     (alongside backend-plan.md and constitution.technical.md). It is loaded on BOTH paths,
+     master and delta: a change's code follows the same rules as the master it changes.
+     NO domain file — domain reaches implement only through the plan (on the delta path, the
+     master backend-plan.md + the change's delta plan). clean-architecture/cqrs are planning
+     concerns; component wiring is a separate /appweaver add-component step. -->
 - guardrails/technology/{{backend_stack}}/coding-standards.md
 - guardrails/technology/{{backend_stack}}/dependency-policy.md
 - guardrails/technology/{{backend_stack}}/folder-structure.md
@@ -149,10 +152,10 @@ NOT listed here — every consumer refers to it directly, as-is.
 - guardrails/technology/{{backend_stack}}/testing.md
 - guardrails/technology/{{backend_stack}}/PACKAGING.md
 
-## /aw-spec-implement-ui
+## /aw-spec-implement-frontend
 <!-- 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
+     master and delta, as the service lane's set is. 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 lane root folder.
 
@@ -176,20 +179,6 @@ NOT listed here — every consumer refers to it directly, as-is.
 - guardrails/technology/{{frontend_stack}}/observability.md
 - guardrails/technology/{{frontend_stack}}/frontend-testing.md
 
-## /aw-spec-implement-delta
-<!-- 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/{{backend_stack}}/coding-standards.md
-- guardrails/technology/{{backend_stack}}/dependency-policy.md
-- guardrails/technology/{{backend_stack}}/folder-structure.md
-- guardrails/technology/{{backend_stack}}/framework-api-map.md
-- guardrails/technology/{{backend_stack}}/testing.md
-- guardrails/technology/{{backend_stack}}/PACKAGING.md
-
 ## /aw-spec-build
 <!-- The compile/fix reference set: the layering + coding rules the fixer respects when
      repairing compile errors against the design intent, plus the layering example it repairs
@@ -289,14 +278,13 @@ 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 |
-| /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-plan-backend | 24 | architecture/security/interop the design author mediates the spec against, each with its example |
+| /aw-spec-plan-frontend | 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-backend | 6 | governance/architecture the SERVICE lane builds against (from backend-plan.md), both paths |
+| /aw-spec-implement-frontend | 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-build | 3 | layering + coding rules the compile-fixer respects, + the layering example |
-| /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-analyze-slice | 3 | testing + coding rules and the framework API map the design↔code gate validates against |
+| /aw-spec-constitution | 18 | 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 |
 | /aw-spec-foundation-backend | 7 | what `foundation` builds the service lane's base project against when it is built from a spec rather than unpacked from a pack |

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-plan`.
+> Pure technology (domain-agnostic) — domain (e.g. FHIR) versioning in [[api-versioning.domain]]. Commands: `/aw-spec-plan-backend`.
 
 ## 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-plan`.
+> Pure technology (domain-agnostic) — domain audit additions in [[auditing.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan-backend`.
 
 ## 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-plan`.
+> Pure technology (domain-agnostic) — domain roles & matrix in [[authorization.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan-backend`.
 
 ## 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-plan`, `/aw-spec-build`.
+> Pure technology (domain-agnostic). NON-NEGOTIABLE. Commands: `/aw-spec-plan-backend`, `/aw-spec-build`.
 
 ## Dependency direction
 

package/assets/guardrails/technology/dotnet-webapi/coding-standards.md

@@ -1,6 +1,6 @@
 # Coding Standards
 
-> Pure technology (domain-agnostic) — domain forbidden patterns & CI gates in [[coding-standards.domain]]. Commands: `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-build`, `/aw-spec-analyze-slice`, `/aw-spec-foundation-backend`.
+> Pure technology (domain-agnostic) — domain forbidden patterns & CI gates in [[coding-standards.domain]]. Commands: `/aw-spec-implement-backend`, `/aw-spec-build`, `/aw-spec-analyze-slice`, `/aw-spec-foundation-backend`.
 
 ## Naming conventions
 

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-plan`.
+> Pure technology (domain-agnostic) — domain additions in [[cqrs.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan-backend`.
 
 ## 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-plan`.
+> Pure technology (domain-agnostic) — domain data categories in [[data-classification.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan-backend`.
 
 ## Classification framework
 

package/assets/guardrails/technology/dotnet-webapi/dependency-policy.md

@@ -1,6 +1,6 @@
 # Dependency Policy
 
-> Pure technology (domain-agnostic) — domain package rules in [[dependency-policy.domain]]. Commands: `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-foundation-backend`.
+> Pure technology (domain-agnostic) — domain package rules in [[dependency-policy.domain]]. Commands: `/aw-spec-implement-backend`, `/aw-spec-foundation-backend`.
 
 ## Package governance
 

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-plan`.
+> Pure technology (domain-agnostic) — domain additions in [[eventing.domain]]. Commands: `/aw-spec-plan-backend`.
 
 ## 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-plan`, `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-foundation-backend`.
+> Pure technology (domain-agnostic) — domain additions (Interop adapters, conformance tests, fixtures) in [[folder-structure.domain]]. NON-NEGOTIABLE. Commands: `/aw-spec-plan-backend`, `/aw-spec-implement-backend`, `/aw-spec-foundation-backend`.
 >
 > Replace `<SampleProjectName>` with the project name (e.g. `Acme.Billing`).
 

package/assets/guardrails/technology/dotnet-webapi/framework-api-map.md

@@ -1,7 +1,7 @@
 # Framework API Map — which package and namespace each cited type comes from
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE where it names a package.
-> Commands: `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-analyze-slice`, `/aw-spec-foundation-backend`.
+> Commands: `/aw-spec-implement-backend`, `/aw-spec-analyze-slice`, `/aw-spec-foundation-backend`.
 >
 > The rules in this corpus name framework types — `AggregateRootBase<TId>`,
 > `IAggregateChild`, `IUnitOfWork`. This file says where each one LIVES. Without it a

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-plan`.
+> Pure technology (domain-agnostic). NON-NEGOTIABLE where marked. Commands: `/aw-spec-plan-backend`.
 
 ## 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-plan`, `/aw-spec-run`.
+> Pure technology (domain-agnostic) — domain additions in [[persistence.domain]]. NON-NEGOTIABLE where marked. Commands: `/aw-spec-plan-backend`, `/aw-spec-run`.
 
 ## EF Core conventions
 

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-plan`, `/aw-spec-implement`, `/aw-spec-implement-delta`, `/aw-spec-analyze-slice`, `/aw-spec-foundation-backend`.
+> Pure technology (domain-agnostic) — domain additions in [[testing.domain]]. Commands: `/aw-spec-plan-backend`, `/aw-spec-implement-backend`, `/aw-spec-analyze-slice`, `/aw-spec-foundation-backend`.
 
 ## Test-first engineering
 

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-plan`.
+> Pure technology (domain-agnostic) — domain additions in [[vertical-slices.domain]]. Commands: `/aw-spec-plan-backend`.
 
 ## 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-plan`.
+> Pure technology (domain-agnostic) — domain additions in [[zero-trust.domain]]. NON-NEGOTIABLE where marked. Commands: `/aw-spec-plan-backend`.
 
 ## 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-plan-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-frontend`, `/aw-spec-implement-frontend`.
 > 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-client.md

@@ -1,7 +1,7 @@
 # API Client Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE.
-> Commands: `/aw-spec-implement-ui`, `/aw-spec-foundation-frontend`.
+> Commands: `/aw-spec-implement-frontend`, `/aw-spec-foundation-frontend`.
 > Detail layer under `constitution.ui.md` UX-IV (the contract is the only server input)
 > and UX-VII (mutations flow through one path).
 

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-plan-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-frontend`, `/aw-spec-implement-frontend`.
 > 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-plan-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-frontend`, `/aw-spec-implement-frontend`.
 > 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-plan-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-frontend`, `/aw-spec-implement-frontend`.
 > 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/client-security.md

@@ -1,7 +1,7 @@
 # Client Security Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE.
-> Commands: `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-implement-frontend`.
 > Detail layer under `constitution.ui.md` UX-VIII (client state carries no secret).
 
 The client is a hostile environment: its code is readable, its storage is inspectable, and

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-plan-ui`, `/aw-spec-foundation-frontend`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-frontend`, `/aw-spec-foundation-frontend`.
 > 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/component-conventions.md

@@ -1,6 +1,6 @@
 # Component Conventions — nextjs (frontend lane)
 
-> Pure technology (domain-agnostic). Commands: `/aw-spec-implement-ui`, `/aw-spec-foundation-frontend`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-implement-frontend`, `/aw-spec-foundation-frontend`.
 > Detail layer under `constitution.ui.md` UX-II (design system) and its Mandatory
 > Frontend Folder Structure.
 

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-plan-ui`, `/aw-spec-implement-ui`, `/aw-spec-foundation-frontend`.
+> Commands: `/aw-spec-plan-frontend`, `/aw-spec-implement-frontend`, `/aw-spec-foundation-frontend`.
 > 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-plan-ui`, `/aw-spec-implement-ui`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-frontend`, `/aw-spec-implement-frontend`.
 > 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-plan-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-frontend`, `/aw-spec-implement-frontend`.
 > 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/frontend-testing.md

@@ -1,7 +1,7 @@
 # Frontend Testing Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE.
-> Commands: `/aw-spec-implement-ui`, `/aw-spec-foundation-frontend`.
+> Commands: `/aw-spec-implement-frontend`, `/aw-spec-foundation-frontend`.
 > Detail layer under `constitution.ui.md` UX-XI (frontend test-first).
 
 Every file `implement-ui` generates ships with its test. The design says what to test: each

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

@@ -1,6 +1,6 @@
 # Internationalization Standards — nextjs (frontend lane)
 
-> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-ui`, `/aw-spec-implement-ui`.
+> Pure technology (domain-agnostic). Commands: `/aw-spec-plan-frontend`, `/aw-spec-implement-frontend`.
 > 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/observability.md

@@ -1,7 +1,7 @@
 # Frontend Observability Standards — nextjs (frontend lane)
 
 > Pure technology (domain-agnostic). NON-NEGOTIABLE where marked.
-> Commands: `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-implement-frontend`.
 > Detail layer under `constitution.ui.md` UX-VIII (client state carries no secret).
 
 The service is instrumented end to end — OpenTelemetry, structured logs, trace propagation

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-plan-ui`, `/aw-spec-implement-ui`.
+> Commands: `/aw-spec-plan-frontend`, `/aw-spec-implement-frontend`.
 > 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