Managing which apps a member may use

The ADMIN view, not the member's own drop-down (that is GET /v1/me/apps, scenario 18). grantedMembers is counted live, so it reflects revocations immediately. The identity app is EXCLUDED: every member reaches it by virtue of membership, so listing it would invite an admin to try to revoke access they cannot revoke.

Returns EVERY app the tenant is enabled for, each flagged granted true/false for this member, so the UI renders the whole toggle set from one call rather than diffing two lists. A foreign-tenant userId is 404, not 403 (AUTH-OBJECT-03) — a 403 would confirm the id names a real user somewhere.

No body. Granting an app the tenant is not enabled for is 422 tenant_app_not_enabled, never a silent success — writing the grant anyway would leave the member seeing nothing in their drop-down with the API having answered 200. A merely SUSPENDED enablement is refused the same way. The identity app is not granted per member → 422 identity_app_not_grantable. Re-granting must UN-DELETE: the write is ON CONFLICT … DO UPDATE SET deleted_at = NULL, because a plain DO NOTHING would silently no-op on re-grant and leave the member locked out while the API reported success. Every grant write also touches the membership row in the same transaction so the next projection emission carries a strictly greater version — without it, revoke-then-re-grant emits twice at one version and the projector's guard silently discards the re-grant. THE GRANT IS PROJECTED AT THE REQUEST: it emits user.upserted + membership.upserted in the same transaction (§2.47), so a member granted after the tenant's backfill now reaches the app without an operator resync. ⚠ DOC DISCREPANCY: §3.96 and a §2.55 gotcha still say this call emits no projection event and that a first-time grant is never projected; §2.47 says the gap is closed, and the service (app-access.service.ts) enqueues both events — the tester follows §2.47. If a granted member is nonetheless missing downstream, that is now an anomaly to diagnose (scenario 48), not the expected state.

Soft delete, no body. Takes effect at the member's NEXT REQUEST, not their next login — the grant is re-checked live at every /internal/validate hop, which is what makes it a real control rather than a note that applies whenever they next sign in. Revoking a grant that is not held answers 200 and still advances the membership version: the alternative would make the version sequence depend on whether a caller sent a redundant request. The revoke also emits membership.removed for THAT app alone, in the request transaction (§2.47), so the app's projected copy is told at once rather than lingering. ⚠ DOC DISCREPANCY: §3.97 and a §2.55 gotcha still say no projection event is emitted here and a revoked member can linger in the app's own UI; the service enqueues it, and the tester follows §2.47. Either way authorization and visibility are decided by different mechanisms — the live /internal/validate check is what enforces the revoke. The member sees the result at GET /v1/me/apps (scenario 18).