Journal

redcorsair day: 36 viz scripts, brand tokens, MCP-to-SSE plumbing

voice-generatedtechvisualizationmcp

Signal

25 sessions, 315 minutes of wall-clock, $67.07 spent. This is a real workday, not a scouting one. Of those, 16 sessions and 299 minutes went into redcorsair, where the brand-token system and 36 viz scripts landed together. The diff is +43,930 / -122,401, which means three times more lines deleted than added. The shape of the day is clear: consolidate first, then extend.

Evidence

redcorsair (11 commits, +43,930 / -122,401): the brand token system shipped alongside 36 viz scripts and a unified quality validator. On the infrastructure side, ASGI middleware now rewrites /mcp to /mcp/ without the 307 redirect that was breaking clients. OAuth client registrations persist across restarts now, with debug logging on the full dance so future failures will be traceable. I pinned mcp==1.10.1 to stop version churn and disabled DNS-rebinding protection in local dev because it was blocking loopback tool calls. A comprehensive README with example outputs landed, plus a CLAUDE.md project guide so the next agent session can orient without me re-explaining.

pirate_ship (2 sessions, 6 minutes): a minor side trip. Opus 4 ran briefly here for 3,875 tokens, which suggests a quick architectural question, not feature work.

So What

Consolidate then extend is the pattern this day encodes. Deleting 122K lines of accumulated noise and then shipping 36 new scripts on top of a unified validator is the right sequence. If you try to ship the scripts first, they inherit the chaos of the old scaffolding and you spend the next month unpicking edge cases. If you consolidate first, the new scripts land on a predictable surface and the validator catches regressions immediately.

The MCP 307 redirect fix is the kind of four-line change that unblocks a week of flaky tool calls. Clients that follow redirects work fine. Clients that do not silently drop the request. Rewriting the path in middleware before the redirect fires is strictly better, because it removes an entire class of intermittent failures that look like timeouts in logs but are actually routing bugs.

Pinning mcp==1.10.1 while OAuth client persistence lands is unglamorous work. It is the kind of fix that does not generate a headline but that makes every subsequent run reproducible. When OAuth state evaporated on restart, every fresh session had to re-authorize, which meant I could never trust that “it worked yesterday” carried over. With persistence plus a pin, yesterday’s setup is still there this morning.

What’s Next

Does the unified quality validator survive the next regeneration of 36 scripts, or does it drift inside a week? A validator that works on the first batch but silently diverges on the second is worse than no validator at all, because it gives false confidence. I want to see it catch a real regression next time I touch the script generator. If it does, the consolidation was real. If it does not, the validator is a lint suite with aspirations.

A secondary thing I want to watch is whether the OAuth persistence fix holds across real restarts. It is easy to build persistence that works in the happy path and breaks under any slightly unusual condition: a crash mid-auth, a clock skew, a stale token. The only way to know is to keep running and see what shakes out. If it survives a week of daily restarts without re-authorization, I will consider it done.

The 3-to-1 delete-to-add ratio is worth treating as a target, not an accident. Any time a day’s net diff is more deletion than addition, I know the work was load-bearing cleanup. That shape of day is rarer than it should be, and it is the one that leaves the codebase in better shape than it started.

Log

  • Sessions: 25 across 3 projects, 315m total
  • Top projects: redcorsair (299m), misc (Documents) (10m)
  • Commits: 11 across 1 repos (+43,930 +, -122,401 -)
  • Models: mostly Haiku 4.5, Opus 4 for heavier redcorsair blocks
  • Cost: $67.07