ea78156d · zzmq.dev@gmail.com/zz
Commit
ea78156d28f6731702e76155094061595a424ed7
Backend step 4: the Ladder (git notes) on Artifacts, proven live Completes the piece flagged as genuinely harder than the changeset commit: the Ladder's git notes against a real Artifacts repo. Confirmed empirically first, before writing any real code: the native ARTIFACTS binding's read methods (log/readCommit/readTree) only resolve the default branch -- a notes ref returns an empty log no matter how it's spelled (refs/notes/x, notes/x, with or without the refs/ prefix). Notes need isomorphic-git for both reads and writes, unlike regular commits where reads go through the native binding. Unlike the main branch, though, a notes ref's own history is small -- one commit per past Ladder write, not the project's full development history -- so a real, scoped `git.fetch` of just that one ref is cheap regardless of how large or old the repo gets. No reason to hold it to the no-clone constraint the changeset-commit path needed that constraint for. cloudflareLadderBackend.ts's scopedNotesCheckout does exactly that: git.fetch with ref/remoteRef both set to the notes ref, singleBranch, tags off; the fetch's returned `fetchHead` has to be written to the local ref manually (fetch doesn't do this itself, confirmed directly), after which isomorphic-git's own addNote/readNote just work -- no custom tree reconstruction needed, since the relevant objects are now genuinely present locally. Scoped to what agent/scriptedWork.ts actually writes: "file" rungs (anchored to a path's blob at HEAD, resolved via the native binding) and "changeset" rungs (anchored to the commit itself, with "filechange" children embedded inline, matching engine/ladderNotes.ts's own anchor rules) -- not every rung kind that module handles locally. Verified live, including the one case that actually matters: two separate file rungs, written via two independent repo handles/tokens (simulating two separate requests), both survive on the same notes ref afterward -- confirming the scoped-fetch-before-write genuinely prevents clobbering, not just that a single write works. Every genuinely risky unknown in site/content/remote-backend/index.md is now resolved with real evidence. Remaining: fold doLaneBackend.ts + cloudflareGitBackend.ts + cloudflareLadderBackend.ts into one Backend-conforming CloudflareBackend class, and the tool-surface HTTP routes so `zz work` itself can point at a deployed Worker.
Troy Howard <thoward37@gmail.com> -- 2026-10-11T13:12:58.000Z