Role card — whether we ask for a calendar, and which admin is the default
Wave 2, lane J: every role card gains one quiet line on the first-sign-in calendar ask — worded for the company's operating model — and the admin card says it is the default admin; the per-building admin is an optional property manager.
18 Sept 2026 · branch onboarding/j1-role-card-calendar-line · captured against propflow-stage · at 17ac74c203
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 · Organization admin — desktop
The card that answers Gera's own confusion (“we have admins and operators…”): one muted line under the name says this is the default admin, and that a per-building admin — optional — is a property manager given their buildings. Under the lists, the calendar line carries the founders' ruling for this role: never asked here. (Where an admin who also gives tours connects one is lane H3's Settings card, #9326, so this line names no Settings path yet.) This line does not change with the operating model. Neither line has a glyph: they are a footnote to the role, not a grant, and the four can-lines stay four. The sign-in screen honours it: since #9308 the gate routes on the catalog's own calendarAskFor table, which answers never for the admin.
Asserted in the captured DOM — Organization admin · Invite teammates, change what they can do, and remove them. · We never ask them for a calendar here. · The default admin. A property manager is your per-building admin if you want one.. The role's name, one can-line, and the new first-sign-in line, plus the default-admin note — in the state the screenshot shows.
2 · Property manager — desktop
The default role. Typing an address touches the row and the card appears with one new line under the two lists, in the same 12px muted ink as the lines above it. An anonymous capture resolves no session, so operatingModel is null — and the calendar line takes the gate's reading of that (isCentralizedLeasing: not literally centralized, so nobody is routed to the calendar screen): the building holds the calendar; no personal one is asked for. At a company known to be centralized the same slot reads “We'll ask them to connect their calendar so Clara can book tours on it.” — pinned by page.test.tsx, not photographable here (see the closing). No note under the name; only the admin carries one.
Asserted in the captured DOM — Property manager · Run the day to day: leasing, maintenance, collections, residents and vendors. · Their calendar lives on the building — we won't ask for a personal one.. The role's name, one can-line, and the new first-sign-in line — in the state the screenshot shows.
3 · Leasing agent — desktop
The same building line as the property manager under the same unknown model; at a centralized company both read the tours sentence, because both roles show units. The can / can't lists are the same words as before; nothing in the grant changed.
Asserted in the captured DOM — Leasing agent · Run leasing end to end: prospects, tours and renewals. · Their calendar lives on the building — we won't ask for a personal one.. The role's name, one can-line, and the new first-sign-in line — in the state the screenshot shows.
4 · Maintenance — desktop
Maintenance is asked too under the ruling (Sean: “still collect the maintenance guy's calendar when he signs up”) — at a centralized company the line reads “…so work orders land on it.” Here, under the unknown model, it reads the building line like the other two. The screen asks by role, not by which modules the company bought — #9308 dropped the modules gate, and calendarAskFor('maintenance') answers work_orders.
Asserted in the captured DOM — Maintenance · Run work orders from start to finish, and manage vendors. · Their calendar lives on the building — we won't ask for a personal one.. The role's name, one can-line, and the new first-sign-in line — in the state the screenshot shows.
5 · View only — desktop
The one role the ruling exempts, under either model. Three words, so the line is still there — a card that said nothing would leave the reader guessing whether we forgot — and it says nothing is asked.
Asserted in the captured DOM — View only · Change or add anything, anywhere. · Nothing to connect.. The role's name, one can-line, and the new first-sign-in line — in the state the screenshot shows.
6 · Organization admin — phone
The same card at 390px: Can stacks above Can't, and the calendar line sits under both as the block's last line, with the default-admin note wrapping under the name. Nothing is squeezed and no fifth bullet was added to keep the admin's card short here.
Asserted in the captured DOM — Organization admin · We never ask them for a calendar here. · The default admin. A property manager is your per-building admin if you want one.
7 · Property manager — phone
The same card at 390px: Can stacks above Can't, and the calendar line sits under both as the block's last line. Nothing is squeezed and no fifth bullet was added to keep the admin's card short here.
Asserted in the captured DOM — Property manager · Their calendar lives on the building — we won't ask for a personal one.
8 · Leasing agent — phone
The same card at 390px: Can stacks above Can't, and the calendar line sits under both as the block's last line. Nothing is squeezed and no fifth bullet was added to keep the admin's card short here.
Asserted in the captured DOM — Leasing agent · Their calendar lives on the building — we won't ask for a personal one.
9 · Maintenance — phone
The same card at 390px: Can stacks above Can't, and the calendar line sits under both as the block's last line. Nothing is squeezed and no fifth bullet was added to keep the admin's card short here.
Asserted in the captured DOM — Maintenance · Their calendar lives on the building — we won't ask for a personal one.
10 · View only — phone
The same card at 390px: Can stacks above Can't, and the calendar line sits under both as the block's last line. Nothing is squeezed and no fifth bullet was added to keep the admin's card short here.
Asserted in the captured DOM — View only · Nothing to connect.
11 · Compare with other roles — all five lines at once
The fold opens the other four under the selected one, and every block carries its own calendar line, so the five answers can be read in one place. Under this capture's unknown model the three working roles all read the building line; the admin's says never; view-only's says nothing to connect. The admin's note is on the admin's block alone.
Asserted in the captured DOM — Property manager (selected) · We never ask them for a calendar here. · The default admin. A property manager is your per-building admin if you want one. · Their calendar lives on the building — we won't ask for a personal one. · Nothing to connect.. Under the unknown model there are three distinct first-sign-in sentences on screen — the building line (shared by the three working roles), the admin's never-asked line, and view-only's — plus the admin's note; the three asserted lines are those three.
Captured anonymously, on purpose — and what these frames do not prove
Neither identity this tool signs in as can reach the wizard (the smoke account is platform staff and is redirected; the seeded non-staff identity is already onboarded and is redirected too), so every section declares anonymous: a local dev server serves the step unauthenticated, and these frames are the step exactly as a customer meets it. The run's own guard confirmed the data source was propflow-stage before a browser launched.
Which wording these frames show, and why. An anonymous request resolves no Organization row, so operatingModel is null. The buildings picker reads that as not-per-building (a grant: narrow is safe); the calendar line reads it the way the calendar gate does — isCentralizedLeasing is true only for a row that literally says centralized, so an unknown company is routed to the calendar screen for nobody, and the card must not promise an ask the gate will not make. That is why the three working roles read “Their calendar lives on the building — we won't ask for a personal one.” here. The centralized wording (“We'll ask them…”, tours or work orders) needs a signed-in admin of a centralized company who has not finished onboarding; no identity this tool holds qualifies and minting one is a data write (the reason #8953 gave for its picker), so it is covered by page.test.tsx — a positive control that the centralized model renders “We'll ask”, and a loop over per_building_team and null asserting no card does.
What these frames do not prove: that the calendar screen fires the way the centralized sentences say. That is pinned in code instead. Since #9308 (merged, and in this branch) welcome-calendar-route.ts routes on the catalog's calendarAskFor table — isCalendarAskRole is its second line — so an admin and a view-only teammate are exempt by role and the three working roles are asked, worded for tours or for work orders. role-catalog.test.ts ties the card's copy to that gate over every UserRole: an offered role's line says “we'll ask” exactly when the gate asks, carries the per-building variant exactly then, and is worded for what the gate asks for; an unoffered role has no card line at all. The one carve-out the gate keeps is isCentralizedLeasing — nobody at a company that is not literally centralized is routed — and the card reads the model the same way (calendarLineIsBuildingHeld, tied to isCentralizedLeasing in roles.test.ts), which is why these anonymous frames show the building line.