/* ============================================================================ nav.css — THE PLATFORM NAVIGATION STRIP (`pnav`). ONE implementation, two apps. Spec: docs/Platform_Navigation_SSO_Spec_2026-09-08.md §2–§3 (Lincoln's rulings ① one strip on every page of both apps, ② built from the promoted design system). Served by sitewalk-server at GET /sitewalk/static/nav.css and included by BOTH the Sitewalk pages (whose `page()` renders the markup server-side) and the board templates (where nav.js builds it into #platform-nav). ⛔⛔ EVERY COLOUR, SIZE AND WEIGHT BELOW COMES FROM design/design-system/tokens.css AND NOTHING IS INVENTED (ruling ②, design/README.md §1.0). The literals in the `var(--token, LITERAL)` fallbacks are the tokens.css values verbatim — they exist because the BOARD pages define these custom properties in their own :root (they inject board_css_primitives(), which lifts board_v2.html's :root, which was itself extracted from the same north-star winner) while SITEWALK pages define none of them. So on the board the strip inherits the page's tokens; on Sitewalk it falls back to the identical tokens.css value. ⛔ Never "simplify" a fallback to a hex you like better: that is the recorded T1/T1b/T2-prompt-v1 baseline-anchoring failure, one surface further out. ============================================================================ */ /* The bar's height is published as a custom property because TWO other stylesheets have to leave room for it: `body > header` below (every app's own sticky header) and board_v2.html's full-height flex body. ⚡ Both read it with a `0px` fallback, so if THIS FILE FAILS TO LOAD (sitewalk-server down) the property is undefined, the fallback applies, and every page lays out exactly as it did before the strip existed — spec §3's "a board page must still render". */ :root { --pnav-h: 44px; } /* --- the box --------------------------------------------------------------- */ /* On Sitewalk the