aw-spec-cli 0.1.15 → 0.1.17

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

@@ -1,57 +1,104 @@
 # =============================================================================
-# aw-spec-implement (orchestrator) — code generation from ONE STORY'S DESIGN
+# aw-spec-implement (orchestrator) — code generation from the LANE PLANS, BOTH LANES
 #
-# The executable end of the story loop: GENERATE the service lane's source files and
-# paired tests for ONE STORY, strictly from the LATEST design pass in that story's own
-# service design — specs/<F>/stories/<ID>/story-backend-plan.md.
+# 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>/frontend-plan.md  when a FRONTEND lane is declared
 #
-# IT BUILDS A SLICE, NOT A FEATURE. The old contract generated the whole aggregate from
-# the feature design every run, which is only correct once: the second run rewrites the
-# first story's code from a document that has since moved. A story design names the
-# files it changes, so this phase edits an existing tree — creating only what the pass
-# says is new — and its OKF write is a MERGE, never a replace.
+# THE LANES COME FROM stacks.json, NOT FROM A FLAG — select-stack is the sole writer of
+# the declaration, and this phase implements whichever lanes are there: backend only,
+# frontend only, or both. It absorbs the former `implement-ui` and `implement-delta`
+# commands, exactly as `plan` absorbed `design-ui` and the delta-design module.
 #
-# DESIGN-ONLY, AND THE DESIGN IS THE STORY'S. spec.md is deliberately NOT a generation
-# input: generating from the spec routes around every gate between them and makes the
-# design advisory without anyone deciding that it should. The spec appears once, AFTER
-# the code exists, in a read-only acceptance check that reports and never repairs.
+# SELF-DETECTING, off the CHANGES ON DISK (symmetric with how `plan` keys off the plan
+# documents' own existence):
+#   • BOOTSTRAP (no change open) → generate from the MASTER plans.
+#     Next: /appweaver build → analyze-slice.
+#   • DELTA (one or more changes/<CR-id>/ open) → ASK WHICH ONE, activate it, and
+#     generate ONLY what that change's delta plans mark ADDED / MODIFIED, into the
+#     tree that is already there. The masters are the BASE, read and never written.
+#     A bare CR id in the argument selects without a prompt; a feature with exactly one
+#     open change auto-confirms. Next: build → analyze-slice-delta (which verifies that
+#     what was planned was actually built, before the merge) → finalize-delta →
+#     analyze-slice → close-delta.
+# "The most recently opened" is a guess that is wrong the moment two people work in
+# parallel, so the change is CHOSEN and then ACTIVATED (cr-activate) — every stage after
+# this one still resolves "the" change through active_version.json.active_change.
 #
-# THE LATEST PASS WINS, AND A HAND EDIT TO IT IS HONOURED. Passes append; earlier ones
-# are superseded history. The pass this run builds from is named in the prompt and in
-# the outputs, so "which design produced this code" has one answer.
+# EACH LANE IS GATED ON ITS OWN, AND A LANE'S GAP IS NOT THE RUN'S. A declared lane needs
+# two things before it can generate: the plan for THIS run (its master plan, or this
+# change's delta plan) and a scaffolded project under the source path it declares. A lane
+# that is missing either is REPORTED with the fix named and SKIPPED — the other lane still
+# runs. Failing the whole command for the frontend's sake is how a backend that was ready
+# goes unbuilt; failing silently is how a frontend that was never generated reports green.
+# Only when NO lane can run does the phase stop, naming every reason it collected.
 #
-# INPUT CHANNELS, each with one job:
-#   story-backend-plan.md   the LATEST pass = the complete WHAT for this slice
-#   stories/<ID>.md         the story's acceptance criteria — what "done" means
-#   current code (OKF)      what EXISTS, per lane, so this run edits rather than recreates
-#   interfaces.md           the PUBLISHED surface the generated code must match
-#   adr.md                  what was DECIDED — binding unless a pass supersedes it
-#   constitution + rules    HOW to build it (stack, layout, standards)
-# backend-plan.md is NOT a generation input. The pass was designed inside it and is the
-# concrete form of it; re-reading the plan here would let code drift from the pass back
-# toward the architecture, with no gate between the two. It is read for two DERIVED
-# facts only — the aggregate's cross-slice edges and its Overview prose — both of which
-# are feature-level properties no single story can state.
+# IT ASKS BEFORE IT WRITES. Generation is the expensive, side-effecting step of the
+# 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.
 #
-# GATES (all loud, all before any write): the service lane declared with its source path;
-# a scaffolded project under that path; an active feature; an OPEN story; and that story
-# having a service design at all. A design behind the current spec, or a story the spec
-# has moved past, is ANNOUNCED — never refused: the story is legitimately in flight, and
-# the spec may have moved on ids it does not carry. The route out of both is named.
+# 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,
+# authoritative source for WHICH elements exist, where each lives and what surface they
+# publish, and anything missing from it is fixed in `plan`, never compensated for here.
+# But since the model split a plan CITES an invariant by id and never restates it, so the
+# bounded context's domain-model.md is in context too, as the authority on the entity
+# names, the aggregate boundary, the lifecycle states and the TEXT of every BR-nnn the plan
+# cites. The plan names the PLACE a rule is enforced; the model states the RULE.
+#   ON THE DELTA PATH THE MODEL ARRIVES IN TWO HALVES — the master, plus that change's
+#   domain-model.<CR-id>.delta.md — and the effective model is the two read together, the
+#   delta winning where they differ. It has to be, because finalize-delta merges the model
+#   AFTER this phase: at generation time the master does not yet carry the change, and a
+#   generator reading only the master would build the change's code against the pre-change
+#   rules. No OTHER change's pending delta is loaded: a predecessor was already accounted
+#   for when the delta plan was authored, and reaching for one here would implement a
+#   change that has not landed.
+#   THE MODEL IS READ, NEVER MINED FOR WORK. It describes the whole bounded context while a
+#   run builds one feature, so an entity or invariant in it that no plan element realises is
+#   a PLANNING gap to surface — not work to invent here.
 #
-# Launch:  /appweaver implement [<story-id>] [guidance]     (asks when ambiguous)
-# Prereq:  /appweaver story-plan (the story's design)  ·  Next: /appweaver build
+# THE STACK BINDS HERE. The plans are technology-agnostic — a component is a
+# responsibility, a contract is a set of field shapes. The language, framework, router,
+# state library, component library and styling approach come from the lane declaration +
+# the constitution halves + this phase's rule sets. Each lane takes its rules from its own
+# heading of tech-rule-bindings, and the frontend set is loaded only when that lane runs,
+# so a backend-only project sees exactly the rules it did before:
+#   • BACKEND  — `## /aw-spec-implement` on the bootstrap path, `## /aw-spec-implement-delta`
+#     on the delta path. Keyed by MODE, which is what the two commands did separately, so
+#     no project's rule set changes by being merged into one command.
+#   • FRONTEND — `## /aw-spec-implement-ui`, both paths. There was never a delta heading
+#     for this lane because the delta half of it was never built; it is built here.
+#
+# ONE SUBTREE PER LANE. Each lane owns the source path stacks.json declares for it and
+# writes nothing outside it. A file written elsewhere belongs to the other lane or to no
+# lane at all, and the project gate is deliberately stricter for the frontend: a manifest
+# found only elsewhere in the repository is the service lane's, and accepting it is how a
+# frontend that was never scaffolded is generated into anyway and reports green.
+#
+# WHAT IT DOES NOT DO. It never writes spec.md, a master plan or the domain model, and it
+# never closes a change — finalize-delta merges the change's spec and model halves,
+# analyze-slice verifies the slice, and close-delta archives it and bumps the version.
+#
+# Prereqs: /appweaver plan (+ analyze-plan, or analyze-plan-delta for a change), and a
+# project scaffolded under each lane's source path — this phase GENERATES into that tree,
+# so with no project there is nowhere to place the files. /appweaver foundation unpacks one
+# where a bundle ships for the stack; a stack with no bundle scaffolds with its own tooling
+# instead, and the gate accepts either, since it tests for a project rather than a bundle.
+#
+# Launch:  /appweaver implement [guidance]
+#          /appweaver implement CR-20260910-…   (implement THAT open change, no prompt)
 # =============================================================================
 
 name: aw-spec-implement
-description: "Generate the service lane's source files and paired tests for ONE STORY, strictly from the LATEST design pass in stories/<ID>/story-backend-plan.md, bound to the declared backend stack and written only under that lane's source path. Model-driven and design-only — the spec is never a generation input; it appears once afterwards in a read-only acceptance check that reports and never repairs. Incremental by contract: it edits the feature's existing tree, creating only what the pass names as new, and MERGES the files it wrote into the feature's OKF concept rather than replacing the list."
+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 it generates from the master plans; with one or more open it ASKS which change and generates only what that change's delta plans mark ADDED or MODIFIED, leaving the masters untouched. Every lane is gated on its own plan and its own scaffolded project, and a lane missing either 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.0.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
 inputs:
   user_input:
-    description: Optional story id and/or implementation guidance (e.g. "Order-001 keep the mapper hand-written").
+    description: "Optional implementation guidance (focus area, stack hints). On the delta path a bare CR id selects which open change to implement."
     required: false
     bind: USER_INPUT
 
@@ -63,400 +110,810 @@ scripts:
     sh:  .appweaver/scripts/bash/aw-xref.sh
     ps1: .appweaver/scripts/powershell/aw-xref.ps1
 
-# Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). The FRAMEWORK /
-# code-generation rule files are CONFIGURATION, loaded per-command from
-# guardrails/projects/<project>/tech-rule-bindings.md under "## /aw-spec-implement" by
-# the tech-select module. Per the rule-partition this phase loads NO domain rule file —
-# the domain reached it through spec → feature plan → the story's design pass. The
-# architecture principles arrive via constitution.technical.md (referred to directly,
-# as-is — NOT mapped). Component rule docs are NOT loaded here: implement codes against
-# a component's PORT, and installing the component is /appweaver add-component.
+# Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). Each lane's
+# FRAMEWORK / code-generation rule files are CONFIGURATION, loaded per-lane from
+# guardrails/projects/<project>/tech-rule-bindings.md by the tech-select module (see the
+# tech_select steps below). Per the rule-partition this phase loads NO domain rule file —
+# everything domain reached the code through spec → plan. The architecture and UX bases
+# arrive via constitution.technical.md / constitution.ui.md (referred to directly, as-is —
+# NOT mapped); the structure via the lane plans. Component rule docs are NOT loaded here:
+# this phase codes against a component's PORT, and installing the component itself is a
+# separate step, /appweaver add-component. (missing files skipped at assembly time)
 standards:
   - { path: .appweaver/ai-rules.md }   # kit-resident: the universal operating rules, every flow
 
 vars:
-  feature_dir: ""
-  spec_file: ""
+  # WHICH RUN THIS IS. bootstrap = generate from the masters; delta = generate one open
+  # change's delta plans. Decided by the changes on disk, not by a flag.
+  mode: "bootstrap"
+  has_changes: "false"
+  cr_choice: ""
+  active_change: ""
+  cr_dir: ""
+  delta_spec: ""
+  delta_model: ""
+  delta_model_exists: "false"
+  delta_backend_plan: ""
+  delta_backend_plan_exists: "false"
+  delta_frontend_plan: ""
+  delta_frontend_plan_exists: "false"
+  wave: ""
+  # PER-LANE STATE. Each lane resolves its own plan, its own project and its own answer;
+  # a lane that is not declared never resolves any of them and its steps never run.
+  # The engine has no compound conditions, so each AND is an ordered assignment: a step
+  # conditioned on one fact assigning the value of the other.
   be_plan: ""
-  be_plan_exists: "false"
-  # story resolution
-  any_open: "false"
-  open_ids: "[]"
-  digest: ""
-  resolved: "false"
-  needs_pick: "false"
-  pick_reason: ""
-  picked_story: ""
-  story: ""
-  story_path: ""
-  story_open: "false"
-  status_msg: ""
-  story_title: ""
-  exercises_csv: ""
-  constraints_csv: ""
-  current_version: ""
-  stale_csv: ""
-  stale_note: ""
-  story_dir: ""
-  adr_path: ""
-  if_path: ""
-  # the story's SERVICE design
-  design_doc: ""
-  design_exists: "false"
-  design_pass: "0"
-  design_spec_version: ""
-  design_stale: "false"
-  # the feature's current code, per lane (OKF)
-  okf_concept: ""
-  coverage_digest: ""
-  be_source_csv: ""
-  be_source_count: "0"
-  fe_source_count: "0"
-  # generation + enrichment
-  files: ""
-  xref_wrote: ""
-  xref_edge_count: "0"
-  okf_overview: ""
-  accept_ok: "true"
-  accept_gaps: ""
-  accept_note: ""
+  be_plan_ok: "false"
+  be_project_ok: "false"
+  be_project_scope: ""
+  be_runnable: "false"
+  be_answer: ""
+  be_go: "false"
+  be_mode: "skip"              # skip | bootstrap | delta
+  be_files: []
+  fe_plan: ""
+  fe_plan_ok: "false"
+  fe_project_ok: "false"
+  fe_project_scope: ""
+  fe_runnable: "false"
+  fe_answer: ""
+  fe_go: "false"
+  fe_mode: "skip"              # skip | bootstrap | delta
+  fe_files: []
+  generate_any: "false"
+  record_edges: "false"
+  overview_ok: "false"
+  domain_model: ""
+  domain_model_exists: "false"
+  # The backend lane's rule-set heading, keyed by MODE — see the header. The frontend
+  # lane's is the same on both paths, so it is written inline at its include.
+  be_tech_command: "aw-spec-implement"
+  # HOOK PHASES. The merged command fires the phase of every branch it actually takes, so
+  # an extensions.yml wired to any of the three former commands keeps working:
+  # before/after_implement always, the _ui pair when the frontend lane generates, the _cr
+  # pair on the delta path. A branch not taken passes the base phase again, and
+  # resolve-hooks merges its phases and dedups by command, so the repeat adds nothing.
+  pre_ui_phase: "before_implement"
+  pre_cr_phase: "before_implement"
+  post_ui_phase: "after_implement"
+  post_cr_phase: "after_implement"
 
 workflow:
 
-  # 0. TECHNICAL rule files → sticky standards (configuration, not hardcoded).
-  #    No blocking gate: an unconfigured project soft-continues, because
-  #    constitution.technical.md still carries the technology base.
-  - id: tech_select
-    action: include
-    module: .appweaver/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-implement }
-
-  # 1. The active feature. spec.md and backend-plan.md are resolved here but neither is
-  #    a generation input — see the header for what each is actually used for.
+  # 0. THE LANE MODEL. lane-verify with NO --require, because this phase requires neither
+  #    kind: a backend-only and a frontend-only project are both correct states, and which
+  #    lanes exist is exactly what it is here to find out. It still reports every DECLARED
+  #    lane whose source path is empty, missing or overlapping another's — a stack named
+  #    against a path that is not there is a mistake in a phase that writes code — and it
+  #    always exits 0, so the reason reaches the gate below as text.
+  - id: lane_verify
+    action: execute_script
+    on_error: continue
+    script: { ref: actions }
+    subcommand: lane-verify
+    args: ["--command", "/appweaver implement"]
+    outputs:
+      - { name: lane_ok,        from: "$.ok" }
+      - { name: lane_issues,    from: "$.message" }
+      - { name: be_declared,    from: "$.backend_declared" }
+      - { name: be_lane_id,     from: "$.backend_lane_id" }
+      - { name: be_source_path, from: "$.backend_source_path" }
+      - { name: be_profile,     from: "$.backend_profile" }
+      - { name: be_title,       from: "$.backend_title" }
+      - { name: be_language,    from: "$.backend_language" }
+      - { name: be_ecosystem,   from: "$.backend_ecosystem" }
+      - { name: be_build,       from: "$.backend_build" }
+      - { name: be_test,        from: "$.backend_test" }
+      - { name: fe_declared,    from: "$.frontend_declared" }
+      - { name: fe_lane_id,     from: "$.frontend_lane_id" }
+      - { name: fe_source_path, from: "$.frontend_source_path" }
+      - { name: fe_profile,     from: "$.frontend_profile" }
+      - { name: fe_title,       from: "$.frontend_title" }
+      - { name: fe_language,    from: "$.frontend_language" }
+      - { name: fe_ecosystem,   from: "$.frontend_ecosystem" }
+      - { name: fe_build,       from: "$.frontend_build" }
+      - { name: fe_test,        from: "$.frontend_test" }
+
+  - id: require_lanes
+    action: verify_context
+    require_true: lane_ok
+    on_false: stop
+    on_false_message: >
+      /appweaver implement cannot run — {{lane_issues}}
+      The lane model in .appweaver/stacks.json is what tells this phase which subtree it
+      owns, what language to generate and what to compile. Declaring it is the first step
+      of both the greenfield and the brownfield sequence.
+
+  # 1. The current feature and its MASTER documents. The plans resolve under their legacy
+  #    names too (design.md / design.ui.md), so a feature authored before the lane split
+  #    is implemented from the document that is actually on disk.
   - id: feature_paths
     action: execute_script
     on_error: continue      # never crash raw on 'no feature set' — the gate below explains it
     script: { ref: actions }
     subcommand: feature-paths
     outputs:
-      - { name: feature_dir,    from: "$.feature_dir" }
-      - { name: spec_file,      from: "$.spec_file" }
-      - { name: be_plan,        from: "$.backend_plan_file" }
-      - { name: be_plan_exists, from: "$.backend_plan_exists" }
+      - { name: feature,             from: "$.feature" }
+      - { name: feature_dir,         from: "$.feature_dir" }
+      - { name: backend_plan,        from: "$.backend_plan" }
+      - { name: backend_plan_exists, from: "$.backend_plan_exists" }
+      - { name: frontend_plan,       from: "$.frontend_plan" }
+      - { name: frontend_plan_exists, from: "$.frontend_plan_exists" }
+
   - id: require_feature
     action: verify_context
     require_non_empty: feature_dir
     on_empty: stop
     on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the aggregate, e.g. Order), then re-run implement."
 
-  # 2. WHICH STORY. Same resolution story-plan uses: an explicit id in the input wins,
-  #    anything else (nothing named, an unknown id, several) becomes a pick from the open
-  #    backlog. One scan returns every fact the gates below read.
-  - id: story_scan
+  # The bounded context's DOMAIN MODEL — in every generating lane's payload as the authority
+  # on what the plan's cited BR-nnn actually require and on the ubiquitous language, and the
+  # source of the OKF concept Overview at the end. On the delta path it is joined by that
+  # change's own model delta, which cr-paths resolves. See the header.
+  - id: context_paths
     action: execute_script
+    on_error: continue
     script: { ref: actions }
-    subcommand: story-plan-check
-    args: ["--feature-dir", "{{feature_dir}}", "--input", "{{USER_INPUT}}"]
+    subcommand: context-paths
     outputs:
-      - { name: any_open,            from: "$.any_open" }
-      - { name: open_ids,            from: "$.open_ids" }
-      - { name: digest,              from: "$.digest" }
-      - { name: resolved,            from: "$.resolved" }
-      - { name: needs_pick,          from: "$.needs_pick" }
-      - { name: pick_reason,         from: "$.pick_reason" }
-      - { name: story,               from: "$.story" }
-      - { name: story_path,          from: "$.story_path" }
-      - { name: story_open,          from: "$.story_open" }
-      - { name: status_msg,          from: "$.status_msg" }
-      - { name: story_title,         from: "$.story_title" }
-      - { name: exercises_csv,       from: "$.exercises_csv" }
-      - { name: constraints_csv,     from: "$.constraints_csv" }
-      - { name: current_version,     from: "$.current_version" }
-      - { name: stale_csv,           from: "$.stale_csv" }
-      - { name: stale_note,          from: "$.stale_note" }
-      - { name: story_dir,           from: "$.story_dir" }
-      - { name: adr_path,            from: "$.adr_path" }
-      - { name: if_path,             from: "$.if_path" }
-      - { name: design_doc,          from: "$.be_doc_path" }
-      - { name: design_exists,       from: "$.be_doc_exists" }
-      - { name: design_pass,         from: "$.be_last_pass" }
-      - { name: design_spec_version, from: "$.be_doc_spec_version" }
-      - { name: design_stale,        from: "$.be_doc_stale" }
-  - id: require_open_backlog
-    action: verify_context
-    require_true: any_open
-    on_false: stop
-    on_false_message: "No open stories for this feature — there is nothing to implement. Stories are minted by /appweaver specify (bootstrap) and /appweaver sync-stories (when the spec moves)."
-  - id: ask_story
-    condition: "{{needs_pick}} == true"
-    action: ask
-    prompt: |
-      Which story is this implementation for? ({{pick_reason}})
-
-      {{digest}}
-    options_from: "{{open_ids}}"
-    answer_key: picked_story
-    answer_var: picked_story
-  - id: story_pick_check
-    condition: "{{needs_pick}} == true"
+      - { name: context,             from: "$.context" }
+      - { name: domain_model,        from: "$.domain_model" }
+      - { name: domain_model_exists, from: "$.domain_model_exists" }
+
+  # 2. WHICH CHANGES ARE OPEN — the evidence is changes/<CR-id>/ on disk; a closed change
+  #    has moved to changes/archive/. Any open change makes this run a DELTA run.
+  #    `matched_label` resolves a CR id passed as the argument to the whole option string,
+  #    so the pick below can auto-select it (the engine matches a preselection against the
+  #    option text exactly).
+  - id: cr_list
     action: execute_script
     script: { ref: actions }
-    subcommand: story-plan-check
-    args: ["--feature-dir", "{{feature_dir}}", "--story", "{{picked_story}}"]
+    subcommand: cr-list
+    args: ["--feature-dir", "{{feature_dir}}", "--preselect", "{{USER_INPUT}}"]
     outputs:
-      - { name: resolved,            from: "$.resolved" }
-      - { name: story,               from: "$.story" }
-      - { name: story_path,          from: "$.story_path" }
-      - { name: story_open,          from: "$.story_open" }
-      - { name: status_msg,          from: "$.status_msg" }
-      - { name: story_title,         from: "$.story_title" }
-      - { name: exercises_csv,       from: "$.exercises_csv" }
-      - { name: constraints_csv,     from: "$.constraints_csv" }
-      - { name: stale_csv,           from: "$.stale_csv" }
-      - { name: stale_note,          from: "$.stale_note" }
-      - { name: story_dir,           from: "$.story_dir" }
-      - { name: design_doc,          from: "$.be_doc_path" }
-      - { name: design_exists,       from: "$.be_doc_exists" }
-      - { name: design_pass,         from: "$.be_last_pass" }
-      - { name: design_spec_version, from: "$.be_doc_spec_version" }
-      - { name: design_stale,        from: "$.be_doc_stale" }
-  - id: require_story
-    action: verify_context
-    require_true: resolved
-    on_false: stop
-    on_false_message: |
-      Could not resolve a story from '{{picked_story}}'. Open stories:
-      {{digest}}
-      Re-run implement naming one of them.
-  - id: require_open_story
-    action: verify_context
-    require_true: story_open
-    on_false: stop
-    on_false_message: "{{status_msg}}"
+      - { name: change_options, from: "$.select_options" }
+      - { name: matched_label,  from: "$.matched_label" }
+      - { name: has_changes,    from: "$.has_changes" }
+      - { name: change_count,   from: "$.count" }
+
+  - id: mode_delta
+    condition: "{{has_changes}} == true"
+    action: set
+    vars:
+      mode: "delta"
+      pre_cr_phase: "before_implement_cr"
+      post_cr_phase: "after_implement_cr"
+      be_tech_command: "aw-spec-implement-delta"
+
+  - id: pick_change
+    condition: "{{mode}} == delta"
+    action: user_select
+    prompt: "Which open change is being implemented? Deltas sharing a wave are independent; a higher wave is built on top of the lower ones, so implement those first."
+    options_from_variable: change_options
+    preselect_from: matched_label
+    single_option_confirm: true
+    outputs:
+      - { name: cr_choice, from: selection }
 
-  # 3. THE STORY MUST HAVE A SERVICE DESIGN. This phase generates from a design pass and
-  #    from nothing else, so an undesigned story has no input — and the fix is one
-  #    command, not a judgement call.
-  - id: require_design
-    action: verify_context
-    require_true: design_exists
-    on_false: stop
-    on_false_message: "Story {{story}} has no service design — {{story_dir}}/story-backend-plan.md does not exist. Run /appweaver story-plan {{story}} first: it designs the slice against the feature's backend plan, the current code and the published interfaces. implement generates from that pass and has no other input."
+  # 2a. Make the chosen change the ACTIVE one. build, finalize-delta, analyze-slice and
+  #     close-delta all still resolve the change through active_version.json.active_change,
+  #     so without this the code generated for CR-B would be merged and closed as CR-C.
+  - id: activate
+    condition: "{{mode}} == delta"
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-activate
+    args: ["--cr-id", "{{cr_choice}}", "--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: active_change, from: "$.active_change" }
 
-  # 3a. A design behind the spec is ANNOUNCED, not refused. The story is legitimately in
-  #     flight and the spec may have moved on ids it does not carry; stale_csv below is
-  #     the sharper signal, because it names only the ids THIS story actually carries.
-  - id: design_stale_notice
-    condition: "{{design_stale}} == true"
-    action: verify_context
-    require_value: design_stale
-    equals: "false"
-    on_mismatch: continue
-    on_mismatch_message: "Design pass {{design_pass}} was written against spec {{design_spec_version}} and the spec is now at {{current_version}}. Generating from it is not wrong — the move may not touch this story — but if it does, the code inherits a contract that no longer holds. Re-run /appweaver story-plan {{story}} to design against the current spec, or check the ids named below."
-  # stale_csv is a STRING, so require_value/equals compares cleanly and needs no
-  # condition. design_stale above is a JSON boolean, which require_value stringifies as
-  # 'True' — it can never equal 'false', so that one is gated by `condition:` and the
-  # value gate is only the vehicle that prints (law 43).
-  - id: story_stale_notice
-    action: verify_context
-    require_value: stale_csv
-    equals: ""
-    on_mismatch: continue
-    on_mismatch_message: "The spec has moved on ids THIS story carries: {{stale_csv}}. Whatever this run generates for them realises superseded wording. Consider /appweaver sync-stories to bring the backlog back in step, then /appweaver story-plan {{story}}, before building."
-
-  # 4. THE SERVICE LANE and its source path. This phase writes code, and the lane's root
-  #    is the only subtree it may write into — so this runs before the project gate,
-  #    which searches that subtree.
-  - id: lane_gate
-    action: include
-    module: .appweaver/orchestrator/modules/lane-gate.orch.yaml
-    with: { require: backend, command: "/appweaver implement" }
-
-  # 5. Require the PROJECT — a scaffolded, compiling tree. Implement GENERATES into it;
-  #    with no project there is nowhere to place the files. Deterministic structure gate:
-  #    searches the LANE'S OWN subtree for an ecosystem manifest, falling back to the
-  #    whole repo for the layout that keeps its manifest beside the lane root rather than
-  #    inside it. How the project got there is not asked.
-  - id: detect_foundation
+  # 2b. That change's documents. The picked value is a LABEL ("CR-… · wave 2 · title");
+  #     the scripts take its first token, and cr-paths reports the clean id back.
+  - id: cr_paths
+    condition: "{{mode}} == delta"
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-paths
+    args: ["--cr-id", "{{cr_choice}}", "--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: cr_id,                     from: "$.cr_id" }
+      - { name: cr_dir,                    from: "$.cr_dir" }
+      - { name: delta_spec,                from: "$.delta_spec" }
+      # THIS CHANGE'S MODEL HALF — the structure the delta plans realise. It is context for
+      # every generating lane, exactly as the master model is: the delta plan cites the
+      # invariants this change ADDS or CHANGES by id and never restates them either.
+      - { name: delta_model,               from: "$.delta_model" }
+      - { name: delta_model_exists,        from: "$.delta_model_exists" }
+      - { name: delta_backend_plan,        from: "$.delta_backend_plan" }
+      - { 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" }
+      - { name: wave,                      from: "$.wave" }
+
+  # 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.
+  - id: be_plan_bootstrap
+    condition: "{{mode}} == bootstrap"
+    action: set
+    vars: { be_plan: "{{backend_plan}}", be_plan_ok: "{{backend_plan_exists}}" }
+  - id: be_plan_delta
+    condition: "{{mode}} == delta"
+    action: set
+    vars: { be_plan: "{{delta_backend_plan}}", be_plan_ok: "{{delta_backend_plan_exists}}" }
+  - id: fe_plan_bootstrap
+    condition: "{{mode}} == bootstrap"
+    action: set
+    vars: { fe_plan: "{{frontend_plan}}", fe_plan_ok: "{{frontend_plan_exists}}" }
+  - id: fe_plan_delta
+    condition: "{{mode}} == delta"
+    action: set
+    vars: { fe_plan: "{{delta_frontend_plan}}", fe_plan_ok: "{{delta_frontend_plan_exists}}" }
+
+  # 4. THE PROJECT each declared lane generates INTO. Deterministic structure gate:
+  #    detect-project searches the LANE'S OWN subtree for an ecosystem manifest (.sln/
+  #    .csproj, pom.xml, build.gradle, package.json, go.mod, Cargo.toml, pyproject.toml),
+  #    falls back to the whole repo, and reports which scope answered. How the project got
+  #    there is not asked — `foundation` unpacked it, or the team scaffolded it with the
+  #    stack's own tooling.
+  - id: be_detect_project
+    condition: "{{be_declared}} == true"
+    action: execute_script
+    script: { ref: actions }
+    subcommand: detect-project
+    args: ["--root", "{{be_source_path}}"]
+    outputs:
+      - { name: be_project_ok,    from: "$.scaffolded" }
+      - { name: be_project_scope, from: "$.scope" }
+
+  # THE SCOPE DISTINCTION IS THE GATE FOR THE FRONTEND, and only for it. A repo-scope hit
+  # in a two-lane project is the service lane's manifest, and generating this lane's code
+  # against it is exactly the failure the lane model exists to prevent — a frontend that
+  # was never scaffolded, generated into anyway, reporting green. The service lane accepts
+  # either scope, because the layout that keeps a manifest beside the lane root rather than
+  # inside it is a normal one for it.
+  - id: fe_detect_project
+    condition: "{{fe_declared}} == true"
     action: execute_script
     script: { ref: actions }
     subcommand: detect-project
-    args: ["--root", "{{lane_source_path}}"]
+    args: ["--root", "{{fe_source_path}}"]
     outputs:
-      - { name: foundation_present, from: "$.scaffolded" }
-      - { name: project_markers,    from: "$.markers" }
-      - { name: project_scope,      from: "$.scope" }
-  - id: foundation_gate
+      - { name: fe_scaffolded,    from: "$.scaffolded" }
+      - { name: fe_project_scope, from: "$.scope" }
+  - id: fe_project_flag
+    condition: "{{fe_project_scope}} == lane"
+    action: set
+    vars: { fe_project_ok: "true" }
+
+  # 5. REPORT EACH DECLARED LANE'S GAPS AND CARRY ON. `on_false: continue` is the whole
+  #    point: the message is the deliverable, not the stop. A lane that cannot run is named
+  #    here with the command that fixes it, and the run continues so the other lane still
+  #    generates. If NOTHING can run, the gate at step 7 stops with that fact.
+  - id: warn_be_plan
+    condition: "{{be_declared}} == true"
     action: verify_context
-    require_true: foundation_present
+    require_true: be_plan_ok
+    on_false: continue
+    on_false_message: "BACKEND LANE SKIPPED — lane `{{be_lane_id}}` ({{be_title}}) is declared in .appweaver/stacks.json, but the plan this run generates from is not there: {{be_plan}}. Run /appweaver plan (then /appweaver analyze-plan for the masters, or /appweaver analyze-plan-delta for a change) and re-run implement. Nothing is generated for this lane; any other declared lane still runs."
+  - id: warn_be_project
+    condition: "{{be_declared}} == true"
+    action: verify_context
+    require_true: be_project_ok
+    on_false: continue
+    on_false_message: "BACKEND LANE SKIPPED — no project found under the {{be_lane_id}} lane's source path `{{be_source_path}}`, nor anywhere else in this repository. This phase GENERATES into an existing project tree, so one has to be scaffolded first: run /appweaver foundation <FoundationName> <AppName> where a foundation bundle ships for {{be_profile}}, or create the project with the stack's own tooling under that path. Any ecosystem manifest marks it — .sln/.csproj, pom.xml, build.gradle(.kts), package.json, go.mod, Cargo.toml or pyproject.toml."
+  - id: warn_fe_plan
+    condition: "{{fe_declared}} == true"
+    action: verify_context
+    require_true: fe_plan_ok
+    on_false: continue
+    on_false_message: "FRONTEND LANE SKIPPED — lane `{{fe_lane_id}}` ({{fe_title}}) is declared in .appweaver/stacks.json, but the plan this run generates from is not there: {{fe_plan}}. Run /appweaver plan (then /appweaver analyze-plan for the masters, or /appweaver analyze-plan-delta for a change) and re-run implement. Nothing is generated for this lane; any other declared lane still runs."
+  - id: warn_fe_project
+    condition: "{{fe_declared}} == true"
+    action: verify_context
+    require_true: fe_project_ok
+    on_false: continue
+    on_false_message: "FRONTEND LANE SKIPPED — no frontend project found under the {{fe_lane_id}} lane's source path `{{fe_source_path}}`. detect-project searched that subtree and then the whole repository, and answered at scope `{{fe_project_scope}}`; `lane` is the only scope this lane accepts. Scaffold a project there — /appweaver foundation <FoundationName> <AppName> where a bundle ships for {{fe_profile}}, or the stack's own tooling — and re-run implement. A manifest found elsewhere in the repository does NOT count: that one belongs to another lane, and generating this lane's code against it is how a frontend that was never built reports green."
+
+  # 6. RUNNABLE = declared AND its plan is there AND its project is there, as an ordered
+  #    assignment plus a knockdown, since the engine has no compound conditions. An
+  #    undeclared lane stays false either way — its `declared` value is what the raise
+  #    assigns.
+  - id: be_runnable_raise
+    condition: "{{be_plan_ok}} == true"
+    action: set
+    vars: { be_runnable: "{{be_declared}}" }
+  - id: be_runnable_clear
+    condition: "{{be_project_ok}} == false"
+    action: set
+    vars: { be_runnable: "false" }
+  - id: fe_runnable_raise
+    condition: "{{fe_plan_ok}} == true"
+    action: set
+    vars: { fe_runnable: "{{fe_declared}}" }
+  - id: fe_runnable_clear
+    condition: "{{fe_project_ok}} == false"
+    action: set
+    vars: { fe_runnable: "false" }
+
+  # 7. CONFIRM EACH RUNNABLE LANE. Generation writes into the repository and costs a model
+  #    pass per lane, so the operator says which lanes this run is for, with the stack, the
+  #    plan and the target subtree in front of them. Declining one lane leaves the other
+  #    free to run. A lane that is not runnable is never asked about — its reason was
+  #    already reported above.
+  - id: ask_backend
+    condition: "{{be_runnable}} == true"
+    action: ask
+    prompt: "Implement the BACKEND lane now? Lane `{{be_lane_id}}` — {{be_title}}, {{be_language}} ({{be_ecosystem}}) — generating from {{be_plan}} into {{be_source_path}}."
+    options: ["yes", "no"]
+    answer_var: be_answer
+  - id: be_go_set
+    condition: "{{be_answer}} == yes"
+    action: set
+    vars: { be_go: "{{be_runnable}}", generate_any: "true" }
+
+  - id: ask_frontend
+    condition: "{{fe_runnable}} == true"
+    action: ask
+    prompt: "Implement the FRONTEND lane now? Lane `{{fe_lane_id}}` — {{fe_title}}, {{fe_language}} ({{fe_ecosystem}}) — generating from {{fe_plan}} into {{fe_source_path}}."
+    options: ["yes", "no"]
+    answer_var: fe_answer
+  - id: fe_go_set
+    condition: "{{fe_answer}} == yes"
+    action: set
+    vars:
+      fe_go: "{{fe_runnable}}"
+      generate_any: "true"
+      pre_ui_phase: "before_implement_ui"
+      post_ui_phase: "after_implement_ui"
+
+  - id: require_a_lane
+    action: verify_context
+    require_true: generate_any
     on_false: stop
-    on_false_message: "No project found under the {{lane_id}} lane's source path `{{lane_source_path}}`, nor anywhere else in this repository. Implement GENERATES this story's code into an existing project tree, so one has to be scaffolded first: run /appweaver foundation <FoundationName> <AppName> where a foundation bundle ships for this stack, or create the project with the stack's own tooling under that path. Any ecosystem manifest marks it — .sln/.csproj, pom.xml, build.gradle(.kts), package.json, go.mod, Cargo.toml or pyproject.toml."
+    on_false_message: "Nothing to implement — no declared lane is both ready and confirmed. Either every declared lane was skipped for a reason printed above (its plan or its project is missing), or each one that was ready was declined at the prompt. Backend lane declared {{be_declared}}, ready {{be_runnable}}; frontend lane declared {{fe_declared}}, ready {{fe_runnable}}. Fix the reasons named above, or re-run and confirm a lane."
+
+  # 8. EACH GENERATING LANE'S authoring MODE — the run's mode where the lane is going, and
+  #    `skip` where it is not, which silences both of that lane's branches without a
+  #    compound condition.
+  - id: be_mode_set
+    condition: "{{be_go}} == true"
+    action: set
+    vars: { be_mode: "{{mode}}" }
+  - id: fe_mode_set
+    condition: "{{fe_go}} == true"
+    action: set
+    vars: { fe_mode: "{{mode}}" }
+
+  # 9. Each generating lane's code-generation rule files → sticky standards (configuration,
+  #    not hardcoded). Loaded only for a lane that is actually going to generate, and the
+  #    backend's heading is keyed by mode (see the header). No blocking gate: an
+  #    unconfigured project soft-continues, since the constitution halves still carry each
+  #    lane's ratified base.
+  - id: tech_select
+    condition: "{{be_go}} == true"
+    action: include
+    module: .appweaver/orchestrator/modules/tech-select.orch.yaml
+    with: { command: "{{be_tech_command}}" }
 
-  # 6. WHAT ALREADY EXISTS, from the feature's OKF concept, split by lane. This is what
-  #    makes the run incremental: the pass names the files it changes, and this names the
-  #    files that are there to change. Advisory — the first story of a greenfield feature
-  #    has no concept and generates into a clean tree.
-  - id: coverage
-    action: execute_script
-    on_error: continue
-    script: { ref: xref }
-    subcommand: concept-coverage
-    args: ["--feature-dir", "{{feature_dir}}", "--ids", "{{exercises_csv}}"]
-    outputs:
-      - { name: okf_concept,     from: "$.concept" }
-      - { name: coverage_digest, from: "$.digest" }
-      - { name: be_source_csv,   from: "$.backend_csv" }
-      - { name: be_source_count, from: "$.backend_count" }
-      - { name: fe_source_count, from: "$.frontend_count" }
+  - id: tech_select_ui
+    condition: "{{fe_go}} == true"
+    action: include
+    module: .appweaver/orchestrator/modules/tech-select.orch.yaml
+    with: { command: aw-spec-implement-ui }
 
-  # 7. Pre-execution hooks.
+  # 10. Pre-execution hooks — see the hook-phase vars above.
   - id: resolve_pre_hooks
     action: execute_script
     script: { ref: actions }
     subcommand: resolve-hooks
-    args: ["--phase", "before_implement"]
+    args: ["--phase", "before_implement", "--phase", "{{pre_ui_phase}}", "--phase", "{{pre_cr_phase}}"]
     outputs:
       - { name: before_hooks, from: "$.hooks" }
   - id: dispatch_pre_hooks
     action: dispatch_hooks
     hooks_from_variable: before_hooks
 
-  # ═══════════════════ GENERATION — one story's slice, from one pass ═══════════
-  # The pass constrains WHAT to build; the constitution, the lane and the loaded
-  # standards fix HOW. spec.md is deliberately absent: the design is the single source
-  # here, and the acceptance check below is where the spec gets its say.
-  - id: ctx_generate
+  # ═══════════ BACKEND LANE — bootstrap, generate from the MASTER plan ═════════
+  # The plan constrains WHAT to build; the constitution + the lane fix HOW. The spec is
+  # deliberately NOT in context — the plan is the single source here. build_context
+  # REPLACES the per-request envelope and PERSISTS, so each generating branch scopes its
+  # own; sticky standards stay prepended.
+  - id: ctx_backend
+    condition: "{{be_mode}} == bootstrap"
     action: build_context
-    vars:
-      story_id: "{{story}}"
-      story_title: "{{story_title}}"
-      exercises_csv: "{{exercises_csv}}"
-      constraints_csv: "{{constraints_csv}}"
-      pass_number: "{{design_pass}}"
-      coverage_digest: "{{coverage_digest}}"
-      source_files_csv: "{{be_source_csv}}"
-      source_file_count: "{{be_source_count}}"
-      stale_note: "{{stale_note}}"
     context:
-      - { path: "{{design_doc}}" }                   # the story's SERVICE design — the LATEST pass is the input
-      - { path: "{{story_path}}" }                   # the story's acceptance criteria — what "done" means
-      - { path: "{{if_path}}", optional: true }      # the PUBLISHED surface this code must match
-      - { path: "{{adr_path}}", optional: true }     # ratified decisions — binding unless a pass supersedes them
-      - { path: .appweaver/memory/constitution.technical.md, optional: true } # technology base ONLY — no domain
-  - id: generate
+      - { path: "{{be_plan}}" }
+      - { 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
+    condition: "{{be_mode}} == bootstrap"
     action: agent_generate
-    tools: "Read,Write,Edit"       # the existing code arrives as {{source_files_csv}} paths, not inlined
+    tools: "Read,Write,Edit"
     permission_mode: acceptEdits
     task: |
-      Implement story {{story_id}} — {{story_title}} — in the service lane, from
-      "## Design pass {{pass_number}}" of the story design in context. Guidance: {{USER_INPUT}}
-
-      THAT PASS IS THE ONLY SOURCE OF WHAT TO BUILD. It is the LAST pass in the
-      document; every earlier pass is superseded history, and any of them may carry
-      hand edits that were deliberate. Read the last one and build exactly it. Do NOT
-      consult or infer from spec.md — it is not in context on purpose: the design
-      already went through the gates that conform it, and generating from the spec
-      routes around all of them.
-
-      THIS IS ONE SLICE OF AN EXISTING FEATURE, NOT THE WHOLE FEATURE.
-      - The pass's "### Changes" section names, file by file, what to create and what
-        to modify. Create ONLY the files it names as new; modify the named existing
-        files IN PLACE. Every other file in this feature belongs to work that is
-        already done — do not regenerate, reformat or "tidy" it.
-      - The story delivers {{exercises_csv}} and must satisfy {{constraints_csv}}.
-        Anything outside those ids is another story's work, even if you can see it is
-        missing. If the slice genuinely cannot be built without touching shared
-        structure, make the smallest change that works and SAY SO in your summary.
-      - The code that already exists for this feature, per lane, is below. The service
-        files ({{source_file_count}} on disk) are yours to read before you edit; the UI
-        list is there so you do not change a surface that already has a client.
-
-      {{coverage_digest}}
-
-          {{source_files_csv}}
-
-      BIND THE STACK: this lane is `{{lane_id}}` — {{lane_title}}, language
-      {{lane_language}} ({{lane_ecosystem}}), declared in .appweaver/stacks.json and
-      compiled with `{{lane_build}}`, tested with `{{lane_test}}`. Generate in THAT
-      language and framework and no other, using its idioms, its project layout and its
-      test framework. Take persistence, messaging and the remaining technology choices
-      from the constitution's technology base + the loaded standards; the design is
-      technology-agnostic, so do not re-decide anything already fixed there. If the
-      loaded standards describe a DIFFERENT stack than the one above, the lane wins on
-      language and layout — follow the standards' INTENT and STOP to surface the
-      mismatch in your summary.
-
-      WRITE ONLY UNDER `{{lane_source_path}}` — the source path the `{{lane_id}}` lane
-      declares. That subtree is this lane's; a file outside it belongs to another lane
-      or to no lane at all. Do not create a parallel source tree because the layout
-      inside it is unfamiliar; if the pass needs a place this subtree has no home for,
-      STOP and surface it.
-
+      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}}
       Rules:
-      - THE PASS IS THE ONLY DOMAIN INPUT. You have it, the story, and framework/code
-        standards — and NO domain rule files. Introduce NO domain rule, identifier,
-        terminology or behaviour the pass does not state. If a domain specific seems
-        missing, STOP and surface it; never invent it from memory.
+      - 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
+        bounded context's DOMAIN MODEL (domain-model.md, in context) is the authority on
+        WHAT THE DOMAIN IS — the entity and value-object NAMES, the aggregate boundary,
+        the lifecycle states, and the TEXT of every invariant the plan cites by id. The
+        plan records WHERE a BR-nnn is enforced and deliberately never restates it, so the
+        model is where you read what it requires; enforce the rule the model states, in the
+        place the plan names. You have NO domain rule files and NO spec — introduce nothing
+        neither document states, and if a domain specific is in neither, STOP and surface
+        it rather than inferring it from a name, from surrounding code or from memory.
+      - THE MODEL IS READ, NEVER MINED FOR WORK. It describes the WHOLE bounded context,
+        while this run builds one feature. Realise only what the PLAN calls for: an entity,
+        event or invariant in the model that no plan element realises is a PLANNING gap —
+        surface it, do not implement it. `{{feature}}` is the aggregate this feature owns;
+        any other `## Aggregate:` section belongs to another slice, and you read it only to
+        honour a reference the plan makes, never to generate its code.
+      - BIND THE STACK: this lane is `{{be_lane_id}}` — {{be_title}}, language
+        {{be_language}} ({{be_ecosystem}}), declared in .appweaver/stacks.json and compiled
+        with `{{be_build}}`, tested with `{{be_test}}`. Generate in THAT language and
+        framework and no other, using its idioms, its project layout and its test
+        framework. Take persistence, messaging and the remaining technology choices from
+        the constitution's technology base + the loaded standards; the plan is
+        technology-agnostic, so do not re-decide anything already fixed there. If the
+        loaded standards describe a DIFFERENT stack than the one above, the lane wins on
+        language and layout — the standards' stack-specific mechanics do not apply, so
+        follow their INTENT and STOP to surface the mismatch in your summary.
+      - WRITE ONLY UNDER `{{be_source_path}}` — the source path the `{{be_lane_id}}` lane
+        declares in .appweaver/stacks.json. That subtree is this lane's, and a file outside
+        it belongs to another lane or to no lane at all. NEVER write into the frontend
+        lane's subtree, not even to consume a contract. Do not create a parallel source
+        tree because the layout inside it is unfamiliar; if the plan needs a place this
+        subtree has no home for, STOP and surface it.
       - Follow the project's folder/layer convention + the loaded coding-standards,
-        dependency-policy and testing standards for HOW to structure, name and place
-        files WITHIN that subtree — the pass says WHAT to build; these say HOW.
-      - Realise the pass's "### Approach" and "### Changes" exactly, changing nothing
-        about WHAT they specify, and preserve every ubiquitous-language name verbatim.
-      - INTERFACES: where the pass's "### Interfaces" describes a published surface,
-        the entry in interfaces.md (in context) is the contract — match its route,
-        shape and semantics. Where the log and the pass disagree, the pass is the
-        newer word and the log entry it supersedes is named in it; if neither says
-        which, STOP and surface it rather than picking.
-      - COMPONENTS: where the pass depends on a framework component (e.g.
-        `IEmailService`, `IJobScheduler`), code against that component's ABSTRACTION /
-        port as the pass declares — do NOT hand-roll it. Installing the component into
-        the project (packages, provider wiring, config) is a SEPARATE step:
-        /appweaver add-component <Component>. If the port is not present yet, code to
-        it and note add-component as the prerequisite.
-      - ADRs are DECIDED — follow them. The pass may propose a superseding one; a
-        proposal is not yet ratified, so follow the pass and change nothing else.
-      - Author a paired test for every acceptance criterion in the story and every
-        behaviour the pass's "### Tests" section names, and cite the requirement id
-        ({{exercises_csv}}) each test exists for. Include the constraint tests the
-        pass names ({{constraints_csv}}) — e.g. an audit record is emitted, a
-        restricted field is NOT exposed on the public surface.
-      - Do NOT add behaviour the pass does not state, and do NOT omit any it does. If
-        the pass looks wrong or incomplete, STOP and surface it — it is fixed by
-        re-running /appweaver story-plan, never compensated for here from the spec or
-        from memory.
-      - This feature OWNS its files; never regenerate a file another feature owns.
-      {{stale_note}}
+        dependency-policy and testing standards for HOW to structure, name and place files
+        WITHIN that subtree — the plan says WHAT to build; these standards (identical for
+        every feature) say HOW.
+      - COMPONENTS: when the plan's External Integrations table depends on a framework
+        component (e.g. `IEmailService`, `IJobScheduler`), code against that component's
+        ABSTRACTION / port as the plan declares — do NOT hand-roll it. Installing the
+        component into the project (packages, provider wiring, config) is a SEPARATE step:
+        /appweaver add-component <Component>. If the port isn't present yet, code to it and
+        note add-component as the prerequisite; do not load component rule docs here.
+      - 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
+        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.
+      - 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.
+      - 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.
+      - This aggregate OWNS its files; never regenerate a file another feature owns.
+      - 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.
+    outputs:
+      - { name: be_files, from: "$.files" }
+
+  # ═══════════ 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), and the delta spec is here ONLY so the paired tests can cite
+  # traceability ids.
+  - id: ctx_backend_delta
+    condition: "{{be_mode}} == delta"
+    action: build_context
+    context:
+      - { path: "{{be_plan}}" }                      # this change's delta-backend-plan.md
+      - { path: "{{delta_spec}}", optional: true }
+      - { 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: "{{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
+    condition: "{{be_mode}} == delta"
+    action: agent_generate
+    tools: "Read,Write,Edit"
+    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}}
+      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.
+      - 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
+        DOMAIN IS, and it reaches you in TWO halves, both in context: the master
+        domain-model.md is the domain as it stands BEFORE this change, and this change's
+        model delta (domain-model.{{cr_id}}.delta.md) is what the change ADDS to, MODIFIES
+        in or REMOVES from it. THE EFFECTIVE MODEL IS THE TWO READ TOGETHER, the delta
+        winning wherever they differ — it is the newer statement, and the master has not
+        been merged yet (finalize-delta does that after this phase). Read there what every
+        BR-nnn the delta plan cites actually requires; the plan records WHERE each is
+        enforced and never restates it. You have NO domain rule files and NO spec beyond
+        the delta-spec's ids — if a domain specific is in none of them, STOP and surface it
+        (it is fixed in specify / plan / analyze-plan-delta), never invent it from memory.
+      - THE MODEL IS READ, NEVER MINED FOR WORK. Realise only what the DELTA PLAN calls
+        for: an item in the model delta that no delta-plan element realises is a PLANNING
+        gap — surface it, do not implement it. Everything in the master model that this
+        change does not touch is ALREADY BUILT; do not regenerate it. `{{feature}}` is the
+        aggregate this feature owns, and another `## Aggregate:` section belongs to another
+        slice — read it only to honour a reference the delta plan makes.
+      - NO OTHER CHANGE'S MODEL DELTA IS IN CONTEXT, deliberately. A predecessor this
+        change builds on was already accounted for when the delta plan was authored and
+        recorded under its "Depends on"; implement it from the PLAN, not by reaching for
+        another change's pending files.
+      - BIND THE STACK: this lane is `{{be_lane_id}}` — {{be_title}}, language
+        {{be_language}} ({{be_ecosystem}}), declared in .appweaver/stacks.json and compiled
+        with `{{be_build}}`, tested with `{{be_test}}`. Generate in THAT language and
+        framework and no other. Take persistence, messaging and the remaining technology
+        choices from the constitution's technology base + the loaded standards; the plan is
+        technology-agnostic, so do not re-decide anything already fixed there. If the
+        loaded standards describe a DIFFERENT stack than the one above, the lane wins on
+        language and layout — follow the standards' INTENT and STOP to surface the
+        mismatch in your summary.
+      - WRITE ONLY UNDER `{{be_source_path}}` — the source path the `{{be_lane_id}}` lane
+        declares. That subtree is this lane's, and a file outside it belongs to another
+        lane or to no lane at all. NEVER write into the frontend lane's subtree.
+      - Follow the project's EXISTING folder/layer convention + the loaded
+        coding-standards, dependency-policy and testing standards for HOW to structure,
+        name and place files WITHIN that subtree. Match the surrounding code already there.
+      - Realise EVERY ADDED/MODIFIED delta element as code: one file per Domain type /
+        Application use-case / API endpoint / Infrastructure adapter, placed by layer.
+        Preserve the ubiquitous-language names verbatim. Enforce each new/changed Domain
+        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.
+      - 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
+        the port isn't present, code to it and note that as the prerequisite.
+      - Author a paired test for every ADDED/MODIFIED behaviour / use-case / endpoint;
+        derive the cases from the delta plan's pre/post/invariant contracts and cite the
+        delta-spec id (FR / BR / CN / DC / IC / US).
+      - 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 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.
+    outputs:
+      - { name: be_files, from: "$.files" }
+
+  - id: verify_be_files
+    condition: "{{be_go}} == true"
+    action: verify_context
+    require_non_empty: be_files
+    on_empty: stop
+    on_empty_message: "The backend lane generated no files. Ensure {{be_plan}} is a FILLED plan (not the empty template) and that it passed its gate — /appweaver analyze-plan for a master, /appweaver analyze-plan-delta for a change — then re-run implement."
+
+  # OKF knowledge — the feature has ONE concept across both lanes and both modes, so every
+  # lane's files JOIN it rather than replace it (--merge unions them with what is already
+  # recorded). Without the union a backend run would erase the frontend lane's source_files
+  # and vice-versa, and either lane may have run first. ⌛ The trade-off is that a file this
+  # lane DELETED stays listed until something prunes it; a lane-scoped replace needs
+  # concept-upsert to learn about lane roots, which is a script change and not built.
+  - id: xref_concept_backend
+    condition: "{{be_go}} == true"
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: concept-upsert
+    args: ["--feature-dir", "{{feature_dir}}", "--source-files", "{{be_files}}", "--merge", "--origin", "greenfield"]
+    outputs:
+      - { name: okf_concept, from: "$.concept" }
+
+  # ═══════════ FRONTEND LANE — bootstrap, generate from the MASTER plan ════════
+  # 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.
+  - id: ctx_frontend
+    condition: "{{fe_mode}} == bootstrap"
+    action: build_context
+    context:
+      - { 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
+  - id: gen_frontend
+    condition: "{{fe_mode}} == bootstrap"
+    action: agent_generate
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Generate the production UI code AND paired tests for this feature STRICTLY from its
+      frontend-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 framework-specific, lane-wide
+      code-generation rules. Guidance: {{USER_INPUT}}
+      Rules:
+      - TWO DOMAIN INPUTS, WITH DIFFERENT JOBS. The PLAN is the only authority on WHAT TO
+        BUILD — the screens, the state, the components, the bindings. The bounded context's
+        DOMAIN MODEL (domain-model.md, in context) is the authority on WHAT THE DOMAIN IS:
+        use its UBIQUITOUS LANGUAGE exactly — the same terms in labels, states, empty
+        copy and messages, no synonyms — and read there what a BR-nnn the plan cites
+        actually requires, since the plan records where each is enforced and never restates
+        it. You have NO domain rule files and NO spec: introduce nothing neither document
+        states, and if a domain specific is in neither, STOP and surface it.
+      - THE MODEL IS READ, NEVER MINED FOR WORK, and reading a rule is not permission to
+        move it. Realise only what the PLAN calls for. A client-side check restates a
+        server-enforced invariant for FEEDBACK — the message says what the model says, in
+        the model's words — and it never becomes the place the rule lives. An entity or
+        invariant in the model that no plan element realises is a PLANNING gap; surface it.
+        `{{feature}}` is this feature's aggregate; another `## Aggregate:` section belongs
+        to another slice.
+      - BIND THE STACK: this lane is `{{fe_lane_id}}` — {{fe_title}}, language
+        {{fe_language}} ({{fe_ecosystem}}), declared in .appweaver/stacks.json and built
+        with `{{fe_build}}`, tested with `{{fe_test}}`. Generate in THAT framework and no
+        other, using its idioms, its project layout and its test framework. Take the
+        router, state approach, component library, design system and styling from the UI
+        constitution + the loaded standards; the plan is technology-agnostic, so do not
+        re-decide anything already fixed there. If the loaded standards describe a
+        DIFFERENT stack than the one above, the lane wins on framework and layout — follow
+        the standards' INTENT and STOP to surface the mismatch in your summary.
+      - WRITE ONLY UNDER `{{fe_source_path}}` — the source path the `{{fe_lane_id}}` lane
+        declares. That subtree is this lane's; a file outside it belongs to the service
+        lane or to no lane. NEVER touch the service lane's code, not even to add a field
+        the UI wants: a gap in the service surface is a contract delta raised back to that
+        lane. Do not create a parallel source tree because the layout inside this one is
+        unfamiliar; if the plan needs a place this subtree has no home for, STOP and
+        surface it.
+      - Follow the UI constitution's folder structure, naming conventions and forbidden
+        patterns, plus the loaded standards, for HOW to structure, name and place files
+        WITHIN that subtree — the plan says WHAT to build; these say HOW.
+      - REALISE EVERY PLAN ELEMENT, changing nothing about WHAT it specifies:
+        • §1 — one route/screen per row, with the navigation shape and the access
+          conditions the row states.
+        • §2 — the client state exactly as owned and scoped there, including its
+          invalidation triggers. Anything the plan lists under "what must NOT be held"
+          NEVER reaches client state, storage, the URL or telemetry.
+        • §3 — one component per row, with the responsibility, the input field shapes and
+          the events the plan gives it. Compose the shared components the plan says it
+          reuses; do not re-implement them.
+        • §4 — EVERY state in EVERY interaction row: loading, empty, error,
+          permission-denied and in-flight/disabled, plus the validation timing, the focus
+          and keyboard behaviour and the concurrency handling stated there. These are
+          requirements, not polish, and they are the first thing a generator drops.
+        • §5 — the service binding, through the lane's own client layer, with the write
+          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 CLIENT IS NOT AN AUTHORITY. A client-side validation or permission check
+        restates a server rule for feedback; it never replaces it. Generate no server-side
+        behaviour, no persistence and no business rule evaluation here.
+      - 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.
+      - 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.
+      - This feature OWNS its files; never regenerate a file another feature owns, and do
+        not modify the app shell, global layout or design system — they belong to no
+        feature. If one of them has to change, 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.
     outputs:
-      - { name: files, from: "$.files" }
+      - { name: fe_files, from: "$.files" }
+
+  # ═══════════ FRONTEND LANE — delta, generate ONLY what the change adds ═══════
+  # The UI half of the CR loop, which never existed as its own command: the ⌛
+  # `implement-ui-delta` phase is BUILT HERE by absorption, exactly as the delta UI plan
+  # shipped as the frontend half of the delta-plan module.
+  - id: ctx_frontend_delta
+    condition: "{{fe_mode}} == delta"
+    action: build_context
+    context:
+      - { path: "{{fe_plan}}" }                       # this change's delta-frontend-plan.md
+      - { path: "{{delta_spec}}", optional: true }
+      - { path: "{{delta_model}}", optional: true }   # this change's MODEL half — new terms, states and rules the UI must speak
+      - { 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 }
+  - id: gen_frontend_delta
+    condition: "{{fe_mode}} == delta"
+    action: agent_generate
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      Implement ONLY change {{cr_id}} (wave {{wave}}) into the existing frontend tree,
+      STRICTLY from its delta-frontend-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 frontend-plan.md (in context) is the BASE: the unchanged
+      screens, state and components the delta depends on; do NOT regenerate them.
+      Guidance: {{USER_INPUT}}
+      Rules:
+      - SCOPE = THE DELTA ONLY. Realise exactly the screens, components, state and bindings
+        the delta plan marks ADDED (create the new file) or MODIFIED (edit the existing
+        file in place). A shared component or a shared state container is MODIFIED in
+        place, never copied into the change. 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. The DOMAIN MODEL is the authority on WHAT THE DOMAIN
+        IS, and it reaches you in TWO halves, both in context: the master domain-model.md
+        is the language and the rules as they stand BEFORE this change, and this change's
+        model delta is what it ADDS, MODIFIES or REMOVES. THE EFFECTIVE MODEL IS THE TWO
+        READ TOGETHER, the delta winning wherever they differ — the master has not been
+        merged yet. A TERM THIS CHANGE INTRODUCES OR RENAMES IS IN THE DELTA, and the UI
+        must speak it exactly as the delta spells it, in labels, states and messages. Read
+        there what any BR-nnn the delta plan cites requires. NO domain rule files, and no
+        spec beyond the delta-spec's ids; if a domain specific is in none of them, STOP and
+        surface it.
+      - THE MODEL IS READ, NEVER MINED FOR WORK, and reading a rule is not permission to
+        move it. Realise only what the DELTA PLAN calls for — an item in the model delta
+        that no delta-plan element realises is a PLANNING gap, and a client-side check
+        restates a server-enforced rule for FEEDBACK and never replaces it.
+      - BIND THE STACK: this lane is `{{fe_lane_id}}` — {{fe_title}}, language
+        {{fe_language}} ({{fe_ecosystem}}), built with `{{fe_build}}`, tested with
+        `{{fe_test}}`. Generate in THAT framework and no other. Take the router, state
+        approach, component library, design system and styling from the UI constitution +
+        the loaded standards, and MATCH the code already in the tree.
+      - WRITE ONLY UNDER `{{fe_source_path}}`. NEVER touch the service lane's code, not
+        even to add a field the UI wants — a gap in the service surface is a contract delta
+        raised back to that lane, never worked around in the client.
+      - STATES ARE PART OF THE CHANGE. Every interaction this delta adds or alters ships
+        its FULL state set — loading, empty, error, permission-denied, in-flight — plus the
+        validation timing, focus placement and keyboard reachability the delta plan states.
+        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
+        evaluation.
+      - Author a paired test for every ADDED/MODIFIED screen, interaction and state,
+        including the unwanted-behaviour states and an accessibility assertion per
+        interactive surface, citing the delta-spec id (UX-/US-/FR-/CN-/DC-/IC-/SC-).
+      - 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.
+      - Do not modify the app shell, global layout or design system — they belong to no
+        feature. If one of them has to change, STOP and surface it.
+      - Where generated code depends on a delta Assumption (DA-n) or Workaround (WA-n),
+        mark it with a comment citing that id.
+    outputs:
+      - { name: fe_files, from: "$.files" }
 
-  - id: verify_generated
+  - id: verify_fe_files
+    condition: "{{fe_go}} == true"
     action: verify_context
-    require_non_empty: files
+    require_non_empty: fe_files
     on_empty: stop
-    on_empty_message: "No files generated for story {{story}}. Check that design pass {{design_pass}} in {{design_doc}} actually describes changes (a pass whose '### Changes' section is empty has nothing to build), then re-run — or re-run /appweaver story-plan {{story}} to design the slice properly first."
-
-  # 8. OKF — MERGE, never replace. This run wrote ONE STORY's files; the feature's
-  #    other stories wrote the rest, and a replace would erase them the moment a second
-  #    story implements. --lane backend puts them in `source_files`, the service lane's
-  #    key, leaving `ui_source_files` for implement-ui.
-  #    Known limit: a file the slice DELETED stays in the list; concept-coverage reports
-  #    it as declared-but-missing drift rather than silently carrying it as real.
-  - id: xref_concept
+    on_empty_message: "The frontend lane generated no files. Ensure {{fe_plan}} is a FILLED plan (not the empty template) and that it passed its gate — /appweaver analyze-plan for a master, /appweaver analyze-plan-delta for a change — then re-run implement."
+
+  - id: xref_concept_frontend
+    condition: "{{fe_go}} == true"
     action: execute_script
+    on_error: continue
     script: { ref: xref }
     subcommand: concept-upsert
-    args: ["--feature-dir", "{{feature_dir}}", "--source-files", "{{files}}", "--merge", "--lane", "backend", "--origin", "greenfield"]
+    args: ["--feature-dir", "{{feature_dir}}", "--source-files", "{{fe_files}}", "--merge", "--origin", "greenfield"]
     outputs:
       - { name: okf_concept, from: "$.concept" }
 
-  # 8a. Cross-slice edges are a FEATURE property, not a story's: which sibling
-  #     aggregates this one references is stated by the feature plan's domain model,
-  #     and no single slice can answer it. So this reads backend-plan.md — the one
-  #     derived fact it takes from the plan — and reconciles on write, so a dropped
-  #     dependency self-heals out of the used aggregate's Cross-References. Skipped
-  #     with no plan on disk: there is then nothing to derive edges from.
+  # 11. CROSS-SLICE EDGES — a Cross-References row written into every SIBLING aggregate
+  #     this one uses, read off the master backend plan (§1 References-by-id + its External
+  #     integrations table), reconcile-on-write so a dropped dependency self-heals and a
+  #     used sibling with no concept yet is stubbed.
+  #     BOOTSTRAP ONLY. On the delta path the master plan still holds the PRE-change
+  #     dependencies, so recording edges now would publish stale references — finalize-delta
+  #     records them after the change merges. Enrichment downstream of a successful
+  #     generation; it never re-decides WHAT was built.
+  - id: record_edges_flag
+    condition: "{{mode}} == bootstrap"
+    action: set
+    vars: { record_edges: "{{be_go}}" }
   - id: xref_record
-    condition: "{{be_plan_exists}} == true"
+    condition: "{{record_edges}} == true"
     action: execute_script
     on_error: continue
     script: { ref: xref }
@@ -466,118 +923,72 @@ workflow:
       - { name: xref_wrote,      from: "$.wrote" }
       - { name: xref_edge_count, from: "$.edge_count" }
 
-  # 8b. The concept's Overview — the one part a deterministic script cannot produce.
-  #     It describes the AGGREGATE, which is the feature plan's subject: distilling it
-  #     from one story's slice would name whatever that slice happened to touch. The
-  #     model authors prose only; concept-overview splices it into `## Overview` alone,
-  #     so the Cross-References rows other slices own are structurally out of reach.
-  #     build_context, not a step-level `context:`: the engine REPLACES the envelope on
-  #     build_context and only ADDS to it on a step-level list, so naming the plan alone
-  #     there would have left generation's whole payload — this story's slice included —
-  #     underneath a prompt that says "describe the whole aggregate, not one story".
+  # 12. The concept's Overview — the ONE part of the OKF concept a deterministic script
+  #     cannot produce. It describes the aggregate ROOT, the invariants it guards and its
+  #     transaction boundary, and since the model split those are literally the CONTEXT'S
+  #     DOMAIN MODEL's content: the plan only records where each invariant is enforced. So
+  #     the model is the source where there is one, and the backend plan is the fallback
+  #     for a feature that predates the split. Its own build_context — the envelope
+  #     persists, and distilling the concept prose from a generation payload would describe
+  #     the code rather than the aggregate.
+  #     BOOTSTRAP ONLY: on the delta path finalize-delta re-authors it from the merged
+  #     model, after the change has actually landed in it.
+  - id: overview_from_model
+    condition: "{{domain_model_exists}} == true"
+    action: set
+    vars: { overview_ok: "true" }
+  - id: overview_from_plan
+    condition: "{{be_go}} == true"
+    action: set
+    vars: { overview_ok: "true" }
+  - id: overview_delta_off
+    condition: "{{mode}} == delta"
+    action: set
+    vars: { overview_ok: "false" }
+
   - id: ctx_overview
-    condition: "{{be_plan_exists}} == true"
+    condition: "{{overview_ok}} == true"
     action: build_context
     context:
-      - { path: "{{be_plan}}" }
+      - { path: "{{domain_model}}", optional: true }
+      - { path: "{{backend_plan}}", optional: true }
   - id: okf_overview
-    condition: "{{be_plan_exists}} == true"
+    condition: "{{overview_ok}} == true"
     action: agent_query
     include_standards: false
     schema: { overview: "<2-4 sentences of prose>" }
     mock: { overview: "" }
     task: |
-      Write the OKF knowledge-concept Overview for the aggregate that the backend plan
-      (in context) describes. 2-4 sentences of PROSE, distilled from §1 Domain Model:
+      Write the OKF knowledge-concept Overview for the aggregate `{{feature}}`. 2-4
+      sentences of PROSE:
       - name the aggregate ROOT and what the aggregate IS;
-      - state the INVARIANTS it guards;
-      - state its TRANSACTION BOUNDARY — what it OWNS inside the boundary vs what it
-        only REFERENCES by id.
+      - state the INVARIANTS it guards (its BR-nnn — what they require, not their ids);
+      - state its TRANSACTION BOUNDARY — what it OWNS inside the boundary vs what it only
+        REFERENCES by id.
+      The bounded context's domain-model.md is the source where it is in context: read
+      ONLY its `## Aggregate: {{feature}}` section — the other aggregates are other
+      slices' concepts. Where it is not in context, distil the same three things from
+      backend-plan.md's domain section instead.
       Plain prose only: no headings, no bullets, no code fences, no file paths, and no
       restating of the dependency edges (those live in the Depends-On / Cross-References
-      tables). Describe only what the plan states — invent nothing, and describe the
-      whole aggregate rather than the one story that happens to be building now.
+      tables). Describe only what the document states — invent nothing.
     outputs:
       - { name: okf_overview, from: "$.overview" }
+
   - id: okf_overview_write
-    condition: "{{be_plan_exists}} == true"
+    condition: "{{overview_ok}} == true"
     action: execute_script
+    on_error: continue
     script: { ref: xref }
     subcommand: concept-overview
     args: ["--feature-dir", "{{feature_dir}}", "--text", "{{okf_overview}}"]
 
-  # ═══════════════ ACCEPTANCE — the ONE place the spec is read ═════════════════
-  # Generation is design-only by contract; this is the check that the design was not
-  # the wrong design. READ-ONLY and REPORT-ONLY: it never edits code, never edits the
-  # pass, and never stops the run. A gap here means one of two documents is wrong, and
-  # which one is a human decision — the message names both routes.
-  - id: ctx_accept
-    action: build_context
-    vars:
-      story_id: "{{story}}"
-      exercises_csv: "{{exercises_csv}}"
-      constraints_csv: "{{constraints_csv}}"
-      files_csv: "{{files}}"
-    context:
-      - { path: "{{story_path}}" }    # the acceptance criteria
-      - { path: "{{spec_file}}" }     # the contract — the ONLY step in this workflow that reads it
-      - { path: "{{design_doc}}" }    # what was designed
-  - id: accept_check
-    action: agent_query
-    tools: Read                       # the generated files arrive as paths, not inlined
-    include_standards: false
-    schema: { ok: "<true|false>", gaps: "<one line per gap, or empty>" }
-    mock: { ok: "true", gaps: "" }
-    task: |
-      Story {{story_id}} was just implemented. Judge ONLY this: does the code that now
-      exists satisfy the requirements the story delivers, AS THE SPEC WORDS THEM?
-
-      In scope: {{exercises_csv}} (delivered) and {{constraints_csv}} (must hold).
-      Resolve each id's wording from spec.md in context — that wording, not the design's
-      restatement of it, is what the code is measured against.
-
-      Read the files this run wrote:
-          {{files_csv}}
-      plus anything they call that you need to follow. Do not modify a single file.
-
-      Report a gap ONLY where the code fails to deliver an in-scope id as the spec words
-      it, or breaks an in-scope constraint. These are NOT gaps, and reporting them is
-      noise that hides the real ones:
-      - a requirement no story has claimed yet, or one another story delivers;
-      - style, naming, structure or test-coverage opinions — other gates own those;
-      - anything the design pass deliberately deferred and named under its risks.
-
-      One line per gap: the id, what the spec requires, and what the code does instead.
-      Set ok=false only when you found at least one. If the SPEC and the DESIGN disagree
-      about an in-scope id, that IS a gap — say which document you believe is wrong and
-      why, because the two routes out of it are different commands.
-    outputs:
-      - { name: accept_ok,   from: "$.ok" }
-      - { name: accept_gaps, from: "$.gaps" }
-  - id: accept_notice
-    condition: "{{accept_ok}} != true"
-    action: verify_context
-    require_value: accept_ok
-    equals: "true"
-    on_mismatch: continue
-    on_mismatch_message: |
-      ACCEPTANCE — story {{story}} does not yet satisfy the spec wording of the ids it delivers:
-
-      {{accept_gaps}}
-
-      Nothing was changed to fix this: the code follows design pass {{design_pass}}, so a gap
-      here means either the design was wrong or the spec has moved. Route by which it is —
-      the design is wrong: /appweaver story-plan {{story}} (a new pass supersedes this one);
-      the spec is wrong: /appweaver sync-spec, then sync-stories, then story-plan.
-      Run /appweaver build either way — a design that is right and code that does not compile
-      is a third thing, and build is where that one surfaces.
-
-  # 9. Post-execution hooks.
+  # 13. Post-execution hooks — the same phase set as the pre-hooks above.
   - id: resolve_post_hooks
     action: execute_script
     script: { ref: actions }
     subcommand: resolve-hooks
-    args: ["--phase", "after_implement"]
+    args: ["--phase", "after_implement", "--phase", "{{post_ui_phase}}", "--phase", "{{post_cr_phase}}"]
     outputs:
       - { name: after_hooks, from: "$.hooks" }
   - id: dispatch_post_hooks
@@ -585,12 +996,19 @@ workflow:
     hooks_from_variable: after_hooks
 
 outputs:
-  story: "{{story}}"
-  built_from: "{{design_doc}} — design pass {{design_pass}} (designed against spec {{design_spec_version}}; spec now {{current_version}})"
-  requirements: "{{exercises_csv}}"
-  files: "{{files}}"
-  lane: "{{lane_id}} → {{lane_source_path}}"
-  okf_concept: "{{okf_concept}} (this run's files MERGED into source_files; {{xref_edge_count}} cross-slice edge(s) recorded into sibling aggregates)"
-  acceptance: "ok={{accept_ok}} · gaps: {{accept_gaps}}"
-  stale_ids: "{{stale_csv}}"
-  next: "/appweaver build — it compiles every declared lane. Then /appweaver analyze-slice (spec ↔ code, through the design), and /appweaver implement-ui if this story has a UI design. The story stays OPEN until /appweaver close-story ratifies its ADRs, flips its interface entries live and archives the passes."
+  feature_dir: "{{feature_dir}}"
+  bounded_context: "{{context}}"
+  mode: "{{mode}}"
+  cr_id: "{{active_change}}"
+  backend_implemented: "{{be_go}}"
+  backend_plan: "{{be_plan}}"          # the document the backend lane generated FROM
+  backend_files: "{{be_files}}"
+  frontend_implemented: "{{fe_go}}"
+  frontend_plan: "{{fe_plan}}"         # the document the frontend lane generated FROM
+  frontend_files: "{{fe_files}}"
+  domain_model: "{{domain_model}}"     # the master model every generating lane read
+  delta_model: "{{delta_model}}"       # its second half on the delta path — empty on the bootstrap path
+  okf_concept: "{{okf_concept}}"
+  xref_edge_count: "{{xref_edge_count}}"
+  note: "Lanes come from .appweaver/stacks.json — backend declared {{be_declared}} (ready {{be_runnable}}, implemented {{be_go}}), frontend declared {{fe_declared}} (ready {{fe_runnable}}, implemented {{fe_go}}). 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."
+  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."