ba300db5 · zzmq.dev@gmail.com/zz
Commit
ba300db5064f69b8b8505fd8c89738e7ca0119c1
Greenfield test (scenario 1): real organic development through the protocol Two related repos, built from scratch, entirely through real Lane/Ask/ Answer/Ladder protocol calls -- numkit (a small numeric utility library: clamp, average, isPrime, with a real bug introduced and later fixed) and numkit-cli (a real consumer, depending on numkit, that has to adapt when numkit's fix changes behavior). 8 real increments total, each one drafted and tested locally first, then submitted and merged through the actual protocol. Every increment verified by checking out the real commit to a disposable git worktree and running the real test suite (13 numkit tests, 5 numkit-cli tests, all passing), plus the real CLI binary executed directly, including the cross-repo npm dependency actually resolving. No write_file tool, no working-tree file ever needed for a submission: engine/changeset.ts's commitChangeset constructs a real commit directly from in-memory content (isomorphic-git's writeBlob/writeTree/ writeCommit/writeRef plumbing), the same way a Worker will eventually have to, since Workers have no persistent working tree either. The file content lives entirely in the submit_changeset ask's payload, the same way a Rung already carries its own full content -- granting that ask is what actually commits it, mirroring how granting a merge_request is what actually writes the Ladder. Also models the real cross-repo dependency directly: numkit-cli's "handle average's empty-input error cleanly" Lane sets its origin to numkit's own "fix-average-empty" Lane (a different repo), not its own _repo -- the same cross-repo mechanism the project's cascade design has described since the start, now actually exercised for the first time by a genuine cause-and-effect case. This test surfaced a real, significant bug: _repo's git-notes anchor was the current/HEAD tree sha, which changes on every commit. Every new commit orphaned the previous _repo note and started a fresh, disconnected one, silently losing every previously-registered child. This never showed up in onboarding-only usage (HEAD never moves after the initial write), only in live, forward-going development -- exactly what this test was built to exercise. Fixed by anchoring _repo to the repo's root commit instead (stable for its whole life), matching how ask/contributor/dependencies already do it. Migrated supertest's and bsharptree's existing _repo notes to the new key by hand (byte-for-byte, 1056 and 9 children respectively, content untouched) rather than risk a naive re-onboard silently replacing supertest's hand-researched file tree with a mechanical one. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Troy Howard <thoward37@gmail.com> -- 2026-10-10T03:38:56.000Z