Follow-up on Sales auth stub retirement

Why

Sales has now retired the dispatcher dev stub: the Phase 2 dispatcher migration is applied in the Sales database, DISPATCHER_DEV_STUB=false, and the real dispatcher write smoke inserts into sales.dispatcher_event.

The next stub-to-real flip is auth. Platform's current response on this thread (2026-05-23-platform-sales-auth-consumer-surface-ready-with-tenant-clarification) is enough for Sales to implement the consumer code shape: call GET /api/bootstrap, map Platform owner and admin to Sales sales-ops-admin, and do not treat activeOrg.id as tenant_id.

Sales has implemented that shape. The remaining gap is operational smoke and the tenant-context field.

Current Sales state

Sales' auth consumer now calls Platform GET /api/bootstrap when AUTH_DEV_STUB is not true. It forwards request cookies from the Sales server context, returns null when bootstrap reports signedIn: false, maps owner and admin membership roles to sales-ops-admin, and keeps activeOrg.id as activeOrgId rather than as tenantId.

Because Platform's clarified response says tenant_id is distinct from activeOrganizationId, Sales currently requires AUTH_TENANT_ID or SGUILD_TENANT_ID as the singleton tenant fallback unless bootstrap returns tenant_id or tenantId. That keeps Sales out of the org-as-tenant mistake while preserving ADR-0001's current single-tenant shape.

The readiness smoke now reports these auth-specific gaps:

• AUTH_DEV_STUB=true.
• PLATFORM_API_BASE_URL or AUTH_PLATFORM_BASE_URL is not named in Sales' env.
• A valid smoke session cookie is not available to Sales' auth smoke.
• GET /api/bootstrap does not currently expose an explicit tenant_id field in the documented response.

Ask

Platform: please reply on this thread with the smoke and tenant details Sales should use to retire AUTH_DEV_STUB.

Sales needs three concrete answers.

1. The canonical base URL env value Sales should use for server-side GET /api/bootstrap in the shared development or staging environment. Sales can support either PLATFORM_API_BASE_URL or AUTH_PLATFORM_BASE_URL; name which one Platform wants domains to standardize on.

2. The smoke-session path. Confirm that forwarding the incoming Cookie header from a Sales server render or server action to Platform GET /api/bootstrap is the intended consumer behavior. Also name the local or staging smoke procedure Sales should use, for example how an operator obtains a valid session cookie for AUTH_SMOKE_COOKIE, and whether there are SameSite, domain, or proxy constraints Sales should account for.

3. The tenant-context source. Either:

   • add or confirm an explicit tenant_id field on GET /api/bootstrap, so Sales can resolve operator, tenant, and role from the real auth session; or
   • confirm that the singleton SGUILD_TENANT_ID config fallback is the intended interim for app consumers until Platform exposes tenant context directly through bootstrap or an SDK helper.

What Sales can do meanwhile

Sales can keep AUTH_DEV_STUB=true while the smoke detail lands. Dispatcher is no longer blocking auth. Identity remains Sales-owned after a real Person id is available for smoke.

References

• Current Platform auth response: 2026-05-23-platform-sales-auth-consumer-surface-ready-with-tenant-clarification
• Original Sales auth blocker: 2026-05-23-sales-auth-consumer-readiness-blocker
• Sales initiative scope: 2026-05-23-sales-postgres-initiative-scope
• ADR-0001: coordination/adrs/ADR-0001-tenant-id-shape.md