to-do first

docs/03-analysis/todo-app.analysis.md

@@ -0,0 +1,100 @@
+# Analysis (Check) — todo-app
+
+> PDCA Phase: **Check** · Feature: `todo-app` · 작성일: 2026-06-15
+> 상위: [Plan](../01-plan/features/todo-app.plan.md) · [Design](../02-design/features/todo-app.design.md)
+
+## Context Anchor
+
+| 항목 | 내용 |
+|------|------|
+| WHY | 사내 샘플을 실제 쓰는 최소 To-Do 앱으로 — DB+S3 패턴 시연 |
+| WHO | 로그인 없는 단일 공용 목록 |
+| RISK | 첨부 처리, schema 마이그레이션, S3-DB 정합성 |
+| SUCCESS | 브라우저 CRUD + 첨부 업/다운로드, db/minio check 통과 |
+| SCOPE | IN: todo CRUD + 첨부 1개 + 웹UI + API / OUT: 인증·태그·검색 |
+
+## Match Rate
+
+| 축 | 점수 | 가중치 | 기여 |
+|----|:----:|:------:|:----:|
+| Structural | 100% | 0.15 | 15.0 |
+| Functional | 96% | 0.25 | 24.0 |
+| Contract | 100% | 0.25 | 25.0 |
+| Runtime (L1) | 100% | 0.35 | 35.0 |
+| **Overall** | **99%** | | |
+
+> 런타임 실행 공식 적용(서버 기동). 16/16 L1 테스트 통과, 서버 로그 에러 없음.
+
+## 1. Structural Match — 100%
+
+Design §2 모듈 구조 전부 존재, §4 라우트 6개(`GET /`, `GET/POST /api/todos`, `PATCH/DELETE /api/todos/:id`, `GET /api/todos/:id/attachment`) 모두 구현·마운트 확인.
+
+## 2. Functional Depth — 96%
+
+| 항목 | 결과 |
+|------|------|
+| 업로드 보상 삭제(§5,§6) | ✅ 업로드 실패 시 `repo.remove` |
+| 삭제 시 S3 선삭제 후 DB(§6) | ✅ best-effort 로깅 후 진행 |
+| pgcrypto fallback(§3) | ✅ 런타임에서 실제 발동 확인(`permission denied`→`randomUUID`) |
+| 입력 검증(title/uuid/done) | ✅ |
+| placeholder/미구현 | 없음 |
+
+**−4% 사유 (Minor)**: Design §5는 "단일 INSERT(첨부 키 포함)"로 기술됐으나, 구현은 "INSERT → setAttachment UPDATE" 2단계. 동작·정합성은 동일(오히려 id 기반 키 생성에 더 적합). 문서-구현 표현 불일치만 존재.
+
+## 3. API Contract — 100% (3자 검증)
+
+Design §4 ↔ `src/routes.todos.js` ↔ `public/index.html` fetch 호출 일치:
+- 응답 envelope `{data}` / `{error}` ✅
+- `hasAttachment` 노출 + `attachment_key` 비노출 ✅ (런타임 L1-8 검증)
+- 상태코드(201/400/404/413/204/200) 일치 ✅
+- 다운로드 `Content-Disposition` 헤더 ✅ (L1-10)
+
+## 4. Runtime Verification (L1) — 16/16 PASS
+
+| # | 검증 | 기대 | 결과 |
+|---|------|:----:|:----:|
+| 1 | GET / | 200 | ✅ |
+| 2-3 | GET /api/todos + {data} | 200 | ✅ |
+| 4 | POST title | 201 | ✅ |
+| 5-6 | POST no title + {error} | 400 | ✅ |
+| 7 | 첨부 hasAttachment | true | ✅ |
+| 8 | attachment_key 비노출 | — | ✅ |
+| 9-10 | 다운로드 + Content-Disposition | 200 | ✅ |
+| 11 | PATCH done | 200 | ✅ |
+| 12-14 | PATCH bad uuid/no done/404 | 400/400/404 | ✅ |
+| 15 | DELETE | 204 | ✅ |
+| 16 | 삭제 후 다운로드(cascade) | 404 | ✅ |
+
+## 5. Success Criteria 평가
+
+| SC | 상태 | 근거 |
+|----|:----:|------|
+| SC-01 CRUD UI | ✅ Met | L1 + public/index.html |
+| SC-02 업로드→S3+DB key | ✅ Met | L1-7, S3 객체 생성 |
+| SC-03 다운로드 | ✅ Met | L1-9/10 내용 일치 |
+| SC-04 삭제 시 S3도 삭제 | ✅ Met | L1-16 cascade |
+| SC-05 db/minio check | ✅ Met | 둘 다 통과 |
+| SC-06 podman | ⚠️ Partial | Dockerfile 무변경으로 빌드 가능하나 이 세션 미실행 |
+
+## 6. Decision Record 준수 검증
+
+| 결정 | 준수 |
+|------|:----:|
+| Option C(repo/attachments/routes 분리) | ✅ |
+| 서버 프록시 스트리밍(presigned 미사용) | ✅ `GetObjectCommand` pipe |
+| pgcrypto + randomUUID fallback | ✅ 런타임 발동 |
+| 변경점: multer 1.x→2.1.1 | ✅ 의도된 보안 대응, API 동일 |
+
+## 7. Gap 목록
+
+| ID | Severity | 내용 | 조치 |
+|----|:--------:|------|------|
+| G1 | Minor | §5 단일 INSERT 서술 vs 2단계 구현 | 문서 동기화(선택) |
+| G2 | Minor | SC-06 podman 빌드 미검증 | 컨테이너 빌드 1회 권장 |
+| G3 | Minor | 파일 content-type 화이트리스트 미적용(NFR-03 일부) | OUT-of-scope 수준, 향후 |
+
+**Critical/Important 갭: 0건.**
+
+## 8. 결론
+
+Overall **99%** (≥90% 목표 달성). Critical/Important 이슈 없음. Minor 3건은 모두 문서/범위 외/검증 절차 항목으로 코드 수정 불요. → iterate 없이 **QA 또는 report** 단계로 진행 가능.