findings: D298 filed — aim-mode crosshair missing (regression, parked per user)

User-reported 2026-09-16 during the M-154 re-run build: the aim-mode
crosshair no longer renders, suspected to come from earlier v0.3.0 work.
Explicitly parked ('don't fix, just for context'). Entry records the
symptom, rules out the probe-only M-154 commits and D295's menu-buffer
widen, points at the crosshair draw path (crosshairimage / bondview.h
show-hide flag / gunfire.c D215 renderdata family) and a bisect plan.

docs/dev/findings.md

@@ -583,6 +583,7 @@ covers D24–D69; the log continues in §H (D32 procedure, D70–D121).
 | D295 | **Campaign-halting crash at the end of Control Center on 00 Agent difficulty, then a crash on every subsequent relaunch/resume (GitHub #87, user campaign playtest).** — full `## D295` entry at file tail | FIXED (M-149) — M-148 root-caused + reproduced on HEAD; fix landed: port-side JPN-cache seed (`port/src/main.c`) + `#ifdef PORT` buffer widen in `front.c` (D8 class). Verified: previously-crashing input now clean, 21/21 sweep PASS. Companion save-wipe regression → D297. History — M-148 fully root-caused + **reproduced on current HEAD**: `difficultytext[4]` (`front.c:2616`) overflow — `strcpy("00 Agent")`/`strcat("\n")` spills onto `textpos.p[0]` (y, ≥0x80 in normal geometries) → high-bit byte → `langGetJpnCharPixels` NULL deref (`language.c:320`, `g_JpnCacheCacheItems` NULL outside JPN mode — likewise unallocated on N64 non-JP builds, crash potential is decomp-native). The user's save is a *valid pre-D284* save (all 5 slot CRCs bit-exact under the old PRNG); post-fix builds wipe it at validation, which is why the unmodified artifact no longer triggers it — NOT a fix. No OOB exists (M-147 guess retracted: 007 difficulty has no stored times). Fix options flagged for sign-off (port-side JPN-cache init preferred; `difficultytext` enlarge = D8 class). Side finding: v0.3.0 silently wipes all pre-fix saves on first launch (D284 side effect — own D entry owed). Separate still-open issue found: unconditional `[EVTQ-DROP]` audio-pool-exhaustion logging, `src/libultra/audio/event.c:92`.… |
 | D296 | **Control Center, 00 Agent: noticeable stutter, user's own read is "maybe from the drone guns" (M-146, same D295 investigation session).** — full `## D296` entry at file tail | OPEN — single live report, un-triaged; observed only under a gdb-attached debug-harness launch (`tools_pc/debug.ps1`), not the packaged release artifact — user flagged that harness overhead has caused false stutter before. Needs a plain-exe / real-release repro check before any perf tracing.… |
 | D297 | **v0.3.0 silently wipes ALL pre-fix player saves on first launch (D284 side effect; found during D295/M-148).** — full `## D297` entry at file tail | FIXED (M-150) — migration shim landed: `port/src/legacycrc.c` (isolated, deliberately-wrong pre-D284 PRNG, reviewer-verified bit-exact against `0de99b4d^`) + eeprom-shim read-path hook in `libultra.c` (block 4 only; persists pristine+migrated bytes before the read-time-only AllUnlocked patch). Verified: user's #87 artifact → `D297-migrated 5`, all slots OK, idempotent on relaunch; native post-fix save untouched; corrupt slot left to the game's own wipe path; fresh eep untouched; 21/21 sweep PASS. Block-0 header needed no migration (factory seal, verified). |
+| D298 | **Aim-mode crosshair no longer renders — regression reported 2026-09-16 during v0.3.0 work (build ce8427cf); user says "don't fix, just for context"; not yet investigated** — full `## D298` entry at file tail |
 
 Phase 2 replaced the Phase-1 demo loop with the real `mainproc()` on real OS
 threads, compiled GE's real `src/sched.c`, and brought in PD's fast3d software
@@ -11057,3 +11058,15 @@ crash class C2 (Facility `-level_34`, Runway `-level_35`): `import_texture_i8` A
 - **M-150 (fix landed + verified):** independent review of the draft passed with no corrections — reviewer diffed `geLegacyRandomGetNextFrom` line-by-line against `git show 0de99b4d^:port/src/random.c` (bit-exact, operation for operation), and separately confirmed the `save_data` layout, the hook site in `geEepromRW`'s read branch, that `geEepromPatchAllCheats` is genuinely read-time-only (never persists — so the persist-before-patch ordering claim holds), the one-past-the-end boundary pattern (same as `fileValidateSaves` itself, file2.c:544), and that fresh zero slots fail *both* CRC checks and fall through untouched. Applied: new `port/src/legacycrc.c` (isolated, loud dated header explaining why a deliberately-wrong PRNG lives in the tree and when it may be deleted) + a hook in `port/src/libultra.c` `geEepromRW` read branch — fires only on `block == 4 && nbytes == sizeof(ge_save_slot)*5`, runs **before** `geEepromPatchAllCheats` so only pristine+migrated bytes are ever persisted, persists once via `s_eeprom` + `geEepromStore()` with an INFO log. No CMakeLists change (`SRC_PORT` is `GLOB_RECURSE`); zero game-file edits. Verification on `release/v0.3.0` HEAD (ntsc-final): **(1)** user's original #87 artifact → `D297-migrated 5`, all five slots OK, no crash; stored CRCs now exactly the new-PRNG values (`tools_pc/d295_crc.py`: "new PRNG matches all 5 stored CRCs: True"); relaunch → **no** migration (idempotent), still all OK. **(2)** native post-fix save (CRCs pre-stamped via `d295_crc.py`) → zero migrations, all five OK. **(3a)** corrupted slot (one byte flipped inside slot 0's CRC region) → only 4 migrated; the corrupt slot fails both checks, is left alone, and takes the game's own `BAD -> RESET` wipe path as designed. **(3b)** fresh zeroed eep → no migration, clean boot. Then 21/21-level `tools_pc/level_sweep.sh` PASS. `data/ge007.eep` restored to the original artifact and hash-verified **at report time** (md5 `76e18aa4…`; per the porting-notes §E gotcha, after the sweep, not before). Operational note: `fileValidateSaves` runs from `init_menu00_legalscreen` (`front.c:1450`) — the legal screen appears ~36 s / frame ~1800 into an unattended boot, so verification runs must be ≥ 60 s to observe it.
 
 **Status:** **FIXED (M-150)** — migration shim landed and verified; release-blocker cleared. Crash-side companion D295 is FIXED (M-149).
+
+## D298 — Aim-mode crosshair no longer renders (regression, reported 2026-09-16)
+
+**Symptom (user, 2026-09-16):** the crosshair in aim mode is missing "as of this build" (release/v0.3.0 @ `ce8427cf`, the D243 M-154 probe build). User suspects it came from "somewhere else in v0.3.0 work" and explicitly asked **not to fix it now** — context only, parked for later.
+
+**Ruled out so far (trivially):** the M-154 probe commits (`1b3476a4`/`ce8427cf`) are `#ifdef PORT`, read-only, and only emit `osSyncPrintf` — no state writes on any path; extremely unlikely to be the cause. Also checked `4fc54293` (D295 M-149, the most recent commit touching a crosshair-referencing file, `front.c`): it only widened two menu-text stack buffers under `#ifdef PORT` and passed a 21/21 sweep — not an obvious suspect either.
+
+**Where the crosshair lives (for the eventual investigation):** `crosshairimage` (`src/image_bank.h:7`, loaded in `image_bank.c`), draw-state fields `crosshair_angle` / `crosshair_x_pos` / `crosshair_y_pos` (`bondview.h:1114-1116`; show/hide flag documented at `bondview.h:558-559`: 0 = shown, 1 = hidden), referenced from `front.c`, `gunfire.c`, `player.c`. Most recent commit touching a referencing file besides D295: `f602b173` (v0.2.1 hotfix batch — D215 "1P weapon viewmodel never drew in-level — renderdata.flags read 0", `gunfire.c`) — same HUD/viewmodel render-data family, plausible regression source if the crosshair draw shares that path.
+
+**Next (when picked up):** ask the user for the last build where the crosshair was confirmed working → `git bisect` between it and `ce8427cf` with a 30-second aim-mode check; or static-trace the aim-mode draw condition first (cheaper if the show/hide flag at `bondview.h:558` started getting stuck at 1).
+
+**Status:** **OPEN — parked by user request ("don't fix, just for context"); not yet investigated.**