aw-spec-cli 0.1.14 → 0.1.16

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

@@ -2,40 +2,56 @@
 
 **Aggregate (feature)**: `[Aggregate]`  <!-- the feature = the aggregate, e.g. Order -->
 
-**Design home**: `specs/[Aggregate]/design.md`
+**Design home**: `specs/[Aggregate]/backend-plan.md`  <!-- the service lane; the frontend twin is frontend-plan.md, owned by /appweaver plan-ui -->
 
 **Source spec**: `specs/[Aggregate]/spec.md`
 
-**Version**: v1.0   <!-- moves in lockstep with the spec; every applied change request bumps this — see Change History -->
+**Version**: v1.0   <!-- SCRIPT-OWNED: plan-stamp sets this to the spec version this plan derives from. Never edit it by hand. -->
 
 **Status**: Draft
 
 <!--
   WHAT THIS DOCUMENT IS
   =====================
-  The single, living High-Level Design (HLD) for ONE aggregate. It is the
-  MEDIATOR between spec.md (WHAT/WHY, tech-agnostic) and the generated code
-  (HOW, tech-specific). It is NOT code: it carries structure, contracts,
-  behaviour, and decisions — enough for ANY capable LLM to generate correct,
-  spec-satisfying code on ANY target stack, but no complete method bodies.
+  The single, living High-Level Design (HLD) for ONE aggregate — the FEATURE-LEVEL
+  ARCHITECTURAL CONFIRMATION. It is the MEDIATOR between spec.md (WHAT/WHY,
+  tech-agnostic) and the generated code (HOW, tech-specific). It is NOT code: it
+  carries structure, contracts, 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  ──▶  design.md  ──▶  code (+ tests)
-    behaviour     structure &       generated by `implement`
-    (FR/BR/US/SC) decisions (HLD)    (stack-bound at generation time)
+    spec.md  ──▶  backend-plan.md  ──▶  story-backend-plan.md  ──▶  code (+ tests)
+    behaviour     structure &          the story's slice          generated by `implement`
+    (FR/BR/CN/SC) decisions (HLD)      (concrete, ephemeral)
+
+  It is LONG-LIVED and moves FORWARD with the spec: /appweaver plan 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 this document.
 
   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.
+  - Every design element traces UP to a spec id (FR-/BR-/CN-/DC-/IC-/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).
-  - Feature = aggregate. Commands (CreateOrder, UpdateOrder…) are USER STORIES,
-    not features. One aggregate = one design.md = one owning design for its code
-    files. A later requirement is a delta on THIS doc, never a new one.
+  - THE CODE IS THE WHAT-EXISTS INPUT, and it is a different authority from the spec.
+    Where code already realises this feature, the plan describes and ADJUSTS TO the
+    structure that is actually there rather than an idealised one, and names any
+    deliberate divergence as a §8 WA-n. The code never overrides the spec on
+    BEHAVIOUR, and it may not introduce a domain rule the spec omits — code that
+    contradicts the spec is a finding to report, not a design to bless.
+  - NO STORY IDS ANYWHERE IN THIS DOCUMENT. Stories live in stories/ and cite the
+    requirement ids they deliver; this design traces to FR-/BR-, which is what keeps
+    it stable while the backlog churns, is reprioritised and is re-raised.
+  - Feature = aggregate. Commands (CreateOrder, UpdateOrder…) are REQUIREMENTS
+    (FR-n) in the spec, not features and not stories. One aggregate = one
+    backend-plan.md = one owning design for its code files. A later requirement is
+    CONFORMED into this document by /appweaver plan's update mode — never a new
+    design doc, and never a delta document.
 
   WHAT LIVES ELSEWHERE (do NOT repeat it here — it is identical for every feature)
   - The clean-architecture layering + dependency rule (API → Application → Domain
@@ -47,6 +63,13 @@
   - Physical persistence (PKs/FKs, columns, indexes, JSON shapes, migration SQL)
     belongs to a technical-data-model. This doc states WHAT is stored and WHICH
     port persists it, not the schema.
+  - THE PUBLISHED SURFACE belongs to `interfaces.md`, this feature's APPEND-ONLY
+    interface log — the anchor the frontend lane designs against. /appweaver plan
+    publishes each entry there (the script assigns IF-nnn, the date and
+    status: proposed); /appweaver plan-ui and the FE story designs READ the latest
+    entry per id. §3 here is the INDEX that cites those ids, never a second copy of
+    the contract: two copies drift, and only the log has a lifecycle and a
+    supersedes: chain.
 
   TECHNOLOGY-AGNOSTIC (mandatory)
   - Express behaviour as SIGNATURES + pre/post/invariant/raises pseudocode and
@@ -128,7 +151,7 @@ trade-off. Layering follows the project architecture standard (constitution).]
 
 | Event | Raised by | Trigger | Key payload | Serves |
 |---|---|---|---|---|
-| `[EntityStateChanged]` | `[Root/Entity]` | [what causes it] | `[id, key fields]` | FR-00X · US-Y |
+| `[EntityStateChanged]` | `[Root/Entity]` | [what causes it] | `[id, key fields]` | FR-00X · BR-00Z |
 
 ### 1.3 Entities
 
@@ -162,7 +185,7 @@ trade-off. Layering follows the project architecture standard (constitution).]
   Invariant:      [what must hold — maps to a spec BR-nnn]
   Post-condition: [resulting state / outputs]
   Raises:         [DomainEvent]
-  Serves:         FR-00X · US-Y · BR-00Z
+  Serves:         FR-00X · BR-00Z
 ```
 
 **Invariants** *(always-true; each maps to a spec BR-nnn — do not add rules absent from the spec)*
@@ -182,13 +205,13 @@ trade-off. Layering follows the project architecture standard (constitution).]
   Purpose:  [why this can't live on one entity]
   Steps:    1. … 2. … 3. …
   Touches:  [aggregates/ports coordinated]
-  Serves:   FR-00X · US-Y
+  Serves:   FR-00X
 ```
 
 ## 2. Application Layer
 
 <!--
-  Use-cases: one command/query per user-story action, its handler's orchestration,
+  Use-cases: one command/query per requirement action (FR-n), its handler's orchestration,
   the ports it depends on, application-level rules (authorization, input validation,
   transaction + event publication), and the request/response DTO shapes. Consumes
   Domain types and the PORTS the Domain/Application defines; NEVER touches
@@ -206,9 +229,9 @@ trade-off. Layering follows the project architecture standard (constitution).]
 
 ### 2.2 Use-cases (commands / queries)
 
-<!-- One block per use-case = one user-story action. This is the LLM's unit of work. -->
+<!-- One block per use-case = one requirement action. This is the LLM's unit of work. -->
 
-#### `[Command/Query]` — Serves US-Y · FR-00X
+#### `[Command/Query]` — Serves FR-00X
 
 - **Type**: command (writes) | query (reads)
 - **Request (DTO)**: `{ [field]: [type], … }`
@@ -224,33 +247,41 @@ trade-off. Layering follows the project architecture standard (constitution).]
     4. [persist via port]  (single transaction boundary)
     5. [publish domain events]
     6. return [Response]
-    On failure: [which error → which API status in §3]
+    On failure: [which error → which published-interface status; the contract is the
+                 IF- entry cited in §3]
   ```
 - **Emits**: `[DomainEvent]` (from §1.2)
 
-## 3. API Layer
+## 3. API Layer — the published surface (INDEX; the wording lives in `interfaces.md`)
 
 <!--
-  The contract other systems couple to. Describe it at PROTOCOL level (REST assumed
-  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 contract other systems and the frontend couple to. Describe it at PROTOCOL level
+  (REST assumed per the constitution — adapt for gRPC/GraphQL/CLI if the stack differs),
+  NEVER as controller code. Delegates to an Application use-case; no business logic here.
+
+  WHERE IT LIVES. Each published interface is an entry in `specs/[Aggregate]/interfaces.md`,
+  the append-only interface log: route/verb, auth, request and response shapes, status
+  codes and the error contract. `plan` publishes those entries — the script assigns the
+  IF-nnn id, the date and status: proposed — and `plan-ui`, the FE story designs and any
+  consuming feature read the LATEST entry per id. This section is the INDEX only.
+
+  HOW TO FILL IT
+  - An interface that ALREADY has an entry in the log (it is in context on an update
+    run): cite its IF- id here, and describe nothing.
+  - An interface being published for the FIRST TIME in this run: describe it in the
+    "Interface" cell in one line and leave the IF- id cell as `(this run)` — the log
+    assigns the real id after this document is written, and the next update run cites
+    it. Never invent an IF- number: the script is the only id authority.
+  - CHANGING a published interface is a NEW entry that supersedes the old one, never
+    an edit to the existing entry and never a change to this table alone.
+  - Every row cites the spec ids it serves and the use-case that implements it, so
+    §6 Traceability and the analyze gate can follow the chain both ways.
 -->
 
-### `[VERB] [/route]` — [purpose] · Serves US-Y · FR-00X
-
-- **Auth**: [required role/scope]
-- **Request**: `[path/query params]` + body `{ [field]: [type], … }`
-- **Success**: `2xx` → `{ [response shape] }`
-- **Errors** *(the error contract)*:
-
-  | Status | When | Body shape |
-  |---|---|---|
-  | 400 | [validation failure] | `{ errors: [{ field, message }] }` |
-  | 403 | [unauthorized] | `{ error }` |
-  | 409 | [conflict / duplicate — maps to a BR] | `{ error }` |
-
-- **Maps to**: `[Command/Query]` (§2.2)
+| Interface | IF- id | Serves | Implemented by |
+|---|---|---|---|
+| `[VERB] [/route]` — [purpose] | IF-00n | FR-00X | `[Command/Query]` (§2.2) |
+| `[DomainEvent]` published outside this feature | (this run) | FR-00X · BR-00X | §2.2 emits, §1.2 |
 
 ## 4. Infrastructure Layer
 
@@ -316,7 +347,7 @@ trade-off. Layering follows the project architecture standard (constitution).]
 ## 6. Traceability (the spine)
 
 <!--
-  The two-way guarantee: every FR/BR/CN/DC/IC/US/SC has a design home, and every
+  The two-way guarantee: every FR/BR/CN/DC/IC/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
   MUST appear as a row here (that is how the analyze gate proves no lifted constraint
@@ -331,7 +362,6 @@ trade-off. Layering follows the project architecture standard (constitution).]
 | 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] |
 
 ## 7. Assumptions (to clarify later)
@@ -369,15 +399,19 @@ trade-off. Layering follows the project architecture standard (constitution).]
 ## 9. Change History
 
 <!--
-  The living-truth ledger, in lockstep with spec.md. 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. A change to this aggregate is a DELTA on THIS document (delta-design:
-  ADDED / MODIFIED / REMOVED sections), never a new design doc. Newest last.
+  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
+  this section went missing, so a dropped ledger can never be silently stamped over.
+
+  SCRIPT-OWNED. `plan-stamp` is the only writer: it appends one row per update naming
+  the requirement ids conformed, and moves the **Version** header to the spec version
+  this plan now derives from. The model writes NO version and NO row, ever — not here,
+  not in the header. 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).
 -->
 
-| Version | Date | Change | User stories | CR |
-|---------|------|--------|--------------|-----|
-| v1.0 | [DATE] | Initial design | US-1 | — |
+| Version | Date | Change |
+|---------|------|--------|
+| v1.0 | [DATE] | Initial design |

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

@@ -15,8 +15,10 @@
   single LIVING source of truth for its whole lifecycle. Every operation on it
   (CreateOrder, UpdateOrder, …) is a REQUIREMENT below (FR-n) — NOT a separate
   feature and NOT a user story. A later requirement is a new FR-n added here,
-  never a new spec folder. One spec + one design.md (specs/[Aggregate]/design.md)
-  — the DESIGN derives from THIS document.
+  never a new spec folder. One spec, and one PLAN per lane that derives from it:
+  specs/[Aggregate]/backend-plan.md (/appweaver plan) and, where a frontend lane is
+  declared, specs/[Aggregate]/frontend-plan.md (/appweaver plan-ui). Both move FORWARD
+  with this document and never write back to it.
 
   THIS DOCUMENT HOLDS NO USER STORIES. A story is an execution SLICE over this
   spec and lives beside it in stories/, citing the FR-/BR- ids it delivers. This
@@ -84,7 +86,7 @@
   only place the spec describes the delivery surface at all.
 
   NOT SCREENS. No pages, layouts, navigation, components or visual design — those are
-  realisation decisions owned by the prototype and design.ui.md, and putting them here
+  realisation decisions owned by the prototype and frontend-plan.md, and putting them here
   would break the WHAT/HOW line the whole kit rests on.
 
   Lifted with the Experience Standards below, from the frontend lane's constitution
@@ -203,17 +205,17 @@
   The PROJECT-WIDE experience standards this aggregate's UI must satisfy, lifted here by
   specify out of the frontend lane's constitution (constitution.ui.md — the UX-* principle
   series) and the mapped ux/ rule files, exactly as CN-/DC-/IC- lift the domain rules.
-  The lift is what makes them binding: prototype, ui-design and ui-implement author from
+  The lift is what makes them binding: prototype, plan-ui and implement-ui author from
   the SPEC and never from the rule files, so a standard not carried here reaches no UI
   phase and is gated by nothing.
 
   HIGH-LEVEL AND PROJECT-WIDE ONLY. Each entry is a standard the whole product holds to,
   stated so it can be checked on ANY surface — never a screen, page, layout, navigation
-  model, component or visual-design choice. Those are the prototype's and design.ui.md's
+  model, component or visual-design choice. Those are the prototype's and frontend-plan.md's
   to settle. An entry that can be satisfied only one way has stopped being a standard and
   has become a design decision in the wrong document.
 
-  Give each a STABLE id (UX-001, …). Its OWN id class on purpose: ui-design and the UI
+  Give each a STABLE id (UX-001, …). Its OWN id class on purpose: plan-ui and the UI
   code gate review and verify these separately from the service lane, so the two never
   have to be untangled out of one list. The consequence to respect — the service-side
   gates (analyze-design, analyze-slice) trace CN- and never read this section, so a bound
@@ -275,7 +277,7 @@
   Fenced out of the ledger ON PURPOSE. The sha256 that guards this document covers the
   CONTRACT, and this section is not contract — it is a projection of the backlog. Were it
   inside the hash, creating a story would look like an unledgered spec edit and refuse the
-  next update-stories; were it visible to the diff, adding a story would read as a
+  next sync-stories; were it visible to the diff, adding a story would read as a
   requirement change and mint a version row. So spec-check, spec-diff and ledger-append
   all cut this block out before they look at anything.
 -->
@@ -283,7 +285,7 @@
 <!-- AW:COVERAGE:BEGIN -->
 | Requirement | Open stories | Closed / cancelled |
 |-------------|--------------|--------------------|
-| _(none yet — run /appweaver update-stories to raise the backlog)_ | | |
+| _(none yet — run /appweaver sync-stories to raise the backlog)_ | | |
 <!-- AW:COVERAGE:END -->
 
 ## Change History
@@ -294,12 +296,12 @@
   Each row names the requirement ids that version touched. Every story records the spec
   version it last synced at (spec_version: in its frontmatter), so a story is stale when
   some row above its version names an id that story cites — one version comparison, no
-  per-requirement content hashing. update-stories reads the rows to refresh the backlog;
+  per-requirement content hashing. sync-stories reads the rows to refresh the backlog;
   update-spec appends one when it folds a hand-edited story back into this document.
 
   The ledger is hand-written, so it is guarded. active_version.json carries a sha256 of
   this whole file as of the last ledger-aware write. A body that has changed while the
-  version stands still is a hand edit that skipped the ledger: update-stories and
+  version stands still is a hand edit that skipped the ledger: sync-stories and
   check-stories refuse until a row is added, because otherwise every affected story goes
   quietly stale and nothing says so.
 

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

@@ -4,9 +4,13 @@ type: functional
 status: open
 title: [one line — the outcome this story delivers]
 exercises: []
+constraints: []
 spec_version: [vN.N]
 depends_on: []
+wave: 1
 follows:
+designed_lanes: []
+dropped_lanes: []
 work_item:
 created: [DATE]
 ---
@@ -15,21 +19,25 @@ created: [DATE]
   USER STORY  —  one execution slice over a feature's spec.
 
   Canonical home: specs/<Feature>/stories/<Feature-NNN>.md
-  Execution artefacts, once story-spec has run: specs/<Feature>/stories/<Feature-NNN>/
+  Execution artefacts, once story-plan has run: specs/<Feature>/stories/<Feature-NNN>/
+  (story-backend-plan.md and story-frontend-plan.md — the ephemeral designs, one per
+  declared lane; every run appends a pass to each lane in scope, the latest pass wins,
+  and a hand edit to that pass is what implement builds)
 
   A story is a slice of work over a spec that is already written. It is NEVER a proposal
   to change the spec — nothing here merges back into spec.md. When a story genuinely
-  needs the contract to change, update-spec folds it back through specify's
+  needs the contract to change, sync-spec (⌛ not built yet — the hand route is
+  .appweaver/SPEC-EDIT-PROTOCOL.md) folds it back through specify's
   checklist -> clarify -> validate loop, and the spec's Change History gains a row.
 
   ONE STORY, ONE FEATURE. A story whose design touches a second feature is failed by
-  analyze-story-design. Cross-feature ordering goes in depends_on, not in a second story.
+  analysis. Cross-feature ordering goes in depends_on, not in a second story.
 
   FRONTMATTER — every field the gates read lives here, so checking the backlog is a
   directory scan rather than a markdown parse.
 
     id            Minted by the kit: the feature name plus the next free number in
-                  stories/. user-story refuses to write over an existing file, so a
+                  stories/. The writer refuses to overwrite an existing file, so a
                   collision is an add/add git conflict, never a silent overwrite.
                   change-story-id corrects it while it is still legal — see below.
 
@@ -53,28 +61,64 @@ created: [DATE]
                   id. A requirement is DELIVERED when it has NO OPEN STORIES — not when a
                   particular story closed, because a follow-on may carry the remainder.
 
+    constraints   The spec-level bounds this slice must satisfy: the CN-/DC-/IC-/UX- ids,
+                  lifted from spec.md by the kit and never typed by hand. Spec constraints
+                  are declared aggregate-wide, so the feature's WHOLE set binds every slice
+                  of it and there is nothing to choose. This field is the gate surface —
+                  implement, implement-ui and analyze-slice read it — and the "## Constraints"
+                  section below is where each id gets the line saying what THIS slice does
+                  about it. Stamped by sync-stories; a story written before this field
+                  existed has no key at all, and its readers fall back to the section.
+
     spec_version  The spec version this story last synced at. A row above this version
-                  naming an id in exercises means the story is stale; check-stories
-                  reports it and update-stories acts on it. Restamped on every sync.
+                  naming an id in exercises OR constraints means the story is stale;
+                  check-stories reports it and sync-stories acts on it. Restamped on
+                  every sync.
 
     depends_on    Story ids that must land first, e.g. [Payment-004]. About CODE ordering,
                   not spec: implement warns on an open dependency, which is where calling
                   into code that does not exist starts to cost something. close-story
                   warns but does not block — a dependency still being open does not make
                   this story's own work wrong. A cycle is rejected at authoring time.
+                  sync-stories writes this as a UNION with what is already here, so an
+                  edge added by hand — including one naming another feature's story — is
+                  never lost to a re-sync.
+
+    wave          The dependency LEVEL this story sits at, computed by sync-stories from
+                  depends_on:. Wave 1 means nothing has to land before it; wave N means
+                  every story in depends_on: sits in a wave below N. STORIES SHARING A WAVE
+                  HAVE NO ORDERING BETWEEN THEM and can be picked up in parallel — which is
+                  why it is a wave and not an order or a priority. A rank would have to
+                  invent a difference between two stories that genuinely have none, and the
+                  fact that they are equal is the useful half.
+
+                  It says when a story becomes ELIGIBLE, not when anyone should start it.
+                  Nothing waits for a whole wave to finish: a story is startable the moment
+                  its own dependencies are done, whatever else shares its wave. A story
+                  raised by hand floors at 1 — nothing is KNOWN to come first.
+
+    designed_lanes  Which lanes story-plan actually designed, e.g. [backend, frontend].
+    dropped_lanes   Which lanes it DROPPED, and why the pair exists: a story with no UI
+                  design either has no user-facing surface or had its UI lane dropped when
+                  it was designed — an undeclared frontend lane, or a frontend-plan.md
+                  missing or behind the spec — and one field cannot say which. Written by
+                  story-plan (never by sync-stories: stories are not designed there);
+                  designed accumulates across passes, dropped holds what has been dropped
+                  and not since designed. Both absent on a story that predates them, which
+                  implement-ui reports as exactly that rather than guessing.
 
     follows       On a follow-on only: the story id this one carries the remainder of.
-                  When the spec moves under a story that already has a story-spec,
-                  update-stories leaves that story untouched and mints a follow-on
+                  When the spec moves under a story that already has a story plan,
+                  sync-stories leaves that story untouched and mints a follow-on
                   instead. There is no superseded status; the link is the whole record.
 
     work_item     Optional tracker id (JIRA-1234). The kit's id and the tracker's id stay
                   separate so the kit depends on no particular tracker.
 
   CHANGE-STORY-ID IS LEGAL only while the story is open and stories/<ID>/ does not exist.
-  After story-spec runs, the id is in that directory, in the story-spec and story-design,
-  in the OKF log, in commit messages and branch names — most of which the kit cannot
-  rewrite.
+  After story-plan runs, the id is in that directory's name, in the OKF log, in commit
+  messages and branch names — most of which the kit cannot rewrite. (The story plan's
+  TEXT never carries the id; its directory is its identity.)
 
   stories.md beside this file is a GENERATED index. Never hand-edit it; it is rebuilt
   from this directory, which is what keeps close-story conflict-free.
@@ -93,6 +137,33 @@ As a [role], I want [capability], so that [outcome].
 
 - **[FR-00n]** — [the part of this requirement this story delivers]
 
+## Constraints
+
+<!-- The spec-level bounds this slice must satisfy, carried BY ID from spec.md and never
+     restated — the spec is the wording, this is the subset that binds this story:
+
+       CN-  constraints & NFRs        DC-  data classification
+       IC-  integration contracts     UX-  experience standards
+
+     Plus the Experience Scope floors (device / browser / assistive technology) wherever
+     this slice has a UI surface. UX- and the floors are what stop a story being built to
+     a standard the product does not hold, and they are the half most often lost: they
+     reach no UI phase except through the story.
+
+     THE IDS ARE STAMPED FOR YOU into `constraints:` above — the kit lifts every one the
+     spec declares, because spec constraints bind the aggregate rather than a single
+     operation. This section is where each gets its LINE. Write one per id saying what
+     this slice has to do about it, and where one genuinely does not apply, say so in its
+     line rather than dropping it: an omission used to be indistinguishable from a bound
+     nobody noticed, which is how a slice gets built without one.
+
+     These are NOT in `exercises:`. That field is FR-/BR- only, because it is the
+     delivery relation — what this story DELIVERS — and a constraint is not delivered,
+     it is met. story-plan carries these ids into its design pass; analyze-slice
+     traces it. -->
+
+- **[UX-00n]** — [what this slice must satisfy of it]
+
 ## Acceptance
 
 <!-- Checkable statements, in the spec's vocabulary. These are what analyze-slice pairs
@@ -104,4 +175,4 @@ As a [role], I want [capability], so that [outcome].
 ## Notes
 
 <!-- Optional: sequencing, risks, what is deliberately out of this slice. Anything that
-     belongs to the CONTRACT belongs in spec.md via update-spec, not here. -->
+     belongs to the CONTRACT belongs in spec.md via sync-spec, not here. -->