aw-spec-cli 0.1.3 → 0.1.5

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

@@ -0,0 +1,79 @@
+# =============================================================================
+# delta-spec (orchestrator module) — author the SPEC-side DELTA of a change
+#
+# Included by /aw-spec-orch 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
+# /aw-spec-orch 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
+
+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)
+      - .aw-spec/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.
+  - 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 the domain applies — Constraints & NFRs
+        (CN-n), Data Classification (DC-n), Integration Contracts (IC-n). A change to a
+        retention/audit rule, a data-exposure rule, or an interop obligation is a
+        CN-/DC-/IC- delta, not a code change.
+      - 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/.aw-spec/orchestrator/modules/domain-select.orch.yaml

@@ -0,0 +1,81 @@
+# =============================================================================
+# 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 comandrulemap → 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 (comandrulemap heading).
+# Produces: domain (+ dg_* internals) and the loaded standards.
+# =============================================================================
+
+name: domain-select
+dialect: aw-spec.orchestrator/v1
+
+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/comandrulemap 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 /aw-spec-orch 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 /aw-spec-orch 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/.aw-spec/orchestrator/modules/tech-select.orch.yaml

@@ -0,0 +1,75 @@
+# =============================================================================
+# 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 docs/domainspecs/<domain>/comandrulemap.md,
+# this module loads the per-command TECHNICAL rule files (the docs/architecture ·
+# docs/security · docs/interop · docs/governance set that used to be HARDCODED in
+# each workflow's `standards:` block) from
+#   docs/domainspecs/<domain>/commandtechrulemap.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 (commandtechrulemap heading).
+# Produces: tech_domain (+ tg_* internals) and the loaded standards.
+# =============================================================================
+
+name: tech-select
+dialect: aw-spec.orchestrator/v1
+
+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" }
+
+  # 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