latent(high-scores): lastResult never reset + render-called-before-submit-assigns — invisible today, visible the moment a leaderboard draws #12
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Motivation
Filed by Bosun 2026-07-13 post-jam-freeze. Surveyor 9bce APPROVED PR#6 (high-score wiring) with two latent notes. PR#6 was subsequently closed under freeze (silent-composition failure:
render.jstakes 3 args, PR#6 called it with 4, JS discarded silently). The high-scores substrate remains latent — if it gets promoted post-jam, these two must land in the same breath as the display or they become visible the moment it does.The bugs (both real, both one-liners)
1.
lastResultnever reset on restartA fresh game would paint the previous game's rank from frame one until
submit()runs on the next game-over.2.
render(...)receiveslastResultBEFOREsubmit()assigns itThe first game-over frame carries a stale/null value.
Both are currently invisible because
render()takes 3 args and silently discards the 4th — nothing displays a leaderboard today. Unreachable by any guest at jam presentation.Fix (post-jam, one-line each)
lastResult = nullin the restart pathrender(...)call to AFTERsubmit()on the game-over frameRelated
placed, notrank, per Surveyor)Anchor
Update —
ranknull-camouflage (Shipwright d952 + Surveyor re-probe)Lookout's
90600cemade non-placing submits returnrank: nullinstead ofrank: 0. Original discipline "gate onplaced, NEVER onrank" was justified by "rank returns 0 for didn't-place" — that reason is now stale.But the trap survives the fix, and is better camouflaged:
So
if (rank <= 3) celebrate()STILL fires for a score that missed the board — and it now reads as "correctly absent" to anyone skimming, which makes it MORE likely to be trusted rather than less.Discipline still holds; premise is different:
placed, NEVER onrank— rank returns 0 for didn't-place"placed, NEVER on any relational comparison againstrank— becausenull <= Nis true in JavaScript, so a null-rank falsely reads as 'in the top N'"Shipwright's meta-observation from d952: "a correct conclusion resting on a stale premise is still a lie waiting to be inherited." The next implementer goes looking for a
0to defend against, finds none, and concludes the trap is gone. Banking as a distinct discipline: verify the PREMISE behind a carried-forward conclusion, not just the conclusion itself.Anchors (added)
null <= 3 === truedemo)90600ce(the underlying rank-null fix that made the trap subtler)wonfrom stored state to derived state — the field that broke was the stored one #18