diff --git a/docs/re/METHOD.md b/docs/re/METHOD.md
index 736d2604..754ecf74 100644
--- a/docs/re/METHOD.md
+++ b/docs/re/METHOD.md
@@ -734,3 +734,11 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
   suite is stated to have terminated — so report the suite count and elapsed
   state rather than the word "green", which is what I should have been doing all
   session.
+* **"Cannot finish" and "takes an hour" are different claims — measure before
+  choosing.** I wrote that the verification gate *cannot terminate*, from having
+  watched it run 3 h 26 m. Timing the work directly: 19 of 166 containers exceed
+  25 s, `Stage_S02` completes in **144 s**, and one full pass is ~45–60 minutes.
+  Nothing hangs. The 3 h 26 m was that hour of work at a load average of 9–14,
+  inflated by my own duplicate runs. A slow thing observed under contention looks
+  like a stuck thing, and the correction matters: an hour-scale gate can be run
+  deliberately, a hung one cannot be run at all.
diff --git a/docs/re/REFUTED.md b/docs/re/REFUTED.md
index 4984c9f0..70b1f873 100644
--- a/docs/re/REFUTED.md
+++ b/docs/re/REFUTED.md
@@ -516,3 +516,9 @@ neighbourhood, not just the line.
   flagged group violates it on a median **52.5 %** of pixels against **30.2 %**
   unflagged — both far from premultiplied, and the flagged group *further*.
   [`ui-paint-order-key.md`](structures/ui-paint-order-key.md)
+* "`build-reborn test` cannot terminate" → **mine, and too strong; corrected the
+  next iteration.** It is heavy, not hung: 19 of 166 `.xpr` containers exceed
+  25 s, `Stage_S02` completes in **144 s** with `rc = 0`, and one full pass is
+  ~45–60 minutes. The 3 h 26 m observed was that work at a load average of 9–14,
+  inflated by my own two duplicate runs.
+  [`test-suite-runtime.md`](test-suite-runtime.md)
diff --git a/docs/re/data/slow-xpr-files.txt b/docs/re/data/slow-xpr-files.txt
new file mode 100644
index 00000000..4517f6f9
--- /dev/null
+++ b/docs/re/data/slow-xpr-files.txt
@@ -0,0 +1,22 @@
+# .xpr files whose `mesh info` decode exceeds 25 s (debug build), of 166 scanned
+# 2026-08-29. Stage_S02 measured at 144 s to completion, rc=0 -- heavy, not hung.
+
+Hangar.xpr
+Stage_S02.xpr
+Stage_S03.xpr
+Stage_S04.xpr
+Stage_S06.xpr
+Stage_S07.xpr
+Stage_S08.xpr
+Stage_S09.xpr
+Stage_S11.xpr
+Stage_S12.xpr
+Stage_S13.xpr
+Stage_S15.xpr
+Stage_S24.xpr
+Stage_S25.xpr
+Stage_S26.xpr
+Stage_S27.xpr
+Stage_S28.xpr
+Stage_S29.xpr
+ptc_pack.xpr
diff --git a/docs/re/test-suite-runtime.md b/docs/re/test-suite-runtime.md
index 01792500..c57e5c44 100644
--- a/docs/re/test-suite-runtime.md
+++ b/docs/re/test-suite-runtime.md
@@ -1,4 +1,4 @@
-# 🔴 `build-reborn test` cannot finish in a working session — and I left two runaways
+# 🟡 `build-reborn test` takes about an hour — and I left two runaways
 
 **Status:** ✅ measured. Two facts, one of them my own mess.
 
@@ -16,6 +16,27 @@ fn twin_pairs_do_not_share_a_buffer() {
 ```
 
 Measured: one instance accumulated **3 h 26 m of CPU at 89 %** without finishing.
+
+### 🔴 "Cannot terminate" was too strong — corrected
+
+It terminates; it is merely heavy, and I said the stronger thing before measuring
+it. Timing `sylpheed-cli mesh info` on each of the 166 files with a 25 s cap
+([`data/slow-xpr-files.txt`](data/slow-xpr-files.txt)):
+
+| | |
+|---|---|
+| files scanned | 166 |
+| exceeding 25 s | **19** — `Hangar`, 17 `Stage_*`, `ptc_pack` |
+| `Stage_S02` timed to completion | **144 s**, `rc = 0` |
+
+So nothing hangs. Nineteen heavy containers at roughly two minutes each is
+**~45–60 minutes** for one pass, before the 147 fast ones. The observed 3 h 26 m
+was that work running at a **load average of 9–14** — inflated by my own two
+duplicate runs competing with each other and with this one. The runaways did not
+merely coexist with the slowness; they multiplied it.
+
+⚠️ The practical conclusion is unchanged and only the wording softens: an
+hour-scale suite is not an iteration-scale gate.
 Its sibling in the same file, `shared_resources_decode_identically_in_every_container`,
 walks the same 166 files and *is* `#[ignore]`d (as known-failing), so the binary's
 cost is easy to underestimate from a glance at the file.