@openrig/cli 0.5.7 → 0.5.9

package/daemon/specs/agents/shared/skills/core/openrig-upgrade/SKILL.md

@@ -1,404 +1,250 @@
 ---
 name: openrig-upgrade
-description: Use when upgrading the OpenRig CLI/daemon on a host with running rigs, especially when preserving tmux-backed agent sessions through a daemon restart or documenting hot-upgrade SOP evidence.
+description: Use when an agent is preparing or performing an OpenRig CLI/daemon upgrade and must preserve live seats, verify each mutation, or reconcile managed plugin and skill files without overwriting local work.
 metadata:
   cli_surfaces_referenced:
     - capture
-    - daemon adopt-state
     - daemon start
     - daemon status
     - daemon stop
-    - down
+    - plugin list
     - ps
     - restore-check
     - snapshot
-    - up
-    - upgrade backup
-    - upgrade preflight
-    - upgrade promote-runtime
-    - upgrade verify
     - version
   openrig:
     stage: factory-approved
     sibling_skills:
       - openrig-user
       - openrig-operator
-      - openrig-builder
-      - openrig-architect
       - forming-an-openrig-mental-model
-      - ai-dev-workflows
 ---
 
-# OpenRig Upgrade
+# Upgrade OpenRig
 
-## Core Principle
+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.
 
-OpenRig has two different failure domains:
+**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.
 
-- **Agent process plane:** Claude/Codex/terminal seats running inside tmux.
-- **Management plane:** the OpenRig daemon, CLI, SQLite DB, transcripts, node inventory,
-  send/capture APIs, restore metadata, and migrations.
+## Safety model
 
-A hot daemon upgrade is possible when the continuity seats remain alive in tmux and
-the new daemon restarts against the same DB and transcript root. Do not run
-`rig down` on continuity rigs unless the goal is a disruptive restore test; `rig down`
-kills OpenRig-launched tmux sessions.
+Keep these planes separate:
 
-## Preferred Live-Cutover Operator Mode
+- 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.
 
-For live production daemon cutovers, prefer an **out-of-band upgrade operator**:
-a temporary host-local tmux seat outside the managed OpenRig topology, spawned
-from the lifecycle/runtime-upgrade agent's current mental model.
+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.
 
-Why: the managed rig stays in the agent process plane while a disposable sidecar
-mutates the management plane. The sidecar inherits enough context to avoid a
-cold handoff, but it is not inside the failure domain it is modifying.
+## The loop
 
-Use this when all are true:
+For every step:
 
-- the upgrade mutates the live daemon, CLI wrapper, DB, runtime worktree, tmux
-  lifecycle, or active control-plane truth;
-- continuity seats should keep working during the upgrade;
-- a lifecycle/runtime-upgrade seat has already prepared the packet or owns the
-  needed context;
-- the human has granted an `operator auto window`.
+1. **Inspect.** Derive current facts from the live host.
+2. **Decide.** Choose one bounded mutation and state its expected effect.
+3. **Act once.** Do not bundle the next mutation with it.
+4. **Observe.** Check the process, listener, database, plugin, and seat surfaces
+   that the step could have changed.
+5. **Continue, adapt, or stop.** A failed expectation is information for the
+   agent, not permission for a blind retry.
 
-In this SOP, `operator auto window` means a bounded operator-authorized upgrade lane. It does not
-mean standing Codex `auto_review`, `--full-auto`, or approval-bypass mode. Use
-`security-and-consequence-boundary-policy` skill for the current
-security and consequence-boundary policy.
+## Bounded helpers
 
-Do not use this pattern as a standing orchestration seat. The sidecar exists for
-one cutover and then closes after handback.
+Let `SKILL_DIR` be the directory containing this `SKILL.md`. These scripts emit
+JSON and do not decide the upgrade sequence.
 
-### Sidecar Contract
+### Inspect current facts
 
-The in-rig lifecycle/runtime-upgrade seat owns packet preparation and final
-interpretation. The out-of-band sidecar owns only execution inside the approved
-window.
-
-Sidecar starter prompt shape:
-
-```text
-You are the host-local OpenRig runtime upgrade operator, outside the managed rig
-topology. Execute the approved daemon-only cutover only after explicit human
-approval. First read the upgrade preflight artifact and runtime-upgrade
-decision. Prove you are outside the topology before mutation. Never run rig
-down. Preserve tmux topology. Stop/start only the daemon, verify protected rigs,
-write cutover evidence, unblock downstream artifacts only when the blocker is
-truly closed, and rollback to <previous-wrapper-or-commit> if needed.
+```bash
+node "$SKILL_DIR/scripts/inspect-upgrade.mjs"
 ```
 
-Required handback:
-
-- write the live cutover evidence under the lifecycle evidence shelf;
-- include proof that the sidecar was outside the topology/failure domain it
-  mutated;
-- update any blocked downstream dogfood/runtime task only when the blocking
-  condition is truly closed;
-- preserve caveats as downstream material instead of using them to reopen a
-  closed cutover gate;
-- report back to the in-rig lifecycle/runtime-upgrade seat or orch surface with
-  daemon provenance, topology verification, caveats, rollback state, and one
-  compact paragraph of operator judgment about ambiguous choices;
-- close the sidecar after the original lifecycle owner has absorbed the result.
-
-Stop conditions for the sidecar:
+This asks the installed `rig` for its version, daemon status, node inventory,
+and plugin inventory. A missing surface remains visible with a suggested next
+probe. `ready: false` means the agent must resolve or consciously bound the gap;
+it does not mean the script should mutate anything.
 
-- preflight or runtime-upgrade decision is missing;
-- human approval is absent or narrower than the requested cutover;
-- protected topology is already degraded beyond the packet's expected caveats;
-- target runtime cannot be verified by process path, port listener, and command
-  evidence;
-- any step would require `rig down` or destructive DB restore without a new
-  explicit human decision.
+### Back up SQLite
 
-Generic primitive: this upgrade specialization composes over the
-`sidecar-operator` skill (the underlying out-of-band-operator pattern;
-this skill is the upgrade-specific specialization).
+Take continuity snapshots first:
 
-## What Changed On 2026-04-27
-
-Initial belief:
+```bash
+rig snapshot <rig-id>
+node "$SKILL_DIR/scripts/backup-sqlite.mjs" \
+  --source "$OPENRIG_HOME/openrig.sqlite" \
+  --destination "/safe/path/openrig-before-upgrade.sqlite"
+```
 
-- All rigs had to be down before daemon restart.
-- Live upgrade was research-gated because DB migrations might break session/node
-  state while sessions were running.
-- A parallel isolated daemon/adoption path looked necessary before production use.
+The helper refuses to overwrite a destination, uses SQLite's backup operation,
+and verifies the backup with `PRAGMA integrity_check`. It does not stop the
+daemon or restore a database.
 
-Observed result:
-
-- A daemon-only hot cutover preserved the live `example-seat` tmux
-  sessions.
-- The old daemon was stopped without running `rig down`.
-- The new source-pinned daemon started against the same production DB.
-- `rig ps --nodes --json`, `rig capture`, and `rig restore-check` could inspect the
-  still-running continuity seats after restart.
+### Plan or apply safe managed-plugin refreshes
 
-The simpler model is now preferred for tmux-backed continuity rigs: snapshot and
-back up state, stop only the daemon, start the new daemon, then verify that live
-sessions are still observable and manageable.
+Plugin trees may contain skills as well as hooks and metadata. Compare the last
+packaged ancestor, the target package, and the live installed tree:
 
-## Proven Hot Path
-
-Use this as the canonical first-choice workflow for a host where continuity rigs
-are tmux-backed and the operator wants non-disruptive daemon upgrade.
-
-0. **Spawn the out-of-band operator when live cutover is required.**
-   The sidecar must be host-local and outside the managed topology being
-   upgraded. Keep the lifecycle/runtime-upgrade owner inside the rig so it can
-   continue to observe, ask questions, and absorb the handback.
-
-1. **Choose continuity targets.**
-   Name the exact rigs that must remain live. Everything else is source material.
-   Do not let "nice to resume later" rigs expand the success criteria.
-
-2. **Freeze active work.**
-   Get continuity seats to a stable/idle checkpoint. Record resume commands if
-   available.
-
-3. **Inventory with filters.**
-   Do not dump full `rig ps` output on this host. Use filtered JSON:
-
-   ```bash
-   rig ps --nodes --json \
-     | jq -r 'map(select(.rigName=="<rig>")) | sort_by(.canonicalSessionName)[] | "\(.canonicalSessionName) \(.sessionStatus) \(.startupStatus) \(.resumeToken // "none")"'
-   ```
-
-4. **Take a non-destructive snapshot of each continuity rig.**
-   This records rollback/recovery metadata without killing tmux sessions:
-
-   ```bash
-   rig snapshot <rigId>
-   ```
-
-   Verify the snapshot payload in SQLite has the expected nodes, sessions,
-   checkpoints, and resume tokens.
+```bash
+node "$SKILL_DIR/scripts/refresh-managed-plugin.mjs" \
+  --ancestor /path/to/previous/package/plugin \
+  --target /path/to/target/package/plugin \
+  --live "$OPENRIG_HOME/plugins/<plugin>"
+```
 
-5. **Create a post-snapshot SQLite backup.**
-   Use SQLite's online backup API while the daemon is live. Then run
-   `PRAGMA integrity_check` on the backup and verify it contains the continuity
-   snapshot.
-
-6. **Prepare a clean runtime artifact.**
-   Prefer a dedicated clean source worktree pinned to a commit:
-
-   ```bash
-   git worktree add --detach /path/to/openrig-runtime-<shortsha> <commit>
-   cd /path/to/openrig-runtime-<shortsha>
-   PATH=/path/to/node22/bin:$PATH npm ci
-   PATH=/path/to/node22/bin:$PATH npm run build
-   ```
-
-   Use even/LTS Node. The 2026-04-27 upgrade used Node `v22.22.1`.
-
-7. **Stop only the daemon.**
-   First try:
-
-   ```bash
-   rig daemon stop
-   ```
-
-   If the daemon state file is missing but the PID is known and verified as the
-   OpenRig daemon, gracefully terminate that PID:
-
-   ```bash
-   kill -TERM <daemonPid>
-   ```
-
-   Do not use `kill -9` unless recovering from a wedged process with human
-   approval. Do not run `rig down` on continuity rigs.
-
-8. **Start the pinned daemon against the same production DB.**
-
-   ```bash
-   PATH=/path/to/node22/bin:$PATH \
-     node packages/cli/dist/index.js daemon start \
-       --port 7433 \
-       --host 127.0.0.1 \
-       --db ~/.openrig/openrig.sqlite
-   ```
-
-9. **Verify management continuity.**
-   Required checks:
-
-   ```bash
-   rig daemon status
-   lsof -nP -iTCP:7433 -sTCP:LISTEN
-   rig ps --nodes --json | jq -r 'map(select(.rigName=="<rig>")) | ...'
-   rig capture --rig <rig> --lines 1 --json
-   rig restore-check --rig <rig>
-   ```
-
-   Success means the daemon is healthy, continuity sessions remain running/ready,
-   capture works, transcripts are present, and `restore-check` reports no red
-   blockers.
-
-10. **Align the default CLI with the new daemon.**
-    If `rig` is a wrapper, make sure it delegates to the new CLI.
-
-11. **Write evidence and hand back.**
-    The sidecar writes a cutover evidence packet with daemon provenance,
-    protected topology counts, representative capture/restore checks, smoke
-    results, caveats, and rollback state. Then it notifies the original in-rig
-    lifecycle/runtime-upgrade owner. Do not rely on chat as the only proof.
-
-## Proof Point: Daemon-Only Hot Cutover
-
-A clean source runtime on an LTS Node version replaced the old daemon while one
-tmux-backed continuity rig stayed live. The operator took a post-snapshot online
-database backup, verified its integrity, stopped only the daemon, started the
-new runtime against the same database, and confirmed that every protected seat
-remained running and ready with no red restore blockers.
-
-Important caveat: this proves hot daemon cutover for the tested tmux-backed
-Claude runtime shape. It does not prove that arbitrary migrations,
-non-tmux runtimes, service-backed rigs, or dead sessions can be recovered without
-separate testing.
-
-## Proof Point: Out-of-Band Sidecar Cutover
-
-A lifecycle owner prepared the decision and preflight artifacts, then spawned a
-host-local tmux sidecar outside the managed topology. The sidecar stopped only
-the daemon, used a verified graceful PID fallback when daemon state was stale,
-started the pinned runtime, aligned the default wrapper, verified the protected
-topology, ran targeted smoke checks, retained cutover evidence, and handed the
-result back while delivery continued.
-
-Important caveat: live `rig up --plan --json` accepted valid `starter_ref`
-specs and rejected forbidden compositions, but plan-mode output did not emit the
-`resolve_starter.detail.starterContent` stage expected by the Dogfood proof bar.
-This is a product/dogfood caveat, not an upgrade failure.
-
-## Brittle Edges Observed On 2026-04-27
-
-Operator lessons from the daemon upgrade:
-
-- `rig down` kills OpenRig-launched tmux sessions. Do not use it as a snapshot
-  primitive when resumability depends on keeping sessions alive.
-- Old daemon/CLI combinations can be partially functional even when newer health
-  checks fail. A `/healthz` mismatch blocked `rig down --snapshot` even though
-  other daemon APIs still worked.
-- `rig daemon stop` can fail when the daemon state file is missing. Operators
-  need a verified PID fallback, but the product should reconcile daemon state
-  automatically.
-- If the sidecar has an operator auto window and `rig daemon stop` refuses only
-  because state is stale, a verified graceful PID termination is acceptable:
-  identify the daemon PID, verify its runtime path, send graceful `TERM`, and
-  verify the port is gone before starting the target daemon.
-- CLI and daemon provenance can drift. Repointing or verifying the default
-  `rig` wrapper is part of the upgrade, not an afterthought.
-- Raw `rig ps` output can be noisy. Use filtered JSON until the product
-  has compact first-class inventory views.
-- Snapshot and backup verification is too manual. The SOP currently depends on
-  checking snapshot rows, resume tokens, SQLite backups, and integrity by hand.
-
-## Disruptive Restore Path
-
-Use disruptive restore when the goal is to test recovery from killed sessions, or
-when hot upgrade is blocked by incompatible migrations or corrupted management
-state.
+Review the sorted decisions. To apply only `refresh-safe` and `add-safe` files:
 
 ```bash
-rig snapshot <rigId>
-rig down <rigId>
-# upgrade daemon/CLI
-rig up <rigName>
-rig restore-check --rig <rigName>
+node "$SKILL_DIR/scripts/refresh-managed-plugin.mjs" \
+  --ancestor /path/to/previous/package/plugin \
+  --target /path/to/target/package/plugin \
+  --live "$OPENRIG_HOME/plugins/<plugin>" \
+  --apply-safe
 ```
 
-Expected restore results:
+The helper never deletes a live file and never overwrites a local modification.
+Local deletions, live-only files, target removals, and ambiguous types are
+reported for the agent to resolve. Re-run the plan after any manual resolution.
 
-| Result | Meaning | Action |
-|---|---|---|
-| `fully_restored` | All nodes resumed or rebuilt | Resume normal work |
-| `partially_restored` | Some nodes succeeded, some failed | Inspect failed nodes and relaunch manually |
-| `failed` | Zero nodes restored | Check daemon logs, snapshot integrity, provider tokens |
-| `not_attempted` | Pre-restore blockers | Fix blockers before retrying |
+### Migrate a pre-0.5.9 instance layout
 
-Do not confuse this path with hot upgrade. `rig down` is intentionally
-disruptive.
+Version 0.5.9 puts context-usage telemetry in
+`$OPENRIG_HOME/state/context-usage`, provider telemetry in
+`state/provider-usage`, the addressable library under `context/`, and the
+default System World at `context/system/system-world.yaml`. Existing 0.5.8
+homes cross that boundary through an **Agent-Operated Migration**: the target
+runtime reads canonical-first with legacy-fallback while all new writes use the
+canonical state roots. An explicitly configured custom context-library root
+stays stable throughout activation.
 
-## Stop Conditions
+The helper supplies bounded, inspectable operations. The agent owns their
+sequence and the target-runtime activation between them. With an exact
+protected preimage path, first inspect and then prepare canonical directories,
+the default System World, and a config pin to the existing library. Preparation
+does not copy telemetry, rewrite live collector settings, or run lifecycle
+actions:
 
-Do not proceed with hot upgrade if:
+`--help` prints the phase grammar without inventorying the instance. With no
+phase flag the helper intentionally runs the read-only plan; unknown options
+fail nonzero before plan or mutation.
 
-- continuity targets are mid-task and cannot checkpoint;
-- continuity target tmux sessions are missing before upgrade;
-- no verified DB backup exists after continuity snapshots;
-- the target runtime cannot build under an even/LTS Node version;
-- the daemon migration plan is known to rewrite session/binding semantics in a
-  way that has not been tested;
-- disk space or DB integrity checks fail;
-- the operator cannot identify the current daemon PID and runtime source.
+```bash
+node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" --help
 
-## Rollback
+node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" \
+  --home "$OPENRIG_HOME"
 
-Rollback means restoring the previous daemon runtime and, if necessary, the DB
-backup.
+node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" \
+  --home "$OPENRIG_HOME" \
+  --apply-state \
+  --preimage "$OPENRIG_HOME/backups/layout-0.5.9-before"
+```
 
-For source runtime:
+Activate the exact target runtime using the ordinary upgrade workflow. Then
+wait until every bounded post-apply legacy tail is followed by newer paired
+new-root samples for that same seat. This proves temporal convergence
+without blanket process replacement; a later legacy write remains a hard stop.
+Capture the verification JSON; copied old sidecars are not evidence:
 
-1. Stop the new daemon.
-2. Start the previous runtime or npm/global daemon.
-3. Verify `/healthz`, filtered continuity inventory, and `rig capture`.
-4. Restore the DB backup only if migration or DB corruption is confirmed. Do not
-   replace the DB just because continuity sessions are still live but management
-   projection is degraded.
+```bash
+node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" \
+  --home "$OPENRIG_HOME" \
+  --verify \
+  --preimage "$OPENRIG_HOME/backups/layout-0.5.9-before" \
+  > /safe/path/layout-0.5.9-verify.json
+```
+
+Only a successful receipt authorizes the separately invoked non-destructive
+finalizer. It copies an unconfigured legacy library into the canonical root
+without overwriting anything; a custom context-library root remains stable:
+
+```bash
+node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" \
+  --home "$OPENRIG_HOME" \
+  --apply-library \
+  --preimage "$OPENRIG_HOME/backups/layout-0.5.9-before" \
+  --verification /safe/path/layout-0.5.9-verify.json
+```
 
-For npm runtime:
+Stop on every reported issue: malformed or foreign telemetry, a reserved-path
+conflict, a library collision, config drift, resumed legacy writes, byte drift,
+or a missing fresh dual sample all require the named repair before continuing.
+Verification binds the exact accepted tail bytes to their paired-newer samples;
+the finalizer revalidates them immediately before switching config. The helper
+never removes the legacy telemetry or library. Their later retirement is a
+separate agent decision after stable runtime, writer, reader, and recovery proof.
+It does not stop/start the daemon, launch a seat, touch the database, or decide
+whether the upgrade proceeds.
+
+To recover, restore the prior runtime as the agent-led workflow requires, then
+reverse only helper-owned config, System World, empty-directory, and copied
+library effects. Real state samples and both legacy recovery sources remain for
+inspection:
 
 ```bash
-npm install -g @openrig/cli@<previous-version>
-rig daemon stop
-rig daemon start
+node "$SKILL_DIR/scripts/migrate-telemetry-state-0.5.9.mjs" \
+  --home "$OPENRIG_HOME" \
+  --rollback "$OPENRIG_HOME/backups/layout-0.5.9-before"
 ```
 
-## Roadmap: Better Hot Upgrades
-
-The product should make the proven manual path boring and explicit.
-
-Needed product surfaces:
-
-- `rig upgrade preflight`:
-  daemon PID/runtime source, CLI source, DB path, migration plan, active rigs,
-  continuity targets, tmux liveness, disk space, DB integrity, backup target,
-  and rollback runtime.
-- `rig daemon adopt-state` or equivalent:
-  recover a healthy daemon on a port when `daemon.json` is missing.
-- `rig upgrade backup`:
-  online SQLite backup plus integrity and snapshot-presence verification.
-- `rig upgrade promote-runtime <commit|artifact>`:
-  start from a clean worktree or packaged artifact under an even/LTS Node.
-- `rig upgrade verify --rig <name>`:
-  filtered inventory, capture, transcript, restore-check, and honest continuity
-  classification.
-- CLI/daemon provenance:
-  `rig version --json` should report CLI path, daemon path, commit/package
-  version, Node version, DB path, and started-at.
-- Wrapper alignment:
-  the default `rig` wrapper should clearly show which real CLI it delegates to.
-- Compact inventory:
-  first-class `rig ps --rig <name> --nodes --compact` or equivalent, so
-  operators do not need ad hoc `jq` for routine safety checks.
-
-Research still needed:
-
-1. Migration-bearing hot upgrade on a throwaway rig.
-2. Hot upgrade with non-critical live Codex seats.
-3. Hot upgrade with service-backed rigs.
-4. Adoption/reconciliation when daemon DB says sessions are running but tmux has
-   partially drifted.
-5. Automated rollback on daemon startup failure or migration failure.
-
-## Operator Summary
-
-Hot upgrade rule:
-
-**Snapshot continuity rigs, back up the DB, stop only the daemon, start the new
-daemon against the same DB, then verify live tmux sessions through filtered
-management surfaces.**
-
-Disruptive restore rule:
-
-**Use `rig down` only when testing or accepting session teardown.**
+## Agent-led continuity upgrade
+
+This is a decision guide, not a command recipe. Adapt paths and checks to the
+host in front of you.
+
+1. Inspect the current CLI, daemon, nodes, and plugins with the helper.
+2. Checkpoint active work and record the exact protected tmux/session census.
+3. Run `rig snapshot <rig-id>` for each protected rig.
+4. Create and verify the SQLite backup.
+5. Build or stage the target runtime separately. Prove its version and source
+   identity before touching the live daemon.
+6. Run `rig daemon stop`. Verify both the listener and the identified daemon
+   process are gone. If the command returns while either remains, stop: inspect
+   identity and use the host's authorized recovery procedure. Do not blindly
+   signal a PID.
+7. Start the target with `rig daemon start` or the host's known wrapper. Verify
+   daemon status, process path, listener, version, and database integrity.
+8. Run the plugin refresh helper in plan mode. Apply safe writes only after the
+   three roots and classifications make sense; resolve preserved paths one at a
+   time when required.
+9. Verify protected seats with `rig ps --nodes -A --json`, representative
+   `rig capture`, and `rig restore-check` where applicable. `-A` is required:
+   without it the node read is your CURRENT rig only, and a daemon upgrade
+   protects seats across every rig on the host — so the narrow form reports
+   success while seats outside your rig went unchecked.
+10. Align wrappers only after deriving how that host owns them. Use its existing
+    mechanism; this skill does not rewrite launchers.
+11. Record the observed result, remaining local preservation decisions, and the
+    exact rollback runtime and backup.
+
+## Stop and hand back when
+
+- a protected tmux session is missing before the upgrade;
+- database integrity or backup verification fails;
+- the running process or listener does not match the expected runtime;
+- daemon stop reports success but the identified process or listener remains;
+- the target cannot start against the existing database;
+- plugin roots cannot be tied to a known ancestor and target;
+- a required plugin path is classified as locally modified or deleted and the
+  correct ownership decision is unclear;
+- continuing would require `rig down`, destructive restore, credential changes,
+  or broader authority than the operator has.
+
+When stopping, report the last proven-good state, the first failed expectation,
+the exact evidence, and the smallest decision needed from the owner. Preserve
+live seats and the database unless recovery specifically requires otherwise.
+
+## Rollback is also agent-led
+
+Prefer starting the previous known runtime against the still-valid database.
+Restore the database backup only when a migration or corruption finding requires
+it; a degraded projection alone is not proof that the database should be
+replaced. After rollback, repeat the same process, listener, database, plugin,
+and seat observations used during the forward path.