From e482add1f5b9d2aba962ab18441414c884014356 Mon Sep 17 00:00:00 2001 From: Sylpheed RE agent Date: Fri, 28 Aug 2026 22:09:07 +0000 Subject: [PATCH] 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/port/HANDOFF.md | 6 ++++-- docs/re/METHOD.md | 11 +++++++++++ docs/re/REFUTED.md | 5 +++++ docs/re/ui-title-build-map.md | 27 ++++++++++++++++++++++----- 4 files changed, 42 insertions(+), 7 deletions(-) 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.