PR #8963 · the go-live checklist, beside the switch that needs it
The seven things staff check before flipping a company live — read-only, real data or nothing, and it blocks nothing.
16 Sept 2026 · branch lane-d/golive-checklist · captured against propflow-stage · at b019e32415+local
Data note. Every name and balance below comes from propflow-stage, which is anonymized by construction (ADR-0097/0110 — phones in the impossible +1000 NPA, emails @example.test). The identical capture against prod would carry real tenants' names and balances and is not safe to attach anywhere, which is why the generator refuses to run against one.
1 · The checklist, under the live switch
The card sits directly under Clara replies to email, because that is what staff read just before they touch it. The onboarding flow map calls this checklist "a staff habit today, not a screen" — this makes it a screen without making it a rule: there is nothing to press, nothing is wired to the toggle above, and the closing line says so in as many words.
The point worth looking at is the status vocabulary. Four states, and two of them are negative in different ways: Not yet means we looked and it is genuinely not done, and Unknown means we could not look — a failed read, or a fact this platform does not record. Collapsing those into one grey dot is the fabricated status hot rule 1 forbids, and it is why a company with an unreadable building list reads Unknown here rather than a confident 0 of 0.
This fixture company is deliberately thin, so most rows render their negative branch. That is the useful capture: it is the branch a real pre-go-live company is in, and it is the one where a fabricated "Ready" would do the damage.
Asserted in the captured DOM — Before you turn Clara on · Portfolio connected · Every building has an escalation owner · Email identity chosen · A phone line points at a building · A calendar is attached · Mailbox reading confirmed · Nothing here blocks the switch. All six rows plus the card title and the it-blocks-nothing line, asserted as rendered text. The STATE of each row is deliberately not asserted here — it is a property of this fixture company's data, not of the card, and pinning it would make this capture fail whenever somebody edits the fixture. The states themselves are covered exhaustively, in both directions, by go-live-checklist-dto.test.ts (36 cases).
What this capture is for
Two things a unit test cannot reach. First, that the card lands under the switch and inside the main column rather than in the rail — the DTO tests know nothing about where it renders, and a card that reads correctly in isolation can still sit a thousand pixels from the control it belongs to (the mistake this page's own header records from an earlier round).
Second, that the negative rows read as information rather than breakage. A column of grey dots saying Unknown is the correct answer for a company nobody has set up yet, and it has to look like an answer.