/*
 * The host page's own stylesheet, not the shell's.
 *
 * It exists because the shell sizes itself as `block-size: 100%` of its container, and something has to
 * give `html`/`body` a definite height for that chain to resolve — `container-type: size` needs a
 * definite block size or the container measures zero.
 *
 * It is **not** imported from `main.tsx`, deliberately: page layout is the host's concern, not the
 * shell's, and the host owns viewport units. It is a `<link>` from the same origin, so it survives a
 * `style-src 'self'` header.
 *
 * ⚠️ **Served to both host pages, and it has to be.** This lived in `src/styles/` and was linked only
 * from `frontend/index.html`, so the *server-rendered* shell — the production entry — had no page
 * sizing at all. The effect in a real browser: `.host { block-size: 100% }` resolved against an
 * auto-height `<main>`, collapsed to zero, `.root { overflow: hidden }` clipped the whole shell, and
 * every control reported "outside of the viewport" and could not be clicked. The page looked almost
 * right and was completely inert. Found by driving it, not by reading it.
 *
 * It lives in `public/` so Vite serves it in dev and copies it to `dist/` for the Python tier to
 * serve at `/static/host.css`. One file, one id, both pages.
 */
html,
body {
  block-size: 100%;
  margin: 0;
  background: #0e0c0a;
  /*
   * `dark`, NOT `dark light`. This one keyword shipped the worst defect on the page.
   *
   * `color-scheme: dark light` reads like "dark, falling back to light". It does not mean that.
   * Per CSS Color Adjust the *used* scheme is whichever entry matches the USER's preference — so on
   * a phone set to light mode it resolves to **light**, the UA paints its white `Field` colour
   * behind every input, and the shell's own `color: inherit` (#f6efe6) lands on it.
   *
   * Measured on the live page: **1.14:1**, against a 4.5:1 requirement. The guest's own selection
   * was effectively invisible. The page background is hard-coded dark two lines above, so offering
   * the UA a light option was never coherent.
   *
   * A light-palette tenant sets `--hg-color-scheme: light` and `.root` below picks it up; this
   * declaration is only the floor for the un-themed host page.
   */
  color-scheme: dark;
}

/* The id the server-rendered shell publishes. */
#honeyguide-root {
  block-size: 100%;
}

/*
 * The property's own header CTA, right-aligned — the shape that makes 2.4.11 answerable.
 *
 * ⚠️ **Its position is the whole point of it, so do not move it without re-reading the measurement
 * in `styles/surface.module.css`.** Every fixed surface of ours is right-aligned, so a
 * left-aligned host control can never be obscured by the dock at any height and a probe over one
 * answers the wrong question. Measured in Chromium at 1440x1284: these links sit at x1275-1408,
 * y24 — inside the band the dock's block-axis ceiling keeps clear, and entirely inside the dock's
 * box the moment that ceiling is removed.
 *
 * `position: absolute` rather than `fixed`: the host owns its own layout, and a fixed header of the
 * host's would be a second confound in a measurement about *our* fixed box.
 *
 * ⚠️ **THIS FILE SHIPS TO GUESTS, and the rule above is inert there only because no production
 * markup carries the class.** `api/templates/shell.html` links it on the served `/plan` page, so it
 * is not the dev harness's stylesheet — it is the one stylesheet this repo puts on the property's
 * own domain. It also ships **unminified, comments intact**: measured 2026-09-10, `dist/host.css`
 * is 3,386 bytes and `grep -c "2.4.11"` on it returns 3. `deploy-spa.sh` excludes `index.html` from
 * publication for exactly this reason and the same reasoning has never been applied here. So
 * anything added below must be safe on a guest's page *and* safe to read — and a stand-in-only rule
 * belongs behind this note rather than beside the sizing rules a guest actually uses.
 */
.hostNav {
  position: absolute;
  inset-block-start: 24px;
  inset-inline-end: 32px;
  display: flex;
  gap: 16px;
}

.hostNav a {
  color: #f5efe6;
  text-decoration: none;
}


/*
 * ── The demonstration notice ────────────────────────────────────────────────────────────────
 *
 * Rendered by the shell template, outside `#honeyguide-root`, for a tenant whose manifest says
 * `demonstration=True`. It is styled here rather than in a CSS module for the reason it is
 * *placed* there: it is a statement about the artefact, not a part of the planner, and the React
 * tree neither renders it nor can suppress it. A CSS-module class would also need the hashed
 * `.scope` ancestor, which this element is deliberately outside of.
 *
 * ⚠️ **`--hg-*` with literal fallbacks, and the fallbacks are the point.** The tenant bundle is
 * applied through the CSSOM to `.scope`, so custom properties do not inherit *up* to this element:
 * every `var()` here resolves to its fallback in practice. They are written as tokens anyway so
 * that the day this moves inside the scope it inherits the property's palette instead of a
 * hard-coded one — and the fallbacks are the shell's own dark ground, which is what `html` above
 * is painted in, so the line is legible before any bundle has loaded. Measured against the shipped
 * `#0e0c0a`: `#8a8580` on it is 5.34:1, clear of 1.4.3's 4.5:1 for body text at this size.
 *
 * Not `position: fixed`. It sits after the mount in normal flow, so it can never obscure a control
 * (2.4.11) and it takes no space from the 100%-height shell above it.
 */
.hg-demonstration {
  margin: 0;
  padding: 0.75rem 1rem calc(0.75rem + env(safe-area-inset-bottom));
  background: var(--hg-color-canvas, #0e0c0a);
  color: var(--hg-color-ink-quiet, #8a8580);
  font-family: var(--hg-font-label, ui-sans-serif, system-ui, -apple-system, Segoe UI, Roboto, sans-serif);
  font-size: 0.75rem;
  line-height: 1.4;
  letter-spacing: var(--hg-label-tracking, 0.09em);
  text-transform: uppercase;
  text-align: center;
}