The Bug Museum

The defect

The AI-import path did a full replace of state.inventory, not a merge. When an AI response contained an inventory array, autoImportState() (js/services/api-import.js, ~line 379) ran state.inventory = inv.map(...) — the entire durable inventory overwritten by whatever the model returned that turn. The directive (js/services/api-directive.js, ~line 120) commands the AI to "return the ENTIRE inventory array" on any inventory-touching turn, so a turn where the model misjudged — e.g. a failed repair and an aborted craft — and emitted a short or empty array deleted real items from state. An empty array wiped everything. The [DELTA] inventory: 1→0 items line the owner saw was telling the truth: the item was genuinely removed, not miscounted.

CAUGHT BY · the owner's eye — tracing a live [DELTA] 1→0 against the code, confirmed real state loss not a display bug
The owner's eye, then confirmed against the code: the DELTA counter reads actual state.inventory length before/after, so 1→0 is a real deletion. Traced against the owner's live screenshots on 2026-07-18. The pre-existing registry-leak guard covered only cross-game mismatches; a same-game short/empty array was unguarded — a hole no machine was watching until the owner hit it.

The defect

_applySlotEnvelope() (the shared core behind LOAD SLOT and VERSION RESTORE) detected a cross-game context mismatch, confirmed it, and then applied the switch in place (loadUI() only, no reload). But FALLOUT_REGISTRY and databaseCSVs are boot-time globals, selected exactly once at boot by index.html's GAME_FILES manifest (one of reg_nv.js/reg_fo3.js + one of db_nv.js/db_fo3.js per boot). An in-place apply left those globals stuck on the old game's data while state.gameContext silently flipped to the new one. Every registry-backed surface was then serving the wrong game: location/item/quest/perk autocomplete, the native LOOT/THREAT/CONSULT lookups, and the AI's own databaseCSVs system context — not just the location box the owner first noticed.

Correction to the record this specimen was drawn from. The museum mockup (specimen 08) framed this as a cosmetic defect — "a New Vegas-skinned terminal showing a Fallout 3 save, the wrong wasteland's chrome around the right save." That is wrong. This is a data-integrity defect. The independent audit reproduced real campaign-data loss on the pre-fix code: the AI-import path (autoImportState) validates state arrays against FALLOUT_REGISTRY and drops every entry the registry doesn't recognise, on a write — so with a stale registry the campaign's own FO3 collectibles (Strength, Perception) matched nothing in the loaded NV registry and were silently emptied and persisted. The implementer's "only lookups and suggestions, never what got written" claim was overturned by the audit.

CAUGHT BY · owner report, then independent audit that reproduced real data loss
Owner report of wrong-game autocomplete, then a Stage-3 independent audit (Protocol 8) that reproduced the bug red→green in a real browser and independently found the data-loss the implementer had ruled out.

The defect

The machine's system-level gitconfig sets core.autocrlf=true. Because museum/generate.mjs names each doc page docs/<sha256(rawBytes)[:12]>.html — hashing its inputs — a CRLF checkout does not merely add \r characters: it renames every generated page and re-churns the entire museum. Separately, sync.ps1 had been writing its generated manifests with PowerShell's default CRLF (WriteAllLines uses Environment.NewLine), which baked CRLF hashes for _CAPTURE_MANIFEST.txt, _CAPTURED_STORES.txt, ARCHIVE_RETAINED.md, and AUDIT.md into the committed museum. This is the same failure family as [[vanishing-addresses]]: an address that moves for a reason unrelated to the content's meaning.

CAUGHT BY · fresh-clone regeneration churning pages on a machine with autocrlf=true
A fresh clone on the autocrlf machine regenerated with the whole museum churning — addresses moving with no content change.

The defect (anticipated)

This defect never shipped — it was caught in review as a failure path in the release machinery. Writing the release pin at the start of a --release run looked harmless. It was not: a run that failed partway would leave the pin claiming a release the museum was never generated for. The museum on disk would be the old release, the pin would claim the new one — and because the pin then matches the newest tag, the NOT CURRENT notice (see [[silent-flatline]]) goes dark at the exact moment it should fire. The guard meant to prevent "authoritative and quietly wrong" would itself have caused it.

CAUGHT BY · reasoning through the failure path in review
By reasoning through the failure path in review, before any release ever exercised it. The inline comment in resolveReleasePin() records the reasoning verbatim.

The defect

Cold-rendering the 28 Playwright prototype thumbnails produced a different 11–13 of them with a few dozen-to-hundred differing bytes each — a different subset every run. The first diagnosis, "PNG re-encode jitter," was wrong, and the correction is the lesson: 27 of the 28 prototypes carry infinite CSS animations (coreSpin 9s linear infinite, corePulse 2.6s ease-in-out infinite, a pulsing status lamp), and the capture waited a flat 600 ms after load with no synchronisation to animation phase. Ordinary process-scheduling jitter landed each screenshot at a different rotation angle / glow intensity — real pixel drift, not lossless-encoder nondeterminism on identical pixels. The other candidate fix the earlier pass had named, "force deterministic PNG encoding," would not have touched the actual cause at all.

CAUGHT BY · git status dirty after a supposed no-op regeneration
git status showed modified PNGs after a regeneration that should have been a no-op, run from a clean clone.

The defect

The entire text corpus was inlined into search.html — 3.9 MB parsed before the input box would take a single keystroke, on a museum whose primary reader is on a phone. It was the heaviest page on the site by two orders of magnitude.

CAUGHT BY · weighing the generated pages against the phone-readable constraint
Weighing the generated pages against the museum's phone-readable constraint — the page weight itself was the finding.

The defect

When the application retired its test-count rule and removed one marker from the changelog, the growth collector silently dropped the newest point entirely — its date, files and lines included. The chart went back to ending ten days earlier and looked perfectly healthy doing it, while every other page of the museum stayed current. Nothing in the build complained. This is the defect class the whole museum is designed against: authoritative, and quietly wrong.

CAUGHT BY · a human noticing — no machine was watching
By a human noticing — and that is the whole problem: no machine was looking. At the moment the point was dropped, no check existed that compared the chart against anything; the currency guard below is precisely the check that was added in response. The mockup attributes the catch to the owner's eye; the primary sources confirm the load-bearing fact — that the defect was invisible to every automated gate — but do not independently name the specific person, so this record claims only what it can source. (See Provenance.)

The defect

The first growth chart drew check count (max 2,951) and code lines (max 94,435) on one set of axes, each series scaled to its own maximum so both ended at the same height. The visible axis was labelled in checks only. The headline the picture made — "these two grew together" — was an artifact of the normalisation, not a fact about the project. Every individual number was correct; the composition was the lie.

CAUGHT BY · design review against the archive's "never quietly wrong" standard
Design review of the chart against the archive's own "never quietly wrong" standard.

The defect

museum/generate.mjs's walk() recursed fs.readdirSync over the whole archive root, so any file on disk — tracked or not — became a published page and fed the global input-tree stamp. The repo-root README.txt was gitignored and explicitly marked "NOT part of the archive", yet it leaked in exactly this way: it got its own doc page (docs/fe41f879e76a.html) and contributed to a build stamp that was only reproducible on a machine that happened to have that untracked file sitting on disk. The museum could not be regenerated from a clone, because a clone never materialises an untracked file.

CAUGHT BY · fresh-clone regeneration
Regenerating from a fresh clone and comparing stamps: the input-tree hash differed with nothing visibly wrong on the page. The discrepancy — not any visible defect — was the tell.

The defect

Document pages were named docs/<sha256(rawBytes)[:12]>.html — the generator content-hashed its inputs, so every edit moved the page's address, and every regeneration dropped the old one. Across this repo's own history, 389 distinct hash addresses have existed. Worse, and this is the second half of the specimen: the first mining pass to recover the old addresses found only 305 of them. Git's content-similarity rename detection was pairing unrelated generated pages as "renames" of each other — they share large boilerplate around a short doc body — and hiding the rest from --diff-filter=A. A mechanism built to lose nothing was itself quietly losing 84 addresses.

CAUGHT BY · measuring the same history query with and without --no-renames and getting two different answers
The address-instability was caught by the owner-facing naming review. The miscount was caught by measuring the same history query with and without --no-renames and getting two different answers (305 vs the true 389).