diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md
index c49d87d0..e1265347 100644
--- a/docs/port/DECISIONS.md
+++ b/docs/port/DECISIONS.md
@@ -4758,3 +4758,66 @@ weak evidence points the other way there — sweeping the phase against
 (0.061 %) and three times worse mid-screen (0.183 %), and if they looped the
 sweep is on screen for roughly 73 % of the cycle. **Two weak signals in opposite
 directions is a reason to scope, not to pick.**
+
+## The menus' residual is the tone floor, not structure — and `extras` is not really 3× worse
+
+`extras` sits at 0.19 % differing against `main_menu`'s 0.06 %, on two screens of
+the same family, and that gap wanted explaining.
+
+**Signed difference (port − capture), by cell:**
+
+| | x=0 | x=320 | x=640 | x=960 |
+|---|---|---|---|---|
+| `extras` y=169 | **+12.13** | −3.64 | +2.43 | **+10.60** |
+| `extras` y=338 | **+12.29** | +1.36 | +1.42 | **+9.05** |
+| `main_menu` y=169 | **+11.63** | −0.68 | +3.01 | **+10.24** |
+| `main_menu` y=338 | **+11.03** | +3.93 | +2.92 | **+8.84** |
+
+**The two screens are nearly identical**, and the port is uniformly **+9 to +12
+brighter in the dark outer columns** — which is exactly the transfer curve I
+measured earlier: γ > 1 in the darks, capture darker than render. There is no
+dipole, no displacement, no missing element.
+
+So the 0.06 % / 0.19 % gap is **not a difference in fidelity**. The thresholded
+count only sees pixels differing by more than 64 levels, which are text and
+sprite **edges**; the two screens simply have different amounts of high-contrast
+edge. The *level* disagreement, which is what a tone term produces, is the same
+on both.
+
+⚠️ **This is the bounding-box lesson again in a different costume.** I had two
+numbers, 0.06 and 0.19, and took the ratio as meaningful. It is a count of
+threshold crossings, and a count of threshold crossings is not a measure of how
+wrong a screen is.
+
+### A diagnostic trap of my own, worth writing down
+
+My first pass at this reported **10 of 18 elements "transparent at rest"** on
+`extras` — the buttons, the title, the frames — and looked exactly like a
+missing-element bug. It was not. **`--screen=NAME` without `--time` renders at
+t = 0**, and `pose_at` clamps `t` to `minf(t, settle_units)`, so t=0 stays t=0 and
+every element is still at its first keyframe. Passing `--time=2.0` draws 18 of 18.
+
+The tool was right and my invocation was wrong, and the failure looked like a
+serious defect rather than an empty argument. Same family as the instrument traps
+this session has collected — and mine was the one that reported a *worse* problem
+than existed, which is the direction that wastes an iteration rather than hiding
+one.
+
+## Refutation attempt — their 239.8-unit figure, checked from my export
+
+The Decoder converted the boot's black gap using the disc as its own clock:
+*"`palogo_sqex` declares alpha ≥ 1 for **239.8 units** and is drawn in 105 frames
+→ 2.284 units/frame."* That 239.8 comes from their reading of the record; I have
+the same element in my export and can compute it independently.
+
+`palogo_sqex` ramps 0 → 255 over t=15…30 and 32 → 0 over t=251…255. Under the
+linear ramp the port already uses, alpha first reaches 1 at **t = 15.0588** and
+last exceeds it at **t = 254.8750**:
+
+**239.816 units.**
+
+✅ **Survives, to four significant figures.** It matters more than a spot-check:
+that number is the *denominator* of the units-per-frame conversion behind the
+9-unit black hold I just authored, so an error in it would have propagated
+straight into a constant I ship. Two derivations from different sides of the same
+record agreeing to 0.02 % is what makes that constant safe to hold.