aw-spec-cli 0.1.20 → 0.1.22

package/assets/.appweaver/ORCH-DIALECT.md

@@ -90,7 +90,7 @@ the raw object, not its JSON string.
 | `set` | engine | assign vars (`vars:` or decl-style `parameters:`); raw-object aware |
 | `build_context` | engine | REPLACE the per-request envelope: `system:`/`context:` file lists (+ `context_from: <var>` holding paths a prior generation reported, + `vars:`) |
 | `load_standards` | engine | F4 — append to the **sticky standards set** prepended to every system block (dedup, `optional:`, `files:`/`files_from_variable`). This is the byte-stable, prompt-cacheable prefix |
-| `execute_script` | engine | F1 — run a `scripts:` ref (`subcommand:` + `args:`; sh/ps1 via `--os`); stdout's last line = JSON, bound via `outputs[]`; `on_error: continue` tolerated; cached across resumes; runs for real even in mock transport |
+| `execute_script` | engine | F1 — run a `scripts:` ref (`subcommand:` + `args:`; sh/ps1 via `--os`); stdout's last line = JSON, bound via `outputs[]`; `on_error: continue` tolerates a script that ran and exited non-zero (its outputs bind empty) — never an undeclared ref, which the pre-flight refuses before step 1; cached across resumes; runs for real even in mock transport |
 | `verify_context` | engine | F2 — gates: `required_files` (+`allow_missing`), `require_non_empty` (+`on_empty[_message]`), `require_true` (+`on_false[_message]`), `require_value`+`equals` (+`on_mismatch[_message]`). `stop` raises a terminal stop |
 | `agent_generate` | fresh agent | demo contract (code work): agent DECIDES file paths per the loaded standards, writes with its tools, reports `files[]` in the trailing ```json fence. `sdk-apply` = read-only generation + invoking agent applies |
 | `agent_review` | fresh agent | payload-only review of `review_of_var`/`review_of` files (inlined into THIS request, never sticky) → `{pass, issues}` |
@@ -159,8 +159,13 @@ orchestrator.py <workflow.orch.yaml>
 ## Validation & smoke
 
 - `--validate` every workflow/module (unknown actions/strategies, duplicate
-  ids, script refs + files on disk, `output_target.path`, module paths,
-  unproduced `{{vars}}`, dialect header).
+  ids, script refs + files on disk — including the refs of every included
+  module, which resolve against the caller's `scripts:` — `output_target.path`,
+  module paths, unproduced `{{vars}}`, dialect header).
+- Every run starts with the same checks. A workflow with an ERROR is not
+  started: the engine exits 1 with `status: stopped` and the defects in the
+  reason, before any step runs and before a checkpoint response is ingested.
+  Warnings never block.
 - `workflows/_smoke.orch.yaml` exercises every construct with no model and no
   writes outside `.smoke-out`: run it `--non-interactive` (CI) and with
   `--checkpoint` (protocol walk-through).

package/assets/.appweaver/STACK-PROFILES.md

@@ -51,15 +51,17 @@ no heading to key on. Where the two lanes are folded into one command, as `plan`
 | `stack` | *(optional)* what the code was found to be, when `profile` is `detected` — e.g. `asp.net-webforms`. The honest record for a legacy lane |
 | `origin` | *(optional)* `reverse-engineered` on a lane `onboard` derived from an existing codebase. Absent means a person declared it, which is the greenfield shape and the historical one |
 | `root` | the lane's **source path** — the subtree it owns (see §3). `--source-path` and `--root` are two spellings of this one field |
+| `test_root` | *(optional)* the lane's **test path**, written by hand only when the profile's answer does not fit this layout. Absent, `lane-resolve` / `lane-verify` work it out from the profile at read time (§4.3), so no lane has to be re-declared for it |
 | `run_from` | *(optional)* **where the commands run**: `repo` (the default, and the shape of every lane written before this key existed) at the repository root, or `root` inside the lane's own source path. See §3.1 |
 | `build` / `test` / `run` | project-supplied command strings the engine shells out to. These are the matched **profile's** defaults and may not fit a legacy layout — reviewing them is what `select-stack` is for. `{{root}}` in a command resolves to this lane's `root` (§4.2) |
 | `migrate` | *(optional)* the lane's schema-migration command, recorded only when the profile declares one. Absent, `run-migrate` falls back to `dotnet ef` and otherwise reports that nothing ran (§4.2) |
 
 ### Three properties matter more than the schema
 
-1. **`root` is ownership, and it is the source path.** `implement`'s service lane writes only
-   under a backend lane's root and its frontend lane only under a frontend lane's,
-   `build`/`test`/`run` act on it, and `onboard` reverse-engineers out of it.
+1. **`root` is ownership, and it is the source path.** `implement`'s service lane writes its
+   code only under a backend lane's root and its frontend lane only under a frontend lane's,
+   `build`/`test`/`run` act on it, and `onboard` reverse-engineers out of it. The lane's
+   **test path** (§4.3) is owned the same way, and is where `implement` writes the lane's tests.
 2. **The commands are project-supplied strings.** The engine stays stdlib-only and
    stack-ignorant. This is how `build` already avoids knowing what a compiler is, and it
    is the only thing that makes "any frontend stack" tractable.
@@ -151,12 +153,17 @@ Declaring **`(none)`** for a lane is a real answer and the way a project says it
 ## 3. The ownership rule
 
 **Lane roots own their subtree and must be disjoint.** Two generators must never be able
-to write the same file.
+to write the same file. A lane owns its test path too, so the rule covers both: no source or
+test path of one lane may overlap a source or test path of another.
 
-`lane-declare` refuses a declaration whose root contains, or is contained by, another
+`lane-declare` refuses a declaration whose paths contain, or are contained by, another
 lane's — compared as `/`-terminated paths, so `src/` is clear of `src-gen/` but collides
 with `src/api/`. The refusal is a non-zero exit and **`stacks.json` is left untouched**.
 
+The one write `implement` may make outside a lane's two paths is registering a test project
+it had to create, in the file the lane's test command discovers tests through — the solution
+file for .NET. `analyze-slice-delta`'s placement check accepts that edit and nothing else.
+
 This is checked at declaration time on purpose. The alternative — discovering it when two
 implement phases fight over a file — is a much worse place to find out.
 
@@ -176,12 +183,15 @@ workflow.**
   "language": "TypeScript",                  // shown in the menu, parenthesised
   "ecosystem": "node",                       // which stack-partitioned corpus this stack draws from
   "root": "web/",                            // the lane root this profile defaults to
+  "test_root": "",                           // optional — where tests go when not inside root — see §4.3
   "run_from": "root",                        // where the commands run — see §3.1
   "build": "npm run build",
   "test":  "npm test",
   "run":   "npm run dev",
   "migrate": "",                             // optional — schema migration, if the stack has one
   "prototype_run": "npm run dev --prefix prototype",   // frontend only — fills the prototype block
+  "reserved_names": ["Event", "Request", "Response"],  // optional — names this stack's AMBIENT
+                                             // scope already defines; see §4.4
   "detect": ["web/package.json", "web/vite.config.*"]  // ANY-of markers — how stack-detect recognises this stack
 }
 ```
@@ -206,10 +216,23 @@ trees that are physically per-ecosystem:
 compiling project and a component runbook edits a host project's build files — both are
 executable artifacts in one toolchain, so offering a `dotnet` bundle to a Spring repo does not
 produce a scaffold, it produces a second foreign project beside the real one. `foundation-list`
-therefore narrows to the declared lanes' ecosystems, and reports `all_foundations` alongside so
-the gate can say *what exists and why none of it applies*. A repo that has declared nothing yet
+therefore narrows by ecosystem, and reports `all_foundations` alongside so the gate can say
+*what exists and why none of it applies*. `--ecosystem` narrows to the ONE lane being
+scaffolded, which is what `foundation` passes: a repo declaring a .NET service and a Node UI
+must not be offered its .NET bundle while the UI lane is the target. Without that argument the
+filter falls back to every declared lane's ecosystem, and a repo that has declared nothing yet
 is not filtered — there is no answer to filter on.
 
+**A scaffold lands in a lane.** `foundation` unpacks a bundle into the SOURCE PATH of the lane
+it is scaffolding — never the repository root, and there is no output-directory argument. One
+bundle fills one lane, so a fullstack repo runs `foundation` once per lane. This is what makes
+every phase's "write only into your lane" rule true of the scaffold as well as of generated
+code: `implement`, `build`, `test` and `run` all resolve the same path the bundle unpacked into.
+A pack carrying its own test tree has it lifted onto the lane's **test path** (§4.3) afterwards,
+because for most backend stacks that path is a sibling of the source path rather than a
+directory inside it. Lanes must therefore be declared before `foundation` runs, which is why
+`select-stack` is the first command of both sequences.
+
 The technical RULE corpora at `guardrails/technology/<stack>/` are keyed by **profile id**, not
 ecosystem, because Spring and Quarkus are both `java` and do not share a persistence rule. They
 are selected through the project's `tech-rule-bindings.md` rather than filtered here — see §7.
@@ -274,6 +297,61 @@ about a backend, and the two errors are not symmetric. A false positive authors
 the project never asked for; a false negative only produces a warning that names the fix. Pick
 ids accordingly — a profile whose id is a common English word will be matched too eagerly.
 
+### 4.4 `reserved_names` — names the stack already defines
+
+A stack's ambient scope defines types nobody imported: C#'s implicit usings put `System`,
+`System.Threading.Tasks`, `Microsoft.AspNetCore.Http` and `Microsoft.AspNetCore.Routing` in
+every file of a `Microsoft.NET.Sdk.Web` project; a browser bundle has `Event`, `Request` and
+`Response`; `java.lang` is always imported; `typing` is star-imported by convention.
+
+A domain noun that matches one of those is **not a naming mistake** — `Route`, `Task`,
+`Order` and `Activity` are ordinary domain vocabulary, the plan carries the ubiquitous
+language, and the generator spells it verbatim. But written bare it is ambiguous, and in C#
+it does not compile (CS0104). The conflict is invisible in the file: the framework name
+arrives through an implicit import and appears in no line of it.
+
+`reserved_names` lists the ones that are BOTH ambient on this stack AND plausible domain
+vocabulary — curated, not an exhaustive dump of the standard library. `lane-resolve` and
+`lane-verify` report it as `<kind>_reserved_names` / `<kind>_reserved_csv`; `implement`
+passes it to `plan-coverage --reserved`, which intersects it with the plan's own element
+names and hands the generating lane the actual collisions before it writes anything. The
+per-stack resolution convention is in that stack's rule corpus — for `dotnet-webapi`, in
+[[framework-api-map]]: qualify with the enclosing namespace segment (`Domain.Route`), never
+rename the domain type.
+
+Absent, nothing is reported and generation is unchanged.
+
+### 4.3 `test_root` — where a lane's tests go
+
+Most backend stacks keep their tests **beside** the source, not inside it: .NET's `tests/` next
+to `src/`, Maven's `src/test/java/` next to `src/main/java/`, pytest's `tests/` next to `app/`.
+A lane that owned only its source path could not hold its own tests, so each lane also owns a
+**test path**, and `implement` writes the lane's paired tests there.
+
+A profile's `test_root` is the test path that pairs with its default `root`. `lane-resolve` and
+`lane-verify` report it per kind as `backend_test_path` / `frontend_test_path`, worked out at
+read time:
+
+| The lane | Its test path |
+|---|---|
+| declares `test_root` itself | that value |
+| sits at the profile's default root (`src/`) | the profile's `test_root` (`tests/`) |
+| sits at a path ending in the default root (`backend/src/`) | the profile's `test_root` under the same prefix (`backend/tests/`) |
+| anything else, or the profile declares no `test_root` | the source path itself |
+
+The last row is right for every shipped frontend (tests under `web/tests/`), for Go's
+colocated `_test.go` files, and for a Maven lane rooted at the directory holding its
+`pom.xml`, where `src/test/java/` is already inside the lane. A layout the table gets wrong is
+fixed by writing `test_root` on the lane in `stacks.json`.
+
+| Profile | `root` | `test_root` |
+|---|---|---|
+| `dotnet-webapi` | `src/` | `tests/` |
+| `java-spring` | `src/main/java/` | `src/test/java/` |
+| `python-fastapi` | `app/` | `tests/` |
+| `node-express` | `src/` | `tests/` |
+| `go-chi` and every frontend | — | *(none — inside the source path)* |
+
 ---
 
 ## 5. Who may write this file
@@ -398,7 +476,8 @@ set**, so a caller binds outputs without knowing which branch ran.
 | `test-run` | every declared lane's own `test`, via `run-phase` — **except** `--scope slice` on a repo where a .NET toolchain is present, which keeps the VSTest `--filter` path | the historic ladder |
 | `run-migrate` | a lane's declared `migrate` (§4.2) when there is one; otherwise `dotnet ef` searched under the **service lane's root** rather than an assumed `src/` | `dotnet ef` under `src/` |
 | `find-host-project` | searches the service lane's root, and reports the lane's `ecosystem` | searches `src/` |
-| `foundation-list`, `list-components` | narrowed to the declared lanes' `ecosystem` (§4.1) | unfiltered / `dotnet` |
+| `foundation-list`, `list-components` | narrowed to the `ecosystem` of the lane being scaffolded, else of every declared lane (§4.1) | unfiltered / `dotnet` |
+| `foundation-unpack` | unpacks into the lane's **source path**, and lifts a packed test tree onto its **test path** (§4.1, §4.3) | cannot run — `foundation` stops until a lane is declared |
 | `resolve-tech` | expands stack placeholders and flags a corpus mismatch (§7a) | no placeholders resolve; nothing is flagged |
 
 **Why `--scope slice` is the one exception.** VSTest's `--filter FullyQualifiedName~` is the

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

@@ -130,6 +130,14 @@ workflow:
                                              # the context's CANONICAL model — the aggregate root,
                                              # its entities and its invariants live here, not in the
                                              # spec and not in this plan.
+      - { path: "{{cr_dir}}/delta-slice-analyze-report.md", optional: true }
+                                             # WHAT THE LAST GATE FOUND, when this change
+                                             # has already been through analyze-slice-delta.
+                                             # A `plan` finding there says THIS document is
+                                             # what was wrong, and re-deriving it is how that
+                                             # finding is closed — the alternative is hand-
+                                             # editing a generated plan, which every
+                                             # authoring rule forbids. Absent on a first pass.
       - { path: .appweaver/DESIGN-FORMAT.md }
   - id: author_backend_delta
     condition: "{{be_existing}} == true"
@@ -148,6 +156,13 @@ workflow:
         IS, and a delta that ignores the difference plans an edit to something that is not
         there. Where the two disagree, plan against the code and record the divergence as
         a WA-n.
+      - THE LAST GATE'S REPORT, when one is in context (delta-slice-analyze-report.md).
+        It records what analyze-slice-delta found the last time this change was gated. A
+        finding tagged `fix: plan` says THIS document was what was wrong — re-derive the
+        rows it names, against the code it names. EVIDENCE, never a requirement source: the
+        delta-spec stays the only authority on what the change must do, and a finding
+        tagged `implement` or `specify` is closed elsewhere and is not this pass's work.
+        Absent on a first pass, which is the normal case.
       - Classify every change to the plan 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
@@ -231,6 +246,14 @@ workflow:
                                              # frontend-only project has no service lane at all.
       - { path: "{{domain_model}}", optional: true }
       - { path: .appweaver/memory/constitution.ui.md, optional: true }
+      - { path: "{{cr_dir}}/delta-slice-analyze-report.md", optional: true }
+                                             # WHAT THE LAST GATE FOUND, when this change
+                                             # has already been through analyze-slice-delta.
+                                             # A `plan` finding there says THIS document is
+                                             # what was wrong, and re-deriving it is how that
+                                             # finding is closed — the alternative is hand-
+                                             # editing a generated plan, which every
+                                             # authoring rule forbids. Absent on a first pass.
       - { path: .appweaver/DESIGN-FORMAT.md }
   - id: author_frontend_delta
     condition: "{{fe_existing}} == true"
@@ -247,6 +270,13 @@ workflow:
         feature: {{source_files}}. Read the ones this change touches — a delta that plans
         an edit to a component that is not there, or that duplicates one that is, costs a
         whole implementation pass to discover.
+      - THE LAST GATE'S REPORT, when one is in context (delta-slice-analyze-report.md).
+        It records what analyze-slice-delta found the last time this change was gated. A
+        finding tagged `fix: plan` says THIS document was what was wrong — re-derive the
+        rows it names, against the code it names. EVIDENCE, never a requirement source: the
+        delta-spec stays the only authority on what the change must do, and a finding
+        tagged `implement` or `specify` is closed elsewhere and is not this pass's work.
+        Absent on a first pass, which is the normal case.
       - Classify every change ADDED / MODIFIED / REMOVED against the master, per the
         master's OWN sections. A shared component or a shared state container is MODIFIED
         in place, never copied into the change.

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

@@ -140,7 +140,7 @@ workflow:
         touches the same aggregate or the same FR ids, say so under "Other open deltas"
         in Impact. If THIS change only makes sense after one of them lands, say so in the
         Wave rationale — that is a wave dependency, and the wave must then be RAISED above
-        that delta's (report it; `cr-wave` applies it). Do not silently assume their
+        that delta's — name it under `## Depends on` and the wave is raised from that. Do not silently assume their
         changes: until merged they are proposals, not the master.
       - Do NOT edit the Wave / Created / Base version headers — scripts stamp those.
       Change request: {{USER_INPUT}}
@@ -183,4 +183,25 @@ workflow:
         entry MUST sit in a LOWER wave than this delta ({{wave}}). "None" when it stands
         alone. Reading another delta is NOT depending on it — only assuming its changes is.
       - Do NOT edit the Wave / Created / Base context version headers — scripts stamp those.
+        Naming a delta under "## Depends on" is what RAISES this change's wave, immediately
+        after you write it; you never set the number yourself.
       Change request: {{USER_INPUT}}
+
+  # 4. THE WAVE THE DOCUMENTS THEMSELVES IMPLY. cr-setup stamped a provisional wave before
+  #    either half existed — the highest already open, which is right for a change that
+  #    stands alone and wrong for one that builds on another: it lands at its predecessor's
+  #    wave, where the blocker fence reads the two as independent and lets them merge in
+  #    either order. Now that "## Depends on" is written, that declaration decides: the wave
+  #    is raised to one above the highest delta named there, in BOTH halves, so the number
+  #    and the prose cannot drift apart. A change that names none keeps what it has, and one
+  #    already sitting higher is left alone. The merge fence re-checks the same rule.
+  - id: derive_wave
+    action: execute_script
+    on_error: continue
+    script: { ref: actions }
+    subcommand: cr-wave-derive
+    args: ["--cr-id", "{{cr_id}}", "--stamp"]
+    outputs:
+      - { name: wave,         from: "$.wave" }
+      - { name: wave_depends, from: "$.depends_on" }
+      - { name: wave_message, from: "$.message" }

package/assets/.appweaver/orchestrator/orchestrator.py

@@ -1458,6 +1458,39 @@ def _refs_in(v):
     return found
 
 
+def _module_script_refs(mpath, base_dir, seen):
+    """(step id, script ref) for every execute_script step an included module runs,
+    following nested includes. Modules that cannot be read contribute nothing — the
+    include check already warns about a module missing from disk."""
+    path = next((c for c in (mpath, os.path.join(base_dir, mpath)) if c and os.path.exists(c)), "")
+    if not path or path in seen:
+        return []
+    seen.add(path)
+    try:
+        with open(path, encoding="utf-8") as fh:
+            mwf = load_yaml(fh.read())
+    except Exception:
+        return []
+    out = []
+
+    def walk(ss):
+        for s in ss or []:
+            if not isinstance(s, dict):
+                continue
+            p = s.get("parameters") or s
+            if s.get("action") == "execute_script":
+                ref = (p.get("script") or {}).get("ref")
+                if ref:
+                    out.append((s.get("id") or "step", ref))
+            elif s.get("action") == "include" and s.get("module"):
+                out.extend(_module_script_refs(s["module"], base_dir, seen))
+            elif s.get("action") == "loop":
+                walk(s.get("steps"))
+
+    walk((mwf or {}).get("workflow"))
+    return out
+
+
 def validate_workflow(wf, base_dir):
     errors, warnings = [], []
     if not isinstance(wf, dict):
@@ -1551,6 +1584,13 @@ def validate_workflow(wf, base_dir):
                 errors.append(f"{loc}: include needs 'module'")
             elif not (os.path.exists(m) or os.path.exists(os.path.join(base_dir, m))):
                 warnings.append(f"{loc}: include module not found on disk: {m}")
+            elif scripts:
+                # A module declares no scripts: of its own — its refs resolve against
+                # THIS workflow's map, so an undeclared one is this workflow's defect.
+                for mid, ref in _module_script_refs(m, base_dir, set()):
+                    if ref not in scripts:
+                        errors.append(f"{loc}: included step {mid} uses script ref "
+                                      f"'{ref}', not declared in top-level scripts:")
         if action == "agent_query" and not step.get("outputs"):
             warnings.append(f"{loc}: agent_query has no outputs[] to bind")
         if action == "agent_author" and not (p.get("output_target") or {}).get("path"):
@@ -1682,6 +1722,31 @@ def main(argv=None):
             print(f"\n{opts.workflow}: {len(errors)} error(s), {len(warnings)} warning(s)")
         return 1 if errors else 0
 
+    # ---- pre-flight: a workflow --validate rejects is never started ----------
+    # An undeclared script ref, an unknown action or a duplicate step id is a defect in
+    # the workflow file, and no run can recover from it — `on_error: continue` covers a
+    # script that RAN and failed, not one the workflow never declared. Found mid-run, it
+    # strands the operator after the questions were answered; found here, nothing has
+    # happened yet. Runs BEFORE the checkpoint ingest, so a refused resume leaves the
+    # pending response on disk for the run after the fix. Warnings do not block.
+    try:
+        with open(opts.workflow, encoding="utf-8") as fh:
+            wf = load_yaml(fh.read())
+        errors, _ = validate_workflow(wf, os.path.dirname(os.path.abspath(opts.workflow)))
+    except Exception as e:
+        wf, errors = None, [f"parse: {e}"]
+    if errors:
+        reason = (f"workflow {opts.workflow} has {len(errors)} defect(s) and was not started: "
+                  + "; ".join(errors)
+                  + " — fix the workflow file (python3 .appweaver/orchestrator/orchestrator.py "
+                  "<workflow> --validate lists them) and re-run.")
+        if opts.json:
+            print(json.dumps({"status": "stopped", "reason": reason, "errors": errors}, indent=2))
+        else:
+            print("\n=== STOPPED ===")
+            print(reason)
+        return 1
+
     # ---- checkpoint mode: load prior state + ingest the agent's response ----
     # (before profile/strategy resolution, so a bare `--checkpoint` resume
     # restores the original run's profile/strategy/model/os and prefills)
@@ -1787,9 +1852,6 @@ def main(argv=None):
         print("ERROR: --transport real needs --strategy (or --agent-profile / --checkpoint)")
         return 2
 
-    with open(opts.workflow, encoding="utf-8") as fh:
-        wf = load_yaml(fh.read())
-
     orch = Orchestrator(wf, opts)
     try:
         result = orch.run()

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

@@ -36,8 +36,8 @@
 # is visible so it can be designed around, and building on it silently is the defect this
 # check exists to catch.
 #
-# OVERLAP IS COMPUTED, NOT ASKED. cr-overlap reads the `## Aggregate:` headings of every
-# pending model delta and reports which other open changes touch the same aggregates.
+# OVERLAP IS COMPUTED, NOT ASKED. cr-overlap reads the `**Aggregates touched**:` header of
+# every pending model delta and reports which other open changes touch the same aggregates.
 # That is a fact about two files, so a regex answers it exactly and the result is handed
 # to the model as a finding rather than as a question.
 #
@@ -229,9 +229,9 @@ workflow:
       - { name: sibling_count,             from: "$.sibling_count" }
       - { name: domain_model,              from: "$.domain_model" }
 
-  # 3b. WHICH OTHER OPEN CHANGES TOUCH THE SAME AGGREGATES. Deterministic: the
-  #     `## Aggregate:` headings of the pending model deltas are the merge unit
-  #     domain-model.md is organised by, so this is a regex over two files rather than a
+  # 3b. WHICH OTHER OPEN CHANGES TOUCH THE SAME AGGREGATES. Deterministic: each pending
+  #     model delta's `**Aggregates touched**:` header names the `## Aggregate:` sections
+  #     of domain-model.md it merges into, so this is a regex over two files rather than a
   #     judgement. The result reaches the check below as a FINDING, not a question.
   - id: cr_overlap
     action: execute_script
@@ -645,7 +645,7 @@ workflow:
     action: verify_context
     require_true: analyze_ok
     on_false: stop
-    on_false_message: "The delta plans for {{cr_id}} do not realise the delta spec (gaps: {{analyze_gaps}}) — repair was skipped (see {{cr_dir}}/delta-plan-analyze-report.md), or it could not be reconciled in 3 passes. A 'LIFT-FAILURE:' gap means a domain constraint from the gate checklist was never lifted into the delta spec, and a `model` gap means a plan needs structure the effective model does not define — both are fixed by /appweaver specify, which authors the delta spec and the model delta; this gate may not write either. A `wave` gap is closed by declaring '## Depends on' (and raising the wave with cr-wave) or by planning around the sibling. Otherwise fix out of band, or re-run and choose Repair."
+    on_false_message: "The delta plans for {{cr_id}} do not realise the delta spec (gaps: {{analyze_gaps}}) — repair was skipped (see {{cr_dir}}/delta-plan-analyze-report.md), or it could not be reconciled in 3 passes. A 'LIFT-FAILURE:' gap means a domain constraint from the gate checklist was never lifted into the delta spec, and a `model` gap means a plan needs structure the effective model does not define — both are fixed by /appweaver specify, which authors the delta spec and the model delta; this gate may not write either. A `wave` gap is closed by declaring '## Depends on' — which is what sets the wave, since specify derives it from that section and the merge fence re-checks it — or by planning around the sibling. Otherwise fix out of band, or re-run and choose Repair."
 
   # 8. Post-execution hooks.
   - id: resolve_post_hooks