Microsoft 365 gatekeeper

Microsoft 365 (Entra ID OAuth, Microsoft Graph). It has three resources. SharePoint's binding is one of: all of SharePoint & OneDrive, a site, a library or OneDrive, a folder, a file, a list, or a page; its configurator starts at "all" and drills down. Outlook's is one mailbox (own or shared), optionally narrowed to a folder, a conversation or senders, at read/draft/send. Calendar's is every calendar (for chat), one calendar (own or shared) at freeBusy/limited/full detail (for a gadget shared with that calendar's sharees), or availability only, at read/edit/schedule; CALENDAR_RESOURCE (…/calendar/*) must stay ahead of OUTLOOK_RESOURCE (…/*) in ALL_RESOURCES, since the Workshop takes the first matching pattern. plans/microsoft-365-gatekeeper.md, plans/microsoft-outlook.md and plans/microsoft-calendar.md are the design records and storage-schema.md the storage layout.

• Agents act with the user's delegated permissions; the binding narrows further, and ScopeGuard (sharepoint-scope.ts) is the chokepoint. Every ID is checked before Graph is called (a folder by walking its ancestry), paths are measured from the binding's top, and a temporary ~N ID is resolved at every entry point. graph-api.ts is the only code that holds a token: it refuses non-Graph hosts, and follows a download redirect once, only to a SharePoint or conversion host, without the Authorization header.
• A connection and its bindings are pinned to (tenantId, objectId) from the id_token, confirmed against /me. Tenant policy (tenantPolicy in microsoft-env.ts) refuses common/consumers, and refuses organizations without a GUID allowlist. Each resource's effective access is the lowest of the binding's own level (Outlook and Calendar), the deployment ceiling (MICROSOFT_SHAREPOINT_ACCESS, MICROSOFT_OUTLOOK_ACCESS, MICROSOFT_CALENDAR_ACCESS) and the grant's scopes, and a SharePoint file, folder or library binding drops to read when Graph's undocumented shared.effectiveRoles says the user can only read it (only ever lowering). MICROSOFT_SHAREPOINT_SITES=selected asks for Sites.Selected instead of the .All permissions, but a connection's behavior follows what it was granted (grantedSharePoint), never the setting; a read-only binding's session (SharePointReader, OutlookReader, CalendarReader) has no write methods at all.
• Observers use tracked collections of access units (site/drive/item/list/listItem/page), because SharePoint breaks inheritance at any level. One container's ACL never stands for its contents.
• Graph behaviours that return wrong-but-plausible data, verified live: /sites?search= can return nothing on a working tenant, so sites come from Microsoft Search (/search/query) plus followed sites; /sites/{id}/lists omits Site Pages, so pages are detected through the pages endpoint; search lags uploads by hours on a new tenant, so nothing may depend on finding a fresh file.
• Outlook's chokepoint is OutlookContext.guarded (outlook-session.ts): every message ID is read with its metadata and checked against the scope before anything else is read or changed, and a listing's Graph filter is only an optimization. 400, 403 and 404 all mean "not in this binding". Every request sends Prefer: IdType="ImmutableId", so IDs survive moves and sending. Send is never auto-approvable and is exactly-once through a Message-ID fixed at proposal, found across the whole mailbox before /send (submit in outlook-actions.ts handles the half-second after a 202 when a second /send is 403). Inbox rules, permanent deletion, permissions and send-as are deliberately not offered.
• Exchange gives a mailbox four concurrent requests, so $batch entries can 429 individually and GraphApi.batch resends them; Sent Items' from is a legacy X.500 DN, replaced with the owner's address on read; Outlook web links use EWS IDs, converted in parseOutlookUrl. New-message hooks run through one OutlookHookDriver per connection and mailbox, which reads by cursor and treats Graph change notifications (when BASE_URL is public https) only as a prompt to read sooner.
• Calendar's chokepoint is CalendarContext.guarded (calendar-session.ts): an event's parent entry ID (Binary 0x0E09) must equal the bound calendar's (Binary 0x0FFF, pinned at binding) before anything is shown, and listings are re-confirmed the same way, because a calendar-scoped calendarView is not trusted. Redaction to the binding's detail level is the gatekeeper's (eventInfo in calendar-events.ts), not Graph's: the user's own token sees everything. Observers (calendar-observers.ts) admit someone to a calendar unit only when the owner's calendarPermissions give them a role that sees that level (calendar-acl.ts; a group entry can only lower the org default), to availability:<address> only when getSchedule as them answers, and to calendars:<id> never but the user. Anything that mails someone (calendar.invitations, calendar.responses) is never auto-approvable and is claimBeforeApply; changes are fenced with If-Match on the change key, creations with a transactionId.
• Tests: Node (vitest.config.ts, where the configurator frame suites drive the generated frames in Chromium through __tests__/frame-host.ts) and workerd against a fake Graph (vitest.worker.config.ts), both run by pnpm --filter @gadgets/microsoft-gatekeeper test:run after it builds the configurator frames; and a live-tenant contract suite (vitest.contract.config.ts), run by test:contract, which is skipped unless .dev.vars and a tokens file are present.