aw-spec-cli 0.1.16 → 0.1.18

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

@@ -76,7 +76,7 @@ workflow:
     with: { require: backend, command: "/appweaver run" }
 
   # The slice's source files, from its OKF concept — what the migration fix loop below is
-  # handed. Replaces the retired `design-paths` fence scan (the tech-agnostic design.md
+  # handed. Replaces the retired `design-paths` fence scan (the tech-agnostic backend-plan.md
   # carries no ```lang path=… code blocks, so it returned nothing and the fixer got an
   # EMPTY context). Read-only, exits 0 with paths=[] when there is no concept yet, and
   # on_error: continue so a missing bundle can never block a migration.
@@ -144,7 +144,7 @@ workflow:
 
   # Record what the migration fix loop touched in the slice's OKF concept. Replaces the
   # retired `design-reconcile` (which copied file bodies back into design fences — a
-  # silent no-op since design.md stopped carrying code). The fix loop can CREATE files
+  # silent no-op since backend-plan.md stopped carrying code). The fix loop can CREATE files
   # (a new migration, a config) that implement never recorded. UNION (--merge), never
   # replace. Advisory: conditioned + on_error: continue, never gated.
   - id: okf_merge_run_fixes

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

@@ -0,0 +1,132 @@
+# =============================================================================
+# aw-spec-select-bounded-context (orchestrator) — pick or create the active
+# BOUNDED CONTEXT
+#
+# A bounded context is the container a feature lives in: specs/<Context>/<Feature>/.
+# It sits between the domain (which project's rules apply) and the feature (which
+# aggregate is being worked on), and it owns ONE domain-model.md that every spec
+# inside it references. That is why it is selected BEFORE select-feature — the
+# feature directory cannot be resolved until the context that holds it is known.
+#
+# Contexts and features are told apart by the only reliable evidence on disk: a
+# directory under specs/ carrying its OWN spec.md is a feature, one that does not is
+# a context. No marker file, so nothing can fall out of sync with the tree.
+#
+# BACKWARD COMPATIBLE BY CONSTRUCTION. A repo that predates bounded contexts has its
+# features flat under specs/ and no context.json; every caller falls back to the flat
+# layout when no context is active, so the tree keeps working untouched and adopts
+# contexts when someone runs this command. The flat features are reported as
+# `legacy_features` rather than being hidden, so an un-migrated repo says so.
+#
+# ZERO LLM: scripts + one select + (conditionally) one ask. Same shape as
+# select-feature, one level up.
+#
+#   list-contexts → user_select (existing | "+ create new") → [ask name] → set-context
+#
+# Persists .appweaver/context.json {"context":"<Name>","context_directory":"specs/<Name>"}.
+#
+# Launch:
+#   /appweaver select-bounded-context           # interactive: list + add-new
+#   /appweaver select-bounded-context Sales     # direct: create-or-select Sales
+# =============================================================================
+
+name: aw-spec-select-bounded-context
+description: Pick an existing bounded context or create a new one, and store it in .appweaver/context.json so select-feature nests its features inside it and every spec in the context shares one domain-model.md. Zero LLM — scripts + one selection only.
+version: 1.0.0
+agent_agnostic: true
+dialect: aw-spec.orchestrator/v1
+
+inputs:
+  user_input:
+    description: Optional bounded context name to create or select directly, e.g. Sales.
+    required: false
+    bind: USER_INPUT
+
+scripts:
+  actions:
+    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
+    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
+
+vars:
+  new_sentinel: "+ Create a new bounded context"   # source of truth is list-contexts $.sentinel; overwritten below
+  typed_name: ""
+  target_name: ""
+
+workflow:
+
+  # 1. Enumerate the bounded contexts under specs/. `select_options` carries the
+  #    "+ create new" sentinel and (when USER_INPUT names a context that does not
+  #    exist yet) that name injected — so a direct argument is one-list select with
+  #    no extra round trip, matching select-feature's fast path.
+  - id: list_contexts
+    action: execute_script
+    script: { ref: actions }
+    subcommand: list-contexts
+    args: ["--preselect", "{{USER_INPUT}}"]
+    outputs:
+      - { name: contexts,        from: "$.contexts" }
+      - { name: context_names,   from: "$.names" }
+      - { name: context_count,   from: "$.count" }
+      - { name: select_options,  from: "$.select_options" }
+      - { name: new_sentinel,    from: "$.sentinel" }
+      - { name: legacy_features, from: "$.legacy_features" }
+      - { name: legacy_count,    from: "$.legacy_count" }
+
+  # 2. Choose. A matching USER_INPUT auto-selects with no prompt; the lone sentinel
+  #    on a repo with no contexts yet auto-confirms.
+  - id: pick
+    action: user_select
+    prompt: "Select the bounded context (e.g. Sales, Billing) — or create a new one:"
+    options_from_variable: select_options
+    preselect_from: USER_INPUT
+    single_option_confirm: true
+    outputs:
+      - { name: chosen, from: selection }
+
+  # 3. Only on the "create new" branch do we ask for a name.
+  - id: ask_new_name
+    action: ask
+    condition: "{{chosen}} == {{new_sentinel}}"
+    prompt: >
+      Name the new bounded context — this is a BOUNDARY in the domain (e.g. Sales,
+      Billing, Fulfilment), not a feature and not a layer. Aggregates like Order or
+      Invoice become features inside it, and every one of them shares this context's
+      single domain-model.md:
+    answer_var: typed_name
+
+  # 4. Coalesce the target name. The engine has no compound conditions, so this is
+  #    two ordered sets: default to the pick, then override with the typed name on
+  #    the "create new" branch only.
+  - id: name_from_pick
+    action: set
+    vars: { target_name: "{{chosen}}" }
+  - id: name_from_new
+    action: set
+    condition: "{{chosen}} == {{new_sentinel}}"
+    vars: { target_name: "{{typed_name}}" }
+
+  # 5. Create-or-select the context dir + persist it as the active context.
+  #    domain-model.md is deliberately NOT created here — specify is the model's only
+  #    writer, and an empty placeholder would read as "the model exists" downstream.
+  - id: set_context
+    action: execute_script
+    script: { ref: actions }
+    subcommand: set-context
+    args: ["--context", "{{target_name}}"]
+    outputs:
+      - { name: context,             from: "$.context" }
+      - { name: context_dir,         from: "$.context_dir" }
+      - { name: domain_model,        from: "$.domain_model" }
+      - { name: existed,             from: "$.existed" }
+      - { name: created,             from: "$.created" }
+      - { name: domain_model_exists, from: "$.domain_model_exists" }
+
+outputs:
+  context: "{{context}}"
+  context_dir: "{{context_dir}}"
+  domain_model: "{{domain_model}}"
+  domain_model_exists: "{{domain_model_exists}}"
+  created: "{{created}}"
+  legacy_features: "{{legacy_features}}"
+  note: "Active bounded context set in .appweaver/context.json. select-feature now creates and lists features inside {{context_dir}}/, and every spec there shares {{domain_model}} as its domain model. Features already sitting flat under specs/ are listed as legacy_features — they keep working exactly as before and are not moved; re-run select-feature after selecting a context to place new work inside it."
+  next: "/appweaver select-feature   (creates {{context_dir}}/<Feature>/, then specify)"

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

@@ -3,7 +3,7 @@
 #
 # 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 + its per-lane plans and every command (CreateOrder/UpdateOrder =
+# 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.
 #
@@ -13,14 +13,20 @@
 # 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.
 #
+# 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
+# only its own features and new work lands beside the domain-model.md it shares. With
+# no context active the base is specs/ itself and behaviour is identical to before
+# contexts existed, which is what lets a repo adopt them without a migration.
+#
 # 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
 #
 # Persists .appweaver/feature.json {"feature_directory":"specs/<Feature>"} so every
-# later command operates on it: the forward loop (specify/plan/analyze-design/implement/
-# build/analyze-slice/run/deploy) and the CR loop (analyze-delta-design/implement-delta/
+# later command operates on it: the forward loop (specify/plan/analyze-plan/implement/
+# build/analyze-slice/run/deploy) and the CR loop (analyze-plan-delta/implement/
 # finalize-delta/close-delta — the standalone `cr` is retired; specify and design author
 # the delta docs themselves).
 #
@@ -54,6 +60,31 @@ vars:
 
 workflow:
 
+  # 0. Resolve the bounded context this feature will live in, and REFUSE to guess.
+  #    scope_ok is false in exactly one state: contexts exist and none is selected.
+  #    Left to run, the feature would be created at specs/<Feature> — outside every
+  #    context and with no domain model to share — and nothing downstream would say
+  #    so. A repo with no contexts at all passes (the flat layout is a valid state),
+  #    which is what keeps a pre-context tree working untouched.
+  - id: context_scope
+    action: execute_script
+    script: { ref: actions }
+    subcommand: list-contexts
+    outputs:
+      - { name: active_context,  from: "$.active" }
+      - { name: context_dir,     from: "$.active_dir" }
+      - { name: feature_base,    from: "$.feature_base" }
+      - { name: context_count,   from: "$.count" }
+      - { name: scope_ok,        from: "$.scope_ok" }
+      - { name: scope_message,   from: "$.scope_message" }
+
+  - id: require_context_scope
+    action: verify_context
+    require_true: scope_ok
+    on_false: stop
+    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,
@@ -77,7 +108,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) — or create a new one:"
+    prompt: "Select a feature (the aggregate, e.g. Order) in {{feature_base}}/ — or create a new one:"
     options_from_variable: select_options
     preselect_from: USER_INPUT
     single_option_confirm: true
@@ -118,11 +149,13 @@ workflow:
       - { name: existed,     from: "$.existed" }
       - { name: created,     from: "$.created" }
       - { name: spec_exists, from: "$.spec_exists" }
+      - { name: context,     from: "$.context" }
 
 outputs:
   feature: "{{feature}}"
   feature_dir: "{{feature_dir}}"
+  context: "{{context}}"
   created: "{{created}}"
   spec_exists: "{{spec_exists}}"
-  note: "Active feature set in .appweaver/feature.json — the aggregate boundary for its single spec.md and the per-lane plans derived from it (backend-plan.md / frontend-plan.md)."
+  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)."
   next: "/appweaver specify <what this feature does>   (authors {{feature_dir}}/spec.md; each operation = a user story)"

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

@@ -30,7 +30,7 @@
 # and `lane-verify` to gate, and neither can write.
 #
 # WHY THE SOURCE PATH IS ASKED AND NOT INHERITED. A lane's root is the subtree it
-# OWNS: the only place its implement phase may write, the directory its build and
+# OWNS: the only place implement's lane for it may write, the directory its build and
 # run commands act on, and in brownfield the code onboard reads. A profile's default
 # root describes how a NEW project of that stack is usually laid out, which is a
 # reasonable proposal and a poor assumption — a repo that already exists did not
@@ -203,7 +203,7 @@ workflow:
   - id: ask_ui_source_path
     action: ask
     condition: "{{ui_selected}}"
-    prompt: "UI lane SOURCE PATH — the subtree this lane owns, the only place ui-implement may write. It must not overlap the service lane's. Pick one or type your own:"
+    prompt: "UI lane SOURCE PATH — the subtree this lane owns, the only place implement's frontend lane may write. It must not overlap the service lane's. Pick one or type your own:"
     options_from_variable: ui_root_options
     answer_var: ui_source_path
 
@@ -292,5 +292,5 @@ outputs:
   api_detected: "{{api_detected}} at {{api_detected_root}}"
   ui_detected: "{{ui_detected}} at {{ui_detected_root}}"
   prototype: "{{prototype}}"
-  note: "Lanes persisted to .appweaver/stacks.json. Each lane carries a STACK and a SOURCE PATH, and both are load-bearing. The SOURCE PATH is ownership: implement writes only under the service lane's, ui-implement only under the UI lane's, build/test/run act on it, and onboard reverse-engineers out of it — overlapping paths are refused here rather than discovered later as two generators writing one file. The build/test/run commands are project-supplied strings the engine shells out to, which is how it stays stdlib-only and stack-ignorant. api_detected / ui_detected report what this repo's own files pointed at, whether or not it was chosen — empty on a greenfield repo with nothing to detect. A source path that does not exist yet is NORMAL here and reported rather than refused: greenfield declares src/ before implement creates it. The on-disk check runs in the phases that read the subtree — implement, implement-delta, build, run and onboard all call lane-verify and STOP with the fix named. Declining a lane with (none) is a real declaration and removes any lane of that kind a previous run left behind; it is also what stops that lane's constitution half and rule files being authored. `prototype` is not a lane — it has a root and a run command so an operator can open it, and nothing else. Re-run this workflow any time to re-stack a lane, move a source path, or drop a lane with (none); it is the only workflow that may write this file."
+  note: "Lanes persisted to .appweaver/stacks.json. Each lane carries a STACK and a SOURCE PATH, and both are load-bearing. The SOURCE PATH is ownership: implement's service lane writes only under the service lane's and its frontend lane only under the UI lane's, build/test/run act on it, and onboard reverse-engineers out of it — overlapping paths are refused here rather than discovered later as two generators writing one file. The build/test/run commands are project-supplied strings the engine shells out to, which is how it stays stdlib-only and stack-ignorant. api_detected / ui_detected report what this repo's own files pointed at, whether or not it was chosen — empty on a greenfield repo with nothing to detect. A source path that does not exist yet is NORMAL here and reported rather than refused: greenfield declares src/ before implement creates it. The on-disk check runs in the phases that read the subtree — implement, build, run and onboard all call lane-verify and STOP with the fix named. Declining a lane with (none) is a real declaration and removes any lane of that kind a previous run left behind; it is also what stops that lane's constitution half and rule files being authored. `prototype` is not a lane — it has a root and a run command so an operator can open it, and nothing else. Re-run this workflow any time to re-stack a lane, move a source path, or drop a lane with (none); it is the only workflow that may write this file."
   next: "GREENFIELD: /appweaver select-domain → constitution → select-feature → specify. BROWNFIELD: /appweaver onboard — it reverse-engineers out of the source paths declared here and generates the project (no select-domain; onboard derives and activates it from the code). Run this workflow FIRST in either sequence: constitution reads the declaration to decide which halves to author, and onboard reads it to decide what to scan."