, so its own max-width/padding apply. */ .toc-layout { max-width: 1080px; margin: 0 auto; padding: 2.5rem 2rem 6rem; display: grid; grid-template-columns: 220px 1fr; gap: 3rem; align-items: start; } .toc { position: sticky; top: 6rem; font-size: .92rem; max-height: calc(100vh - 8rem); overflow-y: auto; scrollbar-width: thin; } .toc h2 { font: 500 .78rem/1 var(--sans); text-transform: uppercase; letter-spacing: .06em; color: var(--ink-faint); margin: 0 0 .9rem; } .toc ol { list-style: none; margin: 0; padding: 0; } .toc li { margin: 0 0 .55rem; } .toc a { color: var(--ink-soft); display: block; line-height: 1.35; } .toc a:hover { color: var(--ink); text-decoration: none; } /* Page hero/lead */ .lead h1 { font: 400 2.6rem/1.15 var(--serif); margin: 0 0 .75rem; } .lead p { color: var(--ink-soft); margin: 0 0 2rem; max-width: 60ch; } /* A Google-Doc-backed page's rendered body (admin.gdoc_render): one .gdoc-body per GdocPage, holding whatever mix of section/h2-h4/p/ul-ol/ table/a/img the source document produced — never a fixed shape the way the hand-written FAQ markup (.qa-section/.qa/.num, now gone) was. Scoped under .gdoc-body rather than bare element selectors so this never leaks into unrelated content that happens to contain a or a

. That disclosure follows a facts grid inside a card, so it needs the separating rule and the breathing room a bare

has none of. Scoped to .payment-panel so no other .disclosure on the portal moves. */ .payment-panel > details.disclosure { border-top: 1px solid var(--rule); margin-top: 1.5rem; padding-top: 1rem; } .payment-panel > details.disclosure > summary { color: var(--ink); font-weight: 500; } /* Person page → Onboarding section (pages/person/onboarding.tsx). Three small things the checklist table did not need before: the note naming which personal channel is being checked, the category picker that sits in a row's action cell beside its Create button, and the issue block's link row in the two states that have no form. Everything else in the section reuses .kv-table, .pill, .form and .form-actions unchanged. */ .onboarding-channel-note { margin-top: -.35rem; } .onboarding-category { display: inline-flex; align-items: center; gap: .35rem; margin-right: .5rem; } .onboarding-category select { max-width: 14rem; } .onboarding-category-note { display: inline-block; margin-right: .5rem; max-width: 22rem; } .onboarding-issue { padding-top: .75rem; } .onboarding-issue .pill { margin-left: .35rem; } /* ── H2: the paginated table's page-range label ──────────────────────────── components/table's PaginatedTable renders its footer as a bare `.form-actions` flex row: Rows select, ‹ Prev, "1–5 of 5", Next ›. Two inherited rules conspired to lift that middle label off the buttons' centre line — `.form-actions` never sets align-items (so items stretch, and a stretched span paints its single line at the TOP of a button-height box), and `.muted` carries `margin-top: -.5rem`, spacing meant for a paragraph sitting under a heading rather than for a flex item between two buttons. Scoped to `.table-pager` so the fix reaches every paginated table and no other `.form-actions` row. Same shape as `.sweep-note` above, and for the same reason. */ .form-actions.table-pager { align-items: center; } .table-pager-range { margin-top: 0; } /* ── I2: the client page's Billing section ───────────────────────────────── Two different things share one card and must not read as one list: who to TALK TO (koseki's contacts, with a route per channel) and where the invoices GO (invoice_prefs.send_to / cc_to, which is a list because a client can want several). `.route-list` is the read view of either — one address per line, no bullets, so a three-recipient client does not read as prose — and `.route-row` is the edit view's input-plus-remove pair. */ .route-list { list-style: none; margin: 0; padding: 0; display: flex; flex-direction: column; gap: .15rem; } .route-list li { margin: 0; } .route-kind { color: var(--ink-faint); font-size: .8rem; text-transform: uppercase; letter-spacing: .04em; margin-right: .4rem; } .route-row { display: flex; gap: .4rem; align-items: center; margin-bottom: .3rem; } .route-row input { flex: 1 1 auto; min-width: 0; } /* The contact book's two add buttons — "Add channel" under each person, and "Add contact" under the list — are the same KIND of action at two levels, so they are drawn to one width rather than each shrink-wrapping its own label. `.btn` is an inline-flex whose width is its text, and the two labels differ by a few characters, which is exactly the mismatch that reads as sloppiness rather than as hierarchy. `min-width` rather than a fixed `width` so a longer label in future grows instead of overflowing, and `justify-content` because the flex box would otherwise leave the text hard left inside the wider box. */ .contact-action { min-width: 12rem; justify-content: center; } /* And they are given room to be told apart. Without this the channel button of one contact sits flush against the next contact's name, and the last one sits flush against "Add contact" — two different actions a few pixels apart. */ .contact-entry { margin-bottom: .9rem; } .contact-entry .contact-action { margin-top: .35rem; } /* THE `min-width` ABOVE WAS ONLY HALF THE STORY, because the two buttons sit at different depths. "Add channel" is nested inside a `.contact-entry`, so it is an inline-flex sized by `max(label, 12rem)` — 12rem. "Add contact" is a DIRECT child of the `.field` flex column, whose default `align-items: stretch` blew it out to the full column width, so the pair still did not match. Opting this one out of the stretch hands the sizing back to the shared `min-width`, which is the single mechanism that should be deciding it. */ .field > .contact-action { align-self: flex-start; margin-top: .9rem; } /* A `.grid` child that is not a field: a banner, a note, a form. `.grid` packs `auto-fit` 220px columns, so anything dropped into it is squeezed into one of them and reads as a value beside the fields rather than as something about them. This spans the row instead. */ .span-all { grid-column: 1 / -1; } /* A MULTI-FIELD EDITOR, STACKED. `.inline-field-form` is the other editing shape on these pages and it is a flex ROW — right for the one-input-plus-two- buttons case it was written for, and wrong for anything larger: an editor with two recipient lists, an explanatory paragraph, a notes box and a button pair laid those five out side by side, vertically centred, each squeezed to a fraction of the column. That is the invoice-routing editor "going all weird". So a form with more than one field says so and stacks. The gap is larger than `.field`'s own .15rem because these ARE separate fields rather than a label and its value. */ .stacked-form { display: flex; flex-direction: column; gap: .9rem; align-items: stretch; } .stacked-form input, .stacked-form select { width: 100%; min-width: 0; } /* The prose between fields keeps the paragraph measure it would have outside a form; a full-width line of small grey text is hard to come back from. */ .stacked-form .muted { margin: 0; max-width: 60ch; } .required-mark { color: var(--bad); font-weight: 700; } .field-help-mark { display: inline-flex; align-items: center; justify-content: center; width: 1rem; height: 1rem; border: 1px solid var(--ink-faint); border-radius: 50%; color: var(--ink-faint); font-size: .7rem; font-weight: 700; line-height: 1; } .form.invoice-outcome-form { display: flex; flex-direction: column; gap: 1rem; } .form.invoice-outcome-form > * { margin: 0; } .form.invoice-outcome-form .outcome-field > label, .form.invoice-outcome-form .receipt-foreign-toggle { display: flex; flex-direction: row; align-items: center; gap: .35rem; } .form.invoice-outcome-form .receipt-foreign-toggle { width: fit-content; color: var(--ink); font-size: .9rem; text-transform: none; letter-spacing: 0; } .form.invoice-outcome-form .receipt-foreign-toggle .field-help-mark { margin-left: .1rem; } .invoice-outcome-confirmation { display: flex; flex-direction: column; gap: 1rem; padding: 1.25rem; border: 1px solid var(--good-rule); border-radius: var(--radius); background: var(--good-soft); color: var(--good); } .invoice-outcome-confirmation h3, .invoice-outcome-confirmation p { margin: 0; } /* A note attached to ONE input — how a value will be interpreted, not what the form does. Sits under its box rather than in the label, which is where the eye already is when the box is the thing being questioned. */ .field-hint { font-size: .8rem; max-width: 60ch; } /* Person page — the Notes section's list of individual notes. koseki holds one commentary string per person; the server reads it as a list of {text, author, at} rows and this styles them as one. No bullet glyph: the byline is what separates one note from the next, and a marker column would push short notes away from the label grid the rest of the card uses. */ .person-notes { list-style: none; margin: 0; padding: 0; } .person-notes li { display: flex; align-items: flex-start; gap: .75rem; padding: .4rem 0; border-bottom: 1px solid var(--rule); } .person-notes li:last-child { border-bottom: 0; } .person-note-content { flex: 1 1 auto; min-width: 0; } /* The checked-in app bundle is rebuilt only during integration. Keep its pre-wrapper markup correct until that batch consumes the source change. */ .person-notes li > .person-note-text { flex: 1 1 auto; min-width: 0; } .person-note-text { white-space: pre-wrap; } /* Provenance is secondary to the note itself, and absent entirely on notes written before it was recorded — so it must read as an aside rather than as a field whose value is missing. */ .person-note-by { color: var(--ink-faint); font-size: .85em; } /* The withdraw control is anchored at the row's far edge. The note owns the flexible left column, so prose wraps beneath itself rather than pushing the destructive action to a different horizontal position on every row. */ .person-note-actions { display: flex; align-items: center; gap: .4rem; margin-left: auto; flex: 0 0 auto; } .person-add-note { margin-top: .75rem; } /* People list — the filter bar's dropdown multiselect pickers. components/ui's MultiSelect, used by pages/page-people for all six closed-list filters (project, milestone, task type, status, currency, missing docs). WHY THESE EXIST AT ALL: the same six filters shipped briefly as `