aw-spec-cli 0.1.26 → 0.1.28

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

@@ -17,11 +17,14 @@
 # against no declared stack invents its own.
 #
 # ONE COMMAND, TWO LANES, TWO RULE SETS. The lanes take their rules from different
-# headings of tech-rule-bindings (`## /aw-spec-plan` for the service, `## /aw-spec-plan-ui`
-# for the frontend), and the frontend set is loaded ONLY when that lane is declared — so
-# a backend-only project sees exactly the rules it did before. In a two-lane project both
-# sets are sticky for the whole run; the lane boundary is held by the prompts instead,
-# and §5 Contract Binding is where it is stated.
+# headings of tech-rule-bindings (`## /aw-spec-plan-backend` for the service,
+# `## /aw-spec-plan-frontend` for the frontend), and each set is loaded only when its lane
+# is declared. The two are never loaded together: the service set loads at step 1, before
+# the backend sections, and the frontend set REPLACES it at the lane swap before the
+# frontend sections — tech_select_ui_master on the master path, the delta-plan module's
+# own swap on the change path. Each plan is therefore authored with only its own lane's
+# rule set in its envelope. Where the two plans meet is stated in the frontend plan's
+# §5 Contract Binding, which binds to the service's published surface only.
 #
 # RENAMED FROM `design`. design.md → backend-plan.md, design.ui.md → frontend-plan.md,
 # and the former separate `design-ui` command is FOLDED IN here. The scaffold MIGRATES a
@@ -105,7 +108,7 @@ scripts:
 
 # Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). The TECHNICAL/
 # architecture rule files are CONFIGURATION, loaded per-command from
-# guardrails/projects/<project>/tech-rule-bindings.md by the tech-select module (see the
+# guardrails/<project>/tech-rule-bindings.md by the tech-select module (see the
 # tech_select steps below), exactly as the DOMAIN rule files are loaded by domain-select.
 # Per the rule-partition this phase loads NO domain rule file — the domain reaches the
 # plan as spec ids (BR-/CN-/DC-/IC-) and as the context's domain model. The technology
@@ -179,7 +182,7 @@ vars:
 workflow:
 
   # 0. WHICH LANES EXIST. lane-resolve reads the declaration only — it does NOT check the
-  #    source path on disk, unlike the lane-gate module, because a plan is authored BEFORE
+  #    lane root folder on disk, unlike the lane-gate module, because a plan is authored BEFORE
   #    the code exists. That is the point of planning.
   - id: lane_resolve
     action: execute_script
@@ -201,18 +204,18 @@ workflow:
     action: verify_context
     require_true: lanes_declared
     on_false: stop
-    on_false_message: "No lane is declared in .appweaver/stacks.json, so there is nothing to plan. Run /appweaver select-stack and declare the backend stack, the frontend stack, or both — plus each one's source path — then re-run plan. The declaration is what tells this phase which documents to write; a plan written against no declared stack invents its own."
+    on_false_message: "No lane is declared in .appweaver/stacks.json, so there is nothing to plan. Run /appweaver select-stack and declare the backend stack, the frontend stack, or both — plus each one's lane root folder — then re-run plan. The declaration is what tells this phase which documents to write; a plan written against no declared stack invents its own."
 
   # 1. TECHNICAL rule files → sticky standards (configuration, not hardcoded).
-  #    The service lane's set is loaded under `## /aw-spec-plan`; the frontend lane's under
-  #    `## /aw-spec-plan-ui`, and ONLY when that lane is declared — so a backend-only
+  #    The service lane's set is loaded under `## /aw-spec-plan-backend`; the frontend lane's
+  #    under `## /aw-spec-plan-frontend`, and ONLY when that lane is declared — so a backend-only
   #    project's standards are exactly what they were before the two commands merged.
   #    No blocking gate: an unconfigured project soft-continues (the constitutions still
   #    carry each lane's ratified base).
   #
   #    ONLY THE BACKEND'S RULES LOAD HERE. The frontend's used to load alongside them,
   #    before either lane authored anything, and sticky standards only accumulate — so the
-  #    service plan was authored with `## /aw-spec-plan-ui` in its envelope and the
+  #    service plan was authored with `## /aw-spec-plan-frontend` in its envelope and the
   #    experience plan with the service set. Each prompt names its lane, but it said so
   #    inside an envelope that contradicted it. The UI set now loads at the frontend
   #    boundary instead, with `replace`, in both places a frontend document is authored:
@@ -222,7 +225,7 @@ workflow:
     condition: "{{be_declared}} == true"
     action: include
     module: .appweaver/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-plan }
+    with: { command: aw-spec-plan-backend }
 
   # 2. Resolve the current feature and require its spec.
   - id: feature_paths
@@ -617,6 +620,10 @@ workflow:
         as field shapes. That section is the ONLY part of this document the frontend plan
         may read; keep it complete and self-contained, because a contract the UI needs and
         this document never states becomes a client-side workaround.
+      - NAME EVERY ENDPOINT. Each §3 endpoint carries an **Operation id** — its name in the
+        service's published API document (e.g. `CreatePatient`), unique across the
+        service and never reused. The frontend plan cites it, and implement gives the
+        endpoint exactly this id, so the two lanes meet on it.
       - CONSTITUTION-MANDATED CROSS-CUTTING (from the loaded technical constitution, NOT
         the spec): a NON-NEGOTIABLE technical principle you must apply that has NO
         per-feature spec id. APPLY it (it is non-negotiable), and because it is not
@@ -704,6 +711,10 @@ workflow:
       - PUBLISH THE SURFACE THE FRONTEND LANE BINDS TO: the section carrying this feature's
         endpoints states each contract as field shapes, completely, because it is the only
         part of this document the frontend plan may read.
+      - NAME EVERY ENDPOINT with its route, verb and operation id — its name in the
+        service's published API document, unique across the service. Where the code
+        already gives the endpoint one, record THAT id exactly as the code spells it; the
+        frontend plan cites it and implement finds the endpoint by it.
       - CONSTITUTION-MANDATED CROSS-CUTTING (from the loaded technical constitution, NOT
         the spec): a NON-NEGOTIABLE technical principle with no per-feature spec id —
         APPLY it, and LOG it as a §5 DA-n whose basis cites the mandating principle
@@ -773,6 +784,9 @@ workflow:
         workarounds are DECISIONS THIS TEAM MADE, not derivations from the spec — keep
         every one, with its id and its basis, unless the thing it decided about is gone.
         Never renumber a surviving entry: its id is cited elsewhere.
+      - OPERATION IDS ARE STABLE. Every endpoint keeps the operation id it already has —
+        the frontend plan and the built code both use it. A new endpoint gets one, unique
+        across the service; an endpoint without one gets one now.
       - THE CODE THAT EXISTS IS THE WHAT-IS AUTHORITY. {{source_count}} source file(s)
         realise this feature: {{source_files}}. READ them, and where the plan and the code
         disagree about STRUCTURE, the code is what is actually there — conform to it and
@@ -788,7 +802,7 @@ workflow:
   # ══════════════ THE LANE SWAP — the frontend's rules replace the backend's ═══
   # Both tech-select includes used to run up at step 4, before either lane authored
   # anything, and sticky standards only accumulate — so on a full-stack run the backend
-  # plan was authored with `## /aw-spec-plan-ui` in its envelope and the frontend plan with
+  # plan was authored with `## /aw-spec-plan-frontend` in its envelope and the frontend plan with
   # the service set. Each prompt names its lane, but it did so inside an envelope that
   # contradicted it, and the envelope is the half the model cannot argue with.
   #
@@ -800,7 +814,7 @@ workflow:
     condition: "{{fe_mode}} != skip"
     action: include
     module: .appweaver/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-plan-ui, replace: "true" }
+    with: { command: aw-spec-plan-frontend, replace: "true" }
 
   # ═══════════ FRONTEND LANE — bootstrap, greenfield experience template ═══════
   # The experience twin of the service plan, and the MEDIATOR between spec.md and the
@@ -867,6 +881,10 @@ workflow:
         DELTA raised back to the service lane under "Contract deltas needed" — never a
         workaround in the client. Where no service plan is in context, bind from the
         spec's IC- surface and record that as a §8 DA-n.
+      - EVERY §5 ROW CITES ITS OPERATION ID, copied exactly from the endpoint's
+        **Operation id** in the backend plan's §3 — implement looks the endpoint up by it
+        in the service's exported API document. Where no service plan names one, write
+        `—` and record it in the same §8 DA-n.
       - CONSTITUTION-MANDATED CROSS-CUTTING (from the loaded UI constitution, NOT the
         spec): a NON-NEGOTIABLE UX principle you must apply that has no per-feature spec
         id. APPLY it, and because it is not spec-derived, LOG it as a §8 DA-n whose
@@ -952,6 +970,9 @@ workflow:
         states. Cite them; do not restate, re-derive or contradict them, and introduce no
         server-side behaviour. What the experience needs and the surface lacks is a
         contract delta raised back to the service lane, never a client workaround.
+      - EVERY BINDING ROW CITES ITS OPERATION ID, copied exactly from the backend plan —
+        implement looks the endpoint up by it in the service's exported API document.
+        Where no service plan names one, write `—` and record it as a DA-n.
       - CONSTITUTION-MANDATED CROSS-CUTTING with no per-feature spec id: apply it, and
         log it as a DA-n citing the mandating principle ("per constitution.ui.md
         UX-<n>"). Do not fabricate a spec id for it and do not leave it uncited.
@@ -1010,6 +1031,9 @@ workflow:
         — the spec's IC- ids and, where the backend plan is in context, the API contracts
         it states. What the experience needs and the surface lacks is a contract delta
         raised back to the service lane, never a client workaround.
+      - EVERY BINDING ROW CITES ITS OPERATION ID, copied exactly from the backend plan; a
+        row that has none yet gets it now, and a row whose id the backend plan no longer
+        has is re-bound. Where no service plan names one, write `—` with a DA-n.
       - TECHNOLOGY-AGNOSTIC: no framework, router, state library, component library or
         styling approach — responsibilities, field shapes, events and states only.
       - ADD ONE Change History row for this re-derivation, describing what MOVED and why.

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

@@ -32,7 +32,7 @@ scripts:
 # operating rules, which is where "never run a migration against a shared environment"
 # lives. The technical rule file
 # the migration step works against (persistence) is now CONFIGURATION, loaded per-command from
-# guardrails/projects/<project>/tech-rule-bindings.md under "## /aw-spec-run" by the tech-select
+# guardrails/<project>/tech-rule-bindings.md under "## /aw-spec-run" by the tech-select
 # module (see the tech_select step below). No domain files; run does not reference
 # constitution.technical.md. (missing files skipped at assembly time)
 standards:
@@ -44,7 +44,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-run" and loads
+  #    reads guardrails/<project>/tech-rule-bindings.md under "## /aw-spec-run" and loads
   #    that set (persistence) into the sticky standards the agent_generate migration step ALWAYS
   #    prepends. No domain rule file here. No blocking gate: an unconfigured project soft-continues.
   - id: tech_select
@@ -66,8 +66,8 @@ workflow:
     on_empty: stop
     on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the feature, e.g. Order or PatientRegistration), then re-run run."
 
-  # Require the SERVICE LANE and its source path. Migrations belong to the backend
-  # lane by definition, and run-migrate searches that lane's root for the project
+  # Require the SERVICE LANE and its lane root folder. Migrations belong to the backend
+  # lane by definition, and run-migrate searches that lane root folder for the project
   # instead of assuming `src/` — which is what lets a repo whose service code sits
   # in `Legacy/App/` or `backend/` find its own migrations.
   - id: lane_gate

package/assets/.appweaver/orchestrator/workflows/aw-spec-select-bounded-context.orch.yaml

@@ -24,6 +24,9 @@
 #   list-contexts → user_select (existing | "+ create new") → [ask name] → set-context
 #
 # Persists .appweaver/context.json {"context":"<Name>","context_directory":"specs/<Name>"}.
+# When the chosen context does not contain the active feature, set-context also clears
+# .appweaver/feature.json, so specify and every later stage stop until select-feature
+# picks a feature inside the new context.
 #
 # Launch:
 #   /appweaver select-bounded-context           # interactive: list + add-new
@@ -32,7 +35,7 @@
 
 name: aw-spec-select-bounded-context
 description: Pick an existing bounded context or create a new one, and store it in .appweaver/context.json so select-feature nests its features inside it and every spec in the context shares one domain-model.md. Zero LLM — scripts + one selection only.
-version: 1.0.0
+version: 1.1.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
@@ -51,6 +54,8 @@ vars:
   new_sentinel: "+ Create a new bounded context"   # source of truth is list-contexts $.sentinel; overwritten below
   typed_name: ""
   target_name: ""
+  feature_cleared: "false"
+  cleared_feature: ""
 
 workflow:
 
@@ -120,6 +125,23 @@ workflow:
       - { name: existed,             from: "$.existed" }
       - { name: created,             from: "$.created" }
       - { name: domain_model_exists, from: "$.domain_model_exists" }
+      - { name: feature_cleared,     from: "$.feature_cleared" }
+      - { name: cleared_feature,     from: "$.cleared_feature" }
+
+  # 6. Say when the active feature was cleared: every feature-scoped stage stops until
+  #    select-feature runs. The never-satisfiable `equals` is the engine's announce-only
+  #    idiom: the step is entered only when a feature was cleared, and the comparison
+  #    always misses, so the message is emitted and the run continues.
+  - id: feature_cleared_notice
+    action: verify_context
+    condition: "{{feature_cleared}} == true"
+    require_value: feature_cleared
+    equals: "never"
+    on_mismatch: continue
+    on_mismatch_message: >
+      The previously active feature {{cleared_feature}} is not in {{context}}, so it is
+      no longer active. Run /appweaver select-feature to pick or create a feature in
+      {{context_dir}}/ before specify or any later stage.
 
 outputs:
   context: "{{context}}"
@@ -128,5 +150,7 @@ outputs:
   domain_model_exists: "{{domain_model_exists}}"
   created: "{{created}}"
   legacy_features: "{{legacy_features}}"
-  note: "Active bounded context set in .appweaver/context.json. select-feature now creates and lists features inside {{context_dir}}/, and every spec there shares {{domain_model}} as its domain model. Features already sitting flat under specs/ are listed as legacy_features — they keep working exactly as before and are not moved; re-run select-feature after selecting a context to place new work inside it."
+  feature_cleared: "{{feature_cleared}}"
+  cleared_feature: "{{cleared_feature}}"
+  note: "Active bounded context set in .appweaver/context.json. select-feature now creates and lists features inside {{context_dir}}/, and every spec there shares {{domain_model}} as its domain model. When the previously active feature is not in this context, .appweaver/feature.json is cleared (feature_cleared true, cleared_feature names it) and specify and every later stage stop until select-feature runs. Features already sitting flat under specs/ are listed as legacy_features — they are not moved; re-run select-feature after selecting a context to place new work inside it."
   next: "/appweaver select-feature   (creates {{context_dir}}/<Feature>/, then specify)"

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

@@ -1,9 +1,14 @@
 # =============================================================================
-# aw-spec-select-domain (orchestrator) — select the active PROJECT under guardrails/projects/
+# aw-spec-select-domain (orchestrator) — select the active PROJECT folder under guardrails/
 #
 # The command name and .appweaver/domain.json are historical: what is selected is a
 # project folder, and a project is bound to rules by its two maps, not by an industry.
 #
+# OPTIONAL: no sequence runs it. domain.json ships naming guardrails/project-specific/ and
+# onboard points it at the guardrails/brf-<domain>/ it creates; this command switches to
+# any other project folder that already exists (e.g. a copy of project-specific). It never
+# creates one — a name with no folder is not offered, and the user picks from the list.
+#
 # Pure orchestration/governance, NO generation: scripts + one gate + one HITL select.
 # Exercises the D1 interaction channel: under ANY strategy the `user_select`
 # step suspends via --checkpoint (kind 'select') so the LAUNCHING agent asks
@@ -17,14 +22,14 @@
 # =============================================================================
 
 name: aw-spec-select-domain
-description: Select the active project under guardrails/projects/ and store it in .appweaver/domain.json, binding both of that project's rule maps — domain-rule-bindings.md and tech-rule-bindings.md — so every AW-Spec command loads the right domain AND technical rule files.
-version: 1.0.0
+description: Switch the active project — a folder under guardrails/ that holds the rule maps — by storing its name in .appweaver/domain.json, binding both of that project's rule maps (domain-rule-bindings.md and tech-rule-bindings.md) so every AW-Spec command loads that project's domain AND technical rule files. Optional; domain.json names guardrails/project-specific/ by default.
+version: 1.1.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
 inputs:
   user_input:
-    description: Optional project folder name under guardrails/projects/ to set directly (e.g. dotnet-default-project). An industry name is not a valid value — an industry is a corpus a project's map points at, never a selection.
+    description: Optional project folder name under guardrails/ to set directly (e.g. project-specific). The folder must already exist and hold a rule map; any other name shows the list of projects instead. An industry name is not a valid value — an industry is a corpus a project's map points at, never a selection.
     required: false
     bind: USER_INPUT
 
@@ -35,7 +40,7 @@ scripts:
 
 workflow:
 
-  # 1. Discover candidate projects = subdirs of guardrails/projects/ carrying a rule map.
+  # 1. Discover candidate projects = top-level folders of guardrails/ carrying a rule map.
   - id: list_domains
     action: execute_script
     script: { ref: actions }
@@ -43,21 +48,22 @@ workflow:
     outputs:
       - { name: domains, from: "$.domains" }
 
-  # 2. Stop early if there are no domains to choose from.
+  # 2. Stop early if there are no projects to choose from.
   - id: guard_no_domains
     action: verify_context
     require_non_empty: domains
     on_empty_message: >
-      No governed projects found. Copy guardrails/projects/dotnet-default-project/ to
-      guardrails/projects/<name>/ and repoint its two maps at the technology and domain
-      corpora this project uses, then re-run.
+      No project folders found under guardrails/. Copy guardrails/project-specific/ to
+      guardrails/<name>/, change the guardrails/project-specific/ paths inside its two maps
+      to guardrails/<name>/, repoint the maps at the technology and domain corpora this
+      project uses, then re-run.
     on_empty: stop
 
-  # 3. Choose the domain. If USER_INPUT names a valid domain it is used directly;
+  # 3. Choose the project. If USER_INPUT names a listed project it is used directly;
   #    otherwise the launcher relays the choice to the user. One option => confirm.
   - id: select_domain
     action: user_select
-    prompt: "Select the active domain:"
+    prompt: "Select the active project:"
     options_from_variable: domains
     preselect_from: USER_INPUT     # direct-argument fast path
     single_option_confirm: true
@@ -79,7 +85,7 @@ outputs:
   domain: "{{domain}}"
   domain_rule_bindings: "{{map_path}}"
   domain_rule_bindings_exists: "{{map_exists}}"
-  note: "Active project '{{domain}}' persisted to .appweaver/domain.json. It selects TWO rule maps under guardrails/projects/{{domain}}/ — domain-rule-bindings.md (DOMAIN rules; read by constitution + specify only, because the spec is the pivot) and tech-rule-bindings.md (TECHNICAL rules; read by 10 workflows incl. design, implement, build and run). The rule FILES themselves live in shared corpora — guardrails/technology/<stack>/ and guardrails/domain/<industry>/ — and the maps are what bind this project to them, so two projects can share a corpus and differ only in their maps and their own three requirements files. domain_rule_bindings_exists reports the domain half only. A map that is absent, or a command with no heading in one, loads nothing for that class and SOFT-CONTINUES — an absent heading is a valid state, never a failure."
-  # constitution comes BEFORE select-feature: it reads the domain rule map this
-  # workflow just bound, and specify declares its domain half as REQUIRED context.
-  next: "/appweaver constitution → select-feature → specify. /appweaver constitution authors the constitution halves from the domain rule map this run just bound — specify declares constitution.domain.md as REQUIRED context, and plan and implement read constitution.technical.md (plus constitution.ui.md on a frontend lane), so it runs before the first feature rather than after. /appweaver select-feature then picks the feature to build; every stage from specify onward reads that active feature and stops without it. Re-run /appweaver select-domain any time to switch projects; it rebinds both maps at once, and /appweaver constitution picks the new bindings up on its next run."
+  note: "Active project '{{domain}}' persisted to .appweaver/domain.json. It selects TWO rule maps under guardrails/{{domain}}/ — domain-rule-bindings.md (DOMAIN rules; read by constitution + specify only, because the spec is the pivot) and tech-rule-bindings.md (TECHNICAL rules; read by the HOW phases incl. foundation's spec builds, plan, implement, build and run). The rule FILES themselves live in shared corpora — guardrails/technology/<stack>/ and guardrails/domain/<industry>/ — and the maps are what bind this project to them, so two projects can share a corpus and differ only in their maps and their own three requirements files. domain_rule_bindings_exists reports the domain half only. A map that is absent, or a command with no heading in one, loads nothing for that class and SOFT-CONTINUES — an absent heading is a valid state, never a failure."
+  # constitution reads the domain rule map this workflow just bound; the halves it
+  # already wrote stay as they are until it runs again.
+  next: "Switching the project changes which rule files later commands load; it does not rewrite anything already written. Re-run /appweaver constitution so constitution.domain.md, constitution.technical.md and constitution.ui.md are authored from the new project's rules — specify declares constitution.domain.md as REQUIRED context, and plan and implement read constitution.technical.md (plus constitution.ui.md on a frontend lane). Specs and plans already written keep the rules they were written under. GREENFIELD with no project scaffolded yet: /appweaver foundation first — a lane built from a spec follows the technical rules this run just bound (`## /aw-spec-foundation-backend` / `## /aw-spec-foundation-frontend`) — then /appweaver constitution → specify. To add another project, copy guardrails/project-specific/ to guardrails/<name>/, change the guardrails/project-specific/ paths inside its two maps to guardrails/<name>/, and run /appweaver select-domain <name>. Re-run /appweaver select-domain any time to switch back; it rebinds both maps at once."

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

@@ -14,12 +14,12 @@
 # evidence sits in, and both are only ever proposals — an operator selects from the
 # list or types a path the kit has never seen.
 #
-#   stack-list --suggest backend  → select stack → stack-list --profile → ask source path → lane-declare
-#   stack-list --suggest frontend → select stack → stack-list --profile → ask source path → lane-declare
+#   stack-list --suggest backend  → select stack → stack-list --profile → ask lane root folder → lane-declare
+#   stack-list --suggest frontend → select stack → stack-list --profile → ask lane root folder → lane-declare
 #
 # THE SOURCE-PATH OPTIONS ARE BUILT AFTER THE STACK IS CHOSEN. Most profiles of a kind
-# share a default root (six frontend stacks default to web/), so a list built before the
-# choice cannot say which stack an option belongs to. The second stack-list call answers
+# share a default root (every backend stack defaults to backend/, every frontend stack to
+# frontend/), so a list built before the choice cannot say which stack an option belongs to. The second stack-list call answers
 # for the chosen stack alone.
 #
 # (none) IS A REAL ANSWER FOR EITHER LANE, and it is how a project says "I do not
@@ -34,7 +34,7 @@
 # lane a person already declared. Every other workflow calls `lane-resolve` to read
 # and `lane-verify` to gate, and neither can write.
 #
-# WHY THE SOURCE PATH IS ASKED AND NOT INHERITED. A lane's root is the subtree it
+# WHY THE LANE ROOT FOLDER IS ASKED AND NOT INHERITED. A lane root folder is the subtree its lane
 # OWNS: the only place implement's lane for it may write, the directory its build and
 # run commands act on, and in brownfield the code onboard reads. A profile's default
 # root describes how a NEW project of that stack is usually laid out, which is a
@@ -60,7 +60,7 @@
 # =============================================================================
 
 name: aw-spec-select-stack
-description: Declare the project's lanes — each lane's STACK and its SOURCE PATH — and persist them to .appweaver/stacks.json, the single channel every later workflow resolves and gates on. The first command of both the greenfield and the brownfield sequence, and the sole writer of the lane model.
+description: Declare the project's lanes — each lane's STACK and its LANE ROOT FOLDER — and persist them to .appweaver/stacks.json, the single channel every later workflow resolves and gates on. The first command of both the greenfield and the brownfield sequence, and the sole writer of the lane model.
 version: 2.3.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
@@ -139,7 +139,7 @@ workflow:
   # 5. WHERE the service lane's source lives. Offered best-first for the CHOSEN stack —
   #    where its evidence sits, then its own default, then where another stack's
   #    evidence sits — and free text is accepted, because a repo that matches no
-  #    profile still has a source path. The label after the path says why it is
+  #    profile still has a lane root folder. The label after the path says why it is
   #    offered and is stripped on the way in.
   - id: list_api_roots
     action: execute_script
@@ -153,7 +153,7 @@ workflow:
   - id: ask_api_source_path
     action: ask
     condition: "{{api_selected}}"
-    prompt: "Service lane SOURCE PATH — the subtree this lane owns, where implement writes its code, and the directory build/test/run act on. Its tests go to the stack's test path beside it (tests/ next to src/ for .NET), shown in the summary. Pick one or type your own:"
+    prompt: "Service LANE ROOT FOLDER — the subtree this lane owns, where implement writes its code, and the directory build/test/run act on. Its tests go to the stack's test path — inside it for a new project (backend/tests/ for .NET), beside it in a classic layout (tests/ next to src/) — shown in the summary. Pick one or type your own:"
     options_from_variable: api_root_options
     answer_var: api_source_path
 
@@ -224,7 +224,7 @@ workflow:
   - id: ask_ui_source_path
     action: ask
     condition: "{{ui_selected}}"
-    prompt: "UI lane SOURCE PATH — the subtree this lane owns, the only place implement's frontend lane may write. It must not overlap the service lane's. Pick one or type your own:"
+    prompt: "UI LANE ROOT FOLDER — the subtree this lane owns, the only place implement's frontend lane may write. It must not overlap the service lane's. Pick one or type your own:"
     options_from_variable: ui_root_options
     answer_var: ui_source_path
 
@@ -243,7 +243,7 @@ workflow:
 
   # ═══════════════ CHECK + REPORT ═════════════════════════════════════════════
 
-  # 10. Is what was just written sound? --allow-missing-root because a source path
+  # 10. Is what was just written sound? --allow-missing-root because a lane root folder
   #     declared here legitimately does not exist yet; what this catches is a lane
   #     declared with NO path at all, which no later phase could act on. The on-disk
   #     check belongs to the phases that read the subtree, and runs there.
@@ -279,7 +279,7 @@ workflow:
   - id: api_summary_lane
     action: set
     condition: "{{api_declared}}"
-    vars: { api_summary: "{{api_lane_id}} ({{api_profile}}) at {{api_root}}, tests at {{api_test_path}} — source path exists: {{api_root_exists}}" }
+    vars: { api_summary: "{{api_lane_id}} ({{api_profile}}) at {{api_root}}, tests at {{api_test_path}} — lane root folder exists: {{api_root_exists}}" }
 
   - id: ui_summary_none
     action: set
@@ -287,7 +287,7 @@ workflow:
   - id: ui_summary_lane
     action: set
     condition: "{{ui_declared}}"
-    vars: { ui_summary: "{{ui_lane_id}} ({{ui_profile}}) at {{ui_root}}, tests at {{ui_test_path}} — source path exists: {{ui_root_exists}}" }
+    vars: { ui_summary: "{{ui_lane_id}} ({{ui_profile}}) at {{ui_root}}, tests at {{ui_test_path}} — lane root folder exists: {{ui_root_exists}}" }
 
   # 12. Read the finished declaration back through the reader every later workflow
   #     uses, so what this run reports is what they will resolve.
@@ -316,5 +316,5 @@ outputs:
   api_detected: "{{api_detected}}"
   ui_detected: "{{ui_detected}}"
   prototype: "{{prototype}}"
-  note: "Lanes persisted to .appweaver/stacks.json. Each lane carries a STACK and a SOURCE PATH, and both are load-bearing. The SOURCE PATH is ownership: implement's service lane writes its code only under the service lane's and its frontend lane only under the UI lane's, build/test/run act on it, and onboard reverse-engineers out of it. Each lane also owns a TEST PATH, taken from its stack profile — tests/ beside a .NET src/, the source path itself for a stack that keeps its tests inside — and implement writes the lane's tests there. Overlapping paths of either kind are refused here rather than discovered later as two generators writing one file. The build/test/run commands are project-supplied strings the engine shells out to, which is how it stays stdlib-only and stack-ignorant. api_detected / ui_detected report what this repo's own files pointed at, whether or not it was chosen, as "<stack> at <path>" — or "nothing detected" on a greenfield repo with nothing to detect. A source path that does not exist yet is NORMAL here and reported rather than refused: greenfield declares src/ before implement creates it. The on-disk check runs in the phases that read the subtree — implement, build, run and onboard all call lane-verify and STOP with the fix named. Declining a lane with (none) is a real declaration and removes any lane of that kind a previous run left behind; it is also what stops that lane's constitution half and rule files being authored. `prototype` is not a lane — it has a root and a run command so an operator can open it, and nothing else. Re-run this workflow any time to re-stack a lane, move a source path, or drop a lane with (none); it is the only workflow that may write this file."
-  next: "GREENFIELD: /appweaver foundation — once per lane, to scaffold a compiling project into each source path declared here (skip it for a lane whose code already exists, or scaffold with the stack's own tooling) — then /appweaver select-domain → constitution → select-feature → specify. BROWNFIELD: /appweaver inventory — it scans the source paths declared here and proposes the bounded contexts and features as specs/proposed-inventory.md; edit that map, run /appweaver inventory apply, then /appweaver onboard <Context> once per bounded context, which reverse-engineers the governance out of the same source paths and activates it (no select-domain; onboard derives it from the code). Run this workflow FIRST in either sequence: foundation unpacks into the source paths declared here, constitution reads the declaration to decide which halves to author, and inventory and onboard read it to decide what to scan."
+  note: "Lanes persisted to .appweaver/stacks.json. Each lane carries a STACK and a LANE ROOT FOLDER, and both are load-bearing. The LANE ROOT FOLDER is ownership: implement's service lane writes its code only under the service lane's and its frontend lane only under the UI lane's, build/test/run act on it, and onboard reverse-engineers out of it. Each lane also owns a TEST PATH, taken from its stack profile — tests/ beside a .NET src/, the lane root folder itself for a stack that keeps its tests inside — and implement writes the lane's tests there. Overlapping paths of either kind are refused here rather than discovered later as two generators writing one file. The build/test/run commands are project-supplied strings the engine shells out to, which is how it stays stdlib-only and stack-ignorant. api_detected / ui_detected report what this repo's own files pointed at, whether or not it was chosen, as '<stack> at <path>' — or 'nothing detected' on a greenfield repo with nothing to detect. A lane root folder that does not exist yet is NORMAL here and reported rather than refused: greenfield declares src/ before implement creates it. The on-disk check runs in the phases that read the subtree — implement, build, run and onboard all call lane-verify and STOP with the fix named. Declining a lane with (none) is a real declaration and removes any lane of that kind a previous run left behind; it is also what stops that lane's constitution half and rule files being authored. `prototype` is not a lane — it has a root and a run command so an operator can open it, and nothing else. Re-run this workflow any time to re-stack a lane, move a lane root folder, or drop a lane with (none); it is the only workflow that may write this file."
+  next: "GREENFIELD: /appweaver foundation → constitution → specify. The project rules live in guardrails/project-specific/, which .appweaver/domain.json names by default — fill in its rule files and its two maps; /appweaver select-domain switches to another project folder under guardrails/ when you keep more than one. On a project with no specs yet, constitution creates the default bounded context MainContext and its feature CoreFeature and makes both active; to use your own names, run /appweaver select-bounded-context <Name> and then /appweaver select-feature <Name> before specify. Once any bounded context exists, select-feature refuses to run until one is selected. foundation scaffolds every lane declared here in one run, backend then frontend — from a verified pack, from a spec the agent builds the project from, or skipped for a lane whose code already exists — and a spec build follows the technical rules the active project maps under `## /aw-spec-foundation-backend` and `## /aw-spec-foundation-frontend`. BROWNFIELD: /appweaver inventory — it scans the lane root folders declared here and proposes the bounded contexts and features as specs/proposed-inventory.md; edit that map, run /appweaver inventory apply, then /appweaver onboard <Context> once per bounded context, which reverse-engineers the governance out of the same lane root folders and activates it: onboard creates guardrails/brf-<domain>/ from the code and names it in .appweaver/domain.json. Run this workflow FIRST in either sequence: foundation scaffolds into the lane root folders declared here, constitution reads the declaration to decide which halves to author, and inventory and onboard read it to decide what to scan."

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

@@ -93,7 +93,7 @@ scripts:
 # Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). Specify's ONE
 # technical input — the MODELLING METHODOLOGY (DDD tactical patterns) — is no longer
 # hardcoded here: it is now CONFIGURATION, loaded per-command 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 step below), exactly as the DOMAIN rule files are loaded by domain-select.
 # Per the rule-partition that heading may carry a modelling methodology ONLY — never an
 # architecture / persistence / codegen file; those belong to design + implement, and
@@ -193,7 +193,7 @@ workflow:
       - { name: next_wave,           from: "$.next_wave" }
 
   # 2. TECHNICAL rule files → sticky standards (configuration, not hardcoded).
-  #    tech-select reads guardrails/projects/<project>/tech-rule-bindings.md under
+  #    tech-select reads guardrails/<project>/tech-rule-bindings.md under
   #    "## /aw-spec-specify" and loads that set. Per the rule-partition that heading is
   #    the MODELLING-METHODOLOGY slot only (DDD tactical patterns) — it must never list an
   #    architecture / persistence / codegen file, which would break specify's domain purity.
@@ -643,7 +643,7 @@ workflow:
         action: verify_context
         require_true: nn_compliant
         on_false: stop
-        on_false_message: "The answer to \"{{c.question}}\" departs from NON-NEGOTIABLE principle {{nn_principle}}: {{nn_why}}. That principle is ratified in .appweaver/memory/ and this answer has no approver — it was settled in this run, not by a domain owner, and the constitution's Governance section holds that a deviation with no named approver is a defect rather than a decision. Re-run specify and answer in a way the principle allows; if the project genuinely intends to depart from it, amend the constitution through its own amendment process FIRST (which names the approver the departure needs) and re-run. Nothing was written to {{quality_target}} for this clarification."
+        on_false_message: "The answer to '{{c.question}}' departs from NON-NEGOTIABLE principle {{nn_principle}}: {{nn_why}}. That principle is ratified in .appweaver/memory/ and this answer has no approver — it was settled in this run, not by a domain owner, and the constitution's Governance section holds that a deviation with no named approver is a defect rather than a decision. Re-run specify and answer in a way the principle allows; if the project genuinely intends to depart from it, amend the constitution through its own amendment process FIRST (which names the approver the departure needs) and re-run. Nothing was written to {{quality_target}} for this clarification."
 
       - id: resolve_clar
         action: agent_author

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

@@ -115,9 +115,9 @@ workflow:
     context:
       - "{{feature_dir}}/ui/workflow-model.md"
       - "{{spec_file}}"
-      - { path: "guardrails/projects/{{domain}}/frontend/design.md", optional: true }
-      - { path: "guardrails/projects/{{domain}}/frontend/DESIGN.md", optional: true }
-      - { path: "guardrails/projects/{{domain}}/frontend/ui-requirements.md", optional: true }
+      - { path: "guardrails/{{domain}}/frontend/design.md", optional: true }
+      - { path: "guardrails/{{domain}}/frontend/DESIGN.md", optional: true }
+      - { path: "guardrails/{{domain}}/frontend/ui-requirements.md", optional: true }
       - { path: ".appweaver/templates/ui-model-template.md", optional: true }
       - { path: ".appweaver/memory/constitution.ui.md", optional: true }
 

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

@@ -141,9 +141,9 @@ workflow:
       - { path: "{{domain_model}}", optional: true }
       - { path: "{{feature_dir}}/ui/workflow-model.md", optional: true }
       - { path: "{{feature_dir}}/ui/ui-model.md", optional: true }
-      - { path: "guardrails/projects/{{domain}}/frontend/design.md", optional: true }
-      - { path: "guardrails/projects/{{domain}}/frontend/DESIGN.md", optional: true }
-      - { path: "guardrails/projects/{{domain}}/frontend/ui-requirements.md", optional: true }
+      - { path: "guardrails/{{domain}}/frontend/design.md", optional: true }
+      - { path: "guardrails/{{domain}}/frontend/DESIGN.md", optional: true }
+      - { path: "guardrails/{{domain}}/frontend/ui-requirements.md", optional: true }
       - { path: ".appweaver/memory/constitution.domain.md", optional: true }
       - { path: ".appweaver/memory/constitution.ui.md", optional: true }
       - { path: "{{feature_dir}}/changes/{{active_change}}/delta-spec.md", optional: true }
@@ -254,7 +254,7 @@ workflow:
       The feature specification is taken directly from the bounded context directory and feature path defined in `.appweaver/feature.json`:
       `{{spec_file}}` (Bounded Context: `{{context_name}}`, Feature: `{{feature_name}}`).
       Read this specification strictly from `{{spec_file}}`, along with the bounded context's canonical domain model (`{{domain_model}}`),
-      the project Design System if present (`guardrails/projects/{{domain}}/frontend/design.md` or `DESIGN.md`, or `{{feature_dir}}/ui/design.md`),
+      the project Design System if present (`guardrails/{{domain}}/frontend/design.md` or `DESIGN.md`, or `{{feature_dir}}/ui/design.md`),
       and when available, the Workflow Model (`{{feature_dir}}/ui/workflow-model.md`) and UI Model (`{{feature_dir}}/ui/ui-model.md`), plus `{{prototype_root}}/lib/screens-registry.ts` / `screens.json`.
       If `workflow-model.md` and `ui-model.md` are not provided, derive all UI surfaces, workflows, and interaction states directly from `{{spec_file}}`.
 
@@ -342,7 +342,7 @@ workflow:
            Tailwind/CSS config from the shell is intact. If it's missing or broken, fix it
            as part of this run and note that in your final summary; don't build a styled-looking
            screen on top of a broken/absent styling pipeline.
-         - If a project visual design system is present in context (`guardrails/projects/{{domain}}/frontend/design.md` or `DESIGN.md`),
+         - If a project visual design system is present in context (`guardrails/{{domain}}/frontend/design.md` or `DESIGN.md`),
            apply its visual design tokens (colors, accent, surface, border, typography, card elevation, and status states)
            consistently across all cards, badges, buttons, forms, and headers on this screen.
          - Use the shell's existing design tokens and Tailwind utility classes (or whatever
@@ -386,7 +386,7 @@ workflow:
           - Generate or update `{{feature_dir}}/ui/ui-spec.md` alongside the prototype code.
           - Format as a markdown document with a brief title and capture intro, followed by a SINGLE fenced `json` code block adhering strictly to the JSON schema defined in `skill/references/output-ui-spec.md`:
             - `screen`: user-facing screen name and route
-            - `captureNotes`: viewport width, CSS px, DPR, and design system token origin (`guardrails/projects/{{domain}}/frontend/DESIGN.md` or `design.md`)
+            - `captureNotes`: viewport width, CSS px, DPR, and design system token origin (`guardrails/{{domain}}/frontend/DESIGN.md` or `design.md`)
             - `regions`: ordered list of UI regions (nav-bar, header, step-card, content, dialogs, drawers) with `layout` (`position`, `wrap`, `direction`) and `elements` array
             - `elements`: each element detailing `id`, `kind` (`text`, `button`, `badge`, `avatar`, `card`, `input`, etc.), verbatim `content`, `style` (`shape`, `colorToken`, `typographyToken`, `spacingPx`), `state` (`default`, `active`, `hover`), and `fields`
             - `navigation`: ordered nav items, activeItem, activeStyle