@7365admin1/layer-common 3.2.1-staging.68 → 3.2.1-staging.70

package/.changeset/camera-wall-selection-and-guidance.md

@@ -0,0 +1,65 @@
+---
+"@7365admin1/layer-common": patch
+---
+
+Mark the selected camera on the wall, and stop telling the reader to raise a
+ticket without saying what for.
+
+Two things the owner found on the live wall after the last copy pass. Both are
+copy and presentation only — **no behaviour, no capability gating, no permission
+check and no request is changed.**
+
+**1. The camera's name was still printed twice.**
+
+The tile said `BBQ AREA` and the panel underneath said it again. The last pass
+merged the panel's heading into its status line, which changed the layout and
+left the repetition exactly where it was.
+
+The name was there to answer "which of these nine tiles is this panel about?".
+That is a real question and a name is the wrong answer to it — it makes the
+reader scan the wall for a matching caption. So:
+
+- **the selected tile is now visibly selected**: a 3 px accent ring with a scrim
+  hairline inside it, so the ring holds against a bright picture as well as a
+  dark one, plus the accent underline on the name chip that the toolbar already
+  uses to mark a selected tool. Both read at 1x1, 2x2 and 3x3;
+- **the camera's name is removed from the panel entirely**. The panel opens on
+  the recorder's state — "● Recorder responding";
+- `aria-current` marks the same tile for anyone not looking at the ring.
+
+The highlight had never worked in the most common case, which is why the name
+was load-bearing: it was bound to the raw clicked id, and before anyone clicks —
+or after paging — nothing on the wall was marked while the panel was already
+describing the first tile. It is now bound to the tile the panel actually
+resolves to, so the two can never disagree.
+
+**The panel can never be about a tile that is off screen**, so it never needs to
+name one: the focused camera is resolved out of the current PAGE, so paging away
+from a selection re-resolves to the first tile of the page in front of you and
+the ring follows. Paging back restores the original selection. Extracted as
+`focusedCamera()` in `camera-wall.ts` with four tests, including the 5-cameras
+-across-2-pages case.
+
+**2. "Ask your Seven365 administrator" was a dead end.**
+
+It was the whole of the advice under every switched-off control, and it tells
+the administrator nothing and a property manager only to go and wait. The screen
+never said what the request should ask for.
+
+The advice now names the two changes that are actually missing, because they are
+two different jobs for two different people: **the site's network has to let our
+server reach the camera recorder**, and **that recorder then has to be added to
+the server's configuration**. Both are stated in plain words, with who arranges
+them, and with the fact that neither is switchable from this page.
+
+No environment variable name appears in any of it — those belong in
+`iservice365-core/docs/camera-integration-config.md`, not on a property
+manager's screen — and there is a test that keeps it that way. The other reason
+codes (`device-http-disabled`, `device-http-unreachable`, `device-http-locked-out`,
+`control-not-enabled`, `no-recorder-configured`, and the unknown-code fallback)
+get the same treatment; the Site Settings ones already said what to do and are
+unchanged.
+
+The truthful-status rules are untouched: the wall still refuses to say "Live"
+until the video service reports a decoded frame, and the recorder's state is
+still a separate fact from the tile's badge.

package/.changeset/dark-primary-contrast.md

@@ -0,0 +1,39 @@
+---
+"@7365admin1/layer-common": patch
+---
+
+Split the dark theme's `primary` into a foreground colour and a fill, so text
+using it is readable again.
+
+Dark `primary` was set to the brand navy `#17506F` so the navigation drawer
+would read as a surface. That is the right value for a fill — a white label on
+it measures 8.70:1 — but Vuetify emits `.text-primary` from the same token, so
+every `class="text-primary"` sentence and every `color="primary"` icon, spinner
+and text button rendered navy on a dark background:
+
+|                        | before | now |
+|---|---|---|
+| `primary` as text on the dark page `#0E1319`   | 2.14:1 | **6.40:1** |
+| `primary` as text on a dark card `#1B242F`     | 1.80:1 | **5.38:1** |
+| `primary` as text on `surface-bright` `#26313E`| 1.52:1 | **4.53:1** |
+
+Dark `primary` is now `#5B9BE0`. That is not a new colour: it is the blue the
+camera wall already draws its accents in (`--vms-accent`), so the two dark
+surfaces in this product agree on one blue.
+
+The navigation drawer no longer depends on `primary`. Both themes gain a
+`brand-surface` colour — `#042134` light (identical to light `primary`, so
+light mode renders exactly as before) and `#17506F` dark — and
+`Layout/NavigationDrawer.vue` is painted with it. Its white label still reads
+16.51:1 light and 8.70:1 dark. `floating` was dropped from the drawer so it
+draws its own edge: the fill is 2.14:1 against the dark page, under the 3:1 a
+boundary wants, and the border at `border-opacity` 0.35 is 3.22:1.
+
+Where `primary` is still used as a fill, Vuetify derives `on-primary` from it
+and picks black, which reads at 7.21:1. What a light `primary` cannot carry is
+a hardcoded white label, and a handful of app-side sites still set one — see
+the pull request for the list.
+
+The light theme is unchanged. The colours moved to `utils/theme.ts` and
+`utils/theme.test.ts` now measures them, so a token cannot be moved for one use
+and quietly broken for the other again.

package/components/CameraWall.vue

@@ -126,7 +126,7 @@
             :online="online"
             :health="healthById[camera._id]"
             :now="now"
-            :focused="camera._id === focusedId"
+            :focused="camera._id === focused?._id"
             @focus="focusedId = $event._id"
           />
         </div>
@@ -171,32 +171,39 @@
     -->
     <div v-if="focused" class="vms__caps">
       <!--
-        THE HEADER IS GONE, AND THE CAMERA'S NAME IS NOW THE SUBJECT OF A
-        SENTENCE INSTEAD.
-
-        This panel used to open with the camera's name on its own line, directly
-        under a tile already captioned with that name. The owner saw it on the
-        live wall and asked why the name was there twice — a fair question,
-        because as a bare heading it was not doing anything the tile had not
-        already done.
-
-        It cannot simply be deleted: on a 3x3 wall the panel describes ONE of
-        nine tiles and the reader has to know which. So the name stays, once,
-        as the thing the status line is about — "BBQ AREA · Recorder
-        responding" is a statement, where "BBQ AREA" over "Recorder responding"
-        was a label followed by a fact about something unnamed.
+        THE CAMERA'S NAME IS GONE FROM THIS PANEL ENTIRELY. THE SELECTED TILE
+        SAYS WHICH CAMERA THIS IS.
+
+        It was here twice before: once as a heading, then — after a first
+        attempt at this — as the subject of the status line. The owner's point
+        was never the line break. It was the REPETITION: the tile directly above
+        is already captioned "BBQ AREA", and printing it again underneath adds
+        no fact.
+
+        The reason it was kept is real — the panel describes ONE of up to nine
+        tiles and the reader has to know which — but a name is the wrong way to
+        answer it. Naming a tile makes the reader search the wall for a matching
+        caption; an accent ring makes the wall answer at a glance. So the ring
+        is the identification (`vms-tile--focused`) and the panel is free to be
+        about the camera rather than about naming it.
+
+        **And the panel can never describe a tile that is off screen**, so it
+        never needs to fall back to naming one. `focused` is resolved out of
+        `tiles` — the CURRENT page — so paging away re-resolves it to the first
+        tile of the page you are now looking at. There is no state in which this
+        panel is about something you cannot see. That is asserted in
+        `camera-wall.test.ts` so it cannot quietly stop being true.
       -->
       <div class="vms__health">
-        <span class="vms__health-state">
-          <span class="vms__health-dot" :class="`vms__health-dot--${focusedHealth.tone}`" />
-          {{ focused.name || focused._id }}
-        </span>
         <!--
           THE RECORDER's own state — a different fact from the tile badge above,
           which is about the picture. They can disagree, and when they do the
           reader needs both, not a merged verdict.
         -->
-        <span class="vms__health-item">{{ focusedHealth.label }}</span>
+        <span class="vms__health-state">
+          <span class="vms__health-dot" :class="`vms__health-dot--${focusedHealth.tone}`" />
+          {{ focusedHealth.label }}
+        </span>
         <!--
           "Last picture" ONLY WHEN THERE HAS BEEN ONE.
 
@@ -283,6 +290,7 @@ import {
   capabilityView,
   clampPage,
   DEFAULT_WALL_LAYOUT,
+  focusedCamera,
   healthView,
   isDenseLayout,
   sharedCapabilityNote,
@@ -441,10 +449,28 @@ function togglePick(id: string) {
 
 /* --------------------------------------------------------- what is focused */
 
+/**
+ * WHICH TILE THE PANEL IS ABOUT — and it is always a tile you can see.
+ *
+ * `focusedId` is what somebody clicked; `focused` is what the panel actually
+ * describes, and the two are deliberately not the same thing. It is resolved out
+ * of `tiles`, which is the CURRENT PAGE, so:
+ *
+ * - before anyone clicks, the panel describes the first tile on the wall;
+ * - paging away from your selection re-resolves to the first tile of the page
+ *   you are now on, rather than describing a camera that is no longer drawn;
+ * - paging back returns to your selection, because `focusedId` is not cleared.
+ *
+ * **The tile highlight is bound to `focused`, not to `focusedId`** — that one
+ * character was the whole defect behind "the panel repeats the tile's name".
+ * Bound to `focusedId`, the fallback cases above lit NO tile at all: the panel
+ * described the first camera on the page and nothing on the wall said so, which
+ * is exactly why the name had to be printed in the panel to make sense of it.
+ * Bound to `focused`, the wall always shows which tile is being described, and
+ * the name in the panel becomes the repetition the owner said it was.
+ */
 const focusedId = ref("");
-const focused = computed(
-  () => tiles.value.find((c) => c._id === focusedId.value) || tiles.value[0] || null
-);
+const focused = computed(() => focusedCamera(tiles.value, focusedId.value));
 
 function capability(key: string) {
   return capabilityView(focused.value, key);

package/components/CameraWallTile.vue

@@ -5,6 +5,7 @@
     :class="{ 'vms-tile--dense': dense, 'vms-tile--focused': focused, 'vms-tile--empty': !camera }"
     :tabindex="camera ? 0 : -1"
     :aria-label="camera ? `${camera.name || camera._id}, ${view.label}` : 'Empty position'"
+    :aria-current="focused ? 'true' : undefined"
     @click="camera && $emit('focus', camera)"
     @dblclick="camera && toggleFullscreen()"
     @keydown.enter="camera && toggleFullscreen()"
@@ -486,8 +487,40 @@ async function toggleFullscreen() {
   min-height: 0;
 }
 
+/*
+  THE SELECTED TILE, AND WHY IT IS NOW LOUDER.
+
+  The panel under the wall describes ONE tile. It used to say which by printing
+  the camera's name — directly under a tile already captioned with that name —
+  because the ring here was too quiet to be doing that job: 2 px of #5b9be0
+  disappears against a bright picture, and at nine tiles it was a hairline the
+  eye skipped. So the panel was answering "which one?" in words, and the words
+  read as the name repeated twice.
+
+  Two marks now, and between them they hold at 1x1, 2x2 and 3x3:
+
+  - a **3 px accent ring**, with a 1 px scrim hairline INSIDE it. The hairline is
+    what makes the ring survive a white picture — accent-on-white is a weak edge,
+    accent-on-near-black is not, so the ring carries its own dark backing rather
+    than depending on what the camera happens to be pointing at.
+  - the **name chip underlined in the accent**, which is the same mark the
+    toolbar already uses for a selected tool (`.vms__tool--on`). At 3x3 the ring
+    is 3 px on a ~118 px tile; the underline sits right beside the caption a
+    supervisor is already reading, so identification does not depend on
+    perceiving 3 px from across a room.
+
+  INVENTED VALUES, recorded: the ring is 3 px where it was 2 px. Everything else
+  is existing — `--vms-accent`, `--vms-scrim-solid`, and the toolbar's 2 px
+  underline idiom. No new colour.
+*/
 .vms-tile--focused {
-  box-shadow: inset 0 0 0 2px var(--vms-accent, #5b9be0);
+  box-shadow:
+    inset 0 0 0 3px var(--vms-accent, #5b9be0),
+    inset 0 0 0 4px var(--vms-scrim-solid, rgba(7, 9, 12, 0.82));
+}
+
+.vms-tile--focused .vms-tile__name {
+  box-shadow: inset 0 -2px 0 var(--vms-accent, #5b9be0);
 }
 
 .vms-tile:focus-visible {

package/components/Layout/NavigationDrawer.vue

@@ -1,6 +1,18 @@
 <!-- LayoutNavigationDrawer.vue -->
 <template>
-  <v-navigation-drawer v-model="drawer" permanent floating class="bg-primary">
+  <!--
+    `bg-brand-surface`, not `bg-primary`: `primary` is a foreground colour on a
+    dark page (it has to carry `class="text-primary"` sentences at 4.5:1), and a
+    fill that carries a white label cannot also be that. `brand-surface` is the
+    deep brand navy in both themes - identical to light `primary`, so light mode
+    is unchanged - and the white label on it reads 16.51:1 light, 8.70:1 dark.
+
+    `floating` dropped so the drawer draws its own edge. The fill is 2.14:1
+    against the dark page, under the 3:1 a boundary wants; the border is 3.22:1
+    and carries it. In light mode the border is black at 0.26 over the navy, so
+    nothing there changes.
+  -->
+  <v-navigation-drawer v-model="drawer" permanent class="bg-brand-surface">
     <v-list>
       <v-list-item>
         <v-list-item-title class="text-h6 text-white">

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "3.2.1-staging.68",
+  "version": "3.2.1-staging.70",
   "author": "7365admin1",
   "main": "./nuxt.config.ts",
   "publishConfig": {

package/plugins/vuetify.ts

@@ -42,66 +42,7 @@ import {
 } from "vuetify-pro-tiptap";
 import "vuetify-pro-tiptap/style.css";
 
-/**
- * Contrast decisions live here rather than inline, because both themes need the
- * same two opacity corrections and a value that differs by accident between
- * light and dark is a bug nobody sees until somebody flips the switch.
- *
- * `disabled-opacity`: Material's 0.38 measures 2.68:1 on white, below the 4.5:1
- * a sentence needs, and disabled fields in this product carry sentences people
- * are expected to read. 0.55 is 4.74:1 on white and 6.21:1 on the dark page -
- * the same value the camera wall settled on, for the same reason.
- *
- * `border-opacity`: 0.12 measures 1.32:1, which is a divider you cannot see.
- * Dark goes to 0.35 (3.22:1) and carries the boundary properly. Light goes to
- * 0.26 (1.88:1) - visible, but short of the 3:1 a component boundary wants.
- * Reaching it on white needs 0.42, which turns every table and card edge into a
- * mid-grey grid across eleven applications; that is a change somebody should
- * look at before it ships, not one to slip in behind a contrast fix.
- */
-const LIGHT_THEME = {
-  dark: false,
-  colors: {
-    primary: "#042134",
-    "primary-button": "#1867C0",
-    "text-primary": "#052439",
-  },
-  variables: {
-    "disabled-opacity": 0.55,
-    "border-opacity": 0.26,
-  },
-};
-
-/**
- * Only the keys that must differ; Vuetify merges the rest from its stock dark.
- */
-const DARK_THEME = {
-  dark: true,
-  colors: {
-    /**
-     * Stock dark's #121212 page and #212121 surface measure 1.16:1 apart, so a
-     * card, a dialog and the page behind them were one flat sheet. These are
-     * 1.19:1 - elevation on a dark screen is a genuinely small delta - but they
-     * are tinted towards the brand navy rather than neutral grey, and the
-     * divider opacity above is what actually draws the edges.
-     */
-    background: "#0E1319",
-    surface: "#1B242F",
-    /** Stock dark ships a lavender #ccbfd6 here, which is not our product. */
-    "surface-bright": "#26313E",
-    "surface-light": "#26313E",
-    /** The brand navy lifted until the nav drawer is a surface, not a hole. */
-    primary: "#17506F",
-    /** Unchanged on purpose: it already passes in both themes. */
-    "primary-button": "#1867C0",
-    /** #052439 on a dark page measures 1.18:1. This is 15.72:1. */
-    "text-primary": "#E8ECF1",
-  },
-  variables: {
-    "disabled-opacity": 0.55,
-    "border-opacity": 0.35,
-  },
-};
+import { LIGHT_THEME, DARK_THEME } from "../utils/theme";
 
 export default defineNuxtPlugin((app) => {
   const vuetify = createVuetify({
@@ -152,18 +93,8 @@ export default defineNuxtPlugin((app) => {
      * means the toggle, `v-theme-provider theme="light"`, the `plain-dark`
      * layout and all of those comparisons keep working, and start being right.
      *
-     * Measured, not eyeballed - WCAG 2.1, alpha composited against the surface
-     * each value actually sits on:
-     *
-     *   text-primary on the page       dark   1.18:1 -> 15.72:1
-     *   nav drawer fill vs the page    dark   1.13:1 ->  2.14:1 (+ a real border)
-     *   white label in the nav drawer  dark   3.12:1 ->  8.70:1
-     *   primary-button vs the page     dark   3.34:1 ->  3.32:1 (unchanged)
-     *   white label on that button     both   5.61:1 ->  5.61:1 (unchanged)
-     *   disabled text                  light  2.68:1 ->  4.74:1
-     *   disabled text                  dark   3.57:1 ->  6.21:1
-     *   divider / outline              dark   1.38:1 ->  3.22:1
-     *   divider / outline              light  1.32:1 ->  1.88:1
+     * The colours themselves, and every ratio they were chosen for, are in
+     * `utils/theme.ts`, which `utils/theme.test.ts` measures on every run.
      */
     theme: {
       defaultTheme: "light",

package/utils/camera-wall.test.ts

@@ -4,9 +4,11 @@ import { test } from "node:test";
 import {
   agoLabel,
   capabilityView,
+  CAPABILITY_NEXT_STEPS,
   clampPage,
   clampPan,
   clampZoom,
+  focusedCamera,
   healthView,
   isDenseLayout,
   playerOrigin,
@@ -70,6 +72,46 @@ test("a selection sets the order, and a stale id is dropped rather than drawn",
   assert.equal(tiles[0]._id, "b");
 });
 
+/* ------------------------------------------- which tile the panel is about */
+
+/*
+  THE PANEL STOPPED PRINTING THE CAMERA'S NAME, AND THESE ARE THE TWO FACTS
+  THAT LET IT.
+
+  The name was there so the reader could tell which of up to nine tiles the
+  panel described. It is now the selected tile's accent ring that answers that —
+  which is only safe while the panel can never be about a tile that is not
+  drawn. Five cameras across two pages is exactly the case the owner asked
+  about, so it is exactly the case pinned here.
+*/
+const FIVE = ["a", "b", "c", "d", "e"].map((id) => ip({ _id: id, name: id.toUpperCase() }));
+
+test("nothing selected yet: the panel is about the first tile ON THIS PAGE", () => {
+  assert.equal(focusedCamera(wallTiles(FIVE, [], "2x2", 0), "")?._id, "a");
+  // Page 2 of the same wall holds one camera, and the panel is about that one —
+  // not still about "a", which is no longer on screen.
+  assert.equal(focusedCamera(wallTiles(FIVE, [], "2x2", 1), "")?._id, "e");
+});
+
+test("paging away from your selection never leaves the panel describing an off-page camera", () => {
+  // Selected "a" on page 1, then paged to page 2. "a" is not drawn there.
+  const pageTwo = wallTiles(FIVE, [], "2x2", 1);
+  const shown = focusedCamera(pageTwo, "a");
+  assert.equal(shown?._id, "e");
+  assert.ok(
+    pageTwo.some((c) => c._id === shown?._id),
+    "the panel must always describe a tile on the current page"
+  );
+});
+
+test("paging back restores the selection, because the raw id is kept", () => {
+  assert.equal(focusedCamera(wallTiles(FIVE, [], "2x2", 0), "c")?._id, "c");
+});
+
+test("an empty wall has nothing to describe", () => {
+  assert.equal(focusedCamera([], "a"), null);
+});
+
 /* ---------------------------------------------------------------- rule 2/3 */
 
 test("no descriptor at all counts as NOT available", () => {
@@ -132,7 +174,38 @@ test("a switched-off control says what would switch it on and who to ask", () =>
   // The server's sentence is still verbatim — rule 3 is not traded away for rule 5.
   assert.match(v.detail, /^No direct connection/);
   assert.match(v.nextStep, /Seven365 administrator/);
-  assert.match(v.nextStep, /not something to switch on from this page/i);
+  assert.match(v.nextStep, /not switchable from this page/i);
+});
+
+/*
+  THE ADVICE HAS TO NAME THE TWO CHANGES, AND IT HAS TO STAY OUT OF THE
+  DEPLOYMENT MANUAL.
+
+  "Ask your Seven365 administrator" was the whole of the old advice and it was a
+  dead end — worse than useless for the owner, who IS the administrator. What
+  makes the new line actionable is that it names the two real changes: the
+  network has to let the server reach the recorder, and the recorder then has to
+  be configured on the server. Both halves are pinned here, because dropping
+  either one silently returns the sentence to a shrug.
+
+  And the other direction is pinned too: no environment variable name may appear
+  in copy a property manager reads. The names are correct, they are in
+  `iservice365-core/docs/camera-integration-config.md`, and they are unreadable
+  to the person this screen is written for.
+*/
+test("the setup advice names the network change AND the server change", () => {
+  const advice = CAPABILITY_NEXT_STEPS["device-http-not-configured"];
+  assert.match(advice, /network/i);
+  assert.match(advice, /recorder/i);
+  assert.match(advice, /server's configuration/i);
+});
+
+test("no environment variable name is ever shown to a reader", () => {
+  // Anything SCREAMING_SNAKE would be a deployment detail leaking into product
+  // copy. `CAMERA_DEVICE_HTTP` and friends belong in the deployment document.
+  for (const [reason, advice] of Object.entries(CAPABILITY_NEXT_STEPS)) {
+    assert.doesNotMatch(advice, /[A-Z][A-Z0-9]*_[A-Z0-9_]+/, `${reason} names a variable`);
+  }
 });
 
 /* ---------------------------------------------------------------- rule 7 */

package/utils/camera-wall.ts

@@ -196,6 +196,30 @@ export function wallTiles(
   return chosen.slice(start, start + tiles);
 }
 
+/**
+ * WHICH TILE THE DETAIL PANEL IS ABOUT, and the guarantee that makes the panel
+ * able to stop naming it.
+ *
+ * The panel used to print the camera's name so the reader could tell which of
+ * up to nine tiles it was describing. The name is gone — the selected tile wears
+ * an accent ring instead — and that only works because **this can never return a
+ * camera that is not on the page being looked at.** It resolves out of the
+ * CURRENT page's tiles, so a selection left behind on page 1 does not leave the
+ * panel describing an invisible camera from page 2; it falls back to the first
+ * tile of the page you are actually on, which the ring then marks.
+ *
+ * The caller keeps the raw id, so paging back restores the original selection.
+ *
+ * Extracted from the component purely so this guarantee is a tested rule rather
+ * than a line of template nobody would think to check.
+ */
+export function focusedCamera(
+  tiles: TWallCamera[],
+  focusedId: string | undefined
+): TWallCamera | null {
+  return tiles.find((c) => c._id === focusedId) || tiles[0] || null;
+}
+
 /**
  * How many grid rows this page actually needs — the other half of packing.
  *
@@ -253,22 +277,49 @@ const NOT_PROBED = "This camera has not been asked what it can do yet.";
  * **Every one of these says the same true and unwelcome thing in a different
  * way: none of it is switched on from this page.** Saying so plainly is the
  * point. An empty settings screen that quietly does nothing would be worse.
+ *
+ * ## "Ask your Seven365 administrator" was a dead end, and it has been replaced
+ *
+ * That was the whole of the advice, and the owner — who IS the administrator —
+ * read it on the live wall and pointed out that it tells him nothing. It tells a
+ * property manager nothing either: they raise a ticket and wait, because the
+ * screen never said what the ticket should ASK FOR.
+ *
+ * The real answer is two changes, and they are two different jobs for two
+ * different people:
+ *
+ *  1. **a network change** — the site's network has to let our server reach the
+ *     camera recorder. Today it does not: the recorder answers video only.
+ *  2. **a configuration change on our server** — that recorder then has to be
+ *     added to the server's configuration.
+ *
+ * So each line below names the change that is missing and who does it, in that
+ * order. **No environment variable is named**, deliberately: the names belong in
+ * the deployment documentation (`iservice365-core/docs/camera-integration-config.md`),
+ * not on a property manager's screen, and printing them would make the sentence
+ * unreadable to the person it is written for without helping the person who
+ * needs them, who has the document.
+ *
+ * Nor does any line point at the camera setup guide. That guide covers ADDING a
+ * camera in Site Settings; it does not cover recorder connectivity, so sending
+ * the reader there would be sending them somewhere that does not answer the
+ * question. Naming the two changes IS the actionable content.
  */
 export const CAPABILITY_NEXT_STEPS: Record<string, string> = {
   "device-http-not-configured":
-    "Not something to switch on from this page — it needs a change on the server. Ask your Seven365 administrator.",
+    "Not switchable from this page. It needs the site's network opened so our server can reach the camera recorder, and that recorder then added to the server's configuration — your Seven365 administrator arranges both with whoever installed the cameras.",
   "device-http-disabled":
-    "Switched off on the server. Ask your Seven365 administrator to switch it on.",
+    "Not switchable from this page. The connection to the recorder exists but is turned off in the server's configuration — your Seven365 administrator turns it on.",
   "device-http-unreachable":
-    "The recorder is not answering. Ask your Seven365 administrator or the camera installer to check it.",
+    "Our server cannot reach this camera's recorder. Usually the site's network is blocking it or the recorder is down — your Seven365 administrator and whoever installed the cameras check it between them.",
   "device-http-locked-out":
-    "Sign-ins to the recorder are being held back so its account is not locked out. Ask your Seven365 administrator.",
+    "Sign-ins to the recorder are being held back so its account is not locked out. It clears on its own; if it keeps happening the password held for the recorder is wrong and your Seven365 administrator corrects it in the server's configuration.",
   "control-not-enabled":
-    "Switched off on the server. It moves real hardware, so a Seven365 backend lead has to approve it first.",
+    "Not switchable from this page. This one moves real hardware, so a Seven365 backend lead has to approve it before it is turned on in the server's configuration.",
   "device-no-ptz":
     "This camera cannot move, so there is nothing to switch on. A different camera would be needed.",
   "no-recorder-configured":
-    "No recorder is set up for this camera's video service. Ask your Seven365 administrator to add it.",
+    "Not switchable from this page. This camera's video service has no recorder linked to it in the server's configuration — your Seven365 administrator adds it.",
   "no-channel-in-address":
     "This camera's address does not say which stream it is. Correct it in Site Settings, under CCTV.",
   "not-a-relay-player-url":
@@ -292,7 +343,7 @@ export const CAPABILITY_NEXT_STEPS: Record<string, string> = {
  * setting on this page, and there is still somebody to ask.
  */
 const NEXT_STEP_FALLBACK =
-  "This is not something to switch on from this page. Ask your Seven365 administrator.";
+  "Not switchable from this page — it needs a change to the server's configuration, which your Seven365 administrator makes.";
 
 /**
  * The capabilities the wall draws a control for, and their plain names.

package/utils/theme.test.ts

@@ -0,0 +1,121 @@
+import assert from "node:assert/strict";
+import { test } from "node:test";
+
+import { DARK_THEME, LIGHT_THEME } from "./theme.ts";
+
+/**
+ * The dark theme was shipped once with `primary` chosen for the one place it
+ * was a fill, which left the twenty-six places it is a sentence at 1.80:1.
+ * These are the measurements that would have caught it.
+ *
+ * WCAG 2.1 relative luminance and contrast ratio, nothing else.
+ */
+const luminance = (hex: string): number => {
+  const channels = [0, 2, 4]
+    .map((i) => parseInt(hex.slice(1 + i, 3 + i), 16) / 255)
+    .map((c) => (c <= 0.03928 ? c / 12.92 : Math.pow((c + 0.055) / 1.055, 2.4)));
+
+  return 0.2126 * channels[0] + 0.7152 * channels[1] + 0.0722 * channels[2];
+};
+
+const contrast = (a: string, b: string): number => {
+  const [x, y] = [luminance(a), luminance(b)];
+
+  return (Math.max(x, y) + 0.05) / (Math.min(x, y) + 0.05);
+};
+
+const WHITE = "#FFFFFF";
+const dark = DARK_THEME.colors;
+const light = LIGHT_THEME.colors;
+
+/** Sanity check on the measuring tape before it is used to judge anything. */
+test("contrast is measured the way WCAG measures it", () => {
+  assert.equal(contrast(WHITE, "#000000").toFixed(2), "21.00");
+  assert.equal(contrast("#777777", WHITE).toFixed(2), "4.48");
+});
+
+test("dark primary is readable as text on the page, a card and a menu", () => {
+  assert.ok(
+    contrast(dark.primary, dark.background) >= 4.5,
+    `primary on the page: ${contrast(dark.primary, dark.background).toFixed(2)}`
+  );
+  assert.ok(
+    contrast(dark.primary, dark.surface) >= 4.5,
+    `primary on a card: ${contrast(dark.primary, dark.surface).toFixed(2)}`
+  );
+  assert.ok(
+    contrast(dark.primary, dark["surface-bright"]) >= 4.5,
+    `primary on surface-bright: ${contrast(
+      dark.primary,
+      dark["surface-bright"]
+    ).toFixed(2)}`
+  );
+});
+
+test("light primary is readable as text on white", () => {
+  assert.ok(contrast(light.primary, WHITE) >= 4.5);
+  assert.ok(contrast(light["text-primary"], WHITE) >= 4.5);
+});
+
+test("text-primary is readable on the surface each theme puts it on", () => {
+  assert.ok(contrast(dark["text-primary"], dark.background) >= 4.5);
+  assert.ok(contrast(dark["text-primary"], dark.surface) >= 4.5);
+});
+
+/**
+ * The drawer is the reason `primary` was moved in the first place. If someone
+ * points it back at `primary` this fails, because a foreground colour cannot
+ * carry a white label.
+ */
+test("the nav drawer fill carries a white label in both themes", () => {
+  assert.ok(
+    contrast(WHITE, dark["brand-surface"]) >= 4.5,
+    `white on the dark drawer: ${contrast(
+      WHITE,
+      dark["brand-surface"]
+    ).toFixed(2)}`
+  );
+  assert.ok(contrast(WHITE, light["brand-surface"]) >= 4.5);
+});
+
+test("light mode's drawer fill is exactly what light primary used to be", () => {
+  assert.equal(light["brand-surface"], light.primary);
+});
+
+test("primary-button carries a white label in both themes", () => {
+  assert.ok(contrast(WHITE, dark["primary-button"]) >= 4.5);
+  assert.ok(contrast(WHITE, light["primary-button"]) >= 4.5);
+});
+
+/**
+ * Both themes correct the same two Vuetify defaults, and a value that drifts
+ * apart between them is a bug nobody sees until they flip the switch.
+ */
+test("disabled text clears 4.5:1 on the surface each theme puts it on", () => {
+  const over = (fg: string, bg: string, alpha: number) =>
+    "#" +
+    [0, 2, 4]
+      .map((i) =>
+        Math.round(
+          parseInt(fg.slice(1 + i, 3 + i), 16) * alpha +
+            parseInt(bg.slice(1 + i, 3 + i), 16) * (1 - alpha)
+        )
+          .toString(16)
+          .padStart(2, "0")
+      )
+      .join("");
+
+  assert.equal(LIGHT_THEME.variables["disabled-opacity"], 0.55);
+  assert.equal(DARK_THEME.variables["disabled-opacity"], 0.55);
+  assert.ok(contrast(over("#000000", WHITE, 0.55), WHITE) >= 4.5);
+  assert.ok(
+    contrast(over(WHITE, dark.background, 0.55), dark.background) >= 4.5
+  );
+});
+
+test("the dark divider clears the 3:1 a boundary wants", () => {
+  const border = "#62666a"; // white at 0.35 over the dark page
+
+  assert.equal(DARK_THEME.variables["border-opacity"], 0.35);
+  assert.ok(contrast(border, dark.background) >= 3);
+});

package/utils/theme.ts

@@ -0,0 +1,101 @@
+/**
+ * THE TWO THEMES THIS PRODUCT SHIPS.
+ *
+ * They live here rather than inline in `plugins/vuetify.ts` so that
+ * `utils/theme.test.ts` can measure them. Every ratio quoted below is WCAG 2.1,
+ * alpha composited against the surface the value actually sits on, and the test
+ * re-measures the ones that matter on every run - this file has already been
+ * got wrong once by moving a colour for one use and forgetting the other.
+ *
+ * `disabled-opacity`: Material's 0.38 measures 2.68:1 on white, below the 4.5:1
+ * a sentence needs, and disabled fields in this product carry sentences people
+ * are expected to read. 0.55 is 4.74:1 on white and 6.21:1 on the dark page -
+ * the same value the camera wall settled on, for the same reason.
+ *
+ * `border-opacity`: 0.12 measures 1.32:1, which is a divider you cannot see.
+ * Dark goes to 0.35 (3.22:1) and carries the boundary properly. Light goes to
+ * 0.26 (1.88:1) - visible, but short of the 3:1 a component boundary wants.
+ * Reaching it on white needs 0.42, which turns every table and card edge into a
+ * mid-grey grid across eleven applications; that is a change somebody should
+ * look at before it ships, not one to slip in behind a contrast fix.
+ */
+
+/**
+ * `primary` IS BOTH A FILL AND A FOREGROUND, AND ONE VALUE CANNOT SERVE BOTH.
+ *
+ * Vuetify emits `.bg-primary` and `.text-primary` from the same token, so the
+ * colour that fills the navigation drawer is also the colour of every
+ * `class="text-primary"` sentence, every `color="primary"` icon, spinner and
+ * text button, and the focused outline on every input. On a dark page those
+ * pull in opposite directions: a fill that carries a white label wants to be
+ * dark, and a foreground that is readable on a dark card wants to be light.
+ * There is no overlap - a value light enough for 4.5:1 text on `surface`
+ * (#1B242F) can carry white at 3.48:1 at the very best.
+ *
+ * So the fill is not `primary` any more. `brand-surface` below is the deep
+ * brand navy, it is what the navigation drawer is painted with, and `primary`
+ * is free to be a foreground colour. The foreground uses outnumber the fill
+ * uses by roughly an order of magnitude, which is why the split falls this way
+ * round.
+ */
+export const LIGHT_THEME = {
+  dark: false,
+  colors: {
+    primary: "#042134",
+    /**
+     * The navigation drawer's own fill. Identical to light `primary`, so light
+     * mode renders exactly as it did before the drawer stopped using `primary`.
+     * White label on it: 16.51:1.
+     */
+    "brand-surface": "#042134",
+    "primary-button": "#1867C0",
+    "text-primary": "#052439",
+  },
+  variables: {
+    "disabled-opacity": 0.55,
+    "border-opacity": 0.26,
+  },
+};
+
+/**
+ * Only the keys that must differ; Vuetify merges the rest from its stock dark.
+ */
+export const DARK_THEME = {
+  dark: true,
+  colors: {
+    /**
+     * Stock dark's #121212 page and #212121 surface measure 1.16:1 apart, so a
+     * card, a dialog and the page behind them were one flat sheet. These are
+     * 1.19:1 - elevation on a dark screen is a genuinely small delta - but they
+     * are tinted towards the brand navy rather than neutral grey, and the
+     * divider opacity above is what actually draws the edges.
+     */
+    background: "#0E1319",
+    surface: "#1B242F",
+    /** Stock dark ships a lavender #ccbfd6 here, which is not our product. */
+    "surface-bright": "#26313E",
+    "surface-light": "#26313E",
+    /**
+     * A FOREGROUND colour, chosen to be read: 6.40:1 on the page, 5.38:1 on a
+     * card, 4.53:1 on the bright surface. Not a new colour - it is the blue the
+     * camera wall already draws its accents in (`--vms-accent`), so the two
+     * dark surfaces in this product now agree on one blue.
+     *
+     * Where it is still used as a fill, Vuetify derives `on-primary` from it
+     * and picks black, which reads at 7.21:1. What it cannot carry is a
+     * hardcoded white label - see the note in the PR for the app-side sites
+     * that still do that.
+     */
+    primary: "#5B9BE0",
+    /** The navigation drawer's own fill. White label on it: 8.70:1. */
+    "brand-surface": "#17506F",
+    /** Unchanged on purpose: it already passes in both themes. */
+    "primary-button": "#1867C0",
+    /** #052439 on a dark page measures 1.18:1. This is 15.72:1. */
+    "text-primary": "#E8ECF1",
+  },
+  variables: {
+    "disabled-opacity": 0.55,
+    "border-opacity": 0.35,
+  },
+};