h1:focus {
    outline: none;
}

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

.invalid {
    outline: 1px solid var(--color-brick-600);
}

/* Task F4.E6.T1: the two Bootstrap-class rules that used to live here
   (".darker-border-checkbox.form-check-input" and the ".form-floating"
   placeholder pair) were dead on arrival - this project has never had a
   Bootstrap/CSS-framework dependency (measured: zero ".form-check-input",
   ".form-floating" or ".form-control" class usages in any ".razor" file under
   Components), so the second rule's own "var(--bs-secondary-color)" read an
   always-undefined custom property. Removed rather than carried forward into
   the brand stylesheets under wwwroot/css - Zalacznik E's own "zaden
   framework CSS" ban applies to leftover framework selectors too, not only to
   a live dependency. */

/* Task F4.E6.T1b: this file used to ALSO declare ".validation-message {
   color: #e50000; }", which collided with wwwroot/css/base.css's own
   ".validation-message { color: var(--color-brick-600); }" - same selector,
   same property, a DIFFERENT value - and Components/App.razor's own <link>
   order (this file loads AFTER every wwwroot/css file) meant this rule
   silently won every browser's cascade: measured computed color on "/login"'s
   validation message was rgb(229, 0, 0), not brick-600. Removed rather than
   reconciled - base.css already owns this selector's color, and once "color"
   was gone this rule had no other declaration left.

   What guards this file now is NOT a cross-file comparison of selectors and
   values (that shape shipped first, and was then measured to pass green while
   its own defect sat at the end of this very file). It is a property-name
   allow-list: IsmsPlatform.ArchitectureTests.AppCssCascadeGuardTests fails if
   this file declares ANY property other than "outline", at any position,
   under any selector, in any letter case - the three rules above are the
   whole legitimate remaining job of Blazor's scaffold stub, and everything
   else about how this application looks belongs to the brand layer under
   wwwroot/css, which loads first and would lose any argument with this file.
   That guard's own class remarks enumerate what it does NOT catch, and each
   of those limits is pinned by its own test. */

/* Task F4.E6.T1b (retry): the comment above this one used to spell a glob as
   "Components" + slash + two stars + slash + "*.razor". A CSS comment ends at
   its FIRST closing terminator, and that spelling contains one in the middle
   of the path - so the comment ended mid-sentence and 186 bytes (188 with
   CRLF line endings; task F4.E6.T2 re-measured this byte for byte - see
   docs/tech-debt.md "F4.E6.T2" for the earlier "232 characters" this
   corrects) of English prose became live CSS at the tail of this file.
   Measured in real Chromium (Playwright, with the served response verified
   byte for byte): a rule appended after that prose did not apply at all,
   because the browser had swallowed it into the dangling selector. Rewritten
   in prose above, and pinned: AppCssCascadeGuardTests now also fails if this
   file (or any wwwroot/css file) stops being a well-formed sequence of rule
   blocks. */

/* Task F4.E6.T1b: the ".blazor-error-boundary" rule pair that used to sit
   here (background banner + "::after" content, and this file's own former
   claim that it was "still exercised by this app today") is removed -
   measured (a search across every ".razor" and ".cs" file in this
   repository): zero references to "ErrorBoundary" or
   "blazor-error-boundary" anywhere outside this stylesheet itself, meaning
   no component in this app has ever rendered an element carrying that
   class. Same reasoning task F4.E6.T1 already applied to the two dead
   Bootstrap-class rules above: a selector nothing here ever renders is not
   "exercised", regardless of what a prior comment asserted. */

/* Task F4.E6.T3: the ".valid.modified"/".invalid" markers above used to
   declare "#26b050"/"#e50000" - two hex values that appear NOWHERE in
   tokens.css's own palette (measured: grepped every hex literal in that
   file). Zalacznik E reserves brick for exactly this state ("stanow
   bledu"), so ".invalid" now reads "var(--color-brick-600)" - the same
   token base.css's own ".validation-message" already uses for the error
   text this outline sits next to. ".valid.modified" reads
   "var(--color-teal-600)" - the one accent token, reused rather than
   inventing a second "success green" the palette has never had (this app
   ships no such token anywhere). Both are still bare "outline" declarations
   - AppCssCascadeGuardTests' own property-name allow-list is unaffected by
   which value "outline" carries (see that guard's own
   "Guard_DoesNotCompareAnAllowedPropertysValueAgainstTheBaseLayer_AKnownAndAcceptedLimit"),
   and neither selector collides with anything base.css itself styles, so
   "AppCss_DeclaresNoOutlineOnASelectorTheBrandLayerAlsoStyles" stays green
   for the same reason it already was. */