openrig-upgrade

1# Upgrade OpenRig
2 
3An upgrade is an observed agent workflow, not a transaction hidden behind one
4command. Hosts differ, process state drifts, local plugin files accumulate, and
5the useful response to a failed step depends on what is still alive.
6 
7**The agent owns the sequence. Stop after every mutation and observe the actual
8effect before choosing the next step.** There is deliberately no end-to-end
9upgrade subcommand.
10 
11## Safety model
12 
13Keep these planes separate:
14 
15- Seats normally live in tmux and can survive a daemon restart.
16- The daemon, database, wrappers, and managed plugin projection are the control
17  plane being changed.
18- `rig down` tears down seats. It is not part of a continuity-preserving upgrade.
19 
20Before acting, name the rigs and seats whose continuity matters. On a production
21host, use the host's normal operator ceremony. On a recovery-friendly build VM,
22the orchestrator may adopt a tested runtime directly, but still observes each
23step and stops on unexplained drift.
24 
25## When recovery crosses an instance boundary
26 
27Before either lane changes runtime state, record one host-qualified executor and
28explicitly select the queue store that owns the recovery ruling. State whether
29the original owner continues, waits, or transfers; an open obligation in another
30store is not exclusive custody of this ruling. If the original store is down,
31retain its owner's disposition in the surviving ruling and communicate it to
32that owner before a competing executor acts.
33…