release-safetylisted

# Release safety Core principle: **a backend release is valid only if the current production app keeps working after it deploys.** Any change that breaks the current app version is an invalid release — regardless of whether a force update is planned. ## 1. Backend backward compatibility Every backend release MUST work with BOTH the current production app and the new app — there's always a gap between backend deploy and app rollout. **Database changes:** - Only additive migrations per release (add columns, add tables). - NEVER rename or drop columns in the same release as the feature using them. - Sequence: add column → update reads/writes → remove old column in a later release. **API changes:** - Preserve existing API contracts (fields, response shapes, endpoints). - Don't remove/break old fields or endpoints until the old app version is fully deprecated. **Code requirement:** when introducing backward-compatible logic, add a comment explaining why it's needed, which app versions are affected, and when the old logic/fields can be removed. ## 2. Test current app against new backend Before every release — including force-update releases — verify the current production app version works against the new backend. Run all critical user flows with the current app pointed at the new backend. If any critical flow fails: block the release, fix the backend, re-test. No exceptions. ## 3. Rollback plan Every release requires a documented rollback plan before it ships, answering: -