diff --git a/docs/port/DECISIONS.md b/docs/port/DECISIONS.md
index b86a97b3..984bca1b 100644
--- a/docs/port/DECISIONS.md
+++ b/docs/port/DECISIONS.md
@@ -4615,3 +4615,66 @@ unexplained exception in `authored/`.
 **What would change it:** a mechanism in the record, or a gate that measures the
 build-in against a capture. Until then the port is visibly wrong for two frames
 during a build-in nobody compares, which is the cheaper of the two wrongs.
+
+## The narrow settle windows are harmless, and I can now say why
+
+Adopting the settle instant left `main_menu` and `extras` on per-element `rest()`
+— their windows are 12 units, below the 30-unit bar — and I recorded that as a
+gap. **It is not one.** `rest()` is malformed only for a **transient**, and the
+transients are precisely on the screens whose windows are wide:
+
+| screen | window | transients |
+|---|---|---|
+| `title` | 76 | `ptlogo1`/`ptlogo2` ×4, `pteff01`, `ptlogo_back2eff1…5`, `ptlogoall_eff` |
+| `publisher_logo` | 190 | `palogo_sqex_eff` |
+| `developer_logos` | 145 | `palogo_*_eff` ×3 |
+| **`main_menu`** | **12** | **none** |
+| **`extras`** | **12** | **none** |
+
+The discriminator is *returning to dark far before the screen's own end* —
+`ptlogo_back2eff1` is dark again at t=58 while the title runs to t=269 — as
+opposed to the ordinary fade-in-hold-fade-out that every menu element has, where
+`rest` at 255 **is** the settled pose and the final 0 is the exit.
+
+⚠️ **I am not claiming that as a rule.** Two screens having narrow windows *and*
+no transients could be coincidence; it is n = 2, and n = 2 is where I have gone
+wrong before. What it does mean is that **nothing measurable is being left on the
+table by the 30-unit bar today.**
+
+## Refuted, mine — "the menu residual is localised on the `ptloop` sweeps"
+
+I have written that twice. It came from reading the **bounding box** of the
+differing pixels, which sat at (441, 230) — the sweep position. Tested by sweeping
+the leaf's phase against the live-menu captures:
+
+| `main_menu`, sweep phase | differing |
+|---|---|
+| t=60 (barely on screen) | 0.063 % |
+| t=350 (mid-screen) | **0.183 %** |
+| t≥600 (parked off-screen) | **0.061 %** |
+
+✅ Two things fall out. **The capture shows no sweeps**: the port matches best
+when they are off-screen and three times worse when they cross the middle. And
+with them parked the residual's box is **834×358 at (445, 167)** — the *button
+column*, which is where the focus signature lives, not the sweep position.
+
+On `extras` the same test moves the box (398×295 at the sweep position at t=70,
+736×525 spread at t=700) while the **magnitude barely changes: 0.192 % against
+0.200 %**.
+
+🔴 **So the box moves with the sweeps and the residual does not.** A bounding box
+over scattered pixels tells you where the outermost differing pixels are, **not
+where the difference is** — and I had been quoting it as if it localised a cause.
+`verify-capture` prints that box, so this is a caution about reading my own tool.
+
+### And a first piece of evidence on whether the sweeps loop
+
+The disc gives one pass, t=0…600, ending parked off-screen at x=1521.
+`ORACLE-CAPTURES.md` says the title's sweeps *"move continuously"*, which I had
+taken as implying a loop. **The idle main-menu capture matches best with them
+off-screen**, which is evidence they run once and park.
+
+⚠️ One capture, one screen, and "best match" is a weak instrument for an absence
+— but it is the first evidence either way, and it points against looping. The
+loop-length field the Decoder decoded (`+0x08` of a nested record's header) would
+settle it outright; it is not in the pinned tag.