aw-spec-cli 0.1.5 → 0.1.7

package/assets/.aw-spec/orchestrator/workflows/aw-spec-characterize.orch.yaml

@@ -1,474 +0,0 @@
-# =============================================================================
-# aw-spec-characterize (orchestrator) — B2 of the Brownfield Pipeline
-#
-# The REGRESSION FENCE. After a slice is adopted (spec.md + design.md +
-# source-map.md), pin what the legacy code CURRENTLY DOES as golden-master /
-# characterization tests — observed behaviour asserted AS-IS, bugs and quirks
-# included. These are NOT correctness claims; they are the missing behaviour
-# ORACLE that lets the slice be changed under a net.
-#
-#   inventory → adopt → CHARACTERIZE → [ forward pipeline / parity → cutover ]   ← you are here
-#
-# Characterize is to brownfield what analyze-slice is to greenfield: greenfield verifies
-# against ACs it authored; brownfield verifies against behaviour it OBSERVED. The
-# key inversion vs. analyze-slice: here the CODE is the oracle — if a characterization
-# test disagrees with the running code, the TEST is wrong (fix the assertion to
-# the observed output), never the production code. When a golden-master later
-# MUST change, that is a deliberate, reviewed decision recorded as a MODIFIED spec
-# item via the CR delta loop — never a silent drift.
-#
-# Characterize GENERATES tests only; it does NOT modify production code and does
-# NOT change spec.md / design.md.
-#
-# EXISTING TESTS. A legacy repo usually already has some. They are not a fence — they
-# assert INTENDED behaviour, which is exactly what brownfield cannot assume. So before
-# authoring, characterize scans for overlap and asks the operator how to resolve it
-# (keep both / keep existing / override), defaulting to the additive choice. Overlap only
-# counts when the behaviour AND the seam match and the existing test agrees with the code;
-# an existing test that DISAGREES is a drift finding routed to a CR, never deduped.
-#
-# DRIFT REPORT. Those disagreements are the most valuable thing a brownfield adoption
-# surfaces — intent (what a past author asserted) vs. as-built (what the code does) — so
-# they are not left in a run log: characterize writes them to `drifted-tests.md` beside the
-# slice's spec, one triaged finding per existing test, as the CR queue. It is rewritten on
-# every run (never appended), so it always reflects the CURRENT scan and can never go stale.
-#
-# Launch:  /aw-spec-orch characterize [strategy] [focus/guidance]
-# Prereq:  /aw-spec-orch adopt <Aggregate>  (spec.md + design.md + source-map.md),
-#          and a scaffolded project (/aw-spec-orch foundation) to host + run tests.
-# =============================================================================
-
-name: aw-spec-characterize
-description: Generate golden-master / characterization tests that pin the adopted slice's CURRENT observed behaviour as-is (quirks included), reconciling them against the legacy project's existing tests under an operator-chosen dedup policy, reporting intent-vs-as-built drift to drifted-tests.md, then run them green against the legacy code — the brownfield regression fence. The code is the oracle (fix the test, never the code); does not modify production code or the spec/design.
-version: 1.2.0
-agent_agnostic: true
-dialect: aw-spec.orchestrator/v1
-
-inputs:
-  user_input:
-    description: Optional focus / guidance (an area to prioritize, extra input cases to cover).
-    required: false
-    bind: USER_INPUT
-
-scripts:
-  actions:
-    sh:  .aw-spec/scripts/bash/aw-spec-actions.sh
-    ps1: .aw-spec/scripts/powershell/aw-spec-actions.ps1
-
-# Sticky standards seed = the UNIVERSAL always-on rule only (ai-rules). The FRAMEWORK /
-# test-generation set (same as implement/analyze-slice — HOW to write + place tests) is no
-# longer hardcoded here — it is now CONFIGURATION, loaded per-command from
-# docs/domainspecs/<domain>/commandtechrulemap.md under "## /aw-spec-characterize" by the
-# tech-select module (see the tech_select step below). No domain files: the behaviour to
-# fence comes from the CODE + the adopted spec/design/source-map (constitution.technical.md
-# is referred to directly as context), not from domain rules — the tech map lists only
-# technical files. (missing files skipped at assembly time)
-standards:
-  - { path: docs/glossary/ai-rules.md, optional: true }
-
-vars:
-  test_ok: "false"
-  # Dedup-pass defaults, so the outputs stay readable when the scan finds nothing
-  # (a repo with no pre-existing tests skips the question entirely).
-  dup_count: "0"
-  duplicates: ""
-  drift_count: "0"
-  drift: ""
-  dedup_policy: "Keep both (add the golden-master alongside the existing test)"
-
-workflow:
-
-  # 0. TECHNICAL rule files → sticky standards (configuration, not hardcoded). tech-select
-  #    reads docs/domainspecs/<domain>/commandtechrulemap.md under "## /aw-spec-characterize"
-  #    and loads that test-generation set into the sticky standards the agent_generate steps
-  #    ALWAYS prepend. No domain rule file is loaded here — the tech map lists only technical
-  #    files. No blocking gate: an unconfigured project soft-continues (the golden-master is
-  #    still fenced from the CODE + adopted spec/design/source-map + constitution.technical.md).
-  - id: tech_select
-    action: include
-    module: .aw-spec/orchestrator/modules/tech-select.orch.yaml
-    with: { command: aw-spec-characterize }
-
-  # 1. Resolve the current feature + its adopted artifacts.
-  - id: feature_paths
-    action: execute_script
-    on_error: continue      # never crash raw on 'no feature set' — the gate below explains it
-    script: { ref: actions }
-    subcommand: feature-paths
-    outputs:
-      - { name: feature_dir,   from: "$.feature_dir" }
-      - { name: spec_file,     from: "$.spec_file" }
-      - { name: design_file,   from: "$.design_file" }
-      - { name: spec_exists,   from: "$.spec_exists" }
-      - { name: design_exists, from: "$.design_exists" }
-
-  - id: require_feature
-    action: verify_context
-    require_non_empty: feature_dir
-    on_empty: stop
-    on_empty_message: "No active feature. Run /aw-spec-orch select-feature first (pick or create the aggregate, e.g. Order), then re-run characterize."
-
-  - id: verify_spec
-    action: verify_context
-    require_true: spec_exists
-    on_false: stop
-    on_false_message: "No spec.md for the current feature. Adopt the slice first: /aw-spec-orch adopt <Aggregate>."
-
-  - id: verify_design
-    action: verify_context
-    require_true: design_exists
-    on_false: stop
-    on_false_message: "No design.md for the current feature. Run /aw-spec-orch adopt <Aggregate> (or /aw-spec-orch design) first."
-
-  # 1b. Require the ADOPT source-map sidecar — characterize fences an ADOPTED
-  #     legacy slice (its as-built quirks + owned source files live here).
-  - id: set_source_map
-    action: set
-    vars:
-      source_map: "{{feature_dir}}/source-map.md"
-      # The drift report lives BESIDE the slice's spec (like source-map.md) — it is a
-      # per-slice adoption artifact, not a run log, and is rewritten on every run.
-      drift_report: "{{feature_dir}}/drifted-tests.md"
-  # required_files raises a fixed Stop that NAMES the missing file (it does not
-  # take a custom message) — "required file not in context: specs/<Agg>/source-map.md"
-  # → run /aw-spec-orch adopt first (it writes source-map.md with files + quirks).
-  - id: require_source_map
-    action: verify_context
-    required_files: ["{{source_map}}"]
-
-  # 1c. Require the FOUNDATION — a compiling project — to host + run the tests.
-  - id: detect_foundation
-    action: execute_script
-    script: { ref: actions }
-    subcommand: detect-project
-    outputs:
-      - { name: foundation_present, from: "$.scaffolded" }
-
-  - id: foundation_gate
-    action: verify_context
-    require_true: foundation_present
-    on_false: stop
-    on_false_message: "No scaffolded project found — run /aw-spec-orch foundation <FoundationName> <AppName> first. characterize writes tests INTO the project's test tree and RUNS them; there is nowhere to place/run them without it."
-
-  # 2. Pre-execution hooks.
-  - id: resolve_pre_hooks
-    action: execute_script
-    script: { ref: actions }
-    subcommand: resolve-hooks
-    args: ["--phase", "before_characterize"]
-    outputs:
-      - { name: before_hooks, from: "$.hooks" }
-  - id: dispatch_pre_hooks
-    action: dispatch_hooks
-    hooks_from_variable: before_hooks
-
-  # ═══════ 3. DEDUP PASS — reconcile against the legacy project's EXISTING tests ═══════
-  # A brownfield repo usually ALREADY has unit tests. They are not a fence: they assert
-  # INTENDED behaviour (and may be stale, skipped, or aspirational), whereas a golden-master
-  # asserts OBSERVED behaviour as-is. So they neither substitute for the fence nor are they
-  # disposable — the operator decides. Scan first (read-only), then ask ONLY if the scan
-  # found real overlap, so a repo with no tests is never interrupted.
-  #
-  # Two rules keep this honest, and both live in the scan schema rather than the question:
-  #   • SAME BEHAVIOUR + DIFFERENT SEAM is NOT a duplicate. An existing test that mocks the
-  #     repository and asserts a domain method is COMPLEMENTARY to a golden-master asserting
-  #     the endpoint response; deduping them would punch a hole in the fence, which is
-  #     deliberately pinned at the outermost seam so it survives an internal refactor.
-  #   • DISAGREEMENT IS NOT DUPLICATION. An existing test asserting behaviour the code does
-  #     NOT exhibit is a DRIFT FINDING (intent vs. as-built) — the most valuable thing a
-  #     brownfield adoption surfaces. It is reported, never resolved by the dedup policy:
-  #     overriding it would delete the bug report, and keeping it leaves a red test the
-  #     capture loop cannot reach (that loop only sees char_files). Route it to a CR.
-  - id: ctx_dup_scan
-    action: build_context
-    context:
-      - { path: "{{source_map}}" }
-      - { path: "{{spec_file}}" }
-      - { path: "{{design_file}}" }
-  - id: scan_existing_tests
-    action: agent_query
-    include_standards: false
-    schema:
-      duplicates: [ { behaviour: "<observable behaviour>", spec_id: "<US-/FR-/BR- id>", existing_test: "<file:test-name>", seam: "<endpoint|handler|domain|persistence>", source_file: "<production file it covers>" } ]
-      drift: [ { existing_test: "<file:test-name>", asserts: "<what the test expects>", code_actually: "<what the code does>", source_file: "<production file it covers>", spec_id: "<US-/FR-/BR- id, or ->", test_state: "<failing|ignored|inconclusive>" } ]
-      dup_count: 0
-      drift_count: 0
-    mock: { duplicates: [], drift: [], dup_count: 0, drift_count: 0 }
-    task: |
-      Before any characterization tests are written, survey the project's EXISTING
-      tests for this slice and report where they would OVERLAP the golden-masters
-      about to be generated. Read the slice's production files (listed in
-      source-map.md, in context) and locate the existing test project(s) covering
-      them (glob the test tree; match by class/namespace/file under test).
-      Report, for each observable behaviour of this slice:
-      - `duplicates` — an existing test that pins the SAME behaviour at the SAME (or
-        equivalent) seam AND currently AGREES with what the code does. ONLY these are
-        duplicates. A test at a DIFFERENT seam (e.g. a mocked domain-level unit test vs.
-        an endpoint/persisted-state assertion) is COMPLEMENTARY, not a duplicate — do NOT
-        list it. A skipped/ignored test is NOT a duplicate (it pins nothing) — do not list it.
-      - `drift` — an existing test whose EXPECTATION differs from what the code actually
-        does right now (including tests that are currently failing, or that assert an
-        intended-but-absent behaviour). These are NOT duplicates: they are intent-vs-as-built
-        findings. List them separately; they are reported, never deduped. For each, set
-        `test_state`: `failing` (it runs and is red today — it will also redden the
-        characterize suite run), `ignored` (skipped/commented-out/[Ignore]d, so it is
-        DORMANT intent and blocks nothing), or `inconclusive` (you cannot tell from
-        reading alone — say so rather than guessing). Quote the assertion in `asserts`
-        and the observed behaviour in `code_actually` precisely enough that a reviewer
-        can act without re-reading both files.
-      Set dup_count / drift_count to the list lengths. If the project has no existing
-      tests for this slice, return empty lists and zero counts. Do not modify any file.
-    outputs:
-      - { name: duplicates,  from: "$.duplicates" }
-      - { name: dup_count,   from: "$.dup_count" }
-      - { name: drift,       from: "$.drift" }
-      - { name: drift_count, from: "$.drift_count" }
-
-  # ── DRIFT REPORT ── the scan's second list is the valuable one, so it becomes a durable
-  # per-slice artifact rather than a line in a run log. Written BEFORE the dedup question so
-  # the operator can open it while answering, and UNCONDITIONALLY — a report that is only
-  # written when drift exists would leave a stale file from an earlier run standing after the
-  # drift was resolved, which is worse than no file. A zero-drift run rewrites it to say so.
-  - id: ctx_drift_report
-    action: build_context
-    vars:
-      drift: "{{drift}}"
-      drift_count: "{{drift_count}}"
-    context:
-      - { path: "{{source_map}}" }                # source files + as-built quirks
-      - { path: "{{spec_file}}" }                 # for the US-/FR-/BR- ids to cite
-  - id: write_drift_report
-    action: agent_author
-    include_standards: false                      # a report, not generated code
-    output_target: { type: file, path: "{{drift_report}}" }
-    task: |
-      Author the INTENT-VS-AS-BUILT DRIFT REPORT for this slice: the pre-existing tests
-      whose expectations disagree with what the legacy code actually does. This is the
-      CR queue for the adoption — each finding is a decision someone must make, NOT a
-      thing characterize may fix. {{drift_count}} finding(s) from the scan:
-      {{drift}}
-      Write markdown, in this order:
-      - `# Drifted Tests — <slice>` and a one-line statement of what this file is:
-        pre-existing tests that assert behaviour the code does not exhibit, found while
-        building the regression fence. Note that characterize did NOT change them.
-      - A SUMMARY line: total findings, split by test_state (failing / ignored /
-        inconclusive). Say plainly that `failing` findings are red in the suite TODAY
-        (they will also show in the characterize test run and are not the golden-masters'
-        fault), while `ignored` ones are dormant intent that blocks nothing.
-      - One `##` section per finding, titled with the test. Under it state, each on its
-        own labelled line: the production file it covers, the spec id it maps to (or `—`),
-        its state, what the TEST asserts, what the CODE ACTUALLY does, and a RESOLUTION
-        line offering the reviewer the real choice — either the code is wrong (a defect:
-        open a CR to change the code, and the golden-master pinning today's behaviour
-        must then change with it as a reviewed MODIFIED spec item) or the TEST is wrong /
-        obsolete (delete or correct it in a CR). Recommend one and say why; do not
-        pretend to certainty you do not have — for `inconclusive`, say what must be run
-        or read to decide.
-      - A closing `## How to use this file` noting it is REGENERATED on every
-        `/aw-spec-orch characterize` run (do not edit it in place — resolve findings via
-        CRs and re-run), and that the golden-masters deliberately pin the code's CURRENT
-        behaviour, drift included.
-      If there are no findings, still write the file: the heading, and a short statement
-      that the scan found no pre-existing test disagreeing with the as-built code —
-      keep it to a few lines, invent nothing, and add no empty sections.
-      Do NOT propose edits to production code or to any test in this file.
-    outputs:
-      - { name: drift_report_file, from: "$.files" }
-
-  # The question fires ONLY when the scan found true duplicates, and it shows them, so the
-  # policy is chosen against evidence rather than blind. Option order is load-bearing:
-  # act_ask takes options[0] under --non-interactive, so the ADDITIVE, non-destructive
-  # choice MUST be first — a headless/CI run must never silently delete a hand-written test.
-  # Pin it deterministically in CI with:  --answer dedup_policy="<exact option text>".
-  - id: ask_dedup
-    condition: "{{dup_count}} != 0"
-    action: ask
-    answer_key: dedup_policy
-    prompt: |
-      EXISTING TESTS OVERLAP THIS SLICE'S GOLDEN-MASTERS.
-      {{dup_count}} existing test(s) already pin the same behaviour at the same seam
-      AND agree with the current code:
-      {{duplicates}}
-      How should characterize handle them?
-        - Keep both      = additive and safest. The golden-master is written anyway. The
-                           existing test keeps its INTENT claim; the golden-master adds the
-                           as-is claim at the outer seam. Costs some redundancy.
-        - Keep existing  = skip the golden-master; the existing test IS the fence for that
-                           behaviour. Leanest suite, but the fence then depends on a test
-                           written against intent, and char_files will not list that
-                           behaviour — coverage moves off the recorded fence.
-        - Override       = replace the duplicated existing test with the golden-master.
-                           DESTRUCTIVE: a hand-written test can encode knowledge (why a
-                           boundary is what it is) that is not recoverable from the code.
-                           Only the named duplicates are touched; recover via git.
-    options:
-      - "Keep both (add the golden-master alongside the existing test)"
-      - "Keep existing (skip the golden-master; the existing test is the fence)"
-      - "Override (replace the existing test with the golden-master)"
-    answer_var: dedup_policy
-
-  # 4. GENERATE the characterization / golden-master tests from the OBSERVED
-  #    behaviour of the legacy code. The adopted artifacts frame the surface;
-  #    the CODE is the source of truth (the agent reads it).
-  - id: ctx_characterize
-    action: build_context
-    context:
-      - { path: "{{source_map}}" }                # owned source files + seam + AS-BUILT QUIRKS
-      - { path: "{{spec_file}}" }                 # the observable surface (US / FR / endpoints)
-      - { path: "{{design_file}}" }               # structure (handlers, events, ports)
-      - { path: .aw-spec/memory/constitution.technical.md, optional: true } # stack + test framework
-  - id: generate
-    action: agent_generate
-    tools: "Read,Write,Edit"
-    permission_mode: acceptEdits
-    task: |
-      Generate CHARACTERIZATION / golden-master tests for this adopted slice that
-      pin what the legacy code CURRENTLY DOES — the regression fence. READ the
-      slice's PRODUCTION code (the files listed in source-map.md, in context) and
-      OBSERVE its actual behaviour; the spec.md + design.md (in context) frame the
-      observable surface. Guidance: {{USER_INPUT}}
-      Rules:
-      - ASSERT OBSERVED BEHAVIOUR, AS-IS. Capture what the code returns/emits/persists
-        for representative inputs RIGHT NOW — bugs and quirks INCLUDED. Do NOT assert
-        ideal/intended behaviour, and do NOT "correct" anything. Every "as-built quirk"
-        recorded in source-map.md MUST get a test that pins that quirk explicitly (name
-        it so a reader knows it is a captured quirk, not a desired outcome).
-      - These are a REGRESSION FENCE, not correctness claims. Mark each test as a
-        characterization/golden-master (class/file name + a header comment stating
-        "captures CURRENT behaviour as-is; a change here is a reviewed CR decision").
-        Cite the source file and the spec id (US-/FR-/BR-) it pins, and the quirk id
-        where relevant.
-      - COVERAGE: one test per observable behaviour — each command / query / endpoint
-        / handler path, each domain invariant, each emitted event and resulting state.
-        Choose representative inputs: the happy path, boundaries, and the quirk cases.
-        Prefer the OUTERMOST observable seam (endpoint / handler response, emitted
-        event, persisted state) over private internals, so the fence survives an
-        internal refactor.
-      - BIND THE STACK + test framework from the constitution + the project's EXISTING
-        test project conventions; place files in the test tree per folder-structure and
-        match the surrounding test style. Reuse existing fixtures/builders.
-      - Do NOT modify any PRODUCTION code — tests only. Do NOT edit spec.md / design.md.
-        If a behaviour is genuinely non-deterministic (time, random, external I/O),
-        pin it via the seam the code already exposes (clock/port) or assert the stable
-        shape; note it in the test rather than asserting a flaky value.
-      - DEDUP — the operator chose: {{dedup_policy}}
-        It applies ONLY to these already-identified duplicates (same behaviour, same seam,
-        agreeing with the code). Every OTHER behaviour still gets its golden-master, and no
-        test outside this list may be edited or deleted for any reason:
-        {{duplicates}}
-          • "Keep both"     → write the golden-master anyway; leave the existing test
-                              untouched. In the golden-master's header comment, name the
-                              existing test it doubles, so a reader knows the redundancy is
-                              deliberate (as-is claim vs. the existing intent claim).
-          • "Keep existing" → do NOT write a golden-master for that behaviour. Instead add a
-                              header comment IN THIS SLICE'S golden-master file recording the
-                              delegation ("FR-x fenced by <file:test-name> — no golden-master
-                              by operator decision"), so the fence stays auditable even though
-                              char_files will not list that behaviour.
-          • "Override"      → write the golden-master, then remove ONLY the specific duplicated
-                              test METHOD/case named above — never a whole file wholesale, never
-                              a neighbouring test. State in the golden-master's header which
-                              test it supersedes and why.
-      - DRIFT — do NOT act on these. {{drift_count}} existing test(s) disagree with what the
-        code actually does; they are intent-vs-as-built findings, not duplicates. Leave them
-        exactly as they are (do not fix, delete, or "align" them) and pin the code's ACTUAL
-        behaviour in your golden-master as usual. They are already reported in
-        {{drift_report}}; resolving them is a reviewed CR decision:
-        {{drift}}
-    outputs:
-      - { name: char_files, from: "$.files" }
-
-  - id: verify_generated
-    action: verify_context
-    require_non_empty: char_files
-    on_empty: stop
-    on_empty_message: "No characterization tests were generated. Ensure source-map.md lists the slice's source files (from /aw-spec-orch adopt) and re-run."
-
-  # 5. GREEN-RUN the fence: the golden-masters MUST pass against the CURRENT code
-  #    (a capture that fails the live code is a wrong capture). The CODE is the
-  #    ORACLE — on failure, fix the TEST to match observed behaviour, NEVER the
-  #    production code. Bounded (3×).
-  - id: capture_loop
-    action: loop
-    while: "{{test_ok}} != true"
-    max_iterations: 3
-    steps:
-      - id: run_tests
-        action: execute_script
-        on_error: continue
-        script: { ref: actions }
-        subcommand: test-run
-        args: ["--feature-dir", "{{feature_dir}}"]
-        outputs:
-          - { name: test_ok,   from: "$.ok" }
-          - { name: test_tool, from: "$.tool" }
-          - { name: test_log,  from: "$.log_tail" }
-      - id: green_break
-        action: break
-        condition: "{{test_ok}} == true"
-      - id: ctx_fix
-        action: build_context
-        vars:
-          test_log: "{{test_log}}"
-        context:
-          - { path: "{{source_map}}" }
-        context_from: char_files                   # the generated golden-master tests
-      - id: fix
-        action: agent_generate
-        tools: "Read,Write,Edit,Bash"
-        permission_mode: acceptEdits
-        task: |
-          A characterization test failed. In characterize the legacy CODE is the
-          ORACLE — its current behaviour is correct BY DEFINITION here. So make the
-          fence green by fixing the TESTS (in context), NOT the production code:
-          - If an assertion's EXPECTED value differs from what the code actually
-            returns/emits/persists, correct the expected value to the OBSERVED output
-            (read the code / run it to confirm) — that is the whole point of a
-            golden-master.
-          - If a generated test has a COMPILE or setup error, fix the test code.
-          - If a test encodes an INTENDED-but-absent behaviour (the code does not do
-            it), DELETE that test — desired behaviour belongs in a CR/spec MODIFIED
-            item, not a golden-master of current behaviour.
-          NEVER modify production code to make a characterization test pass — that
-          would alter the very behaviour you are fencing.
-          SCOPE: fix ONLY the golden-master files in context. The suite also contains the
-          legacy project's PRE-EXISTING tests; a failure in one of those is NOT yours to
-          fix — it is an intent-vs-as-built finding for a CR, and the ones already known
-          are listed in {{drift_report}}. Do not edit, delete, or skip a pre-existing test
-          to make the run green. Test log:
-          {{test_log}}
-        outputs:
-          - { name: fixed_files, from: "$.files" }
-
-  - id: characterize_gate
-    action: verify_context
-    require_true: test_ok
-    on_false: stop
-    on_false_message: "The characterization fence is not green after 3 attempts (last log: {{test_log}}). Either the captured behaviour still mismatches the code (fix the TEST assertions to the observed output) or the project does not build. The code is the oracle — never change production code to pass a golden-master."
-
-  # 6. Post-execution hooks.
-  - id: resolve_post_hooks
-    action: execute_script
-    script: { ref: actions }
-    subcommand: resolve-hooks
-    args: ["--phase", "after_characterize"]
-    outputs:
-      - { name: after_hooks, from: "$.hooks" }
-  - id: dispatch_post_hooks
-    action: dispatch_hooks
-    hooks_from_variable: after_hooks
-
-outputs:
-  feature_dir: "{{feature_dir}}"
-  spec_file: "{{spec_file}}"
-  source_map: "{{source_map}}"
-  characterization_tests: "{{char_files}}"
-  test_tool: "{{test_tool}}"
-  # Dedup audit trail: what overlapped, how it was resolved, and what drifted. `drift` is
-  # the CR queue — existing tests whose intent disagrees with the as-built code.
-  existing_test_duplicates: "{{dup_count}}"
-  dedup_policy: "{{dedup_policy}}"
-  intent_drift_count: "{{drift_count}}"
-  intent_drift: "{{drift}}"
-  drift_report: "{{drift_report}}"
-  next: "Regression fence is GREEN against the legacy code. The slice can now be changed under a net: refine/re-implement via the forward loop + CR delta (a golden-master that MUST change = a MODIFIED spec item, reviewed — never a silent drift). If intent_drift_count is non-zero, READ {{drift_report}} and open a CR per finding — those pre-existing tests assert behaviour the code does not have, and each one is either a defect in the code or an obsolete test. Next brownfield gate: /aw-spec-orch parity (legacy vs. new, per slice) before cutover."

package/assets/.aw-spec/orchestrator/workflows/aw-spec-close-delta.orch.yaml

@@ -1,181 +0,0 @@
-# =============================================================================
-# aw-spec-close-delta (orchestrator) — ARCHIVE the change + bump the version
-#
-# The last of the five CR stages, and the counterpart of finalize-delta:
-#   finalize-delta  MERGES the delta into the master docs  (the change stays OPEN)
-#   close-delta     ARCHIVES the change + bumps the version (the change is CLOSED)
-#
-#   specify → design → analyze-delta-design → implement-delta → build
-#       → finalize-delta → analyze-slice → close-delta        ← you are here
-#
-# WHY THE SPLIT. finalize-delta used to do both. Merging first lets analyze-slice run
-# against a master spec.md/design.md that ALREADY carries the change — so its fix loops
-# repair code against the true, current requirements with no delta-awareness needed. But
-# if the close travelled with the merge, a red analyze-slice would land on a change that
-# was already archived and version-bumped: the only remedy would be a NEW change to
-# repair the one just shipped. Deferring the close to here keeps the change OPEN across
-# analyze-slice, so a red gate is still "fix and re-run", and the version is stamped only
-# once the slice is green, domain-conformant and has not broken a referrer.
-#
-# This stage AUTHORS nothing and generates NO code — no model is invoked. It moves
-# changes/<id>/ into changes/archive/, bumps the minor version, clears active_change,
-# and STAMPS that version into the `**Version**:` header of spec.md + design.md — the
-# single irreversible act of the CR loop, deliberately isolated in a stage of its own.
-#
-# THE VERSION SPINE LIVES HERE, AND ONLY HERE. The number has three carriers — spec.md's
-# header, design.md's header, active_version.json — and all three move in this one step
-# by one deterministic mechanism. Before, design.md's header was bumped by the MODEL at
-# finalize-delta (a stage early, and guessing the target since the number was never
-# passed into the merge prompt) while spec.md's header was bumped by nobody at all,
-# leaving the "living truth" document permanently at v1.0. finalize-delta now writes the
-# Change History rows using version-read's `next_version` — the same bump() authority
-# this stage applies — and touches neither header.
-#
-# NOTE: nothing MECHANICALLY proves analyze-slice ran green before this point — the
-# stage boundary is operator-driven, as everywhere else in this pipeline. What IS
-# enforced is the reverse: while a change is open, `specify` refuses to open another on
-# the same feature (_active_version's open-guard), so a forgotten close-delta blocks the
-# next change rather than passing silently.
-#
-# Launch:  /aw-spec-orch close-delta [strategy]
-# Prereq:  an OPEN change whose delta was merged by finalize-delta and whose slice
-#          passed /aw-spec-orch analyze-slice.
-# =============================================================================
-
-name: aw-spec-close-delta
-description: Close the open change — archive changes/<id>/ into changes/archive/, bump the minor version, clear active_change, and stamp that version into spec.md's and design.md's headers, then anchor the close in the OKF freshness log. The final CR stage, run after finalize-delta merged the delta and analyze-slice verified the slice. The sole owner of the version spine; invokes no model and generates no code.
-version: 1.1.0
-agent_agnostic: true
-dialect: aw-spec.orchestrator/v1
-
-scripts:
-  actions:
-    sh:  .aw-spec/scripts/bash/aw-spec-actions.sh
-    ps1: .aw-spec/scripts/powershell/aw-spec-actions.ps1
-  xref:
-    sh:  .aw-spec/scripts/bash/aw-xref.sh
-    ps1: .aw-spec/scripts/powershell/aw-xref.ps1
-
-# No standards seed and no domain/tech rule selection: this stage authors nothing, so it
-# has no prompt to govern. It is pure bookkeeping over active_version.json + changes/ +
-# the two version headers.
-standards: []
-
-vars:
-  active_change: ""
-  has_change: "false"
-  version: ""
-  stamped_docs: ""      # which master headers version-stamp actually rewrote
-  stamped_count: "0"
-
-workflow:
-
-  # 1. Resolve the active feature.
-  - id: feature_paths
-    action: execute_script
-    on_error: continue      # never crash raw on 'no feature set' — the gate below explains it
-    script: { ref: actions }
-    subcommand: feature-paths
-    outputs:
-      - { name: feature_dir, from: "$.feature_dir" }
-      - { name: spec_file,   from: "$.spec_file" }
-
-  - id: require_feature
-    action: verify_context
-    require_non_empty: feature_dir
-    on_empty: stop
-    on_empty_message: "No active feature. Run /aw-spec-orch select-feature first (pick or create the aggregate, e.g. Order), then re-run close-delta."
-
-  # 2. There must be a change to close. On the BOOTSTRAP path (implement → build →
-  #    analyze-slice) there is none and this stage does not apply at all.
-  - id: read_change
-    action: execute_script
-    script: { ref: actions }
-    subcommand: version-read
-    args: ["--feature-dir", "{{feature_dir}}"]
-    outputs:
-      - { name: active_change, from: "$.active_change" }
-      - { name: has_change,    from: "$.has_change" }
-      - { name: version,       from: "$.version" }
-
-  - id: require_change
-    action: verify_context
-    require_true: has_change
-    on_false: stop
-    on_false_message: "No open change on this feature — nothing to close. A change is opened by /aw-spec-orch specify (or design) and merged by /aw-spec-orch finalize-delta before it can be closed here. If you have not merged yet, run /aw-spec-orch finalize-delta → analyze-slice first."
-
-  # 3. Pre-execution hooks.
-  - id: resolve_pre_hooks
-    action: execute_script
-    script: { ref: actions }
-    subcommand: resolve-hooks
-    args: ["--phase", "before_close_cr"]
-    outputs:
-      - { name: before_hooks, from: "$.hooks" }
-  - id: dispatch_pre_hooks
-    action: dispatch_hooks
-    hooks_from_variable: before_hooks
-
-  # 4. THE CLOSE. Moves changes/{{active_change}}/ to changes/archive/, bumps the minor
-  #    version in active_version.json and clears active_change. Idempotent on the
-  #    directory (an already-moved change leaves archived_dir empty) but NOT on the
-  #    version — the bump fires whenever a change was open, which the gate above
-  #    guarantees. This is the irreversible step of the CR loop.
-  - id: archive
-    action: execute_script
-    script: { ref: actions }
-    subcommand: cr-archive
-    args: ["--feature-dir", "{{feature_dir}}", "--cr-id", "{{active_change}}"]
-    outputs:
-      - { name: version,          from: "$.version" }
-      - { name: previous_version, from: "$.previous" }
-      - { name: archived_dir,     from: "$.archived_dir" }
-
-  # 4b. STAMP the number just computed into the two master headers, so spec.md,
-  #     design.md and active_version.json all carry it from the same instant by the
-  #     same mechanism. Previously design.md's header was bumped by the MODEL back at
-  #     finalize-delta (guessing the target — the number was never passed to it) and
-  #     spec.md's header was bumped by nobody, so it sat at v1.0 for the life of the
-  #     feature. Deterministic and idempotent; only the header value moves.
-  - id: stamp_version
-    action: execute_script
-    script: { ref: actions }
-    subcommand: version-stamp
-    args: ["--feature-dir", "{{feature_dir}}", "--version", "{{version}}"]
-    outputs:
-      - { name: stamped_docs,  from: "$.stamped" }
-      - { name: stamped_count, from: "$.count" }
-
-  # 5. Anchor the CLOSE in the OKF bundle's freshness journal (log.md, OKF §7).
-  #    finalize-delta logs the MERGE; this logs the SHIP — the version bump is the event
-  #    a reader of the journal is looking for. Best-effort + git-aware: a no-op when there
-  #    is no bundle or no commit, so it never writes a non-conformant block.
-  - id: xref_log
-    action: execute_script
-    on_error: continue
-    script: { ref: xref }
-    subcommand: log
-    args: ["--note", "CR {{active_change}} closed — archived, version {{previous_version}} -> {{version}}"]
-    outputs:
-      - { name: xref_log, from: "$.log" }
-
-  # 6. Post-execution hooks.
-  - id: resolve_post_hooks
-    action: execute_script
-    script: { ref: actions }
-    subcommand: resolve-hooks
-    args: ["--phase", "after_close_cr"]
-    outputs:
-      - { name: after_hooks, from: "$.hooks" }
-  - id: dispatch_post_hooks
-    action: dispatch_hooks
-    hooks_from_variable: after_hooks
-
-outputs:
-  feature_dir: "{{feature_dir}}"
-  cr_id: "{{active_change}}"
-  version: "{{version}}"
-  previous_version: "{{previous_version}}"
-  archived_dir: "{{archived_dir}}"
-  stamped_docs: "{{stamped_docs}}"
-  next: "Change {{active_change}} CLOSED — archived to {{archived_dir}}, version {{previous_version}} -> {{version}}, stamped into {{stamped_count}} master header(s) ({{stamped_docs}}). spec.md, design.md and active_version.json now all read {{version}}; the masters describe the shipped state and the feature is free to take a new change. Next: /aw-spec-orch run → deploy, or start the next change with /aw-spec-orch specify."