Receipt — end-to-end stability audit, spawn-storm breakers, and BOTH boot gates PROVEN — 2026-07-14

Evidence & Verdicts · docs/receipts/stability_audit_2026-07-14.md @ 44baf03d5041 (gen2-runtime) — opens the published snapshot ac338733bbba

Three ways to read this page. Precise is the document itself, exactly as it is written in the repository. Plain and Clear were written for this website to help you meet that document — they are about it. They are not it, and they are not evidence.

Eighty-seven dated pages: receipts, pre-registrations, handoffs, validation records and review verdicts. A receipt is written at the moment a piece of work was checked. It names what was claimed, the commit and the seed, what was actually run, and the outcome in one of a small set of controlled words. Then it names what the work did not achieve. That last part is what makes it a receipt rather than an announcement. A pre-registration is the same discipline run in advance: the conditions that would count as a pass and the conditions that would falsify the claim are written down before the run, so neither can be adjusted once the numbers arrive.

That is why so many small dated stubs are an audit trail rather than noise. No one of them is meant to be a good read. The value is in the sequence and in the dates, because you can watch a prediction be registered, then the run happen, then the verdict land — sometimes against the prediction. Pages here record a falsified result, a rejected fix, a retracted overclaim, and a green receipt that turned out not to be reproducible from the commit that carried it. A record that carried only successes would be worth a good deal less than this one.

A gentle way in is to read a pre-registration first, so the shape becomes familiar, then a result page, then one of the corrections. This section sits off the main navigation on purpose: it is the record you check the rest of the site against, not the place to begin.

What it is not: documentation, and not a summary. Nothing here has been tidied in hindsight. Every entry reads as of its date, a later entry may overturn an earlier one, and the presence of a page is not a claim that its result stood.

PlainClearPrecise

Your browser cannot switch reading levels, so the document itself is shown.

This is the document. Rendered from the repository at the commit above, with nothing rewritten for the web. A gate re-renders it on every deploy and fails the build if a single byte differs.

Gate rows fed by this receipt: door-storm-breakers (PASS, Class A), door-boot-persistent (PASS — reboot leg closed), gaia-boot-persistent (PASS — reboot leg closed).

1. The incident, honestly (two storm waves, one real reboot)

Wave 1 (OBS loop): journey verify_1 auto-triggered ONE KEY, and the concurrency fix's end-of-function disk reload discarded the once-only guard -> every 3s poll from every open /door tab spawned studio_up.ps1 -> OBS relaunched endlessly; ~68 stacked shells killed.
The reboot: the operator power-cycled mid-storm. OS truth: LastBootUpTime 07/14/2026 12:26:45.
Wave 2 (command-center window flood): Startup legs correctly revived the door post-reboot, but the revived launcher loaded the STILL-BUGGY journey code from disk (the read-purity fix d09f700 was committed ~12:33, after the 12:26 boot) -> storm resumed; every studio_up run also popped a NEW command-center Chrome window (step 8b was unconditional). Killed + launcher restarted on fixed code ~12:44 -> calm since (timed watches below).
Silver lining, measured: the emergency reboot IS the real power-cycle both boot-persistence gates were waiting for. Both autonomous arbiters flipped to PROVEN (section 4).

2. The three storm breakers (any one alone stops the class; all three are in)

Reads never actuate (d09f700): journey verify steps are pure observers; opening the studio is always a deliberate operator click.
One bring-up at a time (this commit): OS named mutex UNI_STUDIO_UP inside studio_up.ps1 itself — any extra invocation exits in <1s having started NOTHING. -Stop/-Status are never blocked. -MutexProbe is the side-effect-free drill hook.
Idempotent windows (this commit): the command-center Chrome window opens only if no chrome process already runs on its dedicated profile dir (chrome-profiles\command).

3. Class-A drill outputs (verbatim)

Timed spawn watch after the sweep (nothing spawning)

sample 1 @ 12:42:27: studio_up/systray=0  cc-windows=0  obs64=0
sample 2 @ 12:42:35: studio_up/systray=0  cc-windows=0  obs64=0
sample 3 @ 12:42:43: studio_up/systray=0  cc-windows=0  obs64=0

Mutex under REAL concurrency (3 simultaneous -MutexProbe)

probe 1 : MUTEX: HELD (this instance would proceed)
probe 2 : MUTEX: BUSY (another bring-up in flight - would exit without starting anything)
probe 3 : MUTEX: BUSY (another bring-up in flight - would exit without starting anything)
VERDICT: held=1 busy=2 -> MUTEX PROVEN under real concurrency
obs64 spawned by the drill: 0

Reads-never-actuate re-proof after all changes

3 journey polls + 12s: studio_up shells: 0  obs64: 0  cc-windows: 0

(Earlier same-day proof: 8 consecutive polls, 0 spawns.)

Storm cleanup: half-open services closed gracefully

graceful stop sent :8098 / :8099 / :8095
studio ports 4455/9997/8098/8099/8443/8095: down/down/down/down/down/down

4. BOTH boot-persistence gates — the arbiters' verbatim verdicts (exit 0)

-- door_boot_proof --
last_boot 07/14/2026 12:26:45 · install_marker 07/14/2026 12:23:20 · rebooted_since_install True
watchdog_last_start 07/14/2026 12:36:37 · started_after_boot True · port_8090_up True
DOOR REBOOT-SURVIVAL: PROVEN - the machine rebooted after install and the logon task returned the door on :8090.

-- gaia_boot_proof --
last_boot 07/14/2026 12:26:45 · install_marker 07/13/2026 20:32:11 · rebooted_since_install True
watchdog_last_start 07/14/2026 12:28:16 · started_after_boot True · port_8096_up True
REBOOT-SURVIVAL: PROVEN - the machine rebooted after install and the logon task returned Gaia on :8096 onto canonical bytes.

The journey independently detected the same reboot from os.uptime():

{"ts":"2026-07-14T17:28:14.791Z","step":"reboot_1","event":"auto-advance",
 "detail":"last_boot=2026-07-14T17:26:44.929Z armed_at=2026-07-14T17:17:08.189Z - a real reboot occurred since arming"}

5. Code / runtime / reality cross-check

Surface	Code (HEAD d09f700 + this commit)	Runtime (measured)	Agree
Door	door.html + living map + journey UI	:8090 UP, serves `The living map` + `renderMap`	YES
Gaia	collectors emit doors/journey/producer signals	:8096 UP, signals present, gate 11 PASS	YES
Journey	pure-read verify, atomic arming	current=verify_1, 2/11 done, ledger consistent	YES
Studio	closed until ONE KEY	all 6 ports down; obs64=0	YES
Boot legs	3 Startup .vbs entries on disk	both arbiters PROVEN post-reboot	YES
Spawners	mutex + dedup + pure reads	timed watches: zero spawns	YES

6. Honest notes / residuals

studio_up -Status | Select-Object -First 3 showed exit -1 in the drill harness — an artifact of the early-closed pipeline in the drill command, not of the script (full -Status runs exit 0).
The post-reboot auto-open window did NOT appear during the storm (box was saturated; the 90s wait honestly gave up, exit 1). With storms structurally dead, the next logon should auto-open; if it ever cannot, the desktop icon and the offline triage page remain.
Window-dedup's full integration proof (a second studio_up run NOT opening a second window) lands at the next deliberate ONE KEY press — the predicate and drill of its guard are above.
Sequence diagrams: docs/DOOR_LIFECYCLE_SEQUENCES.md (mermaid — boot, one-key, graceful close, journey, go-live, incident appendix). Live visual: the living map panel on /door.

sha256 d34eaf9649221654 — of the original file, so what was ingested stays checkable.

Written for this website — not the document. This is a plain-language retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. Read the document itself → (or choose Precise in the reading-level control above)

A record of a bad afternoon and what came out of it. A routine poll that was meant only to observe was actually triggering a full startup, so every open tab launched the studio over and over until dozens of shells were stacked up. The operator power-cycled the machine mid-storm, and the revived system loaded the still-faulty code from disk and did it again. Three independent brakes were then added, any one of which stops that whole class, so the storm cannot return the same way; the paths that stop the system or report on it are never blocked by them. The unplanned restart also happened to be the real power cycle two waiting gates needed, so both of them closed.

Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is d34eaf9649221654

Written for this website — not the document. This is a clearer retelling, written to help you meet the document. It is not the source, and it is not evidence. It has not yet been checked by a person. Read the document itself → (or choose Precise in the reading-level control above)

An audit written after an incident, and honest that the incident was self-inflicted. Two waves are described in order, with the second explained rather than excused: the restart revived the system onto code from disk that still carried the fault, because the fix was committed minutes after the machine came back up.

The cause of the first wave is stated plainly. A verification step that should have been a pure observation was actuating instead, so every routine poll from every open tab launched a bring-up, and each bring-up relaunched a program endlessly. The second wave added a flood of windows, because one step opened a new one unconditionally.

Three brakes were then installed, and the page notes that any one of them alone stops the class, which is the right way to build against a storm. Reads never actuate, so opening the studio is always a deliberate click. Only one bring-up may run at a time, enforced by a named lock inside the script itself, with the stop and status paths never blocked and a side-effect-free probe left in for drills. And a window opens only if one is not already open on its own profile.

The drill outputs are quoted rather than summarised: timed watches showing nothing spawning, three simultaneous probes where one proceeds and two exit having started nothing, a re-proof that polling actuates nothing, and a graceful shutdown that leaves every port down.

Then the silver lining, measured rather than asserted. The emergency restart was the genuine power cycle that two boot-persistence gates had been waiting for, and both arbiters flipped, each printing the boot time, the install marker and the port check that justify the verdict. Another part of the system detected the same restart independently, which is quoted alongside.

A cross-check table lines up what the code says against what was measured at runtime, surface by surface. The closing residuals stay honest. One odd exit code in a drill is explained as an artifact of the harness rather than of the script. One window did not auto-open because the machine was saturated, and one integration proof waits for the next deliberate press.

Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is d34eaf9649221654