/* ONE SPINE chrome (tasks.id=1454) — identity row + section spine + back bar.
   This file owns ALL chrome styling. app.css (the care-side regression-sensitive
   sheet, shared by every care surface including the kiosk grid) stays byte-untouched;
   its md5 is part of the deploy contract. Every selector here is chrome-namespaced
   (.chrome-id / .spine / .backbar) so nothing in app.css can be shadowed.
   Vocabulary reuses app.css's own tokens: the CSS vars, the radii, and the .pick
   checked treatment (accent border + #e8f0ea fill + inset ring) for "you are here".
   Tap targets are >=44px and nothing is hover-only (tremor rule). Section words are
   template text ("Care") displayed uppercase HERE (Vera spec: CARE · HIRING · ADMIN)
   so a walk-through rename stays a one-word template edit. */

/* Identity row — sticky like the old header.top so who-you-are + Leave stay in
   reach; the spine + back bar scroll with the page (vertical space rule: the
   permanent chrome is ONE row). */
.chrome-id{display:flex;align-items:center;gap:10px;padding:6px 12px;background:var(--card);
  border-bottom:1px solid var(--line);position:sticky;top:0;z-index:5}
.chrome-id .brand{display:inline-flex;align-items:center;min-height:44px;
  font-weight:700;color:var(--ink);text-decoration:none}
.chrome-id .who{flex:1;min-width:0;text-align:right;font-size:15px;color:var(--muted)}
.chrome-id .leave{display:inline-flex;align-items:center;justify-content:center;flex:none;
  min-height:44px;min-width:44px;padding:6px 14px;border:2px dashed var(--line);
  border-radius:10px;background:var(--card);color:var(--muted);font-size:15px;
  font-weight:600;text-decoration:none}

/* ===== S6 (tasks.id=1467, item 7) — PER-SECTION ACCENTS ====================
   Dan declined this at decisions.id=901 in favour of the plain solid chip, then USED the
   site and changed his mind (decisions.id=907). Vera's constraints still govern and are
   not optional, so both are satisfied by construction:

   1. NEVER COLOUR-ONLY. The colour is the third cue, not the first. The section word is
      still written out in the chip, the current section is still a SOLID-INVERTED chip
      (S3/M2), and the screen title still names the screen in words (S4/M1). Turn every
      colour off and nothing is lost. The accent RIDES ON the two cues that already
      shipped; it does not replace either.

   2. LUMINANCE, NOT MERELY HUE — so it survives greyscale and works for a colour-blind
      reader. MEASURED, not asserted (WCAG relative luminance; CIE L* is the greyscale
      lightness a monochrome reader actually sees):

        section  fill      L*     white label ON the fill   fill vs the white chrome row
        Hiring   #163a5f   23.7   11.64 : 1                 11.64 : 1
        Care     #2e5d43   35.6    7.60 : 1                  7.60 : 1   (unchanged)
        Admin    #96601c   45.5    5.27 : 1                  5.27 : 1

      The three are ~10-12 L* points apart, which is a clear step in greyscale. Every
      label passes SC 1.4.3 (>= 4.5:1 for this 15px bold text — it is NOT "large text",
      so 4.5 is the bar, not 3.0), and every fill passes SC 1.4.11 (>= 3:1) as a
      non-text state cue against the white chrome row.
      Care is deliberately UNCHANGED: the care side is the regression-sensitive one and
      moving its colour would repaint every screen an aide sees for no gain.

   3. WHY --sec IS SET ON BOTH THE BAR AND EACH ITEM. The bar-level value is the CURRENT
      section (it paints the band under the spine). The item-level value is that ITEM's
      OWN section, and it overrides within the item — which is why the Hiring badge stays
      Hiring-blue while you are standing in Care, instead of being repainted green and
      lying about which section it belongs to.

   4. WHERE IT DOES **NOT** GO: the back link stays --accent, and the screen title stays
      --ink. Both are read as text, and re-tinting text per section buys nothing that the
      chip and the band do not already say while costing contrast on the two things Dan
      reads at arm's length. If Dan wants a designed palette rather than a defensible one,
      that routes to Lena — these are the three variables she would change.

   ⚠️ app.css is byte-frozen (its md5 is in the deploy contract), so --sec lives here.
   Both selector forms are chrome-namespaced; nothing outside .spine can match them. */
.spine.sec-care,   .spine .sec-care  {--sec:#2e5d43}
.spine.sec-hiring, .spine .sec-hiring{--sec:#163a5f}
.spine.sec-admin,  .spine .sec-admin {--sec:#96601c}

/* Section spine — 3 items max, one row even at 390px.
   S6: the 1px neutral rule under the bar becomes a 3px band in the CURRENT section's
   accent — the glanceable "which part of the site am I in" cue at iMac distance, where a
   chip on a 1440px-wide row is small. Costs 2px of height, once, on chrome screens. */
.spine{display:flex;gap:8px;padding:8px 12px;background:var(--card);
  border-bottom:3px solid var(--sec, var(--line))}
.spine a,.spine .here{display:inline-flex;align-items:center;justify-content:center;
  min-height:44px;min-width:44px;padding:6px 16px;border:2px solid var(--line);
  border-radius:10px;background:var(--card);color:var(--ink);font-size:15px;
  font-weight:700;letter-spacing:.06em;text-transform:uppercase;text-decoration:none}
/* S3 (tasks.id=1457, Vera M2 per decisions.id=901): the current section is a
   SOLID-INVERTED chip — filled --accent, --accent-ink text (the .btn.primary
   vocabulary) — replacing the thin outline that failed Dan at arm's length.
   WCAG 1.4.11: #2e5d43 against the white chrome row is ~7.6:1 (>= 3:1), and the
   label text on the fill is the same ~7.6:1 (>= 4.5:1). Luminance cue, not a hue
   cue — survives grayscale. The chip is a STATIC <span>, never a link (base.html).
   S6 (tasks.id=1467, item 7): the fill is now the SECTION's accent (--sec) instead of
   the one app-wide --accent. The INVERSION — solid fill, light label — is unchanged and
   is still what carries the state; only which dark colour fills it moved. The fallback
   to --accent keeps this rule correct if a future section item ships without a class. */
.spine [aria-current="page"]{border-color:var(--sec, var(--accent));
  background:var(--sec, var(--accent));color:var(--accent-ink)}

/* S4 (tasks.id=1458, D8 per decisions.id=899 OPEN 4): the "(N new)" badge that the
   home page's Hiring link used to carry (deleted in S3/D7). It rides INSIDE the spine
   item, so it is emitted by exactly the markup the show_hiring gate already wraps —
   an aide or a kiosk tap renders neither the item nor the badge (absence, not a
   disabled state). Never colour-only: it is a NUMBER in a pill.
   Contrast both ways: accent fill + accent-ink text on the plain chip (~7.6:1), and
   inverted (accent-ink fill + accent text) on the current-section chip, which is
   itself accent-filled — so the badge stays legible on either background.
   S6 (tasks.id=1467, item 7): the badge takes the HIRING accent from its own item, not
   the current section's, so it does not change colour depending on which screen you are
   standing on. Both ways round still clear 4.5:1 — #163a5f on white and white on
   #163a5f are both 11.64:1. */
.spine .badge{display:inline-flex;align-items:center;justify-content:center;
  min-width:24px;height:24px;margin-left:7px;padding:0 6px;border-radius:12px;
  background:var(--sec, var(--accent));color:var(--accent-ink);font-size:14px;
  font-weight:700;letter-spacing:0}
.spine [aria-current="page"] .badge{background:var(--accent-ink);
  color:var(--sec, var(--accent))}

/* S4 (tasks.id=1458, Vera M1 V2 per decisions.id=901) — THE SCREEN-TITLE ROW.
   Dan's "(b) not knowing where I am": the app now SAYS where you are, in words, in one
   fixed place on every chrome screen. V2 layout = the title shares the back-bar row, so
   on every screen that declares a parent (all non-home screens after S2) it costs ZERO
   extra vertical space; only the three section homes gain a line.
   `margin-left:auto` keeps the title in the SAME place (hard right) whether or not a
   back link is present — a cue that moves is not a location cue. If the pair is too wide
   for 390px the row wraps and the title keeps its side.
   It is the LARGEST text in the chrome on purpose (21px vs the 18px wordmark, 16px back
   link, 15px spine/who/Leave): Dan reads this at arm's length on a 390px phone.
   Screen names are stored as renameable mixed-case template text and DISPLAYED uppercase
   here, exactly like the spine words — an OPEN-6-style rename stays a one-word edit.
   It is pure DISPLAY: no href, no tap target, no cross-section link (ruling 900). */
/* S6 (tasks.id=1467, item 10 — "on the big shared computer the screen name sits far to
   the right, away from the content"). It did: this row spanned the whole viewport while
   .wrap is a 760px column centred in it, so at 1440px the title sat ~340px clear of the
   content it names, with white space between them. The row now takes the SAME max-width,
   centring and horizontal padding as .wrap (app.css: max-width 760, margin auto, padding
   16; `*{box-sizing:border-box}` so the inner edges line up exactly), which pins the
   title to the right edge of the COLUMN instead of the right edge of the screen.
   ⚠️ This does NOT weaken the S4 rule that the cue must not move: it is still hard right,
   still in the same place on every screen, still `margin-left:auto`. It is anchored to a
   different (better) edge. At 390px the viewport is narrower than the column, so the only
   change on a phone is 12px -> 16px of padding, which ALIGNS the back link and the title
   with the body text they sit above rather than being 4px inside it. */
.screenbar{display:flex;align-items:center;flex-wrap:wrap;gap:0 12px;
  max-width:760px;margin:0 auto;padding:2px 16px 0}
.screentitle{margin-left:auto;display:inline-flex;align-items:center;min-height:44px;
  font-size:21px;font-weight:800;letter-spacing:.05em;text-transform:uppercase;
  color:var(--ink);line-height:1.15}
/* S6 (tasks.id=1467, item 10 — an applicant's name rendered in the bar's all-caps style
   "looks like shouting on a person's name").
   The uppercase treatment is right for the SECTION and SCREEN words, which are labels;
   it is wrong for a proper noun. A template whose screen title is a PERSON'S NAME opts
   out with `{% set screen_title_plain = true %}` — currently hiring/applicant.html, the
   only screen whose title is a human being. The letter-spacing drops with it: .05em is
   there to open up all-caps and it makes mixed-case text look stretched. */
.screentitle.plain{text-transform:none;letter-spacing:.01em}

/* Named-parent back link — one slim row, only on screens that declare a parent. */
.backbar{padding:0}
.backbar a{display:inline-flex;align-items:center;min-height:44px;padding:2px 10px 2px 2px;
  color:var(--accent);font-size:16px;font-weight:600;text-decoration:none}

/* ===== S4 (tasks.id=1458) — D5 TAP-TARGET CONFORMANCE =====================
   Vera §1.3: every nav/action target >= 44x44 CSS px (WCAG 2.2 SC 2.5.5 AAA, chosen
   over the 24px SC 2.5.8 floor because Dan has an input tremor), and adjacent targets
   get dead space so a tremor near one control cannot fire its neighbour.
   WHY THESE LIVE HERE: `app.css` is the care-side regression-sensitive sheet and is
   byte-frozen (its md5 is part of the deploy contract), so chrome.css — already loaded
   by every screen that extends base.html — is the only shared sheet available. The two
   rules below that are NOT chrome-namespaced (`.btn.compact`, `.rowlink`) are additive
   MODIFIERS: nothing matches them until a template opts in, so no existing element can
   move. Single-screen layout fixes stay template-local (the D6 admin-table and
   .dosestat precedents) rather than being generalised here. */

/* The who-chip was an 18px-tall tap target on EVERY care screen (measured 129x18 at
   390px). The obvious fix — inline-flex with min-height:44px — MEASURED at +21px on the
   sticky identity row of every screen in the app, which loses against Dan's recorded
   vertical-space preference. So the hit area is grown with padding and the LAYOUT is
   given back with an equal negative margin: the painted/tappable box is 141x44, the
   line box is still 18px, and the identity row measures 57px — byte-for-byte the
   pre-S4 height. Verified at 390px: hit box 141x44, right edge 280px, Leave starts at
   296px, so the two targets keep 16px of dead space between them. */
.chrome-id .who a{display:inline-block;padding:13px 6px;margin:-13px -3px;
  line-height:18px}

/* Micro-buttons: the app had .btn overridden inline to 36/38/40px in five templates
   (admin roster + med rounds, home flag Dismiss, the flash Undo, export Revoke,
   applicant field-verify). One modifier replaces every one of those inline styles.
   NOTE: this modifier deliberately does NOT touch font-size. An earlier draft set 16px
   and the pixels showed the label shrinking from .btn's 19px — the wrong trade for a
   60+ reader at arm's length. It grows the target and leaves the type alone. */
.btn.compact{min-height:44px;width:auto;padding:6px 12px}

/* List rows whose only target is the person's name — the hiring queue, the dashboard's
   "Waiting on you", gap-match, archive, retention. Measured 21px tall; these are the
   hiring coordinator's primary navigation on her daily screen. */
.rowlink{display:inline-flex;align-items:center;min-height:44px;padding:0 6px 0 0}