46eb8347 · zzmq.dev@gmail.com/zz
Commit
46eb8347223ea4efd404a116a07cde0ab122ac94
Backend step 3: real Lane/Ask/Answer storage on a Durable Object, proven live Step 3 of site/content/remote-backend/index.md's build sequencing: Lane/Ask/Answer storage on the Worker/DO's own SQLite backend, proposeLane/ask/answer round-tripping against it. The key realization building this: after step 1's refactor, engine/lane.ts's ask()/answer()/proposeLane() already call resolveBackend() internally rather than taking a storage path directly. That means a Worker never needs to reimplement the protocol's RBAC checks, the changeset_review gate, or the embedded-files guard -- app/worker/src/MaintainerDO.ts calls engine/lane.ts's real functions completely unmodified, just scoped to its own ctx.storage.sql-backed Backend (doLaneBackend.ts) via engine/backend.ts's new withBackend() (AsyncLocalStorage -- verified directly it correctly isolates concurrent contexts inside workerd, needed since one isolate can host multiple DO instances for different repos). Fixed a real bug this surfaced: engine/backend.ts used to import localBackend.ts unconditionally, which touches import.meta.url and node:fs at module scope and crashed the Worker immediately on load ("Received undefined, at fileURLToPath") even though the Worker never calls into it -- esbuild still bundles an unconditional import's module body regardless of whether it's ever invoked. Replaced with registerLocalBackendFactory(), called once at CLI startup (cli/zz.ts, demo/greenfield.ts); the Worker never registers one and never imports localBackend.ts at all, so it's not in that bundle. Verified live against the real deployed Worker: proposeLane -> ask -> claim -> answer complete, read back in a SEPARATE, later HTTP request (not just within one call) -- confirming real persistence on the DO's storage, not just in-memory state for the lifetime of one request. Deliberately not yet implemented: git content (commitChangeset, the Ladder) on this DO -- that's step 4, alongside the tool-surface HTTP routes, since by then there's a real reason to key it per-repo rather than building it in isolation.
Troy Howard <thoward37@gmail.com> -- 2026-10-11T10:52:41.000Z