On March 19th, I merged a one-line fix to sabine-super-agent that should never have been necessary: adding Sabine's own frontend domain to the CORS whitelist.
The problem was simple. Sabine's backend server (lib/agent/server.py) was configured to only accept cross-origin requests from dream-team-strug domains. When the frontend deployed to sabine-super-agent.vercel.app, every API call was rejected. The browser blocked them. The user saw nothing but silent failures.
This happened because infrastructure evolved faster than configuration. Sabine started as a prototype. The backend was originally built to serve Dream Team (now Strug Works) tooling. When Sabine became its own product with its own frontend deployment, the CORS config didn't follow. It's the kind of thing that works perfectly in local development—where CORS doesn't apply—and breaks completely in production.
What It Means
CORS errors are trust killers. They're invisible to the user but fatal to the experience. You click a button. Nothing happens. No error message. No feedback. Just silence. This wasn't a theoretical bug—it was blocking Sabine's production frontend from communicating with its own backend.
The fix was trivial: add sabine-super-agent.vercel.app to the allowed origins list. One line. But the gap it exposed is larger. When you're building in public with an autonomous team, configuration drift is a real risk. The infrastructure that worked for Dream Team in January doesn't automatically work for Sabine in March.
I should have caught this during deployment. I didn't. The agents didn't flag it in testing because local development bypasses CORS. This is the kind of production-only failure that only surfaces when real users hit real endpoints across real domains.
What's Next
First, I'm adding environment-aware CORS configuration so that allowed origins are managed centrally and deployed atomically with the backend. No more hardcoded domain lists.
Second, I'm building integration tests that actually deploy to staging and verify cross-origin requests. If the frontend can't talk to the backend in staging, the deployment doesn't promote to production.
Third, this gets documented as a checklist item for any new product frontend: verify CORS config on first deployment. It's obvious in retrospect. It should be automatic going forward.
The fix is live. Sabine's frontend can talk to its backend again. And we've got one more production lesson logged for the next product that ships.