배경
기존 docs/DATABASE-MIGRATIONS.md 가 두 마이그레이션 시스템 (Supabase CLI + SeaORM) 의 객체 충돌과 통합 deferred 사실을 인지했으나 행동 부재. 같은 패턴의 schema drift 가 반복 발생하는 근본 원인.
상위 spec: docs/superpowers/specs/2026-04-30-db-operating-model-design.md
산출물
단일 마이그레이션 SOT
범위
- 두 가지 방향 중 택일 (epic 내 의사결정):
- (A) Supabase CLI SQL 의 idempotent 화 + SeaORM 마이그레이션을 동일 의도로 재구성
- (B) SeaORM 폐기 + Supabase CLI 단독화
- prod 에서도 api-server 가 마이그레이션 실행 (또는 별도 cargo binary)
- SKIP_DB_MIGRATIONS 플래그 삭제
docs/DATABASE-MIGRATIONS.md 재작성
Acceptance
예상 공수
수 주 ~ 1+ 달 (epic — 별도 sub-task 분해 필요)
Risk / 선결 조건
- 마이그레이션 운영 모델 자체가 바뀜 → 충분한 staging 검증 필요
- staging 환경 미정의 (
docs/agent/staging.md 참조) → 본 epic 진행 전 staging 정의가 선결될 수 있음
- 본 epic 시작 전 이슈 1·2·3 가 안정화되어야 의미 있음
우선순위
P3 (백로그)
관련: #371, #372, #373
배경
기존
docs/DATABASE-MIGRATIONS.md가 두 마이그레이션 시스템 (Supabase CLI + SeaORM) 의 객체 충돌과 통합 deferred 사실을 인지했으나 행동 부재. 같은 패턴의 schema drift 가 반복 발생하는 근본 원인.상위 spec:
docs/superpowers/specs/2026-04-30-db-operating-model-design.md산출물
단일 마이그레이션 SOT
범위
docs/DATABASE-MIGRATIONS.md재작성Acceptance
예상 공수
수 주 ~ 1+ 달 (epic — 별도 sub-task 분해 필요)
Risk / 선결 조건
docs/agent/staging.md참조) → 본 epic 진행 전 staging 정의가 선결될 수 있음우선순위
P3 (백로그)
관련: #371, #372, #373