h1:focus {
    outline: none;
}

.valid.modified:not([type=checkbox]) {
    outline: 1px solid var(--smme-success);
}

.invalid {
    outline: 1px solid var(--smme-error);
}

.validation-message {
    color: var(--smme-error);
}

.blazor-error-boundary {
    background: url(data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iNTYiIGhlaWdodD0iNDkiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMub3JnLzE5OTkveGxpbmsiIG92ZXJmbG93PSJoaWRkZW4iPjxkZWZzPjxjbGlwUGF0aCBpZD0iY2xpcDAiPjxyZWN0IHg9IjIzNSIgeT0iNTEiIHdpZHRoPSI1NiIgaGVpZ2h0PSI0OSIvPjwvY2xpcFBhdGg+PC9kZWZzPjxnIGNsaXAtcGF0aD0idXJsKCNjbGlwMCkiIHRyYW5zZm9ybT0idHJhbnNsYXRlKC0yMzUgLTUxKSI+PHBhdGggZD0iTTI2My41MDYgNTFDMjY0LjcxNyA1MSAyNjUuODEzIDUxLjQ4MzcgMjY2LjYwNiA1Mi4yNjU4TDI2Ny4wNTIgNTIuNzk4NyAyNjcuNTM5IDUzLjYyODMgMjkwLjE4NSA5Mi4xODMxIDI5MC41NDUgOTIuNzk1IDI5MC42NTYgOTIuOTk2QzI5MC44NzcgOTMuNTEzIDI5MSA5NC4wODE1IDI5MSA5NC42NzgyIDI5MSA5Ny4wNjUxIDI4OS4wMzggOTkgMjg2LjYxNyA5OUwyNDAuMzgzIDk5QzIzNy45NjMgOTkgMjM2IDk3LjA2NTEgMjM2IDk0LjY3ODIgMjM2IDk0LjM3OTkgMjM2LjAzMSA5NC4wODg2IDIzNi4wODkgOTMuODA3MkwyMzYuMzM4IDkzLjAxNjIgMjM2Ljg1OCA5Mi4xMzE0IDI1OS40NzMgNTMuNjI5NCAyNTkuOTYxIDUyLjc5ODUgMjYwLjQwNyA1Mi4yNjU4QzI2MS4yIDUxLjQ4MzcgMjYyLjI5NiA1MSAyNjMuNTA2IDUxWk0yNjMuNTg2IDY2LjAxODNDMjYwLjczNyA2Ni4wMTgzIDI1OS4zMTMgNjcuMTI0NSAyNTkuMzEzIDY5LjMzNyAyNTkuMzEzIDY5LjYxMDIgMjU5LjMzMiA2OS44NjA4IDI1OS4zNzEgNzAuMDg4N0wyNjEuNzk1IDg0LjAxNjEgMjY1LjM4IDg0LjAxNjEgMjY3LjgyMSA2OS43NDc1QzI2Ny44NiA2OS43MzA5IDI2Ny44NzkgNjkuNTg3NyAyNjcuODc5IDY5LjMxNzkgMjY3Ljg3OSA2Ny4xMTgyIDI2Ni40NDggNjYuMDE4MyAyNjMuNTg2IDY2LjAxODNaTTI2My41NzYgODYuMDU0N0MyNjEuMDQ5IDg2LjA1NDcgMjU5Ljc4NiA4Ny4zMDA1IDI1OS43ODYgODkuNzkyMSAyNTkuNzg2IDkyLjI4MzcgMjYxLjA0OSA5My41Mjk1IDI2My41NzYgOTMuNTI5NSAyNjYuMTE2IDkzLjUyOTUgMjY3LjM4NyA5Mi4yODM3IDI2Ny4zODcgODkuNzkyMSAyNjcuMzg3IDg3LjMwMDUgMjY2LjExNiA4Ni4wNTQ3IDI2My41NzYgODYuMDU0N1oiIGZpbGw9IiNGRkU1MDAiIGZpbGwtcnVsZT0iZXZlbm9kZCIvPjwvZz48L3N2Zz4=) no-repeat 1rem/1.8rem, var(--smme-error);
    padding: 1rem 1rem 1rem 3.7rem;
    color: white;
}

    .blazor-error-boundary::after {
        content: "An error has occurred."
    }

.darker-border-checkbox.form-check-input {
    border-color: var(--smme-control-border);
}

.form-floating > .form-control-plaintext::placeholder, .form-floating > .form-control::placeholder {
    color: var(--bs-secondary-color);
    text-align: end;
}

.form-floating > .form-control-plaintext:focus::placeholder, .form-floating > .form-control:focus::placeholder {
    text-align: start;
}

.mud-table-row.selected {
    background-color: var(--smme-brand-surface);
}

    .mud-table-row.selected:hover {
        background-color: var(--smme-brand-surface) !important;
    }


@media (min-width: 1200px) {
    .mud-main-content {
        padding-top: 0 !important;
    }
}
/* ---------------------------------------------------------------------------
   Responsive form grid (work item 1225)

   MudBlazor's own breakpoints (sm 600, md 960, lg 1280) do not line up with the
   portal's UI conventions, which are desktop >=1200, tablet 768-1199 and mobile
   <768. Using md="6" would have left the 768-959 band in a single column and
   sm="6" would have put two columns on a large phone. A plain CSS grid hits the
   documented numbers exactly, so the convention and the code agree.

   Children are laid out two-up from 768px. Add .smme-span-all to any field that
   should keep the full width at every breakpoint.
   --------------------------------------------------------------------------- */

.smme-form-grid {
    display: grid;
    grid-template-columns: 1fr;
    column-gap: 24px;
    row-gap: 20px;
    align-items: start;
}

@media (min-width: 768px) {
    .smme-form-grid {
        grid-template-columns: repeat(2, minmax(0, 1fr));
    }
}

.smme-form-grid > .smme-span-all {
    grid-column: 1 / -1;
}

/* The action row stacks below 768px so both buttons keep a full-width 44px+ target,
   and sits inline from 768px up where there is room for them side by side. */
.smme-form-actions {
    display: flex;
    flex-direction: column;
    gap: 12px;
}

@media (min-width: 768px) {
    .smme-form-actions {
        flex-direction: row;
    }

    .smme-form-actions > * {
        flex: 0 1 auto;
        min-width: 220px;
    }
}

/* Cards laid out side by side need equal height, so this opts out of the
   align-items: start the form grid uses to keep fields top-aligned. */
.smme-form-grid.smme-grid-stretch {
    align-items: stretch;
}

/* ---------------------------------------------------------------------------
   Navigation breakpoint (work item 1225)

   The conventions put 768-1199px in the drawer band and reserve the persistent
   side rail for 1200px and up. MudBlazor's d-md-none would have switched at
   960px, which is why the tablet band was showing a 240px rail. The drawer's
   own variant is driven from MainLayoutViewModel; these two rules cover the
   parts that are purely presentational.
   --------------------------------------------------------------------------- */

/* Compact app bar: tablet and mobile only. */
@media (min-width: 1200px) {
    .smme-appbar-compact {
        display: none !important;
    }
}

/* The drawer's own logo would duplicate the app bar's below 1200px — for a screen reader as
   well as visually, because the closed temporary drawer is moved off-screen by transform and
   its contents stay in the accessibility tree (work item 1237).

   This rule did not work when it was written. The element also carried MudBlazor's d-flex,
   which is display:flex !important — identical specificity, and MudBlazor.min.css is loaded
   after app.css, so source order won and the drawer logo rendered at every width. The class
   has been removed from the element rather than this rule escalated: whichever of the two
   selectors sets display, only one of them may. Do not put a d-* display utility back on it.

   Both logo images carry alt="SMMEPortal", which is only correct while these two rules keep
   them mutually exclusive. LogoAccessibilityTests fails if either stops doing so. */
.smme-drawer-logo {
    display: none !important;
}

@media (min-width: 1200px) {
    .smme-drawer-logo {
        display: flex !important;
    }
}

/* Desktop content offset for the persistent rail. The drawer is fixed-positioned
   and takes no space in flow, so the content has to be moved past it explicitly.
   Guarded by the media query as well as the class so a stale class from a
   prerendered desktop layout cannot indent a phone. */
@media (min-width: 1200px) {
    .mud-main-content.smme-main-offset {
        margin-left: 240px;
    }
}

/* THE TWO JOURNEY LAYOUTS STOOD HERE AND ARE GONE. Work item 1351, 22 September 2026.

   The dashboard drew the same four steps twice - a horizontal MudTimeline from 768px up and a stacked
   icon list below it - and these rules chose between them. The status tile grid (.smme-status-grid,
   below) replaces both, so the duplication is removed rather than restyled.

   Worth keeping from what stood here, because the reasoning still binds the grid that replaced it:
   four columns of status text at 375px is a table shrunk to a phone, which the UI conventions refuse.
   The grid answers that the same way, with a media query on the portal's real 768 and 1200 boundaries
   rather than MudBlazor's Breakpoint enum - whose bands are 600 / 960 / 1280 and hit neither of our
   numbers, and which work item 1225 records two failed attempts to go through, the second of which
   appeared to work and then overwrote correct state one render later. */

/* The journey card's header: a title on the left, a completion chip on the right, in one flex row.
   Below the portal's tablet boundary the chip took most of the width and squeezed the title to one
   word per line. Wrapping is the whole fix.

   flex-wrap is chosen because none of the MudBlazor utilities on this element sets it, so there is no
   utility to lose to - the rule the drawer logo broke on (work item 1237) is that a d-* utility and a
   project rule must never both want the same property. */
@media (max-width: 767px) {
    .smme-journey-header {
        flex-wrap: wrap;
        row-gap: 8px;
    }
}

/* ---------------------------------------------------------------------------
   BRAND PLACEMENT — work item 1234, Business Owner decisions of 9 September 2026

   Every number below is derived from the approved SVG geometry rather than chosen, and the
   derivation is written out because a bare pixel value gives the next person no way to tell a
   measured constant from a guess.

   His controlling rule of the same day: "Minimum display sizes refer to the width of the drawn
   lockup, not to the width of the image file. The approved SVG files carry clear space inside
   the canvas; that space is part of the required clear space and is not part of the measured
   size."

   THE GEOMETRY, measured from the checksummed files:

     ASSET-ICON-001   canvas 220 x 220   drawn 186 x 201.1   at x=10, y=6
     ASSET-LOGO-005   canvas 720 x 220   drawn 612.4 x 201.1 at x=10, y=6
     letter M in ASSET-LOGO-001                    71.1 canvas units tall

   Recording those here is safe for a reason that does not generalise: the files are registered
   by SHA-256 and BrandAssetIntegrityTests re-verifies every one against the issued manifest on
   each build, so the geometry cannot change without the build failing first.
   --------------------------------------------------------------------------- */

/* App bar: the standalone symbol at a drawn width of 40px.

   186 / 220 = 0.8455 of the canvas is drawn, so a 47.31px box renders a 40.0px mark - well above
   the symbol's own 32px minimum, and it fits the 57px bar with room on both sides.

   margin-left is 8px and is NOT the register's clear space. The register prescribes clear space
   "around every logo lock-up"; the standalone symbol is a mark rather than a lock-up and no value
   is prescribed for it. Raised with the Business Owner rather than derived here, because the
   nearest derivation - the M-height proportion of the master, 0.354 of the mark's height - would
   need about 74px of vertical room in a 57px bar, and inventing a smaller one to make it fit
   would be exactly the unrecorded change he asked not to see. */
.smme-appbar-symbol {
    width: 47.31px;
    height: auto;
    margin-left: 8px;
    flex: none;
}

/* Drawer: ASSET-LOGO-005 at a drawn width of 180.3px, clearing the controlled 180px minimum.

   612.4 / 720 = 0.8506 of the canvas is drawn, so a 212px box renders a 180.3px lock-up.
   At that scale one canvas unit is 212/720 = 0.29444px, so the required clear space - the height
   of the letter M - is 71.1 x 0.29444 = 20.9px on every side.

   The canvas already carries part of it, and asymmetrically:

     left    10 units  =  2.9px  ->  18px needed outside   (padding-left)
     right   97.6      = 28.7px  ->  none needed           (already exceeds 20.9)
     top      6        =  1.8px  ->  20px needed outside   (padding-top)
     bottom  12.9      =  3.8px  ->  18px needed outside   (padding-bottom)

   18 + 212 = 230px inside a 240px drawer, so it fits with 10px to spare and the drawer does not
   have to grow - which is what the Business Owner asked for. */
.smme-drawer-logo {
    padding: 20px 0 18px 18px;
}

.smme-drawer-logo-mark {
    width: 212px;
    height: auto;
    display: block;
}

/* The print lock-up is hidden on screen. It is the only brand mark on paper. */
.smme-print-lockup {
    display: none;
}

/* ---------------------------------------------------------------------------
   PRINT — the first print-specific rule in the application, and it exists because there were
   none. Business Owner decision of 9 September 2026:

     "I do not want print behaviour to remain an accidental consequence of whichever responsive
      app-bar placement happens to reach paper. For print, use the approved horizontal lockup
      and size it so that the DRAWN LOCKUP is at least 35 mm wide, excluding the clear space
      carried inside the asset canvas."

   Before this, a printed page carried whatever the responsive layout put in the app bar. A4
   portrait lays out at 794 CSS px and A4 landscape at 1123, both below the 1200px threshold at
   which the drawer's lock-up appears - so paper always got the app bar's mark, and it measured
   25.1mm drawn against a 35mm minimum.

   55mm IS A MEASURED VALUE, NOT A CALCULATED ONE, AND THAT DISTINCTION MATTERS.

   The arithmetic says otherwise: 612.4 of ASSET-LOGO-001's 720 canvas units are drawn, so a
   41.15mm box should print a 35.0mm lock-up. It does not. Printed and measured off the sheet,
   41.15mm produced 30.31mm - about 87% of the intended size - because a CSS millimetre in print
   is not a physical millimetre. The browser lays the page out at 96dpi against the paper width
   and then fits that layout into the printable area inside the page margins, so the whole page,
   this element included, is scaled down by whatever those margins take.

   So the value was calibrated instead of derived, and re-measured at each step:

     declared 41.15mm  ->  30.31mm drawn   below the minimum
     declared 50mm     ->  37.43mm drawn   compliant, 7% headroom
     declared 55mm     ->  41.32mm drawn   compliant, 18% headroom   <- shipped

   THE HEADROOM IS THE POINT. A participant who prints at a reduced scale, or with wider margins
   than the browser's default, shrinks this further - and no CSS can prevent that, because the
   physical size of the printed page is decided in the print dialog rather than in the stylesheet.
   18% covers ordinary variation. It does not make 35mm a guarantee, and the Business Owner has
   been told so rather than left to assume it.

   THE PADDING IS SCALED BY THE SAME FACTOR, which is easy to miss and was missed once here. A
   declared 3.6mm of padding does not put 3.6mm on the paper either; it renders at about 88% like
   everything else, so the clear space has to be calculated at the rendered scale and then divided
   back out before it is declared.

   At the shipped size the image box renders 48.6mm wide, so one canvas unit is 0.0675mm and the
   letter M's 71.1 units are 4.80mm - that is the clear space the register requires on every side.
   The canvas carries 0.67mm of it on the left, 6.59mm on the right (already more than enough),
   0.40mm above and 0.87mm below. The declared padding supplies the remainder, grossed up for the
   print scale and rounded up rather than down.
   --------------------------------------------------------------------------- */
@media print {
    .smme-appbar-symbol {
        display: none;
    }

    .smme-print-lockup {
        display: block;
        width: 55mm;
        height: auto;
        padding: 5.1mm 0 4.6mm 4.8mm;
        flex: none;
    }

    /* Deterministic rather than incidental. The drawer is already hidden below 1200px and no
       ordinary paper reaches that width, but leaving the printed mark to depend on paper size is
       the accident this rule was asked to remove. */
    .smme-drawer-logo {
        display: none !important;
    }
}

/* ---------------------------------------------------------------------------
   BRAND NAVY DRAWER — work item 1234 (option C) and 1296 (the focus defect)

   Business Owner decision of 9 September 2026. THESE RULES AND THE SURFACE ARE ONE CHANGE.
   His words: "The drawer change is approved only as the complete measured treatment. It must
   not be implemented with the previous selected, caption or hover values."

   Turning the surface navy on its own put two regressions on a participant's screen. Measured
   in the running product against #163F8C, with the white figure beside it so a regression can
   be told from a defect that was already there:

     selected link text   PortalBlue        1.50  (was 6.58 on white)  needs 4.50  REGRESSION
     group captions       TextSecondary     1.94  (was 5.10 on white)  needs 4.50  REGRESSION
     selected tint        black at 6%       1.06  (was 1.14 on white)  needs 3.00  already failing
     hover                black at 6%       1.06  (was 1.14 on white)  needs 3.00  already failing
     focus indicator      black at 6%       1.06  (was 1.14 on white)  needs 3.00  already failing
     disabled             black at 38%      1.46  (was 2.65 on white)  exempt      unchanged
     normal text, icons   white             9.89                       needs 4.50  pass

   Every replacement below uses a token already in the palette. None introduces a new colour.
   --------------------------------------------------------------------------- */

/* THE SELECTED ITEM. MudBlazor paints it with the theme's primary, which is PortalBlue - so on
   navy the page a participant is currently on becomes the least readable thing on the screen.

   White text plus a Logo Orange leading edge. Orange on navy measures 3.66:1, clearing the 3.00
   a graphical indicator needs, and the 4 September semantic model already gives orange the
   selected-state role: "orange is progress, active state and next action". So this is the
   approved colour doing the job it was approved for rather than a new one chosen to pass.

   THE BAR IS AN INSET SHADOW, NOT A BORDER, and that is deliberate. A 4px border would shift the
   label 4px when an item became selected, so the whole menu would twitch on every navigation.
   An inset shadow paints the same 4px band and moves nothing.

   Colour is not the sole carrier: the bar is position and shape as well, which is the standing
   rule from 4 September. Selecting by colour alone is what this replaces.

   THE SELECTOR CARRIES .mud-navmenu-default DELIBERATELY, AND THE FIRST ATTEMPT WITHOUT IT FAILED
   SILENTLY IN A WAY WORTH RECORDING.

   MudBlazor's rule is:

     .mud-navmenu.mud-navmenu-default .mud-nav-link.active:not(.mud-nav-link-disabled)

   which is five classes. A rule reading `.mud-drawer .mud-navmenu .mud-nav-link.active:not(...)`
   is also five classes - equal specificity - and MudBlazor.min.css loads AFTER app.css, so source
   order decided it and MudBlazor won. The box-shadow still applied, because nothing competes for
   box-shadow, so the orange bar appeared and the selected item stayed PortalBlue at 1.60:1. A
   half-applied rule that looks like it worked.

   That is the trap this codebase already records against a d-flex utility under work item 1237,
   arriving from the other direction: not a utility on our element, but a component rule we cannot
   remove from markup. So the documented fix - take the competing class off the element - is not
   available, and matching their variant class explicitly is the honest alternative. It is not an
   arms race: it names the same variant their rule names, plus the surface the decision is about.

   Found by measuring the rendered result rather than by reading the stylesheet, which is the only
   place it was visible - exactly as work item 1237 records. */
.mud-drawer .mud-navmenu.mud-navmenu-default .mud-nav-link.active:not(.mud-nav-link-disabled) {
    color: var(--smme-surface-raised);
    background-color: rgba(255, 255, 255, 0.12);
    box-shadow: inset 4px 0 0 0 var(--smme-logo-orange);
}

.mud-drawer .mud-navmenu.mud-navmenu-default .mud-nav-link.active:not(.mud-nav-link-disabled) .mud-nav-link-icon {
    color: var(--smme-surface-raised);
}

/* THE GROUP CAPTIONS. White at 70% measures 5.71:1, clearing 4.50, and keeps them quieter than
   the links they head. Plain white passes at 9.89 and would make a caption louder than the item
   beneath it, which inverts the hierarchy the captions exist to create.

   These elements carried MudBlazor's mud-text-secondary until this change. The class was removed
   from the markup rather than overridden here - a d-* or mud-* utility and a project rule must
   never both want the same property, which is the trap work item 1237 recorded and 1225 lost to
   silently. Whichever selector sets the colour, only one of them may. */
.smme-nav-caption {
    color: rgba(255, 255, 255, 0.7);
}

/* CAPTION SIZE. 14px, from MudBlazor's 12px caption. The Business Owner's walkthrough of
   10 September 2026: the explanatory text in the drawer "feels too small", and he approved a
   central adjustment on 11 September with re-measurement under DOC-114 section 9.5.

   The re-measurement is recorded here because it is short. The colour is unchanged, so the ratio
   is unchanged - 5.71:1 on Brand Navy - and 14px is still normal-size text under WCAG, so the
   threshold is unchanged at 4.50. Nothing moved; it was checked rather than assumed.

   TWO CLASSES ON PURPOSE. MudBlazor.min.css loads after this file, and .mud-typography-caption
   sets font-size from a theme variable. A single-class rule here would tie on specificity and
   lose on source order, and nothing would say so - the same silence that hid the drawer-logo
   rule under work item 1237. One extra ancestor is ordinary specificity, not an arms race, and
   the drawer's <nav> is the honest scope: this is about the navigation and nothing else. */
.mud-navmenu .smme-nav-caption {
    font-size: 0.875rem;
}

/* THE NOT-AVAILABLE MARKER sits on its own line under the link label. Inline, at 14px in a
   240px drawer, it wrapped mid-phrase - "Financial Basics Not" then "available yet" - which
   read as overflow rather than as a state. A block on its own line reads as what it is.

   No ml-2 on the element. That is a MudBlazor spacing utility, it is !important, and it would
   fight any margin set here; the markup dropped it rather than this rule out-shouting it. */
.mud-navmenu .mud-nav-link-text .smme-nav-caption {
    display: block;
    line-height: 1.4;
}

/* FIELD HELPER TEXT. 14px, from MudBlazor's hardcoded 12px, on the same request. The colour is
   TextSecondary, already measured against every content surface by ThemeTokenTests, and 14px is
   still normal-size text - so the ratio and the threshold are both unchanged. Two classes for
   the same reason as above: MudBlazor sets .75rem on .mud-input-helper-text and loads last. */
.mud-input-control .mud-input-helper-text {
    font-size: 0.875rem;
}

/* A QUESTION ABOVE ITS SELECT (F40, work item 1342). The registration and compliance questions
   are approved sentences of up to 83 characters, and an outlined select's floating label is one
   line with an ellipsis, so the longest read "Are sector-specific licences, permits or regist..."
   The question is a real <label> above the control instead, free to wrap, joined to the select's
   input by for/id so it is still the field's accessible name.

   The asterisk is drawn the way MudBlazor draws its own - content "*" in ::after on the label -
   so the page's required note describes this marker exactly as it describes the others. TextPrimary
   because the question is the field's label and not supporting text; measured against every
   content surface by ThemeTokenTests. The select is capped on wide screens: a full-row control for
   a Yes / No answer reads as a text field waiting to be typed into. */
.smme-question-label {
    display: block;
    margin-bottom: 6px;
    font-size: 0.875rem;
    line-height: 1.45;
    color: var(--smme-text-primary);
}

.smme-question-required::after {
    content: "*";
}

@media (min-width: 768px) {
    .smme-question-select {
        max-width: 28rem;
    }
}

/* HOVER. Black at 6% over navy is 1.06:1 - imperceptible. White at 20% is 1.72:1 against the
   drawer: visible, where the current value is not.

   Not claimed as compliant. A hover state is not an information-carrying indicator under
   WCAG 1.4.11, so 3.00 does not apply to it; the honest statement is that it becomes visible. */
.mud-drawer .mud-navmenu.mud-navmenu-default .mud-nav-link:hover:not(.mud-nav-link-disabled):not(.active) {
    background-color: rgba(255, 255, 255, 0.2);
}

/* THE FOCUS INDICATOR — work item 1296, and this one was a live defect before the drawer moved.

   MudBlazor's only focus rule for a nav link sets a background tint and no outline at all;
   outline-style computes to none. On the white drawer that tint measured 1.14:1, which fails
   WCAG 2.2 2.4.7 Focus Visible and 1.4.11 today, not as a consequence of anything decided here.
   A participant navigating by keyboard could not see where they were.

   2px white at a 2px offset measures 9.89:1 against the drawer. An outline rather than a
   background, so it survives a later surface-colour change - which is exactly what caught the
   previous treatment out. */
.mud-drawer .mud-navmenu.mud-navmenu-default .mud-nav-link:focus-visible {
    outline: 2px solid var(--smme-surface-raised);
    outline-offset: -2px;
    background-color: rgba(255, 255, 255, 0.2);
}

/* THE OFFSET IS NEGATIVE, AND THE MEASUREMENT DOES NOT SAY IT HAD TO BE.

   The reasoning when this was written was that the nav list scrolls - its container carries
   overflow-y: auto, which clips horizontally too - so a positive offset would put the ring
   outside the link's box and have its left and right edges cut off. Measured with focus actually
   on a link, that is not what happens today: the link runs x=8 to x=232 inside a container
   spanning 0 to 240, so a +2px ring would sit at 6 to 234 and fit.

   It stays negative anyway, for a reason that survives being measured rather than the one that
   did not. Those 8px are MudBlazor's own margin on a nav link, not a value this project sets, and
   an indicator that depends on someone else's margin staying where it is will eventually be
   clipped by a version bump nobody connected to it. Drawn inside the box it cannot be, whatever
   the margin does. It also keeps the ring within the item's bounds, so it reads as part of the
   item rather than floating around it.

   Verified by keyboard against the navy drawer - Tab to the first nav link, then read the
   computed outline and :focus-visible state - because "is it clipped" is not a question the
   stylesheet can answer. */

/* The anonymous drawer's Log In button. Colour removed from the component and set here, so the
   button has one source for its colour rather than a Color parameter and a rule competing.

   White label and white border on Brand Navy: 9.89:1 for both, against 4.50 for the label and
   3.00 for the border as a control boundary. It was PortalBlue at 1.50:1 for both, which is the
   selected-link regression appearing in a state the Business Owner's list did not name. */
.smme-drawer-login.mud-button-outlined {
    color: var(--smme-surface-raised);
    border-color: var(--smme-surface-raised);
}

.smme-drawer-login.mud-button-outlined:hover {
    background-color: rgba(255, 255, 255, 0.12);
    border-color: var(--smme-surface-raised);
}

/* DISABLED NAVIGATION ITEMS. MudBlazor paints them with --mud-palette-text-disabled, which is
   black at 38%. On a white drawer that reads as grey; on Brand Navy it is DARKER THAN THE
   SURFACE, so a disabled item stops looking like quiet text and starts looking like a hole
   punched in the menu. Measured at 1.46:1 against the drawer.

   White at 50% measures 3.70:1 and puts the three states in the right order:

     normal link      white          9.89
     group caption    white at 70%   5.71
     disabled link    white at 50%   3.70

   NOT A CONFORMANCE FIX. WCAG 1.4.3 exempts text in an inactive control, so 1.46:1 was not a
   failure and the Business Owner had said the disabled state "may remain unchanged for this
   release". It is changed because it looked wrong on the new surface once there was a new
   surface to look at, and because two items are disabled in the pre-business state rather than
   the one previously reported to him - /canvas and /tasks together. Reported as a change made,
   with the ratio, and reversible on his word.

   DONE BY REDEFINING THE TOKEN RATHER THAN OVERRIDING THE RULE, and that is the point worth
   keeping. MudBlazor's disabled rule carries !important:

     .mud-nav-link.mud-nav-link-disabled { color: var(--mud-palette-text-disabled) !important }

   so beating it with a selector means matching !important with !important and winning on
   specificity - an arms race with a library, which this codebase has already lost once and
   written down. Redefining the variable inside the drawer means their rule resolves to our value
   and there is no contest at all. It reaches the icon for free, because the icon rule reads the
   same variable. */
.mud-drawer {
    --mud-palette-text-disabled: rgba(255, 255, 255, 0.5);

    /* F32, work item 1315. A scroll that reaches the end of the menu must not chain to the page
       behind the drawer. On a phone that chained scroll hides and shows the address bar, the
       fixed-position drawer resizes with the viewport, and the account block pinned to its bottom
       edge jumps. MainLayout also locks the body while an overlay drawer is open; this is the half
       that works on browsers where overflow:hidden on the body does not stop a touch scroll.
       MudBlazor sets no overscroll-behavior on the drawer, so one class is enough and nothing is
       being out-specified. */
    overscroll-behavior: contain;
}

/* ---------------------------------------------------------------------------
   NEW-LOOK PHASE 1 PORTAL - SHARED PRIMITIVES
   Design brief of 19 September 2026, accepted design direction. Spec at
   docs/superpowers/specs/2026-09-22-new-look-phase-1-portal-design.md.

   Stage 1 of five: presentation only. Nothing here decides a status, a
   percentage, an availability or a next action - all of that stays server-side
   in the view model, which is the standing rule for this project.

   EVERY COLOUR IS A TOKEN. PortalPalette emits these custom properties into the
   document head and is the single definition of each value; a hex literal in
   this file is what NoColourLiteralRemainsOutsideThePalette exists to catch.

   NO MUDBLAZOR UTILITY MAY SET A PROPERTY THESE RULES CONTROL. Its d-*,
   justify-* and spacing utilities carry !important, MudBlazor.min.css loads
   after this file, and at equal specificity source order decides - so the
   utility wins silently and the rule here simply does not apply. That is work
   item 1225, found only by measuring computed style in a running application
   under 1237. Where one of these primitives is used, the element carries it
   instead of a utility for the same property, never as well as. */

/* PANEL. The single card surface, replacing the ad hoc MudCard elevation and
   padding combinations on the dashboard. The brief asks for one consistent
   panel, and twelve cards each carrying their own spacing is what that
   replaces.

   A 1px border rather than an elevation shadow, because the page surface is
   SurfacePage and a raised white card on near-white needs an edge to read as an
   edge at all. */
.smme-panel {
    background-color: var(--smme-surface-raised);
    border: 1px solid color-mix(in srgb, var(--smme-control-border) 25%, var(--smme-surface-raised));
    border-radius: 12px;
    padding: 21px;
}

/* HERO. The recommended next step, and the only navy panel on the page. The
   orange left border is the accent and indicator role the 4 September semantic
   model gives orange, carried by a graphical edge rather than by text.

   Text on this surface is white at 9.89. Orange measures 3.66 against Brand
   Navy, which clears AA's 3.00 for large text and fails the 4.50 that normal
   text needs - so .smme-hero-heading-action exists at 19px/700 and nothing
   smaller may take that colour. */
/* THE COLOUR IS SET TWICE, AND THE SECOND WAY IS THE ONE THAT WORKS ON A MudCard.

   Found by measuring computed style in the running application, which is the only
   place it was visible: the hero rendered WHITE with #333 text while this rule said
   navy. .mud-paper sets background-color and color, both files use a single class
   selector, and MudBlazor.min.css loads after app.css - so specificity ties and
   source order decides it. The rule below was present and simply did not apply.
   Exactly the failure work item 1225 wrote down and 1237 had to measure to find.

   Fixed by redefining MudBlazor's variables inside this element rather than
   out-specifying its rule, which is the pattern .mud-drawer already uses for
   --mud-palette-text-disabled. Their rule then resolves to our values and there is
   no contest: no !important, no arms race, and it reaches every descendant that
   reads the same variable - which is how the MudText inside the hero turns white.

   The plain declarations stay because they are what applies when .smme-hero is used
   on something that is not a MudBlazor surface. Both are needed; neither is
   redundant. Any nested mud-paper would inherit the redefined surface, and there is
   none inside the hero today - a card within the hero would need its own value. */
.smme-hero {
    --mud-palette-surface: var(--smme-brand-navy);
    --mud-palette-text-primary: var(--smme-surface-raised);

    background-color: var(--smme-brand-navy);
    border: 0;
    border-left: 4px solid var(--smme-logo-orange);
    border-radius: 12px;
    color: var(--smme-surface-raised);
    padding: 23px;
}

/* THE CAPITALS ARE A TREATMENT, NOT THE APPROVED TEXT. The register holds "Your
   Business Buddy" in sentence case and this uppercases it, rather than the constant
   storing capitals: a screen reader given literal capitals may spell them out, and the
   register would then hold a string nobody would approve if they read it aloud. */
.smme-hero .smme-eyebrow {
    align-items: center;
    display: flex;
    font-size: 13px;
    font-weight: 650;
    gap: 9px;
    letter-spacing: 0.03em;
    text-transform: uppercase;
}

/* THE HERO'S ACTION ROW. The primary action, its time text, and the Buddy link.
   Wraps rather than shrinking: at 320px a white filled button and a text button
   side by side would each fall under the 44px target, and the conventions put a
   one-column priority flow ahead of keeping a row intact. */
.smme-hero-actions {
    align-items: center;
    display: flex;
    flex-wrap: wrap;
    gap: 12px;
    margin-top: 8px;
}

/* The Buddy link. White on navy is 9.89, so it reads as an action without
   competing with the filled primary beside it - the brief asks for "a solid
   PortalBlue action button and a secondary Buddy link", and on this surface the
   secondary treatment is the absence of a fill rather than a second colour. */
.smme-hero .smme-hero-link {
    color: var(--smme-surface-raised);
    font-weight: 600;
    min-height: 44px;
    text-decoration: underline;
    text-underline-offset: 4px;
}

/* "WHY THIS MATTERS" AS A DISCLOSURE rather than an always-open block, which is
   what the accepted design does with it.

   The marker is left alone: a native <details> is keyboard reachable, announced
   as expandable and remembers nothing, all of which a hand-built accordion has
   to re-earn. Only the summary's affordance is styled. */
.smme-hero-why {
    border-top: 1px solid rgba(255, 255, 255, 0.3);
    margin-top: 18px;
    padding-top: 12px;
}

.smme-hero-why > summary {
    cursor: pointer;
    font-size: 14px;
    font-weight: 600;
    min-height: 44px;
    padding: 10px 0;
}

.smme-hero-why > summary:focus-visible {
    outline: 3px solid var(--smme-surface-raised);
    outline-offset: 3px;
}

/* YOUR BUSINESS BUDDY. An orange top edge, which is the accent and indicator role
   the 4 September semantic model gives orange - a graphical edge, never a label. */
.smme-buddy {
    border-top: 4px solid var(--smme-logo-orange);
}

.smme-buddy-choices {
    display: flex;
    flex-wrap: wrap;
    gap: 9px;
    margin: 15px 0;
}

.smme-buddy-topic {
    min-height: 44px;
}

.smme-buddy-answer {
    background-color: var(--smme-surface-subtle);
    border-radius: 8px;
    font-size: 14px;
    padding: 14px;
}

/* Large text, deliberately. 19px at 700 clears WCAG's 18.66px bold threshold,
   which is what makes 3.66 a pass rather than a failure. Reducing either the
   size or the weight changes the conformance answer, so both are stated here
   rather than left to a utility class to decide. */
.smme-hero .smme-hero-heading-action {
    color: var(--smme-logo-orange);
    font-size: 19px;
    font-weight: 700;
    line-height: 1.45;
}

/* PROGRESS TRACK. Carries the governed journey measure - x of n currently
   available tracked steps, held steps excluded from the denominator - and never
   a bare percentage. The figure beside it names its own scope, for the reason
   the Business Owner gave on 4 September: a number beside the word "journey"
   claims a great deal more than it knows.

   Navy fill rather than orange. Orange on SurfaceSubtle measures 2.06, and a
   graphical object carrying information needs 3.00, so the accent role does not
   reach a progress fill on a light track. */
.smme-track {
    background-color: var(--smme-surface-subtle);
    border: 0;
    border-radius: 3px;
    height: 5px;
    margin-top: 16px;
    overflow: hidden;
}

.smme-track > div {
    background-color: var(--smme-brand-navy);
    height: 100%;
}

/* STATUS TILES. Four areas, replacing the journey timeline and the separate
   narrow icon list beneath it - one grid instead of the same list drawn twice.

   The columns follow the portal's own 1200/768 boundaries, not MudBlazor's
   600/960/1280 and not the mockup's 850/580. Mobile stays a one-column priority
   flow per the UI conventions: two 145px tiles at 320px is a table shrunk to a
   phone, which is the thing those conventions refuse, and 320px is one of the
   brief's own named pass conditions. */
.smme-status-grid {
    display: grid;
    gap: 12px;
    grid-template-columns: minmax(0, 1fr);
    margin-top: 18px;
}

@media (min-width: 768px) {
    .smme-status-grid {
        grid-template-columns: repeat(2, minmax(0, 1fr));
    }
}

@media (min-width: 1200px) {
    .smme-status-grid {
        grid-template-columns: repeat(4, minmax(0, 1fr));
    }
}

/* State is never carried by colour alone. Every tile renders an icon and a
   state word as well, so a participant who cannot distinguish the colour still
   reads the state. Standing rule, not a correction to these screens. */
.smme-status-tile {
    background-color: var(--smme-surface-subtle);
    border-radius: 8px;
    font-size: 14px;
    min-height: 44px;
    padding: 15px 12px;
}

.smme-status-tile strong {
    display: block;
    font-weight: 600;
    margin: 10px 0 4px;
}

.smme-status-tile span {
    color: var(--smme-text-secondary);
    font-size: 14px;
}

/* The interactive variant. An anchor rather than a button, because every tile
   navigates - including a held one, which resolves to the page explaining why
   it is not available (Business Owner Decision 8 of 13 September 2026). A real
   element either way, so it is reachable and announced without a role attribute
   doing that work.

   The tile IS the link, so the step's name inside it must not be a second
   anchor - JourneyStepContent takes NameAsLink="false" here. Nested anchors are
   invalid and the inner one wins the click. */
a.smme-status-tile,
button.smme-status-tile {
    border: 0;
    cursor: pointer;
    display: block;
    text-align: left;
    text-decoration: none;
    width: 100%;
}

a.smme-status-tile:hover,
button.smme-status-tile:hover {
    background-color: var(--smme-surface-raised);
    box-shadow: inset 0 0 0 1px var(--smme-portal-blue);
}

a.smme-status-tile:focus-visible,
button.smme-status-tile:focus-visible {
    outline: 3px solid var(--smme-portal-blue);
    outline-offset: 3px;
}

/* The step's name. PortalBlue at 6.58 on the tile's SurfaceSubtle ground, and it
   is the only blue on the tile - the status word beneath keeps its semantic
   colour, which is what tells the states apart. */
.smme-status-tile .smme-status-name {
    color: var(--smme-portal-blue);
    display: block;
    font-weight: 600;
    margin: 10px 0 4px;
}

/* BUSINESS MODEL AT A GLANCE. Nine cells, and the column count follows the
   CARD's width rather than the viewport's - three above roughly 700px, two
   below, one on a narrow phone, exactly as the brief puts it.

   A container query rather than a media query, and that is the point: the
   viewport width says nothing useful about how wide the card actually is. It
   also keeps this component out of the 1200/768 question entirely. Since the
   Business Owner's correction of 26 September 2026 (work item 1384) the card
   has a row of its own, so a desktop reaches the three-column tier. */
.smme-model-panel {
    container-name: smme-model;
    container-type: inline-size;
}

.smme-model-grid {
    display: grid;
    gap: 9px;
    grid-template-columns: minmax(0, 1fr);
    margin: 15px 0;
}

@container smme-model (min-width: 420px) {
    .smme-model-grid {
        grid-template-columns: repeat(2, minmax(0, 1fr));
    }
}

@container smme-model (min-width: 700px) {
    .smme-model-grid {
        grid-template-columns: repeat(3, minmax(0, 1fr));
    }
}

/* NEVER SPLIT ORDINARY WORDS. The brief says so in those terms and makes it a
   pass condition at 320px. Stated explicitly because the obvious fix for a cell
   that overflows is overflow-wrap:anywhere, which breaks words mid-syllable -
   the mockup's own base rule did exactly that and had to be overridden. A long
   unbroken string still has to go somewhere, so the cell scrolls rather than
   the page. */
.smme-model-cell {
    background-color: var(--smme-surface-subtle);
    border-radius: 6px;
    font-size: 13px;
    hyphens: none;
    overflow-wrap: normal;
    overflow-x: auto;
    padding: 12px;
    word-break: normal;
}

.smme-model-cell strong {
    color: var(--smme-portal-blue);
    display: block;
    font-size: 13px;
    margin-bottom: 5px;
}

/* TAG. A small state label beside a panel heading. Rendered as complete only
   for a confirmed completed model, per the brief - a draft that happens to have
   every box filled is not a completion, and DF-PROF-001 is the reason the two
   are different things. */
.smme-tag {
    background-color: var(--smme-surface-subtle);
    border-radius: 5px;
    color: var(--smme-text-secondary);
    display: inline-block;
    font-size: 12px;
    padding: 3px 9px;
}

.smme-tag.smme-tag-complete {
    color: var(--smme-success);
}

/* ---------------------------------------------------------------------------
   PAGE HEADING, TABS, SECTIONS, RECORDS AND THE SAVE BAR (work item 1381)

   Option 1 of the layout canvas, approved by the Business Owner on 25 September
   2026: the heading on the page rather than inside a card, the dashboard's light
   panel for every section, tabs between related pages, and the save buttons in
   a bar that stays in view. Breakpoints are the portal's own - 768 and 1200 -
   written as media queries on the real numbers (work item 1225).
   --------------------------------------------------------------------------- */

.smme-page-header {
    align-items: flex-end;
    display: flex;
    flex-wrap: wrap;
    gap: 12px 24px;
    justify-content: space-between;
    margin-bottom: 20px;
}

.smme-page-eyebrow {
    color: var(--smme-text-secondary);
    font-size: 12px;
    font-weight: 500;
    letter-spacing: 1px;
    margin: 0 0 6px;
    text-transform: uppercase;
}

.smme-page-title {
    color: var(--smme-brand-navy);
    font-size: 26px;
    font-weight: 800;
    line-height: 1.2;
    margin: 0;
}

.smme-page-subtitle {
    color: var(--smme-text-secondary);
    font-size: 15px;
    margin: 6px 0 0;
    max-width: 70ch;
}

@media (min-width: 768px) {
    .smme-page-title {
        font-size: 32px;
    }
}

/* TABS. The lit tab is navy and bold with an orange bar beneath it: orange is the
   active-state indicator of the 4 September semantic model, and it never sits
   behind a label. Three signals, so the lit tab survives without colour. */
.smme-tabs {
    border-bottom: 1px solid var(--smme-border);
    margin-bottom: 24px;
}

.smme-tabs-scroller {
    display: flex;
    gap: 4px;
    overflow-x: auto;
    scrollbar-width: none;
}

.smme-tabs-scroller::-webkit-scrollbar {
    display: none;
}

.smme-tab {
    align-items: center;
    border-bottom: 3px solid transparent;
    color: var(--smme-text-secondary);
    display: flex;
    flex-shrink: 0;
    font-size: 15px;
    font-weight: 500;
    min-height: 46px;
    padding: 0 12px;
    text-decoration: none;
    white-space: nowrap;
}

.smme-tab:hover {
    color: var(--smme-brand-navy);
}

.smme-tab:focus-visible {
    outline: 2px solid var(--smme-portal-blue);
    outline-offset: -2px;
}

.smme-tab.smme-tab-active {
    border-bottom-color: var(--smme-logo-orange);
    color: var(--smme-brand-navy);
    font-weight: 700;
}

/* A STATE IN WORDS, with its icon. Complete reads in green; the others in the
   secondary text colour, with the icon's shape and the word doing the work. */
.smme-state {
    align-items: center;
    color: var(--smme-text-secondary);
    display: inline-flex;
    font-size: 13px;
    gap: 6px;
    white-space: nowrap;
}

.smme-state.smme-state-complete {
    color: var(--smme-success);
}

.smme-state.smme-state-pill {
    background-color: var(--smme-surface-raised);
    border: 1px solid var(--smme-border);
    border-radius: 999px;
    color: var(--smme-text-primary);
    padding: 5px 12px;
}

/* A SECTION OF A FORM OR A PAGE: the dashboard's panel, with its heading and
   state in one row. scroll-margin keeps a section's heading clear of the fixed
   app bar when the "On this page" list jumps to it. */
.smme-section {
    display: flex;
    flex-direction: column;
    gap: 16px;
    margin-bottom: 16px;
    scroll-margin-top: 88px;
}

.smme-section-head {
    align-items: baseline;
    display: flex;
    flex-wrap: wrap;
    gap: 4px 16px;
    justify-content: space-between;
}

.smme-section-title {
    color: var(--smme-brand-navy);
    font-size: 18px;
    font-weight: 700;
    line-height: 1.3;
    margin: 0;
}

.smme-section-intro {
    color: var(--smme-text-secondary);
    font-size: 14px;
    margin: -8px 0 0;
}

.smme-page-intro {
    font-size: 15px;
    margin: 0 0 4px;
    max-width: 75ch;
}

.smme-page-note {
    color: var(--smme-text-secondary);
    font-size: 14px;
    margin: 0 0 16px;
    max-width: 75ch;
}

/* A single short form - Manage Account's sections - at a comfortable measure
   rather than stretched across a wide screen. */
.smme-page-narrow {
    max-width: 720px;
}

/* THE PROFILE FORM AND ITS SECTION LIST. The list is a wide-screen aid only;
   below 1200px the form takes the whole width and the list is not drawn. */
.smme-page-with-index {
    align-items: start;
    display: grid;
    gap: 28px;
    grid-template-columns: minmax(0, 1fr);
}

.smme-page-index {
    display: none;
}

@media (min-width: 1200px) {
    .smme-page-with-index {
        grid-template-columns: minmax(0, 1fr) 224px;
    }

    .smme-page-index {
        display: flex;
        flex-direction: column;
        gap: 4px;
        position: sticky;
        top: 24px;
    }
}

.smme-page-index-title {
    color: var(--smme-text-secondary);
    font-size: 12px;
    font-weight: 500;
    letter-spacing: 1px;
    margin: 0 0 6px;
    padding: 0 10px;
    text-transform: uppercase;
}

/* The section's name, and its state on the line beneath: the list is 224px wide
   and "Registration and compliance" beside "In progress" does not fit on one. */
.smme-page-index a {
    align-items: flex-start;
    border-radius: 8px;
    color: var(--smme-text-primary);
    display: flex;
    flex-direction: column;
    font-size: 14px;
    gap: 2px;
    justify-content: center;
    min-height: 44px;
    padding: 6px 10px;
    text-decoration: none;
}

.smme-page-index a .smme-state {
    font-size: 12px;
}

.smme-page-index a:hover {
    background-color: var(--smme-brand-surface);
    color: var(--smme-brand-navy);
}

.smme-page-index a:focus-visible {
    outline: 2px solid var(--smme-portal-blue);
    outline-offset: 2px;
}

/* THE SAVE BAR. Stays in view while the form is on screen, so Save Draft and
   Save Changes are never a scroll away, and the answer to a save appears
   beside the button pressed. On a phone it spans the screen's width at its foot
   with the two buttons side by side; from 768px it floats as a panel. The
   sentence explaining the two buttons sits in the bar from 768px, and above it
   on a phone, where the bar holds the buttons and nothing else. */
.smme-save-note {
    color: var(--smme-text-secondary);
    font-size: 14px;
    margin: 4px 0 12px;
}

/* A field reached with the keyboard is scrolled clear of the bar rather than
   left beneath it. */
html:has(.smme-save-bar) {
    scroll-padding-bottom: 112px;
}

.smme-save-bar {
    background-color: var(--smme-surface-raised);
    border-top: 1px solid var(--smme-border);
    bottom: 0;
    display: flex;
    flex-direction: column;
    gap: 10px;
    margin: 8px -16px 0;
    padding: 12px 16px;
    position: sticky;
    z-index: 3;
}

.smme-save-bar-status {
    color: var(--smme-text-secondary);
    font-size: 13px;
    line-height: 1.45;
}

.smme-save-bar-status:empty {
    display: none;
}

.smme-save-bar-status .smme-save-bar-idle {
    display: none;
}

.smme-save-bar-message {
    align-items: flex-start;
    display: flex;
    gap: 6px;
}

.smme-save-bar-message.smme-save-bar-success {
    color: var(--smme-success);
}

.smme-save-bar-message.smme-save-bar-warning {
    color: var(--smme-warning);
}

.smme-save-bar-message.smme-save-bar-error {
    color: var(--smme-error);
}

.smme-save-bar-actions {
    display: flex;
    gap: 10px;
}

.smme-save-bar-actions > * {
    flex: 1 1 0;
    min-height: 48px;
}

@media (min-width: 768px) {
    .smme-save-note {
        display: none;
    }

    .smme-save-bar {
        align-items: center;
        border: 1px solid var(--smme-border);
        border-radius: 12px;
        bottom: 16px;
        box-shadow: 0 6px 18px rgba(15, 45, 92, 0.12);
        flex-direction: row;
        justify-content: space-between;
        margin: 8px 0 0;
        padding: 12px 20px;
    }

    .smme-save-bar-status {
        max-width: 640px;
    }

    .smme-save-bar-status .smme-save-bar-idle {
        display: inline;
    }

    .smme-save-bar-actions {
        flex-shrink: 0;
    }

    .smme-save-bar-actions > * {
        flex: 0 0 auto;
        min-height: 44px;
    }
}

/* RECORDS: a list of people or entries inside a panel. Below 1200px each record
   is a card of its own and the panel around them steps back, so a phone never
   shows a shrunk table; from 1200px they are rows in the panel, one line each. */
.smme-record-list {
    display: flex;
    flex-direction: column;
    gap: 10px;
}

.smme-record {
    background-color: var(--smme-surface-raised);
    border: 1px solid var(--smme-border);
    border-radius: 12px;
    padding: 14px 16px 6px;
}

.smme-record-row {
    align-items: center;
    display: grid;
    gap: 4px 16px;
    grid-template-areas:
        "name state"
        "detail detail"
        "dates dates"
        "actions actions";
    grid-template-columns: minmax(0, 1fr) auto;
}

.smme-record-name {
    font-size: 16px;
    font-weight: 700;
    grid-area: name;
    overflow-wrap: anywhere;
}

.smme-record-detail {
    font-size: 14px;
    grid-area: detail;
}

.smme-record-dates {
    color: var(--smme-text-secondary);
    font-size: 14px;
    grid-area: dates;
}

.smme-record-state {
    grid-area: state;
}

.smme-record-actions {
    display: flex;
    flex-wrap: wrap;
    gap: 4px;
    grid-area: actions;
}

.smme-record.smme-record-inactive .smme-record-name {
    color: var(--smme-text-secondary);
}

.smme-record-panel {
    background-color: transparent;
    border: 0;
    padding: 0;
}

@media (min-width: 1200px) {
    .smme-record-panel {
        background-color: var(--smme-surface-raised);
        border: 1px solid color-mix(in srgb, var(--smme-control-border) 25%, var(--smme-surface-raised));
        border-radius: 12px;
        padding: 21px;
    }

    .smme-record-list {
        gap: 0;
    }

    .smme-record {
        background-color: transparent;
        border: 0;
        border-radius: 0;
        border-top: 1px solid var(--smme-border);
        padding: 4px 0;
    }

    .smme-record:first-child {
        border-top: 0;
    }

    .smme-record-row {
        grid-template-areas: "name detail dates state actions";
        grid-template-columns: minmax(0, 2fr) minmax(0, 2fr) minmax(0, 1.4fr) minmax(0, 1.2fr) auto;
        min-height: 56px;
    }

    .smme-record-name {
        font-size: 15px;
        font-weight: 500;
    }

    .smme-record-actions {
        justify-content: flex-end;
    }
}