diff --git a/docs/port/HANDOFF.md b/docs/port/HANDOFF.md
index d5bda1cb..7546d83f 100644
--- a/docs/port/HANDOFF.md
+++ b/docs/port/HANDOFF.md
@@ -115,8 +115,10 @@ authored version can be deleted.
   capture-not-settled (the band is identical from t = 4.0 s to t = 21.5 s). The
   residual is stable and modest: band mean **+1.83**, edge-corr **0.70** vs ≈ 0.92
   frame-wide. A next attempt should use a **per-draw GPU capture** of the running
-  guest, which reads the actual blend state instead of inferring it — not another
-  field. ✅ And the plate-free capture is sound; use it.
+  guest — not another field — but ⚠️ that capture records prim/indices/shader
+  hashes/**texture bindings**/**vertex attributes** and **no blend state**, so it
+  can test a per-draw *vertex colour* today and would need a Canary change to dump
+  `RB_BLENDCONTROL`. ✅ And the plate-free capture is sound; use it.
   🔴 **Refuted:** it is *not* that our dim covers the whole frame instead of
   sitting beneath the UI — the logo reads +2.36 against a background of −0.74, so
   the paint order is being honoured.
diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md
index 106b940c..9b82d849 100644
--- a/docs/re/METHOD.md
+++ b/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.
diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md
index 494cd01f..750e1a6d 100644
--- a/docs/re/REFUTED.md
+++ b/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.
diff --git a/docs/re/ui-title-build-map.md b/docs/re/ui-title-build-map.md
index 9012ccf9..1f92ec09 100644
--- a/docs/re/ui-title-build-map.md
+++ b/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.