aw-spec-cli 0.1.19 → 0.1.21

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

@@ -2,27 +2,40 @@
 # aw-spec-onboard (orchestrator) — the entry step of the Brownfield DEVELOPMENT flow
 #
 # Onboard an EXISTING codebase into aw-spec so it can be DEVELOPED (evolved, not
-# migrated) governed exactly like greenfield and as lightly as OpenSpec. Runs ONCE
-# per repo, over the WHOLE codebase (project-level, not per-slice). It does two
-# things, both from a single deterministic whole-repo scan — no slice is adopted yet:
+# migrated) governed exactly like greenfield and as lightly as OpenSpec. Runs ONCE PER
+# BOUNDED CONTEXT, against the boundaries /appweaver inventory proposed and the
+# operator confirmed. No slice is adopted yet; each run does three things:
 #
-#   1. FEATURE MAP — a HIGH-LEVEL OKF discovery index of the features/aggregates the
-#      code contains (folders/concepts + a bounded-context map + the tech stack). It
-#      is a shallow map to pick from, NOT a deep reverse — the deep per-feature
-#      reverse (spec.md + the context's domain-model.md + the lane plans) is
-#      /appweaver adopt, done just-in-time when you are about to develop that feature.
+#   1. FEATURE MAP — a HIGH-LEVEL OKF discovery index of THIS CONTEXT's aggregates —
+#      ONE concept per aggregate, listing the features that act on it — plus the tech
+#      stack, added beside whatever earlier contexts already wrote. The bundle is the
+#      PROJECT's knowledge: a concept is an aggregate, never a feature. It is a shallow map to pick from, NOT a deep reverse — the deep
+#      per-feature reverse (spec.md + the context's domain-model.md + the lane plans)
+#      is /appweaver adopt, done just-in-time when you are about to develop that
+#      feature.
 #
-#   2. GOVERNANCE SCAFFOLD — the PROJECT-level governing tier, established once from
-#      the whole-repo vantage so forward development is consistent from the first
-#      change: the split constitution (technical + domain), the guardrails/projects/
-#      brf-<domain>/domain/ rule-file set (+ domain-rule-bindings), the domain charter
-#      that set is headed by, and the activated domain. Because nothing is adopted yet, this tier is
-#      a PROVISIONAL scaffold evidenced by the SCAN (project identity + bounded-context
-#      map are firm; principles/rules are marked provisional). adopt then RECONCILES
-#      each with the slice's own evidence (BR-/CN-/DC-/IC- ids) when that feature is
-#      developed — the "created here, updated when taking each slice" contract.
+#   2. THE CONTEXT'S SPECS TREE — specs/<Context>/ with an EMPTY directory per feature,
+#      and the context made active in .appweaver/context.json. This is what makes the
+#      context real to the commands that read the tree rather than the bundle:
+#      select-bounded-context lists it, select-feature offers exactly its features, and
+#      adopt has somewhere to write. No spec.md and no domain-model.md — a placeholder
+#      for either reads as "the document exists" to every gate downstream.
 #
-#   ONBOARD  →  adopt <Feature> (JIT)  →  specify → plan → analyze-plan-delta → implement → build → analyze-slice-delta → finalize-delta → analyze-slice → close-delta   ← you are here
+#   3. GOVERNANCE SCAFFOLD — the PROJECT-level governing tier: the split constitution
+#      (technical + domain), the guardrails/projects/brf-<domain>/domain/ rule-file set
+#      (+ domain-rule-bindings), the domain charter that set is headed by, and the
+#      activated domain. AUTHORED BY THE FIRST CONTEXT TO ONBOARD AND BY NO OTHER —
+#      re-deriving project principles from one context's evidence is the aggregate-
+#      scoping bias this tier exists to avoid, so every later run skips the whole block
+#      and contributes its own concepts and specs tree instead. Because nothing is
+#      adopted yet, the tier is a PROVISIONAL scaffold evidenced by the SCAN (project
+#      identity + bounded-context map are firm; principles/rules are marked
+#      provisional); /appweaver constitution is what amends it.
+#
+#   inventory → [edit specs/proposed-inventory.md] → inventory apply
+#     → ONBOARD <Context>  (once per context)   ← you are here
+#     → adopt <Feature> (JIT) → specify → plan → analyze-plan-delta → implement → build
+#       → analyze-slice-delta → finalize-delta → analyze-slice → close-delta
 #
 # Establishing the PROJECT-scoped constitution here (whole-repo vantage) — not from a
 # single adopted slice — is deliberate: it keeps governance project-scoped from day
@@ -112,32 +125,32 @@
 # pass was re-deriving an answer the run already had. `lane-declare` has one caller again
 # — select-stack — and this workflow only reads.
 #
-# Never modifies source — every write lands in the OKF bundle, the specs governance dir,
-# guardrails/projects/ (domain/ + service/ + frontend/ rule sets + both maps), or the
-# .appweaver/templates/overrides/ design templates.
+# Never modifies source — every write lands in the OKF bundle, the context's specs/
+# directories, guardrails/projects/ (domain/ + service/ + frontend/ rule sets + both
+# maps), or the .appweaver/templates/overrides/ design templates.
 #
-# Launch:  /appweaver onboard [domain-name / scope hint] [; concerns: a, b, c]
-#   e.g.   /appweaver onboard Pharma
-#   e.g.   /appweaver onboard "Pharma; concerns: auditing, concurrency, authorization"
+# Launch:  /appweaver onboard [<BoundedContext>] [; concerns: a, b, c]
+#   e.g.   /appweaver onboard Clinical
+#   e.g.   /appweaver onboard                       # the next context the map has open
+#   e.g.   /appweaver onboard "Clinical; concerns: auditing, concurrency, authorization"
 # =============================================================================
 
 name: aw-spec-onboard
 description: Onboard an existing codebase for brownfield DEVELOPMENT — a deterministic whole-repo scan produces a high-level OKF feature map (folders/concepts) PLUS the project-level governance scaffold (split constitution + guardrails/projects/brf-<domain>/ with its DOMAIN rule files at domain/ + domain-rule-bindings + code-derived TECHNICAL rule files at service/ + tech-rule-bindings + activated domain), all provisional-from-scan and refined per slice by adopt. Where the scan finds a frontend lane in the CODE, it also authors that lane's half — constitution.ui.md (UX-*) — and its code-derived rule files at brf-<domain>/frontend/, mapped under `## /aw-spec-ui-constitution`; a backend-only repo gets none of it. Every rule tier is reverse-engineered from the CODE alone (never a greenfield rule file), evidenced-only, and WIRED per-workflow so the whole forward pipeline AND adopt govern against THIS codebase — never a greenfield fallback. It also reverse-engineers the repo's own technical structure into a project-specific design + delta-design template pair, installed as the project template overrides, and — where the lane exists — the frontend lane's own pair from the UI source. Every authoring step is shaped by a NEUTRAL rev-templates skeleton; no greenfield constitution, rule file or document template is ever placed in context. Accepts an optional concerns list to look for (onboard decides which are actually present). Reads any declared lane, never writes one. No migration content; never modifies source.
-version: 1.7.0
+version: 2.1.0
 agent_agnostic: true
 dialect: aw-spec.orchestrator/v1
 
 inputs:
   user_input:
     description: >-
-      Optional free-text hint. May carry (a) a domain name for the governance project
-      (e.g. Pharma → guardrails/projects/brf-pharma/); (b) a scope/focus hint for the
-      feature map; and/or (c) a CONCERNS LIST to look for, as a "concerns: a, b, c"
-      clause (e.g. "Pharma; concerns: auditing, concurrency, authorization"). The
-      concerns are a SEARCH HINT only — both rule-set authors still DECIDE which
+      The BOUNDED CONTEXT to onboard, as named in the feature map that
+      /appweaver inventory produced (e.g. Billing). Onboard runs once per context;
+      with no argument it takes the first context in the map that is not yet
+      onboarded. May also carry a CONCERNS LIST to look for, as a
+      "concerns: a, b, c" clause (e.g. "Billing; concerns: auditing, concurrency").
+      The concerns are a SEARCH HINT only — the rule-set authors still DECIDE which
       concerns are actually present from the code, and are never limited to the list.
-      When omitted, the domain defaults to the PROJECT name from the OKF overview,
-      then the repo basename; concerns are auto-discovered from the code.
     required: false
     bind: USER_INPUT
 
@@ -164,6 +177,20 @@ vars:
   bundle_present: "false"   # inventory bundle_guard driver
   conformant:     "false"   # OKF conformance-gate driver
   pack_present:   "false"   # project anti-clobber driver
+  # The governance tier — constitution halves, rule packs, document templates —
+  # is PROJECT-scoped, authored by the first context to onboard and left alone by
+  # every context after it. Re-authoring project principles from one context's
+  # evidence is the scoping bias the rev-constitution work removed; this var is
+  # what keeps the second run from doing it.
+  repo_gov:       "false"   # true once the project governance exists
+  # The governance project is named from the PROJECT, never from the context.
+  # Passing the context name here would produce one rule pack per bounded
+  # context, which is the same bias by another route.
+  gov_name:       ""
+  context_known:  "false"
+  is_blocked:     "false"
+  in_cycle:       "false"
+  already_onboarded: "false"
   technical_ok:   "false"   # technical-half lint guard
   domain_ok:      "false"   # domain-half lint guard
   ui_ok:          "false"   # UI-half lint guard
@@ -281,14 +308,106 @@ workflow:
     on_false: stop
     on_false_message: "Scan found no candidate features in {{root}} (file_count={{file_count}}). Point /appweaver onboard at a codebase with a recognizable domain/vertical-slice layout, or scan a subtree that contains one."
 
-  # 1c. Curation guard (OKF rule): a bundle that already has concept files is
-  #     curation — regenerating from scratch would destroy it.
-  - id: bundle_guard
+  # 1c. WHICH BOUNDED CONTEXT, AND IS IT THIS ONE'S TURN. onboard runs once per
+  #     context, so before anything is written it reads the map inventory
+  #     produced and asks four questions: is this a context the map knows, what
+  #     does it hold, has it already been onboarded, and is everything it depends
+  #     on onboarded first.
+  #
+  #     This replaces the bundle-wide curation guard. That guard stopped whenever
+  #     the bundle held any concept at all, which is indistinguishable from
+  #     "context 1 has been onboarded" — so it made onboarding a second context
+  #     impossible. The curation it protects is still protected, per context:
+  #     a context whose concepts already exist is not regenerated.
+  - id: context_state
+    action: execute_script
+    script: { ref: inventory }
+    subcommand: context-state
+    args: ["--context", "{{USER_INPUT}}", "--bundle", "{{bundle_dir}}"]
+    on_error: continue
+    outputs:
+      - { name: map_present,        from: "$.map_present" }
+      - { name: context_known,      from: "$.context_known" }
+      - { name: bc,                 from: "$.context" }
+      - { name: bc_slug,            from: "$.context_slug" }
+      - { name: bc_features,        from: "$.features" }
+      - { name: bc_feature_count,   from: "$.feature_count" }
+      - { name: pending_features,   from: "$.pending_features" }
+      - { name: pending_count,      from: "$.pending_count" }
+      - { name: bc_aggregates,         from: "$.aggregates" }
+      - { name: bc_feature_aggregates, from: "$.feature_aggregates" }
+      - { name: pending_aggregates,    from: "$.pending_aggregates" }
+      - { name: already_onboarded,  from: "$.already_onboarded" }
+      - { name: is_blocked,         from: "$.is_blocked" }
+      - { name: blocked_by,         from: "$.blocked_by" }
+      - { name: in_cycle,           from: "$.in_cycle" }
+      - { name: cycle_with,         from: "$.cycle_with" }
+      - { name: is_first,           from: "$.is_first" }
+      - { name: onboarded_contexts, from: "$.onboarded_contexts" }
+      - { name: remaining_contexts, from: "$.remaining_contexts" }
+      - { name: contexts_ordered,   from: "$.contexts_ordered" }
+      - { name: feature_map,        from: "$.feature_map" }
+      - { name: map_error,          from: "$.error" }
+
+  # 1d. No map means the boundaries were never decided. Onboarding without them
+  #     is what produced a flat aggregate list with no context level at all.
+  - id: require_map
+    action: verify_context
+    require_value: map_present
+    equals: "true"
+    on_mismatch: stop
+    on_mismatch_message: >
+      No feature map was found. Onboard works one BOUNDED CONTEXT at a time and
+      reads the map /appweaver inventory produces. Run `/appweaver inventory`,
+      review and edit `specs/proposed-inventory.md` — it is the boundary map and
+      it is yours to change — then run `/appweaver inventory apply`.
+
+  - id: require_context
+    action: verify_context
+    require_value: context_known
+    equals: "true"
+    on_mismatch: stop
+    on_mismatch_message: "{{map_error}}"
+
+  # 1e. Per-context curation guard — the narrow form of the old bundle guard.
+  - id: context_done_guard
+    action: verify_context
+    require_value: already_onboarded
+    equals: "false"
+    on_mismatch: stop
+    on_mismatch_message: >
+      Bounded context {{bc}} is already onboarded — every aggregate its
+      {{bc_feature_count}} feature(s) act on ({{bc_aggregates}}) already has a concept in
+      {{bundle_dir}}, and re-running would overwrite that curation. Contexts still open: {{remaining_contexts}}
+
+  # 1f. Dependency order. A context whose dependencies are still open would be
+  #     modelled against aggregates that do not exist yet. A context inside a
+  #     CYCLE is released rather than blocked — each member is waiting on the
+  #     other, so blocking both deadlocks the sequence.
+  - id: context_order_gate
     action: verify_context
-    require_value: bundle_present
+    require_value: is_blocked
     equals: "false"
     on_mismatch: stop
-    on_mismatch_message: "The OKF feature-map bundle at {{bundle_dir}} already holds {{bundle_md_count}} concept file(s) — onboard would overwrite that curation. Back up or remove {{bundle_dir}} to re-onboard from scratch."
+    on_mismatch_message: >
+      Bounded context {{bc}} depends on a context that has not been onboarded yet:
+      {{blocked_by}}. Its features cite aggregates that will not exist until then, so
+      onboard in the order the map gives — {{contexts_ordered}} — or run
+      /appweaver onboard with no argument to take the next one automatically.
+      To change that order, edit the Depends On column in specs/proposed-inventory.md
+      and re-run /appweaver inventory apply.
+
+  - id: cycle_warning
+    action: verify_context
+    condition: "{{in_cycle}} == true"
+    require_value: in_cycle
+    equals: "never"
+    on_mismatch: continue
+    on_mismatch_message: >
+      NOTE: {{bc}} and {{cycle_with}} depend on each other. They cannot be ordered,
+      so {{bc}} is released rather than blocked — but the two share a seam, and the
+      aggregates each cites from the other will be incomplete until both are
+      onboarded. Break the cycle with a seam, or onboard the ring back to back.
 
   # 1d. FRONTEND LANE — the DECLARATION decides that it exists, and the CODE decides
   #     what its governance says. Those are two different questions and they used to be
@@ -389,6 +508,7 @@ workflow:
     action: build_context
     context:
       - { path: "{{inventory_json}}" }                        # the deterministic substrate (aggregate_signals etc.)
+      - { path: "{{feature_map}}" }                           # the CONFIRMED boundaries: which features belong to which bounded context, and in what order
       - { path: .appweaver/templates/okf-concept-template.md }  # OKF v0.1 format authority (frontmatter, index, log, rules) — format only, zero project content
   - id: author_bundle
     action: agent_generate
@@ -396,32 +516,55 @@ workflow:
     permission_mode: acceptEdits
     task: |
       Act as the OKF enrichment agent for the Brownfield DEVELOPMENT onboard step.
-      Produce a CONFORMANT OKF v0.1 knowledge bundle at {{bundle_dir}} that is a
-      HIGH-LEVEL FEATURE MAP — a discovery index of the features/aggregates this
-      codebase contains, organized BY AGGREGATE ROOT — from the deterministic
-      substrate {{inventory_json}} (in context). Follow the OKF concept template in
-      context for format (frontmatter, index.md/log.md rules, cross-linking, hard rules).
-      Domain/scope hint (optional): {{USER_INPUT}}
-
-      THIS IS A MAP, NOT A DEEP REVERSE. Keep every feature concept SHALLOW — enough
-      to recognize and pick the feature to develop next. The deep per-feature reverse
-      (spec.md + the context's domain-model.md + the lane plans) is /appweaver adopt, run
-      just-in-time when a feature is about to be developed. Do NOT deep-model
+      Extend the OKF v0.1 knowledge bundle at {{bundle_dir}} with the features of ONE
+      BOUNDED CONTEXT — a discovery index of what that context contains — from the
+      deterministic substrate {{inventory_json}} and the confirmed boundary map
+      {{feature_map}} (both in context). Follow the OKF concept template in context for
+      format (frontmatter, index.md/log.md rules, cross-linking, hard rules).
+
+      THE CONTEXT YOU ARE ONBOARDING IS `{{bc}}`.
+      Its features, already confirmed by the operator: {{bc_features}}
+      The aggregates those features act on: {{bc_aggregates}}
+      Which feature acts on which: {{bc_feature_aggregates}}
+      Aggregates still without a concept, to be written this run: {{pending_aggregates}}
+
+      THE BUNDLE IS THE PROJECT'S KNOWLEDGE, AND A CONCEPT IS AN AGGREGATE — NEVER A
+      FEATURE. Features are the specs tree's unit (this run creates their directories);
+      they are LISTED on their aggregate's concept and never given concepts of their own.
+      Several features can act on one aggregate — the map split it into capabilities —
+      and that aggregate still gets exactly one concept.
+
+      THE BOUNDARIES ARE DECIDED — DO NOT REDRAW THEM. The feature map is the output of
+      a scan the operator has already reviewed and edited by hand. Write one concept per
+      AGGREGATE the map names for this context, and no others. Do not merge two
+      aggregates, do not split one, do not invent an aggregate or a feature the map does
+      not list, and do not write a concept for an aggregate belonging to another bounded
+      context — those are onboarded by their own runs. Where the substrate's `aggregate_signals` disagree with the map,
+      THE MAP WINS; note the disagreement in `open_questions` on the concept.
+
+      THIS IS ADDITIVE. Other bounded contexts may already have concepts in this bundle.
+      Read the bundle before writing. Create the files this context needs, UPDATE the
+      shared index/log files in place, and NEVER delete, rewrite or re-scope a concept
+      belonging to another context. If a file you would create already exists, it belongs
+      to an earlier run — leave it alone.
+
+      THIS IS A MAP, NOT A DEEP REVERSE. Keep every concept SHALLOW — enough to
+      recognize the aggregate and pick a feature over it to develop next. Do NOT deep-model
       invariants/behaviour here.
 
-      Read the substrate first. Its `aggregate_signals` are CANDIDATE feature roots,
-      each with its files grouped by layer plus detected entities; `ui_attribution`
-      says which FRONTEND files serve which of those roots (and which serve none);
+      Read the substrate for EVIDENCE about the map's aggregates. Its `aggregate_signals`
+      carry each root's files grouped by layer plus detected entities; `ui_attribution`
+      says which FRONTEND files serve which root (and which serve none);
       `git.history.churn` ranks significance; the category lists and `top_level_dirs`
-      fill in the rest.
-      Signals are input, not decisions — YOU draw the real feature boundaries:
-      - Merge a src module and its mirror test module into ONE feature (e.g.
-        src/.../MedicinalProducts + tests/.../MedicinalProducts → MedicinalProduct).
+      fill in the rest. Where several features act on one aggregate (two seams on one
+      root), its ONE concept carries the whole module — domain and behaviour files alike
+      — and names each feature with the capability it covers. Which files serve which
+      capability is recorded per feature later, in the source-map adopt writes.
       - Treat service-level / shared infrastructure (a shared persistence context,
         cross-cutting adapters, host / service-defaults projects) as a Platform/Shared
         concept, NOT a feature.
       - Fold value objects, entities, domain events, commands and endpoints into the
-        feature that OWNS them — one feature concept, not one per type.
+        aggregate that OWNS them — one aggregate concept, not one per type.
       NAME EVERY CONCEPT IN THE CODE'S OWN VOCABULARY — read the identifiers the source
       actually uses. "Aggregate", "entity" and "value object" are how aw-spec ORGANIZES a
       feature map; they are not a claim that this codebase is modelled that way. Where the
@@ -429,9 +572,19 @@ workflow:
       grouping around it.
 
       Write the bundle (all paths under {{bundle_dir}}; bundle-relative links begin
-      with "/", per OKF §5.1):
+      with "/", per OKF §5.1).
+
+      IS THIS THE FIRST CONTEXT IN THIS BUNDLE? `{{is_first}}`
+      The three `architecture/` notes below describe the WHOLE repository, not one
+      context, so they are written ONCE — by the first context to onboard. When
+      `{{is_first}}` is false they already exist: do not rewrite them, and add to them
+      only where this context introduces a technology or integration point the note
+      genuinely lacks. Everything else below is written on every run, for this
+      context's features only.
+
       - `index.md` (bundle root) — frontmatter EXACTLY `okf_version: "0.1"` and nothing
         else; body = sections of bulleted links reusing each concept's `description`.
+        On a later context, ADD this context's entries and leave the rest in place.
       - `architecture/overview.md` (type: Reference) — the system at a glance. Its
         `## Purpose` section MUST open with the whole solution/product name in bold
         followed by "is a …" (e.g. "**Medicinal.Healthcare** is a …") — this bold token
@@ -464,11 +617,14 @@ workflow:
         unattributed` lists the files serving no single aggregate (app shell, layout,
         design system, global styles). Describe what they provide; they belong here
         precisely because no slice owns them.
-      - `aggregates/<feature>.md` (type: Aggregate) — ONE per feature root, SHALLOW:
+      - `aggregates/<aggregate>.md` (type: Aggregate) — ONE per aggregate, SHALLOW, its
+        `title:` EXACTLY the aggregate's name as the map spells it (`MedicinalProduct`,
+        never `Medicinal Product` — later commands find the concept by that name):
         Responsibilities; the entities / value objects / domain events / commands / API
         endpoints / persistence it OWNS (named at a glance from the signal's layer
-        files — a list, not a deep model); and the candidate `specs/<Feature>/` slice
-        name (feature = aggregate). Set `source_files` to the module's files, grouped
+        files — a list, not a deep model); and `features:` in frontmatter — the map's
+        features that act on it, each of which is a `specs/{{bc}}/<Feature>/` directory
+        this run creates. Set `source_files` to the module's files, grouped
         with YAML comment headers by each file's OWN folder — the path segment that
         VARIES across the files after their shared parent (the layer folder in a
         vertical slice; the tier project in an n-tier app; tests → a single `tests`
@@ -480,18 +636,25 @@ workflow:
         is and move or drop one it got wrong. Keep the key and leave it EMPTY where the
         aggregate has no UI (and on a backend-only repo, where every concept has none);
         never fold these paths into `source_files`, which stays the service surface.
-      - `aggregates/index.md` — the bounded-context / feature map (no frontmatter beyond
-        OKF index rules) linking every feature concept.
+      - `aggregates/index.md` — the BOUNDED-CONTEXT / feature map (no frontmatter beyond
+        OKF index rules). Group the links under a `## <BoundedContext>` heading per
+        context, so the file shows which aggregates belong to which context rather than one
+        flat list, each link followed by the features that act on that aggregate. Add a
+        `## {{bc}}` section with this context's aggregates; leave every
+        other section exactly as it is.
       - An `index.md` in EVERY subdirectory (no frontmatter).
-      - `log.md` (bundle root) — first line under a `## <today's date>` heading must be
-        `Commit: ` + backtick + `{{head}}` + backtick (validator rule E4), then a
-        one-line Initialization entry noting the concept count.
+      - `log.md` (bundle root) — APPEND under a `## <today's date>` heading whose first
+        line is `Commit: ` + backtick + `{{head}}` + backtick (validator rule E4), then a
+        one-line entry naming the bounded context onboarded and its concept count. Keep
+        every earlier dated entry.
       Do NOT write a migration-backlog, a seam/clean-torn analysis, or an adopt-order —
       those are migration artifacts and are out of scope for the development flow.
 
       Provenance + safety (OKF hard rules):
-      - Stamp every concept `origin: reverse-engineered` and `generated_by:
-        aw-spec-onboard/1.6.0` in frontmatter.
+      - Stamp every concept `origin: reverse-engineered`, `generated_by:
+        aw-spec-onboard/2.0.0` and `bounded_context: {{bc}}` in frontmatter. The
+        context key is what lets later commands filter features by the context they
+        belong to instead of listing every aggregate under every one.
       - The CODE is the source of truth; capture what IS (quirks included), not what
         SHOULD be. Where intent is unclear from code + git history, add a concrete
         `open_questions` entry rather than inventing one.
@@ -526,6 +689,76 @@ workflow:
     on_false: stop
     on_false_message: "The OKF feature map at {{bundle_dir}} is NON-CONFORMANT (errors: {{okf_errors}}). Fix the reported ERRORs (unparseable frontmatter, missing `type`, malformed index.md/log.md) and re-run."
 
+  # ═══════════ THE CONTEXT'S SPECS TREE — specs/<Context>/<Feature>/ ═══════════
+  # The concepts above say what this context CONTAINS; these two steps make that
+  # shape exist where every later command looks for it. Until now a context left
+  # no trace under specs/ at all: `list-contexts` reads the tree rather than the
+  # bundle, so the context it had just onboarded reported as absent, and
+  # select-feature's refusal-to-guess gate — contexts exist, none is active —
+  # could not even be reached. select-feature merges the bundle's aggregates into
+  # its list to cover the gap, but a feature that exists only as a concept has
+  # nowhere for adopt to write, and picking one would create its directory at
+  # whatever base happened to be active.
+  #
+  # DIRECTORIES ONLY. No spec.md, no domain-model.md, no plan: adopt reverse-
+  # engineers the first per feature and specify authors the second per context,
+  # and a placeholder for either reads as "the document exists" to every gate
+  # downstream. The directory says the feature is KNOWN; the documents say it is
+  # described.
+  - id: activate_context
+    action: execute_script
+    script: { ref: actions }
+    subcommand: set-context
+    args: ["--context", "{{bc}}"]
+    outputs:
+      - { name: bc_dir,          from: "$.context_dir" }
+      - { name: bc_domain_model, from: "$.domain_model" }
+      - { name: bc_dir_created,  from: "$.created" }
+
+  - id: scaffold_features
+    action: execute_script
+    script: { ref: inventory }
+    subcommand: scaffold-context
+    args: ["--context", "{{bc}}", "--map", "{{feature_map}}"]
+    on_error: continue
+    outputs:
+      - { name: scaffold_ok,      from: "$.ok" }
+      - { name: feature_dirs,     from: "$.feature_dirs" }
+      - { name: dirs_created,     from: "$.created" }
+      - { name: dirs_created_num, from: "$.created_count" }
+      - { name: dirs_rejected,    from: "$.rejected" }
+      - { name: dirs_rejected_any, from: "$.rejected_present" }
+      - { name: scaffold_error,   from: "$.error" }
+
+  - id: scaffold_gate
+    action: verify_context
+    require_value: scaffold_ok
+    equals: "true"
+    on_mismatch: stop
+    on_mismatch_message: >
+      The feature directories for {{bc}} could not be created: {{scaffold_error}}
+      The OKF concepts for this context ARE written — only the specs/ tree is
+      missing, so fix the name the message reports in specs/proposed-inventory.md,
+      run /appweaver inventory apply, and re-run onboard for this context.
+
+  # A feature name the map carries that is not a usable directory identifier. Named
+  # rather than dropped silently: the concept exists, so the feature is pickable from
+  # the bundle and would land in a directory nobody chose.
+  # The never-satisfiable `equals` is the engine's announce-only idiom: the step is
+  # entered only when there IS something to report, and the comparison is written so
+  # it always misses, so the message is emitted and the run continues.
+  - id: scaffold_name_warning
+    action: verify_context
+    condition: "{{dirs_rejected_any}} == true"
+    require_value: dirs_rejected_any
+    equals: "never"
+    on_mismatch: continue
+    on_mismatch_message: >
+      These feature names are not valid directory identifiers and got no directory:
+      {{dirs_rejected}}. A feature name has to be a letter-led alphanumeric aggregate
+      (Order, MedicinalProduct). Rename them in specs/proposed-inventory.md, re-run
+      /appweaver inventory apply, then /appweaver select-feature will offer them.
+
   # ═══════════════ PART 2 — GOVERNANCE SCAFFOLD (project-level) ════════════════
   # Establish the governing tier ONCE, from the feature map just written (the whole-
   # repo vantage). No slice is adopted, so list-adopted returns slice_count=0 but STILL
@@ -548,11 +781,16 @@ workflow:
   # Slugify + `brf-` prefix the domain name and create guardrails/projects/brf-<domain>/.
   # Name: explicit arg → PROJECT name from the OKF overview → repo basename. Guarded
   # against clobbering a project that already holds .md files.
+  # The governance project is named from the PROJECT — `gov_name` is empty, so
+  # project-setup falls back to the project name from the OKF overview and then
+  # to the repo basename. Passing the bounded context here would create one rule
+  # pack per context and split the project's constitution along context lines,
+  # which is the aggregate-scoping bias in a new place.
   - id: pack_setup
     action: execute_script
     script: { ref: revcon }
     subcommand: project-setup
-    args: ["--name", "{{USER_INPUT}}", "--fallback", "{{project_name}}"]
+    args: ["--name", "{{gov_name}}", "--fallback", "{{project_name}}"]
     outputs:
       - { name: domain_slug,                from: "$.domain_slug" }
       - { name: pack_dir,                   from: "$.pack_dir" }
@@ -560,18 +798,54 @@ workflow:
       - { name: domain_constitution_source, from: "$.domain_constitution_source" }
       - { name: pack_present,               from: "$.pack_present" }
 
-  - id: pack_guard
-    action: verify_context
-    require_value: pack_present
-    equals: "false"
-    on_mismatch: stop
-    on_mismatch_message: "The project guardrails/projects/{{domain_slug}}/ already holds curated rule files — onboard would overwrite them. Back up or remove that folder to re-onboard, or amend it via /appweaver constitution."
+  # An existing pack is no longer a reason to stop — it is the signal that the
+  # project tier has already been authored and this run is onboarding a LATER
+  # bounded context. The tier is written once and amended by /appweaver
+  # constitution; what each later context still contributes is its own OKF
+  # concepts and its own domain model.
+  - id: repo_gov_present
+    action: set
+    condition: "{{pack_present}} == true"
+    vars: { repo_gov: "true" }
+
+  # WHAT THIS RUN AUTHORS. The engine compares one variable against one value and
+  # has no compound conditions, so "this lane exists AND the project tier has not
+  # been written yet" is computed here as an ordered pair of sets rather than
+  # asked at each step: default to the lane declaration, then clear everything
+  # once the project tier is present.
+  #
+  # The second set also SATISFIES the lint guards the skipped block would
+  # otherwise leave at their "not yet verified" default — the same move
+  # svc_lane_absent makes for a repo with no service lane. Without it a later
+  # context would stop at a gate checking work this run correctly did not do.
+  #
+  # ⌛ OPEN: should a LATER context amend the rule sets? Skipping the whole tier
+  # also skips the code-derived rule files, and a second context can evidence a
+  # domain or technical concern the first one's source never showed — that
+  # evidence reaches nothing today. The two halves of the tier differ here. The
+  # constitution halves, principle numbering, domain activation and the document
+  # templates are project-scoped, and re-deriving them per context IS the
+  # aggregate-scoping bias rev-constitution v1.1.0 removed; /appweaver
+  # constitution is their amendment path. The rule SETS
+  # (guardrails/projects/<p>/{domain,service,frontend}/) are evidenced-only, so
+  # amending them ADDITIVELY from a later context — add a rule for a concern this
+  # context exhibits, never rewrite or renumber an existing one — would be more
+  # evidence at the same project scope rather than one context's bias. That
+  # additive pass is not built; author-once is what runs.
+  - id: author_flags_default
+    action: set
+    vars: { author_repo: "true", author_svc: "{{svc_lane}}", author_ui_flag: "{{ui_lane}}" }
+  - id: author_flags_skip
+    action: set
+    condition: "{{repo_gov}} == true"
+    vars: { author_repo: "false", author_svc: "false", author_ui_flag: "false", technical_ok: "true", domain_ok: "true", ui_ok: "true", numbering_ok: "true" }
 
   # ── DOMAIN RULE SET (provisional, evidenced by the SCAN) ────────────────────
   # Feed NEUTRAL shape skeletons (rev-templates/, zero content to leak) + the rule-
   # partition authority + the project context (the feature map). NO adopted specs
   # exist — the evidence is the OKF overview + aggregates/index + platform.
   - id: ctx_pack
+    condition: "{{author_repo}} == true"
     action: build_context
     context:
       - { path: "{{inventory_json}}" }                                                       # the COMPLETE deterministic scan substrate — read representative SOURCE from its file lists (the OKF map only SUMMARISES this)
@@ -581,6 +855,7 @@ workflow:
       - { path: .appweaver/RULE-PARTITION.md }                                                    # the rule-partition authority (which command reads what)
     context_from: project_context
   - id: author_pack
+    condition: "{{author_repo}} == true"
     action: agent_generate
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
@@ -659,11 +934,13 @@ workflow:
       - { name: pack_files, from: "$.files" }
 
   - id: verify_pack
+    condition: "{{author_repo}} == true"
     action: verify_context
     require_non_empty: pack_files
     on_empty: stop
     on_empty_message: "No domain rule files were written to guardrails/projects/{{domain_slug}}/domain/. Ensure the feature map carries a modellable domain (a feature map + ubiquitous language) and re-run."
   - id: require_domain_rule_bindings
+    condition: "{{author_repo}} == true"
     action: verify_context
     required_files: ["{{domain_rule_bindings}}"]
 
@@ -671,12 +948,14 @@ workflow:
   # Named and placed exactly as a greenfield industry corpus names and places its charter,
   # and already wired as the first `## /aw-spec-constitution` bullet by the step above.
   - id: ctx_domain_source
+    condition: "{{author_repo}} == true"
     action: build_context
     context:
       - { path: "{{domain_rule_bindings}}" }
       - { path: .appweaver/orchestrator/rev-templates/domain-constitution.skeleton.md, optional: true }
     context_from: project_context
   - id: author_domain_source
+    condition: "{{author_repo}} == true"
     action: agent_author
     include_standards: false
     output_target: { type: file, path: "{{domain_constitution_source}}" }
@@ -719,6 +998,7 @@ workflow:
   # do, so a later call without the flag silently recreates the half an earlier call
   # was told to skip.
   - id: setup_constitution
+    condition: "{{author_repo}} == true"
     action: execute_script
     script: { ref: actions }
     subcommand: setup-constitution
@@ -732,7 +1012,7 @@ workflow:
   # set, which is empty), so nothing leaks into the Part-1 feature-map agent.
   - id: ctx_technical
     action: build_context
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     context:
       - { path: "{{constitution_technical_file}}" }
       - { path: .appweaver/orchestrator/rev-templates/technical-constitution.skeleton.md, optional: true }
@@ -740,7 +1020,7 @@ workflow:
     context_from: design_context
   - id: author_technical
     action: agent_author
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     include_standards: false
     output_target: { type: file, path: "{{constitution_technical_file}}" }
     task: |
@@ -783,7 +1063,7 @@ workflow:
 
   - id: technical_validation_loop
     action: loop
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     while: "{{technical_ok}} != true"
     max_iterations: 3
     steps:
@@ -828,7 +1108,7 @@ workflow:
   # ABSENCE is meaningful: a repo with no UI never gets the file at all.
   - id: setup_ui_constitution
     action: execute_script
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     script: { ref: actions }
     subcommand: setup-constitution
     args: ["--ui", "{{setup_tech_flag}}"]
@@ -838,7 +1118,7 @@ workflow:
 
   - id: ctx_ui
     action: build_context
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     context:
       - { path: "{{constitution_ui_file}}" }                                          # the target half being filled
       - { path: "{{inventory_json}}" }                                                # PRIMARY: the COMPLETE deterministic substrate — frontend_signals + the UI file lists to read source from
@@ -846,7 +1126,7 @@ workflow:
       - { path: "{{bundle_dir}}/architecture/frontend.md", optional: true }            # SECONDARY (shallow): the OKF as-built frontend note — corroborate, don't rely on alone
   - id: author_ui
     action: agent_author
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     include_standards: false
     tools: Read   # EVIDENCE = THE UI CODE ITSELF; the inventory inlines the file LISTS, not the files
     output_target: { type: file, path: "{{constitution_ui_file}}" }
@@ -915,7 +1195,7 @@ workflow:
 
   - id: ui_validation_loop
     action: loop
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     while: "{{ui_ok}} != true"
     max_iterations: 3
     steps:
@@ -948,15 +1228,17 @@ workflow:
   # repo no half was created, so the run reports that rather than a bare false a reader
   # would take for a half that needs a manual touch.
   - id: ui_validation_state_absent
+    condition: "{{author_repo}} == true"
     action: set
     vars: { ui_validation_state: "n/a — no frontend lane, no UI half authored" }
   - id: ui_validation_state_present
     action: set
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     vars: { ui_validation_state: "{{ui_ok}}" }
 
   # DOMAIN HALF — from the project + charter, principles continue the technical numbering.
   - id: ctx_domain
+    condition: "{{author_repo}} == true"
     action: build_context
     context:
       - { path: "{{constitution_domain_file}}" }
@@ -965,6 +1247,7 @@ workflow:
       - { path: "{{domain_rule_bindings}}" }
     context_from: project_context
   - id: author_domain
+    condition: "{{author_repo}} == true"
     action: agent_author
     include_standards: false
     output_target: { type: file, path: "{{constitution_domain_file}}" }
@@ -987,8 +1270,8 @@ workflow:
         numeral is whatever the code supported — never a value carried over from another
         constitution. If it mandates no modelling methodology, say so plainly rather than
         supplying one.
-      - Author ONLY the domain layer: domain principles, domain folder additions,
-        regulatory/security posture, domain governance — from the project + charter. NUMBER
+      - Author ONLY the domain layer: project identity, domain principles, domain folder
+        additions, regulatory/security posture, domain governance — from the project + charter. NUMBER
         them by CONTINUING the technical half's roman numerals: READ
         constitution.technical.md (in context), find its LAST numeral N, start the first
         domain principle at N+1 (do NOT assume it ends at XV). TITLE each by DOMAIN
@@ -1005,6 +1288,7 @@ workflow:
       Return the complete updated domain addenda content only.
 
   - id: domain_validation_loop
+    condition: "{{author_repo}} == true"
     action: loop
     while: "{{domain_ok}} != true"
     max_iterations: 3
@@ -1036,6 +1320,7 @@ workflow:
 
   # ── COMPOSE + ACTIVATE ───────────────────────────────────────────────────────
   - id: compose_constitution
+    condition: "{{author_repo}} == true"
     action: execute_script
     script: { ref: actions }
     subcommand: compose-constitution
@@ -1058,6 +1343,7 @@ workflow:
   # Ordered override — the var holds "ok" unless the check reported a problem, because
   # require_non_empty reports on EMPTY.
   - id: numbering_default
+    condition: "{{author_repo}} == true"
     action: set
     vars: { numbering_gate: "ok" }
   - id: numbering_detect
@@ -1065,6 +1351,7 @@ workflow:
     condition: "{{numbering_ok}} == false"
     vars: { numbering_gate: "" }
   - id: numbering_warning
+    condition: "{{author_repo}} == true"
     action: verify_context
     require_non_empty: numbering_gate
     on_empty: continue
@@ -1080,6 +1367,7 @@ workflow:
   # Auto-activate: point .appweaver/domain.json at the scaffolded project so the forward CR
   # loop governs development with it from the first change.
   - id: activate_domain
+    condition: "{{author_repo}} == true"
     action: execute_script
     script: { ref: actions }
     subcommand: set-domain
@@ -1111,7 +1399,7 @@ workflow:
   # lives inside pack_dir, so pack_guard (above) already protects it from clobber.
   - id: ctx_tech_pack
     action: build_context
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     context:
       - { path: "{{inventory_json}}" }                                                          # PRIMARY: the COMPLETE deterministic substrate — read representative SOURCE from its file lists
       - { path: "{{constitution_technical_file}}" }                                             # PRIMARY: the VALIDATED as-built technology base — the ratified principles these files detail
@@ -1122,7 +1410,7 @@ workflow:
     context_from: design_context
   - id: author_tech_pack
     action: agent_generate
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
     task: |
@@ -1210,11 +1498,12 @@ workflow:
 
   - id: verify_tech_pack
     action: verify_context
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     require_non_empty: tech_pack_files
     on_empty: stop
     on_empty_message: "No technical rule files were written to guardrails/projects/{{domain_slug}}/service/. Ensure the scan substrate (inventory_json) + the validated technical constitution carry an as-built technology base and re-run."
   - id: require_tech_rule_bindings
+    condition: "{{author_repo}} == true"
     action: verify_context
     required_files: ["{{pack_dir}}/tech-rule-bindings.md"]
 
@@ -1227,7 +1516,7 @@ workflow:
   # file, and the run's remaining work is worth keeping either way.
   - id: probe_specify_wiring
     action: execute_script
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     on_error: continue
     script: { ref: actions }
     subcommand: resolve-tech
@@ -1236,7 +1525,7 @@ workflow:
       - { name: specify_rules, from: "$.candidates" }
   - id: warn_specify_wiring
     action: verify_context
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     require_non_empty: specify_rules
     on_empty: continue
     on_empty_message: >
@@ -1260,7 +1549,7 @@ workflow:
   # find the lane on every future run without stacks.json or a named stack.
   - id: ctx_ui_pack
     action: build_context
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     context:
       - { path: "{{inventory_json}}" }                                                            # PRIMARY: the COMPLETE deterministic substrate — frontend_signals + the UI file lists to read source from
       - { path: "{{constitution_ui_file}}" }                                                      # PRIMARY: the VALIDATED as-built UX-* base — the ratified principles these files detail
@@ -1271,7 +1560,7 @@ workflow:
       - { path: "{{bundle_dir}}/architecture/frontend.md", optional: true }                       # SECONDARY (shallow): the OKF as-built frontend note
   - id: author_ui_pack
     action: agent_generate
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
     task: |
@@ -1343,7 +1632,7 @@ workflow:
 
   - id: verify_ui_pack
     action: verify_context
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     require_non_empty: ui_pack_files
     on_empty: stop
     on_empty_message: "A frontend lane was detected ({{ui_evidence}}) but no lane rule files were written to guardrails/projects/{{domain_slug}}/frontend/. Check that the scan substrate's frontend_signals carry readable UI source, then re-run."
@@ -1355,7 +1644,7 @@ workflow:
   # it. Announce, don't stop — the rule files are on disk and the heading is one edit away.
   - id: probe_ui_wiring
     action: execute_script
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     on_error: continue
     script: { ref: actions }
     subcommand: resolve-tech
@@ -1364,7 +1653,7 @@ workflow:
       - { name: ui_map_rules, from: "$.candidates" }
   - id: warn_ui_wiring
     action: verify_context
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     require_non_empty: ui_map_rules
     on_empty: continue
     on_empty_message: >
@@ -1392,6 +1681,7 @@ workflow:
   # the run reports the lanes it actually scanned under rather than a second opinion
   # about them.
   - id: lane_readback
+    condition: "{{author_repo}} == true"
     action: execute_script
     on_error: continue
     script: { ref: actions }
@@ -1451,7 +1741,7 @@ workflow:
   # plus a NEUTRAL skeleton for the bones. No greenfield template is in context.
   - id: ctx_design_template
     action: build_context
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     context:
       - { path: "{{inventory_json}}" }                                        # PRIMARY: the COMPLETE deterministic substrate (top_level_dirs, aggregate_signals' per-layer file groupings) — the OKF markdown only SUMMARISES this
       - { path: "{{constitution_technical_file}}" }                           # PRIMARY: the VALIDATED as-built technology base (framework/persistence/concurrency/hosting/testing/cross-cutting)
@@ -1462,7 +1752,7 @@ workflow:
       - { path: "{{bundle_dir}}/aggregates/index.md", optional: true }        # SECONDARY (shallow): the bounded-context / feature map
   - id: gen_design_template
     action: agent_generate
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
     task: |
@@ -1552,7 +1842,7 @@ workflow:
 
   - id: verify_design_template
     action: verify_context
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     require_non_empty: design_template_files
     on_empty: stop
     on_empty_message: "No design template was written to .appweaver/templates/overrides/design-template.md. Ensure the scan substrate (inventory_json) + the technical constitution are present and re-run."
@@ -1563,14 +1853,14 @@ workflow:
   # master's OWN section structure").
   - id: ctx_delta_design_template
     action: build_context
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     context:
       - { path: .appweaver/templates/overrides/design-template.md, optional: true }      # PRIMARY: the JUST-generated code-derived master — mirror its ACTUAL sections
       - { path: .appweaver/orchestrator/rev-templates/delta-design-template.skeleton.md } # SHAPE ONLY: the neutral change-record bones (zero layering, zero technology)
       - { path: "{{constitution_technical_file}}" }                                    # the validated as-built technology base (keep the delta consistent with the master)
   - id: gen_delta_design_template
     action: agent_generate
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
     task: |
@@ -1599,7 +1889,7 @@ workflow:
 
   - id: verify_delta_design_template
     action: verify_context
-    condition: "{{svc_lane}} == true"
+    condition: "{{author_svc}} == true"
     require_non_empty: delta_design_template_files
     on_empty: stop
     on_empty_message: "No delta-design template was written to .appweaver/templates/overrides/delta-design-template.md. Re-run onboard after confirming the design template override was generated."
@@ -1623,6 +1913,7 @@ workflow:
   # entity: naming one would hand the downstream author the answer to the single question
   # the reverse exists to ask the code.
   - id: ctx_model_template
+    condition: "{{author_repo}} == true"
     action: build_context
     context:
       - { path: "{{inventory_json}}" }                                              # PRIMARY: the COMPLETE deterministic substrate
@@ -1630,6 +1921,7 @@ workflow:
       - { path: "{{constitution_domain_file}}", optional: true }                    # the reversed DOMAIN frame — vocabulary, not structure
       - { path: "{{bundle_dir}}/aggregates/index.md", optional: true }              # SECONDARY (shallow): the bounded-context / feature map
   - id: gen_model_template
+    condition: "{{author_repo}} == true"
     action: agent_generate
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
@@ -1676,6 +1968,7 @@ workflow:
       - { name: model_template_files, from: "$.files" }
 
   - id: verify_model_template
+    condition: "{{author_repo}} == true"
     action: verify_context
     require_non_empty: model_template_files
     on_empty: stop
@@ -1709,7 +2002,7 @@ workflow:
   # nothing breaks for their absence in a repo that never onboarded.
   - id: ctx_ui_design_template
     action: build_context
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     context:
       - { path: "{{inventory_json}}" }                                                     # PRIMARY: the COMPLETE deterministic substrate — frontend_signals + the component/route/store/style file lists to read source from
       - { path: "{{constitution_ui_file}}" }                                               # PRIMARY: the VALIDATED as-built UX-* base — the ratified principles this structure must serve
@@ -1718,7 +2011,7 @@ workflow:
       - { path: "{{bundle_dir}}/architecture/frontend.md", optional: true }                # SECONDARY (shallow): the OKF as-built frontend note
   - id: gen_ui_design_template
     action: agent_generate
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
     task: |
@@ -1796,7 +2089,7 @@ workflow:
 
   - id: verify_ui_design_template
     action: verify_context
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     require_non_empty: ui_design_template_files
     on_empty: stop
     on_empty_message: "A frontend lane was detected ({{ui_evidence}}) but no UI design template was written to .appweaver/templates/overrides/ui-design-template.md. Check that the scan substrate's frontend_signals carry readable UI source, then re-run."
@@ -1805,14 +2098,14 @@ workflow:
   # as the service delta mirrors the service master.
   - id: ctx_ui_delta_design_template
     action: build_context
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     context:
       - { path: .appweaver/templates/overrides/ui-design-template.md, optional: true }            # PRIMARY: the JUST-generated lane master — mirror its ACTUAL sections
       - { path: .appweaver/orchestrator/rev-templates/ui-delta-design-template.skeleton.md }      # SHAPE ONLY: the neutral change-record bones (zero framework)
       - { path: "{{constitution_ui_file}}" }                                                    # the validated UX-* base (keep the delta consistent with the master)
   - id: gen_ui_delta_design_template
     action: agent_generate
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     tools: "Read,Write,Edit"
     permission_mode: acceptEdits
     task: |
@@ -1846,7 +2139,7 @@ workflow:
 
   - id: verify_ui_delta_design_template
     action: verify_context
-    condition: "{{ui_lane}} == true"
+    condition: "{{author_ui_flag}} == true"
     require_non_empty: ui_delta_design_template_files
     on_empty: stop
     on_empty_message: "No UI delta-design template was written to .appweaver/templates/overrides/ui-delta-design-template.md. Re-run onboard after confirming the UI design template override was generated."
@@ -1865,6 +2158,13 @@ workflow:
 
 outputs:
   bundle_dir: "{{bundle_dir}}"
+  # The context's specs tree — created here, empty by design. It is what makes the
+  # context visible to list-contexts and its features pickable by select-feature.
+  bounded_context: "{{bc}}"
+  context_dir: "{{bc_dir}}"
+  context_domain_model: "{{bc_domain_model}}"
+  feature_dirs: "{{feature_dirs}}"
+  feature_dirs_created: "{{dirs_created}}"
   aggregate_count: "{{aggregate_count}}"
   concepts: "{{concepts}}"
   warnings: "{{okf_warnings}}"
@@ -1910,4 +2210,4 @@ outputs:
   ui_delta_design_template_files: "{{ui_delta_design_template_files}}"
   technical_validation_ok: "{{technical_ok}}"
   domain_validation_ok: "{{domain_ok}}"
-  next: "Onboarded {{project_name}}: a high-level feature map at {{bundle_dir}} + a PROVISIONAL project governance scaffold, domain {{active_domain}} ACTIVATED, and — reverse-engineered from THIS code alone — the rule tiers wired per-workflow: the DOMAIN set (guardrails/projects/{{domain_slug}}/domain/*.domain.md + domain-rule-bindings.md) always, and each LANE's set where that lane is declared. ONE HALF AND ONE RULE SET PER LANE: service_lane / ui_lane report which lanes .appweaver/stacks.json declared, and the declaration is what decided. A declared service lane gets constitution.technical.md, guardrails/projects/{{domain_slug}}/service/*.md + tech-rule-bindings.md, and the service design/delta-design template overrides; a declared UI lane gets constitution.ui.md, guardrails/projects/{{domain_slug}}/frontend/*.md mapped under ## /aw-spec-ui-constitution, and its own template pair. A lane declared (none) in select-stack gets none of it, which is the correct outcome and not an omission. LANE DECLARATION: read, never written — select-stack is its sole writer, and this run scanned the source paths it named (scanned_service_root / scanned_ui_root). The scan was SCOPED by them, so the backend substrate excludes the UI subtree and the frontend substrate is that subtree: scanned_backend_files / scanned_ui_files report each. ui_source_evidence_found false means the UI lane's declared path held nothing a scan recognises as UI, so its governance is thin — move the source path with /appweaver select-stack and re-run. The build/test/run commands on each lane are that PROFILE's defaults and may not match a legacy layout — review them, and re-run /appweaver select-stack to correct any lane. Because the domain is activated, resolve-domain + resolve-tech now route the WHOLE forward pipeline AND adopt to these code-derived rules — never another project's rules as a fallback. Code-derived design + delta-design templates are installed as the project template overrides (.appweaver/templates/overrides/) so a NEW feature is developed against the as-built architecture with NO adopt — every section derived from a NEUTRAL skeleton plus this repo's own structure, with no greenfield template in context. Where the lane exists, the SAME pair is generated for it (ui-design-template.md + ui-delta-design-template.md) from the UI source; ui-design-template.md is consumed by /appweaver adopt, which reverses a slice's design.ui.md from it wherever that slice owns part of the lane's surface; ui-delta-design-template.md is consumed by the frontend lane of /appweaver plan on its DELTA path, and the plan it produces is generated by the frontend lane of /appweaver implement. Develop an EXISTING feature just-in-time: /appweaver adopt <Feature> reverse-engineers its spec.md + design.md + source-map.md and completes that feature's OKF concept; its governance reconcile is currently HELD, so the scaffold this run wrote stays as it is. Develop a NEW feature straight through the forward pipeline (/appweaver specify → plan → implement). Then drive every change through the CR delta loop (/appweaver specify → plan → analyze-plan-delta → implement → build → analyze-slice-delta → finalize-delta → analyze-slice → close-delta). If a validation_ok is false, its constitution half needs a manual touch (see its Sync Impact Report)."
+  next: "Onboarded bounded context {{bc}} ({{bc_feature_count}} feature(s): {{bc_features}}). Its aggregate concepts ({{bc_aggregates}}) are in {{bundle_dir}}, each keyed `bounded_context: {{bc}}` and listing the features that act on it — the bundle is the project's knowledge, one concept per aggregate, never one per feature — and its specs tree now exists at {{bc_dir}}/ with a directory per feature ({{feature_dirs}}) — EMPTY on purpose: the directory says the feature is known, and the documents that describe it are written per feature by /appweaver adopt and per context by /appweaver specify. {{bc}} is now the ACTIVE bounded context (.appweaver/context.json), so /appweaver select-feature lists exactly these features and nothing from a neighbouring context; switch with /appweaver select-bounded-context. ONBOARD RUNS ONCE PER CONTEXT: contexts already done — {{onboarded_contexts}}; still open — {{remaining_contexts}}; the order the map gives is {{contexts_ordered}}. Run /appweaver onboard <NextContext> for each remaining one, or with no argument to take the next one automatically. THE PROJECT TIER IS WRITTEN ONCE, BY THE FIRST CONTEXT (this run was first: {{is_first}}). That tier is the PROVISIONAL governance scaffold — the split constitution, the domain rule set at guardrails/projects/{{domain_slug}}/domain/*.domain.md + domain-rule-bindings.md, each declared LANE\'s rule set and constitution half, the activated domain {{active_domain}}, and the code-derived design / delta-design / domain-model template overrides in .appweaver/templates/overrides/. A later context does NOT re-author any of it: re-deriving project principles from one context\'s evidence is the scoping bias the governance tier exists to avoid. Amend it with /appweaver constitution. ONE HALF AND ONE RULE SET PER LANE: service_lane / ui_lane report which lanes .appweaver/stacks.json declared, and the declaration is what decided. A lane declared (none) in select-stack gets none of it, which is the correct outcome and not an omission. LANE DECLARATION: read, never written — select-stack is its sole writer, and this run scanned the source paths it named (scanned_service_root / scanned_ui_root); scanned_backend_files / scanned_ui_files report each. ui_source_evidence_found false means the UI lane\'s declared path held nothing a scan recognises as UI, so its governance is thin — move the source path with /appweaver select-stack and re-run. The build/test/run commands on each lane are that PROFILE\'s defaults and may not match a legacy layout — review them. Because the domain is activated, resolve-domain + resolve-tech route the WHOLE forward pipeline to these code-derived rules — never another project\'s rules as a fallback. THE BOUNDARIES CAME FROM THE MAP, not from this run: /appweaver inventory proposed them and you confirmed them in specs/proposed-inventory.md. To change a boundary, edit that file and run /appweaver inventory apply — a context whose concepts already exist is not re-onboarded. Develop an EXISTING feature just-in-time: /appweaver adopt <Feature> reverse-engineers its spec.md + design.md + source-map.md and deepens the OKF concept of the aggregate it acts on. Develop a NEW feature straight through the forward pipeline (/appweaver specify → plan → implement). Then drive every change through the CR delta loop (/appweaver specify → plan → analyze-plan-delta → implement → build → analyze-slice-delta → finalize-delta → analyze-slice → close-delta). If a validation_ok is false, its constitution half needs a manual touch (see its Sync Impact Report)."