re: the primitive colour census -- and it refutes 38 of my own 80 forced verdicts

A disc-wide census of the ARGB that keyless elements carry.

Every full-screen *eff00* PRIMITIVE is pure black at its various alphas
(ff000000, 7f000000, 40000000, b2000000, cc000000, d4000000, 00000000). Black at
alpha a over content is exactly an alpha-over dim or fade, and an additive black
quad would be a no-op nobody would author -- so this narrows the open blend
question a long way. The only non-black primitive on the disc is pbafc.prm, RGB
00e8e0 cyan at alphas up to ff, and it is 844x600, NOT full-screen, so it sits
outside forced_backdrop's geometry guard. It is now the sole additive candidate.

The census also refutes my own argument for nearly half its verdicts. Of the 80
forced-first instances only 42 are .prm; 38 are .tbm carrying fade ffffffff. A
SOLID white quad at alpha 255 painted first would make the screen white, and no
screen is white -- so a .tbm is a white modulation on a texture, and element
alpha does not establish its coverage.

That is the .t32 error one file extension further out. I guarded that with
el.sprite.is_some(), which fixed the symptom and not the cause: an element's
alpha is not its texture's opacity, and only an untextured primitive makes the
two the same fact.

So 42 verdicts stay decoded and 38 drop to inferred -- still almost certainly
right, since all are named *base*, all are full-screen, and pfbase.tbm's first
position is measured in the running game, but that is a name-and-role argument
which this page elsewhere calls the weaker kind.

The code is deliberately unchanged. Restricting forced_backdrop to .prm would
send eleven screens' backgrounds back to u32::MAX -- last -- which is the
blank-screen bug the rule was written to fix. Downgrading the status is honest;
reverting the position would be wrong. The 42/38 split is pinned by a test so
anyone tightening the rule sees what it costs.

Separately, on the port's black_hold_units ask: four more no-input boots yielded
one usable log, which armed late and missed the publisher splash, so the sample
is still two runs spanning 3 and 4 frames. Their 6.5-9.2 range stands. And a
reason it may not be resolvable this way: the draw log DROPS frame numbers -- in
the 3-frame run, frames 121 and 124 are absent entirely, so "frames with no
sprite" and "span of frame numbers" are different quantities.

Their statistical correction is taken: at n=3 the sample SD (3.893) is the
estimator, not the population SD (3.179), making my run 1.88 sigma from the
corpus mean rather than 2.31.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QsEPXWVaEpyfudtR6re1Pd

docs/re/structures/ui-forced-backdrop.md

@@ -129,6 +129,40 @@ being wrong.
 primitives, which are solid quads and do occlude what they cover. That is also the
 only case `derived_paint_order` consults it for.
 
+## 🔴 Self-refutation: the argument is sound for only 42 of the 80
+
+A disc-wide census of the *colour* these elements carry breaks the rule's premise
+for nearly half its verdicts.
+
+| the 80 forced-first instances | count | fade ARGB |
+|---|---|---|
+| `.prm` — untextured solid quads | **42** | pure black (`ff000000`, `7f000000`, `40000000`, …) |
+| `.tbm` | **38** | **`ffffffff`** — white at full alpha |
+
+**A solid white quad at alpha 255 painted first would make the screen white.** No
+screen is white. So a `.tbm` is not a solid quad: `ffffffff` is a white
+*modulation* on a texture, which is exactly what a background bitmap carries.
+
+🔴 **And that means element alpha does not establish coverage for them** — the same
+error the `.t32` guard already caught, one file extension further out. I fixed that
+symptom (`el.sprite.is_some()`) rather than its cause: **an element's alpha is not
+its texture's opacity, and only an untextured primitive makes the two the same
+thing.**
+
+**What this does and does not change:**
+
+* ✅ The **42 `.prm`** verdicts stand as decoded. For a solid colour quad the fade
+  *is* the pixel, so opacity and coverage are the same fact.
+* 🟡 The **38 `.tbm`** verdicts are **not** decoded. They are almost certainly still
+  right — every one is named `*base*`, is full-screen, and one of them
+  (`pfbase.tbm`) has its first position **measured in the running game** — but that
+  is a name-and-role argument, which this page elsewhere argues is the weaker kind.
+* ⚠️ **The code is deliberately unchanged.** Restricting `forced_backdrop` to
+  `.prm` would send `pcbase`, `pnbase`, `pqbase`, `pubase`, `pvbase`, `pjbgbase2`,
+  `po_menu_base` and the four `px_*_base` back to `u32::MAX` — last — which is the
+  blank-screen bug this rule was written to fix. Downgrading their *status* is
+  honest; reverting their *position* would be wrong.
+
 ## Reach
 
 ⚠️ **Assumes straight alpha-over blending.** Blend mode is ❔ on
@@ -136,6 +170,16 @@ only case `derived_paint_order` consults it for.
 would not occlude, and the rule would then be placing it wrongly. The
 `palogo_eff0.prm` control is evidence the assumption holds at least there.
 
+✅ **The colour census narrows this a long way.** Every full-screen `*eff00*`
+primitive on the disc is **pure black** at its various alphas — `ff000000`,
+`7f000000`, `40000000`, `b2000000`, `cc000000`, `d4000000`, `00000000`. Black at
+alpha *a* over content is exactly what an alpha-over dim or fade looks like, and an
+*additive* black quad would be a no-op, so a designer would not author one. The
+single non-black primitive on the disc is **`pbafc.prm`**, RGB `00e8e0` (cyan) at
+alphas up to `ff` — and it is **844×600, not full-screen**, so it is outside this
+rule's geometry guard entirely. ❔ Whether *it* is additive is still open, and it is
+now the only candidate.
+
 ⚠️ **It gives a lower bound, not an ordering.** It settles the 80 instances where
 occlusion forces the position, and says nothing about the 50 where the primitive
 is opaque only part of the time — including `pteff00.prm`, whose place on top is