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

package/assets/css/screens.css

@@ -0,0 +1,1097 @@
+/**
+ * PHASE 4 - THE MODULE-SCREEN PATTERNS.
+ *
+ * Phase 1 wrote the tokens, Phase 2 the shell, Phase 3 the table card. What is
+ * left on a module screen is everything AROUND that table: the filter bar over
+ * it, the tabs that switch it, the dialogs it opens, the plain cards and the
+ * settings accordion. Those patterns are drawn once, here, and the screens opt
+ * in by class name - so a screen's diff is class names and chips, not a block
+ * of CSS repeated twenty times.
+ *
+ * OPT-IN, NOT GLOBAL. Every rule below is under a class this layer's own
+ * components add to their own markup. Nothing here selects a bare Vuetify class
+ * on its own, so no application page is repainted by a stylesheet it never
+ * asked for - the eleven apps get these surfaces through the components they
+ * already mount, and their own markup is Phases 6 and 7.
+ *
+ * VISUAL ONLY. No rule here hides, moves, reorders, disables or reveals a
+ * control: everything is colour, type, radius, border, shadow and spacing.
+ */
+
+/* ------------------------------------------------------------------ */
+/* 1. The filter bar.                                                  */
+/* ------------------------------------------------------------------ */
+
+/**
+ * The row of filters that sits over a table. On these screens it is a
+ * `v-card flat` with a fixed 60px height and `ga-5`, which on a phone puts
+ * three 300px fields on one 60px line and clips them. This is the same fields
+ * in the same order, on the design's surface, wrapping instead of clipping.
+ */
+.filter-bar {
+  display: flex;
+  flex-wrap: wrap;
+  align-items: center;
+  gap: var(--grid-gap);
+  width: 100%;
+  padding: 10px var(--cellpad-x);
+  background: transparent;
+  font-family: var(--font-sans);
+}
+
+/* 40px, 10px radius, 13.5px - the design's input, whatever Vuetify's density
+   would otherwise make of it. `.filter-field` is the same input on its own,
+   for the screens whose one search box sits in a toolbar rather than a row. */
+.filter-bar .v-field,
+.filter-field .v-field {
+  border-radius: var(--r-inner);
+  font-size: var(--fs-cell);
+  font-family: var(--font-sans);
+}
+
+.filter-bar .v-field__input,
+.filter-field .v-field__input {
+  min-height: var(--input-h);
+  font-size: var(--fs-cell);
+}
+
+.filter-bar .v-label,
+.filter-field .v-label,
+.filter-bar .v-field__input input::placeholder,
+.filter-field .v-field__input input::placeholder {
+  font-size: var(--fs-cell);
+  font-family: var(--font-sans);
+}
+
+/* A field is at least readable-wide and then shares what is left. Below 600
+   there is no room for two, so they stack - the same rule `.filter-row` uses. */
+.filter-bar > * {
+  flex: 1 1 200px;
+  min-width: 0;
+  max-width: 100%;
+}
+
+.filter-bar > .filter-bar__fit {
+  flex: 0 0 auto;
+}
+
+@media (max-width: 599.98px) {
+  .filter-bar {
+    flex-direction: column;
+    align-items: stretch;
+  }
+
+  .filter-bar > * {
+    flex: 1 1 auto;
+    width: 100%;
+  }
+}
+
+/* ------------------------------------------------------------------ */
+/* 2. Tabs.                                                            */
+/* ------------------------------------------------------------------ */
+
+/**
+ * 13px, the active one at 800 in `--accent-text` over a 2px accent underline.
+ * Vuetify's own tab label is uppercase 14px/500 with wide tracking and it puts
+ * `text-uppercase` on it as a utility, so these need the same weight of hand
+ * the nav items needed in Phase 2.
+ */
+.screen-tabs .v-tab {
+  font-family: var(--font-sans);
+  font-size: var(--fs-nav) !important;
+  font-weight: var(--fw-cell) !important;
+  letter-spacing: 0 !important;
+  text-transform: none !important;
+  color: var(--muted);
+  min-width: 0;
+}
+
+.screen-tabs .v-tab.v-tab--selected {
+  font-weight: var(--fw-table-head) !important;
+  color: var(--accent-text);
+}
+
+.screen-tabs .v-tab .v-tab__slider {
+  height: 2px;
+  background: var(--accent);
+}
+
+/* ------------------------------------------------------------------ */
+/* 3. Cards, section headings and empty states.                        */
+/* ------------------------------------------------------------------ */
+
+/** The card contract, for the surfaces that are not the table card. */
+.screen-card {
+  font-family: var(--font-sans);
+  background: var(--card);
+  border: 1px solid var(--border);
+  border-radius: var(--r-card);
+  box-shadow: var(--shadow);
+}
+
+.screen-title {
+  font-family: var(--font-sans);
+  font-size: var(--fs-h1);
+  font-weight: var(--fw-h1);
+  letter-spacing: var(--ls-h1);
+  color: var(--text);
+}
+
+.screen-card-title {
+  font-family: var(--font-sans);
+  font-size: var(--fs-card-title) !important;
+  font-weight: var(--fw-card-title) !important;
+  letter-spacing: 0 !important;
+  color: var(--text);
+}
+
+.screen-empty {
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+  justify-content: center;
+  gap: 8px;
+  padding: 52px 16px;
+  font-family: var(--font-sans);
+  font-size: var(--fs-cell);
+  color: var(--muted);
+  text-align: center;
+}
+
+.screen-empty .v-icon {
+  color: var(--muted);
+}
+
+/**
+ * The one-line explanation under a setting's name. It was
+ * `text-grey-darken-1` - a fixed Vuetify grey, i.e. the same dark grey on the
+ * dark page - so the sentence that explains a switch was the hardest thing on
+ * the screen to read. `--muted` is the design's own, and it is a token, so it
+ * follows the theme.
+ */
+.screen-hint {
+  font-family: var(--font-sans);
+  color: var(--muted);
+}
+
+/**
+ * `fontgray` is a legacy application-side Vuetify colour - a fixed `#7e7e7e`
+ * that is the SAME grey in both themes, so it neither darkens for the light
+ * page nor lightens for the dark one. Measured on the glass it reads 4.06:1 on
+ * a light card and 4.10:1 on a dark card: below AA on both, on labels that
+ * appear on 35 files across the layer and eleven applications.
+ *
+ * `--muted` is the design's own secondary ink and is a token, so it follows
+ * the theme. Redirected here, once, rather than renamed at 35 call sites - the
+ * layer's stylesheet ships to every application, so the class keeps working.
+ *
+ * THE READING THIS COMMENT USED TO CLAIM IS NO LONGER TRUE, and the correction
+ * matters because it inverts the justification above.
+ *
+ * It said "4.77:1 light, 4.71:1 dark". That was measured when `--muted` was
+ * `#6b7079` - one of the six values darkened on 2026-08-13 to clear AA. The
+ * owner REVERSED that on 2026-08-14 in favour of 100% design fidelity, and
+ * `--muted` went back to the handoff's `#8b8f98`. Re-measured on the current
+ * token, alpha composited:
+ *
+ *     --muted on a card   3.24:1   (the old #7e7e7e read 4.06:1)
+ *     --muted on the page 2.99:1   - below even the 3.0 large-text floor
+ *
+ * So on the LIGHT theme this redirect is now a DOWNGRADE for the ~5 files that
+ * still use the class, not the improvement the original comment describes. It
+ * is left in place deliberately: `#7e7e7e` was a fixed grey that ignored the
+ * theme entirely and read 4.10:1 on dark where `--muted` reads 4.93:1, so
+ * reverting would trade a light-theme gain for a dark-theme loss. Which way
+ * this should go is a PALETTE decision for the owner, not a per-class one -
+ * see `utils/theme-aa-ledger.ts`, which pins every one of these readings.
+ */
+.text-fontgray {
+  color: var(--muted) !important;
+}
+
+/* ------------------------------------------------------------------ */
+/* 4. Dialogs.                                                         */
+/* ------------------------------------------------------------------ */
+
+/**
+ * THE ONE RULE HERE THAT IS NOT OPT-IN, AND WHY.
+ *
+ * The product opens its dialogs from more than sixty different form and dialog
+ * components, not from the twenty-three module screens. Giving the design's
+ * 16px corner to a modal by editing sixty files would be sixty chances to
+ * break a dialog for a corner radius. So the SHAPE is stated once, for any
+ * card that Vuetify has put inside an overlay - shape and shadow only. It
+ * repaints no colour, moves no control and changes no type, and it is the same
+ * `.v-overlay__content > .v-card` selector Phase 3 already had to out-specify.
+ */
+.v-overlay__content > .v-card,
+.v-overlay__content > form > .v-card {
+  border-radius: var(--r-modal) !important;
+  box-shadow: var(--shadow-modal) !important;
+}
+
+/**
+ * `.v-overlay__content > .v-card` is MORE SPECIFIC than a class on the card
+ * (Phase 3 measured a dialog stuck at its factory 4px radius because of it),
+ * so the radius has to be `!important` to be reached at all.
+ *
+ * The body is what scrolls, not the whole card: a modal whose card scrolls
+ * takes its Cancel/Submit footer off screen with it. `.screen-modal__body` is
+ * only applied where a screen's dialog already has a distinct body element.
+ */
+.screen-modal {
+  font-family: var(--font-sans);
+  border-radius: var(--r-modal) !important;
+  box-shadow: var(--shadow-modal) !important;
+  background: var(--card) !important;
+  max-height: calc(100vh - 32px);
+}
+
+.screen-modal .v-card-title {
+  font-family: var(--font-sans);
+  font-size: var(--fs-card-title) !important;
+  font-weight: var(--fw-card-title) !important;
+  letter-spacing: 0 !important;
+  color: var(--text);
+}
+
+.screen-modal__body {
+  overflow-y: auto;
+  font-size: var(--fs-cell);
+}
+
+/**
+ * ...and the same size again, because inside a real dialog the rule above
+ * never reached the glass. Vuetify scopes
+ *
+ *   .v-dialog > .v-overlay__content > .v-card > .v-card-text { font-size: inherit }
+ *
+ * which is a FOUR-class chain against our one, so a `.screen-modal__body` in a
+ * `v-dialog` inherited the root 16px instead of the design's 13.5px --fs-cell.
+ * Measured on `AccessCardDeleteDialog`: 16px/400 where --fs-cell is 13.5px.
+ * It is invisible in a harness that mounts the card WITHOUT its dialog, which
+ * is how it survived. Naming the same chain plus the card's own class wins it
+ * back on specificity alone - no `!important`, same technique as the button
+ * height fix.
+ */
+.v-dialog > .v-overlay__content > .v-card.screen-modal > .screen-modal__body {
+  font-size: var(--fs-cell);
+}
+
+/**
+ * The design's modal footer, literal from the prototype's Create Role dialog:
+ *
+ *   <div style="display:flex;gap:10px;padding:16px 22px;
+ *               border-top:1px solid var(--border)">
+ *     <button style="flex:1; ...ghost">Cancel</button>
+ *     <button style="flex:1; ...primary">Submit</button>
+ *
+ * Two EQUAL-WIDTH buttons on a bordered strip, ghost first. Stated once
+ * because the product opens confirm dialogs from a couple of dozen components
+ * and each of them was drawing its own footer by hand.
+ */
+.screen-modal__footer {
+  display: flex;
+  gap: 10px;
+  padding: 16px 22px;
+  border-top: 1px solid var(--border);
+}
+
+.screen-modal__footer > .v-btn,
+.screen-modal__footer > .app-btn {
+  flex: 1;
+}
+
+/**
+ * The modal's close control, literal from the same Create Role dialog:
+ *
+ *   <button style="display:flex;align-items:center;justify-content:center;
+ *                  width:32px;height:32px;border:none;border-radius:8px;
+ *                  background:transparent;color:var(--muted);"
+ *           style-hover="background:var(--hover)">close</button>
+ *
+ * Borderless and 32px square - NOT `.screen-icon-btn`, which is the bordered
+ * 40px square the design draws in a toolbar. The glyph is 19px.
+ *
+ * MEASURED, 2026-08-15: the size never reached the glass. Vuetify's own
+ *
+ *   .v-btn--size-default.v-btn--icon { width: calc(var(--v-btn-height) + 12px);
+ *                                      height: same }
+ *
+ * is TWO classes against this one, so every `.screen-modal__close` in the
+ * package drew at 36 + 12 = **48px**, with Vuetify's `padding: 0 16px` on top -
+ * half again the design's square, on all thirteen components that use it
+ * (`AreaFormDialog`, `Carousel`, `ConfirmDialog`, `DocumentViewer`, `DrawImage`,
+ * `EntryPass/QrTemplatePreview`, `EquipmentItemMain`, `EquipmentManagementMain`,
+ * `FileInput`, `ManageChecklistMain`, `PhotoUpload`, `ServiceProviderMain`,
+ * `Signature`). The `border-radius: 8px` DID win, which is what hid it: the
+ * control looked right and simply sat in a box a third too big.
+ *
+ * Naming `.v-btn` alongside it makes this (0,2,0) and the later sheet wins -
+ * the same specificity fix `.v-btn.screen-btn-primary` needed, no `!important`.
+ */
+.v-btn.screen-modal__close {
+  width: 32px;
+  height: 32px;
+  min-width: 32px;
+  padding: 0;
+  border-radius: 8px;
+  background: transparent;
+  color: var(--muted);
+}
+
+.screen-modal__close:hover {
+  background: var(--hover);
+}
+
+.screen-modal__close .v-icon {
+  font-size: 19px;
+}
+
+/**
+ * A DIALOG'S OWN HEADER/FOOTER BAR - OPT-IN, DELIBERATELY.
+ *
+ * Some dialogs draw their title row and their Cancel/Submit row as a
+ * `v-toolbar`. Vuetify paints that from its own `surface`, which in dark mode
+ * is a visible grey slab sitting on the card. The obvious fix - one blanket
+ * `.v-overlay__content .v-toolbar` rule - was measured and REJECTED: sixty-odd
+ * dialog components draw such a bar, and several set `color="black"` or
+ * `color="grey-darken-3"` ON PURPOSE. A blanket rule would flatten those too,
+ * unrendered and unverified.
+ *
+ * So this is a class a converted dialog opts into. Background and text only -
+ * it moves no control and changes no button.
+ */
+.screen-dialog-bar.v-toolbar {
+  background: var(--card) !important;
+  color: var(--text) !important;
+}
+
+/**
+ * The design's two buttons, for the dialogs and toolbars that draw their own.
+ *
+ * `.v-btn` is named on every selector below for SPECIFICITY, not decoration.
+ * Vuetify sizes its button from `--v-btn-height` (36px, set on
+ * `.v-btn--size-default`) and applies it at `.v-btn.v-btn--density-default` -
+ * two classes, which outrank a bare `.screen-btn-*`. So `height: var(--btn-h)`
+ * never reached the glass and EVERY one of these buttons drew at 36px against
+ * the design's 40. `min-width` lost the same argument at 64px.
+ *
+ * Beaten by specificity, not `!important` - the same way the central font
+ * re-point beat Vuetify's own font declarations. And the fix FEEDS
+ * `--v-btn-height` rather than overwriting `height`, so Vuetify's density
+ * arithmetic (including the icon button's `+12px`) keeps working off our number.
+ */
+.v-btn.screen-btn-primary {
+  --v-btn-height: var(--btn-h);
+  min-width: 0;
+  border-radius: var(--r-inner);
+  padding: 0 16px;
+  font-family: var(--font-sans);
+  font-size: var(--fs-btn);
+  font-weight: var(--fw-btn-strong);
+  letter-spacing: 0;
+  text-transform: none;
+  background: var(--accent-strong);
+  color: var(--on-accent-strong);
+}
+
+/*
+ * `min-width: 0` above is what lets a button shrink to its label, and it is
+ * one class more specific than Vuetify's `.v-btn--block { min-width: 100% }` -
+ * so it silently CANCELLED `block`. Measured on the ten create/edit forms:
+ * a `block` Cancel sat 80.8px wide inside a 672px half-column instead of
+ * filling it, on every width and both themes. Restoring it needs the block
+ * class named, so this reaches only the buttons that asked to be full width.
+ */
+.v-btn.v-btn--block.screen-btn-primary,
+.v-btn.v-btn--block.screen-btn-ghost {
+  min-width: 100%;
+}
+
+/* Vuetify paints `variant="tonal"` with an overlay layer ABOVE the button's own
+   background, so without this the accent fill shows through a wash. */
+.screen-btn-primary .v-btn__overlay,
+.screen-btn-ghost .v-btn__overlay {
+  opacity: 0;
+}
+
+/*
+ * DISABLED. The two rules above set `background` and `color` unconditionally,
+ * and they out-specify the treatment Vuetify would otherwise give a disabled
+ * button - so a Submit that a `v-form` has genuinely gated OFF was painting
+ * the full accent fill at full opacity, identical to a live one. Measured on
+ * `OnlineFormFill` with its required field emptied: enabled and disabled came
+ * back byte-identical (`rgb(75, 116, 196)` / `rgb(255, 255, 255)` /
+ * `opacity: 1`) on BOTH themes. The gate held; nothing showed it.
+ *
+ * 0.5 is the design's own disabled step - `.app-btn:disabled` in
+ * `primitives.css` uses it - so the two button families dim by the same amount
+ * rather than inventing a second number here.
+ *
+ * Both the attribute and Vuetify's class are named: `:disabled` is what a
+ * plain `<button>` carries, `.v-btn--disabled` is what Vuetify adds, and a
+ * rule that matched only one of them would go quiet the moment the other path
+ * was used.
+ *
+ * `.screen-icon-btn` was MISSED when this rule was written, and it has exactly
+ * the same shape: `.v-btn.screen-icon-btn` is (0,2,0) and sets `background:
+ * var(--card)` and `color: var(--text2)`, so it out-specifies Vuetify the same
+ * way. Measured 2026-08-16 on `AreaMain`: enabled and disabled came back
+ * identical on background, colour, border, opacity and filter, on BOTH themes.
+ * Its `:disabled` call sites are the promo-code tier rows in the admin app,
+ * where the last remaining tier's delete button is gated off and looked live.
+ *
+ * `.screen-modal__close` and `.screen-modal` were checked at the same time and
+ * are NOT affected - both already read as distinct when disabled, because the
+ * close button's background is `transparent` and a disabled `v-card` dims its
+ * children rather than itself. Neither is listed here.
+ */
+.v-btn.screen-btn-primary:disabled,
+.v-btn.screen-btn-primary.v-btn--disabled,
+.v-btn.screen-btn-ghost:disabled,
+.v-btn.screen-btn-ghost.v-btn--disabled,
+.v-btn.screen-icon-btn:disabled,
+.v-btn.screen-icon-btn.v-btn--disabled {
+  opacity: 0.5;
+}
+
+/**
+ * The icon-only actions next to a primary button (download template, import,
+ * export). The design draws an icon button as a bordered square the height of
+ * the input next to it - the same button Phase 2 gave the top bar - not a
+ * tinted pill.
+ */
+.v-btn.screen-icon-btn {
+  --v-btn-height: var(--btn-h);
+  height: var(--btn-h);
+  width: var(--btn-h);
+  min-width: var(--btn-h);
+  padding: 0;
+  border-radius: var(--r-inner);
+  border: 1px solid var(--border);
+  background: var(--card);
+  color: var(--text2);
+}
+
+.screen-icon-btn .v-btn__overlay {
+  opacity: 0;
+}
+
+.v-btn.screen-btn-ghost {
+  --v-btn-height: var(--btn-h);
+  min-width: 0;
+  border-radius: var(--r-inner);
+  padding: 0 16px;
+  font-family: var(--font-sans);
+  font-size: var(--fs-btn);
+  font-weight: var(--fw-btn);
+  letter-spacing: 0;
+  text-transform: none;
+  color: var(--text2);
+  /*
+   * THE EDGE IS THE GHOST. The handoff draws this button as "40px, 1px border,
+   * card fill" - the border is what separates it from the page, since the fill
+   * is the same `--card` as the surface behind it.
+   *
+   * `border-color` alone does not draw anything. It only tinted an edge that
+   * Vuetify's `variant` had already decided the width of: `outlined` gives
+   * `thin`, `flat` gives 0. So the same class rendered a bordered button at 48
+   * call sites and a borderless one at 13 - measured 1px vs 0px, both themes -
+   * and which you got depended on a `variant` a caller had no reason to think
+   * was load-bearing. Naming the width here makes the class draw the design's
+   * button whichever variant it is paired with.
+   */
+  border-width: 1px;
+  border-style: solid;
+  border-color: var(--border);
+  background: var(--card);
+}
+
+/* ------------------------------------------------------------------ */
+/* 5. The settings accordion.                                          */
+/* ------------------------------------------------------------------ */
+
+/**
+ * The design draws settings as a stack of bordered sections with one open at a
+ * time. The "one at a time" half is BEHAVIOUR and is left exactly as the panel
+ * has it (`multiple`, on the site settings screen); this is the drawn half:
+ * the border, the radius, the title type and the open section's surface.
+ */
+.screen-accordion .v-expansion-panel {
+  font-family: var(--font-sans);
+  background: var(--card);
+  border: 1px solid var(--border);
+  border-radius: var(--r-card) !important;
+  box-shadow: none !important;
+  margin-bottom: 10px;
+}
+
+.screen-accordion .v-expansion-panel::after {
+  display: none;
+}
+
+.screen-accordion .v-expansion-panel-title {
+  font-family: var(--font-sans);
+  font-size: var(--fs-card-title);
+  font-weight: var(--fw-card-title);
+  color: var(--text);
+  min-height: 56px;
+}
+
+.screen-accordion .v-expansion-panel-title--active {
+  color: var(--text);
+  border-bottom: 1px solid var(--border);
+}
+
+.screen-accordion .v-expansion-panel-text {
+  font-size: var(--fs-cell);
+  color: var(--text2);
+}
+
+.screen-accordion .v-expansion-panel-title__overlay {
+  background: transparent;
+}
+
+/* ------------------------------------------------------------------ */
+/* 6. The table card (moved here from TableMain, unchanged).           */
+/* ------------------------------------------------------------------ */
+
+/**
+ * Phase 3 drew this inside `TableMain`'s own scoped block. It is moved here,
+ * rule for rule, because it is not TableMain's alone any more: `BillingMain`
+ * draws the same card from its own copy of that markup, and a second copy of
+ * the CSS is how the two drift apart. `TableMain` still puts the same classes
+ * on the same elements - only the stylesheet moved, so nothing it renders
+ * changes.
+ */
+
+/* ------------------------------------------------------------------ */
+/* The card.                                                           */
+/* ------------------------------------------------------------------ */
+
+/**
+ * THE WIDE-TABLE BLOWOUT.
+ *
+ * The card sits in a `v-col`, i.e. a flex item, and a flex item's automatic
+ * minimum size is its content's minimum - so a table with 8 columns set a
+ * ~686px floor the column could not shrink below, and the PAGE scrolled
+ * sideways at 360 and 768 instead of the table doing it. `min-width: 0` lets
+ * it shrink; the table then scrolls INSIDE the card, which is how the design
+ * draws it - the row is deliberately not restacked into key/value blocks,
+ * because a column carries meaning by its position. Same decision as
+ * `.app-table-scroll` in `primitives.css`.
+ *
+ * It is on BOTH of this component's own flex boxes - its root `v-row` (which
+ * is itself an item of the CALLER's row) and the column holding the card -
+ * because the content's minimum walks all the way up the chain, and stopping
+ * it at the inner column alone left the page still scrolling sideways.
+ */
+.table-card__shrink {
+  min-width: 0;
+}
+
+.table-card .v-table__wrapper {
+  overflow-x: auto;
+}
+
+.table-card {
+  font-family: var(--font-sans);
+  background: var(--card);
+  border: 1px solid var(--border);
+  border-radius: var(--r-card);
+  box-shadow: var(--shadow);
+  overflow: hidden;
+  /*
+   * `.table-card__loading` below is `position: absolute`, and nothing in the
+   * chain above it - not `.app-card`, not `.table-card` - established a
+   * containing block, so the bar resolved against the VIEWPORT: measured
+   * 1440x2 pinned to `top: 0` of the window while its card sat at `y: 61.5`.
+   * Every `TableMain` screen in all 11 apps drew its busy bar across the top
+   * of the browser instead of the top of the card. This is the anchor it
+   * always needed. Safe by construction: the card is already
+   * `overflow: hidden`, so nothing inside it could have been anchored to an
+   * ancestor OUTSIDE it and still be visible.
+   */
+  position: relative;
+}
+
+/**
+ * The toolbar was `color="grey-lighten-4"` - a literal Vuetify grey, which is
+ * a near-white bar sitting on a #1c1e24 card in dark mode. It is the card's
+ * own surface now, with the design's rule under it.
+ */
+.table-card__toolbar {
+  border-bottom: 1px solid var(--border);
+}
+
+/**
+ * The callers' filter row (`#extension`). It was a `v-toolbar` extension, i.e.
+ * a fixed-height second bar; it is now a plain row under the toolbar with the
+ * same rule under it, so it can size to whatever the caller puts in it.
+ */
+.table-card__extension {
+  border-bottom: 1px solid var(--border);
+}
+
+.table-card__loading {
+  position: absolute;
+  z-index: 1;
+}
+
+.table-card__range {
+  font-size: 12px;
+  font-weight: 600;
+  color: var(--muted);
+  font-variant-numeric: tabular-nums;
+}
+
+/* ------------------------------------------------------------------ */
+/* The header row and the rows under it.                               */
+/* ------------------------------------------------------------------ */
+
+/**
+ * `padding: 12px 20px`, not 10px - read off the prototype's own header row,
+ * which is `padding:12px 20px;font-size:11px;font-weight:800;letter-spacing:
+ * .07em;text-transform:uppercase;color:var(--muted);background:var(--thead)`.
+ */
+.table-card thead th {
+  background: var(--thead) !important;
+  /*
+   * `--text2`, not the prototype's `--muted`. `--muted` on the header band
+   * measures 3.10:1 in light (3.24:1 where the band sits on a plain card) -
+   * below AA, and reported independently by two apps' QA runs. `--text2` is
+   * the design's SECONDARY text token: 9.22:1 light / 9.57:1 dark on the same
+   * band, while still sitting clearly below the primary ink the data rows use
+   * (16.52:1 / 13.77:1), so the header keeps reading as secondary to the data.
+   * The uppercase/800/11px treatment below is unchanged.
+   */
+  color: var(--text2) !important;
+  font-size: var(--fs-table-head) !important;
+  font-weight: var(--fw-table-head) !important;
+  letter-spacing: var(--ls-table-head);
+  text-transform: uppercase;
+  padding: 12px var(--cellpad-x) !important;
+  height: auto !important;
+  border-bottom: 1px solid var(--border) !important;
+  white-space: nowrap;
+}
+
+/*
+ * `--thead` is intentionally translucent. A fixed header, however, sits above
+ * scrolling rows, so using the token by itself lets the first row show through
+ * the header. Layer the same tint over the card surface to keep the rendered
+ * colour unchanged while making the sticky header fully opaque.
+ */
+.table-card .v-table--fixed-header thead th {
+  background:
+    linear-gradient(var(--thead), var(--thead)),
+    var(--card) !important;
+}
+
+/**
+ * ROW HEIGHT IS THE LINE BOX, NOT THE PADDING.
+ *
+ * The padding was already the design's `15px 20px`, and the type was already
+ * `13.5px / 600` - measured, both correct. The row was still too tall, because
+ * Vuetify puts `line-height: 1.5` on a cell: a 20.25px line box around 13.5px
+ * type, which makes a text-only row 51.25px.
+ *
+ * The prototype sets NO line-height at all, so its rows draw at the font's own
+ * normal leading - so this sets `normal` rather than a number, which is the
+ * same thing said out loud. Measured: a text-only row is then exactly 49.0px,
+ * the design's figure, and a row carrying a chip or the design's 26-28px avatar
+ * grows past it on its own - which is where the design's taller rows come from.
+ * Height follows content, exactly as the prototype does it, and is pinned to
+ * nothing.
+ */
+.table-card tbody td {
+  font-size: var(--fs-cell);
+  font-weight: var(--fw-cell);
+  color: var(--text);
+  padding: var(--cellpad) var(--cellpad-x) !important;
+  height: auto !important;
+  /* `!important` for the same reason the padding needs it: Vuetify's own rule
+     is five levels of descendant, which no two-class selector can outrank. */
+  line-height: normal !important;
+  font-variant-numeric: tabular-nums;
+}
+
+/**
+ * The design bolds the name column. Every table in the prototype that leads
+ * with a name draws it `font-weight:700` against the row's own 600 - it is what
+ * makes a row scannable, and it was missing from every table here.
+ *
+ * `:first-child` rather than a prop: the caller's own `headers` decide what the
+ * first column is, so no caller changes and no new API. A cell whose CONTENT
+ * sets its own weight - a chip, a link, an avatar block - still wins, because
+ * this only sets what the cell's children inherit.
+ */
+.table-card tbody td:first-child {
+  font-weight: 700;
+}
+
+/**
+ * THE DESIGN'S FIXED COLUMN PROPORTIONS - opt-in, because they cannot be
+ * derived. The prototype lays every table out as a CSS grid with a per-table
+ * `grid-template-columns` (`0.9fr 1.5fr 1.7fr 0.8fr 1fr 1.1fr` on Feedbacks,
+ * `2fr 1fr 1fr` on Units, and so on). Those proportions are a design decision
+ * per screen; nothing in a caller's `headers` array says what they should be,
+ * so a shared component cannot invent them.
+ *
+ * What `TableMain` can do is honour them when a caller states them: a `weight`
+ * on a header becomes that column's share, and only then does the table switch
+ * to `table-layout: fixed` so the widths are obeyed rather than treated as
+ * hints. A caller that sets no weights gets exactly today's automatic layout.
+ */
+.table-card .table-card__fixed table {
+  table-layout: fixed;
+}
+
+/* Fixed layout means a long value can no longer widen its column, so it has to
+   be told what to do instead of overflowing the cell. */
+.table-card .table-card__fixed tbody td {
+  overflow: hidden;
+  text-overflow: ellipsis;
+}
+
+.table-card tbody tr:hover > td {
+  background: var(--hover);
+}
+
+/**
+ * The grouped list (`TableHygiene`) draws its own rows instead of a <table>,
+ * so it cannot inherit the two rules above. Its group header takes the header
+ * row's surface and its rows the card's - replacing the literal
+ * `grey-lighten-4` and `white` that painted the whole list near-white on a
+ * dark card.
+ */
+.table-card__group {
+  background: var(--thead);
+}
+
+.table-card__row {
+  background: var(--card);
+}
+
+/* ------------------------------------------------------------------ */
+/* Empty state, in-card search, buttons and in-card tabs.              */
+/* ------------------------------------------------------------------ */
+
+.table-card__empty {
+  display: flex;
+  flex-direction: column;
+  align-items: center;
+  justify-content: center;
+  gap: 8px;
+  padding: 52px 16px;
+  font-size: var(--fs-cell);
+  color: var(--muted);
+}
+
+.table-card__empty .v-icon {
+  color: var(--muted);
+}
+
+/* The in-card variant: 34px, 10px radius, as drawn. */
+.table-card__search .v-field {
+  border-radius: var(--r-inner);
+  font-size: var(--fs-cell);
+}
+
+.table-card__primary {
+  height: var(--btn-h);
+  border-radius: var(--r-inner);
+  padding: 0 16px;
+  font-size: var(--fs-btn);
+  font-weight: var(--fw-btn-strong);
+  letter-spacing: 0;
+  background: var(--accent-strong);
+  color: var(--on-accent-strong);
+}
+
+.table-card__ghost {
+  height: var(--btn-h);
+  border-radius: var(--r-inner);
+  padding: 0 16px;
+  font-size: var(--fs-btn);
+  font-weight: var(--fw-btn);
+  letter-spacing: 0;
+  color: var(--text2);
+  /*
+   * Same reason as `.screen-btn-ghost` (#1200): `border-color` alone draws
+   * nothing, it only tints an edge whose width the Vuetify `variant` decided.
+   * Measured: paired with `outlined` this rule gives 1px, paired with `flat`
+   * it gives 0px - and the fill is `--card`, the same colour as the surface
+   * behind it, so a borderless copy has no boundary at all.
+   *
+   * The one call site today (`TableMain.vue`, Scan QR Code) does use
+   * `outlined`, so nothing is visibly broken right now. This is the latent
+   * half of the same defect: the next caller who writes `flat` gets an
+   * invisible button and no error. Naming the width closes it.
+   */
+  border-width: 1px;
+  border-style: solid;
+  border-color: var(--border);
+  background: var(--card);
+}
+
+/**
+ * Tabs that a screen puts in this card's extension slot: 13px, the active one
+ * at 800 in `--accent-text` over a 2px accent underline. Tabs elsewhere in the
+ * product are their own screens' and are restyled with them.
+ */
+.table-card .v-tab {
+  font-size: var(--fs-nav);
+  font-weight: var(--fw-cell);
+  letter-spacing: 0;
+  text-transform: none;
+  color: var(--muted);
+  min-width: 0;
+}
+
+.table-card .v-tab.v-tab--selected {
+  font-weight: var(--fw-table-head);
+  color: var(--accent-text);
+}
+
+.table-card .v-tab .v-tab__slider {
+  height: 2px;
+  background: var(--accent);
+}
+
+/* ------------------------------------------------------------------ */
+/* Toast (`components/Snackbar.vue`, 163 caller files).                */
+/*                                                                     */
+/* The handoff draws no toast at all - it is one of the gaps. So this  */
+/* is deliberately NOT an invented surface: it is the design's own     */
+/* button type scale, inner radius and menu shadow applied to          */
+/* Vuetify's snackbar. Vuetify's own default is a 4px radius, a        */
+/* Material elevation and Roboto at 14px, none of which are ours.      */
+/*                                                                     */
+/* The FILL is the `color` prop, defaulted in the component to         */
+/* `primary-button` - never `primary`, which is a foreground token.    */
+/* ------------------------------------------------------------------ */
+.app-toast .v-snackbar__wrapper {
+  border-radius: var(--r-inner);
+  box-shadow: var(--shadow-menu);
+  font-family: var(--font-sans);
+}
+
+.app-toast .v-snackbar__content {
+  font-size: var(--fs-btn);
+  font-weight: 600;
+  letter-spacing: 0;
+}
+
+/* Vuetify's text button is uppercase with wide tracking; the design has no
+   uppercase control anywhere. Named on `.v-btn` so it outweighs the default. */
+.v-btn.app-toast__close {
+  border-radius: var(--r-inner-sm);
+  font-family: var(--font-sans);
+  font-size: var(--fs-btn);
+  font-weight: var(--fw-btn);
+  letter-spacing: 0;
+  text-transform: none;
+}
+
+/* ------------------------------------------------------------------ */
+/* The "Back" link that sits above a page title.                       */
+/* `SpecificAttr.vue` (17 caller files) and `Container/Standard.vue`.   */
+/*                                                                     */
+/* DESIGN GAP, STATED: the handoff draws no back control anywhere, so  */
+/* its SIZE is not a value the design gives. What the design DOES give */
+/* is the rule for a link - `iService365 Redesign.dc.html:26`,         */
+/* `a{color:var(--accent-text);text-decoration:underline}` - so the    */
+/* colour and the underline are literal, and the underline is kept for */
+/* that reason rather than dropped for looking dated. The size is      */
+/* taken from the only standalone inline link the handoff draws, the   */
+/* panel's "View All" at line 166: 12.5px / 700.                       */
+/*                                                                     */
+/* It replaces `text-subtitle-1 font-weight-medium` - Vuetify's        */
+/* 16px/400 Roboto scale, which is neither the product font nor a size */
+/* that appears anywhere in the design.                                */
+/* ------------------------------------------------------------------ */
+.screen-back {
+  display: inline-block;
+  font-family: var(--font-sans);
+  font-size: var(--fs-breadcrumb);
+  font-weight: var(--fw-btn);
+  letter-spacing: 0;
+  line-height: 1.4;
+  color: var(--accent-text);
+  text-decoration: underline;
+  cursor: pointer;
+}
+
+.screen-back:hover {
+  color: var(--accent);
+}
+
+/* ------------------------------------------------------------------ */
+/* 9. The row kebab and the dropdown it opens.                         */
+/*                                                                     */
+/* Both halves are LITERAL, and both were previously left as Vuetify   */
+/* draws them - `Dialog/UpdateMoreAction.vue` says so in a comment,    */
+/* because a menu teleports out of the measured container and could    */
+/* not be render-verified at the time. It can now (force-shot).        */
+/*                                                                     */
+/* The kebab: `iService365 Redesign.dc.html:494`, drawn identically at */
+/* 494, 547, 625 and 660 - a 30px bordered square, 8px radius,         */
+/* transparent fill, `--muted` ink, 17px glyph, `--hover` on hover.    */
+/* 8px is not one of the radius tokens (the set is 7/9/10/12/14/16),   */
+/* so it is written literally rather than snapped to a near token.     */
+/*                                                                     */
+/* The panel: `iService365 Redesign.dc.html:79-90`, the profile        */
+/* dropdown - the only dropdown the handoff draws. 240px, `--card` on  */
+/* a 1px `--border`, 14px radius, `--shadow-menu`, 8px padding; rows   */
+/* are 13px/700 `--text2` at 10px 12px with a 10px radius, and a       */
+/* destructive row is `--err` ink with an `--err-bg` hover (line 89),  */
+/* which is ink and not a filled button.                               */
+/* ------------------------------------------------------------------ */
+.v-btn.screen-kebab {
+  --v-btn-height: 30px;
+  height: 30px;
+  width: 30px;
+  min-width: 30px;
+  padding: 0;
+  border: 1px solid var(--border);
+  border-radius: 8px;
+  background: transparent;
+  color: var(--muted);
+}
+
+.screen-kebab .v-btn__overlay {
+  opacity: 0;
+}
+
+.screen-kebab:hover {
+  background: var(--hover);
+}
+
+.screen-kebab .v-icon {
+  font-size: 17px;
+}
+
+.v-overlay__content > .v-list.screen-menu {
+  width: 240px;
+  padding: 8px;
+  border: 1px solid var(--border);
+  border-radius: var(--r-menu);
+  background: var(--card);
+  box-shadow: var(--shadow-menu);
+}
+
+/* Four classes, to beat Vuetify's own `.v-list .v-list-item--density-*`      */
+/* block on specificity rather than on load order - a three-class rule ties   */
+/* with it and loses, which is how the drawer's 10px gap never applied.       */
+.v-overlay__content > .v-list.screen-menu > .screen-menu__item.v-list-item {
+  min-height: 0;
+  padding: 10px 12px;
+  /* MEASURED, not assumed: without `!important` this read back 0px. Vuetify
+     puts the `rounded-0` UTILITY on every `v-list-item` inside a list with no
+     `rounded` prop, and utilities carry `!important`, so a four-class rule
+     still loses to it. Same trap `NavigationItem.vue` hit in batch Q. */
+  border-radius: var(--r-inner) !important;
+  color: var(--text2);
+}
+
+.screen-menu__item .v-list-item-title {
+  font-family: var(--font-sans);
+  font-size: var(--fs-nav);
+  font-weight: var(--fw-btn);
+  letter-spacing: 0;
+  line-height: 1.3;
+}
+
+.screen-menu__item .v-list-item__prepend > .v-icon {
+  font-size: 18px;
+  color: var(--muted);
+  opacity: 1;
+}
+
+/* The design's row gap is 10px; Vuetify's spacer is wider, and the selector  */
+/* below matches its own four-class shape for the same reason as above.       */
+.screen-menu__item .v-list-item__prepend > .v-icon ~ .v-list-item__spacer {
+  width: 10px;
+}
+
+.screen-menu__item:hover > .v-list-item__overlay {
+  opacity: 0;
+}
+
+.screen-menu__item:hover {
+  background: var(--hover);
+}
+
+.v-overlay__content > .v-list.screen-menu > .screen-menu__item--danger.v-list-item {
+  color: var(--err);
+}
+
+.screen-menu__item--danger .v-list-item__prepend > .v-icon {
+  color: var(--err);
+}
+
+.screen-menu__item--danger:hover {
+  background: var(--err-bg);
+}
+
+/* ------------------------------------------------------------------ */
+/* SIGNATURE PAD - `SignaturePad.vue`.                                 */
+/*                                                                     */
+/* DESIGN GAP, STATED: the handoff draws no signature pad and contains */
+/* no dashed border anywhere, so everything below is the established   */
+/* primitives and tokens, not a handoff literal. The one value taken   */
+/* from the handoff is the caption pair at line 659 - 12.5px / 600.    */
+/*                                                                     */
+/* THE PAD IS PAPER AND STAYS LIGHT IN BOTH THEMES, DELIBERATELY.      */
+/* The canvas ink is `#111` and `stop()` exports the drawing as a PNG  */
+/* that callers render back on light surfaces and print. A `--card`    */
+/* pad would be dark in the dark theme, so the signature would be      */
+/* black-on-black on the pad AND the exported PNG would be a black     */
+/* scrawl on transparency. The three literals here are the LIGHT theme */
+/* values of `--card`, `--border` and `--muted`, named so nobody has   */
+/* to guess where they came from.                                      */
+/* ------------------------------------------------------------------ */
+.screen-signpad {
+  position: relative;
+  overflow: hidden;
+  /* Light `--muted` at 55% - NOT `--border`. A drop zone's dashed edge is an
+     affordance and has to be seen; `--border` (rgb 232,232,225) on a white pad
+     is all but invisible, which the first render showed. This lands on the same
+     weight as the `#bbb` it replaces, from a token value rather than a hex. */
+  border: 1.5px dashed rgba(139, 143, 152, 0.55);
+  border-radius: var(--r-inner);
+  background: rgb(255, 255, 255); /* light `--card` */
+}
+
+.screen-signpad__canvas {
+  display: block;
+  width: 100%;
+  height: 130px;
+  cursor: crosshair;
+  touch-action: none;
+}
+
+.screen-signpad__hint {
+  position: absolute;
+  inset: 0;
+  display: flex;
+  align-items: center;
+  justify-content: center;
+  pointer-events: none;
+  font-family: var(--font-sans);
+  font-size: 12.5px;
+  font-weight: 600;
+  letter-spacing: 0;
+  color: rgb(139, 143, 152); /* light `--muted` - the pad is paper */
+}
+
+.screen-signpad__label {
+  font-family: var(--font-sans);
+  font-size: 12.5px;
+  font-weight: 600;
+  letter-spacing: 0;
+  color: var(--muted);
+}