re: full suite green, and correcting the route I recommended last

iteration

Two loose ends, both on my own work.

The disc-gated suite finally completed: all six binaries, 131 passed,
0 failed, one pre-existing ignored. So the rest() fix and the T8adImage
flags field are fully verified rather than verified-on-three-binaries.
The reason earlier attempts produced empty logs was that the tool
timeout's SIGTERM reached the whole process group; setsid nohup survives
it, which is now a METHOD line.

And a correction that matters more. Last iteration I closed the swoosh as
undecodable from the disc and named a per-draw GPU capture as the next
route, "because it reads the actual blend state". It does not. Reading
command_processor.cc, each captured draw records primitive type, index
count, index-buffer address, VS and PS ucode hashes, the pixel shader's
texture bindings, and vertex attribute 0 of binding 0. There is no
RB_BLENDCONTROL dump.

So the route splits, and I have said so rather than leaving the wrong
version standing: the capture can test a per-draw VERTEX COLOUR today
with no code change, which would explain white-versus-pink directly, and
getting the blend mode itself needs a Canary change to dump the blend
registers. Either way it is instrumentation rather than another field.

The general lesson goes in METHOD too: validate a recommendation before
leaving it as advice. A named next step is a claim like any other, and I
made it without checking.

docs/re/METHOD.md

@@ -299,3 +299,14 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   literals, so `cargo test` failed to compile with exit 101. A green build on the
   binary is not a gate for a struct change; run the tests before believing a
   data-structure edit is safe.
+* **Detach long background work with `setsid`, or a tool-call timeout kills it.**
+  Three attempts to run the disc-gated test suite in the background died at exit
+  143 with an empty log — the timeout's SIGTERM reached the whole process group.
+  `setsid nohup cargo test … &` survives, and the run then completes across later
+  tool calls. An empty log from a "background" job usually means it was killed,
+  not that it produced nothing.
+* **Validate a recommendation before leaving it as advice.** Having concluded a
+  question was undecodable from the disc, I named a per-draw GPU capture as the
+  next route "because it reads the blend state". It does not — checking the
+  capture's own source showed it records textures and vertex attributes and no
+  blend registers. A named next step is a claim like any other.

docs/re/REFUTED.md

@@ -35,6 +35,11 @@ neighbourhood, not just the line.
 
 ## Screens, classes and RTTI
 
+* "the `--log_ui_draws` per-draw capture reads the guest's blend state" →
+  **mine, and wrong.** It records primitive type, index count, index-buffer
+  address, VS/PS ucode hashes, texture bindings and vertex attribute 0 — no
+  `RB_BLENDCONTROL`. It can test vertex colour as-is; blend state needs a Canary
+  change. [`ui-title-build-map.md`](ui-title-build-map.md)
 * "the plate-free title capture (t ≈ 4.0 s) may be too early to be settled" →
   **mine, and refuted.** The swoosh band correlates 0.7342 at t = 4.0 s and
   0.7353 at t = 21.5 s — identical to 0.001 over 17.5 s.

docs/re/ui-title-build-map.md

@@ -573,8 +573,25 @@ The residual is stable and modest: band mean **+1.83**, band edge-correlation
 **0.6971–0.735** against ≈ 0.92 frame-wide. Real, persistent, and **not located in
 any field this project can read from the disc**.
 
-**Where a next attempt should start, and it is not another field.** A per-draw GPU
-capture of the running guest (`--log_ui_draws`, the route that produced
-[`ui-title-paint-order-capture.md`](ui-title-paint-order-capture.md)) reads the
-*actual* blend state, vertex colours and draw order the game submits for that
-band, instead of inferring them from the file. That is where static RE stops here.
+**Where a next attempt should start, and it is not another field** — but check
+what the tool actually records first, because the obvious phrasing of this is
+wrong.
+
+⚠️ **The per-draw capture does NOT record blend state.** Reading
+`command_processor.cc`, each captured draw carries: primitive type, index count,
+index-buffer address, vertex- and pixel-shader `ucode_data_hash`, the pixel
+shader's **texture bindings** (base, dimensions, format), and **vertex attribute
+0 of binding 0**. There is no `RB_BLENDCONTROL` / `RB_COLORCONTROL` dump. An
+earlier version of this section claimed the capture "reads the actual blend
+state"; it does not.
+
+So the route splits:
+
+* ✅ **Testable today, no code change** — whether the game passes a **vertex
+  colour** for those draws. The capture dumps vertex attributes, and a pink vertex
+  colour would explain white-versus-pink directly.
+* ❔ **Needs a Canary change** — the blend mode itself, which means adding an
+  `RB_BLENDCONTROL` dump to the same capture path.
+
+Either way it is instrumentation of the running guest, not another field in the
+file.