---
name: feedback_private_ops_migration_deploy_order
description: "private-ops — main-Merge triggert Vercel-Auto-Deploy; Migration muss sofort nach Merge via apply-migrations.sh --remote laufen, sonst Live-Break"
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 11a42882-3e6b-4e9a-b40d-04743ac8c2c5
---

In **private-ops** deployt Vercel `main` automatisch beim Merge. Wenn ein PR neue DB-Spalten/Objekte einführt, ist der App-Code (der die Spalten selektiert) LIVE bevor die Migration angewendet ist → die betroffene Seite crasht kurz auf die fehlenden Spalten (am 2026-05-29 bei KAR-641 passiert: Belege-Seite, sofort mit `bash scripts/apply-migrations.sh --remote` gefixt).

**Why:** Migration-Apply ist ein separater manueller Schritt (`scripts/apply-migrations.sh`, liest `SUPABASE_DB_URL` aus `.env.local`), NICHT Teil des Vercel-Deploys. Merge → Deploy ist sofort; Migration → manuell danach = Race.

**How to apply:** Bei jedem Migration-tragenden private-ops-PR direkt nach dem Merge `bash scripts/apply-migrations.sh --remote` ausführen (vorher `--remote --dry-run` zum Plan-Check: nur die erwartete Migration darf pending sein). Idempotent, überspringt bereits angewendete via Ledger (`meta.applied_migrations`). Sauberste Dauerlösung: Apply-Step in die CI/Deploy-Pipeline ziehen (eigenes KAR wert). Siehe auch [[feedback_next_build_not_just_tsc]].