@7365admin1/core 3.47.0 → 3.47.1-staging.121

package/.changeset/camera-engagement-site-scope.md

@@ -0,0 +1,15 @@
+---
+"@7365admin1/core": patch
+---
+
+Camera entitlement: an engagement grants a site only to an org-level membership, and permissions resolve against the granting role
+
+Two follow-ups to the camera entitlement change:
+
+- the engagement branch of `cameraGrant` ignored `members.siteId`, so a member
+  pinned to one site could reach every site their organisation is engaged at.
+  It now requires an org-level membership, matching the owning-org branch above
+  it: a membership pinned to a site never grants a different site.
+- `getUserPermissions` accepts the granting membership's `role`, so a caller
+  holding several memberships in one organisation is no longer resolved by
+  whichever member document Mongo returns first.

package/.changeset/camera-entitlement-engagement.md

@@ -0,0 +1,45 @@
+---
+"@7365admin1/core": patch
+---
+
+Let camera authorization understand engagements, and resolve it against the
+right organisation.
+
+Three defects in the same decision, fixed together because they are the same
+question: "may this person reach this site, and on whose behalf?"
+
+**1. An engagement was not an entitlement.** The product routes a service
+provider - a security agency, a property management agency - to a customer's
+site through an ACTIVE `customer.sites` record (`{org: provider, siteOrg: owner,
+site}`). 227 of those are active on staging, 53 of them cross-organisation. It
+is the same list the web apps' own site switcher is drawn from
+(`useCustomerSite().getAll()`). No camera authorization code read it, so a guard
+whose agency is contracted at a site was refused the cameras of the site the
+switcher had just offered them. Measured on staging: **11 people reach a site
+holding an active IP camera by this route and no other, 7 of them on wildcard
+`owner` / `Super Admin` roles** - and across all 200 sites the figure is 125
+people, 43 of them on wildcard roles. Nobody loses access; the change is
+additive.
+
+**2. `site.org` does not exist.** `authorizeSite` and `authorizeCamera`
+projected `{org: 1}` and tested `site?.org`. All 200 site documents carry
+`orgId`; not one carries `org`. So the org-level branch of the rule - the branch
+for the 90 membership rows (56 people) that carry no `siteId` - could never
+match. It reads `orgId` now, with `org` kept as a fallback. This WIDENS access,
+so it was measured before it was enabled: on staging it admits **0** additional
+people to a site holding a camera, and 14 across all 200 sites.
+
+**3. Permissions resolved against an arbitrary organisation.**
+`getUserPermissions({user, org: memberships[0]?.org})` took whichever membership
+Mongo returned first, which for the 22 people who belong to more than one
+organisation is a coin toss - it could read the permissions of an organisation
+that has nothing to do with the site being asked about. It now resolves against
+the membership that actually granted access.
+
+Also splits `entitleSite` (may this person reach this site) out of
+`authorizeSite` (that, plus the permission this particular use needs), so a
+plain read of a site's own camera list can be scoped without also being gated on
+a permission that would strand people who are legitimately at the site.
+
+No response field changed. No route changed. No device is contacted by any of
+this.

package/.changeset/camera-functions-for-patrol.md

@@ -0,0 +1,42 @@
+---
+"@7365admin1/core": minor
+---
+
+Camera functions for Virtual Patrol, proxied server-side.
+
+Adds authenticated camera endpoints so the apps can use a site camera without ever
+holding its credential. Dahua devices authenticate with digest and the cleartext
+password on every request (HTTP API V3.37 §3.4) and the specification offers no
+session or usable token, so the only safe shape is a server-side proxy.
+
+- `useCameraViewController` — snapshot, snapshot-to-file for evidence, and
+  per-recorder health.
+- A camera record does not hold a device address: `site.cameras.host` is the CCTV
+  relay's page URL and its numeric last path segment is the stream channel. A
+  camera is therefore resolved as **recorder (from `CAMERA_RTSP_DEVICES`, keyed by
+  relay authority) + channel (from the stored host)**. The address and credential
+  live in deployment configuration only — never in the database, never in a client.
+- Pictures come off the video stream (one `ffmpeg` frame per snapshot, substream
+  for a tile, main stream for an evidence capture). The recorder in use exposes
+  RTSP only; its HTTP CGI ports are not reachable, so `snapshot.cgi`, firmware
+  (§4.6.14), device clock (§4.6.2) and PTZ (§8.1.5) cannot be used against it.
+  Firmware and clock are reported as unavailable with a reason, and PTZ refuses.
+  `GET /site-cameras/capabilities` reports `ptz: false` whatever
+  `CAMERA_PTZ_ENABLED` says, so a client hides the control rather than drawing a
+  pad whose every press fails.
+- A camera whose relay has no configured recorder, or whose address carries no
+  channel, is refused up-front with a reason rather than failing as a blank picture.
+- At most `CAMERA_MAX_CONCURRENT_GRABS` (4) pictures are taken at once across the
+  process, so the endpoint cannot fill the API host with ffmpeg or overpull the
+  recorder; over that, the caller is told the cameras are busy.
+- Access is decided by the caller's site/org membership and their role's
+  permissions, never by the camera id in the URL.
+- ANPR units are refused: ANPR belongs to visitor and vehicle management, not to
+  Virtual Patrol or CCTV.
+- Camera host, username, password and the RTSP URL are never returned and never
+  logged; ffmpeg's stderr is discarded because it echoes the credential.
+- No retry on a camera call: the device locks an account for 1800 s after 3
+  failures in 30 s (§4.7.x).
+
+Requires `ffmpeg` on the API host (or `CAMERA_FFMPEG_PATH`); where it is absent the
+snapshot endpoints answer with "Video tooling is not available on this server."

package/.changeset/camera-integration-layer.md

@@ -0,0 +1,60 @@
+---
+"@7365admin1/core": minor
+---
+
+Camera integration layer: a capability descriptor, a transport registry, and the
+Dahua device HTTP adapter (written, tested, switched off).
+
+Every camera in the wall and status responses now carries a `capabilities`
+descriptor: `liveVideo`, `stillFrame`, `digitalZoom`, `ptz`, `presets`,
+`playback`, `events`, `audio`, `deviceInfo`, each `supported` / `unsupported` /
+`unknown` with a machine-readable reason code and one sentence. A client renders
+itself from it without knowing anything about relays, recorders or networks.
+`unknown` is distinct on purpose: "we have not been allowed to ask" is not the
+same fact as "this camera cannot".
+
+Capabilities resolve through a transport registry instead of the service picking
+a path. `RELAY_PLAYER` is the stored player-page URL rendered in a WebView (the
+live product's picture path, live video only, no control channel).  `RTSP_FRAME`
+is one ffmpeg still off the recorder. `DEVICE_HTTP` is the camera's own CGI API.
+Registration order is preference order, so one camera serves live video over the
+relay and evidence stills over RTSP at the same time, and adding a transport
+later needs no service change.
+
+`DEVICE_HTTP` covers device info/version, snapshot, PTZ (continuous, absolute,
+stop), presets (list and recall), recorded-file query with playback URL
+construction, and event subscription - digest auth only, values percent-encoded,
+403 treated as bad credentials and 401 as an ordinary challenge. It contacts
+nothing today: the recorder in this estate answers on RTSP only. Enabling it is
+configuration, not a code change.
+
+A shared, persistent authentication failure budget is mandatory on that path. The
+device locks an account for 1800 s after 3 failed logins in 30 s, so failures are
+counted per device in the cache, the budget stops at 2, and once spent no request
+leaves the process. Nothing retries anywhere.
+
+Mutating operations are structurally unreachable while disabled: the adapter is
+`null` without `CAMERA_DEVICE_HTTP_ENABLED`, and its `control` object is `null`
+without `CAMERA_DEVICE_CONTROL_ENABLED`. Movement codes are an allow-list;
+`SetPreset`, `ClearPreset`, tours, patterns, `configManager` writes and reboot are
+absent.
+
+Capability probing is read-only, cached, budget-aware, never throws, and happens
+only on a deliberate single-camera status request - never as a side effect of a
+list.
+
+`host` is now returned for `type: "ip"` cameras on the wall response. It is the
+video relay's player-page URL, not a device address and not a credential, and
+`GET /site-cameras` already returns it to every authenticated caller. `anpr`
+records, whose `host` is a real device endpoint, are excluded by the allow-list
+itself.
+
+New configuration, all optional and all off by default: `CAMERA_DEVICE_HTTP`
+(JSON keyed by relay authority, credential referenced by environment variable
+name), `CAMERA_DEVICE_HTTP_ENABLED`, `CAMERA_DEVICE_CONTROL_ENABLED`,
+`CAMERA_DEVICE_HTTP_TIMEOUT_MS` (8000),
+`CAMERA_DEVICE_HTTP_PROBE_TTL_SECONDS` (900). See
+`docs/camera-integration-config.md`.
+
+Existing responses keep every field they had, with the same wording, so current
+consumers are unaffected.

package/.changeset/camera-list-site-scoping.md

@@ -0,0 +1,42 @@
+---
+"@7365admin1/core": patch
+---
+
+Scope `GET /site-cameras` to the caller's own site.
+
+The site was an OPTIONAL query parameter and nothing on the handler looked at
+the session beyond `requireAuth`. So any signed-in account, in any organisation,
+could page the whole estate's cameras - on staging that is all 15 active IP
+cameras across 3 owner organisations, each record carrying its `host` and its
+`username`. It is the plainest cross-tenant read left in the camera module.
+
+`site` is now required, and the caller is authorised against it with
+`entitleSite`: membership of the site, of its owning organisation, or an ACTIVE
+`customer.sites` engagement with it. "Not yours" and "does not exist" answer
+identically, so site ids cannot be enumerated from the difference.
+
+**Every caller in the estate already sends `site`** - checked across every
+repository, not assumed:
+
+| caller | sends |
+|---|---|
+| `iservice365-mobile-app-security` `pages/cctv/index.vue` (live) | `site`, `type: ip`, `page` |
+| `iservice365-mobile-app-security` `useAnprEnabled` (live) | `site`, `type: anpr` |
+| `iservice365-layer-common` `CameraMain.vue` (Site Settings) | `site`, `type`, `page` |
+| `iservice365-layer-common` `CameraWall.vue` | `site`, `type: ip`, `page` |
+| `iservice365-web-app-security` `VirtualPatrolRoutesForm.vue` | `site`, `type: ip`, `page: 1` |
+| `isecure365-mobile-app` `site.service.ts` `getAnprCameras` | `site`, `type: anpr` |
+
+So no running client breaks.
+
+Deliberately NOT gated on a camera permission. This is the same list the site's
+own Settings panel and the guard's app have always read; on staging only 25 of
+the 118 people entitled to a site with a camera hold a camera-view permission,
+so a permission gate here would strand people who are legitimately at the site.
+Restricting the read to the caller's own sites is the fix; who among them may
+look is a separate decision that needs its own measurement.
+
+The repository's 15-minute cache key already carries the site, so a cached page
+can only be served to callers authorised for that same site. No caller id was
+added to the key - it would make the cache per-person for an answer that is
+identical per site.

package/.changeset/camera-monitoring-wall.md

@@ -0,0 +1,32 @@
+---
+"@7365admin1/core": minor
+---
+
+CCTV monitoring wall: a site-scoped camera list and a batched health sweep.
+
+Two additions to the camera proxy so a supervisor can watch a whole site rather
+than one checkpoint at a time.
+
+`getSiteWall` returns the cameras of one site from `site.cameras` - the
+collection the real cameras are in - together with the polling intervals and
+fan-out caps the client should use. No device is contacted, so opening a wall is
+one database read. Entitlement is by site membership, not by the id in the URL,
+and a caller outside the site gets the same answer as one asking for a site that
+does not exist.
+
+`getSiteHealth` probes the cameras currently on screen with at most
+`CAMERA_WALL_MAX_CONCURRENT_PROBES` in flight. Reachability is a **per-recorder**
+answer, cached per recorder: twelve of this estate's cameras are twelve channels
+on one device, so a full wall is one connect rather than one per tile. It never
+throws for a camera that is down; unreachable is the answer, and a camera whose
+relay has no configured recorder is refused with a reason instead.
+
+Firmware version and device clock are reported as unavailable with a reason: they
+are HTTP CGI facts and the recorder in use exposes RTSP only.
+
+Snapshots now record when a camera last returned a picture, so a tile can say
+"last frame 40 minutes ago" instead of "never".
+
+New, all optional and conservative by default: `CAMERA_WALL_POLL_MS` (5000),
+`CAMERA_SINGLE_POLL_MS` (2000), `CAMERA_WALL_MAX_TILES` (9),
+`CAMERA_WALL_MAX_CONCURRENT_PROBES` (4), `CAMERA_HEALTH_CACHE_SECONDS` (20).

package/.changeset/camera-probe-cache-and-substream-fallback.md

@@ -0,0 +1,46 @@
+---
+"@7365admin1/core": minor
+---
+
+CCTV reliability: cache the capability probe per channel, and stop reporting a
+missing sub-stream as a dead camera.
+
+Two defects in the camera proxy, both of which made one camera answer for
+another.
+
+**The capability probe was cached per recorder.** The key was `probe:<baseUrl>`,
+so the first camera anyone opened decided `ptz` and `presets` for every channel
+on that recorder until the TTL expired (default 900s). On this estate twelve
+cameras are twelve channels on one device, and they are not all the same model.
+The key is now `cameraProbeCacheKey(baseUrl, channel)` and every reader passes a
+channel - `refreshProbe`, the health sweep, and the monitoring wall, whose own
+de-duplication `Map` was keyed by recorder too and would have re-created the
+same fault a layer above the cache. Cache lifetime and eviction are unchanged.
+
+Only `ptz` and `presets` are channel-specific. `reachable`, `lockedOut`,
+`softwareVersion` and `deviceType` are recorder facts that answer identically on
+every channel, which is what `deviceInfo`, `playback` and `events` read, and a
+test pins that so it stays true. The cost is at most one probe per channel per
+TTL, and only on the deliberate single-camera status path - the wall and the
+health sweep still never probe.
+
+**A channel with no sub-stream failed exactly like a dead camera.** An
+ONVIF-attached third-party camera frequently publishes no sub-stream, and the
+recorder answers that channel with no picture, which surfaced as "The camera did
+not return a picture." - indistinguishable from a camera that is off.
+`getSnapshot` now goes through `grabWithSubStreamFallback`: the sub-stream
+first, then exactly one main-stream attempt if and only if the failure is
+`camera-no-picture`. The result carries `stream` and `fellBackToMain`, exposed
+on the snapshot response as `X-Camera-Stream` and `X-Camera-Stream-Fallback`
+alongside the existing `X-Camera-Snapshot-Cached`, so the fallback is explicit
+rather than silent and a client can say "showing full resolution: this camera
+has no low-bandwidth stream". A `nosub:<cameraId>` marker keeps the wasted
+attempt to once per TTL, and a channel later given a sub-stream heals itself.
+
+A refused credential, a timeout, a busy server, an oversized picture or a
+missing ffmpeg never falls back - one attempt each, unchanged. Patrol evidence
+(`hd: true`) already asks for the main stream and never enters the fallback.
+
+Per-camera stream configuration is the better long-term answer but needs a
+schema field, a form, an API surface and a migration for the existing cameras;
+the automatic fallback needs no data change and is raised as a follow-up.

package/.changeset/camera-setup-from-recorder.md

@@ -0,0 +1,43 @@
+---
+"@7365admin1/core": minor
+---
+
+Camera setup from the recorder and channel, and a read-only test before saving.
+
+A CCTV camera record stores a video-relay player-page URL. Nothing printed on a
+camera or shown in a recorder's own screens tells anybody what that URL is, so
+adding a camera meant asking whoever runs the video service for one address per
+camera and pasting it in unverified.
+
+`POST /site-cameras` and `PATCH /site-cameras/id/:id` now also accept
+`recorderHost`, `recorderPort` and `channel`. The server reads the existing
+`CAMERA_RTSP_DEVICES` map backwards - relay authority to recorder becomes
+recorder to relay authority - and derives the same `https://<relay>/<channel>`
+address it has always stored. There is deliberately no second map and no new
+stored field: the recorder fields are consumed by the controller and never reach
+the model, so `site.cameras` keeps exactly the shape it has today.
+
+Additive and ordered so: a request that sends `host` behaves exactly as it
+always has, so every camera configured that way and anyone holding a ready-made
+address is unaffected. A recorder with no configured entry is refused with a
+sentence a property manager can act on rather than a code.
+
+New: `POST /site-cameras/site/:siteId/test` - does this address actually show a
+picture? Site-scoped because the camera does not exist yet, and it requires
+`site-settings:manage-cctv-camera`. The probe is read only: one TCP connect with
+no credential, then at most one video frame off the stream. There is no mutating
+call in the path.
+
+It is rationed before it can reach a device - one test per camera per 15 s, four
+per recorder per 5 minutes - and it consults the shared authentication failure
+budget first, so pressing the button cannot walk a recorder into its own
+3-failures-in-30-seconds, 1800-second lockout. It answers with one of five plain
+sentences and never an address, port, credential or device message.
+
+`ffmpeg`'s stderr is now read for one fact - was the handshake rejected - and
+discarded chunk by chunk without being accumulated, logged or returned, so "the
+recorder refused the credential" can be told apart from "the channel is not
+sending video". Snapshot failures gain that distinction too.
+
+`authorizeSite` takes an optional permission list; existing callers are unchanged
+and still require the camera view permissions.

package/.changeset/camera-write-authorization.md

@@ -0,0 +1,35 @@
+---
+"@7365admin1/core": minor
+---
+
+Authorize creating, editing and deleting a site camera.
+
+`POST /site-cameras`, `PATCH /site-cameras/id/:id` and `DELETE
+/site-cameras/id/:id` carried `requireAuth` and nothing else. There was no
+permission check and no site scoping, so any signed-in account in any
+organisation could add a camera to a site it has no relationship with, rewrite
+another customer's camera address, or hard-delete one - the delete is a real
+`deleteOne`, not a soft delete, and it reported success whether or not it matched
+anything.
+
+All three now go through `authorizeSite`, the same rule the read paths already
+use: the caller must be a member of the camera's site, and their role must hold
+the permission the Settings panel that draws the button is drawn on -
+`site-settings:manage-cctv-camera` for a CCTV camera, `site-settings:manage-anpr-camera`
+for an ANPR one. One endpoint serves both panels, so the permission follows the
+camera's own `type` rather than being one string for both; asking only for the
+CCTV string would have refused a role provisioned to manage ANPR alone.
+
+For `PATCH` and `DELETE` the site and the type are read off the stored camera,
+never off the request - `schemaUpdateSiteCamera` carries neither, and a caller
+must not be able to supply either. A camera the caller may not reach is reported
+exactly as a camera that does not exist, so the difference cannot be used to
+enumerate camera ids.
+
+Measured on staging before shipping: of the 107 users entitled to a site that has
+a CCTV camera, 12 pass this gate and every one of them passes on the `*`
+wildcard. No role that would now be refused holds any `site-settings:` string at
+all, so no account that can open the CCTV or ANPR panel today is refused by this
+change.
+
+No response shape, status code or field changed for a permitted caller.

package/.changeset/console-audit-trail.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+Staff console: record who did what, and add a staff-only endpoint to read it back

package/.changeset/console-subscription-setup.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Add the staff console endpoints that set up, change and read back a client subscription, and the optional plan, start date, end date and billing mode fields they store.

package/.changeset/customer-site-property-details.md

@@ -0,0 +1,42 @@
+---
+"@7365admin1/core": patch
+---
+
+Give the Add / Edit Site form's property details somewhere to land.
+
+The Organization app's Add Site form collects eight fields beyond the name,
+category and address: MCST plan no., UEN, date of constitution, financial year
+end, billing quarter, share capital, temporary occupation permit and
+certificate of statutory. **None of them has ever been stored.** On create
+`schemaCustomerSite` rejects any key it does not list, so sending them returns
+400 - which is why the form quietly leaves them out of the request. On update
+`updateCusSiteById` builds a whitelist of `name`, `address` and `category` and
+drops the rest. The Edit dialog reads them back from the customer-site
+document, so they display as empty every time.
+
+Eight optional string fields are added to `schemaCustomerSite`, to
+`TCustomerSite`, to the `MCustomerSite` projection, and to the update
+whitelist. One exported list (`customerSitePropertyFields`) drives both the
+create projection and the update whitelist, so the two cannot drift apart.
+
+**Additive and optional only.** No migration, no backfill, no index change,
+nothing written to any existing record. A field the caller did not send stays
+absent from the document rather than being written as an empty string, so a
+customer-site written before this change is byte-identical afterwards and still
+validates. An empty string IS kept, because clearing a field on the Edit form
+has to clear it. Unknown keys are still rejected on create - this widens the
+allow-list, it does not open it.
+
+Blast radius, checked across every repository in the organisation rather than
+assumed: `POST /api/customer-sites` has exactly **one** caller in the estate
+(`iservice365-web-app-org` `components/SiteForm.vue`) and `PUT
+/api/customer-sites/:id` has the same one. Every other consumer - all eleven
+Nuxt apps via `layer-common`'s `useCustomerSite`, the resident app, the six
+service-provider mobile apps, `iservice365-mobile-app-security` and
+`isecure365-mobile-app` - only ever reads (`GET`), and reads name their fields
+explicitly. `addViaInvite` sends none of the eight, so the invite-acceptance
+path writes exactly the document it wrote before.
+
+Covered by `test/customer-site-property-fields.test.mjs`, which asserts the
+before-and-after shape both ways round: the details are accepted and survive
+into the document, and a create without them still writes none of them.

package/.changeset/dahua-credential-logging.md

@@ -0,0 +1,19 @@
+---
+"@7365admin1/core": patch
+---
+
+Stop logging camera and mailer credentials
+
+Six places wrote a secret or a resident's details to stdout on an ordinary code
+path. `getTrafficJunction` dumped the whole `TSiteCamera` object — including the
+camera's `username` and plaintext `password` — on every reconnect, and
+`addPlateNumber` logged its argument, which carries the same password plus a
+resident's plate number and owner name. `checkOutBySiteAndPlate` logged the
+matched visitor transaction. `siteCameraRepo.updateById` logged the re-read
+camera document, and `vehicleService.add` logged the whole array of a site's
+cameras, both with credentials in them. `sendEmail` printed `MAILER_PASSWORD`
+itself on every message sent.
+
+All now log identifiers, counts and outcomes only, through the module's logger
+rather than `console.log`; the mailer line is removed outright because it
+carried nothing but the secret.

package/.changeset/dahua-spec-defects.md

@@ -0,0 +1,20 @@
+---
+"@7365admin1/core": patch
+---
+
+Fix three Dahua HTTP API defects found by checking our integration against the
+vendor specification (V3.37):
+
+- The ANPR reconnect loop retried authentication ten times at one-second
+  intervals. The device locks the account for 1800 seconds after three failed
+  logins in thirty, so our own recovery could take ANPR down at a site for half
+  an hour. Authentication now backs off well past the device's counting window,
+  and a network fault is distinguished from an authentication failure.
+- 401 and 403 were handled backwards. Per spec §3.4, 401 is the digest
+  challenge (retry) and 403 is a credentials rejection (stop). We treated 403 as
+  an account lock and killed the listener, and counted 401s toward a "wrong
+  password" warning.
+- `updatePlateNumber`, `bulkInsertPlateNumber` and `removePlateNumber`
+  interpolated values into the CGI query string unencoded, against the spec's
+  stated RFC 3986 requirement. A plate or owner name containing a space or "&"
+  broke the request or appended extra parameters to it.

package/.changeset/dashboard-truth-and-camera-health-claim.md

@@ -0,0 +1,104 @@
+---
+"@7365admin1/core": minor
+---
+
+Stop the dashboards reporting figures nothing measured, and stop a recorder
+socket being reported as camera health.
+
+Five values were being returned in a shape that made "we measured this" and "we
+never measured this" indistinguishable. Each is now either computed from real
+data or returned as an explicit `null` with a reason a client can show.
+
+**Patrol Compliance showed 100% on a site with no patrol data.**
+`complianceRate` fell back to `100` when the checkpoint total was 0, so a site
+with no patrol logs drew the same tile a perfect week draws - and a failed
+request drew 0%. `calculateComplianceRate` now returns `null` when no checkpoint
+was due, alongside `patrolCompliance.checkpointsDue` and an
+`unavailableReason`. The Virtual Patrol process itself is untouched; this is
+reporting only.
+
+**"0 high severity" was a hard-coded literal**, at `openIncidents.highSeverity`
+in both the security and property dashboards, on every site, on every day. It
+read as "we checked your incidents and none of them are serious". Incident
+reports record no severity at all - `TIncidentReport` has no severity, priority
+or criticality field, and the only `highPriority` flags in this package are on
+work orders and feedbacks - so there is nothing to count. It now returns `null`
+with `highSeverityUnavailableReason`. `highSeverityIncidentCount` counts rather
+than hard-returning `null`, so the tile starts telling the truth on its own the
+day the incident form records a severity. Nothing is guessed in the meantime.
+
+**The trend percentage compared the wrong period, in the wrong timezone.** The
+`+/-%` beside every KPI tile was always today-vs-yesterday even on the Week and
+Month views, so a month's count sat next to a yesterday comparison, unlabelled.
+And the day boundary came from `new Date()` + `setHours(0,0,0,0)` - the HOST's
+midnight - while `formatEndDate` and the period range beside it force
+Asia/Singapore. On a UTC container the two halves disagree by eight hours:
+"today" silently loses SGT 00:00-08:00 while "yesterday" keeps its full 24, so
+the comparison was biased before any data was counted.
+
+`getPeriodRange` / `getPreviousPeriodRange` (new,
+`src/utils/dashboard-metrics.util.ts`) state Asia/Singapore explicitly and take
+an injectable clock. Week now compares against the previous ISO week and month
+against the previous month, in all three dashboards plus the facility-booking
+tile. The boundary is correct whatever the host is set to; the host's own `TZ`
+still wants reading by someone with DigitalOcean access, but only to size the
+damage already done.
+
+**A missing prior period now yields no percentage.**
+`calculatePercentageChange` returned `100` when the prior period was empty and
+`0` when both were empty, so a first-ever record read as growth and a site where
+nothing has ever happened read as measured stability. Both now return `null`.
+
+**"Supply Alert" is not an alert.** The query is `sort by qty ascending, limit
+3` with no threshold, because `site.supplies` records no stock level to compare
+against - no `minQty`, no `reorderLevel`, no `threshold`, on any model in this
+package. 900 gloves appeared under a heading that said "alert". No threshold is
+invented: the payload now carries `basis: "lowest-quantity"` and
+`thresholdUnavailableReason` so no client can present the list as a low-stock
+warning. The client already relabels the tile "Lowest Stock".
+
+**Camera health was a socket on the recorder, presented as the camera's.**
+`probeDevice` is a bare TCP connect to the recorder's RTSP port, cached per
+recorder. That caching is deliberate and worth keeping - twelve channels on one
+device is one connect, not twelve - but it means one dead camera among twelve
+stayed invisible (the recorder still answers, so every channel returned
+`reachable: true`, `health: "ok"`, `reason: null`), and a relay outage read as
+twelve healthy tiles because the relay is never probed.
+
+A true per-camera liveness check is not available on this path: it would mean an
+authenticated per-channel RTSP frame grab for every tile on every sweep, which
+is device contact this change is in no position to make or to test and is enough
+of it to reach the recorder's own lockout. So none is faked. Every health answer
+now carries `cameraHealthClaim` - `verified` (`"recorder-video-port"` or
+`"nothing"`), a `verifiedDescription` sentence, and `cameraVerified` /
+`relayVerified` as explicit `null`s - so the response states exactly what was
+checked and cannot be read as a stronger claim. `health` and `reachable` keep
+their existing values and meanings, so the web wall (which already labels this
+"Recorder responding") and the mobile monitoring screen are unaffected. A camera
+that resolves to no recorder reports `"nothing"` rather than a check that
+failed, because no request left the server.
+
+Nothing else in the health descriptor overstates itself: `firmwareVersion`,
+`deviceTime` and `driftSeconds` already return `null` with
+`detailUnavailableReason`, and capabilities already carry an explicit
+`"unknown"` state with a reason.
+
+**Response contract:** `patrolCompliance.count`, `openIncidents.highSeverity`
+and every tile's `percentage` may now be `null`. Checked against the current
+published client rather than assumed: `DashboardMain.vue` coerces through
+`toNumber(value ?? 0)`, so nothing crashes and nothing prints "null". A `null`
+percentage is coerced to 0, which `v-if="card.percentage"` treats as falsy, so
+the trend pill correctly disappears - the intended behaviour, for free. But a
+`null` compliance rate still draws "0%" and a `null` high-severity count still
+draws "0 high severity" until the layer renders the not-available. So on a site
+with no patrol data the tile moves from a fabricated 100% to a fabricated 0%
+until that lands; both are wrong, and the API is now the half that is right.
+The client-side half is `layer-common` #1229 (open).
+
+Dead code removed as a consequence: the local `formatEndDate` and
+`getSiteDayRange` in `new-dashboard.repo.ts` have no remaining callers.
+
+Deliberately not changed: the duplicate current-period aggregations (the trend's
+current-side query now matches the tile's own count query and could be dropped,
+but that is an optimisation, not a correctness fix); the Dahua URL convention;
+and the disabled device-control capabilities, which stay off.

package/.changeset/default-staff-role-lookup.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+Resolve the seeded platform staff role by type as well as name, so the default staff account cannot be bound to an ordinary organisation role that happens to share the name.

package/.changeset/hid-card-pin-authorization.md

@@ -0,0 +1,35 @@
+---
+"@7365admin1/core": patch
+---
+
+HID Amico: authorise the card, PIN, discovery and visitor-QR endpoints
+
+Ten HID Amico handlers required a session and nothing else. The reader id in
+the URL was the only thing selecting the device, and `GET /readers` returns
+every reader in the estate when no `site` is supplied, so any signed-in account
+could act on any reader at any site of any organisation — assign or delete a
+physical access card, set or clear a keypad PIN, put a reader into card
+enrolment, list a user's stored card values, or revoke a visitor's QR pass.
+
+Each of the ten now authorises before it does anything:
+
+- `listUserCards`, `assignUserCard`, `enrollUserCard`, `cancelUserCardEnrollment`,
+  `deleteUserCard` and `revokeVisitorQr` require `site-settings:manage-entry-pass`
+  at the site of the **stored** reader.
+- `getUserPinStatus`, `setUserPin` and `deleteUserPin` allow either that same
+  administrator, or the person whose own device user it is — entitlement to the
+  reader's site plus an ownership check on `hidUserId`, so the resident and MA
+  mobile apps' "Access PIN" screen keeps working while a neighbour's PIN cannot
+  be rewritten.
+- `discoverReader` now takes the `site` the reader is being added to and
+  authorises it, and the address it may be pointed at is constrained: an
+  `http(s)` origin only, no credentials, no path, and never the API host itself
+  or the instance-metadata range. `HID_DISCOVERY_ALLOWED_HOSTS` optionally pins
+  it to named hosts; unset, nothing changes operationally.
+
+A reader that is not yours answers exactly like a reader that does not exist, so
+reader ids cannot be enumerated by watching the difference.
+
+**Consumer change required:** `POST /access-management/hid/readers/discover` now
+requires `site` in the body. `HidReaderForm.vue` in `@7365admin1/layer-common` is
+the only caller and must be updated to send it.

package/.changeset/hid-physical-card-lifecycle.md

@@ -0,0 +1,8 @@
+---
+"@7365admin1/core": minor
+---
+
+Add dedicated physical HID card APIs for PACS and CSN credentials, including
+manual assignment, reader enrollment, cancellation, verified removal, duplicate
+protection, reader configuration checks, identity lookup metadata, and audited
+device events.

package/.changeset/hid-reader-handler-authorization.md

@@ -0,0 +1,21 @@
+---
+"@7365admin1/core": patch
+---
+
+HID: the five reader endpoints added for production readiness now authorise in their own handlers
+
+`listReaderUsers`, `listReaderAccessLogs`, `configureReaderIntegration`,
+`setReaderMonitor` and `setOperatingMode` had no check in their bodies. They are
+guarded today by `authorizeView` / `authorizeManage` in the API-core router, so
+this is not a live hole — but the guard and the handler sit in two different
+repositories, and this is a published package: a router edit or a second
+consumer mounting `useHidAmicoController()` would leave an endpoint that reaches
+a physical door reader with nothing in front of it.
+
+Each now calls `authorizeHidAccess` itself, at the level the router already
+applies — `view` for the two lists, `manage` for the three writes — with the
+site resolved from the stored reader, never from the request. No caller's
+authority changes.
+
+The guard test now covers all fifteen HID handlers and names the unguarded ones
+in its failure message.