Before Clara goes live — the customer's own copy of the pre-launch checklist
Founders' ruling 2026-09-17: the customer sees their own checklist in Settings — connect your inbox, connect a calendar — read off the same resolver staff read, showing only the rows they can act on.
17 Sept 2026 · branch onboarding/i1-customer-checklist · captured against propflow-stage · at da053a796d
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 · Company Settings, as the company admin — the card sits first
Captured as a real org_admin of Test Client Co on stage (a synthetic account minted through the back-office invite, scripts/seed-evidence-identity.ts). The company is not live and staff have set its email up as the customer's own inbox, one for the company — so both customer rows apply. Each row carries where it stands (the same StatusDot vocabulary as the staff card) and the one link to where it is done: Leasing email lands on the Integrations card below; Team on the roster.
What is deliberately NOT here: the phone line, the escalation owners, the PMS and "is the mailbox reading" — staff rows, ours to fix. A nag with no button is not a checklist row.
Asserted in the captured DOM — Before Clara goes live · PropFlow turns Clara on once these are done. · Connect your shared leasing inbox · Not connected yet. · Connect a calendar for tours · Leasing email · Team. The card title, its one-line reason, both customer rows with their state detail, and both action links — in the state the frame shows.
2 · Phone width — every row readable, nothing clipped
The labels wrap (min-w-0 break-words, the lesson the staff card learned at phone width) and the status stays on the row rather than being pushed off it.
Asserted in the captured DOM — Before Clara goes live · Connect your shared leasing inbox · Connect a calendar for tours
3 · Why the calendar row links to Team and not to Profile › My calendar
The plan of record links the customer's calendar row to Profile › My calendar. This is that page for the same admin: the company's connection status, and no connect control — MyCalendarCard is mounted with personalConnectAllowed={false} for an org_admin (Fede, 2026-09-14) and renders nothing when there is no personal calendar to manage. A link here would be a dead end. A teammate's calendar satisfies the row (deriveCalendarRow), so the card sends the admin to invite the people who show units instead. Reported on the PR as a contradiction for the founders, not fixed here.
Asserted in the captured DOM — Profile. Only the page heading is asserted — the point of this frame is what is absent.
What the frames do not prove
That the rows are TRUE for a company. That is the resolver's job (the same reads the staff card has used since #8963) and the DTO's: 14 tests pin which rows a customer sees and the inbox row's four states, and 8 pin that the route answers only the caller's own company and refuses staff and non-admins. The card hides itself once the company is live — not photographable on this bench without flipping a shared company's switch, and pinned by the route test instead.