July 2, 2026

Vision — 15:22

I spent the whole day heads-down in the mechanics — pivoting off SST onto Vercel, wrapping the follows service as a Next.js app, scaffolding twenty-six service consoles, lighting a status board green tile by tile. Somewhere around the twenty-fourth service, stuck watching a TLS cert refuse to issue, I lost the thread of why. So I stopped, made myself look a few days out at the platform, and asked what “done” actually means.

The framing walking in was small and mechanical: get the services deployed, get the board all green, move on. A migration to grind through.

But when I imagined the sprint finished, what came into focus was bigger than a pile of deployed apps. It was a single thing with a name — the Ross environment. A fully functional loop-health, running end to end on Vercel, wired to real staging databases and every third-party service in test mode where test mode exists — test payments, the works — and real connections everywhere else. Not a demo. A place I can blast with data, stress-test, performance-test, break on purpose. And when something buckles, I drop into that one service, hack it, redeploy just that service, and retest the whole platform — with each service’s console right there telling me what’s actually happening.

The surprise was that the environment isn’t the point. The point is proof — that the whole infrastructure genuinely works end to end, all of it integrated, nothing faked. Because the moment that’s proven, it stops being a one-off. It becomes a template I duplicate: point prod DNS at the same Vercel instances, swap in prod environment variables, and it just works. This becomes the real pre-prod — the thing I’d call staging if the name weren’t already taken — the one I hand to William and say: here, a working full loop-health, and everything really works.

That’s where I’m headed.

Converge — 15:25

With the Ross-environment vision fresh, my pull went straight to the parts that feel like progress. Get all twenty-seven tiles on the status board green — chase the stuck certs, fix patient-graph. Or go the other way and start wiring the real integration: staging databases, service-to-service calls, the whole thing lighting up at once. Both feel like the sprint.

But that’s the trap again — polishing the surface, or reaching for the sophisticated integration, when neither is the first move. The consoles are sample-data façades; a green board proves nothing about whether the platform actually runs. And you can’t wire loop-health to anything until loop-health exists on Vercel — and it doesn’t. It has never once built there. Twenty-five workspace packages, sixty-odd env vars, WorkOS auth: the flagship has been the thing I kept routing around all day because it was hard.

So the domino collapses to something almost foundational. Not env. Not secrets. Not auth. Not the service wiring. Just get loop-health to build and deploy on Vercel — one URL that loads. The whole vision, the integrated environment, the duplicate-to-prod template — all of it is stacked on the flagship app running on Vercel. Prove the ground holds before I build the house on it. Everything after has somewhere to stand.

That’s my ONE Thing. Get loop-health to build and deploy on Vercel — a URL that loads. Everything else can wait.

Vision — 17:22

By late afternoon I’d wired three services into the Ross env — patient-graph, commerce, membership — all on a dev-only trust shortcut, and I kept feeling the debt. So before building the real thing, I made myself see it. I framed “real auth” the way I’d been building it: loop-health hands a service a signed ticket, the service checks it. Backend plumbing between machines. That was the whole picture walking in.

But when I imagined it actually finished, it got bigger than machines talking to machines. The service dashboards — the patient-graph console, the commerce console — those are publicly hosted Next.js apps. In dev and in prod. I don’t want random people rolling up to look at real data. So the same auth that guards a service’s API has to guard its dashboard too — and my own token, carrying admin/developer access, is what lets me in. Not a bolted-on second login system for the human surface; the same auth, shared code, one answer to “who are you and what can you do.” And I could sign in once and roam all of them — the systems knowing each other instead of making me log in over and over.

The real point came into focus underneath all of it. It’s not the identity service, and it’s not the tickets. It’s a truly centralized auth anchored in WorkOS — permissions defined in exactly one place, and respected everywhere: every service, every dashboard, machine-to-machine and human-to-dashboard alike. “What’s my auth? It’s in WorkOS.” And it’s honored across the whole ecosystem, seamlessly, no clunky re-logins. The identity service is just the bridge that carries WorkOS’s answer to every corner of the platform.

That’s where I’m headed.

Converge — 17:24

I was already elbow-deep in the identity service when I stopped — reading its token-exchange route, its Ed25519 signing keys, its argon2 M2M client registry, mapping out the meatiest wrap on the platform. My pull was to just build it: stand up identity.ross, get the token-exchange minting real tickets, wire the JWKS. That’s the impressive engineering, the thing that feels like real auth. And the other tempting shiny was the dashboard gates — WorkOS login on every console, my admin token roaming them all.

But both of those are surfaces that honor a permission. And the trap was reaching for the machinery before the thing the machinery reads even exists. A ticket the identity service mints has to say something. A dashboard gate has to check something. That something is a WorkOS-defined permission — and right now it doesn’t exist anywhere. I’d have been building an elaborate bridge to carry an answer I hadn’t written down yet.

So the domino collapsed to something almost embarrassingly small — not a service, not a wrap, not crypto. Just: go into WorkOS, define the admin/developer role and the permission it grants, and assign it to my own user. The single source of truth, seeded once. The moment it exists, my token carries it, and every surface after — the identity bridge, the service scope checks, the dashboard gates — has a real answer to honor. Define the truth before building the things that respect it.

That’s my ONE Thing. Define the admin/developer role + its permissions in WorkOS and assign it to my user. Everything else can wait.

Milestone — 18:54

Real auth is live on the Ross environment, both surfaces, proven end to end — not aspirational, not a shortcut, actually verified with real cryptography.

The path here had a real fork in it. WorkOS’s own M2M product looked like the obvious shortcut — same instinct that worked for human login, just point straight at WorkOS and skip identity. But I checked before committing: WorkOS M2M is built for external third-party access (an org_id claim, no per-service audience), not for an internal service mesh where patient-graph and commerce need to trust different things from the same caller. That’s precisely what identity’s token-exchange was designed to do, and it wasn’t overbuilt — it was the right tool for a problem WorkOS genuinely doesn’t solve.

So I built it: an Ed25519 signing key, identity’s own migrated schema, the real token-broker wrapped and deployed to identity.ross, a real M2M client registered for loop-health scoped to exactly three audiences. Then I flipped the trust shims off, one service at a time — patient-graph, commerce, membership — each now verifying real signed tickets instead of waving through anything with a Bearer header.

The proof mattered more than the build. A token minted for membership got rejected by commerce — real audience scoping, working. A garbage token got a clean 401. And when I wanted to be sure a write — not just a read — survived the whole chain, I minted a fresh ticket and pushed a real change into the intake record: the timestamp moved, the data was there on readback. Cryptographically verified, not just “should work.”

The dashboards close the loop from the other direction. One WorkOS sign-in, and all three consoles recognize me — the shared .ross cookie doing exactly what I asked for at the start of this: sign in once, not over and over.

That’s the milestone. Real machine auth and real human auth, both anchored in WorkOS, both proven — not by trusting the code, but by trying to break it and watching it hold.

Milestone — 21:19

Late tonight the proof of “genuinely works” got tested for real. The community feed had been up for hours when production started throwing “Failed to look up client” — under totally normal load, not a stress test, just people loading a page. For an environment whose whole point is proving the platform holds up under real conditions, that was the wrong kind of surprise.

The first move was the obvious one: throttle it. Lower each service’s own connection allowance, ship it, watch the error rate twitch down a little. It felt like progress — a real fix, deployed. But when I said out loud what I’d actually built, the question came right back at me: why isn’t this shared code every service uses? won’t we need it everywhere? That was the tell. I’d fixed a symptom in one place instead of asking what kind of problem this actually was.

It’s an old problem with a name: many services, one database, no coordination — and AWS already answered it for the real deployment, quietly, months ago. RDS Proxy sits in front of Aurora for exactly this reason, multiplexing a swarm of short-lived connections onto a handful of real ones. The Ross sandbox just needed the same shape, wearing Supabase’s version of the same idea. I didn’t take that on faith — I built a real load test, simulated forty services hammering the database at once, and watched the old setup fail nine times out of ten while the new one didn’t fail once.

Even having found the right fix, the old instinct didn’t fully let go — the throttle stayed in the config “just in case,” and it quietly turned into a real bug: a dashboard page that hung, waiting on a connection slot that never freed. It took getting called on it a second time before I actually pulled it out, everywhere, for good.

Six services are running the real fix now, proven end to end in production, not just locally. And the community console — the thing I’d been treating as a finished box to check — turned out to have more in it than I’d shown: reports, engagement, real communities, not just a table of posts. Proof compounds. The environment is a little more honest tonight than it was this morning.

Converge — 21:34

Status check tonight surfaced something I hadn’t fully registered: thirteen of the services loop-health leans on are actually done — real, deployed, stress-tested, wired in. The instinct was to look at what’s left and just pick up the next yellow square, and follows looked like the obvious one — already partially wired, just needs a real database behind it instead of fake data.

But before reaching for it, the question was worth asking: does it actually need to exist? And the answer was already written down. ADR-0083 settled this months ago — community.user_follows is the canonical social graph, services/follows is an orphaned split-brain nobody writes to, and the decision was explicit: retire it, don’t wire it back in. I’d been about to spend real effort resurrecting a store the codebase had already decided to bury.

The list of what’s actually left just got shorter, not longer. Two real gaps remain — content and entitlements, both called by loop-health but with no real Ross version behind them yet — and one fake gap I can cross off entirely. Check what’s already been decided before building it again.