@7365admin1/layer-common 3.2.7 → 3.2.8-staging.201

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,236 @@
+/**
+ * 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));
+  /*
+   * The label on a SOLID `--ok` fill. Not `#fff`: the dark theme's `--ok` is
+   * `#41c795`, a light mint, and white on it measures 2.14:1 - worse than the
+   * 2.99:1 that got batch C's solid danger button reverted. `on-success` is
+   * the pair Vuetify already computes per theme from `PALETTE.onFill`
+   * (`#ffffff` light, `#131418` dark), so the fill keeps the colour the design
+   * asks for and only the label follows the theme.
+   */
+  --on-ok: rgb(var(--v-theme-on-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);
+
+  /* The edge of a TONAL error control - the check-out button. Alpha over the
+     live `--err` rather than a literal, exactly the way `--accent-soft` is
+     built, so it tracks the theme's error colour instead of restating it. */
+  --err-border: rgba(var(--v-theme-error), 0.24);
+}
+
+.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);
+
+  --err-border: rgba(var(--v-theme-error), 0.28);
+}
+
+/* ------------------------------------------------------------------ */
+/* 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/AcceptDialog.vue

@@ -2,34 +2,33 @@
   <v-dialog
     :model-value="modelValue"
     @update:model-value="val => $emit('update:modelValue', val)"
-    max-width="420"
+    :max-width="520"
     persistent
   >
-    <v-card class="pa-4" style="border-radius:12px;">
-      <v-card-title class="headline" style="font-size:1.3rem; font-weight:500;">
-        {{ title }}
-      </v-card-title>
-      <v-card-text style="font-size:1.05rem; margin-bottom:24px;">
+    <v-card class="screen-modal">
+      <v-card-title>{{ title }}</v-card-title>
+      <v-card-text class="screen-modal__body">
         {{ message }}
       </v-card-text>
-      <v-card-actions class="justify-end" style="gap:12px;">
+      <!-- The design's footer is ghost-then-primary, equal width. "No" is the
+           dismissing action and "Yes" the confirming one, so they take the
+           Cancel / Submit shapes in that order. -->
+      <div class="screen-modal__footer">
         <v-btn
-          color="primary"
+          class="screen-btn-ghost"
           variant="outlined"
-          style="min-width:70px; background:#e3f2fd; color:#1976d2; font-weight:500;"
-          @click="$emit('confirm')"
+          @click="$emit('cancel')"
         >
-          Yes
+          No
         </v-btn>
         <v-btn
-          color="error"
-          variant="outlined"
-          style="min-width:70px; background:#ffebee; color:#d32f2f; font-weight:500;"
-          @click="$emit('cancel')"
+          class="screen-btn-primary"
+          variant="flat"
+          @click="$emit('confirm')"
         >
-          No
+          Yes
         </v-btn>
-      </v-card-actions>
+      </div>
     </v-card>
   </v-dialog>
 </template>
@@ -41,4 +40,4 @@ defineProps<{
   message?: string
 }>();
 defineEmits(['confirm', 'cancel', 'update:modelValue']);
-</script>
+</script>

package/components/AccessCard/AvailableStats.vue

@@ -1,24 +1,32 @@
 <template>
   <v-row no-gutters align="center" style="gap: 8px">
     <span class="text-caption text-medium-emphasis mr-1">Available:</span>
-    <v-chip
-      size="small"
-      variant="tonal"
-      color="primary"
-      prepend-icon="mdi-card-account-details"
-      :loading="loading"
-    >
+    <!--
+      These were `v-chip variant="tonal"` on Vuetify's `primary` / `secondary`.
+      `secondary` is never defined in this layer's theme, so the QR chip was
+      painting itself Vuetify's BUILT-IN default `#48a9a6` - a colour the design
+      never chose, and one that measures 2.58:1 on the page background.
+
+      `StatusChip`'s `tone` prop is the documented route for a chip that is a
+      COUNT rather than a status word: the screen has already worked out the
+      meaning and only needs the design's tone.
+
+      Both take `neutral`, and that is the design system's own rule rather than
+      a preference - `utils/status.ts`: a value the design never named must NOT
+      be guessed into a colour. The handoff draws no "available cards" stat, so
+      neither count has a colour of its own to honour. They are told apart by
+      their icon and label. `info` was measured here too and reads 3.88:1 on
+      the page background, which would have ADDED a sub-AA pair to buy a
+      distinction the design never asked for.
+    -->
+    <StatusChip tone="neutral" pill :dot="false">
+      <v-icon icon="mdi-card-account-details" size="14" />
       NFC: <strong class="ml-1">{{ availablePhysical }}</strong>
-    </v-chip>
-    <v-chip
-      size="small"
-      variant="tonal"
-      color="secondary"
-      prepend-icon="mdi-qrcode"
-      :loading="loading"
-    >
+    </StatusChip>
+    <StatusChip tone="neutral" pill :dot="false">
+      <v-icon icon="mdi-qrcode" size="14" />
       QR Code: <strong class="ml-1">{{ availableNonPhysical }}</strong>
-    </v-chip>
+    </StatusChip>
   </v-row>
 </template>