and IS matched by the child rule
above, but portal.css:4491 declares `padding:0 64px!important` inside the
BRIEFING PROGRESS BAR redesign block, and !important outranks any selector
here. That block also carries eight more `.brief-prog` padding arms across
the breakpoints (600/900/768/640/480/380 and a 681–1024 arm it shares with
.brief-prefilled), so zeroing it once here is one rule against eleven edits
in that file, and cannot leave a width behind. `.brief-reassure` is a
,
and the child rule above names div/section/article only — it was never
reached at any specificity.
!important IS USED ON THE FIRST ARM ONLY, and only because its opponent is
!important too; the note above prefers id strength and that is still right
where it can win. The second arm needs nothing: (0,2,1) over (0,1,0).
HORIZONTAL ONLY. `.brief-prog` keeps its 44px height and `.brief-reassure`
its 10px of vertical air — that is rhythm, and it is not what doubled. */
body .tab-panel.active > .brief-prog{
padding-left:0!important;
padding-right:0!important;
}
body .tab-panel.active > .brief-reassure,
/* ⚠ AND ITS SIBLING ONE LINE BELOW IT, MISSED IN THE SAME PASS (2026-09-08,
second look). `.autosave-hint-top` is the live "● Saved 14:32" proof that
replaces the promise in `.brief-reassure` the moment the first autosave
fires. It is a
with its own `padding:2px 48px 10px`, so it escaped for
exactly the reason `.brief-reassure` did — the div/section/article child
rule above never named it — and it carries the SAME three breakpoint arms
(900/600) in portal.css:5423-5425, all of them (0,1,0) and none !important.
Measured on the Vision room against a 32px gutter: box at 32, text at 64,
while .pkg-lbl, .brief-prog-lbl and .brief-reassure all sat at 32. It is
display:none until the first save, which is why a screenshot of an untouched
form does not show it — the client sees it only once they start typing,
which is the worst moment to move a line. */
body .tab-panel.active > .autosave-hint-top{
padding-left:0;
padding-right:0;
}
/* ⚠ AND TWO THAT NEEDED A SOURCE FIX, NOT A CSS ONE — .designs-ask and
#rm-host-experience kept a 24px interior against every rule above, including
an id-strength one. Neither is a specificity problem: both carry the padding
as an INLINE style, which outranks any stylesheet short of !important.
app/client-portal.html:3252 style="…padding:22px 24px 0…"
app/scripts/portal-rooms.js:1437 wrap.style.cssText = 'padding:24px;…'
Fixed at those two lines instead (22px 0 0 / 24px 0), so the horizontal inset
is supplied once by the gutter and the vertical rhythm is untouched. Nothing
is restated here — if a rule appears in this file for either selector again,
the inline style has come back. */
/* ⚠ THE GLANCE HEADER RULE — 2px of onyx under a 0.58em label (2026-08-25).
Owner, on a zoomed screenshot of this rail: "design wise this is bad." The
heaviest line on the whole card sat under its smallest piece of type, and it
contradicts this file's own header: "Rules are sageDeep, not grey: 0.15 quiet,
0.30 for an edge." A 2px near-black rule is neither, and it is the only one of
its weight in the portal. It reads as a divider bar rather than a card header,
which is most of why the rail looked broken when its body scrolled under it.
The edge strength (0.30) is the right one here — it IS an edge. */
body .gs-glance-hdr{
border-bottom:1px solid var(--v10-rule-edge);
}
/* ═══════════════════════════════════════════════════════════════════════════
9 · COHESION PASS — 2026-08-25 (evening). Owner, on live portal screenshots:
the portal "feels like many features added over time without being properly
integrated … conflicting layouts, inconsistent formatting, unnecessary visual
density, unclear hierarchy." Every rule below consolidates something that
existed twice, or aligns one stray component with a system that already
exists in this file. Nothing is removed — measured first with
scripts/portal-format-shots.mjs, then fixed, then re-measured.
═══════════════════════════════════════════════════════════════════════════ */
/* ── 9a · ONE TELLING OF THE NEXT STEP PER SCREEN ─────────────────────────
The Next Step hero band (#nextStepCard) rendered identically on all TEN
rooms — ~230px of the same sentence above every screen — while the
At a Glance rail repeats it in compact form ("Next: …" + GO) and the
Guests/Files pinned column repeats it a third time. Three tellings of one
fact on one screen is most of what reads as "stacked formats".
The hero now shows ONLY on Today (the room whose job it is), and only
hides where the rail is actually present to carry the message:
· body[data-active-tab] — stamped by portal-rooms.js syncFromTab(); absent
before the rooms engine boots, so the pre-boot paint is untouched.
· body.portal-aside-visible — set only when the At a Glance rail rendered.
· ≥1025px — below that the rail is display:none (portal.css:5554), the
hero is the ONLY next-step surface, and it stays on every room.
display uses !important deliberately: renderNextStepCard() sets an inline
display:block, and this is a scoped, documented override of that inline
style, same pattern as §4's radius law. */
@media (min-width:1025px){
body.portal-aside-visible[data-active-tab]:not([data-active-tab="today"]) #nextStepCard{
display:none !important;
}
}
/* ── 9b · THE RAIL'S FRAME ENDS WHERE ITS CONTENT ENDS ────────────────────
.tab-split-aside was position:fixed with BOTH top and bottom pinned, so its
0.5px frame always spanned the full window height — after the 2026-08-25
trim its content is ~470px, leaving up to ~300px of empty bordered ivory
below Suite Progress that read as a broken, half-loaded panel. Height now
follows content; max-height keeps the same footer clearance the bottom pin
enforced (81px = the fixed opaque footer + breathing room — see
portal.css's warning at .tab-split-aside), and the body still scrolls inside
when long.
⚠ THIS BLOCK IS WHY portal.css's OWN `bottom:calc(81px + …)` NEVER RUNS ON THIS
ELEMENT. `body .tab-split-aside` outranks `.tab-split-aside` and sets bottom:auto,
so the footer clearance moved here and portal.css's number is the losing half of
a pair. A guard that checked only the other file would have passed while the
panel was sliced — so test/portal-footer-geometry.test.mjs asserts BOTH, and
derives the figure from the footer's own markup.
⚠ 62px → 81px on 2026-09-06: the legal row took §8.7's type floor and then the
44px house touch floor, and the footer went 42px → 61px underneath both files. */
@media (min-width:1025px){
body .tab-split-aside{
bottom:auto;
max-height:calc(100vh - var(--hdr-h,var(--hdr-reserve,140px)) - var(--beta-h,0px) - 20px - 81px - env(safe-area-inset-bottom, 0px));
display:flex;
flex-direction:column;
}
body .gs-glance{ height:auto; max-height:100%; }
}
/* ── 9c · PAGE HEADERS: ONE ALIGNMENT ─────────────────────────────────────
Billing and My Events were the only two rooms with a CENTRED page title
(portal.css:4342 .billing-hero) — every other room is left-aligned on the
64px house edge (F-6, 2026-08-21). Two alignments for one structural role
is a conflict, not a variation; the Today letter keeps its centring because
it is correspondence, not a page header. */
body .billing-hero{ text-align:left; padding-top:48px; padding-bottom:32px; }
body .billing-sub{ margin:0; }
/* ── 9d · ONE TRACKED-LABEL VOICE ─────────────────────────────────────────
§2 of this file states the label law (.62rem/.24em/uppercase/sage) and its
list missed four label classes that grew up in module-injected stylesheets:
the Today lanes' .td-lbl (.55rem/.22em/ink-grey), the pinned column's
.rm-pin-k, and the Files countdown's .ech-eyebrow (.36em tracking — the
widest tracking in the portal, on one element). The lane COLOUR coding
(you/us/auto) survives: those rules are .td-lane.you .td-lbl — higher
specificity than this. .rm-wall-k is deliberately absent: it sits on the
dark artwork ground and keeps its light ink. */
body .td-lbl, body .rm-pin-k, body .ech-eyebrow{
font-family:var(--v10-ui);
font-size:var(--text-micro);
letter-spacing:.24em;
text-transform:uppercase;
font-weight:600;
color:var(--sage,#265450);
}
/* ── 9e · ONE CHIP FAMILY ─────────────────────────────────────────────────
Status chips came in three unrelated shapes: .nsc-ball (.6rem/.14em, 4x12px,
tint or fill), the rail's occasion tag .gs-glance-hdr-tag (.52em, solid
dark-green fill — the only solid dark chip in the portal), and the event
set-up ESSENTIALS tag. One family now: the quiet sage tint for facts and
house-side states, the bloodstone fill (unchanged, .nsc-ball-you) reserved
for "waiting on you". */
body .gs-glance-hdr-tag{
font-size:var(--text-micro);
letter-spacing:.14em;
font-weight:700;
/* The same rebind arithmetic as the status pills, and the same answer: this tag is a FACT, so
it is quiet layer, not colour. onyx-62 on the sage tint measured 4.10 on Linen and 3.63 on
Alabaster — under AA on both — where onyx-78 on the Onyx-12 tint reads 6.66 and 5.88. */
color:var(--ch8-onyx-78);
background:rgba(20,20,20,.12);
padding:4px 10px;
}
/* ── 9f · CONTROL FLOOR AT EVERY WIDTH ────────────────────────────────────
The 44px floor existed only inside the ≤640px media arm (portal.css:5507),
so the SAME control rendered 31–42px on desktop and 44px on a phone —
measured per room: Suite 31/39/46/107, Files 34/38/42, Billing 42/48,
My Events 38. One floor for standard actions at every width; .ros-open is
deliberately absent — the run-of-show card's 36px operational density is a
recorded decision (PORTAL_FORMATTING_LEDGER §21), and the choice-card
heights (107/118/150) are content, not controls. */
body .mts-open, body .ds-share-btn, body .pdp-save, body #ewRetryBtn,
body .upgrade-card-btn, body .ndl-fmt-btn, body .billing-action-btn,
body .upgrade-btn, body .yp-btn, body .td-btn,
body .yp-v-in, body select.yp-v-in, body input.yp-v-in{
min-height:44px;
}
/* .pdp-save's bespoke 13px vertical padding rendered it 46px beside 44px
siblings — one off-system value on the screen. 11px + the floor above = 44
exactly, same as .nsc-btn. (.upgrade-btn's 48px is NOT flattened: it is the
--btn-pad-lg token, a deliberate large-CTA tier, not drift.) */
body .pdp-save{ padding-top:12px; padding-bottom:12px; }
/* ── 9g · THE FILES COUNTDOWN, AT ROOM SCALE ──────────────────────────────
#eventCountdownHero opened the Files room with numerals up to 4.8rem and a
bloodstone wash — a second hero, LOUDER than the room's own title, above the
files it exists to deliver, duplicating the countdown the rail already
shows. It stays (celebration is a feature), at a scale that no longer
competes with the page header (43.2px), and on the ivory ground like every
other band — the wash was the only pink surface in the portal. */
body .event-countdown-hero{ padding-top:32px; padding-bottom:28px; }
body .event-countdown-hero::before{ background:transparent; }
body .ech-num{ font-size:clamp(2rem, 4vw, 3.2rem); }
body .ech-title{ font-size:clamp(1.3rem, 2.6vw, 1.9rem); margin-bottom:20px; }
/* ── 9h · THE MOODBOARD WALL IS A FRAMED PANEL ────────────────────────────
.rm-wall renders the client's real moodboard HTML in an iframe under a
bottom-anchored gradient. Above the gradient the artwork sits directly on
the ivory page ground with no boundary, so its own rotated captions and
sketches read as loose, broken page content overlapping the Today room
(owner's screenshot, 2026-08-25). A hairline contains it: the art is
unmistakably a framed panel, exactly like the plate-frame heroes. */
body .rm-wall{ border:1px solid var(--v10-rule-edge); }
/* ── 9i · THE LETTER'S NAME IN THE DISPLAY VOICE ──────────────────────────
Register A's name line (.td-letter .nm) is an
whose injected style sets
face and size but not weight, so it inherited bold — the only 700-weight
display type in the portal (measured 37.8px/700 against the system's
43.2px/300). The letter keeps its centred correspondence form; only the
weight joins the family. */
body .td-letter .nm{ font-weight:400; }
/* ── 9j · THE RAIL AT RAIL SCALE (owner follow-up, 2026-08-25 evening) ─────
Two measured defects made At a Glance read as broken:
1 · §5's ruled-band rule names `.gs-cal` — but the only .gs-cal in the
portal is the little calendar INSIDE the 320px rail, so a page-scale band
treatment landed on a rail-scale component: 32px top padding and a 48px
band-gap under a 119px block. That 48px is the dead space under the date
the owner pointed at, and it pushed the rail's last section past its own
edge. Measured before: event section 209px, rail content 617px against
519px visible — Your Guests clipped mid-content behind an invisible
scrollbar. Scoped restore, not a change to §5: bands stay bands on the
page; inside the rail the calendar is a component.
2 · The rail inherited the page's 18px base type, so every em-padding in a
320px column was sized for a 1440px page. 16px is the rail's own scale;
everything inside is em-based and follows. Content 617px → ~480px:
the whole card fits its frame again in the common states. */
body .tab-split-aside .gs-cal{
padding:0;
margin:0 0 .4em;
border:0;
background:transparent;
}
body .tab-split-aside .gs-glance{ font-size:16px; }
/* ── 9k · THE HEADER PAIR (owner follow-up: "client and event dropdowns") ──
A second event on the account makes #hdrEventSwitcher appear beside the
client chip. The two are the same kind of control and already share the
chip form; what made them read as clutter is that the CLIENT chip had no
width cap — "ÉLise Fontaine-Beaumont" ran the chip to 354px, EVENT ran to
307px, and together they crushed the support line to "answered wi…" at
1440. The event name already capped at 180px; the client name now caps the
same way, the two chips share one interior metric, and the pair sits
tighter than it sits to the bell — so it reads as one group, two choices:
which event · whose account. Both dropdowns keep working exactly as they
do; nothing is hidden. */
body .hdr-client-name{
max-width:200px;
overflow:hidden;
text-overflow:ellipsis;
white-space:nowrap;
}
body .hdr-event-chip, body .hdr-client-chip{ gap:8px; padding:8px 14px; }
body .hdr-meta{ gap:8px; }
body .hdr-meta .hdr-bell{ margin-right:6px; }
/* ── 9l · THE RAIL RETIRED, THE COLUMN MADE WHOLE (owner, 2026-08-25 evening:
"shouldn't we remove the at a glance …?") ─────────────────────────────────
populatePortalAsides() (client-portal.html) no longer sets
body.portal-aside-visible, which is the one switch everything keyed on:
the 360px reserve (portal.css:5564), the two full-width bars' reserves
(:5599, :5608) and §9a's hide of the Next Step band all stop applying, so
the band returns on every room as the single next-step surface and the
content column gets its width back. One thing the class's absence does NOT
supply is a right page gutter — the un-classed panel computes
padding-right:0 at ≥1025px (it was only ever indented FOR the rail), so
the gutter is stated here, symmetric with the left one from the 2026-08-25
morning pass. */
@media (min-width:1025px){
body:not(.portal-aside-visible) .tab-panel.active{ padding-right:var(--v10-gutter); }
}
/* ── 9m · EVENT + CLIENT AS ONE CONTROL (same owner message: "consolidate
dropdowns to event and client being together") ───────────────────────────
The two chips are the same kind of control and now read as one segmented
unit: attached edges, the client chip's left border as the divider. The
negative margin cancels .hdr-meta's 10px flex gap between exactly these
two. When the account has one event, #hdrEventSwitcher is display:none and
both rules are inert — the client chip stands alone, unchanged. Both
dropdown menus keep their own behaviour and anchors. */
body #hdrEventSwitcher{ margin-right:-10px; }
body #hdrEventSwitcher .hdr-event-chip{ border-right:0; }
/* ── 9n · THE EVENT SWITCHER ON A PHONE (register ME-082, 2026-08-26) ───────
MEASURED, not guessed: at a 375px viewport the switcher's right edge sat at
**393px** — 18px off the screen — and the chip stood **34px** tall, under the
house's 44px touch floor. The page did not report a horizontal overflow
because the header clips it, which is exactly why this survived: the control
was partly unreachable and nothing said so.
Three narrow changes, none of which touch the desktop rendering:
1. The "EVENT" eyebrow is dropped. It labels a chip that is already showing
an event name, and it is the single widest piece of dead width here.
2. The name gets a max-width in `ch`, so it truncates with its existing
ellipsis instead of pushing the caret off-screen.
3. The chip meets the touch floor, and the menu anchors to the RIGHT edge so
a long event name cannot push the dropdown out of view either.
Specificity matches the `body .hdr-event-chip` rules above deliberately —
a bare `.hdr-event-chip` here would lose to them and silently do nothing. */
@media (max-width:600px){
body .hdr-event-chip{ padding:8px 12px; min-height:44px; box-sizing:border-box; }
body .hdr-event-chip .hdr-event-label{ display:none; }
body .hdr-event-chip .hdr-event-name{ max-width:14ch; }
body #hdrEventSwitcher .hdr-event-dropdown{ left:auto; right:0; min-width:min(260px, calc(100vw - 32px)); }
/* The options ARE the switch, so they carry the floor too. MEASURED with the
rule removed: an option with a sub-line is 62–81px and fine, but one WITHOUT
a sub-line — an event with no type and no date — is **43px**. One pixel under,
on the only control this row is about.
⚠ min-height ALONE, no flex. The first version added `display:flex;
align-items:center` and that was a real regression: the option's sub-line is a
child
, so a row flex box put "wedding · 2026" BESIDE the event name
instead of under it, and the two-line option collapsed 81px → 63px. Block
layout already stacks them correctly; only the floor was missing. */
body #hdrEventSwitcher .hdr-event-opt{ min-height:44px; }
}
/* ── 9o · THE HEADER PAIR STACKS, AND ITS TYPE COMES DOWN (2026-09-05) ──────
§9k above capped both names because the two chips "crushed the support line
to 'answered wi…' at 1440". That cap held until ledger 19-h gave the event
chip a SECOND string: the occasion-and-plan eyebrow, written by
scripts/portal-event-header.js. It is not a short word — "MILESTONE
BIRTHDAY · ESSENTIALS" renders 313px at .72rem/.2em — and side by side with
the name it put the pair back over budget.
MEASURED at 1440px, signed in as the walkthrough client (Adaeze Okafor /
"Margaret Okafor's 70th Birthday" — real-length data, per §23 of the
formatting spec), before this block:
.hdr-meta 954px of the 1280px the row has to give
.hdr-support 216px shown, of 484px needed → "hello@evor…"
#hdrEventName 180px shown, of 240px needed → "…70t…"
TWO THINGS, ONE CAUSE. The eyebrow and the name are a label and its value;
they do not have to sit on one line. Stacked, the chip is as wide as the
WIDER of the two rather than as wide as their sum, and the type can come
down to eyebrow scale because it is no longer competing for a baseline with
the name beside it.
⚠ SIZES IN PX, NOT IN --text-* ON PURPOSE. tokens.css sets
html{font-size:112.5%} for this portal (18px root, owner 2026-08-03 "make
the portal match the site"), so --text-xs lands at 12.96px and --text-base
at 16.2px — body scale, not header-chrome scale. There is no token below
--text-xs to name, and moving the root is an owner decision the v15 skin
explicitly declines to make (portal-v15.css, note 2). So the two header
eyebrows state their own size and say why here.
AFTER, same viewport and same client:
.hdr-meta 582px
.hdr-support 432px shown, 432px needed → whole line reads
#hdrEventName not clipped; #hdrClientName not clipped
.hdr-top height 74.4px (was 74.4px)
THE HEIGHT IS THE CONSTRAINT, and it is why .hdr-top's vertical padding
comes down 18px → 14px in the same breath: a two-line chip is 46px where a
one-line chip was 38px, and --hdr-reserve (135px on desktop since 2026-09-05, portal.css) is asserted
against the header's settled height by test/portal-header-reserve.test.mjs.
Trading 8px of row padding for the 8px the second line costs keeps the
reserve exactly right and the CLS work behind it untouched.
⚠ min-width:601px. Below it §9n already settles this chip its own way — the
eyebrow is dropped entirely and the chip takes the 44px touch floor — so a
stacked rule there would either fight that or do nothing. The phone header
is deliberately out of scope. */
@media (min-width:601px){
body .hdr-top{ padding:14px 64px; }
body .hdr-event-chip, body .hdr-client-chip{
flex-direction:column; align-items:flex-start; gap:0;
padding:6px 30px 6px 14px; /* right side holds the caret, now absolute */
position:relative;
}
body .hdr-event-label, body .hdr-client-label{
font-size:9.5px; letter-spacing:.14em; line-height:1.5; white-space:nowrap;
/* ONE INK FOR THE PAIR. .hdr-client-label sits in portal.css's big
"…{color:var(--onyx)}" list and rendered #141414 while .hdr-event-label
rendered #464542 beside it — invisible while the two labels were on
separate lines of a wide row, plainly wrong now they are stacked eyebrows
two chips apart. The quieter ink is the eyebrow's, and it measures ~7.9:1
on Linen, so this is a design call and not a contrast concession. */
color:var(--ch8-onyx-78);
}
body .hdr-event-name, body .hdr-client-name{
font-size:12.5px; line-height:1.45; display:block;
max-width:210px; overflow:hidden; text-overflow:ellipsis; white-space:nowrap;
}
body .hdr-client-name{ max-width:170px; }
/* Out of the column and centred on the whole chip: as a third flex child it
would sit UNDER the name and make the chip three lines tall. */
body .hdr-event-chip .hdr-account-caret,
body .hdr-client-chip .hdr-account-caret{
position:absolute; right:11px; top:50%; transform:translateY(-50%);
margin:0; font-size:10px; line-height:1;
}
/* The support line comes down with the pair — same register, and the tighter
tracking is what lets the whole sentence read at 1280 rather than at 1600.
⚠ 12px EXACTLY, AND IT IS A FLOOR, NOT A TASTE. This line's is the
address in Crimson (portal-v15.css), and Crimson is a functional colour —
scripts/portal-brand-conformance.mjs reports functional ink under
SMALL_TEXT_PX (12) on a pale ground as a finding. 11.5px measured fine and
would have been a red on the next conformance run. */
body .hdr-support{ font-size:12px; letter-spacing:.04em; }
}
/* ═══════════════════════════════════════════════════════════════════════════
10 · THE ONE LEFT EDGE — WHERE THE TEXT STARTS (2026-08-25)
───────────────────────────────────────────────────────────────────────────
Owner, on screenshots of two different rooms: "i dont love that the left
formatting throughout the client portal changes everytime. can we make one
law about the left formatting? id prefer everything cohesive and equal, and
left formatting always the same."
THE LAW, in one sentence: in every room, at every width, the first character
of text begins at the page gutter — and a band gets there in exactly one of
two ways, never both and never neither.
(a) A BARE BAND — a stretch of page with no surface of its own — has no
interior at all and inherits the panel's gutter (§7 above).
(b) A FULL-BLEED SURFACE — a hero, a white section, a ruled band that
paints something — cancels the panel gutter with a negative margin and
supplies the SAME value as its own interior.
Both land the text on one line. What is forbidden is doing both, which is
what almost every defect here turned out to be: the panel's gutter plus a
private copy of the same number, i.e. text at exactly 2 × gutter.
⚠ THE PATTERN WAS ALREADY IN THE FILE, IN #nextStepCard, AND THAT IS THE ONE
THAT WAS RIGHT. Measured at 1440 before this block:
#nextStepCard box 0..1440 .nsc-inner padding-left 64 → text 64 ✓
#conceptHero box 64..1376 .ds-hero-body " 64 → text 128 ✗
The Next Step hero is not a child of .tab-panel, so the gutter never reached
it and its own 64px interior IS the gutter. .ds-hero is a child, so it got
the gutter twice. Same component language, opposite result, and the second
is what the owner screenshotted. So case (b) is not a new invention — it is
the existing correct hero generalised to the sections that missed it.
⚠ DO NOT "FIX" THIS BY DELETING THE INNER PADDING. That was this block's
first attempt and it was wrong, caught by rendering it rather than by
reasoning: §6 draws THE PLATE FRAME — a hairline at inset:14px — on
.ds-hero, .rhb-hero, .bb-hero and #nextStepCard, and that frame assumes the
hero has an interior to be inset from. With the interior at 0 the heading
ran straight through its own frame, the exact failure §6's own comment
already warns about ("A plate frame that its own content crosses is worse
than no frame") and had already fixed once at 375px. Pixel-checked: a solid
rule at x=78 with "Your moodboards," starting at x=64 and crossing it.
The interior is load-bearing. Cancel the OUTER gutter, never the inner one.
⚠ LEFT ONLY — the right margin is deliberately untouched. At ≥1025px the
panel reserves its right side for the At a Glance rail (padding-right:420px,
portal.css). A symmetric negative margin would slide these white sections
under a position:fixed rail. The owner's law is about the left edge; the
right side already has a reason to be where it is.
MEASURED RESULT — node scripts/portal-format-shots.mjs, ── BAND LEFT EDGES:
before, 9 bands off the gutter at 1440 (six at exactly +64, .bsp-inner
drifting 146→274→354 as the window widened); after, every band on the
gutter at 1440 / 1280 / 1024 / 768 / 390, and horizontal overflow still 0
of 50 room×viewport combinations.
RE-MEASURE, DO NOT TRUST THIS COMMENT:
node scripts/portal-format-shots.mjs
node --test test/portal-left-edge.test.mjs
═══════════════════════════════════════════════════════════════════════════ */
/* (b) — the full-bleed surfaces. The section stops the page adding a gutter
outside it, and its interior supplies the same one inside. Both halves are
needed and both are stated in terms of --v10-gutter.
⚠ THE INTERIOR MUST BE THE TOKEN, NOT 64. This is what the first version of
this block got wrong, and only a multi-breakpoint measurement showed it: the
interiors are written `padding:52px 64px` in portal.css, a fixed 64 at every
width, while --v10-gutter steps 64 → 32 → 20 down the breakpoints. So
cancelling the outer gutter fixed 1440 and 1280 and left #conceptHero and
#creativeDirectionBanner at +32 on a small laptop and a tablet — a defect
that only exists between 641px and 1024px, which is exactly the band a
desktop-only check never visits. Stated once, in the token, it holds at every
width by construction.
!important on the interiors is required, not preferred: .item-card (:4019),
.items-sec-hdr (:4013) and .docs-ledger's siblings all declare their padding
!important in portal.css. */
body .tab-panel.active > .ds-hero,
body .tab-panel.active > .creative-direction-banner,
body .tab-panel.active > .items-section,
body .tab-panel.active > .docs-section,
body .tab-panel.active > #briefSubmittedPanel{
/* !important because .items-section declares `margin:0!important`
(portal.css:4012); without it the section keeps the page gutter AND its own
interior, which is the exact 2 × gutter this block exists to remove. */
margin-left:calc(-1 * var(--v10-gutter)) !important;
}
body .tab-panel.active .ds-hero-body,
body .tab-panel.active .cdl-card,
body .tab-panel.active .cdl-section-hdr,
body .tab-panel.active .items-sec-hdr,
body .tab-panel.active .item-card,
body .tab-panel.active .docs-ledger,
body .tab-panel.active .docs-section-hdr{
padding-left:var(--v10-gutter) !important;
}
/* ⚠ AND THE TWO THAT CENTRE THEMSELVES — the "changes everytime" half.
.bsp-inner is max-width:860px + margin:0 auto, and #homeTimelineCard and its
three siblings carry padding-left:max(64px, calc((100% - 732px)/2)). Both are
functions of the viewport, so their left edge MOVED while every other band
held still: measured 146px at 1024, 274px at 1280, 354px at 1440. They keep
their max-width — a measure cap is the right way to hold a line of prose to a
readable length — but they are anchored at the gutter instead of centred,
exactly as .nsc-inner was in §6 and .billing-container was in portal.css.
!important is required, not preferred: portal.css:4394 and :4398 declare both
with !important themselves, so an ordinary declaration loses at any
specificity.
⚠ .cdl-card IS HERE BECAUSE ITS ANCHORING LIVED IN THE MARKUP, NOT THE CSS.
portal.css:3327 still says `margin:0 auto`; what actually held it left was an
inline `style="margin-left:0;margin-right:auto"` on the div in
client-portal.html:3053. So the letter looked correct in the running portal
while the STYLESHEET said centre — and anyone deleting that inline attribute,
or rendering this card from a different template, would get the drifting
version back with nothing to catch it. Found by test/portal-left-edge.test.mjs,
which mounts the real nesting without the inline style and measured the card
at gutter+250 / +36 / +0 across the three widths. The rule now lives where
the law is. */
body .tab-panel.active .bsp-inner,
body .tab-panel.active .cdl-card{
margin-left:0 !important;
margin-right:auto !important;
}
body .tab-panel.active .bsp-hero,
body .tab-panel.active .bsp-status-bar,
body .tab-panel.active .bsp-readonly-bar,
body .tab-panel.active #homeTimelineCard{
padding-left:var(--v10-gutter) !important;
}
/* ── 9p · ON A PHONE THE HEADER IS TWO ROWS (2026-09-10, owner decision EVD-166, check 02-03) ──────
MEASURED on production's code signed in as the walkthrough client: at 320–430px the event switcher
and the Account menu (My Events · Billing · Help · Sign Out) sat PAST the right edge in Chrome,
WebKit and Firefox, and the Account menu again at 480–540px and 601–700px. Nothing scrolled
sideways — .portal-hdr clips — which is why every overflow gate stayed green; and
test/event-switcher-mobile.test.mjs measures the switcher ALONE in a fixture, never beside the
logo, the Stop messages control (§9A.1, on every width) and the bell.
Two rows rather than smaller controls: on top the logo · Stop messages · bell; below, the event
(it takes the room) · the Account menu. .hdr-meta becomes display:contents so its children place on
the header's own grid. Previewed at 320/360/390/430/480/540/600/700px: every control on screen, no
overlaps, both dropdowns open inside the screen; the header grows ~22px, so the phone bands of
--hdr-reserve (portal.css) are re-measured by test/portal-header-reserve.test.mjs.
701px and wider: untouched. */
@media (max-width:700px){
body .portal-hdr .hdr-top{grid-template-columns:minmax(0,1fr) auto auto;grid-template-areas:"logo stop bell" "event account account";column-gap:8px;row-gap:10px}
body .portal-hdr .hdr-logo{grid-area:logo;justify-self:start}
body .portal-hdr .hdr-meta{display:contents}
body .portal-hdr #hdrRef{display:none}
body .portal-hdr #portalCommsStop{grid-area:stop}
body .portal-hdr #inboxBell{grid-area:bell}
body .portal-hdr #hdrEventSwitcher{grid-area:event;min-width:0;justify-self:stretch}
body .portal-hdr #hdrEventSwitcher .hdr-event-chip{min-width:0;border-right:1px solid var(--v10-rule-edge, var(--border))}
body .portal-hdr #hdrEventSwitcher .hdr-event-name{max-width:none;min-width:0}
body .portal-hdr #hdrAccountSwitcher{grid-area:account;justify-self:end;min-width:0}
body .portal-hdr .hdr-client-chip{min-width:0}
body .portal-hdr .hdr-account-dropdown{left:auto;right:0}
body .portal-hdr #hdrEventSwitcher .hdr-event-dropdown{left:0;right:auto;min-width:min(260px, calc(100vw - 28px))}
}