--- name: queued-fixes description: "CLOSED as a queue — the fix list moved to QUEUE.md. Kept for the owner's standing rulings and preferences that came out of his bug reports, plus a few recurring gotchas." metadata: node_type: project originSessionId: queued-fixes --- This file was the owner's near-term bug/polish queue during the design overhaul. **It is closed as a queue.** Live work belongs in `QUEUE.md`; what shipped is in `CHANGELOG.md` + git log. *It previously held a per-item fix list with landed/queued status, commit hashes, cache revs, test and suite counts, and a phase checklist. All derivable and most of it stale by the time of the audit; stripped 2026-07-20. What remains below are the standing rulings, preferences and gotchas that came out of those reports and exist nowhere else.* ## Standing rulings the owner made through this queue - **⭐ EVERYTHING DYNAMICALLY UPDATES.** The owner's repeated complaint, in his words: *"no carrier / listening don't live update, like we've established, everything should be able to dynamically update where needed."* Any panel, status line, badge or list that reflects state must re-render when that state changes — never on reload only, never hardcoded. Applies to save lists, connection/carrier status, subsystem status strips, event logs, account status words, everything. - **Scoping rule attached to it:** when the owner reports a specific thing not live-updating, fix **that path** and verify the paths around it — do NOT spin a speculative app-wide re-audit. The standing rule stays; enforcement is by report. - **⚠⚠ PRESERVE THE OPENING BEEP.** Owner: *"will that stop the beep that happens upon opening the app? If so don't do that. I think it's the crt hum that's trying to start but can't."* He LIKES the sound the app makes on open. Before gating any audio behind the first user gesture, distinguish the boot beep (keep — it plays fine) from continuous audio like the CRT hum (which is what browsers were blocking). Verify the beep still fires after any audio change. - **A user deleting their OWN save behind a confirm is a normal allowed feature** — not a data-safety violation. The owner asked for local-save deletion and it's legitimate; destructive ops stay confirm-gated. - **Cloud saves need version history because they have an overwrite affordance** (owner: *"cloud saves should have version history bc of overwrite feature"*). Any store that can be overwritten in place owes the user a way back. - **Saves are PER-GAME** — *"saves should all be per game and show up per game only."* Tag the game context on each save; show only the active game's, local and cloud alike. - **Buttons must fit** — *"All buttons need to fit properly and not be cut off."* Row control sets must lay out cleanly at every width with nothing clipped, and the control set should be consistent across equivalent rows (local vs cloud). - **RNG mode is set ONLY at a terminal wipe / new campaign and is PERMANENT for that save** — irreversible, sticking to the save. It is the one sanctioned exception to [[player-control-principle]], so the wipe confirmation must WARN that enabling it cannot be undone for that campaign. - **One cancel, not two.** A confirm dialog gets the action plus ONE dismiss control; two cancel-equivalent buttons is a defect. - **The legacy flat/schematic fallback is reconciled at the very END of the overhaul, not during it** — it falls out of date deliberately (see [[design-overhaul-direction]] 0a.1). When it runs: enumerate every settings control in the new UI and ensure the fallback mirrors each with the *right control type* (a slider must not degrade to a checkbox) and the same stored semantics. - **Cryptic internal values never reach the UI.** A game-tick prefix on log entries meant nothing to the owner — fails the "discoverable" north star. Keep the underlying data, render it human-readably using the existing formatter. - **Native control for anything the player can currently only type.** The owner found there was no UI way to level up — you could drag XP to one short of the threshold but had to type the command. *"that needs to be in UI/UX form."* Player-driven actions must not require the AI or the command line. - **❌ QR-code save transport — SCRAPPED** (owner 2026-07-03: *"scrap QR"*). Do not pursue. - **Interactive by default.** Owner on the Overseer status tag: *"everything's interactive, why not this too."* If a status readout implies a state, consider making it a real accessible control that does the obvious thing (a no-carrier tag routes to the key setup; a listening tag gives a one-shot flourish). - **Tagged skills belong to BOTH games, not FO3 only** — the owner asked "if fo3 exclusive ship it that way" and the correction is that both games have tag skills. Related standing rule: **don't ship a label for a feature that doesn't exist yet** — hide the affordance until it's real. - **A small-feature audit is owed at gameplay-round planning** (owner 2026-07-03: *"somewhere in the steps an audit for small features like tagging skills that add to the [experience] that are missing and could/should be added"*). Enumerate small, authentic Fallout mechanics missing from the app and give the owner a triaged slate to pick from. ## Recurring gotchas worth not rediscovering - **Restoring panel open/closed state programmatically fires native `toggle` events.** A boot-time restore that sets a panel open will trip any listener watching for a user opening it — which is how a first-visit ceremony overlay came to re-pop on every reload and swallow every click on the page as a full-viewport overlay. It presented as "this control doesn't work on desktop." Guard the restore loop with a flag, and note the flag must be cleared deferred, because toggle events queue as tasks. Diagnostic that proved it: hit-test the coordinates of the "broken" control and see what element actually resolves there. - **A "works on mobile, not on desktop" report is often a stale cached build, not a code defect.** One such report reproduced nowhere and resolved itself after the owner restarted. Check the build the owner is actually running before chasing device-specific routing. - **`frame-ancestors` in a `<meta>` CSP is silently ignored** — it only works as an HTTP header, and static hosting can't set one. Don't assert it as protection. - **A deferred install banner logging "banner not shown" is intended behaviour**, not a bug, when the app shows its own install control. ## Deferred pending a precondition - **Mobile density.** The owner's read on mobile was "big/bloated." Once the visible pieces are on staging, bring him concrete density OPTIONS (tighter spacing, smaller elements, denser layout, collapsible sections) to pick from LIVE. Desktop looked good to him; this is mobile-only. Ties to [[design-overhaul-direction]] 0i.