@7365admin1/core 3.48.1-staging.211 → 3.49.1-staging.212

package/CHANGELOG.md

@@ -1,5 +1,1712 @@
 # @iservice365/core
 
+## 3.49.0
+
+### Minor Changes
+
+- 8581896: Scope the access-management routes to a site the caller can reach.
+
+  Every route on `/api/access-management` carried `requireAuth` and nothing more.
+  `requireAuth` proves a session exists; it makes no organisation or site
+  decision. So any signed-in account on the platform — a resident of a different
+  estate, a cleaner, anybody with a login — could read another client's
+  access-card inventory, its card holders, the residents behind a unit and the
+  block/level/unit structure, and could ISSUE a physical NFC card into that
+  estate, generate visitor QR passes for it and stamp QR tags onto its cards.
+  These are the credentials that open that estate's doors and lifts.
+
+  Twenty-eight handlers now decide from the site the request already names,
+  before any work is done:
+
+  - from the body — `addPhysicalCard`, `addNonPhysicalCard`, `acknowlegdeCard`,
+    `replaceCard`, `assignAccessCardToUnit`, `vmsgenerateQrCodes`,
+    `addVisitorAccessCard`;
+  - from the query — `allAccessCardsCounts`, `availableAccessCards`,
+    `userTypeAccessCards`, `assignedAccessCards`, `assignedAccessCardsByUnit`,
+    `accessandLiftCards`, `doorAndLiftDropdown`, `visitorAccessCards`,
+    `bulkPhysicalAccessCard`, `getCardDetails`, `allQrTag`,
+    `availableCardContractors`, `getBlockLevelAndUnitList`, `getResidents`,
+    `userAccessCards`, `uploadTemplate`, `removeTemplate`, `qrCodeList`;
+  - from the URL — `getCardReplacement`, `getAccessManagementSettings`, `addQrTag`.
+
+  The rule is the existing one, `requireSiteReach` -> `entitleSite`: a membership
+  pinned to the site, an org-wide membership at the site's owning organisation, or
+  an ACTIVE `customer.sites` engagement. The engagement branch is required, not
+  incidental — access cards are administered from the security and
+  property-management apps, whose users hold no membership in the estate's own
+  organisation.
+
+  The guard writes its own response instead of throwing. Every handler in this
+  controller wraps its body in `try { ... } catch { res.status(400|500) }` rather
+  than calling `next(error)`, so a thrown `UnauthorizedError`/`NotFoundError`
+  would never reach the error handler and would have surfaced as a 400 with the
+  guard's message inside it. It is placed AFTER each handler's Joi validation, so
+  a malformed or missing site still answers 400 exactly as before, and only a
+  well-formed site the caller cannot reach is refused. That refusal is 404 — what
+  a site that does not exist already answers — so site ids cannot be enumerated by
+  watching the difference.
+
+  Six routes on the mount are deliberately NOT changed, because they carry no
+  site at all and need per-record resolution:
+
+  - `POST /sign-qr` and `PATCH /visitor-checkout` — both are called by shipped
+    mobile clients that cannot update in lockstep
+    (`resident-mobile-app src/actions/entrypass.ts:66`, `isecure365-mobile-app
+src/features/visitors/entry-pass.service.ts:175` and `visitor.service.ts:194`).
+  - `PATCH /nfc-status`, `PATCH /delete-card`, `POST /card-replacement`,
+    `POST /assign-user` — each identifies a card by id and would need the card's
+    own site loaded first.
+  - `GET /door-access-levels`, `GET /lift-access-levels`, `GET /access-groups` and
+    `POST /settings` take an `acm_url` — an access-control device URL — so they
+    are a separate question from site reach and were not touched here.
+
+- 01ea9fc: Take the attendance caller's identity from the session, and scope every attendance
+  route to its estate.
+
+  Two separate defects, both on every route of `/api/attendances`.
+
+  **The caller's identity came from a cookie the caller writes.** Every handler read
+  `user` out of the raw `Cookie` header. That cookie is set by the browser itself
+  (`layer-common/composables/useLocalAuth.ts`, `setSession`) and by the mobile
+  clients from their own stored id; the server never compared it to the session.
+  `requireAuth` validates `sid` against Redis and puts the real caller on `req.user`
+  — which this controller ignored. A signed-in account could send
+  `Cookie: user=<somebody else>` and clock that person in, read their shift history
+  and check-in photo, or clock them out; and because check-out `$set`s `user` from
+  the request, checking somebody out also re-attributed their shift. The identity
+  now comes from `callerId(req)`, as the rest of the codebase resolves it.
+
+  **The estate was never checked.** All five routes now go through
+  `requireSiteReach`, the rule `/api/vehicles`, `/api/documents`,
+  `/api/service-providers` and `/api/incident-reports` already use. The four that
+  name a site in the URL check it before using it; `GET /id/:id` and
+  `PUT /id/:id/check-out` name only a record, so the site is read off the **stored**
+  row. The `customer.sites` branch matters here — the contracted agency whose staff
+  actually work these shifts holds no membership in the estate's organisation.
+
+  Every existing client already sends its own id in that cookie, so nothing
+  legitimate changes. A bare `Authorization: Bearer` call that sends no cookie at
+  all used to fail Joi's `user is required` with a 400 and now succeeds, which is
+  the only behaviour that gets looser rather than tighter.
+
+- 159a56f: Scope `/api/customer-sites` to the organisations on the record.
+
+  Every route on this module except the pre-login invite acceptance carried
+  `requireAuth` and nothing more, and took the organisation straight out of the
+  query string or the body (`customer-site.controller.ts`). Two things followed
+  from that, and both are closed here.
+
+  `POST /api/customer-sites` is not merely an engagement record: it CREATES A SITE
+  inside whatever `siteOrg` the body names, and writes that site onto the
+  organisation as its default when it has none
+  (`customer-site.service.ts:77-111`). Any signed-in account on the platform — a
+  resident, a cleaner, a guard — could therefore plant a site inside any client.
+
+  A `customer.sites` row is also the cross-organisation access grant itself: the
+  "engaged agency" branch of `resolveSiteAccess` reads it to decide who may reach
+  a site's cameras, HID readers and residents
+  (`camera-view.service.ts:325-341`). Being able to write, edit or delete those
+  rows by id was being able to grant yourself reach into another client's estate,
+  or revoke a contractor's.
+
+  The caller is now resolved from the session and the decision made before
+  anything is read or written:
+
+  - `POST /` requires `requireOrgAccess` on the body's `org`, and on `siteOrg`
+    too when it names a different organisation — because that is where the new
+    site lands. The Add / Edit Site form sends the same id for both
+    (`web-app-org components/SiteForm.vue:397-402`).
+  - `GET /` requires `requireOrgAccess` on the `org` filter the caller sends.
+  - `GET /:id`, `PUT /:id` and `DELETE /:id` load the row first and decide from
+    the row's own `org` and `siteOrg` — Seven365 staff, or a live member of
+    EITHER side of the engagement. Either, not one: the estate's manager reaches
+    the row through `siteOrg` and the contracted agency reaches the same row
+    through `org`, so scoping to one side would break the other's screen.
+  - `GET /service-provider/:id` takes a SITE id, and uses `entitleSite` — the
+    same site-reach rule the camera, HID and people modules already use, so an
+    agency contracted to a site still lists who else works there.
+
+  `POST /invite/:id` is unchanged and still reachable with no session: an invited
+  organisation accepts before it has an account (`web-app-main pages/sign-in.vue:182`).
+
+  No new authorization mechanism is introduced. `requireOrgAccess` and
+  `entitleSite` are the helpers the member, role, people, camera and HID paths
+  already use, and the "either side" test is `resolveInviteActor` asked about two
+  organisations in one round trip rather than two.
+
+- 6c9b40c: Scope the estate-structure writes to the site they act on.
+
+  `POST/PATCH/PUT` on `/api/buildings`, `/api/building-levels` and
+  `/api/building-units` all carried `requireAuth` and nothing more. The site came
+  from the request body on the creates and the record id came from the URL on the
+  edits and deletes, and neither was checked against the caller. So any signed-in
+  account on the platform could add a block to another client's estate, rename its
+  levels in bulk, or delete its units — the records residents, visitor passes,
+  billing and access rights are all hung off.
+
+  Ten routes now decide from the site:
+
+  - `POST /api/buildings/`, `POST /api/building-levels/`,
+    `POST /api/building-units/` — from the site named in the body, which is where
+    the new record lands.
+  - `PATCH /api/buildings/id/:id`, `PUT /api/buildings/:id`,
+    `PUT /api/building-levels/id/:id`, `PUT /api/building-levels/:id`,
+    `PATCH /api/building-units/id/:id`, `PUT /api/building-units/:id` — the stored
+    record is loaded first and its own site decides. The id in the URL selects the
+    record; it never authorises it.
+  - `PATCH /api/building-levels/batch` — EVERY id in the batch is checked, not
+    just the first, and only the distinct sites are looked up so renaming twelve
+    levels of one block stays one check.
+
+  The rule is `entitleSite`, the site-reach rule the camera, HID and people
+  modules already use: a membership pinned to the site, an org-wide membership at
+  the site's owning organisation, or an ACTIVE `customer.sites` engagement. The
+  engagement branch is required, not incidental — the estate structure is
+  maintained from the property-management and service-provider apps, whose users
+  may hold no membership in the estate's own organisation.
+
+  The shared four lines live in a new `src/utils/site-reach.util.ts` so the same
+  check is not written out in three controllers. It introduces no second
+  mechanism: it resolves the caller with `resolveInviteActor` and defers to
+  `entitleSite`, exactly as `person.controller.ts` does.
+
+  A site the caller cannot reach answers as a site that does not exist, so site
+  ids cannot be enumerated by watching the difference. A record with no site at
+  all is refused rather than waved through.
+
+  The READS on these three routers are deliberately unchanged. Six of them share
+  a controller function with a pre-login signup alias
+  (`/buildings/list/site/resident/:siteId`, `/building-levels/list/site/resident/:siteId`,
+  `/building-units/resident/site/:site/block/:block/level/:level` and the three
+  `resident` variants), which the resident mobile app calls before an account
+  exists. Guarding the handler would break registration on a shipped client, so
+  those need the alias split first.
+
+- b6c1490: Scope the feedback routes to the estate the feedback was raised at, and take the
+  author's identity from the session.
+
+  A feedback row is a resident's complaint about their own estate: the subject,
+  the free-text description, the location inside the block, the attachments and
+  the name of the person who raised it. Every route on `/api/feedbacks` carried
+  `requireAuth` and nothing more, and the controller held no authorization
+  identifier of any kind, so being signed in anywhere on the platform was enough
+  to read another client's complaints, rewrite them, re-route them to a different
+  service line, close them, or delete them.
+
+  `DELETE /:id` is the sharp one, twice over. It is the **only** route on this
+  mount with a live caller — `layer-common`'s `useFeedback().deleteFeedback`,
+  wired to the delete button in `FeedbackDetail.vue` and `FeedbackMain.vue`, which
+  every web app draws — and it does not write to the v1 table at all. It writes to
+  `feedbacks2`, the authoritative table every client reads. So the one reachable
+  route on the legacy mount was an unguarded delete against live data. It is now
+  checked against the `feedbacks2` row it actually touches, not the v1 row that
+  happens to share the id.
+
+  All eight routes go through `requireSiteReach`, the rule
+  `/api/manpower-monitoring`, `/api/attendances`, `/api/remarks`,
+  `/api/vehicles`, `/api/documents` and `/api/incident-reports` already use:
+
+  - `GET /site/:site/status/:status` names the site in the URL, so it is checked
+    before the read.
+  - The six record routes name only a record, so the site is read off the
+    **stored** row and a `site` in the caller's own body cannot stand in for it.
+    Two readers are needed, because the two tables are not the same shape: v1
+    `feedbacks` rows keep the site at `metadata.site`, `feedbacks2` rows keep it
+    at the top level.
+  - `POST /` took the author from a `user` cookie the caller writes and never
+    compared it to the session, so a complaint could be filed in somebody else's
+    name. It comes from `callerId(req)` now, which also removes a latent crash:
+    `cookies?.["user"].toString()` short-circuits only on `cookies` being nullish
+    and threw on any request carrying cookies but no `user` cookie.
+
+  `requireSiteReach` matters here because the contracted service provider that
+  answers these complaints holds no membership in the estate's organisation and
+  reaches it through `customer.sites`.
+
+  Not fixed here, and reported separately: `POST /api/feedbacks` cannot succeed
+  and could not before this change either. `feedback.service.ts` replaces
+  `createdBy` with an `ObjectId` and `MFeedback` then re-validates the document
+  against a schema where `createdBy` is `Joi.string().hex()`, so the create always
+  answers 400. No client calls it — every client creates through
+  `/api/feedbacks2`.
+
+- 9a0df17: Scope the incident report routes to the estate the report was written at.
+
+  Every route on `/api/incident-reports` carried `requireAuth` and nothing more, so
+  being signed in anywhere on the platform was enough to page another estate's
+  incident log — complainant name, contact, NRIC, unit, the guard's narrative and
+  the photographs — and to open, rewrite, approve, reject or delete any single
+  report, or file one at any estate.
+
+  All eight now go through `requireSiteReach`, the rule `/api/vehicles`,
+  `/api/documents` and `/api/service-providers` already use:
+
+  - the two lists (`GET /`, `GET /incident-report`) and the two creates
+    (`POST /`, `POST /summary`) name a site in the request; that site is checked
+    before it is used.
+  - the four id routes (`GET /id/:id`, `PUT /id/:id`, `PUT /review/:id`,
+    `PUT /:id`) name only a record, so the site is read off the **stored** record.
+    `PUT /id/:id` carries a `site` of its own in the body, and authorising on that
+    would have let a caller quote their own estate beside another estate's report
+    id — the shape already found on `/api/vehicles`.
+
+  `requireSiteReach` matters more here than anywhere else: a contracted security
+  agency holds no membership in the estate's organisation and reaches its own site
+  through `customer.sites` — and the agency's guards are who **write** these
+  reports. A flat organisation check would have locked them out of their own work.
+
+  A report the caller cannot reach answers exactly as one that does not exist
+  (404), so ids cannot be enumerated from the difference. Guards sit after each
+  handler's Joi validation, so a malformed id still answers 400 exactly as today.
+
+  Note on the count: the route inventory listed six handlers on this mount as
+  unguarded. There are eight, and `POST /` and `GET /` were open too — the
+  controller contains no authorization identifier of any kind at the `staging` tip.
+  All eight are closed here.
+
+  Nothing changes for a permitted caller: same response shape, same fields, same
+  status.
+
+- b62c6a4: Scope the manpower monitoring settings routes to the site they belong to.
+
+  Every route on `/api/manpower-monitoring` carried `requireAuth` and nothing more,
+  so being signed in anywhere on the platform was enough to read another client's
+  shift pattern and alert email recipients, to re-time their late-check-in alert, or
+  to switch their monitoring off entirely — which silences the alert that tells a
+  client nobody turned up for a shift.
+
+  Five of the six now go through `requireSiteReach`, the rule `/api/vehicles`,
+  `/api/documents`, `/api/service-providers` and `/api/incident-reports` already
+  use:
+
+  - `POST /`, `GET /sites/:id/:serviceProviderId` and `POST /multiple` name a site
+    in the request; that site is checked before it is used. `POST /multiple`
+    upserts **by** each item's own `siteId`, so every item is checked before any of
+    them is written.
+  - `PUT /:id` names only a record, so the site is read off the **stored** row —
+    a `siteId` in the caller's own body cannot stand in for it.
+  - `GET /search` names no site at all and returned every client's row on one page.
+    It is narrowed after the read, the way the people and vehicle lookups are.
+
+  `requireSiteReach` matters here because the contracted agency that actually runs
+  these shifts holds no membership in the estate's organisation and reaches its own
+  site through `customer.sites`.
+
+  `GET /sites/active` is deliberately unchanged. It reads nothing from our database
+  — it authenticates to the external HRM Labs directory and returns that system's
+  own site tree — and the only web caller sends a hard-coded service provider id
+  rather than the signed-in one, so scoping it on that id would close the screen for
+  its real users. It needs a product decision, not a guard chosen here.
+
+  A settings row the caller cannot reach answers exactly as one that does not exist,
+  so site ids cannot be enumerated by watching the difference.
+
+- 638320e: Scope the manpower remarks routes to the site the remarks belong to.
+
+  A remarks row is the shift-attendance exception record for one site on one day:
+  which named guards were late or absent, and whether the estate has acknowledged
+  it. Every route on `/api/remarks` carried `requireAuth` and nothing more — the
+  controller held no authorization identifier of any kind — so being signed in
+  anywhere on the platform was enough to read another client's daily manning
+  failures, to write an acknowledgement into their record in a name of the
+  caller's choosing, or to switch a row to `inactive` so the estate's own console
+  stops listing it.
+
+  All five routes now go through `requireSiteReach`, the rule
+  `/api/manpower-monitoring`, `/api/attendances`, `/api/vehicles`,
+  `/api/documents` and `/api/incident-reports` already use:
+
+  - `GET /:id/:serviceProviderId` names the site in the URL, so it is checked
+    before the read.
+  - `PUT /:id` and `PATCH /:id` name only a record, so the site is read off the
+    **stored** row — a `siteId` in the caller's own body cannot stand in for it.
+  - `GET /` names no site at all. Its only filter is a `serviceProviderId` the
+    caller supplies, which is not a claim about the caller, and one agency works
+    for several clients — so the page came back holding every one of those
+    clients' rows. It is narrowed after the read, the way
+    `/api/manpower-monitoring`'s own `GET /search` is. The count in the envelope
+    stays the unfiltered one, as it does there; both callers read it only for the
+    pager.
+  - `POST /` writes a row for whatever `siteId` the body carries. It has no caller
+    in any web app or mobile app — the rows are written internally by
+    `manpower-monitoring.service.ts` when a site's monitoring settings are created
+    — and it is guarded all the same rather than left open.
+
+  `requireSiteReach` matters here because the contracted agency that actually runs
+  these shifts holds no membership in the estate's organisation and reaches its
+  own site through `customer.sites`.
+
+  A row the caller cannot reach answers exactly as one that does not exist, so
+  site ids cannot be enumerated by watching the difference.
+
+- c01b07e: Scope the member list and the member suspend/reactivate write to their own organisation.
+
+  `GET /api/members` took its `org` and `siteId` straight out of the query string,
+  and `PUT /api/members/:id/:status` took the member id straight out of the URL.
+  Both carried `requireAuth` and nothing more. So any signed-in account on the
+  platform could list another client's staff, and suspend or reactivate any member
+  of any client.
+
+  `GET /api/members` also had a hole in its own scope requirement. Line 170 refused
+  a query that named neither an organisation nor a user — **unless**
+  `type === "admin"`, which then listed Seven365's own staff to anybody signed in.
+
+  Both now decide from the session:
+
+  - `type=admin` requires Seven365 staff. That query belongs to the staff console
+    (`web-app-org pages/super-admin`), so it is gated rather than removed.
+  - a caller-supplied `org` is checked with `requireOrgAccess` before it is used —
+    Seven365 staff, or a live member of that organisation.
+  - `user` on its own stays open for the caller's OWN id, because "which
+    organisations am I a member of" is every service app's landing page
+    (`web-app-security pages/index.vue:118` and its siblings). Asking it about
+    somebody else now requires staff.
+  - `PUT /api/members/:id/:status` loads the stored membership and authorises on
+    the organisation recorded on it — never one from the request. A membership with
+    no organisation is a platform staff row, and only Seven365 staff may touch it;
+    a missing org is refused, not waved through.
+
+  Service providers are not special-cased and do not need to be: a provider holds a
+  membership in the organisation whose site it works on — that is how
+  `GET /api/members/user/:id/app/:type?org=` finds its own row at sign-in — so the
+  guard app's member list (`isecure365-mobile-app
+src/features/patrol/use-patrol.ts:180`, which sends `org: site.org` with a
+  `siteId`) passes on the ordinary rule.
+
+  Nothing changes for a permitted caller: same response shape, same fields, same
+  status.
+
+- e76658f: Only Seven365 staff can create a Seven365 staff membership.
+
+  `members.type` decides who is platform staff. `isSuperAdmin` answers true for a
+  live `members` row of type `"admin"` whose role is also of type `"admin"`, and
+  that field was validated as `Joi.string().required()` — a free-form string with
+  no allow-list. Every request path that writes a membership takes the value
+  straight from the caller:
+
+  - `POST /api/members/direct` writes the body's `app` verbatim as `type`
+    (`member.service.ts:137`);
+  - `POST /api/auth/invite` stores the body's `app` on the invitation, and
+    accepting it writes that value as `type` (`member.service.ts:73`);
+  - `PUT /api/members/id/:id/role/:role/type/:type/org/:org` re-pointed a
+    membership at any role, including the seeded platform one, checking only that
+    an owner role existed and that the target was not the last owner — never who
+    was asking.
+
+  All three are `requireAuth`-only. So any signed-in account — a resident, a
+  cleaner, a guard — could post `{ app: "admin" }`, or invite itself as `admin`
+  and accept its own invitation, and be Seven365 platform staff on the next
+  request. That defeats every gate built on `isSuperAdmin`: the staff console,
+  service-provider approvals, the notification broadcast and client suspension.
+  Executed end to end against a throwaway in-memory database, the chain succeeded
+  at every step.
+
+  Three changes, all fail-closed:
+
+  - `members.type` now validates against `MEMBER_TYPES`, enumerated from the
+    values this package actually writes — `admin` (`user.service.ts`
+    `createDefaultUser` and the console's own invitations), `organization` (the
+    default in `member.service.ts`, `user.service.ts`, `user-v2.service.ts` and
+    `subscription.service.ts`), `resident` (`person.service.ts`), and the eight
+    `AppServiceType` service memberships, the same list `organization.model.ts`
+    already accepts as an organisation's `nature`.
+  - `createMemberDirect` refuses `app: "admin"`, and refuses a role of type
+    `"admin"`, unless the caller is already platform staff. The caller is resolved
+    from the session by the controller and passed in; it is never read from a body
+    or a URL.
+  - `createUserInvite` refuses `app: "admin"` unless the caller is already
+    platform staff, so the invitation road to the same place is shut too.
+
+  `updateRoleById` refuses to move a membership onto a role of type `"admin"` for
+  the same reason — that was step 6 of the chain, the one that turned
+  `isPlatformOwner` true by pointing a membership at the seeded owner role.
+
+  The seeded role marker `default: true` was re-checked rather than assumed and is
+  still not forgeable: Joi rejects unknown keys on all three role schemas.
+
+  Every legitimate caller across the sibling repos was checked and still works.
+  `web-app-main pages/sign-in.vue` and `pages/verify/email/index.vue`, and
+  `web-app-org pages/onboarding/getting-started/index.vue`, all pass
+  `app: "organization"` or a service type — none reaches a gate. The one caller
+  that does send `"admin"` is the staff console itself
+  (`web-app-org pages/super-admin/invitations/index.vue:403`), operated by an
+  account that already is staff.
+
+  One transitional case is kept deliberately. `web-app-org
+pages/org/[organization]/invitations/invite.vue:122` and `web-app-hygiene
+pages/[org]/[site]/invitations/invite.vue:135` send the ORGANISATION ID as the
+  invitation's `app`, so accepting one of those invitations writes an org id into
+  `members.type`. That is a defect in those two screens, but it is live: the
+  validator therefore also accepts a 24-character hex string, with the two file
+  references named at the line, to be removed once both screens send a real
+  membership type. It cannot be used to escalate — `"admin"` is not 24 hex
+  characters, so the allow-list still decides that.
+
+  No response shape, status code or field changed for a permitted caller.
+
+- 43dc4bc: Scope the three remaining `/api/members` writes to the membership they name.
+
+  `PUT /api/members/id/:id/role/:role/type/:type/org/:org`,
+  `PUT /api/members/site` and `PUT /api/members/:id/onboarding/complete` all
+  carried `requireAuth` and nothing more, and each took the membership id straight
+  out of the request.
+
+  **The role write is the sharp one.** A role IS the permission set, so
+  re-pointing a membership at another role is an access grant. The service already
+  refused to hand a _Seven365 staff_ role to a non-staff caller, but a **tenant**
+  role was still free: quoting another client's membership id re-pointed it at any
+  of that client's roles, their **owner** role included — and equally could demote
+  that client's own admin. The `org` in the URL was also what the service used to
+  look up owner roles for its "last owner" precondition, so a mismatched one ran
+  that safety check against the wrong client's roles entirely.
+
+  `PUT /api/members/site` took the membership id **and** the target site from the
+  body, so nothing said whose membership, or whose site, either one was — any
+  signed-in account could move any client's member onto any estate.
+
+  `PUT /api/members/:id/onboarding/complete` took the id from the URL and nothing
+  else, so any signed-in account could mark any client's membership onboarded and
+  skip that client's onboarding gate.
+
+  All three now decide from the **stored** membership, through the
+  `requireMemberOrg` helper this controller already uses for
+  `PUT /api/members/:id/:status`:
+
+  - the organisation recorded on the membership is authorised with
+    `requireOrgAccess` — Seven365 staff, or a live member of that organisation.
+  - a membership with **no** organisation is a platform staff row; only Seven365
+    staff may touch it. A missing org is refused, not waved through.
+  - the role write additionally refuses when the `org` in the URL disagrees with
+    the one on the membership, so the service's owner-role lookup can no longer be
+    pointed at another client.
+  - `PUT /api/members/site` puts the incoming site through `requireSiteReach`, the
+    same rule `/api/vehicles` and `/api/documents` use, so a member cannot be moved
+    onto an estate the caller cannot reach. An unreachable site answers as one that
+    does not exist (404), so site ids cannot be enumerated from the difference.
+
+  Guards sit **after** each handler's Joi validation, so a malformed id still
+  answers 400 exactly as it does today.
+
+  Scope note — deliberately NOT changed here: the four read-by-user routes
+  (`GET /api/members/user/:id`, `/users/:id`, `/user/:id/app/:type`,
+  `/user/:id/app/:type/org`). `layer-common ServiceProviderMain.vue:922,1320` and
+  `InvitationClientForm.vue:324` legitimately read the memberships of a user who
+  belongs to a **service provider's** organisation, not to the caller's, and no
+  existing helper expresses "an organisation my organisation has engaged". That
+  needs a product decision rather than a guess. Every other caller passes its own
+  user id. `POST /api/members/direct` and `POST /api/members/verification/:id` are
+  also unchanged — the latter is driven entirely by a single-use, expiring
+  invitation record and grants the caller nothing.
+
+  Nothing changes for a permitted caller: same response shape, same fields, same
+  status.
+
+- 5a46062: Scope the NFC patrol log routes to the estate the round was walked at, and take
+  the author from the session.
+
+  An NFC patrol log is the proof that a round was actually walked: the route, the
+  day, each checkpoint the guard tapped a tag against, the ones that were skipped
+  and why, and the signature that closes the round off. It is the document a
+  client is shown when they ask whether their estate was patrolled.
+
+  Every route on `/api/nfc-patrol-log` carried `requireAuth` and nothing more, and
+  `nfc-patrol-log.controller.ts` held no authorization identifier of any kind.
+  `requireAuth` proves a session exists; it makes no organisation or site
+  decision. So being signed in anywhere on the platform was enough to read another
+  client's patrol history, **mark a checkpoint on another estate's round as
+  completed**, or **sign that round off as done** — falsifying the patrol proof,
+  not merely reading it.
+
+  All five handlers now decide before any work is done. The route count was
+  verified at the registration site — `nfc-patrol-log.route.ts` mounts **five**
+  routes, not the four the earlier inventory recorded.
+
+  - `POST /` and `GET /` already REQUIRE a site (`schemaCreateNfcPatrolLog` and
+    the query schema both have `site` required), so the guard checks a site the
+    request already names and no caller's contract changes. The repository does
+    genuinely apply that `site` — it is the first term of the aggregation match,
+    not a parameter it accepts and ignores.
+  - `PATCH /:id/checkpoint`, `GET /:id` and `PATCH /:id/sign` name only a record,
+    so the site is read off the STORED log through `requireNfcPatrolLogReach`.
+    `getById` on this repository is NOT cached, so no separate raw reader was
+    needed here, unlike the occurrence mounts.
+  - `POST /`'s `createdBy` came from the request body and was never compared to
+    the session. It comes from `callerId(req)` now. The field is still accepted,
+    so no caller starts to 400; it is simply ignored.
+
+  None of the three record routes can MOVE a log: `updateCheckpoint` sets only the
+  checkpoint fields and `sign` sets only the signature fields, so there is no
+  destination to check.
+
+  The rule is the existing one, `requireSiteReach` -> `entitleSite`. The
+  `customer.sites` branch is load-bearing here more than on any other mount: the
+  people who walk these rounds are the contracted security agency's guards and
+  hold no membership in the estate's own organisation.
+
+  `GET /:id` previously answered **200 with `null`** for an id matching nothing,
+  because the handler passed the repository's `null` straight to `res.json`. It
+  now refuses — a log that does not exist has no site, and `requireSiteReach`
+  refuses a missing site.
+
+  Sibling mounts on the same family — `/nfc-patrol-tag`, `/nfc-patrol-settings`,
+  `/nfc-patrol-route` and `/patrol-routes` — are NOT touched here. The first three
+  carry `/public` routes behind `requireSessionOrLegacyToken`, which is inert
+  while `ENFORCE_NFC_PUBLIC_AUTH` is off, so guarding their shared handlers would
+  refuse a live legacy screen. That needs the SEC-028 decision first.
+
+- ef9a540: Scope the daily occurrence book routes to the estate the book belongs to.
+
+  The daily occurrence book is one estate's security log for one day — the record
+  the guards write every shift, and the record an estate is asked to produce when
+  something goes wrong. Every route on `/api/occurrence-books` carried
+  `requireAuth` and nothing more, and `occurrence-book.controller.ts` held no
+  authorization identifier of any kind. `requireAuth` proves a session exists; it
+  makes no organisation or site decision. So being signed in anywhere on the
+  platform was enough to read another client's log, re-date it, re-open or close
+  it, or delete the day outright.
+
+  All five handlers now decide before any work is done. The route count was
+  verified at the registration site — `occurrence-book.route.ts` mounts **five**
+  routes, not the three the earlier inventory recorded.
+
+  - `POST /` and `GET /` already REQUIRE a site (in the body and the query
+    respectively), so the guard checks a site the request already names and no
+    caller's contract changes.
+  - `GET /id/:id`, `PUT /id/:id` and `DELETE /id/:id` name only a record, so the
+    site is read off the STORED row through the new `requireOccurrenceBookReach`.
+    A `site` in the caller's own body or query cannot stand in for it.
+
+  `requireOccurrenceBookReach` is built on a new raw reader,
+  `getRawOccurrenceBookById`. The existing `getOccurrenceBookById` is CACHED and
+  throws `NotFoundError`, so a reach check built on it would have decided who may
+  touch a book from a cache entry, and would have answered 404 with the wrong
+  message before the guard ever ran.
+
+  The rule is the existing one, `requireSiteReach` -> `entitleSite`, already used
+  by `/api/feedbacks`, `/api/work-orders`, `/api/manpower-monitoring`,
+  `/api/attendances`, `/api/remarks`, `/api/vehicles`, `/api/documents` and
+  `/api/incident-reports`. The `customer.sites` branch is load-bearing here: the
+  guards who WRITE this book are the contracted security agency's staff and hold
+  no membership in the estate's own organisation, so a flat organisation check
+  would lock the security app out of the log it exists to keep.
+
+  Each guard sits AFTER the handler's own Joi validation, so a malformed id still
+  answers 400 exactly as before. A row that does not exist has no site, and
+  `requireSiteReach` refuses a missing site, so an id matching nothing is refused
+  rather than falling through.
+
+  `PUT /id/:id` cannot MOVE a book — `schemaUpdateOccurrenceBook` does not accept
+  `site` at all — so there is no destination to check.
+
+  `/api/occurrence-entries` and `/api/occurrence-subjects` are separate mounts and
+  are not touched here; each gets its own change.
+
+- cb7bcd3: Scope the occurrence entry routes to the estate the entry belongs to.
+
+  An occurrence entry is a single line the guards write into an estate's daily
+  security log — the time, the subject, the free-text account of what happened, the
+  signature of the guard who wrote it, and any incident report attached to it.
+  Every route on `/api/occurrence-entries` carried `requireAuth` and nothing more,
+  and `occurrence-entry.controller.ts` held no authorization identifier of any
+  kind. `requireAuth` proves a session exists; it makes no organisation or site
+  decision. So being signed in anywhere on the platform was enough to read another
+  client's log line by line, rewrite what an entry says, or delete an entry from
+  the record.
+
+  All six handlers now decide before any work is done. The route count was
+  verified at the registration site — `occurrence-entry.route.ts` mounts **six**
+  routes, not the four the earlier inventory recorded.
+
+  - `POST /` and `GET /` already REQUIRE a site (in the body and the query
+    respectively), so the guard checks a site the request already names and no
+    caller's contract changes.
+  - `GET /id/:id`, `PUT /id/:id` and `DELETE /id/:id` name only a record, so the
+    site is read off the STORED row through the new `requireOccurrenceEntryReach`,
+    built on a new raw reader `getRawOccurrenceEntryById` (the existing
+    `getOccurrenceEntryById` is CACHED).
+  - `GET /count/bookId/:id` is the one shape not seen on the earlier mounts: the
+    id identifies a **book**, not an entry. Its scope therefore comes from the
+    BOOK's row, through `requireOccurrenceBookSiteReach`.
+
+  That last one matters. Deriving reach from "some entry carrying this book id"
+  would have refused the FIRST entry of every new day, because a freshly opened
+  book has no entries to read — the security app calls this route to work out the
+  next serial number before writing that first line. There is a regression case
+  for exactly that.
+
+  `requireOccurrenceBookSiteReach` deliberately uses the book repository's
+  ordinary (cached) reader. A book's `site` is immutable — no route on
+  `/api/occurrence-books` accepts `site` on update — so a cached row cannot carry
+  a site that differs from the stored one, and the usual objection to deciding
+  reach from a cache does not apply here.
+
+  The rule is the existing one, `requireSiteReach` -> `entitleSite`. The
+  `customer.sites` branch is load-bearing: the guards who WRITE these entries are
+  the contracted security agency's staff and hold no membership in the estate's
+  own organisation.
+
+  Each guard sits AFTER the handler's own Joi validation, so a malformed id still
+  answers 400 exactly as before. A row that does not exist has no site, and
+  `requireSiteReach` refuses a missing site, so an id matching nothing is refused
+  rather than falling through.
+
+  `PUT /id/:id` cannot MOVE an entry — `schemaUpdateOccurrenceEntry` does not
+  accept `site` at all — so there is no destination to check.
+
+  `/api/occurrence-books` and `/api/occurrence-subjects` are separate mounts and
+  are not touched here; each gets its own change.
+
+- 60049e1: Scope the occurrence subject routes to the estate the subject belongs to, and
+  take the author from the session.
+
+  An occurrence subject is one of the named headings the guards pick from when
+  they write a line into an estate's daily security log — "Lift breakdown",
+  "Trespasser", "Fire alarm". The list belongs to one site. Every route on
+  `/api/occurrence-subjects` carried `requireAuth` and nothing more, and
+  `occurrence-subject.controller.ts` held no authorization identifier of any kind.
+  `requireAuth` proves a session exists; it makes no organisation or site
+  decision. So being signed in anywhere on the platform was enough to read another
+  client's subject list, add a heading to it, rename one, or delete one out from
+  under the guards who are picking from it.
+
+  Two defects, not one:
+
+  1. **No scope.** All five handlers now decide before any work is done. The route
+     count was verified at the registration site — `occurrence-subject.route.ts`
+     mounts **five** routes, not the three the earlier inventory recorded.
+  2. **Identity from the caller's body.** `POST /` took `addedBy` straight out of
+     the request body and never compared it to the session, so a heading could be
+     filed under somebody else's name. It comes from `callerId(req)` now. The
+     shipped mobile client's own comment records the old behaviour — "`addedBy` is
+     sent because the model stores it; the server does not take it from the
+     session". Same defect already fixed on `/api/attendances`,
+     `/api/site-entrypass-settings` and `/api/feedbacks`.
+
+  - `POST /` and `GET /` already REQUIRE a site (`schemaOccurrenceSubject` and the
+    query schema both have `site` required), so the guard checks a site the
+    request already names and no caller's contract changes.
+  - `GET /id/:id`, `PUT /id/:id` and `DELETE /id/:id` name only a record, so the
+    site is read off the STORED row through the new
+    `requireOccurrenceSubjectReach`, built on a new raw reader
+    `getRawOccurrenceSubjectById` (the existing `getOccurrenceSubjectById` is
+    CACHED, so a guard built on it would decide reach from a cache entry).
+
+  `GET /`'s `site` is genuinely applied by the repository — it is part of the
+  `baseQuery` and of the cache key — so the list needed a reach check on the site
+  it names, not a narrowing pass after the read.
+
+  The rule is the existing one, `requireSiteReach` -> `entitleSite`. The
+  `customer.sites` branch is load-bearing: the guards who maintain this list are
+  the contracted security agency's staff and hold no membership in the estate's
+  own organisation.
+
+  Each guard sits AFTER the handler's own Joi validation, so a malformed id still
+  answers 400 exactly as before. A row that does not exist has no site, and
+  `requireSiteReach` refuses a missing site, so an id matching nothing is refused
+  rather than falling through.
+
+  `PUT /id/:id` cannot MOVE a subject — `schemaUpdateOccurrenceSubject` accepts
+  only `_id` and `subject` — so there is no destination to check.
+
+  This closes the occurrence-book family: `/occurrence-books`,
+  `/occurrence-entries` and `/occurrence-subjects`.
+
+- 1e93185: Scope the organisation lookups so they stop mapping one client to another.
+
+  Four reads on `/api/organizations` carried `requireAuth` and nothing more, and
+  every one took its key straight from the URL:
+
+  - `GET /api/organizations/user/:user` — which organisations ANY person belongs to
+  - `GET /api/organizations/orgs/:email` — the same, keyed on ANY email address
+  - `GET /api/organizations/name/:name` — any organisation, by name
+  - `GET /api/organizations/email/:email` — any organisation, by email address
+
+  Together those are a cross-client directory and an account-enumeration oracle: a
+  resident of one estate could map which clients an address or a user id belongs
+  to across the whole platform.
+
+  Each is now decided from the session:
+
+  - `user/:user` — the caller's own id, or Seven365 staff. Every live caller asks
+    about itself: the seven service-provider app layouts, the org app, and the
+    resident mobile app all pass the signed-in user's own id.
+  - `orgs/:email` — the caller's own address, compared case-insensitively after
+    being resolved from the session, or Seven365 staff. All three live callers
+    pass the signed-in user's own address.
+  - `name/:name` — Seven365 staff. Its only caller is the staff console's client
+    list.
+  - `email/:email` — Seven365 staff. No caller exists in any repository in the
+    organisation.
+
+  A key that does not exist is refused exactly as one that does, so the refusal
+  itself is not an oracle.
+
+  `GET /api/organizations/id/:id` is deliberately NOT guarded here: the same
+  controller function is mounted a second time, unauthenticated, at
+  `/api/organizations/org/id/:id`, which the sign-up-invite screens call before an
+  account exists. Guarding the handler would guard both mounts and break
+  registration. That one needs the alias split first.
+
+  `GET /api/organizations/` (the full client list) is also unchanged and is
+  recorded as a decision for the leads: it is reached from a live signup path that
+  must move onto the organisation `POST /api/organizations/onboarding` already
+  returns before the list can be staff-gated.
+
+- 07ff8c9: Scope `GET /api/people` to a site the caller can actually reach.
+
+  The endpoint returns resident and visitor records — name, NRIC, contact number,
+  unit, plate numbers — and filters on NRIC, contact and plate number. It carried
+  `requireAuth` and nothing more, and took its `org` and `site` from the query
+  string (`person.controller.ts:79-80, 93`). So any signed-in account on the
+  platform could page through another estate's residents, or look a person up by
+  NRIC across every client at once.
+
+  The caller is now resolved from the session and the scope decided before
+  anything is read:
+
+  - a named `site` is checked with `entitleSite` — the same site-reach rule the
+    camera and HID modules already use: a membership at the site, an org-wide
+    membership at the site's owning organisation, or an ACTIVE `customer.sites`
+    engagement. Reusing it matters rather than being tidy: an agency contracted to
+    an estate holds no membership in that estate's organisation, so an
+    org-membership check would have locked every guard out of the site they work
+    at. A site the caller cannot reach answers exactly as a site that does not
+    exist, so site ids cannot be enumerated.
+  - a named `org` is checked against the caller's own memberships.
+  - naming neither — the NRIC, contact and plate lookups — is narrowed to the
+    caller's own organisations instead of searching the whole platform.
+  - Seven365 staff keep cross-tenant reach, unchanged.
+
+  Every live caller passes a site: `layer-common` `VisitorForm.vue`,
+  `MemberInformation.vue` and `VehicleForm.vue` all pass the site the screen is
+  open on, and the People list passes org and site from its route. The two
+  composable functions that pass neither — `usePeople().findPersonByContact` and
+  `findUsersByPlateNumber` — have no caller in any repository.
+
+  `person.repo.getAll` gains an optional `orgs` filter for the last case. It
+  applies only when no explicit `org` was given, so it cannot fight one, and its
+  absence means "no restriction", which is what staff get.
+
+  No response shape, status code or field changed for a permitted caller.
+
+- edae7cb: Scope the single-value people lookups to a site the caller can reach.
+
+  Seven endpoints on `/api/people` carried `requireAuth` and nothing else and were
+  not scoped at all:
+
+  | Route                           | What it answered                                  |
+  | ------------------------------- | ------------------------------------------------- |
+  | `GET /nric/:nric`               | a `findOne` on NRIC across the **whole platform** |
+  | `GET /contact/:contact`         | the same, on contact number                       |
+  | `GET /plateNumber/:plateNumber` | every person with that plate, anywhere            |
+  | `GET /unit/:unit`               | every person at that unit id                      |
+  | `GET /user/:userId`             | the person record behind any user id              |
+  | `GET /company`                  | company names aggregated across every client      |
+  | `GET /all-nric`                 | a paged NRIC list at a caller-named site          |
+
+  So any signed-in account could type an NRIC or a car plate and read the matching
+  resident of any estate — name, unit, contact number, plates. #1907 scoped the
+  paged list (`GET /api/people`); these are the lookups beside it.
+
+  None of them takes a site — `layer-common usePeople.findPersonByNRIC`,
+  `searchCompanyList` and `getPeopleByUnit` pass only the value being looked up —
+  so the scope is decided **after** the read, on the record, with the same
+  site-reach rule the camera, HID and people-list already use. A record the caller
+  cannot reach is left out, which for these endpoints is exactly what "no such
+  person" already looked like: `null`, or an empty list. **No client sees a new
+  response shape or a new status code.** `entitleSite` is asked once per distinct
+  site, not once per record.
+
+  `/all-nric` requires a site in the query, so that one is checked before the read
+  and answers `404` for a site the caller cannot reach — the same answer a site
+  that does not exist gives, so ids cannot be probed.
+
+  `/company` has no site or unit to scope on, so it is narrowed to the caller's
+  own organisations — the fallback `getAll` already uses. `person.repo.getCompany`
+  gains an optional `orgs` filter; absent means no restriction, which is what
+  Seven365 staff get.
+
+  `GET /user/:userId` also always answers about **your own** record, whatever your
+  memberships say: the resident app reads it during sign-up and when resubmitting
+  a rejected registration.
+
+- 6526669: Scope the resident and visitor WRITES to a site the caller can actually reach.
+
+  `PUT /api/people/id/:id` (edit), `PUT /api/people/:id` (delete),
+  `PATCH /api/people/:id` (approve / reject / ask to resubmit) and the exported
+  `suspendResidentById` identify the person by an id in the URL and carried
+  `requireAuth` and nothing more. Any signed-in account on the platform — a
+  resident, a cleaner, a guard at a different estate — could rename, delete,
+  approve or reject any other client's resident. #1907 closed the read
+  (`GET /api/people`); these are the writes behind it.
+
+  The scope is resolved from the **stored record**, never from the request, and
+  that is not a stylistic choice: **not one live caller sends a site.**
+  `layer-common usePeople.deleteById` sends no body at all,
+  `reviewResidentPerson` sends only `{ status, remarks }`, and both
+  `web-app-property-management pages/[org]/[site]/people-mgmt/index.vue:915-917`
+  and `components/PeopleFormMgmt.vue:618-620` explicitly `delete payload.site`
+  before calling `updateById`. A guard that read the site out of the body would
+  have refused every real caller and protected nobody.
+
+  The rule is the site-reach rule the camera, HID and people-list already use —
+  membership of the site, an org-wide membership at the site's owner, or an active
+  `customer.sites` engagement — so an agency contracted to an estate keeps
+  working. A record carrying an organisation but no site falls back to that
+  organisation. Seven365 staff are unchanged.
+
+  A resident resubmitting their own registration from the mobile app still works:
+  `person.service.ts:155-166` writes a `members` row pinned to the site at
+  sign-up, before any approval, so a rejected resident still reaches their own
+  site. There is an end-to-end case for exactly that.
+
+  Also: **who approved a resident now comes from the session.** It was read out of
+  the `user` cookie the browser sends, falling back to whatever `approvedBy` the
+  request body claimed, so an approval could be attributed to anybody. No caller
+  sends `approvedBy`, so nothing is lost.
+
+- c7f368b: Pin what a logged-out caller may set on the resident sign-up.
+
+  `POST /api/people/resident/create` (`person.route.ts:37`) has no guard, and it
+  shares the `add` handler with the guarded `POST /api/people/`. The handler
+  spread the request body into `schemaPerson` and inserted it.
+
+  `site.people` is the collection every site-reach decision on the platform reads
+  its verdict from. On that schema `status` was a free-form string, and `_id`,
+  `user`, `approvedBy`, `type`, `site` and `org` were all caller-supplied. So an
+  anonymous caller could insert an APPROVED row at any client's site, pointing at
+  an account they control, and be reachable into that estate from then on. That is
+  the manufacture-access path, not a theoretical one.
+
+  It cannot be closed with a session check: the only caller anywhere in the
+  organisation is the resident app's registration wizard
+  (`app/(auth)/createUser.tsx:449`), which by definition has no session yet. So
+  the route is field-pinned instead.
+
+  With no session the body is now validated against a new
+  `schemaResidentSelfSignUp` — an explicit ALLOW-list of exactly what
+  `createUser.tsx` sends, with `stripUnknown`, so `_id`, `user`, `approvedBy` and
+  anything else are dropped rather than written. Two fields are then set
+  server-side rather than accepted:
+
+  - `status` is forced to `"pending"`, the literal the wizard hard-codes at
+    `createUser.tsx:151` and re-sets at `:237`.
+  - `platform` is forced to `"mobile"`. This matters as much as `status`:
+    `person.service.ts:130` reads it to decide whether the USER ACCOUNT it creates
+    starts `"pending"` or `"active"`, so a caller who sent `platform: "web"` got a
+    live account with nobody reviewing them.
+
+  `type` is narrowed to `resident` or `tenant` — the only two the wizard derives
+  (`createUser.tsx:441`) — with `.valid(...)` and `.trim().lowercase()`, never
+  `.allow(...)`, which accepts any non-empty string and would restrict nothing.
+  This closes the `user` hole properly: the service only overwrites a
+  caller-supplied `user` on the resident/tenant branch, so sending
+  `type: "contractor"` was what left a nominated `user` standing.
+
+  The guarded `POST /api/people/` is UNCHANGED and still accepts the full
+  `schemaPerson` — staff legitimately create contractors and visitors, set their
+  own statuses, and record `approvedBy`.
+
+  `site`, `org`, `block`, `level`, `unit`, `isOwner`, `email`, `password`, `name`,
+  `nric`, `contact` and the files are NOT pinnable: a genuine self-registration
+  chooses its own estate and unit, so pinning any of them would block real
+  residents.
+
+  Covered by `test/e2e/resident-self-signup-pinning.e2e.test.mjs`. Both create
+  routes are now mounted in the e2e harness, mirroring `person.route.ts`.
+
+- f6cd1b9: Scope role writes to the role's own organisation, and reserve platform roles for Seven365 staff.
+
+  Every write on `role.controller.ts` carried `requireAuth` and nothing more, and
+  the role id comes from the URL. So any signed-in account on the platform — a
+  resident, a cleaner, a guard — could reach any organisation's roles:
+
+  - `PATCH /api/roles/permissions/id/:id` rewrote another client's role, including
+    its owner role. Executed against a throwaway database during the audit, an
+    outsider rewrote a second organisation's owner role and got a 200.
+  - `PATCH /api/roles/id/:id` renamed it and replaced its permissions.
+  - `PUT /api/roles/deleted/role` and `PUT /api/roles/:id/delete-with-reassignments`
+    deleted it, the second one moving its members onto other roles on the way.
+  - `GET /api/roles/:id/deletion-preview` listed the members holding it — another
+    client's staff list by another name.
+  - `POST /api/roles` and `POST /api/roles/v2` minted a role of `type: "admin"` —
+    the half of `isSuperAdmin` that lives in the roles collection.
+
+  Each of the five writes now loads the role first and authorises on the
+  organisation stored ON THAT ROLE, never on one the caller supplied:
+
+  - a role carrying an `org` is a tenant's, and goes through `requireOrgAccess` —
+    Seven365 staff, or a live member of that organisation. That is the rule the
+    invitation and subscription paths already use; no new mechanism is introduced.
+  - a role with NO `org` is a platform role — the staff console's own, and the one
+    `createDefaultUser` seeds — and only Seven365 staff may touch it. A missing org
+    is refused, not waved through.
+
+  `createRole` on both `/api/roles` and `/api/roles/v2` requires the caller to be
+  platform staff before it will accept `type: "admin"`. `/api/roles/v2` is a
+  separate mount onto a separate controller, so gating one and not the other would
+  have left the hole reachable by adding `/v2` to the URL.
+
+  A role the caller may not reach is reported the same as a role that does not
+  exist, so role ids cannot be enumerated by watching the difference.
+
+  Two things are deliberately NOT changed, and are asserted in the tests so they
+  read as decisions rather than oversights. `createRole` is not scoped to the
+  caller's own organisation, and neither are the role reads: `web-app-main
+pages/sign-in.vue:311,439` and `pages/verify/email/index.vue:474` look up and
+  create the "Admin Service Provider" role in the INVITING organisation, which the
+  caller has not joined yet — that is what accepting a service-provider invitation
+  is, and an org-membership check there would break sign-in for every invited
+  provider. Scoping those needs the invitation to be consulted as well as the
+  membership, and is a separate change.
+
+  Every legitimate caller was checked and still works: the tenant screens
+  (`web-app-org pages/org/[organization]/roles-permissions.vue`, and the
+  `[org]/[site]/roles-permissions` screens in hygiene, security and
+  property-management, all through `layer-common RolePermissionMain.vue` and
+  `RolePermissionFormPreviewUpdate.vue`) edit roles in an organisation the operator
+  is a member of; the staff console (`web-app-org pages/super-admin/*` and the
+  retired admin app) is operated by staff and keeps cross-tenant reach.
+
+  No response shape or field changed for a permitted caller.
+
+- 4de4685: Scope the service provider record routes to the site the engagement works on.
+
+  A `site.service-providers` row is an ENGAGEMENT: a provider organisation attached
+  to one client's site. Two routes took its id straight out of the URL with
+  `requireAuth` and nothing more, so any signed-in account could use them against
+  any client:
+
+  - `GET /api/service-providers/:id` returned any client's engagement — provider
+    name, category, contact email and the site it works on.
+  - `PATCH /api/service-providers/:id/status` suspended or reactivated it.
+    Suspending an engagement stops that provider's guards and cleaners reaching the
+    estate; reactivating one puts them back.
+
+  Both now decide from the **site stored on the row**, through the existing
+  `requireSiteReach` rule that `/api/vehicles` and `/api/documents` already use.
+  That rule admits both sides of the engagement: the client, and the contracted
+  provider whose reach comes from `customer.sites` rather than from a membership in
+  the client's organisation.
+
+  An engagement the caller cannot reach answers exactly as one that does not exist
+  (404), so ids cannot be enumerated from the difference. A row carrying no site at
+  all is refused, not waved through. Guards sit after each handler's Joi
+  validation, so a malformed id or status still answers 400 exactly as today.
+
+  Scope note — deliberately NOT changed here: the four list routes
+  (`GET /api/service-providers`, `/name`, `/category`,
+  `/org/:serviceProviderOrgId/type/:type`) and `GET /provider/:provider/org/:org`.
+  Their `orgId`, `siteId` and `serviceProviderOrgId` are optional filters the
+  caller sends, and `layer-common useServiceProvider.ts` defaults every one of them
+  to an empty string, so it is not yet established which callers depend on the
+  unfiltered list. That is the same open question as the site-less
+  `GET /api/vehicles` and needs a product decision rather than a guess.
+
+  Nothing changes for a permitted caller: same response shape, same fields, same
+  status.
+
+- 89c3640: Scope the entry pass settings routes to their site, and take the writer's
+  identity from the session.
+
+  These rows decide how a site issues visitor passes: whether passes are on at
+  all, whether a physical or NFC pass is used, which USB printer model the
+  gatehouse drives, and the header, disclaimer and URL printed on the pass a
+  visitor is handed at the gate. All seven routes on
+  `/api/site-entrypass-settings` carried `requireAuth` and nothing more — the
+  controller held no authorization identifier of any kind.
+
+  Two defects were fixed, not one.
+
+  **No scope.** `GET /` returned every row on the platform: it accepts `org` and
+  `site` query parameters and the repository never applies them, so a filter that
+  looked like scoping was not one. The record routes took an id and no site.
+  `GET|PUT /site/:site` took a site straight off the URL. All seven now go through
+  `requireSiteReach`, the rule `/api/access-management`,
+  `/api/manpower-monitoring`, `/api/attendances`, `/api/vehicles`,
+  `/api/documents` and `/api/incident-reports` already use:
+
+  - `POST /` and `GET|PUT /site/:site` name a site in the request; it is checked
+    before it is used.
+  - `GET|PUT|DELETE /:id` name only a record, so the site is read off the
+    **stored** row — a `site` in the caller's own body cannot stand in for it.
+  - `PUT /:id` and `PUT /site/:site` can also **move** a row, because the body's
+    `site` is `$set`, so the destination is checked as well as the origin.
+  - `GET /` is narrowed after the read. It cannot be narrowed in the repository:
+    the page is cached under a key built only from page/limit/status/sort, so a
+    per-caller filter there would be served to the next caller. The count in the
+    envelope stays the unfiltered one, as it does on the sibling lists.
+
+  **The writer's identity came from a cookie the caller writes.** `add`,
+  `updateEntryPassSettingsById` and `updateEntryPassSettingsBySiteId` each parsed
+  the raw `Cookie` header for a `user` value and stored it as `createdBy` /
+  `updatedBy` without ever comparing it to the session, so the audit trail on
+  these rows was whatever the caller typed. It now comes from `callerId(req)`.
+  That also removes a latent crash: `cookies?.["user"].toString()` short-circuits
+  only on `cookies` being nullish, so any request carrying cookies but no `user`
+  cookie called `.toString()` on `undefined` and threw.
+
+  `requireSiteReach` matters here because the contracted agency that runs the
+  gatehouse holds no membership in the estate's organisation and reaches its own
+  site through `customer.sites`.
+
+  Nothing on this mount has a live caller: `layer-common`'s
+  `useSiteEntryPassSettings` binds only `GET /:id` and no component calls it, and
+  the entry-pass screens read and write `/api/access-management/settings`, a
+  different mount over a different collection. The routes are guarded rather than
+  removed; whether this mount should exist at all is a product decision.
+
+- 67969e9: Scope `/api/sites` to the organisation that owns the site.
+
+  Every route on this router except the pre-login resident picker carried
+  `requireAuth` and nothing more (`site.controller.ts`), and took the
+  organisation from the query string or the site id from the URL. `requireAuth`
+  proves a session exists and makes no organisation or site decision, so any
+  signed-in account on the platform — a resident, a cleaner, an agency guard —
+  could `DELETE /api/sites/:id` any site belonging to any client, rename it,
+  re-block it, move its guard posts, rewrite its information page, create a site
+  inside any organisation, and page through any client's estate list.
+
+  The caller is now resolved from the session and the decision made before
+  anything is read or written:
+
+  - `POST /` uses `requireOrgAccess` on the body's `orgId` — that is where the new
+    site lands.
+  - `GET /` uses `requireOrgAccess` on the `org` filter the caller sends.
+  - `PUT /:id/block`, `PATCH /id/:id`, `PATCH /guard-post/id/:id`,
+    `PATCH /information/id/:id` and `DELETE /:id` use `entitleSite` — a
+    membership pinned to the site, an org-wide membership at the site's owning
+    organisation, or an ACTIVE `customer.sites` engagement. The engagement branch
+    is required, not incidental: Site Settings lives in the SERVICE-PROVIDER apps
+    (`web-app-security` and the five module apps, each
+    `pages/[org]/[site]/settings.vue` via `layer-common useSiteSettings.ts`), and
+    those users hold no membership in the estate's organisation at all.
+  - `GET /:id` is deliberately one notch wider than the writes: it also passes
+    for any live membership in the site's OWNING organisation. Three shipped
+    mobile clients read this route, and the resident app reads
+    `org.defaultSite` — which in a multi-site organisation need not be the
+    resident's own site, and a resident's membership carries a `siteId`. The
+    wider read closes the cross-CLIENT read, which is the defect, and leaves
+    site-to-site partitioning inside one client where it is today.
+
+  A site the caller cannot reach answers exactly as a site that does not exist,
+  so site ids cannot be enumerated by watching the difference.
+
+  `GET /site/resident` is unchanged and still pre-login: the resident mobile app
+  needs a site picker before an account exists.
+
+  No new authorization mechanism is introduced — `requireOrgAccess` and
+  `entitleSite` are the helpers the member, role, people, camera and HID paths
+  already use.
+
+- d27ed16: Stop the e-mail account lookup handing out the password hash and session id.
+
+  `GET /api/users/user/:email` (`user.route.ts:25`) has no guard on it at all, and
+  `GET /api/users/email/:email` next to it is the same handler behind
+  `requireAuth`. Both answered `res.json(user)` on the raw stored document, and
+  the users collection stores `password` — the hash — and `sid` — that account's
+  CURRENT session id.
+
+  So anyone at all, with no session, who knew or guessed an e-mail address got
+  that account's password hash back in the response body, to crack offline at
+  leisure, plus a live session id to reuse. On the authenticated twin, any signed
+  in account could read the same two fields for any other account, including an
+  administrator's.
+
+  The unguarded route cannot simply be guarded. Its only callers anywhere in the
+  organisation are pre-login signup screens — the resident app's e-mail check
+  (`user-registration.ts:103`) and the four `web-app-main/pages/sign-up-invite/*`
+  pages through `layer-common`'s `getUserByEmailV2` — so a session check would
+  break registration. The fix is therefore not authentication, it is not handing
+  out more than signup asks for.
+
+  All five of those callers read NO field off the reply. The mobile check does
+  `res !== null`; the four web pages do `if (response)`. So without a session the
+  handler no longer loads the document: a new `userExistsByEmail` does a
+  `findOne` with an explicit allow-list projection of `_id` alone and returns a
+  boolean, and the route answers `{ exists: true }` or `null` exactly as before.
+  An allow-list, deliberately — a deny-list would silently start leaking the next
+  credential-shaped field somebody adds to the collection.
+
+  `getUserByEmail` itself is UNCHANGED and still returns the whole document,
+  because signing in genuinely needs the hash to compare against. Putting the
+  projection on that function instead of beside it would have broken every login.
+
+  With a session the reply keeps its existing shape, minus `password` and `sid`,
+  via a small `withoutCredentials`. `_id` is the only field its callers read
+  (`web-app-main pages/verify/email`, `web-app-org onboarding/getting-started`)
+  and it survives. That path is narrowed by removal rather than by allow-list on
+  purpose: it is consumed by screens across web and mobile that cannot all be
+  enumerated from here, and removing two credential fields cannot break a
+  legitimate one, because no screen renders a password hash or a session id.
+
+  The v2 twin `GET /api/users/v2/email/:email` had the same leak — it is behind
+  `requireAuth`, so it was never anonymous, but "signed in" is not "entitled to
+  another account's credentials" — and is stripped the same way. v2 has no
+  anonymous `/user/:email` route and no pre-login caller.
+
+  Covered by `test/e2e/user-email-lookup-leak.e2e.test.mjs`, which asserts on the
+  absence of the key and never on its value.
+
+- 83b0b43: Scope the user record routes to the person themselves, or Seven365 staff — on both `/api/users` and `/api/users/v2`.
+
+  Five routes on each mount carried `requireAuth` and nothing more, with the target
+  user id taken straight out of the URL:
+
+  - `GET /api/users/id/:id` returned any account's name, email, contact and NRIC.
+  - `GET /api/users/organization` took the organisation from the caller's own query
+    string, so any signed-in account could page through any client's whole people
+    directory.
+  - `PATCH /api/users/birthday/:id` rewrote any account's date of birth.
+  - `PATCH /api/users/field/:id` is the sharp one. Its allow-list includes `email`,
+    `nric`, `status` and `defaultOrg`, so pointing it at somebody else's id rewrote
+    **their sign-in address** — and the forgot-password flow then delivers to the
+    new one. That is account takeover, and `status` on the same route disables an
+    account.
+  - `PATCH /api/users/password/:id` verifies the current password inside the
+    service, so it was an online **guessing oracle** against any account: a wrong
+    current password and a mismatched confirmation answered differently.
+
+  `/api/users/v2` is a separate controller file (`user-v2.controller.ts`) with the
+  same routes and the same five holes, so the guard was added to
+  `console-authz.util.ts` as `requireSelfOrPlatformStaff` and **both** controllers
+  call it — rather than fixing v1 and leaving its twin open.
+
+  - the four id-in-URL routes require the id to be the caller's own, or the caller
+    to be Seven365 staff.
+  - `GET /api/users/organization` puts the caller-supplied organisation through
+    `requireOrgAccess` before it is used, the same way `GET /api/members` does.
+
+  Guards sit after each handler's Joi validation, so a malformed id or a malformed
+  value still answers 400 exactly as it does today.
+
+  Every caller in the org already satisfies this rule: the account app's
+  personal-info screens, the resident mobile app's profile editor, and the sign-in
+  and verify-email flows all pass the caller's own id. The one screen that edits
+  another person, `layer-common ClientDetailForm.vue:370`, is reached only from
+  `web-app-org pages/super-admin/client-list.vue` — the Seven365 staff console —
+  which the staff branch covers.
+
+  Nothing changes for a permitted caller: same response shape, same fields, same
+  status.
+
+- 284c83d: Restrict the unauthenticated invitation-status write to the one transition its
+  callers actually perform.
+
+  `PATCH /api/auth/verification/status` (`API-core auth.route.ts:36`) carries no
+  middleware, and it cannot be given any: every caller is an invitation-landing
+  page opened from an emailed link **before an account exists** —
+  `web-app-main` `pages/verify/invitation/[id].vue`,
+  `pages/verify/service-provider/[id].vue`,
+  `pages/verify/service-provider-invite/[id].vue` and
+  `pages/sign-up-invite/service-provider/index.vue`, all through
+  `layer-common composables/useLocalAuth.ts:130`. Adding `requireAuth` would break
+  invitation acceptance for everybody, including the shipped clients.
+
+  What is restricted instead is what an anonymous caller may _do_. Each of those
+  pages calls `GET /auth/verify/:id` first, and `verify`
+  (`verification.service.ts:661-690`) already refuses an invitation that is
+  expired, cancelled or complete — so the only transition a real caller ever
+  performs is `pending -> complete`. Accepting the other three states let anyone
+  who learned an invitation id:
+
+  - set a used invitation back to `pending` and replay it,
+  - revive a `cancelled` or `expired` invitation, or
+  - burn somebody else's pending invitation by marking it `complete` before they
+    opened the email.
+
+  The handler now accepts only `complete`, loads the invitation and requires it to
+  be `pending`. Completing an already-complete invitation still answers 200 so a
+  page that calls this twice is not broken. Cancelling an invitation on purpose
+  keeps its own session-protected endpoint,
+  `PUT /api/verifications/:id/cancel` (`verification.route.ts:13`), so no
+  capability is removed.
+
+- ed0557c: Scope the work order routes to the estate the job was raised at, and take the
+  author's identity from the session.
+
+  A work order is a job at one estate: the subject, the description, the block and
+  unit it sits in, the attachments, the assigned provider, and the name and
+  signature captured when it is signed off. Every route on `/api/work-orders`
+  carried `requireAuth` and nothing more, and `work-order.controller.ts` held no
+  authorization identifier of any kind. `requireAuth` proves a session exists; it
+  makes no organisation or site decision. So being signed in ANYWHERE on the
+  platform was enough to read another client's jobs, rewrite them, drive them
+  between columns, sign them off in a stranger's name, or delete them.
+
+  `DELETE /:id` is the sharp one, and for the same reason it was sharp on
+  `/api/feedbacks`: **it does not write to the v1 table at all.** `deleteWorkOrder`
+  in `work-order.repo.ts` updates `workOrders2Collection` — `work-orders2`, the
+  authoritative table every client actually reads. A guard written against the v1
+  row would have been the wrong guard, so this one is written against the row the
+  write really touches. `DELETE /:id` and `PUT /:id` are also the only two routes
+  on this mount with a live caller: `layer-common`'s
+  `useWorkOrder().deleteWorkOrder` and `updateWorkOrder`, behind the shared
+  `WorkOrder/Main.vue` and `WorkOrder/Detail.vue` screens that every web app draws.
+
+  All seven handlers now decide before any work is done:
+
+  - `GET /site/:site/status/:status` names the site in the URL, so it is checked
+    directly with `requireSiteReach`.
+  - `GET /:id`, `PUT /:id`, `PUT /:id/:status` and `PATCH /:id/completed` name only
+    a record, so the site is read off the STORED row through the new
+    `requireWorkOrderReach`. A `site` in the caller's own body or query cannot
+    stand in for it.
+  - `DELETE /:id` uses `requireWorkOrder2Reach`, against the `work-orders2` row.
+  - `POST /` reads the destination from the body.
+
+  Two readers were needed, not one, because the tables are not the same shape: v1
+  `work-orders` rows keep the site at `metadata.site`, `work-orders2` rows keep it
+  at the top level. Both are new raw readers on the repository —
+  `getRawWorkOrderById` and `getRawWorkOrder2ById`. The existing `getWorkOrderById`
+  is CACHED and shaped for the screen, so a reach check built on it would have
+  decided who may touch a job from a cache entry.
+
+  Two further defects fixed in the same pass:
+
+  1. **Identity from a cookie the caller writes.** `POST /` parsed `createdBy` out
+     of the raw `Cookie` header and never compared it to the session, so a job
+     could be raised in somebody else's name. It comes from `callerId(req)` now.
+     That also closes a latent crash: `cookies?.["user"].toString()`
+     short-circuits only on `cookies` being nullish, so any request carrying
+     cookies but no `user` cookie threw a TypeError.
+  2. **A body that names the site twice, with unequal weight.** `POST /` accepts
+     `metadata.site` AND a top-level `site`, and `work-order.service.ts` copies the
+     top-level one OVER `metadata.site` (`if (value.site) value.metadata.site =
+value.site`). A caller could therefore name their own estate in `metadata`
+     while the row landed at somebody else's. The guard reads them in the order the
+     service resolves them.
+
+  `PUT /:id` is a write that can MOVE a record — the repository `$set`s whatever
+  the body carries, including `site` — so the DESTINATION is checked as well as the
+  origin. Without that, a legacy row carrying no `metadata.site` could be given a
+  top-level `site` of the caller's own and become theirs.
+
+  Each guard is placed AFTER the handler's own Joi validation, so a malformed id
+  still answers 400 exactly as before. A row that does not exist has no site, and
+  `requireSiteReach` refuses a missing site, so an id matching nothing is refused
+  rather than falling through.
+
+  The rule is the existing one, `requireSiteReach` -> `entitleSite`, already used
+  by `/api/feedbacks`, `/api/manpower-monitoring`, `/api/attendances`,
+  `/api/remarks`, `/api/vehicles`, `/api/documents` and `/api/incident-reports`.
+  The `customer.sites` branch is required, not incidental: the contracted provider
+  that does this work holds no membership in the estate's own organisation.
+
+  `/api/work-orders2` is a different mount, lives in API-core's own controller, and
+  is not touched here.
+
+### Patch Changes
+
+- 8a056c0: Scope the attendance settings routes to their estate. `GET` and `PUT /api/attendance-settings/site/:site` carried `requireAuth` and nothing more and the controller held no authorization identifier, so any signed-in account on the platform could read and rewrite any estate's attendance settings — turn location capture off, move the clock-in coordinates, or widen the geofence radius so a shift can be clocked in from anywhere. The read also created a default settings row for a site that had none, so an unauthorised read wrote into another estate's data. Reach is now decided from the session, on the site named in the request, before either the read or the write happens.
+- 1c8c481: Scope the bulletin-board routes to the caller's own estate.
+
+  All five `/api/bulletin-boards` routes carried `requireAuth` and nothing more,
+  and the controller held no authorization identifier of any kind, so any
+  signed-in account in any organisation could publish an announcement into another
+  client's estate — which also fans out as a notification to every recipient group
+  at that site — read that board, and read, rewrite or delete any single bulletin
+  reached by id alone.
+
+  `add` and `getAll` now authorise the site named in the request with
+  `requireSiteReach`; `site` is optional on the add schema, so the org-wide case is
+  asked about separately rather than an absent site leaving the write unscoped. The
+  three by-id handlers take the verdict off the STORED row with a new module-named
+  `requireBulletinReach`, which answers "not yours" and "does not exist"
+  identically so bulletin ids cannot be enumerated.
+
+- 4fbd0aa: Scope the bulletin video routes to their estate. `POST /api/bulletin-videos`, the list, the by-id read, the update and the delete carried `requireAuth` and nothing more, so any signed-in account on the platform could publish a video into another client's estate, list that estate's videos, or read, rewrite and delete any video by its id alone. Reach is now decided from the session — on the site named in the request for the write and the list, and on the stored row for the three by-id routes.
+- b6cea8b: Classify a camera by its `type` correctly, so an ANPR unit can be switched off.
+
+  Reported as `.github-private#35486`: a faulty ANPR camera at a client site is
+  down in PRODUCTION, and `PATCH /api/site-cameras/id/:id` with
+  `status: "inactive"` answers `"You do not have permission to set up cameras on
+this site."` The camera is broken and the person trying to switch it off is
+  locked out.
+
+  The refusal is ours. `cameraManagePermissions` (`camera-view.util.ts`) picked
+  between the two Settings panels' permission strings with
+  `String(type) === "anpr"`, on the strength of a comment claiming `type` was
+  "validated to `ip | anpr` by the model". It was not. `site-camera.model.ts` used
+  `Joi.string().allow("ip", "anpr").required()`, and `.allow()` WHITELISTS
+  additional values rather than restricting to them. Run against joi 17.13.3 the
+  rule accepts `"ANPR"`, `"Anpr"` and `"totally-arbitrary-xyz"` exactly as readily
+  as `"anpr"`; only `""`, `undefined`, `null` and non-strings were refused, and
+  those by `string().required()`, not by the list. So a stored row could carry a
+  spelling the gate could not place, an ANPR unit was classed as CCTV, and the
+  write demanded `site-settings:manage-cctv-camera` — which a role provisioned for
+  the ANPR panel does not hold.
+
+  Two changes, and the gate itself is untouched in substance:
+
+  - The schema is now `Joi.string().trim().lowercase().valid("ip", "anpr")`, so
+    nothing outside the pair can be stored again. `.trim().lowercase()` runs
+    before the check, so a caller sending `"ANPR"` is normalised rather than newly
+    refused; every client in the estate already sends the lower-case pair.
+    `MSiteCamera` normalises the value it writes for the same reason.
+  - `cameraManagePermissions` compares case- and whitespace-insensitively instead
+    of exactly, because the rows already in the collection were written under the
+    old rule and `loadForWrite` reads them raw, so the mapper's default never
+    reaches them. A `type` that still cannot be placed — absent, or a legacy value
+    — now asks for EITHER permission. The two strings are two panels, not two
+    privilege levels; neither is the safer guess, and guessing one is what locked
+    the correct operator out.
+
+  A caller must still be entitled to the site AND hold a camera-management
+  permission on the membership that granted it, so an unrelated tenant is refused
+  exactly as before, and none of the pre-`62e4eb62` behaviour — any signed-in
+  account rewriting or hard-deleting any organisation's cameras — returns. No
+  caller who could write a camera before is refused now: the unplaceable case is a
+  superset of the CCTV string it used to demand.
+
+- 991e0a1: Scope the event-management routes to the caller's own estate.
+
+  All five `/api/event-management` routes carried `requireAuth` and nothing more,
+  and the controller held no authorization identifier of any kind, so any
+  signed-in account in any organisation could file an event into another client's
+  calendar, read that calendar, and read, rewrite or delete any single event
+  reached by id alone.
+
+  `add` and `getAll` now authorise the site named in the request with
+  `requireSiteReach`; the three by-id handlers take the verdict off the STORED row
+  with a new module-named `requireEventReach`, which answers "not yours" and "does
+  not exist" identically so event ids cannot be enumerated.
+
+- f2755a1: Scope the facility booking routes to the estate. `/api/facility-bookings` carried
+  `requireAuth` and nothing else on all five routes: any signed-in account could book
+  a facility at another estate, list another client's bookings, and read, rewrite or
+  cancel any booking by id alone — including moving a booking to a different estate.
+  Reach is now checked on the site named in the request, and on the stored row where
+  the request names only an id.
+- ddac2d2: Scope the form-entry routes to the estate and to the resident who submitted them
+
+  `/api/form-entries` is a second controller over the same collection as
+  `/api/online-forms`, and the rows in it are not templates only - a resident's
+  submission lives there too. Three of its seven routes carried no session check
+  at all, and the other four carried `requireAuth` and nothing more with no
+  authorization identifier in the controller.
+
+  `GET /resident` took `org`, `site` and `userId` from the query string and
+  matched on exactly those with no projection, so an unauthenticated caller who
+  could name a resident's user id got that resident's whole submission history.
+  It now answers only for the caller themselves, or for somebody who reaches the
+  estate being asked about.
+
+  The reads, the update and the archive are decided by `requireFormEntryReach`,
+  on the STORED row: the estate through `entitleSite`, or the person whose
+  `userId` the row carries - residents hold no `members` document, so the
+  owns-it branch is required or every resident loses their own submissions. The
+  list closes both halves of its optional `site`. The update authorises its
+  destination as well as its source, drops `userId` so ownership cannot be
+  reassigned, and stops a resident approving their own application while leaving
+  resubmission working. `POST /resident` stamps `userId` from the session instead
+  of the body, and `add` stamps `createdBy` from the session instead of the
+  caller's own cookie (which also removes a crash for any request sending cookies
+  without a `user`).
+
+- 584bce4: Constrain what a HID configuration write may contain, and stop storing password salts
+
+  `PUT /readers/:readerId/configuration` is a passthrough to the reader's
+  `set_configuration.fcgi`, and its body schema was `Joi.object().unknown(true)`.
+  That reaches `monitor.hostname`, `monitor.port` and `monitor.path` — the block
+  that decides which server receives every identification at that door — so one
+  request could redirect a reader's entire event stream. Writes are now limited to
+  the two modules the product actually writes, `pjsip` and `identifier`, which are
+  the only two `setReaderConfiguration` call sites in `layer-common`. Module
+  contents stay unvalidated (the vendor owns those keys), reading configuration is
+  unchanged, and the monitor block is still managed by the server through
+  `setReaderMonitor` and `configureReaderIntegration`, which do not use this
+  schema.
+
+  `sanitizeHidPayload` — the central redaction every `addEvent` already passes
+  through — did not include `salt`, so a password salt was still being persisted
+  beside the hash it belongs to. `salt`, `salt_value` and `saltvalue` are now
+  redacted like the rest. This does not touch records already stored.
+
+- 65eda12: Scope the four manpower-attendance reads to the caller's sites and the attendance permission.
+- a77e9fb: Scope a subscription's invoices to the subscription's owner.
+
+  `GET /api/invoices/subscription/:id` carried `requireAuth` and nothing more, and
+  `invoice.controller.ts` held no authorization identifier of any kind: the
+  subscription id came off the URL and went straight into the query. Being signed
+  in anywhere on the platform was therefore enough to page through another
+  organisation's billing history — invoice numbers, amounts, line-item
+  descriptions, due dates and payment status.
+
+  A new module-named `requireInvoiceReach` takes the verdict off the STORED
+  subscription, never from anything the caller supplied. A subscription is owned
+  by an organisation OR by a single user, so both are checked: `siteReachOf`'s
+  `canReach` answers the organisation half, and the personal half is the caller
+  being that user. A subscription that names neither is refused. "Not yours",
+  "does not exist" and "not a valid id" all answer 404 identically, so
+  subscription ids cannot be enumerated.
+
+  Read access to invoice records only — no card handling, no payment gateway and
+  no money movement is touched.
+
+- 5235660: Scope the manpower designation routes to the estate, and stamp who filed the plan
+  from the session. `/api/manpower-designations` carried `requireAuth` and nothing
+  else on all three routes: any signed-in account could file a manning plan into
+  another estate, read any estate's guard-strength plan, or rewrite one by id alone.
+  `createdBy` and `createdByName` were taken from the request body, so the plan could
+  be attributed to anybody. Reach is now checked on the site named in the request and
+  on the stored row for the update, and the two identity fields come from the session.
+- 8223c73: Stop the every-minute manpower-sites sync from deleting the whole catalogue when the HRM Labs lookup returns nothing.
+- 62f5fa4: Treat a maximum seat count of 0 as unlimited when an organisation sends an
+  invitation. `createOrganizationInvite` read the subscription's `maxSeats` through
+  `?? 0` and then refused on any falsy value, so an organisation configured with 0
+  seats — which the plan dialog offers and the console labels UNLIMITED — had every
+  invitation rejected with "No seats configured for organization." 0 now admits
+  invitations without a cap, a real limit is still enforced at the limit, and only a
+  genuinely absent or non-numeric value is still treated as a misconfiguration.
+- f4c8bdb: Scope the online form routes to the estate
+
+  All six `/api/online-forms` routes carried `requireAuth` and nothing more, so any
+  signed-in account on the platform could read, rewrite, move or archive another
+  estate's form templates. The controller now takes its verdict from the session:
+  a new `requireOnlineFormReach` for the by-id read, update and delete, a site
+  check on the add and on the by-site list, both tenancy filters closed on the
+  list query, and the update's destination `site` checked as well as the source.
+  `createdBy`/`updatedBy` are stamped from the session instead of the caller's
+  `user` cookie, and `getOnlineFormsBySiteId` now actually applies the estate
+  filter it was given.
+
+- 1f5cba2: Return the organisation's name only on the anonymous organisation lookup.
+
+  `GET /api/organizations/org/id/:id` is the unguarded twin of `/id/:id`, and it
+  shares this controller's `getById`. The handler answered `res.json(data)` on the
+  raw stored organisation document, which carries the client's own business
+  `email` and `contact` number alongside `description`, `busInst`, `nature`,
+  `defaultSite`, `terms` and `policies`. So anyone at all, with no session, who
+  knew or guessed an organisation id got a client's business contact details back.
+
+  It cannot be given a guard. Its only callers anywhere in the organisation are
+  `web-app-main`'s `sign-up-invite/onboarding-admin` and
+  `sign-up-invite/service-provider` pages (via `layer-common`'s
+  `useOrg.getOrgById`), reached from an invite e-mail before the account being
+  invited exists. Both pages do the same thing with the reply:
+  `form.organization = org?.name || ""` — they read `name` and nothing else.
+
+  So the anonymous path now uses a new `getNameById` on the organisation
+  repository: `findOne` with an **allow-list** projection of `_id` and `name`. A
+  field added to the organisation document later is excluded by default rather
+  than leaking on the day it is added.
+
+  `getById` itself is untouched. About twenty callers inside this package need the
+  whole document — `customer`, `feedback`, `member`, `person`, `robot`,
+  `service-provider`, `service-provider-invite`, `site` and `user-v2` services all
+  read it — so projecting that function would have broken them. The new function
+  sits beside it, and the controller picks between the two on whether the request
+  carries a session (`callerId(req)`), which is the same shape used for the
+  pre-login user lookup and resident-create routes. The guarded `/id/:id` route is
+  therefore unchanged: still the whole document, still 401 without a session.
+
+- 30b0739: Scope the patrol log email route to its estate. `POST /api/patrol-logs/email` carried `requireAuth` and nothing more and the controller held no authorization identifier, so any signed-in account on the platform could name another client's site and that site's patrol log ids and have the report emailed — to a list of up to 25 addresses of their own choosing, from the platform's sending address. The service's own log-belongs-to-site check is internal consistency, not reach: name the other estate's site and its own logs and the two agree. Reach is now decided from the session, on the site named in the request body, before anything is read, recorded, rendered or sent. `createdBy` — the audit row for who emailed patrol logs out of the system — is taken from the session rather than from the request body.
+- 4a3f19e: Scope the virtual patrol log routes to the estate, and take the author from the session
+
+  `/api/patrol-logs` carried `requireAuth` and nothing more on all five handlers,
+  and `patrol-log.controller.ts` held no authorization identifier of any kind. A
+  patrol log is the proof a round was walked, so any signed-in account on the
+  platform could read another client's patrol history, rewrite a round's outcome,
+  detach its incident report, move it to another estate, or destroy it. The delete
+  is a HARD delete (`collection.deleteOne`), so there is no tombstone to notice.
+
+  `GET /` was worse than "unscoped": `site` was an OPTIONAL query parameter and
+  the repository only applies it when it is a valid id, so a request that simply
+  omitted it was answered with EVERY estate's patrol history in one page. `site`
+  is now required, which is what both live callers already send.
+
+  `createdBy` was accepted from the request body and never compared to the
+  session, so a round could be filed under another guard's name. It now comes from
+  `callerId(req)`.
+
+  Adds `requirePatrolLogReach`, built on the existing `requireSiteReach` rule,
+  plus an uncached `getRawPatrolLogById` so the check is not decided from a
+  15-minute cache entry. `PUT /id/:id` checks BOTH ends, because
+  `schemaUpdatePatrolLog` accepts `site` and `updateById` writes it.
+
+  Behaviour change: `GET /id/:id` used to answer 200 with `data: null` for an id
+  matching nothing; it now refuses.
+
+- f8e379b: Scope the virtual patrol question routes to the estate
+
+  `/api/patrol-questions` carried `requireAuth` and nothing more on all four
+  handlers, and `patrol-question.controller.ts` held no authorization identifier
+  of any kind. Any signed-in account on the platform could add a question to
+  another client's estate, reword one, change the answers it accepts, or delete
+  it. The reword is the quiet one: the guard's console still shows a question and
+  still records an answer, so nothing looks wrong, but the estate is no longer
+  checking what it believes it is checking.
+
+  `GET /` was worse than "unscoped": `site` was an OPTIONAL query parameter and
+  the repository only applies it when it is a valid id, so a request that simply
+  omitted it was answered with EVERY estate's patrol questions in one page.
+  `site` is now required, which is what both live callers already send.
+
+  Adds `requirePatrolQuestionReach`, built on the existing `requireSiteReach`
+  rule, plus an uncached `getRawPatrolQuestionById` so the check is not decided
+  from a 15-minute cache entry.
+
+- 6a726f6: Scope the virtual patrol route routes to the estate
+
+  `/api/patrol-routes` carried `requireAuth` and nothing more on all six
+  handlers, and `patrol-route.controller.ts` held no authorization identifier of
+  any kind. Any signed-in account on the platform could read another client's
+  patrol schedule, re-time it, re-assign it, point it at different cameras, move
+  it to another estate, or delete it outright — and a deleted round simply stops
+  appearing in `scheduled-routes`, so nobody is told to walk it and nothing looks
+  wrong on the console.
+
+  `GET /` and `GET /scheduled-routes` were worse than "unscoped": `site` was an
+  OPTIONAL query parameter and the repository only applies it when it is a valid
+  id, so a request that simply omitted it was answered with EVERY estate's patrol
+  schedule in one page. `site` is now required, which is what both live callers
+  already send.
+
+  Adds `requirePatrolRouteReach`, built on the existing `requireSiteReach` rule,
+  plus an uncached `getRawPatrolRouteById` so the check is not decided from a
+  15-minute cache entry. `PUT /id/:id` checks BOTH ends, because
+  `schemaUpdatePatrolRoute` accepts `site` and `updateById` writes it.
+
+  Behaviour change: `GET /id/:id` used to answer 200 with `data: null` for an id
+  matching nothing; it now refuses.
+
+- e504691: Make the people search filters narrow each other instead of overwriting each
+  other.
+
+  `person.repo.getAll` built its Mongo filter as one object literal in which four
+  different filters each wrote a `$or` key — the date range (`dateTo`), the
+  free-text `search`, `contact` and `plateNumber`. An object literal can only
+  carry one `$or`, so the last one written silently replaced every earlier one.
+  In practice:
+
+  - searching by name **and** contact number searched only the contact number,
+  - searching by name **and** plate number searched only the plate number,
+  - and a **date range was dropped entirely** the moment any of the three was
+    used — which is the live case, because `layer-common`
+    `composables/usePeople.ts:2-30` sends `search`, `dateFrom` and `dateTo`
+    together from the visitor/people list.
+
+  No error was raised; the endpoint simply answered a narrower question than it
+  was asked, with rows that should not have matched.
+
+  The four groups are now collected and combined with `$and`, so each one narrows
+  the result. A single filter behaves exactly as before, and a request with no
+  filters is unchanged.
+
+- eec7708: Scope the service provider billing routes to the organisation
+
+  `/api/provider-billings` carried `requireAuth` and nothing more on all five
+  handlers, and `service-provider-billing.controller.ts` held no authorization
+  identifier of any kind. A service provider billing record is what a contractor
+  invoices an organisation for, so any signed-in account on the platform could
+  read another organisation's invoices, swap the attachments that evidence one,
+  flip its status, add an acknowledgement that was never given, or delete it.
+
+  The scope here is the ORGANISATION, not the estate: every row carries `orgId`
+  and no `site`, so the rule is `requireOrgAccess` — Seven365 staff, or a live
+  member of that organisation — not `requireSiteReach`.
+
+  Adds `requireServiceProviderBillingReach`, plus an uncached
+  `getRawServiceProviderBillingById` so the check is not decided from a 15-minute
+  cache entry (the existing reader is cached and throws `NotFoundError`, which
+  would also answer before the guard ran).
+
+- 0c167e6: Scope the robot routes to their estate. `POST /api/robots` and `GET /api/robots/organization/:organization/site/:site` carried `requireAuth` and nothing more and the controller held no authorization identifier, so any signed-in account on the platform could page any estate's robot list — which projects `appKey` and `appToken`, the robot's credentials — and aim a robot registration at any estate. Reach is now decided from the session, on the site named in the request. A registration naming no estate is refused rather than falling through unscoped, and `createdBy` is taken from the session rather than from the request body.
+- 88000a3: Scope the site billing configuration routes to the estate, and take createdBy from the session
+- 477139d: Scope the site billing item routes to the estate, and check the unit list against the item's own site
+- 1f71a3e: Scope the site facility routes to the estate. `/api/site-facilities` carried
+  `requireAuth` and nothing else on all six routes: any signed-in account could add a
+  facility to another estate, list another client's facilities — or, by omitting the
+  optional `site` filter, every estate's facilities at once — and read, rewrite or
+  archive any facility by id alone, including its opening hours, booking fees, deposit
+  and policies. Reach is now checked on the site named in the request, and on the
+  stored row where the request names only an id; the unfiltered cross-estate list is
+  left to platform staff.
+- 97a5e71: Scope the statement of account routes to the estate and the unit, and take the requester and approver from the session
+
+  Eight of the nine routes on `/api/site-soa` carried `requireAuth` and nothing
+  more, and `site-soa.controller.ts` held no authorization identifier of any kind.
+  A statement of account is one unit's ledger for a period, so any signed-in
+  account on the platform could read another estate's statements, restate one,
+  approve or reject it, move it to another estate, or delete it.
+
+  `GET /user` is named for the signed-in resident but took `site` and `unitId`
+  from the query and identified the caller not at all, so a resident could read a
+  neighbour's statement of account by changing one id in a URL. It now requires
+  `unitId` and checks it against a live `people` row joining the caller to that
+  unit, via `requireOwnUnit`.
+
+  `add` set `createdBy`, and `reviewSOA` set `approvedBy._id`, by parsing the raw
+  `user` cookie off the request, so a statement could be requested under another
+  resident's name and approved under another person's. Both now come from
+  `callerId(req)`.
+
+  Adds `requireStatementReach` plus an uncached `getRawStatementOfAccountById`.
+  `PUT /id/:id` checks both ends, because `schemaUpdateStatementOfAccount` accepts
+  `site` and `updateById` writes it.
+
+  `GET /generate-pdf` is deliberately unchanged: it is the platform's PDF service,
+  called from every web app by `@7365admin1/layer-common`'s `usePDFDownload`, and
+  it is authorized by forwarding the caller's own session to the headless browser.
+
+- dd01b3e: Scope the unit billing routes to the estate, and the resident routes to the caller's own unit
+
+  `/api/site-unit-billing` carried `requireAuth` and nothing more on all seven
+  handlers, and `site-unit-billing.controller.ts` held no authorization identifier
+  of any kind. Two separate problems followed.
+
+  On the estate side, any signed-in account could add a bill to any estate, read
+  another estate's whole billing run, restate what a resident owes, move a bill to
+  another estate, or delete it. Those five routes now use `requireSiteReach`, plus
+  a new `requireUnitBillingReach` on the stored row and an uncached
+  `getRawUnitBillingById`. `PUT /id/:id` checks both ends, because
+  `schemaUpdateSiteUnitBilling` accepts `site` and `updateById` writes it.
+
+  On the resident side, `GET /user` and `GET /user/unsettled` are named for the
+  signed-in resident but took `site` and `unitId` from the QUERY and identified the
+  caller not at all, so they were never "my bills" — they were any unit's bills at
+  any estate. A resident passing a neighbour's unit id got the neighbour's
+  maintenance bills, and omitting `unitId` dropped that filter too and returned the
+  whole estate's. Both routes now require `unitId` and check it against a live
+  `people` row joining the caller to that unit at that site, via a new
+  `requireOwnUnit`. Seven365 platform staff are exempt.
+
+- c1d9d07: Let Seven365 staff switch a client's faulty camera off, and record it
+
+  `PATCH /api/site-cameras/id/:id` now falls back to a Seven365 staff check when
+  the ordinary site rule refuses. The fallback writes `status` only and is
+  recorded in the console audit trail. Reads, `add` and `deleteById` are
+  unchanged, so staff have gained no access to any organisation's camera list.
+
+- 7ec7f3a: Check the vehicle-approval permission under the resource name the catalogues
+  actually grant.
+
+  When a security agency adds a vehicle, the vehicle is parked at `PENDING` unless
+  the caller may approve one. `vehicle.service.ts:125` asked for
+  `vehicleManagement:approve-vehicle`, but every catalogue that can grant a
+  permission spells that resource `vehicle-mgmt` — `web-app-security`
+  `composables/useSecurityPermission.ts:87,111`, `web-app-org`
+  `composables/usePropertyPermission.ts:312`, `ma-mobile-app`
+  `src/features/permissions/permission.catalog.ts:7`, `isecure365-mobile-app`
+  `src/features/permissions/permission.catalog.ts:32`. Only the prefix differed,
+  so the string checked here was one no role could hold and the bypass could never
+  be reached by granting the permission — the agency's vehicles stayed pending
+  however the role was set up. `vehicleManagement:` appears nowhere else in any
+  repository in the organisation.
+
+  The `*` wildcard branch is untouched, so a role holding all permissions behaves
+  exactly as before; this only makes the specific grant work as intended.
+
+- 772cd89: Scope the visitor guest routes to the estate
+
+  `/api/visitor-guests` carried `requireAuth` and nothing more on all four
+  routes, so any signed-in account could add, read, edit or delete another
+  estate's expected-visitor list. `site` was optional on the list query and the
+  repository only applies it when valid, so omitting it returned every estate's
+  visitor records at once. All four handlers now ask the existing site-reach
+  rule, and `site` is required on the list query.
+
 ## 3.48.0
 
 ### Minor Changes