port: H5 localises to one element, and the rotation rule that explained 14 of 16 is refuted

check-all's four remaining red rows. What I established, and two hypotheses that
died on the way -- the second is the one worth reading.

✅ build_12 / build_15 are ONE ELEMENT. All 951 differing pixels lie inside
pgloading_loop5 (pgloading_ring.png, 333x276 at [1,444]) and the diff's own bbox
x 69..301 y 478..710 sits entirely within it. That also answers, with no rule at
all, why build_00 and build_01 AGREE: the port's own draw log says they draw 7
elements to build_12's 10, and pgloading_loop5 is one of the three they never
draw. The loading screens that agree are the ones that never draw the element
the disagreement is in.

🔴 REFUTED, and it looked strong. ui_layout.rs:86 states in its own words that
"rotation_deg is decoded but NOT rendered", and the port does render it. A
census over all sixteen exported screens gave: every screen with a non-zero rest
rotation DIFFERS, every screen without agrees -- 6 of 6 both ways, including
both legacy rows. Widening it to any rotating element (rest rotation OR a
two-keyframe 360 spinner at any depth) breaks it: build_00 and build_01 carry
two spinners each, the port draws both, and they agree with the reference.

A rule that holds on 14 of 16 and fails on the two cases nobody had looked at is
a rule fitted to the rows it was built from. Recorded rather than deleted,
because the ui_layout.rs:86 comment is exactly what the next reader will find.

🟡 main_menu_jp / extras_jp carry the same sweep leaves -- ptloop01/pteff03 at
rot 30, ptloop02/pteff03a at rot -45 -- whose phase residual is the reason
already named for `title`, and their means (0.79, 0.66) sit with title's 0.44
rather than their EN twins' 3.94 and 6.74. Consistent with, not established:
nobody has isolated those leaves on those screens.

🔴 And an asymmetry this exposed, now DECLARED rather than left silent.
main_menu_jp contains exactly the six elements main_menu marks additive, and
extras_jp all nine of extras'. The map is keyed by screen name and the Decoder's
RB_BLENDCONTROL0 log was taken on the ENGLISH screens, so the port draws them
additive on EN and alpha-over on JP -- asserting by omission that the JP build
blends differently, which is the LESS likely possibility.

Both options assert something unmeasured; only one of them was visible. The map
is NOT extended (that would extrapolate a measurement onto a build nobody drove
to) and the claim is instead written into authored/rendering.json's
additive_elements_why, plus a low-priority ask H6 that says out loud it may not
be worth a boot -- MISSION §7 puts JP out of scope and it costs two rows.

check-all stays red on the same four. Nothing was excused.

Not settled: why the two renderers disagree on pgloading_loop5 specifically; the
JP blend question; H1 (key repeat); whether the splashes tick at the title's rate.

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

authored/rendering.json

@@ -222,6 +222,30 @@
   "being ONE means the fixed-function stage multiplies the SHADER's output by 1,",
   "and the shader has not been read. The port's alpha-over path measures 0.92-1.31x",
   "the frame mean on `ptbase`/`pteff05`, so it is not visibly wrong. Nothing here",
-  "changes it."
+  "changes it.",
+  "",
+  "🔴 2026-09-01 — THE JP SCREENS ARE NOT IN THIS MAP, AND THAT IS AN UNMEASURED",
+  "CLAIM THIS FILE IS MAKING BY OMISSION. Declared here rather than left silent.",
+  "",
+  "`main_menu_jp` contains exactly the elements `main_menu` marks additive --",
+  "ptloop01, ptloop02, ptframe1, ptframe2, pteff10, pteff12 -- and `extras_jp`",
+  "contains all nine of `extras`'. This map is keyed by SCREEN NAME, and the",
+  "Decoder's RB_BLENDCONTROL0 log was taken by driving the game to the ENGLISH",
+  "screens. So the port draws these elements additive on the EN screens and",
+  "alpha-over on the JP ones, and nothing measured says the game does that.",
+  "",
+  "The port is therefore asserting, by omission, that the JP build blends the same",
+  "elements differently from the EN build -- which is the LESS likely of the two",
+  "possibilities. Extending the map would extrapolate a measurement onto a build",
+  "nobody drove to, which is not the port's to do. Both options assert something",
+  "unmeasured; only one of them is visible. This paragraph is how the quieter one",
+  "is made visible. Asked in docs/port/BLOCKED.md.",
+  "",
+  "⚠️ It does not affect the deliverable: PORT-MISSION §7 puts localisation beyond",
+  "English out of scope and the JP screens are not in the boot path. It affects",
+  "`tools/port/verify-screen`, where main_menu_jp and extras_jp DIFFER by 0.79 and",
+  "0.66 -- magnitudes that sit with `title`'s 0.44 sweep-phase residual rather than",
+  "with their own EN twins' 3.94 and 6.74, which is consistent with the JP rows",
+  "carrying no additive contribution at all. Consistent with, not established."
  ]
 }