docs(testing): #132 — judge menu geometry by rendering; "just measure" was the trap

The guest's unfaithful rofi geometry was already documented in TESTING.md
§5. What was not, and what this closes, is that the bullet's fallback
advice — "measure text against the 40% window width instead" — is exactly
how #131 stayed wrong for weeks, and my own #131 fix made it stale on top
of that (the width is calc( 84ch min 65% ) now).

Measuring needs a width and a font, and both are per-theme: text menus
render through themes/<slug>/rofi.rasi, where boreal + neon-glass pinned a
fixed 620px while the rest used 40%, in fonts from Inter 11 to
JetBrainsMono 14. The item measured one combination no theme ships,
concluded "only truncates below 1920", and the truncation was live on a
2560 panel.

So §5 now says: judge by rendering — hardware, or `rofi -dmenu -theme <the
built rasi>` + `hyprctl layers` for the real width — and notes
checks.rofi-text-width guards the invariant that makes it fit, never how it
looks. Declined the other half (fixing the guest's fontconfig/icon cache):
the screenshots are useful as content checks, and a guest that lied
convincingly about spacing would be worse than one that obviously cannot.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

agent/BACKLOG.md

@@ -153,18 +153,6 @@ whether Nomarchy holds itself higher — darker label, or a darker accent mix
 for light palettes — and note `tools/check-theme-contrast.py` covers palette
 pairings only, never GTK widget surfaces. `[human]` for the aesthetic call.
 
-### 132. VM cannot judge rofi menu geometry
-
-The guest renders the picker with icons at roughly a quarter of `ui.iconSize`
-(44 → ~10px) and rows short enough that a 6-row root clips its last entry
-behind a scrollbar, though `lines = 8` and `dynamic = true` should fit it.
-Root is unchanged since before #105, so this is the guest's font/icon
-environment, not a regression — but it means `theme-shot.nix`/`menu-shot`
-screenshots are trustworthy for **menu content** and not for spacing, icon
-size, or truncation. Either fix the guest (fontconfig + icon cache in the
-test node) or document the gap in docs/TESTING.md §5 so the next agent does
-not chase it — right now nothing warns them.
-
 ### 133. No check pins the #107 legacy-name compat shim
 
 `lib.mkFlake`, doctor and lifecycle all still accept `theme-state.json`, and

docs/ROADMAP.md

@@ -555,6 +555,20 @@ Design/decision records and a running log of shipped work (items marked
   `%26`, `%3F`, `%23`, `caf%C3%A9`. **Unverified on purpose:** whether each
   vendor's page fills the box or auto-submits — testing that means posting into
   Bernardo's own accounts.
+- ✓ **The VM's verdict on menu geometry is worthless — and so is measuring
+  (#132, 2026-07-16):** the guest draws the picker with icons at ~¼ of
+  `ui.iconSize` and rows short enough to clip a 6-row root, so screenshots are
+  evidence for *which rows appear* and nothing else. Already documented; what
+  this closes is the **fallback advice**, which #131 proved was the actual trap:
+  "measure text against the 40% window width instead" assumed a width and a font
+  that **no theme shipped** (boreal pinned 620px in GeistMono 11; others 40% in
+  JetBrainsMono 14), concluded "only truncates below 1920", and was contradicted
+  by truncation on a 2560 panel. TESTING.md §5 now says to judge by rendering —
+  hardware, or `rofi -dmenu -theme <built rasi>` + `hyprctl layers` for the real
+  width — and notes `checks.rofi-text-width` guards the invariant that makes it
+  fit, never how it looks. Fixing the guest's fontconfig was declined: the
+  screenshots earn their keep as content checks, and a guest taught to lie
+  convincingly about spacing would be worse than one that obviously cannot.
 - ✓ **Menus are sized in `ch`, not in % of the monitor (#131, 2026-07-16):**
   Bernardo saw Recovery's labels ellipsize **on a 2560×1440 external** — which
   falsified the item's own model ("`width: 40%` + Inter 11 → only below ~1920;

docs/TESTING.md

@@ -148,9 +148,21 @@ Hyprland's headless backend otherwise aborts in a VM-only zero-output state.
 - **Menu geometry does not survive the guest**: the rofi picker draws with
   icons at roughly a quarter of `ui.iconSize` and rows short enough that a
   6-row root clips its last entry behind a scrollbar (`lines = 8` should
-  fit it). Menu screenshots are evidence for **which rows appear**, never
-  for spacing, icon size or label truncation — measure text against the
-  40% window width instead, or check on hardware (BACKLOG #132).
+  fit it) — the guest's font/icon environment, not a regression. Menu
+  screenshots are evidence for **which rows appear**, never for spacing,
+  icon size or label truncation.
+  **And do not "just measure" instead** — that is how #131 stayed wrong for
+  weeks. Measuring needs a width and a font, and both are per-theme: text
+  menus render through `themes/<slug>/rofi.rasi`, where boreal and
+  neon-glass pinned a fixed `620px` while the rest used `40%`, in fonts from
+  Inter 11 to JetBrainsMono 14. The item measured one combination that no
+  theme actually shipped, concluded "only truncates below 1920", and the
+  truncation was live on a 2560 panel. Since #131 the width is
+  `calc( 84ch min 65% )` — font-relative by design, so the arithmetic is
+  even less predictable from a spec sheet. **Judge it by rendering**: on
+  hardware, or with `rofi -dmenu -theme <the built rasi>` plus
+  `hyprctl layers` for the real width. `checks.rofi-text-width` guards the
+  invariant that makes it fit; nothing guards how it looks.
 
 ## 6. When something fails