959b61ce · zzmq.dev@gmail.com/zz
Commit
959b61ce14fd2a65b11c9854e32e646a34caedc9
Drive "work" and "submit_changeset" asks from code, not model tool-calls Both ask kinds share one root cause of real observed failures this session: asking the model to assemble a large, nested tool-call argument (a files array with multi-line content, or a Ladder rung tree) in one shot, then trusting it to both get the JSON right and remember the right sequence of calls. Concretely hit: Groq rejecting malformed tool-call JSON outright on gpt-oss-120b, and a model skipping the submit_changeset step entirely to shortcut straight to answering "complete" with files embedded in the payload. agent/scriptedWork.ts never hands the model a tool for these two ask kinds. It only asks for plain text -- file content in fenced code blocks, flat summary strings -- the one thing every model is reliably good at regardless of size or price tier. The code parses that deterministically and drives every protocol step itself in a fixed order: claim, sandbox-verify, post submit_changeset, commit, write both Ladder rungs, answer. The model supplies judgment (what the code says, how to describe it); the code supplies structure and sequencing. Verified live: the exact gpt-oss-120b task that previously failed with malformed tool-call JSON (two new files plus edits to a third) now completes cleanly end to end -- one commit, correct content, real sandbox-verified tests, both Ladder rungs written. Also: every ChatBackend now omits the `tools` field entirely when given an empty array instead of sending `tools: []`, which Groq (confirmed) and likely others reject outright -- needed for scriptedWork's plain-text, no-tools generation calls. Every other ask kind is unchanged, still served by the generic tool-calling loop in agent/loop.ts.
Troy Howard <thoward37@gmail.com> -- 2026-10-11T08:30:17.000Z