Preflight
Everything exercised before the room fills up
1 · Exercise & room
2 · Sign-in
The facilitator password is required — most of the board is gated behind it. The other two are optional; supply them and preflight will prove the class and Red Cell logins work and that the database rules actually hold against a student account. It finishes signed in as the facilitator either way.
3 · The room’s links
4 · Platform
5 · Every scenario
Every pack is checked, including the ones you did not select — a pack that failed to deploy is invisible until the class you run it for.
6 · Deploy completeness
Reads every page on the site, pulls out every file those pages ask for, and checks each one is actually there. The list is generated from the deployed HTML, so it cannot go stale as the code changes. This is the check that catches a partial upload — a deploy missing files looks completely normal until the moment a seat is opened.
Present is not the same as working, so every script is also handed to the browser’s parser. A file with one character out of place downloads perfectly and then does nothing, taking its whole page with it — that is how the pre-work page sat dead for days with every other check on this board green. The same pass reports what a full room actually downloads, which is the other half of the load question the burst test asks below.
7 · Seats load
Each page is opened for real against a scratch room code and probed for the objects its scripts must have created. Errors thrown before that probe are caught; a page that fails to parse shows as missing objects.
8 · Accounts
9 · Database rules, per node
Signed in as a student, preflight tries the reads a student must never get. A pass here means the attempt was refused.
10 · Dry run — the whole loop
The one thing a single browser cannot do is be two people at once. So preflight does it in turns: it signs in as a participant and files a decision, signs in as you and confirms it arrived, publishes an inject, signs back in as the participant and confirms it landed, then wipes the scratch room and checks it is empty. That is the exercise's whole data path, proven without a second device.
11 · The room you’re about to run
The archive write matters most here: it proves the record you hand a program office after the class can actually be saved. Every completed run is logged to the database, so you can show the checks were done before a session.
12 · Network under load
The first two run on open and need no sign-in — run them on the room’s Wi-Fi, not your hotspot. The last one downloads a real video inject to measure what the venue can actually carry, so it waits for you to ask.
13 · AI advisors, every role
Real calls to the live backend: every role on the selected exercise, plus both advisor personas on the other three. The row also names which model answered — if the ladder fell back off Sonnet 5, the advisor argues less sharply and that belongs in your debrief. Results are held for five minutes so an accidental reload does not wait through all thirteen calls again. The row says how old a held result is; Re-test the AI now ignores the cache.
14 · Report
What this page does not prove: it runs from the network you are on now — run it again on the room’s Wi-Fi before the class arrives. It does not check the video injects or inject imagery. It writes only to a scratch room (—) and never touches your real room’s data.
The one thing to check by eye: the standing monitor watches the platform between classes and emails you if it fails. Preflight cannot read it — doing so would mean putting a monitoring key in this page, where anyone could take it and switch your monitors off. Open the monitor dashboard and confirm it reads 1 of 50 monitors, green. If it reads 0, nothing has been watching.