docs: correct the engine registry — a false ✅, three stale-opens, EN-038's void evidence#101
Conversation
… EN-038's void evidence EN-030 "UI widget layer ✅ shipped — src/menu.ts in the shooter" is RE-OPENED. The engine shipped nothing: there is no src/ui/ and no src/widget*/ (verified). The ticket was closed by pointing at a DIFFERENT REPO's file. That closure hid the exact gap the ticket exists to name — its own scope says a reusable bloom/ui the editor can adopt, and instead the editor still hand-rolls every panel and game #2 starts from zero. One game having a menu is not an engine having a UI layer. The shooter's menu.ts is a good candidate to PROMOTE (it already carries one focus model across mouse/keyboard/gamepad/touch) — but promoting it is the work, and it isn't done. Closing it won't-do would also be honest; a ✅ that means neither is not. EN-003, EN-009, EN-033 closed — all three were already done and simply never marked. EN-033 is the one that cost something real: the shooter recorded SH-027 v2 as "gated on EN-033" for weeks after it landed, so the gate was imaginary. EN-039 closed (PR #100), and its API sketch's premise is corrected in place: it said to route the matrix through the mesh scratch because "Perry can't pass 16 f64 args". Perry can — bloom_scene_set_transform16 already passes 17 and always has. The shipped call spells the matrix out and stays stateless. EN-038 keeps its 🔴 but is prefixed with a warning: its ENTIRE evidence is "the eprintln! never printed", which proves nothing on Windows because eprintln! is dead after init. "The native function is never entered at all" was inferred from a channel that cannot report, and the Perry-FFI-dispatch suspect list is built on top of that. What is actually known: the FFI exists and is registered; the F12 path produces true 4K captures through the SAME readback machinery; no file appears. Re-diagnose with std::fs::write to an absolute path — check for the FILE, not for a log line. Claude-Session: https://claude.ai/code/session_01J1UWgMcrTNvwWeXcJ1T3Fp
|
Warning Review limit reached
Next review available in: 4 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
1 participant
Docs-only. Corrects the EN-* registry against the code.
EN-030 — RE-OPENED (the ✅ was wrong)
It read "✅ shipped — TS-side,
src/menu.tsin the shooter". The engineshipped nothing — no
src/ui/, nosrc/widget*/(verified). The ticket wasclosed by pointing at a different repo's file.
That closure hides the exact gap the ticket exists to name: its own scope says a
reusable
bloom/uithe editor can adopt incrementally. Instead the editor stillhand-rolls every panel, and game #2 starts from zero. One game having a menu is
not an engine having a UI layer.
Closing it won't-do would also be honest ("UI is per-game forever — editor,
stop waiting"). A ✅ that means neither is not.
Three stale-opens closed — all already done
EN-003(SSAO knobs),EN-009(multi-mesh wrapper),EN-033(bone sockets).EN-033 is the one that cost something: the shooter recorded SH-027 v2 as
"gated on EN-033" for weeks after it landed. The gate was imaginary — the work
was free the whole time.
EN-039 closed (#100), premise corrected in place
Its sketch said to use the mesh scratch because "Perry can't pass 16 f64 args".
Perry can —
bloom_scene_set_transform16already passes 17.EN-038 — evidence marked VOID
Keeps its 🔴, gains a warning. Its entire evidence is "the
eprintln!neverprinted" — which proves nothing here, because
eprintln!is dead after initon Windows. "The native function is never entered at all" was inferred from a
channel that cannot report; the Perry-FFI-dispatch suspect list sits on top of
that.
What's actually known: the FFI exists and is registered; the F12 path
produces true 4K captures through the same readback machinery; no file appears.
Re-diagnose with
std::fs::writeto an absolute path — check for the file,not a log line.
https://claude.ai/code/session_01J1UWgMcrTNvwWeXcJ1T3Fp