Hydrate v0.8.0: every orchestration run is now a durable record.

An orchestration you can reopen

Until now an orchestration run was a live thing that left scattered traces. In v0.8.0 each run is a first-class, durable record. It owns its coordination and in-flight facts through an explicit ownership mapping, not a text prefix and not a project-id heuristic, so attribution is exact and teardown is complete. The two leaks that bit multi-fleet runs, orphaned in-flight rows and decayed mirrors slipping past the strength filter, are gone.

A worker's captured facts now mirror to exactly the orchestration its session is bound to, resolved server-side, never the global active pointer. Two orchestrations open at once can no longer cross-attribute. The close is durable and resumable: the archive document is written and re-read before any owned fact is deleted, and a close interrupted by a crash is picked up when the daemon next boots. Harvested canon that escaped into a target project is referenced, not retracted. There is a new hydrate orchestrator CLI to open, close, reopen, export, show and list them.

A measurable definition of done

Every mode now takes a structured acceptance block: a list of checkable criteria, by command, metric or judge, plus a goal-coverage gate, evaluated before a session can be accepted. This applies across all four modes, Design, Develop, Studio and Image. The point is to stop "looks done" from passing. A run is not accepted because it reads well; it is accepted when its own stated criteria verify.

If that idea sounds familiar, it is the discipline behind Karpathy's autoresearch, generalised from one held-out metric to a checkable contract for engineering and design work. We wrote about that lineage on the autoresearch comparison. v0.8.0 is where the acceptance block stops being an internal idea and becomes a gate on every mode you can run.

A coordinator that fails closed

The honest failure mode for a multi-agent system is not a crash. It is a session that quietly hangs while you assume it is working. v0.8.0 closes that gap. A flaky review or audit body no longer wedges a session in the integrating state: the audit fails closed, and a transient exec failure fails over, rebind then roster-exhausted then needs-human, with a clear reason rather than a hang.

The spawn cap moved from one daemon-global slot to per-project namespaces, an atomic test-and-set launch gate proven under the race detector, so work in one project no longer starves another on a shared cap. The defaults rose with it: per-project two to four, ceiling four to eight. After an upgrade Hydrate now surfaces a short what's-new notice and runs state-detected migration checks, and hydrate doctor --advanced gained rows for the orchestration layer, including incomplete-close detection and unattached sessions.

One known wrinkle

In the interest of saying so plainly: if you run orchestration fleets against a daemon started by launchd on macOS, the coordinator's git calls can hang when the launchd context lacks a login session, and the session parks rather than progressing. The memory layer is unaffected; this is specific to the orchestration coordinator's git write-path. The workaround is to run the daemon from a shell with hydrate start when you are driving fleets. A fix that primes the git environment for the launchd path is queued. The everyday memory-hook path needs no change.

Upgrading

brew upgrade hydrate, and you are done. There are no migration steps for the memory layer: the new orchestration tables are additive, and an older binary simply ignores them. If you do not run fleets, this release changes nothing you touch, and that is by design. If you do, every run you start from today is a record you can attribute, archive and reopen.