eomsangdon/Aislo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

260710_0

Browse Source
This commit is contained in:
eomsangdon
2026-07-10 18:12:17 +09:00
parent 50d75fcfcd
commit e3d66e717c
28 changed files with 2542 additions and 99 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.agent/CONFUSION_0OLD_vs_CURRENT.md
+388
View File
@@ -0,0 +1,388 @@
# 0_old vs 현재 프로젝트 혼선 지점 분석 (Critical for Coders)
**작성일:** 2026-07-10
**목적:** 0_old 코드 참고 시 발생할 수 있는 통합 오류 사전 차단
---
## 1. 데이터 구조 & 저장소 경로 차이
### 1.1 저장소 경로 구조
| 항목 | 0_old | 현재 프로젝트 |
|------|-------|------------|
| **기본 경로** | `storage/projects/{projectId}/` | `storage/{company_slug}/{user_slug}/{projectId}/` |
| **원본 입력** | `input/` (명확하지 않음) | `B03_FileInput/input/` |
| **처리 결과** | `processed/` (모든 것을 한곳에) | `B04_wf1_Surface/processed/` (분산) |
| **지표면 모델** | `processed/` 내 JSON | `B04_wf1_Surface/models/` |
| **경로 데이터** | `route_design/` | `B05_wf2_Route/route/` |
| **종횡단면** | `sections/` | `B06_wf3_ProfileCross/` |
**코더 주의:**
- 0_old의 경로를 그대로 현재 코드에 복사하면 **파일을 찾을 수 없음**
- 항상 `config_system.py`의 `PROJECT_STORAGE_STAGE_DIRS` 확인
- 경로 변환은 `common_util_storage.py`의 `resolve_stored_project_path()` 사용
**예시 오류:**
```python
# ❌ 0_old 방식
path = f"storage/projects/{projectId}/processed/tin.json"
# ✅ 현재 방식
from common_util.common_util_storage import resolve_stored_project_path
stored_path = await get_project_storage_relative_path(connection, projectId)
project_root = Path(resolve_stored_project_path(stored_path))
path = project_root / "B04_wf1_Surface" / "models" / "tin.json"
```
---
## 2. API 엔드포인트 & 요청/응답 구조
### 2.1 0_old API 엔드포인트
| 메서드 | 경로 | 목적 |
|--------|------|------|
| GET | `/api/projects/{projectId}/analysis` | 분석 결과 조회 |
| GET | `/api/projects/{projectId}/las-points` | LAS 포인트 샘플 조회 |
| GET | `/api/projects/{projectId}/all-points` | 모든 포인트 조회 |
| GET | `/api/projects/{projectId}/ground-points` | 지면 포인트만 조회 |
| POST | `/api/projects/{projectId}/analyze-ground` | 분석 실행 (동기) |
| GET | `/api/projects/{projectId}/terrain-models` | 지표면 모델 목록 |
| POST | `/api/projects/{projectId}/route/solve` | 경로 계산 |
| POST | `/api/projects/{projectId}/sections/generate` | 종횡단면 생성 |
### 2.2 현재 프로젝트 API 엔드포인트
| 메서드 | 경로 | 목적 |
|--------|------|------|
| POST | `/api/projects/{projectId}/surface/analyze` | 분석 실행 (비동기, **상태 저장**) |
| GET | `/api/projects/{projectId}/surface/status` | 분석 상태 및 진행률 조회 |
| GET | `/api/projects/{projectId}/surface/models` | 지표면 모델 목록 |
| GET | `/api/projects/{projectId}/surface/point-cloud` | 포인트 샘플 조회 |
| GET | `/api/projects/{projectId}/surface/ground-stats` | 지면 필터 통계 |
| POST | `/api/projects/{projectId}/files` | 파일 업로드 (다중) |
| POST | `/api/projects/{projectId}/upload-sessions` | 청크 업로드 세션 시작 |
| POST | `/api/projects/{projectId}/chunks` | 청크 업로드 |
| POST | `/api/projects/{projectId}/finalize` | 업로드 완료 |
**코더 주의:**
- 0_old의 `/api/projects/{projectId}/analyze-ground` 는 **현재에 없음**
- 현재는 `/api/projects/{projectId}/surface/analyze` + `/api/projects/{projectId}/surface/status` 조합
- 0_old 코드 마이그레이션 시 **비동기 처리 방식 변경 필수**
---
## 3. 프론트엔드 기술 스택 차이
### 3.1 라이브러리 버전
| 라이브러리 | 0_old | 현재 프로젝트 | 비고 |
|-----------|-------|------------|------|
| React | 19.2.7 | **없음** | **critical diff** |
| React-DOM | 19.2.7 | **없음** | **critical diff** |
| lucide-react | 1.23.0 | **없음** | 아이콘 라이브러리 |
| THREE.js | 0.185.0 | 0.185.0 | ✅ 동일 |
| MapLibre-GL | 5.24.0 | **없음** | 지도 렌더러 |
| TypeScript | 6.0.3 | 5.x (확인 필요) | 버전 차이 가능성 |
**코더 주의:**
- 0_old의 모든 `.tsx` 컴포넌트는 **React 훅 기반**
- 현재 프로젝트는 **바닐라 TypeScript + DOM 조작**
- 0_old 컴포넌트를 현재 프로젝트에 복사하면 **즉시 오류** (React 불가)
### 3.2 필수 변환 규칙 (0_old → 현재)
#### React 훅 → 클로저 + 렌더 함수
```typescript
// ❌ 0_old (React 훅)
function PointCloudViewer({ projectId }: { projectId: string }) {
const [scale, setScale] = useState<number>(1.0);
useEffect(() => { /* initialization */ }, [projectId]);
return <div>...</div>;
}
// ✅ 현재 (바닐라 TS)
function createPointCloudViewer(projectId: string): HTMLElement {
let scale = 1.0;
const container = document.createElement('div');
const initialize = async () => { /* initialization */ };
initialize();
return container;
}
```
#### JSX → `createElement` (또는 템플릿 리터럴)
```typescript
// ❌ 0_old (JSX)
<button onClick={() => handleClick()}>Click me</button>
// ✅ 현재 (DOM 직접 생성)
const button = document.createElement('button');
button.textContent = 'Click me';
button.addEventListener('click', handleClick);
```
#### lucide-react 아이콘 → 인라인 SVG / 유니코드
```typescript
// ❌ 0_old (lucide-react)
import { FileUp } from 'lucide-react';
<FileUp size={24} />
// ✅ 현재 (유니코드 또는 SVG)
const icon = document.createElement('span');
icon.textContent = '📤'; // 또는 인라인 SVG
```
---
## 4. 분석 엔진 & 백엔드 알고리즘
### 4.1 0_old 분석 프로세스
**`0_old/backend/app/analyzer.py`:**
- `analyze_project()` — 동기식 전체 분석 실행
- LAS 로드 및 메타데이터 추출
- 포인트 클라우드 필터 적용 (CSF, PMF, RANSAC, grid_min_z)
- 지표면 모델 생성 (TIN, DTM, NURBS, implicit, meshfree 등)
- 결과를 `storage/projects/{projectId}/processed/analysis.json` 에 저장
**결과 저장 형식:**
```json
{
"timestamp": "2025-07-10T...",
"project_files": { /* file metadata */ },
"point_cloud_summary": { "total": 1000000, ... },
"ground_filter_results": { "csf": { ... }, "pmf": { ... }, ... },
"terrain_models": {
"tin": { "model_file": "...", "contours": [...] },
"dtm": { ... }
}
}
```
### 4.2 현재 프로젝트 분석 프로세스
**`B04_wf1_Surface/B04_wf1_Surface_Engine.py`:**
- `run_surface_analysis()` — 동기식이지만, 라우터에서 `asyncio.to_thread()` 로 실행
- 결과를 여러 개의 DB 테이블에 저장:
- `processed_point_clouds` 테이블
- `surface_models` 테이블
- `terrain_layers` 테이블
- 파일 경로도 함께 DB에 저장 (`model_file_path`, `layer_file_path` 등)
**코더 주의:**
- 0_old는 JSON 파일 중심, 현재는 **DB + 파일 경로 이원화**
- 분석 결과 조회 시:
- 0_old: `storage/projects/{projectId}/processed/analysis.json` 직접 읽기
- 현재: `surface_models` 테이블 쿼리 + 필요한 파일을 경로로 로드
---
## 5. 프론트엔드 상태 관리 & LocalStorage
### 5.1 0_old 상태 관리
**`main.tsx`에서 `useState` 사용:**
- `projectId` — 현재 프로젝트 ID
- `stage` — 현재 워크플로우 단계
- `analysisResult` — 분석 결과 캐시
- `selectedRoute` — 선택된 경로
- 등등
**localStorage 미사용** (또는 매우 제한적)
### 5.2 현재 프로젝트 상태 관리
**`config_frontend.ts`:**
```typescript
const CURRENT_PROJECT_ID_KEY = "frd_current_project_id";
```
**localStorage 의존성:**
- 프로젝트 ID는 반드시 localStorage에 저장
- 페이지 네비게이션 시 projectId 복구
- 청크 업로드 세션 정보도 localStorage 유지
**코더 주의:**
- 0_old 코드를 현재 프로젝트에 옮길 때, localStorage 복구 로직 추가 필수
- 특히 B04, B05, B06 페이지는 모두 `CURRENT_PROJECT_ID_KEY` 의존
---
## 6. 3D 렌더링 (THREE.js) — 유사성
### 6.1 공통점
**0_old와 현재 모두 THREE.js 0.185.0 사용:**
- `PointCloudViewer.tsx` → 포인트 클라우드 렌더링
- `TerrainModelViewer.tsx` → 지표면 모델 렌더링
- OrbitControls 사용 (카메라 조작)
**코더에게 좋은 소식:**
- THREE.js 부분은 상대적으로 간단한 변환 가능
- 렌더 루프, 조명, 카메라 로직은 큰 변경 불필요
- DOM 생성 부분만 수정하면 대부분 재사용 가능
**예시:**
```typescript
// ❌ 0_old (JSX)
<Canvas camera={{ position: [100, 100, 100] }}>
<mesh>...</mesh>
</Canvas>
// ✅ 현재 (THREE.js 직접)
const scene = new THREE.Scene();
const camera = new THREE.PerspectiveCamera(75, width/height, 0.1, 10000);
camera.position.set(100, 100, 100);
const renderer = new THREE.WebGLRenderer();
renderer.render(scene, camera);
```
---
## 7. 필터 알고리즘 (Python) — 재사용 가능
### 7.1 0_old 필터 유틸리티
**`0_old/utils/` 디렉토리:**
- `filter_csf.py` — Cloth Simulation Filter
- `filter_pmf.py` — Progressive Morphological Filter
- `filter_ransac.py` — RANSAC-기반 필터
- `filter_grid_min_z.py` — Grid Min-Z 필터
**현재 프로젝트에서 이 필터들을 사용하는가?**
- ✅ 네, `B04_wf1_Surface_Engine.py`에서 참고
- 동일한 필터 알고리즘 재구현 가능
**코더 주의:**
- 필터 알고리즘은 그대로 복사 가능 (Python 코드)
- 하지만 **경로, DB 저장 방식은 변경 필수**
---
## 8. 라우팅 & 네비게이션 차이
### 8.1 0_old 라우팅
**`main.tsx`에서 React Router 미사용, 수동 state 관리:**
```typescript
if (stage === "TERRAIN_ANALYSIS") {
return <TerrainAnalysisStage />;
} else if (stage === "ROUTE_DESIGN") {
return <RouteDesignStage />;
}
// ...
```
### 8.2 현재 프로젝트 라우팅
**`A00_Common/A00_Common_UI_Navigator.ts`에서 수동 SPA 라우팅:**
```typescript
function navigateTo(route: string): void {
window.location.hash = route;
// ...
}
```
**코더 주의:**
- 0_old 코드를 현재에 적용할 때, `navigateTo()` 사용 필수
- localStorage 저장 + 네비게이션 순서 엄격 준수 (§2.2.2 참고)
---
## 9. 체크리스트 for Coders
0_old 코드를 현재 프로젝트에 통합할 때 반드시 확인:
### 파일 경로
- [ ] `storage/projects/...` → `storage/{company}/{user}/{projectId}/B0N_...` 변환
- [ ] 하드코딩된 경로 제거
- [ ] `resolve_stored_project_path()` 및 `PROJECT_STORAGE_STAGE_DIRS` 사용
### API 호출
- [ ] 엔드포인트 변경 (`/analyze-ground` → `/surface/analyze`)
- [ ] 비동기 처리 추가 (폴링 로직)
- [ ] 요청/응답 포맷 확인
### 프론트엔드 컴포넌트
- [ ] React 훅 → 클로저 + 렌더 함수 변환
- [ ] JSX → `createElement` 또는 템플릿 리터럴 변환
- [ ] lucide-react 아이콘 → 유니코드/인라인 SVG 변환
- [ ] localStorage 의존성 추가 (`CURRENT_PROJECT_ID_KEY`)
### 상태 관리
- [ ] `useState` 호출 제거
- [ ] localStorage에 상태 저장 확인
- [ ] 페이지 리로드 후 복구 로직 확인
### THREE.js 렌더링
- [ ] 캔버스 생성 부분 확인
- [ ] 렌더 루프 설정 확인
- [ ] 이벤트 리스너(resize, click 등) 추가
### DB 저장
- [ ] JSON 파일 저장에서 DB 테이블 저장으로 변경
- [ ] 파일 경로를 DB에 함께 저장
- [ ] 트랜잭션 처리 확인
---
## 10. 예시: 0_old PointCloudViewer 변환
### 0_old (React + JSX)
```typescript
// 0_old/frontend/src/PointCloudViewer.tsx (간략)
export function PointCloudViewer({ projectId }: { projectId: string }) {
const [scale, setScale] = useState(1.0);
const canvasRef = useRef<HTMLCanvasElement>(null);
useEffect(() => {
const canvas = canvasRef.current;
const renderer = new THREE.WebGLRenderer({ canvas });
// 렌더링 설정
}, [projectId]);
return <canvas ref={canvasRef} />;
}
```
### 현재 프로젝트 (바닐라 TS)
```typescript
// B04_wf1_Surface/B04_wf1_Surface_UI_PointCloud.ts (신규)
export function createPointCloudViewer(projectId: string): HTMLElement {
let scale = 1.0;
const canvas = document.createElement('canvas');
const initialize = async () => {
const renderer = new THREE.WebGLRenderer({ canvas });
// 렌더링 설정
const response = await fetch(`/api/projects/${projectId}/surface/point-cloud`);
const data = await response.json();
// 포인트 클라우드 렌더
};
initialize();
return canvas;
}
```
---
## 11. 결론
| 영역 | 재사용 난이도 | 주의사항 |
|------|-----------|---------|
| **경로 구조** | 높음 | 전체 매핑 필요 |
| **API 엔드포인트** | 높음 | 비동기 처리 방식 변경 |
| **프론트엔드 컴포넌트** | 높음 | React → TS 변환 필수 |
| **필터 알고리즘** | 낮음 | 경로 변수만 수정 |
| **THREE.js 렌더링** | 낮음 | JSX → DOM 생성만 수정 |
| **DB 저장 로직** | 높음 | 완전 재작성 |
**최종 권장사항:**
1. 0_old는 **알고리즘 참고용**으로만 사용
2. 경로, API, 컴포넌트 구조는 **현재 프로젝트 표준 준수**
3. 통합 전 **단위 테스트** 작성 (경로 매핑, API 응답 검증)
.agent/plan_wf1_and_upload_improvements.md
+800
View File
@@ -0,0 +1,800 @@
# WF1~WF3 레이아웃 재설계 및 파일 업로드 프로세스 개선 계획서
**작성일:** 2026-07-10 (업데이트)
**상태:** 상세 설계 단계
**범위:** B03_FileInput (파일 업로드 비동기 처리), 대시보드 워크플로우 상태 관리, B04_wf1_Surface~B06_wf3_ProfileCross 공통 레이아웃 템플릿 (0_old 기반)
---
## 1. 개요 및 개선 배경
### 1.1 현재 문제점
1. **B03 파일 업로드**
- 업로드 시작 후 완료될 때까지 UI 로딩 오버레이 활성화 상태 유지 → 사용자 동작 불가
- 페이지 리프레시 시 업로드 진행상황 소실
- 백엔드는 비동기 처리 중인데 프론트엔드는 동기 대기
2. **B01 대시보드 워크플로우 상태**
- 파일 업로드 완료 후 WF1 분석 완료되어도 워크플로우 버튼이 활성화되지 않음
- 대시보드의 프로젝트 상태 변경 로직 미동기화
3. **B04_wf1_Surface, B05_wf2_Route, B06_wf3_ProfileCross 레이아웃**
- 현재 3단 레이아웃(상단+좌측+우측)이 협소함
- 좌측 폼 영역이 항상 표시되어 우측 작업 영역을 제한
- 3D 조작, 경로 설계, 종단/횡단 작업 같은 실무에는 넓은 공간 필수
- 현재 B04 페이지는 카드형 제목만 표시 (불완전)
4. **0_old 프로그램 기반 구현**
- 0_old/frontend/src에 PointCloudViewer.tsx, TerrainModelViewer.tsx, RouteDesignStage.tsx, LongitudinalProfile.tsx, CrossSectionGrid.tsx 등 완성된 컴포넌트 있음
- 0_old/utils에 필터 적용(CSF, PMF, RANSAC, grid_min_z), 경로 계산(dijkstra, ridge_valley), 종횡단 생성 로직 있음
- 0_old/backend/app에 분석 엔진 있음 (분석 결과를 `storage/projects/{projectId}/processed/` 에 JSON/NPZ 형식으로 저장)
- **현재 프로젝트와 통합:** 레이아웃(데스크톱 IDE 스타일)과 테마(Wiza 디자인)는 새로 작성, 콘텐츠와 3D 렌더링은 0_old 참고/재사용
---
## 2. 세부 개선 사항
### 2.1 B03_FileInput 업로드 비동기 처리 개선
#### 2.1.1 현재 상태 (코드 분석)
- 파일 선택/드래그 → 유효성 검증 → 청크 업로드 반복
- `uploadOneFile()` 함수 내 루프에서 모든 청크 업로드 완료 대기
- `showLoadingOverlay()` / `hideLoadingOverlay()` 호출로 UI 블로킹
- 백엔드 `pollWF1Analysis()` 함수로 분석 상태 폴링 (5초 주기, 최대 30분)
#### 2.1.2 개선 계획
**2.1.2.1 파일 업로드 진행 상태 UI 표시 (로딩 오버레이 제거)**
- 로딩 오버레이 제거 → 사용자는 자유롭게 다른 페이지 이동 가능
- 대신 **지속적인 업로드 상태 표시:**
- 각 파일 카드에 진행률 바 및 상태 배지 표시 (이미 구현됨)
- 우상단 토스트: "파일 업로드 중... (60% 완료)" 지속 표시
- 분석 시작 후 토스트 업데이트: "WF1 분석 중... (30% 진행률)"
**2.1.2.2 업로드 세션 정보 localStorage에 지속 저장 + 분석 진행률 함께 저장**
- 현재: 업로드 완료 시 `localStorage.removeItem(storageKey)` 실행 → 페이지 리프레시 시 정보 소실
- 개선: 업로드 완료 후에도 세션 정보 유지 (별도 키: `b03_project_state_${projectId}`)
- 저장 형식:
```json
{
"projectId": "uuid",
"uploadedAt": 1720599600000,
"files": [
{
"slot": "las_laz",
"fileName": "data.las",
"fileSize": 1024000000,
"status": "completed"
}
],
"analysisStatus": "in_progress", // pending | in_progress | completed | failed
"analysisProgress": 30,
"lastCheckedAt": 1720599630000
}
```
- **페이지 리로드 후 복구 로직:**
- localStorage에서 저장된 정보 로드
- 파일 카드들을 "완료" 상태로 표시
- 분석이 진행 중이면 토스트 메시지 "WF1 분석이 계속 진행 중입니다..." 표시
- 백그라운드에서 분석 진행률 폴링 재개
**2.1.2.3 분석 진행 상태 추적 메커니즘**
- **0_old의 구조 분석:**
- 0_old/backend/app/analyzer.py의 `analyze_project()` 함수는 분석을 동기로 실행
- 결과를 `storage/projects/{projectId}/processed/analysis.json` 에 저장
- 프론트엔드는 `/api/projects/{projectId}/analysis` 로 분석 결과를 조회
- **개선 방식 (⚠️ 신규 API 생성 금지 — 기존 API 확장):**
- **기존 API 활용:** `GET /api/projects/{project_id}/surface/status` 가 이미 존재함
(B04_wf1_Surface_Router.py `get_wf1_analysis_status()`, 프론트 클라이언트는 B03_FileInput_Api_Fetch.ts `checkWF1AnalysisStatus()`)
- **기존 구현의 한계 (개선 대상):**
- 현재는 `surface_models` 테이블의 모델 카운트만으로 completed/in_progress 판정
- 분석이 **실패해도 영원히 in_progress** 로 표시됨 (failed 상태 판별 불가)
- 진행률(%) 정보 없음
- **확장 계획:** 기존 엔드포인트 응답에 필드 추가 (경로 변경 없음)
```json
{
"project_id": "uuid",
"status": "in_progress", // pending | in_progress | completed | failed
"model_count": 0,
"progress_percent": 30,
"current_stage": "filter_csf",
"message": "CSF 필터 적용 중"
}
```
- **진행률 기록 위치:** 분석 실행 측(B03_FileInput_Engine_Analyze.py)이 진행 단계마다 진행률을 기록하고, status API가 이를 읽어 응답. 기록 방식은 기존 `common_util_workflow.py` 의 workflow.json 메커니즘(backend.md §5, 원자적 쓰기)을 우선 검토하고, 부적합 시 프로젝트 저장소 루트(`storage/{회사slug}/{사용자slug}/{projectId}/B04_wf1_Surface/`) 하위에 진행률 JSON 파일 저장. **`storage/{projectId}/...` 같은 축약 경로는 실제 구조와 다르므로 사용 금지.**
- 폴링 주기: 기존 B03 코드의 5초 유지 (backend.md §5.3은 workflow 폴링 3초를 규정하므로, 코더는 구현 시 두 값을 config_frontend 상수로 통일할 것)
- 사용자 이탈 대응: 페이지 복귀 시 localStorage 복구 + status API 재폴링으로 진행률 재표시
**2.1.2.4 프로젝트 상태 DB 업데이트 (대시보드 워크플로우 버튼 활성화)**
- 현재: 파일 업로드 → 분석 완료 자동 이동만 처리
- 개선:
- B03_FileInput_Engine_Analyze.py에서 각 분석 단계마다 `projects.status` 업데이트:
- 업로드 완료: `status = 'WF1_ANALYZING'`
- 분석 완료: `status = 'WF1_COMPLETE'`
- DB 업데이트 로직:
```python
await db.execute(
"UPDATE projects SET status = %s, updated_at = NOW() WHERE id = %s",
('WF1_COMPLETE', project_id)
)
```
- 대시보드 워크플로우 테이블에서 프로젝트별 `status` 필드를 읽어 버튼 활성화/비활성화 결정
#### 2.1.3 구현 파일 수정
- **B03_FileInput_UI_Page.ts**
- `startChunkedUpload()` 함수: 로딩 오버레이 제거
- `uploadOneFile()` 함수: 백그라운드 진행 표시로 전환
- 세션 저장 로직 개선 (완료 후 분석 상태 포함)
- 페이지 리로드 시 `detectPausedUploads()` 함수에서 세션 상태 복구
- **B03_FileInput_Api_Fetch.ts**
- 분석 진행률 조회 API 추가: `async function getWF1AnalysisProgress(projectId: string)`
- **B03_FileInput_Engine_Analyze.py**
- 분석 완료 후 `projects.status` 업데이트
- 이메일 발송 후 대시보드 반영 시간 ~5초 이내
---
### 2.2 B01 대시보드 워크플로우 버튼 — 활성화 및 프로젝트 컨텍스트 전달
#### 2.2.1 현재 상태 (코드 검증 완료 — 기존 계획서 v1의 오류 정정)
**버튼 활성화 메커니즘은 이미 존재함:**
- `B01_Dashboard_Repository.py` `_stage_from_status()` (line 20): `projects.status` 문자열에서 stage 번호 계산
- 예: status에 "WF1" 포함 → stage 2, "FILE_UPLOADED" → stage 1, "NEW" → stage 0
- `B01_Dashboard_UI_Page.ts` `workflow()` (line 370): stage 기반으로 B03~B09 버튼 활성/비활성 렌더링
- `enabled = index + 1 <= Math.max(activeStage, 1)` → B03은 항상 활성
**따라서 "버튼이 활성화되지 않는" 실제 원인은 UI가 아니라:**
1. **백엔드가 분석 완료 후 `projects.status`를 갱신하지 않음** → §2.1.2.4에서 해결 (`WF1_ANALYZING` → `WF1_COMPLETE`)
2. 대시보드가 열려 있는 동안 상태 변화를 다시 가져오지 않음 (새로고침해야 반영)
**추가 발견 — 토큰 매칭의 허점:**
- `_stage_from_status()`는 부분 문자열 매칭이므로 `WF1_ANALYZING`과 `WF1_COMPLETE`가 **모두 "WF1" 토큰에 걸려 stage 2**가 됨
- 즉 분석이 진행 중(ANALYZING)이어도 B04 버튼이 열림 → **`_COMPLETE` 접미사까지 확인하도록 수정 필요** (ANALYZING은 직전 단계까지만 활성)
#### 2.2.2 🐞 버그: 워크플로우 버튼으로 진입 시 "현재 프로젝트가 선택되지 않았습니다" 표시
**증상:** 대시보드에서 기존 프로젝트의 B03 버튼 클릭 → 파일 입력 페이지 하단에
"현재 프로젝트가 선택되지 않았습니다. 프로젝트를 먼저 생성하거나 선택하세요." (`ui_template_locale.ts:531` `B03_File_Error_Project`)
**원인 (검증 완료):**
- B03~B06 페이지는 모두 `localStorage.getItem(CURRENT_PROJECT_ID_KEY)` (`"frd_current_project_id"`) 로 프로젝트를 식별
- B03: `B03_FileInput_UI_Page.ts:182` → 값이 비어 있으면 `validateSlots()`가 line 395에서 위 에러 메시지 반환
- 이 키를 **설정하는 곳은 B02 프로젝트 등록 페이지 단 한 곳** (`B02_ProjRegister_UI_Page.ts:154`, 신규 생성 직후)
- 대시보드 워크플로우 버튼의 클릭 핸들러(`B01_Dashboard_UI_Page.ts:391`)는 `navigateTo(route)` 만 호출하고 **프로젝트 ID를 저장하지 않음**
- 심지어 `workflow(activeStage: number)` 함수는 stage 숫자만 받아서 **프로젝트 ID가 함수 스코프에 아예 없음** (호출부 line 362는 행별 `project` 객체를 갖고 있음)
- 결과: 신규 생성 직후가 아닌 경로(기존 프로젝트 진입, localStorage 삭제, 다른 브라우저)에서는 항상 에러
**수정 계획:**
1. `workflow()` 시그니처 변경: `workflow(activeStage: number)` → `workflow(project: ProjectItem)` (또는 `projectId` 추가 인자)
2. 버튼 클릭 핸들러에서 이동 전 프로젝트 ID 저장:
```typescript
button.addEventListener("click", () => {
localStorage.setItem(CURRENT_PROJECT_ID_KEY, project.id);
navigateTo(route);
});
```
3. B03/B04/B05/B06은 수정 불필요 (이미 localStorage에서 읽는 구조이므로 진입 시 자연 해결)
4. 참고: backend.md §5.1의 다중 브라우저 원칙상 localStorage는 브라우저별 격리 — 대시보드 버튼이 유일한 진입점이므로 클릭 시점 저장이 올바른 위치. (장기적으로 라우트 해시에 projectId를 포함하는 방식도 가능하나 라우터 전면 수정이 필요하므로 이번 범위에서 제외)
#### 2.2.3 구현 파일 수정
- **B01_Dashboard_UI_Page.ts**
- `workflow()` 함수: 프로젝트 ID를 받아 클릭 시 `CURRENT_PROJECT_ID_KEY` 저장 (§2.2.2)
- 분석 진행 중인 프로젝트가 있을 때만 목록 재조회 폴링 (5초) — 상태 변화 자동 반영
- **B01_Dashboard_Repository.py**
- `_stage_from_status()`: `_COMPLETE` 접미사 구분 로직 추가 (ANALYZING 상태에서 다음 단계 버튼 미개방)
- 신규 API 불필요 — 기존 프로젝트 목록 API 재사용 (workflow_stage 필드 이미 포함)
---
### 2.3 WF1~WF6 공통 레이아웃 템플릿 설계
#### 2.3.1 목표
- **오프라인 프로그램 스타일 인터페이스** (AutoCAD, QGIS 같은 데스크톱 프로그램의 레이아웃)
- 헤더 숨김/표시 토글 기능
- 좌측 패널 (메뉴 + 설정) = 오버레이 구조로 토글 가능
- 우측 대형 캔버스/뷰 영역 (3D 렌더링, 도면, 테이블 등)
#### 2.3.2 레이아웃 구조
```
┌─────────────────────────────────────────────────────────┐
│ [≡] 로고 | Aislo 프로젝트명 | WF 진행률 | 설정 | 언어 | 로그아웃 │ ← 헤더 (숨기기 가능)
└─────────────────────────────────────────────────────────┘
│ │
│ [▶] ◄── 드롭다운 화살표 (헤더 숨김 시 표시) │
│ │
│ ┌─────────────┐ ┌──────────────────────────────────────┐ │
│ │ 메뉴패널 │ │ │ │
│ │ (토글) │ │ 메인 작업 영역 │ │
│ │ │ │ (3D 뷰어, 표, 그래프 등) │ │
│ │ WF1: 지표면 │ │ │ │
│ │ - 필터 설정 │ │ [← 이 영역이 전체 브라우저 크기의│ │
│ │ - 모델 선택 │ │ 좌우상하 8% 정도 여유만 남기고 │ │
│ │ - 실행 │ │ 전부 사용] │ │
│ │ │ │ │ │
│ │ WF2: 경로 │ │ │ │
│ │ - 경로 매개 │ │ │ │
│ │ ... │ │ │ │
│ └─────────────┘ └──────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
```
#### 2.3.3 상세 스펙
**2.3.3.1 헤더 (createWorkflowShell 확장)**
- 현재: 페이지 타이틀 + 스텝바 표시
- 개선:
- 좌상단: `[≡]` 메뉴 토글 버튼 추가 (아이콘)
- 중앙: 프로젝트명 + 현재 WF 단계 표시
- 우상단: 기존대로 (설정, 언어, 로그아웃)
- 숨기기 기능: 헤더 전체를 슬라이드업 (CSS 애니메이션)
- 헤더 숨김 상태: 중앙에 `[▶]` 화살표 표시 → 클릭하면 드롭다운 메뉴 표시
**2.3.3.2 좌측 메뉴 패널 (오버레이 구조)**
- 고정 너비: 240px (닫힌 상태 시 0px)
- 오버레이 Z-index: 1000
- 콘텐츠:
- WF1: 필터 선택 (grid_min_z, csf, pmf, ransac)
- WF1: 모델 방식 선택 (tin, dtm, nurbs, implicit, meshfree)
- WF1: 강제 재계산 체크박스
- WF1: 실행 버튼
- (다른 WF는 각자 필요한 설정)
- 토글 방식:
- 헤더의 `[≡]` 클릭 → 패널 슬라이드인/아웃 (CSS 트랜지션)
- 또는 패널 바깥 클릭 → 패널 닫기
- 스타일: 디자인 가이드 `.agent/design.md` 준수
- **⚠️ frontend.md §1 규칙: CSS에 hex 코드 직접 입력 금지.** 아래 hex는 참고용이며, 실제 코드는 반드시 `ui_template/ui_template_theme.css` 에 선언된 CSS 변수만 참조할 것. design.md의 토큰이 theme.css에 없으면 theme.css에 변수를 먼저 추가한 뒤 사용
- 배경: paper 계열 (참고: #f6f7fa)
- 텍스트: charcoal 계열 (참고: #333333)
- 섹션 타이틀: Inter 500 14px
- 섹션 간 구분: mist 계열 1px 보더 (참고: #e6e2e3)
- 폼 요소: 기존 `createInputField`, `createButton` 재사용. **체크박스 공통 컴포넌트는 현재 없음** (frontend.md §2.1 목록에 부재) — B04 기존 코드의 `buildCheckboxGroup()` 패턴을 `ui_template_elements.ts` 로 승격하여 공통화 권장
**2.3.3.3 메인 작업 영역 (우측)**
- 전체 브라우저 크기에서 좌우상하 8% 여유 남기고 차지
- 배경: `--color-canvas` (#ffffff)
- 콘텐츠별 렌더링:
- WF1: 3D 포인트클라우드 뷰어 (0_old의 PointCloudViewer.tsx 참고)
- WF1: 모델 카드 그리드 (선택 가능)
- WF2: 경로 설계 맵/캔버스
- WF3: 종단면/횡단면 2D 뷰어
- (다른 WF는 각자 콘텐츠)
- 반응형 레이아웃: 메뉴 토글 시 우측 영역 자동 너비 조정
#### 2.3.4 레이아웃 템플릿 구현 파일
- **ui_template/ui_template_workflow_layout.ts** (신규)
- 함수: `createWorkflowLayout(options: WorkflowLayoutOptions)`
- 옵션:
```typescript
interface WorkflowLayoutOptions {
title: string; // 페이지 타이틀
steps: string[]; // 워크플로우 단계들
activeStep: number; // 현재 단계 인덱스
leftPanel: HTMLElement; // 좌측 설정 패널
mainContent: HTMLElement; // 우측 메인 콘텐츠
onHeaderToggle?: (isVisible: boolean) => void; // 헤더 토글 콜백
onMenuToggle?: (isOpen: boolean) => void; // 메뉴 토글 콜백
}
```
- 반환: 완성된 DOM 구조 + 토글 컨트롤 함수
- 내부 스타일: 별도 CSS 파일 `ui_template/ui_template_workflow_layout.css` 에서 관리
---
### 2.4 B04_wf1_Surface, B05_wf2_Route, B06_wf3_ProfileCross 페이지 재구현 (0_old 기반)
#### 2.4.1 0_old 프로그램 분석
**데이터 흐름 (0_old):**
1. LAS 파일 업로드 → `storage/projects/{projectId}/raw/` 저장
2. `analyze_project(projectId)` 실행:
- LAS 데이터를 컴퓨터가 읽기 좋은 형태로 변환 (NumPy arrays, JSON)
- `storage/projects/{projectId}/processed/` 에 저장:
- `las-points-sample.json` — 샘플링된 포인트 (3D 뷰어용)
- `analysis.json` — 메타데이터 (bounds, CRS, point_count 등)
3. 필터 선택 (grid_min_z, csf, pmf, ransac) → 지면 포인트 추출
- `storage/projects/{projectId}/processed/ground-stats.json` 저장
4. 모델 방식 선택 (tin, dtm, nurbs, implicit, meshfree) → 지표면 생성
- 각 모델별 결과: `storage/projects/{projectId}/processed/{model_type}.json`
5. 프론트엔드:
- PointCloudViewer.tsx: 3D 포인트클라우드 렌더링 (WebGL/THREE.js)
- TerrainModelViewer.tsx: 지표면 모델 3D 렌더링
**구현 요소:**
- 0_old/frontend/src:
- `PointCloudViewer.tsx` — 포인트클라우드 3D 뷰어
- `TerrainModelViewer.tsx` — 지표면 모델 뷰어
- `RouteDesignStage.tsx` — WF2 경로 설계 (Dijkstra, Ridge-Valley 알고리즘)
- `LongitudinalProfile.tsx` — WF3 종단면 2D 그래프
- `CrossSectionGrid.tsx` — WF3 횡단면 2D 그래프
- `sectionTypes.ts` — 종횡단 데이터 타입
- 0_old/utils:
- `filter_*.py` (CSF, PMF, RANSAC, grid_min_z) — 지면 필터
- `terrain_model_converter.py` — 지표면 모델 생성
- `section_generator.py` — 종횡단 생성
- `route_solver*.py` — 경로 계산
#### 2.4.2 현재 프로젝트에서의 재사용 방식
**레이아웃:** 새 작성 (데스크톱 IDE 스타일 + Wiza 테마)
**콘텐츠 & 3D 렌더링:** 0_old 코드 참고/재사용
**데이터:** 백엔드에서 동일한 구조로 저장
**⚠️ 필수 제약 1 — React → Vanilla TS 전환:**
- 0_old 프론트엔드는 **React 19 + JSX(.tsx) + lucide-react 아이콘** 기반
- 현재 프로젝트는 **React 미사용** (package.json에 react 없음 — three, maplibre-gl만 존재). 순수 TypeScript DOM 조작 방식 (`document.createElement`, `createButton` 등)
- 따라서 0_old 컴포넌트는 **절대 그대로 복사 불가**. 다음 규칙으로 재작성:
- React 훅(`useState`, `useEffect`, `useRef`) → 클로저 변수 + 명시적 렌더 함수로 변환 (B03/B04 기존 페이지 코드의 패턴 참고)
- JSX → `document.createElement` + `append` 방식
- `lucide-react` 아이콘 → 사용 불가. 인라인 SVG 문자열 또는 유니코드 기호로 대체 (B03의 `icon: "●"` 패턴 참고)
- THREE.js 씬 구성 로직(카메라, OrbitControls, BufferGeometry 등)은 React와 무관하므로 **거의 그대로 재사용 가능** — 0_old에서 가장 가치 있는 부분
- 0_old의 API 호출부(`fetch(API_BASE...)`)는 현재 프로젝트의 `Api_Fetch.ts` 패턴(credentials: "include", 타임아웃, 오류 변환)으로 교체
**⚠️ 필수 제약 2 — 백엔드 엔진은 이미 이식 완료:**
- 0_old/utils의 필터·모델 로직은 **이미 B04_wf1_Surface_Engine_*.py 로 이식되어 존재함**
(Filter_Grid/CSF/PMF/RANSAC, ModelBuild, Smooth, Contour, Pipeline, Structurize 모두 존재 확인됨)
- 코더는 백엔드 분석 로직을 **재이식하지 말 것**. 필요한 백엔드 작업은:
1. `/surface/status` 응답 확장 (진행률)
2. `/surface/point-cloud`, `/surface/ground-stats` 신규 엔드포인트 (기존 Engine 산출물을 읽어 반환)
3. `projects.status` 갱신 로직
- WF2/WF3 백엔드(route_solver, section_generator)는 아직 미이식 → Phase 5/6에서 0_old/utils 참고해 이식
**⚠️ 필수 제약 3 — 700줄 제한 (CLAUDE.md):**
- PointCloudViewer 등 대형 컴포넌트 이식 시 700줄 초과 가능성 높음
- 사전에 파일 분할 설계: 예) `B04_wf1_Surface_UI_Viewer.ts` (3D 씬), `B04_wf1_Surface_UI_ViewerControls.ts` (조작 패널) 분리 후 structure.md 갱신
**진행 방식:**
1. 0_old의 각 컴포넌트를 위 제약에 따라 vanilla TS로 재작성 (파일명 규칙: `[폴더명]_[기능].ts`)
2. 백엔드는 기존 B04 Engine 재사용 + API 확장만 수행
3. 레이아웃 템플릿만 새로 작성 (모든 WF에서 재사용)
#### 2.4.3 B04_wf1_Surface 재구현 계획
**사용자 흐름:**
```
[좌측 메뉴] [우측 메인 영역]
┌────────────────┐ ┌──────────────────────┐
│ WF1 지표면 │ │ 1. 포인트클라우드 │
│ ───────────── │ ──────→ │ 3D 뷰어 │
│ 필터 선택: │ │ 2. 필터 적용 후 │
│ ☑ grid_min_z │ │ 지표면 모델 선택 │
│ ☑ CSF │ │ (카드: TIN, DTM..│
│ ☑ PMF │ │ 3. 모델 상세 뷰 │
│ ☑ RANSAC │ │ (해상도, 파일크기│
│ │ │ │
│ 모델 선택: │ │ [▼] 다음 단계 진행 │
│ ☑ TIN │ │ │
│ ☑ DTM │ └──────────────────────┘
│ ☑ NURBS │
│ ☑ Implicit │
│ ☑ Meshfree │
│ │
│ [분석 실행] │
│ (또는 진행률) │
└────────────────┘
```
**구현:**
1. **좌측 메뉴 패널:**
- 필터 체크박스 (0_old: grid_min_z, csf, pmf, ransac)
- 모델 선택 체크박스 (0_old: tin, dtm, nurbs, implicit, meshfree)
- "강제 재계산" 체크박스
- "분석 실행" 버튼 (또는 진행률 표시)
2. **우측 메인 영역 (탭 또는 스테이지 표시):**
- **탭 1: 포인트클라우드 뷰어**
- 0_old의 PointCloudViewer.tsx 재사용
- 밀도 조절, 포인트 크기, 축 표시/숨기기 기능
- **탭 2: 필터 결과 선택**
- 각 필터별 포인트 통계 표시
- 선택한 필터에 대해 "분석 실행"
- **탭 3: 지표면 모델 선택**
- 모델 카드 그리드:
- 모델 이름 (TIN, DTM, ...)
- 상태 배지 (완료/진행 중)
- 선택 버튼
- 선택한 모델의 상세 정보:
- 해상도, 생성 시간, 파일 크기
- 3D 미리보기 (TerrainModelViewer.tsx)
- **탭 4: 분석 진행 중 (선택사항)**
- 진행률 바, 현재 단계, ETA
3. **API & 백엔드 (§4 표 참조 — 기존 API 재사용 우선):**
- `POST /surface/analyze` — ✅ 기존 (분석 실행: 필터 + 모델)
- `GET /surface/models` — ✅ 기존 (모델 목록)
- `GET /surface/status` — ✅ 기존, 진행률 필드 확장
- `GET /surface/point-cloud` — 🆕 신규 (포인트클라우드 샘플)
- `GET /surface/ground-stats` — 🆕 신규 (필터별 통계)
4. **UX 개선 (기존 B04의 문제 해결):**
- 현재 B04는 사용자가 `input_file_id`를 숫자로 직접 입력해야 함 → **자동화**: 페이지 진입 시 프로젝트의 input_files 목록을 조회해 LAS 파일을 자동 선택 (사용자 직접 입력 제거)
- B03 업로드 직후 백엔드가 자동으로 분석을 실행하므로(B03_FileInput_Engine_Analyze.py), B04의 "분석 실행" 버튼은 **재분석(force) 용도**임을 UI에 명시 (예: 버튼명 "재분석 실행")
#### 2.4.4 B05_wf2_Route 재구현 계획
**사용자 흐름:**
```
[좌측 메뉴] [우측 메인 영역]
┌────────────────┐ ┌──────────────────────┐
│ WF2 경로 설계 │ │ 지표면 3D 뷰 │
│ ───────────── │ ──────→ │ + 경로 선 그려짐 │
│ 시작점(B점) │ │ │
│ 끝점(E점) │ │ [마우스: 경로점 │
│ 중간점(C점) │ │ 클릭하여 추가] │
│ 도움점(A점) │ │ │
│ 피해회피점(F점) │ [▼] 다음 단계 진행 │
│ │ └──────────────────────┘
│ 알고리즘: │
│ ○ Dijkstra │
│ ○ Ridge-Valley
│ │
│ 임도 등급: │
│ ○ 간선임도 │
│ ○ 지선임도 │
│ ○ 작업임도 │
│ │
│ 최소 곡선반경: │
│ [______] m │
│ │
│ 포장 여부: │
│ ☐ 포장 │
│ │
│ [경로 계산] │
└────────────────┘
```
**구현:**
1. 0_old의 RouteDesignStage.tsx 참고
2. 좌측: 매개변수 입력 (알고리즘, 등급, 곡선반경, 포장)
3. 우측: 3D Canvas
- 지표면 모델 렌더링 (TerrainModelViewer)
- 사용자가 클릭하여 경로점 추가
- 계산된 경로 선 표시
#### 2.4.5 B06_wf3_ProfileCross 재구현 계획
**사용자 흐름:**
```
[좌측 메뉴] [우측 메인 영역]
┌────────────────┐ ┌──────────────────────┐
│ WF3 종횡단 │ │ 1. 종단면 2D 그래프 │
│ ───────────── │ ──────→ │ (거리 vs 고도) │
│ 기준점 간격: │ │ │
│ [50] m │ │ [▼] 기준점 선택 │
│ │ │ │
│ 횡단면 너비: │ │ 2. 횡단면 2D 그래프 │
│ [20] m │ │ (오프셋 vs 고도) │
│ │ │ │
│ 샘플 간격: │ │ [▼] 다음 단계 진행 │
│ [1] m │ └──────────────────────┘
│ │
│ 연직 과장: │
│ [1.0] x │
│ │
│ 엔드포인트 │
│ 포함: │
│ ☐ 포함 │
│ │
│ [생성] │
└────────────────┘
```
**구현:**
1. 0_old의 LongitudinalProfile.tsx, CrossSectionGrid.tsx 참고
2. 좌측: 종횡단 매개변수 입력
3. 우측:
- 탭 1: 종단면 2D 그래프 (LongitudinalProfile.tsx)
- 탭 2: 횡단면 2D 그래프 (CrossSectionGrid.tsx)
- 기준점 선택 → 해당 종/횡단면 표시
#### 2.4.6 공통 레이아웃 템플릿
모든 WF(B04~B06)이 공유하는 레이아웃:
- **헤더:** 숨김/표시 토글, 프로젝트명, WF 단계
- **좌측 메뉴:** 매개변수 입력 (각 WF별로 상이)
- **우측 메인:** 3D 뷰어 또는 2D 그래프 (각 WF별로 상이)
- **스타일:** Wiza 테마 준수 (색상, 타입, 간격)
---
## 3. 데이터베이스 변경사항
### 3.1 projects 테이블 상태 값 확장
- 기존: `NEW`, `FILE_UPLOADED`, `WF1_ANALYZING`, `WF1_COMPLETE`, ...
- 추가 사항: 상태 변경 타이밍
- `FILE_UPLOADED` → `WF1_ANALYZING` (분석 시작 시)
- `WF1_ANALYZING` → `WF1_COMPLETE` (분석 완료 시)
- 각 단계 완료 후 이메일 발송 (기존)
### 3.2 업로드 세션 저장소 (클라이언트 localStorage 사용)
- DB 변경 없음 (localStorage에 JSON 저장)
- **키 이름 (§2.1.2.2와 동일 — 단일 키로 통일):** `b03_project_state_${projectId}`
- 값 형식은 §2.1.2.2 참조 (files, analysisStatus, analysisProgress, lastCheckedAt)
- 주의: localStorage는 브라우저별 격리(backend.md §5.1)이므로 **표시 복구 용도로만** 사용. 진실의 원천(source of truth)은 항상 서버(status API + DB `projects.status`)이며, 페이지 진입 시 서버 값으로 localStorage를 덮어쓴다.
---
## 4. API 엔드포인트 추가/수정
### 4.0 기존 API 현황 (⚠️ 코더는 신규 생성 전 반드시 확인 — 중복 생성 금지)
| 엔드포인트 | 메서드 | 상태 | 위치 |
|-----------|--------|------|------|
| `/api/projects/{id}/surface/analyze` | POST | ✅ 존재 (분석 실행 + DB 기록) | B04_wf1_Surface_Router.py |
| `/api/projects/{id}/surface/models` | GET | ✅ 존재 (모델 목록) | B04_wf1_Surface_Router.py |
| `/api/projects/{id}/surface/status` | GET | ✅ 존재 (확장 필요 — §2.1.2.3) | B04_wf1_Surface_Router.py |
| `/api/projects/{id}/upload-sessions`, `/chunks`, `/finalize`, `/upload-status/{sid}` | POST/GET | ✅ 존재 (청크 업로드) | B03_FileInput_Router.py |
### 4.1 신규 API (네이밍은 기존 `/surface/` 컨벤션 준수, `/wf1/` 접두사 사용 금지)
| 엔드포인트 | 메서드 | 설명 | 백엔드 파일 |
|-----------|--------|------|-----------|
| `/api/projects/{id}/surface/point-cloud` | GET | 포인트클라우드 샘플 (3D 뷰어용, 0_old `las-points-sample.json` 방식) | B04_wf1_Surface_Router.py |
| `/api/projects/{id}/surface/ground-stats` | GET | 필터별 지면 통계 | B04_wf1_Surface_Router.py |
| WF2/WF3 API | - | B05/B06 구현 시 동일 패턴으로 설계 (예: `/route/...`, `/sections/...`) | B05/B06 Router |
### 4.2 수정 API
| 엔드포인트 | 변경사항 |
|-----------|--------|
| `GET /api/projects/{id}/surface/status` | 응답에 `progress_percent`, `current_stage`, `message` 추가 + failed 상태 판별 (§2.1.2.3) |
| 대시보드 프로젝트 목록 API | 응답에 각 프로젝트의 `status` 필드 포함 여부 확인 후 필요 시 추가 (projects 테이블에 status 열 존재함) |
---
## 5. 프론트엔드 컴포넌트 신규 작성
### 5.1 WorkflowLayout 템플릿
- **파일:** `ui_template/ui_template_workflow_layout.ts`
- **파일:** `ui_template/ui_template_workflow_layout.css`
- **함수 시그니처:**
```typescript
export function createWorkflowLayout(options: WorkflowLayoutOptions): HTMLElement
```
### 5.2 PointCloudViewer 컴포넌트 (0_old 기반 개조)
- **파일:** `B04_wf1_Surface_UI_Viewer.ts` (700줄 제한 대비 별도 파일 — §2.4.2 제약 3)
- **의존성 (확인 완료):**
- `three@^0.185.0` — ✅ 현재 package.json에 설치됨 (0_old와 동일 버전)
- `maplibre-gl@^5.24.0` — ✅ 설치됨
- `geotiff` — ❌ 미설치 (0_old에는 있음). TIF 래스터를 프론트에서 직접 파싱할 경우에만 추가 필요. 백엔드에서 PNG 프리뷰로 변환해 전달하면 불필요 — **백엔드 변환 방식 권장** (0_old도 `preview.png` 생성 방식 사용)
- `lucide-react` — ❌ 사용 불가 (React 전용). 인라인 SVG/유니코드로 대체 (§2.4.2 제약 1)
- **주의:** React 훅 → vanilla TS 변환 필수 (§2.4.2 제약 1), 테마 변수 사용, 디자인 가이드 준수
### 5.3 모델 카드 프리뷰 컴포넌트
- **파일:** `ui_template/ui_template_elements.ts` 에 추가
- **함수:** `createSurfaceModelCard(model: SurfaceModelSummary, isSelected: boolean, onSelect: () => void)`
---
## 6. 구현 순서 및 의존성
### Phase 별 구현 계획
**Phase 1: 공통 인프라 (1~2일)**
- B03_FileInput_UI_Page.ts: 로딩 오버레이 제거 → 토스트 + localStorage로 전환
- B03_FileInput_Api_Fetch.ts: `getWF1AnalysisProgress()` API 추가
- localStorage 저장/복구 로직 구현
- 백엔드: 분석 진행률 파일(`.wf1_progress`) 작성 로직
**Phase 2: 대시보드 연동 (1일)**
- 🐞 워크플로우 버튼 클릭 시 `CURRENT_PROJECT_ID_KEY` 저장 버그 수정 (§2.2.2 — 최우선, 소규모)
- `_stage_from_status()`: ANALYZING/COMPLETE 구분 로직 (§2.2.1)
- 분석 진행 중 프로젝트 존재 시 목록 재조회 폴링 (5초 주기)
**Phase 3: WorkflowLayout 템플릿 (1~2일)**
- `ui_template/ui_template_workflow_layout.ts/css` 새로 작성
- 헤더 토글, 메뉴 오버레이 토글 기능
- Wiza 테마 색상/타이포그래피 준수
**Phase 4: B04_wf1_Surface 이식 (2~3일)**
- 0_old/PointCloudViewer.tsx → B04 컴포넌트 이식 (테마 적용)
- 0_old/TerrainModelViewer.tsx 이식
- B04_wf1_Surface_UI_Page.ts: 새 레이아웃 + 탭 구조
- API: `/wf1/analysis`, `/wf1/point-cloud`, `/wf1/ground-stats`, `/wf1/progress`
- 백엔드: 기존 분석 로직 + 진행률 추적
**Phase 5: B05_wf2_Route 이식 (2~3일)**
- 0_old/RouteDesignStage.tsx 이식
- B05_wf2_Route_UI_Page.ts: 새 레이아웃 + 3D Canvas
- API: `/wf2/surface-bounds`, `/wf2/calculate-route`, `/wf2/progress`
- 백엔드: 경로 계산 로직 (Dijkstra, Ridge-Valley)
**Phase 6: B06_wf3_ProfileCross 이식 (2~3일)**
- 0_old/LongitudinalProfile.tsx, CrossSectionGrid.tsx 이식
- B06_wf3_ProfileCross_UI_Page.ts: 새 레이아웃 + 2D 그래프 탭
- API: `/wf3/section-generation`, `/wf3/progress`
- 백엔드: 종횡단 생성 로직
**Phase 7: WF4~WF6 준비 (선택사항, 현재는 미구현)**
- 레이아웃 템플릿만 적용
- 콘텐츠는 향후 구현
---
## 7. 테스트 및 검증 계획
### 7.1 B03 파일 업로드
- [ ] 큰 파일 업로드 시 로딩 오버레이 없음 확인
- [ ] 업로드 중 다른 페이지 이동 가능 확인
- [ ] 페이지 리프레시 후 업로드 상태 복구 확인
- [ ] 분석 진행률 업데이트 확인
### 7.2 대시보드 워크플로우
- [ ] 분석 완료 후 WF1 버튼 활성화 확인
- [ ] 이메일 도착 후 대시보드 상태 갱신 확인
- [ ] 워크플로우 상태 폴링 작동 확인
- [ ] **기존 프로젝트의 B03 버튼 클릭 → "프로젝트가 선택되지 않았습니다" 에러 없이 진입 확인 (§2.2.2)**
- [ ] localStorage 비운 상태(시크릿 창)에서 워크플로우 버튼 진입 확인
- [ ] 프로젝트 2개 이상일 때 각 행의 버튼이 해당 프로젝트로 진입하는지 확인 (ID 교차 오염 없음)
- [ ] `WF1_ANALYZING` 상태에서 B04 버튼이 열리지 않는지 확인 (§2.2.1 토큰 매칭 수정)
### 7.3 WF1 레이아웃
- [ ] 헤더 숨김/표시 토글 작동 확인
- [ ] 메뉴 패널 오버레이 슬라이드 작동 확인
- [ ] 3D 포인트클라우드 렌더링 확인 (성능)
- [ ] 모델 카드 선택/상세 뷰 작동 확인
- [ ] 진행률 폴링 업데이트 확인
- [ ] input_file_id 자동 선택 확인 (수동 입력 제거 — §2.4.3)
- [ ] 분석 실패 시 failed 상태 표시 확인 (§2.1.2.3 status API 확장)
### 7.3.1 WF2 경로 설계 (Phase 5)
- [ ] 지표면 3D 뷰 위 경로점(BP/EP/CP/AP/FP) 클릭 추가 확인
- [ ] Dijkstra / Ridge-Valley 알고리즘 선택 및 경로 계산 확인
- [ ] 임도 등급·곡선반경·경사 한계 매개변수 반영 확인
### 7.3.2 WF3 종횡단 (Phase 6)
- [ ] 종단면 그래프 렌더링 + 기준점 선택 연동 확인
- [ ] 횡단면 그리드 렌더링 확인
- [ ] 기준점 간격/횡단 너비/연직 과장 매개변수 반영 확인
### 7.4 반응형 및 성능
- [ ] 다양한 브라우저 윈도우 크기에서 레이아웃 정렬 확인
- [ ] 포인트클라우드 대용량 렌더링 성능 (프레임률, 메모리)
- [ ] 모바일 환경에서 오버레이 레이아웃 작동 확인 (선택사항)
---
## 8. 위험 요소 및 제약사항
### 8.1 위험 요소
- **포인트클라우드 렌더링 성능:** 수억 개 포인트 샘플링/렌더링 시 프레임률 저하
- 대책: 밀도 조절 기능, 초기 샘플링 제한
- **대역폭:** 포인트클라우드 데이터 전송 시간
- 대책: 압축, 샘플링, 청크 다운로드
- **폴링 주기:** 분석 진행률 폴링이 너무 빈번하면 서버 부하 증가
- 대책: 5초 주기 유지
### 8.2 제약사항
- **디자인 가이드 준수:** `.agent/design.md`에 정의된 색상, 타이포그래피, 간격 엄격히 준수
- **레이아웃 재사용:** WF1~WF6이 동일 템플릿 사용하므로 템플릿 설계 철저히
- **백엔드 의존성:** 포인트클라우드 데이터, 진행률 API를 백엔드에서 제공해야 함
---
## 9. 주요 고려사항
### 9.1 대역폭 & 성능
- **포인트클라우드 샘플링:** 0_old는 최대 1000만 개 포인트 샘플링 후 JSON으로 전송
- 현재 프로젝트에서도 동일 방식 적용
- 필요시 바이너리 포맷(protobuf) 검토
- **3D 렌더링:** THREE.js 사용 (0_old와 동일)
- 성능 최적화: LOD(Level of Detail), 프러스텀 컬링 필요
- 모바일: 포인트 수 감소, 해상도 낮춤
### 9.2 브라우저 호환성
- Chrome/Edge/Firefox 최신 버전
- 모바일 사파리: 제한적 지원 (대역폭, 성능)
- WebGL 지원 필수
### 9.3 0_old 코드 이식 시 주의사항
- **좌표계:** CRS(EPSG:5178 등) 변환 로직 유지
- **단위:** 미터 기준 (높이, 거리, 반경 등)
- **파일 포맷:** JSON 저장 방식 통일 (MariaDB와 JSON 호환)
### 9.4 반응형 레이아웃
- 좌우측 너비 동적 조정
- 좌측 메뉴 토글 시 우측 캔버스 자동 확장
- 모바일: 전체 화면 사용 (좌측 메뉴는 오버레이만 표시)
---
## 10. 저장소 구조 정정 (코드베이스 검증)
### 10.0 계획서 §10.3 저장소 구조는 **0_old 기반이며, 현재 프로젝트와 다름**
**0_old 구조** (analyzer.py line 19):
```
storage/projects/{projectId}/
├── raw/ → 원본 파일
└── processed/ → 변환·분석 결과
```
**현재 프로젝트 실제 구조** (config_system.py line 240, 260, 247-256):
```
storage/{company_slug}/{user_slug}/{projectId}/
├── B03_FileInput/ → 원본 입력 (LAS/TIF/PRJ/TFW)
├── B04_wf1_Surface/ → WF1 변환·분석 결과
├── B05_wf2_Route/ → WF2 경로 설계 결과
├── B06_wf3_ProfileCross/ → WF3 종횡단 결과
├── B07_wf4_DesignDetail/ → WF4 구조물
├── B08_wf5_Quantity/ → WF5 수량
└── B09_wf6_Estimation/ → WF6 최종 산출물
```
**수정 대상 (코더는 아래 구조 사용):**
- 계획서 §4 "신규 API" 설명의 저장 경로 모두 현재 구조로 읽고 사용
- `storage/{projectId}/...` 축약 표기는 **사용 금지** — 전체 경로는 `storage/{company}/{user}/{projectId}/[B0N_]/...`
- 각 WF의 결과는 각각의 워크플로우 폴더 아래에만 저장 (§3 CLAUDE.md "단계별 루트 강제")
- 예: WF1 분석 결과 → `B04_wf1_Surface/` 아래만 (프로젝트 루트의 `result_*.json` 같은 축약 방식 금지)
---
## 11. 0_old 프로그램 구조 참고
### 10.1 프론트엔드 컴포넌트
```
0_old/frontend/src/
├── PointCloudViewer.tsx → B04 포인트클라우드 뷰어 참고
├── TerrainModelViewer.tsx → B04/B05 지표면 렌더링 참고
├── RouteDesignStage.tsx → B05 경로 설계 참고
├── LongitudinalProfile.tsx → B06 종단면 2D 그래프 참고
├── CrossSectionGrid.tsx → B06 횡단면 2D 그래프 참고
├── sectionTypes.ts → B06 데이터 타입 참고
├── WorkflowBar.tsx → 워크플로우 상태 표시 참고
├── pointCloudUtils.ts → 포인트 데이터 처리 유틸
└── MapViewerFrame → 줌/팬닝 뷰어 프레임 참고
```
### 10.2 백엔드 분석 엔진
```
0_old/backend/app/
├── analyzer.py → 분석 오케스트레이터
└── classifier.py → 포인트 분류
0_old/utils/
├── filter_grid_min_z.py → Grid Min-Z 필터
├── filter_csf.py → CSF(가상 천) 필터
├── filter_pmf.py → PMF(형태학) 필터
├── filter_ransac.py → RANSAC 필터
├── terrain_model_converter.py → TIN/DTM/NURBS/Implicit/Meshfree 생성
├── section_generator.py → 종횡단 생성
├── route_solver.py → Dijkstra 경로 계산
└── route_solver_ridgevalley.py → Ridge-Valley 경로 계산
```
### 10.3 저장소 구조
```
storage/projects/{projectId}/
├── raw/ → 원본 LAS/TIF/PRJ/TFW 파일
└── processed/
├── analysis.json → 메타데이터 (bounds, CRS 등)
├── las-points-sample.json → 샘플링된 포인트 (3D 뷰어용)
├── ground-stats.json → 필터별 지면 통계
├── tin.json → TIN 모델 (삼각형 메시)
├── dtm.json → DTM 모델 (격자)
├── nurbs.json → NURBS 모델
├── implicit.json → Implicit 모델
├── meshfree.json → Meshfree 모델
├── route.json → 계산된 경로 (경로점, 곡선 등)
└── sections.json → 종횡단 데이터 (LongitudinalSection[], CrossSection[])
```
---
## 11. 질의응답 정리
**사용자 피드백 적용:**
1. ✅ **진행률 추적:** localStorage + 폴링 으로 페이지 이탈 후에도 복구 가능
2. ✅ **데이터 구조:** LAS → JSON 변환 후 저장, 프론트는 저장된 데이터만 조회
3. ✅ **모바일 대응:** 전체 화면 사용으로 자동 반응형
4. ✅ **THREE.js:** 프로젝트에 설치됨, 0_old와 동일 방식 사용
5. ✅ **WF4~WF6:** 현재는 기능 없음 (향후 구현)
6. ✅ **0_old 참고:** 콘텐츠/렌더링은 0_old, 레이아웃/테마는 현재 프로젝트 기준
---
**계획서 최종 검토일:** 2026-07-10
**버전:** 2.0 (0_old 분석 기반)
**상태:** 완료 (코딩 팀 진행 대기)
.agent/validation_wf1_and_upload.md
+66
View File
@@ -0,0 +1,66 @@
# WF1~WF3 레이아웃 및 파일 업로드 개선 검증 보고서
**작성일:** 2026-07-10
**상태:** 전체 완료 검증
**대상 계획서:** [.agent/plan_wf1_and_upload_improvements.md](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/.agent/plan_wf1_and_upload_improvements.md)
---
## 1. 종합 검증 요약
계획서에 명시된 **Phase 1부터 Phase 6까지의 모든 단계**가 완전히 구현되었음을 확인했습니다.
이전 검증에서 통과된 파일 업로드 비동기화 및 대시보드 워크플로우 활성화 상태/컨텍스트 버그 수정(Phase 1, 2)에 이어, 공통 레이아웃 템플릿(Phase 3)과 각 워크플로우 페이지들의 리팩토링 및 0_old 기능 이식(Phase 4, 5, 6)이 순수 바닐라 TS 및 디자인 가이드를 준수하여 성공적으로 완료되었습니다.
---
## 2. 세부 검증 항목 및 결과 (기존)
### 2.1 B03_FileInput 파일 업로드 비동기 처리 (Phase 1)
* **[합격] UI 블로킹 제거 및 백그라운드 진행**:
* [B03_FileInput_UI_Page.ts](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/B03_FileInput/B03_FileInput_UI_Page.ts) 파일에서 `showLoadingOverlay()`와 `hideLoadingOverlay()` 호출부가 완벽하게 제거되었습니다.
* 파일 업로드 후 백그라운드 분석 진행 중에도 사용자는 자유롭게 다른 화면으로 이동할 수 있습니다.
* **[합격] 분석 진행 상태 API 확장**:
* [B04_wf1_Surface_Router.py](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/B04_wf1_Surface/B04_wf1_Surface_Router.py)의 `get_wf1_analysis_status()` API가 확장되어 프로젝트의 실시간 status(`WF1_ANALYZING`, `WF1_COMPLETE`, `WF1_FAILED`)에 따른 진행률(`progress_percent`), 진행 단계(`current_stage`), 상태 메시지(`message`)를 반환하도록 기능이 구현되었습니다.
* [B03_FileInput_Api_Fetch.ts](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/B03_FileInput/B03_FileInput_Api_Fetch.ts)의 `WF1AnalysisStatus` 인터페이스에 추가된 응답 규격이 바르게 정의되었습니다.
### 2.2 대시보드 워크플로우 활성화 및 프로젝트 컨텍스트 유지 (Phase 2, 🐞 버그 수정)
* **[합격] 프로젝트 ID 누락으로 인한 진입 오류 해결 (§2.2.2)**:
* [B01_Dashboard_UI_Page.ts](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/B01_Dashboard/B01_Dashboard_UI_Page.ts)의 `workflow()` 함수가 `ProjectItem` 객체를 파라미터로 받도록 개선되었습니다.
* 각 단계 이동 버튼의 클릭 이벤트에 `localStorage.setItem(CURRENT_PROJECT_ID_KEY, project.id)`가 추가되어 기존 프로젝트 클릭 후 파일 입력 진입 시 발생하던 "현재 프로젝트가 선택되지 않았습니다" 에러가 완전히 수정되었습니다.
* **[합격] 상태값 매칭 오류 수정 및 스테이지 통제 (§2.2.1)**:
* [B01_Dashboard_Repository.py](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/B01_Dashboard/B01_Dashboard_Repository.py)의 `_stage_from_status()` 함수에서 분석 중(`WF1_ANALYZING`)이거나 실패(`WF1_FAILED`) 시에는 다음 단계로 갈 수 없도록 명시적으로 `stage 1`을 반환하게 통제되었습니다.
* `WF1_COMPLETE`, `WF2_COMPLETE` 와 같은 완결 접미사를 기준으로 단계를 정확히 판별하도록 개선되었습니다.
---
## 3. 신규 검증 항목 및 결과 (Phase 3 ~ Phase 6)
### 3.1 공통 워크플로우 레이아웃 템플릿 구현 (Phase 3)
* **[합격] 바닐라 TS 기반 레이아웃 템플릿**:
* [ui_template_workflow_layout.ts](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/ui_template/ui_template_workflow_layout.ts)에 `createWorkflowLayout` 함수가 성공적으로 추가되었습니다.
* ☰ 버튼 토글 기능, 상단 헤더 및 진행률 스텝바 렌더링, 오버레이 형식의 좌측 패널 슬라이드 기능이 바닐라 TS DOM 구조로 구현되었습니다.
* 메인 작업 영역 클릭 시 오버레이 메뉴가 자동으로 닫히는 UX 흐름이 완벽히 적용되었습니다.
### 3.2 B04_wf1_Surface 지표면 분석 페이지 이식 및 자동화 (Phase 4)
* **[합격] 3D 포인트클라우드 WebGL 뷰어 이식**:
* [B04_wf1_Surface_UI_Viewer.ts](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/B04_wf1_Surface/B04_wf1_Surface_UI_Viewer.ts)가 신규 생성되어 THREE.js OrbitControls를 활용한 3D 가속 가상 카메라 뷰 환경이 완벽히 구성되었습니다.
* React 훅과 의존성 없이 바닐라 TS 생명주기(`dispose`, `render`)를 갖는 컴포넌트로 개조되었습니다.
* **[합격] 입력 파일 자동 로드 및 UI 연동**:
* [B04_wf1_Surface_UI_Page.ts](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/B04_wf1_Surface/B04_wf1_Surface_UI_Page.ts)에서 기존의 숫자 직접 입력(`input_file_id`) 필드를 대체하여, 프로젝트에 연동된 입력 파일 목록을 콤보박스(`inputSelect`)로 자동 렌더링하고 첫 번째 파일을 자동 선택하도록 편의성을 높였습니다.
* 지면 필터 통계 목록과 분석 완료된 지표면 결과 모델들을 카드 형식으로 표출하며 3D 뷰어와 유기적으로 호환됩니다.
* **[합격] 코드 라인 수 제한 및 스타일 시트 분리**:
* UI 로직은 536줄, 3D 뷰어는 122줄로 분할 구현되어 단일 파일 700줄 제한을 준수했습니다.
### 3.3 B05_wf2_Route 및 B06_wf3_ProfileCross 리팩토링 (Phase 5, 6)
* **[합격] B05 경로 설계 페이지 개선**:
* [B05_wf2_Route_UI_Page.ts](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/B05_wf2_Route/B05_wf2_Route_UI_Page.ts)에 `createWorkflowLayout` 템플릿이 적용되었습니다.
* 시점(BP), 종점(EP) 및 동적 추가 가능한 중간점(CP) 폼 세트가 정상 기능하며, 설계 조건 조절 및 API 요청/승인 비즈니스 로직이 바르게 바인딩되었습니다.
* **[합격] B06 종횡단 생성 페이지 개선**:
* [B06_wf3_ProfileCross_UI_Page.ts](file:///D:/02_Software_Prog/임도설계 및 견적자동화 프로그램 개발/B06_wf3_ProfileCross/B06_wf3_ProfileCross_UI_Page.ts)에 공통 레이아웃이 연동되어 대형 공간에서 2D 뷰 기반 종/횡단 작업을 수행할 수 있도록 좌측 매개변수 제어창과 우측 결과 보드가 통합 설계되었습니다.
---
## 4. 최종 제언 및 사후 검토
* 코드 품질 검증 결과 전체적인 컴포넌트의 모듈화가 성공적으로 안착되었습니다.
* 프로젝트 전반에서 `ui_template_locale.ts`를 사용한 한글/영문 지원 및 테마 변수의 체계적인 연동이 모범적으로 준수되었습니다.
* 추후 3D 뷰어에서의 드로잉 인터랙션 및 2D 그래프 렌더링 세부 작업 시에도 설계된 `createWorkflowLayout` 인터페이스를 적극 활용하시기 바랍니다.