pi-dispatch v1.8.0
Multi-host is complete: forge deliveries route to the machine that can serve them, and the run history is merged across hosts. Together with 1.7.0 this closes issue #57.
Forge deliveries now go where they can run
Two trigger fields bind a job to a machine rather than a repository: run.secretsProfile names a resolver on one host's disk, and a run.waitFor condition names a check script on one host's disk. Before, whichever worker happened to pop the delivery decided whether it ran. Both refusals are returned and never retried, so the same trigger succeeded or failed by chance, permanently, and the message read like a configuration error rather than a placement one.
The receiver reads the host registry at enqueue and picks a queue. It abstains, and stays on the shared queue, whenever the delivery binds neither field, every live host can serve it, no host can, or the registry cannot be read. Declaring the same profiles on every host is still the better shape, and that deployment is unchanged.
The run history is merged
Each worker still writes its records to its own disk and now also mirrors them into Valkey, so every panel lists the whole deployment's runs, labelled by the host that produced them. The files stay the record. The mirror is a view of them and is never allowed to outlive them: its retention is the shorter of your PI_LOG_RETENTION_DAYS and ninety-two days.
If Valkey is unreachable the panel shows this host's runs and says RUNS · this host only, rather than quietly presenting a fraction of your deployment as all of it.
/dispatch logs for a job that ran elsewhere now names the machine it ran on. The raw log itself never travels: it is the one artifact holding issue text, comment text and tool output, and it stays on the host that wrote it.
Still worth reading before you turn it on
docs/multi-host.md, and trap 3 in particular: never share PI_SANDBOX_DIR. The sandbox reaper asks the local docker which sandboxes are live before deleting anything, so on a shared directory one host cannot see that another's sandbox is in use. Nothing detects it, and the reason is worth knowing: a marker file in that directory is exactly what the reaper deletes.
Sharing PI_LOGS_DIR remains a real option and merges more deeply than the mirror does. It also shares the raw logs, and turns a mount outage into a lost record. Both shapes are documented.
Version floor: worker 1.8.0, admin 1.8.0, receiver 1.5.0. A worker below the floor does not publish itself, so the others cannot see it, it will not route its own work, and its runs appear only on its own panel.