Upgrade OpenRig

An upgrade is an observed agent workflow, not a transaction hidden behind one command. Hosts differ, process state drifts, local plugin files accumulate, and the useful response to a failed step depends on what is still alive.

The agent owns the sequence. Stop after every mutation and observe the actual effect before choosing the next step. There is deliberately no end-to-end upgrade subcommand.

Safety model

Keep these planes separate:

• Seats normally live in tmux and can survive a daemon restart.
• The daemon, database, wrappers, and managed plugin projection are the control plane being changed.
• rig down tears down seats. It is not part of a continuity-preserving upgrade.

Before acting, name the rigs and seats whose continuity matters. On a production host, use the host's normal operator ceremony. On a recovery-friendly build VM, the orchestrator may adopt a tested runtime directly, but still observes each step and stops on unexplained drift.

When recovery crosses an instance boundary

Before either lane changes runtime state, record one host-qualified executor and explicitly select the queue store that owns the recovery ruling. State whether the original owner continues, waits, or transfers; an open obligation in another store is not exclusive custody of this ruling. If the original store is down, retain its owner's disposition in the surviving ruling and communicate it to that owner before a competing executor acts.

A refused claim means reconcile ownership with the ruling owner before any further runtime action; it does not authorize continuing under a separate older row. A return names the full executor address and deliberately selected store. Read the resulting row there, including source, destination, body, and the original owner's disposition, before resuming. Receipt creation alone does not establish that a waiting lane received or accepted the transfer.

The loop

For every step: