/*
 * The presentation constants. **Configuration, not a bag of numbers** — every value carries the reason
 * it holds that value and, where one exists, the measurement that set it.
 *
 * ⚠️ **Nothing about puzzles is in here, and nothing here is in `forge/`.** §33 keeps the service
 * ignorant of generating and the forge ignorant of screens. The domain constants — roster caps, the
 * zero-density gate, stall targets, forward inventory — live in `forge/src/boxscore_domain/__init__.py`,
 * and the two files never import each other. A single shared constants module would be the first thing
 * to break that boundary, imported by both sides for the convenience of one.
 *
 * ⚠️ **Separate from `board.css` on purpose.** These are decisions; that file is the rules that spend
 * them. Mixed together, a colour argued over for a paragraph sat three lines from a margin nobody
 * chose, and the two read as equally settled.
 *
 * The width arithmetic every number below descends from (§6):
 *   375 viewport − 2×8 margin = 359 available
 *   359 − 24 slot − 66 label  = 269 for six data columns = 44.8px each
 * That is the 44px touch target with 0.8px to spare. **A seventh column does not fit** and cannot be
 * added; the label column is what would have to give, and it is already at seven characters.
 */

:root {
  /* ⚠️ **Plex for the board, Roboto for two glyphs.** Plex gives `1` a foot serif and this board renders
     `1` constantly; Roboto's is a bare stem. Plex's `⅓` and `⅔` are cramped to illegibility at keypad
     size and Roboto's are clean. Those two characters are borrowed by `unicode-range`, scoped to
     U+2153-2154, rather than letting two keys decide the whole board.

     This is not the *two families* §6's reasoning rules out — that is about a display face competing
     with a body face for 375 pixels, and a fallback that can set no word competes with nothing. */
  --face: "IBM Plex Sans Condensed";
  --cell: 44px;
  --slot-column: 24px;
  --label-column: 66px;
  --board-margin: 8px;

  --ink: #16181d;
  --paper: #ffffff;
  --rule: #d3d7de;
  /* ⚠️ **The grid's own line, separate from `--rule`.** They are the same value on paper and they are
     not the same decision: `--rule` separates *blocks* — a section from a footer, a keypad from a
     board — while this draws the grid every cell sits in, and the grid has to hold a dark board
     together where a block separator does not. Measured in both schemes; see the dark override. */
  --grid-line: #d3d7de;
  --rule-strong: #9aa1ad;
  --given: #16181d;
  /* ⚠️ **What the player wrote, and nothing else.** This token used to paint three things: the value
     in a cell, the slot references beside a live footnote term, and the `?` marks. Only the first is
     the player's handwriting — the other two are the board stating what it knows and does not know.
     Painting all three alike would have made the board claim the player had written its own unknowns. */
  /* ⚠️ **Not red, and the same blue the footnote line already uses.**

     Red is the one colour every player reads as *this is wrong*. Spent on "I typed this" it is
     unavailable for errors, and an error is the one thing no other colour can carry. It was also
     false twice over: in a deduction puzzle what the player types is not provisional — once it
     balances it is as settled as what was given — so red said *tentative* and said *incorrect*.

     One blue for both meanings rather than two similar ones. Two blues a shade apart, carrying
     different meanings, is worse than one carrying both: the eye files them as the same category and
     then discovers they are not.

     ⚠️ **The alternative was the givens' black in bold, and the totals row is what settled it.** Weight
     cannot mark an entry there, because the totals row is bold already — and the real packages erase
     batting and pitching totals, so it is an input surface, in the one row every column sum closes on.
     Colour works everywhere; weight had a hole exactly where the board is most consulted. */
  --entered: #1b57c4;
  /* ⚠⚠ **A third ink, because the finished board has to show what the player did not deduce.**
     Black is given, blue is theirs, and a hinted cell is neither: the board handed it over. Painting
     it blue would make the finished sheet claim work they did not do, which is the one thing the
     reveal exists to show honestly — and painting it black would hide the spend from the person
     looking at their own result.

     ⚠️ **Violet, and the choice is by elimination rather than taste.** Red is spent on *wrong*
     (`--wrong-ground`), amber on the selection, green is the scoreboard, blue is the player's. Violet
     is the only hue left that is not already carrying a meaning on this board. */
  --hinted: #6b3fa0;

  /* ⚠⚠ **The one place red is spent, and it is a badge rather than coloured text.**
     `--entered` above records why red is not available for the player's handwriting: it is the one
     colour every player reads as *this is wrong*, and an error is the one thing no other colour can
     carry. This is that spend.

     ⚠️ **It was `color: #8a1c12` on whatever ground was behind it, and that is 9.31:1 on light paper
     and 1.91:1 on the dark keypad.** Measured, after the operator said it did not read in the dark. A
     colour chosen against one ground and applied to both is the same shape as a justification reused
     rather than re-derived — and dark red on near-black is not a weaker version of the message, it is
     the absence of one.

     A badge carries its own ground, so it does not depend on what is behind it. White on `#b3261e` is
     **6.54:1**, the same in both schemes, and it is deliberately not overridden in the dark block for
     the reason the scoreboard is not: a warning is an object, and an object does not change paint when
     the room does. */
  --wrong-ground: #b3261e;
  --wrong-ink: #ffffff;
  --unknown: #1b57c4;
  --blank: #f4f6f9;
  --selected: #ffe9a8;
  --selected-rule: #c99a12;
  /* The row and the column a selected cell shares an equation with. **One tint for both**, from the
     selection's own family, so the two lines read as *what this cell is connected to* rather than as
     two kinds of thing. The version before this gave them separate colours on the reasoning that the
     row identity and the column sum are different relations — true, and not what the highlight is for:
     it answers *where do I look*, not *which equation is this*. Operator's call, and the right one. */
  --peer: #f6efe2;
  --muted: #6b7280;
  /* ⚠️ **Neutral, and deliberately not the scoreboard's green.** The green belongs to what is *given* —
     the scoreboard and the section headers, the parts the player never touches. The keypad is the
     opposite: it is where the player acts. One colour across both would say they are the same kind of
     object. It is also a third of the screen, and a third of the screen in saturated green competes
     with the board, which is where attention belongs. */
  --keypad: #e6e8ec;
  --key: #ffffff;
  --key-ink: #16181d;

  /* The scoreboard. One colour, named for where it comes from, so a future change is a decision about
     the object rather than about a hex value nobody can place. */
  --fenway: rgb(83, 120, 108);
  --scoreboard-ink: #f2f6f4;
  --scoreboard-dim: #b9cdc5;
  --scoreboard-rule: rgba(242, 246, 244, 0.35);

  /* ⚠️ **Chosen by rendering, and the losers are deleted.** Two of the three lived here behind a
     `data-header` attribute so they could be compared on the real board; keeping them would be three
     things every future change has to hold working. The finding worth remembering: the first two
     candidates were a near-black green and a near-black grey, and **at near-black the hue does not
     read** — they were indistinguishable in situ, so "take it from the scoreboard's family" bought
     nothing until the green was allowed to be green. */
  --header-ground: #1f362e;
  --header-ink: #ffffff;
}

/* ---- the line score's narrow-device breakpoint -------------------------------------------------
   359px, i.e. below the 375px the board is designed to. **Measured, not chosen**: at 320px a
   twelve-inning line score at 13px leaves 2.7px between a two-digit R and a two-digit H — where
   `11 16 2` starts reading as `1116 2`. At 11px the gap is 4.9px and they separate comfortably.

   ⚠️ **This is the exception to "the board is identical on all screens" and it is deliberate.** It is
   type size, not content — every cell, every clue and every given is the same. Eleven innings would
   need no exception at all (4.0px at 13px on 320px); twelve does. The cap and this rule were decided
   together.

   ⚠️ Not a custom property, because a media query condition is evaluated before the cascade and
   cannot read one. It is documented here, where presentation constants live, and spelled once in
   `board.css`. §33 keeps it out of `forge/` entirely: the inning cap it supports is a domain fact and
   lives in `boxscore_domain`, but a viewport width is presentation and the forge must not know it. */

/* ⚠️⚠️ **The dark palette lives here, and it used to live in `board.css`.** (v36-P2-13)
   `tokens.css` defined light values only, so in dark mode the flow read landing (dark) → *How to
   play* (**a full-brightness white page**) → board (dark). The tutorial deliberately does not link
   `board.css` — its board is a made-up illustration and borrowing the real board's rules would mean
   fighting them — and that decision silently took the palette with it, which is written down nowhere.

   It is also what both files' own charters already said: this is the constants file, and an entire
   palette of decided values was sitting outside it. Every page links `tokens.css`. */
@media (prefers-color-scheme: dark) {
  :root:not([data-theme="light"]) {
    --ink: #e6e8ec;
    --paper: #14161a;
    --rule: #2c3038;
    --rule-strong: #565d69;
    /* ⚠️ **Lighter than `--rule`, and that is the whole reason the token is separate.** On paper the
       two are the same value; on a dark board `#2c3038` against a `#14161a` ground is a line you have
       to look for, and the grid is precisely the element that stops a dark board becoming a wall.

       ⚠⚠ **Set by parity with the light mode, not by a contrast threshold — and reaching for the
       threshold first was the mistake.** A grid rule is structure between two data cells, not the
       boundary of a control, and the light board proves the point: `#d3d7de` on white is **1.44:1**
       and reads perfectly. Sizing the dark line to 3:1 would have made it heavier than the version
       that already works. This value is **1.61:1 against the given ground and 1.49:1 against the
       editable one**, both a little stronger than light, which is the right place for a mode where the
       line does more of the separating. Measured, then looked at in both. */
    --grid-line: #363b45;
    --given: #e6e8ec;
    --entered: #7fa8ff;
    /* Lightened for the dark ground like `--entered`, and kept the same distance from it: the two have
       to be told apart at a glance on a finished board, which is the only place they sit side by side. */
    --hinted: #c4a2f5;
    --unknown: #7fa8ff;
    --blank: #1b1e24;
    --selected: #4a3c12;
    --selected-rule: #d8ab26;
    --peer: #2a2418;
    --muted: #9aa1ad;
    --keypad: #16181c;
    --key: #1b1e24;
    --key-ink: #e6e8ec;
    /* The scoreboard keeps its colour in the dark: it is a physical object, and a physical object does
       not change paint when the room does. Only the surround moves. */
    --header-ground: #16281f;
  }
}