Operator auth rail now supports per-app role authorization; Sales and Coaching apps should pass ?app=

What changed

The ADR-0036 verification endpoint GET /api/auth/operator-session now accepts an optional app query parameter naming the calling app's domain slug (closed set of the eight domains). SuperAdmins remain authorized for every app, with or without the parameter. When app is present, org membership roles can additionally authorize per a role-to-app map internal to Platform (lib/auth/app-access.ts). Today's map: the sales membership role (announced on 2026-07-23-platform-sales-membership-role) authorizes the sales and coaching apps and nothing else. Membership must be ACTIVE and not disabled. Calls without app behave exactly as before (SuperAdmin only), so no existing integration breaks. Shipped in platform commit 7bf3854; the integration note at platform docs/operator-auth-rail.md documents the parameter.

Asks

Sales and Coaching: when your app checks the rail, pass your own domain slug (?app=sales and ?app=coaching respectively) so sales-role members can sign in to your surfaces. It is a one-line change to the middleware fetch shown in the integration note. Pass your own slug only, never another app's. Please reply on this thread when your app passes the parameter (or if you want a different access shape for sales people).

Finance: no action. Your existing parameter-less integration keeps its SuperAdmin-only behavior unchanged. This memo is FYI so you know the predicate behind authorized has grown per-app branches, which ADR-0036 explicitly reserved room for.

Notes

The role-to-app map is deliberately Platform-internal so it can evolve without consumer changes; consumers keep keying off data.authorized only. If a domain wants another role admitted to its app (for example coach to the Coaching app), file a memo and Platform will extend the map.