Coding agents stop mid-task. Our coordination store had 3,896 stale conflicts

Foremerge records what each coding agent plans to change before it edits anything, and raises a finding when two plans cannot both be true. That only works if the record is current. Version 0.6.0 fixes the way it was not.

Agents stop without saying goodbye

An agent session ends without closing its intent far more often than you would guess. A context window fills up. A laptop lid closes. A scheduled run reaches the end of its slot. The intent the agent published stays open, its claims expire, and nobody closes it.

Foremerge treated that abandoned work as live. Every later intent on the same files was compared against it, and each comparison that found something was recorded. One of our own repositories, where scheduled agents and interactive sessions share a single coordination store, reached 3,896 open conflicts, 98% of them with no live agent on either side. A new intent on a busy file opened with about 40 recorded against it, and the ones worth reading were buried in the ones that were not.

This is a problem you only get from running several agents at once over a long period. One agent, one session, and the record stays tidy by accident.

What 0.6.0 changes

• A finding below HIGH against work whose agent has stopped is no longer recorded. An intent counts as stopped under the same test work adopt already applied: it sits in INTENT, CLAIMED, IN_PROGRESS or PROVISIONAL, it holds no live claim, and its agent has made no Foremerge call for two hours.
• Stopped work is still listed in related_work, last, marked with owner_stopped_since, and needs no assessment. Another agent can see it there and adopt it. A what-if check_conflicts applies the same rule and names what it left out under stopped_work.
• Nothing is lost if the agent was only quiet. Its next call, an adoption of its work, or a check that validates it records the findings that were skipped in the meantime. Pairs already on record are left alone, settled or not.
• The agent skill and the discard_work description now tell an agent to close its intent before it stops. Work that reached Git without going through acceptance, because no named check is registered or a maintainer committed a batch by hand, can be closed with foremerge work discard --landed REF.

Why HIGH findings are still recorded

HIGH findings gate acceptance, and an agent that was only quiet must not lose that protection. So the gate is unchanged. A stopped intent whose declared plan genuinely contradicts yours still asserts, and you still have to deal with it before your ChangeSet is accepted. The rule only removes the advisory noise underneath that line.

What you see now

Before, a new intent on a crowded file came back with a long list of recorded conflicts, most of them against intents whose agents had been gone for days, and nothing in the list told you which was which. Now the same intent comes back with the live findings only. The stopped work is still there at the end of related_work, each entry carrying owner_stopped_since with the time its agent went quiet, so you can see what was set aside and pick it up if it is worth finishing.

Conflicts already on record are not touched by the upgrade. To clear a backlog like ours, close the stopped intents.

The migration change

Foremerge used to migrate a ledger's schema as a side effect of opening it, and every command opens the ledger, including the ones that only read. A status run by a newer binary from the wrong directory migrated a real repository's shared coordination store and locked every older client out of it.

Foremerge no longer migrates on open. A command that meets an older ledger refuses it with MIGRATION_REQUIRED and leaves the file exactly as it was. foremerge ledger migrate does the migration and nothing else does: it refuses to run while another process has the ledger open, copies the ledger with its WAL contents into a timestamped backup directory, checks the copy's integrity, migrates, and prints how to roll back. Without --yes it only reports what it would do.

The schema itself has not changed since 0.4.0, so upgrading from any 0.4.x or 0.5.x build needs no migration and both versions read the same store. Only a ledger last opened by 0.3.x needs the step. This is why 0.6.0 is a minor version rather than a patch.

Installing it

curl -fsSL https://foremerge.com/install.sh | sh

That installs a checksum-verified release binary on macOS and Linux. On npm, which also covers Windows x64:

npm install -g foremerge

The full list of changes is in the 0.6.0 release notes.

The general lesson

If you are building coordination for agents, the failure mode to design for is not the agent that disagrees with another agent. It is the agent that never comes back. Human collaborators close their tickets, eventually, because somebody asks them to. An agent whose process exited has no such pressure, and a store that assumes otherwise will slowly fill with work that nobody is doing and nobody will ever withdraw.