With a work ledger, the re-run made 2 proposals instead of 6 and no duplicates
An on-chain work ledger now exists on a branch, and a full re-run of the experiment with it in place came back with 2 proposals instead of run 1's 6. None were unneeded, against 4 in run 1. None duplicated other work, against 2. All four key results were reached. The run needed 1 human intervention instead of 3, and took about 3.5x the wall time. A written comparison records the two runs side by side.
The diagnosis behind the design: "The four problems you list are all one problem: the loop has no shared ledger of claimed work, only of deployed work, and no channel for a builder to report work it found." The decision was not to serialize everything: "Serialize along dependencies, and make the dependencies explicit." Under the spec, proposals register claims, and a structural gate rejects duplicates of claims that are still live. Milestone 0 comes first and publishes the interface. Work is scheduled by dependency, and builders get a channel to report gaps they find. The authoritative part of the ledger sits on chain. Large content such as interface source, gap reports and proposal bodies stays off chain, with its hash recorded on chain. The brief for this run also stopped handing over the mandate account interface, so the proposal that claims that work has to publish the interface in milestone 0 itself.
The design is written up as an ADR on the main branch. The implementation spec and the code are on a branch. The dry run against 12 acceptance tests reported all passing, with caveats on three of them, and 22 new ledger tests pass. Three hardening commits followed: the proposer is asked once more when its claims cannot be registered, milestone 0 caps its attempts, and ledger event scans run in windows of 2000 blocks. The re-run used a different model from run 1, with the same harness, objective and drills.
Some things are still loose. The full test suite shows 1 failing test, caused by a mismatch in the letter case of a check name, and it has not been confirmed whether that test also failed at base. The dry-run logs predate the hardening fixes, and some of those fixes were only typechecked. Cycle lengths of 1 to 3 hours and 600-second timeouts were flagged as fragile.
- WorkLedger: on-chain claims with a structural duplicate gateThe system
- Deploy the WorkLedger with the core and load its address in the daemonThe system
- Models from the environment, and the model on every reasoning recordThe system
- Agents see the work ledger: unclaimed work, declared claims, live-claim duplicationThe system
- Milestone 0: find the interface anywhere in the workspace, stub a missing INTERFACE.md, cap attemptsThe system
- Re-ask the proposer once when its claims cannot be registeredThe system
- Ledger event scans in windows of 2000 blocks; ledger-metrics scans only new blocksThe system
- How to prevent overlapping and duplicate proposals, and unscoped builder work, without serializing everything
- Serialize along explicit dependencies rather than serializing everything
- The ledger's authoritative part is on chain; large content stays off chain with a hash on chain
- The brief no longer hands over the mandate account interface; the claiming proposal publishes it in milestone 0
- The re-run used a different model from run 1, with the same harness, objective and drills
- 1 failing test from a check-name case mismatch; not confirmed whether it failed at base
- Dry-run logs predate the hardening fixes; some fixes were only typechecked
- Cycle lengths of 1 to 3 hours and 600-second timeouts flagged as fragile
- Work ledger code is on a branch, not merged