Add UI/UX design philosophy document combining Palantir's information density and Toss's user-centric approach
This commit is contained in:
DDD1542
@@ -0,0 +1,91 @@
|
||||
# Plan Review Report: API 로직 전체 복구 + 테이블 설정 인라인 구현
|
||||
|
||||
### 1. 플랜 요약
|
||||
COMPANY_7 원본 기준으로 COMPANY_16의 전 화면(43개 파일, 20개 태스크) 데이터 흐름을 동기화하고, 해당 화면에 테이블 설정 기능을 인라인 구현.
|
||||
|
||||
---
|
||||
|
||||
### 2. 문제점 지적
|
||||
|
||||
#### 🔴 수정 필요: ref_files 12개 미존재
|
||||
|
||||
다음 COMPANY_7 원본 파일이 존재하지 않아 에이전트가 참조할 수 없습니다:
|
||||
|
||||
| 태스크 | 누락된 ref_file |
|
||||
|--------|----------------|
|
||||
| task-10 (BOM) | `COMPANY_7/production/bom/page.tsx` |
|
||||
| task-11a (발주) | `COMPANY_7/purchase/order/page.tsx` |
|
||||
| task-11b (구매품목) | `COMPANY_7/purchase/purchase-item/page.tsx` |
|
||||
| task-11b (공급업체) | `COMPANY_7/purchase/supplier/page.tsx` |
|
||||
| task-13b (재고) | `COMPANY_7/logistics/inventory/page.tsx` |
|
||||
| task-13b (창고) | `COMPANY_7/logistics/warehouse/page.tsx` |
|
||||
| task-13b (물류정보) | `COMPANY_7/logistics/info/page.tsx` |
|
||||
| task-14 (금형) | `COMPANY_7/mold/info/page.tsx` |
|
||||
| task-15a (회사) | `COMPANY_7/master-data/company/page.tsx` |
|
||||
| task-15b (검사) | `COMPANY_7/quality/inspection/page.tsx` |
|
||||
| task-15b (품목검사) | `COMPANY_7/quality/item-inspection/page.tsx` |
|
||||
| task-15b (PLC) | `COMPANY_7/equipment/plc-settings/page.tsx` |
|
||||
|
||||
→ 이 12개 ref_file이 없으면 에이전트는 "COMPANY_7 기준으로 동기화"라는 지시를 수행할 수 없습니다. **플랜 실행 전 반드시 해결 필요.**
|
||||
|
||||
---
|
||||
|
||||
#### 🟠 도주 위험
|
||||
|
||||
**task-11a (발주관리)**: context가 "수주관리와 동일 패턴"으로 5줄. ref_file도 누락. 에이전트가 최소 수정만 하고 "완료" 보고할 가능성 높음.
|
||||
|
||||
**task-11b (구매품목+공급업체)**: 2개 파일인데 context가 "판매품목과 동일 패턴"/"거래처관리와 동일 패턴" 한 줄씩. ref_file도 둘 다 누락. 이중 위험.
|
||||
|
||||
**task-17a/17b (리포트)**: "이미 이전 파이프라인에서 수정됨. 누락분 보강" → 에이전트가 "확인 결과 이미 충족" 판단 후 아무것도 안 할 가능성. ref_files가 자기 자신(files == ref_files)이므로 비교 대상이 없음.
|
||||
|
||||
**task-14 (외주+설비+금형)**: 4개 파일인데 각 파일별 context가 한 줄. 금형은 ref_file도 누락.
|
||||
|
||||
---
|
||||
|
||||
#### 🟡 충돌 감지
|
||||
|
||||
파일 겹침은 없습니다. 모든 태스크의 files가 고유합니다. depends도 전부 none으로 순환 없음.
|
||||
|
||||
---
|
||||
|
||||
### 3. 수정 범위 예상
|
||||
|
||||
| 항목 | 수치 |
|
||||
|------|------|
|
||||
| 총 태스크 수 | 20개 |
|
||||
| 대상 파일 수 | 43개 |
|
||||
| ref_file 존재 | 60개 중 48개 (12개 누락) |
|
||||
| 예상 변경 줄 수 | 태스크당 200~800줄 × 20 = **4,000~16,000줄** |
|
||||
|
||||
---
|
||||
|
||||
### 4. 예상 구동시간
|
||||
|
||||
- 20 태스크, max_concurrent: 5 → **4 웨이브**
|
||||
- timeout: 30m/태스크
|
||||
- 최악: 4 × 30m = **2시간**
|
||||
- 현실적: 대부분 1~2파일 태스크 → **1~1.5시간**
|
||||
|
||||
---
|
||||
|
||||
### 5. 검증 단계 확인
|
||||
|
||||
| 검증 | 현재 상태 | 비고 |
|
||||
|------|----------|------|
|
||||
| L1 (tsc --noEmit) | ✅ 전 태스크 설정됨 | 양호 |
|
||||
| L6 (verify/grep) | ✅ 전 태스크 설정됨 | 대부분 주요 함수명/패턴 grep |
|
||||
| L3 (api_test) | ✅ 전 태스크 설정됨 | 실제 API 호출로 검증 |
|
||||
|
||||
verify 품질: task-1은 3개 패턴만 체크(dataFilter, autoFilter, tableSettings)로 다소 약함. [A]~[I] 전체 로직 반영 대비 부족하나, api_test가 보완하므로 수용 가능.
|
||||
|
||||
---
|
||||
|
||||
### 6. 종합 판단
|
||||
|
||||
**ref_files 12개 누락이 가장 큰 블로커입니다.** 이 파일들 없이 실행하면 해당 7개 태스크(task-10, 11a, 11b, 13b, 14, 15a, 15b)가 "참조할 원본 없이 추측 수정"하게 됩니다.
|
||||
|
||||
**추천 조치:**
|
||||
1. 누락 ref_files → COMPANY_7에 해당 파일 생성하거나, 다른 경로에 있다면 경로 수정
|
||||
2. task-11a/11b → context에 task-1/task-2 수준의 상세 로직(useState 목록, API 파라미터, 저장/삭제 패턴) 추가
|
||||
3. task-17a/17b → ref_files를 자기 자신이 아닌 정답 기준 파일로 교체하거나, context에 "최소 diff N줄" 기준 추가
|
||||
4. task-14 금형 → ref_file 없이 수행 가능하도록 context에 전용 API 전체 명세 포함 필요
|
||||
Reference in New Issue
Block a user