/* /Components/Layout/AnonymousLayout.razor.rz.scp.css */
/* Task F4.E6.T5 (blueprint section 6; Zalacznik E - binding visual direction;
   Appendix B.4). Every rule below is copied byte-for-byte from the
   corresponding ".app-shell"/"__header"/"__content"/"__footer"/
   "#blazor-error-ui" rule in "MainLayout.razor.css", MINUS the two
   sidebar-only pieces that file also carries (".app-shell-body" - a flex row
   that exists only to sit ".app-shell-sidebar" beside the content - and
   ".app-shell-sidebar" itself, plus its "::deep nav"/"::deep .app-nav__toggle"
   rules, none of which this layout's own markup ever writes). Duplicated
   rather than shared: Blazor's CSS isolation stamps a scope attribute
   ("b-xxxx") only on the elements the OWNING ".razor" file writes directly,
   so a rule declared in "MainLayout.razor.css" never matches markup
   "AnonymousLayout.razor" renders, and vice versa - there is no existing
   "shared chrome" stylesheet in this codebase to factor these into instead
   (measured before writing this file). Kept in exact sync deliberately, not
   accidentally: see "AnonymousLayout.razor"'s own top-of-file remarks for
   the route census this stylesheet applies to, and "MainLayout.razor.css"'s
   own remarks for why ".app-shell-content" carries "overflow-x: auto" (the
   1366x768 horizontal-scroll incident that rule fixed) - copied here for the
   same reason, even though none of the ten routes this layout serves
   currently render a wide table. */

.app-shell[b-gwjswmn04w] {
    display: flex;
    flex-direction: column;
    min-height: 100vh;
}

.app-shell-header[b-gwjswmn04w] {
    display: flex;
    flex-wrap: wrap;
    align-items: center;
    justify-content: space-between;
    gap: var(--space-3);
    padding: var(--space-3) var(--space-4);
    background-color: #ffffff;
    border-bottom: 1px solid var(--color-paper-200);
}

.app-shell-header__brand[b-gwjswmn04w] {
    font-family: var(--font-display);
    font-weight: 600;
    font-size: 1.125rem;
    color: var(--color-ink-950);
}

.app-shell-content[b-gwjswmn04w] {
    flex: 1 1 auto;
    overflow-x: auto;
    background-color: var(--color-paper-50);
    padding: var(--space-6) var(--space-4);
}

.app-shell-footer[b-gwjswmn04w] {
    padding: var(--space-3) var(--space-4);
    border-top: 1px solid var(--color-paper-200);
    background-color: #ffffff;
    font-size: 0.875rem;
}

    .app-shell-footer a[b-gwjswmn04w] {
        color: var(--color-slate-600);
    }

@media (min-width: 1024px) {
    /* No sidebar to reserve 240px for - the content column simply centers
       at the same 1200px max-width "MainLayout.razor.css" gives ITS OWN
       content column once the sidebar is accounted for, matching visual
       rhythm at desktop width rather than stretching a login form edge to
       edge. */
    .app-shell-content[b-gwjswmn04w] {
        max-width: 1200px;
        margin: 0 auto;
        padding: var(--space-8) var(--space-6);
        width: 100%;
    }
}

/* Copied from "MainLayout.razor.css" unchanged - the .NET template's own
   unhandled-JS-error banner, scoped to THIS file's own "#blazor-error-ui"
   element (see this file's own header remarks on why it cannot be shared). */
#blazor-error-ui[b-gwjswmn04w] {
    color-scheme: light only;
    background: lightyellow;
    bottom: 0;
    box-shadow: 0 -1px 2px rgba(0, 0, 0, 0.2);
    box-sizing: border-box;
    display: none;
    left: 0;
    padding: 0.6rem 1.25rem 0.7rem 1.25rem;
    position: fixed;
    width: 100%;
    z-index: 1000;
}

    #blazor-error-ui .dismiss[b-gwjswmn04w] {
        cursor: pointer;
        position: absolute;
        right: 0.75rem;
        top: 0.5rem;
    }
/* /Components/Layout/MainLayout.razor.rz.scp.css */
#blazor-error-ui[b-v0ioemazmn] {
    color-scheme: light only;
    background: lightyellow;
    bottom: 0;
    box-shadow: 0 -1px 2px rgba(0, 0, 0, 0.2);
    box-sizing: border-box;
    display: none;
    left: 0;
    padding: 0.6rem 1.25rem 0.7rem 1.25rem;
    position: fixed;
    width: 100%;
    z-index: 1000;
}

    #blazor-error-ui .dismiss[b-v0ioemazmn] {
        cursor: pointer;
        position: absolute;
        right: 0.75rem;
        top: 0.5rem;
    }

/* Task F4.E6.T2 (blueprint section 6; Zalacznik E - binding visual direction):
   the application shell - header/sidebar/content/footer - measured against
   the round-12 delta (docs/orchestrator-platforma-nis2-v2.md Appendix B.7):
   before this task the only markup MainLayout.razor wrote directly was
   #blazor-error-ui above, so the dashboard's content sat flush at the
   viewport's left edge and NavMenu's <ul> rendered as a bare bulleted list -
   this file's own remarks record that starting state so a later reader does
   not have to re-derive it. Every rule below targets an element this file's
   own MainLayout.razor writes directly (".app-shell" and its descendants,
   including the footer's <a> - that <a> sits inside an <AuthorizeView>
   template, but that template's markup is still authored IN this file, so
   it still carries this file's own scope attribute like everything else
   here) EXCEPT the "::deep nav .../.app-nav__toggle" rules below, which
   are the one genuine exception: styling a CHILD COMPONENT's own markup
   (NavMenu's <details>/<summary>/<nav>/<ul>/<li>/<a>) without that child
   component needing (or gaining) a scope attribute of its own - see
   NavMenu.razor's own remarks for why that matters to NavMenuPageTests.
   Mobile-first: no media query below changes anything about markup or IA,
   only presentation, per this task's own scope. */

/* Session UI1 (finding Z-5). The one number the desktop sticky rules below
   need, declared once here so the header and the navigation cannot drift
   apart. MEASURED, not chosen: 93 px on the live production shell at
   1920 px (2026-08-22, getBoundingClientRect on ".app-shell-header" while
   signed in as the demo account with the two-organization selector
   rendered - the tallest shape this header takes).

   Its one stated limit: the header carries "flex-wrap: wrap", so a very
   long organization name could in principle push the selector onto a
   second row and make the header taller than this value, in which case
   the sticky navigation below would sit that many pixels too high. That
   is measured NOT to happen at any width this media query covers: the
   header's two children measure 222 px + 457 px with a 12 px gap and
   32 px of padding = 723 px, against the 1024 px minimum, so there is
   301 px of slack before a wrap is even possible. "min-height" below
   guarantees the header is never SHORTER than this; nothing can
   guarantee it is never taller, which is why the limit is written down
   rather than promised away. */
.app-shell[b-v0ioemazmn] {
    --app-shell-header-height: 5.8125rem;
    display: flex;
    flex-direction: column;
    min-height: 100vh;
}

.app-shell-header[b-v0ioemazmn] {
    display: flex;
    flex-wrap: wrap;
    align-items: center;
    justify-content: space-between;
    gap: var(--space-3);
    padding: var(--space-3) var(--space-4);
    background-color: #ffffff;
    border-bottom: 1px solid var(--color-paper-200);
}

.app-shell-header__brand[b-v0ioemazmn] {
    font-family: var(--font-display);
    font-weight: 600;
    font-size: 1.125rem;
    color: var(--color-ink-950);
}

.app-shell-body[b-v0ioemazmn] {
    display: flex;
    flex-direction: column;
    flex: 1 1 auto;
}

.app-shell-sidebar[b-v0ioemazmn] {
    background-color: var(--color-ink-950);
}

/* "overflow-x: auto" here is this task's RETRY fix, and it is load-bearing -
   measured, not reasoned about. The first shipped shape of this rule
   (commit 7ee2aad) made a wide table push the whole DOCUMENT sideways on a
   1366x768 desktop, on screens that did not scroll at all before this shell
   existed. Measured with Playwright/Chromium against a real signed-in
   instance, "document.documentElement.scrollWidth" at a 1366px viewport, the
   parent commit 4c7f1f8 in its own worktree on its own port versus this
   branch: /registers/assets 1366 -> 1429, /registers/incidents 1366 -> 1372,
   /registers/suppliers 1366 -> 1378, /registers/risks 1533 -> 1797.
   Arithmetic behind it: the assets table's own min-content width is 1141 on
   BOTH commits (this task never touched any table markup or table CSS), the
   parent handed it the full 1366 so it fitted, and this shell hands it
   1366 - 240 (sidebar) - 48 (this element's own horizontal padding) = 1078.
   A flex item's automatic minimum size is its min-content size, so the
   <main> refused to shrink below 1189 and the overflow escaped into the
   document.
   Why THIS declaration and not "min-width: 0", which is the usual answer to
   an unshrinkable flex item: "min-width: 0" alone was built and measured
   here too, and it is NOT sufficient - it lets this element shrink to 1126,
   but a table still cannot render below its own min-content, so the table
   spilled out of a visible-overflow <main> and the document still grew
   (/registers/assets 1405, /registers/risks 1797, both still above the
   parent's numbers). "overflow-x: auto" does both jobs in one declaration:
   per css-flexbox-1, a scroll container's automatic minimum size is zero, so
   no separate "min-width: 0" is needed (measured: clientWidth 1126 against
   scrollWidth 1189 on /registers/assets), and the overflow is contained in
   this panel instead of the document. After it, all 12 routes this task
   re-measured scroll to exactly the viewport width at both 1366x768 and
   390x844 - no route above its parent number. See docs/tech-debt.md
   "F4.E6.T2 (retry)" for the full before/after table and for what this fix
   does NOT achieve (the assets table's "Akcje" column still needs a
   sideways scroll of THIS panel at 1366px - that is F4.E6.T3's table work,
   and it is arithmetically out of reach of any shell tuning: 1141 + 240
   exceeds 1366 even at zero padding). */
.app-shell-content[b-v0ioemazmn] {
    flex: 1 1 auto;
    overflow-x: auto;
    background-color: var(--color-paper-50);
    padding: var(--space-6) var(--space-4);
}

.app-shell-footer[b-v0ioemazmn] {
    padding: var(--space-3) var(--space-4);
    border-top: 1px solid var(--color-paper-200);
    background-color: #ffffff;
    font-size: 0.875rem;
}

    .app-shell-footer a[b-v0ioemazmn] {
        color: var(--color-slate-600);
    }

/* Zalacznik E: "sidebar ink na desktopie, chowany ponizej 1024px" - NavMenu's
   own <details>/<summary> (see that file's own remarks) provides the
   collapse. Measured DURING this task, not assumed: a closed <details>'s
   non-summary content is NOT hidden via plain "display:none" on that child
   in current Chromium - it is wrapped in an internal "::details-content"
   pseudo-element that gets "content-visibility: hidden" (a diagnostic build
   of this exact rule with only "nav { display: block }" left the nav
   reporting "display: block" AND a non-zero bounding box while a real
   screenshot showed nothing painted; Element.checkVisibility() was the
   signal that actually agreed with the screenshot). Forcing it open on
   desktop therefore has to target that pseudo-element directly. */
.app-shell-sidebar[b-v0ioemazmn]  .app-nav__toggle {
    display: flex;
    align-items: center;
    min-height: 2.5rem;
    padding: var(--space-3) var(--space-4);
    font-family: var(--font-body);
    font-weight: 600;
    color: var(--color-paper-50);
    cursor: pointer;
    list-style: none;
}

    .app-shell-sidebar[b-v0ioemazmn]  .app-nav__toggle::-webkit-details-marker {
        display: none;
    }

.app-shell-sidebar[b-v0ioemazmn]  nav {
    padding: var(--space-2) 0 var(--space-4);
}

.app-shell-sidebar[b-v0ioemazmn]  nav ul {
    list-style: none;
    margin: 0;
    padding: 0;
}

.app-shell-sidebar[b-v0ioemazmn]  nav a {
    display: block;
    min-height: 2.5rem;
    padding: var(--space-2) var(--space-4);
    color: var(--color-paper-100);
    text-decoration: none;
    font-size: 0.9375rem;
    line-height: 1.5rem;
    transition: background-color var(--transition-fast), color var(--transition-fast);
}

    .app-shell-sidebar[b-v0ioemazmn]  nav a:hover {
        background-color: var(--color-ink-900);
        color: #ffffff;
    }

    /* Deliberately NOT overridden here: base.css's own global
       "a:focus-visible { outline: 2px solid var(--color-teal-500);
       outline-offset: 2px; }" (Zalacznik E: ":focus-visible outline 2px
       teal-500 wszedzie") already matches every <a> in the document,
       including these - measured on this task's own screenshots (see the
       implementer's report) rather than assumed. A sidebar-local override
       here would only risk drifting from that one pinned value. */

@media (min-width: 1024px) {
    .app-shell-body[b-v0ioemazmn] {
        flex-direction: row;
    }

    .app-shell-sidebar[b-v0ioemazmn] {
        flex: 0 0 240px;
    }

    .app-shell-content[b-v0ioemazmn] {
        max-width: 1200px;
        margin: 0 auto;
        padding: var(--space-8) var(--space-6);
        width: 100%;
    }

    /* Session UI1 (finding Z-4, third part). Measured on production at
       1920 px: the panel is capped at 1200 px with 232 px of empty margin
       on EACH side, while the risks table has 465 px sitting outside the
       visible panel. 1200 px is the right measure for prose (the course
       lesson pages read well at it) and the wrong one for a page whose
       content IS a wide table.

       Keyed off ":has()" rather than off a route list on purpose: the
       layout stays ignorant of which routes are registers, and a page
       opts in by marking its own table container. Nothing changes at
       1366 px, where the available row width (1366 - 240 sidebar =
       1126) is already below both caps - which is why the arithmetic
       task F4.E6.T2 (retry) pinned for that viewport is untouched by
       this rule; it only spends screen that was empty at 1920.

       ":has()" is used here the same way base.css already uses it for
       the form controls; the scoped-CSS rewrite stamps this component's
       scope attribute onto ".app-shell-content" itself, never into the
       ":has()" argument, so the argument matches the child component's
       own markup without needing "::deep". */
    .app-shell-content:has(.app-table-container--wide)[b-v0ioemazmn] {
        max-width: 1600px;
    }

    /* Session UI1 (finding Z-5). Measured on production 2026-08-22: the
       ONLY element with "position: fixed" or "sticky" in the whole
       document was "#blazor-error-ui" (the hidden Blazor banner at the
       top of this file), so on "/organization-profile" - 3169 px tall -
       the navigation scrolled away and left a 240 px ink column with
       nothing in it, and reaching another register meant scrolling back
       to the very top.

       Three deliberate choices here.

       (a) The <aside> itself is NOT the sticky element. It keeps its own
           stretched full-row height, so the ink column still runs the
           whole page exactly as before - a sticky <aside> would have to
           shrink to its content and would leave paper-50 below the menu,
           which is a look nobody asked for.

       (b) What sticks is NavMenu's own <details> element, which carries
           BOTH the collapse toggle and the link list, so the two never
           separate. It is reached through "::deep" for the same reason
           every other navigation rule in this file is - see the remarks
           above ".app-shell-sidebar ::deep .app-nav__toggle".

       (c) "max-height" plus "overflow-y: auto" so a menu longer than the
           space under the header scrolls inside itself instead of being
           cut off. Measured today: the menu is 544 px and the space is
           852 px at a 945 px viewport, so this is a guard, not a
           behaviour anyone sees now.

       This does not move the vertical scrolling anywhere: the DOCUMENT
       still scrolls (task F4.E6.T2 (retry) measured the panel as
       scrollHeight === clientHeight and this session re-measured the same
       thing after the change - see docs/tech-debt.md "UI1"). Neither the
       "overflow-x: auto" declaration on ".app-shell-content" nor its own
       reasoning is touched. */
    .app-shell-header[b-v0ioemazmn] {
        position: sticky;
        top: 0;
        z-index: 20;
        min-height: var(--app-shell-header-height);
    }

    .app-shell-sidebar[b-v0ioemazmn]  .app-nav {
        position: sticky;
        top: var(--app-shell-header-height);
        max-height: calc(100vh - var(--app-shell-header-height));
        overflow-y: auto;
    }

    /* Gated behind "@supports selector(...)" (itself well-supported; an
       unrecognized function inside "@supports" evaluates the whole
       condition to false per the CSS Conditional Rules spec, so this is
       safe to feature-test rather than browser-sniff) so that a browser
       without "::details-content" degrades to "still collapsible, always
       reachable" - the toggle stays visible and clickable on every
       viewport - rather than the alternative failure mode this task
       measured and rejected: hiding the toggle unconditionally here would
       leave a desktop visitor on such a browser with an invisible menu and
       no way to open it, because the native collapse would still apply and
       nothing would be left to force it open. */
    @supports selector(::details-content) {
        .app-shell-sidebar[b-v0ioemazmn]  .app-nav:not([open])::details-content {
            content-visibility: visible;
        }

        .app-shell-sidebar[b-v0ioemazmn]  .app-nav__toggle {
            display: none;
        }
    }
}
/* /Components/Layout/ReconnectModal.razor.rz.scp.css */
.components-reconnect-first-attempt-visible[b-yhbacr1dqr],
.components-reconnect-repeated-attempt-visible[b-yhbacr1dqr],
.components-reconnect-failed-visible[b-yhbacr1dqr],
.components-pause-visible[b-yhbacr1dqr],
.components-resume-failed-visible[b-yhbacr1dqr],
.components-rejoining-animation[b-yhbacr1dqr] {
    display: none;
}

#components-reconnect-modal.components-reconnect-show .components-reconnect-first-attempt-visible[b-yhbacr1dqr],
#components-reconnect-modal.components-reconnect-show .components-rejoining-animation[b-yhbacr1dqr],
#components-reconnect-modal.components-reconnect-paused .components-pause-visible[b-yhbacr1dqr],
#components-reconnect-modal.components-reconnect-resume-failed .components-resume-failed-visible[b-yhbacr1dqr],
#components-reconnect-modal.components-reconnect-retrying[b-yhbacr1dqr],
#components-reconnect-modal.components-reconnect-retrying .components-reconnect-repeated-attempt-visible[b-yhbacr1dqr],
#components-reconnect-modal.components-reconnect-retrying .components-rejoining-animation[b-yhbacr1dqr],
#components-reconnect-modal.components-reconnect-failed[b-yhbacr1dqr],
#components-reconnect-modal.components-reconnect-failed .components-reconnect-failed-visible[b-yhbacr1dqr] {
    display: block;
}


#components-reconnect-modal[b-yhbacr1dqr] {
    background-color: white;
    width: 20rem;
    margin: 20vh auto;
    padding: 2rem;
    border: 0;
    border-radius: 0.5rem;
    box-shadow: 0 3px 6px 2px rgba(0, 0, 0, 0.3);
    opacity: 0;
    transition: display 0.5s allow-discrete, overlay 0.5s allow-discrete;
    animation: components-reconnect-modal-fadeOutOpacity-b-yhbacr1dqr 0.5s both;
    &[open]

{
    animation: components-reconnect-modal-slideUp-b-yhbacr1dqr 1.5s cubic-bezier(.05, .89, .25, 1.02) 0.3s, components-reconnect-modal-fadeInOpacity-b-yhbacr1dqr 0.5s ease-in-out 0.3s;
    animation-fill-mode: both;
}

}

#components-reconnect-modal[b-yhbacr1dqr]::backdrop {
    background-color: rgba(0, 0, 0, 0.4);
    animation: components-reconnect-modal-fadeInOpacity-b-yhbacr1dqr 0.5s ease-in-out;
    opacity: 1;
}

@keyframes components-reconnect-modal-slideUp-b-yhbacr1dqr {
    0% {
        transform: translateY(30px) scale(0.95);
    }

    100% {
        transform: translateY(0);
    }
}

@keyframes components-reconnect-modal-fadeInOpacity-b-yhbacr1dqr {
    0% {
        opacity: 0;
    }

    100% {
        opacity: 1;
    }
}

@keyframes components-reconnect-modal-fadeOutOpacity-b-yhbacr1dqr {
    0% {
        opacity: 1;
    }

    100% {
        opacity: 0;
    }
}

.components-reconnect-container[b-yhbacr1dqr] {
    display: flex;
    flex-direction: column;
    align-items: center;
    gap: 1rem;
}

#components-reconnect-modal p[b-yhbacr1dqr] {
    margin: 0;
    text-align: center;
}

#components-reconnect-modal button[b-yhbacr1dqr] {
    border: 0;
    background-color: #6b9ed2;
    color: white;
    padding: 4px 24px;
    border-radius: 4px;
}

    #components-reconnect-modal button:hover[b-yhbacr1dqr] {
        background-color: #3b6ea2;
    }

    #components-reconnect-modal button:active[b-yhbacr1dqr] {
        background-color: #6b9ed2;
    }

.components-rejoining-animation[b-yhbacr1dqr] {
    position: relative;
    width: 80px;
    height: 80px;
}

    .components-rejoining-animation div[b-yhbacr1dqr] {
        position: absolute;
        border: 3px solid #0087ff;
        opacity: 1;
        border-radius: 50%;
        animation: components-rejoining-animation-b-yhbacr1dqr 1.5s cubic-bezier(0, 0.2, 0.8, 1) infinite;
    }

        .components-rejoining-animation div:nth-child(2)[b-yhbacr1dqr] {
            animation-delay: -0.5s;
        }

@keyframes components-rejoining-animation-b-yhbacr1dqr {
    0% {
        top: 40px;
        left: 40px;
        width: 0;
        height: 0;
        opacity: 0;
    }

    4.9% {
        top: 40px;
        left: 40px;
        width: 0;
        height: 0;
        opacity: 0;
    }

    5% {
        top: 40px;
        left: 40px;
        width: 0;
        height: 0;
        opacity: 1;
    }

    100% {
        top: 0px;
        left: 0px;
        width: 80px;
        height: 80px;
        opacity: 0;
    }
}