Rsvp Short Term Pain Long Term Gain

The migration needs to: 1. Discover all FK references to members.id (query information_schema.referential_constraints for foreign keys pointing at public.members) 2. For each referencing table, do ALTER TABLE ... DROP CONSTRAINT then ADD CONSTRAINT ... FOREIGN KEY (member_id) REFERENCES members(id) ON UPDATE CASCADE so the UPDATE cascades to child rows 3. Run the UPDATE 4. Re-add the FK constraints 5. Add the BEFORE INSERT/UPDATE trigger to enforce the invariant going forward 6. Document the invariant in a comment in the migration

This is also the second time the user has framed their pick as "short term pain for long term gain" type reasoning (the earlier one was implicit in the reset-to-first-principles request). The pattern is the user consistently prefers architectural fixes over symptom fixes when the symptom-fix path requires repeated repair work. When the symptom-fix path is one-shot and clean, they take it (e.g. the completeSignInWithApple was a 5-line fix, not a schema migration).

Signals: 1 concept captured → concepts/rsvp-short-term-pain-long-term-gain (the user's preference for architectural fixes + the Option B plan + schema migration recipe + short-term pain budget), 0 entities, 0 facts. Captured silently per the WRITES SILENTLY preference. This is the second time the user has explicitly chosen the durable-fix path; the pattern is now a class-level preference signal worth capturing as a concept page.