sonder-selfmod-lifecycle

Use /selfmod plan with an objective and file list, then /selfmod run with a test command, review the diff and recorded gates, approve from the reviewing phase, and deploy. Deploy requires console operator approval and runs a rollback probe before any health check.

Rejections come from review() gates: missing passing checks, a failing recorded gate, a reproducer that did not fail pre-edit, an empty scoped diff, protected file modification, or weakened test inventory. Run /selfmod tests <run-id> and match the last_error string to its documented cause.

Automatic edits can never touch protected paths. Protected maintenance requires an explicitly authorized --maintenance run with a security gate plus explicit user approval, and auto-low-risk mode can never approve it.

Run the stdlib-only selfmod_recover.py against the run's backup manifest.json. It verifies the manifest checksum, validates the whole bundle with path confinement and per-file checksums, then atomically restores files and re-verifies SHA-256 hashes.

Rollback compares live files against recorded post-deploy hashes and refuses if you edited a deployed file afterwards, preserving your changes. Resolve the conflict explicitly; the system never force-clobbers user edits.

Use sonder-change-control for ordinary code review and approval flow, sonder-build-and-env for environment setup and general test runs, and sonder-failure-archaeology for incident history. Selfmod applies only to runs, candidates, backups, and deploys of the self-modification subsystem.