/* The application's one global stylesheet, loaded from Pages/_Host.cshtml. ๐Ÿ”ด W13-11 ยท IT USED TO BE AN OVERRIDE SHEET AND IS NOW THE ONLY ONE. It was layered LAST over a third-party shell's own stylesheet so these rules would win; that shell, its sheet and the packages under it are gone, and nothing is beneath this file any more. Scope discipline is unchanged and still the point: the palette belongs in Theming/, emitted as --biztech-* custom properties by UiThemeTokens, and components belong in Components/Ui/. What is left here is only what CSS has to own - the two pieces of host-page chrome that live outside the Blazor component tree, and the validation styles Blazor's own form components reference by class name. */ /* ๐Ÿ”ด W8-25 ยท THE SCROLLBAR'S GUTTER IS RESERVED, AND A BROWSER MEASUREMENT IS WHY. Reported as "a noticeable jump when you switch tabs" on the agent launcher, and the tab strip turned out to have nothing to do with it. Measured on the running stack at 1536px: the Start tab's page is 735px and fits the viewport exactly; a work tab's is 852px and does not. So the scrollbar appears, `documentElement.clientWidth` drops 1536 โ†’ 1521, and every centred container re-centres inside the narrower box - the h1, the strip and the whole page slide 8px LEFT on the press, and back on the way out. This is not the launcher's defect and it is not fixable there: the scrollbar belongs to the DOCUMENT, so any page whose content crosses the viewport height does the same thing. `scrollbar-gutter: stable` reserves the space whether or not the bar is showing, which is what makes a page that grows stay still. ๐Ÿ”ด ON `html` AND NOT ON A COMPONENT, for the same reason: this is the element that scrolls. Overlay scrollbars (macOS, touch) take no space and are unaffected - the property reserves a gutter only where the platform paints a classic bar, so nothing changes on the platforms that never had the problem. */ /* ๐Ÿ”ด FROM sm UP, AND NOT ON A PHONE โ€” WHICH A VIEWPORT SUITE MEASURED RATHER THAN A PREFERENCE. A reserved gutter costs 15px of layout width whether or not a bar is painted. Above sm that is a fair price for a page that stays still; at 375px it is 15px of a 375px screen spent on a scrollbar the platform does not paint there โ€” iOS and Android both use overlay bars, so the jump this rule exists to stop cannot happen on a phone in the first place. Measured: ResourceLibraryViewportTests found the library's toolbar row 12px past the landmark at 375, because the landmark had become 360 while the row was still laid out for the width the page was authored at. R13.1's boundary, and the narrow end of it is where the gutter buys nothing. */ @media (min-width: 600px) { html { scrollbar-gutter: stable; } } /* โ”€โ”€ The layer scale ยท T29 N7 ยท guidelines ยง6 โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ R6.1: never write a raw z-index, use a layer. Before T29 this file held five bare numbers and the only way to know what any of them was competing with was to read the comment beside it. ๐Ÿ”ด DECLARED HERE, IN THIS FILE, and that is load-bearing rather than tidy. The circuit chrome below renders when NO COMPONENT HAS EMITTED A THEME - that is the whole condition it exists for - so it cannot read a custom property MudBlazor emits, for the same reason R3.1 exempts it from var() colours. A `:root` block in a static stylesheet has no such problem: it is applied by the browser from the file, with or without a live circuit. MudBlazor owns 1100-1600 and we do not enter it (R6.2): Drawer 1100, Popover 1200, AppBar 1300, Dialog 1400, Snackbar 1500, Tooltip 1600. Verified as rendered on 2026-08-05 by reading --mud-zindex-* off :root in the running app, which agrees with the reflection reading in ยง6. */ :root { /* In-flow content. Declared for completeness - nothing sets it, and nothing should need to. */ --biztech-layer-base: 0; /* Board column headings. 2 rather than 1 because .biztech-board-card:hover applies a transform, and a transformed element paints in the same layer as a positioned one - at 1 a hovered card would ride over the heading (R6.4). */ --biztech-layer-sticky: 2; /* The board's edge fades. */ --biztech-layer-scrim: 3; /* Controls that must sit above a scrim - the board's two scroll buttons. */ --biztech-layer-affordance: 4; /* ๐Ÿ”ด W0-59 ยท the navigation drawer as an OVERLAY, below sm only, and its own scrim. Two layers rather than reusing `scrim` and `affordance`, because those two are the BOARD's - the edge fades and the scroll buttons - and /board is precisely the page where the drawer overlays something. At 3 and 4 the drawer would open underneath the fades it is covering, and the scroll buttons would ride over the scrim. Above both of them and below `skip-link`, which is the ordering that matters: one Tab from a fresh load must reach the skip link even with the drawer open, or the first thing a keyboard user meets is painted under an overlay they did not ask for. */ --biztech-layer-drawer-scrim: 5; --biztech-layer-drawer: 6; /* ๐Ÿ”ด W0-65 ยท FINDING 1. THE BANNER, PINNED - AND THE ORDERING IS WHY THIS IS A TOKEN. ABOVE the drawer and its scrim, because below sm the drawer is `position: fixed` from --biztech-layer-drawer and inset below the app bar - so an overlay painted over the banner would cover the toggle that opened it, and an operator would have to guess their way out. BELOW skip-link for T29 N8's reason, unchanged: one Tab from a fresh load reaches the skip link even with the banner pinned over the page. 7 rather than reusing `drawer`: two elements at one layer paint in tree order, and the banner is EARLIER in the DOM than the drawer - so equal layers would put the overlay drawer on top of the banner, which is the ordering this token exists to refuse. ๐Ÿ”ด AND IT MAKES UiMenu.razor.css:9-11's CLAIM TRUE. That sheet already says its popover lives "inside the app bar's own stacking context", which was not so while the bar was unpositioned; a z-index here is what creates that context. Measured 2026-08-31: a sticky banner paints above a z-index: 2 sticky heading beneath it with or without a layer of its own, so this declaration is about the order being STATED rather than about today's geometry happening not to overlap. */ --biztech-layer-appbar: 7; /* W27-06 (plan D4, D19) ยท the snackbar host, above the console's app bar (7) and the portal's sticky header (2), so a toast is never under either. It also paints over the rail and the overlay drawer: a transient message that closes on a click is the accepted trade, and it reverses W0-68's first "Do not" by decision. Below the skip link, which must clear everything while it is focused. */ --biztech-layer-snackbar: 8; /* T29 N8 ยท the skip link, and it needs a layer of its own rather than `affordance`. It is only visible while focused, and at that moment it must clear Studio's app bar (1300) and anything MudBlazor has open above it - a tooltip at 1600 is the highest. A skip link painted under the chrome it skips is not one. Below the circuit chrome, which outranks everything (R6.3). */ --biztech-layer-skip-link: 1700; /* #blazor-error-ui. See the block below for why this is our value rather than MudBlazor's. */ --biztech-layer-circuit-error: 1900; /* The reconnect modal. โš ๏ธ NOT what renders: MudBlazor.min.css declares `#components-reconnect-modal { z-index: 9999 !important }`, which beats this whatever the source order (measured 2026-08-05). This is the floor for a missing MudBlazor stylesheet - exactly the degraded state this chrome exists for - and it keeps our own two circuit layers ordered correctly with respect to each other. */ --biztech-layer-circuit-lost: 2000; } /* โ”€โ”€ The focus ring, once ยท T29 N6 ยท R3.10 โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€ WCAG 2.1.1's other half: reaching a control by keyboard is worth nothing if you cannot see where you are. This used to live down in the board section, which made it look like a board rule; it is an application rule that the board happened to be the first to need. ๐Ÿ”ด THE SELECTOR LIST IS THE AUDIT. Every element in this application that is interactive and NOT a MudBlazor component has to appear here, because MudBlazor rings its own and nothing else will ring these. Today that list is exactly three, and adding a fourth custom interactive element without adding it here is the bug this consolidation exists to make obvious. :focus-visible, not :focus - a mouse click must not leave a ring behind on a board that is on screen in front of an audience. `outline`, not `box-shadow` - the card's hover rule already spends box-shadow, and an outline cannot be clipped by the column's overflow. The colour is safe by construction: Primary is a tested pair against both Background and Surface at 4.5:1, stricter than the 3:1 WCAG 1.4.11 asks of an indicator. ๐Ÿ”ด W0-52 ยท THE COLOUR MOVED FROM --mud-palette-primary TO --biztech-palette-primary, AND NOTHING ELSE IN THIS RULE CHANGED. It is the same value: both projections read BizTechPaletteDefaults, and BizTechCssVariablesTests asserts every role matches the record. What moves is WHO EMITS IT. --mud-palette-* is written at runtime by MudThemeProvider, which W0-53 unmounts; --biztech-* is written by Components/Ui/UiThemeTokens, mounted first in BOTH layouts, which survives it. Left on the MudBlazor token, this ring would resolve to nothing on the day that provider goes - and an outline with no colour is an outline nobody can see. Safe to move today because the token is emitted on every BizTech page already, and because AssigneeFormKeyboardTests reads this ring back from COMPUTED STYLE in a real browser: a token that failed to resolve fails that test rather than shipping. That test is also the one that proves this rule still beats MudBlazor's `button:focus{outline:none}`, which is (0,1,1) against this rule's (0,2,0) and stays linked on this document until W0-53. ๐Ÿ”ด W0-52 ADDS THE SEAM'S CONTROLS TO THE LIST, AND app.css IS WHERE THEY HAVE TO GO. A ring declared in a component's own scoped sheet would work - and would be the second declaration this rule exists to prevent, invisible to anyone auditing the list. Global rather than scoped is R14.1 layer 4's third case, stated as that rule asks: these classes are named by components, but the RULE is an application-wide one that no single component owns. They must also out-specify MudBlazor's `button:focus{outline:none}`, which is still linked on this document until W0-53. A class plus a pseudo-class is (0,2,0) against that rule's (0,1,1), which is the same margin by which .biztech-skip-link already wins in a real browser - measured under a real Tab keypress on 2026-08-11, and re-measured by UiGalleryKeyboardTests on every seam control. */ .biztech-board-card:focus-visible, /* the card - a real