aw-spec-cli 0.1.15 → 0.1.17

package/assets/.appweaver/DESIGN-FORMAT.md

@@ -13,14 +13,14 @@ A feature's design is **one document**, living beside its spec:
 ```
 specs/<Aggregate>/
   spec.md      # behaviour (tech-agnostic) — WHAT / WHY — the source of truth
-  design.md    # structure & decisions (tech-agnostic HLD) — the MEDIATOR
+  backend-plan.md    # structure & decisions (tech-agnostic HLD) — the MEDIATOR
   changes/     # open + archived change records (delta-spec + delta-design)
 ```
 
-`design.md` is the **mediator** between the spec and the generated code:
+`backend-plan.md` is the **mediator** between the spec and the generated code:
 
 ```
-spec.md  ──▶  design.md  ──▶  code (+ tests)
+spec.md  ──▶  backend-plan.md  ──▶  code (+ tests)
 behaviour     structure &       generated by `implement`
 FR/BR/US/SC   decisions (HLD)    (stack bound at generation time)
 ```
@@ -37,11 +37,11 @@ FR/BR/US/SC   decisions (HLD)    (stack bound at generation time)
   layer (§1) follows spec.md exactly — its entities/value-objects are the spec's Key
   Entities and its invariants are the spec's Business Rules.
 - **Technology-agnostic.** Behaviour and contracts use conceptual types, never a
-  language. The SAME design.md must be generatable on a different stack. The target
+  language. The SAME backend-plan.md must be generatable on a different stack. The target
   language/framework/persistence is bound only at `implement` time from the
   constitution's technology base + the active stack profile.
 - **Physical schema is out of scope.** PKs/FKs, columns, indexes, JSON shapes, and
-  migration SQL belong to a separate technical-data-model — design.md states WHAT is
+  migration SQL belong to a separate technical-data-model — backend-plan.md states WHAT is
   stored and WHICH port persists it, not the schema.
 - **Two deferral ledgers are first-class:** §7 Assumptions (`DA-n`, clarify later)
   and §8 Workarounds (`WA-n`, clear later). They keep the HLD honest about what it
@@ -49,7 +49,7 @@ FR/BR/US/SC   decisions (HLD)    (stack bound at generation time)
 - **Solution-wide rules live elsewhere, not per feature:** the layering/dependency
   rule is the constitution's; the code-generation mechanics (folder mapping,
   file-per-element, test pairing, stack binding) are a technology-specific rule
-  applied in the `implement` phase. `design.md` stays feature-specific and
+  applied in the `implement` phase. `backend-plan.md` stays feature-specific and
   technology-agnostic.
 
 ## Brownfield variant (existing codebases)
@@ -89,7 +89,7 @@ from the code.
 ## Frontend lane variant (`design-ui`)
 
 A project with a frontend lane designs it in its **own** document,
-`specs/<Feature>/design.ui.md`, authored by `design-ui` — not a section inside `design.md`.
+`specs/<Feature>/frontend-plan.md`, authored by `design-ui` — not a section inside `backend-plan.md`.
 The lanes are governed by different constitution halves, take their rules from different
 map headings, and are implemented by different commands. A UI section inside the service
 design would put the lane's structure under the service lane's rules and hand `design-ui`
@@ -101,13 +101,13 @@ navigation & screen structure · client state · component structure · interact
 contract binding · cross-cutting · traceability · `DA-n` · `WA-n`. Technology-agnostic here
 means no framework, router, state library or component library appears: a component is
 described by its responsibility, its inputs as field shapes, the events it raises and the
-states it can be in, and the framework binds at `implement-ui` from `constitution.ui.md`
-plus that command's rule set. The authoring template is
+states it can be in, and the framework binds in the FRONTEND LANE of `implement`, from
+`constitution.ui.md` plus that lane's rule set. The authoring template is
 `.appweaver/templates/ui-design-template.md`.
 
 **§5 Contract Binding is the lane boundary.** The UI design reads the whole spec — the
 experience is stated there — but only the service's **published surface**: the spec's `IC-`
-ids and the API contracts `design.md` states. No table, handler or persistence choice
+ids and the API contracts `backend-plan.md` states. No table, handler or persistence choice
 crosses that line, and an operation the experience needs that the surface does not offer is
 a contract delta raised back to the service lane, never a client workaround. ⌛ `design`
 will emit that surface as a `design-contract.md` projection; the rule does not change when
@@ -116,7 +116,7 @@ it does, only what §5 reads.
 **`UX-` lives here and only here.** The service design excludes the spec's Experience
 Standards by contract — it realises no experience standard, and a traceability row for one
 would be a fabrication. So a `UX-` that reaches neither design is a dropped requirement,
-and design.ui.md's §7 is the only place that is visible.
+and frontend-plan.md's §7 is the only place that is visible.
 
 **Interaction & flow and cross-cutting are never omitted**, however thin the feature.
 They are the two sections a backend-shaped process silently drops, and loading, empty,
@@ -134,10 +134,10 @@ The design document and the code are **not** a byte-for-byte copy of each other.
 
 | Direction | Phase | What happens |
 |---|---|---|
-| **Generate** (forward) | Implement | The model reads spec + design.md and **generates** the code and tests — a reasoning step the design guides and constrains, not a transcription. |
-| **Reconcile** (high-level back) | Build / Run fixes | Compile/typecheck/runtime fixes happen on the **code**. Only when a fix is a **high-level technical variation** — a changed pattern, a new component, an altered contract/dependency — is that decision written back into design.md. Low-level churn stays in the code. |
+| **Generate** (forward) | Implement | The model reads spec + backend-plan.md and **generates** the code and tests — a reasoning step the design guides and constrains, not a transcription. |
+| **Reconcile** (high-level back) | Build / Run fixes | Compile/typecheck/runtime fixes happen on the **code**. Only when a fix is a **high-level technical variation** — a changed pattern, a new component, an altered contract/dependency — is that decision written back into backend-plan.md. Low-level churn stays in the code. |
 
-> **Invariant:** design.md remains a faithful **high-level** account of the built
+> **Invariant:** backend-plan.md remains a faithful **high-level** account of the built
 > system — every significant technical decision is recorded — but it is a durable
 > design reference, **not** a line-by-line mirror of the code. (This retires the old
 > `docs == files` extract/reconcile invariant.)
@@ -158,13 +158,13 @@ A **feature is the largest slice whose code no other feature owns.** Because
 `implement` regenerates the whole feature's code coherently, a shared file
 (`src/Domain/Order.cs`) must have exactly **one** owning design. So for an aggregate
 with a shared entity, **feature = the aggregate** (`Order`), and individual commands
-(`CreateOrder`, `UpdateOrder`, …) are **user stories / deltas** on the same design.md:
+(`CreateOrder`, `UpdateOrder`, …) are **user stories / deltas** on the same backend-plan.md:
 
 - `CreateOrder` = US-1; `UpdateOrder` = US-2.
 - Adding `UpdateOrder` is an additive CR: a Delta Spec (`+US-2`) and a Delta Design
   (`ADDED` new use-case/endpoint sections, `MODIFIED` the shared Order/root and
   repository sections — see `delta-design-template.md`). The design phase amends
-  design.md doc-first, bumps the feature version (`v1.0 → v1.1`), and archives the CR;
+  backend-plan.md doc-first, bumps the feature version (`v1.0 → v1.1`), and archives the CR;
   `implement` regenerates the touched slice; regression re-tests the shared-file
   dependents.
 
@@ -179,9 +179,9 @@ The legacy path-tagged helpers (`design-extract` / `design-reconcile` / `design-
 are **retired and deleted** from both shells. They belonged to the four-document,
 full-code model in which `design.{domain,application,api,infra}.md` carried the source
 inside ` ```lang path=… ` fences. That convention is gone — no template emits `path=`,
-and `design-scaffold` writes a single `design.md` — so all three had been finding
+and `design-scaffold` writes a single `backend-plan.md` — so all three had been finding
 nothing and no-op'ing at exit 0. (Their glob, `design.*.md`, could not have matched a
-single `design.md` even if the fences had survived: the second dot required a middle
+single `backend-plan.md` even if the fences had survived: the second dot required a middle
 segment. The one legitimate remaining user of that glob, `list-features`'s informational
 `design_docs` count, is fixed to `design*.md`.)
 

package/assets/.appweaver/ORCH-DIALECT.md

@@ -48,9 +48,7 @@ transport profile (`agent.json`) and their thin `/appweaver` launcher.
    `strategy:` override): `sdk`, `sdk-apply`, `spawn`, `agent` — they only
    govern WHO fulfills a generation, never what goes into it. `agent` isolation
    is best-effort (same conversation); `sdk` / `spawn` / `sdk-apply` generation
-   are isolated. Python scripts (`execute_script`) are deterministic only —
-   they never MODEL-author spec or code content (a few, like `aw-inventory.py`
-   and `aw-rev-constitution.py`, do generate documents — deterministically).
+   are isolated.
 3. **The checkpoint channel is strategy-independent** (D1): `ask`,
    `user_select` and `dispatch_hooks` suspend via `--checkpoint` under EVERY
    strategy, so the launching agent can relay to the human. Converted-skill

package/assets/.appweaver/RULE-PARTITION.md

@@ -44,7 +44,7 @@ A command with **no heading** in a map loads nothing mapped for that class and
 - `.appweaver/memory/constitution.technical.md` — the technology base. Standing input to
   **design + implement**. Domain-agnostic.
 - `.appweaver/memory/constitution.ui.md` — the **frontend lane's** base, a UX-* principle series.
-  Standing input to ⌛ **ui-design + ui-implement**. Domain-agnostic for the same reason the
+  Standing input to the **FRONTEND LANE of `plan` and of `implement`**. Domain-agnostic for the same reason the
   technical base is, and it exists only where a frontend lane does — a backend-only project has
   no such file.
 - `.appweaver/memory/constitution.domain.md` — the active domain's addenda. Standing input to
@@ -52,8 +52,9 @@ A command with **no heading** in a map loads nothing mapped for that class and
 - `.appweaver/memory/constitution.md` — the composed human/compatibility view. The pipeline loads
   the halves, not this file.
 
-One lane's constitution never governs the other lane's code: `design`/`implement` load the
-technical base and `ui-design`/`ui-implement` load the UI base. What they share is the spec.
+One lane's constitution never governs the other lane's code. `plan` and `implement` are each
+ONE command covering BOTH lanes, and the halves are loaded per lane inside them: the service
+lane loads the technical base, the frontend lane loads the UI base. What they share is the spec.
 
 ---
 
@@ -79,10 +80,20 @@ technical base and `ui-design`/`ui-implement` load the UI base. What they share
   spec against.
 - Constitution: the **technical** half.
 
-### `implement` / `implement-delta` — *code generation*
-- **Domain rule files: NEVER.** The design is the only input describing what to build.
-- **Technical rule files: yes** — the code-generation and convention set.
-- Constitution: the **technical** half.
+### `implement` — *code generation, both lanes, both paths*
+- **Domain rule files: NEVER.** The lane's plan is the only input describing what to BUILD.
+- **The domain MODEL: yes, and it is not a rule file.** `specs/<Context>/domain-model.md` is
+  spec-tier, like `spec.md` — the canonical statement of what the domain IS. It is in context
+  because a plan cites `BR-nnn` and never restates it, so without the model the phase is told
+  where to enforce a rule it was never told the content of. On the delta path that change's
+  `domain-model.<CR-id>.delta.md` joins it, since the master is not merged until
+  finalize-delta. The model is READ, never mined for work: what it holds and no plan element
+  realises is a planning gap, not code to invent.
+- **Technical rule files: yes** — the code-generation and convention set, keyed per lane and,
+  for the service lane, per path: `## /aw-spec-implement` generating a master plan,
+  `## /aw-spec-implement-delta` generating a change's delta plan, `## /aw-spec-implement-ui`
+  for the frontend lane either way.
+- Constitution: the **technical** half in the service lane, the **UI** half in the frontend one.
 
 ### `build` — *compile + repair*
 - **Technical rule files: yes** — the layering and convention rules the compile-fixer respects.
@@ -91,7 +102,7 @@ technical base and `ui-design`/`ui-implement` load the UI base. What they share
 ### `run` — *runtime*
 - **Technical rule files:** only if the project evidences a runtime/hosting concern.
 
-### Gates — `analyze-design`, `analyze-delta-design`, `analyze-slice`, and the `/aw-spec-gate` overlay set
+### Gates — `analyze-plan`, `analyze-plan-delta`, `analyze-slice`, and the `/aw-spec-gate` overlay set
 - Load the domain **gate overlays** as a **conformance checklist**.
 - **Validation input ONLY — never authoring.** A gate may fail a document or a slice; it may
   never write a rule into one.
@@ -144,16 +155,21 @@ technical base and `ui-design`/`ui-implement` load the UI base. What they share
 
 ## Invariants
 
-1. **No domain rule file is ever loaded by `design`, `implement`, `implement-delta` or `build`.**
-2. **Domain reaches design and code only as spec ids.**
+1. **No domain rule file is ever loaded by `design`, `implement` or `build`** — on either
+   lane and on either path.
+2. **Domain reaches design and code only through the SPEC TIER** — as spec ids, and as the
+   bounded context's `domain-model.md` (plus a change's pending model delta) that those ids
+   point into. Never as a domain rule file: the rules were resolved into the model and the
+   spec at `specify`, and a phase downstream of that reads the resolution, never re-derives
+   it from the authority.
 3. **Gate overlays validate; they never author.**
 4. **A constraint not in the spec cannot be honoured downstream** — lift it first
    (`LIFT-FAILURE:` → back to `specify`).
 5. **An absent map heading loads nothing and soft-continues** — it is never a blocking error.
 6. **The constitution halves are referred to directly** and never listed in either map.
-7. **A lane's constitution half governs that lane only** — `constitution.ui.md` never reaches
-   `design` or `implement`, and `constitution.technical.md` never reaches `ui-design` or
-   `ui-implement`.
+7. **A lane's constitution half governs that lane only** — inside the one command that covers
+   both, `constitution.ui.md` never reaches the service lane's payload and
+   `constitution.technical.md` never reaches the frontend lane's.
 
 ---
 

package/assets/.appweaver/STACK-PROFILES.md

@@ -20,9 +20,11 @@ A lane is not a project, not a module, and not a layer. Two lanes exist when two
 toolchains do, which is why `kind` has exactly two values today (`backend`, `frontend`)
 and why nothing in the format assumes there are only two lanes.
 
-**Lanes get command names, never a `--lane` flag.** Rule maps are keyed on
-`## /aw-spec-<command>`, so a lane's phases are reached as `ui-implement`, `ui-foundation`
-and so on. A flag would have no heading to key on.
+**Lanes get map headings, never a `--lane` flag.** Rule maps are keyed on
+`## /aw-spec-<name>`, so a lane's rule set is reached under its own heading —
+`## /aw-spec-implement-ui` for the frontend lane of `implement`, and so on. A flag would have
+no heading to key on. Where the two lanes are folded into one command, as `plan` and
+`implement` are, the heading names the lane and the command dispatches on the declaration.
 
 ---
 
@@ -55,9 +57,9 @@ and so on. A flag would have no heading to key on.
 
 ### Three properties matter more than the schema
 
-1. **`root` is ownership, and it is the source path.** `implement` writes only under a
-   backend lane's root, `ui-implement` only under a frontend lane's, `build`/`test`/`run`
-   act on it, and `onboard` reverse-engineers out of it.
+1. **`root` is ownership, and it is the source path.** `implement`'s service lane writes only
+   under a backend lane's root and its frontend lane only under a frontend lane's,
+   `build`/`test`/`run` act on it, and `onboard` reverse-engineers out of it.
 2. **The commands are project-supplied strings.** The engine stays stdlib-only and
    stack-ignorant. This is how `build` already avoids knowing what a compiler is, and it
    is the only thing that makes "any frontend stack" tractable.
@@ -96,8 +98,7 @@ project it does not exist yet — the whole point of declaring `src/` on day one
 `implement` will create it.
 
 `lane-verify` is the check, and it runs where the path has to be real: before `implement`,
-`implement-delta`, `build`, `run`, and before `onboard` reverse-engineers a codebase out of
-it. That split is what lets one file serve a project with no code yet and a project that is
+`build`, `run`, and before `onboard` reverse-engineers a codebase out of it. That split is what lets one file serve a project with no code yet and a project that is
 nothing but code.
 
 Two failure classes, deliberately distinguished:
@@ -139,7 +140,7 @@ file re-checks all three.
 
 `lane-resolve` still reports `declared: false` and exits 0 when the file is missing — reading
 is never fatal. What changed is that the phases which *act* on a lane no longer proceed
-without one. `constitution`, `onboard`, `implement`, `implement-delta`, `build` and `run` all
+without one. `constitution`, `onboard`, `implement`, `build` and `run` all
 call `lane-verify` and stop with the fix named, because each of them needs an answer this
 file is the only place to get: which lanes to govern, which subtree to scan, where to write.
 

package/assets/.appweaver/orchestrator/.state/smoke.state.json

@@ -0,0 +1,32 @@
+{
+  "vars": {},
+  "strategy": "agent",
+  "model": "",
+  "input": "",
+  "answers": {},
+  "selects": {},
+  "agent_profile": "",
+  "isolation": "bare",
+  "os": "posix",
+  "cache": {
+    "script_ro": {
+      "domains": [
+        "dotnet-default-project"
+      ]
+    }
+  },
+  "pending": {
+    "kind": "ask",
+    "key": "pick_mode",
+    "step": "pick_mode",
+    "prompt": "Smoke mode?",
+    "options": [
+      "fast",
+      "slow"
+    ],
+    "multi": false,
+    "instructions": "Ask the USER this question (the options are the allowed choices). Write the answer as PLAIN TEXT to response_path, then re-run the resume command.",
+    "response_path": ".appweaver/orchestrator/.state/smoke.state.json.response.md",
+    "resume": "python3 .appweaver/orchestrator/orchestrator.py .appweaver/orchestrator/workflows/_smoke.orch.yaml --checkpoint .appweaver/orchestrator/.state/smoke.state.json --json"
+  }
+}

package/assets/.appweaver/orchestrator/AGENT-PROFILE.md

@@ -70,7 +70,10 @@ same) — none of which the engine knows about; it only follows the profile's
 [bin] + args
       + (model_flag model)                     if model_flag and --model
       + (system.flag system)                   if system is a {flag}
-      + (tools_flag tools)                     if tools_flag
+      + (tools_flag tools)                     if tools_flag is declared — ALWAYS, even
+                                               when tools is empty: an empty allowlist is
+                                               "no tools", and omitting the flag instead
+                                               lets the CLI fall back to its default set
       + approval[permission_mode | default]
       + isolation[--isolation]
       + (budget_flag budget)                   if budget_flag and --budget

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

@@ -0,0 +1,251 @@
+# =============================================================================
+# delta-plan (orchestrator module) — author ONE change's LANE PLANS
+#
+# Included by /appweaver plan on its DELTA branch (a master plan already exists).
+# It authors, inside the change's own directory beside its delta-spec:
+#   • changes/<cr-id>/delta-backend-plan.md   when a backend lane is declared
+#   • changes/<cr-id>/delta-frontend-plan.md  when a frontend lane is declared
+# and touches NEITHER master. The change stays OPEN; `implement` generates the code from
+# these documents (it asks which change, and takes the delta plans of the answer),
+# finalize-delta merges the change's SPEC and MODEL halves (never a lane plan — a master
+# plan is derived from those two and is re-derived from them), and close-delta archives
+# these plans with the change at the end. No version bump here, no code (that is
+# /appweaver implement).
+#
+# IT DOES NOT CHOOSE THE CHANGE — the caller already did. `plan` asks one question at the
+# top of its run (which is why a re-plan of the MASTER and a delta are the same command),
+# activates the answer and resolves its documents, so this module receives cr_id / cr_dir
+# / delta_spec / delta_model / wave / predecessor_files already bound and is pure
+# AUTHORING. The plan-only change — a refactor or architectural decision where the
+# realisation of EXISTING spec ids moves with no spec delta — is the caller's NEW option
+# and reaches this module as an ordinary change whose delta-spec is an unfilled stub.
+#
+# IT PLANS AGAINST THE EFFECTIVE MODEL, not the bare master:
+#   • the context's domain-model.md          — what the domain IS today
+#   • this change's domain-model.<cr>.delta.md — what this change makes it
+#   • the PREDECESSOR deltas — every open model delta in a LOWER WAVE. A wave is a
+#     dependency level: same wave means independent and developable in parallel, higher
+#     wave means "after those land". So a lower-wave delta is committed to landing first
+#     and may be built on; a same-wave one is visible but is never assumed, because
+#     nothing orders the two against each other.
+#
+# IT READS THE CODE. The feature's real source files arrive from its OKF concept
+# (concept-paths, resolved by the caller) as a PATH LIST, and the authoring steps declare
+# `tools: Read` — a delta plan for an existing feature has to be written against the code
+# that is actually there, not against an idealised master.
+#
+# Runs in the CALLER's context (include semantics): shares vars + the sticky standards
+# (plan's per-lane rule sets) + the caller's scripts map + replay cache.
+# EXPECTS caller vars: feature_dir, spec_file, backend_plan, frontend_plan, domain_model,
+#   be_existing, fe_existing, fe_lane_id, source_files, source_count, USER_INPUT,
+#   and — resolved by the caller from the change it chose and activated — cr_id, cr_dir,
+#   delta_spec, delta_model, wave, predecessor_files, predecessor_count, sibling_count.
+# PRODUCES: delta_backend_plan, delta_frontend_plan, downstream_count, impact_report.
+# =============================================================================
+
+name: delta-plan
+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 plan already supplies them);
+# declaring both keeps the module self-contained + validatable on its own. `actions`
+# mirrors the caller's ref; `xref` (the OKF cross-reference substrate) drives the advisory
+# blast-radius step below.
+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
+
+# Fallbacks only — every one of these is bound by the caller before the include, and is
+# declared here so the module stays validatable on its own.
+vars:
+  cr_id: ""                 # the change being planned — normalised by the caller's cr-paths
+  wave: "1"
+  predecessor_files: []     # every open model delta in a LOWER wave — this delta's predecessors
+  predecessor_count: "0"
+  sibling_count: "0"
+  delta_backend_plan: ""
+  delta_frontend_plan: ""
+
+workflow:
+
+  # 1. Scaffold this change's plan document for each lane whose MASTER already exists.
+  #    A lane whose master was scaffolded in this same run has just been authored from
+  #    the whole spec — there is nothing for a delta to add to it — so it gets none.
+  - id: be_delta_scaffold
+    condition: "{{be_existing}} == true"
+    action: execute_script
+    script: { ref: actions }
+    subcommand: delta-plan-scaffold
+    args: ["--cr-id", "{{cr_id}}", "--lane", "backend", "--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: delta_backend_plan, from: "$.delta_plan" }
+
+  - id: fe_delta_scaffold
+    condition: "{{fe_existing}} == true"
+    action: execute_script
+    script: { ref: actions }
+    subcommand: delta-plan-scaffold
+    args: ["--cr-id", "{{cr_id}}", "--lane", "frontend", "--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: delta_frontend_plan, from: "$.delta_plan" }
+
+  # ═════════════════════ BACKEND LANE — the service delta plan ═════════════════
+  - id: ctx_backend_delta
+    condition: "{{be_existing}} == true"
+    action: build_context
+    context_from: predecessor_files          # the open model deltas in LOWER waves — committed
+                                             # to landing first, so this plan may build on them.
+                                             # Empty for a wave-1 delta, which is the common case.
+    context:
+      - "{{delta_backend_plan}}"             # the delta plan template to fill
+      - "{{delta_spec}}"                     # the spec-side change (from specify)
+      - { path: "{{delta_model}}", optional: true }
+                                             # this change's MODEL half — the structure the plan
+                                             # realises. Optional: a plan-only change has an
+                                             # unfilled one, and that is a valid state.
+      - "{{spec_file}}"                      # the current master spec (READ ONLY)
+      - "{{backend_plan}}"                   # the current master plan (READ ONLY — never amended here)
+      - { path: "{{domain_model}}", optional: true }
+                                             # the context's CANONICAL model — the aggregate root,
+                                             # its entities and its invariants live here, not in the
+                                             # spec and not in this plan.
+      - { path: .appweaver/DESIGN-FORMAT.md }
+  - id: author_backend_delta
+    condition: "{{be_existing}} == true"
+    action: agent_author                     # plan's technical standards stay ON (default) — correct here
+    tools: Read   # the feature's EXISTING source arrives as {{source_files}} paths, not inlined
+    output_target: { type: file, path: "{{delta_backend_plan}}" }
+    task: |
+      Fill the SERVICE-LANE delta plan for change {{cr_id}} (wave {{wave}}) — the target
+      document in context — from the delta-spec, this change's model delta and the CURRENT
+      master backend plan (all in context). THE DELTA ONLY. Do NOT edit backend-plan.md —
+      no stage merges this delta back into it: the master is derived from the spec and the
+      model, which is where finalize-delta lands the change.
+      - READ THE CODE FIRST. {{source_count}} source file(s) currently realise this
+        feature: {{source_files}}. Read the ones this change touches before planning it.
+        The master plan says what the structure was designed to be; the code says what it
+        IS, and a delta that ignores the difference plans an edit to something that is not
+        there. Where the two disagree, plan against the code and record the divergence as
+        a WA-n.
+      - Classify every change to the plan 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.
+        A shared element (e.g. the aggregate root's realisation) is MODIFIED in place,
+        never duplicated.
+      - STRUCTURE IS NOT YOURS TO WRITE. Entities, value objects, domain events and
+        invariants (BR-n) live in the context's domain model and in this change's model
+        delta. Fill "## Model changes this plan realises" with one row per item that
+        model delta ADDED / MODIFIED / REMOVED, saying where it lands and WHERE the
+        invariant is ENFORCED. Cite ids; never restate what an invariant says. An item in
+        the model delta with no row here is a structural change nothing implements.
+      - THE EFFECTIVE MODEL IS master + this change's delta + the PREDECESSOR deltas in
+        context (open changes in a LOWER wave, committed to landing first). You MAY build
+        on a predecessor — record it under "## Depends on", which is what orders the
+        finalizes. You may NOT assume a same-wave delta: nothing orders it against this
+        one. Where one touches the same aggregate or element, say so under "Other open
+        deltas" and plan around it. Until merged, every one of them is a proposal.
+      - PUBLISH WHAT THE FRONTEND LANE NEEDS. Fill "## Contract deltas for the frontend
+        lane" with every addition or change to this feature's published surface, as field
+        shapes. That table is the only part of this document the frontend delta plan may
+        bind against; a contract the UI needs and this document never states becomes a
+        client-side workaround. "None" when the surface is unchanged.
+      - Stay technology-agnostic (no code) and keep the master's form: behaviour as
+        signatures + pre/post/invariant/raises, contracts as field shapes.
+      - TWO CASES — decide from the delta-spec in context:
+        • SPEC-DRIVEN — the delta-spec lists ADDED/MODIFIED/REMOVED spec items: realise
+          them; every changed plan element serves one of those spec ids.
+        • PLAN-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.
+      - Do NOT edit the Wave / Base version / Delta spec / Model delta headers — scripts
+        stamp those.
+      Guidance: {{USER_INPUT}}
+
+  # ═════════════════════ FRONTEND LANE — the experience delta plan ═════════════
+  - id: ctx_frontend_delta
+    condition: "{{fe_existing}} == true"
+    action: build_context
+    context_from: predecessor_files          # the same lower-wave model deltas — the ubiquitous
+                                             # language and the aggregates this change assumes
+    context:
+      - "{{delta_frontend_plan}}"            # the delta plan template to fill
+      - "{{delta_spec}}"                     # the spec-side change (UX-/US-/FR- items)
+      - { path: "{{delta_model}}", optional: true }
+      - "{{spec_file}}"                      # the current master spec (READ ONLY)
+      - "{{frontend_plan}}"                  # the current master plan (READ ONLY — never amended here)
+      - { path: "{{delta_backend_plan}}", optional: true }
+                                             # THE SERVICE HALF of this same change — its contract
+                                             # table is what this lane binds to. Optional: an
+                                             # experience-only change has no service delta, and a
+                                             # frontend-only project has no service lane at all.
+      - { path: "{{domain_model}}", optional: true }
+      - { path: .appweaver/memory/constitution.ui.md, optional: true }
+      - { path: .appweaver/DESIGN-FORMAT.md }
+  - id: author_frontend_delta
+    condition: "{{fe_existing}} == true"
+    action: agent_author
+    tools: Read   # the lane's EXISTING source arrives as {{source_files}} paths, not inlined
+    output_target: { type: file, path: "{{delta_frontend_plan}}" }
+    task: |
+      Fill the FRONTEND-LANE delta plan for change {{cr_id}} (wave {{wave}}) — the target
+      document in context — from the delta-spec and the CURRENT master frontend plan (both
+      in context). THE DELTA ONLY. Do NOT edit frontend-plan.md — no stage merges this delta
+      back into it: the master is derived from the spec's UX- standards and the model, which
+      is where finalize-delta lands the change.
+      - READ THE CODE FIRST. {{source_count}} source file(s) currently realise this
+        feature: {{source_files}}. Read the ones this change touches — a delta that plans
+        an edit to a component that is not there, or that duplicates one that is, costs a
+        whole implementation pass to discover.
+      - Classify every change ADDED / MODIFIED / REMOVED against the master, per the
+        master's OWN sections. A shared component or a shared state container is MODIFIED
+        in place, never copied into the change.
+      - STATES ARE PART OF THE CHANGE. Fill "## Interaction states touched" with the FULL
+        state set of every interaction this change adds or alters — loading, empty, error,
+        permission-denied, in-flight. A new interaction that ships without them is an
+        incomplete delta, not a later refinement. A state the UI can reach that the
+        delta-spec does not describe is a SPEC gap: log it as a DA-n that routes back to
+        `specify`, never invent the requirement here.
+      - THE LANE BOUNDARY IS THE PUBLISHED SURFACE. Bind against the delta-spec's IC- ids
+        and, where the service delta is in context, its "Contract deltas for the frontend
+        lane" table. CITE those contracts; do not restate, re-derive or contradict them,
+        and introduce no server-side behaviour or persistence assumption. What the
+        experience needs and the surface does not offer goes under "Contract deltas
+        needed", raised back to the service lane — never worked around in the client.
+      - UX- IS THIS DOCUMENT'S TO REALISE. The service plan excludes the spec's Experience
+        Standards by contract, so a UX- item in the delta-spec that reaches neither plan
+        is a dropped requirement.
+      - Use the context's UBIQUITOUS LANGUAGE exactly as the domain model defines it, in
+        labels, states and messages — the same terms, no synonyms — and cite BR-nnn rather
+        than restating a rule.
+      - THE EFFECTIVE MODEL IS master + this change's delta + the PREDECESSOR deltas in
+        context (open changes in a LOWER wave). You MAY build on a predecessor — record it
+        under "## Depends on". You may NOT assume a same-wave delta; where one touches the
+        same screens or shared components, say so under "Other open deltas".
+      - TECHNOLOGY-AGNOSTIC: no framework, router, state library, component library or
+        styling approach — responsibilities, field shapes, events and states only. The
+        header's Lane field is `{{fe_lane_id}}`.
+      - Do NOT edit the Wave / Base version / Delta spec / Service delta headers — scripts
+        stamp those.
+      Guidance: {{USER_INPUT}}
+
+  # ADVISORY blast radius: who currently depends on THIS aggregate (its Cross-References in
+  # the OKF bundle). A change here may ripple to them — surfaced now, at planning 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.
+  - id: xref_impact
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: list
+    args: ["--feature-dir", "{{feature_dir}}", "--out", "{{cr_dir}}/impact.md"]
+    outputs:
+      - { name: downstream_count, from: "$.count" }
+      - { name: impact_report,    from: "$.impact_report" }