27474374 · zzmq.dev@gmail.com/zz
Commit
27474374477849e443017a40a1e7d4af5fa00265
Rebuild the ASK/ANSWER protocol as a real payload/dependency work queue Ask/Answer entries now carry a stable random id, a kind-specific payload (what's being asked for or granted), and an optional depends_on list of other ask ids that must be answered first. Ids are random (crypto.randomBytes), never a sequential counter -- a shared counter is exactly the kind of contended state that breaks once multiple actors read/write the same queue concurrently, which this is explicitly headed toward. Adds engine/workqueue.ts: claimableAsks (every unanswered ask whose dependencies are met and whose kind's scope -- coordinator-only or open -- the actor is permitted to act on, sorted by priority), claimAndAnswer (the claim/grant/work/complete round trip, granting as the lane's actual coordinator rather than self-echoing the claimant), and runWorkerLoop (repeatedly claims and handles the next claimable ask until the queue drains). Rewrites ladder-replay-commits.ts on top of this: one ingest_repo ask kicks off a replay-session Lane, which posts one analyze_changeset ask per commit; each spawns its own Lane posting add_filechange asks per file plus a summarize_changeset ask that depends on all of them; once a changeset Lane's queue drains, it fires a merge_request (carrying the built Ladder as its payload) and a per-file rung_update_request at the repo Lane's own queue and moves on without waiting -- the repo Lane is the only thing that ever calls mergeLaneLadder/writeLadder, and only once its own worker loop gets around to those asks after ingest_repo returns. Fixes a real bug found while testing: ladder-build.ts and ladder-replay-commits.ts each assumed a different identity ("zz-local" vs "zz-coordinator") as the repo Lane's coordinator, so whichever command created the `_repo` Lane first fixed its coordinators list to the wrong identity for the other command's own coordinator-scoped asks, silently stranding them unanswered. Both now agree on COORDINATOR for the repo Lane specifically. lane-log.ts now prints each ask/answer's id, payload (summarized), and depends_on, which is what makes the dependency ordering and the deferred repo-level merge processing visible in the log at all. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Troy Howard <thoward37@gmail.com> -- 2026-10-08T05:58:09.000Z