re(ui): withdraw the mechanism -- "palette" was an explanation, not a finding

Last iteration I wrote that a bundle is a palette whose elements are
selectively activated. The disjoint glow/logo phases have two
explanations and I asserted one:

  1. one bundle, some elements run then others;
  2. two bundle-loads shown in sequence (entries 11 and 14 are twins
     declaring identical sprites).

The draw log's tex[base=...] looked like it would separate them. It does
not, and the control is in the same table:

  publisher splash  f1-90     0x11C30000, 0x10000000
  glows             f94-115   0x11C30000, 0x10000000
  logos             f116-211  0x11C30000, 0x10000000

The publisher splash is certainly a DIFFERENT bundle from the developer
splash, and it uses the same base. So 0x11C30000 is a reused upload slot,
not a bundle identity, and the test cannot choose between the two
hypotheses.

Survives: a bundle's declared elements are not what gets drawn.
palogo_anima and palogo_gamearts carry byte-identical keyframe times and
in the same run one is drawn 95 frames and the other none -- and
whichever twin was active declares both. The phases are strictly disjoint
(0 overlapping frames in 235).

Withdrawn: the mechanism. The practical consequence is unchanged --
compositing every element of a bundle does not reproduce what the game
shows over time -- but the why is not established and I stated it as
though it were.

What would separate them: a per-draw capture recording the bundle each
draw came from, or a file-IO log showing whether a second RATC entry is
read between frames 115 and 116.

METHOD: a shared resource address does not identify the resource's owner;
and state the mechanism as a separate claim from the observation, or the
weaker one inherits the stronger one's evidence.
This commit is contained in:
Sylpheed RE agent
2026-08-29 04:51:34 +00:00
parent baed44a9ea
commit 2a086051b3
4 changed files with 70 additions and 2 deletions

View File

@@ -359,8 +359,14 @@ authored version can be deleted.
**Verified against its own refutation:** across all 235 captured frames,
**zero** contain both a glow and a logo; the switch is one clean boundary with
two sprites either side.
🔴 **And it goes further than start times — a bundle is a palette, not a
script.** Entry 11 declares *three* logo/glow pairs; only two are ever drawn.
🔴 **And it goes further than start times — a bundle's declared elements are
not what gets drawn.** ⚠️ I previously called this "a bundle is a palette,
selectively activated"; **the mechanism is withdrawn** — the evidence does not
choose between "one bundle, selective activation" and "two compositions shown
in sequence". The texture-base test that looked like it would separate them
fails its own control: the publisher splash is a different bundle and uses the
same base `0x11C30000`, so that address is a reused upload slot, not an
identity. The consequence for you is unchanged; the reason is not established. Entry 11 declares *three* logo/glow pairs; only two are ever drawn.
`palogo_anima` gets **0 frames** while `palogo_gamearts` gets **95**, from
byte-identical keyframe times. (Reach: the capture covers frames 1214, so
"never in the window".) **Compositing every element of a bundle does not

View File

@@ -808,3 +808,14 @@ agent's loop prompt, i.e. nowhere durable. See [`README.md`](README.md) for the
frames and the other not at all. No amount of re-reading the placement data can
explain that, and the pair is worth more than a survey — when a hypothesis says
"the data decides", look for two records that agree and behave differently.
* **A shared resource address does not identify the resource's owner.** The draw
log's `tex[base=…]` looked like it would say whether two animation phases came
from the same bundle. All three splash phases report `0x11C30000` — including
the publisher splash, which is certainly a *different* bundle. The address is a
reused upload slot. The control was free and sitting in the same table; without
it the shared base would have read as proof of a shared bundle.
* **State the mechanism as a separate claim from the observation.** "Declared
elements are not what gets drawn" is measured and holds. "Because one bundle
activates its elements selectively" was an explanation I attached to it, and it
is not established. Bundling the two let the weaker claim inherit the stronger
one's evidence.

View File

@@ -581,3 +581,10 @@ neighbourhood, not just the line.
gets 0 frames against `palogo_gamearts`'s 95, from byte-identical keyframe
times. (Reach: within the capture's frames 1214.)
[`ui-group-start-time.md`](structures/ui-group-start-time.md)
* "the glow and logo phases are one bundle with elements selectively activated"
**mine, and withdrawn as unestablished.** The alternative — two compositions
shown in sequence — fits equally. The texture-base test fails its control: the
publisher splash is a different bundle and shares the base `0x11C30000`, so
that address is a reused upload slot, not a bundle identity. What survives is
that declared elements ≠ drawn elements.
[`ui-group-start-time.md`](structures/ui-group-start-time.md)

View File

@@ -107,3 +107,47 @@ That is the same conclusion the boot-order work reached from the other end
⚠️ Concretely: **compositing every element of a bundle does not reproduce what
the game shows over time.** It is the right thing for a static screen that
settles, and it is not a timeline.
---
## 🔴 Narrowing "a bundle is a palette" — the mechanism is NOT established
**2026-08-29.** The glow phase and the logo phase are disjoint, but there are two
explanations and I asserted one of them:
1. **one bundle, selective activation** — the game runs some of entry 11's
elements, then others;
2. **two bundle-loads in sequence** — the game shows one composition, then
another (entries 11 and 14 are twins declaring identical sprites).
The draw log records each draw's **texture base**, which looked like it would
separate them. It does not:
| phase | frames | texture bases |
|---|---|---|
| publisher splash | 190 | `0x11C30000`, `0x10000000` |
| glows | 94115 | `0x11C30000`, `0x10000000` |
| logos | 116211 | `0x11C30000`, `0x10000000` |
**The test fails its own control.** The publisher splash is certainly a different
bundle from the developer splash — different entry, different artwork — and it
uses the *same* base. So `0x11C30000` is a reused upload address, not a bundle
identity, and it cannot distinguish hypothesis 1 from hypothesis 2.
### What survives, and what I withdraw
**Survives:** a bundle's declared elements are not what gets drawn.
`palogo_anima` and `palogo_gamearts` carry byte-identical keyframe times, and in
the same run one is drawn for 95 frames and the other for none — whichever of the
twins was active declares *both*. The phases are also strictly disjoint (0 frames
of overlap in 235).
🔴 **Withdrawn:** the mechanism. "One bundle, elements activated selectively" was
my reading, and the evidence does not choose it over "two compositions shown in
sequence". The practical consequence is the same either way — compositing every
element of a bundle does not reproduce what the game shows over time — but the
*why* is not established and should not have been stated as though it were.
❔ What would separate them: a per-draw capture recording the **bundle** each draw
came from, or a kernel/file-IO log showing whether a second RATC entry is read
between frames 115 and 116.