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

package/utils/nav-sections.ts

@@ -0,0 +1,151 @@
+/**
+ * THE GROUPED SIDEBAR - one heading per section, each printed once.
+ *
+ * The design draws the sidebar in labelled sections (OVERVIEW, SERVICE DESK,
+ * PROPERTY, SECURITY OPERATIONS, COMMUNITY, WORKFORCE, ADMINISTRATION). Each
+ * application builds its own menu array in its `layouts/default.vue`, gated
+ * item by item on permissions.
+ *
+ * The applications do not agree on the order they list their modules in
+ * (Property Management interleaves five sections; Landscape puts Feedbacks
+ * after Equipment). Walking that order and printing a heading whenever the
+ * section changed - what this file used to do - made Property Management draw
+ * SERVICE DESK, PROPERTY and SECURITY OPERATIONS TWICE each. It reads as a
+ * bug, so the items are now GROUPED:
+ *
+ *   - every item is collected under its section, and each heading is printed
+ *     exactly once, in the order the design lists the sections (which is the
+ *     order they are declared in the map below).
+ *   - inside a section the application's own order is preserved, so items that
+ *     belong together stay in the sequence their author chose.
+ *   - a title this map has never heard of inherits the section of the item
+ *     above it, so a new menu item added by any of the eleven applications is
+ *     grouped with its neighbours rather than disappearing or forcing a stray
+ *     heading.
+ *   - an item with no section at all (an unmapped FIRST item) leads the rail
+ *     with no heading, exactly as before.
+ *
+ * This changes what ORDER the items are drawn in and nothing else. No item is
+ * added, hidden, renamed, re-routed or re-gated - the array that comes out
+ * holds the same objects as the array that went in.
+ */
+
+export const NAV_SECTIONS: Record<string, string> = {
+  // OVERVIEW
+  Dashboard: "OVERVIEW",
+  Home: "OVERVIEW",
+
+  // SERVICE DESK
+  "Service Providers": "SERVICE DESK",
+  Feedbacks: "SERVICE DESK",
+  "Work Orders": "SERVICE DESK",
+  "Online Forms": "SERVICE DESK",
+
+  // SERVICE DELIVERY - the five service applications' own working modules
+  "Cleaning Schedule": "SERVICE DELIVERY",
+  "Landscape Schedule": "SERVICE DELIVERY",
+  "Pest Schedule": "SERVICE DELIVERY",
+  "Pool Schedule": "SERVICE DELIVERY",
+  "Technician Schedule": "SERVICE DELIVERY",
+  Area: "SERVICE DELIVERY",
+  Unit: "SERVICE DELIVERY",
+  "Schedule Task": "SERVICE DELIVERY",
+
+  // EQUIPMENT
+  "Equipment Management": "EQUIPMENT",
+  "Equipment Items": "EQUIPMENT",
+
+  // PROPERTY
+  "Vehicle Mgmt": "PROPERTY",
+  "Building Mgmt": "PROPERTY",
+  "Visitor Mgmt": "PROPERTY",
+  "Pass & Key Mgmt": "PROPERTY",
+  "Facility Mgmt": "PROPERTY",
+  "People Mgmt": "PROPERTY",
+  "Document Mgmt": "PROPERTY",
+  "Access Mgmt": "PROPERTY",
+  "Event Mgmt": "PROPERTY",
+  "Emergency Contacts": "PROPERTY",
+  "Online Billing": "PROPERTY",
+  "SOA Mgmt": "PROPERTY",
+
+  // SECURITY OPERATIONS
+  "HID Face Reader": "SECURITY OPERATIONS",
+  "Daily Occurrence Books": "SECURITY OPERATIONS",
+  Manpower: "SECURITY OPERATIONS",
+  "Virtual Patrol": "SECURITY OPERATIONS",
+  "NFC Patrol": "SECURITY OPERATIONS",
+  "Robot Mgmt": "SECURITY OPERATIONS",
+  "Incident Reports": "SECURITY OPERATIONS",
+  CCTV: "SECURITY OPERATIONS",
+
+  // COMMUNITY
+  "Bulletin Board": "COMMUNITY",
+  "Bulletin Videos": "COMMUNITY",
+
+  // WORKFORCE
+  Attendance: "WORKFORCE",
+  "My Attendance": "WORKFORCE",
+
+  // ADMINISTRATION
+  Invitations: "ADMINISTRATION",
+  "SP Approvals": "ADMINISTRATION",
+  Members: "ADMINISTRATION",
+  "Roles & Permissions": "ADMINISTRATION",
+  Settings: "ADMINISTRATION",
+  "Site Settings": "ADMINISTRATION",
+  Organizations: "ADMINISTRATION",
+  Users: "ADMINISTRATION",
+  "Promo Codes": "ADMINISTRATION",
+
+  // ACCOUNT - `web-app-account` is a personal-settings application, not a site
+  "Personal Info": "ACCOUNT",
+  "Payment Methods": "ACCOUNT",
+
+  // SERVICES - the account application's list of the products a user can enter
+  "Property Management": "SERVICES",
+  Security: "SERVICES",
+  Hygiene: "SERVICES",
+  "Mechanical & Electrical": "SERVICES",
+  "Pest Control Services": "SERVICES",
+  "Landscaping Services": "SERVICES",
+  "Pool Maintenance Services": "SERVICES",
+};
+
+export type TSectionedNavItem<T> = { item: T; section: string };
+
+/** The design's section order - the order they are declared above. */
+export const SECTION_ORDER: string[] = [
+  ...new Set(Object.values(NAV_SECTIONS)),
+];
+
+/**
+ * Groups the menu by section and tags each item with the heading to print
+ * above it, or "" when the heading is already printed. Same length, same
+ * objects; only the order changes.
+ */
+export function withSections<T extends { title?: string }>(
+  items: T[]
+): Array<TSectionedNavItem<T>> {
+  // An unmapped title inherits the section of the item above it.
+  let current = "";
+  const resolved = items.map((item, index) => {
+    current = NAV_SECTIONS[String(item?.title ?? "")] ?? current;
+    return { item, section: current, index };
+  });
+
+  // Sectionless items (an unmapped first item) rank -1 and lead the rail.
+  // Inside a section the application's own order is kept.
+  const grouped = [...resolved].sort(
+    (a, b) =>
+      SECTION_ORDER.indexOf(a.section) - SECTION_ORDER.indexOf(b.section) ||
+      a.index - b.index
+  );
+
+  let printed = "";
+  return grouped.map(({ item, section }) => {
+    const label = section === printed ? "" : section;
+    printed = section;
+    return { item, section: label };
+  });
+}

package/utils/nfc-patrol-report.test.ts

@@ -0,0 +1,130 @@
+import assert from "node:assert/strict";
+import { test } from "node:test";
+
+import { collectAllPages, mapLogsToMonthlyRows } from "./nfc-patrol-report.ts";
+
+/**
+ * THE DEFECT THIS FILE EXISTS FOR.
+ *
+ * The yearly patrol-compliance table was built from `page: 1, limit: 100` of a
+ * paged endpoint and never looked at `pages`. A route patrolled daily produces
+ * ~300 runs a year, so months past the first page rendered "0 / 0% / 0 / 0%" -
+ * indistinguishable from a month in which every checkpoint was missed, in a
+ * table a manager can print and hand to a client.
+ */
+
+/** 12 months x 25 runs x (4 completed + 1 skipped). Every month is 80%/20%. */
+function yearOfLogs() {
+  const logs: Record<string, any>[] = [];
+  for (let m = 0; m < 12; m++) {
+    for (let d = 1; d <= 25; d++) {
+      const checkPoints = [
+        { status: "Completed" },
+        { status: "Completed" },
+        { status: "Completed" },
+        { status: "Completed" },
+        { status: "Skipped" },
+      ];
+      logs.push({
+        date: `2026-${String(m + 1).padStart(2, "0")}-${String(d).padStart(2, "0")}T08:00:00.000Z`,
+        checkPoints,
+      });
+    }
+  }
+  return logs;
+}
+
+function pagedFetcher(all: Record<string, any>[], limit = 100) {
+  const pages = Math.ceil(all.length / limit);
+  const seen: number[] = [];
+  return {
+    seen,
+    fetchPage: async (page: number) => {
+      seen.push(page);
+      return { items: all.slice((page - 1) * limit, page * limit), pages };
+    },
+  };
+}
+
+test("every page the endpoint reports is read, not just the first", async () => {
+  const all = yearOfLogs();
+  const { fetchPage, seen } = pagedFetcher(all);
+
+  const items = await collectAllPages(fetchPage);
+
+  assert.equal(items.length, all.length, "all 300 runs collected");
+  assert.deepEqual(seen, [1, 2, 3], "walked every page the reply declared");
+});
+
+test("a full year reports the same rate in every month", async () => {
+  const items = await collectAllPages(pagedFetcher(yearOfLogs()).fetchPage);
+  const rows = mapLogsToMonthlyRows(items);
+
+  assert.equal(rows.length, 12);
+  for (const row of rows) {
+    assert.equal(row.checked, 100, `${row.month} checked`);
+    assert.equal(row.missed, 25, `${row.month} missed`);
+    assert.equal(row.checkedPercentage, 80, `${row.month} % checked`);
+    assert.equal(row.missedPercentage, 20, `${row.month} % missed`);
+  }
+});
+
+test("only the first page would have zeroed the rest of the year", () => {
+  // What the screen used to do: one page of 100, the other 200 runs dropped.
+  const firstPageOnly = yearOfLogs().slice(0, 100);
+  const rows = mapLogsToMonthlyRows(firstPageOnly);
+
+  assert.equal(rows[0].checkedPercentage, 80, "January measured");
+  assert.equal(rows[4].checked, 0, "May had no runs on page 1");
+  assert.equal(
+    rows[4].checkedPercentage,
+    null,
+    "and it must NOT read 0% - nothing was measured",
+  );
+});
+
+test("a month with no checkpoint due reports no rate at all", () => {
+  const rows = mapLogsToMonthlyRows([]);
+
+  for (const row of rows) {
+    assert.equal(row.checked, 0);
+    assert.equal(row.missed, 0);
+    assert.equal(row.checkedPercentage, null);
+    assert.equal(row.missedPercentage, null);
+  }
+});
+
+test("a month where every checkpoint was missed still reports 0%", () => {
+  const rows = mapLogsToMonthlyRows([
+    { date: "2026-03-04T08:00:00.000Z", checkPoints: [{ status: "Skipped" }, { status: "Skipped" }] },
+  ]);
+
+  assert.equal(rows[2].checkedPercentage, 0, "0% here is a real measurement");
+  assert.equal(rows[2].missedPercentage, 100);
+  assert.equal(rows[0].checkedPercentage, null, "January measured nothing");
+});
+
+test("a single-page reply is not re-fetched", async () => {
+  const { fetchPage, seen } = pagedFetcher(yearOfLogs().slice(0, 10));
+  await collectAllPages(fetchPage);
+  assert.deepEqual(seen, [1]);
+});
+
+test("a reply with no page count is treated as one page", async () => {
+  const calls: number[] = [];
+  const items = await collectAllPages(async (page) => {
+    calls.push(page);
+    return { items: [{ date: "2026-01-02T00:00:00.000Z", checkPoints: [] }] };
+  });
+  assert.deepEqual(calls, [1]);
+  assert.equal(items.length, 1);
+});
+
+test("undated or malformed logs are skipped, not counted into January", () => {
+  const rows = mapLogsToMonthlyRows([
+    { date: "not-a-date", checkPoints: [{ status: "Completed" }] },
+    { checkPoints: [{ status: "Completed" }] },
+  ]);
+  assert.equal(rows[0].checked, 0);
+  assert.equal(rows[0].checkedPercentage, null);
+});

package/utils/nfc-patrol-report.ts

@@ -0,0 +1,101 @@
+/**
+ * Patrol-report arithmetic that is worth testing on its own.
+ *
+ * The yearly compliance table used to be built from `page: 1, limit: 100` of a
+ * paged endpoint. A route patrolled daily produces far more than 100 runs a
+ * year, so every month past the first page rendered "0 / 0% / 0 / 0%" - eight
+ * months of measured zeros in a table a manager can print and hand to a
+ * client. The page walk and the month mapping live here so they have tests.
+ */
+
+/** One page of the patrol-log endpoint's reply. */
+export type TPatrolLogPage = {
+  items?: Record<string, any>[];
+  pages?: number;
+};
+
+export type TPatrolMonthRow = {
+  month: string;
+  checked: number;
+  missed: number;
+  /** `null` when no checkpoint was due that month - a rate over nothing is not a measurement. */
+  checkedPercentage: number | null;
+  missedPercentage: number | null;
+};
+
+export const MONTHS = [
+  "January",
+  "February",
+  "March",
+  "April",
+  "May",
+  "June",
+  "July",
+  "August",
+  "September",
+  "October",
+  "November",
+  "December",
+];
+
+/**
+ * Read every page the endpoint says exists, not just the first.
+ *
+ * ponytail: sequential. A year of one route is a handful of pages, and firing
+ * them in parallel would only trade a few hundred ms for a burst on the API.
+ * `maxPages` is a runaway guard, not a product limit - if it ever bites, the
+ * caller is asking for a range the report was not designed for.
+ */
+export async function collectAllPages(
+  fetchPage: (page: number) => Promise<TPatrolLogPage>,
+  maxPages = 50,
+): Promise<Record<string, any>[]> {
+  const first = await fetchPage(1);
+  const items = [...(first?.items ?? [])];
+  const pages = Math.min(Number(first?.pages) || 1, maxPages);
+
+  for (let page = 2; page <= pages; page++) {
+    const next = await fetchPage(page);
+    items.push(...(next?.items ?? []));
+  }
+
+  return items;
+}
+
+/**
+ * One row per calendar month. A month with no checkpoint due keeps its zero
+ * counts - zero checkpoints really were checked - but reports `null` for both
+ * percentages, because a percentage of nothing is not a measurement and "0%"
+ * reads exactly like total failure.
+ */
+export function mapLogsToMonthlyRows(
+  logs: Record<string, any>[],
+): TPatrolMonthRow[] {
+  const rows: TPatrolMonthRow[] = MONTHS.map((month) => ({
+    month,
+    checked: 0,
+    missed: 0,
+    checkedPercentage: null,
+    missedPercentage: null,
+  }));
+
+  for (const log of logs) {
+    const monthIndex = new Date(log?.date).getMonth();
+    if (Number.isNaN(monthIndex)) continue;
+
+    for (const checkpoint of log?.checkPoints ?? []) {
+      if (checkpoint?.status === "Completed") rows[monthIndex].checked++;
+      else if (checkpoint?.status === "Skipped") rows[monthIndex].missed++;
+    }
+  }
+
+  for (const row of rows) {
+    const total = row.checked + row.missed;
+    if (total > 0) {
+      row.checkedPercentage = Math.round((row.checked / total) * 100);
+      row.missedPercentage = Math.round((row.missed / total) * 100);
+    }
+  }
+
+  return rows;
+}

package/utils/role.test.ts

@@ -0,0 +1,69 @@
+import assert from "node:assert/strict";
+import { readFileSync } from "node:fs";
+import { test } from "node:test";
+
+import { showSiteField } from "./role.ts";
+
+/**
+ * QA on the admin app (PR #18) reported "no site options" on Create Role. The
+ * Site field is read-only by design - it shows the site a role belongs to -
+ * but an admin role has no site, so it drew permanently disabled and empty.
+ * `RolePermissionFormCreate` defaulted `siteState` to `true` and
+ * `RolePermissionMain` neither declared nor forwarded it, and its root is a
+ * `<div>`, so a fallthrough attribute could not reach the dialog either: no
+ * consuming app could switch the field off.
+ */
+test("an admin role never shows the site field", () => {
+  assert.equal(showSiteField(true, "admin"), false);
+  assert.equal(showSiteField(false, "admin"), false);
+});
+
+test("every other role type keeps what the app asked for", () => {
+  for (const type of [
+    "app",
+    "organization",
+    "security_agency",
+    "cleaning_services",
+  ]) {
+    assert.equal(showSiteField(true, type), true, type);
+    assert.equal(showSiteField(false, type), false, type);
+  }
+});
+
+test("RolePermissionMain declares site-state and forwards it to the dialog", () => {
+  const src = readFileSync(
+    new URL("../components/RolePermissionMain.vue", import.meta.url),
+    "utf8"
+  );
+
+  assert.match(src, /siteState:\s*\{/, "site-state must be a declared prop");
+  assert.match(
+    src,
+    /:site-state="siteFieldShown"/,
+    "the dialog must receive the resolved value, not a fallthrough attribute"
+  );
+});
+
+/**
+ * The category expand toggle carried no class, so it fell back to raw Vuetify
+ * `inset` styling: a white thumb on a white card, measured 1.02:1 light /
+ * 1.04:1 dark against the dialog surface. `.app-switch` (primitives.css) is
+ * this layer's switch shape and is what makes the thumb visible. `inset` is
+ * removed with it - Vuetify's inset dimensions beat the `.app-switch` rules on
+ * source order and collapse the control to zero width.
+ */
+for (const file of [
+  "RolePermissionFormCreate.vue",
+  "RolePermissionFormPreviewUpdate.vue",
+]) {
+  test(`${file} styles its category toggle with .app-switch`, () => {
+    const src = readFileSync(
+      new URL(`../components/${file}`, import.meta.url),
+      "utf8"
+    );
+    const sw = src.slice(src.indexOf("<v-switch"), src.indexOf("/>", src.indexOf("<v-switch")));
+
+    assert.ok(sw.includes('class="app-switch"'), "missing .app-switch");
+    assert.ok(!/\binset\b/.test(sw), "inset fights the .app-switch dimensions");
+  });
+}

package/utils/role.ts

@@ -0,0 +1,10 @@
+/**
+ * Whether the Create-role dialog should show its (read-only) Site field.
+ *
+ * An admin role is org-wide, never site-scoped, so there is no site to show -
+ * the field could only ever render empty and permanently disabled, which is
+ * what QA reported on the admin app. Every other role type keeps whatever the
+ * consuming app asked for.
+ */
+export const showSiteField = (siteState: boolean, type: string): boolean =>
+  siteState && type !== "admin";

package/utils/route-name.test.ts

@@ -0,0 +1,85 @@
+import assert from "node:assert/strict";
+import { readFileSync, readdirSync } from "node:fs";
+import { join } from "node:path";
+import { fileURLToPath } from "node:url";
+import { test } from "node:test";
+
+import { pickRouteName } from "./route-name.ts";
+
+const routerWith = (...names: string[]) => ({
+  hasRoute: (name: string) => names.includes(name),
+});
+
+test("picks the first candidate this app actually has", () => {
+  const router = routerWith("org-site-keys-visitor-pass-add");
+  assert.equal(
+    pickRouteName(router, "org-site-keys-visitor-pass-add", "keys-visitor-pass-add"),
+    "org-site-keys-visitor-pass-add"
+  );
+});
+
+test("falls through to a later candidate for a flatter app", () => {
+  const router = routerWith("keys-visitor-pass-add");
+  assert.equal(
+    pickRouteName(router, "org-site-keys-visitor-pass-add", "keys-visitor-pass-add"),
+    "keys-visitor-pass-add"
+  );
+});
+
+test("candidate order wins when an app has both", () => {
+  const router = routerWith("keys-visitor-pass-add", "org-site-keys-visitor-pass-add");
+  assert.equal(
+    pickRouteName(router, "org-site-keys-visitor-pass-add", "keys-visitor-pass-add"),
+    "org-site-keys-visitor-pass-add"
+  );
+});
+
+test("null when the app has no such page - the caller hides the control", () => {
+  assert.equal(pickRouteName(routerWith("org-site-work-orders"), "org-site-work-orders-id"), null);
+  assert.equal(pickRouteName(routerWith()), null);
+});
+
+// The five names two app-side audits found dead. Each is now resolved through
+// `pickRouteName`, so none may reappear as a literal anywhere in the layer.
+// `organizations-create` is deliberately absent: it is real in web-app-org and
+// is only reached there, so it was never dead.
+const DEAD_NAMES = [
+  "keys-visitor-pass-add",
+  "org-organizations-customers-add",
+  "work-order-details",
+  "org-site-service-provider-mgmt-billing",
+];
+
+function sourceFiles(dir: string, out: string[] = []): string[] {
+  for (const entry of readdirSync(dir, { withFileTypes: true })) {
+    const path = join(dir, entry.name);
+    if (entry.isDirectory()) sourceFiles(path, out);
+    else if (/\.(vue|ts)$/.test(entry.name)) out.push(path);
+  }
+  return out;
+}
+
+test("no dead route name survives as a literal in the layer", () => {
+  const root = fileURLToPath(new URL("..", import.meta.url));
+  const files = ["components", "pages", "layouts", "composables", "middleware", "plugins"]
+    .flatMap((d) => sourceFiles(join(root, d)))
+    .filter((f) => !f.endsWith(".test.ts"));
+
+  assert.ok(files.length > 100, `expected to scan the layer, scanned ${files.length} files`);
+
+  const offenders: string[] = [];
+  for (const file of files) {
+    const source = readFileSync(file, "utf8");
+    for (const dead of DEAD_NAMES) {
+      // Only a `name:` BINDING counts. The same string also appears as a bare
+      // argument in a `pickRouteName(...)` candidate list, which is the fix, not
+      // the fault. Plain string matching on purpose - a backslash class inside a
+      // template literal silently loses its escape and matches nothing.
+      const bound = [`"${dead}"`, `'${dead}'`].some(
+        (quoted) => source.includes(`name: ${quoted}`) || source.includes(`name:${quoted}`)
+      );
+      if (bound) offenders.push(`${file.slice(root.length)} -> ${dead}`);
+    }
+  }
+  assert.deepEqual(offenders, [], `dead route names still bound:\n${offenders.join("\n")}`);
+});

package/utils/route-name.ts

@@ -0,0 +1,24 @@
+/**
+ * Pick the route name the RUNNING app actually has.
+ *
+ * This layer is extended by apps whose pages sit at different depths, so the
+ * same screen has a different Nuxt route name in each of them - the service
+ * apps produce `org-site-keys-visitor-pass-add` from
+ * `pages/[org]/[site]/keys/visitor/pass/add.vue`, while a flatter app would
+ * produce `keys-visitor-pass-add`. A literal name hard-coded in the layer is
+ * therefore correct in some consumers and throws in the rest, because
+ * `router.push({ name })` on an unknown name is a hard error.
+ *
+ * Pass the candidates most-specific-first. Returns the first one this app has,
+ * or `null` when it has none - and `null` means "this app has no such page",
+ * which is the caller's cue to hide the control rather than navigate somewhere
+ * wrong.
+ *
+ * ponytail: vue-router's own `hasRoute`, no name table to keep in sync.
+ */
+export function pickRouteName(
+  router: { hasRoute: (name: string) => boolean },
+  ...candidates: string[]
+): string | null {
+  return candidates.find((name) => router.hasRoute(name)) ?? null;
+}

package/utils/status.test.ts

@@ -0,0 +1,110 @@
+import assert from "node:assert/strict";
+import { test } from "node:test";
+
+import { statusTone, statusToneClass } from "./status.ts";
+
+test("the handoff's mapping, word for word", () => {
+  for (const s of ["Completed", "Paid", "Available", "Open"]) {
+    assert.equal(statusTone(s), "ok", s);
+  }
+
+  assert.equal(statusTone("Pending"), "warn");
+
+  for (const s of ["In Use", "Closed", "Checkout"]) {
+    assert.equal(statusTone(s), "err", s);
+  }
+
+  assert.equal(statusTone("Role"), "info");
+});
+
+/** The same status arrives spelled three ways from three endpoints. */
+test("casing, spacing and underscores do not change a status's colour", () => {
+  for (const s of ["in use", "IN USE", "In_Use", "in-use", "  In Use  "]) {
+    assert.equal(statusTone(s), "err", s);
+  }
+});
+
+/**
+ * The important one. A status the design never named must NOT be guessed into
+ * a colour - a wrong green on a failed job reads as success. Neutral is
+ * visible, honest, and gets it noticed.
+ */
+test("an unmapped status comes out neutral rather than guessed", () => {
+  for (const s of ["Cancelled", "Overdue", "Draft", "", null, undefined]) {
+    assert.equal(statusTone(s), "neutral", String(s));
+  }
+});
+
+/**
+ * PHASE 4. Each of these words is on a module screen today with a colour a
+ * per-screen `getStatusColor` gave it. The list has to keep giving it the SAME
+ * tone, or adopting the shared chip would quietly repaint a status.
+ */
+test("the product's own status words keep the tone the screens already gave them", () => {
+  for (const s of ["Accepted", "Approved", "Resolved", "Active"]) {
+    assert.equal(statusTone(s), "ok", s);
+  }
+
+  for (const s of ["Rejected", "Deleted", "Suspended"]) {
+    assert.equal(statusTone(s), "err", s);
+  }
+
+  for (const s of ["In Progress", "In-Progress", "To-Do", "Awaiting Approval", "Replaced", "Returned"]) {
+    assert.equal(statusTone(s), "warn", s);
+  }
+
+  for (const s of ["Ongoing", "For Review", "Assigned"]) {
+    assert.equal(statusTone(s), "info", s);
+  }
+
+  for (const s of ["Inactive", "Expired"]) {
+    assert.equal(statusTone(s), "neutral", s);
+  }
+});
+
+/**
+ * HID enrolment. These two are the whole point of the Status column on
+ * `HidUserEnrollment` - if they were left unlisted they would BOTH be neutral
+ * and the column would stop distinguishing anything, so they are pinned.
+ */
+test("Mapped and Unmapped keep the tones the enrolment screen already gave them", () => {
+  assert.equal(statusTone("Mapped"), "ok");
+  assert.equal(statusTone("Unmapped"), "warn");
+});
+
+/**
+ * HID intercom SIP state. "Disabled" and "Not connected" must stay NEUTRAL -
+ * painting an intentionally-off intercom red would read as a fault.
+ */
+/**
+ * HID access authorization, landing on `staging` in b0667a7. Pinned before that
+ * merge so the words cannot arrive and quietly render neutral - the difference
+ * between a granted and a denied door is the whole point of the column.
+ */
+test("HID authorization states are known to the shared map before b0667a7 merges", () => {
+  assert.equal(statusTone("Authorized"), "ok");
+  assert.equal(statusTone("Not Authorized"), "err");
+  assert.equal(statusTone("Unknown"), "warn");
+});
+
+test("intercom SIP states keep the tones the intercom screen already gave them", () => {
+  assert.equal(statusTone("Connected"), "ok");
+  assert.equal(statusTone("Connecting"), "warn");
+  assert.equal(statusTone("Not connected"), "neutral");
+  assert.equal(statusTone("Disabled"), "neutral");
+  assert.equal(statusTone("Failed"), "err");
+});
+
+/**
+ * The one place the handoff and the old per-screen colour disagree: `Open` was
+ * grey on the cleaning schedules and the design names it `ok`. Pinned so the
+ * disagreement is a decision on the record rather than a surprise.
+ */
+test("Open follows the design, not the old grey", () => {
+  assert.equal(statusTone("open"), "ok");
+});
+
+test("the class name matches what tokens.css actually defines", () => {
+  assert.equal(statusToneClass("Paid"), "tone-ok");
+  assert.equal(statusToneClass("Whatever"), "tone-neutral");
+});