aw-spec-cli 0.1.33 → 0.1.34

package/assets/.appweaver/orchestrator/workflows/aw-spec-implement.orch.yaml

@@ -3,7 +3,8 @@
 #
 # GENERATE the source files + paired tests for the aggregate, STRICTLY from its lane
 # plans — the mediators between the spec and the code:
-#   • specs/<Context>/<Feature>/backend-plan.md   when a BACKEND lane is declared
+#   • specs/<Context>/<Feature>/backend-plan.md   when a BACKEND lane is declared, with the
+#     api-plan.md beside it — the endpoints that plan realises
 #   • specs/<Context>/<Feature>/frontend-plan.md  when a FRONTEND lane is declared
 #
 # THE LANES COME FROM stacks.json, NOT FROM A FLAG — select-stack is the sole writer of
@@ -54,15 +55,18 @@
 # pipeline, so each runnable lane confirms first, naming its stack, its plan and the
 # subtree it will write into. Answering no to one lane leaves the other free to run.
 #
-# THE BACKEND PUBLISHES THE API DOCUMENT, THE FRONTEND READS IT. When the service lane
-# generates, its API document is exported from the running code and saved beside it, to be
-# committed. When the frontend lane generates, it never starts the service: it reads that
-# committed document plus the operations the backend plan has drafted and the service does
-# not serve yet (api-draft.json), combined into one, generates its client from it and
-# checks the operation ids its plan cites against it. Contract requests the backend plan has
-# not answered are named, and the bindings that wait on them are left unbound while the
-# rest of the lane generates. Every one of those steps warns rather than stops — see the
-# API CONTRACT block before the lane swap.
+# THE API PLAN IS THE CONTRACT, AND BOTH LANES BUILD TO IT. The service lane serves every
+# endpoint of the feature's api-plan.md — a change's delta-api-plan.md on the delta path —
+# at the route, verb and operation id it states; analyze-slice checks the built service
+# serves it, and this phase never starts the service. A feature or change planned before
+# API plans existed keeps its endpoints in its backend plan, which is read in their place.
+# When the frontend lane generates, it reads the operations the API plans draft
+# (api-draft.json, with each open change's draft applied), combined into one document,
+# generates its client from it and checks the operation ids its plan cites against it; the
+# feature's api-plan.md is in its context too, and the backend plan never is. Contract
+# requests the API plan has not answered are named, and the bindings that wait on them are
+# left unbound while the rest of the lane generates. Every one of those steps warns rather
+# than stops — see the API CONTRACT block before the lane swap.
 #
 # THE PLAN SAYS WHAT TO BUILD, THE MODEL SAYS WHAT THE DOMAIN IS. This phase does NOT read
 # spec.md — analyze-plan already conformed the plans to it, so the plan is the complete,
@@ -154,8 +158,8 @@
 # =============================================================================
 
 name: aw-spec-implement
-description: "Generate the aggregate's source files and paired tests from its lane plans — the backend lane from backend-plan.md when a backend stack is declared, the frontend lane from frontend-plan.md when a frontend stack is, both when both are. One command covers backend-only, frontend-only and full-stack projects and absorbs the former implement-ui and implement-delta. Self-detecting off the changes on disk — with none open that names a lane you work on (its **Lanes** line) it generates from the master plans; with one or more it ASKS which change and generates only what that change's delta plans mark ADDED or MODIFIED, for the lanes the change names, leaving the masters untouched. Every lane is gated on its own lane root folder, its own plan and its own scaffolded project, and a lane missing any of them is reported and skipped rather than failing the other lane; each runnable lane confirms before it writes. Model-driven, and it does not read the spec — analyze-plan already conformed the plans to it. The plan says WHAT to build; the bounded context's domain-model.md, in context alongside it, says what the domain IS — the entity names, the boundary and the text of every invariant the plan cites by id — joined on the delta path by that change's own model delta, since the master is not merged until finalize-delta. The stack binds here from the lane declaration and the constitution halves; the plans stay technology-agnostic."
-version: 3.13.0
+description: "Generate the aggregate's source files and paired tests from its lane plans — the backend lane from backend-plan.md, serving the endpoints of the api-plan.md beside it, when a backend stack is declared, the frontend lane from frontend-plan.md when a frontend stack is, both when both are. One command covers backend-only, frontend-only and full-stack projects and absorbs the former implement-ui and implement-delta. Self-detecting off the changes on disk — with none open that names a lane you work on (its **Lanes** line) it generates from the master plans; with one or more it ASKS which change and generates only what that change's delta plans mark ADDED or MODIFIED, for the lanes the change names, leaving the masters untouched. Every lane is gated on its own lane root folder, its own plan and its own scaffolded project, and a lane missing any of them is reported and skipped rather than failing the other lane; each runnable lane confirms before it writes. Model-driven, and it does not read the spec — analyze-plan already conformed the plans to it. The plan says WHAT to build; the bounded context's domain-model.md, in context alongside it, says what the domain IS — the entity names, the boundary and the text of every invariant the plan cites by id — joined on the delta path by that change's own model delta, since the master is not merged until finalize-delta. The stack binds here from the lane declaration and the constitution halves; the plans stay technology-agnostic."
+version: 3.16.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
@@ -200,7 +204,17 @@ vars:
   delta_backend_plan_exists: "false"
   delta_frontend_plan: ""
   delta_frontend_plan_exists: "false"
+  delta_api_plan: ""
+  delta_api_plan_exists: "false"
   wave: ""
+  # THE FEATURE'S API PLAN, and the one the backend lane serves this run (be_api_doc) —
+  # api-plan.md on the bootstrap path, the change's delta-api-plan.md on the delta path;
+  # be_api_doc is empty where there is none, because the (delta) backend plan still carries
+  # its own API.
+  api_plan: ""
+  api_plan_exists: "false"
+  be_api_doc: ""
+  be_api_ok: "false"
   # THE GATE RECEIPT — was this feature's plan pair checked against this spec, with what
   # verdict, and has anything moved since. analyze-plan writes it on every master run; this
   # phase is the reader. Bootstrap path only: a delta generates from delta plans, which
@@ -304,18 +318,8 @@ vars:
   fe_gap_names: ""
   fe_gaps_text: "none"
   # THE API CONTRACT between the lanes — see the block before the lane swap. Every flag
-  # starts lowered: the backend half publishes only when the service lane generates, and
-  # the frontend half reads only when the frontend lane does.
-  contract_go: "false"         # PUBLISH — the service lane generated in this run
-  contract_ok: ""
-  export_doc: ""               # the service's exported document (contracts/openapi.json)
-  export_doc_exists: "false"
-  contract_reason: ""
-  contract_already: "false"
-  contract_fresh: "true"
-  contract_log: ""
+  # starts lowered: the frontend half reads only when the frontend lane generates.
   contract_placeholder: ""
-  contract_export_status: ""
   combine_go: "false"          # READ — the frontend lane generates and a service lane is declared
   combined_ok: ""
   combined_status: ""
@@ -325,13 +329,15 @@ vars:
   clashes_clear: "true"
   contract_doc: ""             # what the frontend binds to: the combined document
   contract_doc_exists: "false"
-  contract_status: "none — no API document is in context, so take each binding from the plan alone and say so in your summary"
-  req_open_csv: ""             # the frontend plan's contract requests the backend plan has not answered
+  contract_status: "none — no API document is in context, so take each binding from the feature's API plan where it is in context, and from the plan alone otherwise, and say so in your summary"
+  req_open_csv: ""             # the frontend plan's contract requests the API plan has not answered
   req_backend_text: "none"
   req_summary: ""
   req_clear: "true"
-  check_drafted: ""
-  drafted_clear: "true"
+  check_unserved: ""
+  unserved_clear: "true"
+  check_removed: ""
+  removed_clear: "true"
   client_go: "false"
   client_ask: "false"
   client_answer: ""
@@ -441,6 +447,8 @@ workflow:
       - { name: backend_plan_exists, from: "$.backend_plan_exists" }
       - { name: frontend_plan,       from: "$.frontend_plan" }
       - { name: frontend_plan_exists, from: "$.frontend_plan_exists" }
+      - { name: api_plan,            from: "$.api_plan" }
+      - { name: api_plan_exists,     from: "$.api_plan_exists" }
 
   - id: require_feature
     action: verify_context
@@ -574,6 +582,10 @@ workflow:
       - { name: delta_backend_plan_exists, from: "$.delta_backend_plan_exists" }
       - { name: delta_frontend_plan,       from: "$.delta_frontend_plan" }
       - { name: delta_frontend_plan_exists, from: "$.delta_frontend_plan_exists" }
+      # THIS CHANGE'S API — the endpoints it adds, changes or removes. Absent for a change
+      # planned before delta API plans existed, whose delta backend plan carries them.
+      - { name: delta_api_plan,            from: "$.delta_api_plan" }
+      - { name: delta_api_plan_exists,     from: "$.delta_api_plan_exists" }
       - { name: wave,                      from: "$.wave" }
       # The lanes the change names — its delta-spec's **Lanes** line, every lane when it
       # records none.
@@ -584,14 +596,28 @@ workflow:
   # 3. WHICH PLAN EACH LANE GENERATES FROM, resolved once per lane from the mode — the
   #    master on the bootstrap path, this change's delta plan on the delta path. Every gate
   #    and prompt below reads be_plan / fe_plan, so neither has to re-branch on the mode.
+  #    The backend lane's API plan resolves beside its plan, and is emptied where it is not
+  #    on disk: that plan still carries its own API section.
   - id: be_plan_bootstrap
     condition: "{{mode}} == bootstrap"
     action: set
-    vars: { be_plan: "{{backend_plan}}", be_plan_ok: "{{backend_plan_exists}}" }
+    vars:
+      be_plan: "{{backend_plan}}"
+      be_plan_ok: "{{backend_plan_exists}}"
+      be_api_doc: "{{api_plan}}"
+      be_api_ok: "{{api_plan_exists}}"
   - id: be_plan_delta
     condition: "{{mode}} == delta"
     action: set
-    vars: { be_plan: "{{delta_backend_plan}}", be_plan_ok: "{{delta_backend_plan_exists}}" }
+    vars:
+      be_plan: "{{delta_backend_plan}}"
+      be_plan_ok: "{{delta_backend_plan_exists}}"
+      be_api_doc: "{{delta_api_plan}}"
+      be_api_ok: "{{delta_api_plan_exists}}"
+  - id: be_api_absent
+    condition: "{{be_api_ok}} != true"
+    action: set
+    vars: { be_api_doc: "" }
   - id: fe_plan_bootstrap
     condition: "{{mode}} == bootstrap"
     action: set
@@ -906,15 +932,17 @@ workflow:
     action: set
     vars: { fe_mode: "{{mode}}" }
 
-  # 8b. EACH GENERATING LANE'S ELEMENT LIST, read off its plan by plan-coverage. The
-  #     generation prompt carries it, and the model reports every name on it — so an
-  #     element it did not get to is declared rather than silently absent.
+  # 8b. EACH GENERATING LANE'S ELEMENT LIST, read off its plan by plan-coverage — and, for
+  #     the backend lane, the endpoints of the API plan it serves (`--api-plan`; an empty
+  #     path reads the endpoints from the plan's own API section). The generation prompt
+  #     carries it, and the model reports every name on it — so an element it did not get to
+  #     is declared rather than silently absent.
   - id: be_plan_elements
     condition: "{{be_go}} == true"
     action: execute_script
     script: { ref: actions }
     subcommand: plan-coverage
-    args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--list-only", "--reserved", "{{be_reserved}}"]
+    args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--api-plan", "{{be_api_doc}}", "--list-only", "--reserved", "{{be_reserved}}"]
     outputs:
       - { name: be_element_names,   from: "$.names_text" }
       - { name: be_collisions,      from: "$.collisions_csv" }
@@ -1011,6 +1039,7 @@ workflow:
     action: build_context
     context:
       - { path: "{{be_plan}}" }
+      - { path: "{{api_plan}}", optional: true }       # the endpoints the plan realises — absent where the plan still carries its own API section
       - { path: "{{domain_model}}", optional: true }   # the CONTEXT'S canonical model — what each cited BR-nnn REQUIRES
       - { path: .appweaver/memory/constitution.technical.md, optional: true } # technology base ONLY — no domain rules
   - id: gen_backend
@@ -1020,10 +1049,11 @@ workflow:
     permission_mode: acceptEdits
     task: |
       Generate the production code AND paired tests for this aggregate STRICTLY from its
-      backend-plan.md (in context). The plan is the complete, authoritative source of WHAT
-      to build — do NOT consult or infer from the spec; analyze-plan already conformed the
-      plan to it. This phase is the HOME of the technology-specific, solution-wide
-      code-generation rules. Guidance: {{USER_INPUT}}
+      backend-plan.md (in context), serving the endpoints of the api-plan.md beside it (in
+      context where the feature has one). The plans are the complete, authoritative source
+      of WHAT to build — do NOT consult or infer from the spec; analyze-plan already
+      conformed them to it. This phase is the HOME of the technology-specific,
+      solution-wide code-generation rules. Guidance: {{USER_INPUT}}
       Rules:
       - TWO DOMAIN INPUTS, WITH DIFFERENT JOBS. The PLAN is the only authority on WHAT TO
         BUILD — which elements exist, where each one lives, what surface they publish. The
@@ -1102,21 +1132,30 @@ workflow:
       - Realise EVERY plan element as code, changing nothing about WHAT it specifies: one
         file per Domain type / Application use-case / API endpoint / Infrastructure
         adapter, placed by layer. Preserve the ubiquitous-language names verbatim.
-      - Enforce EXACTLY as the plan states: every Domain invariant, Application handler
-        orchestration and API error contract; the cross-cutting constraints in the
+      - Enforce EXACTLY as the plans state: every Domain invariant, Application handler
+        orchestration and endpoint error contract; the cross-cutting constraints in the
         Cross-Cutting Concerns table (audit / retention / data-exposure — the CN-/DC-
         realisations); and each integration contract (IC-) in the External Integrations
         table. Implement every port the plan declares.
-      - GIVE EVERY ENDPOINT ITS OPERATION ID. Where the plan names an endpoint's
-        **Operation id**, set it as this stack's published API document names operations
-        (its OpenAPI operationId), spelled exactly as the plan writes it. The frontend lane
-        finds the endpoint by that id in the document exported from this code, so an
-        endpoint left on a framework-generated name is one it cannot find.
+      - SERVE EVERY ENDPOINT OF THE API PLAN EXACTLY AS IT IS WRITTEN. api-plan.md is the
+        API contract: each endpoint block gives the route, verb, **Operation id**, request
+        and response field shapes and the error contract, and **Maps to** names the
+        backend plan's use-case that serves it. Where api-plan.md is not in context, the
+        backend plan's own API section carries the same blocks. Serve each endpoint at the
+        route and verb it gives, with its field names and status codes as stated, and set
+        its operation id as this stack's published API document names operations (its
+        OpenAPI operationId), spelled exactly as the block writes it. The frontend lane
+        binds to the endpoint by that id, and analyze-slice checks that the built service
+        serves it there, so an endpoint left on a framework-generated name is one the
+        frontend calls and cannot reach.
       - Author a paired test for every plan behaviour / use-case / endpoint; derive the
         cases from the plan's pre/post/invariant contracts and cite the spec id (FR / BR /
         CN / DC / IC / US) from its Traceability section. Include tests for the constraints
         — e.g. an audit record is emitted, a DC-restricted field is NOT exposed on the
-        public surface, an IC- projection round-trips.
+        public surface, an IC- projection round-trips. THE CITATION IS CHECKED: analyze-slice
+        fails a slice in which some FR- or BR- of that section is named by no test. Write the
+        id in the test's name, a comment, an attribute or a tag, in whichever form this
+        language allows — `FR-004`, `FR_004` or `FR004`.
       - WIRE WHAT YOU BUILD, in this same pass. Every port, adapter, handler and endpoint
         the plan introduces is registered in the lane's composition root as the plan's §4.3
         Wiring states. A dependency that is injected and never bound COMPILES GREEN — a
@@ -1136,21 +1175,22 @@ workflow:
         one changed, STOP and surface it.
       - Where generated code depends on a plan Assumption (DA-n) or Workaround (WA-n), mark
         it with a comment citing that id so it is easy to revisit later.
-      - REPORT EVERY PLAN ELEMENT. The plan's elements, by name: {{be_element_names}}.
-        Add an `elements` list to your closing JSON block with one entry per name, spelled
-        exactly as listed: {"element": "<name>", "status": "done" | "blocked", "reason":
-        "<what stops it, when blocked>"}. `done` means it is realised in code now,
-        including one that already existed; `blocked` means you could not realise it. An
-        element missing from the list counts as not done, and the code is checked for
-        each name after this step.
+      - REPORT EVERY PLAN ELEMENT. The elements of the plan and its API plan, by name:
+        {{be_element_names}}. Add an `elements` list to your closing JSON block with one
+        entry per name, spelled exactly as listed: {"element": "<name>", "status": "done"
+        | "blocked", "reason": "<what stops it, when blocked>"}. `done` means it is
+        realised in code now, including one that already existed; `blocked` means you
+        could not realise it. An element missing from the list counts as not done, and the
+        code is checked for each name after this step.
     outputs:
       - { name: be_files, from: "$.files" }
       - { name: be_elements, from: "$.elements" }
 
   # ═══════════ BACKEND LANE — delta, generate ONLY what the change adds ════════
   # The delta plan is the authoritative source of WHAT changed — analyze-plan-delta already
-  # conformed it to the delta spec. The MASTER plan is the BASE (the unchanged elements the
-  # delta depends on).
+  # conformed it to the delta spec — and the change's delta-api-plan.md of the endpoints it
+  # adds, changes or removes. The MASTER plan and API plan are the BASE (the unchanged
+  # elements and endpoints the delta depends on).
   #
   # NO DELTA-SPEC HERE, exactly as the bootstrap path carries no spec. It used to be
   # inlined "only so the paired tests can cite traceability ids", but a document in the
@@ -1166,8 +1206,10 @@ workflow:
     action: build_context
     context:
       - { path: "{{be_plan}}" }                      # this change's delta-backend-plan.md
+      - { path: "{{delta_api_plan}}", optional: true } # this change's API — absent for a change whose delta plan carries it
       - { path: "{{delta_model}}", optional: true }  # this change's MODEL half — what it ADDS to / CHANGES in the model
       - { path: "{{backend_plan}}", optional: true } # the master plan — READ ONLY, never amended here
+      - { path: "{{api_plan}}", optional: true }     # the master API plan — READ ONLY, the endpoints as they stand BEFORE this change
       - { path: "{{domain_model}}", optional: true } # the master model — the domain as it stands BEFORE this change
       - { path: .appweaver/memory/constitution.technical.md, optional: true } # technology base ONLY — no domain rules
   - id: gen_backend_delta
@@ -1177,14 +1219,16 @@ workflow:
     permission_mode: acceptEdits
     task: |
       Implement ONLY change {{cr_id}} (wave {{wave}}) into the existing project tree,
-      STRICTLY from its delta-backend-plan.md (in context). The delta plan is the
-      authoritative source of WHAT changed — analyze-plan-delta already conformed it to the
-      delta spec. The master backend-plan.md (in context) is the BASE: the unchanged
-      elements the delta depends on; do NOT regenerate them. Guidance: {{USER_INPUT}}
+      STRICTLY from its delta-backend-plan.md and its delta-api-plan.md (in context where
+      the change has one). The delta plans are the authoritative source of WHAT changed —
+      analyze-plan-delta already conformed them to the delta spec. The master
+      backend-plan.md and api-plan.md (in context) are the BASE: the unchanged elements and
+      endpoints the delta depends on; do NOT regenerate them. Guidance: {{USER_INPUT}}
       Rules:
       - SCOPE = THE DELTA ONLY. Realise exactly the elements the delta plan marks ADDED
-        (create the new file) or MODIFIED (edit the existing file in place). Touch NOTHING
-        the delta does not list, except the regression re-tests below.
+        (create the new file) or MODIFIED (edit the existing file in place), and the
+        endpoints its API delta adds, changes or removes. Touch NOTHING the delta does not
+        list, except the regression re-tests below.
       - TWO DOMAIN INPUTS, WITH DIFFERENT JOBS. The DELTA PLAN is the only authority on
         WHAT TO BUILD in this change — which elements are added or edited, where each one
         lives, what surface they publish. The DOMAIN MODEL is the authority on WHAT THE
@@ -1262,10 +1306,16 @@ workflow:
         invariant, handler orchestration, API error contract, the Cross-Cutting Concerns
         realisations (audit / retention / data-exposure — CN-/DC-) and the External
         Integrations table's contracts (IC-) exactly as the delta plan states.
-      - GIVE EVERY ENDPOINT THIS CHANGE ADDS OR CHANGES the operation id the delta plan
-        names, set as this stack's published API document names operations (its OpenAPI
-        operationId) and spelled exactly; an existing endpoint keeps the id it has. The
-        frontend lane finds each endpoint by that id in the exported document.
+      - SERVE THE CHANGE'S API EXACTLY AS IT IS WRITTEN. delta-api-plan.md lists every
+        endpoint the change adds, changes or removes in its Contract deltas table, and
+        writes each added or changed endpoint whole below it; a change planned before delta
+        API plans existed carries the same in its delta backend plan. Serve each added or
+        changed endpoint at the route and verb its block gives, with its field names,
+        status codes and errors as stated, and set the operation id it names as this
+        stack's published API document names operations (its OpenAPI operationId), spelled
+        exactly; an existing endpoint keeps the id it has, and one the change removes is no
+        longer served. The frontend lane binds to each endpoint by that id, and
+        analyze-slice-delta checks the built service against the change's API draft.
       - COMPONENTS: if a delta element depends on a framework component, code against its
         ABSTRACTION / port as the delta plan declares — do NOT hand-roll it. Installing the
         component (packages, wiring, config) is /appweaver add-component <Component>; if
@@ -1275,7 +1325,10 @@ workflow:
         requirement id THE DELTA PLAN NAMES for that element (FR / BR / CN / DC / IC / US).
         The spec is not in context: take the id from the plan and cite it verbatim, never
         guess one from the element's shape. A delta-plan element that names no id is a
-        planning gap — surface it rather than inventing the traceability.
+        planning gap — surface it rather than inventing the traceability. THE CITATION IS
+        CHECKED: analyze-slice-delta fails a lane in which some FR- or BR- its delta plan
+        rows serve is named by no test — written as `FR-004`, `FR_004` or `FR004` in the
+        test's name, a comment, an attribute or a tag, whichever this language allows.
       - WIRE WHAT YOU BUILD, in this same pass: every port, adapter, handler and endpoint
         this change introduces is registered in the lane's composition root, as the delta
         plan states. A dependency injected and never bound compiles green and fails on the
@@ -1286,11 +1339,12 @@ workflow:
         shared element changed — but do NOT rewrite that existing behaviour.
       - Where generated code depends on a delta Assumption (DA-n) or Workaround (WA-n),
         mark it with a comment citing that id.
-      - REPORT EVERY DELTA ELEMENT. The delta plan's ADDED and MODIFIED elements, by name:
-        {{be_element_names}}. Add an `elements` list to your closing JSON block with one
-        entry per name, spelled exactly as listed: {"element": "<name>", "status": "done"
-        | "blocked", "reason": "<what stops it, when blocked>"}. An element missing from
-        the list counts as not done, and the code is checked for each name after this step.
+      - REPORT EVERY DELTA ELEMENT. The delta plan's ADDED and MODIFIED elements and the
+        endpoints its API delta adds or changes, by name: {{be_element_names}}. Add an
+        `elements` list to your closing JSON block with one entry per name, spelled exactly
+        as listed: {"element": "<name>", "status": "done" | "blocked", "reason": "<what
+        stops it, when blocked>"}. An element missing from the list counts as not done, and
+        the code is checked for each name after this step.
     outputs:
       - { name: be_files, from: "$.files" }
       - { name: be_elements, from: "$.elements" }
@@ -1313,7 +1367,7 @@ workflow:
     action: execute_script
     script: { ref: actions }
     subcommand: plan-coverage
-    args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--source-path", "{{be_source_path}}", "--test-path", "{{be_test_path}}", "--reported", "{{be_elements}}", "--generated", "{{be_files}}"]
+    args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--api-plan", "{{be_api_doc}}", "--source-path", "{{be_source_path}}", "--test-path", "{{be_test_path}}", "--reported", "{{be_elements}}", "--generated", "{{be_files}}"]
     outputs:
       - { name: be_complete,  from: "$.ok" }
       - { name: be_outcome,   from: "$.outcome" }
@@ -1353,8 +1407,8 @@ workflow:
       COMPLETE the backend lane. The generation pass before this one left these plan
       elements unrealised: {{be_gap_names}}.
       Why each was flagged: {{be_gaps_text}}.
-      The same plan, domain model and constitution are in context, and every rule of that
-      pass still holds: realise each element STRICTLY as the plan states it; production
+      The same plans, domain model and constitution are in context, and every rule of that
+      pass still holds: realise each element STRICTLY as the plans state it; production
       code only under `{{be_source_path}}` and paired tests only under `{{be_test_path}}`;
       the `{{be_lane_id}}` lane's stack ({{be_title}}, {{be_language}}) and no other;
       shared aggregate files EXTENDED, never regenerated; nothing the plan does not state.
@@ -1366,7 +1420,7 @@ workflow:
         plan's names are the ubiquitous language.
       - An element the plan names by intent (a port, an adapter, an endpoint route) is done
         when the code realises it, whatever the framework calls it; report it `done`. An
-        endpoint still carries the operation id the plan names, set exactly.
+        endpoint still carries the operation id its API plan names, set exactly.
       - If an element cannot be realised, do not work around it: report it `blocked` and
         say what stops you. A plan that is wrong is fixed in plan / analyze-plan.
       - Report every listed element in an `elements` list in your closing JSON block:
@@ -1379,7 +1433,7 @@ workflow:
     action: execute_script
     script: { ref: actions }
     subcommand: plan-coverage
-    args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--source-path", "{{be_source_path}}", "--test-path", "{{be_test_path}}", "--reported", "{{be_elements}}", "--reported", "{{be_elements_more}}"]
+    args: ["--plan", "{{be_plan}}", "--kind", "backend", "--mode", "{{be_mode}}", "--api-plan", "{{be_api_doc}}", "--source-path", "{{be_source_path}}", "--test-path", "{{be_test_path}}", "--reported", "{{be_elements}}", "--reported", "{{be_elements_more}}"]
     outputs:
       - { name: be_complete,  from: "$.ok" }
       - { name: be_outcome,   from: "$.outcome" }
@@ -1411,68 +1465,32 @@ workflow:
     outputs:
       - { name: okf_concept, from: "$.concept" }
 
-  # ══════════════ THE API CONTRACT — published by the backend, read by the frontend ═══
-  # The frontend binds to the service through its API document, and the document that
-  # counts is the one the CODE serves: routes, verbs, parameters, field names and status
-  # codes as built, which the plans only describe. THE BACKEND PUBLISHES IT AND THE FRONTEND
-  # READS IT, so the two lanes can be built by different developers at different times.
-  # Every step below WARNS and carries on — the frontend still generates, from its plan,
-  # when one of them cannot run.
-  #   1. PUBLISH (when the service lane generated in this run) — start the service with
-  #      its lane's `contract_run`, save what it serves at `contract` under its lane root
-  #      folder, stop it (contract-export). The two values come from the lane in
-  #      stacks.json — where foundation records a pack's own — or else from the stack
-  #      profile. The document is committed with the service, and `build` refreshes it
-  #      after a green compile. A frontend run never starts the service: its developer may
-  #      have neither the service built nor its runtime installed.
-  #   2. REQUESTS — the frontend plan's contract requests the backend plan has not answered
-  #      yet (contract-requests), named to whichever lane runs.
-  #   3. COMBINE (when the frontend lane generates) — the committed document plus every
-  #      operation a backend plan has drafted (api-draft.json) and the service does not
-  #      serve yet, written to .appweaver/contracts/openapi.combined.json (contract-combine).
-  #      That is how a frontend binds to an endpoint the backend has planned and not built.
-  #   4. CLIENT — run the frontend lane's `client` command against the combined document. A
+  # ══════════════ THE API CONTRACT — planned by the backend, bound to by the frontend ═══
+  # The frontend binds to the service through an API document, and the document that counts
+  # is the API plan's: every endpoint api-plan.md names — its backend plan's API section,
+  # for a feature planned before API plans existed — with route, verb, parameters, field
+  # names and status codes, drafted by script into api-draft.json beside it, and, while a
+  # change is open, the change's own draft over it. The code is held to that document
+  # (analyze-slice and analyze-slice-delta check the built service against it), so the two
+  # lanes can be built by different developers at different times and in either order, and
+  # nothing here starts the service. Every step below WARNS and carries on — the frontend
+  # still generates, from its plan, when one of them cannot run.
+  #   1. REQUESTS — the frontend plan's contract requests the API plan has not answered yet
+  #      (contract-requests), named to whichever lane runs.
+  #   2. COMBINE (when the frontend lane generates) — every operation the API plans draft,
+  #      with the open changes applied, written to
+  #      .appweaver/contracts/openapi.combined.json (contract-combine). The service lane's
+  #      as-built document, when one is committed, adds the operations no plan describes and
+  #      marks the planned ones it does not serve yet.
+  #   3. CLIENT — run the frontend lane's `client` command against the combined document. A
   #      lane with none yet asks the developer once and records the answer on the lane; an
   #      empty answer carries on without a generated client.
-  #   5. CHECK — every operation id the frontend plan cites must be in the combined
-  #      document (contract-check, by script); a cited draft operation is named apart.
-  - id: contract_arm
-    condition: "{{be_go}} == true"
-    action: set
-    vars: { contract_go: "true" }
-  - id: contract_export
-    condition: "{{contract_go}} == true"
-    action: execute_script
-    on_error: continue
-    script: { ref: actions }
-    subcommand: contract-export
-    outputs:
-      - { name: contract_ok,          from: "$.ok" }
-      - { name: export_doc,           from: "$.doc" }
-      - { name: export_doc_exists,    from: "$.doc_exists" }
-      - { name: contract_reason,      from: "$.reason" }
-      - { name: contract_already,     from: "$.already_running" }
-      - { name: contract_ops,         from: "$.operations" }
-      - { name: contract_log,         from: "$.log_tail" }
-      - { name: contract_export_status, from: "$.status" }
-  - id: warn_contract_export
-    condition: "{{contract_go}} == true"
-    action: verify_context
-    require_true: contract_ok
-    on_false: continue
-    on_false_message: "API DOCUMENT NOT EXPORTED — {{contract_reason}}. The service lane `{{be_lane_id}}` is started with its `contract_run` command and its document fetched from its `contract` URL, both read from .appweaver/stacks.json or else its stack profile; correct them on the lane there if they do not fit this project, start anything the service needs, and re-run implement or build. Until it is exported and committed, the frontend lane binds to the last committed document plus the backend plan's draft. Service output: {{contract_log}}"
-  - id: contract_stale_flag
-    condition: "{{contract_already}} == true"
-    action: set
-    vars: { contract_fresh: "false" }
-  - id: warn_contract_stale
-    condition: "{{contract_go}} == true"
-    action: verify_context
-    require_true: contract_fresh
-    on_false: continue
-    on_false_message: "WARNING — the API document was {{contract_reason}}. Stop that service and re-run implement to export the code as it is now."
+  #   4. CHECK — every operation id the frontend plan cites must be in the combined
+  #      document (contract-check, by script); one an open change removes, and one the
+  #      service does not serve yet, are named apart.
 
-  # 2. THE REQUEST LEDGER — read from both plans, for whichever lane runs.
+  # 1. THE REQUEST LEDGER — read from the frontend plan and the API plan, for whichever lane
+  #    runs.
   - id: contract_requests
     action: execute_script
     on_error: continue
@@ -1492,15 +1510,15 @@ workflow:
     action: verify_context
     require_true: req_clear
     on_false: continue
-    on_false_message: "FRONTEND CONTRACT REQUESTS OPEN — the frontend plan asks the service for {{req_open_csv}}, and backend-plan.md has not answered them: {{req_backend_text}}. This run generated the backend plan as it stands. Answer each request — publish it under an operation id, or decline it with the reason — with /appweaver plan or /appweaver analyze-plan for the backend lane, then re-run implement."
+    on_false_message: "FRONTEND CONTRACT REQUESTS OPEN — the frontend plan asks the service for {{req_open_csv}}, and the API plan has not answered them: {{req_backend_text}}. This run generated the backend lane from its plans as they stand. Answer each request in the API plan's requests table — publish it under an operation id, or decline it with the reason — with /appweaver plan or /appweaver analyze-plan for the backend lane, then re-run implement."
   - id: warn_requests_frontend
     condition: "{{fe_go}} == true"
     action: verify_context
     require_true: req_clear
     on_false: continue
-    on_false_message: "CONTRACT REQUESTS STILL OPEN — {{req_open_csv}}: the frontend plan asks the service for these and the backend plan has not answered them. The bindings that wait on them are left unbound and marked in this run, and the rest of the frontend lane generates. The backend lane's developer answers them in backend-plan.md; re-run implement once they are published."
+    on_false_message: "CONTRACT REQUESTS STILL OPEN — {{req_open_csv}}: the frontend plan asks the service for these and the API plan has not answered them. The bindings that wait on them are left unbound and marked in this run, and the rest of the frontend lane generates. The backend lane's developer answers them in the API plan (api-plan.md, or the backend plan of a feature planned before API plans existed); re-run implement once they are published."
 
-  # 3. THE COMBINED DOCUMENT — what the frontend reads, never the running service.
+  # 2. THE COMBINED DOCUMENT — what the frontend reads, never the running service.
   - id: combine_arm
     condition: "{{fe_go}} == true"
     action: set
@@ -1524,7 +1542,7 @@ workflow:
     action: verify_context
     require_true: combined_ok
     on_false: continue
-    on_false_message: "NO API DOCUMENT — {{combined_reason}}. The backend lane publishes {{combined_export}} when its implement or build runs, and drafts its plan's endpoints into api-draft.json when plan or analyze-plan runs; once they are committed and pulled here, re-run implement. Until then the frontend lane binds from its plan alone."
+    on_false_message: "NO API DOCUMENT — {{combined_reason}}. The backend lane drafts its API plan's endpoints into api-draft.json beside it when plan or analyze-plan runs and when finalize-delta merges a change, and a change's into its change folder; once they are committed and pulled here, re-run implement. Until then the frontend lane binds from its plan and the feature's API plan."
   - id: contract_doc_set
     condition: "{{combined_ok}} == true"
     action: set
@@ -1540,9 +1558,9 @@ workflow:
     action: verify_context
     require_true: clashes_clear
     on_false: continue
-    on_false_message: "DRAFT LEFT OUT — {{combined_clashes}}. The backend plan drafts an endpoint the service already serves under a different operation id, so the frontend binds to what the service serves. Correct the id in backend-plan.md (/appweaver plan or analyze-plan for the backend lane)."
+    on_false_message: "API DOCUMENT CLASH — {{combined_clashes}}. Each is left as the plan states it: an endpoint drafted twice keeps its first draft, and a route the service answers under another operation id keeps the plan's id, which the frontend binds by. The backend lane corrects the plan (/appweaver plan or analyze-plan) or the code (analyze-slice reports the served id that differs)."
 
-  # 4. THE CLIENT, generated from the combined document — so only once there is one.
+  # 3. THE CLIENT, generated from the combined document — so only once there is one.
   - id: client_arm
     condition: "{{contract_doc_exists}} == true"
     action: set
@@ -1610,7 +1628,7 @@ workflow:
     on_false: continue
     on_false_message: "NO API CLIENT GENERATED — the frontend lane `{{fe_lane_id}}` has no working `client` command, so this run writes its calls from the API document {{contract_doc}} instead. Set `client` on the lane in .appweaver/stacks.json (`{{contract_placeholder}}` stands for the document) to generate the client on the next run."
 
-  # 5. THE CHECK — the operation ids the frontend plan cites, against the combined document.
+  # 4. THE CHECK — the operation ids the frontend plan cites, against the combined document.
   - id: contract_check
     condition: "{{client_go}} == true"
     action: execute_script
@@ -1619,25 +1637,36 @@ workflow:
     subcommand: contract-check
     args: ["--plan", "{{fe_plan}}", "--doc", "{{contract_doc}}"]
     outputs:
-      - { name: check_ok,      from: "$.ok" }
-      - { name: check_reason,  from: "$.reason" }
-      - { name: check_drafted, from: "$.drafted_csv" }
+      - { name: check_ok,       from: "$.ok" }
+      - { name: check_reason,   from: "$.reason" }
+      - { name: check_unserved, from: "$.unserved_csv" }
+      - { name: check_removed,  from: "$.removed_csv" }
   - id: warn_contract_check
     condition: "{{client_go}} == true"
     action: verify_context
     require_true: check_ok
     on_false: continue
-    on_false_message: "CONTRACT CHECK — {{check_reason}}. Each binding in {{fe_plan}} names the endpoint it calls by the operation id the backend plan gives it, or the id its contract request proposes. An id in no document belongs to a contract request the backend has not answered (open now: [{{req_open_csv}}]), or the plan cites the wrong id (fix it with /appweaver plan, then analyze-plan), or an endpoint the service never gave that id (re-run implement for the backend lane). The frontend lane still generates; these bindings are where a call will fail."
-  - id: drafted_flag
-    condition: "{{check_drafted}} != "
+    on_false_message: "CONTRACT CHECK — {{check_reason}}. Each binding in {{fe_plan}} names the endpoint it calls by the operation id the API plan gives it, or the id its contract request proposes. An id in no document belongs to a contract request the backend has not answered (open now: [{{req_open_csv}}]), or the frontend plan cites the wrong id (fix it with /appweaver plan, then analyze-plan), or the API plan has not published the endpoint yet. The frontend lane still generates; these bindings are where a call will fail."
+  - id: unserved_flag
+    condition: "{{check_unserved}} != "
+    action: set
+    vars: { unserved_clear: "false" }
+  - id: warn_unserved
+    condition: "{{client_go}} == true"
+    action: verify_context
+    require_true: unserved_clear
+    on_false: continue
+    on_false_message: "BOUND TO OPERATIONS NOT SERVED YET — {{check_unserved}}: the API plan publishes these, and the service's as-built document does not serve them yet. The frontend binds to them through the client as to any other operation; the calls fail at run time until the backend lane implements them."
+  - id: removed_flag
+    condition: "{{check_removed}} != "
     action: set
-    vars: { drafted_clear: "false" }
-  - id: warn_drafted
+    vars: { removed_clear: "false" }
+  - id: warn_removed
     condition: "{{client_go}} == true"
     action: verify_context
-    require_true: drafted_clear
+    require_true: removed_clear
     on_false: continue
-    on_false_message: "BOUND TO DRAFT OPERATIONS — {{check_drafted}}: the backend plan describes these and the service does not serve them yet. The frontend binds to them through the client as to any other operation; the calls fail at run time until the backend lane implements them and publishes its API document."
+    on_false_message: "BOUND TO OPERATIONS AN OPEN CHANGE REMOVES — {{check_removed}}: each is still in the API document, marked deprecated, until the service stops serving it once its change is implemented — or, where the change serves another operation on its route, is already replaced by that one, and the client no longer has it. Re-bind those elements — in the change's frontend delta plan (/appweaver plan <CR-id>) or a follow-up change — before then."
 
   # ══════════════ THE LANE SWAP — the frontend's rules replace the backend's ═══
   # build_context already scoped the two lanes' PAYLOADS apart; this is the same boundary
@@ -1659,7 +1688,8 @@ workflow:
   # The experience twin of the service generation, one lane over. Its own build_context,
   # because the envelope persists across steps and the two lanes must not see each other's
   # payload — the frontend binds to the service's PUBLISHED surface, never its internals.
-  # That surface is the API document the contract block exported, when there is one.
+  # That surface is the API document the contract block combined, when there is one, and
+  # the feature's API plan it was drafted from; the backend plan is never in context here.
   - id: ctx_frontend
     condition: "{{fe_mode}} == bootstrap"
     action: build_context
@@ -1667,7 +1697,8 @@ workflow:
       - { path: "{{fe_plan}}" }
       - { path: "{{domain_model}}", optional: true }   # the UBIQUITOUS LANGUAGE this lane's labels, states and messages use — and what a cited BR-nnn requires
       - { path: .appweaver/memory/constitution.ui.md, optional: true }   # the lane's ratified UX-* base — conventions, forbidden patterns, gates
-      - { path: "{{contract_doc}}", optional: true }   # the combined API document — the service as built, plus drafted operations it does not serve yet
+      - { path: "{{contract_doc}}", optional: true }   # the combined API document — every operation the API plans publish, with the open changes applied
+      - { path: "{{api_plan}}", optional: true }       # the feature's API plan — the endpoint blocks the document is drafted from, and the answers to this plan's requests
   - id: gen_frontend
     condition: "{{fe_mode}} == bootstrap"
     action: agent_generate
@@ -1761,15 +1792,24 @@ workflow:
           semantics and rollback each row states.
         • §6 — the cross-cutting decisions as code: what is hidden vs disabled,
           accessibility obligations, localization, performance and offline behaviour.
-      - THE SERVICE'S API DOCUMENT IS THE CONTRACT. API document: {{contract_status}}.
+      - THE API DOCUMENT IS THE CONTRACT. API document: {{contract_status}}.
         Each §5 row names its endpoint by Operation id; find that operation in the
         document and take EVERYTHING about the call from it — route, verb, path and query
         parameters, request and response field names and their casing, status codes and
         error codes. Never take a route, a field name or a paging convention from memory,
-        from convention or from the loaded standards' examples: the document is what the
-        service answers. An operation marked `x-aw-draft` is one the backend plan
-        describes and the service does not serve yet: bind to it exactly like any other,
-        through the client, and never stub, mock or fake its response in production code.
+        from convention or from the loaded standards' examples: the document is drafted
+        from the API plans, and the service is checked against it. This feature's
+        api-plan.md is in context too where it has one — the endpoint blocks the document
+        was drafted from, and the answers to this plan's contract requests. Read it for
+        what a block states that the document cannot carry, such as when each error is
+        returned; where the two differ on a route, verb, field or status, follow the
+        document, which the client was generated from. Bind to every
+        operation in it the same way, through the client, and never stub, mock or fake a
+        response in production code — also one marked `x-aw-unserved` (planned, not served
+        yet) or `deprecated` (an open change removes it: bind to it only where the plan
+        says to, and say so in your summary). An id in the document's `x-aw-removed` list
+        is one an open change removes and has replaced on its route: it is not in the
+        client, so its row is a broken binding (below) — name that change when you report it.
       - A BINDING THAT WAITS ON AN OPEN CONTRACT REQUEST (open now: [{{req_open_csv}}]) is
         not broken: its operation is in no document because the backend has not answered. Realise
         the screen or component in full, write nothing that pretends to call the service
@@ -1785,7 +1825,10 @@ workflow:
       - Author a paired test for every screen, interaction and state the plan names —
         including the unwanted-behaviour states from §4 and an accessibility assertion per
         interactive surface — and cite the spec id (UX-/US-/FR-/CN-/DC-/IC-/SC-) from the
-        plan's §7 Traceability in each test. A snapshot alone is not a test.
+        plan's §7 Traceability in each test. A snapshot alone is not a test. THE CITATION IS
+        CHECKED: analyze-slice fails a slice in which some FR- or BR- of §7 is named by no
+        test — written as `FR-004`, `FR_004` or `FR004` in the test's name, a comment, an
+        attribute or a tag.
       - Do NOT add behaviour the plan does not state, and do NOT omit any it does. If the
         plan looks wrong or incomplete, STOP and surface it (it is fixed in plan /
         analyze-plan) — never compensate from the spec or from memory.
@@ -1820,7 +1863,9 @@ workflow:
       - { path: "{{frontend_plan}}", optional: true } # the master plan — READ ONLY, never amended here
       - { path: "{{domain_model}}", optional: true }  # the master model — the ubiquitous language as it stands BEFORE this change
       - { path: .appweaver/memory/constitution.ui.md, optional: true }
-      - { path: "{{contract_doc}}", optional: true }  # the combined API document — the service as built, plus drafted operations it does not serve yet
+      - { path: "{{contract_doc}}", optional: true }  # the combined API document — every operation the API plans publish, with the open changes applied
+      - { path: "{{delta_api_plan}}", optional: true } # this change's API delta — its Contract deltas table and the endpoints it writes whole
+      - { path: "{{api_plan}}", optional: true }      # the feature's API plan — the endpoints as they stand BEFORE this change
   - id: gen_frontend_delta
     condition: "{{fe_mode}} == delta"
     action: agent_generate
@@ -1897,16 +1942,21 @@ workflow:
         A new interaction without them is an incomplete implementation, not a later
         refinement.
       - BIND AGAINST THE PUBLISHED SURFACE ONLY: the delta plan's binding rows and the
-        service delta's "Contract deltas for the frontend lane" table as the delta plan
-        cites them. Generate no server-side behaviour, no persistence and no business rule
+        change's API delta — the "Contract deltas for the frontend lane" table of
+        delta-api-plan.md, in context where the change has one — as the delta plan cites
+        them. Generate no server-side behaviour, no persistence and no business rule
         evaluation.
-      - THE SERVICE'S API DOCUMENT IS THE CONTRACT. API document: {{contract_status}}.
+      - THE API DOCUMENT IS THE CONTRACT. API document: {{contract_status}}.
         Each binding row leads with its endpoint's operation id; find that operation in
         the document and take EVERYTHING about the call from it — route, verb, path and
         query parameters, request and response field names and their casing, status
         codes and error codes — never from memory, convention or the standards' examples.
-        An operation marked `x-aw-draft` is planned and not served yet: bind to it through
-        the client like any other, and never stub, mock or fake its response.
+        It carries this change's own API changes over the master's. The feature's
+        api-plan.md and this change's delta-api-plan.md, in context where they exist, are
+        what it was drafted from: read them for what a block states that the document
+        cannot carry, and follow the document where they differ. Bind to every
+        operation through the client the same way — also one marked `x-aw-unserved`
+        (planned, not served yet) — and never stub, mock or fake its response.
         A binding whose id the document does not have is broken: leave that call unbound,
         report the element `blocked` naming the id, and never guess a substitute.
       - THE CLIENT: {{client_status}}. The client lives in this lane's client layer; a
@@ -1916,6 +1966,9 @@ workflow:
         interactive surface, citing the requirement id THE DELTA PLAN NAMES for that row
         (UX-/US-/FR-/CN-/DC-/IC-/SC-). The spec is not in context: take the id from the
         plan and cite it verbatim. A row that names no id is a planning gap — surface it.
+        THE CITATION IS CHECKED: analyze-slice-delta fails the lane when some FR- or BR- the
+        delta plan rows serve is named by no test (`FR-004`, `FR_004` or `FR004`, in the
+        test's name, a comment, an attribute or a tag).
       - REGRESSION: for each element in the delta plan's regression targets, verify (add or
         adjust a test where needed) that the existing behaviour still holds after a shared
         component or state container changed — but do NOT rewrite that behaviour.
@@ -2150,13 +2203,13 @@ outputs:
   cr_id: "{{active_change}}"
   backend_implemented: "{{be_go}}"
   backend_plan: "{{be_plan}}"          # the document the backend lane generated FROM
+  api_plan: "{{be_api_doc}}"           # the API plan it served — empty where that plan carries its own API section
   backend_files: "{{be_files}}"
   frontend_implemented: "{{fe_go}}"
   frontend_plan: "{{fe_plan}}"         # the document the frontend lane generated FROM
   frontend_files: "{{fe_files}}"
-  api_document: "{{export_doc}}"       # exported from the service in this run (backend lane) — commit it, it is how the frontend developer receives the surface
-  frontend_api_document: "{{contract_doc}}"   # what the frontend bound to: the export plus the drafted operations it does not serve yet (not committed)
-  contract_requests: "{{req_summary}}" # the frontend plan's RQ-n requests and the backend plan's answers
+  frontend_api_document: "{{contract_doc}}"   # what the frontend bound to: every operation the API plans publish, with the open changes applied (not committed)
+  contract_requests: "{{req_summary}}" # the frontend plan's RQ-n requests and the API plan's answers
   # Every plan element realised, per lane — `true` for a lane that did not generate.
   # `*_completion_pass` says whether the first pass left gaps a second one had to close.
   # `*_outcome` is the one word for what the lane did: complete (it generated and every
@@ -2192,5 +2245,5 @@ outputs:
   frontend_plan_gate_at: "{{fe_gate_at}}"
   frontend_plan_gate_verdict: "{{fe_gate_verdict}}"
   frontend_plan_gate_routed_to_specify: "{{fe_gate_routed_csv}}"
-  note: "Lanes come from .appweaver/stacks.json, and the ones you work on from .appweaver/lane.json (`{{working_lane}}`) — backend declared {{be_declared}} (worked {{be_working}}, ready {{be_runnable}}, implemented {{be_go}}), frontend declared {{fe_declared}} (worked {{fe_working}}, ready {{fe_runnable}}, implemented {{fe_go}}). A declared lane you do not work on is left to its developer and is not reported here. A declared lane that was skipped printed its reason above and did not stop the other one; an undeclared lane produces nothing and that is not a failure. Each generating lane read its PLAN for what to build and {{domain_model}} for what the domain is — plus {{delta_model}} on the delta path, since the master model does not carry the change until finalize-delta merges it. Every one of those documents was READ and none was written: this phase generates code and nothing else. Each lane's outcome is backend={{be_outcome}}, frontend={{fe_outcome}} — `already-implemented` means the lane wrote no files because every plan element was already realised in its lane root folder, which is the correct result of re-running implement on a finished feature and not a failure. On the bootstrap path each working lane's plan was checked against that lane's analyze-plan receipt before anything generated (backend tracked={{be_gate_tracked}}, fresh={{be_gate_fresh}}, gated {{be_gate_at}}; frontend tracked={{fe_gate_tracked}}, fresh={{fe_gate_fresh}}, gated {{fe_gate_at}}) — tracked=false means that lane has never passed analyze-plan since the gate began recording what it proved, which is an unknown rather than a stale plan and blocks nothing; run /appweaver analyze-plan once to start the record."
+  note: "Lanes come from .appweaver/stacks.json, and the ones you work on from .appweaver/lane.json (`{{working_lane}}`) — backend declared {{be_declared}} (worked {{be_working}}, ready {{be_runnable}}, implemented {{be_go}}), frontend declared {{fe_declared}} (worked {{fe_working}}, ready {{fe_runnable}}, implemented {{fe_go}}). A declared lane you do not work on is left to its developer and is not reported here. A declared lane that was skipped printed its reason above and did not stop the other one; an undeclared lane produces nothing and that is not a failure. Each generating lane read its PLAN for what to build — the backend lane with the API plan beside it, where there is one ({{be_api_doc}}) — and {{domain_model}} for what the domain is — plus {{delta_model}} on the delta path, since the master model does not carry the change until finalize-delta merges it. Every one of those documents was READ and none was written: this phase generates code and nothing else. Each lane's outcome is backend={{be_outcome}}, frontend={{fe_outcome}} — `already-implemented` means the lane wrote no files because every plan element was already realised in its lane root folder, which is the correct result of re-running implement on a finished feature and not a failure. On the bootstrap path each working lane's plan was checked against that lane's analyze-plan receipt before anything generated (backend tracked={{be_gate_tracked}}, fresh={{be_gate_fresh}}, gated {{be_gate_at}}; frontend tracked={{fe_gate_tracked}}, fresh={{fe_gate_fresh}}, gated {{fe_gate_at}}) — tracked=false means that lane has never passed analyze-plan since the gate began recording what it proved, which is an unknown rather than a stale plan and blocks nothing; run /appweaver analyze-plan once to start the record."
   next: "This run was mode `{{mode}}`, change `{{active_change}}` (empty on the bootstrap path). BOOTSTRAP → /appweaver build → analyze-slice → run. DELTA → /appweaver build → analyze-slice-delta {{active_change}} → finalize-delta → analyze-slice → close-delta, with the change still OPEN throughout — compile first, then analyze-slice-delta verifies that every element the delta plans marked ADDED or MODIFIED is actually in the code with a paired test (the gate that catches a lane you declined at the prompt above), then finalize-delta merges it into spec.md + the context's domain-model.md while leaving it open, analyze-slice verifies the slice against those merged masters while a red result is still recoverable, and close-delta LAST archives the change and bumps the version."