happier-compatibility

# Happier Compatibility Preserve real released and prospective predecessor behavior at system seams without preserving undeployed internal architecture or creating speculative compatibility debt. Read `docs/compatibility.md` before acting. Also read the owning package instructions and the domain document for the affected protocol, feature, encryption, provider, installer, or persistence surface. ## 1. Classify the surface Name the observable contract and classify it as wire, semantic, persistence, operational/installer, or internal-only. If the change is internal-only and leaves external readers, writers, artifacts, and rollout behavior unchanged, stop the compatibility workflow. Do not create a matrix, shim, migration, or compatibility test merely because code moved. ## 2. Establish evidence-backed baselines - Resolve active stable and preview baselines independently for every affected component. Record immutable version tag, commit, and artifact/deploy evidence; do not use a rolling tag alone as the final basis. - Include older versions only when explicitly supported. - Exclude `dev` builds, undeployed internal paths, and abandoned intermediates from lasting obligations. - Apply any repository-specific predecessor rule in `docs/compatibility.md`. When it requires a live sibling worktree, inspect committed, staged, and unstaged code without modifying it and label observed versus inferred behavior. Do not proceed from a vague claim such as “the old client probably sen...