Compatibility, Rollback, and Removal Rules

• Every migration phase is independently revertible.
• Report-only validators may be disabled without changing runtime output.
• Generated projections do not replace hand-authored sources until parity and freshness gates pass.
• A command rename keeps a tested compatibility alias for its declared window; removal requires usage evidence, release notes, and a migration path.
• Schema changes follow explicit major-version compatibility. Readers reject an unsupported future major version with an actionable diagnostic.
• Native-smoke instability can demote the check from blocking to advisory; it cannot convert a failed receipt into a passing one.
• Support demotion preserves historical receipts and explains which evidence expired or failed.
• Rollback never deletes user reports, host configuration, sessions, or caches.
• Old owners are removed only after consumer search and parity evidence show no active dependency outside an intentional compatibility facade.