aw-spec-cli 0.1.26 → 0.1.27

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

@@ -28,7 +28,7 @@
 #
 # EACH LANE IS GATED ON ITS OWN, AND A LANE'S GAP IS NOT THE RUN'S. A declared lane needs
 # two things before it can generate: the plan for THIS run (its master plan, or this
-# change's delta plan) and a scaffolded project under the source path it declares. A lane
+# change's delta plan) and a scaffolded project under the lane root folder it declares. A lane
 # that is missing either is REPORTED with the fix named and SKIPPED — the other lane still
 # runs. Failing the whole command for the frontend's sake is how a backend that was ready
 # goes unbuilt; failing silently is how a frontend that was never generated reports green.
@@ -87,9 +87,10 @@
 #   • FRONTEND — `## /aw-spec-implement-ui`, both paths. There was never a delta heading
 #     for this lane because the delta half of it was never built; it is built here.
 #
-# TWO PATHS PER LANE. Each lane owns the source path stacks.json declares for it and the
-# test path lane-verify resolves beside it — `tests/` next to a .NET `src/`, the source
-# path itself for a stack that keeps its tests inside — and writes nothing outside them.
+# TWO PATHS PER LANE. Each lane owns the lane root folder stacks.json declares for it and the
+# test path lane-verify resolves for it — `backend/tests/` inside a new lane root folder,
+# `tests/` next to a classic .NET `src/`, the lane root folder itself for a stack that keeps
+# its tests inside — and writes nothing outside them.
 # The one exception is registering a test project the lane had to create, in whatever
 # file the lane's test command discovers tests through (a .NET solution file). A file
 # written elsewhere belongs to the other lane or to no lane at all, and the project gate
@@ -99,35 +100,35 @@
 #
 # A FILE LIST IS NOT A FINISHED LANE. Each generating lane is handed its plan's element
 # list and reports every element back as done or blocked; `plan-coverage` then checks the
-# code under the lane's source path for every identifier the plan introduces. Whatever
+# code under the lane root folder for every identifier the plan introduces. Whatever
 # either check leaves open gets one completion pass, and anything still open after it
 # stops the run once both lanes have generated — so a pass that stopped at five use-cases
 # of seven is reported, not shipped.
 #
 # A LANE'S GAP DISABLES THAT LANE, NOT THE RUN. Three things a lane needs are checked per
-# lane and reported per lane: its source path is on disk, its plan is there, and a project
+# lane and reported per lane: its lane root folder is on disk, its plan is there, and a project
 # is scaffolded under it. Any of them missing skips that lane with the command that fixes
 # it named, and every other declared lane still generates; only when NOTHING can run does
 # the run stop, with all the reasons printed. The whole-run stop is reserved for states
 # with no correct lane to fall back on — no lane declared at all, a lane declaring no
-# source path, and two lanes claiming overlapping subtrees.
+# lane root folder, and two lanes claiming overlapping subtrees.
 #
 # WHAT IT DOES NOT DO. It never writes spec.md, a master plan or the domain model, and it
 # never closes a change — finalize-delta merges the change's spec and model halves,
 # analyze-slice verifies the slice, and close-delta archives it and bumps the version.
 #
 # Prereqs: /appweaver plan (+ analyze-plan, or analyze-plan-delta for a change), and a
-# project scaffolded under each lane's source path — this phase GENERATES into that tree,
-# so with no project there is nowhere to place the files. /appweaver foundation unpacks one
-# where a bundle ships for the stack; a stack with no bundle scaffolds with its own tooling
-# instead, and the gate accepts either, since it tests for a project rather than a bundle.
+# project scaffolded under each lane root folder — this phase GENERATES into that tree,
+# so with no project there is nowhere to place the files. /appweaver foundation scaffolds one,
+# from a pack or from a spec; a team may also scaffold with the stack's own tooling, and the
+# gate accepts any of them, since it tests for a project rather than for how it got there.
 #
 # Launch:  /appweaver implement [guidance]
 #          /appweaver implement CR-20260910-…   (implement THAT open change, no prompt)
 # =============================================================================
 
 name: aw-spec-implement
-description: "Generate the aggregate's source files and paired tests from its lane plans — the backend lane from backend-plan.md when a backend stack is declared, the frontend lane from frontend-plan.md when a frontend stack is, both when both are. One command covers backend-only, frontend-only and full-stack projects and absorbs the former implement-ui and implement-delta. Self-detecting off the changes on disk — with none open it generates from the master plans; with one or more open it ASKS which change and generates only what that change's delta plans mark ADDED or MODIFIED, leaving the masters untouched. Every lane is gated on its own source path, its own plan and its own scaffolded project, and a lane missing any of them is reported and skipped rather than failing the other lane; each runnable lane confirms before it writes. Model-driven, and it does not read the spec — analyze-plan already conformed the plans to it. The plan says WHAT to build; the bounded context's domain-model.md, in context alongside it, says what the domain IS — the entity names, the boundary and the text of every invariant the plan cites by id — joined on the delta path by that change's own model delta, since the master is not merged until finalize-delta. The stack binds here from the lane declaration and the constitution halves; the plans stay technology-agnostic."
+description: "Generate the aggregate's source files and paired tests from its lane plans — the backend lane from backend-plan.md when a backend stack is declared, the frontend lane from frontend-plan.md when a frontend stack is, both when both are. One command covers backend-only, frontend-only and full-stack projects and absorbs the former implement-ui and implement-delta. Self-detecting off the changes on disk — with none open it generates from the master plans; with one or more open it ASKS which change and generates only what that change's delta plans mark ADDED or MODIFIED, leaving the masters untouched. Every lane is gated on its own lane root folder, its own plan and its own scaffolded project, and a lane missing any of them is reported and skipped rather than failing the other lane; each runnable lane confirms before it writes. Model-driven, and it does not read the spec — analyze-plan already conformed the plans to it. The plan says WHAT to build; the bounded context's domain-model.md, in context alongside it, says what the domain IS — the entity names, the boundary and the text of every invariant the plan cites by id — joined on the delta path by that change's own model delta, since the master is not merged until finalize-delta. The stack binds here from the lane declaration and the constitution halves; the plans stay technology-agnostic."
 version: 3.10.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
@@ -148,7 +149,7 @@ scripts:
 
 # Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). Each lane's
 # FRAMEWORK / code-generation rule files are CONFIGURATION, loaded per-lane from
-# guardrails/projects/<project>/tech-rule-bindings.md by the tech-select module (see the
+# guardrails/<project>/tech-rule-bindings.md by the tech-select module (see the
 # tech_select steps below). Per the rule-partition this phase loads NO domain rule file —
 # everything domain reached the code through spec → plan. The architecture and UX bases
 # arrive via constitution.technical.md / constitution.ui.md (referred to directly, as-is —
@@ -272,15 +273,15 @@ workflow:
   #    kind: a backend-only and a frontend-only project are both correct states, and which
   #    lanes exist is exactly what it is here to find out.
   #
-  #    --allow-missing-root, because a lane whose source path is not on disk is THAT LANE'S
+  #    --allow-missing-root, because a lane whose lane root folder is not on disk is THAT LANE'S
   #    gap, not the run's. This phase is per-lane throughout — a missing plan or a missing
   #    project is reported at step 5 and the other lane still generates — and a missing root
   #    is the same kind of gap, most often a declared frontend that `foundation` has not
-  #    unpacked yet. With the check left on it arrives here instead, as a whole-run stop
+  #    scaffolded yet. With the check left on it arrives here instead, as a whole-run stop
   #    that takes the ready lane down with it. It is re-checked per lane at step 5 from
   #    `*_root_exists`, which lane-verify reports whether or not the on-disk half is armed.
   #
-  #    What still stops the run: no lane declared at all, a lane declaring no source path,
+  #    What still stops the run: no lane declared at all, a lane declaring no lane root folder,
   #    and two lanes claiming overlapping subtrees. Those are declaration errors with no
   #    correct lane to fall back to, and none of them is a state any phase can work around.
   - id: lane_verify
@@ -539,8 +540,8 @@ workflow:
   #    detect-project searches the LANE'S OWN subtree for an ecosystem manifest (.sln/
   #    .csproj, pom.xml, build.gradle, package.json, go.mod, Cargo.toml, pyproject.toml),
   #    falls back to the whole repo, and reports which scope answered. How the project got
-  #    there is not asked — `foundation` unpacked it, or the team scaffolded it with the
-  #    stack's own tooling.
+  #    there is not asked — `foundation` unpacked or built it, or the team scaffolded it with
+  #    the stack's own tooling.
   - id: be_detect_project
     condition: "{{be_declared}} == true"
     action: execute_script
@@ -555,7 +556,7 @@ workflow:
   # in a two-lane project is the service lane's manifest, and generating this lane's code
   # against it is exactly the failure the lane model exists to prevent — a frontend that
   # was never scaffolded, generated into anyway, reporting green. The service lane accepts
-  # either scope, because the layout that keeps a manifest beside the lane root rather than
+  # either scope, because the layout that keeps a manifest beside the lane root folder rather than
   # inside it is a normal one for it.
   - id: fe_detect_project
     condition: "{{fe_declared}} == true"
@@ -586,13 +587,13 @@ workflow:
     action: verify_context
     require_true: be_root_exists
     on_false: continue
-    on_false_message: "BACKEND LANE SKIPPED — lane `{{be_lane_id}}` ({{be_title}}) declares source path `{{be_source_path}}` in .appweaver/stacks.json, and that path is not a directory in this repository. A lane owns its subtree and this phase writes into it, so there is nothing to generate into: unpack a project there with /appweaver foundation <FoundationName> <AppName> where a bundle ships for {{be_profile}}, create one with the stack's own tooling, or re-run /appweaver select-stack and point the lane at the directory that really holds its source. Nothing is generated for this lane; any other declared lane still runs."
+    on_false_message: "BACKEND LANE SKIPPED — lane `{{be_lane_id}}` ({{be_title}}) declares lane root folder `{{be_source_path}}` in .appweaver/stacks.json, and that path is not a directory in this repository. A lane owns its subtree and this phase writes into it, so there is nothing to generate into: scaffold a project there with /appweaver foundation (a pack or a spec for {{be_profile}}, or a spec you give it), create one with the stack's own tooling, or re-run /appweaver select-stack and point the lane at the directory that really holds its source. Nothing is generated for this lane; any other declared lane still runs."
   - id: warn_be_project
     condition: "{{be_declared}} == true"
     action: verify_context
     require_true: be_project_ok
     on_false: continue
-    on_false_message: "BACKEND LANE SKIPPED — no project found under the {{be_lane_id}} lane's source path `{{be_source_path}}`, nor anywhere else in this repository. This phase GENERATES into an existing project tree, so one has to be scaffolded first: run /appweaver foundation <FoundationName> <AppName> where a foundation bundle ships for {{be_profile}}, or create the project with the stack's own tooling under that path. Any ecosystem manifest marks it — .sln/.csproj, pom.xml, build.gradle(.kts), package.json, go.mod, Cargo.toml or pyproject.toml."
+    on_false_message: "BACKEND LANE SKIPPED — no project found under the {{be_lane_id}} lane root folder `{{be_source_path}}`, nor anywhere else in this repository. This phase GENERATES into an existing project tree, so one has to be scaffolded first: run /appweaver foundation, which scaffolds it from a pack or from a spec (one it ships for {{be_profile}}, or one you give it), or create the project with the stack's own tooling under that path. Any ecosystem manifest marks it — .sln/.csproj, pom.xml, build.gradle(.kts), package.json, go.mod, Cargo.toml or pyproject.toml."
   - id: warn_fe_plan
     condition: "{{fe_declared}} == true"
     action: verify_context
@@ -604,15 +605,15 @@ workflow:
     action: verify_context
     require_true: fe_root_exists
     on_false: continue
-    on_false_message: "FRONTEND LANE SKIPPED — lane `{{fe_lane_id}}` ({{fe_title}}) declares source path `{{fe_source_path}}` in .appweaver/stacks.json, and that path is not a directory in this repository. A lane owns its subtree and this phase writes into it, so there is nothing to generate into: unpack a project there with /appweaver foundation <FoundationName> <AppName> where a bundle ships for {{fe_profile}}, create one with the stack's own tooling, or re-run /appweaver select-stack and point the lane at the directory that really holds its source. Nothing is generated for this lane; any other declared lane still runs."
+    on_false_message: "FRONTEND LANE SKIPPED — lane `{{fe_lane_id}}` ({{fe_title}}) declares lane root folder `{{fe_source_path}}` in .appweaver/stacks.json, and that path is not a directory in this repository. A lane owns its subtree and this phase writes into it, so there is nothing to generate into: scaffold a project there with /appweaver foundation (a pack or a spec for {{fe_profile}}, or a spec you give it), create one with the stack's own tooling, or re-run /appweaver select-stack and point the lane at the directory that really holds its source. Nothing is generated for this lane; any other declared lane still runs."
   - id: warn_fe_project
     condition: "{{fe_declared}} == true"
     action: verify_context
     require_true: fe_project_ok
     on_false: continue
-    on_false_message: "FRONTEND LANE SKIPPED — no frontend project found under the {{fe_lane_id}} lane's source path `{{fe_source_path}}`. detect-project searched that subtree and then the whole repository, and answered at scope `{{fe_project_scope}}`; `lane` is the only scope this lane accepts. Scaffold a project there — /appweaver foundation <FoundationName> <AppName> where a bundle ships for {{fe_profile}}, or the stack's own tooling — and re-run implement. A manifest found elsewhere in the repository does NOT count: that one belongs to another lane, and generating this lane's code against it is how a frontend that was never built reports green."
+    on_false_message: "FRONTEND LANE SKIPPED — no frontend project found under the {{fe_lane_id}} lane root folder `{{fe_source_path}}`. detect-project searched that subtree and then the whole repository, and answered at scope `{{fe_project_scope}}`; `lane` is the only scope this lane accepts. Scaffold a project there — /appweaver foundation, from a pack or a spec for {{fe_profile}} or a spec you give it, or the stack's own tooling — and re-run implement. A manifest found elsewhere in the repository does NOT count: that one belongs to another lane, and generating this lane's code against it is how a frontend that was never built reports green."
 
-  # 6. RUNNABLE = declared AND its source path is on disk AND its plan is there AND its
+  # 6. RUNNABLE = declared AND its lane root folder is on disk AND its plan is there AND its
   #    project is there, as one ordered assignment plus a knockdown per condition, since
   #    the engine has no compound conditions. An undeclared lane stays false either way —
   #    its `declared` value is what the raise assigns.
@@ -676,7 +677,7 @@ workflow:
     action: verify_context
     require_true: generate_any
     on_false: stop
-    on_false_message: "Nothing to implement — no declared lane is both ready and confirmed. Either every declared lane was skipped for a reason printed above (its source path, its plan or its project is missing), or each one that was ready was declined at the prompt. Backend lane declared {{be_declared}}, ready {{be_runnable}}; frontend lane declared {{fe_declared}}, ready {{fe_runnable}}. Fix the reasons named above, or re-run and confirm a lane."
+    on_false_message: "Nothing to implement — no declared lane is both ready and confirmed. Either every declared lane was skipped for a reason printed above (its lane root folder, its plan or its project is missing), or each one that was ready was declined at the prompt. Backend lane declared {{be_declared}}, ready {{be_runnable}}; frontend lane declared {{fe_declared}}, ready {{fe_runnable}}. Fix the reasons named above, or re-run and confirm a lane."
 
   # 8. EACH GENERATING LANE'S authoring MODE — the run's mode where the lane is going, and
   #    `skip` where it is not, which silences both of that lane's branches without a
@@ -1165,7 +1166,7 @@ workflow:
   # recorded). Without the union a backend run would erase the frontend lane's source_files
   # and vice-versa, and either lane may have run first. ⌛ The trade-off is that a file this
   # lane DELETED stays listed until something prunes it; a lane-scoped replace needs
-  # concept-upsert to learn about lane roots, which is a script change and not built.
+  # concept-upsert to learn about lane root folders, which is a script change and not built.
   - id: xref_concept_backend
     condition: "{{be_go}} == true"
     action: execute_script
@@ -1554,7 +1555,7 @@ workflow:
     action: verify_context
     require_true: lanes_complete
     on_false: stop
-    on_false_message: "PARTIAL GENERATION — implement did not realise every plan element, even after one completion pass. Backend lane: {{be_gaps_text}}. Frontend lane: {{fe_gaps_text}}. Everything written so far is kept and recorded in the OKF concept. An element reported `blocked` names what stops it — a plan that is wrong is fixed with /appweaver plan (then analyze-plan or analyze-plan-delta). An element with no code under the lane's source path is still to be written, or was written under a name that is not the plan's: re-run /appweaver implement to finish, which extends existing files rather than regenerating them."
+    on_false_message: "PARTIAL GENERATION — implement did not realise every plan element, even after one completion pass. Backend lane: {{be_gaps_text}}. Frontend lane: {{fe_gaps_text}}. Everything written so far is kept and recorded in the OKF concept. An element reported `blocked` names what stops it — a plan that is wrong is fixed with /appweaver plan (then analyze-plan or analyze-plan-delta). An element with no code under the lane root folder is still to be written, or was written under a name that is not the plan's: re-run /appweaver implement to finish, which extends existing files rather than regenerating them."
 
   # 11. CROSS-SLICE EDGES — a Cross-References row written into every SIBLING aggregate
   #     this one uses, read off the master backend plan (§1 References-by-id + its External
@@ -1691,5 +1692,5 @@ outputs:
   plan_gate_at: "{{gate_at}}"
   plan_gate_verdict: "{{gate_verdict}}"
   plan_gate_routed_to_specify: "{{gate_routed_csv}}"   # open spec/model gaps this code does not cover
-  note: "Lanes come from .appweaver/stacks.json — backend declared {{be_declared}} (ready {{be_runnable}}, implemented {{be_go}}), frontend declared {{fe_declared}} (ready {{fe_runnable}}, implemented {{fe_go}}). A declared lane that was skipped printed its reason above and did not stop the other one; an undeclared lane produces nothing and that is not a failure. Each generating lane read its PLAN for what to build and {{domain_model}} for what the domain is — plus {{delta_model}} on the delta path, since the master model does not carry the change until finalize-delta merges it. Every one of those documents was READ and none was written: this phase generates code and nothing else. Each lane's outcome is backend={{be_outcome}}, frontend={{fe_outcome}} — `already-implemented` means the lane wrote no files because every plan element was already realised in its source path, which is the correct result of re-running implement on a finished feature and not a failure. On the bootstrap path the plans were checked against analyze-plan's receipt before anything generated (tracked={{gate_tracked}}, fresh={{gate_fresh}}, gated {{gate_at}}) — tracked=false means this feature has never passed analyze-plan since the gate began recording what it proved, which is an unknown rather than a stale plan and blocks nothing; run /appweaver analyze-plan once to start the record."
+  note: "Lanes come from .appweaver/stacks.json — backend declared {{be_declared}} (ready {{be_runnable}}, implemented {{be_go}}), frontend declared {{fe_declared}} (ready {{fe_runnable}}, implemented {{fe_go}}). A declared lane that was skipped printed its reason above and did not stop the other one; an undeclared lane produces nothing and that is not a failure. Each generating lane read its PLAN for what to build and {{domain_model}} for what the domain is — plus {{delta_model}} on the delta path, since the master model does not carry the change until finalize-delta merges it. Every one of those documents was READ and none was written: this phase generates code and nothing else. Each lane's outcome is backend={{be_outcome}}, frontend={{fe_outcome}} — `already-implemented` means the lane wrote no files because every plan element was already realised in its lane root folder, which is the correct result of re-running implement on a finished feature and not a failure. On the bootstrap path the plans were checked against analyze-plan's receipt before anything generated (tracked={{gate_tracked}}, fresh={{gate_fresh}}, gated {{gate_at}}) — tracked=false means this feature has never passed analyze-plan since the gate began recording what it proved, which is an unknown rather than a stale plan and blocks nothing; run /appweaver analyze-plan once to start the record."
   next: "This run was mode `{{mode}}`, change `{{active_change}}` (empty on the bootstrap path). BOOTSTRAP → /appweaver build → analyze-slice → run. DELTA → /appweaver build → analyze-slice-delta {{active_change}} → finalize-delta → analyze-slice → close-delta, with the change still OPEN throughout — compile first, then analyze-slice-delta verifies that every element the delta plans marked ADDED or MODIFIED is actually in the code with a paired test (the gate that catches a lane you declined at the prompt above), then finalize-delta merges it into spec.md + the context's domain-model.md while leaving it open, analyze-slice verifies the slice against those merged masters while a red result is still recoverable, and close-delta LAST archives the change and bumps the version."

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

@@ -22,7 +22,7 @@
 #      for either reads as "the document exists" to every gate downstream.
 #
 #   3. GOVERNANCE SCAFFOLD — the PROJECT-level governing tier: the split constitution
-#      (technical + domain), the guardrails/projects/brf-<domain>/domain/ rule-file set
+#      (technical + domain), the guardrails/brf-<domain>/domain/ rule-file set
 #      (+ domain-rule-bindings), the domain charter that set is headed by, and the
 #      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
@@ -71,8 +71,8 @@
 #
 # CODE-DERIVED RULE SETS + MAPS (both tiers): onboard authors, from the code ALONE
 # (never a greenfield rule file), BOTH the DOMAIN rule-file set
-# (guardrails/projects/brf-<domain>/domain/*.domain.md +
-# domain-rule-bindings.md) AND the TECHNICAL rule-file set (guardrails/projects/brf-<domain>/service/*.md
+# (guardrails/brf-<domain>/domain/*.domain.md +
+# domain-rule-bindings.md) AND the TECHNICAL rule-file set (guardrails/brf-<domain>/service/*.md
 # + tech-rule-bindings.md), then WIRES each per-workflow. This is what makes the WHOLE
 # forward pipeline AND adopt govern against THIS codebase's rules — resolve-domain /
 # resolve-tech read the activated brf-<domain>'s maps, so no workflow ever falls back to a
@@ -92,7 +92,7 @@
 #   .appweaver/memory/constitution.ui.md          — the lane's UX-* base, authored from the UI
 #       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
+#   guardrails/brf-<domain>/frontend/*.md — the code-derived lane rule set, the detail
 #       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`
@@ -112,7 +112,7 @@
 # generated, which subtrees are scanned, and what technology the derived rules name.
 # select-stack detects all three from the repo's own files and proposes them, so answering
 # it on an existing codebase is mostly confirmation — but it is a person's confirmation,
-# which is exactly what detection on a legacy repo needs. A declared source path that is
+# which is exactly what detection on a legacy repo needs. A declared lane root folder that is
 # not a directory stops this run with the fix named rather than producing a scaffold
 # reverse-engineered from nothing.
 #
@@ -122,7 +122,7 @@
 # for the service lane gets no technical half and no service rules. The deterministic
 # scan is still what reads the code, now pointed AT the declared subtree: it decides what
 # the governance SAYS, and the declaration decides what there is to govern. A declared
-# lane whose source path holds nothing recognisable is reported, because the governance
+# lane whose lane root folder holds nothing recognisable is reported, because the governance
 # derived from it will be thin.
 #
 # ONE ORACLE, UNCHANGED. Nothing about where the CONTENT comes from has moved. Every
@@ -138,7 +138,7 @@
 # — select-stack — and this workflow only reads.
 #
 # Never modifies source — every write lands in the OKF bundle, the context's specs/
-# directories, guardrails/projects/ (domain/ + service/ + frontend/ rule sets + both
+# directories, guardrails/brf-<domain>/ (domain/ + service/ + frontend/ rule sets + both
 # maps), or the .appweaver/templates/overrides/ design templates.
 #
 # Launch:  /appweaver onboard [<BoundedContext>] [; concerns: a, b, c]
@@ -149,7 +149,7 @@
 # =============================================================================
 
 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. 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.
+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/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
@@ -242,7 +242,7 @@ workflow:
   #    right technology).
   #
   #    The on-disk check is ON here, unlike in constitution: this run is about to READ
-  #    those directories. A declared path that is not there stops the run with the fix
+  #    those directories. A declared lane root folder that is not there stops the run with the fix
   #    named, rather than producing a governance scaffold reverse-engineered from
   #    nothing.
   - id: lane_model
@@ -272,7 +272,7 @@ workflow:
       onboard reverse-engineers this repository's governance out of its source, so it
       has to be told which subtrees hold which lane before it starts scanning. Run
       /appweaver select-stack first — it detects what this repo already is, proposes
-      the stack and the source path for each lane, and lets you correct both.
+      the stack and the lane root folder for each lane, and lets you correct both.
 
   - id: lane_kinds_gate
     action: verify_context
@@ -507,7 +507,7 @@ workflow:
   # component library, a front end whose API lives in another repository. The
   # technical half, the service rule set and the service design templates are all the
   # SERVICE lane's, so none of them is authored, and saying so is better than leaving
-  # someone to notice that guardrails/projects/<p>/service/ is empty.
+  # someone to notice that guardrails/<p>/service/ is empty.
   - id: svc_lane_warning
     action: verify_context
     require_true: svc_lane
@@ -532,13 +532,13 @@ workflow:
     condition: "{{fe_declared}}"
     vars:
       ui_lane: "true"
-      ui_evidence: "lane '{{fe_lane_id}}' ({{fe_profile}}) is declared at the source path {{fe_root}}; the scan found UI source there — {{frontend_roots}}"
-      ui_declaration_note: "lane '{{fe_lane_id}}' ({{fe_profile}}) at {{fe_root}} — the declared source path this run reverse-engineered the UI governance out of"
+      ui_evidence: "lane '{{fe_lane_id}}' ({{fe_profile}}) is declared at the lane root folder {{fe_root}}; the scan found UI source there — {{frontend_roots}}"
+      ui_declaration_note: "lane '{{fe_lane_id}}' ({{fe_profile}}) at {{fe_root}} — the declared lane root folder this run reverse-engineered the UI governance out of"
 
-  # A declared UI lane whose source path holds nothing a scan recognises as UI. The
+  # A declared UI lane whose lane root folder holds nothing a scan recognises as UI. The
   # path exists — lane-verify already refused the run otherwise — so this is not a
   # broken declaration, it is an empty one: a lane scaffolded but not yet built, or a
-  # source path one directory too high. Announce and continue rather than stop: the
+  # lane root folder one directory too high. Announce and continue rather than stop: the
   # declaration is a person's statement and is left exactly as it stands, but the UI
   # governance below will be thin, and it is better to say why now than to let someone
   # discover a UX base derived from an empty directory.
@@ -551,7 +551,7 @@ workflow:
       Frontend lane '{{fe_lane_id}}' is declared at {{fe_root}}, but the scan found no
       component, view or build-config files under that path ({{frontend_file_count}}
       file(s) there in total). The UI governance authored below is reverse-engineered
-      from that subtree, so it will be thin or empty. Check that the source path points
+      from that subtree, so it will be thin or empty. Check that the lane root folder points
       at the directory holding the UI — /appweaver select-stack can move it — or
       retire the lane there with (none) if this repo has no UI yet.
 
@@ -673,7 +673,7 @@ workflow:
         repo must not get one). It is the UI counterpart of the platform note and the
         evidence the frontend lane's constitution is scaffolded from. Read the candidate
         roots in `frontend_signals` and then READ REPRESENTATIVE UI SOURCE from their
-        component/route/store file lists, and record AS-BUILT: the lane root(s) and whether
+        component/route/store file lists, and record AS-BUILT: the lane root folder(s) and whether
         the UI is separable or rendered inside the service tree; what it is built with (name
         it from the code — the `framework_markers` are markers, not conclusions); how
         components are organized and named; routing/navigation; where client state and
@@ -877,7 +877,7 @@ workflow:
       - { name: project_name,    from: "$.project_name" }
       - { name: overview,        from: "$.overview" }
 
-  # Slugify + `brf-` prefix the domain name and create guardrails/projects/brf-<domain>/.
+  # Slugify + `brf-` prefix the domain name and create guardrails/brf-<domain>/.
   # 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
@@ -974,8 +974,8 @@ workflow:
     permission_mode: acceptEdits
     task: |
       Scaffold the PROJECT-level DOMAIN RULE SET for **{{project_name}}** (domain
-      {{domain_slug}}) into guardrails/projects/{{domain_slug}}/domain/ (the dir exists),
-      plus the domain map guardrails/projects/{{domain_slug}}/domain-rule-bindings.md at the
+      {{domain_slug}}) into guardrails/{{domain_slug}}/domain/ (the dir exists),
+      plus the domain map guardrails/{{domain_slug}}/domain-rule-bindings.md at the
       project root. A project keeps its three rule classes in domain/ · service/ · frontend/
       and both maps at its root; adopt reconciles this set in place, so a file written
       anywhere else is unreachable.
@@ -1039,8 +1039,8 @@ workflow:
         - `## /aw-spec-plan`       — `_None — plan loads no domain file. Domain reaches plan through the spec and the context's domain-model.md._`
         - `## /aw-spec-implement`    — `_None — implement loads no domain file. Domain reaches implement through the lane plans and the context's domain-model.md._`
         - `## /aw-spec-gate`         — the conformance-checklist set (the *.domain.md files).
-      Each bullet is a workspace-relative path `- guardrails/projects/{{domain_slug}}/domain/<file>`.
-      Write ONLY inside guardrails/projects/{{domain_slug}}/ (domain/ + the map). Report the
+      Each bullet is a workspace-relative path `- guardrails/{{domain_slug}}/domain/<file>`.
+      Write ONLY inside guardrails/{{domain_slug}}/ (domain/ + the map). Report the
       files written.
     outputs:
       - { name: pack_files, from: "$.files" }
@@ -1050,7 +1050,7 @@ workflow:
     action: verify_context
     require_non_empty: pack_files
     on_empty: stop
-    on_empty_message: "No domain rule files were written to guardrails/projects/{{domain_slug}}/domain/. Ensure the feature map carries a modellable domain (a feature map + ubiquitous language) and re-run."
+    on_empty_message: "No domain rule files were written to guardrails/{{domain_slug}}/domain/. Ensure the feature map carries a modellable domain (a feature map + ubiquitous language) and re-run."
   - id: require_domain_rule_bindings
     condition: "{{author_repo}} == true"
     action: verify_context
@@ -1426,7 +1426,7 @@ workflow:
 
       EVIDENCE = THE UI CODE ITSELF (deep read). Authority, in order:
         1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_ui_json}} (in context):
-           `frontend_signals` lists the candidate lane roots with their kind
+           `frontend_signals` lists the candidate lane root folders with 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 principle from what the UI ACTUALLY does. Do NOT assert an
@@ -1764,14 +1764,14 @@ workflow:
   # under a constitution.technical.md principle (thin ratified line ↑ / enforceable rule ↓).
   # Evidence = the CODE (deep read via inventory_json's file lists) + the validated technical
   # constitution + the shallow platform note (corroboration only). Writes:
-  #   1. guardrails/projects/<domain>/service/<concern>.md — evidenced-only code-derived tech rule
+  #   1. guardrails/<domain>/service/<concern>.md — evidenced-only code-derived tech rule
   #      files (the ANALOG of a greenfield project's architecture · security · governance set, but reverse-
   #      engineered from THIS code, never a greenfield file), INCLUDING the one file that
   #      feeds /specify: service/domain-modelling.md, the as-built modelling METHODOLOGY (the
   #      analog of the greenfield corpus's technology/<stack>/domain-driven-design.md). Without it brownfield
   #      specify has a model but no HOW-to-model standard, and models a NEW feature in a
   #      different idiom than the code it joins, and
-  #   2. guardrails/projects/<domain>/tech-rule-bindings.md — the TECHNICAL map (resolve-tech +
+  #   2. guardrails/<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 files live
@@ -1796,8 +1796,8 @@ workflow:
     task: |
       Scaffold the PROJECT-level TECHNICAL RULE SET for **{{project_name}}** (domain
       {{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
+      into guardrails/{{domain_slug}}/service/ (create it), plus the technical map
+      guardrails/{{domain_slug}}/tech-rule-bindings.md. This is the TECHNICAL twin of the
       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.
@@ -1815,9 +1815,9 @@ workflow:
            numeral on the rules it details. Never contradict it; never restate it wholesale.
         3. The OKF platform.md (in context, if present) — SECONDARY, shallow corroboration only.
       NEVER reference, read, copy, or list a rule file belonging to another project
-      (guardrails/projects/<other>/**) — those are the
+      (any other project folder under guardrails/, e.g. guardrails/project-specific/**) — those are the
       greenfield fixture, NOT this project's rules. Every path you write lives under
-      guardrails/projects/{{domain_slug}}/service/.
+      guardrails/{{domain_slug}}/service/.
 
       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
@@ -1868,8 +1868,8 @@ workflow:
         - `## /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
-      workspace-relative path `- guardrails/projects/{{domain_slug}}/service/<file>`. Close with the
-      quick-reference table. Write ONLY inside guardrails/projects/{{domain_slug}}/ (service/ + the map);
+      workspace-relative path `- guardrails/{{domain_slug}}/service/<file>`. Close with the
+      quick-reference table. Write ONLY inside guardrails/{{domain_slug}}/ (service/ + the map);
       modify no source. Report the files written + the concerns you found present (with the code
       paths that evidence them).
     outputs:
@@ -1880,7 +1880,7 @@ workflow:
     condition: "{{author_svc}} == true"
     require_non_empty: tech_pack_files
     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."
+    on_empty_message: "No technical rule files were written to guardrails/{{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_svc}} == true"
     action: verify_context
@@ -1908,7 +1908,7 @@ workflow:
     require_non_empty: specify_rules
     on_empty: continue
     on_empty_message: >
-      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      guardrails/{{domain_slug}}/tech-rule-bindings.md maps nothing under
       `## /aw-spec-specify`, so brownfield specify will model new features with no
       as-built modelling methodology to follow. That is correct only where the code has no
       discernible domain model (a pure script/ETL repo). Otherwise add
@@ -1947,15 +1947,15 @@ workflow:
     task: |
       Scaffold the PROJECT-level FRONTEND RULE-FILE PACK for **{{project_name}}** (domain
       {{domain_slug}}) — the CODE-DERIVED lane rules — into
-      guardrails/projects/{{domain_slug}}/frontend/ (create it), and WIRE it into the existing
-      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md. This is the FRONTEND LANE's
+      guardrails/{{domain_slug}}/frontend/ (create it), and WIRE it into the existing
+      guardrails/{{domain_slug}}/tech-rule-bindings.md. This is the FRONTEND LANE's
       twin of the service/ set you have already generated: it is the detail layer under
-      constitution.ui.md's UX-* principles, and it governs only code under the lane's root.
+      constitution.ui.md's UX-* principles, and it governs only code under the lane root folder.
 
       EVIDENCE = THE UI CODE ITSELF (deep read) + THE VALIDATED UI CONSTITUTION. Authority,
       in order:
         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
+           `frontend_signals` gives the lane root folders, 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
            have not seen in the code.
@@ -1964,10 +1964,10 @@ workflow:
            it details. Never contradict it; never restate it wholesale.
         3. The OKF architecture/frontend.md (in context, if present) — SECONDARY, shallow.
       NEVER reference, read, copy, or list a rule file belonging to another project
-      (guardrails/projects/<other>/**) — those are the greenfield fixture, NOT this project's
+      (any other project folder under guardrails/, e.g. guardrails/project-specific/**) — those are the greenfield fixture, NOT this project's
       rules. Never carry over a convention, an accessibility target, a folder taxonomy or a
       quality gate from a greenfield UI rule file or from how frontends are usually built.
-      Every path you write lives under guardrails/projects/{{domain_slug}}/frontend/.
+      Every path you write lives under guardrails/{{domain_slug}}/frontend/.
 
       EVIDENCED-ONLY (lean). Follow the SHAPE of frontend-rule-file.skeleton.md (in context):
       frontmatter (origin: reverse-engineered, generated_by: {{generated_by}}, concern),
@@ -1986,13 +1986,13 @@ 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 — guardrails/projects/{{domain_slug}}/tech-rule-bindings.md. Where the
+      WIRE THE MAP — guardrails/{{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:
+      `- guardrails/{{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
@@ -2010,7 +2010,7 @@ workflow:
       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
+      Write ONLY inside guardrails/{{domain_slug}}/ (frontend/ + the map edit); modify
       no source. Report the files written, the concerns you found present with the code paths
       that evidence them, and the concerns you deliberately omitted.
     outputs:
@@ -2022,7 +2022,7 @@ workflow:
     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."
+    on_empty_message: "A frontend lane was detected ({{ui_evidence}}) but no lane rule files were written to guardrails/{{domain_slug}}/frontend/. Check that the scan substrate's frontend_signals carry readable UI source, then re-run."
 
   # Did the lane's heading land in the map? The files above are only half the wiring:
   # `## /aw-spec-ui-constitution` is what a later /appweaver constitution re-ratifies
@@ -2044,8 +2044,8 @@ workflow:
     require_non_empty: ui_map_rules
     on_empty: continue
     on_empty_message: >
-      The lane rule files were written to guardrails/projects/{{domain_slug}}/frontend/,
-      but guardrails/projects/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      The lane rule files were written to guardrails/{{domain_slug}}/frontend/,
+      but guardrails/{{domain_slug}}/tech-rule-bindings.md maps nothing under
       `## /aw-spec-ui-constitution`. Without that heading a later /appweaver
       constitution finds no lane rules to re-ratify the UI half from, and reads this
       project as backend-only. Add the heading after the last technical one, bulleting
@@ -2069,7 +2069,7 @@ workflow:
     require_non_empty: ui_plan_rules
     on_empty: continue
     on_empty_message: >
-      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      guardrails/{{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.
@@ -2088,7 +2088,7 @@ workflow:
     require_non_empty: ui_impl_rules
     on_empty: continue
     on_empty_message: >
-      guardrails/projects/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      guardrails/{{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.
@@ -2161,7 +2161,7 @@ workflow:
   #
   # 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
+  # the lane root folders from the structure it derives. One lane's template never describes the
   # 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.
@@ -2215,7 +2215,7 @@ workflow:
       into §1.1 or §2 from memory. DESIGN-FORMAT.md (in context, § Brownfield variant) states
       which anchors are pinned and why.
 
-      SERVICE LANE ONLY. Frontend lane roots this repo has: {{frontend_roots}} (empty = none).
+      SERVICE LANE ONLY. Frontend lane root folders this repo has: {{frontend_roots}} (empty = none).
       Where that is non-empty, EXCLUDE those roots when deriving the structure — the lane has
       its own design template pair, generated next, and one lane's template must never describe
       the other's code. A UI tier that is NOT a separable lane (rendered inside the service
@@ -2458,7 +2458,7 @@ workflow:
 
       GROUND EVERYTHING IN THE LANE'S OWN CODE. Evidence authority, in order:
         1. THE ACTUAL UI SOURCE (ground truth). Use {{inventory_ui_json}} (in context):
-           `frontend_signals` gives the lane roots, their kind (spa / server-rendered /
+           `frontend_signals` gives the lane root folders, 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
            the UI ACTUALLY does. Do NOT assert a convention you have not seen.
@@ -2467,7 +2467,7 @@ workflow:
            serves; cite them by their real numerals.
         3. The generated frontend/ui-constitution.md and the OKF architecture/frontend.md
            (in context, if present) — the lane's own rule detail and a shallow corroboration.
-      STAY INSIDE THE LANE. Derive structure ONLY from code under the lane's roots. The
+      STAY INSIDE THE LANE. Derive structure ONLY from code under the lane root folders. The
       service lane has its own template, generated just above; this one never describes
       server-side structure.
 
@@ -2655,4 +2655,4 @@ outputs:
   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)."
+  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/{{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 lane root folders it named (scanned_service_root / scanned_ui_root); scanned_backend_files / scanned_ui_files report each. ui_source_evidence_found false means the declared lane root folder of the UI lane held nothing a scan recognises as UI, so its governance is thin — move the lane root folder 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)."