4f9afe8d · zzmq.dev@gmail.com/zz
Commit
4f9afe8da6d171e07979c13f4ff9ec2adfec86e7
zz work against a deployed Worker, remote by default The real coordination-layer demo: `zz work` now drives the actual protocol (claim, propose, test, review, commit, Ladder write) against real Lane/Ask/Ladder state on the deployed zz-maintainer Worker, not just a local .zz/ directory. Remote is the new default; --local keeps the original behavior fully intact for the demo/cascade-case-study path, which has no reason to touch the network. Architecture, settled after tracing exactly what zz work's code touches (agent/scriptedWork.ts, agent/loop.ts, engine/workqueue.ts): mutations (ask_claim/ask_post/ask_answer/commit_changeset/ ladder_write_rung/lane_propose) are proxied as whole tool calls to MaintainerDO.callTool via a new generic POST /api/repos/:owner/:repo/ tools/:name route (webApp.ts) -- the real atomic Lane mutation (storage.transactionSync-backed withLane) only exists server-side, so reconstructing it client-side would race against other agents working the same repo concurrently. Reads go through a new, deliberately minimal client-side RemoteBackend (cli/lib/remoteBackend.ts) whose write methods throw loudly rather than silently doing something non- atomic. agent/loop.ts gained an `executeTool` override and agent/ scriptedWork.ts's local callTool helper became swappable per call (default local, remote when zz work passes one) -- run_in_sandbox is never proxied either way, it's inherently local. A new lane_list tool (agent/tools.ts) exists so RemoteBackend.listLanes can reuse the tool- call surface instead of a bespoke endpoint. cli/lib/repo.ts's ensureCloned clones via the zz git-proxy (not GitHub) in remote mode, with a syncClone fast-forward before each claimed ask (other agents' commits land on the real remote, not this local working copy). The server-side tool-call route checks that a caller-supplied actor/from field matches the authenticated token's own agent id -- a valid token can't act as a different agent just by naming it in the payload. Verified live end to end, twice, against two real repos on the deployed Worker: a brand-new repo (exercising ensureRepoLaneRemote's full from-scratch bootstrap -- lane_propose, review_request/grant, the Ladder's root rung, all confirmed correct via lane/ladder reads afterward) and a repo whose root Lane already existed. Posted a real Ask, ran `zz work` in the background, watched it claim the work ask, generate a proposal with a local Ollama model, verify it in a real sandbox, post for changeset_review, approve it, commit the real change to the Artifacts repo, and write the Ladder -- confirmed the committed file content and the Ladder's file rung directly against the live repo afterward. Test repos cleaned up after. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Troy Howard <thoward37@gmail.com> -- 2026-10-12T05:32:19.000Z