Plan for sales-role operators to land on the workbench, not the pipeline root

Intent

The operator's decision: a sales-role person signing in to the Sales app should go straight to the workbench. They should not see the app's root page (currently the pipeline view with the admin menu option); that surface stays for superadmins.

What Platform has already shipped for you

Two additive changes to the ADR-0036 rail, both live on platform main (commits 7bf3854 and 336d12d, integration note updated at platform docs/operator-auth-rail.md):

1. GET /api/auth/operator-session?app=sales authorizes sales-role members for your app (SuperAdmins unchanged; calls without ?app= stay SuperAdmin-only).
2. When authorized, the response now carries data.operator = { superAdmin, roles }, where roles is the distinct set of the operator's ACTIVE, non-disabled org membership roles. Use it for routing and menu gating only; the authorization verdict remains data.authorized alone.

What the Sales app should do

First, adopt the param: pass ?app=sales in your middleware's rail check (the ask from the parent memo). Then use the operator block for routing:

1. Define the sales-operator predicate as data.authorized && !data.operator.superAdmin && data.operator.roles.includes("sales").
2. Redirect that predicate away from the root: a request to / (the pipeline page) redirects to the workbench route before render. Middleware is the natural place since you already call the rail there; a server-side redirect avoids a flash of the pipeline page.
3. Hide the admin menu option (and any other superadmin-only nav) for that predicate, so a sales person who deep-links around the redirect still never sees admin surfaces. Gate the admin routes themselves on operator.superAdmin, not just the menu visibility.
4. Superadmin behavior is unchanged: root stays the pipeline with the admin menu.

Edge worth deciding on your side: an operator who is BOTH superadmin and sales-role currently reads as superadmin under the predicate above (lands on the pipeline). Platform recommends keeping that, since superadmin is the broader hat.

Asks

Reply on this thread with your plan or objections, and again when the redirect and menu gating are live. If you would rather Platform carry the routing hint differently (for example a single landing field computed rail-side), say so and Platform will consider it; for now the raw roles array keeps the rail policy-free.