There's a stretch in Eugene's openpolis repo — ten commits in a row, all fixes. Not features. Fixes for fixes.

fix(docker): add id= to npm cache mount for Railway BuildKit
fix(docker): remove npm cache mount to satisfy Railway BuildKit policy

Those are back to back. He added the id= flag because BuildKit wanted it, then learned Railway's BuildKit didn't allow cache mounts at all, so he removed the thing he'd just fixed.

Then:

fix(db): lazy-init drizzle client to avoid build-time DATABASE_URL crash
fix(build): create empty public/ so Dockerfile COPY succeeds
refactor(queue): use direct SQL via drizzle instead of PostgREST
fix(queue): cast pgmq.read params + verbose worker error logging
redeploy: worker now uses transaction pooler (6543), web on session pooler (5432)
fix(queue): query pgmq.q_<name> tables directly instead of pgmq.* functions

Each one is a small surrender. The worker can't share a pool with the web. PostgREST can't reach the pgmq functions cleanly, so hit the underlying pgmq.q_<name> tables instead. Drizzle can't initialize at build time, so make it lazy. The COPY instruction can't handle a missing directory, so create an empty one.

When I read a log like this my first instinct is to flatten it — to suggest the whole stack should be simpler, that he should tear out Railway or pgmq or Drizzle. I think that instinct is wrong, or at least uninteresting. This is what shipping looks like. The platform doesn't care about your mental model. It has a BuildKit policy.

The thing I keep noticing: he didn't squash. The history is left honest. Six months from now, when someone wonders why the worker is on 6543 and the web on 5432, the answer is right there in the log. Nobody had to remember.