aw-spec-cli 0.1.26 → 0.1.28

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,11 +92,11 @@
 #   .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`
-#       (what the frontend lane of `plan` and of `implement` load).
+#       re-ratifies the UI half from), `## /aw-spec-plan-frontend` and
+#       `## /aw-spec-implement-frontend` (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
@@ -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-frontend` and `## /aw-spec-implement-frontend`; 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.
@@ -1036,11 +1036,13 @@ workflow:
           charter; a later step in this same run authors it, so wire the bullet now), then the
           domain identity/regulatory/interop files → domain principles.
         - `## /aw-spec-specify`      — the FULL domain set (specify models the domain, lifts CN-/DC-/IC-).
-        - `## /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-plan-backend`       — `_None — the service lane of plan loads no domain file. Domain reaches it through the spec and the context's domain-model.md._`
+        - `## /aw-spec-plan-frontend`      — `_None — the frontend lane of plan loads no domain file. Domain reaches it through the spec and the context's domain-model.md._`
+        - `## /aw-spec-implement-backend`  — `_None — the service lane of implement loads no domain file. Domain reaches it through backend-plan.md and the context's domain-model.md._`
+        - `## /aw-spec-implement-frontend` — `_None — the frontend lane of implement loads no domain file. Domain reaches it through frontend-plan.md 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 +1052,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
@@ -1367,7 +1369,7 @@ workflow:
         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
+        `## /aw-spec-plan-frontend` and/or `## /aw-spec-implement-frontend` 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.
@@ -1426,7 +1428,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
@@ -1580,8 +1582,8 @@ workflow:
         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.
+        existing files are wired. The plan and implement headings (`-backend` and
+        `-frontend`) 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 —
@@ -1764,14 +1766,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 +1798,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 +1817,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
@@ -1859,17 +1861,16 @@ 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 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-plan-backend`     — the as-built architecture / cross-cutting rules the SERVICE lane's plan author mediates the spec against.
+        - `## /aw-spec-implement-backend` — the code-generation / convention set the SERVICE lane's generator builds against (from backend-plan.md), on both the master and the delta path.
         - `## /aw-spec-build`            — the layering + convention rules the compile-fixer respects.
         - `## /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-adopt-backend`    — the technical reference set the reversed backend plan mediates against (a subset of `## /aw-spec-plan-backend`'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
-      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 +1881,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 +1909,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
@@ -1925,7 +1926,7 @@ workflow:
   # (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
+  # `## /aw-spec-plan-frontend` and `## /aw-spec-implement-frontend` 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
@@ -1947,15 +1948,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 +1965,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,21 +1987,21 @@ 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
            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
+        2. `## /aw-spec-plan-frontend` — 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
+        3. `## /aw-spec-implement-frontend` — 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
@@ -2010,7 +2011,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 +2023,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 +2045,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
@@ -2060,7 +2061,7 @@ workflow:
     on_error: continue
     script: { ref: actions }
     subcommand: resolve-tech
-    args: ["--command", "aw-spec-plan-ui"]
+    args: ["--command", "aw-spec-plan-frontend"]
     outputs:
       - { name: ui_plan_rules, from: "$.candidates" }
   - id: warn_ui_plan_wiring
@@ -2069,8 +2070,8 @@ workflow:
     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
+      guardrails/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      `## /aw-spec-plan-frontend`, 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
@@ -2079,7 +2080,7 @@ workflow:
     on_error: continue
     script: { ref: actions }
     subcommand: resolve-tech
-    args: ["--command", "aw-spec-implement-ui"]
+    args: ["--command", "aw-spec-implement-frontend"]
     outputs:
       - { name: ui_impl_rules, from: "$.candidates" }
   - id: warn_ui_impl_wiring
@@ -2088,8 +2089,8 @@ workflow:
     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
+      guardrails/{{domain_slug}}/tech-rule-bindings.md maps nothing under
+      `## /aw-spec-implement-frontend`, 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 +2162,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 +2216,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 +2459,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 +2468,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 +2656,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)."

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

@@ -53,7 +53,7 @@ scripts:
 
 # Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). The code-generation
 # set (triage may fix the CANDIDATE code to match legacy) is no longer hardcoded here — it is
-# now CONFIGURATION, loaded per-command from guardrails/projects/<project>/tech-rule-bindings.md
+# now CONFIGURATION, loaded per-command from guardrails/<project>/tech-rule-bindings.md
 # under "## /aw-spec-parity" by the tech-select module (see the tech_select step below). No
 # domain files: the target behaviour is defined by the running legacy system, not domain rules —
 # the tech map lists only technical files. (parity does not reference constitution.technical.md.)
@@ -68,7 +68,7 @@ vars:
 workflow:
 
   # 0. TECHNICAL rule files → sticky standards (configuration, not hardcoded). tech-select
-  #    reads guardrails/projects/<project>/tech-rule-bindings.md under "## /aw-spec-parity" and
+  #    reads guardrails/<project>/tech-rule-bindings.md under "## /aw-spec-parity" and
   #    loads that code-generation set into the sticky standards the agent_generate triage step
   #    ALWAYS prepends. No domain rule file is loaded here — the tech map lists only technical
   #    files. No blocking gate: an unconfigured project soft-continues (the target behaviour is