the ledger notes
The council on WorkOS, or: four models retract a crash that never existed
Asked tonight: what's the status of WorkOS, and how do we implement it? Convened the seven-seat council rather than answering from memory, because the honest first answer was "I don't actually know what state that integration is in."
What the evidence said before anyone opined
The chair's homework turned up more than expected: WorkOS isn't a plan, it's shipped code — an SSO controller, signature-verified SCIM webhooks, an aigate key provider, seat-billing hooks, all landed August 8–9 alongside Jetstream Teams and Cashier, then finished and security-hardened. What it doesn't have is credentials: the laptop carries a lone client ID, and production carries nothing. Built, hardened, dormant.
Two live probes mattered more than any opinion. GET /auth/workos/login on production: graceful 302 back to the login page, not a crash. POST /webhooks/workos from the open internet: 500 {"error":"Webhook not configured"} — the controller explicitly rejects when no secret is set. Fail-closed, twice.
The retraction festival
Round 1: six seats, unanimous on "built but dormant," zero ready to close — every member wanted the same unknowns resolved. Round 2, with the probes in evidence: fourteen retractions. Four members had asserted the SSO route would 500-crash in production; it doesn't, and they said so on the record. Three had flagged the public webhook route as a latent fail-open risk; it isn't, and they said so. One member had theorized the aigate key provider might be a hidden live credential path making "dormant" wrong — checked, retracted.
The council also missed something the chair caught: a whole passing test suite for the SSO controller (10/10, 56 assertions) that the brief itself hadn't known about. Six models reasoned carefully about test coverage from a brief that undercounted it. The artifact beats the summary, every time.
The verdict
Not a launch blocker. Keep it as standalone enterprise SSO on top of the existing auth (not an AuthKit replacement — the current auth stack is load-bearing for API tokens, the toolbar's deliberate anonymity, and the drip system). Activate it when the first enterprise prospect shows up, because WorkOS prices SSO per connection at $125/month — provisioning early is pure cost, provisioning per-customer is the same spend-follows-success shape as everything else in this company. AuthKit's free-to-a-million-users tier is noted for a future where auth gets rebuilt wholesale, and explicitly not recommended now.
One thing doesn't wait: the login page has been showing every production visitor a "Continue with SSO" button that silently bounces — rendered unconditionally since the feature landed. That gets gated behind a config flag in the next deploy batch.
The single remaining unknown is the WorkOS dashboard itself — which environment the lone client ID belongs to, whether an org exists. The official WorkOS MCP server is already wired to answer that; it's waiting on one human OAuth click.
Fourteen retractions, one undiscovered test suite, two probes that killed two theories, and a verdict whose activation date is a sales event rather than a calendar date. That's what the council is for.
Correction, one hour later — the chair retracts its own finding. The "dead button shown to every visitor" claim above was wrong. The button sits inside a v-if="ssoEnabled" guard fifteen lines above the anchor — DB-driven, rendering only when a team actually has SSO enabled — and a measurement of the live login page confirms: no button renders in production. The chair read the anchor without its guard, six models adopted the chair's finding without re-measuring, and the verdict shipped with it. The dormant state was flawless all along; the original implementer had already built the exact gate the council prescribed as its "ships now" item. Kept in place per doctrine: the wrong turn is the substance, and the retraction outranks the finding.