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

package/.changeset/camera-wall-plain-english.md

@@ -0,0 +1,60 @@
+---
+"@7365admin1/layer-common": patch
+---
+
+Rewrite the camera wall's detail panel for the people who read it, and stop
+repeating the same sentence four times.
+
+The panel under the tiles was written for a developer. On the live wall it
+read:
+
+> BBQ AREA
+> The video page loaded, but this browser cannot confirm a picture is arriving.
+> The player belongs to the video service and a browser cannot look inside it.
+> Judge the tile by what you can see, and report a blank or frozen picture.
+> ● Recorder responding   Last picture this server received: none yet
+> Firmware and device clock are not available: this recorder is reachable over
+> video only.
+
+Every one of those statements is true, and the screen was still wrong: it
+explained cross-origin isolation to a guard, repeated the camera's name the
+tile already showed, put a green light beside the words "none yet", and printed
+the same reason on four capability cards in a row.
+
+Changes, all copy and layout — **no behaviour, no capability gating and no
+permission check is touched**:
+
+- **The badge reads "Not confirmed"**, not "Not verified". "Not verified"
+  describes a check we failed to make; "Not confirmed" describes the picture,
+  which is the thing the reader cares about. Same claim, and the wall still
+  refuses to say "Live" until the video service reports a decoded frame.
+- **The sentence behind it is now an instruction**: "This page cannot confirm
+  the picture is arriving, so check the tile yourself. If it is blank or frozen,
+  report the camera." Why the software cannot confirm it is our problem, and it
+  has been removed from the product.
+- **The camera's name is no longer a heading of its own.** It is the subject of
+  the status line — "BBQ AREA · Recorder responding" — so a reader on a 3x3 wall
+  still knows which tile the panel describes, without a second caption under the
+  first one.
+- **"Last picture" is drawn only when there has been one.** A green "Recorder
+  responding" beside "none yet" read as a contradiction. They were never in
+  conflict, but a screen that has to be explained is wrong. The tile's own
+  health line has always behaved this way; the panel now matches it.
+- **The firmware-and-device-clock sentence is gone**, from the panel and from
+  the tile's tooltip. This screen never showed either value, so explaining their
+  absence gave the reader nothing to do. The server still sends
+  `detailUnavailableReason`; nothing draws it.
+- **One reason for the group instead of four copies.** When every switched-off
+  control is off for the same reason, that reason and its next step are stated
+  once above the row and each card keeps only its title and its state. When the
+  reasons differ — "the recorder is unreachable" and "this camera cannot move"
+  are two problems with two different people to ask — the group note is refused
+  and each card carries its own again. New rule 7, in `camera-wall.ts`, with
+  four tests.
+- Shorter next-step and no-signal wording, and a subject on the recorder's
+  status labels ("Recorder not checked yet" rather than "Health not checked
+  yet").
+
+Rules 3 and 6 are intact: the server's own sentence is still shown verbatim and
+never rewritten, and the recorder's state is still a separate fact from the
+tile's badge.

package/components/CameraWall.vue

@@ -170,44 +170,73 @@
       ask for it, and hiding it is what stops anyone asking.
     -->
     <div v-if="focused" class="vms__caps">
-      <p class="vms__caps-head">{{ focused.name || focused._id }}</p>
-
       <!--
-        HEALTH — the recorder's own state, which is a different fact from the
-        tile badge above it (that one is about the video page loading). They can
-        disagree, and when they do a supervisor needs both, not a merged verdict.
-
-        Firmware and the device clock are blank on this estate and the server
-        says why, in its own words. An empty field with no explanation reads as
-        "checked, and fine", which would be the opposite of the truth.
+        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.
       -->
-      <!--
-        WHAT THE BADGE ON THE TILE ACTUALLY MEANS, said once here rather than
-        nine times across the wall. "Not verified" is a word a supervisor has
-        every right to challenge, and the answer — the picture belongs to
-        another origin's page and a browser cannot look inside it — is too long
-        for a tile and too important to leave out.
-      -->
-      <p v-if="embedsPlayer" class="vms__badge-note">{{ UNVERIFIED_DETAIL }}</p>
-
       <div class="vms__health">
         <span class="vms__health-state">
           <span class="vms__health-dot" :class="`vms__health-dot--${focusedHealth.tone}`" />
-          {{ focusedHealth.label }}
+          {{ focused.name || focused._id }}
         </span>
-        <span class="vms__health-item">
-          Last picture this server received:
-          <b>{{ focusedHealth.lastFrame || "none yet" }}</b>
+        <!--
+          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>
+        <!--
+          "Last picture" ONLY WHEN THERE HAS BEEN ONE.
+
+          It used to read "Last picture this server received: none yet" beside a
+          green "Recorder responding", and the two together read as a
+          contradiction: a green light next to "none yet" tells a guard nothing
+          they can act on. They were never in conflict — one is the recorder
+          answering, the other is a still frame this server has never been set
+          up to fetch — but a screen that has to be explained is a screen that
+          is wrong. When there IS a picture, its age is worth knowing and it is
+          shown. When there is not, the line is silent, exactly as the tile's
+          own health line has always behaved.
+        -->
+        <span v-if="focusedHealth.lastFrame" class="vms__health-item">
+          Last picture <b>{{ focusedHealth.lastFrame }}</b>
         </span>
         <span v-if="focusedHealth.detail" class="vms__health-item">
           {{ focusedHealth.detail }}
         </span>
-        <span v-if="focusedHealth.deviceDetail" class="vms__health-item">
-          {{ focusedHealth.deviceDetail }}
-        </span>
         <span v-if="healthFailed" class="vms__health-item">{{ healthFailed }}</span>
       </div>
 
+      <!--
+        WHAT THE TILE's BADGE MEANS, said once here rather than nine times
+        across the wall — and said in the reader's terms, not ours. See
+        `UNVERIFIED_DETAIL`.
+      -->
+      <p v-if="embedsPlayer" class="vms__badge-note">{{ UNVERIFIED_DETAIL }}</p>
+
+      <p class="vms__caps-head">Camera controls</p>
+      <!--
+        RULE 7. One reason, stated once, when it is genuinely one reason — see
+        `sharedCapabilityNote`. When the reasons differ the note is `null` and
+        every card carries its own, as before.
+      -->
+      <div v-if="sharedNote" class="vms__caps-note">
+        <p class="vms__cap-detail">{{ sharedNote.detail }}</p>
+        <p v-if="sharedNote.nextStep" class="vms__cap-next">{{ sharedNote.nextStep }}</p>
+      </div>
+
       <div class="vms__caps-row">
         <div
           v-for="c in WALL_CAPABILITY_CONTROLS"
@@ -224,17 +253,21 @@
               {{ capability(c.key).tag }}
             </span>
           </p>
-          <!-- Working: what it does HERE. Off: the server's sentence, verbatim. -->
-          <p class="vms__cap-detail">
-            {{ capability(c.key).available ? c.ready : capability(c.key).detail }}
-          </p>
+          <!--
+            Working: what it does HERE. Off: the server's sentence, verbatim
+            (rule 3) — unless the whole group shares that sentence, in which
+            case it has already been said once above and the card carries only
+            its title and its tag.
+          -->
+          <p v-if="capabilityText(c)" class="vms__cap-detail">{{ capabilityText(c) }}</p>
           <!--
             RULE 5. The line the server cannot write, because it does not know
             who the reader can go and ask. Somebody read "Not set up yet" on this
             screen and asked how to set it up — which is a fair question that the
-            screen was not answering.
+            screen was not answering. Suppressed here for the same reason as
+            the sentence above it: it is in the group note.
           -->
-          <p v-if="capability(c.key).nextStep" class="vms__cap-next">
+          <p v-if="!sharedNote && capability(c.key).nextStep" class="vms__cap-next">
             {{ capability(c.key).nextStep }}
           </p>
         </div>
@@ -252,6 +285,7 @@ import {
   DEFAULT_WALL_LAYOUT,
   healthView,
   isDenseLayout,
+  sharedCapabilityNote,
   wallCameras,
   wallLayout,
   wallPageCount,
@@ -417,7 +451,29 @@ function capability(key: string) {
 }
 
 /**
- * Whether this camera embeds a player at all — i.e. whether the "Not verified"
+ * Rule 7: the one reason the whole group is off, or `null` when they differ.
+ * When it is set, the cards stop repeating it — see the template.
+ */
+const sharedNote = computed(() =>
+  sharedCapabilityNote(
+    focused.value,
+    WALL_CAPABILITY_CONTROLS.map((c) => c.key)
+  )
+);
+
+/**
+ * What one card says under its title: what the control does when it works, the
+ * server's reason when it does not, and NOTHING when that reason has already
+ * been given once for the group.
+ */
+function capabilityText(control: (typeof WALL_CAPABILITY_CONTROLS)[number]) {
+  const view = capability(control.key);
+  if (view.available) return control.ready;
+  return sharedNote.value ? "" : view.detail;
+}
+
+/**
+ * Whether this camera embeds a player at all — i.e. whether the "Not confirmed"
  * badge is something its tile can ever show. A camera the server has already
  * refused has a reason of its own on the tile and does not need this one too.
  */
@@ -470,7 +526,7 @@ async function sweepHealth() {
   } catch {
     // Kept, not cleared: the last known health is still the most useful thing
     // we have, and "the recorder was fine a moment ago" is a real answer.
-    healthFailed.value = "The camera health check did not answer this time.";
+    healthFailed.value = "Could not check the recorder just now.";
   }
 }
 
@@ -831,14 +887,31 @@ async function toggleFullscreen() {
   border-top: 1px solid var(--vms-line);
 }
 
+/*
+  Now a GROUP LABEL rather than the camera's name repeated: it names what the
+  row below it is, which is the one job a heading here has. The camera is
+  identified once, in the status line above.
+*/
 .vms__caps-head {
-  margin: 0 0 8px;
+  margin: 0 0 6px;
   font-size: 11px;
   letter-spacing: 0.06em;
   text-transform: uppercase;
   color: var(--vms-text-dim);
 }
 
+/*
+  RULE 7's one-sentence-for-the-group. Sits between the group label and the
+  cards, indented on the same 2 px accent rail the cards wear, so it reads as
+  belonging to all of them rather than to the first one.
+*/
+.vms__caps-note {
+  margin: 0 0 8px;
+  padding-left: 10px;
+  border-left: 2px solid var(--vms-accent);
+  max-width: 92ch;
+}
+
 .vms__caps-row {
   display: grid;
   grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));

package/components/CameraWallTile.vue

@@ -178,10 +178,10 @@ import {
  * origin's document is blocked by the browser — correctly.
  *
  * That ceiling has not moved. What has changed is that the badge no longer
- * pretends otherwise. A loaded page earns **"Not verified"**, not "Live"; only
+ * pretends otherwise. A loaded page earns **"Not confirmed"**, not "Live"; only
  * a frame the video service itself reports over `postMessage` earns "Live".
  * The service sends nothing today, so every tile on this estate sits at "Not
- * verified" — which is the true answer. It went in because on the live wall two
+ * confirmed" — which is the true answer. It went in because on the live wall two
  * cameras rendered a blank rectangle under a green "Live" badge, which is the
  * one thing a monitoring screen must never do.
  *
@@ -239,10 +239,13 @@ const healthLine = computed(() => {
   return lastFrame && !props.dense ? `${label} · ${lastFrame}` : label;
 });
 
-/** Everything the line had no room for, on hover. */
-const healthTitle = computed(() =>
-  [recorder.value.detail, recorder.value.deviceDetail].filter(Boolean).join(" ")
-);
+/**
+ * Everything the line had no room for, on hover. The firmware-and-clock
+ * sentence used to be appended here too; it is gone for the same reason it is
+ * gone from the panel — this screen never showed either value, so explaining
+ * their absence gave the reader nothing to do. See `THealthView`.
+ */
+const healthTitle = computed(() => recorder.value.detail || "");
 
 /* -------------------------------------------------------------------- zoom */
 
@@ -432,7 +435,7 @@ function restartFrameClock() {
  * direction.
  *
  * The timeout only fires while nothing at all has been heard: a page that
- * loaded is already at `page-up` and stays there. Sitting on "Not verified"
+ * loaded is already at `page-up` and stays there. Sitting on "Not confirmed"
  * indefinitely is deliberate — declaring a camera dead on a timer, with no
  * evidence, is the same mistake as declaring it live on a timer.
  */

package/components/VisitorSocketPopUp.vue

@@ -66,6 +66,29 @@
       </template>
     </v-snackbar>
 
+    <!--
+      Camera health is its own alert, deliberately separate from the plate
+      snackbar above: it is not a visitor event, it must not be silenced by the
+      unregistered-visitor switch, and it must not be hidden on the unregistered
+      tab. Several failing cameras collapse into one line rather than one
+      snackbar each.
+    -->
+    <v-snackbar
+      v-if="canViewVisitor"
+      v-model="cameraAlert.modal"
+      :color="cameraFaults.size ? 'warning' : 'success'"
+      :timeout="10000"
+      location="top right"
+      class="rounded-xl"
+      multi-line
+      :z-index="100000000"
+    >
+      <span class="text-1-4rem">{{ cameraAlertText }}</span>
+      <template #actions>
+        <v-btn icon="mdi-close" variant="text" @click="cameraAlert.modal = false" />
+      </template>
+    </v-snackbar>
+
     <v-dialog v-model="permanentMessageDialog.modal" max-width="480" persistent>
       <v-card>
         <v-card-title class="text-h6">Notice</v-card-title>
@@ -132,6 +155,36 @@ const permanentMessageDialog = reactive({
   text: "",
 });
 
+// Outstanding camera faults for this site, keyed by camera id so a repeat for
+// the same camera replaces its line instead of adding another.
+const cameraFaults = reactive(new Map<string, string>());
+const cameraRecovery = ref("");
+const cameraAlert = reactive({ modal: false });
+
+const cameraAlertText = computed(
+  () => cameraAlertMessage([...cameraFaults.values()]) || cameraRecovery.value
+);
+
+const handleCameraHealth = (data: TVisitorSocketData) => {
+  // Older API-core builds send the fault text with no `event`, so a bare
+  // message is a fault.
+  if (data?.event === "camera-recovered") {
+    // Without a camera id there is no way to tell which fault cleared.
+    if (data?.camera) cameraFaults.delete(data.camera);
+    else cameraFaults.clear();
+    // Alerts are now infrequent, so the operator is told it came back —
+    // otherwise the only signal a camera recovered is silence.
+    cameraRecovery.value = cameraFaults.size ? "" : data?.message || "";
+    cameraAlert.modal = Boolean(cameraAlertText.value);
+    return;
+  }
+
+  if (!data?.message) return;
+  cameraRecovery.value = "";
+  cameraFaults.set(data?.camera || data.message, data.message);
+  cameraAlert.modal = true;
+};
+
 watch(
   () => props.siteId,
   async (siteId) => {
@@ -233,8 +286,9 @@ const connectSocket = () => {
     }
 
 
-    if (data?.message) {
-      showTransientMessage(data.message, "error");
+    // Camera health, not a visitor event: its own alert, its own gate.
+    if (data?.message || data?.event) {
+      handleCameraHealth(data);
     }
 
     if (data?.messagePermanent) {

package/composables/useVisitorSocket.ts

@@ -5,6 +5,32 @@ export type TVisitorSocketData = {
   message?: string;
   messagePermanent?: string;
   reload?: boolean;
+  /**
+   * Camera health. Sent alongside `message` by API-core so the client can group
+   * or clear an alert per camera instead of matching on the message text.
+   * Absent on older API-core builds — treat a bare `message` as a fault.
+   */
+  event?: "camera-fault" | "camera-recovered";
+  /** The camera the `event` is about. */
+  camera?: string;
+};
+
+/**
+ * One line for however many cameras are currently down.
+ *
+ * A site with several ANPR cameras could otherwise raise one alert per camera
+ * at the same moment. The single-camera case shows the server's own message,
+ * which names the camera; beyond that, naming them all in a snackbar is worse
+ * than sending the operator to the page that lists them.
+ */
+export const cameraAlertMessage = (messages: string[]): string => {
+  if (!messages.length) return "";
+  if (messages.length === 1) return messages[0] as string;
+  return (
+    `${messages.length} cameras at this site are not responding. Plate reads ` +
+    `and automatic barrier opening are stopped for them. Open Site Settings > ` +
+    `Cameras to see which.`
+  );
 };
 
 export const useVisitorSocket = () => {

package/package.json

@@ -2,7 +2,7 @@
   "name": "@7365admin1/layer-common",
   "license": "MIT",
   "type": "module",
-  "version": "3.2.1-staging.66",
+  "version": "3.2.1-staging.68",
   "author": "7365admin1",
   "main": "./nuxt.config.ts",
   "publishConfig": {
@@ -14,6 +14,7 @@
     "build": "nuxt build .playground",
     "generate": "nuxt generate .playground",
     "preview": "nuxt preview .playground",
+    "test": "esbuild composables/useVisitorSocket.ts --format=esm --outfile=test/.build/useVisitorSocket.mjs --log-level=error && node --test \"test/*.test.mjs\"",
     "release": "yarn run build && changeset publish"
   },
   "devDependencies": {

package/test/visitor-socket.test.mjs

@@ -0,0 +1,36 @@
+import assert from "node:assert/strict";
+import { test } from "node:test";
+
+import { cameraAlertMessage } from "./.build/useVisitorSocket.mjs";
+
+/*
+ * The reported symptom was one camera raising a red toast every 10 seconds on
+ * an unrelated page. API-core now paces the alert; this side has to make sure
+ * several cameras failing at once still cannot become several snackbars.
+ */
+
+test("nothing is shown when no camera is down", () => {
+  assert.equal(cameraAlertMessage([]), "");
+});
+
+test("one failing camera shows the server's own message, which names it", () => {
+  const text = "The entry and exit ANPR camera at Seventh Condominium is not responding.";
+  assert.equal(cameraAlertMessage([text]), text);
+});
+
+test("several failing cameras collapse into a single line", () => {
+  const many = ["camera one is down", "camera two is down", "camera three is down"];
+  const text = cameraAlertMessage(many);
+  assert.match(text, /^3 cameras at this site are not responding/);
+  for (const message of many) assert.doesNotMatch(text, new RegExp(message));
+});
+
+test("the collapsed line points at the page that lists them", () => {
+  assert.match(cameraAlertMessage(["a", "b"]), /Site Settings > Cameras/);
+});
+
+test("no camera message tells the operator to deactivate anything", () => {
+  for (const messages of [["a camera is down"], ["a", "b"]]) {
+    assert.doesNotMatch(cameraAlertMessage(messages), /inactive|deactivat/i);
+  }
+});

package/utils/camera-wall.test.ts

@@ -11,6 +11,7 @@ import {
   isDenseLayout,
   playerOrigin,
   playerSignal,
+  sharedCapabilityNote,
   tileView,
   wallCameras,
   wallLayout,
@@ -134,6 +135,66 @@ test("a switched-off control says what would switch it on and who to ask", () =>
   assert.match(v.nextStep, /not something to switch on from this page/i);
 });
 
+/* ---------------------------------------------------------------- rule 7 */
+
+const OFF_FOR_THE_SAME_REASON = {
+  state: "unsupported",
+  reason: "device-http-not-configured",
+  detail: "No direct connection to this camera's recorder is configured on this server.",
+};
+const CAP_KEYS = WALL_CAPABILITY_CONTROLS.map((c) => c.key);
+
+test("four controls off for one reason state that reason once", () => {
+  // What the owner actually saw: the same sentence and the same next step,
+  // four times in a row, under four different titles.
+  const cam = ip({
+    capabilities: {
+      // Exactly the live wall: zoom works, the other four are off together.
+      digitalZoom: { state: "supported" },
+      playback: OFF_FOR_THE_SAME_REASON,
+      events: OFF_FOR_THE_SAME_REASON,
+      ptz: OFF_FOR_THE_SAME_REASON,
+      presets: OFF_FOR_THE_SAME_REASON,
+    },
+  });
+  const note = sharedCapabilityNote(cam, CAP_KEYS);
+  assert.match(note.detail, /^No direct connection/);
+  assert.match(note.nextStep, /Seven365 administrator/);
+});
+
+test("controls off for DIFFERENT reasons are never merged into one", () => {
+  // "The recorder is unreachable" and "this camera cannot move" are two
+  // problems with two different people to ask. Flattening them would be a lie
+  // of convenience, so the group note is refused and each card keeps its own.
+  const cam = ip({
+    capabilities: {
+      playback: OFF_FOR_THE_SAME_REASON,
+      ptz: { state: "unsupported", reason: "device-no-ptz", detail: "This camera cannot move." },
+    },
+  });
+  assert.equal(sharedCapabilityNote(cam, CAP_KEYS), null);
+});
+
+test("one control off on its own does not get a group note", () => {
+  const cam = ip({
+    capabilities: {
+      playback: OFF_FOR_THE_SAME_REASON,
+      events: { state: "supported" },
+      ptz: { state: "supported" },
+      presets: { state: "supported" },
+      digitalZoom: { state: "supported" },
+    },
+  });
+  assert.equal(sharedCapabilityNote(cam, CAP_KEYS), null);
+});
+
+test("a camera with no descriptor at all still groups its unknowns", () => {
+  // Every control reads "Not checked yet" with the same not-probed sentence —
+  // which is four identical cards, the same noise, and the same fix.
+  const note = sharedCapabilityNote(ip(), CAP_KEYS);
+  assert.match(note.detail, /has not been asked/);
+});
+
 test("a reason code this build has never seen still names somebody to ask", () => {
   const cam = ip({
     capabilities: { ptz: { state: "unsupported", reason: "invented-later", detail: "Nope." } },
@@ -175,15 +236,19 @@ test("a page that has not loaded is Connecting, never Live", () => {
  * green "Live". The page had loaded; no picture was arriving. A loaded page is
  * now worth exactly one thing, and it is not the word "Live".
  */
-test("a loaded player page is NOT Live - it is Not verified", () => {
+test("a loaded player page is NOT Live - it is Not confirmed", () => {
   const v = tileView(ip(), { player: "page-up" });
   assert.equal(v.state, "unverified");
-  assert.equal(v.label, "Not verified");
+  assert.equal(v.label, "Not confirmed");
   // No scrim: there may be a perfectly good picture under that badge, and
   // covering a working camera would be a worse lie than the one being fixed.
   assert.equal(v.detail, null);
   assert.equal(v.showPlayer, true);
-  assert.match(v.note, /cannot confirm a picture is arriving/);
+  assert.match(v.note, /cannot confirm the picture is arriving/);
+  // Plain English, and an instruction rather than an explanation: the reader is
+  // a guard, not a browser engineer. Nothing about origins, players or frames.
+  assert.match(v.note, /check the tile/i);
+  assert.doesNotMatch(v.note, /browser|origin|player|iframe|service/i);
 });
 
 test("only a reported frame earns the word Live", () => {
@@ -349,16 +414,44 @@ test("reachability alone is enough when the server sends no summary word", () =>
   assert.equal(healthView({ reachable: false }).tone, "down");
 });
 
-test("the server's health sentences are carried through, not rewritten", () => {
+test("the server's health sentence is carried through, not rewritten", () => {
   const v = healthView({
     health: "unreachable",
     reachable: false,
     reason: "The recorder did not respond.",
+  });
+  assert.equal(v.detail, "The recorder did not respond.");
+});
+
+/**
+ * The firmware-and-clock sentence is the server explaining why two values it
+ * never showed are blank. It was drawn on the panel and appended to the tile's
+ * tooltip; a guard can do nothing with a firmware version, so it is not carried
+ * at all now. Pinned, because "soften it" was the tempting answer and the wrong
+ * one.
+ */
+test("the firmware and device-clock sentence is not carried to the screen", () => {
+  const v = healthView({
+    health: "ok",
+    reachable: true,
     detailUnavailableReason:
       "Firmware and device clock are not available: this recorder is reachable over video only.",
   });
-  assert.equal(v.detail, "The recorder did not respond.");
-  assert.match(v.deviceDetail, /^Firmware and device clock/);
+  assert.equal(v.detail, null);
+  assert.equal("deviceDetail" in v, false);
+});
+
+/**
+ * The complaint that started this: a green "Recorder responding" beside "Last
+ * picture this server received: none yet" reads as a contradiction. It is not
+ * one — but the panel now simply says nothing when there has never been a
+ * picture, which is the only reading a guard can act on.
+ */
+test("a recorder that is up with no picture yet reports no picture line at all", () => {
+  const v = healthView({ health: "ok", reachable: true, lastFrameAt: null });
+  assert.equal(v.tone, "ok");
+  assert.equal(v.label, "Recorder responding");
+  assert.equal(v.lastFrame, null);
 });
 
 test("a picture's age is coarse above a minute, and never a fake time", () => {

package/utils/camera-wall.ts

@@ -256,15 +256,15 @@ const NOT_PROBED = "This camera has not been asked what it can do yet.";
  */
 export const CAPABILITY_NEXT_STEPS: Record<string, string> = {
   "device-http-not-configured":
-    "This is a server setting, not something to switch on from this page: the server needs a network route to the camera's recorder, plus the recorder's sign-in details. Ask your Seven365 administrator.",
+    "Not something to switch on from this page — it needs a change on the server. Ask your Seven365 administrator.",
   "device-http-disabled":
-    "Direct camera access is switched off on this server. Ask your Seven365 administrator to switch it on.",
+    "Switched off on the server. Ask your Seven365 administrator to switch it on.",
   "device-http-unreachable":
-    "The recorder did not answer this server. Ask your Seven365 administrator or the camera installer to check the recorder and its network.",
+    "The recorder is not answering. Ask your Seven365 administrator or the camera installer to check it.",
   "device-http-locked-out":
-    "Sign-ins to the recorder are being held back so its account is not locked out. Ask your Seven365 administrator to check the recorder's sign-in details.",
+    "Sign-ins to the recorder are being held back so its account is not locked out. Ask your Seven365 administrator.",
   "control-not-enabled":
-    "Camera control is switched off on this server. Switching it on moves real hardware, so it has to be approved by a Seven365 backend lead first.",
+    "Switched off on the server. It moves real hardware, so a Seven365 backend lead has to approve it first.",
   "device-no-ptz":
     "This camera cannot move, so there is nothing to switch on. A different camera would be needed.",
   "no-recorder-configured":
@@ -282,7 +282,7 @@ export const CAPABILITY_NEXT_STEPS: Record<string, string> = {
   "device-not-probed":
     "The camera is asked what it can do the first time it is opened. Nothing to do — check back in a moment.",
   "no-transport":
-    "Nothing on this server can do this yet. It has to be built before it can be switched on.",
+    "Not built yet. Nothing on this server can do it.",
 };
 
 /**
@@ -386,6 +386,47 @@ export function capabilityView(
   };
 }
 
+/**
+ * RULE 7 — SAY IT ONCE FOR THE GROUP WHEN IT IS ONE FACT, NOT FOUR.
+ *
+ * On this estate all four of the switched-off controls are off for the SAME
+ * reason: there is no direct connection to the recorder. So the panel drew four
+ * cards, each carrying an identical sentence and an identical next step —
+ * eight lines of repetition saying one thing. Four copies of a sentence do not
+ * make it four facts; they make the reader skim, and skimming is how the one
+ * line that mattered got missed.
+ *
+ * So when every unavailable control shares the same reason, this returns it and
+ * the panel prints it once above the row. Each card keeps its own title and its
+ * own tag, so the individual state is never lost — only the echo is.
+ *
+ * Returns `null` the moment the reasons DIFFER, which is the case that must not
+ * be flattened: "the recorder is unreachable" and "this camera cannot move" are
+ * two different problems with two different people to ask, and merging them
+ * would be a lie of convenience. Also `null` when nothing is off (nothing to
+ * explain) or when only one control is off (a group note for a group of one is
+ * just the card, moved).
+ */
+export function sharedCapabilityNote(
+  camera: TWallCamera | null | undefined,
+  keys: readonly string[]
+): { detail: string; nextStep: string | null } | null {
+  const off = keys
+    .map((key) => capabilityView(camera, key))
+    .filter((view) => !view.available);
+
+  if (off.length < 2) return null;
+
+  const first = off[0];
+  const same = off.every(
+    (view) => view.detail === first.detail && view.nextStep === first.nextStep
+  );
+
+  return same && first.detail
+    ? { detail: first.detail, nextStep: first.nextStep }
+    : null;
+}
+
 /* -------------------------------------------------------------------------- */
 /* Tile state                                                                  */
 /* -------------------------------------------------------------------------- */
@@ -428,10 +469,16 @@ export type TTileState =
  *
  * `unverified` is the state this wall is in for every camera on this estate
  * today, and saying so is the point — see the note above `tileView`.
+ *
+ * It used to read "Not verified", which is a word from our side of the fence:
+ * it describes a check we did not manage to make. "Not confirmed" describes the
+ * PICTURE, which is the only thing the reader cares about, and it is the same
+ * claim. The instruction that goes with it — check the tile — is in
+ * `UNVERIFIED_DETAIL`, on the badge's tooltip and once on the panel.
  */
 export const TILE_LABELS = {
   live: "Live",
-  unverified: "Not verified",
+  unverified: "Not confirmed",
   connecting: "Connecting…",
   "no-signal": "No signal",
   offline: "No connection",
@@ -548,12 +595,23 @@ export type TTileView = {
 };
 
 /**
- * The sentence behind "Not verified", said once on the focused camera's panel
- * rather than nine times across the wall. Invented here: no server has a
- * reason code for "your browser cannot see inside another origin's page".
+ * The sentence behind "Not confirmed", said once on the focused camera's panel
+ * rather than nine times across the wall.
+ *
+ * **Written for a guard or a property manager, not for us.** The first version
+ * of this line explained cross-origin isolation — "the player belongs to the
+ * video service and a browser cannot look inside it" — which is true, is the
+ * reason, and is none of the reader's business. The owner read it on the live
+ * wall and said so. A reader of this screen has exactly three questions: is
+ * this camera working, what do I do if it is not, and what can I do here. WHY
+ * the software cannot answer the first one is our problem, not theirs.
+ *
+ * So: what we cannot do, then what they should do. Nothing else. The claim is
+ * every bit as honest as the paragraph it replaces — it just stops making the
+ * reader sit through an engineering lesson to get to the instruction.
  */
 export const UNVERIFIED_DETAIL =
-  "The video page loaded, but this browser cannot confirm a picture is arriving. The player belongs to the video service and a browser cannot look inside it. Judge the tile by what you can see, and report a blank or frozen picture.";
+  "This page cannot confirm the picture is arriving, so check the tile yourself. If it is blank or frozen, report the camera.";
 
 /**
  * Rule 4, plus every reason a tile may have nothing to show.
@@ -632,14 +690,14 @@ export function tileView(
       // we genuinely cannot tell a dead camera from a dead video service.
       return showing(
         "no-signal",
-        "The live view did not load. The camera or the video service may be down."
+        "No picture. The camera or the video service may be down. Report it if it stays like this."
       );
     case "stalled":
       // It WAS playing and stopped. That is the one case where we can say a
       // picture has genuinely gone away, because we saw one arrive first.
       return showing(
         "no-signal",
-        "The picture stopped arriving. The camera or the video service may have dropped."
+        "The picture stopped arriving. The camera or the video service may have dropped. Report it if it does not come back."
       );
     case "playing":
       return showing("live", null);
@@ -688,15 +746,27 @@ export type THealthView = {
   detail: string | null;
   /** "4 min ago", or `null` when this server has never had a picture. */
   lastFrame: string | null;
-  /** Why firmware and clock are blank. The server's sentence, verbatim. */
-  deviceDetail: string | null;
 };
 
+/*
+  THE FIRMWARE-AND-CLOCK LINE IS GONE, AND IT IS NOT COMING BACK.
+
+  The server sends `detailUnavailableReason` — "Firmware and device clock are
+  not available: this recorder is reachable over video only." — so that two
+  blank fields do not read as "checked, and fine". That is a good reason to
+  send it and a bad reason to DRAW it: this screen never showed firmware or a
+  device clock in the first place, so the sentence was explaining the absence
+  of something the reader had not been offered and could not use. A guard
+  cannot act on a firmware version. Softening the wording would have kept the
+  noise, so the line is removed instead. The field is still on
+  `TWallCameraHealth` because the API sends it; nothing on the wall draws it.
+*/
+
 const HEALTH_LABELS: Record<string, { tone: THealthTone; label: string }> = {
   ok: { tone: "ok", label: "Recorder responding" },
   drifted: { tone: "warn", label: "Recorder clock is out" },
   unreachable: { tone: "down", label: "Recorder not responding" },
-  unsupported: { tone: "unknown", label: "Not checked" },
+  unsupported: { tone: "unknown", label: "Recorder not checked" },
 };
 
 /**
@@ -716,7 +786,7 @@ export function healthView(
       ? HEALTH_LABELS.ok
       : health?.reachable === false
         ? HEALTH_LABELS.unreachable
-        : { tone: "unknown", label: "Health not checked yet" };
+        : { tone: "unknown", label: "Recorder not checked yet" };
 
   const { tone, label } = known ?? fallback;
 
@@ -725,7 +795,6 @@ export function healthView(
     label,
     detail: (health?.reason || "").trim() || null,
     lastFrame: agoLabel(health?.lastFrameAt, now),
-    deviceDetail: (health?.detailUnavailableReason || "").trim() || null,
   };
 }