@7365admin1/core 3.76.0 → 3.77.1-staging.329

package/.changeset/cctv-live-view-signed.md

@@ -0,0 +1,12 @@
+---
+"@7365admin1/core": minor
+---
+
+Sign the camera relay's LIVE view link, the same way recorded footage is already signed
+
+The relay's live routes (player page, stream socket, screenshot, clip) had no authorization at
+all. The camera payloads this server returns now carry a signed `liveUrl` and a reusable
+`liveAuth` (`exp=&sig=`), HMAC-SHA256 over `channel|exp` with the same PLAYBACK_SIGNING_KEY and
+the same 120-second lifetime as a playback link. The stored `camera.host` is deliberately left
+untouched: a query string there would switch off the liveVideo capability and would be frozen
+into patrol-route documents. A camera whose relay is not configured is unchanged.

package/.changeset/cctv-recorded-footage.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Recorded footage for CCTV cameras: `RELAY_PLAYBACK` capability (`CAMERA_PLAYBACK_RELAYS` + referenced signing key), `getPlayback` signs a 120-second link to the camera relay's recorder playback for a past window of up to 30 minutes, gated by site reach and the new `cctv-mgmt:view-recordings` permission.

package/.changeset/client-invite-owner-role-permissions.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Invite Client: Seven365 staff choose the new client owner's role permissions with the modules (`permissions` on `POST /api/auth/invite/user`, only with `modules`, each inside them, never a console permission). Onboarding writes them on the client's own application owner role and records it as the organisation's `invitedRole`, so the owner's application membership gets exactly that role. Role writes for that application in that organisation stay within it (`*`/empty becomes the grant; wider strings are refused; Seven365 staff are not capped). Clients invited before this are unchanged. Kill switch: `CLIENT_INVITE_OWNER_PERMISSIONS=off`.

package/.changeset/client-invite-service365.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Invite Client for a Property Management or real estate developer client can carry the Service365 resident app modules; onboarding writes them on the organisation

package/.changeset/customer-sites-one-row-per-site.md

@@ -0,0 +1,19 @@
+---
+"@7365admin1/core": patch
+---
+
+Return one row per site from `/api/customer-sites`, named by the site.
+
+`getAll` grouped by `{ name, site }`. A customer-sites row is an ENGAGEMENT and
+one site can carry more than one, so two rows for the same site with different
+names both survived as "distinct" — a provider's site list showed four entries
+for three sites, and the site switcher ticked two at once.
+
+`name` is also a snapshot from when the engagement was created and goes stale
+when the site is renamed; recency is no guide, since the newer row held the
+staler name. The site is now looked up and its live name projected over the
+snapshot, with the stored name kept as a fallback.
+
+The search and the sort both run after the rename, so a site is found and
+ordered by the name it actually has, and the count is derived from the same
+pipeline.

package/.changeset/daily-occurrence-book-startup.md

@@ -0,0 +1,24 @@
+---
+"@7365admin1/core": minor
+---
+
+Create the daily occurrence book on server startup as well as at midnight, and skip a site that already has today's book
+
+`processCreateDOB` was reachable only from the `0 0 * * *` cron API-core registers. A cron pattern
+does not fire when it is registered, so a server that was down, redeployed, or running outside
+production at midnight skipped that day and nothing ever went back for it - one site's book list
+stopped at 17/07/2026 while its guards kept logging entries.
+
+The job is now idempotent by the Singapore day: it reads the site ids that already have a book dated
+inside today's window (`getSiteIdsWithBookInWindow`) and inserts only for the rest, returning
+`{ created, skipped, message }`. The unique `{ site, date }` index cannot stand in for that check,
+because the stored `date` carries the hour of the run, so 00:00 and a 09:15 restart are two different
+keys. The book counter is consumed only when there is something to insert. API-core can therefore
+call it on boot as well as on the cron.
+
+`closeOccurrenceBooks` no longer throws when nothing is due to be closed - the normal case on a quiet
+night, and now on every restart - and logs instead.
+
+Every run now logs its outcome from inside the service - created how many and skipped how many, or nothing to create, and how many books were closed - so the midnight cron reports the same way the startup pass does. Silence used to be the only evidence either way.
+
+The book number is now PER SITE. It came from one global `occurrence-book` counter row bumped once per run, which held only while every site got a book on the same night: a site added mid-day, or one that later stops taking daily occurrence books, would have its next number jump by however many days it missed. `getHighestEntryCounterBySite` reads each site's own high-water mark (deleted books included, so an issued number is never handed out twice) and `nextEntryCounter` adds one, so a site with no books starts at No. 1. Existing sites are unaffected: their highest number today is the same value the shared counter last wrote, so the sequence continues where it left off. Manual creation through `POST /occurrence-books` is numbered the same way, and the counter row no longer decides any number.

package/.changeset/hid-duplicate-enrollment.md

@@ -0,0 +1,22 @@
+---
+"@7365admin1/core": minor
+---
+
+Refuse to enrol the same person on one HID reader twice.
+
+`POST /readers/:readerId/identities` and `PATCH /identities/:identityId` now
+check whether the linked resident, staff member or service provider already
+holds a HID user on that reader, and refuse with a 400 naming the user that is
+in the way. The existing duplicate check in `addIdentity` could not catch this:
+it asks about the reader's own keys, and enrolment allocates a fresh
+`hidUserId` and registration every time, so a second enrolment of one person
+looked entirely new while leaving the reader holding two users for one human.
+
+The check is reader-scoped on purpose — the same person enrolled at a different
+gate is normal. Visitors are excluded, because their identity is re-issued
+rather than duplicated and a returning visitor legitimately gets a new
+credential on the same reader.
+
+`GET /readers/:readerId/identities` takes an optional `person` filter so the
+enrolment form can ask the same question before it writes anything to the
+device.

package/.changeset/hid-facial-error-wording.md

@@ -0,0 +1,20 @@
+---
+"@7365admin1/core": patch
+---
+
+Say what a rejected face photo actually means.
+
+A facial failure was passed through as the reader wrote it, so an operator was
+shown `HID facial enrollment failed - code 3: Face exists Scores:
+{"bounds_width":240,...}`. The code is the device's, the scores are its quality
+figures for the photo, and neither says what went wrong or what to do.
+
+The codes we have seen the reader return are now written as sentences: a face
+already enrolled under another HID user, a face too close to the camera, a face
+not square to it, a face too near the photo's edge. The device's own codes are
+quoted once at the end so support still has them, and a code we have not seen is
+passed through verbatim rather than guessed at.
+
+The raw errors and quality scores move off the message and onto the
+`hid-amico-events` row, which is where a rejected photo gets diagnosed later.
+They were the least useful half of a modal and the most useful half of a log.

package/.changeset/hid-identity-user-link.md

@@ -0,0 +1,26 @@
+---
+"@7365admin1/core": minor
+---
+
+Store the user account on a HID identity, and recognise one person across every
+id they are filed under.
+
+An identity's link fields name a RECORD, and different screens name the same
+human through different records: permission reconciliation writes `user` and
+`member`, the enrolment screen writes `person`, and the enrolment picker itself
+has offered two different things over time, since `loadPermissionSubjects`
+returns a `site.people` id for a resident with an account and a `users` id for
+one without. The duplicate check compared field to matching field, so it saw
+none of it. One reader was found holding three HID users for one resident, keyed
+`user`, `person`-as-user-id and `person`-as-people-id.
+
+`createIdentity` and `updateIdentity` now resolve the subject's account through
+`resolvePermissionUserBindings`, the same resolver the permissions screen uses,
+and store it as `user` alongside the record link. The duplicate check matches
+every id that names the subject against every field that can hold one, so a
+resident already enrolled through any screen is refused rather than duplicated.
+
+`GET /readers/:readerId/identities` gains a `subject` filter that asks the same
+question, so the enrolment screen can warn before it writes anything to the
+device instead of failing at submit. The existing `person` filter is unchanged
+and remains an exact match on that one field.

package/.changeset/hid-objectid-across-driver-copies.md

@@ -0,0 +1,26 @@
+---
+"@7365admin1/core": patch
+---
+
+Stop the HID repository mistaking every id it reads from Mongo for "not an id".
+
+`optionalObjectId` in `hid-amico.repo.ts` identified ObjectIds with
+`instanceof`. That only ever holds for an id this file minted itself: three
+copies of the `mongodb` package are installed across `iservice365-core`,
+`iservice365-utils` and `iservice365-API-core`, and `useAtlas` opens its
+connection with the one under `iservice365-utils`, so every id on every
+document it returns belongs to a different class. `instanceof` was false and
+the value fell through to a `typeof value !== "string"` branch that returned
+null.
+
+The visible effect was enrolment. `assertPermissionSubject` treats a resident
+as valid only when their `site.people` record carries a linked user account,
+and it read that link through this helper — so a resident with an account read
+as a resident without one, and `POST /readers/:readerId/identities` answered
+400 "The linked HID identity subject is not active at this site." for residents
+who were perfectly enrollable.
+
+Ids are now read structurally, by `toHexString`, which every copy's ObjectId
+has. `toValidatedId` goes through the same helper, so it too stops rejecting
+ids that came from the database. `hid-amico.model.ts` already read ids this
+way; this brings the repository in line with it.

package/.changeset/hid-profile-qr-backend.md

@@ -0,0 +1,31 @@
+---
+"@7365admin1/core": minor
+---
+
+Let a signed-in member hold their own HID QR code.
+
+`GET`, `POST` and `DELETE /readers/:readerId/profile-qr` read, issue and revoke
+the caller's own QR credential on one reader. The caller comes from the session,
+so there is no user id in the path to point at somebody else, and each handler
+calls `authorizeReader` for itself rather than trusting the router - the site is
+re-resolved from the stored reader record.
+
+The credential is the visitor mechanism: an alphanumeric value in the reader's
+`qrcodes` table, with the reader put into the QR-readable configuration first.
+Unlike a visitor pass it carries no validity window, matching the member's
+facial enrollment, which is standing until removed. Issuing replaces any earlier
+code for that member on that reader, and the replacement is written and verified
+before the old one is removed.
+
+It creates no access rule, deliberately. `setProfileFacial` beside it does not
+either: a member's door access comes from the HID permissions screen, and
+minting a rule here would mean anyone who can press Generate admits themselves.
+The read reports whether that screen admits them, resolved through
+`resolvePermissionUserBindings` - the same resolver that writes the rules onto
+the device - so the answer is the one the reader will actually be asked.
+
+Two settings are now readable that were already writable: the QR identification
+and legacy-mode flags `configureVisitorQrReader` sets on every issue, plus
+`access_rule_time_zones` alongside its two sibling link tables. Whether a reader
+was set up to accept a QR, and whether an access rule had a schedule, were
+invisible to every screen and every diagnosis.

package/.changeset/hid-reader-user-search.md

@@ -0,0 +1,22 @@
+---
+"@7365admin1/core": patch
+---
+
+Make the search on the HID reader user roster work.
+
+`listReaderUsers` asked the device to filter. Amico's `where` takes a value or a
+list of values per column and has no operator form, so the substring clause it
+sent for a text term, `{name: {LIKE: "%x%"}}`, was answered
+`400 Invalid value (string or array expected)`. Every search by name threw, and
+the screen showed "Unable to load HID users from reader" with an empty table.
+
+A numeric term took a different branch that matched the HID user id exactly.
+That did not fail, it answered wrongly: searching a registration number like
+`000004` resolved to `id = 4` and returned a different person.
+
+Rows are already pulled in one page and filtered here for `userType`, so the
+search now joins that filter as a case-insensitive substring over name, id and
+registration - the same three fields, and the same "contains" semantics, the
+identities search uses. Verified against a live reader: a name matches
+partially and case-insensitively, a registration number returns its own user,
+a full UID still works, and no match returns an empty page rather than an error.

package/.changeset/inventory-notification-category.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Add the `inventory` notification category (in-app and push), offered to roles holding any `inventory:*` permission, for API-core's inventory alerts: a request waiting for approval, a decided request, and low stock.

package/.changeset/manpower-authenticated-namespace.md

@@ -0,0 +1,27 @@
+---
+"@7365admin1/core": minor
+---
+
+Manpower live status: an authenticated namespace beside the open one
+
+`/manpower` streams every client site's live staffing level — how many guards are
+actually on shift against how many were promised — to anyone who connects, with no
+credential of any kind.
+
+This adds `/manpower-live`, carrying exactly the same `manpower-status-update`
+events, which admits a socket only when the handshake presents a session id that
+resolves to a live session. Every refusal is an identical `Unauthorized`, and a
+session store that is down refuses rather than letting everyone in.
+
+`/manpower` itself is deliberately unchanged: the Capacitor guard app installed on
+phones today and the Nuxt security screen both connect to it with no credential and
+would be cut off the moment it were tightened. Every update is emitted to both, so
+the two feeds can never disagree, and both namespaces share one connection handler,
+so a client on the authenticated feed still starts the poll and still gets an
+immediate snapshot.
+
+A live session is the whole check, deliberately. Scoping the feed to the caller's
+own sites is not possible today: manpower lives in HRM Labs' vendor id space, none
+of those site ids match ours, and no field links the two — a site check would empty
+the screen for the one customer using it. That mapping is a schema change and
+belongs to the leads.

package/.changeset/member-direct-role-org.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+POST /api/members/direct refuses (400) a role that belongs to a different organisation, unless the caller already holds that role in the organisation being joined.

package/.changeset/member-direct-self-enrol-role.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+POST /api/members/direct: adding yourself now needs a role you may give yourself - Seven365 staff, the organisation's owner, a role you already hold there, or the role your own invitation offers. Enrolling somebody else is unchanged.

package/.changeset/member-list-site-scope.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+`GET /api/members?org=` lists only the sites a caller is pinned to when the caller holds no organisation-wide membership or organisation-level role there; a `siteId` outside those sites is refused. Organisation-wide members, owners/invitees and Seven365 staff are unchanged; a resident-only caller lists no staff.

package/.changeset/member-lookup-follows-site.md

@@ -0,0 +1,16 @@
+---
+"@7365admin1/core": patch
+---
+
+A person's role now follows the site they are on.
+
+`GET /api/members/user/:id/app/:type` accepts an optional `?site=` (a 24-hex
+site id, like `?org=`). When it is sent, the answer is the person's live
+membership of that app type pinned to that site (inside `?org=` when it is also
+sent); failing that, their organisation-wide membership in `?org=`; failing
+that, any live membership in `?org=`. When none of these exists the route
+answers exactly as before. A removed membership never wins, and a site never
+turns a found membership into "not found". Callers that do not send `site`
+see no change. Login, auth-v2 and verification are unchanged.
+
+The rule is the pure `pickSiteMembership` in `utils/member-lookup.util.ts`.

package/.changeset/members-by-user-reach.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+`GET /api/members/users/:id` no longer shows anybody's memberships to any signed-in account. The person and Seven365 staff still get the full list; anyone else gets only the memberships in organisations they belong to, were invited to or own (an empty list, not an error, when there are none).

package/.changeset/module-ceiling-site-owner.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+Role writes: a site's own module list narrows a role only when the site belongs to the role's organisation. A service provider's role at a client's site is no longer refused modules the client switched off for that site — matching what the role editor now offers.

package/.changeset/module-gate-foundation.md

@@ -0,0 +1,20 @@
+---
+"@7365admin1/core": patch
+---
+
+Lay the groundwork for module lists becoming a gate, without narrowing anyone.
+
+- New `utils/module-gate.util.ts`: the list of modules a client's list can
+  govern (generated from layer-common 5a96f95), the spelling groups, the
+  always-included set, and pure functions that work out which modules a
+  caller's apps must hide (`deniedModules`) and who would lose what if a list
+  changed (`moduleImpact`). Nothing calls them yet.
+- The organisation and site module checks now treat every spelling of a module
+  as the same module (ticking `workOrder` also allows `work_orders`,
+  `work_order` and `work-orders`), and never refuse members, invitations, roles,
+  sites, customers, subscriptions, payment methods or site settings. This only
+  ever refuses less than before.
+- A Site Settings save (`PATCH /api/sites/id/:id`) now always keeps the site's
+  stored module list. Before this, the save replaced `metadata` wholesale and
+  could wipe or overwrite that list. `PATCH /api/sites/:id/modules` is the only
+  way to change it.

package/.changeset/module-gate-kill-switch-and-read.md

@@ -0,0 +1,26 @@
+---
+"@7365admin1/core": patch
+---
+
+Module gate: the kill switch now stops the 409, and the check stops reading when there is nothing to decide
+
+Two follow-ups from the module-gate server review, both behaviour-neutral for
+anybody who is not using the kill switch.
+
+**`MODULE_LIST_GATE=off` now means off.** Every other part of the gate checked the
+master switch; `mustAcknowledge` did not. So with the gate switched off, a save that
+narrowed a client's module list was still refused with a 409 "acknowledge the impact
+first" — the one lever a lead would reach for in an emergency, not working for the
+one path that blocks a save from going through. Both the organisation and the site
+save paths go through that function, so both are fixed. With the switch at its
+default the 409 behaves exactly as before, and that is asserted.
+
+**`moduleDeniedForCaller` no longer reads memberships when no list is enforced.** It
+runs on every governed request and read the caller's memberships before finding out
+whether there was anything to decide — and `members.user` has no index to use. It now
+returns early unless the site or its organisation has an enforced list, which is what
+the notification filter already did. No verdict changes: a client that really has an
+enforced list is still measured exactly as before, and that is asserted too.
+
+Also corrects the 3.65.0 changelog, which claimed `MODULE_LIST_GATE` switched all of
+the gate off at once. It did not, for the reason above.

package/.changeset/module-gate-server.md

@@ -0,0 +1,35 @@
+---
+"@7365admin1/core": minor
+---
+
+Module gate, server step: the deny-list endpoint, the impact preview, and
+acknowledge-before-save. Everything ships inert and fails open.
+
+- `useMemberController().getModulesByUserIdType` (for
+  `GET /api/members/user/:id/app/:type/modules?org=&site=`) answers
+  `{ denied: string[] }` for the membership `getByUserIdType` answers with. It
+  is the same self-or-staff guard. It answers `[]` for no list, an empty list,
+  a resident, Seven365 staff, a site of another organisation, any lookup
+  error, and `MODULE_LIST_GATE=off`. `ALWAYS_ALLOWED` is never denied.
+- A saved list is enforced only once it has been saved through the
+  acknowledged preview. The marker is the save's own append-only console-audit
+  row (`gateListHash`). A list saved earlier, or changed any other way, behaves
+  as absent. No field is added to any organisation or site.
+- `useOrgController().previewOrgModules` and
+  `useSiteController().previewSiteModules` (for
+  `POST /api/organizations/:id/modules/preview` and
+  `POST /api/sites/:id/modules/preview`) return who would lose what. They are
+  read-only and never go through `GET /api/roles`.
+- `updateModules` and `updateSiteModules` accept `acknowledgeImpact`. A save
+  that takes a module away from somebody is refused with 409 until it is
+  acknowledged. An empty list restores everything and never needs it. Site
+  saves are now recorded in the console audit (`site.modules-changed`).
+- `filterByAccess` (Q7) runs at the top of the notification `send()`. It is
+  `NOTIFY_ACCESS_FILTER=log` by default: it logs who would be filtered and
+  still sends to everyone. It is exported so API-core's own sender can call it.
+- `moduleDeniedForCaller` (Q3) is the server-refusal primitive. It is
+  `MODULE_GATE_MODE=log` by default and never refuses. `enforce` refuses only
+  the keys in `MODULE_GATE_ENFORCE_KEYS`. Work stamped (`at`) before the
+  acknowledged save is accepted.
+- `MODULE_LIST_GATE` (code default `on`) switches all of the above off at
+  once.

package/.changeset/notify-access-filter-on.md

@@ -0,0 +1,24 @@
+---
+"@7365admin1/core": minor
+---
+
+Notifications: stop sending alerts for modules a client was never given
+
+`NOTIFY_ACCESS_FILTER` now defaults to `on` instead of `log`, so the module-based
+drop is real: a recipient no longer gets a notification when every membership they
+hold at the site denies every module the notification's category is about.
+
+Only the module drop acts. The role-based check is still computed and logged and
+never drops anybody, because most apps do not enforce their role gates yet and a
+role-based drop would hide alerts for screens people can still open.
+
+Unchanged: residents, anyone with no membership at the site, Seven365 staff, sends
+with no site, and categories the catalogue does not govern are all exempt; any
+error sends to everyone; and `MODULE_LIST_GATE=off` still disables it entirely.
+`NOTIFY_ACCESS_FILTER=log` or `off` overrides this default with no deploy.
+
+This is inert until a client's module list is enforced — measured read-only on
+staging at the time of the flip, no organisation (0 of 199) and no site (0 of 256)
+had a stored list and there were no acknowledged-save markers, so nothing is
+dropped for anybody until a Super Admin saves a module list with the acknowledged
+preview.

package/.changeset/org-owner-membership-repair.md

@@ -0,0 +1,15 @@
+---
+"@7365admin1/core": minor
+---
+
+Add a staff-only handler that repairs an organisation's missing owner membership.
+
+An organisation created before 3.60.0 can exist with no `members` row at all, so
+`GET /api/members/user/:id/app/organization` answers 404 and every console
+landing page tells the real owner that no organisation exists. The new
+`orgOwnerRepairHandlers` writes the one membership the onboarding path already
+writes, for one organisation at a time, and only when that organisation is
+active, holds exactly zero `organization` memberships, and has an account
+registered under its own e-mail address. Staff-only (`organizations` console
+permission), idempotent under a one-writer claim, audited, and behind the
+`ORG_OWNER_REPAIR` switch. No schema change and no migration.

package/.changeset/org-read-reach.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+GET /api/organizations/id/:id returns the whole organisation record only to a caller with a relationship to it (member, invitee, owner, Seven365 staff, an active resident of one of its sites, or an engaged service provider). Everyone else gets the name-only record the anonymous lookup already returns. It never answers 401/403.

package/.changeset/org-update-diagnosable-error.md

@@ -0,0 +1,14 @@
+---
+"@7365admin1/core": patch
+---
+
+Say what is wrong when an organisation cannot be saved.
+
+`PUT /api/organizations/:id` — the write behind onboarding step 1 and the staff
+Client List edit — collapsed every MongoDB write error into a 500 reading
+"Failed to update organization.", with only `error.message` in the log. A
+duplicate-key refusal (the `organizations` collection still carries a unique
+index an earlier version of this file created and nothing ever dropped) is now
+a 400 naming the field the caller has to change, a typed error raised
+underneath is no longer turned into a 500, and the log line carries the error
+name, code, key and the organisation id.

package/.changeset/patrol-email-scope-restore.md

@@ -0,0 +1,16 @@
+---
+"@7365admin1/core": patch
+---
+
+Restore and extend the site scoping on the patrol-log email endpoints.
+
+#1967 added a `requireSiteReach` guard to `POST /api/patrol-logs/email`. #1981,
+branched before #1967 landed, rewrote the same controller to add the history
+endpoints and dropped the guard. Neither repo runs its tests in CI, so the e2e
+test #1967 shipped has been failing on `main` unnoticed ever since.
+
+All five endpoints now resolve the caller from the session: the two that name a
+site (`send`, `getAll`) check that site, and the three that name a record
+(`resend`, `getById`, `deleteById`) check the site stored on the record. The
+`createdBy` pinning is restored with them, so a send cannot be filed under
+another user's name.

package/.changeset/people-create-reach-enforce.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+Enforce the reach check on `POST /api/people` by default: a signed-in caller can only create a person at a site (or organisation) they belong to or serve. `PEOPLE_CREATE_REACH_MODE=log` switches back to counting without refusing.

package/.changeset/people-create-reach-gate.md

@@ -0,0 +1,31 @@
+---
+"@7365admin1/core": patch
+---
+
+POST /api/people: count cross-client person creation (gate ships switched off)
+
+The signed-in branch of `POST /api/people` checked only that somebody was signed
+in. The site and organisation came straight from the request body, and where that
+body carries an e-mail, a password and a resident/tenant type, the service goes on
+to create a **user account** and an **active membership** as well as the person row.
+
+`site.people` is the collection every site-reach decision on the platform reads its
+verdict from, so a row written there is not an ordinary record — it manufactures
+reach into another client's estate.
+
+This adds the site-reach check the camera, HID and people-list paths already use,
+behind `PEOPLE_CREATE_REACH_MODE`, and **ships it in `log` mode**: it records what
+it would refuse and refuses nothing. `enforce` refuses; `off` does not look. Any
+unexpected error allows the request — this must never be why a real registration
+fails.
+
+It ships off because of RP-5. A person row carries no `createdBy`, so who created
+the existing rows cannot be established retrospectively and the true refusal count
+is only knowable from live traffic. Measured read-only on staging: 372
+`site.people` rows, of which exactly **1** is self-signup shaped (`platform:
+"mobile"`, `status: "pending"`) and 371 were written by a signed-in caller, across
+3 of 256 sites.
+
+Pre-login self-signup is untouched in every mode: a request with no session takes
+the other branch of `add` before this runs, and that route is already constrained
+by its own allow-list schema with `status` and `platform` pinned server-side.

package/.changeset/people-occupied-structure.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Add `getOccupiedStructure` to the people module: the blocks, levels and units at one site that actually have a person of a given type (`resident` and `tenant` by default), so a block/level/unit picker can offer only locations where the person step has an answer. Site-scoped and authorised with `requireSiteReach` before any person record is read; the status and type filter is `getPeopleByUnit`'s exactly, so a unit is never offered whose person list then comes back empty.

package/.changeset/real-estate-developer-app-type.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Real Estate Developer clients use the Property Management application: membership and role types `real_estate_developer` are stored and looked up as `property_management_agency`, so a developer's owner can open the Property Management app and the owner grant caps their roles.

package/.changeset/real-estate-developer-lookup-both-types.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+Membership and role lookups by type match every stored spelling of an application: a Property Management lookup finds rows stored as `real_estate_developer` (written before 3.75.0) as well as `property_management_agency`, including the module deny list and the owner-grant cap.

package/.changeset/resident-app-module-ceiling.md

@@ -0,0 +1,18 @@
+---
+"@7365admin1/core": minor
+---
+
+Add the organisation tier over the resident-app modules (R4).
+
+`organizations.residentAppModules` is the ceiling over the per-site
+`sites.metadata.residentAppModules` that property-management's Site Settings
+panel already writes. `GET /api/sites/:id` now also returns
+`metadata.residentAppModulesEffective`, the two tiers intersected, because the
+resident app cannot read its own organisation and so cannot apply the ceiling
+itself. The saved per-site field is returned unchanged alongside it, so the
+settings panel still reads back what it wrote.
+
+Only an explicit `false` disables, at either tier, so absent keeps meaning
+everything and this is inert for every organisation until Seven365 sets a
+ceiling. A site write that switches ON a module the client was not given is
+refused by name.

package/.changeset/role-module-ceiling.md

@@ -0,0 +1,16 @@
+---
+"@7365admin1/core": minor
+---
+
+Enforce the organisation's module ceiling on every role write (R1 tier three).
+
+A role can no longer be granted a permission whose module Seven365 never gave
+the organisation, nor one the organisation never gave the site. Applied to all
+four write paths — `role.controller` create / update / updatePermissionsById and
+`role-v2.controller` create — because `/api/roles/v2` is a separate mount and
+gating one leaves the rule reachable by adding `/v2` to the URL.
+
+Only what a write ADDS is tested, so a role that predates the module list can
+still be renamed and can still have a permission removed. Absent and empty
+module lists still mean everything at every tier, so this is inert for all 168
+live organisations until Seven365 sets a list.

package/.changeset/role-read-self-arm.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": patch
+---
+
+Scope `GET /api/roles/id/:id`: a caller may read a role they themselves hold (resolved from the session's own `members` rows), otherwise the role's organisation rule applies. Closes the cross-tenant read of any organisation's role name and permissions.

package/.changeset/role-v2-platform-grant.md

@@ -0,0 +1,14 @@
+---
+"@7365admin1/core": patch
+---
+
+Stop `/api/roles/v2` minting a role that holds the console's own resources.
+
+`role.controller createRole` has carried `requireNoPlatformGrant` for a while;
+`role-v2.controller createRole` did not. It is a separate controller behind a
+separate route and accepts any permission string, so the hole was reachable by
+adding `/v2` to the URL.
+
+Measured on production before adding: no site-scoped role holds a platform-only
+string, and this mount requires a `site`, so the check refuses nothing that
+exists today. It only ever refuses a NEW grant regardless.

package/.changeset/site-module-allowlist.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Tier two of the module cascade: `sites.metadata.modules`, the modules a site offers, plus `PATCH /sites/:id/modules` for the organisation to set it. The write refuses any key Seven365 never gave the organisation (owner requirement R1); the read fails open at every tier, so absent and empty both mean "everything the organisation has" and no site or role editor changes until somebody sets a list.

package/.changeset/site-modules-client-admin.md

@@ -0,0 +1,5 @@
+---
+"@7365admin1/core": minor
+---
+
+Per-site module lists can be set and enforced by the client's own owner/admin (organisation membership holding `*` or `sites:manage-site-modules`), not only by Seven365 staff. Anyone else who merely reaches the site (a guard pinned to it, an engaged provider, a resident) is refused on the save and the preview.