# 상시 계획서 — 2026-09-04 정리 전 원문 스냅샷

> 운영 원칙
>
> - **진행 중**: 현재 구현·검증 대상으로 선택된 작업만 둔다.
> - **진행 예정**: 아직 착수하지 않은 작업을 기능군별로 둔다.
> - **참고**: 코드 작업 중 필요한 기준표·확정사항만 둔다.
> - 완료 항목은 사용자 검증 또는 교차검증 후 `docs/raw/plans/`와 `docs/raw/verification/`으로 이관한다.
> - **담당은 적지 않는다** — 어느 창·폴더가 맡을지는 그때그때 정한다.
> - **작성방법** — 짧고 이해하기 쉽게, 문단의 종료 시점 전까지 줄바꿈금지.

---

## 진행 중

> **2026-09-04 현재 — 미완료 체크 11건.** 완료 구현과 자체검증 기록은 `docs/raw/plans/`로 이관했다(이번 이관: `2026-09-04_plan_user_verified_completed_items.md`). 이 문서에는 진행 중·진행 예정·판단 대기 항목만 유지한다.

### B05↔B06 이동 지연 — 원인 확정과 개선 (2026-09-04 조사 · 2026-09-05 작업 예정)

사용자 지시(2026-09-04) — 「B05·B06을 세션·캐시로 한 페이지처럼 만들어 빠르게 하려 했는데 생각보다 느림. **원인을 파악**할 것」. 조사만 끝냈고 **구현은 하지 않음**(내일 작업).

#### 1. 실측 (공용 브라우저 5174 · 프로젝트 용화_LAS · 2026-09-04)

| 이동 | 화면 틀 | 서버 요청 | 마지막 응답 | 메인스레드 멈춤 |
| --- | --- | --- | --- | --- |
| B05 → B06 | 0.61초 | 11건 | 0.93초 | 합 1.02초 (최대 0.28초) |
| **B06 → B05** | 즉시 | **21건** | **4.87초** | **합 2.62초 (최대 0.89초)** |

**느린 쪽은 B05 재진입 한 방향뿐임.** 개별 요청은 60~500ms 로 느리지 않고, **줄을 서느라** 4.9초가 됨.

B06→B05 요청 순서 실측(시작ms +소요ms):

```
   13 +484  surface/status          ← 이동 문지기
  498 +366  surface/confirmed       ← 이동 문지기
  927 +67/134/104/71  auth/session ×4
 1141 +61   vworld-meta
 1144 +113  workflow-state (24KB)
 1303 +101  workflow-state (24KB, 중복)
 1305 +161  route/latest (67KB)
 1305 +116  sections/context
 1305 + 59  sections/road-widths
 1469 +153  surface/models
 1485 + 62  geojson(도엽_하천) 304
 1582 + 67  geojson(도엽_등고선) 304
 2173 +386  drainage/pipe-points (139KB)
 2317 + 93  route/structures/migrate
 2318 + 87  route/structures
 2594 +167  surface/confirmed (중복)
 2928 + 76  surface/models/418/preview 304
 4112 +759  surface/models/418/contour 304
```

#### 2. 원인 4가지 (코드 위치 포함)

- **(가) 요청이 줄줄이 앞을 기다림 — 가장 큰 몫** 
  ① 이동 문지기 `A00_Common/b_workflow_nav.ts` `routeAfterPreloadCheck` 가 **화면을 띄우기 전에** `surface/status` → `surface/confirmed` 를 차례로 물어 **0.9초**를 먼저 씀. 
  ② B05 진입 `B05_Profile/B05_Profile_UI_Page.ts:599~` 이 `워크플로우 상태` → `Promise.all(노선·설정·도로폭)` → `지표면 목록` → `종·횡단` → `구조물` 순으로 **다섯 덩이를 차례로** 기다림. 이 중 워크플로우 상태·지표면 목록·구조물은 서로 필요 없음(참 의존은 「노선 → 종·횡단」뿐).
- **(나) 같은 것을 여러 번 물어봄** — 로그인 확인 **4번**(`A00_Common/router.ts` 문지기 2번 + `A00_Common/app_shell.ts` 상단바 2번, 게다가 상단바는 두 번을 차례로 부름), 워크플로우 상태 **2번**(24KB×2 — 두 번째 호출자는 내일 확정), 확정 지표면 **2번**(문지기 + B05 3D 단계), 구조물 목록 **2번**(`migrate` 포함).
- **(다) 세션 캐시가 큰 자료를 담지 않음** — 담아 두는 것은 준비 표식(`frd_preloaded_signature`)·계획선 초안·노선 latest 정도임. 노선 최신값은 진입 때 **일부러 DB를 다시 읽고**(`loadLatest(true)`), 배수관(139KB)·구조물·지표면 목록은 매번 새로 받음. **B06에서 방금 쓰고 온 자료도 다시 받음.**
- **(라) 받은 뒤 그리느라 2.6초 멈춤** — 3D 메쉬와 **등고선 12.7MB**(`contour_csf_dtm_smooth_1.0m.json`)를 다시 읽어 그림. 서버는 304(본문 0바이트)만 주지만 브라우저가 그 12.7MB를 **다시 해석**함. 이 멈춤이 뒤따르는 요청까지 밀어냄(마지막 contour 요청이 759ms로 잡힌 것도 이 영향).

#### 3. 내일 작업 (효과 큰 순서, 앞에서부터)

- [ ] **(1) 중복 호출 제거** — 로그인 확인 4 → 1, 워크플로우 상태 2 → 1, 확정 지표면 2 → 1, 구조물 2 → 1. 화면 한 번 그리는 동안 같은 요청은 **한 번만** 나가게 공용 캐시를 둠(같은 URL 진행 중이면 그 약속을 함께 씀). 먼저 두 번째 워크플로우 상태 호출자를 확정할 것. 기대: 요청 21 → 15건, 앞머리 0.3~0.6초 단축.
- [ ] **(2) B05 진입을 병렬로** — 워크플로우 상태·노선·설정·도로폭·지표면 목록·구조물을 **한 번에** 보내고, 「노선 → 종·횡단」 의존만 남김. 화면 틀은 워크플로우 상태가 오는 대로 세움. 기대: 1.4초 → 0.5초 안팎.
- [ ] **(3) 이동 문지기를 화면과 겹치게** — `routeAfterPreloadCheck` 의 `surface/status`·`surface/confirmed` 확인을 **이동을 막지 않게** 바꿈(먼저 넘어가고 뒤에서 확인, 다르면 그때 준비 화면으로). 기대: 앞머리 0.9초 제거.
- [ ] **(4) 화면을 오가도 자료를 들고 있기** — B05·B06이 함께 쓰는 자료(노선 latest·배수관·구조물·지표면 목록)를 **프로젝트+갱신표식 기준 메모리 캐시**에 두고, 저장·확정으로 값이 바뀔 때만 버림. 「진입 때 무조건 DB 재조회」는 그 표식 비교로 대체. 기대: 재진입 요청 15 → 6건 안팎.
- [ ] **(5) 등고선·3D 다시 그리지 않기** — 한 번 해석한 등고선·메쉬를 화면을 나갈 때 버리지 말고 들고 있다가 되돌아오면 그대로 얹음. 기대: 메인스레드 멈춤 2.6초 → 1초 미만.
- [ ] **(6) 자체검증** — 아래 「측정 방법」으로 전·후 수치를 재고 PLAN 에 남김. 목표: **B06→B05 마지막 응답 1.5초 이하, 요청 10건 이하, 메인스레드 멈춤 1초 이하**.

#### 4. 측정 방법 (전·후 비교에 그대로 씀)

공용 브라우저 명령 파일(`tmp/browser/cmd/NN_*.py`)에서:

1. B05 에 들어가 안정된 뒤 `performance.clearResourceTimings()` + `PerformanceObserver({entryTypes:['longtask']})` 를 걺.
2. 진행단계의 「횡단설계」/「종단설계」를 눌러 이동.
3. `performance.getEntriesByType('resource')` 에서 `/api/` 만 골라 **시작·소요·전송크기**를, 롱태스크에서 **멈춤 합·최대**를 뽑음.
4. 위 표와 같은 형식으로 기록. 이번 측정값이 기준선임.

#### 5. 앞으로 이런 문제를 만들지 않기 위한 규칙 (사용자 지시 2026-09-04)

새 화면·기능을 붙일 때마다 같은 지연이 다시 쌓임. 아래를 **개발 중 지킬 규칙**으로 삼음.

- **① 진입은 「틀 먼저, 자료는 한꺼번에」** — 화면 진입 코드에서 `await` 를 세로로 쌓지 말 것. 서로 값을 쓰지 않는 요청은 `Promise.all` 로 묶고, 진짜 의존(앞 응답의 id 를 쓰는 경우)만 줄을 세움. 새 자료가 필요해지면 **기존 묶음에 넣는 것이 기본**이고, 새 단계를 만드는 것은 예외임.
- **② 같은 요청은 화면당 한 번** — 로그인·워크플로우 상태처럼 여러 곳이 쓰는 값은 공용 캐시를 거쳐 받음. 모듈마다 자기 몫을 따로 부르지 말 것.
- **③ 화면 이동을 막는 요청을 새로 만들지 말 것** — 이동 전에 확인이 필요하면 **먼저 넘어가고 뒤에서 확인**해 어긋날 때만 되돌림.
- **④ 화면을 나갈 때 비싼 것을 버리지 말 것** — 3D 메쉬·등고선처럼 해석에 수백 ms 드는 자료는 프로젝트가 바뀔 때만 버림.
- **⑤ 무엇이 바뀌었을 때 버릴지 먼저 정할 것** — 캐시를 둘 때는 「무엇을 담나」보다 **「언제 버리나」**를 먼저 적음(저장·확정·재계산·프로젝트 변경). 이 규칙이 없으면 옛 값이 남아 더 큰 문제가 됨.
- **⑥ 화면마다 성능 한도를 둠** — 진입 시 **API 10건 이하 · 대기 사슬 3단계 이하 · 메인스레드 멈춤 1초 이하 · 한 응답 100KB 이하**. 넘기면 그 자리에서 줄이거나, 못 줄이면 PLAN 에 사유와 함께 남김.
- **⑦ 화면 작업을 끝낼 때 진입 수치를 한 번 잼** — 위 「측정 방법」을 그대로 돌려 요청 수·마지막 응답·멈춤을 검증 기록에 적음. 눈으로 「빠른 것 같다」는 판정 금지.
- **⑧ 응답 크기도 봄** — 목록 응답이 수십 KB 로 커지면 화면이 실제로 쓰는 필드만 내려보내게 서버를 고침(지금 워크플로우 상태 24KB·배수관 139KB 가 그 후보).

### B03 계획노선 미리보기 색·점선 (2026-09-04 지시 · laptop-sub)

사용자 지시(2026-09-04) — 「계획노선 도형이 왜 붉은색인가. **점선 없애고 실선은 녹색으로**」.

- **붉은색은 경고였음** — 노선이 지형 자료 범위를 벗어나면 선과 상자를 붉게 칠함. 그때 지형이 검증용 가짜 라이다라 범위가 어긋나 있었음. 실제 라이다를 올리니 경고가 풀림.
- **점선 상자는 「자료가 덮는 땅 범위」** — 노선은 선 자체가 범위를 보여 주므로 상자가 겹침.

- [X] **노선 카드의 점선 상자 제거** — 그릴 선이 있는 자료(계획노선)에는 범위 상자를 그리지 않음. 점구름·래스터는 그대로.
- [X] **노선 실선 녹색** — 선 색을 녹색으로. 범위를 벗어나면 붉은 경고색으로 덮어쓰는 규칙은 그대로 둠.
- [X] **자체검증**(2026-09-04, 검증 대기) — 공용 브라우저 5174, 프로젝트 카드미리보기_검증_sub. 실측: 노선 미리보기의 범위 상자 **없음**, 선 색 `rgb(63,187,111)`(녹색), 경고 표시 없음(실제 라이다 기준 범위 안). `npm run typecheck` 통과.
  - 계획 대비 차이 — 없음.

### B03 파일 교체 후 다시 돌리기 (2026-09-04 지시 · laptop-sub)

사용자 지시(2026-09-04) — 「검증용 프로젝트를 지우지 말고 그걸로 전처리 시험을 하려 함. **파일 교체해서 [파일 업로드] 버튼으로 실행**할 수 있게 할 것」.

막고 있던 것 두 가지를 찾음.

- **끝난 카드에 [파일 선택]이 없었음** — CSS 가 `완료` 카드의 선택 단추를 감추고 있어 파일을 갈아 끼울 방법이 없었음. 규칙 자체는 이미 교체를 허용함(필수 칸은 서버에 올라간 파일로 충족).
- **한 번 「자동 확정 보류」가 나면 그 프로젝트는 영영 새 자료를 못 받았음** — 전처리 1단계가 `IN_PROGRESS` 로 남고 서버 업로드 관문이 그것을 「분석 중」으로 읽음. 보류는 **계산이 끝나고 사용자의 확정을 기다리는 상태**라 분석 중이 아님. 검증용 프로젝트만의 문제가 아니라 실사용에서도 같은 자리에서 막힘.

- [X] **끝난 카드에도 [파일 선택]** — 올리는 중에만 감추게 바꿈. 누르면 기존대로 「기존 파일 교체 확인」 모달이 뜨고, [교체하고 계속] 뒤 [파일 업로드]가 열림.
- [X] **「확정 대기」는 업로드를 막지 않음** — 업로드 관문이 1단계 상태만 보던 것을 고쳐, 전처리 진행 파일이 `awaiting_confirmation`·`completed`·`failed` 로 끝나 있으면 새 자료를 받음. 실제로 도는 중(`analyzing`)이면 그대로 막음.
- [X] **자체검증**(2026-09-04, 검증 대기) — 공용 브라우저 5174, 프로젝트 **카드미리보기_검증_sub**. 백엔드 재시작 후 실측.
  - ① 끝난 카드 9개 전부 [파일 선택] 보임(`display: block`). **합격**
  - ② 포인트클라우드를 다른 파일로 교체 → 교체 확인 모달 → [파일 업로드] 활성. 고치기 전에는 서버가 409 「이 프로젝트는 지금 분석 중입니다」로 거절했음. **합격**
  - ③ 업로드 뒤 카드가 「완료 / verify_mini2.las 1.14 MB」로 바뀌고, **전처리가 새 파일로 다시 돎** — 입력 파일 22:40:33 저장, B04 산출물 `structured.npz` 22:40:35 재생성. **합격**
  - ④ 회귀 — `pytest tmp/tests/` 185 통과·1 건너뜀, `npm run typecheck` 통과.
  - **남은 것** — 이 프로젝트는 가짜 라이다라 자동 확정이 계속 보류됨(「기본값과 일치하는 지표면 모델 없음: filter=csf, method=dtm」). 전처리 시험은 B04 에서 모델을 직접 골라 확정하면 됨.
  - 계획 대비 차이 — 없음. 계획에 없던 서버 관문 수정이 붙음(그것이 진짜 원인이었음).

### B03 파일입력 카드 — 부속 파일 값 표시 (2026-09-04 지시 · laptop-sub)

사용자 지시(2026-09-04) — 「지금 그림은 3개(노선·점구름·래스터)뿐이고 나머지는 글자임. **shx·dbf·cpg·prj 파일 내용 중 중요한 정보를 몇 개 뽑아** 넣을 것」 + 「지형 래스터는 왜 다른 그림처럼 점선 박스에 안 들어가 있나」.

- **개수만 보이던 것이 문제** — 「도형 1개」·「레코드 1개」로는 그 파일에 무엇이 들었는지 안 보임.
- **재료는 파일 머리글에 이미 있음** — 머리글만 읽으므로 업로드가 느려지지 않음(사용자 제약 「오래 걸리면 안 됨」). .cpg 견본만 같은 세트 .dbf 앞부분을 함께 읽음.
- **래스터에 점선이 없던 이유** — 다른 미리보기는 「자료가 덮는 땅 범위」를 점선 사각형으로 그리는데, 래스터는 그 범위를 썸네일이 그대로 채워 그리는 코드가 썸네일에서 끝났음.

- [X] **.shx — 도형 종류·범위** — 머리글에서 도형 종류 코드와 bbox 를 읽어 「폴리라인 · 도형 1개 / 범위 1,234×435 m」로 보임.
- [X] **.dbf — 속성 이름** — 머리글 서술자에서 속성 이름을 읽어 앞 4개를 보임(넘으면 `…`).
- [X] **.cpg — 글자 견본** — 같은 세트 .dbf 의 첫 글자 속성을 그 인코딩으로 읽어 「견본 「…」」으로 보임. 인코딩이 틀리면 글자가 깨져 눈에 바로 보임.
- [X] **.prj — 원점·단위** — 투영 매개변수에서 중앙자오선을, 축 정보에서 길이 단위를 읽음. proj 문자열 변환을 쓰지 않아 정보 손실 경고가 사라짐.
- [X] **표시 줄 수·단위 표기** — 카드 값을 2줄 → 3줄로 늘리고 길이 단위는 `metre`·`METER` 를 모두 `m` 으로 통일.
- [X] **래스터 썸네일 점선 테두리** — 썸네일에 다른 미리보기와 같은 점선 테두리를 둘러 셋이 같은 모양이 되게 함.
- [X] **자체검증**(2026-09-04, 검증 대기) — 기존 프로젝트를 건드리지 않으려고 **새 프로젝트 「카드미리보기_검증_sub」**를 만들어 실제 업로드 경로로 확인함(공용 브라우저 5174). 백엔드는 재시작 후 확인.
  - ① 업로드 후 카드 실측 — .shx 「폴리라인 · 도형 1개 / 범위 1,234×435 m」, .dbf 「레코드 1개 · 속성 2개 / 대상지, 길이」, .cpg 「인코딩 949 / 견본 「일월.용화.2.2」」, .prj 「Korean 1985 / Modified East Belt (EPSG:5176) / 중앙자오선 129.0029°E · 단위 m」. **합격**
  - ② 단위 표기 — 노선 .prj 는 사용자 정의 WKT 라 `METER` 로 나오던 것을 고쳐 두 카드 모두 「단위 m」으로 나옴. **합격**
  - ③ 래스터 썸네일 — 용화_LAS 의 지형 래스터 카드에서 테두리 실측 `dashed · 1px · rgb(50,42,69)` — 다른 미리보기 점선과 같은 색. **합격**
  - ④ 회귀 — `pytest tmp/tests/` **185 통과·1 건너뜀**, `npm run typecheck` 통과.
  - **뒷정리 필요** — 검증용 프로젝트 「카드미리보기_검증_sub」가 대시보드에 남아 있음(자동설계는 돌지 않음). 필요 없으면 지울 것.
  - 계획 대비 차이 — 없음.

### B07 화면 손질 5건 (2026-09-04 지시 · laptop-sub)

사용자 지시(2026-09-04) — ① 횡단면도 배치에서 박스와 박스 사이 간격 제거 ② 마지막 1장으로 구성된 횡단면도에 도각 없음 ③ 도면 위 마우스 스크롤을 줌인아웃으로(도면 영역 안에서만) ④ CAD 리본 메뉴의 세로 스크롤 안 나오게 ⑤ 좌측 패널 하위 버튼이 이름이 길어 우측으로 튀어나감 — 누가거리 대신 그 장의 시작 측점으로 표기, 넘치면 `…`.

착수 전 공용 브라우저(5174, 시행정 테스트)와 코드로 확인한 현황임.

- **②·③ 은 확인 결과 손댈 것 없음** — 사용자 확정(2026-09-04) 「도각 / 마우스 휠 괜찮음」. ② 도각은 4개 프로젝트의 마지막 장·단면 1개짜리 장까지 전부 A1 도각이 들어 있음(도면 범위 840×594mm = A1 실치수, 내용만이면 739×499mm 이내). ③ 캔버스 위 휠은 이미 확대/축소이고 페이지 스크롤이 아님 — 사용자가 겪은 상하 팬은 **트랙패드 두 손가락 이동**이 설계상 팬으로 잡히는 것임(`isMouseWheel`) — 그대로 두기로 확정.
- **① 간격은 상수 하나**가 정함 — 장 배치가 칸 크기를 「블록 + 간격 8mm」로 잡고 테두리를 그 칸 안쪽에 그림(`_BLOCK_GAP_MM`).
- **④ 리본이 4px 모자람** — 실측: 리본 줄의 내용 높이 85px, 보이는 높이 81px. 리본 칸 높이가 116px 로 고정돼 있어 4px 이 남고, 한 축만 잘리면 브라우저가 나머지 축도 스크롤로 바꿔 세로 스크롤바가 생김. **잘라 숨기지 않고 리본 높이를 조금 늘려** 없앰(사용자 지시 2026-09-04). 높이는 토큰 한 곳(`--cad-ribbon-height`)이 정하고 캔버스 위치·높이가 그 값을 따라감.
- **⑤ 튀어나감은 실측으로 재현** — 2열 격자의 오른쪽 열 단추가 패널 오른쪽 끝(303px)을 14px 넘어 317px 까지 나감. 격자 칸의 기본 최소폭이 글자 길이라 칸이 컨테이너를 밀어냄. 라벨도 「16장 (1060~1070m)」처럼 누가거리 범위라 긺.

- [X] **① 박스 사이 간격 없애기** — 칸 여백 상수를 0 으로 두어 테두리끼리 맞닿게 함(`_BLOCK_GAP_MM`). 척도(1/100)·칸 통일 규칙은 그대로.
- [X] **④ 리본 높이 늘리기** — 리본 칸 높이를 116px → 122px 로 올려 세로 스크롤바가 안 생기게 함(모자란 4px + 여유 2px). 가로 스크롤은 그대로 둠.
- [X] **⑤ 라벨을 시작 측점으로** — 「N장 (시작~끝m)」 → 「N장 (No.n)」. 측점 표기는 납품 도면과 같은 규칙(`station_no_label`)을 씀.
- [X] **⑤ 단추가 패널을 넘지 않게** — 격자 칸의 최소폭을 풀어(`min-width: 0`) 이름이 길면 `…` 로 잘리게 함.
- [X] **자체검증**(2026-09-04, 검증 대기) — 공용 브라우저(5174, 프로젝트 **용화_LAS**) + 생성 도면 실측. CAD 앱은 다시 빌드하고 캐시를 비운 뒤, 백엔드는 재시작하고 확인함.
  - ① 한 장(9칸, 칸 168.0×164.43mm)의 칸 테두리 9개를 재니 **가로·세로 이웃 간격 모두 0.0mm**(옛 8mm). 테두리 크기 = 칸 크기와 같음. 화면에서도 이웃 박스가 세로선 한 줄을 함께 씀. **합격**
  - ④ 리본 줄의 내용 높이 87px = 보이는 높이 87px(옛 85 > 81) — 세로 스크롤 가능 높이 0. 리본 칸 122px, 캔버스 상단이 158 → 164px 로 내려감. **합격**
  - ⑤ 단추 33개 중 패널 오른쪽 끝(303px)을 넘는 것 **0개**(옛 8개가 317px 까지 나감), 횡단 격자의 내용 폭 277px ≤ 칸 폭 279px. 라벨은 「1장 (No.0)」…「20장 (No.53+10.4)」 형식이고, 가장 긴 「20장 (No.53+10.4)」만 `…` 로 잘림. **합격**
  - ⑥ 회귀 — `pytest tmp/tests/` **185 통과·1 건너뜀**(다른 창 커밋 2건을 되받은 뒤 실행).
  - 계획 대비 차이 — 없음.

### B05 종단·유토곡선 조작감 3건 (2026-09-04 지시)

사용자 지시 3건 — ① 휠 스크롤이 늦게 따라옴, 리소스가 크지 않으면 부드럽게 ② 유토곡선
「다시 계산 중」 문구가 창을 밀어냄 — 그래프 안 우측 상단 오버레이로 ③ 코리도 초기값 —
지금 로딩이 늦음.

**착수 전 측정 (공용 브라우저 5173, 실측)**

- 휠 이동 자체는 즉시. 마지막 휠 508ms → 그래프 재구성 706ms — **멈춘 뒤 약 0.2초**에
  세로 눈금·곡선이 다시 섬(디바운스 160ms + 재구성). 재구성은 longtask 0건(50ms 미만)이라 가벼움.
- 이동이 **한 칸 120px 점프**라 부드럽지 않음 — `scrollLeft += deltaY` 직접 대입이 브라우저
  기본 휠 관성을 대신함.
- 같은 휠 처리가 종단(`B05_Profile_UI_Profile_Panel.ts`)·유토곡선(`_MassHaul.ts`)·
  테이블(`_TableOverlay.ts`) **세 곳에 복사**돼 있음.
- 「다시 계산 중…」 칩이 요약 막대(`flex-wrap: wrap`)에 붙어 줄바꿈 → 막대가 높아지며 곡선이 밀림.
- 코리도 저장본 17.6MB, 전송만 328ms(압축 없음) + 파싱. [초기화]는 **새 route id**를 만들어
  (`restore_initial_snapshot`) 저장본 파일명이 어긋남 → 초기화 뒤 첫 진입은 **항상 재빌드**.

- [X] **휠 가로 이동 부드럽게** — 세 곳의 휠 처리를 `B05_Profile_UI_Profile_Wheel.ts`
  한 벌로 모음. 이동은 **rAF 로 목표를 쌓아 프레임마다 좁히는 방식**.
  - 계획 대비 차이 — 브라우저 기본 `scrollTo({ behavior: "smooth" })` 로 갔다가 되돌림.
    휠이 들어올 때마다 애니메이션이 **처음부터 다시 시작**해 느린 구간만 반복함:
    실측 1.6초 동안 1,200px 중 **17px**만 이동. 자체 애니메이션으로 교체함.
- [X] **따라오는 시간 단축** — 세로 자동 맞춤 디바운스 160 → 80ms. 「멈춘 뒤 한 번」 규칙 유지.
- [X] **「다시 계산 중」 오버레이화** — 칩을 요약 막대에서 떼어 곡선 영역 우측 상단에
  절대배치(범례 아래 4px, `pointer-events: none`). 레이아웃 차지 0.
- [X] **자체검증 (2026-09-04, 검증 대기)** — 방법: `npm run typecheck` 통과, 공용 브라우저
  5173 임시 탭에서 실제 휠 조작·수치 판독(사용자가 쓰던 B07 탭은 건드리지 않음).
  결과: ① 휠 10칸(1,200px) 중 **1,199px** 이동, 궤적이 40ms 간격으로 연속(점프 없음),
  마지막 휠 500ms → 그래프 재구성 813ms ② 칩 표시/숨김에서 요약 막대 높이 53px·곡선 자리
  (top 1078 · height 226) **완전 동일** — 창밀림 0, 칩은 곡선 영역 안 우측(범례와 겹치지 않음).
  계획 대비 차이 — 재구성 시점이 고침 전 706ms → 813ms 로 약 0.1초 늦어짐(이동
  애니메이션 시간만큼). 이동 자체가 이어져 보이므로 그대로 둠. 커밋 `c2f681f9`.
- [X] **코리도를 서버가 미리 만들어 저장** (2026-09-04 사용자 확정 — 「같은 TS 코드를 서버에서 1회 실행」).
  다른 데이터와 같은 흐름으로 맞춤: 전처리 체인 마지막에 계산·영구저장 → 진입 시 로딩만 →
  조작은 캐시 → [저장]·[확정] 때 저장. 계산 재구현 없음 — 브라우저 빌더 8,209줄을 그대로 씀.
  - [X] **저장 형식 공용화** — `B05_Profile_UI_Corridor_Envelope.ts` 신설. 버전 해시·직렬화를
    `_UI_Corridor.ts` 에서 **내용 그대로** 떼어 브라우저·서버가 한 벌을 씀.
  - [X] **서버 진입점 + 번들** — `B05_Profile_Corridor_Node.ts`(47줄) → `npm run build:corridor`
    로 335kB 번들. `npm run build` 에 물림. 번들 산출물은 git 제외(`.gitignore`).
  - [X] **낡은 번들 방지** — `B05_Profile_Corridor_Prebuild.py` 가 번들과 TS 원본 시각을 대조해
    낡았으면 스스로 다시 만듦. 계획서가 「유일한 위험」으로 적었던 항목을 코드로 막음.
  - [X] **체인 마지막 단계** — 스냅샷 직전에 호출. 실패는 비치명적(브라우저 폴백 유지).
  - [X] **초기값 편입** — 스냅샷이 코리도를 `initial_corridor.json` 으로 함께 뜨고,
    [초기화] 복원 때 **새 route id** 이름으로 되돌림.
  - [X] **프론트는 무변경** — 저장본 해시가 맞으면 `ensureCorridor` 가 그대로 로드함.
    확인용 디버그 훅 `window.__corridorSource` 만 추가.
  - [X] **자체검증 (2026-09-04, 검증 대기)** — 방법: 전체 시험 + 실제 프로젝트 실행 + 공용
    브라우저 임시 탭 판독. 결과: ① 전체 시험 **381 통과 · 17 건너뜀** ② 용화 프로젝트
    (route 139)로 서버 사전 생성 성공(16MB) ③ 그 저장본을 브라우저가 **`source: "stored"`,
    해시 `377c2a84` 로 그대로 채택** — 재빌드 0회, 전송 278ms ④ 스냅샷 복원 3건
    (`tmp/tests/test_b05_corridor_prebuild.py`) 통과.
    계획 대비 차이 — 착수 전 확인 항목이던 「체인 시점 기본설계·구조물 정본」은 상세 조회
    (`get_section_detail`)를 그대로 부르므로 따로 손댈 것이 없었음. 옛 테스트 2건은 이름·경로
    변경에 맞춰 갱신(`_corridor_path` → `corridor_path`, 배수유역 스냅샷 자리).
    **미검증** — 새 프로젝트 업로드로 체인이 처음부터 도는 실경로와 [초기화] 뒤 복원은
    아직 못 돌림(둘 다 사용자 프로젝트를 갈아엎는 조작이라 지시 필요). 커밋 `c322f538`.
- [X] **코리도 응답 압축(일단 동의로 종료처리) — 백로그** (2026-09-04 사용자 판단). 압축은 **전송량만** 줄고 회전·이동
  같은 조작 속도와는 무관함(그건 GPU·메쉬 몫). 18MB 는 견딜 만하므로 미룸.

### B05 종단 세로 맞춤 — 다시 그리기에서 변환으로 (2026-09-04 지시)

사용자 지시 — 「지금은 화면을 리프레시하는 느낌. 가장 강한 지연은 **멈춘 뒤 끊김**.
실시간처럼 동작하려면 근본적으로 표현을 바꿔야 하지 않나」. 확정: **변환 방식**.

**착수 전 측정** — 스크롤을 멈추면 그래프를 통째로 새로 만듦. SVG 요소 457개
(선 311·글자 76)를 버리고 다시 그려 **한 번에 34ms**(60Hz 두 프레임 통째 누락).
스크롤 중 프레임 자체는 중앙값 16.6ms(60fps)라 **그리기 성능 문제가 아님** — 세로 위치가
선 하나하나의 좌표에 박혀 있어, 세로 창이 바뀌면 좌표를 전부 다시 만들 수밖에 없는 구조임.

**방식** — 세로 창을 좌표가 아니라 **한 줄 변환**(`translate`+`scale`)으로 표현. 창이
바뀌어도 좌표 재계산 없이 변환값만 갈아 끼움. 두 창의 대응은 1차식이라 정확히 겹침
(a = 기존폭/새폭, b는 중심 이동분). 스크롤하는 내내 매 프레임 적용해도 1ms 미만.

- [X] **그래프 구조 손질**(`B06_Section_UI_Longitudinal.ts`) — 세로에 딸린 것(눈금선·
  절성토 음영·지반선·계획선)을 `b06-chart__ywindow` 한 겹으로 묶음. 자를 영역은 변환 밖,
  글자도 변환 밖에서 자리만 옮김. 선 굵기는 `vector-effect: non-scaling-stroke`
  (변환이 걸렸을 때만 적용해 B06 은 예전 그대로).
- [X] **기준값 각인** — 그릴 때 쓴 창(중심·표고1m당 px·기준 y·플롯 상단·높이)을 SVG 속성으로
  남김. 그리는 함수의 인자를 늘리지 않음.
- [X] **적용 모듈 신설** — `common_util_chart_ywindow.ts`(B05·B06 공용으로 옮김). 변환 계산 + 눈금 글자·
  좌측 고정 축 이동. 배율이 0.8~1.25 밖으로 나가면 **눈금층만** 다시 만듦(요소 20개 안팎).
- [X] **눈금 계산 공용화** — `yWindowTickValues` 로 빼 그리는 쪽과 갱신 쪽이 같은 눈금을 씀.
- [X] **스크롤 연결**(`_UI_Profile_Panel.ts`) — 스크롤마다 변환 갱신만. 전체 재구성은
  눈금 갱신으로도 못 살릴 때만 남김.
- [X] **B06 영향 없음 확인** — 변환 겹 3개 모두 변환값 없음(항등).
- [X] **자체검증 (2026-09-04, 검증 대기)** — 방법: 공용 브라우저 임시 탭에서 휠 20칸
  (4,800px) 실제 조작 후 수치 판독(사용자가 쓰던 탭은 건드리지 않음).
  결과: ① 그래프 전체 재구성 **0회**(고침 전 다회) ② 최대 프레임 **59.9 → 20.0ms**,
  20ms 초과 **0건** ③ 눈금 글자와 눈금선 어긋남 6.4 → **0.5px** ④ 지반선의 한 점을
  변환이 놓은 자리와 눈금이 말하는 자리가 **0.000px 일치**(배율 2.715 상태)
  ⑤ B06 종단 화면 불변 ⑥ 전체 시험 **381 통과 · 17 건너뜀**.
  계획 대비 차이 — 「눈금 값이 낡으면 눈금층만 다시 만든다」를 계획대로 넣되, 글자 내림
  4px 을 변환 **뒤에** 더해야 함을 실측으로 발견해 고침(그전에는 배율만큼 벌어짐).
  커밋 `8dca4bbf`.
- [X] **유토곡선·B06 페이지 확대 적용** (2026-09-04 사용자 지적 — 「유토곡선도 반영해야지.
  B06 페이지도 있잖아. 같은 로직일 텐데 왜 반영이 안 된 거야」).

  - 원인 — 그리는 쪽(종단 렌더러)은 공용이라 이미 바뀌어 있었고, **스크롤을 받아 창을 옮기는
    쪽이 화면마다 따로** 있어 B05 만 연결돼 있었음.

  - [X] 세로 창 모듈을 `common_util_chart_ywindow.ts` 로 옮겨 B05·B06 공용. 좌측 고정 축은
    표식이 붙은 것만 옮김(B06 은 한 컨테이너에 종단·유토곡선 축이 함께 삶).
  - [X] 세로 과장(B06 조절값)을 각인·반영 — 예전에는 과장 1일 때만 대상이었음.
  - [X] 유토곡선은 변환이 아니라 **곡선만 다시 그림**. 곡선 위 말풍선·EP 표·측점 점이
    세로로 늘어나면 안 되는 것이라, 그것만 따로 옮기는 값이 다시 그리는 값보다 큼
    (유토 SVG 234개 = 종단의 1/3).
  - [X] B06 상단 패널 통째 재구성 제거 — 종단은 변환, 유토곡선은 제자리 교체.
  - [X] 700줄 정리 — 종단 조립을 `_View_Chart.ts`(116줄), 유토곡선 조립기를
    `_View_MassHaul.ts` 로 분리(`_Section_View.ts` 727 → 718줄).
  - [X] **자체검증 (2026-09-04, 검증 대기)** — ① B05 유토곡선 눈금이 스크롤을 따라
    4.3㎥ → −1,348.8㎥ 이동(예전에는 안 따라옴) ② B06 종단 830/840/850m → 824/826/828m,
    유토곡선 68.2㎥ → −3,375.1㎥ 동시 이동 ③ B06 최대 프레임 **35.9 → 23.5ms**,
    33ms 초과 1 → **0건** ④ B05 최대 프레임 27.4ms, 33ms 초과 0건 ⑤ 전체 시험 381 통과.
    커밋 `685d44ac`.
- [X] **유토곡선 세로창이 확 튀는 것** (2026-09-04 사용자 보고·확정 「버티기 + 부드럽게」).

  - 원인 측정 — 한 칸마다 세로 폭 240·234·228 → **1,019㎥**(4.5배). 누가토량 곡선이 표고와
    달리 가팔라, 급한 구간이 창에 들어오면 배율이 한 번에 몇 배로 바뀜. 종단은 같은 방식인데
    폭이 20m로 계속 같음 — 방식이 아니라 데이터가 가파른 것이 원인.

  - [X] 버티기 — 곡선이 지금 창 안에 들고 55% 넘게 채우면 창을 안 건드림.
  - [X] 부드럽게 — 바꿀 때도 남은 만큼 20%씩 좁혀 약 0.15초에 걸쳐 미끄러짐.
  - [X] 여유 5% → **20%**(종단과 같은 값) — 곡선이 위아래 끝에 딱 붙지 않음.
  - [X] 곡선 계산을 입력 객체 단위로 아낌 — 스크롤 중 다시 계산해 프레임을 먹던 것.
  - [X] **자체검증** — ① 8칸 중 **4칸은 폭 변화 0**(버티기) ② 바뀌는 순간 궤적
    257 → 711(42ms) → 882(80ms) → 1,030(151ms) — 계단이 아니라 미끄러짐 ③ 휠 20칸 기준
    최대 프레임 27.4 → **24.0ms**, 33ms 초과 0건 ④ B06 21.2ms·0건 ⑤ 전체 시험 381 통과.
    커밋 `2b1fe118`.
- [X] **되돌림 — 곡선 계산 캐시 제거** (2026-09-04 사용자 보고 「종단 곡선 조절에 따라 횡단
  기준 유토곡선 변경 안 됨」). 같은 날 프레임을 아끼려고 넣은 캐시가 원인 — 횡단 설계는
  `refreshCrossDesigns` 가 **같은 객체를 제자리에서 고치므로** 「입력 객체가 같으면 안 바뀐 것」
  판정이 성립하지 않음. B06 은 `detail` 동일성으로 캐시해 한 번 계산한 뒤로는 영원히 낡은
  곡선을 보였음. 두 곳 모두 걷어내고 그릴 때마다 계산하게 되돌림. 커밋 `79dc0cc8`.
  - [X] **자체검증** — ① B06 지반 종류 변경 시 절토 4,500.3 → 4,500.7㎥·곡선 경로 변화 확인
    (고치기 전에는 완전 동일) ② B05 계획고 6칸 조절 시 계획선·유토곡선 둘 다 변화
    (성토 14,729 → 17,513㎥) ③ 휠 20칸 최대 프레임 27.0ms·33ms 초과 0건 ④ 전체 시험 381 통과.
- [X] **유토곡선이 그래프 칸 밖으로 새던 것** (2026-09-04 사용자 보고 — 「0선이 위로 넘어가고
  채움색이 눈금 상한을 넘어 표현됨」). 유토곡선에 **자르는 영역(clip)이 없었음** — 종단은
  진작 자르고 있었는데 빠져 있었음. 겹 둘(면 뒤 / 곡선 앞)로 자르고, 0선은 창 안에 있을 때만
  그리도록 함(사용자 확정: 0선은 나가도 됨). 커밋 `331be116`.

  - [X] **자체검증** — 확대 4칸 + 휠 25칸으로 0을 밖으로 보낸 상태에서 자르는 겹 2개,
    0선·0눈금 사라짐, 눈금 5개 전부 음수, 영역 캡처로 채움색이 위 경계에서 멈춤 확인.

- 700줄 초과 건은 아래 「700줄 제한 초과 — 한 번에 정리」로 모았음(2026-09-04 사용자 지시).

### 구조물 측점 누가거리 정본 일원화 (2026-09-04 사용자 보고)

증상 — 배수관 2 자리에서 계획선이 수직으로 꺾이고 최대 기울기 **155,791 %**.

원인(측정으로 특정) — 「가까운 점이 겹친 것」이 아니라 **한 구조물이 층마다 다른 누가거리를
든 것**: 횡단 측점 `264.054626` · 종단 정본 변화점 `264.055` · 배수 정본 파일 **`264.06`**
(cm 반올림, `common_util_drainage_pipes.py`). 사이드 목록이 든 값으로 계획고를 편집하면 정본
옆 5mm 자리에 변화점이 하나 더 서고, 둘 사이 종단곡선이 mm 로 쭈그러들어 기울기가 거리 0 에
가까운 값으로 나뉨. 2026-09-03 에 같은 증상(11,858%)을 ▲▼ 버튼 경로만 막아 뒀고, 측점
테이블·도구 경로가 남아 다시 터짐.

- [X] **저장 쪽** — 누가거리를 좌표와 같은 밀리미터 기준으로 남김(cm 반올림 제거).
- [X] **화면 쪽** — 구조물 측점 목록이 들어오는 한 자리에서 종단 정본 측점(0.1m 안)으로
  누가거리를 갈아 끼움. 모든 편집 경로가 함께 막히고, 이미 cm 로 저장된 옛 프로젝트도 안전.
- [X] **자체검증 (2026-09-04, 검증 대기)** — ① 264 부근 그래프 측점이 `264.055` 하나로 모임
  ② 그 측점 계획고를 8칸 올려도 수직 꺾임 **0건**, 계획선 점 수 1,208 불변, 최대 기울기
  66.0 → 183.5%(정상값) ③ 전체 시험 381 통과. 커밋 `5446f0cf`.
- [ ] **겹치면 구조물 측점만 남김** (2026-09-04 사용자 확정 — 「규칙 측점에 구조물 측점이
  위치하면 그때는 **구조물 측점 하나만 기준으로** 종단선을 그리면 된다」).
  지금은 정본 맞춤으로 둘이 같은 자리에 모이면 측점선이 두 벌 그려짐(예: 980m — 배수관 11 이
  규칙 측점 980 과 겹침). 겹쳐 보여 눈에 띄지는 않으나 같은 자리에 선이 둘인 것은 맞지 않음.
  - [ ] 그래프 측점 목록을 만들 때, 구조물 측점과 같은 자리(0.1m 안)의 **규칙 측점을 뺀다**
    (`_UI_Profile_Render.ts` 의 `regular` + `injected` 합치는 자리).
  - [ ] 측점 번호 라벨은 그대로 읽혀야 함 — 구조물 측점이 같은 누가거리를 들고 있어 라벨
    계산(`offsetStationLabel`)은 같은 값이 나옴. 실화면으로 확인.
  - [ ] **선택 동기화 확인** — 규칙 측점을 빼면 그 측점의 `station_id` 가 사라짐. 그래프·3D·
    사이드바가 같은 측점을 고르는 경로(`selectStation`)와 측점 테이블 열이 구조물 측점 id 로
    이어지는지 확인할 것. 여기가 이 작업의 유일한 위험.
  - [ ] 같은 규칙을 B06 종단에도 적용할지 확인(같은 렌더러를 씀).

### 700줄 제한 초과 — 한 번에 정리 (2026-09-04 지시)

사용자 지시 — 「700줄 리밋 리팩토링은 한번에 하자」. 그때그때 쪼개지 않고 여기에 모아 두고
한 번에 처리함. **착수 지시 대기.**

전수 조사(`.py`·`.ts`·`.css`, `node_modules`·`venv`·`0_old`·`tmp`·`storage`·`resources` 제외)
— **초과 5개**, 임박(620~700줄) 39개.

| 줄수 | 파일                                            | 나눌 결                                                                                                          |
| ---- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------- |
| 944  | `B07_DesignDetail/openwebcad/src/App.css`     | 화면 영역별(툴바·캔버스·패널·대화상자)로 나눔. 이 폴더는 상류 저장소 없는**우리 코드**라 규칙 대상임    |
| 851  | `common_util/common_util_mass_haul_view.ts`   | 세로창 규칙(버티기·부드럽게·범위 계산)을`common_util_mass_haul_window.ts` 로, 말풍선·EP·선택 강조를 별도로 |
| 730  | `B05_Profile/B05_Profile_UI_Profile_Panel.ts` | 높이 캐스케이드·리사이저 몫과 스크롤·세로창 갱신 몫을 각각 분리                                                |
| 718  | `B06_Section/B06_Section_UI_Section_View.ts`  | 스크롤·패널 높이 처리 분리(종단 조립·유토곡선 조립은 2026-09-04 에 이미 뺌)                                    |
| 714  | `B03_FileInput/B03_FileInput_UI_Style.css`    | 업로드 칸·카드·미리보기 영역별로 나눔                                                                          |

- [ ] **위 5개 분리** — 기능 이동 없이 **잘라 옮기기만** 함(내용 불변). 옮긴 뒤 `npm run typecheck`
  · `ruff format` · 전체 시험으로 같은 동작임을 확인.
- [ ] **임박 39개는 손대지 않음** — 620~700줄 구간(가장 큰 것 `B05_Profile_UI_Page.ts` 700줄).
  넘길 때 그 작업에서 함께 나눔.

### B05 초기화 범위 확대 — 전체 결과 보존 (2026-09-04 지시)

사용자 확정(2026-09-04) — 「초기값 = 파일 입력 직후 내부 기본값 결과 **전부**. 배수유역·
유토곡선·횡단도·횡단 구조물·3D 전체 포함, 불변」.

- **지금 되돌리는 것** — 노선 폴더 · 종단 · 횡단 · 관 편집분, DB 5개 표.
- **빠진 것** — 배수유역 분석 산출물(`01~04`), 3D 코리도(지우고 재계산), B07·B08 산출물.

- [X] **스냅샷 범위 확대(배수유역)** — 촬영 대상이 `B04_PreProcess/drainage/edits` 에서
  **`B04_PreProcess/drainage` 폴더 통째**로 넓어짐. 이제 `00_watershed_response` ·
  `01_primary_region` · `02_flow_direction` · `03_road_routing` · `04_detailed_basins` 가 함께 들어감.
  용량 실측(용화_LAS): 배수유역 폴더 **8.6MB**, 스냅샷 전체 3.9MB → **약 12MB**. 감당할 수준.
- [X] **옛 스냅샷 호환** — 범위를 넓히기 전에 찍힌 프로젝트는 `edits/` 만 갖고 있음.
  그 경우 예전처럼 관 지점 편집분만 되돌림(안 하면 초기화 뒤에도 편집분이 남음).
- [X] **3D 코리도 — 해결됨(2026-09-04)**. 「체인 시점에 코리도가 없다」는 전제 자체가 사라짐 —
  전처리 체인 마지막에 **서버가 같은 TS 빌더로 코리도를 만들어 저장**하게 바꿨으므로,
  스냅샷이 그것을 그대로 뜨고 [초기화] 는 새 route id 이름으로 되돌림. 읽기 전용 규칙도
  안 건드림. 구현·검증은 위 「B05 종단·유토곡선 조작감 3건」의 코리도 항목(커밋 `c322f538`).
- [X] **자체검증(단위)** — `tmp/tests/test_initial_snapshot_scope.py` 3건 통과.
  ① 촬영 목록에 배수유역 폴더가 있음 ② 관을 옮겨 세부유역이 바뀐 뒤 복원하면
  `04_detailed_basins` 와 관 지점이 **초기 내용으로 되돌아감** ③ 옛 스냅샷도 관 지점 편집분이
  되돌아감. 전체 시험 **185 통과 · 1 건너뜀**.
- [ ] **자체검증(실경로) 남음** — 용화_LAS 의 스냅샷은 **범위를 넓히기 전에 찍힌 것**이라
  새 범위를 실화면으로 확인할 수 없음. 파일입력부터 자동설계 체인이 새로 도는 프로젝트가
  필요함(또는 기존 프로젝트의 초기값을 버리고 다시 촬영 — 초기값 삭제라 사용자 지시 필요).

### B05/B06 구조물 UI 통합 후속(2026-09-04 예정)

완료한 UI 결함 수정은 `docs/raw/plans/2026-08-30_plan_B05_B06_ui_fixes.md`로 이동했다.

#### 도각·표제란 후속

완료 구현은 `docs/raw/plans/2026-09-02_plan_user_verified_completed_items.md`와
`docs/wiki/pages/B08_DesignDetail/B08_CAD_title_block.md`로 이관했다.

- [ ] 도각 외부 파일 불러오기와 개인용 도각은 다음 판 범위로 유지한다.

### B05/B06 700줄 제한 위반 정리 — 남은 확인 (2026-09-04)(분리시 유사 기능끼리 모아서 제한 리밋과 갭을 만들것.)

두 창이 15개를 나눠 정리해 **초과 파일 0건**. 분리 목록·자체검증 기록은 `docs/raw/plans/2026-09-04_plan_700line_split.md` 로 이관함.

- [ ] **B04 배수유역 라우터 — 쓰기 경로 확인**. 분리 검증에서 읽기 경로(`/drainage/rainfall`·`/drainage/primary-region` 200)와 텍스트 대조까지만 했고 **분석 재실행은 돌리지 않음**(30초 재계산이 작업본 산출물을 덮어씀). 다음에 그 프로젝트를 재분석할 일이 생기면 그때 결과가 분리 전과 같은지 확인.

### 초기값 보전 후속

완료 구현은 `docs/raw/plans/2026-08-29_plan_initial_design_lock.md`로 이동했다.

- [ ] 새 프로젝트 업로드 때 `initial_design.lock` 동안 B05 진입이 B11 준비 화면으로
  이동하고 체인 종료 후 자동으로 넘어가는지 실측한다.
- [ ] 노선 경로 변경을 전체 재계산으로 분리하고 별도 모달·진행 표시·
  `route_signature` 게이트를 설계한다.

## 진행 예정

### B06 횡단·수량 후속

- [ ] 3D 코리도 스윕과 저장·확정·새로고침에서 `extra_spans` 단별 구간값을 확인한다.
- [ ] 자동 자리에서 좌우 이동이 적용되지 않는 측점의 지형·배치 한계를 분리한다.
- [ ] 불규칙 측점 생성 시점 정본화.

  - 파일 업로드 직후 자동연산은 저장, 사용자 직접 추가는 캐시에 두고 임시저장·확정 때 정본화.

### 라이다 다중 파일 입력·대용량 처리

- [ ] 드론 라이다 프로그램의 병합 가능 여부 확인 후 용량 대책을 합의하고 별도 계획 수립.
  - 평상시 2장 30GB 미만, 최대 3장 50GB 미만.
  - 노선 버퍼 클리핑 없이 병합 전체 범위를 전처리한다는 현재 방침 유지.

### 구조물 절·성토 면적 반영 — 분리 보류 (2026-09-02 사용자 확정)

**현재 방식을 그대로 둔다.** 착수 시점은 나중에 따로 정하며, 그때까지 2D 면적·유토곡선은
지금처럼 **트림 전 표준횡단** 기준으로 산출한다. B05·B06 다른 작업에서 이 산식을 건드리지
말 것 — 손대면 이 항목의 판이 흐트러진다.

- [ ] 구조물이 차지하는 절·성토 면적과 수량 반영 (**보류 — 착수 지시 대기**).
  - 원인 확인(2026-08-30): `compute_cross_design`이 구조물 인자를 아예 받지 않는다
    (`samples, design_elevation_m, ground_type, section_mode, ditch_*, paved, standard, rock_boundary_offset_m, two_stage_slope`). 정본 `design_line`·`cut/fill_area_m2`는
    **트림 전 표준횡단**이고, 구조물이 깎는 `designTrim`은 화면·3D가 그릴 때만 만든다.
  - 그 결과 3D(트림 반영)와 2D 면적·유토곡선(미반영)이 서로 다른 단면을 본다.
    `common_util_mass_haul.ts`가 `design.fill_area_m2`를 그대로 쓴다.
  - 크기(구조물 단면적 상한 — 겹침·근입 포함, 신발끈 적분):
    84.3m 15.83㎡ / 149.73m 11.89㎡ / 200.92m 14.74㎡ / 275.71m 16.12㎡ 대
    같은 측점 저장 성토면적 8.84 / 18.46 / 19.86 / 17.77㎡ — 성토량의 절반 규모다.
  - 착수 시 결정할 것: 트림 산식을 서버로 포팅할지, 확정 시점에 프론트가 잰 면적을
    함께 저장할지. B08 수량산출(현재 37줄 셸)의 선행 조건이다.

## 참고

### 구조물 구현 기준

- 상세 타입·옵션 정본: `B05_Profile/B05_Profile_Structure_Types.json`.
- 배수관 정본: `pipe_points.json`; 일반 구조물 정본: `structures.json`.
- B05·B06은 같은 프론트 캐시와 백엔드 데이터를 사용한다.
- 점형=측점 1개, 구간형=시점~종점, 부지형=위치+면적.
- 자동=프로그램 산출, 후보=제안 후 사용자 확정, 수동=직접 추가.
- A8 집수정은 A1 배수관 유입부 옵션이며 단독 구조물이 아니다.
- 교량(A5)과 생태연못(F2)은 임도에서 사용하지 않는다.
- B·F·G군은 B05 선택지에서 제외하고 필요한 항목만 B06에서 사용한다.
- 기술 근거·수치는 `resources/knowledge/technical_info/01_임도/`를 우선한다.

### 계곡 통과 시설 선정

| 조건                                           | 시설                                             |
| ---------------------------------------------- | ------------------------------------------------ |
| 소계류, 횡단경사 30% 이하, 종단 3~5% 조정 가능 | 물넘이 또는 세월교 우선 검토                     |
| 계곡 횡단경사 30% 초과                         | 배수관 Ø800 이상; 800→1000→1200→1500 순 검토 |
| 수리계산 Ø1,500 초과, 협곡, 횡단경사 40% 이하 | BOX암거 검토                                     |
| 배수관 2련 이상 필요                           | 물넘이 재검토                                    |
| 하천 또는 3차수 이상 계곡                      | 세월교 검토                                      |

설계유량은 `Qd = 2.0 × Q`와 Manning 통수능으로 판단한다. 관경은 유량으로,
집수정·기슭막이 등 부속은 지형과 배치 위치로 정한다.