/* =============================================================================
   vrtually-base.css — FOUNDATION LAYER
   =============================================================================

   The single source of truth for primitives: font, colour, radius, shadow and
   type scale. Nothing here styles a component. If you are adding a rule that
   targets a specific piece of UI, it belongs in a component stylesheet
   (vrrtually-ui.css today) and should reference these tokens.

   LOAD POSITION
   -------------
   Linked in layouts/layoutv2.blade.php immediately before @yield("styles").
   That puts it after bootstrap, edety.css, v2ui.css, responsive.css and
   vrrtually-ui.css, but BEFORE any page's own @section('styles') block — so
   pages can still override, which is correct.

   WHY TOKENS RATHER THAN OVERRIDES
   --------------------------------
   responsive.css carries ~3,333 !important declarations. A plain override
   loaded later still loses to every one of them. Custom properties do not have
   that problem — they are inherited values, not competing declarations, so
   nothing can override a token it never mentions.

   The only rule in this file with any visual effect today is
   `body { font-family }`. Everything else is inert until a component
   references it.

   ============================================================================= */


/* -----------------------------------------------------------------------------
   1. TYPE
   -----------------------------------------------------------------------------
   Lato is loaded from Google Fonts in layoutv2.blade.php:
       Lato:ital,wght@0,300;0,400;0,700;1,400

   Lato contains ONLY 100 / 300 / 400 / 700 / 900. There is no 500, no 600 and
   no 800 — they cannot be added to the font request because they do not exist
   in the family. When CSS asks for them the browser rounds to the nearest real
   weight:

       500  ->  400        600  ->  700        800  ->  700

   The codebase currently asks for 500, 600, 700 and 800 in various places,
   which renders as two weights, not four. Use the two tokens below rather than
   raw numbers, so the CSS says what actually happens on screen.

   Montserrat is also loaded twice (Google Fonts in the layout, plus a
   self-hosted @font-face at the top of responsive.css). It is not used by the
   workspace UI. Left alone.
   -------------------------------------------------------------------------- */

:root {
  --v-font-sans: 'Lato', -apple-system, BlinkMacSystemFont, 'Segoe UI',
                 Roboto, 'Helvetica Neue', Arial, sans-serif;

  --v-weight-regular: 400;
  --v-weight-bold: 700;

  /* Type scale — the sizes genuinely in use across the product. */
  --v-text-xs: 11px;    /* chips, action rows */
  --v-text-sm: 12px;    /* KPI labels, timestamps, toasts */
  --v-text-md: 13px;    /* link subtitles */
  --v-text-base: 14px;  /* body copy, form controls */
  --v-text-lg: 16px;    /* link URLs, card titles, KPI values */
  --v-text-xl: 20px;    /* page headings (.title-cmm) */
  --v-text-2xl: 24px;   /* hero: the firm's name on a client-facing page */
}

/* --v-text-2xl exists for ONE job, and it is worth stating so nobody reaches
   for it casually. On the workspace the largest thing on screen is a page
   heading at 20px, because the person reading it already knows whose product
   they are in. On a client-facing page they do not: an injured person landing
   on an intake form is deciding whether to trust a law firm, and the firm's
   name is the answer to the first question they have. It is the masthead, so
   it outranks the page heading scale rather than sitting inside it.

   Use it for the firm identity on client-facing surfaces. Nothing else. */


/* -----------------------------------------------------------------------------
   2. TEXT COLOUR — a neutral ramp
   -----------------------------------------------------------------------------
   #4c4f52 is the product's body text. It is set with !important in roughly 30
   places in responsive.css, so it wins whether or not anything else claims
   otherwise. It is also a NEUTRAL grey — its red and blue channels are 6 points
   apart.

   Every secondary grey previously in use was a COOL grey, with red and blue up
   to 39 points apart:

       #6b7280  spread 21   (.se-kpi-title, upload UI)
       #94a3b8  spread 36   (.se-muted, .se-avatar)
       #9ca3af  spread 19   (.note-id)
       #64748b  spread 39   (inline in the intake modal JS)

   Neutral and cool greys sitting together is what makes an interface read as
   assembled rather than designed. The three tiers below are derived from
   #4c4f52 and share its tonal family. The four values above are retired.
   -------------------------------------------------------------------------- */

:root {
  --v-text-strong: #212427;   /* headings, emphasis — use sparingly */
  --v-text: #4c4f52;          /* body text. The locked value. */
  --v-text-label: #6e7174;    /* field labels, KPI captions, table headers */
  --v-text-subtle: #9c9fa2;   /* timestamps, record ids, de-emphasised meta */
}


/* -----------------------------------------------------------------------------
   3. SURFACES AND LINES
   -----------------------------------------------------------------------------
   #eeeaf7 earns a name. It is the clients table header AND the account
   visibility banner on the workspace dashboard — written in both places as
   `linear-gradient(180deg, #eeeaf7, #eeeaf7)`, a flat fill spelled as a
   gradient. Same intent, same value, no shared definition until now.

   Borders collapse from six values to three. #e6e8f0, #dfe3ea and #edf0fb all
   sit within a few points of #e5e7eb — those were the same decision written
   three ways, not three decisions.
   -------------------------------------------------------------------------- */

:root {
  --v-surface: #ffffff;
  --v-surface-subtle: #f9fafb;   /* page background, inset panels */
  --v-surface-muted: #f3f4f6;    /* neutral chips, icon tiles */
  --v-surface-accent: #eeeaf7;   /* table headers, status banners */
  --v-surface-hover: #fafafa;    /* table row hover */

  --v-line: #e5e7eb;                  /* default hairline */
  --v-line-strong: #d1d5db;           /* badge rings, input borders */
  --v-line-soft: rgba(0, 0, 0, 0.06); /* translucent — darkens what is behind */
}


/* -----------------------------------------------------------------------------
   4. STATUS COLOUR
   -----------------------------------------------------------------------------
   Each status is a background / border / foreground triplet so chips, badges
   and banners can be built from one family instead of improvised per component.
   -------------------------------------------------------------------------- */

:root {
  --v-ok: #16a34a;
  --v-ok-bg: #dcfce7;

  --v-warn: #d97706;
  --v-warn-bg: #fef3c7;
  --v-warn-line: #f6d9a8;

  --v-info: #2f6fed;
  --v-info-bg: #eef4ff;
  --v-info-line: #d4e2ff;

  --v-accent: #7357d6;
  --v-accent-bg: #f2efff;
  --v-accent-line: #ded5ff;

  --v-neutral: #5b6b7f;
  --v-neutral-bg: #f4f6f8;
  --v-neutral-line: #dbe2ec;

  --v-toast: #10b981;
}


/* -----------------------------------------------------------------------------
   5. ACTION COLOUR
   -----------------------------------------------------------------------------
   RECOMMENDATION: use --v-primary for primary buttons, not --v-gradient.

   The product currently paints its primary actions (the clients "Apply" button,
   the CSV upload button) with a cyan-to-purple gradient. There are two such
   gradients in the codebase and they do not match:

       #6ee7ff -> #a78bfa   page-level style blocks
       #22d3ee -> #a855f7   v2ui.css, marketing pages

   Two reasons to move off it. First, a bright gradient on the primary action
   reads consumer-SaaS, which sits badly against personal-injury firms as the
   buyer and against the product's own plain-status tone standard. Second, text
   contrast on a gradient varies across its own width — dark text is fine on the
   cyan end and marginal on the purple end, and there is no single foreground
   that is correct across both.

   --v-primary is #000, taken from .savebtn-01 in responsive.css. That is the
   product's actual primary button and it appears on every save action in the
   product — a black pill with white bold text, fully rounded. It is not a new
   colour; it is the existing one, finally named.

   (An earlier draft of this file set --v-primary to #2563eb on the strength of
   .btn-start in vrrtually-ui.css. That was wrong: .btn-start is the Start
   meeting button, one specific action, not the general primary.)

   The gradient is kept as a token so the two versions become one and it is
   controlled from a single place. Nothing is changed by this file — switching a
   button from gradient to solid is a component-level edit for later.
   -------------------------------------------------------------------------- */

:root {
  --v-primary: #000000;
  --v-primary-hover: #1f1f1f;
  --v-primary-on: #ffffff;

  /* Links. #00348f is the product's existing anchor navy (.auth-name,
     #connectedAccountEdit). Kept distinct from --v-primary so a link never
     looks like a button. */
  --v-link: #00348f;

  /* Destructive. The product had no named danger colour — remove buttons used
     #ff4757, notification dots used #f44336, and validation used the CSS
     keyword `red`. One value, matched tonally to the other status colours. */
  --v-danger: #dc2626;
  --v-danger-bg: #fee2e2;

  /* Legacy. Prefer --v-primary. Standardised on the saturated pair, which is
     the one the marketing site already uses. */
  --v-gradient: linear-gradient(90deg, #22d3ee, #a855f7);
  --v-gradient-on: #0a0f1f;

  /* The original brand orange, still live in edety.css. Note it sits close to
     --v-warn (#d97706) — brand and warning states should probably not be that
     similar, but that is a branding decision, not a CSS one. */
  --v-brand: #ff7521;
}


/* -----------------------------------------------------------------------------
   6. SHAPE
   -----------------------------------------------------------------------------
   Eight radii were in use (6 / 10 / 12 / 14 / 16 / 18 / 26 / 999) with no system
   behind them. Five cover every real case; 18px and 26px were one-off modal
   values and map to --v-radius-2xl.
   -------------------------------------------------------------------------- */

:root {
  --v-radius-sm: 6px;      /* toasts, small tags */
  --v-radius-md: 10px;     /* menu items, secondary buttons */
  --v-radius-lg: 12px;     /* rows, icon buttons, badge tiles */
  --v-radius-xl: 14px;     /* cards */
  --v-radius-2xl: 16px;    /* modals, filter bars, table containers */
  --v-radius-pill: 999px;  /* chips, pill buttons */

  --v-shadow-card: 0 6px 18px rgba(2, 6, 23, 0.04);
  --v-shadow-row: 0 4px 5px rgba(0, 0, 0, 0.07);
  --v-shadow-pop: 0 14px 40px rgba(2, 6, 23, 0.18);
}


/* -----------------------------------------------------------------------------
   7. THE ONE VISIBLE RULE
   -----------------------------------------------------------------------------
   Before this line, `body` had no font-family anywhere in the project. Body
   text fell through to Bootstrap 5's --bs-body-font-family, which is the system
   stack — so every non-heading rendered in Segoe UI on Windows, SF Pro on
   macOS and Roboto on Android, while headings rendered in Lato. Two typefaces
   on every screen, in a pairing that changed with the visitor.

   This is the entire visual change in this file. Delete these three lines to
   revert.
   -------------------------------------------------------------------------- */

body {
  font-family: var(--v-font-sans);

  /* Optional polish, left off deliberately so this file makes exactly one
     visible change. Uncomment together once the font change is confirmed —
     they make Lato noticeably cleaner on macOS and do nothing on Windows.
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  */
}


/* -----------------------------------------------------------------------------
   8. COMPATIBILITY BRIDGE
   -----------------------------------------------------------------------------
   vrrtually-ui.css declares nine --vrtual-* tokens on .vrtual-section. Only
   three are ever used (muted, line, card); the other six are dead. Rather than
   edit that file, the three live ones are re-pointed here.

   The values are identical to what vrrtually-ui.css already sets, so nothing
   changes on screen. What changes is where you edit — from now on, changing
   --v-text changes both.

   Note: gigs-manager.blade.php loads vrrtually-ui.css a second time from inside
   the page body, which lands after this file and reverts these three aliases on
   that one page. No visual effect, since the values match. That duplicate link
   should still come out.
   -------------------------------------------------------------------------- */

.vrtual-section {
  --vrtual-muted: var(--v-text);
  --vrtual-line: var(--v-line);
  --vrtual-card: var(--v-surface);
}