aw-spec-cli 0.1.19 → 0.1.21

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

@@ -95,7 +95,7 @@ workflow:
     action: verify_context
     require_non_empty: feature_dir
     on_empty: stop
-    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the aggregate, e.g. Order), then re-run parity."
+    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the feature, e.g. Order or PatientRegistration), then re-run parity."
 
   - id: verify_spec
     action: verify_context

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

@@ -164,6 +164,10 @@ vars:
   plan_mode: "bootstrap"       # bootstrap | rederive | delta — reported, not branched on
   domain_model: ""
   domain_model_exists: "false"
+  owned_sections: ""           # the model section(s) this feature answers for — feature-aggregates
+  shared_with_csv: ""          # the other features answering for the same aggregate(s)
+  one_to_one: "true"
+  model_scope_plan: ""         # which part of those sections the domain layer realises
   source_files: []             # the feature's real source files, from its OKF concept
   source_count: "0"
 
@@ -241,11 +245,42 @@ workflow:
       - { name: domain_model,        from: "$.domain_model" }
       - { name: domain_model_exists, from: "$.domain_model_exists" }
 
+  # WHICH PART OF THAT MODEL THIS PLAN REALISES. The model is filed by aggregate, and a
+  # feature is a capability scope the developer chose: it may act on several aggregates,
+  # and several features may act on one. Resolved from the spec's Acts-on line, then the
+  # boundary map, then the feature name. on_error: continue — without an answer the
+  # prompt falls back to the model as a whole, which is what it read before.
+  - id: feature_aggregates
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: feature-aggregates
+    args: ["--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: owned_sections,  from: "$.owned_sections" }
+      - { name: shared_with_csv, from: "$.shared_with_csv" }
+      - { name: one_to_one,      from: "$.one_to_one" }
+
+  # HOW MUCH OF THOSE SECTIONS THE DOMAIN LAYER CARRIES. A feature that alone answers for
+  # an aggregate realises its whole section. A feature that shares it realises only what
+  # its own requirements act on: the rest is a sibling feature's, and planning it here
+  # would give two plans the same element to realise. The engine has no conditional
+  # prompt text, so the rule is an ordered pair of sets handed to the prompt as one line.
+  - id: model_scope_shared
+    action: set
+    vars:
+      model_scope_plan: "{{owned_sections}}, which this feature SHARES with other features. Realise only the entities, value objects, states and BR-nnn this feature's requirements act on, under the model's names and boundary; an element of that section this feature does not use belongs to another feature and is left out — never redefined, renamed or narrowed"
+  - id: model_scope_sole
+    condition: "{{one_to_one}} == true"
+    action: set
+    vars:
+      model_scope_plan: "{{owned_sections}}. This feature is the only one that answers for it, so the domain layer realises that whole section"
+
   - id: require_feature
     action: verify_context
     require_non_empty: feature_dir
     on_empty: stop
-    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the aggregate, e.g. Order), then re-run plan."
+    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the feature, e.g. Order or PatientRegistration), then re-run plan."
 
   - id: verify_spec
     action: verify_context
@@ -531,9 +566,10 @@ workflow:
       - THE SPEC AND THE DOMAIN MODEL ARE THE ONLY DOMAIN INPUTS. You have them plus the
         technical standards, and NO domain rule files. Realise what they state, and invent
         no domain rule they omit (an unavoidable new concept → §7 DA-n).
-      - THE DOMAIN LAYER (§1) MUST FOLLOW THE CONTEXT'S DOMAIN MODEL EXACTLY: entities &
-        value objects are its `## Aggregate:` section's entities (SAME names), invariants
-        are its BR-nnn (cite each, never restate), the aggregate boundary is its Boundary
+      - THE DOMAIN LAYER (§1) MUST FOLLOW THE CONTEXT'S DOMAIN MODEL EXACTLY. The
+        section(s) this feature answers for: {{model_scope_plan}}. Within that scope,
+        entities & value objects are the section's entities (SAME names), invariants are
+        its BR-nnn (cite each, never restate), the aggregate boundary is its Boundary
         block, and states are the lifecycle it describes. The model — not the spec — is
         where those facts live; the spec cites them by id. This document records WHERE
         each invariant is ENFORCED, never what it says. Elaborate with domain events /
@@ -631,10 +667,11 @@ workflow:
         textbook layer gets its own section; a layer the feature does not need does NOT
         appear.
       - KEEP THE NEUTRAL ANCHORS (the template pins them): §1.2 is the domain/data MODEL
-        and MUST follow the CONTEXT'S DOMAIN MODEL EXACTLY — entities & value objects are
-        its aggregate section's entities (SAME names), invariants are its BR-nnn (cite
-        each and record WHERE each is enforced), the boundary is its Boundary block,
-        states are its lifecycle; cross-slice references-by-id live here. One §2
+        and MUST follow the CONTEXT'S DOMAIN MODEL EXACTLY for the section(s) this feature
+        answers for — {{model_scope_plan}}. Entities & value objects are the section's
+        entities (SAME names), invariants are its BR-nnn (cite each and record WHERE each
+        is enforced), the boundary is its Boundary block, states are its lifecycle;
+        cross-slice references-by-id live here. One §2
         subsection is the EXTERNAL INTEGRATIONS table (its heading contains "Integration")
         — one port/adapter row per IC-, realising the obligation the spec named.
       - REALISE THE LIFTED CONSTRAINTS (each cites its spec id): CN- → structural ones
@@ -704,9 +741,10 @@ workflow:
         A row whose id is gone is deleted along with what it justified. A spec id or model
         invariant with NO plan element is a GAP — realise it, in the shape the rest of the
         document already uses.
-      - THE DOMAIN LAYER (§1) MUST FOLLOW THE CONTEXT'S DOMAIN MODEL EXACTLY: entities &
-        value objects are its `## Aggregate:` section's entities (SAME names), invariants
-        are its BR-nnn (cite each, never restate), the aggregate boundary is its Boundary
+      - THE DOMAIN LAYER (§1) MUST FOLLOW THE CONTEXT'S DOMAIN MODEL EXACTLY. The
+        section(s) this feature answers for: {{model_scope_plan}}. Within that scope,
+        entities & value objects are the section's entities (SAME names), invariants are
+        its BR-nnn (cite each, never restate), the aggregate boundary is its Boundary
         block, and states are the lifecycle it describes. Where the model has MOVED since
         this plan was written, the model is right and the plan is stale.
       - CARRY THE LEDGERS FORWARD. §7 DA-n architectural decisions and the WA-n

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

@@ -121,7 +121,7 @@ workflow:
     action: verify_context
     require_non_empty: feature_dir
     on_empty: stop
-    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the aggregate, e.g. Order), then re-run recall-delta."
+    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the feature, e.g. Order or PatientRegistration), then re-run recall-delta."
 
   # 2. WHICH CHANGES ARE OPEN — the evidence is changes/<CR-id>/ on disk. No synthetic
   #    rows: `main` is not a change and there is nothing to open here, so the menu is the

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

@@ -64,7 +64,7 @@ workflow:
     action: verify_context
     require_non_empty: feature_dir
     on_empty: stop
-    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the aggregate, e.g. Order), then re-run run."
+    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

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

@@ -1,17 +1,21 @@
 # =============================================================================
 # aw-spec-select-feature (orchestrator) — pick or create the active FEATURE
 #
-# feature = AGGREGATE (e.g. Order). This is the FIRST step of the spec-anchored
-# pipeline: it fixes the aggregate boundary BEFORE any spec/design exists, so the
-# feature's single spec.md + backend-plan.md and every command (CreateOrder/UpdateOrder =
-# user stories) hang off one directory. It replaces guessing the aggregate out of prose in
-# `specify` — that is why finding #1 (feature=aggregate) is enforced here, not hoped for.
+# A FEATURE IS A CAPABILITY SCOPE THE DEVELOPER CHOOSES (e.g. Order, or
+# PatientRegistration). It may act on several aggregates, and several features may act on
+# one: the aggregates live in the bounded context's domain model and the OKF bundle, above
+# every feature, and the spec names the ones this feature acts on. This is the FIRST step
+# of the spec-anchored pipeline: it fixes the feature's scope BEFORE any spec/plan exists,
+# so its single spec.md + backend-plan.md and every operation (CreateOrder/UpdateOrder =
+# user stories) hang off one directory.
 #
 # The pickable list is TWO merged sources (deduped by name): specs/ sub-folders
-# (features already scaffolded/adopted) AND the OKF bundle's Aggregate concepts —
-# the brownfield feature map `/appweaver onboard` reverse-engineers. So in a
-# brownfield repo you pick a real discovered code feature BEFORE anything is under
-# specs/; on greenfield (no bundle) the list is specs-only, exactly as before.
+# (features already scaffolded/adopted) AND the features the OKF bundle's concepts are
+# known to serve — from the boundary map the developer confirmed, else from each
+# concept's `features:` list. So in a brownfield repo you pick a real discovered code
+# feature BEFORE anything is under specs/. An aggregate is never offered as a feature
+# nobody defined: on greenfield every feature already has its specs/ directory, so the
+# list is specs-only.
 #
 # SCOPED BY THE ACTIVE BOUNDED CONTEXT. When .appweaver/context.json names one, both
 # the listing and the creation happen inside specs/<Context>/ — so a context shows
@@ -22,7 +26,7 @@
 # ZERO LLM: only scripts + one select + (conditionally) one ask. No generation,
 # no standards, no domain-select. Pure, deterministic orchestration/governance.
 #
-#   list-features (specs/ ∪ OKF aggregates) → user_select (existing | "+ create new") → [ask name] → set-feature
+#   list-features (specs/ ∪ features the OKF concepts serve) → user_select (existing | "+ create new") → [ask name] → set-feature
 #
 # Persists .appweaver/feature.json {"feature_directory":"specs/<Feature>"} so every
 # later command operates on it: the forward loop (specify/plan/analyze-plan/implement/
@@ -36,14 +40,14 @@
 # =============================================================================
 
 name: aw-spec-select-feature
-description: Pick an existing feature (aggregate) or create a new one, and store it in .appweaver/feature.json so every AW-Spec command operates on it. Zero LLM — scripts + one selection only.
+description: Pick an existing feature (a capability scope you choose) or create a new one, and store it in .appweaver/feature.json so every AW-Spec command operates on it. Zero LLM — scripts + one selection only.
 version: 1.0.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
 inputs:
   user_input:
-    description: Optional feature (aggregate) name to create or select directly, e.g. Order.
+    description: Optional feature name to create or select directly, e.g. Order or PatientRegistration.
     required: false
     bind: USER_INPUT
 
@@ -85,11 +89,12 @@ workflow:
     on_false_message: >
       {{scope_message}}
 
-  # 1. Enumerate selectable aggregates from TWO merged sources (deduped by name):
-  #    specs/ sub-folders (already scaffolded/adopted) AND the OKF bundle's
-  #    Aggregate concepts — the brownfield feature map onboard reverse-engineers,
-  #    so a not-yet-adopted code feature is pickable before its specs/ dir exists.
-  #    On greenfield (no bundle) the OKF source is empty → specs-only, as before.
+  # 1. Enumerate selectable FEATURES from TWO merged sources (deduped by name):
+  #    specs/ sub-folders (already scaffolded/adopted) AND the features the OKF
+  #    bundle's aggregate concepts serve — the boundary map first, else each concept's
+  #    `features:` list — so a not-yet-adopted code feature is pickable before its
+  #    specs/ dir exists. A concept greenfield implement wrote contributes nothing:
+  #    its features all have specs/ dirs, and its own name is an aggregate.
   #    `select_options` carries the "+ create new" sentinel and (when USER_INPUT
   #    names a not-yet feature) that name injected — a direct arg is one-list select.
   - id: list_features
@@ -108,7 +113,7 @@ workflow:
   #    no prompt; the lone sentinel at bootstrap (no features yet) auto-confirms.
   - id: pick
     action: user_select
-    prompt: "Select a feature (the aggregate, e.g. Order) in {{feature_base}}/ — or create a new one:"
+    prompt: "Select a feature (a capability scope, e.g. Order or PatientRegistration) in {{feature_base}}/ — or create a new one:"
     options_from_variable: select_options
     preselect_from: USER_INPUT
     single_option_confirm: true
@@ -120,9 +125,10 @@ workflow:
     action: ask
     condition: "{{chosen}} == {{new_sentinel}}"
     prompt: >
-      Name the new feature — this is the AGGREGATE root (e.g. Order, Invoice,
-      Customer), NOT a single command. Operations like CreateOrder / UpdateOrder
-      become user stories inside it:
+      Name the new feature — the capability scope you want to specify and build as
+      one unit (e.g. Order, PatientRegistration). It may act on several aggregates, and
+      other features may act on the same ones; its spec names them. Each operation in
+      its scope (e.g. CreateOrder / UpdateOrder) becomes a user story inside it:
     answer_var: typed_name
 
   # 4. Coalesce the target name. The engine has no compound conditions, so this
@@ -136,7 +142,7 @@ workflow:
     condition: "{{chosen}} == {{new_sentinel}}"
     vars: { target_name: "{{typed_name}}" }
 
-  # 5. Create-or-select the aggregate dir + persist it as the active feature.
+  # 5. Create-or-select the feature dir + persist it as the active feature.
   - id: set_feature
     action: execute_script
     script: { ref: actions }
@@ -157,5 +163,5 @@ outputs:
   context: "{{context}}"
   created: "{{created}}"
   spec_exists: "{{spec_exists}}"
-  note: "Active feature set in .appweaver/feature.json — the aggregate boundary for its single spec.md + backend-plan.md. `context` names the bounded context it was created in, and is empty on a repo with no active context (the flat specs/<Feature> layout, which keeps working unchanged)."
+  note: "Active feature set in .appweaver/feature.json — the capability scope that owns its single spec.md + backend-plan.md. `context` names the bounded context it was created in, and is empty on a repo with no active context (the flat specs/<Feature> layout, which keeps working unchanged)."
   next: "/appweaver specify <what this feature does>   (authors {{feature_dir}}/spec.md; each operation = a user story)"

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

@@ -14,8 +14,13 @@
 # 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 → ask source path → lane-declare
-#   stack-list --suggest frontend → select stack → ask source path → lane-declare
+#   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
+#
+# 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
+# for the chosen stack alone.
 #
 # (none) IS A REAL ANSWER FOR EITHER LANE, and it is how a project says "I do not
 # have one of these". A backend-only project answers (none) to the UI lane; a
@@ -56,7 +61,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.
-version: 2.0.0
+version: 2.3.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
@@ -93,9 +98,7 @@ workflow:
       - { name: api_options,       from: "$.select_options" }
       - { name: api_ids,           from: "$.ids" }
       - { name: api_preselect,     from: "$.preselect" }
-      - { name: api_root_options,  from: "$.root_options" }
-      - { name: api_detected,      from: "$.detected_profile" }
-      - { name: api_detected_root, from: "$.detected_root" }
+      - { name: api_detected,      from: "$.detected_summary" }
       - { name: api_none_sentinel, from: "$.none_sentinel" }
 
   # 2. No profiles installed is a setup error, not an empty menu. Gated on the
@@ -114,7 +117,7 @@ workflow:
   #    does a detected stack; a project with exactly one candidate auto-confirms.
   - id: select_api_stack
     action: user_select
-    prompt: "Select the API (backend) stack — it owns the service lane. This repo's own files point at: {{api_detected}} (leading the list). (none) declares a project with no service lane at all, and stops the technical constitution half and the service rule files being authored:"
+    prompt: "Select the API (backend) stack — it owns the service lane. This repo's own files point at: {{api_detected}}. A detected stack leads the list. (none) declares a project with no service lane at all, and stops the technical constitution half and the service rule files being authored:"
     options_from_variable: api_options
     preselect_from: api_preselect
     single_option_confirm: true
@@ -133,14 +136,24 @@ workflow:
     condition: "{{chosen_api}} == {{api_none_sentinel}}"
     vars: { api_selected: "" }
 
-  # 5. WHERE the service lane's source lives. Offered best-first — where the
-  #    evidence actually sits, then each profile's own default — 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 offered and is stripped on the way in.
+  # 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
+  #    offered and is stripped on the way in.
+  - id: list_api_roots
+    action: execute_script
+    condition: "{{api_selected}}"
+    script: { ref: actions }
+    subcommand: stack-list
+    args: ["--kind", "backend", "--suggest", "--profile", "{{chosen_api}}"]
+    outputs:
+      - { name: api_root_options, from: "$.root_options" }
+
   - id: ask_api_source_path
     action: ask
     condition: "{{api_selected}}"
-    prompt: "Service lane SOURCE PATH — the subtree this lane owns, the only place implement may write, and the directory build/test/run act on. Pick one or type your own:"
+    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:"
     options_from_variable: api_root_options
     answer_var: api_source_path
 
@@ -159,6 +172,7 @@ workflow:
       - { name: api_lane_id,     from: "$.lane_id" }
       - { name: api_profile,     from: "$.profile" }
       - { name: api_root,        from: "$.source_path" }
+      - { name: api_test_path,   from: "$.test_path" }
       - { name: api_root_exists, from: "$.root_exists" }
 
   # ═══════════════ UI LANE ════════════════════════════════════════════════════
@@ -176,15 +190,13 @@ workflow:
       - { name: ui_options,       from: "$.select_options" }
       - { name: ui_ids,           from: "$.ids" }
       - { name: ui_preselect,     from: "$.preselect" }
-      - { name: ui_root_options,  from: "$.root_options" }
-      - { name: ui_detected,      from: "$.detected_profile" }
-      - { name: ui_detected_root, from: "$.detected_root" }
+      - { name: ui_detected,      from: "$.detected_summary" }
       - { name: ui_none_sentinel, from: "$.none_sentinel" }
 
   # 8. Choose the UI stack.
   - id: select_ui_stack
     action: user_select
-    prompt: "Select the UI (frontend) stack — it owns the web lane, and its root must not overlap the service lane's. This repo's own files point at: {{ui_detected}} (leading the list). (none) declares a backend-only project, and stops the UI constitution half and the frontend rule files being authored:"
+    prompt: "Select the UI (frontend) stack — it owns the web lane, and its root must not overlap the service lane's. This repo's own files point at: {{ui_detected}}. A detected stack leads the list. (none) declares a backend-only project, and stops the UI constitution half and the frontend rule files being authored:"
     options_from_variable: ui_options
     preselect_from: ui_preselect
     single_option_confirm: true
@@ -199,7 +211,16 @@ workflow:
     condition: "{{chosen_ui}} == {{ui_none_sentinel}}"
     vars: { ui_selected: "" }
 
-  # 9. WHERE the UI lane's source lives.
+  # 9. WHERE the UI lane's source lives, offered for the chosen UI stack.
+  - id: list_ui_roots
+    action: execute_script
+    condition: "{{ui_selected}}"
+    script: { ref: actions }
+    subcommand: stack-list
+    args: ["--kind", "frontend", "--suggest", "--profile", "{{chosen_ui}}"]
+    outputs:
+      - { name: ui_root_options, from: "$.root_options" }
+
   - id: ask_ui_source_path
     action: ask
     condition: "{{ui_selected}}"
@@ -217,6 +238,7 @@ workflow:
       - { name: ui_lane_id,     from: "$.lane_id" }
       - { name: ui_profile,     from: "$.profile" }
       - { name: ui_root,        from: "$.source_path" }
+      - { name: ui_test_path,   from: "$.test_path" }
       - { name: ui_root_exists, from: "$.root_exists" }
 
   # ═══════════════ CHECK + REPORT ═════════════════════════════════════════════
@@ -257,7 +279,7 @@ workflow:
   - id: api_summary_lane
     action: set
     condition: "{{api_declared}}"
-    vars: { api_summary: "{{api_lane_id}} ({{api_profile}}) at {{api_root}} — source path exists: {{api_root_exists}}" }
+    vars: { api_summary: "{{api_lane_id}} ({{api_profile}}) at {{api_root}}, tests at {{api_test_path}} — source path exists: {{api_root_exists}}" }
 
   - id: ui_summary_none
     action: set
@@ -265,7 +287,7 @@ workflow:
   - id: ui_summary_lane
     action: set
     condition: "{{ui_declared}}"
-    vars: { ui_summary: "{{ui_lane_id}} ({{ui_profile}}) at {{ui_root}} — source path exists: {{ui_root_exists}}" }
+    vars: { ui_summary: "{{ui_lane_id}} ({{ui_profile}}) at {{ui_root}}, tests at {{ui_test_path}} — source path 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.
@@ -287,10 +309,12 @@ outputs:
   ui_lane: "{{ui_summary}}"
   api_source_path: "{{api_root}}"
   ui_source_path: "{{ui_root}}"
+  api_test_path: "{{api_test_path}}"
+  ui_test_path: "{{ui_test_path}}"
   api_source_path_exists: "{{be_root_exists}}"
   ui_source_path_exists: "{{fe_root_exists}}"
-  api_detected: "{{api_detected}} at {{api_detected_root}}"
-  ui_detected: "{{ui_detected}} at {{ui_detected_root}}"
+  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 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 — overlapping paths 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 — empty 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 select-domain → constitution → select-feature → specify. BROWNFIELD: /appweaver onboard — it reverse-engineers out of the source paths declared here and generates the project (no select-domain; onboard derives and activates it from the code). Run this workflow FIRST in either sequence: constitution reads the declaration to decide which halves to author, and onboard reads it to decide what to scan."
+  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 onboard — it reverse-engineers out of the source paths declared here and generates the project (no select-domain; onboard derives and activates 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 onboard reads it to decide what to scan."

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

@@ -1,8 +1,9 @@
 # =============================================================================
 # aw-spec-specify (orchestrator) — author the SPEC for the ACTIVE feature
 #
-# Spec-anchored pipeline, spec phase. feature = AGGREGATE (picked/created by
-# /appweaver select-feature, which sets .appweaver/feature.json). specify does
+# Spec-anchored pipeline, spec phase. The feature is a capability scope the developer
+# picked/created with /appweaver select-feature (.appweaver/feature.json); it may act on
+# several aggregates, and several features may act on one. specify does
 # NOT guess or create the feature — it CONSUMES the active one, and is phase-pure
 # (spec side only; the single backend-plan.md is the `design` phase).
 #
@@ -163,7 +164,7 @@ workflow:
     action: verify_context
     require_non_empty: feature_dir
     on_empty: stop
-    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the aggregate, e.g. Order), then re-run specify."
+    on_empty_message: "No active feature. Run /appweaver select-feature first (pick or create the feature, e.g. Order or PatientRegistration), then re-run specify."
 
   # 1b. Resolve the BOUNDED CONTEXT's domain model — the canonical home of the aggregate
   #     root, its entities and its invariants, which this spec references and never
@@ -325,13 +326,17 @@ workflow:
     action: agent_author
     output_target: { type: file, path: "{{spec_file}}" }
     task: |
-      Author the MASTER specification for this aggregate by filling out the
+      Author the MASTER specification for the feature `{{feature}}` by filling out the
       template in context. This is the first user story, US-1. Base everything on:
 
       {{USER_INPUT}}
 
       Rules for the content you generate:
-      - The feature IS the aggregate slice; set the Aggregate field and keep US-1's id.
+      - The feature is a CAPABILITY SCOPE the developer chose; set the Feature field to
+        `{{feature}}` and keep US-1's id. It may act on several aggregates, and other
+        features may act on the same ones: name every aggregate its requirements act on
+        in the Domain Model Reference's `**Acts on aggregate(s)**:` line, each in
+        backticks — every later command finds this feature's part of the model there.
       - Preserve the template's section order and headings.
       - SPECIFY IS THE ONLY PHASE THAT READS THE DOMAIN RULES. Design and implement
         work from the spec + the domain model, never the domain docs — so this pair is
@@ -436,11 +441,14 @@ workflow:
         section per root: its boundary (owns / references by id / out of scope), entities,
         value objects, domain events, and its invariants as stable BR-nnn ids. The spec
         cites those ids; this document defines them.
-      - IF THE MODEL ALREADY HAS CONTENT, this is the context's SECOND (or later) feature.
-        ADD this feature's aggregate as a new section and EXTEND the ubiquitous language.
-        Do NOT rewrite, renumber or "tidy" the aggregates already there — other specs cite
-        their ids, and a renumbered BR breaks every citation silently. Add `{{feature}}` to
-        the `Serving specs` line of any existing aggregate this feature also acts on.
+      - IF THE MODEL ALREADY HAS CONTENT, this is the context's SECOND (or later) feature,
+        and the aggregates it acts on may already be there. An aggregate that already has
+        a section is EXTENDED in place — add what this feature's requirements need, and add
+        `{{feature}}` to its `Serving specs` line — never duplicated, and never given a
+        second section named after the feature. Only an aggregate the model does not have
+        yet gets a new section. EXTEND the ubiquitous language. Do NOT rewrite, renumber
+        or "tidy" what is already there — other specs cite those ids, and a renumbered BR
+        breaks every citation silently.
       - DDD IS THE RATIFIED MODELLING STANDARD (NON-NEGOTIABLE → the modelling-methodology
         standard in the sticky standards, wired per-project via tech-rule-bindings
         "## /aw-spec-specify", plus the domain's own DDD overlay): a consistent ubiquitous
@@ -662,5 +670,5 @@ outputs:
   authored_document: "{{quality_target}}"   # spec.md (bootstrap) | delta-spec.md (delta)
   checklist_file: "{{checklist_file}}"
   checklist_quality: "{{checklist_passed}}/{{checklist_total}} items passing"
-  note: "Behaviour and structure were authored together: the spec says what the system must do, {{domain_model}} says what the domain IS. The aggregate root, its entities and its invariants (BR-n) live in the model and are cited from the spec by id — never restated there, because several specs act on one aggregate and a per-spec copy drifts. On the DELTA path neither master was touched: this run wrote changes/{{cr_id}}/delta-spec.md and {{delta_model}}, and that model delta sits BESIDE the master where every other open delta can see it while being authored. WAVE {{wave}} is its parallel-development level — deltas sharing a wave are independent, a higher wave is implemented only after the lower ones land; `cr-wave --cr-id {{cr_id}} --wave <n>` moves it. {{open_count}} change(s) are open on this feature."
+  note: "Behaviour and structure were authored together: the spec says what the system must do, {{domain_model}} says what the domain IS. The aggregate root, its entities and its invariants (BR-n) live in the model and are cited from the spec by id — never restated there, because several specs act on one aggregate and a per-spec copy drifts. On the DELTA path neither master was touched: this run wrote changes/{{cr_id}}/delta-spec.md and {{delta_model}}, and that model delta sits BESIDE the master where every other open delta can see it while being authored. WAVE {{wave}} is its parallel-development level — deltas sharing a wave are independent, a higher wave is implemented only after the lower ones land. The wave is DERIVED from the model delta's `## Depends on`: one above the highest delta named there, stamped into both halves as soon as it was authored ({{wave_message}}). To move it, correct that section and re-run `.appweaver/scripts/bash/aw-spec-actions.sh cr-wave-derive --cr-id {{cr_id}} --stamp`; finalize-delta refuses a change whose wave contradicts it. {{open_count}} change(s) are open on this feature."
   next: "/appweaver plan — BOOTSTRAP authors backend-plan.md from the spec + the domain model; a DELTA (this run opened change {{cr_id}}, wave {{wave}}) authors the delta plans for it. A change then flows: analyze-plan-delta → implement → build → analyze-slice-delta → finalize-delta → analyze-slice → close-delta (finalize-delta merges the delta into spec.md + domain-model.md — not the lane plans, which are derived from those two — but leaves the change open; analyze-slice verifies the slice against the merged master; close-delta archives the change and bumps the version). ⚠️ With more than one change open, plan, analyze-plan-delta and implement ASK which one they are for (pass the id as the argument to skip the prompt) and activate the answer; finalize-delta and close-delta still act on whichever change is active — so finish or close the others deliberately."

package/assets/.appweaver/scripts/bash/aw-inventory.sh

@@ -11,6 +11,21 @@
 #                            [--service-root <p>] [--ui-root <p>]   (the declared lane paths:
 #                            backend signals come from outside the UI subtree, frontend
 #                            signals from inside it, so neither carries the other's files)
+#   aw-inventory.sh propose  [--root <dir>] [--service-root <p>] [--ui-root <p>]
+#                            [--strategy structure|reference|persistence] [--out <md>] [--map <json>]
+#                            (Pass A+B+C: writes the editable specs/proposed-inventory.md
+#                            and the machine map onboard reads)
+#   aw-inventory.sh apply    [--root <dir>] [--proposal <md>] [--map <json>]
+#                            (validates the operator's edits to the proposal and
+#                            regenerates the machine map; reports the row it cannot resolve)
+#   aw-inventory.sh scaffold-context --context <Name> [--root <dir>] [--map <json>]
+#                            (creates specs/<Context>/<Feature>/ for every feature the map
+#                            assigns to that context — directories only, no documents)
+#   aw-inventory.sh concept  --bundle <dir> --aggregate <Name>
+#   aw-inventory.sh list-aggregates --bundle <dir> [--context <Name>] [--root <dir>] [--map <json>]
+#                            (--context drops concepts stamped with a DIFFERENT bounded
+#                            context; unstamped concepts are always kept. `pickable` offers
+#                            each concept as the features the map puts on it)
 #   aw-inventory.sh validate --bundle <dir> [--repo-root <dir>]
 set -euo pipefail
 DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"