aw-spec-cli 0.1.16 → 0.1.18

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

@@ -1,89 +1,99 @@
 # =============================================================================
-# aw-spec-plan (orchestrator) — the spec-anchored Plan phase (service lane)
+# aw-spec-plan (orchestrator) — the spec-anchored Plan phase, BOTH LANES
 #
-# Authors and MAINTAINS one high-level plan per feature and lane. This workflow owns
-# the SERVICE lane's document — specs/<Aggregate>/backend-plan.md — the tech-agnostic
-# HLD that MEDIATES between the spec and the code (formerly design.md; the scaffold
-# migrates a legacy design.md by renaming it). The frontend lane's twin,
-# frontend-plan.md, is owned by /appweaver plan-ui — a SEPARATE command because the
-# two lanes are governed by different rule sets (tech-rule-bindings gives each lane
-# its own set; one command would hand this phase both lanes' whole rule surface).
-# `implement` GENERATES the code from spec + plan (model-driven, not a deterministic
-# extract). See .appweaver/DESIGN-FORMAT.md + .appweaver/templates/design-template.md.
-# (`plan` re-uses the name of a long-retired phase whose plan.md had zero consumers.)
+# Authors the feature's LANE PLANS — the tech-agnostic HLDs that MEDIATE 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
+# `implement` GENERATES each lane's code from ITS PLAN ALONE (model-driven, not a
+# deterministic extract) — it never reads the spec, so whatever a plan leaves out is
+# missing from the code. See .appweaver/DESIGN-FORMAT.md + the design-template /
+# ui-design-template.
 #
-# WHERE IT SITS. specify/sync-spec (⌛ sync-spec is not built yet; the hand route is
-# .appweaver/SPEC-EDIT-PROTOCOL.md) move the spec; the developer then runs plan, which
-# conforms this feature's design to what moved. Story designs (/appweaver story-plan)
-# READ this document for the ids they carry and NEVER write back — nothing merges into
-# it, so it keeps exactly one writer and cannot be silently rewritten. It is the
-# FEATURE-LEVEL ARCHITECTURAL CONFIRMATION: what the feature's structure IS to be,
-# tech-agnostic, with the concrete file-level work left to the per-story passes.
+# THE LANES COME FROM stacks.json, NOT FROM A FLAG. select-stack is the sole writer of
+# the lane declaration, and this phase simply plans whichever lanes are there: backend
+# only, frontend only, or both. A lane declared `(none)` produces no plan and no failure.
+# With NO lane declared at all the phase stops and names select-stack — a plan written
+# against no declared stack invents its own.
 #
-# IT READS THE CODE. concept-paths resolves the feature's OKF concept to the source
-# files realising it and the authoring steps declare `tools: Read`, so a plan over an
-# existing codebase ADJUSTS to the shape that is actually there. The code is the
-# what-exists authority; the spec stays the only authority on behaviour and the only
-# domain input. source_count 0 = greenfield, and the phase never blocks on it.
+# ONE COMMAND, TWO LANES, TWO RULE SETS. The lanes take their rules from different
+# headings of tech-rule-bindings (`## /aw-spec-plan` for the service, `## /aw-spec-plan-ui`
+# for the frontend), and the frontend set is loaded ONLY when that lane is declared — so
+# a backend-only project sees exactly the rules it did before. In a two-lane project both
+# sets are sticky for the whole run; the lane boundary is held by the prompts instead,
+# and §5 Contract Binding is where it is stated.
 #
-# IT PUBLISHES THE INTERFACES. The feature's published surface lives in
-# specs/<Aggregate>/interfaces.md — APPEND-ONLY, script-numbered (IF-nnn, dated,
-# status: proposed). This phase writes it and §3 of the plan cites the ids; /appweaver
-# plan-ui and the FE story designs CONSUME the latest entry per id. A changed interface
-# is a superseding entry, never an edit — one wording, one lifecycle, no second copy.
+# RENAMED FROM `design`. design.md → backend-plan.md, design.ui.md → frontend-plan.md,
+# and the former separate `design-ui` command is FOLDED IN here. The scaffold MIGRATES a
+# legacy document by renaming it, so an existing feature moves to the plan names on its
+# next run instead of needing a flag day.
 #
-# THREE MODES, resolved deterministically (self-detecting on the plan doc's own
-# existence, symmetric with how specify keys off spec.md):
-#   • bootstrap_gf (default) — no backend-plan.md yet: author the master from the
-#     whole spec, four-layer greenfield template (Domain·Application·API·Infra).
-#   • bootstrap_bf — same, but onboard installed the code-derived design-template
-#     override: author with the project's AS-BUILT structure instead.
-#   • update — backend-plan.md exists: conform it to what the spec's Change History
-#     ledger says moved SINCE THIS PLAN WAS LAST DERIVED, and nothing else. This
-#     replaces the former delta-design branch (delta-design + finalize-delta merge);
-#     in the story flow the spec moves via sync-spec and the plan follows here.
+# TEMPLATE-DRIVEN AUTHORING (greenfield-safe). Each lane's authoring step follows the
+# structure of whichever template is ACTIVE for it, chosen deterministically:
+#   • GREENFIELD (default) — the kit's templates: the four-layer service template
+#     (Domain·Application·API·Infra) and the experience template (§0–§9).
+#   • BROWNFIELD — when /appweaver onboard has GENERATED a code-derived override
+#     (design-template / ui-design-template; override_active), a NEW feature added to an
+#     existing repo is authored with the as-built structure instead, so it slots into the
+#     codebase already there.
+# The variants are separate steps selected by one `*_mode` var per lane, so greenfield
+# authoring never sees the brownfield guidance and vice-versa.
 #
-# TRACKING (the lockstep made real). Every write ends with plan-stamp, which is the
-# only writer of the plan's version identity:
-#   • the doc's **Version** header := the spec version this plan now derives from,
-#   • an update appends the plan's own Change History row naming the conformed ids,
-#   • .aw-plan-track.backend-plan.json (beside the spec) records {spec_version,
-#     sha256} — one track file per plan document, so the two lanes never contend.
-# plan-check reads that record back: BEHIND (ledger rows above the derived version →
-# the exact ids to conform), EDITED (hash mismatch — the doc was hand-edited since
-# the stamp; refused unless accept_manual folds the edits in), UNTRACKED (a migrated
-# legacy design.md with no baseline — the update reconciles the WHOLE plan once and
-# baselines it). The model writes NO version anywhere; the script stamps.
+# IT READS THE DOMAIN MODEL AND NEVER WRITES IT. The aggregate root, its entities, its
+# events and its invariants (BR-n) live in specs/<Context>/domain-model.md, which
+# `specify` authors. This phase records where each invariant is ENFORCED, not what it
+# says — the model is spec-tier, the plan is realisation-tier.
 #
-# LANE-AWARE. Lanes come from .appweaver/stacks.json (select-stack declares them):
-#   • backend lane declared → author backend-plan.md. This is a REQUIREMENT, not a
-#     default: with no backend stack declared the phase stops and says so, because a
-#     service plan written against no declared service invents its own stack.
-#   • frontend lane also declared → the handoff names /appweaver plan-ui.
-#   • frontend-only, or nothing declared at all → stop, each with its own message.
+# AUTHORS only — the gates are SEPARATE stages. IT ASKS WHAT IT IS PLANNING, exactly as
+# `implement` asks what it is building: list what is open, pick one, activate it. The
+# difference is that this phase can also be pointed at the feature's OWN spec, so the menu
+# carries two synthetic rows beside the open changes:
+#   • main → author the MASTER plan for each declared lane, from spec.md + the context's
+#     domain model. On a feature that has never been planned this is a BOOTSTRAP and
+#     nothing is asked. On one that HAS masters it is a RE-DERIVATION, and it is
+#     CONFIRMED first — the run stops on a decline, leaving them untouched.
+#     Next: /appweaver analyze-plan (spec↔plan gate) → implement.
+#   • CR-…  → author THAT change's delta plans ONLY (delta-plan module). The masters are
+#     left UNTOUCHED, and finalize-delta does not merge them either: it merges the
+#     change's spec and model halves, and a master plan is RE-DERIVED from those — which
+#     is what the main row above does. The change stays OPEN.
+#     Next: analyze-plan-delta → implement (which asks which change) → build →
+#     analyze-slice-delta → finalize-delta → analyze-slice → close-delta.
+#   • new  → open a plan-only change first, then plan it: a refactor or architectural
+#     decision where the realisation of EXISTING spec ids moves with no spec delta. Its
+#     delta-spec stays an unfilled stub, and that stub is the signal downstream.
+# The argument doubles as the answer — `plan main`, `plan CR-…` and `plan new` all skip
+# the prompt — and only the WHOLE argument counts, so guidance prose never selects.
 #
-# AUTHORS only — the gates are SEPARATE stages: /appweaver analyze-design proves
-# spec ↔ plan conformance after every bootstrap AND every update.
+# THE MENU APPEARS ONLY ONCE THERE IS A MASTER. With none yet there is nothing to choose:
+# a delta needs a master to be a delta OF, and so does a plan-only change. A first run
+# therefore authors the masters with no prompt at all. A change already open on such a
+# feature waits for the next run, when the menu will offer it.
 #
-# Launch:  /appweaver plan [guidance]           (accept_manual:true folds hand edits in)
+# The forward paths are explicit:
+#   NEW    : specify → plan → analyze-plan → implement
+#   CHANGE : specify (delta-spec + model delta) → plan (delta plans, per change) →
+#            analyze-plan-delta → implement (the delta plans) → build →
+#            finalize-delta → analyze-slice → close-delta
+#
+# Launch:  /appweaver plan [guidance]
+#          /appweaver plan main             (re-plan the masters, no prompt)
+#          /appweaver plan CR-20260910-…    (plan THAT open change, no prompt)
+#          /appweaver plan new              (open a plan-only change and plan it)
 # Prereq:  /appweaver specify
 # =============================================================================
 
 name: aw-spec-plan
-description: "Author or update the service lane's high-level plan — specs/<Feature>/backend-plan.md — from the spec. Self-detects: no plan yet ⇒ bootstrap the master (greenfield four-layer template, or the code-derived structure when onboard installed the design-template override); plan exists ⇒ UPDATE — conform exactly the sections serving the ids the spec's Change History moved since this plan's derivation stamp, preserving the Assumptions/Workarounds/Change History ledgers. Tracking is script-owned: plan-stamp moves the **Version** header to the derived spec version, appends the plan's history row and records the body hash; plan-check refuses hand-edited documents unless accept_manual folds them in. Reads the CODE as well as the spec (concept-paths + tools: Read), so a plan over an existing codebase conforms to the as-built shape; the spec remains the only domain and behaviour authority. Publishes the feature's PUBLISHED SURFACE to the append-only interfaces.md (script-assigned IF-nnn, status: proposed) — the anchor /appweaver plan-ui and the FE story designs consume; the plan's API section cites those ids rather than restating the contract. Lane-aware via stacks.json — a declared frontend lane routes its twin to /appweaver plan-ui; frontend-only projects are refused. Authoring only — gate every write at /appweaver analyze-design."
-version: 4.1.0
+description: "Author the feature's lane plans from the spec and the bounded context's domain model — backend-plan.md when a backend lane is declared, frontend-plan.md when a frontend lane is, both when both are. Lanes come from .appweaver/stacks.json, so one command covers backend-only, frontend-only and full-stack projects; the former separate design-ui command is folded in. It ASKS what it is planning, the way implement asks what it is building: the master (`main`), one of the OPEN CHANGES, or a new plan-only change for a refactor with no spec delta — the argument doubles as the answer, and the menu appears only once a master exists, so a first run bootstraps with no prompt. `main` on a feature that already has masters RE-DERIVES them from the merged spec.md + domain-model.md — the operation finalize-delta's contract assumes when it merges a change's spec and model halves and no lane plan — and is confirmed before it rewrites anything. A change instead gets delta-backend-plan.md / delta-frontend-plan.md inside changes/<CR-id>/ while the masters stay untouched, written against the effective model (the master model, the change's own model delta, and the pending model deltas of LOWER waves, which are its predecessors) and against the feature's real source files from its OKF concept. Master authoring is template-driven: the kit's templates by default, or the code-derived as-built structure when onboard installed an override. Authoring only — a master gates at analyze-plan; a change ships through the CR chain."
+version: 5.0.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
 inputs:
   user_input:
-    description: Optional plan guidance (architectural constraints, trade-off preferences).
+    description: "Optional plan guidance (architectural constraints, trade-off preferences), OR the answer to the one question this phase asks: `main` to re-plan the masters, a bare CR id to plan that open change, `new` to open a plan-only change. Only the whole argument counts as an answer, so guidance prose is never mistaken for one."
     required: false
     bind: USER_INPUT
-  accept_manual:
-    description: "true ⇒ a hand-edited plan (tracking state edited/edited_behind) is folded in instead of refused: the update keeps the manual edits' intent, reconciles them with the spec, and the stamp re-baselines."
-    required: false
-    bind: ACCEPT_MANUAL
 
 scripts:
   actions:
@@ -95,10 +105,13 @@ scripts:
 
 # Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). The TECHNICAL/
 # architecture rule files are CONFIGURATION, loaded per-command from
-# guardrails/projects/<project>/tech-rule-bindings.md under "## /aw-spec-plan" by the
-# tech-select module. No domain rule file is loaded here — domain reaches the plan
-# solely as spec ids (BR-/CN-/DC-/IC-). The technology base itself arrives via
-# constitution.technical.md (referred to directly, as-is — NOT mapped).
+# guardrails/projects/<project>/tech-rule-bindings.md by the tech-select module (see the
+# tech_select steps below), exactly as the DOMAIN rule files are loaded by domain-select.
+# Per the rule-partition this phase loads NO domain rule file — the domain reaches the
+# plan as spec ids (BR-/CN-/DC-/IC-) and as the context's domain model. The technology
+# base itself arrives via constitution.technical.md / constitution.ui.md (referred to
+# directly, as-is — NOT mapped). DDD stays in specify; coding-standards in implement.
+# (missing files skipped at assembly time)
 standards:
   - { path: .appweaver/ai-rules.md }   # kit-resident: the universal operating rules, every flow
 
@@ -106,71 +119,98 @@ vars:
   lanes_declared: "false"
   be_declared: "false"
   fe_declared: "false"
-  be_gate_msg: "No backend lane is declared in .appweaver/stacks.json, so there is no service to plan. Run /appweaver select-stack and declare the backend stack plus its source path, then re-run plan. A project that is genuinely UI-only plans the frontend lane alone with /appweaver plan-ui."
-  brownfield_plan: "false"     # design-scaffold.override_active — onboard installed the code-derived template
-  plan_created: "false"        # scaffold.created — true ⇒ the doc was absent ⇒ bootstrap
-  plan_migrated: "false"       # scaffold renamed a legacy design.md into backend-plan.md this run
-  plan_mode: "bootstrap_gf"    # resolved below → bootstrap_gf | bootstrap_bf | update
-  track_state: ""              # plan-check → fresh | untracked | clean | behind | edited | edited_behind
-  derived_version: ""          # the spec version the plan last derived from (empty when untracked)
-  current_version: ""          # the spec's current ledger version
-  changed_csv: ""              # ids the ledger moved above the derived version
-  changed_summary: ""          # the moved rows' summaries, for the update prompt
-  manual_ok: "true"            # false ⇒ hand edits present and accept_manual not given
-  plan_stale: "true"           # false ⇒ update mode with nothing to do (clean) — friendly stop
-  stamp_ok: "false"
-  stamp_error: ""
-  fe_next: ""                  # filled when a frontend lane is declared — the plan-ui handoff
-  source_csv: ""               # concept-paths — the feature's source files, as a PATH LIST
-  source_count: "0"            # 0 ⇒ greenfield: no code realises this feature yet
-  okf_concept: ""              # the feature's OKF concept doc (use-case log, source map)
-  if_ok: "true"                # log-append — the interface publication
-  if_error: ""
-  if_appended: "0"
-  if_ids_csv: ""
-  if_unknown_csv: ""
-  if_badsup_csv: ""
+  be_lane_id: ""
+  fe_lane_id: ""
+  active_change: ""
+  has_change: "false"
+  version: ""
+  # Per-lane authoring state. Each lane resolves its own mode; a lane that is not
+  # declared never resolves one and its steps never run.
+  be_mode: "skip"              # skip | bootstrap_gf | bootstrap_bf | update
+  fe_mode: "skip"              # skip | bootstrap_gf | bootstrap_bf | update
+  be_brownfield: "false"       # plan-scaffold.override_active — onboard installed the code-derived template
+  fe_brownfield: "false"
+  be_created: "false"          # plan-scaffold.created — true ⇒ the document was ABSENT ⇒ bootstrap
+  fe_created: "false"
+  be_migrated: "false"         # a legacy design.md was renamed into backend-plan.md this run
+  fe_migrated: "false"
+  backend_plan: ""
+  frontend_plan: ""
+  # PER-LANE BRANCH FLAGS. A lane is either NEW (declared, and its master was just
+  # scaffolded ⇒ bootstrap it) or EXISTING (declared, and its master was already there ⇒
+  # its change goes through the delta module). The engine has no compound conditions, so
+  # each AND is computed as one ordered assignment.
+  #
+  # BOTH CAN BE TRUE IN ONE RUN, and that case is real: declaring a frontend lane on a
+  # feature that already has a backend plan bootstraps the frontend master (from the whole
+  # spec — nothing is missing from it) while the backend half of the change is a delta.
+  be_new: "false"
+  be_existing: "false"
+  fe_new: "false"
+  fe_existing: "false"
+  be_update: "false"           # this lane has a master AND the re-derivation was confirmed
+  fe_update: "false"
+  # WHAT THIS RUN IS POINTED AT, and how it was answered. plan_target is the menu's
+  # answer; master_exists is what makes the menu appear at all.
+  master_exists: "false"       # a DECLARED lane's master plan was already on disk
+  plan_target: "main"          # main | delta — the answer to the one question this phase asks
+  plan_choice: ""              # the raw selection (a label): the MAIN row, a change, or the NEW row
+  main_label: ""               # cr-list --include-main's exact label, to test the selection against
+  new_label: ""                # cr-list --include-new's
+  open_new: "false"            # the NEW row was chosen ⇒ open a plan-only change before planning it
+  has_changes: "false"
+  rederive_needed: "false"     # main was chosen on a feature that already has masters
+  rederive: "false"            # …and the rewrite was confirmed
+  plan_mode: "bootstrap"       # bootstrap | rederive | delta — reported, not branched on
+  domain_model: ""
+  domain_model_exists: "false"
+  source_files: []             # the feature's real source files, from its OKF concept
+  source_count: "0"
 
 workflow:
 
-  # 0. TECHNICAL rule files → sticky standards (configuration, not hardcoded).
-  #    tech-select reads tech-rule-bindings.md under "## /aw-spec-plan". No blocking
-  #    gate: an unconfigured project soft-continues (constitution.technical.md still
-  #    carries the tech base).
-  - id: tech_select
-    action: include
-    module: .appweaver/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-plan }
-
-  # 1. The BACKEND LANE MUST EXIST. This phase writes a service design document, so
-  #    it asks the declaration whether there is a service lane at all — not the
-  #    lane-gate module, whose on-disk check would refuse a greenfield project that
-  #    has declared `src/` but not scaffolded it yet. A plan is authored before the
-  #    code exists; that is the point of planning. Two distinct refusals (the
-  #    evaluator takes single comparisons only, so the message is picked by an
-  #    ordered set): nothing declared at all, vs a frontend-only project.
+  # 0. WHICH LANES EXIST. lane-resolve reads the declaration only — it does NOT check the
+  #    source path on disk, unlike the lane-gate module, because a plan is authored BEFORE
+  #    the code exists. That is the point of planning.
   - id: lane_resolve
     action: execute_script
     on_error: continue      # never crash raw on an undeclared lane — the gate below explains it
     script: { ref: actions }
     subcommand: lane-resolve
     outputs:
-      - { name: lanes_declared, from: "$.declared" }
-      - { name: be_declared,    from: "$.backend_declared" }
-      - { name: fe_declared,    from: "$.frontend_declared" }
-  - id: lane_msg_frontend_only
-    condition: "{{fe_declared}} == true"
-    action: set
-    vars: { be_gate_msg: "Frontend-only project: a frontend lane is declared in .appweaver/stacks.json, a backend lane is not. There is no service to plan here, and authoring backend-plan.md anyway would invent one. Run /appweaver plan-ui for frontend-plan.md; if a service lane does exist, declare it with /appweaver select-stack and re-run plan." }
-  - id: require_backend_lane
+      - { name: lanes_declared,  from: "$.declared" }
+      - { name: be_declared,     from: "$.backend_declared" }
+      - { name: be_lane_id,      from: "$.backend_lane_id" }
+      - { name: be_language,     from: "$.backend_language" }
+      - { name: be_root,         from: "$.backend_source_path" }
+      - { name: fe_declared,     from: "$.frontend_declared" }
+      - { name: fe_lane_id,      from: "$.frontend_lane_id" }
+      - { name: fe_language,     from: "$.frontend_language" }
+      - { name: fe_root,         from: "$.frontend_source_path" }
+
+  - id: require_lane
     action: verify_context
-    require_true: be_declared
+    require_true: lanes_declared
     on_false: stop
-    on_false_message: "{{be_gate_msg}}"
-  - id: fe_handoff
+    on_false_message: "No lane is declared in .appweaver/stacks.json, so there is nothing to plan. Run /appweaver select-stack and declare the backend stack, the frontend stack, or both — plus each one's source path — then re-run plan. The declaration is what tells this phase which documents to write; a plan written against no declared stack invents its own."
+
+  # 1. TECHNICAL rule files → sticky standards (configuration, not hardcoded).
+  #    The service lane's set is loaded under `## /aw-spec-plan`; the frontend lane's under
+  #    `## /aw-spec-plan-ui`, and ONLY when that lane is declared — so a backend-only
+  #    project's standards are exactly what they were before the two commands merged.
+  #    No blocking gate: an unconfigured project soft-continues (the constitutions still
+  #    carry each lane's ratified base).
+  - id: tech_select
+    condition: "{{be_declared}} == true"
+    action: include
+    module: .appweaver/orchestrator/modules/tech-select.orch.yaml
+    with: { command: aw-spec-plan }
+
+  - id: tech_select_ui
     condition: "{{fe_declared}} == true"
-    action: set
-    vars: { fe_next: "A frontend lane is declared — run /appweaver plan-ui to author/refresh frontend-plan.md against this same spec version." }
+    action: include
+    module: .appweaver/orchestrator/modules/tech-select.orch.yaml
+    with: { command: aw-spec-plan-ui }
 
   # 2. Resolve the current feature and require its spec.
   - id: feature_paths
@@ -179,10 +219,25 @@ workflow:
     script: { ref: actions }
     subcommand: feature-paths
     outputs:
+      - { name: feature,     from: "$.feature" }
       - { name: feature_dir, from: "$.feature_dir" }
       - { name: spec_file,   from: "$.spec_file" }
       - { name: spec_exists, from: "$.spec_exists" }
 
+  # The BOUNDED CONTEXT's domain model — where the aggregate root, its entities and its
+  # invariants (BR-n) live. The spec cites them by id; this phase records where each is
+  # ENFORCED, so the model has to be in context or the instruction to "follow it exactly"
+  # has nothing to follow.
+  - id: context_paths
+    action: execute_script
+    on_error: continue
+    script: { ref: actions }
+    subcommand: context-paths
+    outputs:
+      - { name: context,             from: "$.context" }
+      - { name: domain_model,        from: "$.domain_model" }
+      - { name: domain_model_exists, from: "$.domain_model_exists" }
+
   - id: require_feature
     action: verify_context
     require_non_empty: feature_dir
@@ -195,109 +250,246 @@ workflow:
     on_false: stop
     on_false_message: "No spec.md for the current feature. Run /appweaver specify first."
 
-  # 3. The spec's own ledger tripwire. A plan derived from an unratified contract is
-  #    conformance theatre: an edit that skipped the Change History has no version, so
-  #    the derivation stamp this run writes would claim a baseline the ledger cannot
-  #    name. spec-check's only ok:false is exactly that case.
-  - id: spec_guard
-    action: include
-    module: .appweaver/orchestrator/modules/spec-state-gate.orch.yaml
-    with: { command: "/appweaver plan" }
+  # 3. Read the open change state (set by specify). The delta path uses it to decide
+  #    whether there is anything to plan at all.
+  - id: read_change
+    action: execute_script
+    script: { ref: actions }
+    subcommand: version-read
+    args: ["--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: active_change, from: "$.active_change" }
+      - { name: has_change,    from: "$.has_change" }
+      - { name: version,       from: "$.version" }
 
-  # 4. Scaffold backend-plan.md (idempotent). --lane backend resolves the pair
-  #    design-template → backend-plan.md, and MIGRATES a legacy design.md by renaming
-  #    it (created=false, migrated=true) — one document, never two side by side.
-  - id: plan_scaffold
+  # 4. THE FEATURE'S REAL SOURCE FILES, from its OKF concept. A plan over an existing
+  #    codebase has to conform to the shape that is actually there; the paths arrive as a
+  #    LIST and the authoring steps declare `tools: Read`, because a legacy tree does not
+  #    fit in a payload. Read-only, exits 0 with paths=[] when there is no concept yet —
+  #    source_count 0 IS the greenfield case, and the phase never blocks on it.
+  - id: concept_paths
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: concept-paths
+    args: ["--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: source_files, from: "$.paths" }
+      - { name: source_count, from: "$.count" }
+
+  # 5. Scaffold each DECLARED lane's plan (idempotent — returns the existing path when it
+  #    already exists, and RENAMES a legacy design.md / design.ui.md into the plan name).
+  - id: be_scaffold
+    condition: "{{be_declared}} == true"
     action: execute_script
     script: { ref: actions }
-    subcommand: design-scaffold
+    subcommand: plan-scaffold
     args: ["--feature-dir", "{{feature_dir}}", "--lane", "backend"]
     outputs:
-      - { name: plan_doc,        from: "$.design_doc" }
-      - { name: brownfield_plan, from: "$.override_active" }   # true ⇒ onboard installed the code-derived template
-      - { name: plan_created,    from: "$.created" }           # true ⇒ the doc was ABSENT (just scaffolded) ⇒ bootstrap
-      - { name: plan_migrated,   from: "$.migrated" }          # true ⇒ a legacy design.md became backend-plan.md this run
-
-  # 4a. Resolve the MODE (ordered override — the evaluator has no compound
-  #     conditions): greenfield default; the code-derived override flips it; an
-  #     EXISTING document flips either into an update.
-  - id: mode_brownfield
-    condition: "{{brownfield_plan}} == true"
+      - { name: backend_plan,  from: "$.plan_doc" }
+      - { name: be_brownfield, from: "$.override_active" }   # true ⇒ onboard installed the code-derived template
+      - { name: be_created,    from: "$.created" }           # true ⇒ the document was ABSENT ⇒ bootstrap
+      - { name: be_migrated,   from: "$.migrated" }          # true ⇒ a legacy design.md was renamed into place
+
+  - id: fe_scaffold
+    condition: "{{fe_declared}} == true"
+    action: execute_script
+    script: { ref: actions }
+    subcommand: plan-scaffold
+    args: ["--feature-dir", "{{feature_dir}}", "--lane", "frontend"]
+    outputs:
+      - { name: frontend_plan, from: "$.plan_doc" }
+      - { name: fe_brownfield, from: "$.override_active" }
+      - { name: fe_created,    from: "$.created" }
+      - { name: fe_migrated,   from: "$.migrated" }
+
+  # 5a. Self-detect NEW-vs-EXISTING per lane, from each plan document's OWN existence
+  #     (symmetric with specify's spec.md trigger). A scaffold reports created=true only
+  #     when it had to CREATE the document, so created=false on a DECLARED lane means the
+  #     plan pre-existed and that lane's change is a delta.
+  #     A MIGRATED document counts as pre-existing: it is the same plan under its new
+  #     name, and its content was authored before this run.
+  #     Taking the lane's own `declared` value under the created/not-created condition is
+  #     how the AND is expressed — an undeclared lane's flags stay false either way.
+  - id: be_flag_new
+    condition: "{{be_created}} == true"
+    action: set
+    vars: { be_new: "{{be_declared}}" }
+  - id: be_flag_existing
+    condition: "{{be_created}} == false"
     action: set
-    vars: { plan_mode: "bootstrap_bf" }
-  - id: mode_update
-    condition: "{{plan_created}} == false"
+    vars: { be_existing: "{{be_declared}}" }
+  - id: fe_flag_new
+    condition: "{{fe_created}} == true"
     action: set
-    vars: { plan_mode: "update" }
+    vars: { fe_new: "{{fe_declared}}" }
+  - id: fe_flag_existing
+    condition: "{{fe_created}} == false"
+    action: set
+    vars: { fe_existing: "{{fe_declared}}" }
+
+  # Either declared lane having a pre-existing master means this feature HAS BEEN PLANNED
+  # ONCE. That is the precondition for both of the things the menu below offers — a delta
+  # has to have a master to be a delta OF, and a re-derivation has to have a document to
+  # re-derive. The two raises are independent so neither can cancel the other.
+  - id: master_exists_backend
+    condition: "{{be_existing}} == true"
+    action: set
+    vars: { master_exists: "true" }
+  - id: master_exists_frontend
+    condition: "{{fe_existing}} == true"
+    action: set
+    vars: { master_exists: "true" }
 
-  # 5. Tracking. plan-check diffs the doc's derivation record against the spec's
-  #    ledger: WHAT moved since this plan was derived (the update's exact work list),
-  #    and whether the doc itself was hand-edited since its stamp.
-  - id: plan_track
+  # ═════════════ 5b. WHAT IS BEING PLANNED — ONE QUESTION, ASKED ONCE ═════════
+  # The same opening `implement` has: list what is open, ask which one, activate it. The
+  # difference is that this phase can also be pointed at the feature's OWN spec, so the
+  # menu carries two synthetic options alongside the open changes (cr-list --include-main
+  # / --include-new):
+  #   main · re-plan the master from spec.md + domain-model.md
+  #   CR-…  · author THAT change's delta plans          (one row per open change, by wave)
+  #   new  · open a plan-only change — a refactor or architectural decision with no spec
+  #          delta. This is the path that used to be taken AUTOMATICALLY whenever a master
+  #          existed and no change was open; it is now something you ask for, because
+  #          "re-plan the master" and "open a refactor change" were never the same intent.
+  #
+  # ONLY WHEN THERE IS A MASTER. With no master yet there is nothing to choose: a delta
+  # needs one to be a delta of, and so does a plan-only change. So a first run authors the
+  # masters with no prompt at all, exactly as before — and if a change is already open on
+  # such a feature, it waits for the next run, when the menu will offer it.
+  - id: cr_list
+    condition: "{{master_exists}} == true"
     action: execute_script
     script: { ref: actions }
-    subcommand: plan-check
-    args: ["--feature-dir", "{{feature_dir}}", "--doc", "{{plan_doc}}"]
+    subcommand: cr-list
+    args: ["--feature-dir", "{{feature_dir}}", "--preselect", "{{USER_INPUT}}", "--include-main", "--include-new"]
+    outputs:
+      - { name: change_options, from: "$.select_options" }
+      - { name: matched_label,  from: "$.matched_label" }
+      - { name: main_label,     from: "$.main_label" }
+      - { name: new_label,      from: "$.new_label" }
+      - { name: has_changes,    from: "$.has_changes" }
+      - { name: change_count,   from: "$.count" }
+
+  # The argument doubles as the answer: `plan main` and `plan CR-…` both resolve to a
+  # label in matched_label and skip the prompt. Only the WHOLE argument counts as one of
+  # the synthetic words, so ordinary guidance prose ("new caching layer") never selects.
+  - id: pick_target
+    condition: "{{master_exists}} == true"
+    action: user_select
+    prompt: "What is being planned? `main` re-plans the feature's master from its spec and domain model. A CR row authors that change's delta plans only, leaving the masters untouched — deltas sharing a wave are independent, and a higher wave is planned on top of the lower ones. `new` opens a plan-only change, for a refactor or architectural decision with no spec delta."
+    options_from_variable: change_options
+    preselect_from: matched_label
+    single_option_confirm: true
     outputs:
-      - { name: track_state,     from: "$.state" }
-      - { name: derived_version, from: "$.derived_version" }
-      - { name: current_version, from: "$.current_version" }
-      - { name: changed_csv,     from: "$.changed_csv" }
-      - { name: changed_summary, from: "$.changed_summary" }
-
-  # 5a. Hand-edit fence (LOUD, and unblockable by design): a hash mismatch means the
-  #     document moved outside this workflow. Refuse — unless accept_manual:true asks
-  #     the update to fold the edits in, which keeps their intent, reconciles them
-  #     with the spec, and re-baselines at the stamp.
-  - id: manual_flag_edited
-    condition: "{{track_state}} == edited"
+      - { name: plan_choice, from: selection }
+
+  # 5c. The answer, RAISED then KNOCKED DOWN. Anything that is not the MAIN row is a
+  #     change — either an existing one or the NEW row, which is the same path plus a
+  #     cr-setup.
+  #
+  #     THE KNOCKDOWN IS NOT DECORATIVE. When the menu never ran, plan_choice and both
+  #     labels are empty, and the engine's conditions compare RENDERED STRINGS: "" == ""
+  #     is TRUE, so the NEW test fires on a feature that has no menu, no changes and no
+  #     master. Without the knockdown a first `plan` run opens a stray plan-only change
+  #     before authoring its first master. master_exists is exactly "the menu ran", so it
+  #     is what restores the first-run defaults.
+  - id: target_delta
+    condition: "{{plan_choice}} != {{main_label}}"
     action: set
-    vars: { manual_ok: "false" }
-  - id: manual_flag_edited_behind
-    condition: "{{track_state}} == edited_behind"
+    vars: { plan_target: "delta", plan_mode: "delta" }
+  - id: target_new
+    condition: "{{plan_choice}} == {{new_label}}"
     action: set
-    vars: { manual_ok: "false" }
-  - id: manual_accept
-    condition: "{{ACCEPT_MANUAL}} == true"
+    vars: { open_new: "true" }
+  - id: target_no_menu
+    condition: "{{master_exists}} == false"
     action: set
-    vars: { manual_ok: "true" }
-  - id: manual_fence
-    action: verify_context
-    require_true: manual_ok
-    on_false: stop
-    on_false_message: "backend-plan.md was hand-edited since its last stamp (tracking state: {{track_state}}). Re-run plan with accept_manual:true to fold the edits in (kept, reconciled with the spec, recorded in the ledgers, re-baselined) — or restore the document to its stamped state."
+    vars: { plan_target: "main", plan_mode: "bootstrap", open_new: "false" }
 
-  # 5b. Idempotence: an update with nothing to update stops here, friendly.
-  - id: clean_flag
-    condition: "{{track_state}} == clean"
+  # ═════════ 5d. RE-DERIVING A MASTER IS CONFIRMED, NOT ASSUMED ══════════════
+  # `main` on a feature that has never been planned is a bootstrap: there is no document
+  # to lose, and nothing is asked. `main` on a feature that HAS one is a REWRITE of a
+  # long-lived, hand-edited document, so it is confirmed first and the run stops on a
+  # decline. The options are ordered no-first deliberately, against this kit's usual
+  # yes-first convention: an unattended run takes the first option, and the safe default
+  # for "rewrite the plan this team has been maintaining" is to decline and say so.
+  - id: rederive_needed_set
+    condition: "{{plan_target}} == main"
     action: set
-    vars: { plan_stale: "false" }
-  - id: clean_stop
+    vars: { rederive_needed: "{{master_exists}}" }
+
+  - id: confirm_rederive
+    condition: "{{rederive_needed}} == true"
+    action: ask
+    prompt: "This feature already has master plan(s). Re-derive them from the current spec.md and domain-model.md? Recorded architectural decisions (DA-n) and workarounds (WA-n) are carried forward, but any section the spec and model no longer support IS REWRITTEN — including hand edits. Answer no to stop without touching them."
+    options: ["no", "yes"]
+    answer_var: rederive_answer
+
+  - id: rederive_go
+    condition: "{{rederive_answer}} == yes"
+    action: set
+    vars: { rederive: "true", plan_mode: "rederive" }
+
+  - id: require_rederive_confirm
+    condition: "{{rederive_needed}} == true"
     action: verify_context
-    require_true: plan_stale
+    require_true: rederive
     on_false: stop
-    on_false_message: "backend-plan.md is in step with spec {{current_version}} — nothing to update. If the PLAN is wrong and the spec is right, hand-edit backend-plan.md and re-run /appweaver plan with accept_manual: true — that is what tells this command to keep the edit's intent and reconcile it rather than treat it as drift; without the flag the manual fence stops the run after the edit is already on disk."
-
-  # 5b. THE CODE. The plan is an architectural confirmation, so it must know what the
-  #     feature already looks like on disk: concept-paths resolves the feature's OKF
-  #     concept to the source files realising it, and the authoring steps declare
-  #     `tools: Read` so they can open the ones that matter. A PATH LIST, not inlined
-  #     content — a real codebase does not fit a payload (E60). on_error: continue,
-  #     because a greenfield feature has no concept doc and must not be blocked by it:
-  #     source_count 0 is the greenfield signal the tasks read.
-  - id: concept_paths
-    action: execute_script
-    on_error: continue
-    script: { ref: xref }
-    subcommand: concept-paths
-    args: ["--feature-dir", "{{feature_dir}}"]
-    outputs:
-      - { name: source_csv,   from: "$.csv" }
-      - { name: source_count, from: "$.count" }
-      - { name: okf_concept,  from: "$.concept" }
+    on_false_message: "Stopped — the master plans were left untouched. Re-run and answer yes to re-derive them, or pick a change instead (/appweaver plan CR-…) to author that change's delta plans without touching a master."
 
-  # 6. Pre-execution hooks. (Phase keys keep their historical names — they are the
-  #    hooks CONFIG contract, orthogonal to the command's name.)
+  # 5e. Resolve each lane's authoring MODE. Four ordered assignments per lane: the
+  #     greenfield default for a new lane, the code-derived override replacing it, a
+  #     `skip` for any lane that is not new — which silences both bootstrap branches on
+  #     the delta path without needing a compound condition — and finally `update` for a
+  #     lane whose master exists on a CONFIRMED re-derivation. The raise-then-test pair is
+  #     how "this lane has a master AND the re-derivation was confirmed" is expressed.
+  #
+  #     A re-derivation has no greenfield/brownfield split: both bootstrap branches differ
+  #     only in WHICH TEMPLATE supplies the section structure, and in update mode the
+  #     structure is the existing document's own.
+  - id: be_mode_gf
+    condition: "{{be_new}} == true"
+    action: set
+    vars: { be_mode: "bootstrap_gf" }
+  - id: be_mode_bf
+    condition: "{{be_brownfield}} == true"
+    action: set
+    vars: { be_mode: "bootstrap_bf" }
+  - id: be_mode_skip
+    condition: "{{be_new}} == false"
+    action: set
+    vars: { be_mode: "skip" }
+  - id: be_update_raise
+    condition: "{{be_existing}} == true"
+    action: set
+    vars: { be_update: "{{rederive}}" }
+  - id: be_mode_update
+    condition: "{{be_update}} == true"
+    action: set
+    vars: { be_mode: "update" }
+  - id: fe_mode_gf
+    condition: "{{fe_new}} == true"
+    action: set
+    vars: { fe_mode: "bootstrap_gf" }
+  - id: fe_mode_bf
+    condition: "{{fe_brownfield}} == true"
+    action: set
+    vars: { fe_mode: "bootstrap_bf" }
+  - id: fe_mode_skip
+    condition: "{{fe_new}} == false"
+    action: set
+    vars: { fe_mode: "skip" }
+  - id: fe_update_raise
+    condition: "{{fe_existing}} == true"
+    action: set
+    vars: { fe_update: "{{rederive}}" }
+  - id: fe_mode_update
+    condition: "{{fe_update}} == true"
+    action: set
+    vars: { fe_mode: "update" }
+
+  # 6. Pre-execution hooks.
   - id: resolve_pre_hooks
     action: execute_script
     script: { ref: actions }
@@ -309,70 +501,61 @@ workflow:
     action: dispatch_hooks
     hooks_from_variable: before_hooks
 
-  # ══════════════════ BOOTSTRAP (GREENFIELD) — author the master ══════════════
-  # Author the whole HLD in one pass: all four layers as sections, tech-agnostic,
-  # traced to the spec. build_context REPLACES the per-request envelope; sticky
-  # standards stay prepended. The ENGINE writes plan_doc; plan-stamp then baselines it.
-  - id: ctx_plan
-    condition: "{{plan_mode}} == bootstrap_gf"
+  # ═══════════ BACKEND LANE — bootstrap, greenfield four-layer template ═══════
+  # Author the whole HLD in one pass: all four layers as sections, tech-agnostic, traced
+  # to the spec. build_context REPLACES the per-request envelope; sticky standards stay
+  # prepended. The ENGINE writes backend_plan.
+  - id: ctx_backend
+    condition: "{{be_mode}} == bootstrap_gf"
     action: build_context
     context:
-      - { path: "{{plan_doc}}" }                # the copied template = section structure
-      - { path: "{{spec_file}}" }               # the source of truth (FR/BR/CN/DC/IC/SC)
+      - { path: "{{backend_plan}}" }            # the copied template = section structure
+      - { path: "{{spec_file}}" }               # BEHAVIOUR: FR/CN/DC/IC/US/SC + cited BR ids
+      - { path: "{{domain_model}}", optional: true }   # the CONTEXT's canonical model — entities, invariants, boundary
       - { path: .appweaver/DESIGN-FORMAT.md }      # the HLD contract
-      - { path: "{{feature_dir}}/interfaces.md", optional: true }   # the published surface — cite these IF- ids in §3; absent on a first run
-      - { path: "{{okf_concept}}", optional: true }                 # the feature's OKF concept: use-case log + source map
-      - { path: .appweaver/memory/constitution.technical.md, optional: true } # technology base ONLY — no domain (domain enters via the spec)
-  - id: gen_plan
-    condition: "{{plan_mode}} == bootstrap_gf"
+      - { path: .appweaver/memory/constitution.technical.md, optional: true } # technology base ONLY — no domain (domain enters via the spec + model)
+  - id: gen_backend
+    condition: "{{be_mode}} == bootstrap_gf"
     action: agent_author
-    tools: Read   # the current code arrives as {{source_csv}} paths, not inlined
-    output_target: { type: file, path: "{{plan_doc}}" }
+    tools: Read   # the feature's EXISTING source arrives as {{source_files}} paths, not inlined
+    output_target: { type: file, path: "{{backend_plan}}" }
     task: |
-      Author the MASTER service plan (the target backend-plan.md in context) for this
-      aggregate by filling out the template, based on the feature spec + the loaded
-      technical/architecture standards. This is the MEDIATOR between the spec and the
-      generated code. Guidance: {{USER_INPUT}}
+      Author the MASTER service-lane plan (the target backend-plan.md in context) for this
+      aggregate by filling out the template, based on the feature spec + the context's
+      domain model + the loaded technical/architecture standards. This is the MEDIATOR
+      between the spec and the generated code. Guidance: {{USER_INPUT}}
       Rules:
-      - THE SPEC IS THE ONLY DOMAIN INPUT. You have the spec + technical standards, and
-        NO domain rule files. The domain arrives as spec ids only — realise them, and
-        invent no domain rule the spec omits (an unavoidable new concept → §7 DA-n).
-      - THE CODE IS THE WHAT-EXISTS AUTHORITY, and it is a DIFFERENT authority from the
-        spec. {{source_count}} source file(s) realise this feature today; read the
-        ones that bear on the structure you are deciding, and ADJUST this plan to the
-        shape that is actually there rather than to an idealised one. An empty list is
-        greenfield — design from a clean slate and say so. The code NEVER overrides the
-        spec on behaviour and may not introduce a domain rule the spec omits: code that
-        contradicts the spec is reported (§7 DA-n) and designed to the SPEC, never
-        quietly blessed. A deliberate divergence from the as-built shape is a §8 WA-n
-        with its revisit trigger.
-          {{source_csv}}
-      - THE PUBLISHED SURFACE IS CITED, NOT RESTATED. Every endpoint, published event
-        and externally consumed contract belongs to `interfaces.md`, the feature's
-        append-only interface log — the anchor /appweaver plan-ui and the FE story
-        designs read. §3 here is the INDEX: cite the IF- id of an interface the log
-        already carries (it is in context on an update run), and for one being
-        published for the FIRST time write a one-line description with `(this run)` in
-        the id cell. NEVER invent an IF- number — the script is the only id authority,
-        and a later step publishes what you describe. Changing a published interface
-        means a SUPERSEDING entry, never an edit to an existing one.
+      - THE SPEC AND THE DOMAIN MODEL ARE THE ONLY DOMAIN INPUTS. You have them plus the
+        technical standards, and NO domain rule files. Realise what they state, and invent
+        no domain rule they omit (an unavoidable new concept → §7 DA-n).
+      - THE DOMAIN LAYER (§1) MUST FOLLOW THE CONTEXT'S DOMAIN MODEL EXACTLY: entities &
+        value objects are its `## Aggregate:` section's entities (SAME names), invariants
+        are its BR-nnn (cite each, never restate), the aggregate boundary is its Boundary
+        block, and states are the lifecycle it describes. The model — not the spec — is
+        where those facts live; the spec cites them by id. This document records WHERE
+        each invariant is ENFORCED, never what it says. Elaborate with domain events /
+        state machines / behaviour signatures ONLY to realise spec behaviour; do NOT
+        invent or contradict. Any unavoidable new concept goes in §7 as a DA-n.
+      - THE CODE THAT EXISTS IS THE WHAT-IS AUTHORITY. {{source_count}} source file(s)
+        already realise this feature: {{source_files}}. READ them before planning and
+        CONFORM to the shape that is there — its module boundaries, its naming, its
+        seams. The spec stays the only authority on BEHAVIOUR; the code is the authority
+        on what the structure currently IS. With no source files this is a greenfield
+        feature and there is nothing to conform to.
       - Cover the four layers as sections: Domain (§1), Application (§2), API (§3),
         Infrastructure (§4). Keep the template's section order and headings.
-      - The DOMAIN layer (§1) MUST follow spec.md EXACTLY: entities & value objects
-        are the spec's Key Entities (SAME names), invariants are the spec's Business
-        Rules (BR-nnn — cite each), the aggregate boundary is the spec's Aggregate
-        Boundary, and states are the lifecycle the spec describes. Elaborate with
-        domain events / state machines / behaviour signatures ONLY to realise spec
-        behaviour; do NOT invent or contradict. Any unavoidable new concept goes in
-        §7 as a DA-n assumption.
       - REALISE THE LIFTED CONSTRAINTS (each cites its spec id):
         • Constraints & NFRs (CN-) → structural ones (immutability, append-only audit,
-          no-hard-delete) as §1 invariants/events; retention/performance/audit as §5
-          Cross-Cutting rows or §4 persistence.
+          no-hard-delete) as §1 invariant enforcement/events; retention/performance/audit
+          as §5 Cross-Cutting rows or §4 persistence.
         • Data Classification (DC-) → §5 data-protection + the §2/§3 projection surface
           (what MUST NOT be exposed in API/logs/traces).
         • Integration Contracts (IC-) → §4.2 External integrations (one port/adapter row
           per IC-), realising the obligation the spec named.
+      - PUBLISH THE SURFACE THE FRONTEND LANE BINDS TO. §3 states each endpoint's contract
+        as field shapes. That section is the ONLY part of this document the frontend plan
+        may read; keep it complete and self-contained, because a contract the UI needs and
+        this document never states becomes a client-side workaround.
       - CONSTITUTION-MANDATED CROSS-CUTTING (from the loaded technical constitution, NOT
         the spec): a NON-NEGOTIABLE technical principle you must apply that has NO
         per-feature spec id. APPLY it (it is non-negotiable), and because it is not
@@ -385,73 +568,52 @@ workflow:
         conceptual types. The stack is bound only at `implement` time. Do NOT include
         code-generation mechanics or the layering/dependency rule — those are
         solution-wide rules applied in `implement` / the constitution, not per feature.
-      - Every plan element traces UP to a spec id (FR-/BR-/CN-/DC-/IC-/SC-); the whole
-        spec traces DOWN — fill §6 Traceability completely, with a row for EVERY
-        CN-/DC-/IC- so no lifted constraint is silently dropped. NO STORY IDS ANYWHERE:
-        this plan traces to requirements, which is what keeps it stable while the
-        backlog churns.
+      - Every plan element traces UP to a spec id (FR-/BR-/CN-/DC-/IC-/US-/SC-); the
+        whole spec traces DOWN — fill §6 Traceability completely, with a row for EVERY
+        CN-/DC-/IC- so no lifted constraint is silently dropped.
       - Fill the two ledgers: §7 Assumptions (DA-n, to clarify later) and §8
         Workarounds (WA-n, to clear later). Empty → "None (as of v1.0)".
       - Physical persistence schema is OUT OF SCOPE (defer to the technical-data-model).
-      - LEAVE the template's initial Change History row as it stands and write NO
-        version anywhere — plan-stamp owns the **Version** header and every row.
+      - This is v1.0: set the initial Change History row + keep US-1's mapping.
       - Omit a LAYER section only if the aggregate genuinely has nothing there
         (state why); never write "N/A". No complete code anywhere.
 
-  # ═══════ BOOTSTRAP (BROWNFIELD) — code-derived template, NEW feature, no adopt ═══
-  # Same contract as the greenfield bootstrap (tech-agnostic HLD, spec is the only
-  # domain input, full §Traceability + the two ledgers), with ONE difference: the plan
-  # STRUCTURE follows the code-derived brownfield template + the project's AS-BUILT
-  # architecture, not the fixed four layers — so a new feature added to an existing
-  # repo is consistent with the code already there. Runs only when onboard generated
-  # the code-derived design-template override (plan_mode == bootstrap_bf).
-  - id: ctx_plan_brownfield
-    condition: "{{plan_mode}} == bootstrap_bf"
+  # ═══ BACKEND LANE — bootstrap, brownfield code-derived template, NEW feature ═══
+  # Same contract as the greenfield bootstrap above (tech-agnostic HLD, spec + model are
+  # the only domain inputs, full §Traceability + the two ledgers), with ONE difference:
+  # the STRUCTURE follows the code-derived template + the project's AS-BUILT architecture,
+  # not the fixed four layers — so a new feature added to an existing repo is consistent
+  # with the code already there. Runs only when onboard generated the override.
+  - id: ctx_backend_brownfield
+    condition: "{{be_mode}} == bootstrap_bf"
     action: build_context
     context:
-      - { path: "{{plan_doc}}" }                # the scaffolded BROWNFIELD template = code-derived section structure
-      - { path: "{{spec_file}}" }               # the source of truth (FR/BR/CN/DC/IC/SC)
+      - { path: "{{backend_plan}}" }            # the scaffolded BROWNFIELD template = code-derived section structure
+      - { path: "{{spec_file}}" }               # BEHAVIOUR: FR/CN/DC/IC/US/SC + cited BR ids
+      - { path: "{{domain_model}}", optional: true }   # the CONTEXT's canonical model — entities, invariants, boundary
       - { path: .appweaver/DESIGN-FORMAT.md }      # the HLD contract (see its Brownfield variant note)
-      - { path: "{{feature_dir}}/interfaces.md", optional: true }   # the published surface — cite these IF- ids in §3; absent on a first run
-      - { path: "{{okf_concept}}", optional: true }                 # the feature's OKF concept: use-case log + source map
       - { path: knowledge/architecture/overview.md, optional: true }  # the project's AS-BUILT architecture (onboard) — align to it
       - { path: knowledge/architecture/platform.md, optional: true }  # the as-built technology base / cross-cutting reality
-      - { path: .appweaver/memory/constitution.technical.md, optional: true } # technology base ONLY — no domain (domain enters via the spec)
-  - id: gen_plan_brownfield
-    condition: "{{plan_mode}} == bootstrap_bf"
+      - { path: .appweaver/memory/constitution.technical.md, optional: true } # technology base ONLY — no domain
+  - id: gen_backend_brownfield
+    condition: "{{be_mode}} == bootstrap_bf"
     action: agent_author
-    tools: Read   # the current code arrives as {{source_csv}} paths, not inlined
-    output_target: { type: file, path: "{{plan_doc}}" }
+    tools: Read   # the feature's EXISTING source arrives as {{source_files}} paths, not inlined
+    output_target: { type: file, path: "{{backend_plan}}" }
     task: |
-      Author the MASTER service plan (the target backend-plan.md in context — it is the
-      code-derived BROWNFIELD template) for this NEW feature being added to an EXISTING
-      codebase, by filling the template from the spec + the loaded technical/architecture
-      standards. It is the MEDIATOR between the spec and the code `implement` will
-      generate. Guidance: {{USER_INPUT}}
+      Author the MASTER service-lane plan (the target backend-plan.md in context — it is
+      the code-derived BROWNFIELD template) for this NEW feature being added to an EXISTING
+      codebase, by filling the template from the spec + the context's domain model + the
+      loaded technical/architecture standards. It is the MEDIATOR between the spec and the
+      code `implement` will generate. Guidance: {{USER_INPUT}}
       Rules:
-      - THE SPEC IS THE ONLY DOMAIN INPUT. You have the spec + technical standards + the
-        project's as-built architecture references, and NO domain rule files. The domain
-        arrives as spec ids only — realise them, invent no domain rule the spec omits (an
+      - THE SPEC AND THE DOMAIN MODEL ARE THE ONLY DOMAIN INPUTS. You have them plus the
+        technical standards and the project's as-built architecture references, and NO
+        domain rule files. Realise what they state, invent no domain rule they omit (an
         unavoidable new concept → a §5 DA-n assumption).
-      - THE CODE IS THE WHAT-EXISTS AUTHORITY, and it is a DIFFERENT authority from the
-        spec. {{source_count}} source file(s) realise this feature today; read the
-        ones that bear on the structure you are deciding, and ADJUST this plan to the
-        shape that is actually there rather than to an idealised one. An empty list is
-        greenfield — design from a clean slate and say so. The code NEVER overrides the
-        spec on behaviour and may not introduce a domain rule the spec omits: code that
-        contradicts the spec is reported (§5 DA-n) and designed to the SPEC, never
-        quietly blessed. A deliberate divergence from the as-built shape is a §6 WA-n
-        with its revisit trigger.
-          {{source_csv}}
-      - THE PUBLISHED SURFACE IS CITED, NOT RESTATED. Every endpoint, published event
-        and externally consumed contract belongs to `interfaces.md`, the feature's
-        append-only interface log — the anchor /appweaver plan-ui and the FE story
-        designs read. the EXTERNAL-facing §2 subsection here is the INDEX: cite the IF- id of an interface the log
-        already carries (it is in context on an update run), and for one being
-        published for the FIRST time write a one-line description with `(this run)` in
-        the id cell. NEVER invent an IF- number — the script is the only id authority,
-        and a later step publishes what you describe. Changing a published interface
-        means a SUPERSEDING entry, never an edit to an existing one.
+      - THE CODE THAT EXISTS IS THE WHAT-IS AUTHORITY. {{source_count}} source file(s)
+        already realise this feature: {{source_files}}. READ them and CONFORM to the shape
+        that is there.
       - STRUCTURE FOLLOWS THE TEMPLATE + THE PROJECT'S AS-BUILT ARCHITECTURE, NOT the four
         greenfield layers. Keep the template's own section order and headings (§0 Overview
         + ubiquitous language; §1 Architecture Context & Domain Model; §2 Component &
@@ -466,17 +628,20 @@ workflow:
         textbook layer gets its own section; a layer the feature does not need does NOT
         appear.
       - KEEP THE NEUTRAL ANCHORS (the template pins them): §1.2 is the domain/data MODEL
-        and MUST follow spec.md EXACTLY — entities & value objects are the spec's Key
-        Entities (SAME names), invariants are the spec's Business Rules (BR-nnn, cite
-        each), the boundary is the spec's Aggregate Boundary, states are its lifecycle;
-        cross-slice references-by-id live here. One §2 subsection is the EXTERNAL
-        INTEGRATIONS table (its heading contains "Integration") — one port/adapter row
-        per IC-, realising the obligation the spec named.
+        and MUST follow the CONTEXT'S DOMAIN MODEL EXACTLY — entities & value objects are
+        its aggregate section's entities (SAME names), invariants are its BR-nnn (cite
+        each and record WHERE each is enforced), the boundary is its Boundary block,
+        states are its lifecycle; cross-slice references-by-id live here. One §2
+        subsection is the EXTERNAL INTEGRATIONS table (its heading contains "Integration")
+        — one port/adapter row per IC-, realising the obligation the spec named.
       - REALISE THE LIFTED CONSTRAINTS (each cites its spec id): CN- → structural ones
-        (immutability, append-only audit, no-hard-delete) as §1.2 invariants/events;
-        retention/performance/audit as §2 persistence or §3 Cross-Cutting rows. DC- → §3
-        data-protection + the projection surface (what MUST NOT be exposed in
+        (immutability, append-only audit, no-hard-delete) as §1.2 invariant enforcement /
+        events; retention/performance/audit as §2 persistence or §3 Cross-Cutting rows.
+        DC- → §3 data-protection + the projection surface (what MUST NOT be exposed in
         API/logs/traces).
+      - PUBLISH THE SURFACE THE FRONTEND LANE BINDS TO: the section carrying this feature's
+        endpoints states each contract as field shapes, completely, because it is the only
+        part of this document the frontend plan may read.
       - CONSTITUTION-MANDATED CROSS-CUTTING (from the loaded technical constitution, NOT
         the spec): a NON-NEGOTIABLE technical principle with no per-feature spec id —
         APPLY it, and LOG it as a §5 DA-n whose basis cites the mandating principle
@@ -487,216 +652,369 @@ workflow:
         bound at `implement` time. Do NOT include code-generation mechanics or the
         layering/dependency rule (those are solution-wide / constitution rules).
       - Every plan element traces UP to a spec id; fill §4 Traceability completely (a
-        row for EVERY FR/BR/CN/DC/IC/SC so no lifted constraint is dropped). NO STORY
-        IDS ANYWHERE — this plan traces to requirements. Fill the
+        row for EVERY FR/BR/CN/DC/IC/US/SC so no lifted constraint is dropped). Fill the
         §5 Assumptions (DA-n) and §6 Deviations (WA-n) ledgers — "None (as of v1.0)" if
         empty. §6 records only genuine deviations, not "organised unlike a reference
         architecture" (that is the as-built shape, §1.1).
-      - LEAVE the template's initial Change History row as it stands and write NO
-        version anywhere — plan-stamp owns the **Version** header and every row.
-        Omit a section only if the feature genuinely has nothing there (state why); no
-        complete code anywhere.
-
-  # ══════════════════ UPDATE — conform the existing plan to the moved spec ═════
-  # The work list is COMPUTED, never guessed: the ledger rows above this plan's
-  # derivation stamp name exactly the ids to conform. Everything else stays
-  # byte-identical — the analyze gate reads an unrelated "improvement" as drift.
-  - id: ctx_plan_update
-    condition: "{{plan_mode}} == update"
+      - This is v1.0: set the initial Change History row + keep US-1's mapping. Omit a
+        section only if the feature genuinely has nothing there (state why); no complete
+        code anywhere.
+
+  # ═══════════ BACKEND LANE — RE-DERIVE an existing master ════════════════════
+  # `main` on a feature that already has a master. This is the operation finalize-delta's
+  # contract has always assumed exists: it merges a change's SPEC and MODEL halves and
+  # merges no lane plan, on the stated grounds that "a master plan is DERIVED from those
+  # two and is re-derived from them". This is where that re-derivation happens.
+  #
+  # IT REVISES, IT DOES NOT REFILL. The document in context is the CURRENT master, not a
+  # blank template, and it is the section structure — which is why this branch has no
+  # greenfield/brownfield split. Content that the spec and model still support survives
+  # verbatim; content they no longer support is rewritten; content they now require and
+  # the document lacks is added. Nothing is preserved on the grounds that it is already
+  # written: an element with no spec id behind it is exactly what the analyze-plan gate
+  # calls over-reach.
+  - id: ctx_backend_update
+    condition: "{{be_mode}} == update"
     action: build_context
     context:
-      - { path: "{{plan_doc}}" }                # the CURRENT plan — the document being conformed
-      - { path: "{{spec_file}}" }               # the source of truth at {{current_version}}
-      - { path: .appweaver/DESIGN-FORMAT.md }      # the HLD contract
-      - { path: "{{feature_dir}}/interfaces.md", optional: true }   # the published surface — cite these IF- ids in §3; absent on a first run
-      - { path: "{{okf_concept}}", optional: true }                 # the feature's OKF concept: use-case log + source map
-      - { path: knowledge/architecture/overview.md, optional: true }   # brownfield repos: the as-built architecture
-      - { path: knowledge/architecture/platform.md, optional: true }
-      - { path: .appweaver/memory/constitution.technical.md, optional: true }
-  - id: gen_plan_update
-    condition: "{{plan_mode}} == update"
+      - { path: "{{backend_plan}}" }                   # the CURRENT master = what is being revised, and its section structure
+      - { path: "{{spec_file}}" }                      # BEHAVIOUR, carrying every change finalize-delta has merged
+      - { path: "{{domain_model}}", optional: true }   # the CONTEXT's canonical model — entities, invariants, boundary
+      - { path: .appweaver/DESIGN-FORMAT.md }          # the HLD contract
+      - { path: .appweaver/memory/constitution.technical.md, optional: true } # technology base ONLY
+  - id: gen_backend_update
+    condition: "{{be_mode}} == update"
     action: agent_author
-    tools: Read   # the current code arrives as {{source_csv}} paths, not inlined
-    output_target: { type: file, path: "{{plan_doc}}" }
+    tools: Read   # the feature's EXISTING source arrives as {{source_files}} paths, not inlined
+    output_target: { type: file, path: "{{backend_plan}}" }
     task: |
-      UPDATE the master service plan (the target backend-plan.md in context) so it
-      conforms to the CURRENT spec. Tracking state: {{track_state}}. The spec moved
-      from {{derived_version}} (this plan's derivation) to {{current_version}}; the
-      ledger rows above the derivation name what moved:
-        ids:     {{changed_csv}}
-        changes: {{changed_summary}}
-      Guidance: {{USER_INPUT}}
+      RE-DERIVE the MASTER service-lane plan in context from the current spec + the
+      context's domain model. The document you are given is the plan as it stands today;
+      produce the plan this feature's spec and model call for NOW. Guidance: {{USER_INPUT}}
       Rules:
-      - SCOPE IS THE COMPUTED WORK LIST. Rework ONLY the sections and rows that realise
-        the ids above — their §1 invariants/entities, the §2/§3 elements serving them,
-        the §4.2 integration rows, the §5 cross-cutting rows and the §6 traceability
-        rows. Every other line stays BYTE-IDENTICAL; an unrelated "improvement" is
-        drift the analyze gate will fail. EXCEPTION — tracking state `untracked`: this
-        document has no baseline (a migrated legacy design.md), so reconcile the WHOLE
-        plan to the spec once; the stamp then baselines it.
-      - accept_manual: {{ACCEPT_MANUAL}}. When true, the document carries hand edits
-        that were deliberately accepted: KEEP their intent, reconcile them with the
-        spec, and record each kept deviation honestly — a new concept as a §7 DA-n, a
-        deliberate shortcut as a §8 WA-n. Never silently revert a hand edit.
-      - AN ID THE SPEC NO LONGER DEFINES LOSES ITS REALISATION: remove the elements
-        that existed only to serve it (and their §6 rows). An id whose wording moved
-        is re-realised from the spec's CURRENT text — the spec is the wording.
-      - AN ID THE SPEC HAS NEWLY DEFINED GAINS ONE. An id in the work list that NO
-        existing section realises is an ADDITION, not an error and not out of scope:
-        give it a home — the §1/§2/§3 elements that realise it, its §4.2 or §5 rows
-        where it needs them — and a §6 traceability row like any other. The scope rule
-        above says which sections may be touched; it does not say a new requirement may
-        not be designed, and reading it that way would let every added requirement
-        select nothing to rework and quietly land unrealised.
-      - THE SPEC IS THE ONLY DOMAIN INPUT, same as at bootstrap: realise ids, invent
-        nothing; an unavoidable new concept is a §7 DA-n.
-      - THE CODE IS THE WHAT-EXISTS AUTHORITY, and it is a DIFFERENT authority from the
-        spec. {{source_count}} source file(s) realise this feature today; re-read the
-        ones the moved ids touch (code state is read FRESH every run, never assumed), and ADJUST this plan to the
-        shape that is actually there rather than to an idealised one. An empty list is
-        greenfield — design from a clean slate and say so. The code NEVER overrides the
-        spec on behaviour and may not introduce a domain rule the spec omits: code that
-        contradicts the spec is reported (§7 DA-n) and designed to the SPEC, never
-        quietly blessed. A deliberate divergence from the as-built shape is a §8 WA-n
-        with its revisit trigger.
-          {{source_csv}}
-      - THE PUBLISHED SURFACE IS CITED, NOT RESTATED. `interfaces.md` is in context:
-        §3 cites the IF- id of every interface the log already carries. A moved id that
-        CHANGES a published interface is described in §3 with `(this run)` in the id
-        cell — a later step publishes it as a SUPERSEDING entry, and the next update
-        cites the new id. Never invent an IF- number and never edit the log by hand.
-      - PRESERVE THE LEDGERS: §7 Assumptions, §8 Workarounds and §9 Change History
-        keep every existing entry and their numbering — append, never rewrite. Write
-        NO version numbers anywhere and ADD NO Change History row: the stamp step
-        appends the row and moves the **Version** header.
-      - §6 TRACEABILITY STAYS COMPLETE both ways — every CN-/DC-/IC- still has a row
-        after the update; no element without a spec reason.
-      - TECHNOLOGY-AGNOSTIC, no complete code, same contract as at bootstrap.
-
-  # 7. STAMP — the only writer of the plan's version identity, and the ledger-survival
-  #    check: it REFUSES (no baseline written) if the update dropped the Change History
-  #    section, so a lost ledger can never be silently baselined over.
-  - id: stamp_bootstrap
-    condition: "{{plan_mode}} != update"
-    action: execute_script
-    script: { ref: actions }
-    subcommand: plan-stamp
-    args: ["--feature-dir", "{{feature_dir}}", "--doc", "{{plan_doc}}", "--no-row"]
-    outputs:
-      - { name: stamp_ok,        from: "$.ok" }
-      - { name: stamp_error,     from: "$.error" }
-      - { name: current_version, from: "$.version" }
-  - id: stamp_update
-    condition: "{{plan_mode}} == update"
-    action: execute_script
-    script: { ref: actions }
-    subcommand: plan-stamp
-    args: ["--feature-dir", "{{feature_dir}}", "--doc", "{{plan_doc}}", "--ids", "{{changed_csv}}", "--note", "Conformed to spec {{current_version}}"]
-    outputs:
-      - { name: stamp_ok,    from: "$.ok" }
-      - { name: stamp_error, from: "$.error" }
-  - id: stamp_fence
-    action: verify_context
-    require_true: stamp_ok
-    on_false: stop
-    on_false_message: "plan-stamp refused: {{stamp_error}} — backend-plan.md has been written but NOT baselined. Restore the missing ledger section, then re-run plan (or plan-stamp) to record the baseline."
-
-  # ═══════════ PUBLISH THE SURFACE — the interface log (payload-only) ════════
-  # §3 of the plan describes this feature's published surface; this pair turns what it
-  # newly describes into APPEND-ONLY log entries. Separate steps so the script stays the
-  # only id authority: entries arrive as IF-NEW blocks and log-append assigns IF-nnn,
-  # the date and status: proposed. It runs AFTER the stamp — the log lives in its own
-  # file, so appending to it cannot invalidate the baseline just recorded.
-  #
-  # This is the BE→FE contract anchor: /appweaver plan-ui and the FE story designs read
-  # the latest entry per id. A changed interface is published as a SUPERSEDING entry,
-  # never an edit — which is why the log is append-only and the plan cites ids.
-  - id: ctx_if
+      - THIS IS A REVISION, NOT A RE-AUTHORING. Keep the existing document's section
+        structure, its wording, and every element the spec and model still support —
+        byte-for-byte where nothing requires a change. A re-derivation that rewrites
+        untouched sections destroys the review history of a document a team maintains.
+      - WHAT THE SPEC AND MODEL SAY NOW WINS. Every §4 Traceability row must resolve to a
+        spec id that STILL EXISTS; every §1 invariant to a BR-nnn the model STILL states.
+        A row whose id is gone is deleted along with what it justified. A spec id or model
+        invariant with NO plan element is a GAP — realise it, in the shape the rest of the
+        document already uses.
+      - THE DOMAIN LAYER (§1) MUST FOLLOW THE CONTEXT'S DOMAIN MODEL EXACTLY: entities &
+        value objects are its `## Aggregate:` section's entities (SAME names), invariants
+        are its BR-nnn (cite each, never restate), the aggregate boundary is its Boundary
+        block, and states are the lifecycle it describes. Where the model has MOVED since
+        this plan was written, the model is right and the plan is stale.
+      - CARRY THE LEDGERS FORWARD. §7 DA-n architectural decisions and the WA-n
+        workarounds are DECISIONS THIS TEAM MADE, not derivations from the spec — keep
+        every one, with its id and its basis, unless the thing it decided about is gone.
+        Never renumber a surviving entry: its id is cited elsewhere.
+      - THE CODE THAT EXISTS IS THE WHAT-IS AUTHORITY. {{source_count}} source file(s)
+        realise this feature: {{source_files}}. READ them, and where the plan and the code
+        disagree about STRUCTURE, the code is what is actually there — conform to it and
+        record the divergence rather than describing a shape nobody built. The spec stays
+        the only authority on BEHAVIOUR.
+      - TECHNOLOGY-AGNOSTIC, exactly as the master already is: signatures + pre/post/
+        invariant/raises pseudocode, contracts as field shapes, conceptual types. Never
+        language code; the stack binds at `implement` time.
+      - ADD ONE Change History row for this re-derivation, describing what MOVED and why
+        (the spec ids and BR-nnn that drove it). Do NOT invent a version number — the
+        version spine belongs to close-delta.
+
+  # ═══════════ FRONTEND LANE — bootstrap, greenfield experience template ═══════
+  # The experience twin of the service plan, and the MEDIATOR between spec.md and the
+  # frontend code. Its sections are the experience, not the four clean-architecture
+  # layers. UX- lives HERE and only here — the service plan excludes the spec's Experience
+  # Standards by contract, so a UX- that reaches neither plan is a dropped requirement.
+  - id: ctx_frontend
+    condition: "{{fe_mode}} == bootstrap_gf"
     action: build_context
-    vars:
-      derived_version: "{{current_version}}"
     context:
-      - { path: "{{plan_doc}}" }                                    # the plan as just written — §3 is the source
-      - { path: "{{feature_dir}}/interfaces.md", optional: true }   # existing entries — what a change supersedes
-  - id: gen_if
+      - { path: "{{frontend_plan}}" }                                   # the copied template = section structure
+      - { path: "{{spec_file}}" }                                       # the source of truth (UX/US/FR/CN/DC/IC/SC)
+      - { path: "{{domain_model}}", optional: true }                    # the ubiquitous language this lane's labels and messages use
+      - { path: .appweaver/DESIGN-FORMAT.md }                           # the design-doc contract + its frontend lane variant
+      - { path: .appweaver/memory/constitution.ui.md, optional: true }  # the lane's ratified UX-* base — optional: a lane may be declared before it is ratified
+      - { path: "{{backend_plan}}", optional: true }                    # §5 ONLY — the service's published surface, never its internals
+  - id: gen_frontend
+    condition: "{{fe_mode}} == bootstrap_gf"
     action: agent_author
-    output_target: { type: file, path: "{{feature_dir}}/.aw-if-new.tmp.md" }
+    output_target: { type: file, path: "{{frontend_plan}}" }
     task: |
-      From the plan document in context, extract this feature's PUBLISHED SURFACE into
-      formal interface-log entries: the endpoints, published events and externally
-      consumed contracts its API/published-surface section describes.
+      Author the MASTER frontend-lane plan (the target frontend-plan.md in context) for
+      this feature's EXPERIENCE by filling out the template from the feature spec + the
+      loaded frontend standards. This is the frontend lane's MEDIATOR between the spec
+      and the components `implement` will generate. Guidance: {{USER_INPUT}}
+      Rules:
+      - THE SPEC IS THE ONLY DOMAIN INPUT. You have the spec + frontend standards, and
+        NO domain rule files. The domain arrives as spec ids only — realise them, and
+        invent no domain rule the spec omits (an unavoidable new concept → §8 DA-n).
+        Where the context's domain model is in context, use its UBIQUITOUS LANGUAGE
+        exactly — the same terms in labels, states and messages, no synonyms — and cite
+        its BR-nnn rather than restating a rule.
+      - Keep the template's section order and headings: §0 Design Overview, §1
+        Navigation & Screen Structure, §2 Client State, §3 Component Structure, §4
+        Interaction & Flow, §5 Contract Binding, §6 Cross-Cutting, §7 Traceability,
+        §8 Assumptions, §9 Workarounds, Change History.
+      - REALISE THE SPEC'S EXPERIENCE CONTENT:
+        • Experience Standards (UX-) are THIS document's to realise — the service plan
+          excludes them by contract, so a UX- with no home here is a DROPPED
+          requirement, not a tidy omission. Every UX- gets a §7 row.
+        • Experience Scope (actors · channels · device/browser/AT floors) bounds §1
+          and §6 — design for the floors the spec names and no more.
+        • Each User Story (US-) gets a screen home in §1 and a flow in §4. A US- with
+          no screen is a coverage failure.
+        • Interaction-state requirements are ordinary FR- ids (the EARS
+          unwanted-behaviour form). Each one gets a §4 row.
+      - REALISE THE LIFTED CONSTRAINTS, each citing its spec id:
+        • CN- → §6 Authorization surface and the §1 access conditions (what is hidden
+          vs disabled vs enforced server-side — the client never becomes the authority).
+        • DC- → §2 "what must NOT be held" and the §6 data-exposure row: what may not
+          reach the client, its logs, its storage or its URLs.
+        • IC-/SC- → §5 binding rows and the §6 performance row respectively.
+      - §4 INTERACTION & FLOW AND §6 CROSS-CUTTING ARE NEVER OMITTED, however thin the
+        feature. Loading, empty, error, permission-denied and in-flight states, plus
+        validation timing, focus placement and keyboard reachability, are where most UI
+        defects live. A state the UI can reach that the spec does not describe is a SPEC
+        gap: log it as a §8 DA-n and say it routes to `specify`; never invent the
+        requirement here.
+      - §5 IS THE LANE BOUNDARY. Bind against the service's PUBLISHED surface only —
+        the spec's IC- ids, and where the backend plan is in context, the API contracts
+        it states. CITE those contracts; do NOT restate, re-derive or contradict them,
+        and introduce NO server-side behaviour, persistence assumption or handler detail.
+        Anything the experience needs that the surface does not offer is a CONTRACT
+        DELTA raised back to the service lane under "Contract deltas needed" — never a
+        workaround in the client. Where no service plan is in context, bind from the
+        spec's IC- surface and record that as a §8 DA-n.
+      - CONSTITUTION-MANDATED CROSS-CUTTING (from the loaded UI constitution, NOT the
+        spec): a NON-NEGOTIABLE UX principle you must apply that has no per-feature spec
+        id. APPLY it, and because it is not spec-derived, LOG it as a §8 DA-n whose
+        basis cites the mandating principle ("per constitution.ui.md UX-<n>"); set the
+        corresponding §6 row's "Serves" to that DA-n. Do NOT fabricate a spec UX- for
+        it, and do NOT leave it uncited.
+      - TECHNOLOGY-AGNOSTIC: name no framework, router, state library, component library
+        or styling approach. Describe a component by its RESPONSIBILITY, its INPUTS as
+        field shapes, the EVENTS it raises and the STATES it can be in; describe routing
+        as a conceptual shape. The framework binds at implement time. Do NOT include
+        file placement, naming conventions or test mechanics — those are the UI
+        constitution's and `implement`'s, identical for every feature.
+      - The header's Lane field is `{{fe_lane_id}}`. That identifier is the ONLY thing you
+        are told about the lane: its framework and language are deliberately withheld,
+        because a plan that knows them starts naming them.
+      - STAY IN THE LANE'S SCOPE. This feature's screens only. The app shell, global
+        layout and the design system belong to no single feature: cite them under
+        "Screens this feature does NOT own" / "Reused from the design system", and do
+        not claim or redesign them here.
+      - §7 TRACEABILITY IS THE SPINE — fill it completely, both ways: a row for EVERY
+        UX-, US-, and for every CN-/DC-/IC-/SC- with an experience obligation, so no
+        lifted constraint is silently dropped; and no UI element without a spec reason.
+      - Fill the two ledgers: §8 Assumptions (DA-n, to clarify later) and §9 Workarounds
+        (WA-n, to clear later). Empty → "None (as of v1.0)".
+      - This is v1.0: set the initial Change History row. No component code anywhere.
 
-      Output ONLY entries that are NOT ALREADY in the interface log in context, or that
-      SUPERSEDE an entry there because the plan now describes them differently. An
-      interface the log already carries unchanged is NOT re-published. If there is
-      nothing to publish — no published surface, or every one already logged unchanged
-      — output exactly:
-      none
+  # ═══ FRONTEND LANE — bootstrap, brownfield code-derived template, NEW feature ═══
+  # Same contract as above (technology-agnostic, spec is the only domain input, full §7
+  # and both ledgers), with ONE difference: the STRUCTURE follows the code-derived
+  # template's own composition axes and the lane's as-built conventions, so a new feature
+  # slots into the app already there instead of introducing a second convention.
+  - id: ctx_frontend_brownfield
+    condition: "{{fe_mode}} == bootstrap_bf"
+    action: build_context
+    context:
+      - { path: "{{frontend_plan}}" }                                   # the scaffolded CODE-DERIVED template = as-built section structure
+      - { path: "{{spec_file}}" }                                       # the source of truth (UX/US/FR/CN/DC/IC/SC)
+      - { path: "{{domain_model}}", optional: true }                    # the ubiquitous language this lane's labels and messages use
+      - { path: .appweaver/DESIGN-FORMAT.md }                           # the design-doc contract + its frontend lane variant
+      - { path: .appweaver/memory/constitution.ui.md, optional: true }  # the lane's UX-* base, reversed by onboard from this same UI
+      - { path: knowledge/architecture/frontend.md, optional: true }    # the as-built UI architecture + the SHARED surface no slice owns
+      - { path: "{{backend_plan}}", optional: true }                    # §5 ONLY — the service's published surface, never its internals
+  - id: gen_frontend_brownfield
+    condition: "{{fe_mode}} == bootstrap_bf"
+    action: agent_author
+    tools: Read   # the lane's EXISTING source arrives as {{source_files}} paths, not inlined
+    output_target: { type: file, path: "{{frontend_plan}}" }
+    task: |
+      Author the MASTER frontend-lane plan (the target frontend-plan.md in context — it is
+      this project's CODE-DERIVED UI template) for this NEW feature being added to an
+      EXISTING frontend, by filling the template from the feature spec + the loaded
+      frontend standards. It is the MEDIATOR between the spec and the components
+      `implement` will generate. Guidance: {{USER_INPUT}}
+      Rules:
+      - THE SPEC IS THE ONLY DOMAIN INPUT. You have the spec + frontend standards + the
+        lane's as-built architecture reference, and NO domain rule files. The domain
+        arrives as spec ids only; an unavoidable new concept is an Assumption (DA-n).
+        Where the context's domain model is in context, use its ubiquitous language
+        exactly and cite its BR-nnn rather than restating a rule.
+      - THE CODE THAT EXISTS IS THE WHAT-IS AUTHORITY. {{source_count}} source file(s)
+        already realise this feature: {{source_files}}. READ them and MATCH the app's
+        screen organisation, its state and data-fetching placement and its styling
+        approach, so the feature slots in rather than introducing a second convention.
+      - STRUCTURE FOLLOWS THE TEMPLATE AND THE LANE AS-BUILT, not a fixed screen
+        taxonomy. Keep the template's own section order and headings, and create one
+        component subsection per composition axis THIS feature actually needs, titled
+        with the lane's OWN name for it.
+      - KEEP THE NEUTRAL ANCHORS the template pins: the navigation/screen inventory, the
+        client-state table, the interaction-and-flow section, the cross-cutting table
+        and the traceability spine exist in every UI plan, whatever the axes are
+        called. INTERACTION & FLOW and CROSS-CUTTING are NEVER omitted, however thin the
+        feature — loading, empty, error, permission-denied and in-flight states, focus
+        placement and keyboard reachability are where most UI defects live.
+      - REALISE THE SPEC'S EXPERIENCE CONTENT: every Experience Standard (UX-) gets a
+        traceability row (the service plan excludes them by contract, so this is their
+        only home), every User Story a screen and a flow, every interaction-state FR- a
+        flow row. Realise the lifted constraints citing their ids — CN- as the
+        authorization surface and access conditions, DC- as what may not reach the client
+        or its logs, storage and URLs, IC- as binding rows, SC- as the performance
+        decision.
+      - THE LANE BOUNDARY: bind against the service's PUBLISHED surface only — the
+        spec's IC- ids and, where the backend plan is in context, the API contracts it
+        states. Cite them; do not restate, re-derive or contradict them, and introduce no
+        server-side behaviour. What the experience needs and the surface lacks is a
+        contract delta raised back to the service lane, never a client workaround.
+      - CONSTITUTION-MANDATED CROSS-CUTTING with no per-feature spec id: apply it, and
+        log it as a DA-n citing the mandating principle ("per constitution.ui.md
+        UX-<n>"). Do not fabricate a spec id for it and do not leave it uncited.
+      - TECHNOLOGY-AGNOSTIC: name no framework, router, state library, component library
+        or styling approach — responsibilities, field shapes, events and states only.
+        Naming the lane's as-built CONVENTION is not naming a framework; naming the
+        library that implements it is. The framework binds at implement time.
+      - The header's Lane field is `{{fe_lane_id}}`. That identifier is the ONLY thing you
+        are told about the lane: its framework and language are deliberately withheld,
+        because a plan that knows them starts naming them.
+      - THE SHARED SURFACE (app shell, global layout, design system) belongs to no
+        feature. Cite it; do not copy it in and do not claim it here.
+      - Fill the traceability spine completely, both ways, and both ledgers —
+        Assumptions (DA-n) and Workarounds (WA-n), "None (as of v1.0)" when empty.
+      - This is v1.0: set the initial Change History row. No component code anywhere.
+
+  # ═══════════ FRONTEND LANE — RE-DERIVE an existing master ═══════════════════
+  # The experience twin of the service re-derivation, and the same contract: revise the
+  # document that is there against the spec as it stands now, keep what still holds, and
+  # never refill from a template.
+  - id: ctx_frontend_update
+    condition: "{{fe_mode}} == update"
+    action: build_context
+    context:
+      - { path: "{{frontend_plan}}" }                                   # the CURRENT master = what is being revised
+      - { path: "{{spec_file}}" }                                       # UX/US/FR/CN/DC/IC/SC as they stand now
+      - { path: "{{domain_model}}", optional: true }                    # the ubiquitous language this lane's labels and messages use
+      - { path: .appweaver/DESIGN-FORMAT.md }                           # the design-doc contract + its frontend lane variant
+      - { path: .appweaver/memory/constitution.ui.md, optional: true }  # the lane's ratified UX-* base
+      - { path: "{{backend_plan}}", optional: true }                    # §5 ONLY — the service's published surface, never its internals
+  - id: gen_frontend_update
+    condition: "{{fe_mode}} == update"
+    action: agent_author
+    tools: Read   # the feature's EXISTING source arrives as {{source_files}} paths, not inlined
+    output_target: { type: file, path: "{{frontend_plan}}" }
+    task: |
+      RE-DERIVE the MASTER frontend-lane plan in context from the current spec. The
+      document you are given is the plan as it stands today; produce the plan this
+      feature's spec calls for NOW. Guidance: {{USER_INPUT}}
+      Rules:
+      - THIS IS A REVISION, NOT A RE-AUTHORING. Keep the existing document's section
+        structure and every element the spec still supports — byte-for-byte where nothing
+        requires a change.
+      - WHAT THE SPEC SAYS NOW WINS. Every §7 Traceability row must resolve to a spec id
+        that STILL EXISTS; a row whose id is gone is deleted along with what it justified.
+        Every UX- and every US- in the spec needs a home here — UX- lives in THIS document
+        and only here, so a UX- with no §7 row is a DROPPED requirement, and a US- with no
+        screen in §1 and flow in §4 is a coverage failure.
+      - CARRY THE LEDGERS FORWARD. §8 DA-n and §9 WA-n are decisions this team made, not
+        derivations from the spec — keep every one with its id and basis unless the thing
+        it decided about is gone, and never renumber a survivor.
+      - THE CODE THAT EXISTS IS THE WHAT-IS AUTHORITY for STRUCTURE. {{source_count}}
+        source file(s) realise this feature: {{source_files}}. Read them and conform to
+        the component boundaries and naming actually there.
+      - THE LANE BOUNDARY IS UNCHANGED: bind against the service's PUBLISHED surface only
+        — the spec's IC- ids and, where the backend plan is in context, the API contracts
+        it states. What the experience needs and the surface lacks is a contract delta
+        raised back to the service lane, never a client workaround.
+      - TECHNOLOGY-AGNOSTIC: no framework, router, state library, component library or
+        styling approach — responsibilities, field shapes, events and states only.
+      - ADD ONE Change History row for this re-derivation, describing what MOVED and why.
+        Do NOT invent a version number — the version spine belongs to close-delta.
 
-      Otherwise output ONE block per interface, nothing else:
+  # ══════════════ DELTA — resolve the chosen change, then delegate ════════════
+  # A change was chosen at 5b. Everything that RESOLVES it lives here, beside the question
+  # that asked it, so this command's opening reads the same as `implement`'s: list → ask →
+  # activate → paths. The delta-plan module below is then pure AUTHORING.
 
-      ## IF-NEW — <METHOD /route, or the event name>
+  # The NEW row: there is no change yet, so open one. A PLAN-ONLY change — the spec is
+  # unchanged and the realisation of EXISTING spec ids moves (a refactor, an architectural
+  # decision). cr-setup scaffolds the delta-spec, which stays an unfilled stub on this
+  # path — that stub IS the signal to every downstream gate that no requirement moved.
+  - id: open_change
+    condition: "{{open_new}} == true"
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-setup
+    args: ["--feature-dir", "{{feature_dir}}", "--title", "{{USER_INPUT}}"]
+    outputs:
+      - { name: opened_cr, from: "$.cr_id" }
 
-      serves: <the FR-/BR- ids from the spec this interface exists for>
-      supersedes: <the IF-nnn id it replaces from the log in context, or none>
+  # Coalesce the two ways in. An existing change arrived as a LABEL ("CR-… · wave 2 ·
+  # title") and the scripts take its first token; a just-opened one arrives as a bare id.
+  - id: cr_choice_picked
+    condition: "{{plan_target}} == delta"
+    action: set
+    vars: { cr_choice: "{{plan_choice}}" }
+  - id: cr_choice_opened
+    condition: "{{open_new}} == true"
+    action: set
+    vars: { cr_choice: "{{opened_cr}}" }
 
-      <the contract: request/response or payload shapes, auth, status codes and the
-      error contract — shapes, not implementations>
+  # Make the chosen change the ACTIVE one. Every stage after this still resolves the
+  # change through active_version.json.active_change, so without this a plan authored for
+  # CR-B would be gated, implemented and merged as CR-C.
+  - id: activate
+    condition: "{{plan_target}} == 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" }
 
-      Every block starts with "## IF-NEW — " exactly: the script assigns the real ids,
-      the date and status: proposed. Describe only what the plan actually contains —
-      invent no interface the plan does not describe.
-  - id: append_if
+  # That change's documents, its wave, and the model deltas that come BEFORE it — the open
+  # ones in a LOWER wave, which are the deltas committed to landing first and so the only
+  # ones a plan may build on. Same-wave siblings are counted, never assumed.
+  - id: cr_paths
+    condition: "{{plan_target}} == delta"
     action: execute_script
-    on_error: continue   # a malformed extraction is reported LOUDLY but must not undo a
-                         # plan that already landed and baselined: the temp file survives
-                         # for a hand-run of log-append; if_error carries the refusal
     script: { ref: actions }
-    subcommand: log-append
-    args: ["--feature-dir", "{{feature_dir}}", "--log", "interfaces", "--entries-file", "{{feature_dir}}/.aw-if-new.tmp.md"]
+    subcommand: cr-paths
+    args: ["--cr-id", "{{cr_choice}}", "--feature-dir", "{{feature_dir}}"]
     outputs:
-      - { name: if_ok,          from: "$.ok" }
-      - { name: if_error,       from: "$.error" }
-      - { name: if_appended,    from: "$.appended" }
-      - { name: if_ids_csv,     from: "$.ids_csv" }
-      - { name: if_unknown_csv, from: "$.unknown_ids_csv" }
-      - { name: if_badsup_csv,  from: "$.bad_supersedes_csv" }
-
-  # 7c. THE TWO INTEGRITY SIGNALS log-append ALREADY RETURNS. Both were bound and neither
-  #     was said out loud — the idiom every other integrity check in these workflows uses
-  #     is a verify_context that continues, and these had none.
-  #       unknown_ids_csv     an entry's `serves:` names an id the spec does not define,
-  #                           so the BE→FE contract anchor points at nothing.
-  #       bad_supersedes_csv  an entry supersedes one the log does not carry, so what it
-  #                           claims to replace is not there — and readers take the LATEST
-  #                           entry per interface, which is now ambiguous.
-  #     Announce-only: the entries are appended by the time this is visible, ids are
-  #     permanent, and an append-only log is corrected by a later entry, never by a rewrite.
-  - id: if_unknown_notice
-    condition: "{{if_unknown_csv}} != ''"
-    action: verify_context
-    require_value: if_unknown_csv
-    equals: ""
-    on_mismatch: continue
-    on_mismatch_message: >
-      interfaces.md now carries entries whose `serves:` names ids the spec does not define:
-      {{if_unknown_csv}}. That is a broken trace anchor in the BE→FE contract — the frontend
-      binds to these entries by id, and the requirement they claim to serve is not in
-      {{spec_file}}. Either the id is a typo, or the requirement was never specified: fix it
-      with a superseding entry (never by editing the log), or take it through /appweaver specify.
-  - id: if_badsup_notice
-    condition: "{{if_badsup_csv}} != ''"
-    action: verify_context
-    require_value: if_badsup_csv
-    equals: ""
-    on_mismatch: continue
-    on_mismatch_message: >
-      An entry appended to interfaces.md supersedes an id the log does not carry:
-      {{if_badsup_csv}}. Nothing was replaced, so the interface it meant to retire is still
-      the latest entry for its surface and both now read as current. Append a corrected
-      superseding entry naming the real id.
-
-  # 8. Post-execution hooks.
+      - { name: cr_id,             from: "$.cr_id" }       # normalised: the label's first token
+      - { name: cr_dir,            from: "$.cr_dir" }
+      - { name: delta_spec,        from: "$.delta_spec" }
+      - { name: delta_model,       from: "$.delta_model" }
+      - { name: wave,              from: "$.wave" }
+      - { name: predecessor_files, from: "$.predecessor_files" }
+      - { name: predecessor_count, from: "$.predecessor_count" }
+      - { name: sibling_count,     from: "$.sibling_count" }
+
+  # Author that change's delta plans — one per declared lane whose MASTER exists, inside
+  # changes/<CR-id>/ beside its delta-spec. The masters are left UNTOUCHED; the change
+  # stays OPEN and finalize-delta merges it later. Runs in this context (shares vars +
+  # the lane rule sets + source_files).
+  - id: delta_plan_module
+    condition: "{{plan_target}} == delta"
+    action: include
+    module: .appweaver/orchestrator/modules/delta-plan.orch.yaml
+
+  # ═══════════ HANDOFF — authoring only; the gates are SEPARATE stages ═══════
+  #   • MAIN (bootstrap or re-derivation) → /appweaver analyze-plan (spec↔plan
+  #     conformance gate) → implement. No change is opened either way.
+  #   • DELTA → the chosen change stays OPEN with filled delta plans. Ship it via the CR
+  #     chain: /appweaver analyze-plan-delta → implement → build → analyze-slice-delta
+  #     → finalize-delta (merges the delta into spec.md + domain-model.md — not the lane
+  #     plans, which are derived from those two; the change stays OPEN) → analyze-slice
+  #     → close-delta (archives the change, bumps the minor version). Re-deriving the
+  #     masters from the merged documents is `plan main` on a later run.
+
+  # 7. Post-execution hooks.
   - id: resolve_post_hooks
     action: execute_script
     script: { ref: actions }
@@ -710,12 +1028,16 @@ workflow:
 
 outputs:
   feature_dir: "{{feature_dir}}"
-  plan_doc: "{{plan_doc}}"
+  bounded_context: "{{context}}"
+  backend_plan: "{{backend_plan}}"      # empty when no backend lane is declared
+  frontend_plan: "{{frontend_plan}}"    # empty when no frontend lane is declared
+  domain_model: "{{domain_model}}"
   plan_mode: "{{plan_mode}}"
-  migrated_legacy_design: "{{plan_migrated}}"
-  derived_from_spec: "{{current_version}}"
-  conformed_ids: "{{changed_csv}}"
-  interfaces_published: "{{if_ids_csv}}"
-  interfaces_error: "{{if_error}}"
-  source_files_read: "{{source_count}}"
-  next: "Gate this write: /appweaver analyze-design (spec ↔ plan conformance) — after EVERY bootstrap and EVERY update. Then the backlog and the stories: /appweaver sync-stories, then /appweaver story-plan <id>, which READS this plan and refuses to design against one the spec has moved past. {{fe_next}} READ THE FIELDS ABOVE FIRST: interfaces_published are the IF- ids this run appended to interfaces.md as status:proposed — cite them in the plan's API section on the next update, and never edit the log by hand; interfaces_error non-empty means the extraction was refused and .aw-if-new.tmp.md is still beside the plan for a hand-run of log-append, so THIS RUN PUBLISHED NOTHING; source_files_read 0 means no code was found for this feature, so the plan was written greenfield."
+  plan_target: "{{plan_target}}"
+  be_mode: "{{be_mode}}"
+  fe_mode: "{{fe_mode}}"
+  version: "{{version}}"
+  change_id: "{{active_change}}"
+  source_count: "{{source_count}}"
+  note: "This run was pointed at `{{plan_target}}` (plan_mode {{plan_mode}}); backend lane {{be_mode}}, frontend lane {{fe_mode}}. Lanes come from .appweaver/stacks.json: backend declared = {{be_declared}}, frontend declared = {{fe_declared}}. A declared lane gets a plan; an undeclared one gets nothing and that is not a failure. A lane whose mode is `update` had its MASTER re-derived from the current spec and model, with its DA-n and WA-n ledgers carried forward — that rewrite was confirmed before it ran. The domain model at {{domain_model}} was READ, never written — it is spec-tier, and this phase records where each invariant is ENFORCED rather than what it says."
+  next: "MAIN (masters authored or re-derived): /appweaver analyze-plan (spec↔plan gate) → implement. DELTA (change {{active_change}} open, delta plans authored): /appweaver analyze-plan-delta → implement → build → analyze-slice-delta → finalize-delta → analyze-slice → close-delta — implement is the same command on both paths and ASKS which open change it is building, so pass the id (/appweaver implement {{active_change}}) to skip the prompt (finalize-delta merges the delta into spec.md and domain-model.md — not the lane plans, which are derived from those two — but leaves the change open; analyze-slice verifies the slice against the merged masters; close-delta archives the change and bumps the minor version). Once a change has merged, /appweaver plan main re-derives the masters from the documents it merged into."