/* ==========================================================================
   Agent Rooms — SITE CHROME BRIDGE
   ==========================================================================

   render_navigation() (includes/nav_functions.php) and render_footer()
   (includes/footer_functions.php) ship their own component CSS inline, but
   they are NOT self-contained. They depend on three things the page must
   provide:

     1. A :root palette. Their inline styles read --primary-color,
        --text-primary, --glass-background, --border-glass, --dropdown-bg,
        --transition-speed and friends. Those live in index1.css, which tool
        pages do not load. Unset, every colour, border and transition in the
        nav and footer falls back to nothing — which is exactly why Agent
        Rooms' nav and footer rendered as unstyled browser defaults.

     2. Base .button / .button-primary / .button-outline rules. /css/nav-shared.css
        provides only contextual overrides (.mobile-menu .button, .auth-buttons
        .button); the base rules also live in index1.css. Without them the
        Sign Up / Login buttons render as raw <button> elements.

     3. Font Awesome, for every icon in both the nav and the footer.
        That one is a <link> in the page head, not here.

   This file supplies 1 and 2 for BOTH Agent Rooms pages, plus the fixes each
   page needs to host the chrome without fighting it. It follows the pattern
   documented in decision-lab/decision-lab.css: a FROZEN COPY of the homepage
   palette, not a reference to it, so editing the homepage cannot silently
   restyle this tool. To re-sync, copy new values in deliberately.

   Load order: /css/nav-shared.css -> the page's own stylesheet -> THIS FILE.
   Last, deliberately: sections 3 and 4 restate the chrome's intent against
   rules in app.css / landing.css that would otherwise win on source order.

   Deliberately NOT copied from decision-lab.css:
     - `html, body { overflow-x: hidden }`. Setting overflow on <html> makes
       <body> a real scroll container, and `position: sticky` on .nav-container
       stops sticking. Both Agent Rooms pages already handle overflow-x on body
       alone, which is the form that keeps the sticky nav working.
     - The global `* { margin: 0; padding: 0 }` reset. Both pages already zero
       the list margins the chrome actually relies on.
   ========================================================================== */


/* ==========================================================================
   1. THE PALETTE
   Frozen copy of the homepage tokens, 2026-08. Canonical site values are used
   verbatim — the point of this work is that the nav looks IDENTICAL here to
   every other page, so this is not the place to be creative.
   ========================================================================== */

:root {
  /* Brand */
  --primary-color: #4F46E5;
  --secondary-color: #7C3AED;
  --accent-primary: #A78BFA;

  /* --primary-color-dark is read by the footer promo strip
     (footer_functions.php) and is defined NOWHERE else in the codebase, so its
     unstyled fallback is a stray orange (#c85d0a). Pin it to a real shade of
     the brand indigo. */
  --primary-color-dark: #4338CA;

  /* Surfaces */
  --bg-primary: #0D0C1D;
  --bg-secondary: #1A1A2E;
  --surface-glass: rgba(255, 255, 255, 0.05);
  --surface-glass-hover: rgba(255, 255, 255, 0.08);
  --glass-background: rgba(255, 255, 255, 0.05);
  --glass-background-hover: rgba(255, 255, 255, 0.08);
  --card-bg: rgba(255, 255, 255, 0.03);
  --dropdown-bg: #0D0C1D;

  /* Text */
  --text-color: #FFFFFF;
  --text-primary: #FFFFFF;
  --text-secondary: #9CA3AF;
  --text-tertiary: #6B7280;
  --text-headings: #E5E7EB;

  /* Borders */
  --border-glass: rgba(255, 255, 255, 0.1);
  --border-glass-hover: rgba(255, 255, 255, 0.2);

  /* Status */
  --success-color: #10b981;
  --warning-color: #f59e0b;
  --danger-color: #ef4444;

  /* Motion */
  --transition-speed: 0.3s;
  --transition-ease: cubic-bezier(0.4, 0, 0.2, 1);
  --transition: all 0.3s cubic-bezier(0.4, 0, 0.2, 1);

  /* Radii */
  --radius-sm: 0.375rem;
  --radius-md: 0.5rem;
  --radius-lg: 0.75rem;
  --radius-xl: 1rem;
  --radius-2xl: 1.5rem;
}


/* ==========================================================================
   2. BUTTONS
   The nav emits `class="button button-primary"` (Sign Up) and
   `class="button button-outline"` (Login). These are the site's own button
   classes, not Bootstrap's — Bootstrap is not loaded here and is not needed.
   ========================================================================== */

/* Values copied verbatim from index1.css:1586-1621 and :1310-1313. Do not
   "improve" them — the whole point is that Sign Up and Login are pixel-identical
   to the homepage. The primary button's indigo->violet gradient and its hover
   lift are the site's signature; a flat fill reads as a different site. */
.button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: 0.5rem;
  padding: 0.75rem 1.5rem;
  border: none;
  border-radius: 0.5rem;
  cursor: pointer;
  transition: all var(--transition-speed);
  font-weight: 500;
  font-size: 0.95rem;
  text-align: center;
}

.button-primary {
  background: linear-gradient(135deg, var(--primary-color), var(--secondary-color));
  color: var(--text-primary);
  border: 1px solid transparent;
}
.button-primary:hover {
  transform: translateY(-2px);
  box-shadow: 0 8px 25px rgba(79, 70, 229, 0.4);
}

.button-outline {
  background: transparent;
  border: 1px solid var(--border-glass);
  color: var(--text-primary);
}
.button-outline:hover {
  background: var(--surface-glass-hover);
  border-color: var(--border-glass-hover);
}

@media (min-width: 1024px) {
  .button { padding: 0.6rem 1.2rem; font-size: 0.95rem; }
}

/* NOTE: no rules here for .notification-icon / .profile-icon / .submit-icon.
   Those are already sized by css/notifications.css (which render_navigation()
   injects itself) and by nav_functions.php's own inline style. Anything added
   here at .button.notification-icon (0,2,0) would outrank both and shrink the
   bell out of its circle. */


/* ==========================================================================
   3. PROTECTING THE CHROME FROM THE PAGE
   Both Agent Rooms stylesheets style bare `a` and `button` elements, and the
   nav/footer markup is injected into that same document. These rules restate
   the chrome's own intent at a specificity that survives.
   ========================================================================== */

/* No blanket link-colour rules here, deliberately. The obvious defensive block
   — `.nav-container a.nav-link { color: var(--text-primary) }` and friends —
   was written against `a { color: var(--ar-accent) }` in app.css. But that rule
   is (0,0,1) and nav-shared.css already colours every one of those elements
   with (0,1,0) class rules, so it never had a fight to win. What such a block
   DOES do is outrank `.nav-upgrade { color: #fbbf24 }` (nav_functions.php) at
   (0,2,1) and turn the amber Upgrade link white on this page and no other.
   The chrome colours itself correctly. Leave it alone.
   The one exception, cheap and safe: */
.footer-v2 a {
  text-decoration: none;
}

/* Both pages zero focus outlines with a :where() rule and then restore rings
   only on their own .ar-* selectors — which would leave every nav and footer
   control with no visible keyboard focus at all. WCAG 2.4.7 is not optional.

   LOAD ORDER IS LOAD-BEARING HERE: landing.css's `.ar-landing :where(...):focus`
   is also (0,2,0), so this wins on source order alone. If this file is ever
   moved above landing.css in the <head>, every nav and footer focus ring
   silently disappears — with no visual symptom until somebody tabs. */
.nav-container :where(a, button, [tabindex]):focus-visible,
.banner-container :where(a, button):focus-visible,
.mobile-menu :where(a, button, [tabindex]):focus-visible,
.footer-v2 :where(a, button, [tabindex]):focus-visible {
  outline: 2px solid var(--accent-primary);
  outline-offset: 2px;
  border-radius: var(--radius-sm);
}


/* ==========================================================================
   4. THE APPLICATION SHELL ONLY  (body.ar-body — agent-rooms/index.php)
   The logged-out landing page is an ordinary document and needs none of this.
   ========================================================================== */

/* 4a. Make room for the nav.
   .ar-app is `height: 100dvh`, which assumed it owned the whole viewport. With
   a 64px nav in flow above it the document overflowed by exactly the nav's
   height and the composer fell below the fold. A flex column is used rather
   than `calc(100dvh - 4rem)` because the promo banner above the nav has no
   fixed height — it changes with its own breakpoints — so any hard-coded
   subtraction would be wrong on some viewport. */
/* `overflow: hidden` matters as much as the height. The document is now exactly
   one viewport tall, so anything absolutely positioned inside the nav that
   hangs below it — an open notification list is ~570px — becomes page overflow
   and hands the "fixed" shell a scrollbar it is not built to have. On an
   ordinary page the document was long anyway and this never showed. */
body.ar-body {
  display: flex;
  flex-direction: column;
  min-height: 100dvh;
  height: 100dvh;
  overflow: hidden;
}
/* `flex: 1 1 0`, NOT `1 1 auto`. With an auto basis the flex base size is
   .ar-app's max-content height, and a scroll container's max-content height is
   its whole content — so a long transcript would size the shell to the
   transcript, the document would grow past the viewport, .ar-pane-body's own
   overflow would never engage, and the composer would end up thousands of
   pixels down the page. A zero basis makes the leftover space definite, the
   panes scroll internally again, and the composer stays pinned. */
body.ar-body .ar-app {
  flex: 1 1 0;
  min-height: 0;
  height: auto;
}

/* 4b. Lift the nav above the app's own chrome.
   .nav-container carries `z-index: 50`, which makes it a stacking context —
   so its dropdowns (1000), profile menu (1001) and mobile panel (49) are all
   resolved as 50 against the root. The app header is 200 and the tab bar 250,
   so every nav dropdown would open UNDERNEATH them. 300 clears both while
   staying below --ar-z-overlay (800), so app modals still cover the nav. */
body.ar-body .nav-container {
  z-index: 300;
}

/* 4c. Keep the chrome dark when the app is in light mode.
   The app is theme-aware (data-theme / prefers-color-scheme, see tokens.css)
   but the site chrome palette is dark-only. Two surfaces are translucent white
   and become invisible over a light app: `.nav-container` (--surface-glass) and
   `.profile-menu` (--glass-background, and it sits BELOW the nav's box so
   pinning the nav does not cover it). The dropdown and toolbox panels use
   --dropdown-bg, which is already opaque, so they are fine.

   `color` is pinned too, not just `background`. .profile-item declares its own
   colour but .profile-email does not — it inherits from body, which in light
   mode is --ar-text #0D1117. Against a pinned #0D0C1D panel that is a 1.01:1
   contrast ratio, i.e. the account email rendered as an invisible smudge.

   backdrop-filter is deliberately NOT touched. .nav-container's blur(10px) is
   what makes it a containing block for .mobile-menu, which is `position: fixed;
   top: 3.5rem` — remove or neutralise the filter and the panel re-anchors to
   the viewport and jumps up over the logo, in light mode only. The blur is
   already a visual no-op once the background behind it is opaque, so the
   cheapest correct move is to leave it exactly as dark mode has it. */
:root[data-theme="light"] body.ar-body .nav-container,
:root[data-theme="light"] body.ar-body .profile-menu,
:root[data-theme="light"] body.ar-body .notification-dropdown,
:root[data-theme="light"] body.ar-body .mobile-menu {
  background: var(--bg-primary);
  color: var(--text-primary);
}
@media (prefers-color-scheme: light) {
  :root:not([data-theme="dark"]) body.ar-body .nav-container,
  :root:not([data-theme="dark"]) body.ar-body .profile-menu,
  :root:not([data-theme="dark"]) body.ar-body .notification-dropdown,
  :root:not([data-theme="dark"]) body.ar-body .mobile-menu {
    background: var(--bg-primary);
    color: var(--text-primary);
  }
}

/* 4d. Claw back some mobile height.
   Below 1023px the site nav, the app header and the pane tab bar stack up
   before any content. The app header's brand mark is pure duplication once the
   site nav sits directly above it carrying the same logo, so that goes; the
   header itself stays, because it holds the theme toggle, export and privacy
   controls and there is nowhere else for them to live.

   The promo banner stands down at this width too — on the app shell only; the
   logged-out landing page keeps it, which is where it earns its keep. Budget on
   a 375x667 phone with Safari's toolbars showing (visual viewport ~553px), with
   the banner hidden: nav 64 + app header 43 + tab bar 40 + composer ~151 = ~298,
   leaving ~255px of transcript. Restoring the banner costs ~44px of that.
   Delete the .banner-container rule if you would rather keep the promo. */
@media (max-width: 1023px) {
  body.ar-body { --ar-header-h: 42px; }
  body.ar-body .ar-brand { display: none; }
  body.ar-body .banner-container { display: none; }
}
