@7365admin1/layer-common 3.2.2-staging.80 → 3.2.2-staging.81

package/assets/css/shell.css

@@ -0,0 +1,258 @@
+/**
+ * THE RESPONSIVE SHELL PRIMITIVES.
+ *
+ * The prototype is not responsive. Rendered at 360 and 768 its sidebar stays a
+ * fixed 252px, the content column is clipped, and the hamburger only hides the
+ * rail instead of overlaying it - so there is no reference to copy and this
+ * behaviour is designed rather than transcribed. It is built from the same
+ * tokens, so nothing here introduces a colour, a size or a radius of its own.
+ *
+ * Breakpoints, and why these:
+ *   >= 1024   the layout the design draws: 252px rail beside the content.
+ *   < 1024    the rail becomes an overlay drawer behind the hamburger. 252px
+ *             out of 1024 is a quarter of the screen; below that the content
+ *             column stops being usable before the rail stops fitting.
+ *   < 768     one column. Filter rows stack, the breadcrumb truncates.
+ *   < 600     modals go near-full-screen with a 16px inset.
+ *
+ * TWO KINDS OF RULE LIVE HERE, and the distinction is deliberate:
+ *
+ *   1. Token adjustments at a breakpoint. These change what `--content-pad-x`
+ *      and friends MEAN on a small screen. They reach every surface that reads
+ *      the tokens and touch nothing that does not, which is why the padding is
+ *      done this way instead of as a rule on someone else's markup.
+ *
+ *   2. Named primitives (`.app-shell`, `.app-topbar`, `.filter-row`,
+ *      `.table-scroll`, `.modal-body`). These are what Phase 2 onwards builds
+ *      the shell out of. NOTHING in Phase 1 applies them to a module screen -
+ *      the primitives exist and are reviewable; rolling them across the
+ *      product is the next phase's work.
+ *
+ * The one thing here that DOES reach the existing product is the touch-target
+ * rule at the bottom, and that is on purpose - see the note above it.
+ */
+
+/* ------------------------------------------------------------------ */
+/* 1. What the tokens mean on a smaller screen.                        */
+/* ------------------------------------------------------------------ */
+
+@media (max-width: 1023.98px) {
+  :root {
+    --content-pad-x: 20px;
+    --content-pad-y: 18px;
+  }
+}
+
+@media (max-width: 767.98px) {
+  :root {
+    --content-pad-x: 16px;
+    --content-pad-y: 16px;
+    --content-pad-bottom: 28px;
+    /* The row keeps its vertical rhythm and gives back side padding, which is
+       what buys a table its columns before it has to scroll. */
+    --cellpad-x: 14px;
+    --grid-gap: 10px;
+  }
+}
+
+@media (max-width: 599.98px) {
+  :root {
+    --content-pad-x: 14px;
+    /* 22px on a 360px screen is a headline that wraps to three lines. */
+    --fs-h1: 19px;
+    --fs-kpi: 26px;
+  }
+}
+
+/* ------------------------------------------------------------------ */
+/* 2. The primitives.                                                  */
+/* ------------------------------------------------------------------ */
+
+/**
+ * The shell. A flex row at desktop; at < 1024 the rail is out of flow (it is
+ * an overlay) and the content column takes the full width.
+ *
+ * `min-width: 0` on the content column is not decoration. A flex child's
+ * default `min-width: auto` refuses to shrink below its content, so ONE wide
+ * table pushes the whole column past the viewport and the page scrolls
+ * sideways with the sidebar attached. This is the line that stops that.
+ */
+.app-shell {
+  display: flex;
+  min-height: 100vh;
+  background: var(--bg);
+}
+
+.app-shell__rail {
+  flex: 0 0 var(--sidebar-w);
+  width: var(--sidebar-w);
+  background: var(--sidebar);
+  border-right: 1px solid var(--border);
+}
+
+.app-shell__content {
+  flex: 1 1 auto;
+  min-width: 0;
+  display: flex;
+  flex-direction: column;
+}
+
+.app-content {
+  flex: 1 1 auto;
+  min-width: 0;
+  padding: var(--content-pad-y) var(--content-pad-x) var(--content-pad-bottom);
+}
+
+@media (max-width: 1023.98px) {
+  .app-shell__rail {
+    display: none;
+  }
+}
+
+/** The 58px top bar. Its two ends are fixed; the middle is what gives way. */
+.app-topbar {
+  display: flex;
+  align-items: center;
+  gap: 12px;
+  height: var(--topbar-h);
+  min-height: var(--topbar-h);
+  padding: 0 var(--content-pad-x);
+  background: var(--card);
+  border-bottom: 1px solid var(--border);
+}
+
+.app-topbar__crumb {
+  flex: 1 1 auto;
+  min-width: 0;
+  font-size: var(--fs-breadcrumb);
+  color: var(--muted);
+  /* Truncates rather than wrapping: a two-line breadcrumb would break the
+     58px bar, and the site name is the half worth losing first. */
+  overflow: hidden;
+  white-space: nowrap;
+  text-overflow: ellipsis;
+}
+
+.app-topbar__actions {
+  flex: 0 0 auto;
+  display: flex;
+  align-items: center;
+  gap: 8px;
+}
+
+/** The hamburger only exists where the rail does not. */
+.app-topbar__toggle {
+  display: none;
+}
+
+@media (max-width: 1023.98px) {
+  .app-topbar__toggle {
+    display: inline-flex;
+  }
+}
+
+/**
+ * A filter row wraps before it stacks. Wrapping keeps two short selects side
+ * by side on a 768px tablet, where forcing them full-width would waste half
+ * the row; below 600 there is no room for two, so they stack.
+ */
+.filter-row {
+  display: flex;
+  flex-wrap: wrap;
+  gap: var(--grid-gap);
+  align-items: center;
+}
+
+.filter-row > * {
+  flex: 1 1 200px;
+  min-width: 0;
+}
+
+@media (max-width: 599.98px) {
+  .filter-row {
+    flex-direction: column;
+    align-items: stretch;
+  }
+
+  .filter-row > * {
+    flex: 1 1 auto;
+    width: 100%;
+  }
+}
+
+/**
+ * A table scrolls sideways inside its own card rather than reflowing into
+ * stacked key/value blocks. The design is a table card and its columns carry
+ * meaning by position; restacking them at 360 would be a different design, not
+ * a smaller one - and it is the kind of change rule 2 rules out. So the card
+ * edge stays put and the table moves within it.
+ */
+.table-scroll {
+  overflow-x: auto;
+  -webkit-overflow-scrolling: touch;
+  overscroll-behavior-x: contain;
+}
+
+.table-scroll > table {
+  min-width: max-content;
+}
+
+/**
+ * Modal container. 520px as designed, but never wider or taller than the
+ * viewport it has to fit inside, and the BODY is what scrolls - a modal whose
+ * whole card scrolls takes its Cancel/Submit footer off screen with it.
+ */
+.modal-card {
+  width: min(var(--modal-w), calc(100vw - 32px));
+  max-height: calc(100vh - 32px);
+  display: flex;
+  flex-direction: column;
+  border-radius: var(--r-modal);
+  background: var(--card);
+  box-shadow: var(--shadow-modal);
+}
+
+.modal-body {
+  flex: 1 1 auto;
+  min-height: 0;
+  overflow-y: auto;
+}
+
+@media (max-width: 599.98px) {
+  .modal-card {
+    width: calc(100vw - 32px);
+    max-height: calc(100dvh - 32px);
+  }
+}
+
+/* ------------------------------------------------------------------ */
+/* 3. Touch targets. This one DOES reach the existing product.         */
+/* ------------------------------------------------------------------ */
+
+/**
+ * A 36px icon button is comfortable with a mouse and a miss with a thumb.
+ * WCAG 2.2 asks for 44x44 on a touch pointer, and this is the one rule in
+ * Phase 1 that changes existing screens rather than waiting for a phase to
+ * adopt it - because it only applies on a COARSE pointer, so no desktop
+ * rendering moves by a pixel, and because leaving it to seven more phases
+ * means shipping the mobile-hostile version for all of them.
+ *
+ * `min-height`/`min-width` only, so nothing shrinks and no layout is forced.
+ */
+@media (pointer: coarse) {
+  .v-btn--icon,
+  .v-btn--size-small,
+  .v-btn--size-x-small {
+    min-height: 44px;
+    min-width: 44px;
+  }
+
+  .v-list-item {
+    min-height: 44px;
+  }
+
+  .v-selection-control__wrapper {
+    min-height: 44px;
+    min-width: 44px;
+  }
+}

package/assets/css/tokens.css

@@ -0,0 +1,220 @@
+/**
+ * PLATFORM REDESIGN - THE DESIGN TOKENS.
+ *
+ * Not one colour is written down in this file. Every colour token is an ALIAS
+ * onto the Vuetify theme variable that already holds it, and the values
+ * themselves live in `utils/theme.ts` (`PALETTE`), which `utils/theme.test.ts`
+ * measures. Two systems, one source of truth, flowing one way:
+ *
+ *     PALETTE -> LIGHT_THEME/DARK_THEME -> --v-theme-* -> --bg, --card, --muted
+ *
+ * The aliases are declared on `[class*="v-theme--"]` rather than on `:root`
+ * ON PURPOSE. Vuetify puts that class on the application root AND on every
+ * `<v-theme-provider>` subtree, so `--card` read inside the `plain-dark`
+ * layout, or inside a dialog that forces a theme, resolves to THAT subtree's
+ * theme. Declaring the aliases at `:root` - or flipping a class on `<body>`,
+ * which is how the prototype does it - would have painted those subtrees with
+ * the page's theme instead.
+ *
+ * Values below that are NOT colours (opacity overlays, shadows, the type
+ * scale, the spacing scale) have nothing on the Vuetify side to alias, so they
+ * are stated here. The theme-dependent ones are stated twice, once per theme.
+ */
+
+/* ------------------------------------------------------------------ */
+/* Colour tokens - aliases only.                                       */
+/* ------------------------------------------------------------------ */
+
+[class*="v-theme--"] {
+  /* Surfaces */
+  --bg: rgb(var(--v-theme-background));
+  --sidebar: rgb(var(--v-theme-sidebar));
+  --card: rgb(var(--v-theme-surface));
+  --border: rgb(var(--v-theme-border));
+
+  /* Text */
+  --text: rgb(var(--v-theme-text-primary));
+  --text2: rgb(var(--v-theme-text2));
+  --muted: rgb(var(--v-theme-muted));
+
+  /* Semantic status */
+  --ok: rgb(var(--v-theme-success));
+  --warn: rgb(var(--v-theme-warning));
+  --err: rgb(var(--v-theme-error));
+  --info: rgb(var(--v-theme-info));
+
+  /*
+   * The brand accent, exactly as the design specifies it. `--accent-strong` is
+   * the same colour 18% darker and is the ONLY thing a white label may sit on:
+   * white on `--accent` measures 3.23:1 in both themes. Everything else - the
+   * links, the active nav item, the tab underline, the toggle's on state, the
+   * chart lines, `--accent-soft` - uses `--accent` unchanged.
+   */
+  --accent: rgb(var(--v-theme-accent));
+  --accent-strong: rgb(var(--v-theme-accent-strong));
+  --accent-text: rgb(var(--v-theme-accent-text));
+  --accent-soft: rgba(var(--v-theme-accent), 0.12);
+  --on-accent-strong: #ffffff;
+}
+
+/*
+ * Overlays and shadows. Not colours in the Vuetify sense - an overlay is a
+ * colour AND an alpha, and a shadow is a whole box-shadow - so these are the
+ * only values restated per theme. Equal specificity to the block above, so
+ * source order decides: light first, dark second.
+ */
+[class*="v-theme--"] {
+  --hover: rgba(20, 22, 26, 0.05);
+  --thead: rgba(20, 22, 26, 0.02);
+  --shadow: 0 1px 2px rgba(16, 24, 40, 0.05);
+  --shadow-modal: 0 24px 64px rgba(10, 12, 16, 0.3);
+  --shadow-menu: 0 12px 32px rgba(16, 24, 40, 0.14);
+  --scrim: rgba(12, 14, 18, 0.5);
+
+  /* Soft status backgrounds. Stated by the design literally rather than
+     derived from the foreground, so darkening a label for AA leaves its chip
+     the colour it was drawn. */
+  --ok-bg: rgba(15, 138, 98, 0.1);
+  --warn-bg: rgba(190, 140, 25, 0.13);
+  --err-bg: rgba(207, 75, 75, 0.1);
+  --info-bg: rgba(59, 111, 212, 0.1);
+}
+
+.v-theme--dark {
+  --hover: rgba(255, 255, 255, 0.06);
+  --thead: rgba(255, 255, 255, 0.02);
+  --shadow: 0 1px 2px rgba(0, 0, 0, 0.2);
+
+  --ok-bg: rgba(65, 199, 149, 0.12);
+  --warn-bg: rgba(220, 175, 78, 0.13);
+  --err-bg: rgba(229, 115, 115, 0.12);
+  --info-bg: rgba(125, 166, 236, 0.12);
+}
+
+/* ------------------------------------------------------------------ */
+/* Type, shape and spacing - the same in both themes.                  */
+/* ------------------------------------------------------------------ */
+
+:root {
+  /*
+   * Manrope is loaded in `nuxt.config.ts` and this token names it, but NOTHING
+   * in Phase 1 sets `font-family` on the page. Switching eleven applications to
+   * a new typeface before a single screen has been rebuilt would leave the
+   * product looking half-migrated; each phase adopts the token as it rebuilds
+   * its surfaces.
+   */
+  --font-sans: "Manrope", -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
+    "Helvetica Neue", Arial, sans-serif;
+
+  /* Type scale - size / weight / letter-spacing, straight from the contract. */
+  --fs-h1: 22px;
+  --fw-h1: 800;
+  --ls-h1: -0.01em;
+
+  --fs-card-title: 15.5px;
+  --fw-card-title: 800;
+
+  --fs-kpi: 30px;
+  --fw-kpi: 800;
+  --ls-kpi: -0.02em;
+
+  --fs-table-head: 11px;
+  --fw-table-head: 800;
+  --ls-table-head: 0.07em;
+
+  --fs-cell: 13.5px;
+  --fw-cell: 600;
+  --fs-cell-dense: 13px;
+
+  --fs-nav: 13px;
+
+  --fs-section-label: 10.5px;
+  --fw-section-label: 800;
+  --ls-section-label: 0.09em;
+
+  --fs-btn: 13.5px;
+  --fw-btn: 700;
+  --fw-btn-strong: 800;
+
+  --fs-chip: 11.5px;
+  --fs-chip-lg: 12px;
+  --fw-chip: 700;
+
+  --fs-breadcrumb: 12.5px;
+
+  /* Shape */
+  --r-card: 14px;
+  --r-inner: 10px;
+  --r-inner-sm: 9px;
+  --r-inner-lg: 12px;
+  --r-tag: 7px;
+  --r-pill: 999px;
+  --r-modal: 16px;
+  --r-menu: 14px;
+
+  /* Shell metrics */
+  --sidebar-w: 252px;
+  --topbar-h: 58px;
+  --content-pad-y: 22px;
+  --content-pad-x: 26px;
+  --content-pad-bottom: 40px;
+
+  /* Controls */
+  --input-h: 40px;
+  --input-h-compact: 34px;
+  --btn-h: 40px;
+  --icon-btn: 36px;
+  --avatar: 36px;
+  --toggle-w: 38px;
+  --toggle-h: 22px;
+  --grid-gap: 12px;
+  --modal-w: 520px;
+  --menu-w: 240px;
+
+  /*
+   * Table density - the design's own knob. `--cellpad` is the comfortable row
+   * padding; put `data-density="compact"` on a table card for the dense one.
+   * The accent is the other knob the handoff asks for, and it is a value in
+   * `PALETTE` (utils/theme.ts) rather than a runtime switch, because nothing
+   * changes it at runtime yet.
+   */
+  --cellpad: 15px;
+  --cellpad-x: 20px;
+
+  --motion: 150ms;
+}
+
+[data-density="compact"] {
+  --cellpad: 9px;
+  --fs-cell: var(--fs-cell-dense);
+}
+
+/* ------------------------------------------------------------------ */
+/* Semantic status tones.                                              */
+/* ------------------------------------------------------------------ */
+
+/*
+ * The mapping from a status word to a tone lives in `utils/status.ts`, so that
+ * one list serves the chips, the dots and anything else. These classes are
+ * what that tone paints with. A chip is `.tone-*` plus its own shape.
+ */
+.tone-ok {
+  color: var(--ok);
+  --tone-bg: var(--ok-bg);
+}
+.tone-warn {
+  color: var(--warn);
+  --tone-bg: var(--warn-bg);
+}
+.tone-err {
+  color: var(--err);
+  --tone-bg: var(--err-bg);
+}
+.tone-info {
+  color: var(--info);
+  --tone-bg: var(--info-bg);
+}
+.tone-neutral {
+  color: var(--text2);
+  --tone-bg: var(--hover);
+}

package/components/Layout/Header.vue

@@ -3,7 +3,18 @@
     <v-app-bar-nav-icon v-if="!props.hideNavIcon" @click="drawer = !drawer"></v-app-bar-nav-icon>
 
     <template #append>
-      <v-btn icon="mdi-theme-light-dark" variant="text" class="mx-2" @click="toggleTheme" />
+      <!--
+        The icon now says which theme you would GET, and the choice is
+        remembered - see `composables/useThemePreference.ts`. Same button, same
+        place, same one click.
+      -->
+      <v-btn
+        :icon="current === 'dark' ? 'mdi-weather-sunny' : 'mdi-weather-night'"
+        :aria-label="current === 'dark' ? 'Switch to light theme' : 'Switch to dark theme'"
+        variant="text"
+        class="mx-2"
+        @click="toggleTheme"
+      />
 
       <v-menu offset="10px" :close-on-content-click="false">
         <template #activator="{ props }">
@@ -45,8 +56,6 @@
 </template>
 
 <script setup lang="ts">
-import { useTheme } from "vuetify";
-
 const props = defineProps({
   hideNavIcon: {
     type: Boolean,
@@ -64,11 +73,13 @@ const { redirect } = useUtils();
 
 const { APP_ACCOUNT, APP_MAIN, APP_NAME } = useRuntimeConfig().public;
 
-const theme = useTheme();
-
-function toggleTheme() {
-  theme.global.name.value = theme.global.current.value.dark ? "light" : "dark";
-}
+/**
+ * This used to be `theme.global.name.value = ...` and nothing else, so the
+ * choice was gone on the next reload - and, because these are eleven separate
+ * applications, gone again on every hop between them. The composable writes the
+ * layer's shared `theme` cookie, and `plugins/vuetify.ts` boots on it.
+ */
+const { current, toggleTheme } = useThemePreference();
 
 const { currentUser } = useLocalAuth();
 

package/components/Layout/NavigationDrawer.vue

@@ -28,9 +28,26 @@
       primary-tinted fill (see `NavigationItem.vue`); 0.12 left the fill at
       1.15:1, 0.18 is 1.44:1 light, 1.33:1 dark.
   -->
+  <!--
+    RESPONSIVE: THE RAIL BECOMES AN OVERLAY BELOW 1024px.
+
+    `permanent` was hardcoded, which is why the prototype's own behaviour - and
+    ours - was a 252px rail still sitting there on a 360px phone with the
+    content squeezed into what was left. Dropping `permanent` and naming the
+    breakpoint hands the whole behaviour to Vuetify: at >= 1024 the drawer is
+    part of the layout exactly as it is today, and below it the same drawer
+    becomes temporary, floats OVER the content with a scrim, and closes on the
+    scrim, on Escape and on a navigation.
+
+    1024 rather than Vuetify's default 1280: at 1024 the rail still leaves a
+    772px content column, which is a usable table. Below that it does not.
+
+    Nothing about the menu changes - same items, same order, same permissions,
+    same routes. Only where the panel is drawn.
+  -->
   <v-navigation-drawer
     v-model="drawer"
-    permanent
+    :mobile-breakpoint="1024"
     class="bg-brand-surface brand-drawer"
   >
     <v-list>
@@ -75,6 +92,8 @@
 </template>
 
 <script setup lang="ts">
+import { useDisplay } from "vuetify";
+
 const props = defineProps({
   navigationItems: { type: Array, required: true },
   title: { type: String, default: "" },
@@ -85,6 +104,32 @@ const emit = defineEmits(["navigate"]);
 const { drawer } = useLocal();
 const { APP_NAME } = useRuntimeConfig().public;
 const route = useRoute();
+
+/**
+ * `drawer` is shared application state and it defaults to OPEN, which is right
+ * for a rail and wrong for an overlay - a phone would load with the menu
+ * covering the page behind a scrim. So the default follows the viewport, and a
+ * user who resizes past the breakpoint gets the state that suits where they
+ * landed.
+ *
+ * Only the DEFAULT is managed here. Once the hamburger has been used, the
+ * user's choice stands until the layout itself changes underneath them.
+ */
+const { mobile } = useDisplay({ mobileBreakpoint: 1024 });
+
+watch(mobile, (isOverlay) => (drawer.value = !isOverlay), { immediate: true });
+
+/**
+ * An overlay drawer that survives a navigation leaves the scrim over the page
+ * the user just asked for. A rail must NOT close - that would be a step added
+ * to every desktop navigation.
+ */
+watch(
+  () => route.fullPath,
+  () => {
+    if (mobile.value) drawer.value = false;
+  }
+);
 const orgId = computed(() => String(route.params.org ?? ""));
 const siteId = computed(() => String(route.params.site ?? ""));
 const { useHidFaceReaderMenu } = useHidNavigation();

package/composables/useThemePreference.ts

@@ -0,0 +1,63 @@
+/**
+ * THE USER'S LIGHT/DARK CHOICE, REMEMBERED.
+ *
+ * Until now `Layout/Header.vue` flipped `theme.global.name` and wrote nothing,
+ * so the choice was gone on the next reload.
+ *
+ * A COOKIE, NOT localStorage. The handoff says "persists in localStorage", and
+ * for a single-page prototype that is right - but this product is ELEVEN
+ * applications on eleven hostnames. localStorage is per-origin, so a user who
+ * picked dark mode in Security would land on a white screen in Property
+ * Management, and again in Account, and would have to set it eleven times.
+ *
+ * A cookie written with the layer's own `cookieConfig` carries the parent
+ * domain, which is exactly how `sid`, `user` and `landing-page` already travel
+ * between these applications. So this is the estate's existing preference
+ * mechanism rather than a new one, and it is also the only one that makes the
+ * setting mean what a user expects it to mean.
+ *
+ * NO FLASH OF THE WRONG THEME. Nothing here corrects the theme after mount -
+ * `plugins/vuetify.ts` reads the same cookie BEFORE `createVuetify` and boots
+ * on it, so the first paint is already right. The apps are `ssr: false`, so
+ * there is no server render to disagree with.
+ */
+import { useTheme } from "vuetify";
+import type { CookieOptions } from "#app";
+
+export type TThemeName = "light" | "dark";
+
+/** The one place the cookie is named. `plugins/vuetify.ts` reads the same one. */
+export const THEME_COOKIE = "theme";
+
+export default function useThemePreference() {
+  // `runtimeConfig.public.cookieConfig` is typed `unknown`, so it is narrowed
+  // here rather than at every call site. Same object `sid`, `user` and
+  // `landing-page` are written with - it carries the shared parent domain.
+  const cookieConfig = useRuntimeConfig().public.cookieConfig as CookieOptions<
+    TThemeName | null
+  > & { readonly?: false };
+
+  const vuetifyTheme = useTheme();
+
+  const stored = useCookie<TThemeName | null>(THEME_COOKIE, cookieConfig);
+
+  const current = computed<TThemeName>(() =>
+    vuetifyTheme.global.current.value.dark ? "dark" : "light"
+  );
+
+  /**
+   * Sets the theme AND remembers it. The write is the whole point - a caller
+   * that only wants a temporary theme for one subtree should use
+   * `<v-theme-provider>` instead, which is what `plain-dark` does.
+   */
+  function setTheme(name: TThemeName) {
+    vuetifyTheme.global.name.value = name;
+    stored.value = name;
+  }
+
+  function toggleTheme() {
+    setTheme(current.value === "dark" ? "light" : "dark");
+  }
+
+  return { current, setTheme, toggleTheme, stored };
+}

package/nuxt.config.ts

@@ -7,6 +7,37 @@ export default defineNuxtConfig({
     transpile: ["vuetify"],
   },
 
+  /**
+   * THE REDESIGN'S TYPEFACE - LOADED, DELIBERATELY NOT APPLIED YET.
+   *
+   * `--font-sans` in `assets/css/tokens.css` names Manrope, and a token that
+   * names a font nobody loaded is a trap: the next phase writes
+   * `font-family: var(--font-sans)`, silently falls back to Arial, and looks
+   * fine to whoever wrote it. So the stylesheet is requested here.
+   *
+   * Nothing sets `font-family` on the page in Phase 1. Switching eleven
+   * applications to a new typeface before one screen has been rebuilt would
+   * leave the whole product looking half-migrated; each phase adopts the token
+   * as it rebuilds its own surfaces. Browsers do not download a webfont no
+   * element uses, so until then this costs one small CSS request.
+   */
+  app: {
+    head: {
+      link: [
+        { rel: "preconnect", href: "https://fonts.googleapis.com" },
+        {
+          rel: "preconnect",
+          href: "https://fonts.gstatic.com",
+          crossorigin: "",
+        },
+        {
+          rel: "stylesheet",
+          href: "https://fonts.googleapis.com/css2?family=Manrope:wght@400;500;600;700;800&family=Material+Symbols+Outlined:opsz,wght,FILL,GRAD@20..48,100..700,0..1,-50..200&display=swap",
+        },
+      ],
+    },
+  },
+
   runtimeConfig: {
     public: {
       cookieConfig: {