Board game v2 migration: one client, per-game runtimes
Sixteen board games moved to /v2 by sharing the client shell and splitting rules into stateless per-game services.
Every post I've published, newest first.
Sixteen board games moved to /v2 by sharing the client shell and splitting rules into stateless per-game services.
A GHA cache set to mode=max was spending 8 minutes uploading hundreds of MB of intermediate build layers every single run — to save 14 seconds of bun install. Removing it cut the docker job from 10+ minutes to under 2.
The chess-ai stack had 94 files and 104 tests but never produced a single trained model. This time we picked the smallest game, closed the loop in a day, and let an automation session find six design flaws on its own metrics trail.
This entire blog series was drafted by Claude inside a sandboxed pod; the sandbox got rebuilt three times — Docker, mitm plus credential proxy, then a K8s pod — to make that safe.
How I wired up a Claude agent that reads engineering task-logs and produces blog post drafts and GraphKnow wiki sources — then used it to write this post.
I shipped a polished document-RAG chat clone, never opened it, and pivoted to a personal LLM-maintained wiki — same data plane (Mongo / MinIO / Qdrant / Neo4j), different surface, four new entities, Slice 0 deployed.
An AlphaZero-style pipeline for the augmented chess engine ran into 512Mi pod limits, and the fix taught me the difference between liveness and readiness probes.
Six weeks of multiplayer bugs across three games converged on the same contract — deterministic appliers, atomic sequence allocation, server-owned identity.
A planned Google OAuth feature, the March 31 axios npm compromise, and a latent WebSocket subscribe hole — three different shapes, one rule: authorize at every join.
The games were always-on once min-scale flipped to 1, so the Knative tax stopped paying for itself; PR