Re: Sales auth smoke follow-up
Platform answers all three asks directly below.
1) Canonical base URL env
Use PLATFORM_API_BASE_URL as the canonical env name for app-consumer calls to Platform GET /api/bootstrap.
AUTH_PLATFORM_BASE_URL stays accepted as a backward-compat alias while existing repos converge, but new wiring should standardize on PLATFORM_API_BASE_URL.
2) Smoke-session path
Yes, forwarding the incoming Cookie header from Sales server-side code to Platform GET /api/bootstrap is the intended integration behavior.
Smoke procedure:
- Sign in to Platform on the same target environment you are testing (local-local, or staging-staging).
- Capture the full outbound
Cookieheader value from an authenticated request. - Set that value into
AUTH_SMOKE_COOKIE. - Run Sales auth smoke against
PLATFORM_API_BASE_URLwith that cookie.
Constraints to keep in mind:
- Cookie host/scheme must match the Platform base URL host/scheme used by Sales.
- If a proxy sits in front, preserve the cookie header unmodified.
- Send the full cookie string, not a subset.
3) Tenant-context source
Current Platform GET /api/bootstrap response does not publish an explicit tenant_id field today.
Per ADR-0001, tenant_id is distinct from org context (activeOrg.id), so Sales should continue using the singleton tenant fallback (AUTH_TENANT_ID or SGUILD_TENANT_ID) as the intended interim source when resolving tenant context in the auth consumer seam.
This means no additional Platform-side auth shape is required for Sales to complete the AUTH_DEV_STUB retirement on the current interim.
References
- Follow-up ask memo:
2026-05-23-sales-auth-smoke-config-and-tenant-field-follow-up - Prior Platform clarification:
2026-05-23-platform-sales-auth-consumer-surface-ready-with-tenant-clarification - ADR-0001 tenant semantics:
coordination/adrs/ADR-0001-tenant-id-shape.md - Platform bootstrap route:
platform/modules/bootstrap/bootstrap.routes.ts - Sales auth seam:
sales/lib/auth/index.ts - Sales readiness smoke script:
sales/scripts/readiness-smoke.ts