findings: D243 M-144 — user confirms real N64 does NOT show the abseil shake

Closes the open question M-143 ended on: this is a genuine PC-only
divergence, not an original-game quirk. Since bondviewUpdatePlayerCollisionPositionFields's
smoothing-filter math is decomp-exact and already g_ClockTimer-scaled, the
bug must be upstream of the filter -- either the position warp itself is
wrong/larger on PC, or a call-ordering desync around the CAMERAMODE_INTRO
transition. Narrows the next step to a single probe: log raw field_488.pos
and field_3B8 (pre-filter) around the warp tick, instead of the open-ended
"needs N64 hardware" framing M-143 left off on.

Claude-Session: https://claude.ai/code/session_01KwZViAFaXua3PKgHHjNgvi

docs/dev/findings-index.csv

@@ -139,7 +139,7 @@ D239,?,"QoL ask (M-106, user QA):",CLOSED — executed in the v0.2.0 prep pass (
 D240,OPEN,"Player gunshot SFX timing/cadence reportedly does not match the N64 original's rate (M-106, user QA report).","OPEN — not root-caused; static call-site tracing only, no runtime verification possible in this environment."
 D241,OPEN,Player gunshot SFX goes silent under some conditions —,"OPEN — not newly root-caused; high confidence this is D207 reproduced, not an independent bug."
 D242,?,Player-death sequence UX regression vs N64 original:,NOT A PORT-LOGIC BUG as far as static analysis can tell.
-D243,OPEN,"Dam end-of-level cutscene (the abseil/bungee sequence, D148/D160's subject):",OPEN — M-143: mechanism named.
+D243,OPEN,"Dam end-of-level cutscene (the abseil/bungee sequence, D148/D160's subject):","OPEN — M-144: CONFIRMED PC-only (user, direct N64 comparison) —"
 D245,OPEN,IsWater water: two competing patterns with a visible seam that moves as the player looks around (mouse/aim) —,"OPEN — REOPENED, M-142 headless probe found the tc-shift k measurably flips during ordinary view rotation (new root-cause evidence); an opt-in GE_D245_FIXEDSHIFT candidate is build-verified but needs…"
 D246,OPEN,"Tiny pixel strips at the left and right edges of the screen, ""like overscan"" —","OPEN — one candidate ruled out (M-116 follow-up), root cause not found."
 D247,RESOLVED,Black bars top and bottom of screen —,"NOT A BUG — confirmed faithful, unmodified N64 decomp behaviour, no code change made."

docs/dev/findings.md

@@ -546,7 +546,7 @@ covers D24–D69; the log continues in §H (D32 procedure, D70–D121).
 | D240 | **Player gunshot SFX timing/cadence reportedly does not match the N64 original's rate (M-106, user QA report).** — full `## D240` entry at file tail | **OPEN — not root-caused; static call-site tracing only, no runtime verification possible in this environment.** Confidence LOW-MEDIUM that this is a *new* bug distinct from the D155/D186/D193/D204/D209 timing-keystone family (all of which gate the identical `deltaFrames→speedgraphframes→g_ClockTimer→g_GlobalTimer` chain this SFX trigger consumes).… |
 | D241 | **Player gunshot SFX goes silent under some conditions — reported on Bunker with the alarm sounding, "or some other factor" — but only for PP7 and AK47, Klobb…** — full `## D241` entry at file tail | **OPEN — not newly root-caused; high confidence this is D207 reproduced, not an independent bug.** Recommend folding this repro into D207 (or closing D241 as a duplicate once D207 is reopened) rather than tracking separately.… |
 | D242 | **Player-death sequence UX regression vs N64 original: PC requires an LMB click to proceed to the mission-failed/file-select screen; user recalls N64 auto-plays…** — full `## D242` entry at file tail | **NOT A PORT-LOGIC BUG as far as static analysis can tell.** Confidence HIGH that the LMB-click skip path is faithful original behavior (Z_TRIG-mapped, exists unmodified in `bondview2.c`), not a defect to remove.… |
-| D243 | **Dam end-of-level cutscene (the abseil/bungee sequence, D148/D160's subject): the camera violently shakes/"spazzes" during each of the scripted camera-angle…** — full `## D243` entry at file tail | OPEN — M-143: mechanism named. The `gBondViewCutscene` look-at branch reads `field_3C4/8/C`, a leaky-integrator low-pass filter of Bond's real position that isn't reset when the scripted cutscene warps him — the filter needs ~1s to catch up, producing the shake. The filter's own update is `g_ClockTimer`-scaled (looks decomp-faithful); open question is whether real N64 hardware shows the same transient, which would make this not a port bug at all. D146 still fully decoupled (zero hits, 3rd run running). |
+| D243 | **Dam end-of-level cutscene (the abseil/bungee sequence, D148/D160's subject): the camera violently shakes/"spazzes" during each of the scripted camera-angle…** — full `## D243` entry at file tail | OPEN — M-144: CONFIRMED PC-only (user, direct N64 comparison) — real N64 does not show this shake. Mechanism (M-143): the `gBondViewCutscene` look-at branch reads `field_3C4/8/C`, a leaky-integrator low-pass filter of Bond's real position that isn't reset when the scripted cutscene warps him, producing a ~1s look-at snap. Filter math is decomp-exact and `g_ClockTimer`-scaled, so the bug must be upstream: either the position warp itself is wrong/bigger on PC, or a call-ordering desync around the `CAMERAMODE_INTRO` transition. Next: probe raw `field_488.pos`/`field_3B8` around the warp tick. D146 still fully decoupled (zero hits, 3 runs). |
 | D245 | **IsWater water: two competing patterns with a visible seam that moves as the player looks around (mouse/aim) — "looks almost exactly like skybox" (M-116, user…** — full `## D245` entry at file tail | OPEN — REOPENED, M-142 headless probe found the tc-shift `k` measurably flips during ordinary view rotation (new root-cause evidence); an opt-in `GE_D245_FIXEDSHIFT` candidate is build-verified but needs a live A/B, not shipped as default.… |
 | D246 | **Tiny pixel strips at the left and right edges of the screen, "like overscan" — look like raw pixels, not 3D graphics (M-116, user QA report).** — full `## D246` entry at file tail | **OPEN — one candidate ruled out (M-116 follow-up), root cause not found.** Step (1) from the original plan is done… |
 | D247 | **Black bars top and bottom of screen — possible aspect-ratio defect (M-116, user QA report).** — full `## D247` entry at file tail | **NOT A BUG — confirmed faithful, unmodified N64 decomp behaviour, no code change made.** `GE_PCDUMP` captures (both against the pre-existing save and a fresh-EEPROM run, to rule out a stale `Screen` option from earlier test sessions) show the exact same inset on Frigate… |
@@ -10699,7 +10699,9 @@ crash class C2 (Facility `-level_34`, Runway `-level_35`): `import_texture_i8` A
 
 **M-142 update: live playthrough with both probes on, real signal, still not root-caused.** User played Dam to the abseil cutscene twice this session with `GE_D243=1 GE_D160=1` set (first run), then again with a new `GE_D243CAM` probe added. **Key new fact: the visible "violent shake" symptom reproduced on BOTH runs, but the `D146` stale-memory burst fired on NEITHER run** (log captured well past the historical 1600-3900-frame window both times, zero `D146:` lines) — this decouples the two symptoms M-107/M-109 had been treating as related. The shake is real, reproduces every time, and has nothing observable to do with the D146 mechanism; whatever drives it must be a silent bad-value computation (camera position/angle math), not a logged error. **Camera code path narrowed (partially):** `bondviewFrozenCameraTick`'s `CAMERAMODE_POSEND` branch (`bondview2.c:1537+`) has three sub-paths — `g_CameraLookAtBondPad` look-at, a `gBondViewCutscene`-struct spherical-angle path, and a pad-orbit fallback (`flt_CODE_bss_80079A00` angle accumulated by `g_GlobalTimerDelta` each tick). Added a `GE_D243CAM` probe (`#ifdef PORT`) to the orbit-fallback branch to check whether `g_GlobalTimerDelta` jitter there explains the shake — **it fired zero times**, meaning the Dam abseil cutscene does NOT use that branch; the real driver is one of the two earlier `return`-before-my-probe branches (`g_CameraLookAtBondPad` or `gBondViewCutscene`), not yet instrumented. Next session: add the same style of probe to those two branches (log `pos`/`pos2`/`gBondViewCutscene->theta,verta` every call) and re-capture — same repro (Dam, Agent, to the abseil cutscene, `GE_D160=1` to confirm mode(7) still fires 3x) works reliably and takes only a few minutes end to end.
 
-**M-143: live capture with the two new probes names the mechanism — a leaky-integrator position filter not reset across a scripted position warp; likely decomp-faithful, open question is whether it's a real port bug at all.** User replayed the same Dam-abseil repro with `GE_D243=1 GE_D160=1 GE_D243CAM=1` (probes from the M-142 next-step now added to both previously-uninstrumented `CAMERAMODE_POSEND` sub-paths: `g_CameraLookAtBondPad` look-at and the `gBondViewCutscene` spherical-angle branch). **The `gBondViewCutscene` branch fires** (confirmed live — the pad-orbit branch stays at zero hits, third confirmation). Within it, `pos` (the eye) stays exactly fixed for the whole cutscene segment while `pos2` (the look-at target) is the thing moving — and tracing which of the branch's two `pos2` assignments actually ran (the `dword_CODE_bss_80079A18 == CAMERAMODE_INTRO` case reads `g_CurrentPlayer->field_3C4/3C8/3CC` directly; the `else` case derives `pos2` from `pos` + a `theta`/`verta` trig offset) rules out the trig path by arithmetic: with `theta`/`verta` observed constant across a stretch of frames, the trig formula only allows `pos2` to vary by a fraction of a unit, but the log shows `pos2.y` sweeping from **-22832 to +691 over roughly the first 60 frames** of the branch, then settling into a small ~110-unit 4-frame-period wobble — only the raw-field-read (`CAMERAMODE_INTRO`) path is consistent with a swing that large. **`dword_CODE_bss_80079A18` is scripted, not a mode flag Claude findings mislabeled** — it's set only from `ai->LOOK_AT_BOND_FLAG` in `chrai.c:4007`, i.e. the Dam level's own AI/cutscene script explicitly requests "look at Bond" framing for this segment; this is by design, not a bug in the flag itself. **`field_3C4/3C8/3CC` is not a raw position — it's a leaky-integrator low-pass filter of Bond's real collision position:** `bondviewUpdatePlayerCollisionPositionFields()` (`bondview2.c:4702`, called from three sites including `bondviewFrozenMoveBond` — the puppet/cutscene-movement driver used while Bond is "frozen" for a scripted sequence) runs `field_3B8 = FACTOR_1*field_3B8 + field_488.pos` **`g_ClockTimer` times per call** (already delta-scaled, one of porting-notes' documented `g_ClockTimer`-iteration sites — this specific update looks decomp-faithful, not a naive per-frame-not-per-tick bug), then `field_3C4/8/C = field_3B8 * FACTOR_2` where `FACTOR_1`/`FACTOR_2` are complementary constants (`0.9`/`0.100000024` non-EU, `0.8812`/`0.1188` EU) chosen so the filter's steady state converges back to the real `field_488.pos` — i.e. `field_3C4/8/C` is a **lagged, smoothed shadow of Bond's actual position**, not his position itself. **The mechanism this explains:** the instant the abseil sequence's scripted camera engages `LOOK_AT_BOND_FLAG`, Bond's actual `field_488.pos` (driven by `bondviewFrozenMoveBond`'s animation/offset-based puppet movement) jumps to wherever the cutscene's puppet animation starts — but the `field_3B8` accumulator was still converged on wherever Bond had been standing/walking a moment before (a very different location, hence the ~20,000-unit initial gap), and it takes on the order of a couple dozen ticks of the geometric decay to catch up — visually, a fixed eye with a look-at target that starts wildly displaced and snaps toward the puppet over about a second, i.e. exactly the reported "violent shake." **Open question, not yet answerable from this repo alone: is this also what real N64 hardware shows?** The filter's own update is `g_ClockTimer`-scaled (frame-rate-correct by the same standard porting-notes.md already applies to other delta-scaled code), so nothing found this session points at a PC-specific timing divergence in *this* filter — if the N64 original also snaps Bond's `field_488.pos` for this scripted segment without resetting `field_3B8` (it's only ever zero-initialized once, at player creation in `player.c:271-273`, never re-seeded on a cutscene-mode entry anywhere in `src/game`), the same transient would play out identically on real hardware, which would make this **not a port bug at all** — an original-game quirk that happens to be more noticeable now, or previously undocumented on N64 itself. Confirms (third run in a row): **zero `D146:` hits** — the shake and the D146 stale-memory burst remain fully decoupled; treat them as two separate, unrelated findings going forward, not two symptoms of one cause. **Next, concrete:** (1) the decisive test is an N64 emulator/hardware capture of the identical Dam-abseil moment to see if the same look-at snap is visible there — if yes, close this as "faithful to original, not a port defect" and move D148/D173 (the broader cutscene-bug umbrella) up instead; (2) if no N64 access is available, the next-best port-side check is logging `field_488.pos` and `field_3B8` (not just the already-smoothed `field_3C4/8/C`) at the exact tick `dword_CODE_bss_80079A18` flips to `CAMERAMODE_INTRO`, to confirm the Line truncated
+**M-143: live capture with the two new probes names the mechanism — a leaky-integrator position filter not reset across a scripted position warp; likely decomp-faithful, open question is whether it's a real port bug at all.** User replayed the same Dam-abseil repro with `GE_D243=1 GE_D160=1 GE_D243CAM=1` (probes from the M-142 next-step now added to both previously-uninstrumented `CAMERAMODE_POSEND` sub-paths: `g_CameraLookAtBondPad` look-at and the `gBondViewCutscene` spherical-angle branch). **The `gBondViewCutscene` branch fires** (confirmed live — the pad-orbit branch stays at zero hits, third confirmation). Within it, `pos` (the eye) stays exactly fixed for the whole cutscene segment while `pos2` (the look-at target) is the thing moving — and tracing which of the branch's two `pos2` assignments actually ran (the `dword_CODE_bss_80079A18 == CAMERAMODE_INTRO` case reads `g_CurrentPlayer->field_3C4/3C8/3CC` directly; the `else` case derives `pos2` from `pos` + a `theta`/`verta` trig offset) rules out the trig path by arithmetic: with `theta`/`verta` observed constant across a stretch of frames, the trig formula only allows `pos2` to vary by a fraction of a unit, but the log shows `pos2.y` sweeping from **-22832 to +691 over roughly the first 60 frames** of the branch, then settling into a small ~110-unit 4-frame-period wobble — only the raw-field-read (`CAMERAMODE_INTRO`) path is consistent with a swing that large. **`dword_CODE_bss_80079A18` is scripted, not a mode flag Claude findings mislabeled** — it's set only from `ai->LOOK_AT_BOND_FLAG` in `chrai.c:4007`, i.e. the Dam level's own AI/cutscene script explicitly requests "look at Bond" framing for this segment; this is by design, not a bug in the flag itself. **`field_3C4/3C8/3CC` is not a raw position — it's a leaky-integrator low-pass filter of Bond's real collision position:** `bondviewUpdatePlayerCollisionPositionFields()` (`bondview2.c:4702`, called from three sites including `bondviewFrozenMoveBond` — the puppet/cutscene-movement driver used while Bond is "frozen" for a scripted sequence) runs `field_3B8 = FACTOR_1*field_3B8 + field_488.pos` **`g_ClockTimer` times per call** (already delta-scaled, one of porting-notes' documented `g_ClockTimer`-iteration sites — this specific update looks decomp-faithful, not a naive per-frame-not-per-tick bug), then `field_3C4/8/C = field_3B8 * FACTOR_2` where `FACTOR_1`/`FACTOR_2` are complementary constants (`0.9`/`0.100000024` non-EU, `0.8812`/`0.1188` EU) chosen so the filter's steady state converges back to the real `field_488.pos` — i.e. `field_3C4/8/C` is a **lagged, smoothed shadow of Bond's actual position**, not his position itself. **The mechanism this explains:** the instant the abseil sequence's scripted camera engages `LOOK_AT_BOND_FLAG`, Bond's actual `field_488.pos` (driven by `bondviewFrozenMoveBond`'s animation/offset-based puppet movement) jumps to wherever the cutscene's puppet animation starts — but the `field_3B8` accumulator was still converged on wherever Bond had been standing/walking a moment before (a very different location, hence the ~20,000-unit initial gap), and it takes on the order of a couple dozen ticks of the geometric decay to catch up — visually, a fixed eye with a look-at target that starts wildly displaced and snaps toward the puppet over about a second, i.e. exactly the reported "violent shake." **Open question, not yet answerable from this repo alone: is this also what real N64 hardware shows?** The filter's own update is `g_ClockTimer`-scaled (frame-rate-correct by the same standard porting-notes.md already applies to other delta-scaled code), so nothing found this session points at a PC-specific timing divergence in *this* filter — if the N64 original also snaps Bond's `field_488.pos` for this scripted segment without resetting `field_3B8` (it's only ever zero-initialized once, at player creation in `player.c:271-273`, never re-seeded on a cutscene-mode entry anywhere in `src/game`), the same transient would play out identically on real hardware, which would make this **not a port bug at all** — an original-game quirk that happens to be more noticeable now, or previously undocumented on N64 itself. Confirms (third run in a row): **zero `D146:` hits** — the shake and the D146 stale-memory burst remain fully decoupled; treat them as two separate, unrelated findings going forward, not two symptoms of one cause. **Next, concrete (superseded by M-144 below — kept for the reasoning trail):** (1) the decisive test is an N64 emulator/hardware capture of the identical Dam-abseil moment to see if the same look-at snap is visible there — if yes, close this as "faithful to original, not a port defect" and move D148/D173 (the broader cutscene-bug umbrella) up instead; (2) if no N64 access is available, the next-best port-side check is logging `field_488.pos` and `field_3B8` (not just the already-smoothed `field_3C4/8/C`) at the exact tick `dword_COLine truncated
+
+**M-144: CONFIRMED — real N64 does NOT show this shake (user, direct comparison).** This settles the open question M-143 ended on: the abseil cutscene's look-at snap is a genuine PC-only divergence, not an original-game quirk. Since the filter math itself (`bondviewUpdatePlayerCollisionPositionFields`) is decompiled/byte-exact and its update loop is already `g_ClockTimer`-scaled, the bug is not "the filter is unreset" in isolation — that property is presumably just as true in the original binary, since nothing in `src/game` differs from what N64 would execute at this call site. **Reframed root-cause question:** something upstream of the filter must differ between N64 and PC — either (a) the actual position jump the filter is asked to absorb is larger/different on PC than on N64 (i.e. `field_488.pos` itself warps to a wrong or differently-timed value at cutscene entry — a genuine bug in the warp, with the filter just faithfully rendering visible whatever bad delta it's fed), or (b) something about call *ordering/frequency* around the `CAMERAMODE_INTRO` transition differs — e.g. `bondviewUpdatePlayerCollisionPositionFields()` (three call sites: two in normal/frozen movement ticks, one in the `DEATH_CAM_SP` branch) running an extra or missing time relative to when `g_CameraMode`/`dword_CODE_bss_80079A18` actually flips, which would desync the filter's internal state from what N64's single deterministic tick loop produces even though the per-call math matches. **Next, concrete (single next step, supersedes the N64-comparison item above since that question is now closed):** add one more `#ifdef PORT` probe logging `g_CurrentPlayer->field_488.pos` (the raw, pre-filter position) and `g_CurrentPlayer->field_3B8` (the filter's raw accumulator, pre-`FACTOR_2` scale) every tick for a few seconds either side of the moment `dword_CODE_bss_80079A18` becomes `CAMERAMODE_INTRO` — this directly shows (i) how large the real position jump is at the exact warp tick (confirms or refutes candidate (a)) and (ii) whether `field_3B8` is already desynced from `field_488.pos` *before* the warp even happens, which would point at candidate (b) instead. Do not touch `src/game/*.c` behavior yet (rule #2) — this is still diagnosis; if the eventual root cause is call-ordering in the port's scheduler (`port/src/gesched.c`) rather than game logic, that's a legitimate port-layer fix with no `#ifdef PORT` needed in `src/game` at all.
 
 **Status (from §F table):** **OPEN — M-109 re-analysis of the same session's raw logs corrects the timing/pattern claims above; the D134/pendingGfx race hypothesis is likely wrong.** Confidence MEDIUM on the correction, LOW-MEDIUM on the new lead. Re-reading `data/playtest_d160.log`/`_run2.log` at the `g_framesRendered` level (not just grepping for `D146`) shows the D146 burst fires **~1600-3900 frames (tens of real seconds) *after*** `bossReturnTitleStage`/the `camera_switch(7)` calls, not during them, in **both** runs — "right in the camera-cut window" and "run 1 only" are both wrong as stated above. This also weakens the D134/`pendingGfx` citation: `osSpTaskStartGo` runs `gfx_run()` synchronously and inline (`port/src/libultra.c:1232-1258`), so nothing from the cutscene's own DL submission is still in flight by the time any teardown code runs — the port doesn't have the async-RSP race the hypothesis above assumes. **New lead:** whatever screen renders in that multi-thousand-frame gap after mission-complete is the more likely site — probably `MENU_MISSION_COMPLETE` (`front.c:7267`, `constructor_menu0D_missioncomplete`) or an adjacent briefing/file-select screen in that chain, same general class as D75 (front-end model absence) / D141 (menu bad-pointer bug), not a cutscene-render race. Of the 4 repeating fault addresses, 3 read as literal zero words and only 1 matches the `0xfafbfbfc…` pattern, arguing against a deliberate poison-fill (none found anywhere in `port/`) and for either genuinely-unwritten memory or a decode landing inside unrelated valid data. Next: an env-gated `front.c` menu-transition trace (`MENU_*` id + `g_framesRendered` on every transition after `bossReturnTitleStage`) plus a `GE_PCDUMP` window over frames ~4500-8000 (not the camera-cut window) to name the exact screen/segment. Cross-ref D160 (this supersedes its stale "cutscene skipped" framing with a "cutscene renders corrupted" one, now further corrected to "corruption isn't in the cutscene render at all") and D173 (Cradle's Bond-floating/spinning cutscene bug — same subsystem family, unconfirmed shared root cause). **M-120: the `GE_D243` trace above was BUILT (statically, i.e. written) on branch `investigate/d243-cutscene-race` (`764a1f26`, pushed, not merged) — `src/game/front.c` only, `#ifdef PORT`, logs the target `MENU_*` name + a local per-tick counter on every `menu_init()` state transition. NOT build-verified: two independent sessions (the dispatched subagent, then this session re-verifying in a fresh worktree) both hit the same reproducible failure — `cmake`'s C-compiler ABI check fails with "Cannot create temporary file in C:\Windows\: Permission denied" when gcc is invoked *through* CMake/ninja, even though a bare `gcc -c` invocation from the same shell, same session, succeeds and correctly resolves its temp dir to `%TEMP%`. This is a genuine, reproducible environment issue distinct from the diff's content (static review of the diff found nothing wrong: enum cases all verified to exist in `bondconstants.h`, brace/`#ifdef` balance checked, follows the existing `GE_D160`/`GE_D178` env-gated trace idiom used elsewhere in the same file) — worth a session with a working toolchain investigating the CMake/ninja-vs-bare-gcc environment discrepancy itself as its own item, separate from D243. Next: build `investigate/d243-cutscene-race` on a session where `./build-pc.sh` actually completes, then run the `-level_33` Dam repro with `GE_D243=1` (and the existing `GE_D160`/`GE_PCDUMP` mechanisms) to correlate the trace against the D146 burst's frame range. **M-141: the M-120 toolchain blocker is EXPLAINED and worked around, GE_D243 is now build-verified.** The "Cannot create temporary file in C:\Windows\" failure isn't specific to CMake/ninja vs. bare `gcc -c` — it's this Claude Code session's `Bash` tool shell (Git-for-Windows Bash, not a real MSYS2 MINGW64 window) not exposing a usable `TMP`/`TEMP` to child processes the way an interactive MSYS2 shell does; a bare `gcc -c` from the same shell happened to not hit the temp-file path M-120 tested, which is why it looked clean while the full build wasn't. Fix: explicitly `export TMP=... TEMP=...` (Windows-style path) alongside the already-known `PATH=/c/msys64/mingw64/bin:/c/msys64/usr/bin:$PATH` fix, both before invoking `./build-pc.sh`/`ninja`/`cmake` — now also recorded in `porting-notes.md` §E as a general session-start gotcha, not just a D243-specific note. Cherry-picked the `GE_D243` trace commit (`764a1f26`) cleanly onto `release/v0.3.0` (branch `investigate/d243-fresh`), fixed one thing the original diff got wrong per this project's own D250 rule (`menu_init()` runs ~once/frame during front-end states — the diff's three `getenv("GE_D243")` calls were uncached; now a single cached `static int s_d243` check), and confirmed it builds clean. **Smoke-tested, not fully exercised:** a bare `-level_33` boot runs 1100+ frames with zero crashes and (correctly) zerLine truncated