aw-spec-cli 0.1.28 → 0.1.30

package/assets/.amp/agent.json

@@ -0,0 +1,22 @@
+{
+  "name": "amp",
+  "runtime": "Amp CLI (amp -x)",
+  "note": "amp has no system-prompt flag, so 'system' is folded into the prompt (system: prepend), and no model flag (its --mode picks model, system prompt and tools together), so --model is ignored. No tools allowlist or bare mode, so isolation is best-effort: AGENTS.md still loads. -x is execute mode: the prompt is read from stdin and only the last assistant message is printed. --no-ide keeps the open editor's file and selection out of the prompt. Amp has no permission flags, so each step passes one of the kit's settings files with --settings-file: .amp/settings-edit.json allows every tool; .amp/settings-read.json rejects file writes, shell commands and subagents. That file stands in for the developer's own Amp user settings (MCP servers included) for spawned steps only; a workspace .amp/settings.json still applies on top of it. Amp has no launcher of its own: it reads .agents/skills/appweaver/SKILL.md. No sdk block: Amp has no Python SDK adapter, so sdk/sdk-apply are unavailable.",
+  "bin": "amp",
+  "args": ["-x", "--no-ide"],
+  "model_flag": null,
+  "system": "prepend",
+  "user": { "mode": "stdin" },
+  "tools_flag": null,
+  "approval": {
+    "acceptEdits": ["--settings-file", ".amp/settings-edit.json"],
+    "bypassPermissions": ["--settings-file", ".amp/settings-edit.json"],
+    "default": [],
+    "readonly": ["--settings-file", ".amp/settings-read.json"]
+  },
+  "isolation": {
+    "bare": [],
+    "fresh": []
+  },
+  "result_keys": ["result"]
+}

package/assets/.amp/settings-edit.json

@@ -0,0 +1,5 @@
+{
+  "amp.permissions": [
+    { "tool": "*", "action": "allow" }
+  ]
+}

package/assets/.amp/settings-read.json

@@ -0,0 +1,12 @@
+{
+  "amp.permissions": [
+    { "tool": "create_file", "action": "reject" },
+    { "tool": "edit_file", "action": "reject" },
+    { "tool": "apply_patch", "action": "reject" },
+    { "tool": "delete_file", "action": "reject" },
+    { "tool": "Bash", "action": "reject" },
+    { "tool": "shell_command", "action": "reject" },
+    { "tool": "async_shell_command", "action": "reject" },
+    { "tool": "Task", "action": "reject" }
+  ]
+}

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

@@ -128,6 +128,15 @@ a contract delta raised back to the service lane, never a client workaround. ⌛
 will emit that surface as a `design-contract.md` projection; the rule does not change when
 it does, only what §5 reads.
 
+**Contract deltas are a request ledger between the two plans.** frontend-plan.md §5 "Contract
+deltas needed" is a table, one `RQ-n` per operation the experience needs and the surface does
+not offer, with the operation id and field shapes it proposes; a request keeps its id for
+life. backend-plan.md §3 answers each in its "Requests from the frontend lane" table —
+`published` under an operation id, or `declined` with the reason — so each lane's developer
+writes only their own plan. `contract-requests` reads both: an open request is a backend-lane
+gap at `analyze-plan`, a declined one or an answered one not yet re-bound is a frontend-lane
+gap. With no backend plan at all, every binding is a request.
+
 **`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,

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

@@ -174,6 +174,70 @@ Declaring **`(none)`** for a lane is a real answer and the way a project says it
 
 ---
 
+## 2a. `.appweaver/lane.json` — the developer's working lane
+
+`stacks.json` says which lanes the **project** has. `lane.json` says which of them the
+**developer on this machine** works on — `backend`, `frontend` or `both`:
+
+```json
+{
+  "_note": "This developer's working lane: backend, frontend or both. Not committed. …",
+  "lane": "frontend",
+  "set_by": "select-lane",
+  "updated": "2026-10-11T07:46:32Z"
+}
+```
+
+- **Not committed** (the kit's `.gitignore` lists it). A backend developer and a frontend
+  developer on one repository each keep their own, so each can work on their lane at a
+  different time from the other.
+- **`select-stack` writes the default** after every declaration — `both` when both lanes are
+  declared, otherwise the one that is — so a re-stacked project starts again from every
+  declared lane. **`select-lane` narrows it**; its options come from `stacks.json` (all three
+  when both lanes are declared, only the declared one otherwise, picked without a question).
+- **A missing file reads as the default**, and so does one that names a lane `stacks.json`
+  no longer declares or that cannot be read — `working_note` says which. A stale choice never
+  switches a lane off.
+
+Every reader (`lane-resolve`, `lane-verify`) reports **`<kind>_working`** beside
+`<kind>_declared`, plus `working_lane`, `working_kinds[]` and three fields for callers that
+narrow: `working_kind` (the ONE kind being worked, or empty when every declared lane is),
+`working_root` and `working_test_path` (that lane's two paths, empty likewise). Empty is
+deliberate — passed as `--kind` or `--under`, it means "every declared lane", which is the
+behaviour from before the file existed.
+
+**The rule the phases follow: write the working lane, read the declared one.**
+
+| Phase | With a working lane narrower than the declared lanes |
+|---|---|
+| `plan` | scaffolds, authors, re-derives and delta-plans only the working lane; the menu and the re-derive question look only at its master. The other lane's plan is read — the frontend plan binds to the backend plan's published surface. The backend half answers the frontend's open contract requests and writes `api-draft.json`; the frontend half re-binds answered requests and raises new ones (§4.5) |
+| `analyze-plan` | gates, repairs and receipts only the working lane's plan (`.aw-plan-gate.<lane>.json`, that lane's verdict); check 3 reads the other plan and the request ledger, and a finding only it can close is reported for its developer (`plan-gaps --lanes` → `other`). The frontend receipt also hashes the backend plan's §3, so a backend contract change re-gates the frontend |
+| `implement` | offers, receipt-checks and generates only the working lane; a refused receipt skips that lane with the reason. The backend half exports the API document; the frontend half reads it, combined with the drafts, and never starts the service (§4.5) |
+| `build` | compiles only the working lane (`build-compile --kind`); `lane-verify --working-only` does not require the other lane's root on disk. With the backend worked, a green compile re-exports the API document |
+| `analyze-slice` | tests only the working lane (`test-run --kind`); the fix loops' file list is narrowed with `concept-paths --under`; the composition pass runs when the backend is worked |
+| `specify`, `finalize-delta`, `close-delta` | **ignore it** — the spec is written whole, and a change merges and closes with whatever its lanes delivered |
+
+**A change records the lanes it touches**, separately from anyone's working lane: the
+`**Lanes**:` line of its `delta-spec.md` — `backend`, `frontend`, or `backend, frontend`.
+`specify` asks when it opens a change, and `plan new` when it opens a plan-only one; the
+options come from `stacks.json`, both lanes first as the default, and one declared lane is
+taken without a question. The answer is not narrowed to the working lane of whoever opened
+the change. A delta-spec without the line, or with the template's `[…]` placeholder, touches
+every declared lane. `cr-lanes` (§6) reads and writes it; `cr-list` and `cr-paths` report it,
+and `cr-list --lane` lists only the changes touching the given lanes.
+
+What reads it:
+
+| Phase | With a change that names fewer lanes than are declared |
+|---|---|
+| `plan` | the change menu lists only the changes touching a working lane (`cr-list --lane`) and names the others in its question; `plan CR-…` naming one of those stops and says why. A change's delta plans are written only for the lanes it names that are worked and have a master |
+| `analyze-plan` | decides master or report mode per lane: a lane is repaired and receipted unless an open change names it (`cr-list --lane`), so a backend-only change leaves the frontend plan gateable while it is in flight. A report-mode lane's gaps are listed with those this run does not repair |
+| `implement` | changes mode only for the changes naming a working lane (`cr-list --lane`); the others are named in a note and the lane builds from its master. On a change, a working lane it does not name is skipped with that reason; `implement CR-…` naming another lane's change stops |
+| `analyze-plan-delta` | lists only the changes naming a working lane, and gates only the lanes the change names that are worked — a backend-only change needs no frontend delta plan. The other developer's delta plan is read for check 3; a gap only it can close is reported for them (`plan-gaps --lanes`), and its absence is a note. `contract-impact` warns when the service delta changes or removes an operation the frontend master binds to that the frontend delta does not name. A developer working one lane of two writes its report as `delta-plan-analyze-report.<lane>.md` |
+| `analyze-slice-delta` | lists only the changes naming a working lane, and gates only the lanes the change names that are worked and have a delta plan. Each gated lane runs its own tests (`test-run --kind`) and has its result written to `changes/<CR-id>/.aw-slice-gate.<lane>.json` (`slice-gate-stamp`) — `pass` when no test failed and its requirement checks are met, else `fail`, with `tests_ran` saying whether a suite actually ran — committed with the change. A named lane somebody else works on is a note: its developer gates it in their own run. A developer working one lane of two writes the report as `delta-slice-analyze-report.<lane>.md` |
+
+---
+
 ## 3. The ownership rule
 
 **Lane root folders own their subtree and must be disjoint.** Two generators must never be able
@@ -445,18 +509,34 @@ A layout the table gets wrong is fixed by writing `test_root` on the lane in `st
 ### 4.5 `contract_run`, `contract` and `client` — the API contract between the lanes
 
 The frontend lane binds to the service through the service's published API document, and
-the document that counts is the one the **built code** serves. `implement` therefore runs
-three steps between the two lanes, each of which warns rather than stops:
-
-1. **Export** (`contract-export`) — start the service with the backend lane's
-   `contract_run`, fetch its `contract` URL, write the document to
+the document that counts is the one the **built code** serves. **The backend lane publishes
+it and the frontend lane reads it**, so the two can be built by different developers at
+different times, and a frontend developer never needs the service's code built or its
+runtime installed. Every step warns rather than stops:
+
+1. **Export** (`contract-export`) — run by whoever works on the service lane: `implement`
+   after its backend half generates, and `build` after a green compile. Start the service
+   with the backend lane's `contract_run`, fetch its `contract` URL, write the document to
    `<service lane root folder>/contracts/openapi.json`, and stop the service with
    everything it started. A service already answering at the URL is used as it is, and
-   the run says it may be older than the code.
-2. **Client** (`contract-client`) — run the frontend lane's `client` command, with
-   `{{contract}}` standing for that document as seen from where the command runs.
-3. **Check** (`contract-check`) — every operation id the frontend plan cites must be an
-   `operationId` in the document.
+   the run says it may be older than the code. The document is committed with the service.
+2. **Draft** (`contract-draft`) — run by the backend lane's `plan` and `analyze-plan`:
+   `backend-plan.md` §3 drafted by script into `specs/<ctx>/<feature>/api-draft.json`, an
+   OpenAPI document of what the plan says the service will serve. Committed with the plan.
+3. **Combine** (`contract-combine`) — run by the frontend half of `implement`: the exported
+   document plus every drafted operation it does not serve yet, each marked `x-aw-draft`,
+   written to `.appweaver/contracts/openapi.combined.json` (not committed). A drafted
+   operation whose id the service serves drops out; one whose route and verb the service
+   answers under another id is left out and reported.
+4. **Client** (`contract-client --doc`) — run the frontend lane's `client` command, with
+   `{{contract}}` standing for the combined document as seen from where the command runs.
+5. **Check** (`contract-check`) — every operation id the frontend plan cites must be an
+   `operationId` in the combined document; the ids that are only drafts are named apart.
+
+Between the plans, what the frontend needs and the backend does not publish travels as a
+**request ledger**: `frontend-plan.md` §5 "Contract deltas needed" holds one `RQ-n` per
+request, and `backend-plan.md` §3 "Requests from the frontend lane" answers each —
+published under an operation id, or declined. `contract-requests` reads both (§6).
 
 Each key is read from the lane first and from its profile second, so a lane declared
 before the keys existed still answers them. Where the values come from:
@@ -604,10 +684,17 @@ implementation and the twins cannot drift.
 | `lane-declare --profile <id\|label\|none\|detected> [--kind k] [--id lane] [--source-path\|--root p] [--stack label] [--origin declared\|reverse-engineered] [--build/--test/--run/--migrate c] [--run-from repo\|root] [--no-prototype] [--require-existing-root]` | upsert a WHOLE lane — its one caller is `select-stack` (§5). `detected` declares a stack the kit ships no profile for (needs `--stack` and a lane root folder), which is how a legacy WebForms, JSP or ERB lane gets recorded at all |
 | `lane-set (--id lane\|--kind k) [--set KEY=VALUE]… [--unset KEY]…` | change only `contract_run`, `contract` or `client` on a lane already declared, leaving the rest of it alone. An empty VALUE changes nothing; `--unset` puts the key back on the profile's value. Called by `foundation` (a pack's lane settings) and `implement` (the client command a developer supplies) — re-declaring would reset every other command |
 | `contract-export [--timeout s]` | start the service lane with `contract_run`, fetch `contract`, save it to `<service root>/contracts/openapi.json`, stop the service and everything it started. A service already answering at the URL is used as it is, and said so (§4.5) |
-| `contract-client` | `run-phase --phase client` for the frontend lane — its `client` command, `{{contract}}` expanded |
-| `contract-check --plan p [--doc d]` | the operation ids a frontend plan cites (its §5 `Operation id` column, or a delta plan's `Contract Binding` rows) against the document's `operationId`s — by script, no model |
-| `lane-resolve [--kind k] [--id lane]` | read; exit 0 always. `exists` reports the file, `declared` reports the lanes — the shipped-but-unfilled seed is `exists:true, declared:false`. Returns the matched lane **and** both kinds flattened — `backend_source_path`, `frontend_root_exists`, `backend_build` … — so a workflow binds one variable instead of calling twice |
-| `lane-verify [--require backend\|frontend]… [--allow-missing-root] [--command phase]` | **the gate**: is the declaration usable for the phase about to run. Never writes, and **always exits 0** — the calling workflow's `verify_context` owns the stop, so the reason arrives as text |
+| `contract-draft --feature-dir p` | draft `api-draft.json` beside the feature's plans from `backend-plan.md`'s API section, by script: each `### \`VERB /route\`` endpoint with its operation id, request and response field shapes (conceptual types → JSON schema, a use case's DTO standing in for a named shape) and error statuses. Rewritten only when it differs; removed when the plan names no endpoint (§4.5) |
+| `contract-combine` | write `.appweaver/contracts/openapi.combined.json`: the exported document plus every feature's drafted operations it does not serve, marked `x-aw-draft`. `ok:false` with a reason when there is neither (§4.5) |
+| `contract-requests --feature-dir p` | the request ledger: the frontend plan's `RQ-n` rows against the backend plan's answers — `open`, `published` (and whether the frontend still has to re-bind), `declined` — with one line per lane's to-do for a prompt to quote |
+| `contract-client [--doc d]` | `run-phase --phase client` for the frontend lane — its `client` command, `{{contract}}` expanded to `--doc` (`implement` passes the combined document), else to the exported one |
+| `contract-check --plan p [--doc d]` | the operation ids a frontend plan cites (its §5 `Operation id` column, or a delta plan's `Contract Binding` rows; never the request table) against the document's `operationId`s — by script, no model. `drafted[]` names the cited ids that are only draft operations |
+| `contract-impact --delta-backend p --frontend-plan p [--delta-frontend p]` | the operations a change's service delta marks `changed` or `removed` in its "Contract deltas for the frontend lane" table that the frontend master plan binds to, and which of them the change's frontend delta plan does not name (`unaddressed[]`) — `analyze-plan-delta`'s warning. By script, no model |
+| `lane-resolve [--kind k] [--id lane] [--feature-dir p]` | read; exit 0 always. `exists` reports the file, `declared` reports the lanes — the shipped-but-unfilled seed is `exists:true, declared:false`. Returns the matched lane **and** both kinds flattened — `backend_source_path`, `frontend_root_exists`, `backend_build` … — so a workflow binds one variable instead of calling twice — and the working-lane fields of §2a |
+| `lane-verify [--require backend\|frontend]… [--allow-missing-root] [--working-only] [--command phase]` | **the gate**: is the declaration usable for the phase about to run. Never writes, and **always exits 0** — the calling workflow's `verify_context` owns the stop, so the reason arrives as text. `--working-only` checks on disk only the working lanes' root folders and the required kinds (§2a) |
+| `lane-select [--lane backend\|frontend\|both] [--default] [--preselect text]` | read or write `.appweaver/lane.json` (§2a). No argument reads it and returns the `select_options[]` the declared stacks offer; `--lane` writes one of them; `--default` writes the default — `select-stack`'s call |
+| `cr-lanes [--cr-id id [--feature-dir p] [--stamp] [--set both\|backend\|frontend]]` | the lanes a change touches (§2a). No `--cr-id` returns the `select_options[]` the declared stacks offer, both first; with it, reads that change's `**Lanes**:` line — `lanes[]` is what it touches among the lanes declared now, every declared lane when nothing is recorded. `--set` writes an answer (a whole option line is accepted); `--stamp` alone writes every declared lane |
+| `slice-gate-stamp --cr-id id --lane backend\|frontend [--feature-dir p] [--tests-green b] [--tests-ran b] [--requirements-ok b] [--findings json]` | write one lane's `analyze-slice-delta` result to `changes/<id>/.aw-slice-gate.<lane>.json` (§2a): `verdict` `pass` when no test failed and the requirements are met, else `fail`, with `tests_ran` (false when the lane declares no test command, so nothing ran), the findings counts and the sha256 of the delta-spec and the lane's delta plan it was gated against. Findings that cannot be read are recorded as `null`, never as none |
 | `lane-probe [--kind k] [--hint text]` | read; the **file** signals for "does this lane exist" — a declared lane, and a stack named in free prose. Retained for callers that want a soft hint; the authoritative answer is the declaration, read through `lane-resolve` or `lane-verify` |
 
 Both `lane-declare` branches — declaring a lane and declaring `none` — emit the **same key
@@ -618,7 +705,7 @@ set**, so a caller binds outputs without knowing which branch ran.
 | Subcommand | With a declaration | With none |
 |---|---|---|
 | `build-compile` | every declared lane's own `build`, via `run-phase` | the historic first-match-wins ladder |
-| `test-run` | every declared lane's own `test`, via `run-phase` — **except** `--scope slice` on a repo where a .NET toolchain is present, which keeps the VSTest `--filter` path | the historic ladder |
+| `test-run` | every declared lane's own `test`, via `run-phase` — **except** `--scope slice` on a repo where a .NET toolchain is present, which keeps the VSTest `--filter` path. `--kind` runs one lane only; `--kind frontend` always delegates, since the VSTest path runs the service's suite | the historic ladder |
 | `run-migrate` | a lane's declared `migrate` (§4.2) when there is one; otherwise `dotnet ef` searched under the **service lane root folder** rather than an assumed `src/` | `dotnet ef` under `src/` |
 | `find-host-project` | searches the service lane root folder, and reports the lane's `ecosystem` | searches `src/` |
 | `foundation-list`, `list-components` | narrowed to the `ecosystem` of the lane being scaffolded, else of every declared lane; `foundation-list` also by each entry's `# kind:` / `# profiles:` (§4.1) | unfiltered / `dotnet` |

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

@@ -42,8 +42,17 @@
 #
 # 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.
+# ONLY THE WORKING LANES THE CHANGE NAMES ARE AUTHORED. be_existing / fe_existing arrive
+# from the caller already narrowed to the developer's working lanes (.appweaver/lane.json)
+# and to the lanes on the change's **Lanes** line, so a lane that is somebody else's, or
+# that the change does not touch, gets no delta plan here. The other half of the change is
+# READ: the frontend delta plan binds to delta_backend_plan_read, the change's service delta
+# plan as the backend developer left it — absent for a frontend-only change, whose bindings
+# are to the master's published surface.
+#
 # 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,
+#   delta_backend_plan_read,
 #   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, predecessor_ids,
 #   sibling_count, sibling_ids, related_docs.
@@ -82,6 +91,7 @@ vars:
   related_docs: []
   delta_backend_plan: ""
   delta_frontend_plan: ""
+  delta_backend_plan_read: ""
 
 workflow:
 
@@ -134,13 +144,16 @@ workflow:
                                              # the lane's ratified technology base, the same one
                                              # the master plan is authored under — no domain.
       - { path: "{{cr_dir}}/delta-slice-analyze-report.md", optional: true }
+      - { path: "{{cr_dir}}/delta-slice-analyze-report.backend.md", optional: true }
                                              # WHAT THE LAST GATE FOUND, when this change
-                                             # has already been through analyze-slice-delta.
-                                             # A `plan` finding there says THIS document is
-                                             # what was wrong, and re-deriving it is how that
-                                             # finding is closed — the alternative is hand-
-                                             # editing a generated plan, which every
-                                             # authoring rule forbids. Absent on a first pass.
+                                             # has already been through analyze-slice-delta —
+                                             # the run that gated every lane, and the one that
+                                             # gated the backend alone. A `plan` finding there
+                                             # says THIS document is what was wrong, and
+                                             # re-deriving it is how that finding is closed —
+                                             # the alternative is hand-editing a generated
+                                             # plan, which every authoring rule forbids.
+                                             # Absent on a first pass.
       - { path: .appweaver/DESIGN-FORMAT.md }
   - id: author_backend_delta
     condition: "{{be_existing}} == true"
@@ -159,8 +172,10 @@ workflow:
         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.
-      - THE LAST GATE'S REPORT, when one is in context (delta-slice-analyze-report.md).
-        It records what analyze-slice-delta found the last time this change was gated. A
+      - THE LAST GATE'S REPORT, when one is in context (delta-slice-analyze-report.md from
+        a run that gated every lane, delta-slice-analyze-report.backend.md from one that
+        gated the backend alone; when both are, the one with the later date is the last
+        gate). It records what analyze-slice-delta found the last time this change was gated. A
         finding tagged `fix: plan` says THIS document was what was wrong — re-derive the
         rows it names, against the code it names. EVIDENCE, never a requirement source: the
         delta-spec stays the only authority on what the change must do, and a finding
@@ -245,21 +260,26 @@ workflow:
       - { 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 }
+      - { path: "{{delta_backend_plan_read}}", optional: true }
                                              # THE SERVICE HALF of this same change — its contract
-                                             # table is what this lane binds to. Optional: an
+                                             # table is what this lane binds to. READ here, and
+                                             # authored above only when the backend is a working
+                                             # lane: another developer may own it. 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: "{{cr_dir}}/delta-slice-analyze-report.md", optional: true }
+      - { path: "{{cr_dir}}/delta-slice-analyze-report.frontend.md", optional: true }
                                              # WHAT THE LAST GATE FOUND, when this change
-                                             # has already been through analyze-slice-delta.
-                                             # A `plan` finding there says THIS document is
-                                             # what was wrong, and re-deriving it is how that
-                                             # finding is closed — the alternative is hand-
-                                             # editing a generated plan, which every
-                                             # authoring rule forbids. Absent on a first pass.
+                                             # has already been through analyze-slice-delta —
+                                             # the run that gated every lane, and the one that
+                                             # gated the frontend alone. A `plan` finding there
+                                             # says THIS document is what was wrong, and
+                                             # re-deriving it is how that finding is closed —
+                                             # the alternative is hand-editing a generated
+                                             # plan, which every authoring rule forbids.
+                                             # Absent on a first pass.
       - { path: .appweaver/DESIGN-FORMAT.md }
   - id: author_frontend_delta
     condition: "{{fe_existing}} == true"
@@ -276,8 +296,10 @@ workflow:
         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.
-      - THE LAST GATE'S REPORT, when one is in context (delta-slice-analyze-report.md).
-        It records what analyze-slice-delta found the last time this change was gated. A
+      - THE LAST GATE'S REPORT, when one is in context (delta-slice-analyze-report.md from
+        a run that gated every lane, delta-slice-analyze-report.frontend.md from one that
+        gated the frontend alone; when both are, the one with the later date is the last
+        gate). It records what analyze-slice-delta found the last time this change was gated. A
         finding tagged `fix: plan` says THIS document was what was wrong — re-derive the
         rows it names, against the code it names. EVIDENCE, never a requirement source: the
         delta-spec stays the only authority on what the change must do, and a finding

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

@@ -25,11 +25,17 @@
 # Runs in the CALLER's context (include semantics): shares vars + the sticky standards
 # (specify's DDD authority + the selected domain rule files) + the caller's scripts map
 # + replay cache.
+# THE CHANGE'S LANES. Before opening the change this module asks which lanes it touches —
+# both (the default), backend or frontend, from the stacks declared — and stamps the answer
+# on the delta-spec's **Lanes** line. That is the only thing the answer does here: the
+# delta is still specified whole. It does not follow .appweaver/lane.json either; the
+# question is about the change, not about who is running specify.
+#
 # EXPECTS caller vars: feature_dir, spec_file, USER_INPUT, domain_model,
 #                      pending_model_files.
-# PRODUCES: cr_id, cr_dir, delta_spec, delta_model, wave, open_count (and, via cr-setup,
-#           an OPEN change). The change's LANE PLANS are scaffolded by `plan`, per declared
-#           lane — the spec phase does not know which lanes exist.
+# PRODUCES: cr_id, cr_dir, delta_spec, delta_model, wave, open_count, change_lanes_csv (and,
+#           via cr-setup, an OPEN change). The change's LANE PLANS are scaffolded by `plan`,
+#           per declared lane.
 #           cr_dir is what lets the caller's quality loop target THIS change
 #           (create-checklist --kind delta).
 # =============================================================================
@@ -46,8 +52,38 @@ scripts:
     sh:  .appweaver/scripts/bash/aw-spec-actions.sh
     ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
 
+vars:
+  change_lane_options: []
+  change_lane_has: "false"     # the declared stacks offer an answer (no lane declared ⇒ nothing to ask)
+  change_lanes: ""             # the answer picked; empty ⇒ every declared lane is stamped
+  change_lanes_csv: ""
+
 workflow:
 
+  # THE LANES THIS CHANGE TOUCHES, asked before the change is opened so that a cancelled
+  # answer leaves nothing behind. The options come from stacks.json: both — listed first,
+  # so it is the default — then each lane alone. One declared lane is the only answer and
+  # is taken without a question; with no lane declared there is nothing to ask. The answer
+  # is written onto the delta-spec's **Lanes** line once the change exists. The spec half
+  # below is authored whole whatever the answer: which lanes plan and build a change is a
+  # delivery question, not a requirements one.
+  - id: change_lane_options
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-lanes
+    outputs:
+      - { name: change_lane_options, from: "$.select_options" }
+      - { name: change_lane_has,     from: "$.has_options" }
+
+  - id: ask_change_lanes
+    condition: "{{change_lane_has}} == true"
+    action: user_select
+    prompt: "Which lanes does this change touch? The answer is recorded on the change's **Lanes** line as the lanes that plan and build it; the spec is written whole either way."
+    options_from_variable: change_lane_options
+    single_option_confirm: true
+    outputs:
+      - { name: change_lanes, from: selection }
+
   # Open the change + scaffold its TWO documents: the delta-spec under changes/<cr-id>/,
   # and the model delta BESIDE the context's master model. The delta PLANS are not
   # scaffolded here — `plan` owns them and creates them with delta-plan-scaffold when it
@@ -67,6 +103,19 @@ workflow:
       - { name: wave,        from: "$.wave" }
       - { name: open_count,  from: "$.open_count" }
 
+  # The answer, onto the delta-spec's **Lanes** line — before the author fills the document
+  # around it. --set goes last: an empty answer is dropped by PowerShell 5.1, and the
+  # script then stamps every declared lane. A failure leaves the template placeholder,
+  # which reads as every declared lane, so it does not stop the change from being written.
+  - id: stamp_change_lanes
+    action: execute_script
+    on_error: continue
+    script: { ref: actions }
+    subcommand: cr-lanes
+    args: ["--cr-id", "{{cr_id}}", "--feature-dir", "{{feature_dir}}", "--stamp", "--set", "{{change_lanes}}"]
+    outputs:
+      - { name: change_lanes_csv, from: "$.lanes_csv" }
+
   - id: ctx
     action: build_context
     context_from: pending_model_files      # EVERY other open delta's model change, so this
@@ -142,7 +191,10 @@ workflow:
         Wave rationale — that is a wave dependency, and the wave must then be RAISED above
         that delta's — name it under `## Depends on` and the wave is raised from that. Do not silently assume their
         changes: until merged they are proposals, not the master.
-      - Do NOT edit the Wave / Created / Base version headers — scripts stamp those.
+      - Do NOT edit the Wave / Lanes / Created / Base version headers — scripts stamp
+        those. Lanes ({{change_lanes_csv}}) says which lanes plan and build this change;
+        it does NOT narrow what you write here — the delta is specified whole, behaviour and
+        experience alike.
       Change request: {{USER_INPUT}}
 
   # The MODEL half of the same change, authored in the same run so the model can never

package/assets/.appweaver/orchestrator/modules/lane-gate.orch.yaml

@@ -33,6 +33,16 @@
 #              caller reads none of.
 #   command  — the phase being gated, quoted back in the failure message
 #
+# THE WORKING LANE. A declared lane that the developer on this machine does not work on
+# (.appweaver/lane.json — select-stack writes the default, select-lane narrows it) is not
+# required to be on disk here: a backend developer's build must not stop because the
+# frontend lane, somebody else's, has not been scaffolded yet. `--working-only` narrows the
+# on-disk check to the working lanes and the required kind; a lane with no root and two
+# lanes overlapping are still checked for every lane. The working lane's fields come back
+# too — `working_kind` is the ONE kind being worked, or empty when every declared lane is,
+# which is what a caller passes as `--kind` so that both lanes behave as before — and
+# `be_working` / `fe_working` say per kind whether it is declared and worked here.
+#
 # Produces, for the required kind: WHERE it lives (lane_root / lane_source_path),
 # WHAT it is (lane_profile / lane_title / lane_language / lane_ecosystem) and HOW it
 # is driven (lane_build / lane_test / lane_run), plus both kinds' flattened fields,
@@ -66,9 +76,15 @@ workflow:
     action: execute_script
     script: { ref: actions }
     subcommand: lane-verify
-    args: ["--require", "{{require}}", "--command", "{{command}}"]
+    args: ["--require", "{{require}}", "--command", "{{command}}", "--working-only"]
     outputs:
       - { name: lane_ok,            from: "$.ok" }
+      - { name: be_working,         from: "$.backend_working" }
+      - { name: fe_working,         from: "$.frontend_working" }
+      - { name: working_lane,       from: "$.working_lane" }
+      - { name: working_kind,       from: "$.working_kind" }
+      - { name: working_root,       from: "$.working_root" }
+      - { name: working_test_path,  from: "$.working_test_path" }
       - { name: lane_issues,        from: "$.message" }
       - { name: be_lane_id,         from: "$.backend_lane_id" }
       - { name: be_source_path,     from: "$.backend_source_path" }

package/assets/.appweaver/orchestrator/rev-templates/ui-design-template.skeleton.md

@@ -230,9 +230,18 @@ does none.]
 |---|---|---|---|---|---|---|
 | `[Screen]` | `[OperationId]` | `[operation]` | [field: type, …] | [field: type, …] | [§4 state] | FR-00X · IC-00X |
 
-**Contract deltas needed**: [anything the experience requires that the contract
-does not offer — raised back to the service lane, never worked around in the
-client. Or `None`.]
+**Contract deltas needed**
+
+<!-- THE REQUEST LEDGER. One row per operation the experience needs that the
+     contract does not offer — raised back to the service lane, never worked
+     around in the client. Each request keeps its RQ-n for life. The backend plan
+     answers in its "Requests from the frontend lane" table, published under an
+     operation id or declined with the reason; an answered request is re-bound
+     above to that id. Write `None` instead of the table when there is none. -->
+
+| Request | Operation id | Needed by | Sends (field shape) | Receives (field shape) | Serves |
+|---|---|---|---|---|---|
+| RQ-[n] | `[ProposedOperationId]` | `[Screen / component]` | [field: type, …] | [field: type, …] | FR-00X |
 
 ## 6. Cross-Cutting