/* ============================================================
   PLATFORM THEME — base tokens and the one global reset.
   Loaded on every page from src/app/(frontend)/layout.tsx.

   These are the platform's own design tokens: careers.css,
   smos-home.css, smos-v4.css, studio.css and not-found.tsx all
   read --wine / --gold / --cream / --sand from here.

   It used to live at /sufii/theme.css, headed "SUFII DAY SPA —
   shared theme", because it began life as one prospect's brand
   sheet and quietly became the foundation for everything. That
   prospect never became a client. The file is named for what it
   actually is now.

   The token NAMES are deliberately unchanged. wine, gold, cream,
   sand and espresso are ordinary colour words, not a business's
   property, and renaming fourteen tokens across five stylesheets
   would risk real breakage for no gain. What mattered was that
   the platform's palette no longer lives inside a former
   prospect's file.

   SMOS-298 — WHAT THIS FILE NO LONGER CONTAINS, and why it is
   worth knowing before adding anything to it. Underneath the
   tokens this file also shipped a full component stylesheet —
   .card .band .sec-head .wrap .btn .faq .menu-row and the rest,
   plus bare `h1`/`a`/`img` rules — all unscoped, all loaded on
   every route, all written against exactly the class names the
   shared block components emit. Every tenant theme inherited a
   component kit it never asked for; `.sec-head{text-align:center}`
   was silently centring sections on a client site days from
   launch, and `a{color:inherit;text-decoration:none}` was
   stripping link affordance from any surface that did not
   re-style links itself.

   Those rules now live in /platform-kit.css, scoped to a
   `platform-kit` class a surface opts into. THE TEST FOR
   ANYTHING NEW HERE: would a business with a completely
   different brand still want it? A colour token, yes. A
   `.card` rule, no — that belongs in the kit or in that
   theme's own sheet.
   ============================================================ */
:root{
  --wine:#5A2233; --wine-deep:#3A1620; --wine-2:#7A3247;
  --gold:#C6A15C; --gold-text:#E1C489; --gold-soft:#D9BE86;
  --cream:#F8F2E9; --ivory:#FFFDF8; --sand:#EDE3D3; --sand-2:#E3D4BE;
  --espresso:#2A1E1C; --stone:#6E6055; --sage:#8C9A80; --line:#E4D8C6;
}
/* Deliberately global, and deliberately NOT moved into the kit. Every
   stylesheet in this app was written against border-box and against zeroed
   margins; scoping this would restyle all of them at once, which is a
   different and much larger change than SMOS-298. */
*{margin:0;padding:0;box-sizing:border-box;}
/* The app's default ground and typeface, which a surface overrides by
   setting its own — as .sv4, .aw and .wb all do. This is the foundation
   the file's header describes and is correct app-wide. `overflow-x:hidden`
   used to be here too and is NOT foundational: it hides overflow bugs
   rather than preventing them, so it moved into the kit with the rules
   that were designed around it. */
body{background:var(--cream);color:var(--espresso);font-family:'Inter',system-ui,sans-serif;font-size:16px;line-height:1.65;-webkit-font-smoothing:antialiased;}
/* Also deliberately global. `max-width:100%` is a guard rather than a style —
   it stops an oversized image breaking out of whatever contains it, and no
   brand wants the opposite. Confirmed by measurement rather than taste: scoping
   it alongside the rest took `img.wpm-logo` on /get-a-quote from max-width:100%
   to none, i.e. the change introduced an overflow risk on a page that had never
   opted into anything. A rule whose removal creates a defect on an uninvolved
   surface is foundational by definition. */
img{max-width:100%;display:block;}