aw-spec-cli 0.1.26 → 0.1.27

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

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

@@ -105,7 +105,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 +179,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,7 +201,7 @@ 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

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.

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