aw-spec-cli 0.1.7 → 0.1.9

package/assets/.appweaver/orchestrator/modules/delta-design.orch.yaml

@@ -0,0 +1,105 @@
+# =============================================================================
+# delta-design (orchestrator module) — author the DESIGN-side DELTA of a change
+#
+# Included by /appweaver design on its DELTA branch (design.md already exists).
+# This is the DESIGN half of the former standalone `cr` capture, relocated here.
+# JOIN-or-OPEN the change: if one is already open (specify opened it via delta-spec)
+# JOIN it; otherwise OPEN one here (a DESIGN-ONLY change — the design's realisation of
+# EXISTING spec ids changes without a spec delta). It then authors the DELTA-DESIGN
+# ONLY — it does NOT touch the master design.md. The change stays OPEN; finalize-delta
+# merges the delta into design.md later in the chain and close-delta closes it at the
+# end. No version bump here, no code (that is /appweaver implement-delta).
+#
+# Runs in the CALLER's context (include semantics): shares vars + the sticky standards
+# (design's TECHNICAL/architecture set) + the caller's scripts map + replay cache.
+# EXPECTS caller vars: feature_dir, spec_file, design_doc, has_change, active_change,
+#   need_new_change (design_mode==delta AND no change open yet), USER_INPUT.
+# PRODUCES: active_change, delta_spec, delta_design, downstream_count, impact_report.
+# =============================================================================
+
+name: delta-design
+dialect: aw-spec.orchestrator/v1
+
+# Scripts this module invokes. A module's scripts EXTEND the caller's map (setdefault, so
+# the caller's refs WIN at runtime — these are inert when design already supplies them);
+# declaring both keeps the module self-contained + validatable on its own. `actions` mirrors
+# the caller's (design's) ref; `xref` (the OKF cross-reference substrate) is ADDED for the
+# advisory blast-radius step below, which design does not otherwise provide.
+scripts:
+  actions:
+    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
+    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
+  xref:
+    sh:  .appweaver/scripts/bash/aw-xref.sh
+    ps1: .appweaver/scripts/powershell/aw-xref.ps1
+
+workflow:
+
+  # OPEN a change only when none is open (a design-only change). cr-setup refuses if
+  # one is already open, so the JOIN case (specify opened it) SKIPS this and keeps the
+  # caller's active_change. cr-setup also scaffolds delta-design.md from its template.
+  - id: open_change
+    condition: "{{need_new_change}} == true"
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-setup
+    args: ["--feature-dir", "{{feature_dir}}", "--title", "{{USER_INPUT}}"]
+    outputs:
+      - { name: active_change, from: "$.cr_id" }     # the design-opened change becomes the active one
+      - { name: delta_spec,    from: "$.delta_spec" }
+      - { name: delta_design,  from: "$.delta_design" }
+
+  # Resolve the delta doc paths from the active change (covers the JOIN case, where
+  # open_change was skipped; recomputes the same paths on the OPEN case — harmless).
+  - id: paths
+    action: set
+    vars:
+      delta_design: "{{feature_dir}}/changes/{{active_change}}/delta-design.md"
+      delta_spec:   "{{feature_dir}}/changes/{{active_change}}/delta-spec.md"
+
+  - id: ctx
+    action: build_context
+    context:
+      - { path: "{{delta_design}}" }            # the delta-design template to fill
+      - { path: "{{delta_spec}}" }              # the spec-side change (from specify/delta-spec)
+      - { path: "{{spec_file}}" }
+      - { path: "{{design_doc}}" }              # the current master design.md (READ ONLY — never amended here)
+      - { path: .appweaver/DESIGN-FORMAT.md }
+  - id: author
+    action: agent_author                          # design's technical standards stay ON (default) — correct here
+    output_target: { type: file, path: "{{delta_design}}" }
+    task: |
+      Fill the delta-design record (target in context) for this change, from the
+      delta-spec and the CURRENT master design.md (both in context) — the DELTA ONLY.
+      Do NOT edit design.md: finalize-delta merges the delta into the master later.
+      Classify every change to the design as ADDED / MODIFIED / REMOVED against the
+      master, per the master's OWN section structure (whatever sections it actually has
+      — do not assume a fixed layering), plus the cross-section impact, the regression
+      targets, and any new assumption (DA-n) or workaround (WA-n) the change introduces.
+      Stay technology-agnostic (no code). A shared element (e.g. the aggregate root) is
+      MODIFIED in place, never duplicated.
+      TWO CASES — decide from the delta-spec in context:
+        • SPEC-DRIVEN — the delta-spec lists ADDED/MODIFIED/REMOVED spec items: realise
+          them; every changed design element serves one of those spec ids.
+        • DESIGN-ONLY — the delta-spec is an unfilled stub (no spec delta): this change
+          refines HOW the EXISTING spec is realised (an architectural / decision change)
+          driven by the guidance below. The spec is unchanged, so every changed element
+          MUST still trace to an EXISTING spec id (FR-/BR-/CN-/DC-/IC-/US-/SC-) — you are
+          changing the realisation, never inventing a requirement.
+      Guidance: {{USER_INPUT}}
+
+  # ADVISORY blast radius (restored from the retired `cr`): who currently depends on THIS
+  # aggregate (its Cross-References in the OKF bundle). A change here may ripple to them —
+  # surfaced now, at delta-review time, and written to the change dir (impact.md) for the
+  # record. Read-only + on_error: continue: it INFORMS how to scope the change; the actual
+  # downstream-green enforcement is finalize-delta's job. Uses the change's own id
+  # ({{active_change}}) — the JOIN case inherits it from specify, the OPEN case sets it above.
+  - id: xref_impact
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: list
+    args: ["--feature-dir", "{{feature_dir}}", "--out", "{{feature_dir}}/changes/{{active_change}}/impact.md"]
+    outputs:
+      - { name: downstream_count, from: "$.count" }
+      - { name: impact_report,    from: "$.impact_report" }

package/assets/.appweaver/orchestrator/modules/delta-spec.orch.yaml

@@ -0,0 +1,101 @@
+# =============================================================================
+# delta-spec (orchestrator module) — author the SPEC-side DELTA of a change
+#
+# Included by /appweaver specify on its DELTA branch (spec.md already exists).
+# This is the SPEC half of the former standalone `cr` capture, relocated here: a
+# later requirement is a new user story on the SAME aggregate. It opens the change
+# (cr-setup — single-active-change guarded; also scaffolds delta-spec AND delta-design)
+# and authors the DELTA-SPEC ONLY. It does NOT touch the master spec.md — the change
+# stays OPEN; finalize-delta merges the delta into spec.md later in the chain and
+# close-delta closes it at the end. No version bump here, no design (that is
+# /appweaver design → delta-design).
+#
+# Runs in the CALLER's context (include semantics): shares vars + the sticky standards
+# (specify's DDD authority + the selected domain rule files) + the caller's scripts map
+# + replay cache.
+# EXPECTS caller vars: feature_dir, spec_file, USER_INPUT.
+# PRODUCES: cr_id, cr_dir, delta_spec (and, via cr-setup, an OPEN change + a scaffolded
+#           delta-design.md for the design phase to fill). cr_dir is what lets the
+#           caller's quality loop target THIS change (create-checklist --kind delta).
+# =============================================================================
+
+name: delta-spec
+dialect: aw-spec.orchestrator/v1
+
+# Scripts this module invokes. A module's scripts EXTEND the caller's map (setdefault, so
+# the caller's refs WIN at runtime — these are inert whenever the including workflow already
+# supplies them); declaring them here keeps the module self-contained and validatable on its
+# own, rather than only inside a caller that happens to declare the ref.
+scripts:
+  actions:
+    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
+    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
+
+workflow:
+
+  # Open the change (sets active_version.json.active_change) + scaffold the two delta
+  # docs from their templates. Refuses if a change is already open on this aggregate.
+  - id: cr_setup
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-setup
+    args: ["--feature-dir", "{{feature_dir}}", "--title", "{{USER_INPUT}}"]
+    outputs:
+      - { name: cr_id,      from: "$.cr_id" }
+      - { name: cr_dir,     from: "$.cr_dir" }
+      - { name: delta_spec, from: "$.delta_spec" }
+
+  - id: ctx
+    action: build_context
+    context:
+      - "{{delta_spec}}"                     # the delta-spec template to fill
+      - "{{spec_file}}"                      # the current master spec (READ ONLY — never amended here)
+      - .appweaver/memory/constitution.domain.md      # the DOMAIN authority — specify's frame. Declared
+                                                     # REQUIRED (bare string, not `optional: true`) ON PURPOSE:
+                                                     # specify is the ONLY phase that reads the domain rules and
+                                                     # the task text below tells the agent this file is in context,
+                                                     # so a missing one must ANNOUNCE (`[context] MISSING (required)`)
+                                                     # rather than silently thin the payload. It announces, it does
+                                                     # not stop — a delta only ever runs against an established
+                                                     # feature, so the constitution is long since written.
+                                                     # NOT constitution.technical: architecture is a HOW
+                                                     # concern for design/implement, not domain modelling.
+      - { path: .appweaver/memory/constitution.ui.md, optional: true }
+                                                     # The frontend lane's UX-* base — the source a UX- delta is
+                                                     # lifted from. OPTIONAL, unlike the domain half: a project
+                                                     # with no frontend lane has no such file, and that is the
+                                                     # ordinary backend-only path, not something to announce.
+  - id: author
+    action: agent_author
+    include_standards: true
+    output_target: { type: file, path: "{{delta_spec}}" }
+    task: |
+      A change request to this aggregate's EXISTING spec (change {{cr_id}}). Fill the
+      delta-spec (the output target, in context) relative to the current master spec.md
+      (in context) — the DELTA ONLY. Do NOT edit spec.md: finalize-delta merges the delta
+      into the master later in the chain.
+      - Classify every item ADDED / MODIFIED / REMOVED vs the current master, in the
+        master's vocabulary — System Requirements in EARS, Business Rules (BR-n), User
+        Stories with Given/When/Then, and — where their rules apply — Constraints & NFRs
+        (CN-n), Data Classification (DC-n), Integration Contracts (IC-n) and Experience
+        Standards (UX-n). A change to a retention/audit rule, a data-exposure rule, an
+        interop obligation or a project-wide experience standard is a CN-/DC-/IC-/UX-
+        delta, not a code change.
+      - A UX- delta states the STANDARD only — accessibility conformance, interaction-state
+        coverage, content and language, journey integrity, responsiveness-as-a-limit — never
+        a screen, page, layout or component, which the prototype and design.ui.md settle. A
+        change to this aggregate's own interaction BEHAVIOUR is an FR- delta; only a change
+        to the standard governing every such behaviour is a UX- delta. A bound the SERVICE
+        must meet stays a CN-, because the service-side gates trace CN- and never read the
+        Experience Standards.
+      - The new operation is a NEW USER STORY — assign the next id after the highest US-n
+        in the master — never a new feature/aggregate. Record the regression risk (shared
+        behaviour that must still hold).
+      - Model the delta strictly in DDD terms (→ the modelling-methodology standard + the
+        domain's own DDD overlay, both in the sticky standards): keep the
+        ubiquitous language, respect the aggregate boundary and its root, entities vs
+        value objects, and aggregate-owned invariants — domain MODEL, never code.
+        Business-facing and testable; NO implementation mechanics (an external interop
+        OBLIGATION is a requirement → an IC- item, but never the adapter design); NO
+        design docs (that is the design phase).
+      Change request: {{USER_INPUT}}

package/assets/.appweaver/orchestrator/modules/domain-select.orch.yaml

@@ -0,0 +1,90 @@
+# =============================================================================
+# domain-select (orchestrator port) — shared domain rule-file selection module
+#
+# Included (via
+# `action: include`) by every domain-aware converted skill. Same flow:
+#   1. resolve the active domain + candidate rule files for {{command}}
+#   2. Domain gate: no domain / no domain-rule-bindings → ask Continue (technical only)
+#      or EXIT (stops the whole skill, no side effects)
+#   3. Selection box: all / subset / none
+#   4. load the selected rule files — into the STICKY STANDARDS SET (D3: domain
+#      rules are SYSTEM standards; every later generation sees them without the
+#      caller re-declaring them per request)
+#
+# Runs in the CALLER's context: shares vars + standards + the caller's
+# `scripts:` map + replay cache (include semantics; cache keys namespaced under
+# the include id). HITL steps suspend via the checkpoint channel under EVERY
+# strategy; non-interactive defaults: gate→continue, selection→all.
+#
+# Input (via include `with`): command = the command name (domain-rule-bindings heading).
+# Produces: domain (+ dg_* internals) and the loaded standards.
+# =============================================================================
+
+name: domain-select
+dialect: aw-spec.orchestrator/v1
+
+# Scripts this module invokes. A module's scripts EXTEND the caller's map (setdefault, so
+# the caller's refs WIN at runtime — these are inert whenever the including workflow already
+# supplies them); declaring them here keeps the module self-contained and validatable on its
+# own, rather than only inside a caller that happens to declare the ref.
+scripts:
+  actions:
+    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
+    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
+
+workflow:
+
+  # 1. Resolve the active domain + candidate rule files.
+  - id: resolve
+    action: execute_script
+    script: { ref: actions }
+    subcommand: resolve-domain
+    args: ["--command", "{{command}}"]
+    outputs:
+      - { name: domain,            from: "$.domain" }
+      - { name: dg_rulemap_exists, from: "$.rulemap_exists" }
+      - { name: dg_candidates,     from: "$.candidates" }
+
+  # 2. Domain gate — only when the domain/domain-rule-bindings is missing.
+  - id: gate
+    action: ask
+    condition: "{{dg_rulemap_exists}} == false"
+    prompt: >
+      Domain is not set or its rule files are missing (domain '{{domain}}').
+      Continue with technical standards only, or exit to run /appweaver select-domain?
+    options: ["continue", "exit"]
+    answer_var: dg_gate
+  - id: gate_stop
+    action: verify_context
+    condition: "{{dg_rulemap_exists}} == false"
+    require_value: dg_gate
+    equals: "continue"
+    on_mismatch: stop
+    on_mismatch_message: "Exited — run /appweaver select-domain (or fix the domain folder) and re-run."
+
+  # 3. Selection box — only when a rule map with candidates exists.
+  - id: select_mode
+    action: ask
+    condition: "{{dg_candidates}} != []"
+    prompt: "Domain rule files for {{command}}:"
+    options: ["all", "subset", "none"]
+    answer_var: dg_mode
+  - id: pick_subset
+    action: ask
+    condition: "{{dg_mode}} == subset"
+    prompt: "Pick the domain rule files to load:"
+    options_from: "{{dg_candidates}}"
+    multi: true
+    answer_var: dg_subset
+
+  # 4. Load the selection into the sticky standards set (system block, D3).
+  - id: load_all
+    action: load_standards
+    condition: "{{dg_mode}} == all"
+    files_from_variable: dg_candidates
+    optional: true
+  - id: load_subset
+    action: load_standards
+    condition: "{{dg_mode}} == subset"
+    files_from_variable: dg_subset
+    optional: true

package/assets/.appweaver/orchestrator/modules/lane-gate.orch.yaml

@@ -0,0 +1,126 @@
+# =============================================================================
+# lane-gate (orchestrator) — shared LANE + SOURCE PATH gate
+#
+# Included by every phase that reads or writes a lane's subtree. It answers one
+# question before that phase starts doing work:
+#
+#     is there a lane of the kind I need, and is its source path really there?
+#
+# WHY A GATE AND NOT A FALLBACK. A phase that cannot find a source path has two
+# options: guess, or stop. Guessing is what the kit did before the lane model —
+# `build` sniffed for a .sln, `run-migrate` hardcoded `src/`, and `implement` let
+# the model decide where files should go. Each of those is right on the layout the
+# guess was written for and quietly wrong on every other one, and "quietly" is the
+# problem: a build that never compiled the frontend still reports green, and a
+# generator that invents a root writes a second copy of the project. Stopping with
+# the fix named costs one command and cannot be misread.
+#
+# WHAT IT DOES NOT DO. It never writes, never repairs a declaration, and never
+# proposes one — select-stack is the sole writer and this module has no opinion
+# about what the answer should be. It also does not require a lane of a kind the
+# caller did not ask for: a backend-only project passes the backend gate and is
+# never asked about a UI lane it declined.
+#
+# Inputs (via include `with`):
+#   require  — the lane kind this phase cannot run without: backend | frontend
+#   command  — the phase being gated, quoted back in the failure message
+#
+# Produces, for the required kind: WHERE it lives (lane_root / lane_source_path),
+# WHAT it is (lane_profile / lane_title / lane_language / lane_ecosystem) and HOW it
+# is driven (lane_build / lane_test / lane_run), plus both kinds' flattened fields,
+# so the caller can put any of them into a prompt or a script argument without a
+# second script call. The identity fields matter as much as the path: a phase that
+# generates code has to name the language it is generating, and `implement` binding
+# the stack from "the active profile" only works if something puts the profile in
+# front of the model.
+# =============================================================================
+
+name: lane-gate
+dialect: aw-spec.orchestrator/v1
+
+# Scripts this module invokes. A module's scripts EXTEND the caller's map (setdefault, so
+# the caller's refs WIN at runtime — these are inert whenever the including workflow already
+# supplies them); declaring them here keeps the module self-contained and validatable on its
+# own, rather than only inside a caller that happens to declare the ref.
+scripts:
+  actions:
+    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
+    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
+
+workflow:
+
+  # 1. Check the declaration. Always exits 0 — the whole point is that the reason
+  #    reaches the gate below as text rather than as a non-zero exit nobody sees.
+  #    The on-disk check is ON here: this module only runs in phases that are about
+  #    to read or write the subtree, which is exactly where a path that is not there
+  #    stops being a normal greenfield state and becomes a defect.
+  - id: verify
+    action: execute_script
+    script: { ref: actions }
+    subcommand: lane-verify
+    args: ["--require", "{{require}}", "--command", "{{command}}"]
+    outputs:
+      - { name: lane_ok,            from: "$.ok" }
+      - { name: lane_issues,        from: "$.message" }
+      - { name: be_lane_id,         from: "$.backend_lane_id" }
+      - { name: be_source_path,     from: "$.backend_source_path" }
+      - { name: be_profile,         from: "$.backend_profile" }
+      - { name: be_title,           from: "$.backend_title" }
+      - { name: be_language,        from: "$.backend_language" }
+      - { name: be_ecosystem,       from: "$.backend_ecosystem" }
+      - { name: be_build,           from: "$.backend_build" }
+      - { name: be_test,            from: "$.backend_test" }
+      - { name: be_run,             from: "$.backend_run" }
+      - { name: fe_lane_id,         from: "$.frontend_lane_id" }
+      - { name: fe_source_path,     from: "$.frontend_source_path" }
+      - { name: fe_profile,         from: "$.frontend_profile" }
+      - { name: fe_title,           from: "$.frontend_title" }
+      - { name: fe_language,        from: "$.frontend_language" }
+      - { name: fe_ecosystem,       from: "$.frontend_ecosystem" }
+      - { name: fe_build,           from: "$.frontend_build" }
+      - { name: fe_test,            from: "$.frontend_test" }
+      - { name: fe_run,             from: "$.frontend_run" }
+
+  - id: gate
+    action: verify_context
+    require_true: lane_ok
+    on_false: stop
+    on_false_message: >
+      {{command}} cannot run: {{lane_issues}}
+      The lane model in .appweaver/stacks.json is what tells this phase which subtree
+      it owns — where to write, what to compile, and what to run. Declaring it is
+      the first step of both the greenfield and the brownfield sequence.
+
+  # 2. Bind the REQUIRED kind's fields to unprefixed names, so a caller that asked
+  #    for one lane reads `lane_source_path` and never repeats the kind it already
+  #    named. Ordered override rather than a branch: the engine has no conditional
+  #    binding, so state the backend case and let a frontend requirement replace it.
+  - id: lane_fields_backend
+    action: set
+    vars:
+      lane_kind: "backend"
+      lane_id: "{{be_lane_id}}"
+      lane_root: "{{be_source_path}}"
+      lane_source_path: "{{be_source_path}}"
+      lane_profile: "{{be_profile}}"
+      lane_title: "{{be_title}}"
+      lane_language: "{{be_language}}"
+      lane_ecosystem: "{{be_ecosystem}}"
+      lane_build: "{{be_build}}"
+      lane_test: "{{be_test}}"
+      lane_run: "{{be_run}}"
+  - id: lane_fields_frontend
+    action: set
+    condition: "{{require}} == frontend"
+    vars:
+      lane_kind: "frontend"
+      lane_id: "{{fe_lane_id}}"
+      lane_root: "{{fe_source_path}}"
+      lane_source_path: "{{fe_source_path}}"
+      lane_profile: "{{fe_profile}}"
+      lane_title: "{{fe_title}}"
+      lane_language: "{{fe_language}}"
+      lane_ecosystem: "{{fe_ecosystem}}"
+      lane_build: "{{fe_build}}"
+      lane_test: "{{fe_test}}"
+      lane_run: "{{fe_run}}"

package/assets/.appweaver/orchestrator/modules/tech-select.orch.yaml

@@ -0,0 +1,123 @@
+# =============================================================================
+# tech-select (orchestrator) — shared TECHNICAL rule-file selection module
+#
+# The technical counterpart of domain-select. Where domain-select loads the
+# per-command DOMAIN rule files from guardrails/projects/<project>/domain-rule-bindings.md,
+# this module loads the per-command TECHNICAL rule files — the project's mapped technical rules and
+# the worked examples/ samples that go with them — from
+#   guardrails/projects/<project>/tech-rule-bindings.md
+# Included (via `action: include`) by every technical-rule consumer so the set is
+# CONFIGURATION, not code — tune the map, not the workflow.
+#
+# Flow (mirrors domain-select):
+#   1. resolve the active domain + candidate technical rule files for {{command}}
+#   2. Selection box: all / subset / none (non-interactive default: all)
+#   3. load the selected files into the STICKY STANDARDS SET (D3: system standards
+#      every later generation sees without the caller re-declaring them)
+#
+# DELIBERATE difference from domain-select: there is NO blocking gate/exit. When
+# the domain or the map is missing the module SOFT-CONTINUES (loads nothing extra)
+# — the technology base still reaches the consumer through constitution.technical.md
+# (referred to directly, as-is — NOT mapped) plus the caller's minimal seed, so an
+# unconfigured / greenfield project is never blocked. This keeps greenfield-safety.
+#
+# Runs in the CALLER's context: shares vars + standards + the caller's `scripts:`
+# map + replay cache (include semantics). HITL steps suspend via the checkpoint
+# channel under every strategy; non-interactive default: selection → all.
+#
+# Input (via include `with`): command = the command name (tech-rule-bindings heading).
+# Produces: tech_domain (+ tg_* internals) and the loaded standards.
+# =============================================================================
+
+name: tech-select
+dialect: aw-spec.orchestrator/v1
+
+# Scripts this module invokes. A module's scripts EXTEND the caller's map (setdefault, so
+# the caller's refs WIN at runtime — these are inert whenever the including workflow already
+# supplies them); declaring them here keeps the module self-contained and validatable on its
+# own, rather than only inside a caller that happens to declare the ref.
+scripts:
+  actions:
+    sh:  .appweaver/scripts/bash/aw-spec-actions.sh
+    ps1: .appweaver/scripts/powershell/aw-spec-actions.ps1
+
+workflow:
+
+  # 1. Resolve the active domain + candidate technical rule files.
+  - id: resolve
+    action: execute_script
+    script: { ref: actions }
+    subcommand: resolve-tech
+    args: ["--command", "{{command}}"]
+    outputs:
+      - { name: tech_domain,        from: "$.domain" }
+      - { name: tg_techmap_exists,  from: "$.techrulemap_exists" }
+      - { name: tg_candidates,      from: "$.candidates" }
+      - { name: tg_mismatch,        from: "$.stack_mismatch" }
+      - { name: tg_mismatched,      from: "$.mismatched_stacks" }
+      - { name: tg_declared_stacks, from: "$.declared_stacks" }
+
+  # 1a. STACK MISMATCH — the map points at a technical corpus for a stack this repo
+  #     does not declare. These files become STICKY STANDARDS: the generator obeys
+  #     them for the rest of the run, so a Spring repo mapped to the .NET corpus is
+  #     told to write C# project layout and EF Core persistence for Java code. That is
+  #     not a soft problem, but it is also not always a mistake — a shared corpus may
+  #     be referenced on purpose — so this ASKS rather than stops. It fires ONLY on a
+  #     real mismatch: nothing declared, no map, or a matching corpus never reaches it,
+  #     which is what keeps the unconfigured and greenfield paths untouched. The
+  #     non-interactive default is the first option, i.e. the historic behaviour.
+  - id: mismatch_ack
+    action: ask
+    condition: "{{tg_mismatch}} == true"
+    prompt: >
+      The technical rule map for `{{tech_domain}}` loads rules from {{tg_mismatched}},
+      but this repository declares {{tg_declared_stacks}}. These files become standards
+      the code generator follows. Proceed?
+    options:
+      - "load them anyway — the corpus applies here"
+      - "stop — fix the map first"
+    answer_var: tg_mismatch_ack
+
+  - id: mismatch_gate
+    action: verify_context
+    condition: "{{tg_mismatch}} == true"
+    require_value: tg_mismatch_ack
+    equals: "load them anyway — the corpus applies here"
+    on_mismatch: stop
+    on_mismatch_message: >
+      Stopped before loading technical rules from {{tg_mismatched}} into a
+      {{tg_declared_stacks}} repository. Point the `## /` headings in
+      guardrails/projects/{{tech_domain}}/tech-rule-bindings.md at a corpus for this
+      stack, or write the corpus segment of the path as a stack PLACEHOLDER (see the
+      header of resolve-tech) so one map resolves from .appweaver/stacks.json and serves
+      every stack this project declares. A corpus
+      for a new stack is a new directory under guardrails/technology/ plus the bullets
+      that map it — no workflow changes.
+
+  # 2. Selection box — only when a tech rule map with candidates exists.
+  #    No-map path: no step fires (both conditions below are false) ⇒ soft-continue.
+  - id: select_mode
+    action: ask
+    condition: "{{tg_candidates}} != []"
+    prompt: "Technical rule files for {{command}}:"
+    options: ["all", "subset", "none"]
+    answer_var: tg_mode
+  - id: pick_subset
+    action: ask
+    condition: "{{tg_mode}} == subset"
+    prompt: "Pick the technical rule files to load:"
+    options_from: "{{tg_candidates}}"
+    multi: true
+    answer_var: tg_subset
+
+  # 3. Load the selection into the sticky standards set (system block, D3).
+  - id: load_all
+    action: load_standards
+    condition: "{{tg_mode}} == all"
+    files_from_variable: tg_candidates
+    optional: true
+  - id: load_subset
+    action: load_standards
+    condition: "{{tg_mode}} == subset"
+    files_from_variable: tg_subset
+    optional: true