[P1/P2] Recover interrupted install/update/uninstall transactions after hard process termination

[gitcoder89431]

Problem

Current rollback handles ordinary command/script failures well, but an ERR/EXIT trap cannot run after events such as kill -9, power loss, kernel/system crash, or abrupt machine reset.

A lifecycle operation interrupted between plugin/config mutations can therefore leave a partially applied state even though normal failures roll back correctly.

Goal

Add durable transaction metadata so the next mutating Ruixen lifecycle command can detect and safely recover an unfinished operation before doing new work.

Suggested design

Before exposing live mutations, create a transaction directory such as:

~/.local/state/ruixen/transactions/<token>/
  journal.json
  shell.json.before
  ...

The journal should record schema version, operation type, transaction token, phase, exact managed targets, whether each target existed before, backup/snapshot locations, config snapshot metadata, and whether live mutation/restart began.

On startup of any mutating lifecycle command:

1. acquire the lifecycle lock
2. detect unfinished transactions
3. validate journal/snapshot paths and schema
4. recover or finish the prior transaction safely
5. only then begin the new command

Critical safety requirements

• Never trust arbitrary paths from a journal without validating they are under expected Ruixen/Omarchy roots.
• Refuse symlinked/malformed transaction roots.
• Do not delete the journal if recovery itself fails.
• Recovery should be idempotent.
• Existing normal rollback remains useful; the journal covers crash/interruption durability.
• Do not stop or mutate the shell until all required recovery data has been validated.

Acceptance tests

Simulate termination after first plugin replacement, after all plugins before shell.json, after shell.json before looknfeel, after looknfeel before restart, after restart begins before success commit, and during uninstall.

For each case, terminate without executing shell traps, run a new lifecycle command, verify the previous working installation/config is recovered, verify no mixed old/new plugin set remains, and remove the transaction directory only after successful recovery.

Also corrupt a journal/snapshot and confirm Ruixen refuses unsafe recovery instead of guessing.

[gitcoder89431]

Status check-in after tonight's related work, leaving this open rather than closing it -- real scope remains, but worth recording what's actually covered now vs what isn't.

Covered:

• The specific failure mode that actually hit a real tester (a hard interruption -- 'the screen cut off' -- mid-plugin-copy) is now caught immediately: install.sh verifies every deployed plugin's content hash right after copying it, and fails loudly if a copy didn't complete cleanly (825007a's own predecessor commit).
• Recovery from that state doesn't need a transaction journal at all: the plugin-copy loop is already unconditional (replaces every plugin from scratch every run) and now self-verifying, so a plain re-run of install.sh -- or ruixen-repair.sh, which wraps exactly that -- already fixes a mixed old/new plugin set (repair, closed via [P2] Add ruixen status and transactional ruixen repair health commands #33).
• shell.json writes already go through omarchy-shell-config's own atomic commit() primitive (temp-file-then-rename), and looknfeel deploys already write to a temp file and rename into place (see install.sh's own existing comments on both) -- a hard kill during either of those genuinely can't leave a torn/partial file, only an old-vs-new logical state, which install.sh already resolves idempotently on the next run either way.

Not covered (the issue's own remaining real scope):

• No durable journal.json actually recording phase/progress across a run -- recovery today is 'idempotently redo everything', not 'detect exactly which phase was interrupted and resume/roll back precisely'. For a single-machine, single-user tool where 'just re-run it' is always safe and cheap, this matters less than it would for a distributed/transactional system, but it's still the real gap if the acceptance criteria's own 6-interruption-point test matrix is the bar.
• No detection of an unfinished transaction on startup (a stale lock left behind by a hard kill, say) beyond flock's own natural release-on-process-exit behavior.

Given the practical risk is now meaningfully smaller than when this was filed, I'd suggest this stays open as real but lower-urgency follow-up rather than something to build speculatively without a concrete new failure mode motivating the full journal design.