Rebased onto bdfdc30 and rewritten on top of #212. The description above predates that rebase and describes the earlier revision — this comment is the accurate summary of what the branch now does.

What changed. The first revision predated #212 and carried its own adoption bookkeeping in manifest.json. That is gone. adopt and adopt_skills already publish receipts (adopted_legacy.json, adopted_skills.json) pinning live_path, sha256_before ("" when no file existed), sha256_after, and backup_path — everything an undo needs. revert() and revert_skills() simply reverse those.

Consequences:

• The backup-clobber fix is dropped. The earlier revision fixed _backup overwriting itself on a second adopt. feat(sleep): adopt reviewed skill subsets safely #212's immutable backups and its "already adopted from this night" refusal made that moot.
• Both ledgers are covered, with adopt's selection surface: --skill NAME (repeatable), --all-skills, --legacy, --staging DIR.
• New refusal: if the live file no longer matches sha256_after, revert stops. It was edited or replaced after adoption, and restoring the backup would discard that work.
• Revert consumes the backup and clears the night's receipt rows, returning the staging directory to its pre-adopt shape so it can be adopted again — adoption refuses to run while an immutable backup is present. A test covers the full adopt → revert → adopt → revert cycle.

Two deliberate limits, both documented in docs/reference/cli.md:

Directories adoption created are left in place. The receipt records no created_dirs, and removing a directory whose ownership was not durably recorded is the same fail-closed case _recover_transaction_locked already refuses.

Revert is not WAL-journaled. It takes _adoption_locks, runs _recover_before_manifest first so an interrupted adoption settles before anything is undone, re-reads the ledger under the lock, and checks every step against the receipt's pins — a live file already matching sha256_before is treated as done rather than as a mismatch, so an interrupted revert is completed by running it again. Promoting it into the durable transaction would mean teaching _TransactionTarget to delete a path, which the WAL schema has no representation for today, so the sha256_before == "" case needs a schema bump. Glad to do that as a follow-up if you would rather revert be journaled end to end.

On the test suite. 23 new tests in tests/test_sleep_revert.py, driving real adopt/adopt_skills calls rather than hand-built ledgers. Separately, and unrelated to this PR: main at bdfdc30 is currently red on macOS. Verified by stashing — clean main gives 38 failed, 1351 passed, this branch gives 38 failed, 1374 passed. Same 38, plus the 23 from here.

They are all one cause. /tmp and /var are symlinks to /private/... on macOS, so the canonicalization added in #212 returns a resolved path where the tests assert the unresolved one:

AssertionError: '/private/tmp/live/alpha/SKILL.md' != '/tmp/live/alpha/SKILL.md'

I have not touched it here. Happy to open a separate issue if that would be useful.

Also verified: end-to-end through run_sleep_cycle with auto_adopt=True against a pre-existing hand-written skill — adoption changed it (f69ed225b55e → db0f5e360448), revert restored it byte-exact and removed the CLAUDE.md adoption had created. python -m mkdocs build --strict passes; Ruff is clean on the changed files.

One reviewer question: status gained a revertable_staging key and two printed lines. It already reports which skills were adopted from the latest night, but the revertable night can be an older one, and that is what a bare revert acts on. Happy to drop it if you would rather keep this to the command alone.

Reverting an adoption is valuable, but I found receipt-validation and history-ordering cases that make the current implementation unsafe to merge.

1. _revert_receipts() uses the generic receipt reader and trusts receipt-supplied live/backup paths instead of binding each row to the validated manifest, canonical live root, and fixed backup location. _safe_live_path() only requires an absolute .md path. I reproduced a tampered created-file receipt (sha256_before == "") deleting a matching .md file outside the adopted project. Please validate the complete ledger-specific schema, derive or verify paths from trusted manifest data, reject duplicate/extra fields and invalid backup combinations, and under the lock compare the full receipt identity/bytes rather than only the set of keys.
2. A content hash does not prove that an old receipt is the current adoption. In the sequence O -> X (night 1), X -> Y (night 2), Y -> X (night 3), explicitly reverting night 1 sees the expected X hash and incorrectly restores O, undoing later history. Please persist parent/sequence lineage and allow only the current ledger head to be reverted, or implement an equivalently safe stack model.
3. The non-journaled flow is not fully convergent. If the process stops after restoring the live file but before deleting its backup, the next run sees sha256_before, skips _revert_one(), removes the receipt, and leaves an orphan immutable backup that blocks future adoption. Please make recovery cover this window; a journaled/atomic multi-target revert is the clearest solution.

Required regressions should include an external live_path, wrong skill parent/basename, redirected or contradictory backup fields, duplicate/extra receipt fields, receipt replacement while acquiring locks, the ABA sequence above, and interruption after each mutation step. Please also avoid selecting “latest” by mutable directory mtime and preserve an immutable audit record. The happy-path tests pass, but arbitrary-file deletion and stale-history rollback are merge blockers.