genichin
829629fa8f
Core Changes: - Migrate portfolio_id from string to UUID in schema and repository layer - Update portfolio CLI commands to use name+user combination for identification - Update HTTP API to accept portfolio_id as UUID path parameter - Implement portfolio ownership validation in repository queries Requirements Completed (REQ-016 to REQ-019): - REQ-016: portfolios table UUID schema migration with data migration script - REQ-017: CLI portfolio commands with name+user identification - REQ-018: HTTP API portfolio path parameters and v1 asset_id UUID returns - REQ-019: Portfolio UUID baseline documentation updates BAT-001 Re-verification: - REQ-004~010 marked as Implemented after verification evidence validation - All v1 API endpoints verified with comprehensive test coverage Documentation Updates: - Update data-model.md with portfolio UUID structure - Update interface-contract.md with UUID path parameters - Update runtime-flows.md with ownership-based resolution flows - Update project-structure.md with database layer changes - Add migration script for portfolio UUID transition Testing: - Add test_portfolio_uuid.py for migration validation - Update test_cli.py and test_portfolio_ownership.py for ownership checks
3.6 KiB
3.6 KiB
BAT-007 Planning
- Status: confirmed
- Batch: BAT-007
- Profile: batch-lite
Included REQ
- REQ-001: 로컬 DB 초기화 및 마이그레이션 검증 시나리오 정의
- REQ-002: Alembic와 runtime schema ownership 경계 정리
- REQ-003: 로컬 DB 운영 runbook 및 baseline 문서 갱신
Out of Scope
- shared dev DB, staging, production-like 환경 검증 (REQ-001 Notes 참고)
- legacy DB 지원 및 legacy stamp 경로 검증 (REQ-002 Notes 참고)
- baseline 문서 전체 복제 또는 로컬 DB 검증과 무관한 구조 변경 (REQ-003 Notes 참고)
- trex-basic 연동 환경 검증 (이번 batch 범위 외)
구현 순서
1단계: 현황 파악 (REQ-002 선행)
app/repositories/postgres.py의ensure_schema()메서드가 다루는 테이블/인덱스 목록 확인migrations/versions/*.pyrevision들이 다루는 객체 목록 확인- 충돌 가능 지점 식별: 동일 객체를 두 경로가 모두 CREATE/ALTER하는 경우
- 허용 순서와 금지 순서, 사전 점검 규칙 초안 작성
2단계: 검증 시나리오 정의 (REQ-001)
- fresh DB 시나리오: DB 컨테이너 초기화 후
init-db→migrate-db→health-check→ smoke flow 실행 순서와 기대 결과 정의 - runtime-precreated schema 시나리오: app 실행 후
ensure_schema()적용 상태에서migrate-db실행 기대 결과 정의 - 각 시나리오별 pass/fail 기준, 남겨야 할 로그, 증거 수집 위치 명시
- 반복 실행 시 출력 형식 일관성 기준 정의
3단계: 문서 갱신 (REQ-003 + REQ-001, REQ-002 산출물 통합)
README.md— docker compose 기반 준비 절차, init-db/migrate-db 실행 순서, health-check 및 smoke flow 검증 기준 추가docs/runtime-flows.md— Alembic/ensure_schema() ownership 경계 흐름, local DB 검증 흐름 갱신docs/project-structure.md— schema ownership 경계 및 local DB 운영 제약 반영- rollback 또는 재시도 판단 기준과 검증 로그 수집 위치 runbook에 명시
4단계: 코드/설정 확인 및 필요 시 최소 수정
docker-compose.local-test.yml— 검증 시나리오 실행 환경 점검 (변경 필요 시 최소 반영)app/cli/commands/health.py— health-check 출력 형식이 검증 기준과 일치하는지 확인app/db/migrations.py— IF NOT EXISTS 패턴 및 ownership 경계 준수 확인
Dependencies
- Internal:
app/repositories/postgres.py—ensure_schema()ownership 분석 대상app/db/migrations.py— migration 실행 entry point 확인migrations/versions/*.py— Alembic revision 대상 객체 목록docker-compose.local-test.yml— 로컬 검증 환경
- External: 없음
Design Gate
- Design Required Before Implementation: no
- Reason: 신규 인터페이스, DB 스키마, 런타임 흐름 변경 없음. 기존 코드 분석 → 문서 작성 중심 batch. 구조적 결정 사항이 분석 과정에서 발견되면 planning을 갱신하고 필요 시 design.md를 추가한다.
Milestones
- REQ-002: Alembic vs ensure_schema() ownership 경계 분석 완료 + 문서 초안
- REQ-001: 검증 시나리오 매트릭스 정의 완료
- REQ-003: README, docs/runtime-flows.md, docs/project-structure.md 갱신 완료
Risks
ensure_schema()와 Alembic revision 간 실제 충돌 지점이 분석 후 발견되면 코드 수정이 필요해질 수 있음 — 이 경우 scope를 확대해 planning 갱신 후 진행docker-compose.local-test.yml이 현행 환경(PostgreSQL + TimescaleDB)과 맞지 않으면 수동 검증 절차 수정 필요