Two captures of the same animation disagree on frame counts by 1.947x, so
frames are not comparable across runs. Expressed as ratios to a long
in-capture baseline, both runs agree: loop period = 13.93 baselines (0.35%
apart), and the sweep starts 0.79-0.80 baselines BEFORE the plate (0.9%).
This answers F6: the sweep does not start at t=0 as the port has it, nor
exactly with the plate -- it leads the plate by about 40 title units, under
a second, which is consistent with what the human reported seeing.
Surfaces a conflict rather than smoothing it: unit 8's title rate of 1.0
units/frame (from ptcopyright) and the plate's 0.571 units/frame are 1.75x
apart in the SAME capture. Either an element's declared ramp is misread or
the two are not on one clock -- the port's clock:"shared" premise. The
ratios stand without a clock; the title-unit conversions are 🟡 pending F4.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Applies the fix unit 9 named. Twice a probe printed "armed", carried on and
wrote no draw log -- once because the window lookup failed, once with the
window found and the key sent. Sending the keystroke is not evidence the
logger responded.
After arming, the probe now polls for xenia_re_ui_draws_*.log to exist and
be non-empty, for up to 20 s, and aborts loudly if it does not appear. A
probe that cannot confirm its own instrument is recording is a probe whose
negatives mean nothing.
Narrower fixes were tried and were not enough: making the window lookup
fatal caught the first failure and not the second.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Unit 8's rate (0.514 units/frame) rests on one wrap, a start-to-wrap span
rather than a period. Hardening it needs a longer capture with two or more
wraps. Two attempts, both failed on the harness rather than the game.
First launch never started: the pgrep && echo || { } guard took the wrong
branch, no output directory was created and no process ran, while a stale
emulator from the previous iteration was still up. It looked like a running
capture for several minutes.
Second launch started, armed, pressed A and wrote no draw log at all --
canary.stdout stayed at 0 bytes and no xenia_re_ui_draws log appeared,
despite the script printing "armed at 8s". Likely a race with the orphaned
emulator from the first failure, not confirmed.
Unit 8's numbers are unaffected; they came from the intact f6 capture,
which is still on disk. The offset has two independent supports; the rate
still rests on a single wrap and the port should not ship on it.
The lesson, and it is the second harness failure of this shape: "armed at
8s" printed while nothing was being logged. The arming step reports success
on SENDING the keystroke, not on the logger responding -- the same silent
failure that cost the first F1 probe a run, which I "fixed" by making the
window lookup fatal. That fix was too narrow: the window was found, the key
was sent, and the log still never appeared. The check that would have
caught both is to wait for the draw log to exist and be non-empty after
arming, and abort loudly otherwise. A probe that cannot confirm its own
instrument is recording is a probe whose negatives mean nothing, and I have
now written that bug twice.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
Question, look-at and not-covered written before the work, per PROTOCOL's
units section.
One boot, one A to skip the attract video, then no input so the title
builds in undisturbed. The sweeps are the two rotated 600%-scaled strips,
identified by size: NDC 1.38x3.15 and 1.39x3.15, matching the corpus's own
independently measured AABB height of 1134 px (2*1134/720 = 3.15).
Drawn alphas run 8, 24, 33, 50, 58, 74, 83, 100, 107 and 16, 41, 67, 91,
116, 128... pteff03's LEAF alpha is bounded below by 128 (keys 0:255
150:128 540:255 600:255). 8 < 128, so the leaf cannot produce it alone.
The parent's alpha is multiplied in.
That refutes the port's screen_view.gd decode that "the leaf runs on its
OWN timeline and the parent's alpha is NOT multiplied in" -- which is
exactly what that file asked for. It flagged honestly that every
observation behind it had parent alpha 0, so "the leaf wins" and "the
parent is ignored because it draws nothing" were never separated, and named
t=100..238 as the separating interval. This capture is in that interval.
Bears on F6's original report: the parent ramps 0->255 across t=70..100, so
if it multiplies in the sweep is invisible before ~70 and dim until 100. A
human reporting it starts late is seeing a real gate -- the parent's ENTRY
ramp, not the 238 cluster, which unit 1 showed is an exit.
Reach: one boot; quads identified by size against a previously measured
AABB, not by name, since the draw stream carries no names. The bound
argument needs only that the leaf minimum is 128, which is from the disc.
It does NOT establish the combination is plain leaf x parent rather than
some other one that also dips below 128 -- only that the parent
participates.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t
