aw-spec-cli 0.1.19 → 0.1.20

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-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

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)"

package/assets/.appweaver/scripts/bash/aw-spec-actions.sh

@@ -42,7 +42,7 @@
 #                     Always exits 0 — the workflow's verify_context owns the stop)
 #   lane-probe       [--kind <k>] [--hint <text>]  -> {declared, declared_profile, hint_profile, hint_terms[], signals[], any, evidence}
 #                    (the FILE signals for "does this lane exist"; resolve-tech carries the rule signal)
-#   list-features    [--preselect <name>] [--bundle <dir>]  -> {features[], names[], count, select_options[], sentinel}   (specs/ ∪ OKF aggregates)
+#   list-features    [--preselect <name>] [--bundle <dir>]  -> {features[], names[], count, select_options[], sentinel}   (specs/ ∪ features the OKF concepts serve)
 #   set-feature      --feature <name>              -> {feature, feature_dir, spec_file, existed, created, spec_exists}
 #   version-read     [--feature-dir <path>]        -> {feature, version, active_change, exists, bootstrap_pending}
 #   version-init     [--feature-dir <path>] [--bootstrap]  -> {…, created, bootstrap_pending}   (create active_version.json v1.0; --bootstrap marks a FIRST draft in progress)
@@ -1206,6 +1206,10 @@ cmd_model_scaffold() {
 #      reverse-engineers (the discovered aggregates NOT yet under specs/). This is
 #      why select-feature can offer real code features in a brownfield repo before
 #      anything is adopted, instead of an empty specs/ list.
+# BOTH sources are scoped to the ACTIVE BOUNDED CONTEXT: source 1 by enumerating the
+# context's own directory, source 2 by the `bounded_context:` key onboard stamps on
+# every concept it writes. onboard runs once per context, so an unfiltered bundle
+# offers a neighbouring context's features to a picker that would scaffold them here.
 # On greenfield (no bundle) source 2 is empty → identical to the old specs-only
 # behaviour. `select_options` = merged names + (an injected --preselect that is not
 # yet a feature) + a "create new" sentinel, so select-feature can offer add-new and
@@ -1223,16 +1227,24 @@ cmd_list_features() {
     local repo_root; repo_root=$(get_repo_root)
     [ -n "$bundle" ] || bundle="knowledge"
     case "$bundle" in /*) ;; *) bundle="$repo_root/$bundle" ;; esac
-    # Best-effort OKF aggregate list from the shared python core (single source of
-    # truth for OKF parsing; the ps1 twin calls the SAME script). Empty on greenfield.
-    local okf_json="{}" invpy="$SCRIPT_DIR/../python/aw-inventory.py"
-    if [ -d "$bundle" ] && [ -f "$invpy" ] && command -v python3 >/dev/null 2>&1; then
-        okf_json=$(python3 "$invpy" list-aggregates --bundle "$bundle" 2>/dev/null) || okf_json="{}"
-    fi
     # Features are enumerated from the ACTIVE BOUNDED CONTEXT's directory when one is
     # set, and from specs/ itself when none is — so a context scopes the picker to its
     # own features and a pre-context repo lists exactly what it always did.
     local base_rel; base_rel=$(feature_base_rel "$repo_root")
+    # The OKF half is scoped the same way. onboard runs once per bounded context and
+    # stamps each concept it writes, so a bundle that has seen two runs holds two
+    # contexts' aggregates; unfiltered, standing inside one context would offer the
+    # other's features and scaffold them into the wrong tree. Empty when no context is
+    # active, which keeps the flat layout listing everything.
+    local active_ctx=""
+    [ "$base_rel" != "specs" ] && active_ctx="${base_rel##*/}"
+    # Best-effort OKF aggregate list from the shared python core (single source of
+    # truth for OKF parsing AND for the context filter; the ps1 twin calls the SAME
+    # script with the same argument). Empty on greenfield.
+    local okf_json="{}" invpy="$SCRIPT_DIR/../python/aw-inventory.py"
+    if [ -d "$bundle" ] && [ -f "$invpy" ] && command -v python3 >/dev/null 2>&1; then
+        okf_json=$(python3 "$invpy" list-aggregates --bundle "$bundle" --root "$repo_root" --context "$active_ctx" 2>/dev/null) || okf_json="{}"
+    fi
     AW_SPECS="$repo_root/$base_rel" AW_BASE_REL="$base_rel" AW_PRESELECT="$preselect" AW_OKF="$okf_json" python3 - <<'PY'
 import json, os, glob
 base = os.environ["AW_SPECS"]
@@ -1293,9 +1305,13 @@ if os.path.isdir(base):
             "version": ver,
             "active_change": active_change,
         })
-# Merge OKF-discovered aggregates NOT already scaffolded under specs/ (a specs/
-# folder is the adopted/created form of the same aggregate — it wins, no dup).
-for agg in (okf.get("aggregates") or []):
+# Merge the OKF-discovered FEATURES not already scaffolded under specs/ (a specs/
+# folder is the adopted/created form of the same feature — it wins, no dup).
+# `pickable` is each aggregate concept offered as the features the map puts on it, so
+# an aggregate split into capabilities is never itself offered as a feature to pick.
+# An EMPTY `pickable` is an answer — nothing to offer, e.g. a greenfield bundle whose
+# features all have specs/ dirs — so only its absence falls back to the raw aggregates.
+for agg in (okf["pickable"] if "pickable" in okf else okf.get("aggregates") or []):
     nm = (agg.get("name") or "").strip()
     if not nm or nm.lower() in seen:
         continue
@@ -1328,26 +1344,26 @@ PY
 }
 
 # ─────────────────────────────── set-feature ───────────────────────────────
-# Create-or-select an aggregate under specs/ and persist it as the active feature
-# (.appweaver/feature.json). feature = aggregate: the name is normalized to a
-# PascalCase identifier (e.g. "order management" -> OrderManagement). Idempotent:
+# Create-or-select a feature under specs/ and persist it as the active feature
+# (.appweaver/feature.json). The name is the developer's capability scope, normalized to
+# a PascalCase identifier (e.g. "patient registration" -> PatientRegistration). Idempotent:
 # selecting an existing feature just re-points feature.json; a new one is created.
 cmd_set_feature() {
     local raw=""
     while [ $# -gt 0 ]; do
         case "$1" in
             --feature) raw="$2"; shift 2 ;;
-            --help|-h) echo "set-feature --feature <name>   (create-or-select the aggregate under specs/)"; return 0 ;;
+            --help|-h) echo "set-feature --feature <name>   (create-or-select the feature under specs/)"; return 0 ;;
             *) echo "set-feature: unknown arg '$1'" >&2; return 1 ;;
         esac
     done
     [ -n "$raw" ] || { echo "set-feature: --feature is required" >&2; return 1; }
 
-    # Normalize to a PascalCase aggregate identifier (feature = aggregate).
+    # Normalize to a PascalCase identifier.
     local cleaned; cleaned=$(echo "$raw" | sed -E 's/[^A-Za-z0-9]+/ /g; s/^ +| +$//g')
     local feature; feature=$(_pascal "$cleaned")
     if ! [[ "$feature" =~ ^[A-Za-z][A-Za-z0-9]*$ ]]; then
-        echo "set-feature: '$raw' is not a valid feature name (need a letter-led alphanumeric aggregate, e.g. Order)" >&2
+        echo "set-feature: '$raw' is not a valid feature name (need a letter-led alphanumeric name, e.g. Order or PatientRegistration)" >&2
         return 1
     fi
 

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

@@ -10,6 +10,9 @@
 #   aw-xref.sh concept-upsert   --aggregate X [--source-files a,b,c] [--description D] [--origin ...] [--root DIR]
 #   aw-xref.sh concept-overview --aggregate X (--text PROSE | --text-file F) [--root DIR]
 #   aw-xref.sh concept-paths    --aggregate X | --feature-dir <dir> [--root DIR] [--bundle knowledge]
+#   aw-xref.sh feature-aggregates --feature-dir <dir> [--root DIR]
+#                               (the aggregate(s) a feature acts on: its spec's Acts-on line,
+#                               then the boundary map, then the feature name itself)
 set -euo pipefail
 DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
 exec python3 "$DIR/../python/aw-xref.py" "$@"

package/assets/.appweaver/scripts/powershell/aw-inventory.ps1

@@ -10,6 +10,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.ps1 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.ps1 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.ps1 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.ps1 concept  --bundle <dir> --aggregate <Name>
+#   aw-inventory.ps1 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.ps1 validate --bundle <dir> [--repo-root <dir>]
 $ErrorActionPreference = "Stop"
 $core = Join-Path $PSScriptRoot "..\python\aw-inventory.py"

package/assets/.appweaver/scripts/powershell/aw-spec-actions.ps1

@@ -684,6 +684,8 @@ function Invoke-LaneProbe {
 # (case-insensitive) — (1) specs/ sub-folders (already scaffolded/adopted) and
 # (2) the OKF bundle's Aggregate concepts (the brownfield feature map, resolved by
 # the SAME shared python core the bash twin calls). Empty source 2 on greenfield.
+# Both are scoped to the ACTIVE BOUNDED CONTEXT — source 1 by the directory listed,
+# source 2 by the `bounded_context:` key onboard stamps on every concept it writes.
 # ─────────────────────── context.json (bounded context) ───────────────────
 # Twin of the bash read_context_json_context_directory / feature_base_rel pair. A
 # bounded context is the container a feature lives in — specs/<Context>/<Feature>/ —
@@ -861,13 +863,31 @@ function Invoke-ListFeatures {
     if (-not $bundle) { $bundle = 'knowledge' }
     if (-not [System.IO.Path]::IsPathRooted($bundle)) { $bundle = Join-Path $repo $bundle }
 
+    # The OKF half is scoped to the active bounded context the same way. onboard runs
+    # once per context and stamps each concept it writes, so a bundle that has seen two
+    # runs holds two contexts' aggregates; unfiltered, standing inside one context would
+    # offer the other's features and scaffold them into the wrong tree. Empty when no
+    # context is active, which keeps the flat layout listing everything.
+    $activeCtx = ''
+    if ($baseRel -ne 'specs') { $activeCtx = ($baseRel -split '/')[-1] }
+
     # Best-effort OKF aggregate list (brownfield feature map). Empty on greenfield.
     $okfAggs = @()
     $py = Get-Py; $invpy = Join-Path $PSScriptRoot '..' 'python' 'aw-inventory.py'
     if ($py -and (Test-Path $bundle) -and (Test-Path $invpy)) {
         try {
-            $okfRaw = & $py $invpy list-aggregates --bundle $bundle 2>$null
-            if ($okfRaw) { $okfAggs = @((($okfRaw | ConvertFrom-Json).aggregates)) }
+            # --context only when one is active: Windows PowerShell drops an empty-string
+            # argument to a native command, which would leave --context with no value.
+            $ctxArgs = @(); if ($activeCtx) { $ctxArgs = @('--context', $activeCtx) }
+            $okfRaw = & $py $invpy list-aggregates --bundle $bundle --root $repo @ctxArgs 2>$null
+            if ($okfRaw) {
+                # The FEATURES the map puts on each concept, not the aggregates themselves —
+                # the same list the bash twin reads.
+                $okfJson = $okfRaw | ConvertFrom-Json
+                # An EMPTY `pickable` is an answer (nothing to offer); only its absence
+                # falls back to the raw aggregates.
+                $okfAggs = if ($okfJson.PSObject.Properties.Name -contains 'pickable') { @($okfJson.pickable) } else { @($okfJson.aggregates) }
+            }
         } catch { $okfAggs = @() }
     }
 
@@ -901,7 +921,7 @@ function Invoke-ListFeatures {
             }
         }
     }
-    # Merge OKF-discovered aggregates not already scaffolded under specs/.
+    # Merge the OKF-discovered FEATURES not already scaffolded under specs/.
     foreach ($agg in $okfAggs) {
         $nm = "$($agg.name)".Trim()
         if (-not $nm -or $seen.ContainsKey($nm.ToLower())) { continue }
@@ -944,11 +964,11 @@ function Invoke-SetFeature {
     }
     if (-not $raw) { Write-Error 'set-feature: --feature is required'; exit 1 }
 
-    # Normalize to a PascalCase aggregate identifier (feature = aggregate).
+    # Normalize to a PascalCase identifier.
     $cleaned = ($raw -replace '[^A-Za-z0-9]+', ' ').Trim()
     $feature = ConvertTo-Pascal -In $cleaned
     if ($feature -notmatch '^[A-Za-z][A-Za-z0-9]*$') {
-        Write-Error "set-feature: '$raw' is not a valid feature name (need a letter-led alphanumeric aggregate, e.g. Order)"; exit 1
+        Write-Error "set-feature: '$raw' is not a valid feature name (need a letter-led alphanumeric name, e.g. Order or PatientRegistration)"; exit 1
     }
 
     $repo = Get-RepoRoot

package/assets/.appweaver/scripts/powershell/aw-xref.ps1

@@ -9,6 +9,9 @@
 #   aw-xref.ps1 concept-upsert   --aggregate X [--source-files a,b,c] [--description D] [--origin ...] [--root DIR]
 #   aw-xref.ps1 concept-overview --aggregate X (--text PROSE | --text-file F) [--root DIR]
 #   aw-xref.ps1 concept-paths    --aggregate X | --feature-dir <dir> [--root DIR] [--bundle knowledge]
+#   aw-xref.ps1 feature-aggregates --feature-dir <dir> [--root DIR]
+#                                (the aggregate(s) a feature acts on: its spec's Acts-on line,
+#                                then the boundary map, then the feature name itself)
 $ErrorActionPreference = "Stop"
 $core = Join-Path $PSScriptRoot "..\python\aw-xref.py"
 & python3 $core @args