| **근거** | 기존 스크린/슬랫과 동일한 row_index 의미 유지. 구성품 구분은 field_key 패턴으로 해결. DB 스키마 변경 불필요. 이미 TemplateInspectionContent save/restore에 구현 완료. |
| **결정일** | 2026-02-26 |
---
### C2. 기존 절곡 검사 데이터의 실제 저장 구조 오해
**지적자**: Quality Engineer (핵심 발견)
**위치**: 계획서 4.2.3절 하위호환 단락
**문제**: 계획서는 절곡 검사가 EAV(`document_data`)에 row_index 기반 저장된다고 가정했으나, **실제로는**`work_order_items.options.inspection_data`에 JSON으로 저장되며 `products[].id` 매칭 기반으로 복원된다 (BendingInspectionContent L186-199).
**영향**: 하위호환 전략의 전제 자체가 틀림. 마이그레이션 전략 재설계 필요.
**권장안**:
- A) 기존 options.inspection_data 방식을 유지하고, 동적 구성품도 같은 패턴으로 저장
- B) EAV(document_data)로 전환하되 기존 데이터 마이그레이션 포함
- C) 양쪽 모두 지원 (과도기)
| 정책 결정 | |
|----------|---|
| **선택** | Option B — EAV(document_data)로 전환. 기존 options.inspection_data(InspectionInputModal 경로)는 당분간 병행 유지. |
| **근거** | TemplateInspectionContent가 document_data EAV 저장/복원을 담당. InspectionInputModal은 기존 options 경로 유지 (개소별 빠른 입력). 두 경로가 독립적으로 동작하므로 마이그레이션 불필요. |
| **결정일** | 2026-02-26 |
---
### C3. TemplateInspectionContent에 이미 절곡 동적 로직 존재
**지적자**: System Architect (핵심 발견)
**위치**: 계획서 Phase 2 전체 방향
**문제**: 계획서는 "새 API → BendingInspectionContent 동적화"를 핵심으로 삼았으나, `TemplateInspectionContent.tsx`에 이미 구현됨:
-`buildBendingProducts()` (L209-274): `order.bendingInfo`에서 동적 구성품 생성
-`DEFAULT_GAP_PROFILES`: 제품별 간격 포인트 기본값
-`bendingExpandedRows`: BOM 기반 동적 행 확장
**영향**: Phase 2 방향 자체를 재검토해야 할 수 있음. 두 가지 경로:
- A) TemplateInspectionContent의 bending 지원을 확장 → BendingInspectionContent 레거시 대체 (중복 제거)
- B) BendingInspectionContent를 독립 동적화 (기존 계획 유지, 중복 감수)
**권장안**: A) 통합 방향 (System Architect 강력 권장)
| 정책 결정 | |
|----------|---|
| **선택** | Option A — TemplateInspectionContent 통합 방향. BendingInspectionContent는 레거시로 유지하되 신규 개발은 TemplateInspectionContent에서 진행. |
| **근거** | TemplateInspectionContent에 이미 buildBendingProducts, bendingExpandedRows, DEFAULT_GAP_PROFILES 구현됨. bending save/restore 추가 완료 (커밋 7b8b5cf5, 36052f3e). 중복 개발 방지. |
| **결정일** | 2026-02-26 |
---
### C4. BOM 변경 시 기존 검사 문서 데이터 무결성
**지적자**: Backend Architect, Quality Engineer
**위치**: 계획서 4.2.2, 2.4절
**문제**: 검사 문서(DRAFT) 저장 후 BOM이 변경되면 구성품↔데이터 매핑 불일치. APPROVED 문서 조회 시에도 현재 BOM으로 렌더링하면 데이터 어긋남.
**권장안**:
- A) 검사 문서 생성 시점의 BOM 스냅샷을 `document.options.bom_snapshot`에 저장
- B) document_data에 구성품 식별자를 field_key에 포함시켜 순서 독립적 매핑
- C) BOM 변경 시 기존 DRAFT 문서에 경고 표시 + 수동 재매핑 UI
| 정책 결정 | |
|----------|---|
| **선택** | 현행 유지 → BOM 동적화 시점에 Option A+B 병행 (bom_snapshot 저장 + 구성품 식별자 기반 field_key) |
| **근거** | 현재 buildBendingProducts()가 고정 순서로 생성하므로 인덱스 기반 field_key로 충분. BOM API 도입 시 `b{productId}_...` 형태로 전환 + document.options에 스냅샷 저장. |
| **결정일** | 2026-02-26 |
---
### C5. product_code 선행 의존성 fallback 부재
**지적자**: 3명 모두
**위치**: 계획서 8절, 4.1.3절
**문제**: product-code-traceability-plan Phase 1 미완료 시 API가 어떤 제품코드로 구성품을 결정하는지 fallback 없음. product_code 없는 기존 작업지시에 대한 에러 처리도 미정의.
**권장안**:
- A) `order_nodes.options`에서 product_code 추출하는 fallback 경로 추가
- B) product_code 없으면 KWE01 기본값으로 추정 (현행 동작과 동일)
- C) product_code 없으면 빈 배열 반환 → 프론트에서 DEFAULT_PRODUCTS 사용
| 정책 결정 | |
|----------|---|
| **선택** | product_code 전파 누락 수정 (product-code-traceability-plan Phase 1). order_nodes.options → work_order_items.options로 product_code 복사. fallback이 아니라 버그 수정. |
| **근거** | 데이터는 order_nodes.options에 이미 존재. createWorkOrders에서 복사하지 않은 단순 누락. Phase 1 완료 시 해결. 프론트 DEFAULT_PRODUCTS는 Phase 1 완료 전까지 임시 fallback으로 유지. |
| **결정일** | 2026-02-26 |
---
## 🟡 IMPORTANT
### I1. INITIAL_PRODUCTS vs DEFAULT_GAP_PROFILES 기준치 불일치
**지적자**: System Architect
**위치**: BendingInspectionContent L71-135 vs TemplateInspectionContent L176-206
| **선택** | 통일 불필요 — C3에서 TemplateInspectionContent 통합 결정. BendingInspectionContent의 타입(ProductRow, INITIAL_PRODUCTS 등)은 레거시로 동결. 신규 개발은 TemplateInspectionContent의 BendingProduct, DEFAULT_GAP_PROFILES 사용. |
