# MUSEUM EXHIBITS — design spec **Snapshot 2026-07-20 · ARCHIVE-class planning doc · NOT YET BUILT.** Produced during 2.8.5. Filed by the release whose work produced it, not the version it describes. **Provenance.** Derived from two independent external reviews of the *built* museum (Gemini 3.1 Pro Extended and GPT-5.6 Sol, blind to each other), then a design conversation with Gemini, adjudicated by Dispatch. Where they disagreed, the verdict and reasoning are recorded — including two places GPT was overruled and one where it was decisively right. ⛔ **Nothing here is implemented.** The museum as built (264 pages, commit `9d77370`) is the baseline this extends. --- ## 0. The governing rules **R0-a — Everything factual is generated. The only hand-written content is FROZEN PROSE.** "Frozen" means: written once, about something finished, never updated. A release account or a curator's note cannot rot because the thing it describes has stopped moving. This is what makes curation possible without creating a maintenance obligation — it was GPT's central objection to every curated exhibit, and this dissolves it. **R0-b — MODULES vs MANIFESTS.** - **Seated modules** (reusing the app's existing Module Bay vocabulary: slot, part number, status plate, and the `SEAT` motion verb) are for artifacts with *individual* significance. - **Manifests** — dense, monospaced, utilitarian — are for meaning that only exists *in aggregate*. The distinction is **structural, not decorative**: density and layout, never a badge or an accent colour. Decoration drifts when the design system moves; structure doesn't. **R0-c — The chrome carries the atmosphere; the text carries the truth.** Diegetic framing is applied to the *presentation*. Every fact inside it is literal. Never invent a cause, a reason, or a failure explanation for flavour. This mirrors the project's existing accessibility standard (ARIA labels stay literal; the in-world voice lives only in visible text). **R0-d — ⭐ A MECHANICAL PROPERTY MUST NEVER SILENTLY OVERRIDE A HUMAN JUDGEMENT.** The generator reports state. It does not re-curate. See §4 for the case that produced this rule; it generalises well beyond the museum. **R0-e — Claims must be literal.** No "DATA INTEGRITY — clean". State exactly what was checked: duplicate-content paths: 0 · unclassified files: 0 · broken internal links: 0 of 3,509. (Same disease as the Suite 220 overclaim fixed 2026-07-19: a narrow check printing a broad reassurance.) --- ## 1. FIX FIRST — defects in the built museum Ordered; do these before any new exhibit. 1. **The growth chart is misleading and must be corrected.** It plots test count and lines-of-code as two series normalised to finish at the same height, against a visible axis that only applies to one (2,951 vs 94,435). Use separate charts, separate axes, or an explicitly-labelled normalised index. ⭐ **And reconsider the metric.** Celebrating test *count* repeats the exact error the project retired Protocol 2a for on the same day: count is inventory, not confidence. Many of those checks are static source assertions. 2. **Overbroad integrity language** → literal assertions (R0-e). 3. **Keypad navigation** is `<button onclick>` inside `role="tablist"`; these are separate-page links. Use `<a href>` styled as keycaps. Removes JS, restores open-in-new-tab and link preview, gives assistive tech the correct model. 4. **Sparse-room coverage notices** (§3). 5. **The DRAFT account banner** — approve or omit; it is currently visible to any reader. 6. **Search page is 3.9 MB** — violates the phone-readable constraint. Shard it, or gate it behind an explicit weight warning. --- ## 2. THE CURATION MECHANISM (enables everything else) Extend the existing per-release account file to carry a short **featured-artifact list**: a filename plus one line of why it matters. - The generator renders those at the top of the room as seated modules, pulling their real thumbnails, links and metadata from the archive as normal. - **The SELECTION is frozen prose; everything around it is generated.** - **Honesty mechanism:** if a named artifact no longer exists, the page must SAY SO. A curator's pick silently pointing at a missing file is precisely the "looks authoritative, is quietly wrong" failure. - The manifest below stays **fully exposed, never collapsed**. Gemini's argument, adopted: *the scroll is the scale*, and the curation only reads as valuable next to the bulk it saved you from. --- ## 3. SPARSE ROOMS (2.5.0, 2.6.0 — one artifact each) Not a filing problem. An honest archival fact with a presentation defect. - Elevate the single artifact to a **seated module on an otherwise empty board**. The unused slots do the work — a one-line manifest reads as a broken page; a near-empty board reads as deliberate. - Generated coverage notice, and the wording is load-bearing (GPT's precision, adopted): > **ARCHIVE COVERAGE — SPARSE.** This archive contains 1 document attributed to release 2.5.0, with 0 mockups and 0 prototypes. No additional planning material for this release **is present in the archive**. - ⚠ Say **"is present in the archive"**, never "was never created". The archive can prove absence from itself; it cannot prove absence from history. Only an owner-written frozen account can claim the stronger thing. - **Routing:** lobby → the 2.8.0 explosion → *then* the sparse rooms as a flashback. Reverence requires contrast; a near-empty room as the second beat reads as a broken link. (Gemini's own revised advice, overriding its first answer.) --- ## 4. PROPOSITIONS vs REALITY **Gemini's original "intent vs reality" (pair each mockup with the screen it became) is REJECTED** — GPT's objection is correct: that mapping is human semantic judgement, permanently maintained, and unmappable anyway (variants, explorations, abandoned directions don't map 1:1). **The temporal version is ADOPTED.** Two opposing blocks in the room — **THE PROPOSITIONS** (that release's mockups and prototypes) facing **THE REALITY** (that release actually rendered) — with no pairing at all. The generator renders two lists; the visitor's eye finds the connections. *The absence of curation IS the curation here*, so **nothing in this exhibit is ever elevated to a module** — elevating items would tell the visitor what to think and destroy the effect. ### 4.1 Historical capture — how "REALITY" is produced ⭐ **GPT rejected historical screenshots as "a permanent curatorial project." That is wrong, and this is the mechanism that proves it:** The generator checks out a release tag into a **temporary git worktree**, serves it locally, boots it with the browser automation the project *already* depends on, captures frames, tears the worktree down. **Why it isn't a heavy build step: a release commit is IMMUTABLE, so each release is captured exactly once, ever, and cached against its commit hash.** Regenerating next week re-shoots nothing. The only work a future run does is capturing a release that did not previously exist. One-off cost per room, not a recurring build. GPT priced this as maintenance when it is a one-time capture. **Seed no save data — boot the machines EMPTY.** A modern fixture would fail to load in an old save format and could crash a genuinely healthy build, making the exhibit lie. An empty terminal is also the truthful artifact: the chrome IS what was built. And it forces the eye onto structural change between eras rather than placeholder content. ### 4.2 Failure states Old versions may not boot (~9,000 → ~94,000 lines in two months). A failed boot is an **exhibit, not an excuse** — software rot made visible, the digital equivalent of a museum displaying a machine it can no longer power on. **Threshold (Gemini):** the failure only carries meaning as the exception. One dead machine is lore; all of them dead means the automation is broken and the exhibit is ruined. Treat a total-failure result as a bug in the generator, not a finding. **Detection — reuse the project's EXISTING boot-smoke judgement.** Do not invent a second definition of "working"; two definitions is how the museum ends up disagreeing with the pipeline. Three signals, in order: 1. **Navigation failed** → environmental (worktree didn't serve, path didn't resolve). Not the artifact's fault; say so. 2. **Uncaught error during boot** → genuine boot failure. The existing failure-capture wiring already collects console output and screenshots. 3. **Anchor present but nothing painted** → render failure. A different fact from a boot failure. 4. **All pass, screen empty** → **NOT a failure.** That is the app's honest empty state. An archive that reports "no data" as "broken" is lying about the artifact. **The panic frame** is diegetic; its contents are the **verbatim captured error** (R0-c): ``` [ BOOT SEQUENCE TERMINATED ] [ RELEASE 2.5.0 — CAPTURED AT COMMIT a1b2c3d ] > TypeError: Cannot read properties of undefined (reading 'inventory') > at loadUI (js/ui.js:412) ``` ⚠ Never write "no longer boots in a modern browser" or "dependencies lost to time". Both are almost certainly false for a vanilla app this young, and inventing *any* cause breaks R0-c. The real stack trace is the better exhibit regardless — it's the actual last words of a version of the software. ### 4.3 ⭐ The case that produced R0-d **Q: if a curator's pick sits in a build that fails to boot, does it stay elevated or drop to the manifest?** **A: it stays elevated, showing the panic on its pedestal.** Demotion would let the museum **re-curate itself according to software rot** — and invisibly, since nobody would witness the demotion. The effect is survivorship bias baked into the exhibition: whatever still runs gets a pedestal, whatever died sinks into a list, and over time the museum drifts toward flattering the recent and burying the fragile. A pedestal bearing a dead machine and its last stack trace is a stronger exhibit than an empty one, and the only version faithful to the curator's original judgement. **Room-level rot summary** near the top of each room, e.g. `[ ARCHIVE INTEGRITY: 4 UNRESPONSIVE CAPTURES ]`, so a visitor sees the decay level of an era at a glance rather than discovering it one broken frame at a time. --- ## 5. THE BUG MUSEUM — conditionally adopted **GPT rejected it; the objection is sharp and must be respected: a guard can exist while being INERT.** This project proved that on 2026-07-19 — a cache-bump guard that was written, hooked, tested, and silently doing nothing on the working branch for weeks. A room asserting "this defect is now prevented" would be making exactly the unverifiable authority claim the whole system exists to avoid. **Adopted only in the form that strips the authority claim.** The machine reports state; it does not promise the future: ``` ANOMALY #42 TEST RECORD: <filename> STATUS: PASSING AT COMMIT <stamp> ``` That is a fact, not a guarantee. It leaves intact the underlying dread that the sensor itself may be broken — which is both diegetically correct and epistemically honest. **Structure:** a few frozen-prose picks seated as modules; the rest as a raw diagnostic manifest (the manifest is what proves the picks aren't cherry-picked). **Not "every defect"** — that set is unprovable. A non-comprehensive *Documented Failures* index, generated from reviewed records. **Why the owner wants it:** it's the only proposed exhibit that would change how he works — every guard shown beside the defect it exists to prevent is the evidence the trim (R3) needs, and that argument currently lives only in scattered audit files and orchestrator memory. --- ## 6. ARCHIVE ACTIVITY ON THIS DATE — build The one addition **both** reviewers endorse as genuinely generatable with no hidden human step. Generated from git history, release tags, file classification and first-appearance commits. Use **separate lanes** and precise terminology (GPT): *shipped* · *first entered the archive* · *planning artifact* · *mockup*. Do NOT conflate a git timestamp with when an idea was conceived. The honest title is **"Archive Activity on This Date"**, not "what was happening". Gemini ranked this last as "a database query, not an exhibit". **Overruled**: for the primary visitor (the owner) it is the diary view, and it is the only proposal with no maintenance tail. It is not the headline exhibit, but it is the cheapest real one. --- ## 7. CLICKABLE GROWTH CHART — deferred, in order Only after §1's chart correction and §6's date pages exist. Then the inline SVG points are simply wrapped in links to the date pages. **Navigation, not a second analytical subsystem.** No framework, no runtime data. --- ## 8. REJECTED — do not build | Item | Why | |---|---| | **Graveyard as the front door** | Rejected by both, permanently. "Never start the tour in the basement" — the visitor needs the scale first for the graveyard to mean anything. It also misrepresents the project as defined by its failures, and publicly invites decontextualised screenshots. Lobby stays the entrance. | | **Semantic mockup→screen mapping** | §4. Permanent human curation obligation. | | **"Every defect" bug museum** | §5. Unprovable set. | | **A decisions room (for now)** | Deferred, not rejected. The material sits in orchestrator memory and requires owner adjudication plus separation from personal context first. Creating the reviewed records IS the obligation; generating the room afterwards is trivial. | | **A public redaction pipeline** | A filter running every build is a second product. The boundary is drawn ONCE, at the source (§9). | | **Inlining CSS into every page** | GPT's own original spec, which it retracted. Shared stylesheet is correct at 264 pages. | | **Live iframes for all prototypes** | Archived HTML is untrusted active code. | --- ## 9. PUBLICATION — if it goes public Owner is open to it. GPT reversed its earlier position: a public museum is rational, because GitHub Pages eliminates the distribution problem entirely (stable URLs, deep links, ordinary asset loading, no backend). ### ⚠ 9.1 The two findings that must not be lost **A — The existing archive repo can NEVER be made public.** Deleting the memory folder does not remove it from git history; it survives in past commits, clones, forks and caches. That decision was made the moment it was committed. **B — ⭐ SAME-ORIGIN HAZARD.** A GitHub project site at `zerckzzyHD.github.io/robco-uos-local-archive/` shares a **browser origin** with the live app at `zerckzzyHD.github.io/Robco-UOS/`. Origin-scoped storage is shared. The archive contains **28 executable HTML prototypes**; one opened by anyone could read or overwrite the `localStorage` holding the owner's live campaign — the exact data hardened all day on 2026-07-19. ⇒ **The public museum MUST be served from a different origin (separate GitHub account/organisation), not merely a different repository path.** This is the single most valuable finding of the entire review exercise and nobody would have found it by looking at the museum. ### 9.2 The repository boundary | Repo | Contents | Visibility | |---|---|---| | Existing archive | Canonical evidence + its original history, incl. historical memory commits | **Private permanently** | | Private context | Ongoing orchestrator memory and other non-publishable material | Private | | **New** museum repo | Freshly generated output + only deliberately published assets, clean history | **Public, separate Pages origin** | Regenerate from clean inputs. Do **not** carry forward the existing search index or generated pages — they duplicate source content and may embed material the folder split was meant to exclude. ### 9.3 Other public failure modes - Content-hash-only document URLs vanish when content changes → link rot. Generate stable aliases or retain old pages. - Privacy is broader than the memory folder: absolute Windows paths, private repo URLs, unpublished security findings, personal anecdotes, third-party copyrighted material. - Ship `.nojekyll`, and **verify the deployed stamp and links over HTTP** after publishing — the deployment can disagree with the repo. - Full images must be copied *into* the published tree rather than referenced above `museum/site/`. --- ## 10. SEQUENCING 1. §1 defect fixes (chart, claims, nav semantics, sparse notices, draft banner, search weight). 2. §2 curation mechanism. 3. §6 Archive Activity on This Date. 4. §4 Propositions vs Reality + historical capture. **⚠ Size this properly before starting — worktree booting, cached captures and failure states is a real feature, not museum polish.** 5. §5 Bug Museum, in its state-reporting form only. 6. §7 clickable chart. 7. §9 publication, only if the owner wants it and only via a new origin. **Do not build another room before §1 is done.** GPT's judgement, adopted: prove the museum is *current and honest* before making it *larger*. --- ## 11. Standing note on the reviewers Recorded because it's reusable. Across this exercise: **Gemini's instinct beat GPT's caution on buildability twice** (the historical-capture cost; the temporal pivot that saved Propositions vs Reality). **GPT's rigour beat Gemini's enthusiasm on facts twice** (the growth chart is numerically wrong — Gemini praised it without checking; the same-origin storage hazard). Neither could have produced the other's contribution. Run both, blind, and adjudicate — do not average them.