Wiki · Evidence & Verdicts
Receipt — door-boot-persistent (The Door survives an apocalypse) — 2026-07-14
How to read this page
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.
Your browser cannot switch reading levels, so the document itself is shown.
Precise — the source document
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 row: door-boot-persistent (evidence/gates.ndjson). Verdict PARTIAL — three legs PROVEN
live today, the literal reboot leg honestly PENDING until the next real power-cycle.
What was built
viewer/door_watchdog.ps1— dedicated supervisor forlauncher.cjs(:8090, serves/door); named-mutex (UNI_DOOR_WATCHDOG) self-dedup; 5s interval;-Oncegate mode.viewer/door_boot_install.ps1— per-user Startup.vbs(UNI-Door-Watchdog.vbs) + install marker (mirrors the provengaia_boot_install.ps1mechanism). Installed 2026-07-14T11:12:14.viewer/door_boot_proof.ps1— autonomous reboot arbiter (cannot false-pass: boot must post-date the install marker AND the watchdog must start post-boot AND :8090 answer).viewer/door_open.vbs+viewer/door_open.ps1— THE ICON PATH: always spawn the watchdog (mutex makes duplicates exit), wait for :8090, open the Chrome app window; if node itself is dead, open the staticviewer/door_offline.htmltriage page (the door never dead-ends).- Desktop + Start-menu shortcuts retargeted to
wscript.exe door_open.vbs(door icon kept). studio_up.ps1 -Stopsurvival is by construction (inspected, not executed live): neitherlauncher.cjsnordoor_watchdog.ps1appears in Kill-Everything's node/powershell match lists.
Honest calibration — a falsified first design, corrected forward
The first self-dedup used a CommandLine substring match (*door_watchdog.ps1*). The T1 drill
FALSIFIED it: the fresh watchdog matched the operator agent's own tool shell (whose command TEXT
mentions the script), declared a phantom twin, and exited — leaving the launcher dead. Log line:
2026-07-14T11:12:16 another door_watchdog is already running (PID 25316) - exiting.
Corrected to a named mutex (only a real holder is a twin); door_open.ps1 now spawns
unconditionally and lets the mutex arbitrate. The failed drill + correction are part of this receipt.
Drill outputs (verbatim)
T0 — dedup (mutex): spawn a 2nd watchdog, exactly ONE survives
before: 1 (PID 32964)
after spawn attempt: 1 (PID 32964)
T0 VERDICT: DEDUP PROVEN (mutex held, twin exited)
log: 2026-07-14T11:14:57 another door_watchdog holds the mutex - exiting
T1 — crash-restart: kill launcher.cjs, watchdog resurrects it
killing launcher PID=34608
launcher alive after kill: False
T1 VERDICT: launcher_resurrected=True door_serving=True -> CRASH-RESTART PROVEN
log: 2026-07-14T11:14:10 launcher.cjs DOWN - restarting / started launcher.cjs (port 8090)
T3 — apocalypse: kill watchdog + launcher, ONE icon click resurrects the chain
post-kill: watchdogs=0 launcher=False door=False (must be 0/False/False)
-- clicking the icon (wscript door_open.vbs) --
T3 VERDICT: watchdogs=1 launcher=True door_serving=True -> ONE-CLICK COLD RESURRECTION PROVEN
log: 2026-07-14T11:15:07 door_watchdog started (interval 5s, port 8090)
2026-07-14T11:15:07 launcher.cjs DOWN - restarting / started launcher.cjs (port 8090)
T4 — reboot leg (autonomous arbiter): honest NOT YET
last_boot : 07/13/2026 16:01:55
install_marker : 07/14/2026 11:12:14
rebooted_since_install : False
started_after_boot : True
port_8090_up : True
DOOR REBOOT-SURVIVAL: NOT YET - crash-restart + cold one-click are the proven legs; the reboot leg
confirms automatically on the next power-cycle.
What flips the gate to PASS
After the operator's next real reboot: powershell -File viewer\door_boot_proof.ps1 prints
DOOR REBOOT-SURVIVAL: PROVEN (exit 0). Append a superseding PASS row citing that output.
sha256 9dae19feb45450b0 — of the original file, so what was ingested stays checkable.
Plain — written for this website, not the source document
A record of testing whether a small piece of software comes back after being killed in several different ways. Three of the four legs were run live that day and came out well: two copies cannot both run, killing the process brings it back, and after killing everything a single click on the icon rebuilds the whole chain. The fourth leg, surviving an actual restart of the machine, is honestly marked as not yet, because no restart had happened since the thing was installed. The verdict is partial rather than pass, and that is the point.
Plain · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 9dae19feb45450b0
Clear — written for this website, not the source document
A receipt — the file recording what was run — with a partial verdict, and the partial is the honest part of it. Three legs were run live and are recorded with their output; the fourth waits on something that had not happened yet, a real power cycle.
The build list comes first. A supervisor watches the process and restarts it, and a startup installer leaves a marker recording when it was installed. An arbiter checks the restart leg on its own and cannot pass falsely, because it requires the boot to be later than that marker and the supervisor to have started after the boot. An icon path always tries to bring the chain up, and falls back to a static triage page if nothing can run at all, so the door never dead-ends. One survival property is marked as inspected rather than executed, which is a weaker class, and it is labelled as such rather than counted with the rest.
Then a section most receipts would leave out. The first design was falsified by its own drill. The check for a duplicate copy matched on command text, and it matched the operator's own tool shell, so a fresh copy saw a phantom twin and exited, leaving nothing running at all. The log line is quoted. The fix was to arbitrate with a named lock instead, where only a real holder counts as a twin. The failed drill and its correction are kept as part of the receipt.
The drill outputs are quoted verbatim, one block per leg, each ending in its own verdict line. The last block is the restart leg, and it prints its inputs and its refusal: the boot predates the install, so the answer is not yet. The page closes by saying exactly what would flip the gate, which is to run the arbiter after the next real restart and append a superseding row citing that output rather than editing this one.
Clear · written 2026-08-01 by claude-opus-5 · not yet checked by a person · about the document whose sha256 is 9dae19feb45450b0