aw-spec-cli 0.1.16 → 0.1.18

package/assets/.appweaver/orchestrator/workflows/aw-spec-analyze-slice-delta.orch.yaml

@@ -0,0 +1,643 @@
+# =============================================================================
+# aw-spec-analyze-slice-delta (orchestrator) — the DELTA spec↔code gate
+#
+# The fourth conformance gate, and the one the CR loop was missing. The family is a
+# 2×2 — static vs dynamic, master vs change — and only three corners were built. Every
+# corner is anchored on the REQUIREMENTS; what changes across the grid is what they are
+# compared to, and which set of them is in scope:
+#
+#                       MASTER (bootstrap)          CHANGE (delta)
+#   STATIC  spec↔plan   analyze-plan                analyze-plan-delta
+#   DYNAMIC spec↔code   analyze-slice               analyze-slice-delta   ← this
+#
+# WHAT IT ANSWERS, AND WHY analyze-slice CANNOT. analyze-slice scores the WHOLE slice
+# against the MERGED master, and it is test-driven: a behaviour that is implemented WRONG
+# fails its paired test and is caught. A behaviour that was never implemented AT ALL leaves
+# no failing test — it leaves NO test — so nothing fails and the gate reports green. That
+# is not a hypothetical state: `implement` skips a lane whose plan or project is missing and
+# ASKS before each lane, so "the frontend half of this change was declined and nobody
+# noticed" is reachable. Merge that and spec.md asserts behaviour with no code behind it.
+# This gate asks the question analyze-slice structurally cannot, and asks it of the CHANGE'S
+# OWN REQUIREMENTS: does the code do what this delta spec asked for?
+#
+# IT RUNS BEFORE finalize-delta, WHICH IS THE POINT. The existing fence there refuses a
+# change that BREAKS A DEPENDENT; this is the same principle one step earlier — a change
+# that WAS NOT IMPLEMENTED must not reach the master documents either. It is also the first
+# time anything RUNS the tests on the change path: `build` only compiles, so without this
+# stage a change whose new tests are red is merged into spec.md and domain-model.md before
+# a single one of them has been executed.
+#
+#   specify → plan → analyze-plan-delta → implement → build
+#       → analyze-slice-delta   ← you are here
+#       → finalize-delta → analyze-slice → close-delta
+#
+# delta-spec.md IS THE ANCHOR — THE REQUIREMENTS, NOT THE PLAN. This gate asks whether the
+# change DOES WHAT IT WAS ASKED TO DO, and the thing that asked is the delta spec (plus the
+# invariants in the change's model delta, which are requirements too). Every gate in this
+# family anchors the same way: spec.md anchors analyze-plan and analyze-slice, delta-spec.md
+# anchors analyze-plan-delta and this.
+#   ANCHORING ON THE PLAN INSTEAD WOULD MISS THE WORST CASE. A plan-anchored gate can only
+#   ever ask "did the code do what the plan said" — so a requirement that BOTH the plan and
+#   the code dropped comes back green, because nothing in its evidence ever mentioned it.
+#   The delta spec is the only document that knows the change was asked for at all.
+# The DELTA PLAN is in context as the MAP, not the authority: it says which element serves
+# which requirement, so a finding can point at the place the behaviour was supposed to land
+# instead of just reporting a requirement as absent. It is also cross-checked in its own
+# right (check 3), because an element the plan promised and nobody built is a real defect
+# even when the requirement it served looks satisfied elsewhere.
+# The MASTERS are read-only context for what was already there — nothing here compares the
+# slice to a master that does not yet carry the change.
+#
+# IT VERIFIES; IT NEVER BUILDS AND NEVER REPAIRS. An unrealised requirement means the code
+# was never generated, and generating it here would do it with none of `implement`'s inputs — no
+# lane rule set, no constitution, no stack binding — which is the same reason analyze-plan
+# stops naming `/appweaver plan` instead of filling an empty template itself. So every
+# finding is REPORTED with the command that closes it (implement for missing code, plan for
+# a delta plan that is wrong, specify for a spec or model gap) and the gate stops. The
+# repair loops stay in analyze-slice, where the merged master is the anchor and the job is
+# fixing what is BROKEN rather than building what is ABSENT.
+#
+# NO NEW RULE-MAP HEADING. It loads `## /aw-spec-analyze-slice` — the same testing +
+# coding-standards set its master twin reads — so no project has to add configuration to
+# get this gate. The DOMAIN gate overlays are deliberately NOT loaded: full domain
+# conformance of the slice is analyze-slice's pass 2, against the merged model, and running
+# it twice against two different versions of the model is how one gate contradicts another.
+# The invariants THIS CHANGE adds are checked here anyway, from its model delta, because
+# they are requirements of the change rather than standing domain policy.
+#
+# Launch:  /appweaver analyze-slice-delta [CR-id]
+# Prereq:  /appweaver implement (this change) then /appweaver build.
+# =============================================================================
+
+name: aw-spec-analyze-slice-delta
+version: 1.0.0
+description: "The delta-spec↔delta-code gate — verify that the open change DOES WHAT IT WAS ASKED TO DO, before it reaches the master documents. delta-spec.md is the anchor, exactly as it is for analyze-plan-delta. Asks which open change it is gating, runs the slice's tests (the first execution on the change path, since build only compiles), then evaluates the code and its paired tests against the change's REQUIREMENTS — every ADDED or MODIFIED delta-spec item realised in code, every one covered by a test that cites its id, every invariant the model delta adds actually enforced — with the delta plan in context as the map from requirement to code and cross-checked in its own right, so an element the plan promised and nobody built is caught too. The dynamic twin of analyze-plan-delta and the delta twin of analyze-slice, which cannot see a missing implementation because a behaviour that was never built leaves no failing test. Verify-only — it reports each finding with the command that closes it and stops; it generates no code and repairs nothing."
+agent_agnostic: true
+dialect: aw-spec.orchestrator/v1
+
+inputs:
+  user_input:
+    description: "Optional — a bare CR id selects which open change to gate without a prompt."
+    required: false
+    bind: USER_INPUT
+
+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
+
+# Sticky standards seed = the UNIVERSAL always-on rule only. A gate needs it above all: a
+# gate passes when it RAN and returned a pass, never by inference. The technical set
+# (testing + coding-standards — what a paired test has to look like for check 2 to mean
+# anything) is loaded per-command by tech-select, under analyze-slice's own heading.
+standards:
+  - { path: .appweaver/ai-rules.md }   # kit-resident: the universal operating rules, every flow
+
+vars:
+  cr_id: ""
+  cr_choice: ""
+  cr_dir: ""
+  wave: ""
+  has_changes: "false"
+  delta_spec: ""
+  delta_model: ""
+  delta_backend_plan: ""
+  delta_backend_plan_exists: "false"
+  delta_frontend_plan: ""
+  delta_frontend_plan_exists: "false"
+  domain_model: ""
+  # WHICH LANES THIS GATE CHECKS — a lane is gated when it is DECLARED and this change has
+  # a delta plan for it. An experience-untouched change has no frontend delta plan, and
+  # skipping that lane's checks is correct rather than a pass by omission. Each AND is an
+  # ordered assignment; the engine has no compound conditions.
+  be_declared: "false"
+  fe_declared: "false"
+  be_gated: "false"
+  fe_gated: "false"
+  any_lane: "false"
+  # Slice evidence.
+  source_files: []
+  source_count: "0"
+  test_ok: "false"
+  test_tool: ""
+  test_log: ""
+  test_scoped: "false"
+  test_ran: "false"
+  test_matched: "false"
+  # Verdict.
+  requirements_ok: "false"
+  gate_ok: "false"
+
+workflow:
+
+  # 0. TECHNICAL rule files → sticky standards. Keyed on `## /aw-spec-analyze-slice`, NOT on
+  #    a heading of this command's own name: the set this gate needs is exactly the
+  #    set its master twin reads, and inventing a heading would silently load nothing in
+  #    every project that has not been reconfigured. No blocking gate — an unconfigured
+  #    project soft-continues and the checks below still run on the documents themselves.
+  - id: tech_select
+    action: include
+    module: .appweaver/orchestrator/modules/tech-select.orch.yaml
+    with: { command: aw-spec-analyze-slice }
+
+  # 1. WHICH LANES EXIST. Declaration only — this gate reads code, it does not write it, so
+  #    it has no reason to require a source path on disk.
+  - id: lane_resolve
+    action: execute_script
+    on_error: continue
+    script: { ref: actions }
+    subcommand: lane-resolve
+    outputs:
+      - { name: lanes_declared, from: "$.declared" }
+      - { name: be_declared,    from: "$.backend_declared" }
+      - { name: be_lane_id,     from: "$.backend_lane_id" }
+      - { name: be_source_path, from: "$.backend_source_path" }
+      - { name: fe_declared,    from: "$.frontend_declared" }
+      - { name: fe_lane_id,     from: "$.frontend_lane_id" }
+      - { name: fe_source_path, from: "$.frontend_source_path" }
+
+  - id: require_lane
+    action: verify_context
+    require_true: lanes_declared
+    on_false: stop
+    on_false_message: "No lane is declared in .appweaver/stacks.json, so there is no code to gate. Run /appweaver select-stack, then take the change through /appweaver plan → analyze-plan-delta → implement → build before gating it here."
+
+  # 2. The active feature.
+  - id: feature_paths
+    action: execute_script
+    on_error: continue
+    script: { ref: actions }
+    subcommand: feature-paths
+    outputs:
+      - { name: feature,       from: "$.feature" }
+      - { name: feature_dir,   from: "$.feature_dir" }
+      - { name: spec_file,     from: "$.spec_file" }
+      - { name: backend_plan,  from: "$.backend_plan" }
+      - { name: frontend_plan, from: "$.frontend_plan" }
+
+  - id: require_feature
+    action: verify_context
+    require_non_empty: feature_dir
+    on_empty: stop
+    on_empty_message: "No active feature. Run /appweaver select-feature first (pick the aggregate, e.g. Order), then re-run analyze-slice-delta."
+
+  # 3. WHICH CHANGE. Same selection contract as plan, analyze-plan-delta and implement:
+  #    cr-list enumerates the open changes (evidence = changes/<CR-id>/ on disk), a bare CR
+  #    id in the argument auto-selects, one open change auto-confirms, and the pick is
+  #    ACTIVATED so finalize-delta and close-delta act on the change this gate cleared.
+  - id: cr_list
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-list
+    args: ["--feature-dir", "{{feature_dir}}", "--preselect", "{{USER_INPUT}}"]
+    outputs:
+      - { name: change_options, from: "$.select_options" }
+      - { name: matched_label,  from: "$.matched_label" }
+      - { name: has_changes,    from: "$.has_changes" }
+      - { name: change_count,   from: "$.count" }
+
+  - id: require_change
+    action: verify_context
+    require_true: has_changes
+    on_false: stop
+    on_false_message: "No open change on this feature — there is no delta to gate. This is the CHANGE path's gate; on the bootstrap path the whole slice is gated by /appweaver analyze-slice after build. A change is opened by /appweaver specify."
+
+  - id: pick_change
+    action: user_select
+    prompt: "Which open change is being gated? This checks that the change was actually BUILT, before finalize-delta merges it into the masters."
+    options_from_variable: change_options
+    preselect_from: matched_label
+    single_option_confirm: true
+    outputs:
+      - { name: cr_choice, from: selection }
+
+  - id: activate
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-activate
+    args: ["--cr-id", "{{cr_choice}}", "--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: active_change, from: "$.active_change" }
+
+  - id: cr_paths
+    action: execute_script
+    script: { ref: actions }
+    subcommand: cr-paths
+    args: ["--cr-id", "{{cr_choice}}", "--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: cr_id,                     from: "$.cr_id" }
+      - { name: cr_dir,                    from: "$.cr_dir" }
+      - { name: delta_spec,                from: "$.delta_spec" }
+      - { name: delta_model,               from: "$.delta_model" }
+      - { name: delta_backend_plan,        from: "$.delta_backend_plan" }
+      - { name: delta_backend_plan_exists, from: "$.delta_backend_plan_exists" }
+      - { name: delta_frontend_plan,       from: "$.delta_frontend_plan" }
+      - { name: delta_frontend_plan_exists, from: "$.delta_frontend_plan_exists" }
+      - { name: wave,                      from: "$.wave" }
+      - { name: domain_model,              from: "$.domain_model" }
+
+  # 3a. WHICH LANES ARE GATED — declared AND this change has a delta plan for that lane.
+  - id: be_gated_flag
+    condition: "{{delta_backend_plan_exists}} == true"
+    action: set
+    vars: { be_gated: "{{be_declared}}" }
+  - id: fe_gated_flag
+    condition: "{{delta_frontend_plan_exists}} == true"
+    action: set
+    vars: { fe_gated: "{{fe_declared}}" }
+  - id: any_lane_be
+    condition: "{{be_gated}} == true"
+    action: set
+    vars: { any_lane: "true" }
+  - id: any_lane_fe
+    condition: "{{fe_gated}} == true"
+    action: set
+    vars: { any_lane: "true" }
+
+  - id: require_any_lane
+    action: verify_context
+    require_true: any_lane
+    on_false: stop
+    on_false_message: "Change {{cr_id}} has no delta plan for any declared lane — backend declared {{be_declared}} (delta plan {{delta_backend_plan_exists}}), frontend declared {{fe_declared}} (delta plan {{delta_frontend_plan_exists}}). There is nothing to gate the code against. Run /appweaver plan {{cr_id}} to author the delta plans, then analyze-plan-delta → implement → build, and gate it here."
+
+  # 4. THE SLICE'S REAL SOURCE FILES, from its OKF concept — the same resolution
+  #    analyze-slice uses. They arrive as a PATH LIST and the check steps declare
+  #    `tools: Read`, because a slice does not fit in a payload. THE PLANS CARRY NO PATHS,
+  #    BY CONTRACT: they are technology-agnostic, so an ADDED element names a type, a
+  #    use-case or an endpoint and never a file. That is why this gate is a model pass over
+  #    real files rather than a deterministic existence check — the same reason design-paths
+  #    was retired when the plan stopped carrying ```lang path=…``` fences.
+  - id: concept_paths
+    action: execute_script
+    on_error: continue
+    script: { ref: xref }
+    subcommand: concept-paths
+    args: ["--feature-dir", "{{feature_dir}}"]
+    outputs:
+      - { name: source_files, from: "$.paths" }
+      - { name: source_count, from: "$.count" }
+
+  - id: require_source
+    action: verify_context
+    require_non_empty: source_files
+    on_empty: stop
+    on_empty_message: "The OKF concept for {{feature}} lists no source files, so there is no implementation to gate. Either /appweaver implement has not run for change {{cr_id}} yet, or it ran and reported no files. Run /appweaver implement {{cr_id}} → build, then re-run this gate."
+
+  # 5. Pre-execution hooks.
+  - id: resolve_pre_hooks
+    action: execute_script
+    script: { ref: actions }
+    subcommand: resolve-hooks
+    args: ["--phase", "before_analyze_slice_cr"]
+    outputs:
+      - { name: before_hooks, from: "$.hooks" }
+  - id: dispatch_pre_hooks
+    action: dispatch_hooks
+    hooks_from_variable: before_hooks
+
+  # ═══════════════ PASS 1 — BEHAVIOUR. Run the slice's tests. ═══════════════
+  # THE FIRST EXECUTION ON THE CHANGE PATH. `build` compiles and does not test, and
+  # analyze-slice does not run until after finalize-delta — so without this the change's own
+  # new tests are merged into the masters before anything has run them once.
+  # scope=slice: this feature's tests only. Referring aggregates are the downstream fence's
+  # subject in finalize-delta and the integrity pass's in analyze-slice; this gate is about
+  # THIS change.
+  # NO FIX LOOP, deliberately — see the header. A red fence is reported and stops.
+  - id: run_tests
+    action: execute_script
+    on_error: continue
+    script: { ref: actions }
+    subcommand: test-run
+    args: ["--feature-dir", "{{feature_dir}}", "--scope", "slice"]
+    outputs:
+      - { name: test_ok,      from: "$.fence_green" }
+      - { name: test_tool,    from: "$.tool" }
+      - { name: test_log,     from: "$.log_tail" }
+      - { name: test_scoped,  from: "$.scoped" }
+      # A GREEN FENCE IS NOT ALWAYS AN EXECUTED SUITE. test-run reports fence_green true
+      # with ran=false on a project whose lanes declare no test command — the vacuous pass
+      # its own ladder warns about. It is not made fatal here (that would fail every project
+      # that has not declared one, and analyze-slice scores the same fence the same way),
+      # but it IS reported, so "BUILT ✓" is never read as "the tests passed" when nothing
+      # ran. The requirement checks below are what actually answer whether the change
+      # does what it asked for, and they do not depend on a suite existing.
+      - { name: test_ran,     from: "$.ran" }
+      - { name: test_matched, from: "$.matched" }
+
+  # ══════ PASS 2 — REQUIREMENTS. Does the code do what the change asked for? ══════
+  # THE REQUIREMENTS ARE THE ANCHOR; the plan is the map; the masters are read-only context
+  # for what was already there. Per lane, because the two lanes' evidence is disjoint and a
+  # lane with no delta plan is not gated.
+  - id: ctx_backend
+    condition: "{{be_gated}} == true"
+    action: build_context
+    context:
+      - { path: "{{delta_spec}}", optional: true }   # THE ANCHOR — what this change was asked to do
+      - { path: "{{delta_model}}", optional: true }  # the invariants it adds or changes — requirements too
+      - { path: "{{delta_backend_plan}}" }           # THE MAP — which element serves which requirement
+      - { path: "{{spec_file}}", optional: true }    # the master spec — the EXISTING ids a plan-only change still serves
+      - { path: "{{backend_plan}}", optional: true } # the master plan — what was already there
+      - { path: "{{domain_model}}", optional: true } # the model as it stands before the merge
+  - id: check_backend
+    condition: "{{be_gated}} == true"
+    action: agent_query
+    tools: Read          # the slice's files arrive as {{source_files}} paths, not inlined
+    include_standards: true
+    schema: { ok: true, gaps: [ { severity: "high", check: "<requirement|test|plan|model|regression|scope|placement>", lane: "backend", ref: "<delta-spec id, or the delta-plan element where the check is 'plan'>", where: "<file or 'absent'>", gap: "<what is missing or wrong>", fix: "<implement|plan|specify>" } ] }
+    mock: { ok: true, gaps: [] }
+    task: |
+      Gate the SERVICE lane's CODE for change {{cr_id}} (wave {{wave}}) against
+      delta-spec.md — THE ANCHOR in context. The question is not "is this code good" and
+      not "does it match the plan": it is DOES THIS CHANGE DO WHAT IT WAS ASKED TO DO?
+      {{source_count}} file(s) realise this slice: {{source_files}} — READ the ones this
+      change should have touched.
+      The delta plan is in context as the MAP from a requirement to the element that serves
+      it — use it to know WHERE to look, and to write a finding that names the place the
+      behaviour was supposed to land. It is not the authority: a requirement the plan never
+      planned is still this gate's finding, because the delta spec is the only document
+      that knows it was asked for.
+      The master spec, master plan and master domain model are what was ALREADY there; they
+      do not yet carry this change (finalize-delta merges it AFTER this gate), so never
+      report an element as missing from them.
+
+      CHECK 1 — REQUIREMENTS → CODE (the reason this gate exists). For EVERY ADDED or
+      MODIFIED item in the delta-spec — FR-, BR-, CN-, DC-, IC-, user story — the code must
+      actually DO what it states:
+      (a) find where the behaviour lives (the delta plan says which element should serve it)
+      and confirm the code realises the REQUIREMENT, not merely that some element with the
+      right name exists. A requirement with no realisation anywhere in the slice is a HIGH
+      `requirement` gap, fix `implement`. This is the failure no other gate can see: an
+      unbuilt requirement leaves NO failing test, so analyze-slice reports green on it;
+      (b) a requirement realised PARTIALLY — the happy path only, a rule enforced in one
+      caller and not another, an error contract the spec states and the code omits — is a
+      HIGH gap too. Say which part is missing;
+      (c) a MODIFIED item whose code still behaves the pre-change way is a HIGH gap;
+      (d) EXCEPT the Experience Standards (UX-), which this lane excludes by contract —
+      they belong to the frontend lane and are checked there.
+      Set `ref` to the delta-spec id and `where` to the file you looked in (or "absent").
+
+      CHECK 2 — TESTS PROVE THE REQUIREMENT. Every ADDED or MODIFIED delta-spec item has a
+      test that CITES its id and actually EXERCISES what it states — including the
+      constraints (an audit record is emitted, a DC-restricted field is not exposed, an IC-
+      projection round-trips). A requirement with code but no test is a HIGH `test` gap; a
+      test that exercises it but cites no id is MEDIUM. Judge what counts as a test by the
+      loaded testing standards: one that constructs the type and asserts nothing is not a
+      test for this purpose.
+
+      CHECK 3 — THE PLAN'S OWN PROMISES (cross-check, not the anchor). Every element the
+      delta plan marks ADDED exists, every MODIFIED one carries its change, every REMOVED
+      one is gone and unreferenced. A promised element nobody built is a HIGH `plan` gap
+      even when the requirement it served looks satisfied elsewhere — the two usually mean
+      the change was implemented in a different shape than was planned, which is worth
+      knowing before the masters are re-derived from it. Where the code satisfies the
+      requirement in a DIFFERENT and coherent shape, report it MEDIUM with `fix` = `plan`:
+      the plan is what is now wrong.
+
+      CHECK 4 — MODEL REALISATION. For every item in this change's MODEL DELTA (in
+      context): the entity, value object or event exists with the model's OWN name, and
+      each ADDED or CHANGED invariant (BR-nnn) is ENFORCED in the code. An invariant the
+      model delta introduces and no code enforces is a HIGH `model` gap — a BR- is a
+      requirement, not documentation. Do NOT restate the rule in your finding; cite its id,
+      say where it should be enforced and what you found there.
+
+      CHECK 5 — REGRESSION TARGETS. Each element under the delta plan's regression targets
+      has a test exercising the behaviour that was supposed to SURVIVE this change. A named
+      target with nothing testing it is a MEDIUM `regression` gap.
+
+      CHECK 6 — NO OVER-REACH. Behaviour this change introduced that NO delta-spec item
+      asked for and no delta-plan element declared is a MEDIUM `scope` gap — the change did
+      more than it was asked to, and the masters are about to be re-derived from documents
+      that do not describe it. Judge this only over what this change touched; do not report
+      the pre-existing slice.
+
+      CHECK 7 — PLACEMENT. Every file this change added or edited sits under the lane that
+      owns it: this lane's source path is `{{be_source_path}}`. A service-lane element
+      written into the frontend lane's subtree — or outside every lane root — is a HIGH
+      `placement` gap.
+
+      PLAN-ONLY CHANGE — if the delta-spec is an unfilled stub, this change deliberately
+      alters only HOW the EXISTING spec is realised (a refactor, an architectural decision).
+      Then checks 1 and 2 have no anchor and are SKIPPED, not failed. What applies instead:
+      the observable behaviour of every EXISTING spec id (master spec, in context) must be
+      UNCHANGED — a plan-only change that alters behaviour is a HIGH `requirement` gap
+      routing to `specify`, because that behaviour was never asked for — and checks 3 to 7
+      run as written.
+
+      Tag every gap with its `check`, its `severity` (high | medium) and the `fix` command
+      that closes it: `implement` when the code is missing or wrong, `plan` when the delta
+      plan is what is wrong, `specify` when the delta spec or the model delta is what is
+      missing. Set ok=true ONLY when every applicable check passes.
+    outputs:
+      - { name: be_ok,   from: "$.ok" }
+      - { name: be_gaps, from: "$.gaps" }
+
+  - id: ctx_frontend
+    condition: "{{fe_gated}} == true"
+    action: build_context
+    context:
+      - { path: "{{delta_spec}}", optional: true }     # THE ANCHOR — including this change's UX- items
+      - { path: "{{delta_model}}", optional: true }    # the terms and rules the UI must speak
+      - { path: "{{delta_frontend_plan}}" }            # THE MAP — which screen serves which requirement
+      - { path: "{{spec_file}}", optional: true }      # the master spec — existing ids a plan-only change still serves
+      - { path: "{{frontend_plan}}", optional: true }  # the master plan — what was already there
+      - { path: "{{domain_model}}", optional: true }
+  - id: check_frontend
+    condition: "{{fe_gated}} == true"
+    action: agent_query
+    tools: Read
+    include_standards: true
+    schema: { ok: true, gaps: [ { severity: "high", check: "<requirement|test|plan|model|regression|scope|placement>", lane: "frontend", ref: "<delta-spec id, or the delta-plan element where the check is 'plan'>", where: "<file or 'absent'>", gap: "<what is missing or wrong>", fix: "<implement|plan|specify>" } ] }
+    mock: { ok: true, gaps: [] }
+    task: |
+      Gate the FRONTEND lane's CODE for change {{cr_id}} (wave {{wave}}) against
+      delta-spec.md — THE ANCHOR in context. The question is: DOES THIS CHANGE DO WHAT IT
+      WAS ASKED TO DO? {{source_count}} file(s) realise this slice: {{source_files}} — READ
+      the ones this change should have touched.
+      The delta plan is in context as the MAP from a requirement to the screen, component
+      or state that serves it — it says WHERE to look, and it is not the authority: a
+      requirement the plan never planned is still this gate's finding. The master spec,
+      master plan and master model are what was ALREADY there and do not yet carry this
+      change.
+
+      CHECK 1 — REQUIREMENTS → CODE. For every ADDED or MODIFIED delta-spec item this lane
+      owns, the UI must actually DO what it states:
+      (a) every UX- Experience Standard is realised HERE — the service lane excludes them
+      by contract, so one realised in neither lane is a DROPPED requirement, a HIGH
+      `requirement` gap;
+      (b) every user story has a reachable screen and a working flow; every
+      interaction-state FR- is realised as the state it describes;
+      (c) the lifted constraints are honoured — CN- as what is hidden, disabled or
+      permission-gated; DC- as what never reaches client state, storage, the URL or
+      telemetry; IC-/SC- as the binding and the performance behaviour;
+      (d) a requirement realised PARTIALLY — the happy path only, one screen of two — is a
+      HIGH gap too; say which part is missing.
+      Set `ref` to the delta-spec id and `where` to the file (or "absent").
+
+      CHECK 2 — INTERACTION STATES ARE PART OF THE REQUIREMENT. For every interaction this
+      change adds or alters, the code renders its FULL state set — loading, empty, error,
+      permission-denied, in-flight/disabled — plus the validation timing, focus placement
+      and keyboard reachability. A state the delta describes and the code does not render
+      is a HIGH `requirement` gap: these are requirements, not polish, and they are the
+      first thing a generator drops.
+
+      CHECK 3 — TESTS PROVE THE REQUIREMENT. Every ADDED or MODIFIED delta-spec item has a
+      test citing its id (UX-/US-/FR-/CN-/DC-/IC-/SC-) that exercises what it states,
+      including the unwanted-behaviour states from check 2 and an accessibility assertion
+      per interactive surface. Missing test = HIGH `test` gap; a snapshot alone is not a
+      test; a test that exercises the change but cites no id is MEDIUM.
+
+      CHECK 4 — THE PLAN'S OWN PROMISES (cross-check, not the anchor). Every screen, route,
+      component, state container and binding the delta plan marks ADDED exists, every
+      MODIFIED one carries its change, every REMOVED one is gone and unreferenced. A
+      promised element nobody built is a HIGH `plan` gap; a requirement satisfied in a
+      DIFFERENT and coherent shape than planned is MEDIUM with `fix` = `plan`.
+
+      CHECK 5 — LANGUAGE AND AUTHORITY. Labels, states and messages use the ubiquitous
+      language of the model delta and the master model EXACTLY — a term this change renames
+      is renamed in the UI too, and a synonym is a MEDIUM `model` gap. A client-side check
+      may restate a server-enforced rule for FEEDBACK; if the client has become the ONLY
+      place a rule is enforced, that is a HIGH `model` gap.
+
+      CHECK 6 — NO OVER-REACH. A screen, control or behaviour this change introduced that
+      no delta-spec item asked for and no delta-plan element declared is a MEDIUM `scope`
+      gap. Judge it only over what this change touched.
+
+      CHECK 7 — PLACEMENT. Every file this change added or edited sits under this lane's
+      source path, `{{fe_source_path}}`. A file written into the service lane's subtree is a
+      HIGH `placement` gap — a gap in the service surface is a contract delta raised back to
+      that lane, never a client-side edit to it.
+
+      PLAN-ONLY CHANGE — if the delta-spec is an unfilled stub, this change alters only HOW
+      the existing spec is realised. Checks 1 to 3 have no anchor and are SKIPPED, not
+      failed; instead the observable experience of every EXISTING spec id must be UNCHANGED
+      (an alteration is a HIGH `requirement` gap routing to `specify`), and checks 4 to 7
+      run as written.
+
+      Tag every gap with its `check`, its `severity` (high | medium) and the `fix` command:
+      `implement` when the code is missing or wrong, `plan` when the delta plan is what is
+      wrong, `specify` when the delta spec or model delta is what is missing. Set ok=true
+      ONLY when every applicable check passes.
+    outputs:
+      - { name: fe_ok,   from: "$.ok" }
+      - { name: fe_gaps, from: "$.gaps" }
+
+  # ═══════════════════════════ THE VERDICT ═══════════════════════════
+  # requirements_ok = every GATED lane passed. Expressed as a raise-then-knock-down chain,
+  # because the engine has no compound conditions and an ungated lane must not vote.
+  - id: requirements_seed
+    action: set
+    vars: { requirements_ok: "true" }
+  - id: requirements_clear_backend
+    condition: "{{be_ok}} == false"
+    action: set
+    vars: { requirements_ok: "false" }
+  - id: requirements_clear_frontend
+    condition: "{{fe_ok}} == false"
+    action: set
+    vars: { requirements_ok: "false" }
+
+  # gate_ok = the tests ran green AND every gated lane's requirements are met.
+  - id: gate_flag
+    condition: "{{test_ok}} == true"
+    action: set
+    vars: { gate_ok: "{{requirements_ok}}" }
+
+  # THE REPORT IS ALWAYS WRITTEN — green or red. A green one is the record that this change
+  # was verified built before it was merged, which is what makes the merge auditable; a red
+  # one is the work list. It lands beside the change's other documents, so close-delta
+  # archives it with them.
+  # An EMPTY envelope, on purpose. build_context REPLACES the payload and PERSISTS, so
+  # without this the report would inherit whichever lane's documents were checked last —
+  # and a report step holding the plans it is reporting on starts re-deriving findings
+  # instead of writing down the ones the checks returned. Everything it needs is in the
+  # variables below.
+  - id: ctx_report
+    action: build_context
+    context: []
+  - id: write_report
+    action: agent_author
+    include_standards: false
+    output_target: { type: file, path: "{{cr_dir}}/delta-slice-analyze-report.md" }
+    task: |
+      Write a Delta Slice Analyze Report for change {{cr_id}} (wave {{wave}}) to the
+      output. This gate asked whether the change's CODE does what its DELTA SPEC asked for
+      — the requirements are the anchor, the delta plan was the map — before finalize-delta
+      merges the change into spec.md and domain-model.md.
+      Evidence:
+      - tests: green={{test_ok}}, tool `{{test_tool}}`, actually ran={{test_ran}},
+        matched a slice filter={{test_matched}}, slice-scoped={{test_scoped}}. Log tail:
+        {{test_log}}
+      - service lane gated={{be_gated}}, verdict ok={{be_ok}}, gaps: {{be_gaps}}
+      - experience lane gated={{fe_gated}}, verdict ok={{fe_ok}}, gaps: {{fe_gaps}}
+      Markdown format:
+      - "# Delta Slice Analyze Report — {{cr_id}}" plus today's date.
+      - A verdict line: "verdict: REQUIREMENTS MET ✓" when the tests are green and every
+        gated lane passed, else "verdict: NOT READY ✗ · <n> finding(s)".
+      - "## Evidence" — the test fence (tool, green or red, and the log tail when red), and
+        which lanes were gated. A lane that was NOT gated is listed as "not gated — this
+        change has no delta plan for it", never as a pass. WHERE `actually ran` IS FALSE,
+        say so in that section in plain words — the fence went green because this project's
+        lanes declare no test command, not because a suite passed — and note that the
+        requirement findings below, not the fence, are what answer whether the change does
+        what it was asked to.
+      - "## Findings" as a table — | # | check | lane | severity | delta-spec ref | where |
+        finding | fixed by | — ordered high severity first, and within that the
+        `requirement` check first, because an unrealised requirement is the finding this
+        gate exists for. Omit the section entirely when there are none, and say so under
+        the verdict.
+      - "## How to resolve": group by the `fix` command. `implement` — re-run
+        /appweaver implement {{cr_id}} for the lane concerned; it generates only what the
+        delta plans mark ADDED/MODIFIED, so re-running it fills the gap without touching
+        what is already correct. `plan` — the requirement is met but the delta plan no
+        longer describes how, or it promised an element the code does not have; re-run
+        /appweaver plan {{cr_id}}, then analyze-plan-delta. `specify` — the delta spec or
+        the model delta is what is missing (a requirement realised in code that nothing
+        asked for lands here too, as does a plan-only change that moved behaviour); re-run
+        /appweaver specify, which is the only phase that authors either. Then re-run
+        /appweaver analyze-slice-delta {{cr_id}}.
+      - Close with one line stating that this gate verifies only; it generated no code and
+        repaired nothing.
+      Return the complete report markdown only.
+    outputs:
+      - { name: report_written, from: "$.status" }
+
+  - id: gate
+    action: verify_context
+    require_true: gate_ok
+    on_false: stop
+    on_false_message: "Change {{cr_id}} does NOT yet meet its delta spec. Tests green={{test_ok}} (tool `{{test_tool}}`); service lane gated={{be_gated}} ok={{be_ok}}; experience lane gated={{fe_gated}} ok={{fe_ok}}. Findings — backend: {{be_gaps}} · frontend: {{fe_gaps}}. The full report, with the command that closes each finding, is at {{cr_dir}}/delta-slice-analyze-report.md. DO NOT run finalize-delta yet: merging now would write requirements into spec.md and domain-model.md that the code does not satisfy, and the masters would describe an intention rather than the system. Fix the findings (a `requirement` or `plan` finding is usually /appweaver implement {{cr_id}}), re-run build, then re-run this gate."
+
+  # 6. Post-execution hooks.
+  - id: resolve_post_hooks
+    action: execute_script
+    script: { ref: actions }
+    subcommand: resolve-hooks
+    args: ["--phase", "after_analyze_slice_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: "{{cr_id}}"
+  cr_dir: "{{cr_dir}}"
+  wave: "{{wave}}"
+  built: "{{gate_ok}}"
+  tests_green: "{{test_ok}}"
+  tests_ran: "{{test_ran}}"      # false + green = the project declares no test command
+  test_tool: "{{test_tool}}"
+  backend_gated: "{{be_gated}}"
+  backend_ok: "{{be_ok}}"
+  backend_gaps: "{{be_gaps}}"
+  frontend_gated: "{{fe_gated}}"
+  frontend_ok: "{{fe_ok}}"
+  frontend_gaps: "{{fe_gaps}}"
+  report: "{{cr_dir}}/delta-slice-analyze-report.md"
+  source_count: "{{source_count}}"
+  note: "Gated change {{cr_id}} (wave {{wave}}) — delta-spec.md is the ANCHOR, so the question answered here is whether the CODE does what the change asked for, not whether it matches the plan. The delta plan is the MAP from a requirement to the element that serves it, and is cross-checked in its own right; the change's model delta supplies the invariants the code must enforce, and they are requirements too. The masters are read-only context for what was already there — they do not carry this change until finalize-delta merges it. Only a lane with a delta plan for THIS change is gated: backend {{be_gated}}, frontend {{fe_gated}} — an ungated lane is reported as not gated, never as a pass. The tests ran here for the first time on the change path, since build only compiles. This gate verifies: it generated no code and repaired nothing, and every finding names the command that closes it."
+  next: "/appweaver finalize-delta → analyze-slice → close-delta. The change MEETS ITS SPEC and is still OPEN: finalize-delta merges it into spec.md + the context's domain-model.md — writing requirements the code has now been shown to satisfy — analyze-slice then scores the WHOLE slice against those merged masters (behaviour, domain conformance and the referrer blast radius) while a red result is still recoverable, and close-delta LAST archives the change and bumps the version."