aw-spec-cli 0.1.23 → 0.1.25

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

@@ -24,13 +24,25 @@
 #   3. GOVERNANCE SCAFFOLD — the PROJECT-level governing tier: the split constitution
 #      (technical + domain), the guardrails/projects/brf-<domain>/domain/ rule-file set
 #      (+ domain-rule-bindings), the domain charter that set is headed by, and the
-#      activated domain. AUTHORED BY THE FIRST CONTEXT TO ONBOARD AND BY NO OTHER —
-#      re-deriving project principles from one context's evidence is the aggregate-
-#      scoping bias this tier exists to avoid, so every later run skips the whole block
-#      and contributes its own concepts and specs tree instead. Because nothing is
-#      adopted yet, the tier is a PROVISIONAL scaffold evidenced by the SCAN (project
-#      identity + bounded-context map are firm; principles/rules are marked
-#      provisional); /appweaver constitution is what amends it.
+#      activated domain. The FIRST context to onboard AUTHORS it from the whole-repo
+#      scan. Every LATER context AMENDS it from its own code — ADDITIVELY: a rule file
+#      for a concern no existing file covers, rules for a variant an existing file does
+#      not state, a principle for a project-level trait no principle covers, and the
+#      context's entry in every map the tier keeps. It never rewords, renumbers or
+#      deletes what an earlier context wrote; where this context's code contradicts a
+#      rule, it records a Divergence note under it for /appweaver constitution to
+#      decide. Re-deriving the tier per context would be the aggregate-scoping bias the
+#      rev-constitution work removed; adding one context's evidence at project scope is
+#      not. A TIER that does not exist yet — a lane declared after an earlier onboard —
+#      is authored in full by whichever run first sees it. The document templates are
+#      written once per lane and never amended: plans already written follow them.
+#      Because nothing is adopted yet, the tier is PROVISIONAL, evidenced by the code
+#      (project identity + bounded-context map are firm; principles/rules are marked
+#      provisional); /appweaver constitution is its human amendment path.
+#
+#      Naming a context that is ALREADY onboarded re-runs this governance pass alone —
+#      its concepts and specs tree are left as they are. That is how a lane declared
+#      after every context was onboarded gets its governance.
 #
 #   inventory → [edit specs/proposed-inventory.md] → inventory apply
 #     → ONBOARD <Context>  (once per context)   ← you are here
@@ -81,18 +93,18 @@
 #       source (never from a greenfield UI template's content), then linted like the other
 #       halves and composed in. Parallel to the technical base, so its numbering is its own.
 #   guardrails/projects/brf-<domain>/frontend/*.md — the code-derived lane rule set, the detail
-#       layer under those UX-* principles, plus `## /aw-spec-ui-constitution` appended to
-#       tech-rule-bindings.md so a later /appweaver constitution re-ratifies from THIS
-#       project's lane rules.
+#       layer under those UX-* principles, wired into tech-rule-bindings.md under the lane's
+#       three headings: `## /aw-spec-ui-constitution` (what a later /appweaver constitution
+#       re-ratifies the UI half from), `## /aw-spec-plan-ui` and `## /aw-spec-implement-ui`
+#       (what the frontend lane of `plan` and of `implement` load).
 #   .appweaver/templates/overrides/ui-design-template.md + ui-delta-design-template.md — the
 #       lane's own document pair, reverse-engineered from the UI source the same way the
 #       service pair is reverse-engineered from the service code. The lane is governed by a
-#       different constitution half and implemented by different commands, so it gets its own
-#       design document rather than a section inside the service design; the only thing that
-#       crosses between them is the design contract. Their consumers are the FRONTEND LANES
+#       different constitution half and generated by a different lane of `implement`, so it
+#       gets its own plan document rather than a section inside the backend plan; the only
+#       thing that crosses between them is the service's published surface. Their consumers are the FRONTEND LANES
 #       of `plan` and `implement` — one command each, covering both lanes — and the templates
-#       are written here because the whole-repo evidence for them exists exactly once, at
-#       onboard.
+#       are written here because the whole-repo evidence for them is read at onboard.
 # RUN /appweaver select-stack FIRST. It is the first command of the brownfield
 # sequence and this workflow REFUSES to run without it, because it needs to be told three
 # things before it can start: which lanes this project has, where each lane's source is,
@@ -132,12 +144,13 @@
 # Launch:  /appweaver onboard [<BoundedContext>] [; concerns: a, b, c]
 #   e.g.   /appweaver onboard Clinical
 #   e.g.   /appweaver onboard                       # the next context the map has open
+#   e.g.   /appweaver onboard Clinical              # already onboarded: governance pass only
 #   e.g.   /appweaver onboard "Clinical; concerns: auditing, concurrency, authorization"
 # =============================================================================
 
 name: aw-spec-onboard
-description: Onboard an existing codebase for brownfield DEVELOPMENT — a deterministic whole-repo scan produces a high-level OKF feature map (folders/concepts) PLUS the project-level governance scaffold (split constitution + guardrails/projects/brf-<domain>/ with its DOMAIN rule files at domain/ + domain-rule-bindings + code-derived TECHNICAL rule files at service/ + tech-rule-bindings + activated domain), all provisional-from-scan and refined per slice by adopt. Where the scan finds a frontend lane in the CODE, it also authors that lane's half — constitution.ui.md (UX-*) — and its code-derived rule files at brf-<domain>/frontend/, mapped under `## /aw-spec-ui-constitution`; a backend-only repo gets none of it. Every rule tier is reverse-engineered from the CODE alone (never a greenfield rule file), evidenced-only, and WIRED per-workflow so the whole forward pipeline AND adopt govern against THIS codebase — never a greenfield fallback. It also reverse-engineers the repo's own technical structure into a project-specific design + delta-design template pair, installed as the project template overrides, and — where the lane exists — the frontend lane's own pair from the UI source. Every authoring step is shaped by a NEUTRAL rev-templates skeleton; no greenfield constitution, rule file or document template is ever placed in context. Accepts an optional concerns list to look for (onboard decides which are actually present). Reads any declared lane, never writes one. No migration content; never modifies source.
-version: 2.1.0
+description: Onboard an existing codebase for brownfield DEVELOPMENT — a deterministic whole-repo scan produces a high-level OKF feature map (folders/concepts) PLUS the project-level governance scaffold (split constitution + guardrails/projects/brf-<domain>/ with its DOMAIN rule files at domain/ + domain-rule-bindings + code-derived TECHNICAL rule files at service/ + tech-rule-bindings + activated domain), all provisional-from-scan. The first context authors that tier; every later context amends it additively from its own code (new rules, principles and map entries — never a rewrite, renumbering or deletion; a contradiction is recorded as a Divergence note), and a tier that does not exist yet, such as a lane declared after an earlier onboard, is authored in full. Naming an already-onboarded context re-runs that governance pass alone. Where the scan finds a frontend lane in the CODE, it also authors that lane's half — constitution.ui.md (UX-*) — and its code-derived rule files at brf-<domain>/frontend/, mapped under `## /aw-spec-ui-constitution`, `## /aw-spec-plan-ui` and `## /aw-spec-implement-ui`; a backend-only repo gets none of it. Every rule tier is reverse-engineered from the CODE alone (never a greenfield rule file), evidenced-only, and WIRED per-workflow so the whole forward pipeline AND adopt govern against THIS codebase — never a greenfield fallback. It also reverse-engineers the repo's own technical structure into a project-specific design + delta-design template pair, installed as the project template overrides, and — where the lane exists — the frontend lane's own pair from the UI source. Every authoring step is shaped by a NEUTRAL rev-templates skeleton; no greenfield constitution, rule file or document template is ever placed in context. Accepts an optional concerns list to look for (onboard decides which are actually present). Reads any declared lane, never writes one. No migration content; never modifies source.
+version: 2.3.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
@@ -174,15 +187,31 @@ standards:
   - { path: .appweaver/ai-rules.md }   # kit-resident: the universal operating rules, every flow
 
 vars:
-  bundle_present: "false"   # inventory bundle_guard driver
+  # The provenance stamp every generated file carries. It names THIS workflow's version,
+  # so it moves with `version:` above — one value, never a literal repeated per prompt.
+  generated_by:   "aw-spec-onboard/2.3.0"
+  bundle_present: "false"   # set by the scan (the bundle holds concepts); reported, gates nothing
   conformant:     "false"   # OKF conformance-gate driver
-  pack_present:   "false"   # project anti-clobber driver
+  pack_present:   "false"   # the project tier exists ⇒ repo_gov, so this context AMENDS it
   # The governance tier — constitution halves, rule packs, document templates —
-  # is PROJECT-scoped, authored by the first context to onboard and left alone by
-  # every context after it. Re-authoring project principles from one context's
-  # evidence is the scoping bias the rev-constitution work removed; this var is
-  # what keeps the second run from doing it.
+  # is PROJECT-scoped: the first context to onboard authors it, and every later one
+  # amends it additively. Re-authoring project principles from one context's evidence
+  # is the scoping bias the rev-constitution work removed; this var is what switches
+  # a later run from authoring to amending.
   repo_gov:       "false"   # true once the project governance exists
+  # Per-lane tier presence, from project-setup. A lane whose tier is absent is authored
+  # in full even on a later context — a lane declared after an earlier onboard.
+  service_present:  "false"
+  frontend_present: "false"
+  amend_repo:     "false"   # the domain tier + domain half exist ⇒ amend them
+  amend_svc:      "false"   # the service tier exists and the lane is declared ⇒ amend it
+  amend_ui:       "false"   # the frontend tier exists and the lane is declared ⇒ amend it
+  # False when the named context is already onboarded: its concepts and specs tree are
+  # left as they are and the run is the governance pass alone.
+  bundle_pass:    "true"
+  amended_domain_files:  ""
+  amended_service_files: ""
+  amended_ui_files:      ""
   # The governance project is named from the PROJECT, never from the context.
   # Passing the context name here would produce one rule pack per bounded
   # context, which is the same bias by another route.
@@ -273,6 +302,11 @@ workflow:
     args: ["--service-root", "{{be_root}}", "--ui-root", "{{fe_root}}"]
     outputs:
       - { name: inventory_json,   from: "$.inventory_json" }
+      # The same substrate cut per lane. A step that authors ONE lane's governance
+      # reads its lane's view; the bundle and the lane-neutral domain steps read the
+      # whole substrate.
+      - { name: inventory_service_json, from: "$.inventory_service_json" }
+      - { name: inventory_ui_json,      from: "$.inventory_ui_json" }
       - { name: root,             from: "$.root" }
       - { name: head,             from: "$.head" }
       - { name: file_count,       from: "$.file_count" }
@@ -348,6 +382,11 @@ workflow:
       - { name: contexts_ordered,   from: "$.contexts_ordered" }
       - { name: feature_map,        from: "$.feature_map" }
       - { name: map_error,          from: "$.error" }
+      - { name: all_onboarded,      from: "$.all_onboarded" }
+      # The input's "concerns:" clause, split off the context name. Prompts quote
+      # `concerns_line`, never the raw input.
+      - { name: concerns,           from: "$.concerns" }
+      - { name: concerns_line,      from: "$.concerns_line" }
 
   # 1d. No map means the boundaries were never decided. Onboarding without them
   #     is what produced a flat aggregate list with no context level at all.
@@ -362,6 +401,23 @@ workflow:
       review and edit `specs/proposed-inventory.md` — it is the boundary map and
       it is yours to change — then run `/appweaver inventory apply`.
 
+  # context-state exits non-zero on the three refusals below and still prints its
+  # verdict; `on_error: continue` binds that JSON, so each gate quotes the reason.
+  - id: all_done_gate
+    condition: "{{all_onboarded}} == true"
+    action: verify_context
+    require_value: all_onboarded
+    equals: "false"
+    on_mismatch: stop
+    on_mismatch_message: >
+      Every bounded context in the feature map is already onboarded
+      ({{onboarded_contexts}}), so there is no context left to onboard. Pick a feature
+      with /appweaver select-feature and develop it — adopt it first if it exists in
+      the code. To re-run the governance pass — for instance after declaring a lane
+      with /appweaver select-stack — name a context: /appweaver onboard <Context>. To
+      onboard a context the map does not have, edit specs/proposed-inventory.md and run
+      /appweaver inventory apply.
+
   - id: require_context
     action: verify_context
     require_value: context_known
@@ -369,16 +425,27 @@ workflow:
     on_mismatch: stop
     on_mismatch_message: "{{map_error}}"
 
-  # 1e. Per-context curation guard — the narrow form of the old bundle guard.
-  - id: context_done_guard
+  # 1e. Per-context curation guard — the narrow form of the old bundle guard. A context
+  #     whose concepts all exist is not re-mapped: the concept author is skipped, so its
+  #     curation is never overwritten. The governance pass still runs, because what it
+  #     amends is project-scoped and may have moved since — a lane declared after this
+  #     context was onboarded is the case that needs it.
+  - id: context_done_refresh
+    condition: "{{already_onboarded}} == true"
+    action: set
+    vars: { bundle_pass: "false" }
+  - id: context_done_note
+    condition: "{{already_onboarded}} == true"
     action: verify_context
     require_value: already_onboarded
-    equals: "false"
-    on_mismatch: stop
+    equals: "never"
+    on_mismatch: continue
     on_mismatch_message: >
       Bounded context {{bc}} is already onboarded — every aggregate its
-      {{bc_feature_count}} feature(s) act on ({{bc_aggregates}}) already has a concept in
-      {{bundle_dir}}, and re-running would overwrite that curation. Contexts still open: {{remaining_contexts}}
+      {{bc_feature_count}} feature(s) act on ({{bc_aggregates}}) has a concept in
+      {{bundle_dir}}. Those concepts and its specs tree are left as they are; this run is
+      the GOVERNANCE pass alone: it authors any lane tier that does not exist yet and
+      amends the rest from {{bc}}'s code.
 
   # 1f. Dependency order. A context whose dependencies are still open would be
   #     modelled against aggregates that do not exist yet. A context inside a
@@ -505,12 +572,14 @@ workflow:
   #    OKF format authority, and an OPTIONAL DDD vocabulary aid for naming (no
   #    migration/pipeline reference — this is development).
   - id: ctx_author
+    condition: "{{bundle_pass}} == true"
     action: build_context
     context:
       - { path: "{{inventory_json}}" }                        # the deterministic substrate (aggregate_signals etc.)
       - { path: "{{feature_map}}" }                           # the CONFIRMED boundaries: which features belong to which bounded context, and in what order
       - { path: .appweaver/templates/okf-concept-template.md }  # OKF v0.1 format authority (frontmatter, index, log, rules) — format only, zero project content
   - id: author_bundle
+    condition: "{{bundle_pass}} == true"
     action: agent_generate
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
@@ -631,9 +700,10 @@ workflow:
         group). Do NOT impose a fixed Domain/Application/UI taxonomy — the CODE's
         folders ARE the grouping. Set `timestamp` to the latest commit time across them.
         Then set `ui_source_files` to the FRONTEND files that serve this aggregate,
-        grouped the same way. The substrate's `ui_attribution` proposes them per
-        aggregate — it is a NAME match, so confirm each against what the file actually
-        is and move or drop one it got wrong. Keep the key and leave it EMPTY where the
+        grouped the same way. The substrate proposes them per aggregate (the `ui_files`
+        of each aggregate signal, summarised in `ui_attribution`): files under a UI
+        feature folder the map names are attributed through the map, the rest by NAME —
+        confirm those against what the file actually is and move or drop one it got wrong. Keep the key and leave it EMPTY where the
         aggregate has no UI (and on a backend-only repo, where every concept has none);
         never fold these paths into `source_files`, which stays the service surface.
       - `aggregates/index.md` — the BOUNDED-CONTEXT / feature map (no frontmatter beyond
@@ -652,7 +722,7 @@ workflow:
 
       Provenance + safety (OKF hard rules):
       - Stamp every concept `origin: reverse-engineered`, `generated_by:
-        aw-spec-onboard/2.0.0` and `bounded_context: {{bc}}` in frontmatter. The
+        {{generated_by}}` and `bounded_context: {{bc}}` in frontmatter. The
         context key is what lets later commands filter features by the context they
         belong to instead of listing every aggregate under every one.
       - The CODE is the source of truth; capture what IS (quirks included), not what
@@ -666,16 +736,21 @@ workflow:
       - { name: bundle_files, from: "$.files" }
 
   - id: verify_authored
+    condition: "{{bundle_pass}} == true"
     action: verify_context
     require_non_empty: bundle_files
     on_empty: stop
     on_empty_message: "No feature-map files were written to {{bundle_dir}}. Ensure the substrate {{inventory_json}} has aggregate_signals and re-run."
 
   # 4. CONFORMANCE gate — OKF v0.1 validator (errors block; warnings noted).
+  # validate exits non-zero on a non-conformant bundle; `on_error: continue` binds the
+  # verdict it prints, so the gate below names the errors instead of the run stopping
+  # on a bare script failure.
   - id: validate_bundle
     action: execute_script
     script: { ref: inventory }
     subcommand: validate
+    on_error: continue
     args: ["--bundle", "{{bundle_dir}}", "--repo-root", "{{root}}"]
     outputs:
       - { name: conformant,   from: "$.conformant" }
@@ -689,6 +764,30 @@ workflow:
     on_false: stop
     on_false_message: "The OKF feature map at {{bundle_dir}} is NON-CONFORMANT (errors: {{okf_errors}}). Fix the reported ERRORs (unparseable frontmatter, missing `type`, malformed index.md/log.md) and re-run."
 
+  # Did every aggregate this context acts on get its concept? The conformance gate checks
+  # the files that were written; this checks that the ones the map asked for were. Read
+  # back through context-state, the same reader that decides whether the context is
+  # onboarded, so a concept it cannot find counts as missing.
+  - id: concepts_check
+    action: execute_script
+    script: { ref: inventory }
+    subcommand: context-state
+    on_error: continue
+    args: ["--context", "{{bc}}", "--bundle", "{{bundle_dir}}"]
+    outputs:
+      - { name: concepts_complete, from: "$.already_onboarded" }
+      - { name: concepts_missing,  from: "$.pending_aggregates" }
+  - id: concepts_gate
+    action: verify_context
+    require_value: concepts_complete
+    equals: "true"
+    on_mismatch: stop
+    on_mismatch_message: >
+      The bundle at {{bundle_dir}} has no concept for these aggregates of {{bc}}:
+      {{concepts_missing}}. Each needs a concept whose `type` names an aggregate and whose
+      `title` is the aggregate's name exactly as the map spells it. Re-run onboard for
+      {{bc}}; the concepts already written are left as they are.
+
   # ═══════════ THE CONTEXT'S SPECS TREE — specs/<Context>/<Feature>/ ═══════════
   # The concepts above say what this context CONTAINS; these two steps make that
   # shape exist where every later command looks for it. Until now a context left
@@ -760,31 +859,31 @@ workflow:
       /appweaver inventory apply, then /appweaver select-feature will offer them.
 
   # ═══════════════ PART 2 — GOVERNANCE SCAFFOLD (project-level) ════════════════
-  # Establish the governing tier ONCE, from the feature map just written (the whole-
-  # repo vantage). No slice is adopted, so list-adopted returns slice_count=0 but STILL
-  # yields project_name / overview / project_context (domain evidence) and
-  # design_context (= overview + platform: the technical evidence) from the bundle.
-  # There is NO require_adopted gate here — that is the whole point of onboarding first.
+  # The first context AUTHORS the governing tier from the whole-repo vantage; every
+  # later context AMENDS it additively from its own code (see the flags below).
+  # project-context reads the project framing from the OKF bundle only:
+  # project_name / overview / project_context (domain evidence) and technical_context
+  # (overview + platform: the technical evidence). It never lists adopted features, so
+  # a team that re-runs onboard after adopting some still gets a tier evidenced by the
+  # code, not by those features' documents.
 
   - id: project_ctx
     action: execute_script
     script: { ref: revcon }
-    subcommand: list-adopted
+    subcommand: project-context
     outputs:
-      - { name: slice_count,     from: "$.slice_count" }
-      - { name: spec_context,    from: "$.spec_context" }     # at onboard = project_context (no specs yet)
-      - { name: design_context,  from: "$.design_context" }   # at onboard = overview + platform (the tech evidence)
+      - { name: technical_context, from: "$.technical_context" }  # overview + platform (the tech evidence)
       - { name: project_context, from: "$.project_context" }  # overview + aggregates/index + platform + index
       - { name: project_name,    from: "$.project_name" }
       - { name: overview,        from: "$.overview" }
 
   # Slugify + `brf-` prefix the domain name and create guardrails/projects/brf-<domain>/.
-  # Name: explicit arg → PROJECT name from the OKF overview → repo basename. Guarded
-  # against clobbering a project that already holds .md files.
+  # Name: explicit arg → the ACTIVE brf- project → PROJECT name from the OKF overview →
+  # repo basename. It reports which tiers already hold rule files, and lists them.
   # The governance project is named from the PROJECT — `gov_name` is empty, so
-  # project-setup falls back to the project name from the OKF overview and then
-  # to the repo basename. Passing the bounded context here would create one rule
-  # pack per context and split the project's constitution along context lines,
+  # project-setup falls back to the active project, then the project name from the OKF
+  # overview, then the repo basename. Passing the bounded context here would create one
+  # rule pack per context and split the project's constitution along context lines,
   # which is the aggregate-scoping bias in a new place.
   - id: pack_setup
     action: execute_script
@@ -797,48 +896,62 @@ workflow:
       - { name: domain_rule_bindings,              from: "$.domain_rule_bindings" }
       - { name: domain_constitution_source, from: "$.domain_constitution_source" }
       - { name: pack_present,               from: "$.pack_present" }
-
-  # An existing pack is no longer a reason to stop — it is the signal that the
-  # project tier has already been authored and this run is onboarding a LATER
-  # bounded context. The tier is written once and amended by /appweaver
-  # constitution; what each later context still contributes is its own OKF
-  # concepts and its own domain model.
+      - { name: service_present,            from: "$.service_present" }
+      - { name: frontend_present,           from: "$.frontend_present" }
+      - { name: domain_files,               from: "$.domain_files" }
+      - { name: service_files,              from: "$.service_files" }
+      - { name: frontend_files,             from: "$.frontend_files" }
+
+  # An existing project is the signal that an earlier context authored the tier and
+  # this run AMENDS it.
   - id: repo_gov_present
     action: set
     condition: "{{pack_present}} == true"
     vars: { repo_gov: "true" }
 
-  # WHAT THIS RUN AUTHORS. The engine compares one variable against one value and
-  # has no compound conditions, so "this lane exists AND the project tier has not
-  # been written yet" is computed here as an ordered pair of sets rather than
-  # asked at each step: default to the lane declaration, then clear everything
-  # once the project tier is present.
+  # WHAT THIS RUN AUTHORS AND WHAT IT AMENDS, PER TIER. The engine compares one
+  # variable against one value and has no compound conditions, so "this lane is
+  # declared AND its tier does not exist yet" is computed here as ordered sets rather
+  # than asked at each step: default to authoring whatever the declaration names, then
+  # switch each tier that already exists to amending.
   #
-  # The second set also SATISFIES the lint guards the skipped block would
-  # otherwise leave at their "not yet verified" default — the same move
-  # svc_lane_absent makes for a repo with no service lane. Without it a later
-  # context would stop at a gate checking work this run correctly did not do.
+  # Authoring and amending are exclusive per tier, and between them they cover every
+  # declared lane, so every constitution half this run can touch is linted below. The
+  # document templates follow the author flags only: they are written when their lane's
+  # tier is first authored and never amended, because the plans already written follow
+  # their shape.
   #
-  # ⌛ OPEN: should a LATER context amend the rule sets? Skipping the whole tier
-  # also skips the code-derived rule files, and a second context can evidence a
-  # domain or technical concern the first one's source never showed — that
-  # evidence reaches nothing today. The two halves of the tier differ here. The
-  # constitution halves, principle numbering, domain activation and the document
-  # templates are project-scoped, and re-deriving them per context IS the
-  # aggregate-scoping bias rev-constitution v1.1.0 removed; /appweaver
-  # constitution is their amendment path. The rule SETS
-  # (guardrails/projects/<p>/{domain,service,frontend}/) are evidenced-only, so
-  # amending them ADDITIVELY from a later context — add a rule for a concern this
-  # context exhibits, never rewrite or renumber an existing one — would be more
-  # evidence at the same project scope rather than one context's bias. That
-  # additive pass is not built; author-once is what runs.
+  # AMENDING IS ADDITIVE, and that is what makes it safe to do per context. A later
+  # context adds what its own code evidences and the tier does not yet say — a rule
+  # file for a new concern, rules for a variant an existing file does not state, a
+  # principle for a project-level trait no principle covers, its entry in every map —
+  # and never rewords, renumbers or deletes what an earlier context wrote. Re-deriving
+  # the tier per context would be the aggregate-scoping bias rev-constitution v1.1.0
+  # removed; adding one context's evidence at project scope is more evidence, not bias.
+  # A contradiction is recorded as a Divergence note under the rule it contradicts, for
+  # /appweaver constitution to decide, never resolved here.
   - id: author_flags_default
     action: set
-    vars: { author_repo: "true", author_svc: "{{svc_lane}}", author_ui_flag: "{{ui_lane}}" }
-  - id: author_flags_skip
-    action: set
+    vars:
+      author_repo: "true"
+      author_svc: "{{svc_lane}}"
+      author_ui_flag: "{{ui_lane}}"
+      gov_mode: "authored — this run wrote the project tier"
+  - id: amend_repo_flags
     condition: "{{repo_gov}} == true"
-    vars: { author_repo: "false", author_svc: "false", author_ui_flag: "false", technical_ok: "true", domain_ok: "true", ui_ok: "true", numbering_ok: "true" }
+    action: set
+    vars:
+      author_repo: "false"
+      amend_repo: "true"
+      gov_mode: "amended — an earlier context wrote the project tier and this run added {{bc}}'s evidence to it"
+  - id: amend_svc_flags
+    condition: "{{service_present}} == true"
+    action: set
+    vars: { author_svc: "false", amend_svc: "{{svc_lane}}" }
+  - id: amend_ui_flags
+    condition: "{{frontend_present}} == true"
+    action: set
+    vars: { author_ui_flag: "false", amend_ui: "{{ui_lane}}" }
 
   # ── DOMAIN RULE SET (provisional, evidenced by the SCAN) ────────────────────
   # Feed NEUTRAL shape skeletons (rev-templates/, zero content to leak) + the rule-
@@ -878,11 +991,10 @@ workflow:
       vantage — describe the domain / bounded context AS A WHOLE, so any feature later
       slots in without a rewrite.
 
-      CONCERNS HINT: {{USER_INPUT}} may carry a "concerns: a, b, c" clause. Treat any listed
-      concern as a SEARCH HINT — go look for it in the code — but you still DECIDE presence
-      from evidence: include a concern's rule file ONLY if the code exhibits it, drop a
-      listed concern the code shows none of, and ADD an unlisted concern the code clearly
-      evidences. Ignore any non-concerns text (the domain name / scope hint).
+      CONCERNS HINT: {{concerns_line}} Treat any listed concern as a SEARCH HINT — go look
+      for it in the code — but you still DECIDE presence from evidence: include a concern's
+      rule file ONLY if the code exhibits it, drop a listed concern the code shows none of,
+      and ADD an unlisted concern the code clearly evidences.
 
       PROVISIONAL BY CONSTRUCTION. Because no slice is adopted, you have the domain's
       SHAPE (its features, ubiquitous language, bounded-context map, evident concerns)
@@ -915,7 +1027,7 @@ workflow:
         - domain-requirements.md          — the PROJECT overview: open with a
           `[DOMAIN: Bounded Contexts / Modules]` map (from the overview + aggregates
           index), then per-subsection pointers, platform topology, governance overrides.
-      Stamp every file `origin: reverse-engineered`, `generated_by: aw-spec-onboard/1.6.0`,
+      Stamp every file `origin: reverse-engineered`, `generated_by: {{generated_by}}`,
       and note the project is a provisional scaffold reconciled per slice at adopt.
 
       domain-rule-bindings.md (MANDATORY — /specify's resolve-domain reads this exact filename).
@@ -947,13 +1059,17 @@ workflow:
   # ── DOMAIN CONSTITUTION SOURCE — <project>/domain/domain-constitution.md ────────────
   # Named and placed exactly as a greenfield industry corpus names and places its charter,
   # and already wired as the first `## /aw-spec-constitution` bullet by the step above.
+  # The charter is authored from the domain rule set the step above wrote — its files,
+  # not only the map that lists them. This step has no tools, so every file it cites is
+  # inlined here: `pack_files` is what author_pack reported, narrowed by the engine to
+  # the files actually on disk.
   - id: ctx_domain_source
     condition: "{{author_repo}} == true"
     action: build_context
     context:
       - { path: "{{domain_rule_bindings}}" }
       - { path: .appweaver/orchestrator/rev-templates/domain-constitution.skeleton.md, optional: true }
-    context_from: project_context
+    context_from: [project_context, pack_files]
   - id: author_domain_source
     condition: "{{author_repo}} == true"
     action: agent_author
@@ -962,8 +1078,10 @@ workflow:
     task: |
       Author the DOMAIN CONSTITUTION SOURCE (the output target) — the human-readable
       charter for the WHOLE PROJECT **{{project_name}}** (domain {{domain_slug}}),
-      scaffolded from the OKF feature map (architecture/overview.md, aggregates/index.md
-      — in context) and the generated project's domain-rule-bindings.md. Follow the SHAPE of the
+      scaffolded from the OKF feature map (architecture/overview.md, aggregates/index.md)
+      and the project's generated domain rule set — domain-rule-bindings.md and every rule
+      file it maps, all in context. The rule files were read out of the code; they are
+      the deeper evidence, the map the shallower one. Follow the SHAPE of the
       neutral skeleton domain-constitution.skeleton.md (in context) — its Project-Identity
       + Domain-Principle structure — so the normal /appweaver constitution can
       re-derive the domain half later. The skeleton carries NO content; every value
@@ -980,7 +1098,8 @@ workflow:
       - `## Domain Principles` — principles the domain embodies, TITLED by DOMAIN CONCERN
         (not by a feature name), each a declarative rule that would hold across features.
         Number with a stable "D1, D2, …" convention (the composed constitution assigns
-        exact roman numerals after the technology base). Cite the feature-map evidence;
+        exact roman numerals after the technology base). Cite the evidence — the rule
+        file a principle rests on, or the feature-map line;
         mark any principle whose exact rule ids are not yet enumerable `PROVISIONAL —
         reconciled at adopt`.
       - AS-BUILT: state the rule the code evidences; do NOT prescribe an ideal it does
@@ -996,9 +1115,9 @@ workflow:
   # EVERY setup-constitution call in this workflow, the UI one included: this command
   # creates the always-present halves as a side effect of whatever else it is asked to
   # do, so a later call without the flag silently recreates the half an earlier call
-  # was told to skip.
+  # was told to skip. It creates only what is missing and returns every path either way,
+# so it runs on each pass: an amending run needs the same paths an authoring one does.
   - id: setup_constitution
-    condition: "{{author_repo}} == true"
     action: execute_script
     script: { ref: actions }
     subcommand: setup-constitution
@@ -1007,7 +1126,91 @@ workflow:
       - { name: constitution_technical_file, from: "$.constitution_technical_file" }
       - { name: constitution_domain_file,    from: "$.constitution_domain_file" }
 
-  # TECHNICAL HALF — from the OKF overview + platform note (design_context), DOMAIN-FREE.
+  # ── AMEND THE SERVICE TIER (a later context, the tier exists) ────────────────
+  # One step for the lane's whole tier — its rule files, its headings in the map and
+  # its constitution half — because a new principle is only ever the ratified line over
+  # a rule this context's code evidences, and the two are decided together. Rules first,
+  # principle second, from THIS context's code: the first context's author read the
+  # whole-repo scan, so what a later context adds is the depth it brings to its own
+  # files. Runs before the domain tier's amendment, which continues this half's
+  # numbering. Changing nothing is a valid outcome, so nothing here gates on a result.
+  - id: ctx_amend_service
+    condition: "{{amend_svc}} == true"
+    action: build_context
+    context:
+      - { path: "{{constitution_technical_file}}" }                                             # the ratified half being amended
+      - { path: "{{pack_dir}}/tech-rule-bindings.md" }                                           # the map being amended
+      - { path: "{{inventory_service_json}}" }                                                   # the lane's substrate — locate this context's files
+      - { path: .appweaver/orchestrator/rev-templates/technical-rule-file.skeleton.md, optional: true }  # SHAPE ONLY for a new rule file
+      - { path: .appweaver/RULE-PARTITION.md }                                                   # which heading a new file may go under
+    # The existing rule files, inlined, plus the overview + platform note this run's
+    # concept author may have added this context's technology to.
+    context_from: [technical_context, service_files]
+  - id: amend_service_tier
+    condition: "{{amend_svc}} == true"
+    action: agent_generate
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      AMEND the SERVICE lane's governance for **{{project_name}}** (project
+      {{domain_slug}}) with what bounded context `{{bc}}` evidences. The tier exists — an
+      earlier context authored it — and this run ADDS to it. It never re-authors it.
+
+      THE EVIDENCE IS THIS CONTEXT'S CODE. Its aggregates: {{bc_aggregates}} (features:
+      {{bc_features}}). Each has a concept under {{bundle_dir}}/aggregates/ whose `title`
+      is the aggregate's name, and its `source_files` are this context's service code.
+      Read those concepts, then READ the source they list — enough to see how this
+      context handles each technology concern. {{inventory_service_json}} (in context) is
+      the whole lane's substrate, for anything the concepts do not list.
+
+      WHAT EXISTS (in context): every rule file in {{pack_dir}}/service/, the map
+      {{pack_dir}}/tech-rule-bindings.md and the technical half
+      {{constitution_technical_file}}. Read all of it before writing anything.
+
+      WHAT YOU MAY ADD — and only add:
+      - A NEW rule file `{{pack_dir}}/service/<concern>.md` for a technology concern this
+        context's code exhibits and no existing file covers. Same shape as the existing
+        files (frontmatter origin: reverse-engineered, generated_by: {{generated_by}},
+        concern); every rule cites a code coordinate from this context and the numeral
+        of the principle it details. Wire it into tech-rule-bindings.md under the
+        headings its rules serve (RULE-PARTITION.md, in context) and give it a row in
+        the quick-reference table. Nothing but service/domain-modelling.md ever goes
+        under `## /aw-spec-specify`.
+      - NEW rules appended to an EXISTING file, where this context shows a form of that
+        concern the file does not state — each citing this context's coordinate and
+        marked `(context: {{bc}})`.
+      - A NEW principle in the technical half, only for a PROJECT-level technology trait
+        this context evidences and no principle covers. Append it after the last one
+        with the next roman numeral, citing its evidence and marked `PROVISIONAL — code
+        coordinate reconciled at adopt` where the exact coordinate is not pinned.
+      NEVER reword, reorder, renumber or delete an existing rule, principle, map bullet
+      or heading, and never touch the evidence another context contributed. Add no
+      domain-specific principle, identifier or terminology — this tier is domain-free.
+
+      A CONFLICT IS RECORDED, NOT RESOLVED. Where this context's code does what an
+      existing rule or principle says the code does not do (or the reverse), leave that
+      text as it is and add under it one line:
+      `Divergence ({{bc}}): <what this code does> (evidence: <path>)`.
+      Name every divergence in the half's Sync Impact Report as needing a decision
+      through /appweaver constitution.
+
+      WHEN YOU CHANGE THE HALF: bump its version — MINOR for a new principle, PATCH when
+      only a divergence note was added — set Last Amended to today and keep Ratified;
+      replace the leading Sync Impact Report comment with one for this amendment
+      (version old→new, what was added or noted and from which context); and if the
+      principle count moved, update the hand-off line ("Technical principles: I–<N>;
+      domain half continues at <N+1>").
+
+      CHANGING NOTHING IS A VALID OUTCOME. If the tier already covers everything this
+      context's code shows, write no file and say so.
+      Write ONLY inside {{pack_dir}}/service/, {{pack_dir}}/tech-rule-bindings.md and
+      {{constitution_technical_file}} — the domain tier and the frontend lane are
+      amended by their own steps. Modify no source. Report the files you changed (an
+      empty list when none) and, per change, the concern and the code path evidencing it.
+    outputs:
+      - { name: amended_service_files, from: "$.files" }
+
+  # TECHNICAL HALF — from the OKF overview + platform note (technical_context), DOMAIN-FREE.
   # The neutral technical shape skeleton is fed via CONTEXT (not the sticky standards
   # set, which is empty), so nothing leaks into the Part-1 feature-map agent.
   - id: ctx_technical
@@ -1017,7 +1220,7 @@ workflow:
       - { path: "{{constitution_technical_file}}" }
       - { path: .appweaver/orchestrator/rev-templates/technical-constitution.skeleton.md, optional: true }
       - { path: .appweaver/orchestrator/rev-templates/ai-rules.reference.md, optional: true }
-    context_from: design_context
+    context_from: technical_context
   - id: author_technical
     action: agent_author
     condition: "{{author_svc}} == true"
@@ -1061,9 +1264,11 @@ workflow:
         the technical count / domain hand-off numeral, and dependent artifacts (✅/⚠).
       Return the complete updated technical constitution content only.
 
+  # Authored or amended, the half is linted: with a service lane declared, one of the
+  # two ran.
   - id: technical_validation_loop
     action: loop
-    condition: "{{author_svc}} == true"
+    condition: "{{svc_lane}} == true"
     while: "{{technical_ok}} != true"
     max_iterations: 3
     steps:
@@ -1105,10 +1310,11 @@ workflow:
   # order the technical tier already uses in this workflow.
 
   # Create the UI half from its template — on demand, unlike the other two. Its
-  # ABSENCE is meaningful: a repo with no UI never gets the file at all.
+  # ABSENCE is meaningful: a repo with no UI never gets the file at all. Where the half
+  # exists it is left alone and its path returned, for the amending step below.
   - id: setup_ui_constitution
     action: execute_script
-    condition: "{{author_ui_flag}} == true"
+    condition: "{{ui_lane}} == true"
     script: { ref: actions }
     subcommand: setup-constitution
     args: ["--ui", "{{setup_tech_flag}}"]
@@ -1116,12 +1322,91 @@ workflow:
       - { name: constitution_ui_file, from: "$.constitution_ui_file" }
       - { name: ui_created,           from: "$.ui_created" }
 
+  # ── AMEND THE FRONTEND TIER (a later context, the tier exists) ───────────────
+  # The frontend lane's twin of the service amendment above: its rule files, its three
+  # headings in the map and the UX-* half, from this context's UI code. A lane declared
+  # after an earlier onboard has no tier yet, so it takes the authoring path below
+  # instead — this step never runs for it.
+  - id: ctx_amend_ui
+    condition: "{{amend_ui}} == true"
+    action: build_context
+    context:
+      - { path: "{{constitution_ui_file}}" }                                                    # the ratified UX-* half being amended
+      - { path: "{{pack_dir}}/tech-rule-bindings.md" }                                           # the map whose UI headings are amended
+      - { path: "{{inventory_ui_json}}" }                                                        # the lane's substrate — locate this context's UI files
+      - { path: .appweaver/orchestrator/rev-templates/frontend-rule-file.skeleton.md, optional: true }   # SHAPE ONLY for a new rule file
+      - { path: .appweaver/RULE-PARTITION.md }
+      - { path: "{{bundle_dir}}/architecture/frontend.md", optional: true }                     # the shared UI surface, as the bundle records it
+    context_from: frontend_files
+  - id: amend_ui_tier
+    condition: "{{amend_ui}} == true"
+    action: agent_generate
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      AMEND the FRONTEND lane's governance for **{{project_name}}** (project
+      {{domain_slug}}) with what bounded context `{{bc}}` evidences. The tier exists — an
+      earlier context authored it — and this run ADDS to it. It never re-authors it.
+
+      THE EVIDENCE IS THIS CONTEXT'S UI CODE. Its aggregates: {{bc_aggregates}}
+      (features: {{bc_features}}). Each has a concept under {{bundle_dir}}/aggregates/
+      whose `title` is the aggregate's name, and its `ui_source_files` are the UI files
+      serving it. Read those concepts, then READ the UI source they list — enough to see
+      how this context's screens handle each experience concern. {{inventory_ui_json}}
+      (in context) is the whole lane's substrate. The shared UI surface (app shell,
+      layout, design system) belongs to no context and is already governed; amend it
+      only where this context's screens show something the tier does not state.
+
+      WHAT EXISTS (in context): every rule file in {{pack_dir}}/frontend/, the map
+      {{pack_dir}}/tech-rule-bindings.md and the UX half {{constitution_ui_file}}. Read
+      all of it before writing anything.
+
+      WHAT YOU MAY ADD — and only add:
+      - A NEW rule file `{{pack_dir}}/frontend/<concern>.md` for an experience concern
+        this context's UI exhibits and no existing file covers. Same shape as the
+        existing files (frontmatter origin: reverse-engineered, generated_by:
+        {{generated_by}}, concern); every rule cites a UI code coordinate from this
+        context and the UX numeral it details. Wire it into tech-rule-bindings.md under
+        `## /aw-spec-plan-ui` and/or `## /aw-spec-implement-ui` as its rules serve
+        planning or generating, and give it its table row. frontend/ui-constitution.md
+        stays the only file under `## /aw-spec-ui-constitution` that is not also a
+        concern file.
+      - NEW rules appended to an EXISTING file, where this context shows a form of that
+        concern the file does not state — each citing this context's coordinate and
+        marked `(context: {{bc}})`.
+      - A NEW principle in the UX half, only for a lane-wide experience trait this
+        context evidences and no principle covers. Append it with the next UX-* numeral.
+      NEVER reword, reorder, renumber or delete an existing rule, principle, map bullet
+      or heading, never touch the service lane's headings or files, and add no
+      domain-specific principle, identifier or terminology.
+
+      A CONFLICT IS RECORDED, NOT RESOLVED. Where this context's UI does what an
+      existing rule or principle says the UI does not do (or the reverse), leave that
+      text as it is and add under it one line:
+      `Divergence ({{bc}}): <what this UI does> (evidence: <path>)`.
+      Name every divergence in the half's Sync Impact Report as needing a decision
+      through /appweaver constitution.
+
+      WHEN YOU CHANGE THE HALF: bump its version — MINOR for a new principle, PATCH when
+      only a divergence note was added — set Last Amended to today and keep Ratified,
+      and replace the leading Sync Impact Report comment with one for this amendment
+      (version old→new, what was added or noted and from which context).
+
+      CHANGING NOTHING IS A VALID OUTCOME. If the tier already covers everything this
+      context's UI shows, write no file and say so.
+      Write ONLY inside {{pack_dir}}/frontend/, the UI headings and table rows of
+      {{pack_dir}}/tech-rule-bindings.md, and {{constitution_ui_file}}. Modify no source.
+      Report the files you changed (an empty list when none) and, per change, the
+      concern and the code path evidencing it.
+    outputs:
+      - { name: amended_ui_files, from: "$.files" }
+
   - id: ctx_ui
     action: build_context
     condition: "{{author_ui_flag}} == true"
     context:
       - { path: "{{constitution_ui_file}}" }                                          # the target half being filled
-      - { path: "{{inventory_json}}" }                                                # PRIMARY: the COMPLETE deterministic substrate — frontend_signals + the UI file lists to read source from
+      - { path: "{{inventory_ui_json}}" }                                             # PRIMARY: the substrate's UI view — frontend_signals + the UI file lists to read source from
       - { path: .appweaver/orchestrator/rev-templates/ui-constitution.skeleton.md, optional: true }  # SHAPE ONLY: heading style, Sync-Impact-Report shape, evidence-line pattern (zero UI content)
       - { path: "{{bundle_dir}}/architecture/frontend.md", optional: true }            # SECONDARY (shallow): the OKF as-built frontend note — corroborate, don't rely on alone
   - id: author_ui
@@ -1137,10 +1422,10 @@ workflow:
       base it runs parallel to.
       Why this lane was detected: {{ui_evidence}}
       Lane declaration: {{ui_declaration_note}}
-      User hint (optional, may name nothing about the UI): {{USER_INPUT}}
+      Concerns hint: {{concerns_line}} A hint only — the UI code decides what is present.
 
       EVIDENCE = THE UI CODE ITSELF (deep read). Authority, in order:
-        1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_json}} (in context):
+        1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_ui_json}} (in context):
            `frontend_signals` lists the candidate lane roots with their kind
            (spa / server-rendered / desktop), their framework markers, and their
            component / route / store / style file lists. READ ENOUGH OF THOSE FILES to
@@ -1195,7 +1480,7 @@ workflow:
 
   - id: ui_validation_loop
     action: loop
-    condition: "{{author_ui_flag}} == true"
+    condition: "{{ui_lane}} == true"
     while: "{{ui_ok}} != true"
     max_iterations: 3
     steps:
@@ -1228,14 +1513,110 @@ workflow:
   # repo no half was created, so the run reports that rather than a bare false a reader
   # would take for a half that needs a manual touch.
   - id: ui_validation_state_absent
-    condition: "{{author_repo}} == true"
     action: set
     vars: { ui_validation_state: "n/a — no frontend lane, no UI half authored" }
   - id: ui_validation_state_present
     action: set
-    condition: "{{author_ui_flag}} == true"
+    condition: "{{ui_lane}} == true"
     vars: { ui_validation_state: "{{ui_ok}}" }
 
+  # ── AMEND THE DOMAIN TIER (a later context, the tier exists) ─────────────────
+  # The domain rule set, its map, the charter and the domain half, from this context's
+  # domain-carrying code. It runs AFTER both lane halves are settled because the domain
+  # half continues the technical half's numerals: a technical principle added above
+  # moves where the domain series starts, and this is the one step allowed to shift it.
+  # The context maps the tier keeps — the bounded-context/feature map, the requirements
+  # overview's context list, the charter's Project Identity — must carry this context,
+  # so a newly onboarded context always has at least that to write.
+  - id: ctx_amend_domain
+    condition: "{{amend_repo}} == true"
+    action: build_context
+    context:
+      - { path: "{{domain_rule_bindings}}" }
+      - { path: "{{constitution_domain_file}}" }
+      - { path: "{{constitution_technical_file}}", optional: true }   # the numerals the domain half continues (absent with no service lane)
+      - { path: .appweaver/orchestrator/rev-templates/domain-rule-file.skeleton.md, optional: true }   # SHAPE ONLY for a new rule file
+      - { path: .appweaver/RULE-PARTITION.md }
+    # The existing domain rule files (the charter and the requirements overview among
+    # them), inlined, plus the bundle framing this run just extended with the context.
+    context_from: [project_context, domain_files]
+  - id: amend_domain_tier
+    condition: "{{amend_repo}} == true"
+    action: agent_generate
+    tools: "Read,Write,Edit"
+    permission_mode: acceptEdits
+    task: |
+      AMEND the DOMAIN governance of **{{project_name}}** (project {{domain_slug}}) with
+      bounded context `{{bc}}`. The tier exists — an earlier context authored it — and
+      this run ADDS this context to it. It never re-authors it.
+
+      THE EVIDENCE IS THIS CONTEXT'S CODE. Its aggregates: {{bc_aggregates}} (features:
+      {{bc_features}}; which feature acts on which: {{bc_feature_aggregates}}). Each has
+      a concept under {{bundle_dir}}/aggregates/ whose `title` is the aggregate's name
+      and whose `source_files` list its code. Read those concepts, then READ the
+      domain-carrying files among them — entities, value objects, invariant checks,
+      validation, domain events — enough to state each rule from what the code actually
+      enforces. The OKF overview and aggregates/index.md (in context) already carry this
+      context.
+
+      WHAT EXISTS (in context): every file in {{pack_dir}}/domain/ — the rule files, the
+      requirements overview and the charter {{domain_constitution_source}} — the map
+      {{domain_rule_bindings}}, and the domain half {{constitution_domain_file}}. Read
+      all of it before writing anything.
+
+      WHAT YOU MUST ADD — this context's place in every map the tier keeps, in each
+      file that has one: the bounded-context / feature map and ubiquitous language
+      (domain-model.domain.md, where it exists), the `[DOMAIN: Bounded Contexts /
+      Modules]` map (domain-requirements.md, where it exists), the charter's Project
+      Identity context map, and the domain half's identity / context map. Add `{{bc}}`
+      with its aggregates, its features and the terms its code uses wherever a map does
+      not carry it yet (a re-run for an onboarded context usually finds it there); leave
+      every other context's entry as it is.
+
+      WHAT YOU MAY ADD — and only add:
+      - A NEW rule file `{{pack_dir}}/domain/<concern>.domain.md` for a domain concern
+        this context's code exhibits and no existing file covers, in the existing
+        files' shape (origin: reverse-engineered, generated_by: {{generated_by}}),
+        named after the concern the code exhibits. Wire it into
+        domain-rule-bindings.md under `## /aw-spec-specify` and `## /aw-spec-gate`
+        (plus `## /aw-spec-constitution` for an identity / regulatory file), as the
+        existing files are wired. `## /aw-spec-plan` and `## /aw-spec-implement` keep
+        loading no domain file.
+      - NEW rules appended to an EXISTING rule file, where this context's code enforces
+        a rule of that concern the file does not state — each citing this context's code
+        and marked `(context: {{bc}})`. Mark unresolved specifics `PROVISIONAL —
+        reconciled at adopt`.
+      - A NEW principle in the charter (the next D-n) and in the domain half, only for a
+        project-level domain trait this context evidences and no principle covers.
+      NEVER reword, reorder or delete an existing rule, principle, map bullet or entry,
+      and never touch another context's evidence. Never invent a rule the code does not
+      evidence.
+
+      NUMBERING. The domain half continues the technical half's roman numerals: its
+      first principle is the technical half's last numeral + 1 (the technical half is in
+      context; with no service lane the series starts at I). If the domain half no longer
+      starts there — a technical principle was added earlier in this run — renumber the
+      domain principles IN ORDER to resume at the right numeral, keeping every title and
+      text, and record the shift in its Sync Impact Report. That is the only renumbering
+      you may do. A new domain principle takes the next numeral after the last one.
+
+      A CONFLICT IS RECORDED, NOT RESOLVED. Where this context's code contradicts an
+      existing rule or principle, leave that text as it is and add under it one line:
+      `Divergence ({{bc}}): <what this code does> (evidence: <path>)`, and name it in the
+      domain half's Sync Impact Report as needing a decision through /appweaver
+      constitution.
+
+      THE DOMAIN HALF: bump its version — MINOR for a new principle, PATCH for context-
+      map entries, divergence notes or a numeral shift — set Last Amended to today and
+      keep Ratified, and replace the leading Sync Impact Report comment with one for this
+      amendment (version old→new, what was added and from which context).
+
+      Write ONLY inside {{pack_dir}}/domain/, {{domain_rule_bindings}} and
+      {{constitution_domain_file}}. Modify no source. Report the files you changed and,
+      per change, what was added and the code path evidencing it.
+    outputs:
+      - { name: amended_domain_files, from: "$.files" }
+
   # DOMAIN HALF — from the project + charter, principles continue the technical numbering.
   - id: ctx_domain
     condition: "{{author_repo}} == true"
@@ -1245,7 +1626,8 @@ workflow:
       - { path: "{{constitution_technical_file}}" }   # to CONTINUE its numbering (evidenced-only ⇒ not a fixed XV)
       - { path: "{{domain_constitution_source}}" }
       - { path: "{{domain_rule_bindings}}" }
-    context_from: project_context
+    # The domain rule files themselves, inlined: this step has no tools to read them by path.
+    context_from: [project_context, pack_files]
   - id: author_domain
     condition: "{{author_repo}} == true"
     action: agent_author
@@ -1254,9 +1636,9 @@ workflow:
     task: |
       Scaffold the DOMAIN ADDENDA constitution for the WHOLE PROJECT **{{project_name}}**
       (domain {{domain_slug}}) — the target file in context — AS-BUILT and PROVISIONAL,
-      from the OKF project context (overview, aggregates/index — in context) + the
-      domain-constitution source + the generated project (domain-rule-bindings in context; READ
-      the project's rule files under guardrails/projects/{{domain_slug}}/). It is a TEMPLATE
+      from the OKF project context (overview, aggregates/index) + the domain-constitution
+      source + the project's generated domain rule set (domain-rule-bindings.md and every
+      rule file it maps) — all in context. It is a TEMPLATE
       with [ALL_CAPS] tokens; this half carries ONLY domain material.
       - Name the SAME project as the technical half / charter: title / any [PROJECT_NAME]
         token = {{project_name}}. This is a PROJECT constitution, not an aggregate spec —
@@ -1287,8 +1669,8 @@ workflow:
         principles, dependent artifacts ✅/⚠ + TODOs).
       Return the complete updated domain addenda content only.
 
+  # The domain half is authored or amended on every run, so it is linted on every run.
   - id: domain_validation_loop
-    condition: "{{author_repo}} == true"
     action: loop
     while: "{{domain_ok}} != true"
     max_iterations: 3
@@ -1320,7 +1702,6 @@ workflow:
 
   # ── COMPOSE + ACTIVATE ───────────────────────────────────────────────────────
   - id: compose_constitution
-    condition: "{{author_repo}} == true"
     action: execute_script
     script: { ref: actions }
     subcommand: compose-constitution
@@ -1343,7 +1724,6 @@ workflow:
   # Ordered override — the var holds "ok" unless the check reported a problem, because
   # require_non_empty reports on EMPTY.
   - id: numbering_default
-    condition: "{{author_repo}} == true"
     action: set
     vars: { numbering_gate: "ok" }
   - id: numbering_detect
@@ -1351,7 +1731,6 @@ workflow:
     condition: "{{numbering_ok}} == false"
     vars: { numbering_gate: "" }
   - id: numbering_warning
-    condition: "{{author_repo}} == true"
     action: verify_context
     require_non_empty: numbering_gate
     on_empty: continue
@@ -1365,9 +1744,9 @@ workflow:
       constitution.md was still written so the clash is visible.
 
   # Auto-activate: point .appweaver/domain.json at the scaffolded project so the forward CR
-  # loop governs development with it from the first change.
+  # loop governs development with it from the first change. Every pass activates it, so
+  # the project this run authored or amended is the one the pipeline reads afterwards.
   - id: activate_domain
-    condition: "{{author_repo}} == true"
     action: execute_script
     script: { ref: actions }
     subcommand: set-domain
@@ -1395,19 +1774,20 @@ workflow:
   #   2. guardrails/projects/<domain>/tech-rule-bindings.md — the TECHNICAL map (resolve-tech +
   #      tech-select read it by that exact name), wiring the generated files per-workflow.
   # Because onboard already ACTIVATED brf-<domain>, the forward pipeline's + adopt's tech_select
-  # steps now resolve to THESE files — never another project's rules, ever. The project
-  # lives inside pack_dir, so pack_guard (above) already protects it from clobber.
+  # steps now resolve to THESE files — never another project's rules, ever. The files live
+  # inside pack_dir, so a later context does not author them again: service_present switches
+  # the lane to amend_service_tier above, which only adds to them.
   - id: ctx_tech_pack
     action: build_context
     condition: "{{author_svc}} == true"
     context:
-      - { path: "{{inventory_json}}" }                                                          # PRIMARY: the COMPLETE deterministic substrate — read representative SOURCE from its file lists
+      - { path: "{{inventory_service_json}}" }                                                  # PRIMARY: the substrate's service view — read representative SOURCE from its file lists
       - { path: "{{constitution_technical_file}}" }                                             # PRIMARY: the VALIDATED as-built technology base — the ratified principles these files detail
       - { path: .appweaver/orchestrator/rev-templates/tech-rule-bindings.skeleton.md, optional: true }   # SHAPE ONLY: the technical map's headings + partition + table (zero real files)
       - { path: .appweaver/orchestrator/rev-templates/technical-rule-file.skeleton.md, optional: true }  # SHAPE ONLY: one code-derived tech rule file's shape (zero real tech)
       - { path: .appweaver/RULE-PARTITION.md }                                                    # the rule-partition authority (which command reads what)
       - { path: "{{bundle_dir}}/architecture/platform.md", optional: true }                     # SECONDARY (shallow): the OKF as-built platform note — corroborate, don't rely on alone
-    context_from: design_context
+    context_from: technical_context
   - id: author_tech_pack
     action: agent_generate
     condition: "{{author_svc}} == true"
@@ -1418,14 +1798,14 @@ workflow:
       {{domain_slug}}) — the CODE-DERIVED replacement for the greenfield technical rule set —
       into guardrails/projects/{{domain_slug}}/service/ (create it), plus the technical map
       guardrails/projects/{{domain_slug}}/tech-rule-bindings.md. This is the TECHNICAL twin of the
-      already-generated domain set: it feeds the HOW phases (design/implement/build/…) plus
+      already-generated domain set: it feeds the HOW phases (plan/implement/build/…) plus
       ONE modelling-methodology file for /specify (see domain-modelling below) — and nothing
       else ever reaches /specify from this tier.
 
       EVIDENCE = THE CODE ITSELF (deep read) + THE VALIDATED TECHNICAL CONSTITUTION. Authority,
       in order:
-        1. THE ACTUAL SOURCE CODE (ground truth). Use {{inventory_json}} (in context) to locate
-           representative files across top_level_dirs + a few aggregate_signals, and Read enough
+        1. THE ACTUAL SOURCE CODE (ground truth). Use {{inventory_service_json}} (in context) to
+           locate representative files across top_level_dirs + a few aggregate_signals, and Read enough
            to state each technical rule from what the code ACTUALLY does — the folder/tier/module
            convention, the dependency direction, the persistence approach, concurrency handling,
            testing convention, the auth/cross-cutting posture. Do NOT assert structure you have
@@ -1439,17 +1819,16 @@ workflow:
       greenfield fixture, NOT this project's rules. Every path you write lives under
       guardrails/projects/{{domain_slug}}/service/.
 
-      CONCERNS HINT: {{USER_INPUT}} may carry a "concerns: a, b, c" clause. Treat any listed
-      concern as a SEARCH HINT — look for it in the code — but DECIDE presence from evidence:
-      write a tech rule file for a concern ONLY if the code exhibits it, drop a listed concern
-      the code shows none of, and ADD an unlisted concern the code clearly evidences. Ignore any
-      non-concerns text.
+      CONCERNS HINT: {{concerns_line}} Treat any listed concern as a SEARCH HINT — look for it
+      in the code — but DECIDE presence from evidence: write a tech rule file for a concern ONLY
+      if the code exhibits it, drop a listed concern the code shows none of, and ADD an unlisted
+      concern the code clearly evidences.
 
       EVIDENCED-ONLY (lean). Write a `service/<concern>.md` ONLY for a technology concern the code
       actually exhibits — e.g. as-built-architecture, persistence, concurrency, testing,
       security-posture, api-surface, eventing, observability, hosting. Follow the SHAPE of
       technical-rule-file.skeleton.md (in context): frontmatter (origin: reverse-engineered,
-      generated_by: aw-spec-onboard/1.6.0, concern), a one-line framing, rules each citing a CODE
+      generated_by: {{generated_by}}, concern), a one-line framing, rules each citing a CODE
       COORDINATE (real file/folder path or named type) + the constitution principle numeral where
       it maps. The skeleton carries NO real technology — copy the shape only. State stubs/partials
       AS-BUILT (do not upgrade a stub into a greenfield ideal); omit a concern the code shows none
@@ -1480,12 +1859,12 @@ workflow:
       ONLY a heading you have a generated file for (an absent heading soft-continues → loads
       nothing):
         - `## /aw-spec-specify`         — EXACTLY ONE bullet: `service/domain-modelling.md`, the modelling methodology. NEVER an architecture / persistence / codegen / security file here — specify is the domain phase and any technology rule under this heading breaks its domain purity. Omit the heading only if you did not write domain-modelling.md.
-        - `## /aw-spec-plan`          — the as-built architecture / cross-cutting rules the design author mediates the spec against.
+        - `## /aw-spec-plan`          — the as-built architecture / cross-cutting rules the SERVICE lane's plan author mediates the spec against.
         - `## /aw-spec-implement`        — the code-generation / convention set the SERVICE lane's generator builds against (from backend-plan.md).
         - `## /aw-spec-implement-delta`  — the same set for the service lane on the DELTA path. `implement` is one command that keys this heading when it is generating a change's delta plan and the one above when it is generating the master, so a project that wants the same rules on both paths repeats them here.
         - `## /aw-spec-build`            — the layering + convention rules the compile-fixer respects.
-        - `## /aw-spec-analyze-slice`    — the conformance rules the design↔code gate validates against.
-        - `## /aw-spec-adopt`            — the technical reference set the reversed design mediates against (a subset of design's).
+        - `## /aw-spec-analyze-slice`    — the conformance rules the plan↔code gate validates against.
+        - `## /aw-spec-adopt`            — the technical reference set the reversed plan mediates against (a subset of plan's).
         - `## /aw-spec-constitution`     — the standards a later `/appweaver constitution` re-ratifies the TECHNICAL half from. You authored that half from code evidence before these files existed; this heading is what makes a re-run author from THIS project's rules rather than from an empty set. Ratifiable standards only, no worked `examples/` sample, no domain file.
         - `## /aw-spec-run`              — the runtime / execution conventions the app-run step honors (add ONLY if the code evidences a runtime/hosting concern file; NOT data-migration — migration is the deferred later phase).
       Each bullet is a
@@ -1503,7 +1882,7 @@ workflow:
     on_empty: stop
     on_empty_message: "No technical rule files were written to guardrails/projects/{{domain_slug}}/service/. Ensure the scan substrate (inventory_json) + the validated technical constitution carry an as-built technology base and re-run."
   - id: require_tech_rule_bindings
-    condition: "{{author_repo}} == true"
+    condition: "{{author_svc}} == true"
     action: verify_context
     required_files: ["{{pack_dir}}/tech-rule-bindings.md"]
 
@@ -1516,7 +1895,7 @@ workflow:
   # file, and the run's remaining work is worth keeping either way.
   - id: probe_specify_wiring
     action: execute_script
-    condition: "{{author_svc}} == true"
+    condition: "{{svc_lane}} == true"
     on_error: continue
     script: { ref: actions }
     subcommand: resolve-tech
@@ -1525,7 +1904,7 @@ workflow:
       - { name: specify_rules, from: "$.candidates" }
   - id: warn_specify_wiring
     action: verify_context
-    condition: "{{author_svc}} == true"
+    condition: "{{svc_lane}} == true"
     require_non_empty: specify_rules
     on_empty: continue
     on_empty_message: >
@@ -1542,18 +1921,20 @@ workflow:
   # enforceable rule ↓), exactly as service/ is the detail layer under the technical half.
   #
   # Runs AFTER the technical set because both write the SAME map file: the technical set
-  # authors tech-rule-bindings.md, and this step APPENDS the lane's heading to it. That
-  # heading is what makes a later /appweaver constitution re-ratify the UI half from
-  # THIS project's lane rules — and it is also the authoritative signal that the project
-  # HAS a frontend lane, so writing it is what lets the greenfield constitution command
-  # find the lane on every future run without stacks.json or a named stack.
+  # authors tech-rule-bindings.md, and this step APPENDS the lane's three headings to it
+  # (or creates the file, in a project with no service lane). `## /aw-spec-ui-constitution`
+  # is what makes a later /appweaver constitution re-ratify the UI half from THIS project's
+  # lane rules, and the authoritative signal that the project HAS a frontend lane.
+  # `## /aw-spec-plan-ui` and `## /aw-spec-implement-ui` are what the frontend lane of
+  # `plan` and of `implement` load; without them that lane plans and generates against no
+  # project rule at all.
   - id: ctx_ui_pack
     action: build_context
     condition: "{{author_ui_flag}} == true"
     context:
-      - { path: "{{inventory_json}}" }                                                            # PRIMARY: the COMPLETE deterministic substrate — frontend_signals + the UI file lists to read source from
+      - { path: "{{inventory_ui_json}}" }                                                         # PRIMARY: the substrate's UI view — frontend_signals + the UI file lists to read source from
       - { path: "{{constitution_ui_file}}" }                                                      # PRIMARY: the VALIDATED as-built UX-* base — the ratified principles these files detail
-      - { path: "{{pack_dir}}/tech-rule-bindings.md" }                                            # the map to APPEND to — read it so the edit preserves what the technical set wrote
+      - { path: "{{pack_dir}}/tech-rule-bindings.md", optional: true }                            # the map to APPEND to — absent only where no service lane is declared
       - { path: .appweaver/orchestrator/rev-templates/frontend-rule-file.skeleton.md, optional: true }   # SHAPE ONLY: one code-derived lane rule file's shape (zero real UI tech)
       - { path: .appweaver/orchestrator/rev-templates/tech-rule-bindings.skeleton.md, optional: true }   # SHAPE ONLY: the technical map's headings + partition + table
       - { path: .appweaver/RULE-PARTITION.md }                                                      # the rule-partition authority (which command reads what)
@@ -1573,7 +1954,7 @@ workflow:
 
       EVIDENCE = THE UI CODE ITSELF (deep read) + THE VALIDATED UI CONSTITUTION. Authority,
       in order:
-        1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_json}} (in context):
+        1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_ui_json}} (in context):
            `frontend_signals` gives the lane roots, their kind, their framework markers and
            their component / route / store / style file lists. Read enough of those files to
            state each rule from what the UI ACTUALLY does. Do NOT assert a convention you
@@ -1589,7 +1970,7 @@ workflow:
       Every path you write lives under guardrails/projects/{{domain_slug}}/frontend/.
 
       EVIDENCED-ONLY (lean). Follow the SHAPE of frontend-rule-file.skeleton.md (in context):
-      frontmatter (origin: reverse-engineered, generated_by: aw-spec-onboard/1.6.0, concern),
+      frontmatter (origin: reverse-engineered, generated_by: {{generated_by}}, concern),
       a one-line framing, then rules each citing a CODE COORDINATE (a real component / route /
       store / stylesheet / config path) and the UX principle numeral where it maps.
       - `frontend/ui-constitution.md` — ALWAYS, the lane's base file: the lane declaration
@@ -1605,24 +1986,29 @@ workflow:
       divergence with its coordinates. Do not upgrade a partial into a greenfield ideal, and
       do not create a debt/backlog sink — modernization is a separate later phase.
 
-      WIRE THE MAP — EDIT guardrails/projects/{{domain_slug}}/tech-rule-bindings.md IN PLACE.
-      It already exists and carries the technical headings you wrote; PRESERVE all of them
-      byte-for-byte. Make exactly two additions:
-        1. A `## /aw-spec-ui-constitution` section, placed after the last technical heading
-           and BEFORE the closing quick-reference table. Bullet ONLY the frontend files you
-           just generated, `frontend/ui-constitution.md` first, each as a workspace-relative
-           path `- guardrails/projects/{{domain_slug}}/frontend/<file>`. Ratifiable lane
-           standards only — no domain file, no technical file, no example. Precede them with
-           a short HTML comment saying what this half ratifies and that the heading is also
-           the authoritative signal that the project has a frontend lane.
-        2. Its row in the quick-reference table, in the same format as the existing rows.
-      Do NOT add `## /aw-spec-plan-ui` or `## /aw-spec-implement-ui` — the frontend lane's
-      headings in `plan` and `implement`. ⌛ Both phases DO exist now, but those two headings
-      are a different TIER from the one you just wrote: `## /aw-spec-ui-constitution` maps the
-      lane's RATIFIABLE standards, and those two map its per-phase authoring and
-      code-generation sets. The files above have not been separated into those tiers, and
-      mapping one file under a heading of the wrong tier is what makes a generator obey a
-      standard nobody ratified. Splitting them is the UI lane's own follow-up.
+      WIRE THE MAP — guardrails/projects/{{domain_slug}}/tech-rule-bindings.md. Where the
+      service rule set was generated it exists and carries the technical headings: EDIT IT IN
+      PLACE and PRESERVE every one of them byte-for-byte. Where this project has no service
+      lane it does not exist yet: CREATE it with the skeleton's title and framing and only the
+      headings below. Add the lane's THREE headings after the last technical heading and
+      BEFORE the closing quick-reference table. Every bullet is a workspace-relative path
+      `- guardrails/projects/{{domain_slug}}/frontend/<file>` naming a file you just generated:
+        1. `## /aw-spec-ui-constitution` — the lane's RATIFIABLE standards,
+           `frontend/ui-constitution.md` first. It is what a later /appweaver constitution
+           re-ratifies the UI half from, and the authoritative signal that the project has a
+           frontend lane; precede the bullets with a short HTML comment saying both.
+        2. `## /aw-spec-plan-ui` — the files the FRONTEND lane of `plan` authors
+           frontend-plan.md against: those whose rules decide a feature's screens, navigation,
+           client state, interaction states, forms, accessibility and service binding.
+        3. `## /aw-spec-implement-ui` — the files the FRONTEND lane of `implement` generates
+           code against, on the master and the delta path alike: those whose rules govern
+           component conventions, state and data fetching, styling, forms and UI tests.
+      A file whose rules carry both a planning half and a generating half is listed under both
+      2 and 3 — a rule read by only one of the two phases loses its other half. Do NOT list
+      `frontend/ui-constitution.md` under 2 or 3: it is the source the UI half is ratified
+      from, and both phases already read that half (constitution.ui.md) directly. No domain
+      file, no service/ file and no example under any of the three. Give each heading its row
+      in the quick-reference table, in the same format as the existing rows.
 
       Write ONLY inside guardrails/projects/{{domain_slug}}/ (frontend/ + the map edit); modify
       no source. Report the files written, the concerns you found present with the code paths
@@ -1634,6 +2020,7 @@ workflow:
     action: verify_context
     condition: "{{author_ui_flag}} == true"
     require_non_empty: ui_pack_files
+    required_files: ["{{pack_dir}}/frontend/ui-constitution.md", "{{pack_dir}}/tech-rule-bindings.md"]
     on_empty: stop
     on_empty_message: "A frontend lane was detected ({{ui_evidence}}) but no lane rule files were written to guardrails/projects/{{domain_slug}}/frontend/. Check that the scan substrate's frontend_signals carry readable UI source, then re-run."
 
@@ -1644,7 +2031,7 @@ workflow:
   # it. Announce, don't stop — the rule files are on disk and the heading is one edit away.
   - id: probe_ui_wiring
     action: execute_script
-    condition: "{{author_ui_flag}} == true"
+    condition: "{{ui_lane}} == true"
     on_error: continue
     script: { ref: actions }
     subcommand: resolve-tech
@@ -1653,7 +2040,7 @@ workflow:
       - { name: ui_map_rules, from: "$.candidates" }
   - id: warn_ui_wiring
     action: verify_context
-    condition: "{{author_ui_flag}} == true"
+    condition: "{{ui_lane}} == true"
     require_non_empty: ui_map_rules
     on_empty: continue
     on_empty_message: >
@@ -1664,6 +2051,48 @@ workflow:
       project as backend-only. Add the heading after the last technical one, bulleting
       frontend/ui-constitution.md first, then the rest of the frontend/ set.
 
+  # The same read-back for the two headings the frontend lane's PHASES key on. Empty
+  # means that lane of `plan` / `implement` runs with the ratified UX-* base and no
+  # project rule file at all.
+  - id: probe_ui_plan_wiring
+    action: execute_script
+    condition: "{{ui_lane}} == true"
+    on_error: continue
+    script: { ref: actions }
+    subcommand: resolve-tech
+    args: ["--command", "aw-spec-plan-ui"]
+    outputs:
+      - { name: ui_plan_rules, from: "$.candidates" }
+  - id: warn_ui_plan_wiring
+    action: verify_context
+    condition: "{{ui_lane}} == true"
+    require_non_empty: ui_plan_rules
+    on_empty: continue
+    on_empty_message: >
+      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      `## /aw-spec-plan-ui`, so the frontend lane of /appweaver plan will author
+      frontend-plan.md with no project rule file. Add the heading, bulleting the
+      frontend/ files whose rules shape a feature's screens, state and interactions.
+  - id: probe_ui_impl_wiring
+    action: execute_script
+    condition: "{{ui_lane}} == true"
+    on_error: continue
+    script: { ref: actions }
+    subcommand: resolve-tech
+    args: ["--command", "aw-spec-implement-ui"]
+    outputs:
+      - { name: ui_impl_rules, from: "$.candidates" }
+  - id: warn_ui_impl_wiring
+    action: verify_context
+    condition: "{{ui_lane}} == true"
+    require_non_empty: ui_impl_rules
+    on_empty: continue
+    on_empty_message: >
+      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      `## /aw-spec-implement-ui`, so the frontend lane of /appweaver implement will
+      generate UI code with no project rule file. Add the heading, bulleting the
+      frontend/ files whose rules govern component, state, styling and test conventions.
+
   # ═══════════ LANE DECLARATION — read back, never written ═══════════════════════
   # onboard does not declare lanes. It used to: before select-stack was the first
   # command of this sequence, a repo could arrive here with no declaration at all, so
@@ -1681,7 +2110,6 @@ workflow:
   # the run reports the lanes it actually scanned under rather than a second opinion
   # about them.
   - id: lane_readback
-    condition: "{{author_repo}} == true"
     action: execute_script
     on_error: continue
     script: { ref: actions }
@@ -1702,11 +2130,11 @@ workflow:
   # DESIGN CONVENTION by REVERSE-ENGINEERING its own technical structure into a project-
   # specific design + delta-design template pair, written to the PROJECT-LEVEL override slot
   # (.appweaver/templates/overrides/{design,delta-design}-template.md — resolve_template
-  # Priority-1). The forward `design` phase's brownfield branch (design-scaffold reports
-  # override_active ⇒ design_mode == bootstrap_bf) then authors EVERY new feature against the
-  # as-built architecture, and a CHANGE authors its delta-design against the SAME code-derived
-  # sections (cr-setup scaffolds the delta from resolve_template("delta-design-template") ⇒
-  # the override) — no adopt required, consistent with the backend-plan.md adopt emits.
+  # Priority-1). The service lane of `plan` (plan-scaffold reports override_active ⇒
+  # be_mode == bootstrap_bf) then authors EVERY new feature's backend-plan.md against the
+  # as-built architecture, and a CHANGE authors its delta plan against the SAME code-derived
+  # sections (delta-plan-scaffold resolves "delta-design-template" ⇒ the override) — no adopt
+  # required, consistent with the backend-plan.md adopt emits.
   #
   # THE TEMPLATE IDENTIFIERS KEEP THE `design-template` SPELLING DELIBERATELY. The DOCUMENTS
   # are backend-plan.md / frontend-plan.md now; the template NAMES are not, because a repo
@@ -1728,14 +2156,15 @@ workflow:
   # (header block, the §1.2 domain/data-model anchor, the traceability spine, the two
   # deferral ledgers, Change History, the tech-agnostic authoring rules) with the layering
   # removed and every structural section left as a slot the code fills. The generated
-  # template keeps the §0–§6 shape the forward `design` bootstrap_bf branch expects and the
-  # two anchors aw-xref keys on, so no workflow change is needed to consume it.
+  # template keeps the §0–§6 shape `plan`'s bootstrap_bf branch expects and the two
+  # anchors aw-xref keys on, so no workflow change is needed to consume it.
   #
   # WHERE A FRONTEND LANE EXISTS the lane gets its OWN pair (ui-design-template +
   # ui-delta-design-template, below), so this pair covers the SERVICE lane only and excludes
   # the lane's roots from the structure it derives. One lane's template never describes the
-  # other's code. Re-onboard is gated upstream (bundle_guard / pack_guard) — remove the OKF
-  # bundle to regenerate.
+  # other's code. The templates are authored when their lane's tier is first authored — by
+  # the first context, or by the run that first sees a lane declared later — and are never
+  # amended: every plan already written follows their shape.
 
   # DESIGN template — the code-derived evidence (code + inventory + technical constitution)
   # plus a NEUTRAL skeleton for the bones. No greenfield template is in context.
@@ -1743,7 +2172,7 @@ workflow:
     action: build_context
     condition: "{{author_svc}} == true"
     context:
-      - { path: "{{inventory_json}}" }                                        # PRIMARY: the COMPLETE deterministic substrate (top_level_dirs, aggregate_signals' per-layer file groupings) — the OKF markdown only SUMMARISES this
+      - { path: "{{inventory_service_json}}" }                                # PRIMARY: the substrate's service view (top_level_dirs, aggregate_signals' per-layer file groupings) — the OKF markdown only SUMMARISES this
       - { path: "{{constitution_technical_file}}" }                           # PRIMARY: the VALIDATED as-built technology base (framework/persistence/concurrency/hosting/testing/cross-cutting)
       - { path: .appweaver/orchestrator/rev-templates/design-template.skeleton.md }   # SHAPE ONLY: the neutral bones + the pinned anchors + tech-agnostic authoring rules (zero layering, zero technology)
       - { path: .appweaver/DESIGN-FORMAT.md }                                   # the HLD contract + its Brownfield variant note (which anchors are pinned, and why)
@@ -1759,16 +2188,16 @@ workflow:
       REVERSE-ENGINEER this repo's design convention into a PROJECT-SPECIFIC design
       TEMPLATE and Write it to .appweaver/templates/overrides/design-template.md (create the
       overrides/ dir if absent). It is a TEMPLATE — concrete project-derived section HEADERS
-      with [PLACEHOLDER] tokens + authoring HTML comments the forward `design` phase fills
-      per feature — NOT a filled design.
+      with [PLACEHOLDER] tokens + authoring HTML comments the service lane of `plan` fills
+      per feature into specs/<Context>/<Feature>/backend-plan.md — NOT a filled plan.
 
       GROUND EVERYTHING IN THE CODE + THE REVERSE-ENGINEERED FILES — not the shallow OKF map
       and not any architecture you know from elsewhere. Evidence authority, in order:
         1. THE ACTUAL SOURCE CODE (ground truth). Read REPRESENTATIVE source files across the
-           repo's top_level_dirs and a few aggregate_signals (from {{inventory_json}}) — enough
+           repo's top_level_dirs and a few aggregate_signals (from {{inventory_service_json}}) — enough
            to CONFIRM from the code the recurring folder/tier/module convention + the dependency
            direction it actually follows. Do NOT assert structure you have not seen in the code.
-        2. {{inventory_json}} — the COMPLETE deterministic scan substrate (top_level_dirs, each
+        2. {{inventory_service_json}} — the deterministic scan substrate's service view (top_level_dirs, each
            aggregate_signal's files grouped by layer, categories, tech stack). The OKF markdown
            only SUMMARISES this, shallowly — prefer the substrate + the code over it.
         3. The TECHNICAL CONSTITUTION (constitution.technical.md, in context) — the VALIDATED
@@ -1796,10 +2225,10 @@ workflow:
       folders + the dependency rule) from evidence 1–3 — this ONE template governs every
       future feature.
 
-      Then AUTHOR the template on the skeleton's §0–§6 shape (the shape the forward `design`
-      brownfield branch expects — keep these section numbers + headings):
-      - Keep the skeleton's header block (Aggregate / Design home / Source spec / Version /
-        Status) and its TECHNOLOGY-AGNOSTIC authoring rules (behaviour as signatures +
+      Then AUTHOR the template on the skeleton's §0–§6 shape (the shape `plan`'s
+      bootstrap_bf branch expects — keep these section numbers + headings):
+      - Keep the skeleton's header block (Feature / Plan home / Source spec / Source model /
+        Version / Status) and its TECHNOLOGY-AGNOSTIC authoring rules (behaviour as signatures +
         pre/post/invariant/raises, contracts as field shapes, NO code; every element traces to
         a spec id). Fill [GENERATED_STRUCTURE_NOTE] with this project's convention.
       - §0 Design Overview + `### Ubiquitous Language (design delta)` — carry over as-is.
@@ -1829,8 +2258,8 @@ workflow:
         deviations, NOT "organised unlike a reference architecture" (that is the as-built
         shape, §1.1).
       - Change History — carry over.
-      Keep every [PLACEHOLDER] and authoring comment so `design` can fill it — and in those
-      comments DIRECT the downstream author (forward `design` / adopt) to GROUND each filled
+      Keep every [PLACEHOLDER] and authoring comment so `plan` can fill it — and in those
+      comments DIRECT the downstream author (`plan` / adopt) to GROUND each filled
       section in the ACTUAL CODE + the reverse-engineered files (cite real file/folder paths and
       the relevant technical-constitution principle). Do NOT invent project structure the code
       does not show; where the convention is unclear, template a generic axis and flag it in a
@@ -1844,12 +2273,13 @@ workflow:
     action: verify_context
     condition: "{{author_svc}} == true"
     require_non_empty: design_template_files
+    required_files: [".appweaver/templates/overrides/design-template.md"]
     on_empty: stop
     on_empty_message: "No design template was written to .appweaver/templates/overrides/design-template.md. Ensure the scan substrate (inventory_json) + the technical constitution are present and re-run."
 
   # DELTA-DESIGN template — MIRROR the just-generated master template's OWN sections so a
   # change classifies ADDED/MODIFIED/REMOVED against the code-derived structure, not the
-  # greenfield four layers. Aligns with the delta-design module (classifies "per the
+  # greenfield four layers. Aligns with the delta-plan module (classifies "per the
   # master's OWN section structure").
   - id: ctx_delta_design_template
     action: build_context
@@ -1867,20 +2297,21 @@ workflow:
       Author the matching PROJECT-SPECIFIC DELTA-design TEMPLATE and Write it to
       .appweaver/templates/overrides/delta-design-template.md. It is a TEMPLATE (placeholders
       + authoring comments) for classifying a CHANGE to a feature as ADDED / MODIFIED /
-      REMOVED against the master design.md.
+      REMOVED against the master backend-plan.md.
 
       MIRROR the just-generated master template (.appweaver/templates/overrides/design-template.md,
       in context — Read it): its ADDED/MODIFIED/REMOVED tables must key off the master's OWN
       code-derived sections (§1.1/§1.2, the §2.n axes it derived, §3). Use the skeleton's
-      "Section (§ in design.md)" column and fill its example rows with the ACTUAL sections of
+      "Section (§ in backend-plan.md)" column and fill its example rows with the ACTUAL sections of
       the generated master template. Never name a layering — neither one you know nor one the
       master did not derive.
       - CARRY OVER the neutral parts of rev-templates/delta-design-template.skeleton.md (in
         context): Change summary, Cross-section impact, Regression targets, New assumptions/
-        deviations (DA-n / WA-n), On close. Keep behaviour technology-agnostic (signatures +
+        deviations (DA-n / WA-n), On merge — word for word: finalize-delta merges the spec and
+        the model, never this plan, which `plan main` re-derives. Keep behaviour technology-agnostic (signatures +
         contracts, no code); a shared element is MODIFIED in place, never duplicated; every
         changed element serves a spec id.
-      - This aligns with the delta-design module, which classifies "per the master's OWN
+      - This aligns with the delta-plan module, which classifies "per the master's OWN
         section structure" — so the template MUST NOT hardcode a fixed layering.
       Keep every [PLACEHOLDER] and authoring comment. Write ONLY the override file; modify no
       source. Report the file written.
@@ -1891,6 +2322,7 @@ workflow:
     action: verify_context
     condition: "{{author_svc}} == true"
     require_non_empty: delta_design_template_files
+    required_files: [".appweaver/templates/overrides/delta-design-template.md"]
     on_empty: stop
     on_empty_message: "No delta-design template was written to .appweaver/templates/overrides/delta-design-template.md. Re-run onboard after confirming the design template override was generated."
 
@@ -1971,6 +2403,7 @@ workflow:
     condition: "{{author_repo}} == true"
     action: verify_context
     require_non_empty: model_template_files
+    required_files: [".appweaver/templates/overrides/domain-model-template.md"]
     on_empty: stop
     on_empty_message: "No domain-model template was written to .appweaver/templates/overrides/domain-model-template.md. Without it every reversed slice authors its aggregate against the kit's GREENFIELD model template, whose shape assumes a domain designed before it was built. Ensure the scan substrate (inventory_json) is present and re-run."
 
@@ -1984,12 +2417,13 @@ workflow:
   # WHY THE LANE NEEDS ITS OWN PAIR rather than a section inside the service design: the
   # two lanes are governed by different constitution halves and different map headings,
   # they are implemented by different commands, and the ONLY thing that crosses between
-  # them is the design contract. A UI section inside design.md would put the lane's
-  # structure under the service lane's rules and hand ⌛ ui-design the whole service
-  # design to read — precisely the context leak the contract projection exists to stop.
+  # them is the service's published surface. A UI section inside backend-plan.md would put
+  # the lane's structure under the service lane's rules and hand the frontend lane of `plan`
+  # the whole backend plan to read — precisely the leak §5's published-surface boundary
+  # exists to stop.
   #
   # THE SECTION LIST IS RATIFIED, THE CONTENT IS THE CODE'S. aw-spec specifies what
-  # design.ui.md contains (navigation & screen structure · client state · component
+  # frontend-plan.md contains (navigation & screen structure · client state · component
   # structure · interaction & flow · contract binding · cross-cutting · traceability ·
   # DA-n · WA-n); the skeleton carries exactly that, framework-free. What this step
   # derives from the lane's source is what goes IN those sections — the real composition
@@ -1998,13 +2432,13 @@ workflow:
   # THE CONSUMERS ARE BUILT: the frontend lane of `plan` scaffolds from this override when
   # onboard installed one (plan-scaffold reports override_active), and the frontend lane of
   # `implement` generates from the plan it produced. The templates are written HERE because
-  # the evidence for them is the whole-repo vantage that exists exactly once, at onboard, and
-  # nothing breaks for their absence in a repo that never onboarded.
+  # the evidence for them is onboard's whole-repo scan, and nothing breaks for their absence
+  # in a repo that never onboarded.
   - id: ctx_ui_design_template
     action: build_context
     condition: "{{author_ui_flag}} == true"
     context:
-      - { path: "{{inventory_json}}" }                                                     # PRIMARY: the COMPLETE deterministic substrate — frontend_signals + the component/route/store/style file lists to read source from
+      - { path: "{{inventory_ui_json}}" }                                                  # PRIMARY: the substrate's UI view — frontend_signals + the component/route/store/style file lists to read source from
       - { path: "{{constitution_ui_file}}" }                                               # PRIMARY: the VALIDATED as-built UX-* base — the ratified principles this structure must serve
       - { path: .appweaver/orchestrator/rev-templates/ui-design-template.skeleton.md }       # SHAPE ONLY: the ratified section list + neutral bones (zero framework, zero component library)
       - { path: "{{pack_dir}}/frontend/ui-constitution.md", optional: true }               # the generated lane rule set's base file — the detail layer under those principles
@@ -2018,12 +2452,12 @@ workflow:
       REVERSE-ENGINEER this repo's FRONTEND LANE into a PROJECT-SPECIFIC UI DESIGN TEMPLATE
       and Write it to .appweaver/templates/overrides/ui-design-template.md (create the
       overrides/ dir if absent). It is a TEMPLATE — concrete lane-derived section content
-      with [PLACEHOLDER] tokens + authoring HTML comments that ⌛ `ui-design` fills per
-      feature into specs/<Feature>/design.ui.md — NOT a filled design.
+      with [PLACEHOLDER] tokens + authoring HTML comments that the frontend lane of `plan`
+      fills per feature into specs/<Context>/<Feature>/frontend-plan.md — NOT a filled plan.
       The lane: {{ui_evidence}} · roots: {{frontend_roots}}
 
       GROUND EVERYTHING IN THE LANE'S OWN CODE. Evidence authority, in order:
-        1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_json}} (in context):
+        1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_ui_json}} (in context):
            `frontend_signals` gives the lane roots, their kind (spa / server-rendered /
            desktop), their framework markers and their component / route / store / style
            file lists. READ ENOUGH OF THOSE FILES to state each structural claim from what
@@ -2070,13 +2504,14 @@ workflow:
         shows little. They are the two sections a backend-shaped process drops and where
         most UI defects live. Where the code handles no error or empty state, template the
         section so the downstream author must record that as-built — never delete it.
-      - §5 Contract Binding — keep the lane boundary intact: the binding table reads the
-        ⌛ design-contract projection, never the service design. Note in the authoring
-        comment that where no contract document exists yet the author binds against the
-        spec's own IC-/FR- surface and logs a §8 assumption.
+      - §5 Contract Binding — keep the lane boundary intact: the binding table binds
+        against the service's PUBLISHED SURFACE (the spec's IC- ids and the API contracts
+        backend-plan.md states), never the service's internals. Note in the authoring
+        comment that where the surface does not name an operation yet, the author binds
+        against the spec's own IC-/FR- surface and logs a §8 assumption.
       - §7 Traceability, §8 Assumptions (DA-n), §9 Deviations (WA-n), Change History — carry
         over; the §7 Section column uses THIS template's own section refs.
-      Keep every [PLACEHOLDER] and authoring comment so ⌛ `ui-design` can fill it — and in
+      Keep every [PLACEHOLDER] and authoring comment so `plan` can fill it — and in
       those comments DIRECT the downstream author to GROUND each filled section in the
       ACTUAL UI CODE and the lane's governance (cite real component/route/store/stylesheet
       paths and the constitution.ui.md UX numeral). Do NOT invent lane structure the code
@@ -2091,6 +2526,7 @@ workflow:
     action: verify_context
     condition: "{{author_ui_flag}} == true"
     require_non_empty: ui_design_template_files
+    required_files: [".appweaver/templates/overrides/ui-design-template.md"]
     on_empty: stop
     on_empty_message: "A frontend lane was detected ({{ui_evidence}}) but no UI design template was written to .appweaver/templates/overrides/ui-design-template.md. Check that the scan substrate's frontend_signals carry readable UI source, then re-run."
 
@@ -2112,18 +2548,19 @@ workflow:
       Author the matching PROJECT-SPECIFIC UI DELTA-design TEMPLATE and Write it to
       .appweaver/templates/overrides/ui-delta-design-template.md. It is a TEMPLATE
       (placeholders + authoring comments) for classifying a CHANGE to a feature's
-      EXPERIENCE as ADDED / MODIFIED / REMOVED against the master design.ui.md.
+      EXPERIENCE as ADDED / MODIFIED / REMOVED against the master frontend-plan.md.
 
       MIRROR the just-generated lane master (.appweaver/templates/overrides/ui-design-template.md,
       in context — Read it): its ADDED/MODIFIED/REMOVED tables must key off that master's OWN
       sections, including whatever composition axes its §3 derived. Use the skeleton's
-      "Section (§ in design.ui.md)" column and fill its example rows with the ACTUAL sections
+      "Section (§ in frontend-plan.md)" column and fill its example rows with the ACTUAL sections
       of the generated master. Never name a framework or a UI taxonomy the master did not
       derive.
       - CARRY OVER the neutral parts of rev-templates/ui-delta-design-template.skeleton.md
         (in context): Change summary, Interaction states touched, Contract impact,
         Cross-section impact, Regression targets, New assumptions/deviations (DA-n / WA-n),
-        On close.
+        On merge — word for word: finalize-delta merges the spec and the model, never this
+        plan, which `plan main` re-derives.
       - KEEP the "Interaction states touched" section whatever this lane's code shows: a new
         interaction that ships without its loading, empty, error and permission-denied states
         is an incomplete delta, and the template is where that is enforced.
@@ -2141,6 +2578,7 @@ workflow:
     action: verify_context
     condition: "{{author_ui_flag}} == true"
     require_non_empty: ui_delta_design_template_files
+    required_files: [".appweaver/templates/overrides/ui-delta-design-template.md"]
     on_empty: stop
     on_empty_message: "No UI delta-design template was written to .appweaver/templates/overrides/ui-delta-design-template.md. Re-run onboard after confirming the UI design template override was generated."
 
@@ -2210,4 +2648,11 @@ outputs:
   ui_delta_design_template_files: "{{ui_delta_design_template_files}}"
   technical_validation_ok: "{{technical_ok}}"
   domain_validation_ok: "{{domain_ok}}"
-  next: "Onboarded bounded context {{bc}} ({{bc_feature_count}} feature(s): {{bc_features}}). Its aggregate concepts ({{bc_aggregates}}) are in {{bundle_dir}}, each keyed `bounded_context: {{bc}}` and listing the features that act on it — the bundle is the project's knowledge, one concept per aggregate, never one per feature — and its specs tree now exists at {{bc_dir}}/ with a directory per feature ({{feature_dirs}}) — EMPTY on purpose: the directory says the feature is known, and the documents that describe it are written per feature by /appweaver adopt and per context by /appweaver specify. {{bc}} is now the ACTIVE bounded context (.appweaver/context.json), so /appweaver select-feature lists exactly these features and nothing from a neighbouring context; switch with /appweaver select-bounded-context. ONBOARD RUNS ONCE PER CONTEXT: contexts already done — {{onboarded_contexts}}; still open — {{remaining_contexts}}; the order the map gives is {{contexts_ordered}}. Run /appweaver onboard <NextContext> for each remaining one, or with no argument to take the next one automatically. THE PROJECT TIER IS WRITTEN ONCE, BY THE FIRST CONTEXT (this run was first: {{is_first}}). That tier is the PROVISIONAL governance scaffold — the split constitution, the domain rule set at guardrails/projects/{{domain_slug}}/domain/*.domain.md + domain-rule-bindings.md, each declared LANE\'s rule set and constitution half, the activated domain {{active_domain}}, and the code-derived design / delta-design / domain-model template overrides in .appweaver/templates/overrides/. A later context does NOT re-author any of it: re-deriving project principles from one context\'s evidence is the scoping bias the governance tier exists to avoid. Amend it with /appweaver constitution. ONE HALF AND ONE RULE SET PER LANE: service_lane / ui_lane report which lanes .appweaver/stacks.json declared, and the declaration is what decided. A lane declared (none) in select-stack gets none of it, which is the correct outcome and not an omission. LANE DECLARATION: read, never written — select-stack is its sole writer, and this run scanned the source paths it named (scanned_service_root / scanned_ui_root); scanned_backend_files / scanned_ui_files report each. ui_source_evidence_found false means the UI lane\'s declared path held nothing a scan recognises as UI, so its governance is thin — move the source path with /appweaver select-stack and re-run. The build/test/run commands on each lane are that PROFILE\'s defaults and may not match a legacy layout — review them. Because the domain is activated, resolve-domain + resolve-tech route the WHOLE forward pipeline to these code-derived rules — never another project\'s rules as a fallback. THE BOUNDARIES CAME FROM THE MAP, not from this run: /appweaver inventory proposed them and you confirmed them in specs/proposed-inventory.md. To change a boundary, edit that file and run /appweaver inventory apply — a context whose concepts already exist is not re-onboarded. Develop an EXISTING feature just-in-time: /appweaver adopt <Feature> reverse-engineers its spec.md + backend-plan.md + source-map.md and deepens the OKF concept of the aggregate it acts on. Develop a NEW feature straight through the forward pipeline — /appweaver select-feature FIRST (specify and every stage after it read the active feature and STOP without one), then specify → plan → analyze-plan → implement → build → analyze-slice → run. Then drive every change through the CR delta loop (/appweaver specify → plan → analyze-plan-delta → implement → build → analyze-slice-delta → finalize-delta → analyze-slice → close-delta). If a validation_ok is false, its constitution half needs a manual touch (see its Sync Impact Report)."
+  # Authored (the first context, or a lane tier that did not exist) or amended (a later
+  # context adding its evidence), and what each amendment step changed — empty when the
+  # tier already covered this context.
+  governance_mode: "{{gov_mode}}"
+  amended_domain_files: "{{amended_domain_files}}"
+  amended_service_files: "{{amended_service_files}}"
+  amended_ui_files: "{{amended_ui_files}}"
+  next: "Onboarded bounded context {{bc}} ({{bc_feature_count}} feature(s): {{bc_features}}). Its aggregate concepts ({{bc_aggregates}}) are in {{bundle_dir}}, each keyed `bounded_context: {{bc}}` and listing the features that act on it — the bundle is the project's knowledge, one concept per aggregate, never one per feature — and its specs tree now exists at {{bc_dir}}/ with a directory per feature ({{feature_dirs}}) — EMPTY on purpose: the directory says the feature is known, and the documents that describe it are written per feature by /appweaver adopt and per context by /appweaver specify. {{bc}} is now the ACTIVE bounded context (.appweaver/context.json), so /appweaver select-feature lists exactly these features and nothing from a neighbouring context; switch with /appweaver select-bounded-context. ONBOARD RUNS ONCE PER CONTEXT: contexts already done — {{onboarded_contexts}}; still open — {{remaining_contexts}}; the order the map gives is {{contexts_ordered}}. Run /appweaver onboard <NextContext> for each remaining one, or with no argument to take the next one automatically. GOVERNANCE — {{gov_mode}}. The project tier is the PROVISIONAL governance scaffold — the split constitution, the domain rule set at guardrails/projects/{{domain_slug}}/domain/*.domain.md + domain-rule-bindings.md, each declared LANE's rule set and constitution half, the activated domain {{active_domain}}, and the code-derived design / delta-design / domain-model template overrides in .appweaver/templates/overrides/. The first context authors it; every later context AMENDS it from its own code, additively — rules, principles and map entries its code evidences, never a rewrite, renumbering or deletion of what an earlier context wrote — and a lane tier that did not exist yet is authored in full. Files this run amended — domain: {{amended_domain_files}}; service: {{amended_service_files}}; frontend: {{amended_ui_files}}. Search them for `Divergence ({{bc}})`: each marks a rule this context's code contradicts, left as written for you to decide with /appweaver constitution, which is also how you amend the tier by hand. The templates are written once per lane and never amended. To re-run this governance pass later — after declaring a lane with /appweaver select-stack, say — name an onboarded context: /appweaver onboard <Context>. ONE HALF AND ONE RULE SET PER LANE: service_lane / ui_lane report which lanes .appweaver/stacks.json declared, and the declaration is what decided. A lane declared (none) in select-stack gets none of it, which is the correct outcome and not an omission. LANE DECLARATION: read, never written — select-stack is its sole writer, and this run scanned the source paths it named (scanned_service_root / scanned_ui_root); scanned_backend_files / scanned_ui_files report each. ui_source_evidence_found false means the UI lane's declared path held nothing a scan recognises as UI, so its governance is thin — move the source path with /appweaver select-stack and re-run. The build/test/run commands on each lane are that PROFILE's defaults and may not match a legacy layout — review them. Because the domain is activated, resolve-domain + resolve-tech route the WHOLE forward pipeline to these code-derived rules — never another project's rules as a fallback. THE BOUNDARIES CAME FROM THE MAP, not from this run: /appweaver inventory proposed them and you confirmed them in specs/proposed-inventory.md. To change a boundary, edit that file and run /appweaver inventory apply — a context whose concepts already exist is not re-mapped; naming it re-runs only its governance pass. Develop an EXISTING feature just-in-time: /appweaver adopt <Feature> reverse-engineers its spec.md + backend-plan.md + source-map.md and deepens the OKF concept of the aggregate it acts on. Develop a NEW feature straight through the forward pipeline — /appweaver select-feature FIRST (specify and every stage after it read the active feature and STOP without one), then specify → plan → analyze-plan → implement → build → analyze-slice → run. Then drive every change through the CR delta loop (/appweaver specify → plan → analyze-plan-delta → implement → build → analyze-slice-delta → finalize-delta → analyze-slice → close-delta), and re-derive the master plans after it with /appweaver plan main → analyze-plan — finalize-delta merges a change into spec.md and domain-model.md, never into the plans. If a validation_ok is false, its constitution half needs a manual touch (see its Sync Impact Report)."