/*
 * brand-tokens.css - default values for the brand token namespace.
 *
 * Why this file exists: Brand.PrimaryColor is editable at /admin/settings, but until now its only
 * consumer was the public marketing API, which hands it to the static themes. The portal a
 * client's customers sign into every week ignored it and painted the vendor blue hardcoded into
 * the Tailwind @theme block in both root layouts. A courier would set their colour, save, and see
 * nothing change. The --brand-* variables below are the single place the rest of the UI reads a
 * colour from, so there is somewhere for that setting to land.
 *
 * These are DEFAULTS ONLY, and they are exactly the current vendor palette. Two reasons:
 *
 *   1. The file has to be valid and complete on its own, so a page that loads it without the
 *      runtime block still renders - during setup, on an error page, or if branding fails to
 *      resolve.
 *   2. An install that never sets a brand colour must look identical to how it looks today. The
 *      diff for those installs should be zero pixels.
 *
 * IBrandTokenService renders the same variable names into an inline ":root { ... }" block at
 * request time, derived from the client's chosen colour. That block is emitted after this
 * stylesheet and wins on document order at equal specificity, so it overrides these values
 * wherever a client has actually configured something.
 *
 * This file is also where the two palettes that are deliberately NOT derived from the brand colour
 * live - the neutral chrome ramp and the status ramp. They were previously restated in full inside
 * the Tailwind @theme block of _TailwindAdminLayout and again inside _AuthLayout, which is two
 * copies of the same twenty-odd values drifting independently. Keeping them here does not make them
 * client-editable; it makes there be one of each. The layouts alias rather than restate.
 *
 * Do not add a hardcoded colour to this file that a client should be able to change. Anything
 * driven by Brand.PrimaryColor belongs in the service's derivation, not here.
 */

:root {
    /*
     * The 25..950 ramp. The service derives all of these from the single colour the client picks -
     * asking a courier owner for eleven hex values would produce either an unusable palette or an
     * abandoned settings form. The values here are the vendor ramp, and feeding #465fff back
     * through the derivation reproduces them, which is what makes the default path a no-op.
     */
    --brand-25: #f2f7ff;
    --brand-50: #ecf3ff;
    --brand-100: #dde9ff;
    --brand-200: #c2d6ff;
    --brand-300: #9cb9ff;
    --brand-400: #7592ff;
    --brand-500: #465fff;
    --brand-600: #3641f5;
    --brand-700: #2a31d8;
    --brand-800: #252dae;
    --brand-900: #262e89;
    --brand-950: #161950;

    /* The anchor of the ramp, aliased so callers that only want "the brand colour" need not know
       that 500 is the weight that means "the one they picked". */
    --brand-primary: var(--brand-500);

    /*
     * Foreground for text and icons sitting on --brand-primary. White is correct here only
     * because the vendor blue is dark; the service recomputes it per install by contrast ratio, so
     * a client choosing a pale yellow gets black instead of invisible white labels.
     */
    --brand-on-primary: #ffffff;

    /* Neutral chrome. Not derived from the brand hue - tinting every card and divider towards the
       brand colour reads as a rendering bug rather than as branding. */
    --brand-surface: #ffffff;
    --brand-surface-muted: #f9fafb;
    --brand-border: #e4e7ec;
    --brand-ink: #1d2939;
    --brand-ink-muted: #667085;

    /* Matches --font-outfit in the root layouts. */
    --brand-font: "Nunito", "Segoe UI", sans-serif;

    /*
     * Neutral chrome ramp.
     *
     * Same values the two root layouts each carried their own copy of. Three of the twelve stops
     * are aliases rather than literals because they already had a token whose default was byte
     * identical - which also means an install that overrides Brand.SurfaceMutedColor,
     * Brand.BorderColor or Brand.InkMutedColor moves gray-50/200/500 with it. The indirection
     * resolves correctly regardless of source order: a var() in a custom property is substituted at
     * computed-value time, so the runtime :root block still wins even though it is emitted after
     * this declaration.
     *
     * The other nine are literals on purpose. They are mostly dark-mode chrome with no counterpart
     * in the token set, and inventing a mapping onto the brand hue would let one setting repaint
     * surfaces it was never meant to describe - a courier who picks red would get a faintly
     * alarming pink application rather than a branded one.
     */
    --brand-gray-25: #fcfcfd;
    --brand-gray-50: var(--brand-surface-muted);
    --brand-gray-100: #f2f4f7;
    --brand-gray-200: var(--brand-border);
    --brand-gray-300: #d0d5dd;
    --brand-gray-400: #98a2b3;
    --brand-gray-500: var(--brand-ink-muted);
    --brand-gray-600: #475467;
    --brand-gray-700: #344054;
    --brand-gray-800: #1d2939;
    --brand-gray-900: #101828;
    --brand-gray-950: #0c111d;

    /*
     * Status ramp. Never derived from the brand colour, in either direction.
     *
     * Green means delivered, amber means delayed, red means failed. That reading is the semantics
     * of the operation rather than decoration, and it has to survive a client picking red or green
     * as their brand colour - otherwise a courier who likes red gets a dashboard where every parcel
     * appears to have failed. The error ramp carries its full tint range because the auth pages
     * build validation summaries out of the 25..200 stops.
     */
    --status-error-25: #fffbfa;
    --status-error-50: #fef3f2;
    --status-error-100: #fee4e2;
    --status-error-200: #fecdca;
    --status-error-300: #fda29b;
    --status-error-400: #f97066;
    --status-error-500: #f04438;
    --status-error-600: #d92d20;
    --status-error-700: #b42318;

    --status-success-500: #12b76a;
    --status-warning-500: #f79009;

    /*
     * Marketing-site palette, consumed by wwwroot/css/site.css.
     *
     * The front pages predate the token namespace and painted their own unrelated blue. Their
     * colour-carrying variables now read the ramp above, but four values have no equivalent there
     * and would otherwise stay as literals in the stylesheet:
     *
     *   accent / accent-strong  The CTA colour. Deliberately NOT derived from the brand hue: the
     *                           whole job of this colour is to contrast with --brand-500, and
     *                           deriving both from one hue collapses the call to action into the
     *                           block it is meant to stand out from.
     *   ink-strong              A deeper body text than --brand-ink, which the marketing pages use
     *                           at large sizes where --brand-ink reads washed out.
     *   ink-soft / surface-sunken  The far end of the dark CTA gradient and the tinted section
     *                           background - both need a second neutral a step away from the first.
     */
    --brand-accent: #f97316;
    --brand-accent-strong: #ea580c;
    --brand-ink-strong: #0f172a;
    --brand-ink-soft: #2d3748;
    --brand-surface-sunken: #f1f5f9;
}