chore(rebar): Pier_T_rebar 작업 폴더 초기 구성 및 외부 의존 파일 통합

- Code\rebar_pipeline, review_pipeline, pier-program을 정션에서 실제 폴더로 전환
- Code\rhino_mcp 및 CLAUDE_rhino배경.md 추가, .mcp.json은 PYTHONPATH로 새 위치 사용
- pier-program 내부 .git 제거(이력은 backup\pier-program_20261028.bundle에 보관)
- worktree 가이드 반영(CLAUDE.local.md, HANDOFF.md)
- D:\Rhino-MCP 경로 참조를 새 위치로 치환

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>

context-migration/OPEN_미해결목록.md

@@ -0,0 +1,55 @@
+# OPEN — 미해결 항목 단일 창구
+
+> [G3-2] 미해결·보류·확인 필요 항목은 **개별 메모리에 분산 기록하지 않고 이 파일 한 곳에 모읍니다.**
+> 매 Task [Step 0]에서 확인하고, [Step 5]에서 신규 추가·상태 갱신을 수행합니다.
+> **대상이 삭제·폐기되어 무효화된 항목은 `무효`로 명시 표기**하며 삭제하지 않습니다.
+
+**상태값**: `미해소` / `해소` / `무효`
+
+| # | 항목 | 제기일 | 최근확인일 | 상태 | 원출처 [ref:] |
+| :-- | :--- | :--- | :--- | :--- | :--- |
+| 1 | [CONFLICT] 운곡교 P1 받침 대좌 높이 기준 불일치 — D2 ELEVATION TABLE의 EL.'X'−E(=h1+h2+h3+h4)로 구한 대좌 하단 EL 43.200 등이 D1 코핑 소단 상면(43.411 등)보다 5개소 모두 211mm 낮음. 대좌 작도 높이도 169.4/139.0으로 TABLE h1 164/139와 다름. 해소 전까지 대좌 10개소는 모델에서 제외(사용자 결정) → **[해소 2026-10-07 / 심영표]** 사용자 지정 기준 EL.'X'−(h1+h2)로 재계산하니 10개소 모두 코핑 소단 상면과 일치(8개소 0mm, NO.3·4는 −1mm로 표고 소수 셋째 자리 반올림 범위). 211mm 차이는 E(=h1+h2+h3+h4=425/400)를 빼서 생긴 해석 오류였음. EL.'X' = 코핑 상면 + h1 + h2. 남은 사항: D1 단면도 대좌 작도 높이 169.4(표 h1 164)의 5.4mm 차이, 대좌 모델 추가 여부는 별도 결정 | 2026-10-07 | 2026-10-07 | 해소 | [ref: DOC/02_분석/분석_운곡교P1교각도면판독_2026-10-07_v0.1.01.md §4 U1·U2], [ref: Code/교각모델링/검증/bearing_seat_check.json] |
+| 2 | 운곡교 P1 코핑 하면 평면도 은선 원 r=1,100(CS-CONC-MINR)의 설계 의도 미확인 — 현재 모델은 정면 R12,000 곡선의 교축방향 압출(띠형)로 해석(사용자 결정) | 2026-10-07 | 2026-10-07 | 미해소 | [ref: 같은 판독서 §4 U3] |
+| 3 | 운곡교 P1 교각 모델(.3dm) 육안 확인 — 헤드리스 뷰포트 캡처 실패로 Agent가 시각 확인을 하지 못함. 담당자 확인 필요. **현행 대상: v0.1.09 (3,190객체, 철근·교량받침·솔플레이트 포함. P1-FT·P1-CP는 사용자 결정으로 숨김 상태)** | 2026-10-07 | 2026-10-08 | 미해소 | [ref: DOC/05_검증/검증_운곡교P1교각모델_2026-10-08_v0.1.05.md §1-1~§1-5·§3] |
+| 4 | 운곡교 P1 후속 범위 — 철근 모델링(D2 조립도·D3 재료표 기반), 측량 평면좌표 반영(도면 미표기 → 선형 자료 필요). **[갱신 2026-10-07] 기둥 P1~P6(v0.1.02)·기초 B1~B12(v0.1.04)·코핑 C1~C16·교좌면 보강 S1·S2(v0.1.08) 철근 완료. 남은 것: 측량좌표. UA1(기초 조립용)은 사용자 결정으로 제외** | 2026-10-07 | 2026-10-07 | 미해소 | [ref: prompt/심영표/2026-10-07/Task_운곡교P1교각모델링_2026-10-07_v0.1.00.md] |
+| 5 | 운곡교 P1 받침대좌·패드 작도와 표의 차이 — ① D1 단면도 대좌 높이 169.4 vs D2 TABLE h1 164 ② D1 평면도 후열 패드 840폭 vs TABLE B=540 기준 740. 모델은 TABLE 값 적용(사용자 결정). 설계자 확인 시 해소 | 2026-10-07 | 2026-10-07 | 미해소 | [ref: DOC/03_설계/설계_운곡교P1교각모델링_2026-10-07_v0.1.02.md 작도 차이] |
+| 6 | [CONFLICT] 운곡교 P1 기둥 띠철근 P4·P5 간격 — 라벨·단면 표기 `H19 @100` vs 정면도 치수 사슬 `8@120=960`·`22@120=2.640`. 모델은 @120 적용(사용자 결정, 사슬이 전체 높이 17.203·본수 9/22와 일치) | 2026-10-07 | 2026-10-07 | 미해소 | [ref: DOC/03_설계/설계_운곡교P1교각모델링_2026-10-07_v0.1.04.md §5.2] |
+| 7 | 운곡교 P1 주철근 작도와 재료표 차이 — 작도선 상단 P1 43.011 / **P2 40.411(기둥 상단)** vs 재료표 길이로 계산한 상단 43.061(둘 다). 모델은 재료표 적용(H1). 주철근 반지름: 치수 `875` vs 단면 작도 870.5/825.5, 모델은 작도값 적용(H2, 띠철근 R897과 1mm 여유) | 2026-10-07 | 2026-10-07 | 미해소 | [ref: 같은 설계서 §5.2] |
+| 8 | 운곡교 P1 기둥 철근 간 교차 미보정 — ① 같은 높이 크로스타이 4본 중심 교차 ② 0°·180° 크로스타이가 주철근 다발 관통 ③ P3 이음부 갈고리 시작점 겹침. 커플러(P1 XIV, P4·P5) 솔리드 미작성. 철근 간 간섭 검사 미실시 | 2026-10-07 | 2026-10-07 | 미해소 | [ref: DOC/05_검증/검증_운곡교P1교각모델_2026-10-07_v0.1.02.md §1-2] |
+| 9 | [CONFLICT] 운곡교 P1 기초 철근 B12 본수 — 작도 위치 28곳(D1 정면도 중앙 4단) vs D3 재료표 34본. 모델은 작도 28본(F2). 검증 C9에서 FAIL로 기록 | 2026-10-07 | 2026-10-07 | 미해소 | [ref: DOC/05_검증/검증_운곡교P1교각모델_2026-10-07_v0.1.03.md §1-3] |
+| 10 | 운곡교 P1 기초 상면 피복 미달 — 작도 높이(F1) 채택 결과 B5 58.5 / B6 57.5 / B10 66.5 / B9 69.5mm (표기 100). B9 수량은 재료표에 비어 있어 총연장/L로 역산(493) | 2026-10-07 | 2026-10-07 | 미해소 | [ref: 같은 보고서 §1-3] |
+| 11 | 운곡교 P1 기초 철근 간 간섭 미검사 — B5·B6 다리 겹침(x=±4,575, y=±3,800), B9와 기둥 철근 교차, P1 갈고리(z 300)와 B7(z 277) 근접, B9 상단 갈고리 R 20.4 < 박스 최소 24 | 2026-10-07 | 2026-10-07 | 미해소 | [ref: DOC/03_설계/설계_운곡교P1교각모델링_2026-10-07_v0.1.06.md §6] |
+| 12 | [CONFLICT] 운곡교 P1 코핑 스터럽·폐합 철근 폭 — 재료표 C9~C11 a 1,407 / C12·C13 b 1,407 vs 단면 A-A 작도 스터럽 1,160/1,740/1,160, 폐합 1,106/1,686/1,106. 모델은 작도 폭(K1, 사용자 결정). 원길이 FAIL 5건으로 기록 | 2026-10-07 | 2026-10-07 | 미해소 | [ref: DOC/05_검증/검증_운곡교P1교각모델_2026-10-07_v0.1.04.md §1-4] |
+| 13 | 운곡교 P1 코핑 철근 [추론] 7건 설계자 확인 필요 — ① 상면 단 배정(1단 C1·C4 등, a 증가 순서 근거) ② C9 좌·C11 우 ③ 좌측 스터럽 상단 = 소단 −100 (우측만 작도) ④ 폭 방향 교대 ①CYCLE부터(K5) ⑤ C14 갈고리 방향(아래, 하면 근처 4본만 위) ⑥ C16 갈고리 좌단 ⑦ S1 위층·S2 아래층. 단면 B-B 정밀 추출 미실시 | 2026-10-07 | 2026-10-07 | 미해소 | [ref: DOC/03_설계/설계_운곡교P1교각모델링_2026-10-07_v0.1.09.md §7] |
+| 14 | 운곡교 P1 코핑 철근 간 간섭 미검사 — 스터럽 하단과 C7·C8 같은 높이(EL 40.511), C14 끝·갈고리와 스터럽 다리, S1·S2 다리와 상면 주철근, C1·C7 다리 겹침(정착 의도) | 2026-10-07 | 2026-10-07 | 미해소 | [ref: 같은 보고서 §1-4] |
+| 15 | 운곡교 P1 모델 객체 숨김 상태 — P1-FT(v0.1.03~), P1-CP(v0.1.07~)가 숨김으로 저장됨. Agent 스크립트에는 숨김 처리 없음(사용자 화면 조작 추정). 사용자 결정: 둘 다 유지. 납품·공유 전 표시 상태 확인 필요 | 2026-10-07 | 2026-10-07 | 미해소 | [ref: prompt/심영표/2026-10-07/Task_운곡교P1코핑철근모델링_2026-10-07_v0.1.00.md] |
+| 16 | 운곡교 P1 솔플레이트 경사 방향 [추론, 사용자 결정] — 두꺼운 쪽(T1 38)을 전열(−Y)로 둠. D2 솔플레이트 상세의 방향 표시·종단 경사와 모델 Y축 대응 근거 미확정. 양끝 두께 37.6/22.4 vs 표 38/22(반올림) | 2026-10-08 | 2026-10-08 | 미해소 | [ref: DOC/03_설계/설계_운곡교P1교각모델링_2026-10-08_v0.1.10.md §8] |
+| 17 | 교각 도면 모델링 앱 의사결정 4건 — ① 기술 기반(권고: 판독·검사 Python 엔진 + B-rep 생성(Rhino.Compute/플러그인) + 박스 웹앱 UI 혼합) ② 1차 대상 교각 형식 범위 ③ 산출 모델 형식(.3dm, IFC 연계) ④ 측량좌표·선형 입력 방식. **[해소 2026-10-08] 사용자 결정: ① 혼합구조(Python 엔진 + 로컬 Rhino 8 자동 실행 + Flask 단순 HTML), ② T형 교각만(그 외 무시), ③ .3dm, ④ local 좌표(측량좌표 변환 범위 밖). 반자동 MVP. 개발 진행 중: `Code/교각모델링앱/`** | 2026-10-08 | 2026-10-08 | 해소 | [ref: DOC/01_기획/기획_교각도면모델링앱요구사항검토_2026-10-08_v0.1.01.md §8.2·§9.3] |
+| 18 | 이 PC의 Rhino 8 자동 실행 정체 — 2026-10-12 오후부터 시작이 23분 지연되거나 결과 기록 뒤 종료하지 않음. 원인 미확인(창 제목 비어 있음). 실행기가 강제 종료·재시도로 대응 중 | 2026-10-12 | 2026-10-12 | 미해소 | [ref: prompt/심영표/2026-10-08/Task_T형교각모델링앱개발_2026-10-08_v0.1.00.md PROCESS 9] |
+| 19 | T형 교각 앱의 일반화 미검증 — ① 판독 규칙(표 3종) ② 음성 시험 대상(받침 10개 전제) ③ 객체 근거 문구(운곡교 고유) ④ 보고서 7장 항목명(영어). 운곡교 P1 도면 1세트로만 확인함. 두 번째 T형 교각 도면으로 검증 필요. **[갱신 2026-10-12] 운곡교 P2로 검증: G1~G5 PASS. 엔진 결함 2건 수정(말뚝 X·Y 간격, 마크별 띠철근 반지름). 미수정 5건(범위 문자 인식, 표 후보값이 params 미반영, 위치 목록 직접 입력, D1 작도 판독 앱 미지원, 음성 시험 받침 10개 전제)** **[갱신 2026-10-13 / 심영표] A3 범위 문자(열별 허용 거리)·A4 params 후보 별도 행·A5 치수 사슬 입력·A7 음성 시험 기본 대상 자동 조정 해소. A6은 핸들 조회 화면까지만(값 자동 반영·템플릿 판독은 미구현). 남은 것: A6 템플릿 판독, ③ 객체 근거 문구(운곡교 고유), ④ 보고서 7장 항목명(영어)** | 2026-10-12 | 2026-10-13 | 미해소 | [ref: Code/교각모델링앱/README.md 한계; DOC/02_분석/분석_운곡교P2교각도면판독_2026-10-12_v0.1.00.md §7] |
+| 21 | 산외교 울산 P1 — 형상(G1)·받침(G5)만 모델링. **[철근 해소 2026-10-13]** 철근 G2·G3·G4 모델링 완료(울산 전용 생성기·검사기 신설, G1~G5 전 게이트 PASS) → 남은 철근 확인사항은 #22로 이관. 남은 형상 사항: 코핑 평면 모서리 R500은 16분할 근사, 배수관 미모델. 대좌 fck 40 MPa [추론] | 2026-10-13 | 2026-10-13 | 미해소 | [ref: prompt/심영표/2026-10-13/Task_산외교울산P1모델링_2026-10-13_v0.1.00.md] |
+| 22 | 산외교 울산 P1 철근 — 사용자 확인 필요한 [추론]·도면 불일치. (1) 기초: B4 상면 끝 철근 3,650(측면 사슬) vs 정면 3,600 — 작도대로; B5 위치는 정면 상면열 [추론]; B7 체크무늬 98개·중앙 배치·갈고리 +Y [추론]; B9·B10 같은 높이(1,275)로 교차 간섭. (2) 코핑: C10·C12 수량(7·6)과 재료표 A 범위(8단·5단 해당)가 어긋남 — 수량 우선, C10 평균 길이 재료표보다 883 짧음; C8 x=0 스터럽 높이 우측 기준(평균 −18); C1/C3·C2/C4·C5/C6 교번 배치, C14 다리 방향·x 19 이격, S1/S3 위단 [추론]; 평면 R500 모서리 철근 단축(R400 원호까지) [추론]; 코핑 철근 상호 간섭(교차·겹침) 미검사. (3) H22·H13 색상 확장은 R8 등재 확정 대기 | 2026-10-13 | 2026-10-13 | 미해소 | [ref: prompt/심영표/2026-10-13/Task_산외교울산P1모델링_2026-10-13_v0.1.00.md], [ref: Code/울산P1판독/extract_r3.py, extract_r4.py] |
+| 23 | Ramp-A교 P1 — 형상(G1)·받침(G5)만 모델링(G1 97/97, G5 39/39 PASS, 엔진 실행). **[갱신 2026-10-13 / 심영표] 기둥 철근 G2 완료(26/26 PASS; K1~K4 결정, P3-주철근·띠철근 간섭 미검사, H35 색 (148,103,189) 사용자 확정 2026-10-13)** 남은 것: ① 앱에서 묶음 확정·G1·G2·G5 승인(담당자) ② **[갱신 2026-10-13] 말뚝 철근망 G3 완료(48/48 PASS, S1~S6 결정; U형 30개 중심 겹침·P3-1 관통 간섭 미검사, SPACER 미모델)** ③ **[갱신 2026-10-14] 코핑 철근 G4 완료(126/126; T1~T6 결정 + 추가 [추론] 모서리 단축 C1·C2·C3·C4·C6·C14 21본, 안쪽 스터럽 +20 — 사용자 확인 필요; C15 배치·C6 9본은 추정)** ④ **[해소 2026-10-14] 사용설명서 v0.2.05에 Ramp-A교P1형 반영, 앱 확정 대상 보완(G1·G3가 앱에서 막히던 결함 수정)**. 남은 것: ① 앱 확정·승인 ③의 [추론] 확인 ③ [추론] 솔플레이트 두꺼운 쪽 −Y(R4, 운곡교 규칙) ④ 말뚝 상부 Ø2,500이 케이싱 포함 지름일 가능성('75, 2,350, 75') ⑤ 육안 확인 미실시(캡처 수단 없음) ⑥ 장식 홈(상세 B) 미모델(R1 결정) | 2026-10-13 | 2026-10-14 | 미해소 | [ref: DOC/02_분석/분석_Ramp-A교P1교각도면판독_2026-10-14_v0.1.07.md §6·§9·§11·§12·§13] |
+| 20 | [CONFLICT] 운곡교 P2 도면 내부 미갱신 — 측면도 h1 163.4/139·h3 181, 평면도 패드 900×840(B 640), 단면 띠철근 R897.5, D3 B9 493본이 P1 값 그대로. P1 규칙(표·재료표 R 채택, 본수는 작도 채택)으로 처리, B9·B12(32/38) 계획 FAIL. **[결정 2026-10-12] 사용자가 P1 규칙대로 확정, 솔플레이트 −Y 유지. 모델 처리는 해소, 도면 자체의 미갱신은 설계자 확인 대상으로 남음** | 2026-10-12 | 2026-10-12 | 미해소(설계자 확인) | [ref: DOC/02_분석/분석_운곡교P2교각도면판독_2026-10-12_v0.1.00.md §6] |
+| 24 | 옥성교 P1 — 형상(G1)·받침(G5)만 모델링(G1 147/147, G5 183/183, 엔진 실행). 남은 것: ① 앱에서 확정·승인(담당자) ② **[갱신 2026-10-14] 기둥 철근 G2 완료(39/39, Q1~Q4)**. **G3 기초 완료(75/75, F1~F5; UM·겹이음 미모델; 518본, 모델 1,536객체, 회귀 전부 PASS)**. G3 [추론] 사용자 확인 필요: F2 B9 a 567 평균, F3 교번·겹이음 생략, F4 Y방향 중간근 +19. **[갱신 2026-10-14] 코핑·교좌면 철근 G4 완료(251/251, 1,163본; H1~H6 권장안, G1~G5 전부 PASS·불변, 모델 3,862객체; 135° 갈고리·겹이음·스터럽 이음 미모델)**. G4 [추론] 확인 필요: S1~S4를 가운데(3번) 대좌에(H1), 교좌면 그물을 평행사변형 방향으로(H2), C7 가장자리 2본 측면면 위로·C18 낮은 단 폭·다리 위로·C20 상면 y 줄(H3), S6을 S5 아래 직경만큼(H5), 5각형 스터럽 x +20, 스터럽·C18 평면 전단 적용. 간섭 미검사. ③ [추론] 대좌 상면 경사(O2), 솔플레이트 +Y(O4), 강관말뚝 속찬 원기둥(O5) ④ **[해소 2026-10-14] 사용설명서 v0.2.06 반영, v0.2.07에 철근 완료 반영** ⑤ 육안 확인 미실시. 남은 것: 앱 확정·승인(담당자) | 2026-10-14 | 2026-10-14 | 미해소 | [ref: DOC/02_분석/분석_옥성교P1교각도면판독_2026-10-14_v0.1.07.md], [ref: prompt/심영표/2026-10-14/Task_옥성교P1코핑철근_2026-10-14_v0.1.00.md], [ref: prompt/심영표/2026-10-14/Task_옥성교P1기초철근_2026-10-14_v0.1.00.md], [ref: DOC/02_분석/분석_옥성교P1교각도면판독_2026-10-14_v0.1.01.md §6·§8] |
+| 25 | 앱 데이터의 게이트 보고서가 웹 일괄 시험에 덮어써짐 — 산외교 울산 P1 `runs/current/G*_gate.json`이 '일괄 실행(단일 세션) — 저장·재로드 안 함' 상태(Ramp-A도 같았으나 2026-10-14 G1~G5 재실행으로 복원, test_rampa PASS 확인). 시험이 실제 교각 데이터에 쓰는지 확인하고, 울산은 `Code/울산P1판독` 또는 앱에서 G1~G5 재실행 필요. **[해소 2026-10-16] 옥성교P1·산외교울산P1을 엔진으로 G1~G5 개별 실행해 `runs/current` 복원(옥성교 147·39·75·251·183, 울산P1 104·35·63·129·75 PASS; 덮어쓰기 전 기록은 각 교각 `backup/runs_before_restore_20261016/`), test_okseong PASS. 웹 일괄 시험이 실제 교각 기록을 덮어쓰는 구조 자체는 미변경(시험은 자기 `검증/*_data`만 씀을 확인 필요)** | 2026-10-14 | 2026-10-16 | 해소(옥성교·울산P1) | [ref: Code/교각모델링앱/tools/test_rampa.py FAIL 원인] |
+| 26 | 앱 「2. 입력 묶음 확인·확정」 개편 기획(앱 확인 + 사람 확정, 표 밖 치수 탐색 = 규칙 + 템플릿 앵커, 변수 V1·V2·V3·F 구분) — **[갱신 2026-10-15] D3~D6 모두 권고안으로 결정(심영표)**: D3 경고+사유 입력, D4 일치 묶음만+근거표 열람, D5 A→B 먼저, D6 옥성교·Ramp-A교부터. **[갱신 2026-10-16] A단계(분류·표시) 구현 완료, 사용자 승인 대기**: `engine/variability.py`·보호 템플릿 6종 `variability.json`(초안)·묶음 표 「변수 등급」「값 출처」 열·템플릿 원본 그대로 표시(새 교각부터, 기존 교각은 기록 없어 미표시)·F 항목 편집 사유 필수(D3)·V3 편집 차단, `tools/test_variability.py` PASS, 웹 시험 19+1개 PASS. **[갱신 2026-10-16] B단계(앱 확인) 구현 완료, 사용자 승인 대기**: `engine/verify.py`(C1~C8)·`autocheck.json`·묶음 표 요약 띠/앱 확인 열·근거 보기·일치 묶음 일괄 확정(D4)·비일치 묶음 개별 확정 사유 필수·보고서 8.1, Prism은 새 화면만(`web/static/prism.css`). 시험 `tools/test_autocheck.py` PASS(거짓 불일치 0·거짓 일치 0, 운곡교 P3·P4 불일치 8건 검출), 회귀 fast 14/14·Rhino 7/7 PASS. **한계**: 표 밖 치수 묶음은 C단계 전에는 근거 없음, C8 재생성 미연결, 이전 방식 일괄 확정(`confirm_all`)은 접힌 항목으로 유지(D단계 결정), 기존 교각은 템플릿 원본 여부 미판단. **[갱신 2026-10-19] 이전 방식 일괄 확정(`confirm_all`) 제거 완료(사용자 결정), C단계 1차 구현 완료·사용자 승인 대기**: `engine/anchors.py`(앵커 학습·따라가기 R1·R2·R5, 등급 A/B/C, 틀 일치율 70 % 미만은 C)·템플릿 6종 `anchors.json`(`tools/make_anchors.py`)·[표 후보값] 「표 밖 치수 후보」 화면+도면 보기·반영 규칙(P7·C 사유·로그)·앱 확인 C2b. 시험 `tools/test_anchors.py` PASS: 같은 도면 틀 A등급 45건 중 틀린 후보 0, 값 변경 필드 복원 13, B 86 %, 다른 틀 36쌍 A·B 0, **운곡교 P4 도면의 치수 사슬 2건 불일치 발견(`62@125=7.250`, `29@250=7.750`)**. 회귀 fast 15/15·Rhino 7/7 PASS. **한계**: R3(철근 점·선)·R4(콘크리트 외곽 점열) 미구현, 계산으로 얻는 값·1 m 미만은 앵커 없음, B등급 약 14 % 오답, 기존 교각은 앵커를 템플릿에서 불러와야 함. **[갱신 2026-10-19] C단계 2차 완료·사용자 승인 대기**: ① 운곡교 P3·P4에 운곡교P1형 앵커를 불러와(`data/운곡교P3·P4/anchors.json`, 값 반영은 안 함) 실제 후보 확인 — 후보 146건, 표 교차 확인 후 A 56(표 일치 47)·B 65·C 25, 앱 확인 불일치 P3 10·P4 11 ② 표 값 교차 확인 구현(같은 틀 A등급 45→165건, 전부 맞음) ③ **R3·R4 기하(선 길이) 앵커는 시험 결과 채택하지 않음**(바뀐 값 복원 0건, 오답 A 2~7건/쌍) → 철근 위치·코핑 외곽은 계속 근거 없음 ④ A등급 expected만/params만 빠른 선택. **[갱신 2026-10-19] D단계 완료**: 전 화면 Prism 교체(`base.html`+`prism-app.css`), 사용설명서 v0.2.12, 전체 회귀, 운곡교 P3·P4 expected 쪽 A등급 반영(P3 29·P4 34필드, params 쪽은 P7로 막힘, 묶음 불일치 10/11 그대로, 필드 차이 69→52·75→63). **[갱신 2026-10-20] 운곡교 P3·P4 실사용 완료**: 도면에서 읽은 값으로 params·expected 반영 후 G1~G5 모두 통과·승인(P3 578/585·P4 577/585, 계획 외 FAIL 0, 계획된 FAIL P3 7·P4 8), 도구 `tools/verify_pier_geometry.py`·`apply_pier_read.py` 추가 — 개선 목록은 #34, 설계자 확인 대상은 #35. **남은 것**: 앱 개선(#34), 설계자 확인(#35) 사용자 결정 2026-10-16: Prism은 B에서 새 화면부터, 기존 화면 교체는 D | 2026-10-14 | 2026-10-14 | 미해소 | [ref: DOC/01_기획/기획_입력묶음확인확정개편_2026-10-14_v0.1.00.md §7.2] |
+| 27 | 새재1교 P1 — 형상(G1 138/138)·받침(G5 183/183)만 모델링(엔진 실행, 모델 39객체). 남은 것: ① 앱에서 확정·승인(담당자) ② [추론] 대좌 상면 평면 경사(N2), 기둥 fck 35 MPa(N3), 솔플레이트 두꺼운 쪽 −Y ③ **[갱신 2026-10-15] 기둥 철근 G2 완료(41/41; P3·P4 구간 배정·크로스타이 Y 높임 19·꼬리 c 165 [추론])**, **[갱신 2026-10-15] 기초 철근 G3 완료(72/76, 계획 FAIL 4: B5~B8 본수; 옥성교 F1~F4 재적용 [추론])**, **[갱신 2026-10-15] 코핑·받침좌 철근 G4 완료(189/189; 받침좌 S1·S2 배치, C7 올린 줄, C18 다리 방향, 스터럽 x 어긋남 ±12.5/37.5는 옥성교 규칙 재적용 [추론], 135° 갈고리·겹이음 미모델)** ④ 육안 확인 미실시(Rhino 렌더로 배치만 확인) | 2026-10-15 | 2026-10-15 | 미해소 | [ref: DOC/02_분석/분석_새재1교P1교각도면판독_2026-10-15_v0.1.00.md §5~7] |
+| 28 | [CONFLICT] 새재1교 P1 기초 X방향 철근 본수 — 작도 51곳(측면 점, 사슬 '52@150=7.800 −300') vs 재료표 B5 27 + B7 26 = 53(B6·B8도 같음). 모델은 작도 51곳(계획 FAIL 4건, 사용자 승인 2026-10-15). 설계자 확인 대상 | 2026-10-15 | 2026-10-15 | 미해소(설계자 확인) | [ref: DOC/02_분석/분석_새재1교P1교각도면판독_2026-10-15_v0.1.02.md §9.3 R1] |
+| 29 | 앱 화면 PRD·디자인 시스템(`DOC/01_기획/웹앱디자인시안/`) — **UX1~UX6 결정 완료 2026-10-15(심영표)**: UX1 R8 대체(Prism), UX2 상태색 전환, UX3 Pretendard 내장, UX4 마커 도형 승인, UX5 다크 시험 제외, UX6 HTML 시안 제작. 남은 것: 앱 코드 반영은 기획서 A→B 단계 착수 시(Pretendard 파일은 `web/static/fonts/`에 배치만 함), 디자인 시스템 공백 G1~G10 Prism 반영 요청, 상태 시프트 HEX 산출(G7) | 2026-10-15 | 2026-10-15 | 부분 해소(구현 대기) | [ref: DOC/01_기획/웹앱디자인시안/PRD.md §11.2] |
+| 30 | 템플릿 구분 기준 재정의와 도면 기반 템플릿 추천: ① 각도(skew·받침 회전·기초 회전)는 템플릿이 아닌 값으로 보고 옥성교·새재1교 검사기를 통합할지 ② 기초 형식 기준을 '말뚝 유무'로 할지 ③ ~~새재1교 '기초 회전' 값 위치 확인~~ → [정정 2026-10-15 / 심영표] 새재1교에는 기초 회전이 없음(앞선 전제가 잘못된 정보였음, 해당 확인 불필요) ④ S02를 '도면 먼저 → 추천'으로 바꿀지. **[결정 2026-10-15 / 심영표]** ①②④ 모두 권고안: 각도는 값으로 두고 옥성교·새재1교 검사기 통합, 기초 형식은 말뚝 유무만, S02는 도면 먼저→추천 순서로 변경. 기획서 v0.1.02 4.4절·PRD S02에 반영 완료. **남은 것: ③ (정정: 새재1교 기초 회전 없음 — 도면 확인 불필요) **[갱신 2026-10-15] G1 검사기 통합 완료**: `g1_skew.py` 폐기(백업 `Code/교각모델링앱/backup/2026-10-15_g1통합전/`), 옥성교·새재1교 모두 `g1_pedestal.py` 사용, G1 재실행 옥성교 147/147·새재1교 138/138 PASS(음성 시험 검출). **G4(`g4_okseong.py`·`g4_sj.py`)는 통합 보류** — 차이가 각도가 아니라 철근 배치 규칙(C7 줄·스터럽 구간·받침좌 철근 구성)이라 별도 결정 필요. 또한 옥성교 `runs/current/G1_gate.json`은 아직 구 검사기 기록(#25 일괄 실행 덮어쓰기와 같은 상태) — 앱에서 G1 재실행 필요. **[갱신 2026-10-15] S02 도면 먼저 추천 구현 완료**(`engine/recommend.py`, `web/app.py` /recommend, 시험 `tools/test_recommend.py` 8/9 교각 추정=실제 + 울산P2 1건 불일치 경고, `tools/test_recommend_web.py` 운곡교 DWG 3장 순위1 3/3 PASS). 추정은 3문항(말뚝 유무·하면 형상·받침 개수)만, 나머지는 사람이 답함. 규칙은 9개 도면 세트로만 확인(일반화 미검증). PRD S02에 구현 범위 반영함. **[갱신 2026-10-15] 형식 불일치 경고 상시 표시·각도 값 입력·결과 판정 영역도 구현 완료(test_recommend_web PASS). 화면 시안 `DOC/01_기획/웹앱디자인시안/시안/index.html`에 S02 화면 추가 완료(#/new, 헤드리스 Edge로 동작 확인; 추가 스크립트 `Code/교각모델링앱/tools/patches/s02_mockup_*`)**** | 2026-10-15 | 2026-10-15 | 부분 해소(구현 대기) | [ref: context-migration/템플릿구분기준과도면기반추천_논의.md] |
+| 31 | 산외교울산P2 도면과 모델 불일치 의심 — 도면에 '강관말뚝' 문자 3개(CS-DIMT)가 있는데 모델 params는 P1 복사본(직접기초, 말뚝 없음). 템플릿 추천 시험이 발견. 도면 말뚝이 실제 이 교각 기초에 해당하는지(범례·다른 교각 표기일 수 있음) 확인 필요. **[해소 2026-10-15] 울산P2를 P2 도면 값으로 모델링(기초 7,800×7,500 + 강관말뚝 30본 + 37° 회전) — 도면 말뚝은 이 교각의 말뚝이었고 기존 모델이 P1 복사본이었음** | 2026-10-15 | 2026-10-15 | 해소 | [ref: Code/교각모델링앱/tools/test_recommend.py KNOWN_MISMATCH] |
+| 32 | 산외교 울산 P2 — 형상(G1 118/118)·받침(G5 75/75)과 **철근 G2 35/35·G3 63/64(계획 FAIL 1)·G4 129/129 모델링 완료**(2026-10-15, 엔진 회귀 울산P1·새재1교·옥성교 G1·G3 PASS). 사용자 확인 2026-10-15: 기초 회전 반시계, 말뚝(속찬 원기둥)·솔플레이트 +Y·대좌 fck 40 추론 적용. 남은 것: ① 앱에서 확정·승인(담당자) ② **[CONFLICT] B8 띠철근 길이 — [사용자 승인 2026-10-16] expected.json 승인란 반영, G1~G5 재실행 PASS(118·35·63/64·129·75), 설계자 확인 대상은 유지**: 재료표 L 33.330 vs 2A+2B+4J 32.190(P1은 일치) — G3 계획 FAIL, 승인 미기재 ③ **B7 320본 배치 [추론]**(입면 22×20 위치 중 |x|≤2,000 & |y|≤1,750 제외; 가로·세로 바꿔도 320) ④ B9·B10 위치 1,000 간격 대칭 [추론], B7 다리 78/52 +Y, B5 위치 [추론] ⑤ 코핑 [추론]은 #22 동일, 철근 간 간섭 미검사 ⑥ 육안 확인 미실시 ⑦ 보호 템플릿 `산외교울산P2형` 저장 완료(철근·승인 반영본, 이전본 `_이전/`) | 2026-10-15 | 2026-10-16 | 미해소 | [ref: DOC/02_분석/분석_산외교울산P2교각도면판독_2026-10-15_v0.1.01.md §8]
+| 33 | 운곡교 P4 도면 치수 사슬 불일치 의심 — D2의 `62@125=7.250`(62 × 125 = 7,750)과 `29@250=7.750`(29 × 250 = 7,250)이 합계가 서로 바뀐 것으로 보임. 앱 R2 사슬 검산이 발견. 운곡교 P4는 아직 모델링하지 않았고(데이터는 P1 값 복사), 모델링 전 설계자 확인 필요. **[갱신 2026-10-19 / 심영표 화면 제시]** 사용자의 CAD 화면에는 같은 평면(기초 배근 평면도)이 `62@125=7.750`·`31@250=7.750`으로 보이고, 앱에 올라간 파일(`data/운곡교P4/drawings/dwg/C0050205-035-…P4).dwg`, sha256 2ea47f8d…)은 재변환해도 `62@125=7.250`·`29@250=7.750`이다 → **사용자가 보는 도면과 앱에 올린 파일의 판(version)이 다른 것으로 추정**. D1 정면도의 사슬(`62@125=7.750`·`30@250=7.500`·`31@250=7.750`)도 사용자 화면과 일치하므로 정정값은 7.750 / 31개일 가능성이 높음. 확인: 사용자가 보는 파일을 앱에 다시 올려(sha 비교) 오류가 개정본에서 고쳐졌는지 확인. **[갱신 2026-10-20]** 사용자가 P4 도면을 다시 올렸으나 해시가 같음(D2 `2ea47f8d81b1…`) → 같은 판. 오류는 그대로. 기초 철근 개수(재료표 65·34본)는 이 사슬과 무관하게 규칙 계산과 일치하므로 모델 값 선택에는 영향 없음(P4 G1~G5 통과) | 2026-10-19 | 2026-10-19 | 미해소(설계자 확인) | [ref: Code/교각모델링앱/tools/test_anchors.py R2 시험, data/운곡교P4/drawings/texts.json] |
+| 34 | 앱 개선 목록(운곡교 P3·P4 실사용에서 도출, 효과 큰 순): ① 도면 읽기 도구(`verify_pier_geometry.py`·`apply_pier_read.py`)를 앱 후보 화면에 통합, 템플릿 재현 검증 포함(새 교각당 수작업 100곳 이상 감소) ② params↔expected 일관성 검사(Rhino 실행 전, 게이트 1회 약 150초) ③ 묶음 안 필드 단위 '템플릿 원본 그대로 남음' 검사(P3: 앱 확인 불일치 0인데 게이트 40여 건 실패) ④ 표 칸에서 학습한 앵커의 거짓 후보 제거(재료표 행이 밀리면 '3.800' 같은 길이 칸을 사슬 끝으로 오인) ⑤ 일괄 실행이 마지막 단계(`display.py`)에서 중단될 때 중간 결과와 이전 승인 요약을 구분해 표시 ⑥ 점 좌표를 키로 쓰는 목록(`hooks_up` 등) 정합 검사(P3 G4 코핑 밖 점 56개의 원인) ⑦ 확정 사유 최소 품질(사유 'asf'·'12' 방지) ⑧ 임시 등록(계획된 FAIL) '설계자 확인 대기' 상태 관리와 더는 해당 없는 항목 자동 탐지(P2의 G3 B9 551/493 항목이 P3·P4에 남음) ⑨ 보고서에 독립 근거 구분 표시(PASS = 내부 일관성이며 도면 보증이 아님) ⑩ 후프 반경 마크별(표에서 읽음), 스터럽 좌측 윗면·c14 좌측 규칙 같은 P1 규칙 가정 단계의 도면 읽기 ⑪ 도면 파일 해시·개정 번호 기록과 비교 ⑫ 다른 도면 틀·형식(울산·새재1교 등)에서의 읽기 도구 일반성 확인. 기획서 6.6절 참조. **[갱신 2026-10-20] ②③④⑥ 구현 완료**(앱 확인 B3): ② C9 params↔expected 일관성(`engine/consistency.py`, 규칙 103~106건), ③ C3b 필드 단위 원본 잔존(교각 생성 시 `origin_values.json` 기록, 높이로 보이는 값만 비교), ④ 재료표 칸 하나에서만 따라간 앵커 후보를 C등급으로(`anchors.TABLE_RULE="single"`, 확인값 기준 B등급 오답 10/65 → 2/39, A등급 영향 없음; 부작용: 운곡교 P3의 expected:G2·params:column_rebar 가 일치 → 주의/근거 없음으로 내려감), ⑥ 점 좌표 목록(`hooks_up` ⊂ `c14.points`) 검사는 C9에 포함. 시험 `tools/test_consistency.py`(P3·P4 최초 백업의 실제 오류 상태를 모두 잡음, 완성된 P1·P3·P4 거짓 불일치 0), 회귀 fast 16/16. **[갱신 2026-10-20] ①⑤ 구현 완료**: ① `engine/geomread.py`(읽기 규칙 통합, 완성된 P1·P3·P4 에서 읽은 값 = 현재 값, 초기 P4 백업 → 144건 제안이 검증된 값과 같음)와 화면 「도면에서 읽기」(고른 줄만 반영, 백업·`read_log.json`, 다른 도면 틀 거절, 추론 줄은 기본 미선택) 및 `tools/apply_pier_read.py` 가 같은 읽기를 씀, `tools/test_geomread.py`. ⑤ 일괄 실행이 끝까지 가지 못했을 때 게이트 화면이 이유(error/fail/blocked/killed)·이전 실행 결과 표시·중간 결과·무효 승인을 보여 줌(`batch.json` 에 `started`·`reason`), `tools/test_batch_notice.py`. 회귀 fast 18/18. **[갱신 2026-10-20] P4 사고 후속**: 읽기 도구가 `G2.tie_offset`(= (dia.P4 + dia.P6) / 2, P1~P4 5개 값 일치)을 제안하도록 구현·시험 PASS(회귀 fast 19/19). 코핑 상단 `a` 는 12:00 코드 수정으로 이미 제안됨(12:11 판에서 반영 안 된 원인은 앱 서버가 수정 전 코드를 올려 둔 탓으로 추정, 미확인 → 앱 재시작 후 새 교각에서 확인 필요). c14 높이는 0.4 mm 차이로 허용오차 안(게이트 통과)이라 변경 없음. 앱 수정 계획 W1~W8·W4a~e 는 기획서 v0.1.14 6.10·6.11(미구현, D7~D13 사용자 결정 대기). 남은 것: ⑦~⑫ | 2026-10-20 | 2026-10-20 | 미해소 | [ref: DOC/01_기획/기획_입력묶음확인확정개편_2026-10-20_v0.1.08.md §6.6] |
+| 35 | 운곡교 P3·P4 설계자 확인 대상(모두 **임시 등록**, 사용자 승인 문구 '설계자 확인 전'): P3 — 재료표 C13 L 28.966(총중량 260.694÷9본과 일치)이 규칙 (max+min)/2 = 29.346과 380 mm 다름. P4 — ① 재료표 B11 30본 대 도면 점 32본(우측 반 작도, 좌우 대칭 가정; P1 28/28·P3 32/32는 일치) ② B12 재료표 38본 대 작도 32본(P1 34/28·P3 38/32와 같은 F2 규칙) ③ C9 좌측 스터럽 윗면은 도면에 없어 재료표 C9 b 최대 2.812·최소 1.376 에서 역산한 40447(= 철근 단 1 높이)로 둠(P1·P3의 '소단 − 100' 규칙과 다름) ④ C13 L 28.966(P3와 동일, 개정판 공통 표기 가능성) ⑤ D2 사슬 `62@125=7.250`·`29@250=7.750`(#33). P3·P4 승인 기록은 일괄 실행 자동 승인이며 보고서 3~5장은 담당자 작성 항목. **[갱신 2026-10-20]** 재료표 C13 L 28.966(규칙 29.346과 380 mm 차이)은 **P3·P4 도면에만** 있고 운곡교 P2 도면의 C13 은 29.345 로 규칙과 일치(P2 는 G4 에 계획된 FAIL 없음) → 설계자 문의는 'P3·P4 도면의 재료표 C13'으로 한정. P2 는 옛 P2(2026-10-12)에서 사용자가 확정한 B9(551 대 493)·B12(32 대 38) 계획된 FAIL 만 있음 | 2026-10-20 | 2026-10-20 | 미해소 | [ref: Code/교각모델링앱/data/운곡교P3·P4/expected.json planned_fail, prompt/심영표/2026-10-19/Task_도면도형직접판독시험_2026-10-19_v0.1.00.md] |
+| 36 | 입력 묶음 확정에 시간이 오래 걸리고 확인이 어려움(사유 '12'·'asf') — **[해소 2026-10-20]** 「검토 요약 확정」 구현: 앱이 바뀐 것·확인하지 못한 것·값의 출처를 한 화면에 모으고 사람이 도면과 대조한 묶음에 체크해 한 번에 확정, 사유는 앱이 자동 기록(`engine/review.py`, `/pier/<이름>/review`, `tools/test_review.py`). '앱이 확정' 방식은 확정의 의미를 없애므로 채택하지 않음. **남은 것**: 체크는 사용자의 선언이라 실제 대조 여부를 앱이 확인하지 못함, 'C10 도구 읽기 이력'(출처 근거) 연결 미구현, 기존 묶음별 개별 확정 화면은 예외용으로 유지 | 2026-10-20 | 2026-10-20 | 해소 | [ref: DOC/01_기획/기획_입력묶음확인확정개편_2026-10-20_v0.1.11.md §6.9] |
+| 37 | **운곡교 P4(2026-10-20 11:22 템플릿에서 재작성본) 마무리 대기** — 검증·승인된 첫 P4(G1~G5 PASS 09:08)는 사용자가 11:20 삭제해 `data/_휴지통/운곡교P4_20261020_112015` 에 있음(승인·결과 보존). 재작성본: 읽기(도면 145+1+4건·표 130건)·결정(좌측 스터럽 윗면 40447, tie_offset 22.5, 계획된 FAIL B11·C13, 앵커 rear_first_from_tip 1198)까지 반영, 11:59 게이트에서 G1~G3 승인·G4 계획 외 C1·C4(원래 길이 2 mm = 코핑 상단 철근 a 가 템플릿 값 11855) → 읽기 도구 비교 허용오차 수정(글자·재료표 값은 정확 비교) 후 `coping_rebar.tiers.a` 를 11856/11881/11905 로 반영. **[갱신 2026-10-20 12:50] 12:11 재작성본에서 위 결정이 템플릿 값으로 되돌아가 12:15 일괄 실행이 G1~G4 계획 외 FAIL 11건으로 중단 → 휴지통 `운곡교P4_20261020_121116` 의 `expected.json`·`params.json` 으로 복원(현재 판 백업 `data/운곡교P4/backup/before_restore_decisions_20261020/`). 임시 폴더 시험 실행: G1 171/171·G2 42/42·G3 71/73(계획 2)·G4 110/116(계획 6)·G5 183/183, 계획 외 0. 읽기 도구가 재현하지 못한 6곳: 앵커 rear_first_from_tip, tie_offset, 좌측 스터럽 윗면, 코핑 상단 a, c14 높이, 계획된 FAIL B11·C13. **[갱신 2026-10-20 14:35] 사용자가 읽기 도구만으로 P4 를 처음부터 다시 만들어 시험(14:31 재작성): tie_offset·코핑 상단 a 는 읽기가 맞게 채워 G2 PASS·G4 C1·C4 통과. 남은 계획 외 FAIL 8건(G1 5·G3 B11·G4 C9 b_sched·C13 규칙)은 손으로 정하던 결정 4건 → **읽기 도구에 4규칙 추가·시험 PASS(회귀 fast 19/19)**: ① 좌측 스터럽 윗면을 재료표 C9 b 범위로 역산(두 끝 일치 시, 이 P4 값 [[0,40597],[1100,40447]] 재현) ② 앵커 후보 rear_first_from_tip(A·B등급, 1232→1198, 기본 선택) ③ B11·B12 작도≠재료표 → 작도 채택 + 계획된 FAIL 제안(이 교각 숫자로 갱신, 승인 대기) ④ 재료표 L 이 (max+min)/2 규칙과 다르면(C9~C13) 계획된 FAIL 제안. 계획된 FAIL 제안은 기본 선택 안 함(승인은 사람). **남은 것**: 앱(웹 서버) 재시작 후 P4 를 다시 만들어 읽기 화면에서 4건이 올라오는지 확인 → 선택·반영 → 검토 요약 재확정 → 일괄 승인 → G4·G5 승인 → 보고서 초안. 한계: 운곡교 계열 P1~P4 에서만 확인, 시험용 P4 템플릿 상태는 `Code/교각모델링앱/검증/fixtures/p4_template_state/` 에 보관(P4 데이터를 다시 만들면 백업이 사라지므로) **[갱신 2026-10-22] 열린 Rhino에 P4 직접 반영(검사기만, 승인 아님): G1 171/171·G2 42/42·G3 71/73·G4 110/116·G5 183/183, 계획 외 0, 저장본 data/운곡교P4/runs/live/P4_열린Rhino반영_2026-10-22.3dm. 정식 승인·보고서 초안은 남음.** | 2026-10-20 | 2026-10-22 | 미해소 | [ref: Code/교각모델링앱/data/운곡교P4, prompt/심영표/2026-10-20/Task_앱개선_검토요약확정과P2P4마무리_2026-10-20_v0.1.00.md] |
+| 38 | 운곡교 P2(2026-10-20 10:53 템플릿에서 새로 만듦) — 읽기(126+4+6건)·표 94건·앵커 1건·planned_fail(B9·B12) 반영 후 G1~G5 PASS·승인(11:13, 578/585, 계획 7, 계획 외 0). 새 도구로 새 교각이 약 20분에 끝남. **남은 것**: 보고서 초안 미생성, 확정 기록의 공통 의견 칸이 비어 있음(앱이 자동 사유는 남김), 보고서 3~5장 담당자 작성. **[갱신 2026-10-20 15:32] 사용자가 P2 도 읽기 도구만으로 15:28 에 다시 만들어 시험: G1·G2·G4·G5 PASS(171·42·111·183), G3 71/73 계획 외 1(B9 551 대 493 — 읽기 도구가 B9 계획된 FAIL 을 제안하지 않음)** → **읽기 도구에 B9 추가·계획된 FAIL 반영 시 승인 기록(`approved`)을 사용자 선택·이름·날짜로 남기도록 수정, 시험 PASS**(`geomread.extra_changes` B9, `stamp_pending`; 템플릿 상태 P2 에서 B9·B12 제안·C13 없음, 완성된 P1·P2·P3·P4 거짓 제안 0). 예상: B9 등록 시 578/585·계획 7(이전 승인판과 동일, 실행 확인은 아직). **남은 것**: 앱 재시작 → P2 를 다시 만들어 읽기 화면에서 B9·B12 선택·반영 → 재확정 → 일괄 승인 → 보고서 초안 | 2026-10-20 | 2026-10-20 | 미해소 | [ref: Code/교각모델링앱/data/운곡교P2] |
+| 39 | 기초 철근 최외각 직경 판단 — 산외교·옥성교 기초는 교축·교직 주철근 직경이 서로 다른 마크가 있어(예: 산외 B1·B4 H16 / B2·B5 H22) 계산서 확인 후 피복이 작은 철근을 바깥에 두는 설계자 문의 필요. 운곡교 P1은 H29(B5·B6) 바깥으로 정해 수정3 반영(2026-10-23). 운곡교 B9 갈고리(내면지름 24.7<31.8, 연장 0·72<80)와 B2 다리 54.5mm 단축은 재료표와 불일치 — 설계자 확인 **[갱신 2026-10-26] 산외·옥성 기초도 같은 규칙으로 수정(직경 동일, 문의 불필요). 운곡 B9 임시 R24·연장100(수정6), 전단·세로철근(옥성 B9, 산외 B7·B9·B10)은 L 맞춤·걸기 수정을 했다가 도면 A·C 와 어긋나 **취소(수정3 폐기, 수정2 가 최신, 2026-10-26)** — 수정2 가 도면 치수와 이미 일치. 옥성 B9 는 ㄷ철근이 J 로 겹치는 서로 마주보는 ㄷ자 철근(사용자 확인 2026-10-26) — 모델의 마주보는 배치·J 겹침 확인 필요. **[갱신 2026-10-26 후속] 굽힘 R 미달 102본 완료, 운곡 B2 다리 끝 2100 통일, 옥성 P5·Ramp-A P3·P3-1 갈고리를 도면 r·c·d 로 수정(R-13~R-15). 최신: 운곡 수정7·산외 수정2(J 겹침 시험은 수정4)·옥성 수정6(P5 b 보정, R-17)·Ramp-A 수정6(P3-1 P3 각도 R-18, P3·P3-1 b 보정 R-17, P3-2 ㄷ자 R-16). **Ramp-A P3-1 은 도면 치수대로면 말뚝 밖으로 나감(M-9 도면 오류: 기존 모델 중심 피복 106.5mm 안쪽, 수정5 PL01 26본 중심 밖·PL02 22본 돌출) — 사용자 의견 2026-10-27: 도면 r135 각도 이상 → 철근은 P3 각도(r70.21·c165·d150)로 수정6 완료, 도면 r135 는 설계자 확인.**  남은 것: 옥성 B9 a=586~548 범위·J 겹침 규칙(도면 위치 확인), 겹침 J(C-3: 산외 코핑·기초 B2·B5·B8 은 수정5 R-19 완료 2026-10-27, 옥성 기초·코핑(C1~C6,B1~B8,B11,B12)은 수정7 R-22 완료, 옥성 C7·루프형·C15·C17, Ramp-A C14, 산외 P2 후프 미작업·운곡은 J 값 없음, 재료표 4J vs 모델 2J 설계자 확인), B9 갈고리(운곡) 설계자 확인. 엑셀 '수정 내역' R-1~R-12, 스크립트·결과 Code/검토수정/** | 2026-10-23 | 2026-10-26 | 미해소 | [ref: 검토파일/철근 모델랑 운곡교P1_바이브코딩/운곡교p1_수정3_20261023.3dm], [ref: memory/feedback_footing_rebar_cover_rule.md] |
+| 40 | 도면↔모델 마크별 형상 대조 이미지 — 옥성 완료(도면대조_옥성_코핑·기초, 엑셀 R-23). 운곡·산외·Ramp-A 미작성. 옥성 C15·C17 형상 불일치(도면 갈고리/모델 직선) 보정 대기. 겹침 보류(C7·C14·C16·B10, Ramp-A C14)는 사용자 지시로 당분간 유지 |
+| 41 | 옥성 수정8(C9·C11·C13 c=630 겹침) 반영. 남은 것: C15·C17 갈고리 형상, 운곡·산외·Ramp-A 오각형·사각형 j 형식 확인, C11 재료표 길이 불일치 |
+| 42 | 옥성 수정9(C15·C17 갈고리, R-25) 반영 — 갈고리 방향·C17 j 위치는 가정, 도면 확인 대기. 내일: 사각형 j·4개교 같은 형식 적용, 운곡·산외·Ramp-A 마크별 대조 이미지 |
+| 43 | 산외 마크별 대조 이미지 완료(R-26, 불일치 없음). 운곡·Ramp-A 는 DXF 에서 형식별 상세 그림 추출 후 작성. 엑셀 백업 하루 1개 규칙 적용(백업_중간본 폴더는 사용자가 확인 후 삭제 가능) |
+| 44 | 운곡·Ramp-A 마크별 대조 완료(R-27·R-28). 운곡 도면↔도면 오류 D-10(형식 그림 j ↔ 재료표 J 빈칸) 설계자 확인 대기. 산외·옥성 대조 이미지 도면 그림을 원본 DXF 렌더로 교체 예정 |
+| 45 | 옥성 도면 오류 D-11(C15·C17 갈고리 방향 미표기)·D-12(B10 j 6곳 vs 그림 2곳)·D-13(C14·C16 형상 그림 없음) + 운곡 D-10 — 설계자 확인 대기. 모델 수정9 의 갈고리 방향은 가정값 |

context-migration/README.md

@@ -0,0 +1,39 @@
+# context-migration 폴더
+
+프로젝트 진행 중 누적된 **컨텍스트 메모리**를 저장하는 폴더입니다. (Single Source of Truth)
+> 본 문서는 `.claude/taskexecutionagent.md` **v0.3.01**의 [G3]·[G3-1~4]·[R6]에 종속됩니다.
+
+## 목적
+- Task 진행 과정(Step 0~4)에서 획득한 컨텍스트를 메모리(.md)로 영구 보관합니다.
+- 중복 Task 요청 시 저장된 메모리를 먼저 확인하여 **재조사·재계산 비용을 없앱니다.** ([G6])
+
+## 필수 서식 — 신선도 4필드 ([G3-4])
+
+모든 메모리 파일은 상단에 아래 4필드를 둡니다. **필드가 없는 메모리는 근거로 인용하지 않습니다.**
+
+```
+소유자: [담당자명]
+확정일: [YYYY-MM-DD]
+최근확인일: [YYYY-MM-DD]
+재확인 조건: [이 사실이 무효가 되는 조건]
+```
+
+- 확정일로부터 **90일이 지난 메모리는 인용 전 재확인**하고, 재확인했으면 `최근확인일`을 갱신합니다.
+- 메모리가 파일·경로·조항·인원을 특정하는 경우, 인용 전에 그 대상이 아직 존재하는지 확인합니다.
+- [Step 0] 조회 시 **90일 초과 메모리가 3건 이상이면 사용자에게 정리를 제안**합니다.
+
+## 작성 규칙
+- **한 파일에는 하나의 주제/사실 단위**로 저장합니다. 파일이 비대해지면(권장 상한 20KB) 주제별로 분리합니다.
+- 동일 사실을 여러 파일에 중복 기록하지 않고 **기존 파일을 갱신**합니다. 신규 생성 전 기존 파일을 전수 확인합니다. ([R6])
+- **단정형 자동 확정 지시를 넣지 않습니다.** "다시 묻지 말 것", "확정됨 — 재확인 불요" 같은 문구는 오식별을 고착시킵니다. 확정 사실은 근거와 확정 일자를 함께 적고 재확인 조건을 명시합니다.
+- **재사용 가능한 형태로 씁니다.** 결론뿐 아니라 재계산·재조사가 불필요함을 명시하고(예: `## 검증 근거 (재확인 불필요)`), 실패한 접근은 `동일 방식 재시도 금지`로 남깁니다.
+- **오류로 판명된 메모리는 삭제**합니다. 단 재발 가능한 유형이면 삭제 대신 **기술 노트**로 전환합니다.
+- **비밀정보를 기록하지 않습니다.** ([F11])
+
+## 이 폴더의 상설 파일
+
+| 파일 | 역할 |
+| :--- | :--- |
+| `OPEN_미해결목록.md` | **미해결·보류·확인 필요 항목의 단일 창구** ([G3-2]). 개별 메모리에 분산 기록 금지 |
+| `정본선언_*.md` | 산출물이 2개 이상 계열로 분기했을 때의 정본 선언 ([G3-1]) |
+| `기술노트_*.md` | 사고·실패의 원인과 회피 방법 ([F13]) |

context-migration/memory/MEMORY.md

@@ -0,0 +1,39 @@
+- [평강1교 DXF drawings](reference_pyeonggang1_dxf.md) — Desktop DXF file locations/contents: general(bearing) drawing + rebar structural drawing for P1 pier
+- [평강1교 as modeling standard](project_pyeonggang1_modeling_standard.md) — why: reused as house baseline for structure/rebar modeling on future bridge projects
+- [notes.md location](reference_notes_md.md) — D:\Rhino-MCP\rhino-mcp-main\notes.md, background note from prior Claude Desktop chats on P1 work
+- [P1 pier structure facts](project_p1_pier_structure.md) — 대호지교 history/mechanics (long); OLD TODO list in it is superseded by the FINAL-state file below
+- [KDS rebar bend radius — HOW TO BUILD IT](feedback_kds_rebar_bend_radius.md) — KDS 24 14 21 Table 4.5-1 only (14 20 50 dropped) PLUS the actual validated Rhino method (Curve.CreateFilletCornersCurve + single CreatePipe sweep) — check here first for any future bent-rebar work
+- [Section/drawing standing rules](feedback_section_drawing_rules.md) — 1/2/3번 section method convention, layout/dimension rules, always ask before delete
+- [Coping haunch rebar method](feedback_coping_haunch_rebar_method.md) — validated approach: local frame from Brep faces, ray-cast underside, overlapping ⊓+⊔ box pairs
+- [IronPython exec scoping gotchas](feedback_ironpython_exec_scoping.md) — no nested def/comprehensions in execute_rhino_code, Z independent of L/W, AddBlock doesn't auto-insert
+- [Rhino connection check](feedback_rhino_connection_check.md) — is_server_available checks Grasshopper, not Rhino; use get_scene_info/get_layers to verify Rhino
+- [Rebar pipeline program plan](project_rebar_pipeline_program.md) — user will build a rebar-generation program; full method + scripts in D:\Rhino-MCP\rhino-mcp-main\rebar_pipeline\ (read README first)
+- [Final scene dump 2026-10-06](reference_final_scene_dump.md) — JSON snapshot of final P1 model (layers/objects/idefs/views)
+- [P1 FINAL model state 2026-10-06](project_p1_final_model_state_261006.md) — ground truth: geometry, all marks C1~C26, decisions resolved/open, scene hygiene (read first)
+- [Material table text alignment](feedback_material_table_text_alignment.md) — table texts left-aligned at cell-left+200 (DXF 72=0/73=2); new file *_좌측정렬.dxf
+- [Isolate-rebar layer gotcha](feedback_isolate_rebar_layers_gotcha.md) — C12~C18 stirrups live on layer P1_두부(코핑): keep ON, hide solids per object
+- [Rebar pipeline scripts index](reference_rebar_pipeline_scripts.md) — reusable scripts/method for other projects: D:\Rhino-MCP\rhino-mcp-main\rebar_pipeline (README §5-4 = 2026-10-06 additions)
+- [Always show paths](feedback_always_show_paths.md) — user gets confused by paths; end every reply with full paths used; keep pier-program\docs\paths.md updated
+- [Pier program state 2026-10-07](project_pier_program_state.md) — new program D:\Rhino-MCP\pier-program: T-001~T-007 done (119 tests), next T-008/T-009 + open questions; read docs/next_steps.md first
+- [KDS 24 14 21 = base standard (ALL projects)](reference_kds_24_14_21.md) — HWP location, extracted text + extractor, verified numbers, deviation-reporting rule (비고 3, magenta); also in CLAUDE.md §0
+- [운곡교 P1 project](project_ungokgyo_p1.md) — 현재 Rhino 모델=운곡교P1 (not 대호지교). 철근 도면↔모델 검토 완료(간섭 제외), 표 105항목, 내일 이어서: 검토_운곡교P1\README_내일시작.md 먼저 읽기
+- [운곡교P1 검토보고서 요약](reference_ungokgyo_p1_review_report.md) — E-01~E-12/M-01~M-10, 재료표 전 마크, 형상 I~XVII; 철근 하나씩 재검토 작업 기준
+- [운곡교P1 검토 작업 규칙](feedback_ungokgyo_review_workflow.md) — 4자 대조표·저장 폴더·내면반지름은 도면에 없음·측정 오류 교훈
+- [운곡교P1 모델 기준 재료표](project_ungokgyo_p1_model_bom.md) — 2026-10-16 도면/모델 재료표 대조 xlsx+DXF(비고 포함), 사용자 검토 단계, 재생성 방법·미해결 항목
+- [운곡교P1 B12 = 34본이 맞음](project_ungokgyo_b12_34_correct.md) — 모델 28본·D-16 도면내부 판정은 내가 도면 오독(간격1000·단면 400 엇갈림), 수정 요청 시 B12 재배치+대조표·표식 정정
+- [운곡교P1 B10 형상 오류](project_ungokgyo_b10_shape_error.md) — B10 모델 형상이 잘못(개수 9는 맞음), 올바른 형상 확인 후 재작성·대조표 정정 대기
+- [검토 단계 규칙: 지적은 기록만](feedback_ungokgyo_unrecognized_items_record_only.md) — 사용자가 내 인식 못 한 부분을 찾는 중, 오류 지적 시 모델·표 수정/되묻기 없이 기록만
+- [다른 교량 3개 검토 범위](feedback_review_other_bridges_scope.md) — 모델↔도면만 대조, 도면 내부 오류는 별도 보관 파일에 저장만
+- [산외교 P1 검토(1차 완료)](project_sanoegyo_p1_review.md) — 2026-10-19 DXF 변환·재료표 대조·표식 M-1~M-8, 다음 옥성교·Ramp-A교
+- [옥성교 P1 검토(1차 완료)](project_okseonggyo_p1_review.md) — V2 엑셀·이미지 파이프라인, 코드 M-1~M-8, 다음 산외교 재작성·Ramp-A교
+- [Ramp-A교 P1 검토(1차 완료)](project_rampa_p1_review.md) — 폴더 Ramp-A교P1, 코드 M-1~M-7, 말뚝 포함 모델
+- [운곡교 M-8·M-9 원인](project_ungokgyo_m8_m9_cause.md) — 도면 겹침 작도 vs 모델 간섭 회피 배치, 판정 보류(기록만)
+- [검토 파이프라인 스크립트](reference_review_pipeline.md) — D:\Rhino-MCP\rhino-mcp-main\review_pipeline (README 먼저)
+- [내일 할 일: Ramp-A 전체 재점검](project_next_session_rampa_todo.md) — 2026-10-19 인수인계, 점(원) 기준 방법·스크립트 위치, 운곡교 M-8/M-9 재확인도
+- [내일 할 일: P4 정식 승인·자동연결 확인](project_next_session_p4_live_and_review_files.md) — 2026-10-22 인수인계, 열린 Rhino P4 반영(승인 전), 검토파일 복사, 연결 바로가기
+- [기초 철근 높이·피복 규칙](feedback_footing_rebar_cover_rule.md) — 최외각 주철근 중심 기준, 직경 다르면 계산서·설계자 문의, 안쪽은 접촉 배치
+- [재료표 형상 확인·L 은 직선 합](feedback_rebar_table_shape_check.md) — 교량·재료표마다 형상 다름, 수정 전 A·C 대조, 중심선 길이를 L 에 맞추지 않음
+- [엑셀은 양쪽 복사본 같이 갱신](feedback_excel_both_copies.md) — 원본(심수석님 검토 파일)+Pier_T 복사본, 백업·해시 확인
+- [내일 할 일: 산외 J 겹침 승인·확대, 옥성 B9, P3-1](project_next_session_models_20261027.md) — 2026-10-26 인수인계, 최신 모델 파일 목록
+- [엑셀 백업 하루 1개](feedback_excel_backup_one_per_day.md) — 같은 날 수정은 한 백업 파일, 중간본은 백업_중간본 폴더
+- [DXF 도면이 제1 기준 자료](feedback_dxf_primary_source.md) — DXF 에서 직접 읽고 그림 잘라 증거에, 도면↔도면·도면↔모델 오류 엑셀 구분 기록(모든 프로젝트)

context-migration/memory/feedback_always_show_paths.md

@@ -0,0 +1,14 @@
+---
+name: feedback-always-show-paths
+description: User gets confused by file paths; list every path used at the end of each reply and keep docs/paths.md updated
+metadata:
+  node_type: memory
+  type: feedback
+  originSessionId: 1d08867c-dad9-4bc6-97dc-96e9d602d811
+  modified: 2026-10-07T00:00:18.088Z
+---
+
+사용자가 경로를 자주 헷갈려 하므로, 파일을 읽거나 만들거나 수정한 응답 끝에는 "이번에 쓴 경로"를 전체 경로로 알려준다. 새 경로는 `D:\Rhino-MCP\pier-program\docs\paths.md`에 추가한다.
+
+**Why:** 사용자가 직접 "내가 많이 헷깔리거든"이라고 말했고, 현재 기존 프로젝트(`rhino-mcp-main`)와 새 프로젝트(`pier-program`) 두 폴더를 오가고 있다.
+**How to apply:** 매 응답 끝에 짧은 경로 목록을 붙이고, 어느 쪽이 새 프로그램이고 어느 쪽이 참고용 기존 프로젝트인지 구분해서 적는다. 관련: [[project-rebar-pipeline-program]], [[reference-rebar-pipeline-scripts]].

context-migration/memory/feedback_coping_haunch_rebar_method.md

@@ -0,0 +1,25 @@
+---
+name: feedback-coping-haunch-rebar-method
+description: Validated modeling method for coping/cap-beam haunch rebar (e.g. C12/C18-type marks) with dimensions that vary along a sloped underside — user confirmed to keep reusing this approach on future pier rebar work
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: d49157ae-9661-437c-a1d1-639728d3fff0
+  modified: 2026-09-21T02:31:23.248Z
+---
+
+For coping (두부보) haunch-region rebar marks whose leg lengths vary along the pier length (following a sloped/stepped underside), use this method. Confirmed correct and to be reused going forward, on [[project_p1_pier_structure]] (대호지교 P1) and future similar pier projects.
+
+**Why:** the coping sits at real survey coordinates that are rotated/skewed relative to global X/Y (the pier is not aligned with the survey grid), so naive X/Y-based reasoning about "length direction" and "width direction" is wrong. Text-based DXF archaeology (parsing TEXT/DIMENSION entities to infer bend geometry) is slow and error-prone — several rounds of wrong shapes resulted from guessing at shape topology from DXF dimension text alone.
+
+**How to apply:**
+1. **Get the true local frame from the 3D model, not the DXF.** Query the coping's own Brep faces via `TryGetPlane()` — flat "shelf" faces give the width axis as their in-plane X/Y axes; vertical "riser" faces give the length axis as their face normal. Cross-check against the known coping width (should come out to a clean round number, e.g. 3500mm) and the known pile spacing.
+2. **Use ray-casting for exact underside elevation**, not manual face/vertex topology reasoning: `Rhino.Geometry.Intersect.Intersection.RayShoot(ray, [brep], 10)` shot upward from below the brep at any (station, width) point gives the exact underside Z at that point — far more reliable than reconstructing the stepped-haunch profile from face bounding boxes.
+3. **A "closed box (ㅁ)"-looking mark is often two overlapping open pieces, not one closed loop or one diagonal-following bar.** For this project's "V" shape (양곡) family: a "lid" piece (⊓, short FIXED leg length, opens downward from the main top-bar level) + a "base" piece (⊔, variable leg length computed from the ray-cast underside + cover, opens upward) — placed coincident/overlapping at the design stage; the physical front/back offset to avoid bar clash is a construction-detail-stage decision, not a design-stage one.
+4. **Multiple such boxes can be nested/overlapping across the width** (e.g. a 1005mm box near each edge + a 1250mm box further in, overlapping each other and mirrored left/right) rather than laid edge-to-edge — check whether the sum of box widths exceeds the actual member width before assuming edge-to-edge placement.
+5. **Longitudinal spacing is often two different CTC zones** (e.g. wider spacing far from a support, tighter spacing near it) rather than one uniform spacing. Always cross-check `(stations in zone 1 × boxes per station) + (stations in zone 2 × boxes per station)` against the material table quantity — an exact match confirms the station count/zone split is right.
+6. **Reuse an already-built neighboring mark's level as a datum** when the drawing says a piece "ties in" to it (e.g. the lid piece's Z level = the existing C1 top-bar block's own bounding-box Z, read directly off the block instance geometry, not assumed).
+7. **Iterate visually at one station before mass-generating.** Build one full cross-section (all boxes at one station) as raw pipes, isolate the relevant layers + coping in Wireframe display (Shaded mode hides embedded rebar inside solid concrete), and get explicit sign-off before looping over all stations.
+8. **Bundle each unique station's geometry into its own named block** (via `rs.AddBlock`) rather than trying to reuse one shared block across stations when leg lengths differ per station — block instancing only pays off for genuinely identical repeated geometry.
+
+See [[feedback_ironpython_exec_scoping]] for the RhinoMCP `execute_rhino_code` scripting gotchas hit while implementing this (no nested `def`/comprehensions, Z must be set explicitly since local L/W axes here are horizontal-only).

context-migration/memory/feedback_dxf_primary_source.md

@@ -0,0 +1,11 @@
+---
+name: feedback-dxf-primary-source
+description: DXF 도면이 모든 프로젝트의 제1 기준 자료 — DXF 에서 직접 읽고 그림은 DXF 를 잘라 증거에 넣고, 도면↔도면·도면↔모델 오류는 엑셀에 구분 기록
+metadata:
+  type: feedback
+---
+
+사용자가 주는 DXF 도면 파일이 배근·자료·모델 작성의 가장 기본 자료다(2026-10-28 지시, 모든 프로젝트에서 항상).
+
+**Why:** PNG 캡처나 표 숫자만 보고 작업하면 형상 오류를 놓친다(산외 B1/B4, 옥성 C15·C17 갈고리 등). 사용자는 도면을 잘 보고 오류 없이 배근하길 요구한다.
+**How to apply:** (1) 도면 값·형식 그림은 DXF 에서 직접 읽고 렌더링해 잘라 쓴다(`ezdxf` 설치됨). (2) 대조·증거 이미지의 도면 쪽 그림은 DXF 에서 자른 것. (3) 도면 안 오류는 엑셀에 '도면↔도면 오류'(내부 불일치), 모델과의 차이는 '도면↔모델 오류'로 구분해 항상 기록. 규칙은 `D:\Rhino-MCP\rhino-mcp-main\CLAUDE.md` §0 에도 추가함(백업 CLAUDE_백업_20261028.md). 관련: [[feedback-rebar-table-shape-check]] [[project-next-session-models-20261027]]

context-migration/memory/feedback_excel_backup_one_per_day.md

@@ -0,0 +1,11 @@
+---
+name: feedback-excel-backup-one-per-day
+description: 4개교_공통사항_종합.xlsx 백업은 수정마다 만들지 말고 하루(날짜)당 1개만 — 그날 첫 수정 전 상태
+metadata:
+  type: feedback
+---
+
+엑셀 백업 파일이 수정마다 쌓여 너무 많아졌다(2026-10-28 사용자 지적). 같은 날짜에 수정한 것은 한 파일로.
+
+**Why:** 두 폴더(검토파일, 심수석님 검토 파일)에 백업이 20여 개씩 쌓여 관리가 어려움.
+**How to apply:** 엑셀 수정 전 `Code\검토수정\스크립트\xlsx_backup_once.py`의 `backup_once()` 사용 → `4개교_공통사항_종합_백업_<날짜>.xlsx` 하루 1개(이미 있으면 새로 안 만듦). 2026-10-28에 기존 백업을 날짜별 1개만 남기고 `백업_중간본\` 하위 폴더로 이동(삭제 안 함, `consolidate_xlsx_backups.py`). 관련: [[project-next-session-models-20261027]]

context-migration/memory/feedback_excel_both_copies.md

@@ -0,0 +1,12 @@
+---
+name: feedback-excel-both-copies
+description: "4개교_공통사항_종합.xlsx 는 원본(심수석님 검토 파일)과 프로젝트 복사본(Pier_T\검토파일) 양쪽을 항상 같이 갱신 — 수정 전 백업, 엑셀 창 닫힘 확인, 해시 일치 확인"
+metadata:
+  node_type: memory
+  type: feedback
+---
+
+`4개교_공통사항_종합.xlsx` 를 고칠 때는 **원본 `D:\★Pier 자료\심수석님 검토 파일\` 과 프로젝트 복사본 `D:\★Pier 자료\프로그램\Pier_T\검토파일\` 양쪽을 모두** 같은 내용으로 갱신한다 (사용자 지시 2026-10-26 "양쪽다 바꿔").
+
+**Why:** 사용자가 "수정된 것 옆에 수정 완료를 작성해 달라"고 했을 때 복사본에만 써서 원본에는 안 보였다. 사용자는 원본 파일을 열어 확인한다.
+**How to apply:** ① 두 파일이 엑셀에서 열려 있지 않은지 확인(열려 있으면 닫아 달라고 요청) ② 각 폴더에 `…_백업_<날짜>_<사유>.xlsx` 로 수정 전 상태 보관 ③ 한 파일을 고친 뒤 다른 쪽으로 복사하고 SHA-256 일치 확인 ④ 이미지 48개 유지 확인 ⑤ 보고에 두 경로를 모두 적는다. 현재 두 파일은 12개 시트, 해시 `bd0f3e11a5087f27…` 로 동일(2026-10-26 15:27). 원본의 수정 전 7시트 백업은 `…_백업_20261026_원본.xlsx`. [[feedback-footing-rebar-cover-rule]]

context-migration/memory/feedback_footing_rebar_cover_rule.md

@@ -0,0 +1,20 @@
+---
+name: feedback-footing-rebar-cover-rule
+description: "기초 철근 높이·피복 규칙(사용자 2026-10-23) — 최외각 주철근 중심 기준, 직경 다르면 계산서 확인·설계자 문의, 안쪽 철근은 접촉해 들어옴. 이전 '같은 방향 모두 도면선 높이' 규칙은 폐기"
+metadata:
+  node_type: memory
+  type: feedback
+---
+
+기초 철근 높이는 **최외각 주철근의 중심으로 피복을 산정**한다. 교축·교직 철근 직경이 같으면 도면 최외각 직선철근 기준으로 그대로 하고, **직경이 서로 다르면 계산서를 확인해 피복이 작은 철근을 바깥에 둔다 — 설계자 문의 필요 사항**. 나머지 주철근은 최외각 철근 안쪽으로 접촉(반지름 합)해서 들어온다. 피복 밖으로 나갈 수 있는 것은 전단철근(B9류)뿐이고 주철근에 걸어준다.
+
+**운곡교 P1 적용(2026-10-23)**: H29(B5 상면 X, B6 하면 X)가 최외각. B5 중심 z2100(상면 피복 100), B6·B8 z150, B1 z2072.5, B2·B4 z177(B2 다리 끝 2072.5, 약 54.5 짧아짐). 결과 `검토파일\철근 모델랑 운곡교P1_바이브코딩\운곡교p1_수정3_20261023.3dm`. B9 갈고리(KDS 미달)는 설계자 확인 전까지 수정 안 함.
+
+**Why:** 같은 방향 철근이 모두 도면선 높이라는 이전 해석(수정2)은 교차 철근이 겹쳐 사용자가 폐기. 어느 직경이 바깥인지는 설계자·계산서 판단이라 AI가 정하지 않는다.
+**How to apply:** 산외교·옥성교 기초는 마크별 직경(교축/교직)을 먼저 표로 보여 주고, 직경이 다르면 설계자 문의로 올린 뒤 사용자 확인 후 수정. Ramp-A교는 말뚝 기초라 해당 없음. [[project-next-session-p4-live-and-review-files]]
+
+**2026-10-26 갱신 (4개교 기초 철근 작업 결과)** — 산외·옥성 기초도 같은 규칙으로 수정(직경이 교축·교직 같아 설계자 문의 없음): 산외 B1 2400/B4 2384/B2·B3 150/B5·B6 172, 옥성 B5·B7 2071/B6·B8 179. U자 다리 끝은 바깥 상면 철근선에 맞춤(도면 다리 길이 = 하면선~상면선 [추론]). 운곡 B2 다리 끝(2072.5)은 이 해석과 다름 — 통일 여부 사용자 결정 대기.
+- **B9 갈고리(운곡, H16)**: 도면에 R·연장 없음(도면 오류) → 임시 R24(KDS H16 최소 23.85)·연장 100(임의), 결과 `운곡교p1_수정6_20261026.3dm`. 정책: 도면에 값이 있으면 재료표 L 을 따르고, 없을 때만 KDS 최소 R + 임의 연장.
+- 전단·세로철근(승인 2026-10-26): 옥성 B9 연장 → 재료표 L 4,763, 산외 B7 양 끝을 바깥 주철근에 걸림(132.5/2414.5), 산외 B9·B10 연장 → L 7,500. 결과 `산외교P1 G5_수정3_20261026.3dm`, `옥성교P1_G5_수정3_20261026.3dm`.
+- 엑셀 `검토파일\4개교_공통사항_종합.xlsx` 에 '수정 내역' 계열 시트 5개 + '공통 문제 상세(이미지)' I열 '수정 완료' 추가. 스크립트·결과 JSON 은 `Code\검토수정\`.
+- 남은 것: 굽힘 R 미달 102본(운곡 P3 72, 옥성 C9·C13 18, Ramp-A C12 12 — 형상 복잡), 겹침 J(C-3), B7·B9 설계자 확인.

context-migration/memory/feedback_ironpython_exec_scoping.md

@@ -0,0 +1,31 @@
+---
+name: feedback-ironpython-exec-scoping
+description: "RhinoMCP execute_rhino_code (IronPython 2.7) scoping gotchas that caused repeated \"name X is not defined\" errors — avoid nested def/comprehensions and remember Z is independent of horizontal L/W axes"
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: d49157ae-9661-437c-a1d1-639728d3fff0
+  modified: 2026-09-21T08:00:01.071Z
+---
+
+When writing Python for `mcp__rhino__execute_rhino_code` (IronPython 2.7, run via exec with separate globals/locals):
+
+**Why:** the code runs with `exec(code, globals, locals)` where globals != locals. Any `def`-ined function or list/dict/set comprehension created inside the script cannot see the script's own top-level local variables — only globals. This repeatedly produced `name 'X' is not defined` errors even though X was clearly assigned earlier in the same script.
+
+**How to apply:**
+- Never define a helper `def function(...)` inside an `execute_rhino_code` script if it needs to reference other local variables from that script — inline the logic instead, or recompute needed values inside the function from parameters only.
+- Avoid list/dict comprehensions that reference outer local variables (e.g. `[pts[i].DistanceTo(pts[i+1]) for i in range(3)]` inside the same script scope) — same failure mode. Use an explicit loop or separate statements instead.
+- When building 3D points from a rotated local coordinate frame (length axis L, width axis W) that lie flat in a horizontal plane (Lz = Wz = 0, as is the case for [[project_p1_pier_structure]]'s skewed-in-plan coping), the formula `Z = Oz + s*Lz + w*Wz` will always just give `Oz` — Z must be set explicitly per point, it is not derivable from the L/W parametrization.
+- `Rhino.Geometry.Intersect.Intersection.RayShoot(ray, [geometry], maxReflections)` returns a `Point3d[]` of hit points directly, not an array of ray parameters — don't call `ray.PointAt(hit)` on the results.
+- `rs.AddBlock(object_ids, base_point, name, delete_input)` only **defines** the block and deletes the source objects; it does **not** insert an instance. Follow it with `rs.InsertBlock2(name, xform)` where `xform` is `Transform.Translation(base_point)` to place it back at the original location — inserting with `Transform.Identity` puts it at world origin instead.
+- To hide a solid brep so embedded/buried curves or pipes become visible, use Wireframe display mode (or hide the specific object) — Shaded mode's opaque surface hides anything inside it regardless of layer visibility toggles in some cases.
+- **Nested layer visibility is gated by the parent.** Setting `rs.LayerVisible("Parent::Child", True)` has no visible effect if `"Parent"` itself is off — worse, turning a parent off with `rs.LayerVisible("Parent", False)` can also flip the child's own visibility flag to False as a side effect. When isolating a nested rebar mark layer (e.g. `P1_두부_주철근_1CYCLE::C26_H19`) by looping `rs.LayerNames()` and turning everything off except a keep-list, always add the PARENT layer name to the keep-list too, not just the full child path — otherwise the mark silently fails to render even though the objects exist and its own layer flag reads True. This caused repeated "rebar isn't visible" reports from the user in one session ([[project_p1_pier_structure]]) before being traced to this cause — always verify with `rs.LayerVisible(parent)` AND `rs.LayerVisible(child)` when rebar seems to vanish, before suspecting a placement/scale bug.
+- After any isolate-for-screenshot operation, restore ALL layer visibility immediately afterward (loop `rs.LayerNames()` and set every one to `True`) — don't leave the document in an isolated state, since the user may look at the live Rhino viewport themselves between turns.
+- **`rs.AddBlock` re-bases raw geometry relative to `base_point`, but does NOT re-base nested block-instance objects** — when the objects passed to `rs.AddBlock` are themselves `InstanceReference`s (e.g. bundling several already-placed block instances into one wrapper block), their world-coordinate transform is captured as-is inside the new definition. Re-inserting with `Transform.Translation(base_point)` then double-applies the offset (coordinates come out roughly doubled). For a wrapper block made of existing instances, insert with `Transform.Identity` instead. For a block made from raw curves/breps freshly created at `base_point`, `Transform.Translation(base_point)` is correct (this is the case in [[feedback_coping_haunch_rebar_method]]'s leaf-level boxes). When in doubt, insert once and check the resulting bounding box against the expected world coordinates before moving on.
+- To bulk-remove unused/orphaned block definitions (e.g. after re-generating geometry and leaving old block names behind), loop `sc.doc.InstanceDefinitions`, check `idef.UseCount()` (no arguments — the 1-arg overload doesn't exist here), and call `sc.doc.InstanceDefinitions.Delete(idef.Index, True, True)` for any with a zero count.
+- **Whether a freshly-`AddBlock`-ed instance needs `Transform.Identity` or `Transform.Translation(base_point)` on reinsertion is NOT reliably predictable** when the bundled objects are themselves block instances (as opposed to raw curves/breps) — it varies between calls in the same session for reasons not pinned down (possibly stale/colliding block-definition names from earlier failed attempts, seen once as a confirmed cause). The robust pattern: insert with `Identity`, check the resulting bbox's X against the known expected world X (from the pre-bundle `base_point`); if off by more than ~1 unit, delete that instance and reinsert with `Translation(base_point)` instead. Always verify this way rather than assuming either transform is correct. A large constant (non-varying) Z across many wrapped stations is not automatically a bug — check whether that span of the structure is genuinely flat (e.g. sits on a flat bearing shelf) before assuming the transform is broken.
+- Before reusing a block base-name across repeated build/rebuild attempts, purge stale unused definitions matching that name pattern first (see the `UseCount()`-zero purge above) — leftover definitions from an earlier failed attempt can collide with or shadow a later rebuild using the same names and produce corrupted (wrong-position) instances. **This bit twice in the same session** (C18's station 1/19, then C15's entire station level) — the safe sequence every time a mark gets rebuilt at the same station-numbering scheme is: (1) delete the mark's layer objects, (2) explicitly purge every definition whose name starts with that mark (`idef.Name.startswith("C15")` etc, not just an exact-name match — the per-station and per-box-type sub-block names share the prefix), (3) only then regenerate. Also always delete throwaway verification instances (e.g. from `rs.InsertBlock2` used just to check a definition's position) immediately — a leftover one keeps that definition's `UseCount()` above zero and defeats the purge.
+- **`Rhino.Geometry.PipeCapMode.None` is a syntax error** (invalid syntax, not a runtime error) — `None` is a reserved Python keyword and can't follow a dot as an attribute name. The actual enum member for "no cap" is spelled `Rhino.Geometry.PipeCapMode.NONE` (all-caps) in this RhinoCommon build — check with `dir(Rhino.Geometry.PipeCapMode)` if unsure rather than guessing the casing.
+- **To lengthen just one leg of an existing ⊓/⊔ box leaf (e.g. extending a lid's leg while its overlap point with a separate base piece must stay fixed — see [[project_p1_pier_structure]]'s C13/14/15/16/17 lid-extend fix), don't rigidly translate the whole Brep.** Instead: duplicate the Brep, translate the duplicate by the desired offset, then bridge the gap with a new straight filler pipe from the original (fixed) end point to the shifted end point (`Brep.CreatePipe(LineCurve(Line(p, p_shifted)), radius, False, PipeCapMode.NONE, False, tol, angleTol)`), and put `[shifted_original, ...unrelated_pieces_unchanged, filler1, filler2]` back into the definition via `ModifyGeometry`. This preserves the exact original bend/corner geometry (never touched) and the exact original overlap length with any neighboring piece, while genuinely adding real bar length at the correct end — the general pattern is "shift + fill the gap with a new straight segment," not "stretch/scale the existing solid." To find each leg's exact fixed end point, use `brep.Vertices` — for a simple open-ended (uncapped) pipe swept along a bent rail with no sharp corners, the topological vertex list contains exactly the 2 open-end points (both located at the Brep's own bbox Zmin if it opens downward, or Zmax if it opens upward) and nothing else; this also doubles as a fast way to tell two overlapping box pieces apart (the one whose vertices sit at ITS OWN Zmin opens downward/"lid"-style, the one whose vertices sit at ITS OWN Zmax opens upward/"base"-style).
+- **ROOT CAUSE of "rebar color keeps not matching its diameter after any edit" (recurring user complaint): `InstanceDefinitions.ModifyGeometry(index, geometryList)` called with the 2-arg (geometry-only) overload silently RESETS the `ObjectAttributes` of every object in that definition — including ones passed through unchanged by reference — to `ColorSource=ColorFromLayer` on whatever incidental layer index the definition happened to store (seen: layer `P1_두부(코핑)`, not the mark's own rebar layer).** The correct/original state (confirmed by comparing against an untouched box-def, e.g. `C12_1005_01`) is `ColorSource=ColorFromParent` on every leaf object — that's what makes a nested block instance actually display the mark layer's diameter-based color (e.g. H22=dark red 104,0,25) instead of whatever the leaf's own stored layer says. **Any use of the geometry-only `ModifyGeometry` overload (as used throughout [[project_p1_pier_structure]]'s C13/14/15/16/17 lid-extend fix on 2026-09-21) silently breaks color for every object in that definition, not just newly-added ones.** Fix (queued for [[project_p1_pier_structure]]'s next session, not yet applied): use the 3-arg overload instead — `InstanceDefinitions.ModifyGeometry(idef.Index, geometryList, attributesList)` — where `attributesList` is a matching list of `Rhino.DocObjects.ObjectAttributes()` with `.ColorSource = Rhino.DocObjects.ObjectColorSource.ColorFromParent` set on each (this overload exists; confirmed via `InstanceDefinitionTable.ModifyGeometry.__doc__` listing 3 overloads including `(Int32, IEnumerable<GeometryBase>, IEnumerable<ObjectAttributes>)`). Going forward, **always pass an attributes list alongside geometry** on any `ModifyGeometry` call on these rebar box-defs, never the bare 2-arg form, to avoid re-breaking color on every future edit.
+- **To rigidly move ONE station's sub-block within a nested "mark" block definition (e.g. shift just `C13_13_r3` inside the `C13` definition up in Z), `rs.TransformObject`/`sc.doc.Objects.Transform` on the id from `idef.GetObjectIds()` silently no-ops** (returns `None`, bbox unchanged) — those ids are not transformable as live doc objects. The working method: `objs = idef.GetObjects()`; for each `o`, `geo = o.Geometry` (an `InstanceReferenceGeometry` whose `.Xform` is the placement transform and `.ParentIdefId` names the nested sub-block); build a **new** list where the target entries are replaced by `Rhino.Geometry.InstanceReferenceGeometry(geo.ParentIdefId, Rhino.Geometry.Transform.Translation(0,0,dz) * geo.Xform)` and all others keep the original `geo`; then call `sc.doc.InstanceDefinitions.ModifyGeometry(idef.Index, newlist)` (note: **`.Index` not `.Id`** — passing the Guid throws a type-conversion error since the method wants the integer index) and `sc.doc.Views.Redraw()`. Mechanically verified working (the `.Index` vs `.Id` call itself succeeds and redraws correctly), but **this whole-sub-block rigid-move was the WRONG fix for [[project_p1_pier_structure]]'s C13/14/15/16/17 datum-raise** — it was tried first, then reverted, because those stations are lid+base overlapping boxes and rigidly moving the whole thing also drags the base (which must stay put); see the lid-extend bullet above for the corrected approach. Keep this `ModifyGeometry`/`.Index` mechanism in mind for cases where a genuine whole-station rigid move IS correct (e.g. no base/lid split, or intentionally repositioning an entire self-contained station). Identify which sub-block belongs to which named station via `sc.doc.InstanceDefinitions.FindId(geo.ParentIdefId).Name` (not `.Find(guid)` — that overload wants a string and throws).

context-migration/memory/feedback_isolate_rebar_layers_gotcha.md

@@ -0,0 +1,11 @@
+---
+name: feedback-isolate-rebar-layers-gotcha
+description: When isolating rebar in the P1 model, the C12~C18 stirrup content lives on layer P1_두부(코핑) — never turn that layer off; hide the concrete objects individually
+metadata:
+  type: feedback
+---
+
+All leaf objects inside the C12~C18 block definitions (152/137/130/338/130/137/152 leaves) are on layer `P1_두부(코핑)` (ColorFromParent, so they draw in the mark layer's colour). Turning that layer off makes the stirrups vanish even though layers C12_H22…C18_H22 are on (user: "철근이 켜져있는데 안보여 … 다 어디로 날려보냈니?"). C1~C11 and C19~C25 leaves sit on their own mark layers and are fine.
+
+**Why:** happened 2026-10-06 when the user asked "C22,C24 철근이랑 주철근만 켜줘" and I hid every other layer; cost several turns of debugging (I first blamed camera positions/zoom).
+**How to apply:** to show rebar only, keep `P1_두부(코핑)` ON and hide its 3 objects (coping solid + 2 construction lines) with rs.HideObject; the user restores with Show. Also remember `doc.Objects` iteration skips objects on off layers unless ObjectEnumeratorSettings.HiddenObjects=True. Previous visibility state of all layers: `261006_layer_visibility_before_isolate.json` in the drawings folder. See [[project-p1-final-model-state-261006]].

context-migration/memory/feedback_kds_rebar_bend_radius.md

@@ -0,0 +1,35 @@
+---
+name: feedback-kds-rebar-bend-radius
+description: "Rebar bend rule = KDS 24 14 21 Table 4.5-1 ONLY (KDS 14 20 50 not used) + validated Rhino method for building bent rebar"
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: 3f00c5a2-89d3-4ff6-bce0-294eebc0a639
+  modified: 2026-09-22T05:31:31.332Z
+---
+
+Rebar bend geometry follows **KDS 24 14 21 4.5.2.1 Table 4.5-1** (min inner bend **diameter**, not radius). KDS 14 20 50 (building code) does NOT apply to this project - user ruled it out 2026-10-22.
+
+- Deformed bar: D16 or less 2db / D19 or more 3.5db (inner radius 1db / 1.75db). Plain bar: 1.25db / 2.5db.
+- Standard hook (4.5.4.2): 90-150 deg bend, extend >= 5db past the bend; >=150 deg also >= 5db.
+- Nominal bar diameters (KS D 3504): H16=15.9mm (commonly 16), H19=19.1, H22=22.2, H25=25.4, H29=28.6.
+- Already-built P1 models used R=3db (H25 R=76.2mm) / 4db (H29 R=114.4mm): old values, larger than the KDS 24 14 21 minimum, so not violations - but they are NOT the standard.
+- Which R to use for NEW modeling (code minimum vs previous practice) is the user's decision - [미확정], ask before building.
+
+**Why:** user wants only the bridge code (KDS 24 14 21) carried in this project; the earlier 14 20 50 table was a building-code carry-over that does not fit.
+
+**How to apply:** compute inner radius from Table 4.5-1 (or the user-confirmed value), then centerline fillet radius = inner radius + db/2. See [[reference_kds_24_14_21]] and [[project-pyeonggang1-modeling-standard|future pier projects]].
+
+## How to actually build a real KDS-compliant curved bend in Rhino (method validated 2026-09-23, [[project_p1_pier_structure]] C8/C10 rebuild)
+
+**Do not build bent rebar as multiple straight `Brep.CreatePipe` segments joined at sharp/mitered corners** — this was the original (wrong) construction found in C8/C10: many tiny straight sub-segments (some as short as ~18-30mm) meeting at sharp vertices with zero bend radius. A real KDS bend needs an actual circular fillet arc at the corner, and short straight segments physically cannot fit a realistic bend radius (e.g. R=76.2mm for H25 needs the arc's two tangent legs to each have that much straight room on both sides — a corner between two ~20-30mm segments cannot hold it at all). If straight segments were pre-built that short, first **simplify the path to only its真正 structural corners** (e.g. collapse "hook tip → tiny kink → tiny kink → long diagonal" down to just the long diagonal's own two endpoints) before fillet-ing — don't try to fillet every pre-existing micro-corner.
+
+**The actual working method — one clean call, not manual arc/tangent-point math:**
+1. Build the full **centerline** path as an ordered list of `Point3d` (the bar's true corner/anchor points — hook tips, bend points, straight-span ends). Convert to a `Rhino.Geometry.Polyline` then `.ToPolylineCurve()`.
+2. **Centerline fillet radius = KDS inner radius R + bar radius (db/2)** — e.g. (past P1 case, old value, not the standard) H25: R_inner=76.2mm + db/2=12.7mm → centerline radius = **88.9mm**. (The inner radius is the radius of the bend's *inner* face, not the centerline — always add the bar radius to get the sweep-rail radius.)
+3. Call **`Rhino.Geometry.Curve.CreateFilletCornersCurve(polylineCurve, centerlineRadius, tolerance, angleTolerance)`** — this single static method fillets *every* interior corner of the polyline in one call and returns a `PolyCurve` with the true endpoints preserved exactly (start/end untouched, only interior corners rounded). Far simpler and more robust than manually computing per-corner tangent points and building/trimming arcs by hand.
+4. Sweep **one single pipe** along the whole resulting smooth `PolyCurve` via `Brep.CreatePipe(filletedCurve, barRadius, False, PipeCapMode.NONE, False, tol, angleTol)` — this gives ONE clean Brep for the entire bent bar (not a fragmented multi-piece assembly), since the curve itself is already one continuous smooth path.
+5. **Verify the fillet radius actually landed correctly** by sampling curvature along the filleted curve *before* piping it: loop `t` across `curve.Domain`, call `curve.CurvatureAt(t).Length` (=kappa), and check `1.0/kappa` at its minimum equals the intended centerline radius (88.9 in the H25 example) — this was the actual validation step used and it matched to 5 decimal places. (Checking curvature on the final *pipe's* boundary edges afterward is unreliable — pipe edges mix in the cross-sectional circle's own curvature; always validate on the rail/centerline curve itself, pre-pipe.)
+6. If the corner spacing is too tight for `CreateFilletCornersCurve` to succeed (returns `None`), that's the signal the point list still has micro-segments — go back to step 1 and simplify the path further, don't lower the radius to force it to fit.
+
+**Gotcha carried over from the cover-fix work**: when re-deriving centerline points from an already-built (possibly mirrored) Brep, don't assume a vertex read via `.Vertices` is on any particular side (top/bottom) of the pipe — use the **bounding-box center** of the relevant flat/straight piece (`(bbox.Min.Z + bbox.Max.Z) / 2.0`) to get the true centerline Z robustly regardless of which side the vertex happens to sit on for a given (possibly mirror-reflected) bar; this was mixed up once (added the bar radius in the wrong direction for the mirrored C10) and caught only by comparing C8/C10's post-fix bounding boxes and finding them asymmetric when they should have matched.

context-migration/memory/feedback_material_table_text_alignment.md

@@ -0,0 +1,11 @@
+---
+name: feedback-material-table-text-alignment
+description: Rebar material table DXF text rule — left-align every text in its cell, starting 200 from the cell's left border
+metadata:
+  type: feedback
+---
+
+In the 철근재료표 DXF (`261006_철근재료표*.dxf`), every text inside a table box must be LEFT-aligned (TEXT 72=0, 73=2 vertical middle), with its start point 200 mm to the right of that cell's left border (cell left = nearest vertical TABL-LIN line left of the text that spans the text's row; merged cells are handled automatically because missing lines mean no border). Title, subtitle and the ※ notes below the table stay as they are.
+
+**Why:** user request 2026-10-06 ("각각의 표박스 왼쪽에서 200을 띄우고 거기부터 텍스트를 왼쪽에 맞춰서 정렬"); the first version had all text centered.
+**How to apply:** script `leftalign.ps1` logic = parse LINE/TEXT from the cp949 R12 DXF (CRLF), set group 10/11 x = left+200 and 72=0, write a NEW file `…_좌측정렬.dxf` (don't overwrite the source). Result 2026-10-06: 353 texts moved, 0 overflow, 13 outside-table texts untouched. The `.dwg` is NOT regenerated automatically (needs CAD conversion). See [[project-p1-final-model-state-261006]].

context-migration/memory/feedback_rebar_table_shape_check.md

@@ -0,0 +1,26 @@
+---
+name: feedback-rebar-table-shape-check
+description: "철근 형상은 교량·재료표마다 다르다 — 수정 전 매번 해당 교량의 재료표(A·B·C·J·L)와 도면 형상을 직접 확인. 재료표 L 은 직선 치수 합(굽힘 보정 없음)이라 모델 중심선 길이에 억지로 맞추지 않는다"
+metadata:
+  node_type: memory
+  type: feedback
+---
+
+철근 형상은 **재료표마다·교량마다 다르다.** 한 교량(운곡교 B9 등)에서 정한 해석을 다른 교량에 그대로 쓰지 말고, 수정 전에 그 교량의 재료표 행(형식·직경·A·B·C·J·L)과 철근 상세 형상 그림을 확인한다.
+
+**재료표 L 은 직선(외곽) 치수의 단순 합**이다 (예: 옥성 B9 a 567 + 2×b 1,998 + 2×c 100 = 4,763; 산외 B7 A 2,218 + 2×C 100 = 2,418). 모델 중심선 길이는 90° 굽힘 1개당 약 0.43R 만큼 짧은 것이 정상이므로 **중심선 길이를 L 에 맞추려고 연장을 늘리면 도면(c·A)에서 벗어난다.** 비교는 a·b·c 치수(갈고리 곧은 구간 + 굽힘 반지름 = c)로 한다.
+
+**Why:** 2026-10-26 산외 B9·B10 연장, 옥성 B9 연장, 산외 B7 끝 이동을 L 맞춤·추론으로 수정했다가 사용자가 재료표를 보여 주며 지적 → 수정2 모델이 이미 도면 A·C 와 일치해 수정3 폐기(엑셀 R-10~R-12 취소).
+**How to apply:** 형상 수정 전에 재료표 스크린샷·DXF 행으로 A·C 와 모델을 대조하고, 일치하면 수정하지 않는다. 산외교 B7 은 기초 상·하부 철근을 잡아주는 ㄷ철근(A 2,218 = 바깥 주철근 안쪽 면 접촉 위치 167.5/2385.5), 옥성교 B9 는 ㄷ철근이 J 로 겹치는 서로 마주보는 ㄷ자 철근(사용자 확인 2026-10-26: 산외 도면 스크린샷을 보며 설명했고 '옥성교는 B9 가 맞다'고 재확인). 옥성 B9 의 마주보는 배치·J 겹침이 모델에 있는지는 미확인. [[feedback-footing-rebar-cover-rule]]
+
+**2026-10-26 후속**: 도면 상세 행의 치수는 `L = a+b+c+d` 이고 c 는 **호 길이**(호 각도 = c ÷ r), d 는 호 뒤 곧은 구간이다 (옥성 P5 r60 c141 d80 → 134.65°, Ramp-A P3 r60 c141 d100, P3-1 r135 c165 d150 → 70°). 도면에 r·c·d 가 있으면 그대로 따르고 없을 때만 KDS 최소값 + 임의 연장(사용자 지시).
+- 굽힘 R 보정 완료: 4교 모든 굽힘이 KDS 최소 중심선 R 이상(운곡 P3·옥성 C9/C13·Ramp-A C12 포함). 형상이 복잡한 곡선은 'CreatePipe' 기본 설정이 실패하므로 fitRail=False 등 대체 설정 필요(`Code/검토수정/스크립트/c1_fix_remaining.py`).
+- 최신 모델: 운곡 수정7_20261026, 산외 수정2_20261026, 옥성 수정5_20261026, Ramp-A 수정3_20261026 (검토파일 아래 각 교량 폴더). 옥성 B9 의 a=586~548 범위·J 겹침 규칙은 미확인.
+
+**2026-10-26 Ramp-A P3-2**: 도면(4) '철근망 최하단 저부철근 상세도'의 P3-2(H16)는 바닥 수평 + 다리 수직 ㄷ자(다리 200 은 P1-2 에 용접)인데 모델은 다리가 약 13.4° 기울고 R135 두 호로 이어진 깔때기였다(사용자 지적 "그냥 ㄷ자철근"). 바닥 W 2,050 + 다리 2×646 = 재료표 L 3,342, 모서리 R24(도면에 없어 KDS H16 최소)로 30본 재작성 → `ramp-A G5_수정4_20261026.3dm`(Ramp-A 최신). 수정 전·후 Rhino 캡처는 엑셀 '공통 문제 상세(이미지)' 맨 아래 행(F열 전, M열 후). 엑셀의 '수정 후 캡처' J~M열 이미지는 `검토파일\수정후_캡처\` PNG + `Code\검토수정\스크립트\make_after_images.py`·`add_수정후_이미지_xlsx.py`·`c1_capture.py`.
+
+**2026-10-26 갈고리 직선 b**: 도면 갈고리 직선(P5·P3·P3-1)의 **b 는 다리선에서 호 시작점까지**다. 기존 모델은 b 를 꺾임 꼭짓점까지 재서 R24×tan67.5°=57.9 짧았고, 호만 R60 으로 바꾼 1차 수정(R-15)이 이를 놓쳤다 → R-17 로 호·끝을 57.9 평행 이동(옥성 수정6, Ramp-A 수정5). **형상 수정 후에는 a·b·c·d 전부 도면과 대조하고 콘크리트 안/밖(피복)까지 재측정한다.** Ramp-A P3-1 은 도면 치수(b 2,137, r135·C 곡선 165·D 150 = 70° 아래로 걸리는 갈고리, 사용자 확인 2026-10-27)대로 만들면 말뚝 밖으로 나간다 — 말뚝은 PL01 r1175(z 32752~40252)·PL02 r1250(~45452)·기둥 r1000(~57452)으로 구간별 반경이 다르고, 기존 모델은 b·갈고리가 작아 안쪽이었다(최소 중심 피복 106.5). 수정5 에서는 PL01 26본 중심이 밖(-71.6), PL02 22본 표면 돌출. 도면 오류로 기록(엑셀 M-9), 모델은 도면 치수 유지. 콘크리트 측정은 말뚝 포함 구간별 반경으로 한다(말뚝 솔리드 빠뜨리면 오판). 측정 스크립트 `Code\검토수정\스크립트\c1_radial_cover.py`.
+
+**2026-10-27 Ramp-A P3-1 갈고리**: 도면 r135·c165·d150 은 호 70°라 갈고리가 바깥으로 뻗고 말뚝 밖으로 나가며 P3(r60·c141, 134.65°)와 같은 그림인데 각도가 다르다. 사용자 판단: 도면 r135 각도가 이상함 → 엑셀에 체크하고 철근은 P3 각도를 따른다(r 70.21, c165, d150, 수정6). 도면 값이 형상 그림·인접 마크와 모순되면 임의로 고치지 말고 도면 확인 필요로 기록한 뒤 사용자 결정에 따른다.
+
+**강종별 상세 (2026-10-27)**: 도면 '이형 철근 상세'는 SD400·SD500 두 벌이고 같은 형식 번호라도 모양이 다르다(산외: SD400 I=ㄷ자(a+b), SD500 I=직선). 재료표 행이 어느 강종 표에 있는지 보고 같은 강종 상세에서 형상을 확인한다. 산외 B1·B4(SD500 I)는 직선이 맞음(엑셀 R-20).

context-migration/memory/feedback_review_other_bridges_scope.md

@@ -0,0 +1,14 @@
+---
+name: review-other-bridges-scope
+description: "운곡교 다음 교량 3개 검토 범위 - 모델↔도면만 대조, 도면 내부 오류는 따로 저장만"
+metadata:
+  node_type: memory
+  type: feedback
+  originSessionId: f46b47bc-9105-4079-9b62-fcbee31b26ae
+  modified: 2026-10-19T01:12:17.441Z
+---
+
+운곡교P1과 같은 방식으로 다른 교량 3개를 검토한다. 범위는 **모델↔도면 대조만**. 도면 내부 오류(도면끼리 불일치)는 보고하지 않고 교량별 폴더의 `도면내부_오류_보관.md`에 따로 저장해 두며, 사용자가 요청할 때 꺼낸다.
+
+**Why:** 사용자가 지금은 모델이 도면대로 만들어졌는지만 보려 하고, 도면 오류는 필요할 때 따로 논의하려 함.
+**How to apply:** 새 교량 검토 시 대조표(도면↔모델)에는 도면 내부 오류를 섞지 말고 보관 파일에만 기록. 운곡교 보관본: D:\★Pier 자료\심수석님 검토 파일\검토_운곡교P1\도면내부_오류_보관.md. 관련: [[feedback_ungokgyo_review_workflow]], [[project_ungokgyo_p1]].

context-migration/memory/feedback_rhino_connection_check.md

@@ -0,0 +1,15 @@
+---
+name: feedback-rhino-connection-check
+description: "is_server_available checks the Grasshopper socket server, not Rhino — use get_scene_info or get_layers to verify the Rhino connection instead"
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: 63928af6-71fe-4cd0-ac03-4b5401fe375c
+  modified: 2026-09-21T23:41:14.343Z
+---
+
+`mcp__rhino__is_server_available` checks whether the **Grasshopper** socket server is running (see `rhino_mcp/rhino_mcp/grasshopper_tools.py:280` — `GrasshopperTools.is_server_available`), not the Rhino RhinoScript connection. It returns `False` whenever Grasshopper itself isn't open, even when Rhino (`rhino_mcp_client.py`) is running fine and fully connected.
+
+**Why:** user reported "라이노 연결이 안 된다" (Rhino won't connect) after confirming `rhino_mcp_client.py` was on; `is_server_available` returned `False` but `get_scene_info` succeeded immediately after — the tool name is misleading (sounds like a general Rhino MCP check) but is Grasshopper-specific.
+
+**How to apply:** to verify the Rhino connection (not Grasshopper), call `get_scene_info` or `get_layers` directly instead of `is_server_available`. Only use `is_server_available` when actually checking Grasshopper's server.

context-migration/memory/feedback_section_drawing_rules.md

@@ -0,0 +1,24 @@
+---
+name: feedback-section-drawing-rules
+description: Standing Rhino/Grasshopper conventions for extracting sections and laying out 2D drawings — numbered method options plus always-follow layout/dimension/deletion rules
+metadata: 
+  node_type: memory
+  type: feedback
+  originSessionId: 3f00c5a2-89d3-4ff6-bce0-294eebc0a639
+  modified: 2026-09-16T07:01:14.424Z
+---
+
+**Section extraction method convention** — when the user asks for a section by number, it means:
+- **"1번"** = manual method — extract curves via BrepPlane, place dimensions/labels by hand into a manually-built 2D box/frame
+- **"2번"** = Rhino native ClippingSections + ClippingDrawings — live-linked to the 3D model, refreshed via `UpdateClippingDrawings`
+- **"3번"** = a ClippingPlane object cutting the section visually directly on the 3D model (no 2D curve extraction)
+
+**Always-follow rules for section/drawing work:**
+- Sections always go in the **middle cell** of a 3-split A1 frame box.
+- ClippingDrawings' auto-generated black name text dots (e.g. "AA", "BB") always get moved **outside** the drawing box.
+- **Always ask the user before deleting any object in Rhino.**
+- Two-tier dimension convention: the 2nd-tier (outer/total) dimension line sits 1000 units away from the 1st tier; only the leg segment below the arrow extends (add a stub manually below the bottom point, length = 1500, i.e. 15 at 1:1 print scale); arrow position and the length protruding above always stay as they currently are — never change those.
+
+**Why:** these are standing preferences the user set for prior P1 section-drawing work (captured in [[reference-notes-md]]) so that repeated requests ("2번으로 뽑아줘" etc.) and drawing layout stay consistent without re-explaining each time.
+
+**How to apply:** apply these rules by default on any Rhino section/drawing task in this project (and likely future pier projects per [[project-pyeonggang1-modeling-standard]]), and treat "before deleting, always ask" as a hard rule regardless of project.

context-migration/memory/feedback_ungokgyo_review_workflow.md

@@ -0,0 +1,22 @@
+---
+name: feedback-ungokgyo-review-workflow
+description: "운곡교P1 철근 검토 작업 규칙 — 4자 대조표, 불일치 분류·색 구분(도면↔모델 최우선), 내면반지름은 도면에 없음, 저장 위치, 측정 오류 교훈"
+metadata:
+  node_type: memory
+  type: feedback
+  originSessionId: 53f62976-8c81-4fad-b764-69ad691f1791
+  modified: 2026-10-15T03:36:38.632Z
+---
+
+운곡교P1 철근을 재료표 순서대로 하나씩 사용자와 같이 검토. 결과는 나중에 **"정면도·단면도·모델·재료표가 일치하는지 / 무엇이 다른지" 표 보고서**로 만들 재료. 현재 상태와 결과는 [[project-ungokgyo-p1]].
+
+**How to apply**
+- **분류·색 규칙 (사용자 지시):** 최우선은 "도면과 모델의 일치". 불일치는 반드시 두 종류로 나눠 따로 작업·색 구분 — 도면 내부 불일치(노랑 ACI 2, 도면끼리 다름, 모델이 따른 쪽 명시) / 도면↔모델 불일치(주황 ACI 30, 도면이 서로 같거나 정보 없는데 모델이 다름) / 기준(KDS)↔모델 / 일치(초록 ACI 3) / 미확인(회색). 도면끼리 다르면 도면 내부로 분류.
+- 모든 결과는 `D:\★Pier 자료\심수석님 검토 파일\검토_운곡교P1\` 에 저장: `대조표_C1-C16_도면모델_분류.xlsx`(마크마다 행 추가, 못 본 칸 "미확인", 도면에 정보 없으면 "해당 없음"), `검토기록_최종.md`, `1/2/3_도면검토_색구분_*.dxf`(+PNG), `스크립트\`, `추출데이터\`. 불필요한 이전판은 정리하되 사용자가 파일을 열어 둔 경우(삭제 실패/덮어쓰기 실패) 알려 줄 것.
+- 도면에는 **내면반지름이 그려져 있지 않음** → KDS 24 14 21 최소값(D19↑ 내면지름 3.5db) 충족 여부만 확인. 재료표 L 은 각진 치수(a+b+c)라 모델 중심선은 굽힘 때문에 약 42mm 짧은 게 정상.
+- 띠철근 간격(E-01)은 계산서 확인 사항. 피복은 도면값(운곡교 상면 100) 우선. 설명은 쉬운 말로, 숫자는 도면 좌표인지 EL 인지 명시, 답변 끝에 사용한 경로 표기([[feedback-always-show-paths]]).
+- 한글이 든 파이썬은 stdin heredoc 로 넘기면 깨지므로 Write 도구 또는 `cat > file` 후 실행.
+
+**Why:** 사용자가 보고서 표를 만들 예정이라 근거·정정 이력까지 필요하고, 도면 정정 요청(도면 내부)과 모델 수정(도면↔모델)을 분리해야 함.
+
+**교훈(내 실수):** (1) 정면도에서 "가장 낮은 상면"을 y=19659.3 으로 잘못 잡아 143.7mm 불일치를 보고했다가 정정 — 기준면은 전체 x 범위의 계단을 먼저 나열한 뒤 정할 것(최저는 왼쪽 끝 y=19515.6). (2) 레이어 이름만 보고 프로젝트를 "대호지교"로 추측했다가 정정 — 프로젝트명은 확인된 것만 말할 것.

context-migration/memory/feedback_ungokgyo_unrecognized_items_record_only.md

@@ -0,0 +1,15 @@
+---
+name: feedback-ungokgyo-unrecognized-items-record-only
+description: "운곡교P1 검토 단계 규칙 — 사용자가 '내가 인식 못 한 부분'을 찾는 중이므로, 지적받은 오류는 모델·표를 바꾸지 말고 기록만 한다 (2026-10-16)"
+metadata:
+  node_type: memory
+  type: feedback
+  originSessionId: a82a1be1-cf11-4d33-988f-0c35b9b726d4
+  modified: 2026-10-16T05:32:12.038Z
+---
+
+사용자가 운곡교 P1 모델·대조표를 검토하며 **내가 도면을 인식하지 못한 부분을 찾아내는 단계**다. 오류를 지적하면(예: B12 수량 34본, B10 형상 오류) **바로 모델이나 엑셀·DXF·표식을 고치지 말고 "기록만" 한다.** 올바른 형상·값을 되묻지도 않는다.
+
+**Why:** 사용자가 B10 형상 오류를 알려주며 내가 "무엇이 올바른 형상이냐"고 되물은 것에 대해 "지금은 너가 인식 못하는 부분을 찾는 거라서 바꾸지 말고 그냥 기록만 해둬"라고 정정했다. 목적은 나의 인식 한계(간소화 도면 등)를 모으는 것이고, 수정은 별도 지시가 있을 때 한다.
+
+**How to apply:** 지적 → 메모리 + `검토_운곡교P1\검토기록_최종.md`/README 에 "내가 인식 못 한 부분 / 설계자 판단 필요"로 기록하고 끝낸다. 수정·재생성·되묻기는 사용자가 명시할 때만. 기록 사례: [[project-ungokgyo-b12-34-correct]], [[project-ungokgyo-b10-shape-error]].

context-migration/memory/project_next_session_models_20261027.md

@@ -0,0 +1,38 @@
+---
+name: project-next-session-models-20261027
+description: "2026-10-26 종료 시점 인수인계 — 4개교 모델 수정 현황(최신 파일), 엑셀 양쪽 갱신 규칙, 미해결·다음 할 일(산외 J 겹침 확대, 옥성 B9, P3-1 도면 r 불일치 등)"
+metadata:
+  node_type: memory
+  type: project
+---
+
+**최신 모델**(모두 `D:\★Pier 자료\프로그램\Pier_T\검토파일\` 아래): 운곡 `철근 모델랑 운곡교P1_바이브코딩\운곡교p1_수정7_20261026.3dm` / 산외 `검토_산외교P1\산외교P1 G5_수정2_20261026.3dm`(승인된 최신) → **J 겹침 `수정5_20261027`(코핑 수정4 + 기초 B2·B5·B8, 최신, 엑셀 R-19)** / 옥성 `검토_옥성교P1\옥성교P1_G5_수정7_20261027.3dm`(J 겹침, R-22) / Ramp-A `Ramp-A교P1\ramp-A G5_수정5_20261026.3dm`. 폐기: 운곡 수정2·4·5, 산외 수정3, 옥성 수정3. 엑셀 `4개교_공통사항_종합.xlsx`(원본 `심수석님 검토 파일\` + 복사본 `Pier_T\검토파일\` 양쪽, 해시 `9af4a341…`)에 '수정 내역' R-1~R-22 등 13시트('형상 일람(모델)' 추가), 이미지 75개. 스크립트·결과 `Code\검토수정\`.
+
+**내일 할 일**
+1. **산외 J 겹침 시험(수정4) 승인 확인** — C7~C9(II)·C10(III)·C12(XII)·C13(VIII)를 ⊓뚜껑+⊔바닥/좌우 ㄷ 두 조각, 겹침 J 660(대호지교 방식)으로 바꿈. 맞으면 운곡(C9~C13)·옥성(C8~C17, c/j 표기)·Ramp-A(C7~C14)로 확대(마크별 재료표·도면 형상 규칙 먼저 읽기). 재료표 III·XII 의 L=2A+2B+4J 와 도면 형상(겹침 1곳×2) 차이는 설계자 확인. 엑셀·OPEN·메모리에는 아직 미반영.
+2. **옥성 B9**: 도면 a=586~548(범위)·'ㄷ철근이 J 로 겹치는 서로 마주보는 ㄷ자'(사용자) — 어느 방향·규칙으로 a 가 변하는지 도면 위치 확인 필요(미수정).
+3. **Ramp-A P3-1**: 사용자 의견(2026-10-27) — 도면 r135 각도가 이상해 보임. 엑셀 M-9 에 '도면 r 확인 필요' 체크, 철근은 P3 각도(134.65°)를 따라 C 곡선 165·D 150 유지 → r 70.21 로 수정 완료(`ramp-A G5_수정6_20261026.3dm`, 말뚝 안, 증거 엑셀 25행 + R-18). 설계자에게 도면 r135 확인만 남음.
+4. 설계자 확인 대기: 운곡 B9 갈고리(임시 R24·연장 100), 산외 B7, 겹침 J(C-3), 산외 B8·옥성 B10~B12 겹침.
+
+**규칙**: 엑셀은 양쪽 같이 갱신(백업·해시 확인) [[feedback-excel-both-copies]]. 재료표·도면 형상을 매번 확인, 형상 수정 후 a·b·c·d·콘크리트 피복까지 재측정 [[feedback-rebar-table-shape-check]]. 기초 철근 규칙 [[feedback-footing-rebar-cover-rule]]. Rhino 연결: 일반 창으로 열면 MCP 미연결, 작업은 `runner.run_job` 전용 Rhino 로 실행(창을 닫으면 작업이 끊김).
+
+**Why:** 사용자 "여기까지 저장, 내일 다시 작업". **How to apply:** 새 세션 시작 시 이 파일 + OPEN #39 먼저 읽고, 응답 끝에 쓴 경로를 적는다 ([[feedback-always-show-paths]]).
+
+4. **산외 J 겹침(2026-10-27)**: 사용자 요청 '기초도 코핑처럼' → 기초 B2·B5(IV, J1000)·B8(V, J570) 2조각 겹침, 파일 `검토_산외교P1\산외교P1 G5_수정5_20261027.3dm`, 엑셀 R-19·공통 상세 26행. 재료표 L 의 4J vs 모델 2J(III/XII/V) 설계자 확인, 코핑 기둥 P2 후프 J380·다른 3개 교량 J 는 미작업(사용자 승인 후 확장).
+
+5. **옥성 J 겹침(2026-10-27)**: 기초 B1~B8(j1530/1070)·B11·B12(j560), 코핑 C1~C6(j1510) 2조각 겹침 완료(수정7, R-22). 미작업: C7(j1050 경사), 루프형 C14·C16(j550×4)·B10(j560×6), C15·C17(모델 직선 vs 도면 갈고리 불일치). 운곡은 재료표 J 값 없음, Ramp-A 는 C14(j290)만·루프형 보류.
+6. **형상 점검**: 산외 B1·B4 는 SD500 형식 I=직선이 맞음(R-20). 4개교 모델 형상 일람(12장, 시트 '형상 일람(모델)', R-21)만 작성 — 도면 형식별 상세와 마크별 대조 이미지는 사용자 요청(2026-10-27)으로 진행 예정(운곡 C16 형식 II ㄴ자 등 후보).
+
+7. (2026-10-27) 옥성 도면↔모델 마크별 대조 이미지 완료: `검토파일\수정후_캡처\도면대조_옥성_{코핑,기초}.png` (엑셀 '형상 일람(모델)' 하단, R-23, 스크립트 make_legend_compare_okseong.py). 불일치 C15·C17(도면 양끝 갈고리, 모델 직선), C14·C16 도면 그림 없음. 운곡·산외·Ramp-A 마크별 대조는 아직 미작성. 겹침 보류 항목(C7·루프·B10 등)은 사용자 지시로 당분간 그대로 둠.
+
+8. (2026-10-27) 옥성 C9·C11·C13 오각형 스터럽 c=630 겹침 → `옥성교P1_G5_수정8_20261027.3dm` (수정7 기반, 엑셀 R-24). 겹침 위치=긴 세로 변 위쪽 끝에서 아래로 630. 도면 c=630(겹침), c1=변하는 길이. 미반영: 옥성 C15·C17 양끝 갈고리 형상(r80,b188,c140), 운곡·산외·Ramp-A 마크별 도면 대조, 4개교 같은 형식 적용. Rhino MCP 연결 끊김(WinError 10054) 상태였음.
+
+9. (2026-10-27 저녁) 옥성 C15·C17 양끝 갈고리 → `옥성교P1_G5_수정9_20261027.3dm` (수정8 기반, 엑셀 R-25, 이미지 옥성교_타이C15C17_갈고리_전후.png). 갈고리 r80, 호 188(=134.65°), 꼬리 140, L = a+2×(188+140)(+j550) 재료표 역산 일치. **가정**: 방향=단면 중심 쪽(z 일정 평면), C17 j550=가운데 → 내일 도면 평면·단면으로 확인. **현재 최신 옥성 = 수정9**.
+내일 이어서: (a) C15·C17 갈고리 방향 확인, (b) 사각형 j(C8·C10·C12·B10) 및 운곡·산외·Ramp-A 같은 형식(오각형 c겹침, 사각형 j) 재료표 확인 후 적용, (c) 운곡·산외·Ramp-A 마크별 도면 대조 이미지(옥성은 도면대조_옥성_코핑/기초.png 완료), (d) C11 재료표 길이(7,992) 불일치 확인, (e) 보류: C7·C14·C16·B10 겹침(사용자: 일단 둠). Rhino MCP 연결 끊김이면 headless runner(Code\교각모델링앱\runner.py)로 작업.
+
+10. (2026-10-28) 엑셀 백업 정리(날짜별 1개, 나머지 `백업_중간본\`) + 앞으로 하루 1백업 [[feedback-excel-backup-one-per-day]]. 산외 도면↔모델 마크별 대조 이미지 3장 완료(도면대조_산외_{코핑,기초,기둥}.png, R-26): 형식 불일치 없음. 운곡·Ramp-A 대조 이미지는 형식별 상세 그림이 PNG에 없고 DXF 안에 있어 DXF 렌더·추출 필요(미작성). 옥성 C15·C17 갈고리 방향 확인, 사각형 j(C8·C10·C12·B10) 적용은 계속 대기. B10: 표 L 41,152 = 4×9,448 + 6×560 로 일치(6곳 겹침, 위치 미정).
+
+11. (2026-10-28) DXF 기준 마크별 대조 이미지: 운곡(3.dxf, 도면대조_운곡_{코핑,기초,기둥}, R-27), Ramp-A(교각(3).dxf, 도면대조_RampA_{코핑,기둥말뚝}, R-28) 완료 + 산외(R-26)·옥성(R-23). 4개교 형식 불일치 없음(옥성 C15·C17 제외, 수정9 로 반영). 운곡 C16 형식 II=ㄴ자는 도면과 일치(의심 해소). **도면↔도면 오류 D-10(운곡)**: 형식 XII·XIII·X·XVI·VI 그림엔 j 가 있으나 재료표 J 열이 비어 있어 겹침 미반영(교량별 항목 합본). DXF 렌더 도구 `render_dxf.py`. 산외·옥성 대조 이미지의 도면 그림은 색구분 DXF 에서 낸 PNG 에서 잘랐으므로 필요 시 원본 DXF 렌더로 교체. 남은 일: 옥성 C15·C17 갈고리 방향 확인, 사각형 j(C8·C10·C12·B10), 산외·옥성 도면 그림 DXF 원본 재추출, 겹침 보류분.
+
+12. (2026-10-28 오후) 산외·옥성 대조 이미지를 원본 DXF 렌더 기준으로 교체(도면_이형철근상세_DXF렌더.png / 도면_철근상세_DXF렌더.png 저장). 옥성 도면 오류 기록: D-11 C15·C17 갈고리 방향 도면 미표기(모델 수정9 는 단면 중심 쪽·z 일정 평면 **가정** 유지), D-12 B10 j560×6 vs 그림 2곳, D-13 C14·C16 j550×4 형상 그림 없음 — 모두 설계자 확인 대기, 모델 미수정. 옥성 DXF 는 렌더가 10분 이상 걸림(옥성교P1.dxf: 구조도(1)~(4) 4장, 철근상세는 x 688000~729000, y 315500~345500). 실수 기록: 엑셀 이미지 교체 스크립트가 '산외 코핑'으로 시작하는 제목 6개를 다 바꿔 형상일람 산외 3장이 덮였다가 복원(fix_sanoe_overwrite_xlsx.py) — 이미지 교체 시 제목 접두어가 겹치지 않는지 먼저 확인할 것.
+남은 일: 설계자 확인(D-10 운곡 j, D-11~D-13 옥성), 겹침 보류분(C7·C14·C16·B10·Ramp-A C14), 산외 P2 후프 J380, 4개교 같은 형식 j 적용은 도면 값 확정 후.

context-migration/memory/project_next_session_p4_live_and_review_files.md

@@ -0,0 +1,20 @@
+---
+name: project-next-session-p4-live-and-review-files
+description: "2026-10-22 종료 시점 인수인계 — 운곡교 P4를 열린 Rhino에 직접 반영(게이트 승인 전), 검토 자료 Pier_T\검토파일로 복사, Rhino 자동연결 바로가기"
+metadata:
+  node_type: memory
+  type: project
+---
+
+**내일 이어서 할 일**
+1. 운곡교 P4(OPEN #37): 열린 Rhino에 만든 모델은 검사기만 돌렸고 **정식 승인(G1~G5)은 안 했다**. 앱을 재시작해 P4를 읽기 도구로 다시 만들고 B11·C13 등 계획된 FAIL 4건 선택·반영 → 검토 요약 재확정 → 일괄 승인 → 보고서 초안.
+2. Rhino 자동 연결이 실제로 되는지 확인 — 바탕화면 `Rhino 8 (MCP 자동연결)` 바로가기로 열어 `get_scene_info` 응답 확인. 안 되면 Rhino Options > General 의 시작 명령 칸에 `-_RunPythonScript "D:\Rhino-MCP\rhino-mcp-main\rhino_mcp\rhino_mcp_client.py"` 입력(이 칸을 저장하면 settings-Scheme__Default.xml 의 바뀐 키를 기록해 둘 것).
+3. 10-19 인수인계([[project-next-session-rampa-todo]]) Ramp-A교 P1 재점검은 아직 안 함.
+
+**오늘 한 일**
+- P4 열린 Rhino 반영: 엔진 스크립트가 Python3라 IronPython 2.7인 `execute_rhino_code`로 못 돌림 → `runner.JOB_PY`(활성 문서용, Modified 줄 제거)를 `Rhino.RhinoApp.RunScript('-_RunPythonScript "<job.py>"')`로 실행. 작업 폴더 `C:\Users\User\AppData\Local\PierApp\jobs\live_p4_20261022_163050`. 3,406객체. 열린 문서 검사: G1 171/171, G2 42/42, G3 71/73, G4 110/116, G5 183/183, FAIL 8건 전부 planned_fail(계획 외 0). display.py가 P4-CP·P4-FT 숨김. 긴 검사 호출은 MCP 소켓이 타임아웃(작업은 계속 진행) → result.json 생길 때까지 기다릴 것.
+- 저장본: `Code\교각모델링앱\data\운곡교P4\runs\live\P4_열린Rhino반영_2026-10-22.3dm` (정식 게이트 산출물 아님).
+- 검토 자료 복사(원본 유지): `D:\★Pier 자료\심수석님 검토 파일\` → `Pier_T\검토파일\` (213파일, 3dm 9·xlsx 11, zip 제외). 정본을 어느 쪽으로 할지 미정.
+- 자동연결: `Pier_T\Rhino_MCP_연결실행.bat`, 바탕화면·시작메뉴 바로가기 `Rhino 8 (MCP 자동연결)`. 기존 Rhino 8 바로가기(공용)는 안 건드림. 실제 기동 시험은 안 함.
+
+**Why:** 사용자가 "여기까지 저장, 내일 다시 작업" 지시. **How to apply:** 새 세션 시작 시 이 파일 + OPEN #37 먼저 읽고, 응답 끝에 쓴 경로를 적는다 ([[feedback-always-show-paths]]).

context-migration/memory/project_next_session_rampa_todo.md

@@ -0,0 +1,18 @@
+---
+name: project-next-session-rampa-todo
+description: "2026-10-19 종료 시점 인수인계 - 내일 Ramp-A교 P1 을 산외·옥성교처럼 위치·CTC·피복·재료표 전체 재점검, 운곡교 M-8/M-9 도 점(원) 기준 재확인"
+metadata:
+  node_type: memory
+  type: project
+---
+
+**내일 할 일 (사용자: "내일 와서 Ramp 를 할 거야")** Ramp-A교 P1(폴더 `D:\★Pier 자료\심수석님 검토 파일\Ramp-A교P1\`, 모델 `ramp-A G5.3dm`, 도면 `Ramp-A교 P1 교각(1)~(4).dxf`)을 산외·옥성교와 같은 순서로 전체 재점검. 사용자가 라이노에 Ramp-A 모델을 연결해 줄 것.
+1. 재료표 처음부터 (DXF 재판독 → 본수·길이·형상·표 산술, 옥성교용 `review_pipeline\dots_method\ok_rerun1~3.py` 를 Ramp-A 좌표·열 위치로 변형). 커플러 표 대조도 (115개).
+2. 위치·CTC·피복 — **단면 점(원) 기준** (`review_pipeline\dots_method\README_점대조방법.md`, swdots.py). 말뚝 기초라 기초 B 철근 피복 해당 없음, 코핑·기둥·말뚝 위주.
+3. 결과를 엑셀 ⑤ 시트(checks)·M-n 으로 반영 (`ra_cfg.py` → `make_review_xlsx.py`), 도면 색구분 DXF·.3dm 표식은 요청 시.
+4. 운곡교 M-8·M-9 도 점(원) 기준으로 재확인 (산외·옥성에서는 모델이 도면 점과 일치했음 → 사용자 "간섭 회피는 오류" 판단과 상충, 사용자에게 이미 보고함).
+
+**오늘(2026-10-19) 완료 상태** 산외교: M-1~M-10, 위치·CTC 전부 일치(M-10 신규 코핑 스터럽 +26.5/-27.5), 코핑 C1~C6 높이·C14·C15·S 미확인. 옥성교: M-1~M-12(M-12 B12 +19.0 신규), 재료표 재실행 완료(P3·P4 b 연장, P5 c·d 비고 보강), 코핑 A-A C7 13점 미확인, 커플러 표 미대조. 4개교 종합 엑셀 42항목. 산외·옥성 .3dm 에 M-9~M-12 표식 미삽입.
+**위치** 스크립트·README `D:\Rhino-MCP\rhino-mcp-main\review_pipeline\dots_method\`, 각 교 `검토기록_최종.md`, 종합 `D:\★Pier 자료\심수석님 검토 파일\4개교_공통사항_종합.xlsx`.
+
+**Why:** 같은 방법을 다른 교량에 일관되게 적용하려고. **How to apply:** 새 세션 시작 시 이 파일 + [[project-ungokgyo-m8-m9-cause]] 먼저 읽기.

context-migration/memory/project_okseonggyo_p1_review.md

@@ -0,0 +1,21 @@
+---
+name: project-okseonggyo-p1-review
+description: "옥성교 P1 도면↔모델 검토 1차 완료(2026-10-19) - 산출물, 코드 M-1~M-8, V2 엑셀 형식·이미지 파이프라인, 다음은 산외교 엑셀 재작성·Ramp-A교"
+metadata:
+  node_type: memory
+  type: project
+  originSessionId: f46b47bc-9105-4079-9b62-fcbee31b26ae
+  modified: 2026-10-19T02:38:05.531Z
+---
+
+폴더 `D:\★Pier 자료\심수석님 검토 파일\검토_옥성교P1\`: `대조표_옥성교P1_도면모델_분류_V2.xlsx`(운곡교 V2 형식, 캡처 8장), `도면↔모델_불일치_시각자료\`, `검토기록_최종.md`, `도면내부_오류_보관.md`, 표식 모델 `옥성교P1_G5_대조코드표식.3dm`(원본 불변), 도면 `옥성교P1.dxf`.
+
+**결과** UM(기초 조립용 철근 H22 92본) 모델 없음(M-1), j(겹침) 길이 형상 미작도(M-2, C1~C7 은 설계길이도 제외), C7 바깥 2본 형상(M-3), C8~C13 스터럽 a·c630(M-4), C14~C17(M-5), C18(M-6), 내면지름 H25/H22/H19(M-7), P3·P4 이음각도(M-8). 옥성교 재료표는 A~J 열이 없어 '철근상세'(CS-TEXT L= N= a= b= c= j=) 글자를 읽어 치수 대조. 선행 보고서는 재료표를 인식 못 해 대조 안 했음.
+
+**파이프라인(재사용)** 스크래치패드: `fastrender.py`(DXF 크롭 렌더, dark 옵션, 블록 속성 글자 포함) → `compose_new.py`(헤더/도면 패널/모델 패널/차이·도면쪽·조치 이미지) → `make_review_xlsx.py <cfg.json> <out.xlsx>`(분류 안내/① 캡처/② 전체 대조표/③ 미검토/④ 측정 근거; 도면 내부 시트 없음) ; 모델 캡처는 라이노에서 `cap.py`(`shots_ok.py`/`shots_sw.py` 형태). 모델 표식 코드는 execute_rhino_code 에 유니코드 이스케이프로 레이어명 지정.
+
+**다음** 산외교 엑셀을 같은 V2 형식으로 재작성(도면 크롭·cfg 준비됨, 모델 캡처는 산외교 모델을 라이노에 열어야 함: `shots_sw.py`) → Ramp-A교P1 (`Ramp-A교 P1 교각(1)~(4).dxf`, `ramp-A G5.3dm`). [[project-sanoegyo-p1-review]]
+
+**2026-10-19 추가** M-10 코핑 스터럽 C8~C13 상단 +22.5/하단 -22.5, M-11 C9·C11·C13 오각형 스터럽 d +33~43(C11 b +54). 3교 재료표 산술은 이상 없음. 4개교 종합은 40항목으로 재생성(M-10/M-11 개별). M-9~M-11 표식은 .3dm 에 아직 없음.
+
+**2026-10-19 점(원) 기준 재점검** 기초·기둥·코핑 B-B 단면 점은 모델과 전부 일치. 신규 M-12 (B12 +19.0, B11 은 일치). 코핑 단면 A-A 의 C7 바닥 13점 미확인. 엑셀 ⑤ 시트에 점대조 행 추가. 코핑 정면도 12.000 ↔ 평면 사각 끝은 도면 내부 후보(D-7).

context-migration/memory/project_p1_final_model_state_261006.md

@@ -0,0 +1,54 @@
+---
+name: project-p1-final-model-state-261006
+description: FINAL state of the 대호지교 P1 Rhino model as of 2026-10-06 11:xx (user declared final) — geometry, every rebar mark, decisions made, what is resolved/open; supersedes stale TODOs in project-p1-pier-structure
+metadata:
+  type: project
+---
+
+Verified by reading the live Rhino scene on 2026-10-06 (model saved 10:54; material table `261006_철근재료표.dxf/.dwg` saved 10:49-10:50; full scene JSON `261006_FINAL_scene_dump.json` + `261006_FINAL_model_detail.json` in the drawings folder `D:\★Pier 자료\클로드로 모델그리기\대호지교 P1\`). User said "지금 라이노 모델이 최종" — this is the baseline. Older details/mechanics: [[project-p1-pier-structure]]; scene-dump pointer: [[reference-final-scene-dump]].
+
+## Concrete geometry (units mm, real survey coords; model is NOT at local origin anymore)
+- Column/pile centres: A (480708784, 153831202), B (480721068, 153835457); spacing 13,000; coping axis angle atan2(4255,12284)=19.105° from world X. Midpoint = coping local origin = bbox centre of coping Brep (X 480714926.0, Y 153833329.5).
+- Piles `P1_현장타설말뚝(지중부)` Φ3000 z −28402..−342 (vol 198.34 m3 each); columns `P1_기둥(지상부)` Φ3000 z −342..7738 (57.11 m3 each). Both are plain 3-face cylinders.
+- Coping Brep `P1_두부(코핑)` 1 solid, 24 faces, 226.65 m3, 3500 wide (t=±1750), s=±12100 long, z 7738..10924. Local (s along axis): end face z 9238~10738 at s=±12100; haunch diagonal down to (±8100, 7738); flat 7738 to ±4900; inner diagonal up to (±3400, 8238); centre flat 8238. **TOP IS NOW SYMMETRIC stepped, 62 mm steps: 10924 (|s|≤3100), 10862 (3100–6200), 10800 (6200–9300), 10738 (9300–12100)** — fixed 2026-10-06 (old +1550-shifted top is gone; the 261006 coping backup layer is EMPTY, backup objects were deleted).
+- Coping layer also holds 2 stray LineCurves (axis/construction lines, one at z −144462 spanning X 0..480522175, one at z −28402) — leftovers, harmless, ask before deleting.
+
+## Rebar marks in the final scene (doc-level objects)
+All instance marks sit on layers `P1_두부_주철근_1CYCLE::Cn_Hxx` / `_2CYCLE::Cn_Hxx`; layer colour dark red (104,0,25) for C1~C18, magenta C26, blue (0,0,255) C19~C25 (all ColorFromLayer / ColorFromParent chain). Counts/lengths below = material table (re-measured from model; table lengths agree with model to <1% — C12~C18 area-estimate ~1–2% under, pipe-fillet approximation, trust the DXF).
+- C1 IV H25 ×14 (L 26.554, A 23.960/B 1.297); C2, C3 II H25 ×14 (10.030 each); C4~C7 I H25 ×13 (9.930, 2CYCLE; C4/C6 z~10605–10630, C5/C7 z~10505–10530); C8, C10 VII H25 ×14 (A630/B4167/C3159/D2331, X1 159°/X2 162°, L 10.287, open uncapped pipes, standalone — no 2CYCLE counterpart by design); C9 I H29 ×14 (8.539); C11 I H25 ×13 (8.339, centred, z~8345–8371).
+- C12/C18 V H22 ×76 each (19 stations × box-defs 1005/1250, L 7.602); C13/C17 ×52 (8.890); C14/C16 ×40 (8.515); C15 ×104 (8.043). Structure: mark idef → station idefs → box-defs (`C12_1250_01`…, C13's carry `_r3` suffix) → leaf pipes. **All 224 box-defs: lid leg C=510, base leg = full box height, lap 510, no off-axis stubs, all ColorFromParent.** Box stirrups sit ON main-bar centerlines (centre cover 120), so table A/B = original −47 — user accepted (original table wraps outside).
+- C19/C21/C23 VI H16 hoops ×4/5/6, w=±1630, ends ON the 120 offset line (C23 A 23.960 vs original 24.001 — user chose drawing cover over table); C20/C22/C24 VIII H16 straight bars + 135° hooks (horizontal, hook bulge ends at hoop end) ×24/30/36; C25 III H16 ⊓ ×114, **9 piercing bars flipped legs-UP (decision resolved)**. C26 III H19 ×15 are 15 separate Brep objects (not an instance) on `…C26_H19`, 1620→±1630 fixed, Rc rebuilt per KDS.
+- Bend radii: C1/C2/C3 inner R=3db=76.2 (centerline 88.9); C26 inner 3db=57.3 (centreline ~66.85). Cover rule applied: every mark's CENTERLINE cover 120 (top/bottom/end/side); 2-tier main bars 220. Outer 1CYCLE bars at w=±1630 (C1/C2/C3/C8/C9/C10/C26), 2CYCLE at ±1500.
+- Material table totals (DXF): 8,211.316 m / 22.472 t, with splice allowance 6.8% = 24.000 t; vs original table 8,276.785 m (−65.5 m, −0.177 t). Subtotals: 주철근 1,565.4 m / 6.23 t; C12~C18 3,597.8 m / 10.94 t; C26 192.9 m; C19~C25 2,735.7 m / 4.27 t.
+
+## Scene hygiene facts
+- 641 instance definitions, 286 with UseCount 0 = backups (`*_bk1002`, `*_bk1006`, `C1/C2/C3_bk1006r`, `C25_bk1006`, `C8/C10_backup_20261002`). Don't purge without asking. C1~C11 idefs report UseCount 4 but there is only ONE doc-level instance each — P2/P10/P12 DO have C1~C11 main-bar instances (hidden layers, z-offset copies sharing the same idefs, UseCount 4) — they were missed earlier because doc.Objects skips objects on hidden layers unless ObjectEnumeratorSettings.HiddenObjects=True; no stirrups/horizontal bars there.
+- Empty/hidden helper layers: `P1_CHECK_튀어나옴_피복부족`, `P1_CHECK_간섭` (stale — made BEFORE the 10-06 fixes; clash/cover CSVs from 10-02 are outdated), `TEMP_*` (TEMP_C8_ONE, TEMP_FILLET_TEST, TEMP_C26_PROTOTYPE, TEMP_COVER_CHECK, TEMP_R_TEST — empty), `P1_두부(코핑)_백업_261006`, `P1_C26_백업_261006` (both empty).
+- 4 viewports: Perspective, Top, Left (rotated to coping axis), Front (parallel, looking along 109.105°).
+
+## Status vs old TODO list (`261002_수정해야할 부분.md`)
+RESOLVED: C25 9 piercing bars; coping top steps; 1CYCLE outer ±1630; C13~C17 leg composition (C=510); C14/C16 lap 392→510; cover 120 all marks; C1/C2/C3/C26 KDS Rc; box-wrap question (3-6, kept on centerline, table shows −47).
+STILL OPEN / not done: clash (간섭) re-check after model completion (user: do it last; old CSVs invalid); C23 A 23.960 vs table 24.001 (accepted deviation); C26 A 12.165 vs 12.160 (+5 mm, minor); P2/P10/P12/P11 not modeled; Section drawings (A1 frame, 1/2/3번 methods) for P1 not started in this file.
+
+**Why:** the user's Claude connection dropped repeatedly during the 10-06 session, so many model changes were never written to memory; this file was rebuilt by reading the live scene and DXF.
+**How to apply:** treat this as ground truth for P1 over any older memory line that says the coping top is shifted, C25 undecided, or the material table lacks C19~C25. Re-verify against the scene (get_scene_info / the JSON dumps) before large edits.
+
+## CTC check vs drawing (2026-10-06, 코핑구조도 DXF @-dims vs model leaf centroids in coping local frame; raw data `261006_CTC_model_points.json` in drawings folder)
+Drawing @-dims: 24@125=3.000 (1+2CYCLE combined), 12@250=3.000 (2CYCLE, 13 bars), 11@250=2.750 (1CYCLE interior, 12 bars), plan stirrups 7@300|14@150|8@300|16@150|19@300|16@150|8@300|14@150|7@300 (=110 stations), 38@600=22.800 (C25), side bars @200 (13 levels 8058..10458).
+Model = drawing for: C4~C7/C11 13 bars @250 (±1500); C1/C2/C3/C8/C9/C10 interior 12 bars @250 (±125..±1375) + 2 outer at ±1630 (gap 255); stirrup stations 110, s −11850..+11850, exact 300/150 pattern; C25 39 stations @600 (s −11250..+11550, asymmetric by design 120|730…430|120), vertical zigzag rows; C19~C24 levels @200 (13 levels).
+[SUPERSEDED — the C14 / C12-C18 items in this line were corrected and FIXED later, see "CORRECTION" and "CTC FIX DONE" below; only C20 / C8-C10 / C26 / C22-C24 remarks still stand] Small deviations found (not fixed): C14 stations sit −1.9 mm off the exact grid (−4801.9…−3451.9; C16 mirror is exact) → gaps C13→C14 148.1 / C14→C15 151.9; C12/C18 lid and base centroids differ 2.7 mm in s on all 19 stations (C13~C17 don't) — verify lid/base coaxial; C20 VIII bars t asymmetric (−114.5/+112.7 vs C22/C24 symmetric ±107.6); C8/C10 interior bars ±0.2 mm; C26 outer bars ±1630 are only 130 from the ±1500 grid. C22/C24 VIII bar t-positions (±107.6/±645.7/±1107.6, touching the box legs) differ ~18–20 mm from the ±89/±661/±1089 noted in the earlier drawing review — unverified which is right.
+
+## CTC FIX DONE 2026-10-06 (user: "C14 1.9mm와 C12/C18 2.7mm 가장 간단한 것부터")
+CORRECTION of the CTC section above: the "C14 stations −1.9 mm" was my clustering artifact. Real cause: in C12/C18 (base 2.68 mm toward centre) and C14/C16 (base + its 2 extension pieces 1.95 mm outward) the ⊔ base pieces sat off the lid's s-plane (leftover of the earlier normal-direction cover fixes); lid was exactly on the 150/300 grid. C13/C15/C17 had 0 offset.
+FIX: in every box-def of C12/C14/C16/C18 (38/20/20/38) the base pieces were translated back to the lid's s-plane (Δs = −dev) AND moved along the haunch tangent so the perpendicular cover stays 120 (Δz = slope·Δs, slope 0.375 end haunch / 1/3 inner haunch → +1.006 / +0.649 mm up), then re-trimmed at lid-top centerline (Brep.Trim, lap stays 510). Backups = idefs `<boxname>_bk1006b`. Re-measured over all instances: leaf s-spread per station = 0, stations exactly C12 −11850..−8100, C14 −4800..−3450, C16 3450..4800, C18 8100..11850; leaf counts unchanged; all ColorFromParent. Model saved after the fix.
+Open: C22/C24 VIII bar t-positions (user is checking the drawing himself); C20 ±1.8 mm asymmetry; material table DXF not regenerated (lengths change <1 mm).
+
+## SAVED 2026-10-06 12:02 — `대호지교 교각 model.3dm` (127 MB) includes the C12/C14/C16/C18 base-realign fix and was saved with ALL layers visible/objects shown (file is clean). Session working view (rebar-only: C1~C11, C12~C18, C19, C22, C24; coping solid hidden per object, layer P1_두부(코핑) ON) was re-applied after saving and is NOT saved. Left viewport re-aligned to the coping axis (19.105°, up = Z) — saved in the file. Pending user check: C22/C24 VIII bar width positions vs drawing.
+
+## C20/C22/C24 hook flip (2026-10-06 ~12:15, user screenshot `스크린샷_3 2026-10-06.png`, green circles): the VIII bars at width position t≈±646 (axis ±644.05; 2nd bar from each side; 8/10/12 bars = 2 positions × all levels × regions) were mirrored about their own axis so the 135° horizontal hooks now point INWARD (C22 bbox t now ±[464.6..662.3], tip ≈ 2CYCLE main bar at t=±500) instead of outward. Other 4 bar positions per level (t≈±108, ±1108) unchanged, hooks outward. Backups = idefs `C20_bk1006c`, `C22_bk1006c`, `C24_bk1006c`. NOT saved to the .3dm yet (unsaved after the 12:02 save). Material table lengths unchanged (mirror).
+
+## SAVED 2026-10-06 12:21 (supersedes the 12:02 note): `대호지교 교각 model.3dm` (132 MB) now includes the C20/C22/C24 hook flip too, saved with all layers visible. Scene snapshot refreshed: `261006_FINAL_scene_dump_v2.json` (objects incl. hidden ones; layer visible flags = working view). Open items: C22/C24 bar width positions vs drawing (user checking), unused backup idefs (`*_bk1006b`, `*_bk1006c`, `*_bk1006`, `*_bk1002`) not purged, material-table DXF not regenerated since 10-06 10:49 (lengths unchanged by later edits).
+
+## KDS 24 14 21 review 2026-10-06 ~13:00: table `261006_철근재료표_KDS.dxf` (= `_좌측정렬.dxf` + new right column "비고 3 (KDS 24 14 21 기준 상이)" in magenta + legend; made with `rebar_pipeline\dxf\kds_note_column.ps1`). Details/results in [[reference-kds-24-14-21]]. NO real geometry deviation found (the C15 width-1005 "R 34.6" was a measurement artifact; all box bends are R=66.6 centerline). Only the interference/clear-spacing items are noted in the table. Rhino model file unchanged since the 12:21 save (only views/layer visibility changed afterwards).
+
+## CLASH RE-CHECK 2026-10-06 ~14:00 (user: "간섭은 재검사하되 변경은 하지 말고 체크만 해서 저장") — READ ONLY, model untouched. Report `261006_간섭재검사.md` + `261006_간섭재검사_목록.csv` + `_요약.json` in the drawings folder; script `rebar_pipeline/rhino/08_clash_check.py`. Result: 15,101 clashing bar pairs (P1 only; 1,711 bars, 120,559 segments). By cause: stirrups×main 7,272; stirrups×horizontal 3,828; stirrups×stirrups 1,320 (NEW category: left/right 1250/1005 boxes overlap on the same line); stirrups×C26 1,120; horizontal×horizontal 701; horizontal×main 596; C26×horizontal 122; main×main 84 + C26×main 58. Essentially identical structure to the 10-02 check (13,522) → the 10-06 edits did not change the clash picture. Table `261006_철근재료표_KDS.dxf` column 비고 3 now lists the 10-06 partner marks per mark (C1~C26). Gotcha found: `BoundingBox(p0,p1)` is invalid when points are not ordered min→max → use `BoundingBox([p0,p1])`; NURBS param-0.5 midpoint ≠ opposite point (up to 8 mm off on trimmed pipes) → take cross-section circle center via `IsoCurve(...).TryGetCircle`.

context-migration/memory/project_p1_pier_structure.md

@@ -0,0 +1,81 @@
+---
+name: project-p1-pier-structure
+description: "Structural facts about the P1 pier (대호지교) being modeled in Rhino — column/pile configuration, coordinate placement basis, cap-beam rebar status incl. C12/C18 haunch marks"
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: 3f00c5a2-89d3-4ff6-bce0-294eebc0a639
+  modified: 2026-10-06T00:50:32.902Z
+---
+
+P1 is one pier in a set (P1, P2, P10, P11, P12) being modeled from real construction drawings (교각도, 두부보 도면). **Bridge name: 대호지교** (corrected — this is NOT 평강1교, a separate project; see [[project_pyeonggang1_modeling_standard]] for that one). Rhino file: `D:\★Pier 자료\클로드로 모델그리기\대호지교 P1\대호지교 교각 model.3dm`. Drawing files (DXF) and a project-local `notes.md` live in the same folder. See [[reference-pyeonggang1-dxf]] for the separate 평강1교 drawings (do not confuse the two).
+
+- P1 is a **2주식 교각** (two-column pier) with **no separate footing** — two Φ3.0m cast-in-place pile-columns (현장타설말뚝기둥) at 13.0m center spacing, continuous from pile tip straight up to the cap beam (두부보/코핑).
+- Placement basis: real survey coordinates from the pile coordinate table (말뚝좌표표) — left/right X, Y — and real elevations (H, H1, H2, ground level, EL "CL"/"CR"/"PB"). **The coping is rotated/skewed relative to the global X/Y survey axes** — do not assume global X = pier length direction; see [[feedback_coping_haunch_rebar_method]] for how to get the true local frame.
+- The coping (두부보/코핑) Brep is ~24.45m long end-to-end, 3500mm wide, with a stepped/haunched underside (deepest near each column, shallower toward mid-span and the outer ends) already modeled into the Brep's faces.
+- Cap-beam rebar: SD400, bar marks C1~C26 (+more per material table), shape legend I~VIII per the P1/P3/P5/P8 cap-beam drawings (I=straight, II=single-bend, IV=symmetric-hook-ends, V=see below, VI/VII/VIII=stirrup/hook/complex variants).
+- **Terminology (user's own naming, use consistently)**: **주철근** ("main rebar") = C1~C11, the 1CYCLE/2CYCLE top/bottom mat bars. **수직전단철근** ("vertical shear-transfer rebar") = C12~C18 (and by extension C26's own family), the haunch-region ⊓+⊔ box assemblies. **수평전단철근** ("horizontal shear rebar") = C19~C25 (built 2026-10-02). Don't conflate them when discussing "which rebar" needs a change.
+- **User added (2026-10-02): 수직전단철근 C12~C18 — 이음장(lid/base lap) 부분과 뚜껑(lid) 부분 must be re-checked against the drawing** (lap length/location, lid top z & width, how the +124 raised zones are handled, coincident lap representation, bend radii lid R≈42.7 / base R≈47~63 vs KDS H22 3db → centerline 77.7). Recorded as section 3-A of `261002_수정해야할 부분.md`.
+- **DONE 2026-10-06 (user: "삭제하고 재료표처럼 다리 C=510으로, 엇갈린 것은 지워줘")**: all off-axis stubs in C13~C17 removed (144×124mm in C13 09-13/C15/C17 v2_09-13, 80×12.9mm in C14/C16; 112 box-defs, backups `<name>_bk1006`) AND base(⊔) legs extended coaxially up to the lid-top centerline (+124 / +118.1) → all 224 C12~C18 box-defs now: lid leg C=510, base B=full height, lap 510. C12/C18 (76 defs) base tops then trimmed 7.2 via `Brep.Trim(plane z=lidtop, +Z normal)` → lap 510 everywhere (same day, user request). Extensions are separate coaxial pipes (base = 3 pieces; Brep join fails because the original base's rim edges are not naked). File saved. This closes items 3-1/3-2/3-3 and pending decision #4 of the to-do md; the stub/lap notes further below are now historical. MCP gotcha: `execute_rhino_code` returns only the variable `result`, `print` output is not returned.
+- **COVER CHECK vs DXF 2026-10-06** (report `261006_피복 체크(도면 대조).md` in drawings folder; user: 간섭은 모델 완성 후, 지금은 피복만). Key finding: **the model coping Brep's top steps are wrong** — both 구조도 and 일반도 front views have symmetric 62mm steps at s=±3100/±6200/±9300; model has them at −7750/−4650/−1550/+4650/+7750/+10850 (shifted +1550; left ones sit on the bearing centers ±1550/4650/7750/10850). This is the cause of the top cover 58 on C26/C13/C14 — rebar is right, concrete is wrong (fix not yet requested). Everything else matches the drawing except the known items (1CYCLE outer bars ±1617.3 vs ±1630, C24 end 44.2, C23 99.3 = table A vs front view, hoops 20.65 long, C25 9 bars, stirrups not wrapping main bars). `교각도(1)(P1~P2,P10~P12).dxf` is actually a binary DWG (AC1024): copy to a `.dwg` name and read via `RhinoDoc.CreateHeadless(None).Import`. Structural DXF front-view origin: s = x − 876439.2, z = y − 316296.8 + 7738.
+- **COVER-120 FIX DONE 2026-10-06 (user: "구조도랑 같이 피복을 120에 맞춰서 수정")**: outer 1CYCLE bars (C1/C2/C3/C8/C10/C9/C26) moved to w=±1630; C19/C21/C23 hoops rebuilt with ends ON the 120 offset line (no 20.65 wrap; C23 ends ±11980, A 23.960 ≠ table 24.001 — user chose drawing/cover over table); C20/C22/C24 rebuilt so the hook bulge ends at the hoop end (straight end = hoop end − 60). Re-check: every mark top/bottom/end/side center cover = 120.0 against the DRAWING concrete outline. Backups `<mark>_bk1006` idefs. Idefs C1~C11 are SHARED with the P2/P10/P12 instances (UseCount 4) — idef edits change those piers too. Offset-line formulas: s_end(z)=11980−(9321.16−z)/0.375 (z<9321.16), s_in(z)=4919.47−(z−7858)·3. C25: the 9 piercing bars were flipped legs-UP (⊔, mirror about the top-bar centerline z; user chose "방향을 바꿔줘" 2026-10-06), other 105 stay legs-down; backup `C25_bk1006`. **Coping Brep top FIXED 2026-10-06** (user: "코핑 중심에서 대칭이 되어야"): rebuilt as profile extrusion with steps at ±3100/±6200/±9300 (62 each, 10738→10924), same GUID d7b51436 kept via Objects.Replace, bottom/ends/width/volume unchanged; old Brep kept on hidden layer `P1_두부(코핑)_백업_261006`. C26/C13/C14 top cover now 120 against the model too. Exact length angle = 19.1053°. STILL OPEN: stirrup-wraps-main-bar question. File saved (saved with only P1 layers visible, P2/P10/P12/CHECK/PIER_LABELS off).
+- **2026-10-06 later**: material table written as `261006_철근재료표.dxf` (비고 column = diffs vs original table; C1~C11/C26 lengths re-measured = table exactly). C1/C2/C3 (Rc 76.2→88.9) and C26 (Rc ~58→66.85) rebuilt with KDS centerline radius (inner 3db + r), dims/end positions unchanged, flat caps; backups idefs `C1/C2/C3_bk1006r`, C26 originals on hidden layer `P1_C26_백업_261006`. Gotcha: sampling `BrepFace.PointAt` on flat CAP faces reads the untrimmed plane (points outside the bar) — skip planar faces in cover/extent checks.
+- **END OF DAY 2026-10-02 — START HERE NEXT SESSION.** Model saved 13:46. Authoritative to-do list: `D:\★Pier 자료\클로드로 모델그리기\대호지교 P1\261002_수정해야할 부분.md` (done list, exposed/low-cover items, drawing mismatches, 4 pending user decisions: C25 9 bars / box bars outside main bars / coping top camber basis / C13~C17 leg split). Clash summary: `261002_간섭 부분.md` (118 mark pairs, 13,522 bar pairs, re-checked AFTER the hook fix and C12/C18 stub removal; CSVs regenerated to current state). `261002_철근 간섭 및 피복 체크.md` is the superseded first pass. Rhino `P1_CHECK_*` layers are still the pre-fix version.
+- **Offset "short stub" fillers in 수직전단철근 (found 2026-10-02, user spotted "이상한 짧은 철근")**: every 4-piece box-def has 2 filler pipes built from SURFACE vertices → ~11.1 off the leg axis (look like separate stubs). Top stubs 14.9 (C12/C18) / 12.9 (C14/C16) at base-leg tops; mid 124 (C13/C15/C17) at lid-leg bottoms. Box heights (top/bottom z, station s) match the 정면도 for ALL stations (≤1mm z, ≤6mm s). Leg split vs drawing (B=full height, C=510): **C12/C18 MATCH** (base cap already at lidtop+7 → stubs are pure junk, removing them changes nothing); C13/C17 raised + C15 (base short by 124, lid 634) and C14/C16 (lap 392) do NOT match → user said leave those. **C12/C18 stubs REMOVED 2026-10-02 (user permitted)**: all 76 box-defs now 2 pieces (lid+base), ColorFromParent intact, lap 517; originals backed up as un-inserted idefs `<name>_bk1002`; file saved, view restored. C13/C15/C17 (124 mid stubs) and C14/C16 (top stubs) intentionally LEFT (legs don't match drawing split).
+- **DONE 2026-10-02: VIII hooks (C20/C22/C24) re-oriented HORIZONTAL** per user ("갈고리 방향이 수평으로 되어야해 지금 코핑상면으로 향해있어"). Hook plane = horizontal, curling toward the OUTSIDE of the width (sign of w; inward would make the ±106 bars' hooks cross each other). A/L unchanged. Center cover now: C20/C22 min 93.3 (hook tips toward haunch diagonals), C24 43.9 at end faces (hook bulges 60 past straight end — still open). File saved. CHECK layers/CSVs are from BEFORE this change. Rule for future VIII bars: hooks horizontal, never up/down.
+- **(was) NEXT TASK (user, 2026-10-02): fix the 수평전단철근 (C19~C25) FIRST — user says one of today's bars has a wrong bar DIRECTION ("철근 방향이 오늘 만든것중에 있어").** Which mark/what direction was not yet specified — ask at the start of the next session (candidates to look at: VIII hook orientation (turned UP by me, legend shows down), C25 ⊓ leg direction/the 9 piercing bars, hoop/bar orientation). This comes before the other pending fixes (C14/C16 lap, 1CYCLE outer ±1630, box bars vs main-bar centerline).
+- **C1~C11 status**: top-mat rebar, already modeled as block instances under layers `P1_두부_주철근_1CYCLE::C{n}_H25` / `..._2CYCLE::C{n}_H25`. C1 is a 14-bar array at H25, top level Z≈10618 (block instance bbox top ≈10630.7, i.e. bar-surface top) — this Z level is the datum other marks (e.g. C12's lid) tie into. Colors currently by CYCLE (1CYCLE=red, 2CYCLE=blue), **not yet converted to the diameter-based scheme** — still needed: H25 and H29 ACI color numbers (not on the color chart image seen so far, which only covered H10/H13/H16/H19/H22 — ask the user again if picking this up).
+- **Shape V (양곡) family = "⊓ lid + ⊔ base" overlapping box, NOT a single diagonal-following bar.** Icon (user's `V.철근형상.png`): top segment "a"(=table col A) oriented along the 3500mm width, left leg "b"(=table col B, variable) down, right leg "c"(=table col C) — but the *physical* construction (confirmed by user) is two separate overlapping pieces: a fixed-length "lid" (⊓, legs = the SHORT fixed value, opens downward from the C1 top-bar level, "뚜껑") + a variable "base" (⊔, legs = the value that grows with haunch depth via ray-cast underside+120mm cover, opens upward) — both symmetric (same length both legs), coincident/overlapping at this design stage (front/back offset to avoid physical clash is a construction-detail-stage decision, not modeled). Multiple such boxes nest across the width (e.g. C12's 1005/1250/1250/1005mm pattern, overlapping, cover120/625mm from each edge).
+- **C12/C18 (H22) — left/right haunch, DONE.** Layers `P1_두부_주철근_1CYCLE::C12_H22` / `...C18_H22`, each a single top-level block instance (nested: mark block → per-station block `C12_XX` → per-box-type block `C12_1005_XX`/`C12_1250_XX` → leaf pipes). C12 = near END_A (coping's s_min end), C18 = mirror near END_B. **Final corrected station schedule** (measured from the coping end face, first bar at cover120+130=250mm): **7@300mm=2100mm (8 stations) then 11@150mm=1650mm (11 stations) = 19 stations total**, ×4 width-boxes = 76 boxes matching the material table qty exactly (152 physical bars incl. both lid+base pieces). Box widths 1005/1250/1250/1005mm as above.
+- **C13/C17 (H22) — continue right after C12/C18's last station.** 13 stations each (S=4150~7150 from END_A for C13): 3@150=450mm (3) + 8@300=2400mm (8) + 2@150=300mm (2), starting one gap after C12's/C18's final station (S=4000). Same 4-box width pattern as C12.
+- **C14/C16 (H22) — continue right after C13's/C17's last station** (corrected — earlier "starts from C26" was wrong/caused overlap with C13; user corrected this). 10 stations (S=7300~8650 from END_A for C14): 10@150=1500mm, starting one gap after C13's final station (S=7150).
+- **C15 (H22) — continues right after C14's last station**, standalone/centered (no mirror pair — its own 26 stations already span the full center gap). 26 stations (S=8800~15400 from END_A): 4@150=600mm (4) + 19@300=5700mm (19) + 3@150=450mm (3), starting one gap after C14's final station (S=8650). 26×4=104 boxes, matches material table qty exactly.
+- **IMPORTANT: do not reuse the DXF's combined dimension-chain numbers directly for C13/14/15 without care.** The actual coping structural drawing has ONE continuous symmetric dimension chain per side (120|7@300=2100|14@150=2100|8@300=2400|16@150=2400|19@300=5700(center)|...mirrored...) where individual segments often combine TWO adjacent marks' gap counts into one drawn dimension (e.g. "14@150" = C12's remaining 11 gaps + C13's own 3 gaps, drawn as one line) — attributing DXF segments to marks by callout proximity alone is unreliable; the user's direct verbal station/spacing statements (as recorded here) are what was actually built and are authoritative for this model.
+- **C26 (H19, shape III) — DONE.** Centered ㄷ-shape (⊓, both legs equal — NOT the asymmetric lid+base pattern): straight span A=12.160m centered on the coping's longitudinal midpoint (S≈12100mm from END_A), with a 90° hook B=350mm bending down at each end (total developed length 12.160+2×0.350=12.860m, matches material table exactly). Flat straight-portion Z = **10742mm** (= coping's center-plateau top EL10924 minus 182mm cover — NOT the C1/global-lowest datum of 10618, since C26's span sits entirely within the higher central portion of the coping's stepped top camber and never reaches the coping's absolute lowest edge; using the global-lowest datum put it noticeably too low). General lesson: **the "flat bar, cover120 from lowest point" rule must use the lowest point actually crossed by THAT bar's own span, not automatically reuse another mark's datum** — check the top-camber profile (ray-cast) over the specific S-range before picking a Z. 15 bars across the width, center-out at 250mm CTC (matching C1's own array method: pure grid, outermost pair snapped inward to maintain cover120+radius from each edge). Layer `P1_두부_주철근_1CYCLE::C26_H19`, color magenta (ACI 210).
+- **C13/C14/C15/C16/C17 (H22) — datum-raise fix DONE (2026-09-21, corrected).** These marks were originally built with every station's lid top at the same low datum as C12/C18's lid (centerline Z=10618, surface Z=10629.1 for H22's r=11.1) — but the portion of the coping they sit under is the same elevated center plateau C26 already used (centerline Z=10742, surface Z=10753.1 for H22). **User-specified exact scope** (decided in an earlier session, previously lost — write scope decisions down immediately): only the C14-ward/center-ward tail of C13 and C17 — stations **09,10,11,12,13** (last 5, counting inward from the C14 side) and mirrored C17 stations **v2_09..13**; C14, C15, C16 raised **in full** (all 10/26/10 stations), since their whole span sits within the plateau ("C14,15,16은 전부 다 C26 위치에서부터 시작").
+  - **First attempt (WRONG, reverted the same session): rigid +124mm Z-translate of the whole station sub-block.** This was wrong because these marks are the SAME lid(⊓)+base(⊔) overlapping-box construction as C12/C18 (see the Shape V bullet above), not a single uniform-height box — rigidly translating the whole station moves the **base** piece too, which must stay exactly where it was (its bottom ties to the ray-cast underside+cover, independent of the top datum). The "uniform Zmin/Zmax across stations" observation that seemed to justify a rigid shift was a red herring — it just meant those particular stations' base leg happened to be constant-height, not that the lid+base split didn't apply.
+  - **Correct method: extend only the lid, leave the base untouched.** Per box-def (e.g. `C14_1005_01`, holding exactly 2 leaf Breps): identify the **lid** as the Brep with the smaller Z-span (base has the larger/varying span); get its `.Vertices` (exactly 2, both sitting at the lid's own Zmin — these are the two leg-bottom tie-in points, since the lid is an open-ended ⊓ pipe with its bend at the top and its two open ends at the bottom); duplicate the lid Brep and translate the duplicate by `(0,0,+124)`; for each of the 2 bottom points, build a straight filler pipe from the original (fixed) point up to `point+124` in Z via `Rhino.Geometry.Brep.CreatePipe(LineCurve(Line(p, p+dz)), radius, False, Rhino.Geometry.PipeCapMode.NONE, False, tol, angleTol)` (note the enum member is spelled `NONE`, not `None` — `PipeCapMode.None` is a Python syntax error since `None` is a keyword); replace the box-def's geometry list with `[shifted_lid, base_brep_unchanged, filler1, filler2]` via `InstanceDefinitions.ModifyGeometry(idef.Index, newlist)`. This exactly preserves the lid/base overlap length (510mm here) and genuinely lengthens the lid's bar (matches the user's own framing: "위에 510[mm] 부분은 고정이니 철근이 더 길어져야 한다" — the fixed short lid dimension doesn't change, the bar just gets a longer straight run before its bend). Box-def naming convention confirmed general across these marks: `<mark>_<width:1005|1250>_<stationsuffix>` where stationsuffix is the station block's own name with the `<mark>_` prefix stripped (e.g. station `C17_v2_09` → box-defs `C17_1005_v2_09` / `C17_1250_v2_09`).
+  - Verified post-fix (world-space, via the mark's outer instance bbox): all 5 raised marks now read Zmax=10753.1 (lid's new top), while **Zmin is exactly unchanged from the pre-fix value for every mark** (C13/C17=7846.9, C14/C16=7880.2, C15=8346.9) — proof the base pieces were untouched. Un-raised C13 01-08 / C17 v2_01-08 stations remain at the original Zmax=10629.1.
+- **C4/C6/C5/C7 (2CYCLE tier1/tier2, H25) cover-convention fix — DONE (2026-09-22).** These 4 marks had been built using CLEAR/SURFACE cover (bar surface exactly 120mm/220mm below the coping top surface) while C1 (1CYCLE) was already built using CENTER cover (bar centerline exactly 120mm below) — an inconsistency the user caught by inspection. Root-cause check: coping top surface's real minimum Z within each mark's own footprint (ray-cast, both C4/C5's span and C6/C7's span independently checked) = 10738.000 in both cases (matches the coping-wide global minimum too, i.e. the low point recurs near both columns symmetrically). Fix: moved each of C4/C5/C6/C7's single doc-level instance object by `(0,0,+12.7)` (exactly one H25 radius) via `rs.MoveObject` — a plain rigid translate, no rebuild needed since these are simple flat un-nested single blocks (unlike C12-C18's per-station nested structure). Verified post-fix: center-to-surface cover reads exactly 120.000 (C4/C6) and 220.000 (C5/C7).
+- **C2/C3/C8/C9/C10/C11 cover-convention audit — DONE (2026-09-22), user confirmed scope "주철근 및 수직전단철근 까지 전부다 포함".**
+  - **C2, C3**: already correct (center-cover, exactly 220.000mm) — no fix needed. Each is a single-bend (hook) shape: one long flat main span (world Z=10518.0) + a short hook dropping to Z=0 at one end only. The hook doesn't affect the cover check on the main span.
+  - **C9 (H29), C11 (H25)**: simple flat single-tier arrays (bbox Z-span exactly = bar diameter, confirms non-bent). Both were surface/clear-cover 120mm from the coping's BOTTOM surface (EL 8238.0, confirmed via ray-cast at C9/C11's own footprint). Fixed via plain `rs.MoveObject` rigid shift **toward** the reference surface (DOWN, since surface is below) by exactly one bar radius: C9 by -14.3 (H29), C11 by -12.7 (H25) — **mistake made and caught**: first applied C9's H29 radius (-14.3) to C11 too by copy-paste error; caught via post-fix verification (center didn't land on the expected clean value) and corrected with a +1.6mm follow-up move. **Lesson: always use each mark's own bar diameter for its shift — never reuse a shift constant computed for a different-diameter mark.** Both now read exactly 120.000mm center-cover.
+  - **C8, C10 (H25) — the hard case, DONE.** Not simple bars: each of the 14 parallel bars per mark is a single Brep with **11 real topological vertices** and 9 Faces, tracing hook→diagonal-down→flat "valley"→diagonal-up→hook (the bar physically follows the coping's stepped haunch underside profile, unlike C12-18's simple 2-leg V/⊔ boxes). Root cause: the flat "valley" span (~3133mm long) was built at clear/surface-cover 120mm from the coping's absolute-lowest bottom plane (EL 7738.0, same global-min plane used elsewhere in this project), not center-cover.
+    - **Automated path/segment extraction (reusable for any future multi-vertex bent-bar fix)**: collect `Brep.Edges`, keep only "travel" edges where `start.DistanceTo(end) > 1.0` (filters out the small circular "rim/seam" edges at each joint, length ≈ pipe circumference `2·π·radius` but start≈end), dedupe reversed-duplicate edges (same edge often appears twice, once per adjacent face), build a node/adjacency graph from survivors, find the 2 degree-1 nodes (the bar's true open ends), walk the graph between them for the ordered vertex path. Reliably reconstructed the identical path for all 28 bars (14×C8, 14×C10) with zero manual coordinate entry.
+    - Identify the target "flat" segment generically: the consecutive path pair with `|dz| < 2.0` AND horizontal length `> 500` (filters out short bend/joint edges that happen to be locally near-flat).
+    - **Gotcha: which side of the pipe a vertex represents (top surface vs bottom surface) is NOT assumed — it flips between mirrored bars.** For C8, the flat segment's vertices sit at local Zmin (bottom surface, confirmed by matching the segment's own tight bbox minimum). For C10 (a mirror of C8), the *same-role* path vertices instead sit at local Zmax (**top** surface) — confirmed because C10's overall leaf bbox still bottoms out at local Z=0.0 while the detected flat-segment vertices read Z=25.4 (=2×radius, the far/top side of the same physical line). A vertical downward ray-cast from the raw vertex therefore read a confusingly-different "cover" number for C10 (145.4) vs C8 (120.0) even though **the correct fix (shift by exactly one radius, -12.7, toward the coping surface) was numerically identical for both** (145.4 − 2×12.7 = 120.0, consistent once you account for which surface the vertex is on). **Always verify a multi-vertex bar's vertex-to-surface convention per mark via its own bbox before trusting a raw vertex-based ray-cast number at face value — mirrored geometry can flip which side of the pipe a same-role vertex sits on.**
+    - **Fix method — extract-shift-refill, not full rebuild**: match the flat segment's 2 neighboring "transition" sub-segments to their corresponding `Brep.Faces` entries by checking which face's bounding box contains both segment endpoints' X,Y (robust — same face indices `[3,4,5]` for all 28 bars). Duplicate the whole leaf Brep and `Faces.RemoveAt` the 3 target face indices (highest index first) + `.Compact()` to get the "unchanged" remainder (hooks + both long diagonals, byte-for-byte original). Separately `Faces[i].DuplicateFace(False)` the 3 target faces and `.Translate(0,0,-12.7)` as one rigid group (preserves exact relative shape, sidesteps needing to determine true centerline offset direction at the bend joints — key insight avoiding a much harder "recompute centerline via local pipe tangent" problem). Bridge the two new gaps (unchanged-anchor D/G ↔ shifted D'/G') with a fresh `Brep.CreatePipe(LineCurve(Line(anchor, shifted)), radius, False, PipeCapMode.NONE, ...)` filler each. Final leaf = `[unchanged_remainder, shifted_face×3, filler×2]` (6 Brep pieces replacing the original 1), submitted via `ModifyGeometry` with each piece's attributes = `Duplicate()` of the ORIGINAL leaf's own (unmodified) attributes — **for C8/C10 specifically the correct `ColorSource` is `ColorFromLayer`, NOT `ColorFromParent`** (unlike C12-18's deeply-nested mark→station→boxtype→leaf structure; C8/C10 are shallow doc-instance→leaf, same as untouched C1/C9 — don't blindly force ColorFromParent on marks with different nesting depth).
+    - `Brep.JoinBreps` on freshly-`CreatePipe`'d segments returned them unjoined (no-op, same count in/out) — don't rely on it; multiple separate Brep pieces per leaf (as already established for C12-18) is the working pattern.
+    - Verified post-fix (both marks, all 14 leaves each): shifted flat segment's own bbox = `[-12.70, 12.70]`, true center-to-coping-surface cover reads exactly 120.000mm. Visual wireframe check (coping hidden, C8+C10 isolated) shows smooth continuous hook→diagonal→valley→diagonal→hook profile, no gaps/spikes. ColorFromLayer confirmed intact (84 pieces × 2 marks).
+- **Diameter-based color scheme (from user's `직경별 철근 색상표.png`, ACI color index numbers)**: H10=74, H13=74 (olive-green, RGB 0,129,0), H16=5 (blue, 0,0,255), H19=210 (magenta, 255,0,255), **H22 and every diameter above it (H25, H29, and any future larger mark) = ACI 246, dark red/maroon RGB(104,0,25), all the SAME color** — confirmed by user 2026-09-23: "H25,H29는 H22색상을 따라간다고 이전에도 말했는데 저장을 안했구나... H22이상은 전부 같은색상이야" (told in an earlier session, lost because it wasn't written down — reminder to save color/spec statements immediately, not just geometry facts).
+  - **Applied and DONE (2026-09-23)**: set `rs.LayerColor(layer, (104,0,25))` on all 11 C1~C11 H25/H29 mark layers (1CYCLE: C1,C2,C3,C8,C9,C10; 2CYCLE: C4,C5,C6,C7,C11). Found the layers were **already** at (104,0,25) before this edit — meaning the earlier memory note "colored red/blue by CYCLE" was stale (fixed directly in Rhino at some point without being recorded); this edit was a harmless confirm/no-op. Verified: every leaf object within each of these idefs has its OWN `LayerIndex` pointing at that same mark's own layer (not an incidental one) with `ColorSource=ColorFromLayer` — **for C1-C11 (shallow doc-instance→leaf structure, same depth as C8/C10) `ColorFromLayer` set on the mark's own layer is the correct/working mechanism, NOT `ColorFromParent`** (that only matters for C12-C18's deep mark→station→boxtype→leaf nesting). Visual wireframe check (C1,C9,C4,C11 isolated) confirms all four show the identical maroon color.
+- **Cover convention (user-confirmed 2026-09-22, applies project-wide): "피복 120mm" means the REBAR'S CENTERLINE sits exactly 120mm from the concrete surface — not clear/surface-to-surface cover.** User's exact words: "항상 철근의 중심을 피복에 놓고 그려줘 120이라하면 120위치에서 원의 중심이 시작되는거야" (always place the rebar's center at the cover distance — if it's called 120, the circle's center starts at the 120 position). This matches how cover was already being measured in this project (centerline-to-surface, e.g. C1's "cover120" and the C12 base ray-cast measurement below) — this is a confirmation/lock-in of the existing convention, not a change, but write it down explicitly since it deviates from the textbook KDS definition of 피복 (clear cover to nearest bar surface) and must not be "corrected" to clear-cover in some future session.
+- **TODO #1 scope confirmed 2026-09-22: base-leg cover fix applies to the ENTIRE C12~C18 haunch family** (C12, C13, C14, C15, C16, C17, C18 — all stations, both 1005/1250 width box-defs each), not just C12. User's exact instruction: "C12~C18까지 전부다 반영이야" (C12 through C18, apply to all of them).
+- **C12~C18 base-leg underside cover fix — DONE (2026-09-22).** All 224 box-defs across the 7 marks (C12=38, C13=26, C14=20, C15=52, C16=20, C17=26, C18=42) checked; 188 needed correction (now 4-leaf: lid + shifted-base + 2 fillers) and 36 were already exactly 120.000mm (skipped, left as original 2-leaf — mostly C13/C17 stations 01-08, which sit on the coping's flat absolute-lowest plane EL7738 and were already exactly right; also C18's 2 end stations). Post-fix spot-checks (C15_1005_05, C18_1250_10, plus the full C12 set) all read exactly 120.000mm. ColorFromParent verified intact on all 224 idefs' leaf objects after the fix (0 broken).
+  - **Cover must be measured as the SHORTEST/PERPENDICULAR distance to the real coping Brep (`Brep.ClosestPoint`), not a blind vertical ray-cast** — the underside near a haunch is often sloped, and a straight-up/down ray can miss the true nearest face and either hit nothing (travel hundreds/thousands of mm before hitting an unrelated distant face) or land on a coincidentally-round wrong number. `Rhino.Geometry.Brep.ClosestPoint(testPoint)` against the whole real coping Brep (id `d7b51436-d411-4ed6-be00-5af9d2058029`) is the reliable method.
+  - **Ray/cover direction gotcha: the coping's underside is BELOW the rebar, not above.** The rebar sits inside the concrete just above the bottom-facing exposed surface; cover = rebar.Z − surface.Z (positive), found via `closest_on_coping.DistanceTo(rebar_point)`, not by shooting a ray "up looking for concrete." Shooting up from the bar point (an early wrong attempt) sailed past the whole rebar cage and found the coping's TOP surface far away instead — a strong red flag if seen again.
+  - **A box-def's bottom "bend" point (for a ⊔/V-shaped base leg swept as a single pipe with no vertex at the bend) is NOT any bounding-box corner** — bbox min/max X,Y,Z are independently-minimized per axis and do not correspond to a real point on a curved/bent pipe surface. Find the true point via `face.ClosestPoint(probe)` where `probe` = (local bbox X/Y center, bbox.Min.Z − large margin) — i.e. closest-point-from-straight-below the shape's own center; the result's Z should exactly equal the brep's own bbox.Min.Z when correct (sanity check). Then centerline point = that surface point + radius (11.1mm for H22) in local Z.
+  - **Fix method (mirrors the lid-extend pattern, flipped top/bottom): keep the TOP (open-end vertices, the fixed lap point with the lid) anchored; rigidly translate a DUPLICATE of the whole base Brep by the needed delta vector (computed in world space via the closest-point/target-120mm math, then converted to local space via the box-type instance's inverse `Xform` applied to the delta as a Vector3d — exact even under the coping's in-plane skew, no flat/no-tilt assumption needed); then bridge the gap at the TOP with 2 new filler pipes (`Brep.CreatePipe`, same radius, `PipeCapMode.NONE`) from each original (now-abandoned) top vertex to its shifted counterpart.** Final leaf list = `[lid_unchanged, shifted_base, filler1, filler2]`, submitted via the 3-arg `ModifyGeometry(idef.Index, geometryList, attributesList)` with every new/duplicated attribute's `ColorSource` forced to `ColorFromParent` (do not use the 2-arg overload — see [[feedback_ironpython_exec_scoping]]'s color-break root cause).
+  - **To get a real WORLD transform for a deeply-nested box-def instance (mark→station→box-type→leaf) without manually chaining transforms**, duplicate the mark's doc-level instance, `rs.ExplodeBlockInstance(id, False)` one level (→ station instances, now placed at correct WORLD transforms), find the target station by its idef name, duplicate + explode that one level too (→ box-type instances, also now correctly WORLD-placed) — the resulting object's `Geometry.Xform` IS the correct full world transform for that box-def's own local content. Much simpler and more reliable than composing `InstanceReferenceGeometry.Xform` values by hand. **Always delete every duplicated/exploded temp object afterward** (leaf-level dedup by idef name first — a station typically instances each unique box-type idef twice, mirrored left/right at the same cover, since they share one idef).
+
+- **TODO #2 — DONE (2026-09-22): re-applied correct color to every C13/14/15/16/17 box-def touched by the 2026-09-21 lid-extend fix.** Fixed via the 3-arg `ModifyGeometry(idef.Index, geometryList, attributesList)` overload with each attribute's `ColorSource=ColorFromParent`. All 112 box-defs (C14 01-10, C15 01-26, C16 01-10, C17 v2_01-13 — wait, only v2_09-13 + all C14/15/16 were in scope, ×2 widths 1005/1250) verified post-fix: every leaf object's `ColorSource == ColorFromParent`, 0 mismatches, 0 not-found. **Naming gotcha found during this fix: C13's box-defs (and only C13's) carry an extra `_r3` suffix** — actual names are `C13_1005_09_r3`..`C13_1250_13_r3`, not the plain `C13_1005_09` pattern used by C14/15/16/17's otherwise-identical box-def names. Always check actual `InstanceDefinitions` names (don't assume the documented naming pattern is 100% uniform across marks) before batch-targeting by constructed name strings. **User's own framing of why this keeps happening**: "자꾸 새로 철근 수정할 때마다 직경별 색상이 안 맞아" (every time rebar gets newly modified, the diameter-based color stops matching) — this is a recurring pattern across sessions; treat ANY future `ModifyGeometry` call on these box-defs as color-breaking by default and always pair it with the attributes-list fix in the same call.
+- **How the two TODOs interact**: the C12-cover-fix TODO (#1 above) will itself call `ModifyGeometry` on C12's box-defs — when doing that fix, use the 3-arg attributes-preserving form from the start so it doesn't create a THIRD round of color breakage on top of the two above.
+
+- **C8/C10 bend-radius (R) rebuild — DONE (2026-09-23).** User flagged that the cover-fix session's C8/C10 geometry (and likely the ORIGINAL pre-existing geometry too) had no real KDS bend radius anywhere — every corner (hook-tip kinks, the D/G diagonal-to-flat transitions) was a sharp/mitered joint between short straight `CreatePipe` segments, several of which (18-32mm) were physically too short to ever hold a real R=76.2mm(inner)/88.9mm(centerline) H25 fillet. **User-directed simplification**: no hook geometry to build (hook tips I and J keep their exact existing positions, "갈고리 없음 — 현재 훅 끝점 위치만 그대로 유지"); collapse the whole bar down to just 4 centerline points **I → E → F → J** (E,F = the already cover-fixed flat-valley endpoints) and put real R=88.9mm fillets at the two interior corners (E and F). Rebuilt via `Curve.CreateFilletCornersCurve` + single `Brep.CreatePipe` sweep — see [[feedback_kds_rebar_bend_radius]] for the full reusable method/gotchas (this is where to look next time any bent-rebar R needs building, not here). Result: each of the 28 bars (14×C8, 14×C10) went from a fragmented 6-piece assembly down to **one single clean Brep** (5 faces: 2 straight cylinder sections + flat section + 2 torus fillet patches). Verified post-fix: cover still exactly 120.000mm at the flat segment for both marks (bbox now identically `[-12.70, 2159.83]` for C8 and C10 — this symmetry check is what caught a mid-fix bug where C10's mirrored vertex convention caused the first attempt to add the bar radius in the wrong direction, landing the flat segment 25.4mm too high; fixed by using bbox-center instead of vertex+radius for the centerline, see the linked memory). ColorFromLayer preserved. Visual check: both marks show a clean, simple, symmetric hook→smooth-diagonal→flat→smooth-diagonal→hook silhouette.
+- **CLASH / COVER CHECK 2026-10-02 (no model edits; user: "수정은 추후에")** — report `261002_철근 간섭 및 피복 체크.md` + CSVs (`261002_철근 간섭 목록.csv`, `261002_철근 피복부족 및 튀어나옴 목록.csv`) in the drawings folder; Rhino layers `P1_CHECK_튀어나옴_피복부족` (TextDots, cover<100) and `P1_CHECK_간섭` (point cloud). Key results: exposed = only C25 ×8 (+1 cover 37); C24 hooks bulge 60 past straight ends → end cover 43.9; C26/C13/C14 tops at 10742 have only 58 cover on s<0 side (model top 10800 there — asymmetric camber); C23 ends 99.3. Clashes: box bars C12~C18 sit ON main-bar centerlines (pen 23.8) and ON hoop/C25 legs at w±1630 (19.0); C1×C2/C3 hook, C1×C8/C10 a-leg (lap), C8/C10×C9, C26×C4~C7, VIII-end×hoop 15.7, C25×side bars 15.9. Method: centerline segments via isocurve ToPolyline(tol 0.3) + opposite-param midpoint, RTree.SearchOverlaps (RTreeEventArgs.Id/IdB, handler via System.EventHandler[RTreeEventArgs]), Line.MinimumDistanceTo fallback for parallel; cover via 2D section polygon + |w| (coping is a w-extrusion) — 7s for all marks.
+- **SESSION STATE 2026-10-02 12:31 (user: "좀이따가 보자")**: model file SAVED with all layers visible. Later (13:30) all layers turned back on and saved again — no isolation pending. Pending user decisions: (a) C25's 9 piercing bars (shorten / flip ⊔ / keep), (b) fix C14/C16 lap 392→510, (c) move 1CYCLE outermost bars ±1617.3→±1630, (d) coping top step layout vs 구조도. Material-table DXF does NOT yet include C19~C25 — regenerate after decisions.
+- **C19~C24 BUILT 2026-10-02** (layers `P1_두부_주철근_1CYCLE::C19_H16`..`C24_H16`, blue (0,0,255) ColorFromLayer, one idef per mark at identity, geometry in world coords). Hoops: closed polyline started mid-side, CreateFilletCornersCurve Rc=2db+r=39.75, pipe r=7.95, w=±1630; s-ends = 120-offset line + WRAP 20.65 (outside C8/C10 diagonals or C1 end legs) → A exactly = table. VIII bars: A = hoop A − 9 (4.5 inside each end), hook = 135° arc centerline R60 (=b 141 arc length) + 100 ext, **hooks turned UP** (down-hooks pierced the haunch diagonals — first C20 build was wrong and rebuilt). Counts 4/24/5/30/6/36 = table. Covers: sides 120 exact; diagonal ends ~112.7; C23 end faces 99.4 (consequence of table A=24.001 wrap). **C25 BUILT 2026-10-02 per user's definition**: ⊓ across width (top A=3260 at w=±1630, legs 300 DOWN at both sides), one bar per CSBSEC1 dot in the 코핑구조도 정면도 (x0=876439.2 → s=x−x0, NOT mirrored; y0=316296.8 ↔ z=7738): rows z=10742 (8 @1200 s−2850..5550), 10495.5 (32 @600, |s| 2250..11550 in two groups), 10258 (20 @1200), 9658 (19), 9058 (19), 8458 (16) = 114 = table. Fillet 2db, L 3.860. **OPEN: 9 bars' legs pierce/under-cover the underside** (z=8458 row s=−3450..3750 center bottom 8238, s=−9450 z8458, s=−11250 z9058) — asked user how to treat (flip/shorten/keep). Mesh-based cover checks gave a bogus 108.5 — verify with Brep.ClosestPoint on a few points; full Brep sampling of long bars times out.
+- **C19~C25 (H16) drawing review** — drawing review 2026-10-02 (sections A-A end / B-B over column / C-C center of 코핑구조도).** Drawing marks = C1~C26 exactly = 재료표 (no extra marks). Side-face horizontal bars at 200 vertical spacing, levels (model z, bottom-over-column 7738): 8058, 8258 | 8458…9258 | 9458…10458 (13 levels in B-B).
+  - VI = closed rectangular hoop, L=2A+2B, B=3.260 (w=±1630; drawing dots shown at ±1594 = symbol offset inside box legs). C19: 2 levels × 2 column regions (bounded by end-haunch & inner-haunch diagonals, A 5.466~4.333) = 4. C21: 5 levels 8458~9258 full length bounded by end diagonals (A 23.664~19.397) = 5. C23: 6 levels 9458~10458, A=24.001 (=end-face cover 23.96 + wrap outside C1 legs) = 6.
+  - VIII = straight bar + 135° hooks both ends (b=141, c=100, r=60; L=A+0.483). 6 per level at interior w = ±89, ±661, ±1089 (just inside the inner box legs). C20 = C19 levels (2×6×2=24), C22 = C21 levels (5×6=30), C24 = C23 levels (6×6=36). A ≈ matching VI A − 9.
+  - C25 (III, A=3.260 ⊓ across width, legs B=300, 114 ea, "H16 @ 600"): seen as 3260 lines in sections at ~600 vertical spacing + plan "38@600=22.800" (120|730|…|430|120) — exact placement still UNCERTAIN, confirm with user.
+  - Correction to the +47 finding below: the sections draw C12 box legs at w=±1630/±1125/±625/±125 with widths 1250/1005 — SAME as model. So table A/B (+47) is the table's dimension convention, not a model error.
+- **Full audit vs DXF 2026-10-02 (output: `261002_철근재료표 작업중.dxf` in the drawings folder, R12/ANSI_949, same columns as 원 재료표 + 비고 column).** C1~C11: count, dims, longitudinal s-ranges all = DXF/table exactly. Findings NOT yet fixed (await user): (1) 1CYCLE outermost bars (C1,C2,C3,C8,C10 at w=±1617.3; C9 ±1615.7; C26 ±1620.4) use surface-cover 120 at the side faces — DXF plan puts them at centerline 120 (w=±1630); 2CYCLE ±1500 is correct. (2) C12~C18 table A=1.297/1.052 and box heights are exactly model+47 (=2×(12.7+11.1)) → drawing has stirrups wrapping OUTSIDE the main bars; model stirrups sit on main-bar centerlines. Table V convention verified: L = 2A + 2B + 2C, B = full box height, C = 510 lid lap. (3) C14/C16: ALL box-defs lost the 124mm lid-extension fillers (the later base-cover fix rewrote the geometry list as [lid,base,2 tiny fillers]) → lid–base lap 392 < 510. C13/C17/C15 kept their fillers (C=634). (4) C26 A=12.165 vs 12.160. (5) Model coping-top step positions (±1550/4650/7750/10850, asymmetric) differ from the 구조도 front view (symmetric ±3100/6200/9300) — likely 일반도 vs 구조도 difference, ask user. Measurement tricks: pipe centerline length = average of two opposite rail isocurves (fast); Brep area via AreaMassProperties times out over MCP.
+- **C8/C10 rebuilt AGAIN 2026-10-02 to the drawing's shape VII (supersedes the 09-23 I→E→F→J rebuild).** Source: 코핑구조도 ①CYCLE assembly (C8 polyline in DXF: a=630 vertical leg UP at the end-face cover line, b=4167.1 diagonal along end haunch, c=3158.8 flat over column, d=2331.1 diagonal UP along inner haunch, continuing past the haunch into the center region as anchorage) + 재료표 X1=159°/X2=162°. Coping section in local frame (u=19.105°, origin=coping bbox center 480714926,153833329.5): s=±12100 end face z9238~10738, end diagonal to (±8100,7738), flat to ±4900, inner diagonal to (±3400,8238), center flat. Offsetting every face 120mm inward gives centerline pts (s>0 side): (11980,9951.16)-(11980,9321.16)-(8078.24,7858)-(4919.47,7858)-(2708.09,8595.13) — b and c lengths fall out EXACTLY equal to the drawing (validates drawing = 120 centerline offset). In this frame C8 is on s>0, C10 on s<0. Built per bar (kept old w positions, ±1617.3 outer / 250 CTC) with CreateFilletCornersCurve Rc=88.9 + single CreatePipe, ModifyGeometry with original attrs (ColorFromLayer). Verified: bar-surface clear cover 107.34 everywhere = 120 centerline. Old geometry kept as un-inserted idefs `C8_backup_20261002` / `C10_backup_20261002`. Gotcha: FastRenderMesh-vertex cover checks gave bogus low numbers (91~104) — sample BrepFace.PointAt grid instead.
+- **2026-10-02 color fix #3 (station level):** C13~C17 still drew tan (coping layer color) because their STATION-level instances inside the mark idef were `ColorFromLayer` on layer `P1_두부(코핑)` (C12/C18 stations were already `ColorFromParent`). Fixed by `ModifyGeometry(markIdef, geoms, attrs)` forcing station attrs to ColorFromParent for C13..C17 — all 3 nesting levels (station/box/leaf) must be ColorFromParent. Also found 7 stray C18 box instances (C18_1250_01/C18_1005_01/_19) floating at Z≈17000~21300 on the coping layer — leftovers; DELETED 2026-10-02 with user approval (coping layer now holds 3 objs: coping Brep + 2 curves).
+- Views: "Left" viewport camera rotated to coping long axis (19.105° from world X); the 4th viewport (was a 2nd Perspective) converted to parallel, renamed "Front", looking along 109.105°, Wireframe. Geometry untouched.
+- **RESOLVED 2026-10-02 via DXF (`철근재료표 및 상세(P1~P3,P5~P8).dxf` + `코핑구조도(P1~P3,P5~P8).dxf`): C8/C10 have NO 2CYCLE counterpart — standalone by design.** Material table 주철근 group = only C1~C11 (C8, C10 = shape VII, H25, 14EA each, A=630/B=4.167/C=3.159/D=2.331, X1=159°/X2=162°, L=10.287m; no other VII mark). 주철근 조립도 ①CYCLE view labels C1,C2,C3 (top) + C8,C9,C10 (bottom); ②CYCLE view labels C4,C5,C6,C7 (top) + C11 only (bottom). Every mark's own callout is "@250" (14 bars across 3.5m), so 250 is per-mark spacing, not a 1+2CYCLE interleave result. Remaining unbuilt marks from table: C19(VI,H16,4), C20(VIII,24), C21(VI,5), C22(VIII,30), C23(VI,6), C24(VIII,36), C25(III,114) — all H16. Original question history follows: does C8/C10 have a missing 2CYCLE counterpart mark? User asked to re-verify why bottom main rebar's 1CYCLE/2CYCLE marks show "250mm spacing" — investigation found: (a) 2CYCLE layer only has C4,C5,C6,C7,C11 — no mark shaped like C8/C10 exists in 2CYCLE at all; (b) C8's own 14 bars are independently spaced at ~250mm CTC on their own (measured via consecutive-leaf tip-point distances, consistently 242-250mm), and C1's own 14 bars show the exact same self-sufficient ~250mm pattern — i.e. neither C1 nor C8 actually NEEDS a 2CYCLE partner to reach 250mm (contradicts an initial assumption that 1CYCLE alone would be at 500mm, needing 2CYCLE interleaved to densify to 250mm); (c) meanwhile C9(1CYCLE)+C11(2CYCLE) ARE an explicit interleaved pair (C11's own description literally says "interleaves between 1CYCLE bars"), and C1(120mm cover)+C4/C6(120mm cover) / C2,C3(220mm cover)+C5/C7(220mm cover) match up by cover value too. Given this mixed pattern, **could not determine from Rhino geometry alone whether C8/C10 are correctly standalone (no 2CYCLE partner by design) or are missing a not-yet-modeled 2CYCLE counterpart** — needs the user to check the material table/배근도 directly.
+
+**Why:** these are drawing-derived facts and hard-won modeling corrections not re-derivable from the Rhino scene alone — several rounds of wrong shapes/positions occurred before landing on the above (see [[feedback_coping_haunch_rebar_method]] and [[feedback_ironpython_exec_scoping]] for the mechanics/gotchas). Re-deriving any of this from scratch would repeat the same mistakes.
+
+**How to apply:** when continuing P1's cap-beam rebar (C15 not yet done — its own B value is a single 2.431m, not a range, per the material table; other marks beyond C26 not yet started), reuse the exact station/box/color conventions above rather than re-deriving. Always verify new block-instance placements by comparing bounding-box X against the expected world coordinate before trusting it (see [[feedback_ironpython_exec_scoping]] on `AddBlock`'s unreliable re-basing).

context-migration/memory/project_pier_program_state.md

@@ -0,0 +1,16 @@
+---
+name: project-pier-program-state
+description: "New rebar program at D:\\Rhino-MCP\\pier-program — status after T-001~T-007 (2026-10-07), what to do next (T-008, T-009) and open questions"
+metadata:
+  node_type: memory
+  type: project
+  originSessionId: 1d08867c-dad9-4bc6-97dc-96e9d602d811
+  modified: 2026-10-07T07:23:07.441Z
+---
+
+새 교각 철근 프로그램은 `D:\Rhino-MCP\pier-program` (git, 브랜치 master, 사용자명 yjahn). 2026-10-07 기준 T-001~T-007 완료, 테스트 119개 통과, 커밋 7개(마지막 fddf8de). 기존 `rhino-mcp-main\rebar_pipeline`은 참고용이라 수정하지 않는다 ([[reference-rebar-pipeline-scripts]], [[project-rebar-pipeline-program]]).
+
+**Why:** 사용자가 교각 프로그램을 처음부터 작업규칙(테스트 먼저, docs/ 문서화, scripts/ 재사용, tasks.md 번호 커밋)으로 시작하길 원했다. 규칙 원문은 `D:\Rhino-MCP\pier-program\CLAUDE.md`.
+**How to apply:** 새 세션에서 `docs/next_steps.md`, `docs/tasks.md`, `docs/paths.md` 순서로 읽고 이어간다. 다음은 T-008(재료표 DXF, CP949·왼쪽정렬 지원 여부를 사용자에게 먼저 확인)과 T-009(Rhino 연결 코드; 레이어 이름 규칙·형상 코드 I~VIII 일반화를 사용자가 먼저 정해야 함). 응답 끝에는 쓴 경로를 항상 적는다 ([[feedback-always-show-paths]]).
+
+환경: Python 3.12.10은 `C:\Users\User\AppData\Local\Programs\Python\Python312\python.exe`(새 터미널 전에는 PATH에 없을 수 있음). 용량 큰 패키지가 필요하면 C가 아니라 `D:\Rhino-MCP\pier-program\.venv`에 설치(C는 여유 357GB지만 사용자가 D 선호).

context-migration/memory/project_pyeonggang1_modeling_standard.md

@@ -0,0 +1,15 @@
+---
+name: project-pyeonggang1-modeling-standard
+description: 평강1교 P1 pier DXF drawings are the house baseline standard for structure and rebar modeling to be reused across future bridge projects in this Rhino-MCP workflow
+metadata: 
+  node_type: memory
+  type: project
+  originSessionId: 3f00c5a2-89d3-4ff6-bce0-294eebc0a639
+  modified: 2026-09-16T06:54:22.530Z
+---
+
+The user's current Rhino modeling ("교각 모델링 연습.3dm" / "평강1교 test.3dm" — P1 pier: cap, column, cast-in-place pile, rebar cages C1–C11 in 1CYCLE/2CYCLE groups) is being built from the two 평강1교 DXF drawings described in [[reference-pyeonggang1-dxf]].
+
+**Why:** the user stated that once this pier model is finished, the same base drawing content (layer conventions, bar-shape/number block system, cap/column/pile geometry rules, rebar cycle grouping, coupler/spacer/tie-bar detailing conventions) will be reused as the standard for structure and rebar modeling on *other* (future, different-bridge) projects — not just this one.
+
+**How to apply:** when a future project asks for pier/column/pile structure or rebar modeling in Rhino, treat the 평강1교 drawing conventions as the default template unless the new project's own drawings say otherwise — e.g. the `CSBSHPE-*` bar shape codes, `CSBNUM1` bar numbering, 1CYCLE/2CYCLE rebar layer split, C.T.C tie/cross-tie spacing pattern, coupler and shape-holding-rebar (형상유지철근) notes. Confirm with the user whether the new project supplies its own DXF (in which case that takes precedence) or whether to carry over 평강1교's conventions wholesale.

context-migration/memory/project_rampa_p1_review.md

@@ -0,0 +1,15 @@
+---
+name: project-rampa-p1-review
+description: "Ramp-A교 P1 도면↔모델 검토 1차 완료(2026-10-19) - 폴더(Ramp-A교P1, 검토_ 접두 없음), 코드 M-1~M-7, 산출물 위치"
+metadata:
+  node_type: memory
+  type: project
+  originSessionId: f46b47bc-9105-4079-9b62-fcbee31b26ae
+  modified: 2026-10-19T03:05:22.450Z
+---
+
+폴더 `D:\★Pier 자료\심수석님 검토 파일\Ramp-A교P1\` (사용자는 "검토_Ramp-A교P1"이라 불렀지만 실제 폴더명은 접두어 없음). 도면 4장: (3)=코핑 재료표·철근상세, (4)=기둥·말뚝 재료표(P계열 H16 SD400, P1·P1-1 H35·P1-2 H22 SD500). 모델 `ramp-A G5.3dm`(원본 불변) → `ramp-A G5_대조코드표식.3dm`. 산출물: `대조표_Ramp-A교P1_도면모델_분류_V2.xlsx`, `도면↔모델_불일치_시각자료\`, `검토기록_최종.md`, `도면내부_오류_보관.md`, `Ramp-A교 P1 교각(3)/(4)_도면검토_색구분.dxf`(+PNG).
+
+**결과** 본수 전부 일치. M-1 끝 겹침 c·j 모델 형상 없음, M-2 a=모델+48, M-3 b 단일값↔모델 변화·총길이 -49.9 m, M-4 C1~C5 다리 경미, M-5 커플러 115개 없음, M-6 KDS 내면지름 H25·H19, M-7 P2·P3 갈고리·겹침 미확인. 본 모델은 말뚝(P1-1·P1-2)이 있고 마크 이름에 하이픈이 있음(P1-1) → 곡선 이름 분해 대신 user string mark 사용. C6 는 곡선 폴리선이라 꼭짓점 치수 비교 불가(총길이 일치).
+
+산외교·옥성교와 같은 파이프라인([[project-okseonggyo-p1-review]], [[project-sanoegyo-p1-review]]). 3개 교량(산외교·옥성교·Ramp-A교) 1차 완료.

context-migration/memory/project_rebar_pipeline_program.md

@@ -0,0 +1,19 @@
+---
+name: project-rebar-pipeline-program
+description: User plans to build a program that generates rebar (DXF drawings → Rhino rebar → audit → material-table DXF); full validated method saved in rebar_pipeline/ folder
+metadata:
+  node_type: memory
+  type: project
+  originSessionId: 888d28a0-dc6f-4081-9e33-fb12bd0121be
+  modified: 2026-10-02T03:08:53.758Z
+---
+
+User (2026-10-02) asked to save the entire workflow because they intend to **build a program that generates rebar this way** later.
+
+Saved at `D:\Rhino-MCP\rhino-mcp-main\rebar_pipeline\`:
+- `README.md` — full method: environment limits, DXF reading (awk), material-table rules (V형 L=2A+2B+2C, 할증/겹이음 6.80%, unit weights), coping local frame + section, offset-120 centerline construction, KDS fillet+pipe, block/color rules, audit (isocurve centerline, LineLine virtual corners, BrepFace.PointAt cover sampling, box lid/base/lap measurement), R12 CP949 table writer, proposed module split.
+- `awk/txt.awk, geo.awk, ins.awk` — DXF text / line / insert extractors.
+- `rhino/01_section_profile.py, 02_build_shape_VII.py, 03_audit.py, 04_table_writer.py` — validated IronPython snippets.
+
+**Why:** these were hard-won in sessions on 대호지교 P1 ([[project_p1_pier_structure]]); the program should reuse them rather than re-derive.
+**How to apply:** when the user starts the program or any new pier/bridge rebar job, read that README first and extend the scripts; update the README whenever a new method is validated. Related: [[feedback_kds_rebar_bend_radius]], [[feedback_ironpython_exec_scoping]], [[feedback_coping_haunch_rebar_method]].

context-migration/memory/project_sanoegyo_p1_review.md

@@ -0,0 +1,21 @@
+---
+name: project-sanoegyo-p1-review
+description: "산외교(울산) P1 도면↔모델 검토 1차 완료(2026-10-19) - 산출물 위치, 코드 M-1~M-8, 남은 일, 다음은 옥성교·Ramp-A교"
+metadata:
+  node_type: memory
+  type: project
+  originSessionId: f46b47bc-9105-4079-9b62-fcbee31b26ae
+  modified: 2026-10-19T02:12:58.848Z
+---
+
+2026-10-19: 운곡교와 같은 방식으로 다른 교량 3개(산외교·옥성교·Ramp-A교)를 검토 시작. 첫 번째 산외교 P1 1차 완료. 범위는 모델↔도면만, 도면 내부 오류는 `도면내부_오류_보관.md` 에만 기록 ([[feedback-review-other-bridges-scope]]).
+
+**폴더** `D:\★Pier 자료\심수석님 검토 파일\검토_산외교P1\` — DWG→DXF 는 라이노 headless 문서(`RhinoDoc.CreateHeadless` → `Import` → `Export`)로 변환(열려 있는 모델 영향 없음, 별도 변환기 없음). 대조 엑셀 `철근재료표_도면_모델_대조.xlsx`, 스크립트 `스크립트\make_bom_compare_sw.py`(운곡교 make_bom_compare.py 변형: 표 열 x 범위·형상별 치수 추출은 산외교 전용), 기록 `검토기록_최종.md`, 표식 모델 `산외교P1 G5_대조코드표식.3dm`(표식 레이어 `P1::검토표시_코드표`, M-1~M-8).
+
+**결과 요약** 본수 전부 일치, 차이는 J/C 길이 모델 형상 미작도(M-2), 일부 철근 짧음(M-1), +54 산식(M-3), C10 A 최대(M-4), B8 정사각(M-5), 주철근 커플러 476 없음(M-6), H22/H19 내면지름(M-7), 커플러 각도 가정(M-8).
+
+**남은 일** 색 구분 DXF, 4자 분류 대조표·캡처, 좌표 기준 위치/피복/간격 점검. **다음** 옥성교P1(옥성교P1.dwg, 옥성교P1_G5.3dm), Ramp-A교P1(`Ramp-A교 P1 교각(1)~(4).dwg`, ramp-A G5.3dm) — 사용자가 해당 모델을 라이노에 연결하면 같은 방식으로.
+
+**교훈** 도면 DXF(R2010) 텍스트는 UTF-8 (ezdxf 기본값 사용, cp949 지정 금지). 터미널 출력 한글은 깨져 보이므로 파일로 쓰고 Read 도구로 읽을 것. 재료표의 J 열은 L 에 포함되지만 이 모델 생성기는 형상에 그리지 않음.
+
+**2026-10-19 위치·CTC 점검 완료** 기초·기둥·코핑 스터럽 위치 전부 일치(점·수직선 기준), 신규 M-10(코핑 스터럽 상 +26.5/하 -27.5), 엑셀 ⑤ 시트 추가. 미확인: 코핑 C1~C6 높이·C14·C15·S. 스크립트 scratchpad sw*.py (swdots.py 등).

context-migration/memory/project_ungokgyo_b10_shape_error.md

@@ -0,0 +1,19 @@
+---
+name: project-ungokgyo-b10-shape-error
+description: "운곡교P1 기초 B10 — 모델 철근 형상 자체가 잘못 만들어짐(형상 오류), 개수 9본은 맞음 (사용자 지적 2026-10-16), 수정 방향 확인 대기"
+metadata:
+  node_type: memory
+  type: project
+  originSessionId: a82a1be1-cf11-4d33-988f-0c35b9b726d4
+  modified: 2026-10-16T05:32:07.256Z
+---
+
+운곡교 P1 기초 **B10(S19, 형상 XIII)**: 사용자가 "철근 형상 자체를 잘못 만들었다 — '철근 형상 오류'로 적고 바꿔 놓으라"고 지시. **개수(9본)는 맞다.**
+
+**Why:** 대조표에서 B10 을 "일치"로 판정했지만 그건 개수·치수 A·B(9.198×7.644)·길이(33.684 m)만 비교한 결과였고 형상은 비교하지 못했다. 모델 B10: 평면 사각(x ±4599, y ±3822) 닫힌 고리 9단(@200), 모서리 필렛 R42.75, 시작/끝이 -X 변 중앙에서 맞닿음(겹침 없음).
+
+**도면 쪽 형상(3.dxf 가공도 XIII, 직접 확인)**: 직사각형 a×b 에 겹침 구간 j 가 있는 닫힌 형태(그림에 변 중앙 바깥쪽 짧은 선 2개와 j 치수). 재료표 L 33.684 = 2(a+b) 로 j 는 길이에 안 들어감, 표의 J 칸 빈칸. 정면도/측면도에서 B10 은 S19 @200, 측면 수평 띠(9@200=1.800 표기, 개수는 9).
+
+**현재 지시 (2026-10-16): 바꾸지 말고 기록만.** 지금 단계는 내가 도면을 인식 못 하는 부분을 사용자가 찾아내는 작업이라 모델·엑셀·DXF·표식은 수정하지 않는다. 올바른 형상을 되묻지도 않는다(사용자가 파악 중). [[feedback-ungokgyo-unrecognized-items-record-only]]
+
+**How to apply (수정 지시가 나중에 올 때만):** 올바른 형상이 정확히 무엇인지(겹침 j 위치·방향, 갈고리 유무, 고리 평면 위치 등)는 사용자 확인 필요 — 확정되면 B10 9본을 그 형상으로 다시 만들고(기존 B10 삭제 전 사용자 확인), 엑셀·DXF 대조표 B10 판정을 "형상 오류(모델)"로 정정, 표식 D-18/M-10 내용 갱신. 수정 전까지 B10 은 "형상 오류"로 기록. 관련: [[project-ungokgyo-p1-model-bom]], [[project-ungokgyo-b12-34-correct]]

context-migration/memory/project_ungokgyo_b12_34_correct.md

@@ -0,0 +1,20 @@
+---
+name: project-ungokgyo-b12-34-correct
+description: "운곡교P1 기초 B12 는 도면 재료표대로 34본이 맞음 — 모델 28본·D-16 '도면 내부 불일치' 판정은 내가 도면을 잘못 읽은 것 (사용자 정정, 2026-10-16)"
+metadata:
+  node_type: memory
+  type: project
+  originSessionId: a82a1be1-cf11-4d33-988f-0c35b9b726d4
+  modified: 2026-10-16T05:19:33.409Z
+---
+
+운곡교 P1 기초 철근 **B12(S16)는 재료표의 34본이 맞다**. 도면이 간소화되며 작도에서 일부가 지워져 28곳만 남아 있었을 뿐이다. 정면도에서 개수를 셀 수 있고, 간격 1000, 한 줄이며, 단면도에서 보면 400 위치에 엇갈려서 1000 간격으로 들어가는 철근이다.
+
+**기록 방식 (사용자 지시)**: B12 수량 오류는 "간소화된 도면을 내가 정확히 인식하지 못해서 생긴 것 → **설계자의 판단이 필요한 부분**"으로 적어 둔다. 적용 위치: `검토_운곡교P1\검토기록_최종.md` 7-1, `README_내일시작.md`, `스크립트\make_bom_compare.py` 의 NOTE["B12"](다음 재생성부터 엑셀·DXF 비고에 반영).
+
+**Why:** 내가 도면을 잘못 읽어 B12 를 28본으로 배치했고, 그걸 "재료표 34 ↔ 작도 28 = 도면 내부 불일치(D-16, 선행 E-05)"로 보고했다. 실제로는 도면이 맞고 모델 배치가 틀린 것(도면↔모델 불일치로 분류가 바뀜).
+
+**How to apply:**
+- B12 를 다시 다루면 34본 기준(간격 1000, 단면도 400 위치에서 엇갈림)으로 모델을 고쳐야 한다. 사용자가 "그냥 기억해둬"라고 했으므로 지금은 모델·엑셀·DXF·표식을 수정하지 않았다 — 수정 요청이 오면 그때 B12 재배치와 대조표(②모델, ③ 비고, D-16 → M 코드로 이동), 표식 D-15~D-18 내용을 함께 고칠 것.
+- 도면과 모델이 안 맞을 때 도면 쪽을 "내부 불일치"로 결론 내리기 전에 정면도·단면도를 다시 읽고 규칙(간격·엇갈림)을 찾을 것. 같은 이유로 기초 철근의 다른 "작도 N곳 ↔ 재료표 M본" 판정도 의심해 볼 것.
+- 관련: [[project-ungokgyo-p1-model-bom]] (D-16 기록, 대조 결과 B12 34↔28), [[feedback-ungokgyo-review-workflow]]

context-migration/memory/project_ungokgyo_m8_m9_cause.md

@@ -0,0 +1,20 @@
+---
+name: project-ungokgyo-m8-m9-cause
+description: "기초 교차 철근을 도면(겹침·같은 높이)과 달리 어긋나게 배치한 것은 모델 쪽 오류 - 운곡교 M-8·M-9, 산외교·옥성교 M-9 (사용자 지시 2026-10-19)"
+metadata:
+  node_type: memory
+  type: project
+  originSessionId: f46b47bc-9105-4079-9b62-fcbee31b26ae
+  modified: 2026-10-19T05:47:39.717Z
+---
+
+2026-10-19 사용자: 도면은 교차 철근을 겹쳐 같은 높이에 그렸고, 모델 작성 시 AI 가 간섭을 피해 어긋나게 배치했는데 "간섭을 피하라"는 지시는 한 적이 없으므로 **이것도 오류사항**이다.
+
+**사례** 운곡교 M-8(교차 간격 27~28 ↔ 54~56)·M-9(B5 73·B6 다리 끝 72·B2 128 ↔ 도면 100). 산외교 M-9: B1~B6 중심이 도면 선(상면 -100/하면 +150)과 ±22.5 (H22 지름 정도). 옥성교 M-9: B5~B8 만 ±22.5 (B1~B4 일치). Ramp-A교는 말뚝 기초라 해당 없음. 도면 철근선은 DXF 정면도·측면도 수평 CS-RBAR 선(기초 외곽 CS-CONC 선 기준)에서 읽음.
+
+**Why:** 모델이 임의로 만든 간섭 회피 배치는 도면과 다른 가정이므로 도면↔모델 불일치로 분류.
+**How to apply:** 새 교량 검토 시 기초 철근 중심 높이를 도면 철근선과 대조(코드 M-n 도면↔모델). 종합 엑셀 C-8 (`4개교_공통사항_종합.xlsx`). 산외교·옥성교 모델(.3dm) 표식에는 M-9 가 아직 없음(모델 연결 시 추가).
+
+**확인 범위(2026-10-19)** 하부 기초 피복 비교는 치수 글자가 아니라 DXF 작도 선(철근 선·원)과 모델 중심선을 비교. 산외교 B1~B6, 옥성교 B5~B8 불일치(M-9). Ramp-A교 말뚝 주철근은 작도 선 반지름 ~1000 = 모델 999.5 일치 (도면 단면 치수 225/1025 만 작도와 달라 도면 내부 D-6). 도면 치수 글자와 작도 선이 다를 수 있으니 항상 선 기하로 확인할 것.
+
+**2026-10-19 반례 발견(중요)** 산외교·옥성교는 도면 단면의 철근 점(원 지름 22.5 안쪽, DXF 는 모두 LINE 다각형)이 모델 높이와 0.0 mm 일치 (산외 B1 77.5/B4 122.5/B3 127.5/B6 172.5, 옥성 측면 점 321527.3/323432.3). 철근 선(100/150)과 점이 도면 안에서 다른 것. 엑셀 M-9 에 주석 추가, 사용자에게 보고. 운곡교 M-8·M-9 는 점으로 아직 안 확인 → 확인 필요. 방법: swdots.py (LINE 다각형 군집 → 원 중심).

context-migration/memory/project_ungokgyo_p1.md

@@ -0,0 +1,31 @@
+---
+name: project-ungokgyo-p1
+description: "운곡교 P1 (완도방향) 철근 도면↔모델 일치 검토 — 위치, 진행 범위, 확정된 결과, 남은 결정 사항 (2026-10-15 기준 최종)"
+metadata:
+  node_type: memory
+  type: project
+  originSessionId: 53f62976-8c81-4fad-b764-69ad691f1791
+  modified: 2026-10-15T05:43:36.089Z
+---
+
+현재 Rhino 에 열려 있는 모델은 대호지교가 아니라 **운곡교 P1** (레이어 이름만 보고 프로젝트를 추측하지 말 것). 철근을 재료표 순서대로 사용자와 같이 검토 중이며, 목적은 나중에 "정면도·단면도·모델·재료표 일치/불일치 표 보고서"를 만드는 것.
+
+**위치**
+- 원본: `D:\★Pier 자료\심수석님 검토 파일\철근 모델랑 운곡교P1_바이브코딩\` — `1.dxf`(교각도1 정면도·단면 A-A·B-B) `2.dxf`(교각도2 받침·S1/S2 상세) `3.dxf`(재료표) `운곡교p1.3dm` + 선행 검토보고서 PDF(심영표 v0.1.00, 미확정). 원도면 `D:\★Pier 자료\교각자료\도면 _운곡교`.
+- 검토 산출물(최종): `D:\★Pier 자료\심수석님 검토 파일\검토_운곡교P1\` — `검토기록_최종.md`(전체 기록·정정 이력·좌표, 먼저 읽을 것), `대조표_C1-C16_도면모델_분류.xlsx`(보고서용 표), `1/2/3_도면검토_색구분_*.dxf` + PNG, `스크립트\`, `추출데이터\`. (`1_검토표시_노랑_C1-C6.dxf` 는 다른 프로그램에서 열려 있어 삭제 못 한 이전판 → 닫으면 지울 것)
+- 기둥 띠철근 간격(선행 E-01)은 구조계산서에서 확인할 사항.
+
+**검토 범위/결과 (2026-10-15)**: 코핑 C1~C16 + S1·S2 + 기초 B1~B12 완료. 기초: 본수·길이·간격·총길이·B11/B12 높이는 일치하나 M-8 모델이 점 값을 서로 다른 뷰에서 가져와 교차 철근 간격 54~56mm(도면 27~28), M-9 B5 중심 73 아래(피복 58.5), M-10 내면지름 S25·S19 가 공칭 기준에 1.3/0.3mm 부족; 도면 내부는 점/선 높이 27~28mm 차, B12 34↔28, B3 치수 33@250+450↔38본, B10 9@200(10단)↔9단. 코핑 철근 높이·가로 위치·본수·치수는 정면도·단면 A-A·B-B·단면도·모델이 거의 모두 일치. 도면↔모델 불일치: M-1 C14 최하단 점 2개 모델이 350mm 높음, M-3/M-4 굽힘 내면반지름(C7·C8 각진 연결, C1~C6 여유 거의 없음), M-5 +54.3 산식 범위, M-6 S1·S2 높이 기준(도면 대좌 상면 -50 ↔ 모델 코핑 상면 -50), M-7 S1·S2 층 순서. 도면 내부 불일치: 단면 점 +4.5mm, A-A 하면 110↔100, 단면 스터럽 높이 +45mm, 스터럽·폐합근 폭 1.407↔단면, 재료표 L (최대+최소)/2 근사(총길이 차이 주원인), C2·C5 L 1mm, 다리 각도 반올림, C7·C8 재료표 빈칸 등. 상세는 기록 파일 참조.
+
+**기둥 P1~P6 완료**: P1·P2 46본·길이·하단 훅(EL 26.508)·P3/P4/P5/P6 단 수·높이 일치. 도면 내부: D-20 P1/P2 상단 정면도 43.011/40.411 ↔ 재료표 43.061, D-21 반지름 875 ↔ 점 870.5, D-22 링 902 ↔ 897, D-23 P4·P5 라벨 @100 ↔ 치수 @120(계산서 확인). 기준↔모델 M-11 P3 갈고리 연장 86.7<5db(95)·내면지름 66.5(공칭 66.85), 미확인 M-12 이음·커플러 각도 기준 없음.
+
+**받침(대좌·패드·받침·솔플레이트) 완료**: D2 ELEVATION TABLE 값(h1 164/139, h2 50, h3 181, A·B, 패드 (A+200)x(B+200), 솔플레이트 L·W·T·S, E, EL.X, 받침 중심 Y -698/+600, S1 852/S2 1298/S1 950 = 3100) 모델과 일치. 도면 내부만: D-24 D1 단면도 전열 대좌 169.4↔표 164, D-25 D1 평면도 후열 패드 840↔표 740. 미확인: 전열 회전 4.4°, 솔플레이트 경사 방향.
+
+**남은 항목까지 완료 (간섭 제외, 사용자 지시)**: UA1 은 모델에 없음(M-13, 73본 H22, 도면은 배치 예시도). 교량받침 연단거리 적용 472.7 ↔ 모델 #3 받침 472.9 일치(N 1503.3 은 모델 대응 미확인). 기둥 단면: P1/P2 46분할 0°부터 7.826°, 870.5/825.5 일치. 평면도 받침 회전 4.4°/3.1° 일치. 해소: B-B 상면 -100 전폭 선 = 뒤쪽 C14 상단 연결근, D1 평면도 S1/S2/S1 = 치수 이름, D2 전열 상세 139 = 후열 값(D-14), P1/P2 상단은 D1·D2 가 같고 재료표만 다름. 확인 불가: 정면도 좌측 반쪽 항목, C14 훅 방향, B9 수량, S1·S2 보강 대상(전열만/쌍), P3 이음·커플러 각도, 솔플레이트 경사 방향. **현재 표: 105항목 (일치 59, 도면 내부 27, 도면↔모델 7, 기준↔모델 4, 간접 확인 3, 미확인 5)**. 사용자가 이 자료를 한 번 더 검토할 예정. 도면에 없는 항목은 재료표·형상·기하 제약으로 "간접 확인"(추정)을 시도해 구분함: C14 훅 방향(하부 점은 위, 상부 점은 아래로 보임 → M-1 모델 350mm 상향은 불필요 가능), 좌측 반쪽(재료표로 간접), S1·S2 격자는 쌍 전체, B9 493 정합. 끝까지 미확인: P3 이음·커플러 각도, 솔플레이트 경사 방향, 연단거리 N 1503.3, UA1 배치 근거, C14 훅 방향(추정만).
+
+**미검토**: 코핑 철근 간 간섭(선행 4.3) — 사용자 지시로 제외.
+
+**Why:** 사용자가 도면과 모델링의 일치가 최우선, 도면 내부 불일치는 따로 분리해서 보고서 표로 만들 예정.
+**How to apply:** 새 마크 검토 시 4자(정면도·단면·재료표·모델) 대조 후 대조표 시트 ③에 행 추가, 분류(도면↔모델=주황 / 도면 내부=노랑 / 일치=초록 / 미확인=회색)에 따라 시트 ①·②에 반영. [[feedback-ungokgyo-review-workflow]]
+
+**기술 메모**: 정면도 EL 환산 EL(m)=43.411+(y−19515.6)/1000 (최저 상면은 왼쪽 끝 y=19515.6 — 오전에 y=19659.3 으로 잘못 잡았다 정정함). S=1:30 상세는 좌표 2배. 모델 중심선 이름 `P1-RC-<마크>-…`(레이어 `P1::철근::중심선`), Rhino 서버 스크립트 `D:\Rhino-MCP\rhino-mcp-main\rhino_mcp\rhino_mcp_client.py`. execute_rhino_code 는 Rhino 8 Python3, print 출력이 안 돌아오므로 파일로 쓸 것.

context-migration/memory/project_ungokgyo_p1_model_bom.md

@@ -0,0 +1,37 @@
+---
+name: project-ungokgyo-p1-model-bom
+description: 운곡교P1 모델 기준 철근재료표 재작성 + 도면 재료표 대비 비고 (2026-10-16 산출물 위치·방법·결과)
+metadata:
+  node_type: memory
+  type: project
+  originSessionId: a82a1be1-cf11-4d33-988f-0c35b9b726d4
+  modified: 2026-10-16T05:18:38.809Z
+---
+
+2026-10-16 사용자 요청: 도면 재료표(3.dxf)와 모델에서 작성된 철근으로 재료표를 새로 뽑고, 서로 다른 점을 비고란에 작성.
+
+**산출물**: `D:\★Pier 자료\심수석님 검토 파일\검토_운곡교P1\철근재료표_모델기준_비고.xlsx` (시트: 요약 / 철근재료표_모델기준 / 비고코드설명 / 모델_개별철근). 생성 스크립트 `...\검토_운곡교P1\스크립트\make_model_bom.py <pylib경로> <출력xlsx>` (rhino3dm·openpyxl·ezdxf 는 pip --target 폴더 필요; 3.dxf 와 운곡교p1.3dm 은 바이브코딩 폴더에서 직접 읽음).
+
+**최신판(사용자 요청 "재료표랑 똑같이 만들고 → 모델 재료표 → 대조·비고")**: `...\검토_운곡교P1\철근재료표_도면_모델_대조.xlsx` (시트: ④요약 / ①도면 재료표(재현) / ②모델 재료표 / ③대조·비고 / ⑤코드설명 / ⑥모델_개별철근), 스크립트 `스크립트\make_bom_compare.py` (앞의 `철근재료표_모델기준_비고.xlsx`·make_model_bom.py 는 1차판). 모델 치수 A~J 는 중심선 직선을 연장한 꼭짓점 사이 거리로 추출(C1~C8·기초·S·P1·P4·P5·B9·B10 도면과 일치), P3 A·B 는 추출 불가(미추출 표시), IV/X 는 user string(w_model, b_sched, a_sched). 판정: 일치 21 / 반올림 5 / 도면빈칸·미추출 4(C7·C8 R, P3, B9) / 차이 7(C9~C13, UA1, B12).
+
+**도면(DXF)판 (사용자: "엑셀은 비교가 힘들다")**: `...\검토_운곡교P1\3_재료표_도면모델대조.dxf` (+ `_SD400.png`/`_SD500.png` 미리보기). 마크마다 위 줄=도면값, 아래 줄=모델값, 다른 칸 색(레이어 `대조_다름(주황)` 등), 오른쪽 판정/비고/비고3(KDS, 자홍 ACI 6). 스크립트 `스크립트\make_bom_dxf.py <pylib> <추출데이터\재료표_대조결과.json> <출력.dxf>` — JSON 은 make_bom_compare.py 가 xlsx 와 함께 생성. 3.dxf 의 스타일·레이어를 상속하고 내용은 비운 뒤 새로 그림, 글자 스타일 KR_TBL(malgun.ttf). 엑셀이 열려 있으면 xlsx 저장 실패(PermissionError)하나 JSON 은 갱신됨.
+
+**방법(1차판)**: 모델 철근 Brep 의 user string(mark, dia, shape, design_length, coupler_length)을 마크별 합산 = 재료표식 길이(각진 치수 합+커플러), 중심선(`P1-RC-<mark>-<occ>`) 샘플링 길이 = 굽힘 반영 실길이. P3·P4 는 반원 2조각=1링으로 개수 환산. 도면 표는 3.dxf TEXT 를 x/y 로 파싱(합계가 도면 인쇄값과 일치 검증함).
+
+**결과**: 개수·길이 불일치 UA1(모델 없음 -377.848 m), B12(34↔28본 -46.8 m), C9~C13 길이(-98.104 m = 폭 1.407↔작도값 -20.948 + 근사 -77.156). 나머지 일치. SD400 총길이 도면 5801.619 / 모델 5325.667, SD500 4990.106 / 4943.309. 비고 3 열은 KDS 기준 상이(마젠타 글자).
+
+**현재 상태 (2026-10-16 오후 저장)**: 엑셀·DXF 대조본 + 모델 코드 표식(21세트) 모두 완성, 사용자가 표식을 하나씩 확인하는 단계 ("보고 하나씩 확인해 볼께"). 아래 '표식 최종판'·'표식 내용·색' 항목이 최신. 검토에서 틀린 판정이 나오면 해당 칸만 도면·모델 재측정 후 NOTE/KDS 사전 수정 → make_bom_compare.py → make_bom_dxf.py 순서로 재생성. 미해결: C7·C8 굽힘 반지름 모델 수정(라이노 객체 변경 전 사용자 확인), P3 A·B 모델 치수 미추출, 겹이음 6.8% 총계 행 산식 불명(모델 미산출).
+
+**모델 표식 파일 (2026-10-16)**: 엑셀 ⑤비고코드설명의 M-/D- 코드 위치를 라이노 모델에 표식으로 넣어 새 파일 `...\철근 모델랑 운곡교P1_바이브코딩\운곡교p1_대조코드표식.3dm` 로 저장(원본 운곡교p1.3dm 은 그대로). 레이어 `P1::검토표시_대조코드::{주황_도면모델 10 / 노랑_도면내부 14 / 진한노랑_기준모델 8 / 회색_미확인 4}`, 코드당 구슬(R150)+지시선+TextDot(이름 `대조_<코드>`, user string code/text), 총 36개(M-1~M-13, D-4~D-9, D-15~D-18, D-20~D-23). 기존 `P1::검토표시`(선행 E-/M- 코드 14세트, 42객체)는 사용자 허락(2026-10-16)으로 새 파일에서만 삭제함(레이어는 빈 채로 남김, 원본 운곡교p1.3dm 에는 그대로 있음, 삭제 직전 상태는 `운곡교p1_대조코드표식.3dmbak`). 위치는 중심선 좌표로 계산(마커 목록 JSON 은 세션 임시폴더), 도면에 위치가 없는 M-13(UA1)은 기초 중앙 임의 위치. SaveAs 로 라이노 현재 문서가 새 파일로 바뀜.
+
+**표식 최종판 (2026-10-16 오후)**: 36세트가 너무 많다는 요청 → 사용자가 엑셀 ⑤비고코드설명 캡처(`검토_운곡교P1\너가 모델에서 찾아서 넣어야할 부분이 22개 내용이 이거야.png`, 표 행 21개 = M-1~M-13, D-4/D-5, D-6, D-7, D-8, D-9, D-15~D-18, D-20~D-23, E-01)를 기준으로 줌. → 코드 행당 1세트, 총 21세트를 `P1::검토표시_코드표::{주황·노랑·진한노랑·회색}` 에 추가(글자=코드만, 설명은 user string `text`·엑셀 코드표), 이전 36세트 `P1::검토표시_대조코드` 는 삭제하지 않고 레이어만 숨김(사용자 삭제 허락 시 삭제). 파일 `운곡교p1_대조코드표식.3dm` 저장됨.
+
+**표식 내용·색 (2026-10-16 오후, 사용자 "추천대로")**: 21세트 각 객체 user text 에 code/gu/content/marks/table_color/table_color_basis/detail(엑셀 ③ 비고 전체)/where 입력. 색·레이어는 엑셀 ③ 칸 색 기준: 차이(주황) M-5·M-13·D-4/D-5·D-6·D-15~D-18, 반올림(파랑) D-7, 빈칸·미추출(노랑) D-9, 나머지 14개는 '표에 안 잡힘(회색)' (위치·기준·미확인은 표 칸이 일치로 나오기 때문). 보기 스크립트 `스크립트\표식_내용보기.py` (RunPythonScript; 표식 선택 후 실행=내용 창, 선택 없이 실행=클릭 자동 창 켜기/끄기, 구문만 검사·창은 사용자 실기 테스트 전). 레이어는 이름만 바꿔 재사용(삭제 없음).
+
+**시작 스크립트·레이어 (2026-10-16 저녁)**: `스크립트\라이노_시작.py` = MCP 서버(9876) + 표식 자동 보기 한 번에(구문 검사만, 실행 테스트 전). rhino_mcp_client.py 와 표식_내용보기.py 는 별개라 동시 사용 가능하나, 표식 창이 떠 있으면 MCP 명령이 대기함 → 내가 라이노 작업할 땐 자동 보기 끄기. 사용자 요청으로 `P1::검토표시`, `P1::검토표시_대조코드`(+하위)는 끄고 잠금(삭제 없음), `P1::검토표시_코드표`만 켬.
+
+**정정 대기 (2026-10-16)**: B12 는 도면대로 34본이 맞음(내가 28본으로 잘못 배치·D-16 오판) → 이 문서의 엑셀·DXF·표식에 적힌 "B12 34↔28 도면 내부 불일치(D-16)"는 잘못된 판정, 사용자가 "기억만 해둬"라고 해서 아직 수정 안 함. [[project-ungokgyo-b12-34-correct]]
+
+**사용자 확인 사항**: 도면 재료표 치수는 철근 중심끼리 직선으로 이은 각진 치수(내면반지름 미반영)이고, 모델은 내면반지름을 넣어 그리는 것이 맞다 → 굽힘 때문에 모델 중심선 실길이가 짧은 것은 차이로 세지 않는다. [[feedback-kds-rebar-bend-radius]]
+
+**Why:** 사용자가 재료표를 도면↔모델 비교용으로 보고서에 쓸 예정. **How to apply:** 사용자가 표 검토 후 판정이 바뀌면 make_model_bom.py 의 NOTE/KDS 사전을 수정해 다시 생성. DXF 표(색 62 비고 3) 형태가 필요하면 별도 요청 확인. [[project-ungokgyo-p1]]

context-migration/memory/reference_final_scene_dump.md

@@ -0,0 +1,10 @@
+---
+name: reference-final-scene-dump
+description: Full Rhino scene snapshot of the FINAL P1 (대호지교) model saved 2026-10-06 as JSON
+metadata:
+  type: reference
+---
+
+`D:\★Pier 자료\클로드로 모델그리기\대호지교 P1\261006_FINAL_scene_dump.json` — user declared the Rhino model final on 2026-10-06 and asked for the whole scene saved. Contains: 119 layers (path/visible/locked/color), 47 doc-level objects (bbox, layer, idef, user strings, color), 641 instance definitions (name/use count/object count), 4 viewport cameras. Idef inner geometry is NOT dumped (only the .3dm has it).
+
+Related: [[project-p1-pier-structure]]

context-migration/memory/reference_kds_24_14_21.md

@@ -0,0 +1,17 @@
+---
+name: reference-kds-24-14-21
+description: STANDING RULE — KDS 24 14 21 (콘크리트교 설계기준, 한계상태설계법) is the base design standard for ALL projects; where the document/extracted text live, key numbers, and how deviations are reported
+metadata:
+  type: reference
+---
+
+User rule (2026-10-06): "모든 프로젝트에서 KDS 24 14 21 콘크리트교 설계기준(한계상태설계법)이 기본 원칙. 이거랑 다르게 배근된 철근이 있다면 철근재료표 비고란에 다른 색상으로 적고 저장". Also written into `D:\Rhino-MCP\rhino-mcp-main\CLAUDE.md` §0.
+
+- Source: `D:\★Pier 자료\KDS 24 14 21 콘크리트교 설계기준(한계상태설계법).hwp` (2025.08.22 개정, HWP5 binary, Hancom Office 2018 is installed but not needed).
+- Readable text incl. equations: `D:\Rhino-MCP\rhino-mcp-main\rebar_pipeline\kds\KDS_24_14_21.txt` made by `kds\hwp2txt.js` (own OLE/zlib parser, `node hwp2txt.js in.hwp out.txt`). Equations appear as `[수식: …]` lines right after their paragraph. Key sections by line: 4.4.4 cover, 4.5.2.1 bends (table 4.5-1), 4.5.3.1 spacing, 4.5.4.2 hooks, 4.5.5 laps, 4.6.2.6 shear, 4.6.2.8 skin, 4.6.15 temperature (re-grep, line numbers shift).
+- Numbers verified: min inner bend diameter D16↓ 2db, D19↑ 3.5db; horizontal clear spacing ≥ max(1.5db, 1.5Gmax, 40); multi-layer vertical clear ≥ max(25, db) same vertical plane; hook 90–150° extension ≥ 5db; shear s_long ≤ 0.75d(1+cotα), s_trans ≤ min(0.75d, 600), ρv,min = 0.08√fck/fy; lap lateral clear ≤ 4db/50; cover = max(c_bond=db, c_dur table 4.4-4: E0 20 … ED3/ES3 55) + Δc_dev 10; cover > 70 → skin reinforcement 0.005 A_ct,ext (4.6.2.8(4)). Lap length formula (4.5-8) needs σsd/fbd from design → NOT verified.
+- Reporting: deviations go to the material-table DXF as column "비고 3 (KDS 24 14 21 기준 상이)" in magenta (62=6, layer KDS) via `rebar_pipeline\dxf\kds_note_column.ps1` (needs a UTF-8 BOM when saved; CP949 can't hold ⊔ so write "U형").
+- 대호지교 P1 result 2026-10-06 (`261006_철근재료표_KDS.dxf`): satisfied = bend radii for ALL marks (inner R: C1/C2/C3/C8/C10 76.2, C26 57.3, C19/C21/C23/C25 31.8, hooks C20/22/24 52, C12–C18 all boxes/leaves centerline R=66.6 → inner 55.5, verified by length inversion); NOTE an earlier "C15 width-1005 inner R 34.6 < 38.85" finding was a MEASUREMENT ARTIFACT of the isocurve-curvature method — never trust it; hooks c=100 ≥ 5db=79.5; stirrup spacing & ρv; cover. Deviations noted: stirrups C12–C18 on main-bar centerlines (clear spacing <0) and coaxial lap legs; C19/C21/C23 hoops & C25 legs at w=±1630 on stirrup outer legs; C26 at stirrup lid-top height and legs crossing C4–C7; coaxial lap modelling of C1/C2/C3/C8/C10 ends. Clash-type rows are based on the 2026-10-02 clash check (not re-run after 10-06 edits).
+Related: [[feedback-kds-rebar-bend-radius]], [[project-p1-final-model-state-261006]], [[feedback-material-table-text-alignment]], [[reference-rebar-pipeline-scripts]].
+
+**Measuring bend radius — lesson (2026-10-06):** do NOT estimate bend radius from min curvature of pipe-surface isocurves (gave a false 34.6 for C15 1005 base; real R=66.6). Use length inversion: polyline S→C1→C2→E from the two end-circle centers + corner z (bbox ± bar radius), then R = (L_poly − L_centerline)/(2·(2−π/2)) with L_centerline = (area − caps)/(2πr). Verified identical R=66.6 on every box leaf.

context-migration/memory/reference_notes_md.md

@@ -0,0 +1,13 @@
+---
+name: reference-notes-md
+description: "Location of notes.md, a background-context file the user maintains summarizing prior Claude Desktop conversations about the P1 pier Rhino modeling work"
+metadata: 
+  node_type: memory
+  type: reference
+  originSessionId: 3f00c5a2-89d3-4ff6-bce0-294eebc0a639
+  modified: 2026-09-16T07:00:51.848Z
+---
+
+The user keeps a standing background note at `D:\Rhino-MCP\rhino-mcp-main\notes.md` (duplicated at `D:\Rhino-MCP\rhino-mcp-main\Claude outputs\notes.md`), written to let a fresh Claude Code session pick up P1 교각 (pier) modeling work without prior chat history. It covers two threads: (1) P1 pier cap-beam (두부보) rebar modeling — structure facts and the bend rule (now superseded: KDS 24 14 21 Table 4.5-1 only; KDS 14 20 50 is NOT used), captured in [[project-p1-pier-structure]] and [[feedback-kds-rebar-bend-radius]]; (2) Grasshopper section-extraction conventions and standing drawing rules, captured in [[feedback-section-drawing-rules]].
+
+When the user says "notes.md 읽고 시작해줘" or references past background/rules without repeating them, this file (and these derived memories) is what they mean. Re-read the live file if unsure it's still current — the user may append to it over time.

context-migration/memory/reference_pyeonggang1_dxf.md

@@ -0,0 +1,20 @@
+---
+name: reference-pyeonggang1-dxf
+description: Location and contents of the 평강1교 P1 pier baseline DXF drawings (general/bearing drawing + rebar structural drawing) used as the modeling reference standard
+metadata: 
+  node_type: memory
+  type: reference
+  originSessionId: 3f00c5a2-89d3-4ff6-bce0-294eebc0a639
+  modified: 2026-09-16T06:54:14.813Z
+---
+
+Two DXF drawings on the user's Desktop (`C:\Users\User\Desktop\`) serve as the baseline reference for 평강1교 (Pyeonggang 1 Bridge) P1 pier modeling in Rhino:
+
+- **`평강1교_일반도.dxf`** (일반도, ~884KB, 24 layers) — pier general arrangement / bearing (교량받침) drawing. Contains: 교각 일반도(1)/(2) (pier general elevation/section views), 교량받침 ELEVATION TABLE, 솔플레이트 상세 (sole plate detail), 연단거리 테이블 (edge-distance table), 기둥 단면도 A-A, 평면도/정면도. Design basis notes: KL-510 design load, fck=35MPa, fy=400MPa, 한계상태설계법 (limit state design), 도로교설계기준 (Korea Highway Bridge Design Standard), elastomeric bearing 2500kN 양방향 (bidirectional).
+- **`평강1교_.dxf`** (구조도/철근 상세도, ~4.6MB, 44 layers, 25 blocks) — pier structural rebar shop drawing. Contains 교각 구조도(1)/(2)/(3): full bar list (철근 재료표) with bar marks C1–C30(+variants), P1–P10, S1–S4, W1–W2, bar shape blocks (`CSBSHPE-A01/B00/B01/C01-C/D00/D01/G20/G57/G58/H07/H08/X12`), bar numbering blocks (`CSBNUM1`, `CSBNUM1-JEWON`), sections A-A through H-H, 주철근 조립도 (main rebar assembly, ①CYCLE/②CYCLE — matches the `1CYCLE`/`2CYCLE` layer split already used in the Rhino model), coupler (커플러) details incl. slip test note, spacer (간격재)/chair detail, tie-bar (띠철근)/cross-tie (크로스타이) spacing (C.T.C 150/300/400), shape-holding rebar notes for P8/P9/P10, rebar-rise prevention steel plate (철근올음방지철판) detail, splice-distribution note ("이음이 한 곳에 집중되지 않도록 분산").
+
+Bar diameters used: H13, H16, H19, H22, H25, H29, H32.
+
+Parsed via a Node.js DXF text-extraction script (group-code parser: layers, blocks, TEXT/MTEXT content) since no DXF library was available in the environment; UTF-8 encoded file. Use this same approach (or ezdxf if later installed) to re-extract on demand rather than re-reading raw DXF text.
+
+See [[project-pyeonggang1-modeling-standard]] for how this is used going forward.

context-migration/memory/reference_rebar_pipeline_scripts.md

@@ -0,0 +1,15 @@
+---
+name: reference-rebar-pipeline-scripts
+description: Where the reusable rebar/DXF scripts and method notes live (for other bridge projects) and what each does
+metadata:
+  type: reference
+---
+
+User wants everything from the 대호지교 P1 work kept so it can be reused on other projects. All reusable code + method is in `D:\Rhino-MCP\rhino-mcp-main\rebar_pipeline\` — READ its `README.md` first (sections 0–6; §5-4 added 2026-10-06).
+- `awk/` txt/geo/ins extractors for DXF drawings (no Python/ezdxf on this PC).
+- `rhino/01_section_profile.py`, `02_build_shape_VII.py`, `03_audit.py`, `04_table_writer.py` — section outline, shape builder, cover/clash audit, material-table DXF writer.
+- `rhino/05_realign_base_pieces.py` — realign ⊔ base pieces to the ⊓ lid plane (tangent move keeps cover, re-trim lap 510).
+- `rhino/06_flip_hooks.py` — mirror selected hooked bars about their own axis (counts-checked).
+- `rhino/07_ctc_extract.py` — leaf centroids in coping-local (s,t,z) → compare with drawing `@` CTC dims.
+- `dxf/leftalign.ps1` — left-align material-table texts at cell-left+200 (R12/CP949 DXF).
+Project-specific constants (origin 480714926/153833329.5, angle atan2(4255,12284)) sit at the top of each script — change them per project. Related: [[project-p1-final-model-state-261006]], [[feedback-isolate-rebar-layers-gotcha]], [[feedback-material-table-text-alignment]], [[project-rebar-pipeline-program]].

context-migration/memory/reference_review_pipeline.md

@@ -0,0 +1,11 @@
+---
+name: reference-review-pipeline
+description: "산외교·옥성교·Ramp-A교 검토에 쓴 스크립트 모음 위치 (D:\\Rhino-MCP\\rhino-mcp-main\\review_pipeline), 재사용 순서는 README"
+metadata:
+  node_type: memory
+  type: reference
+  originSessionId: f46b47bc-9105-4079-9b62-fcbee31b26ae
+  modified: 2026-10-19T03:29:22.039Z
+---
+
+`D:\Rhino-MCP\rhino-mcp-main\review_pipeline\` — DXF 글자 추출, 재료표·철근상세 파싱, 모델 치수 추출(rhino3dm), 라이노 캡처(cap.py·shots_*), 이미지 합성(compose_new.py), V2 엑셀(make_review_xlsx.py), 도면 표시 DXF(*_mark_dxf.py). 교량별 접두어 ok_/sw_/ra_. 새 교량은 ok_*(옥성교: 재료표에 A~J 열 없음)나 sw_*(산외교: 열 있음)를 복사해 시작. 관련: [[project-okseonggyo-p1-review]], [[project-sanoegyo-p1-review]], [[project-rampa-p1-review]].

context-migration/memory/reference_ungokgyo_p1_review_report.md

@@ -0,0 +1,36 @@
+---
+name: reference-ungokgyo-p1-review-report
+description: "운곡교P1 도면 검토보고서(v0.1.00, 2026-10-08, 작성 심영표, [미확정]) 전체 요약 — E-01~E-12 오류·불일치, M-01~M-10 누락, 재료표, 형상 I~XVII"
+metadata:
+  node_type: memory
+  type: reference
+  originSessionId: 53f62976-8c81-4fad-b764-69ad691f1791
+  modified: 2026-10-15T01:09:01.716Z
+---
+
+PDF: `D:\★Pier 자료\심수석님 검토 파일\철근 모델랑 운곡교P1_바이브코딩\보고서_운곡교P1교각도면검토_2026-10-08_v0.1.00.pdf` (한글은 PyMuPDF `fitz`로 추출해야 안 깨짐; pdftotext는 깨짐). `_빨간줄.pdf`는 텍스트 동일, 빨간 밑줄만 추가: **E-01~E-12 전 행 + M-01~M-03** ID칸에 표시(의미는 사용자에게 확인 필요).
+도면: D1=C0050205-025(평·정·단면 A-A~E-E), D2=-026(받침·ELEVATION TABLE·주철근 조립도), D3=-027(재료표 SD400/SD500·가공도). 원본 모델 보고서 쪽은 모델 3,190객체/철근 1,513본, 사용자 모델 파일은 운곡교p1.3dm. 상태 [미확정].
+
+## 2. 오류·불일치
+- 기둥: E-01 오류 P4·P5 띠철근 간격 D1 표기 H19@100 vs 치수 8@120=960, 22@120=2,640 (전체 17.203, 재료표 9·22본 일치 → @120 적용) **→ 사용자: 계산서 확인 사항**. E-02 불일치 주철근 상단 D1 P1 EL43.011/P2 40.411 vs D3 P1 a16.213·P2 16.553 → 둘 다 EL43.061 적용(P2 코핑 정착 2.65m 차이). E-03 확인필요 단면 C-C 치수 125·875 vs 작도 870.5(P1)/825.5(P2) → 875 쓰면 띠철근 R897 내면과 3.5mm 간섭. E-04 띠철근 R 897(D3) vs 898/902(D1) 경미.
+- 확대기초: E-05 B12(S16) 재료표 34본 vs 작도 28곳(6본 과다/작도 누락, 46.8m 0.073t). E-06 상면철근 피복 100 표기 vs 작도 B5 중심+2,127(피복 58.5)·B1 +2,073 (B6 다리 57.5).
+- 코핑: E-07 C9·C10·C11 스터럽 폭 D3 a=1.407 vs D1 A-A 작도 1,160/1,740/1,160 (본당 -107~-505mm). E-08 C12·C13 수평폐합근 폭 D3 b=1.407 vs 작도 1,106/1,686/1,106. E-09 재료표 치수=작도 중심선+54.3mm(외면/중심 기준 미표기).
+- 받침부: E-10 대좌 높이(3500kN) 작도 169.4 vs D2 표 h1=164 (5.4mm). E-11 후열(2800kN) 패드 작도 900×840 vs 표 (A+200)×(B+200)=900×740. E-12 솔플레이트 T1 38/T2 22 vs S=-1.901~-1.910%·L800·T30 → 37.6/22.4 (≤0.4mm).
+- 참고: ELEVATION TABLE EL.'X' = 코핑상면+h1+h2 (≤1mm 정합), E=h1+h2+h3+h4면 211mm 차 → 기준면 정의 필요.
+
+## 4. 추가 필요
+좌표·선형 없음(원점 0,0), 받침 10개소 좌표표, 솔플레이트 경사 방향(모델은 전열 3500kN 쪽 두껍게 가정), EL.'X' 기준 정의, 받침 회전(전열 4.4°/후열 3.1°). 철근 간섭(4.3): P6 크로스타이 4본 중심 교차·P1,P2 다발 관통 / P3 이음 갈고리 겹침 / B5·B6 ±4,575,±3,800 모서리 다리 겹침 / P1 갈고리 vs B7 / B9 기둥 내부 교차 / 코핑 스터럽 하단·C7·C8 같은 높이(EL40.511) / S1·S2 다리 700이 상면주철근 3단(EL43.111~43.311) 통과. 4.4: 변길이 철근 L=(최대+최소)/2, 커플러 길이 L 포함(P4·P5).
+
+## 5. 누락
+M-01 B9(H16) 수량 빈칸→1,062.415÷2.155=493본(34×29 체크무늬). M-02 상동(") 그룹 해석(B7·B10=S19, B12=S16). M-03 UA1 조립용 "배치간격 예시도"→모델 제외. M-04 형상VII(C7·C8) r1·r2·j 빈칸→하면 곡선 동심 R12,100 해석. M-05 형상XIV(P1) 커플러 위치 미표현. M-06 C14·C16 갈고리 방향·S1·S2 층순서 추정(C14 4본 갈고리 위로 변경). M-07 평면도 우측 절반만. M-08 정면도 우측 절반만(좌측 스터럽 상단 소단-100 추정, C9 최솟값 1,376 일치). M-09 하면 평면도 은선 원 r=1,100 무설명. M-10 단면 B-B 정밀확인 미실시.
+
+## 6. 재료표 (마크/형상/직경/본수/L m)
+기둥 P1 XIV S32 46 17.247 / P2 XVI S32 46 16.553 / P3 VI H19 36 6.436 / P4 V H19 9 5.636 / P5 IX H19 22 5.636 / P6 III H16 36 2.136.
+기초 B1 III S25 38 8.000 / B2 XII S25 38 11.500 / B3 III S19 38 8.000 / B4 I S25 35 7.600 / B5 XII S29 32 9.550 / B6 XII S29 32 13.050 / B7 XII S19 32 9.550 / B8 XVI S29 29 9.150 / B9 XI H16 (빈칸→493) 2.155 / B10 XIII S19 9 33.684 / B11 XII S16 28 9.350 / B12 III S16 34 7.800.
+코핑 C1·C4 VIII H29 12·12 14.490 / C2·C5 12.081 / C3·C6 12.106 / C7·C8 VII H29 12·12 13.994 / C9 IV H25 60 8.647 / C10 IV H25 21 10.310 / C11 IV H25 60 8.934 / C12 X H25 18 20.513 / C13 X H25 9 29.345 / C14 III H19 41 3.600 / C15 III H19 13 2.784 / C16 II H19 13 5.611.
+S1 III H19 50 3.800 / S2 III H19 105 2.500 / UA1 XVII H22 73 5.176. 합계 SD500 4,990.106m 21.552t, SD400 5,801.619m 19.388t. 단위중량 D32 6.230, D29 5.040, D25 3.980, D22 3.040, D19 2.250, D16 1.560 kg/m.
+
+## 7. 형상 (D3 가공도)
+I 직선 a / II 직선+한쪽갈고리 a+b / III 직선+양끝갈고리 a+2b / IV 닫힌스터럽+겹침 2a+2b+2c / V 반원2+커플러2 / VI 반원2+갈고리4 / VII 중앙수평+곡선+끝다리 / VIII 수평+꺾인다리2 / IX 링+커플러 / X 수평폐합+겹침 2a+2b+4c / XI 수직결속 하단90°·상단180° / XII 직선+양끝다리 a+2b / XIII 닫힌사각 / XIV 직선+90°원호+갈고리(P1 R340) / XVI 직선 / XVII 조립용. 굽힘: 도면 명시 R 우선(P1 R340, 띠철근 R897), 미표기는 D16↓2d·D19↑3.5d. P3 이음은 단마다 90° 엇갈림 적용(기준각 도면에 없음).
+
+작성자 자체 검증 보고서이며 "오류" 판정은 담당자 확정 전. 사용자는 이 PDF의 불일치 + 보고서가 놓친 오류를 철근 하나씩 같이 뜯어볼 예정(2026-10-15).

context-migration/교각모델링앱_요구사항.md

@@ -0,0 +1,156 @@
+# 교각 도면 모델링 앱 — 요구사항 검토 결과
+
+```
+소유자: 심영표
+확정일: 2026-10-08
+최근확인일: 2026-10-15
+재확인 조건: 앱 개발 착수·기술 기반 결정 시 / 두 번째 교각 도면으로 규칙을 검증할 때 / 요구사항 검토서 판이 바뀔 때
+```
+
+## 정본
+- `DOC/01_기획/기획_교각도면모델링앱요구사항검토_2026-10-08_v0.1.01.md` (확정, 9장 + 부록)
+- 근거: 운곡교 P1 실작업 전체(모델 v0.1.09, 판독서 2, 설계서 v0.1.10, 검증 v0.1.05, 도면 검토보고서 v0.1.01, 스크립트 25종)
+
+## 요지 (재조사 불필요)
+- 공정: 입력·판독 → 형상(G1) → 기둥 철근(G2) → 기초 철근(G3) → 코핑 철근(G4) → 솔플레이트·받침(G5) → 검토보고서. 게이트 = 독립 기대값 + 음성 대조(수평·높이) + 재로드 + 숨김 포함 집계 + 지문 불변
+- 추가 입력: 실작업 결정 32건을 7유형(범위·표현·충돌 해소·추정 확인·기준·보고·표시 상태)으로 표준화. 외부 자료: 측량좌표·선형, 설계기준, 표준 상세, 디자인 지침
+- 검토 예외: 예정된 FAIL(B12, C9~C13 폭), 기록 전용(반올림·곡선길이·피복·굽힘 R 미달), 검사 대상 외(철근 간섭, 시공성, 구조 계산), 예외 승인 절차
+- 권고 `[추론]`: 판독·규칙·검사 Python 엔진 + B-rep 생성(Rhino.Compute/플러그인) + 박스 웹앱 UI. 로드맵 P0(스크립트 라이브러리화·회귀 고정) → P1(CLI 게이트) → P2(웹 UI) → P3(복수 도면 범용화)
+- 의사결정 4건 → OPEN #17 **해소(2026-10-08)**
+
+## 개발 현황 (2026-10-08, 최근확인일 2026-10-08)
+- 앱 위치: `Code/교각모델링앱/` (원본 `Code/교각모델링/`은 수정하지 않음). 결정: 반자동 MVP · 로컬 Rhino 8 자동 실행 · Flask + 단순 HTML · T형만 · .3dm · local 좌표
+- 단계: P0 완료(엔진 라이브러리화 + v0.1.09 지문 회귀 **3,190/3,190 동일**) → P1 완료(CLI 게이트 `tools/run_gates.py`, G1~G5 PASS) → P2 완료(Flask, 사용자 승인 2026-10-12) → P3 완료(보고서). 단계마다 정지·승인(사용자). **2026-10-12 사용자 확정(화면 포함), 개발 마감.** 남은 과제는 OPEN #18·#19
+- P2 완료(2026-10-12): `web/app.py` (127.0.0.1:5000, 인증 없음 → 로컬 전용)
+  - 판독은 '입력 폼 + 도면 문자 검색'(사용자 선택). 표 3종(ELEVATION, 솔플레이트, 재료표 SD400/500)만 후보값 자동 비교. EL 문자는 목록만 보여 줌
+  - 운곡교 P1 도면 치수는 DIMENSION이 아니라 TEXT(CS-DIMT 레이어)
+  - 확정·승인은 해시 기반: 값이 바뀌면 자동으로 무효. E2E 41/41 (`tools/test_web.py`)
+- P3 완료(2026-10-12): 검토보고서 초안 자동 생성(`engine/report.py`, 8장, MD + PDF)
+  - 승인된 계획 FAIL은 '불일치', 미계획 FAIL과 표 값 차이는 '확인 필요'로 등록
+  - E2E 49/49
+- Rhino 정체(2026-10-12 오후부터, 원인 미확인): 시작이 23분 늦거나, 결과 기록 뒤 종료하지 않음
+  - 실행기(`runner.py`)가 결과 후 30초 유예 → 강제 종료, 시작 10분 초과 → 1회 재시도로 대응
+  - 강제 종료 뒤 다음 Rhino 시작은 정상(`tools/test_runner_stall.py`)
+- 작업 상태: 작업 고유 번호·프로세스 번호를 기록. 서버가 중간에 멈춰 남은 '실행 중'은 '중단됨'으로 표시하고 재실행 허용
+- 일괄 기능(2026-10-12, 사용자 요청)
+  - 묶음 일괄 확정, G1~G5 연속 실행·자동 승인
+  - PASS만 승인, 의견 '일괄 실행 자동 승인', 기록 이름은 누른 사람
+  - 최신 PASS 결과는 재실행 없이 승인
+  - 나머지는 단일 Rhino 세션(`run_batch_session`)에서 실행: 게이트 검사·음성 시험만, 중간 저장·재로드 없음, G5만 저장(사용자 결정)
+  - 일괄 실행 게이트의 재로드·불변은 '생략'. 저장·재로드 검증은 개별 실행으로 함
+- 두 번째 형식(2026-10-13, 산외교 울산 P1)
+  - 교각별 `params.scope` / `builders`, `expected.checkers` / `negative`로 형식을 확장
+  - 생성기 `concrete_tapered.py`(직선 경사 코핑·직접기초), 검사기 `g1_tapered.py`
+  - Rhino 불리언 함정: 칼날형 끝·동일 평면 접촉·접선 면은 교차·합치기·필렛이 실패함
+    - 우회: 한 번 압출한 뒤 분할 원호 외측 오프셋 커터로 빼기
+  - AddBrep은 무효 브렙을 오류 없이 거부함 → 생성기에서 IsValid와 Guid를 확인
+  - 철근(2026-10-13): G2 `column_rebar_ring.py`/`g2_ring.py`(원형 기둥 1열 주철근·띠철근 구간), G3 `footing_rebar_mats.py`/`g3_mats.py`(명시 위치 묶음·둘레 띠·연직근), G4 `rebar_polylines.py`/`g4_polylines.py`(철근별 중심선 꺾은선을 판독 스크립트가 만들고 생성기는 범용)
+  - 울산 결과: G1 104 · G2 35 · G3 63 · G4 129 · G5 75 전부 PASS. 판독 스크립트 `Code/울산P1판독/extract_r2~r4.py`
+  - 판독 요령: 재료표 L은 'L 열'(시트 x 111,000~112,500) 값으로 읽음(형상 열이 추가된 행은 끝에서 두 번째가 총길이). 형상표 II 주기 a=(1,250×2+2,000)/3+D로 스터럽 3조 해석. 코핑 평면 R500 모서리의 바깥 철근은 R400 원호까지 단축
+- 보호 템플릿(2026-10-13, 사용자 선택 "보호된 템플릿 목록 신설")
+  - `data/_템플릿/<이름>/`에 params·expected·template.json(설명, 원본, 저장일, 입력 해시) 고정 사본. 교각 목록에 나오지 않고 앱 화면에서 고칠 수 없음
+  - 저장은 `tools/make_template.py`로만 함(재저장 시 이전 사본은 `_템플릿/_이전/`). 현재 `운곡교P1형`, `산외교울산P1형`
+  - 새 교각 화면: '보호 템플릿'(값 `tpl:<이름>`)과 '기존 교각 복사' 두 묶음. pier.json의 template = "템플릿: <이름>"
+  - 경위: 사용자가 원본 산외교울산P1을 앱에서 삭제(13:11, 휴지통 보존) → 산외교울산P1형은 휴지통 사본에서 만듦(G1~G5 PASS 입력과 바이트 동일)
+- 울산 형식 앱 시험(2026-10-13, `tools/test_ulsan_e2e.py` 44/44): 판독기 결함 2건 수정
+  - 받침별 값: 울산 expected G5 h3·L·T는 받침 번호별 사전 → 후보값이 받침 번호를 함께 넘겨 그 칸과 비교·반영(이전: 거짓 '다름' 8건, 반영 시 사전을 숫자로 덮어씀)
+  - 여러 줄 머리행: 재료표 머리행 아래 2단 이내 문자 줄을 머리행에 합침(단위 줄 제외), 같은 열 아래 표 제목에서 읽기 종료 → 울산 재료표 34마크 인식, 보고서 6장 34행 일치
+  - 보고서 자체 점검: 철근 마크가 있는데 재료표를 못 읽으면 미통과(`schedule_unread`)
+  - 시험 함정: 입력 하나를 바꾸면 전 게이트 승인이 무효(입력 해시) → 잘못된 입력 시험은 G1부터
+- 확정 범위 보완(2026-10-13, 사용자 "진행해줘", `tools/test_confirm_required.py` 13/13, 회귀 8종 전부 통과)
+  - 경위: 일괄 확정은 `web/store.py`의 `COMMON`·`GATE_SECTIONS` 묶음만 확정 → 울산 교각에 미확정 8개가 남음
+  - 실행 설정 `params.scope`·`builders`, `expected.checkers`·`negative`는 게이트 결과를 바꾸므로 필수 확정으로 추가. 묶음이 없으면(운곡교 형식) 요구하지 않음(`OPTIONAL`)
+  - 참고 묶음(`_`로 시작, `_src`로 끝남, `hitl_decisions*`)은 게이트가 쓰지 않음 → 화면에 '확정 불필요(참고)'로 표시(`store.is_info`)
+  - 필수 확정 묶음 수: 운곡교 형식 23개, 울산 형식 26개
+  - 함께 고친 결함: `OPTIONAL` 판정이 params 파일만 확인 → expected 묶음은 있어도 요구 목록에서 빠졌음. 묶음이 속한 파일을 확인하도록 수정
+  - 사용설명서 정본 `DOC/04_실행/실행_T형교각모델링앱사용설명서_2026-10-14_v0.2.05.md`(Ramp-A 형식 반영; 구판은 backup)
+- 세 번째 형식(2026-10-13, Ramp-A교 P1, 사용자 결정 "앱 형식 확장", 범위 G1·G5)
+  - 형식: 단일 현장타설말뚝(Ø2,350 암반 근입 7,500 + Ø2,500 5,200) + 원형 기둥 Ø2,000 + Y형 코핑(하면 R5,000, 끝면 = 평면 볼록 원호→상단 직선 선직면, 상면 315 단차, 측면 2,200→2,000 테이퍼) + 받침 2개(회전 −5.55°·−9.19°)
+  - 생성기 `concrete_shaft.py`(coping form "y_shaft"), 검사기 `g1_shaft.py`. G5는 기존 `bearings.py`·`g5_bearings.py` 그대로(대좌 `seat_z`, `bearing_size` "AB", thick_end −Y)
+  - 코핑 = 정면 윤곽 압출 ∩ 측면 윤곽 압출 − 양 끝 커터(두 단면 직선 로프트 = 선직면). 각 입체를 상대 면 너머로 뻗어 일치·접선 면을 피함 → 불리언 1회 통과
+  - 함정: Rhino `Point3d`에 2D 튜플을 넘기면 SerializationInfo 생성자 오류. 검사 단면을 X=0으로 자르면 상면 단차면과 겹쳐 고리가 쪼개짐 → X=+1
+  - 판독기 보완 3건: 천 단위 쉼표 `_int`, 머리행 선택(아래 첫 숫자 줄이 칸 수 절반 이상), 다른 종류 표 제목에서 창 하단 자름. 운곡교·울산 표 레코드·후보 불변(`tools/test_rampa.py`)
+  - 결과: G1 97/97, G5 39/39 PASS(엔진 실행; 앱 확정·승인은 담당자 몫). 보호 템플릿 `Ramp-A교P1형`. 판독서 `DOC/02_분석/분석_Ramp-A교P1교각도면판독_2026-10-13_v0.1.01.md`, 판독 스크립트 `Code/RampA판독/`
+  - 판독 요령: D1 z = 도면 y + 534,115.2. 평면 끝 원호는 LWPOLYLINE bulge(0.136, 처짐 150)로만 표현됨
+  - 기둥 철근 G2(2026-10-13, 사용자 결정: 기둥 P1·P2·P3만, 말뚝 철근망은 범위 밖): 생성기 `column_rebar_straight.py`·검사기 `g2_straight.py`(form "straight": 곧은 주철근+하단 커플러, 반원 2조각 겹이음 띠철근, X·Y 연결철근). G2 26/26 PASS, 객체 764
+    - 판독 요령: D2 정면 파단(4,000 생략) → 높이는 치수선 끝점으로 읽음. 사슬 기점 EL 45.492(말뚝 상단 +40). 띠철근 작도선은 파단 위아래로 50 어긋남 → 사슬 격자 + 재료표 N으로 확정(K2)
+    - 결정 K1~K4: 커플러 40(작도 16,260 + 40 = L), P2 43.542+150k ×107, P3 43.692+300k ×54 × X·Y(Y +16), 이음·갈고리 단마다 교번
+    - 함정: 기둥-코핑·말뚝 단 사이 동일 평면 접촉 → 콘크리트 합집합 실패(0개) → 피복은 기둥 구간 측면 피복으로 기록. 재료표에 형식 열이 없으면 판독기가 형상 None을 제안 → 지름만 비교로 수정
+  - 말뚝 철근망 G3(2026-10-13, 사용자 결정: 철근 5마크 + PLATE, SPACER는 공식만): 생성기 `shaft_rebar.py`·검사기 `g3_shaft.py`(form "shaft_cage"). G3 48/48, 모델 객체 1,357. `pipeline.GATE_PREFIXES` G3에 `PT` 추가
+    - 판독 요령: D4 정면은 개략도(길이 불일치) → 높이는 구조물 치수표 + 사슬('110'·'260'·'100')로. 첫~끝 띠철근 단 = P1-1 + P1-2 L 합(12,150) 정확히 일치. 단면 기호 r 1,002.5, 첫 각 1.475°
+    - 결정 S1~S6: 띠철근 r 1,025(재료표 r 929·J-J '2,300' 오기), 주철근 r 999.5, U형 중심 통과 30면, PLATE U형 바닥 아래, 이음·갈고리 교번, 커플러 0
+    - 말뚝 철근 id는 'R-P1-1-..'이라 G2 접두('R-P')에 걸리지만 불변 검사에는 무해(앞 게이트 전체 비교)
+  - 코핑 철근 G4(2026-10-14, 사용자 결정: 20마크 한 Task, 울산식 중심선): `Code/RampA판독/extract_g4.py`가 449본 꺾은선 생성 → 범용 `rebar_polylines.py`, 검사기 `g4_ramp.py` 신설. G4 126/126, 모델 2,255 객체. Ramp-A G1~G5 전 범위 완료
+    - 판독 요령: 스터럽 위치는 정면 작도선 55곳(사슬 58@125는 59곳이라 불일치), 하단 = 하면 R+77.5 원호. 재료표 가변 마크 L은 b 최댓값·양 끝 평균 기준이라 위치별 평균과 다름(기록만). C13·C14 = 단마다 동심 수평 고리 3개(정면 수평선 10단)
+    - 앱 확정 대상 보완(2026-10-14): `store.GATE_SECTIONS`에 `pile`(G1)·`shaft_rebar`(G3) 추가, `lean_concrete`·`footing`·`footing_rebar`를 OPTIONAL로 → 이전에는 Ramp-A G1·G3가 앱에서 '없음'으로 막혔음(엔진 직접 실행이라 드러나지 않았음). 필수 확정 14개. 시험 `tools/test_rampa_web.py`
+    - 함정: 코핑 끝면이 평면 볼록 원호 → y ±1,000 모서리에서 정면 작도 위치 철근이 밖으로 나감 → 끝면 피복 40 단축(울산 R500과 같은 방식). 같은 x의 안쪽·바깥 스터럽은 상면 변이 일직선으로 겹침 → 안쪽 +20
+- 네 번째 교각(2026-10-14, 옥성교 P1, 범위 G1·G5): T형 말뚝기초 + 직선 경사 코핑 + 측면 테이퍼 + **평면 사각 18°** + 묶음 대좌(앞뒤 받침 공유, 상면 경사)
+  - 생성기: 울산 `concrete_tapered.py`에 선택 옵션(piles, coping.side_taper, coping.skew_deg = 전단 x' = x − tan·y, bearing_seats.pedestals) 추가(사용자 결정 '울산 생성기 확장'). 검사기 `g1_skew.py` 신설. G5 `g5_bearings.py`는 패드 축을 윗면에서 구함
+  - 결과: G1 147/147, G5 183/183(엔진 실행). 보호 템플릿 `옥성교P1형`. 판독서 `DOC/02_분석/분석_옥성교P1교각도면판독_2026-10-14_v0.1.01.md`, 판독 스크립트 `Code/옥성P1판독/`
+  - 판독 요령: 한 DWG에 일반도·배근도가 함께 있음. z = 도면 y − 314,374.9. 정면도 코핑 외곽은 y = 0 단면이고, 평면 사각은 전단으로 재현(상면 단 경계선도 같은 전단으로 일치 ✓)
+  - 함정: 옆 표(ELEVATION)의 행이 솔플레이트 표 창에 끼어듦 → 머리행 x 범위 밖 숫자 줄은 건너뜀. **머리행 규칙을 다른 방식으로 바꾸면 울산(3줄 머리행)·Ramp-A(라벨 줄)가 깨짐 — 동일 방식 재시도 금지**. 기울어진 패드 바닥 → 무게중심이 평면 중심과 다름(검사는 bbox 중심)
+  - 기둥 철근 G2(2026-10-14): 울산 `column_rebar_ring.py`·`g2_ring.py`에 옵션 추가(main.inner 안쪽 링·안쪽 갈고리, zone.radius, ties.shape "90-135" + y_lift). 사용자가 처음 '운곡교 생성기 재사용'을 골랐으나 판독 결과(커플러 반원 띠철근, 갈고리 주철근)로 울산 쪽을 제안해 변경 승인(Q1). G2 39/39
+    - 판독 요령: 구조도(1) 정면 z = 도면 y − 309,179.8, 기둥 단면은 1/4 원호 4개(CIRCLE 아님). 사슬 '띠철근외측'이 작도 띠철근과 정확히 일치. 작도 주철근 다리(12.375)와 사슬·재료표(12.325) 50 차이 → 치수 채택(Q2)
+  - 기초 철근 G3(2026-10-14, 사용자 결정: 철근별 중심선): 범용 `rebar_polylines.py`를 G3에도 씀 — 엔진이 생성기에 `GATE` 전역값을 넘기고(G3 → params footing_rebar, 그 외 coping_rebar). 검사기 `g3_poly.py`. G3 75/75, 518본
+    - 판독 요령: 기초 평면의 B9 기호는 아래 절반만 작도, 그중 일부가 상세 표시 점선 원에 가려 빠짐 → 작도 점을 대칭 복사하지 말고 열·행 규칙으로 격자 생성. 운곡교 기초 생성기는 마크 배치가 하드코딩돼 다른 교각에 재사용 불가
+    - 결정(사용자, 권장안 전부): F1 B9 한 곳 빼서 171본 · F2/F3 권장안(B9 a 567 평균, 마크 두 개 가장자리부터 교번, 겹이음 미모델) · F4 Y방향 중간근 +19 위로 · F5 UM(조립용 받침) 기록만. F2~F4는 [추론] — 사용자 확인 대기
+    - 스크립트: `Code/옥성P1판독/extract_g3.py`→`판독/g3_values.json`, `extract_g3_bars.py`→`판독/g3_bars.json`, `add_g3.py`(백업 `data/옥성교P1/backup/2026-10-14_g3/`). 엔진 패치 `tools/patches/2026-10-14_patch_gate_global.py`(백업 `backup/2026-10-14_okseong_g3/`)
+    - 회귀(전부 PASS): Ramp-A G4 126/126·G5 39/39, test_web_batch 20·test_web 49·test_web_ulsan_full 16·test_ulsan_e2e 44, 빠른 시험 okseong 14·templates 12·open19 38·rampa 24·confirm_required 13. 모델 1,536 객체. 로그 `prompt/심영표/2026-10-14/Task_옥성교P1기초철근_2026-10-14_v0.1.00.md`, 판독서 v0.1.05
+  - 코핑·교좌면 철근 G4(2026-10-14, 사용자 결정 H1~H6 권장안): 범용 `rebar_polylines.py`(coping_rebar)·엔진 수정 없음. `Code/옥성P1판독/extract_g4.py`(1,163본, `판독/g4_bars.json`)·`g4_shapes_dump.py`(모양표↔재료표 (L, N) 짝맞춤)·`add_g4.py`(백업 `data/옥성교P1/backup/2026-10-14_g4/`), 검사기 `g4_okseong.py`. **G4 251/251**, G1~G5 전부 PASS·불변 확인, 모델 3,862 객체. 판독서 v0.1.07, 사용설명서 v0.2.07, 로그 `prompt/심영표/2026-10-14/Task_옥성교P1코핑철근_2026-10-14_v0.1.00.md`
+    - 판독 요령(재판독 불필요): 한 DWG에 4장(구조도 1~4)이 x 방향으로 나열. 재료표 x 714,965~ / 모양표 x 689,900~712,000. **재료표 수량이 해독 열쇠** — 스터럽 연직선 106 = 39(C8)+27(C10)+40(C12), 정면 점 117 = C18, C7 13 = 9+2+2, 측면 고리 6+6단 × 4줄 = 24, S1~S4 = 대좌 1개분·S5~S8 = 4개분(5 대좌). 정면 선은 철근 중심선보다 22.5 안쪽(스터럽 위·아래), b 3,207 = 3,050 / cos18°(고리 변이 끝면과 평행)
+    - 코핑 철근은 단면(y = 0) 좌표로 만든 뒤 코핑과 같은 전단 x' = x − tan18°·y 적용(스터럽·고리·C18 포함), 교좌면 철근은 모델 좌표(대좌 평행사변형 방향: 긴 철근 = 끝면과 평행, 짧은 철근 = X)
+    - 함정: 모따기 20 mm 미만이면 파이프 생성 실패(C9 x −5725) / 낮은 단 C18 다리를 아래로 두면 코핑 하면 밖(피복 −8) → 위로 / 전단된 고리의 bbox는 모서리 필렛 때문에 최대 37 mm 줄어듦 → 검사 허용 오차 명시
+    - 앱 데이터 주의: Ramp-A·울산 `runs/current/*_gate.json`이 웹 일괄 시험(11:17)에 '저장·재로드 안 함' 모드로 덮어써져 test_rampa가 FAIL → Ramp-A는 `Code/RampA판독/run_gates.py G1~G5`로 복원. 울산은 미복원(OPEN #25)
+    - 다음 작업: 옥성교 P1 G1~G5 전 범위 완료. 남은 것은 담당자의 앱 확정·승인·육안 확인과 [추론] 확인(OPEN #24)
+    - 환경: 이 세션에서 Rhino MCP 서버 연결 실패(CONNECTION_CLOSED) — 엔진 직접 실행에는 영향 없음
+- 일반화 보완(2026-10-13, OPEN #19 A3~A7, `tools/test_open19.py` 전 항목 PASS, 회귀 9종 FAIL 0, 사용설명서 v0.2.04)
+  - A3: `reader.table_records` 허용 거리 = 셀 쪽 이웃 머리열 간격 × 0.6(이전: 표 최소 간격 × 0.6 → 넓은 열의 범위 문자 탈락). 추가된 칸만 생김(운곡교 P1·P2 C12·C13 A, 울산 C7~C13 A·B 7칸), 기존 칸 변화 0
+  - A4: `reader.proposals`가 같은 표 값을 params 별도 행으로 냄(`bearing_seats.bearings[no]` el_x·h1·h2·A·B, `sole_plates.table[no]` S·L·W·T·h3, 공통 h3는 `sole_plates.h3`). params에 있는 칸만. 현행 params와 '다름' 0(운곡교 P1·P2 각 91행, 울산 40행) → 후보 총 행수 운곡교 166 → 257
+  - 함정: `_get`이 목록 인덱스를 못 따라가 params 행이 조용히 빠졌음 → 정수 키 처리 추가
+  - A5: 묶음 저장 시 `{"chain": "시작, 증분, n@간격"}`를 숫자 목록으로 펼침(`store.chain`·`expand_chains`). params에는 목록만 저장 → 생성기·검사기·지문 불변
+  - A6: [도면 문자 검색] 화면의 '핸들 조회'(`reader.entity_info`): 종류·레이어·좌표·길이·호 반지름·bbox. P2 D1 21A76 = LINE 10,350, 20E89 = ARC R12,000 확인
+  - A7: `gates.negative_moves` 재정의 없을 때 기본 받침 id가 expected G5 el_x 번호 밖이면 마지막 받침 번호로 대체(받침 10개는 기본값 그대로)
+  - 수정 전 사본 `Code/교각모델링앱/backup/2026-10-13_open19/`, 회귀 기준 `검증/open19_snapshot_before.json`(`tools/open19_snapshot.py`)
+- 지문 함정(2026-10-12): FAST 지문(관 부피 생략)은 Rhino가 관 솔리드 bbox를 관 반지름만큼 작게 돌려줌 → FAST와 전체 지문을 섞어 비교하면 가짜 차이(569건)가 남. `compare_fingerprints.py`가 혼합 비교를 거부함
+- 운곡교 P2 판독(2026-10-12): G1~G5 PASS, 엔진 일반화 2건 수정(말뚝 `pitch_x/pitch_y`, `hoops.radius_by_mark`), P1 회귀 동일. 판독서 `DOC/02_분석/분석_운곡교P2교각도면판독_2026-10-12_v0.1.00.md`
+- Windows 함정: 스레드 간 JSON 파일 공유 시 `write_text`는 빈 파일이 읽힐 수 있음
+  - 원자적 교체(`os.replace`)를 쓰고, 교체 순간의 PermissionError는 읽기·쓰기 양쪽에서 재시도(`web/store.py`)
+- 검사 독립성: 검사기는 `data/<교각>/expected.json`(도면 문자·표 값, 계획 FAIL 목록)만 읽고 params는 읽지 않음. 이관 검사기 = 기존 verify 5종과 646항목 값·판정 일치
+- 게이트 PASS 조건: 미계획 FAIL 0 + 음성(수평·수직 이동) 검출 + 재로드 객체 수 일치 + 앞 게이트 객체 지문 불변
+- Rhino 자동 실행 사실: `"Rhino.exe" /nosplash /notemplate /runscript="_-RunPythonScript <ASCII경로> _-Exit"` — `/runscript="..."` 형식만 인식(인자 전체 따옴표·Git Bash 경로 변환 시 무동작), 끝에 `doc.Modified=False` 필요. 작업 폴더 `%LOCALAPPDATA%\PierApp\jobs`. 전체 모델 생성 17초, 부피 포함 지문 약 12분
+- 앱 매개변수 규격 `pier-T/1` = 기존 params + 상수 이관 필드(`rebar_marks`, `footing_rebar.a_x/a_y`, `coping_rebar.soffit_arc_centre`(0.1mm 반올림값 유지), 스터럽 상단 구간표, `materials.fck`, `sole_plates.h3`, `display`)
+
+## 주의
+- 근거 도면 1세트 — 54.3 오프셋·층 구성 등은 운곡교 P1 관찰값이며 고정 상수로 쓰지 않는다
+
+## 앱 개선 기획 (2026-10-14, 구현 전)
+- 정본: `DOC/01_기획/기획_입력묶음확인확정개편_2026-10-14_v0.1.00.md` (초안 `[미확정]`). 교각 화면 「2. 입력 묶음 확인·확정」 개편
+- 결정(사용자 2026-10-14): D1 **앱 확인 + 사람 확정**(앱은 확정 기록을 만들지 않음, 앱 확인은 `autocheck.json` 별도 층), D2 표 밖 치수 = **규칙 + 템플릿 앵커**(신뢰 등급 A·B·C·없음, 억지 후보 금지)
+- 변수 등급: V1 값 / V2 목록 / V3 생성(판독 스크립트가 만든 큰 목록, 편집 차단) / F 고정(형식 정의). 철근 중심선 목록이 확정 필요 묶음 용량의 84~95 %(울산·Ramp-A·옥성)라 손 대조 불가가 핵심 문제
+- 가장 위험한 문제(P2): 템플릿 복사값을 새 도면 대조 없이 확정하면 원본 교각 모델이 PASS → 앱 확인 C3 '템플릿 원본 잔존'으로 막을 것(가장 쉬워 1순위)
+- 대기: D3~D6 (OPEN #26). 확정·게이트 승인은 어떤 단계에서도 앱이 대신하지 않는다(시험은 별도 폴더에서만)
+
+## 다섯 번째 교각 — 새재1교 P1 (2026-10-15, 범위 G1·G5)
+- 직접기초(말뚝 없음, 7.7 × 7.7 × 2.6) + 원형 기둥 Ø2.2(높이 16.9) + 직선 경사 코핑(끝면 수직, 상면 5단, 측면 3,000 → 2,200 테이퍼, **평면 직사각**) + 받침 10개(**대좌 5개 공유**, 앞·뒤 열 패드가 서로 다른 각도 −2.15° / −6.45°로 회전). 같은 도면 틀(옥성교와 같은 설계사)·구조도(1)~(4) 철근도 있음(철근 미판독)
+- 결과: G1 138/138, G5 183/183(엔진 실행), 모델 39객체. 보호 템플릿 `새재1교P1형`. 판독서 `DOC/02_분석/분석_새재1교P1교각도면판독_2026-10-15_v0.1.00.md`, 스크립트 `Code/새재1교P1판독/`(`convert_index`·`extract_g1`·`make_pier [--update]`·`run_gates`), 로그 `prompt/심영표/2026-10-15/Task_새재1교P1모델링_2026-10-15_v0.1.00.md`
+- 엔진 변경 없음: 생성기 `concrete_tapered.py`(말뚝 없음·측면 테이퍼·공유 대좌) 그대로, 검사기 `g1_pedestal.py` 신설(옥성교 `g1_skew.py` 복사본 + 말뚝 선택·사각 0° 허용) → 다른 교각 영향 없음
+- 판독 요령: 정면·단면도 **기둥이 중간에서 절단 표시로 끊겨 z 오프셋이 둘**(기초 쪽 y − 14,716.5, 코핑 쪽 y − 5,816.5). 단 높이 = EL.'X' − h1 − h2인데 표의 앞열·뒤열 값이 1 mm 어긋남(표 반올림) → 평균(.5)을 써서 앞·뒤 0.5 mm 안(작도선 소수 .1을 그대로 쓰면 패드 윗면 FAIL 3건). 받침 평면 위치·회전은 패드 폴리라인 3겹(750/650/550)의 바깥 사각형에서
+- 결정(사용자): N1 G1+G5 먼저, N2 대좌 상면 = 앞·뒤 받침 사이 평면 경사 [추론], N3 기둥 fck 35 MPa [추론]. 솔플레이트 두꺼운 쪽 −Y(S < 0, 운곡교 규칙 [추론], OPEN #16)
+- 다음 작업: 철근 G2~G4(구조도 1~4) — 요청 시. 앱 확정·승인·육안 확인은 담당자 몫
+  - 기둥 철근 G2(2026-10-15): 옥성교와 같은 `column_rebar_ring.py`·`g2_ring.py` 재사용(엔진 변경 없음). 스크립트 `extract_g2.py`·`add_g2.py`. **G2 41/41**, G5 재실행 183/183, 앞 게이트 663 불변. 판독서 v0.1.01
+    - 판독 요령: 주철근 두 겹 49본씩(r 975 / 930, 7.347°), 띠철근 72단·크로스타이 40단은 **치수 사슬이 전부**(기둥이 절단 표시로 끊겨 도면은 일부만 그림). 띠철근 구간은 표 수량(P3 45 / P4 27)과 사슬 그룹 크기(5·18·36·9·4)로 맞춤. 띠철근 반지름 = 주철근 바깥 + 주철근 r + 띠철근 r(표 '1.004'는 1,003.5의 반올림 → 표값을 쓰면 곡선 길이 FAIL)
+    - 다음 작업: 기초 철근 G3(B1~B12), 코핑 철근 G4(C1~C20, S1·S2, 대좌 5개) — 요청 시
+  - 기초 철근 G3(2026-10-15, 옥성교 F1~F5 재적용): 범용 `rebar_polylines.py`(G3)·엔진 변경 없음. `extract_g3.py`(점 목록 → `g3_values.json`)·`extract_g3_bars.py`(307본)·`add_g3.py`, 검사기 `g3_sj.py` 신설(옥성교 `g3_poly.py` 복사본, 위치는 작도 점 목록). **G3 72/76(계획 FAIL 4)**, G5 재실행 183/183, 앞 게이트 1,277 불변. 판독서 v0.1.02
+    - 판독 요령: Y방향 61곳(정면 점)·X방향 **51곳**(측면 점; 재료표는 53 → 계획 FAIL, OPEN #28)이 핵심. X철근은 Y철근보다 22.5 위·아래(작도 관례). 평면 치수 '8.000'은 사슬 합(7,700 + 300, '−300' 보정) — 기초 평면 선은 7,700. B9는 정면 연직선 15곳(x @500, 짝수 행 8·홀수 행 7) + 측면 다리 행 6(@1,200, 다리는 행 중심 ±600 작도 = ±622 표) → 45본
+    - 다음 작업: 코핑 철근 G4(C1~C20, S1·S2, 대좌 5개) — 요청 시
+
+### 새재1교 P1 코핑·받침좌 철근 G4 (2026-10-15)
+- 결과: G4 189/189(873본, 엔진 실행), G5 재실행 183/183, 모델 3,043객체. 보호 템플릿 `새재1교P1형` 재저장(G1~G5). 판독서 `DOC/02_분석/분석_새재1교P1교각도면판독_2026-10-15_v0.1.03.md` 10장, 스크립트 `Code/새재1교P1판독/`(`extract_g4`·`add_g4`), 검사기 `engine/rhino/checks/g4_sj.py`, 로그 `prompt/심영표/2026-10-15/Task_새재1교P1코핑철근_2026-10-15_v0.1.00.md`
+- 도면에서 확인한 규칙: 스터럽 윗단은 받침 단 모서리가 아니라 도면 구역 경계에서 바뀐다(윗면 − 124.5 = 중심 − 102 + 그림 겹침 22.5). 단 모서리에서 바꾸면 피복이 사라진다.
+- [추론] 사용자 확인 필요: 받침좌 S1·S2 배치, C7 올린 줄 덮개, C18 아래 3단 다리 위, 스터럽 x 어긋남, 마크 교번.
+
+## 앱 화면 개편 PRD·디자인 시스템·시안 (2026-10-15)
+- 문서: `DOC/01_기획/웹앱디자인시안/PRD.md`(v0.1.02, 화면 13종), `design.md`(v0.1.01, Prism v0.1.1 앱 프로파일), `시안/index.html`(S04·S05·S07·S10 동작 시안, jsdom 19항 PASS), 캔버스 시안 13화면(앱 이름 PierProof). 기획서 `기획_입력묶음확인확정개편_2026-10-15_v0.1.01.md`(D1~D6 결정 완료).
+- 결정(심영표 2026-10-15): D3 경고+사유, D4 일치 묶음만+근거표 열람, D5 A→B 먼저, D6 옥성교·Ramp-A교부터 / UX1 R8을 Prism으로 대체, UX2 Prism 상태색, UX3 Pretendard 내장(파일 `web/static/fonts/`에 배치만), UX4 마커 도형 승인, UX5 다크 시험 제외, UX6 HTML 시안 제작.
+- 앱 구조 답변: Flask + HTML, 로컬 전용(127.0.0.1:5000), Rhino 8을 `/runscript`로 작업마다 실행 후 종료, 다른 PC 사용은 설치 필요, 네트워크 공유는 인증 추가 필요.
+- 미결: 템플릿 구분 기준(OPEN #30, `템플릿구분기준과도면기반추천_논의.md`), 앱 코드 반영(기획서 A→B 착수 시, 계획서 승인 후).

context-migration/기술노트_DWG판독_Rhino모델링환경.md

@@ -0,0 +1,90 @@
+# 기술노트 — DWG 판독·Rhino 모델링 작업 환경 함정
+
+```
+소유자: 심영표
+확정일: 2026-10-07
+최근확인일: 2026-10-20
+재확인 조건: ODA·Rhino·Python 버전이 바뀌거나 Rhino MCP 도구가 갱신될 때
+```
+
+## DWG → DXF
+- `dwg2dxf`(LibreDWG, 기존 박스 프로젝트 기준 변환기)는 이 PC에 **없음**. ODA File Converter 27.1.0 사용: `C:\Program Files\ODA\ODAFileConverter 27.1.0\ODAFileConverter.exe <in_dir> <out_dir> ACAD2018 DXF 0 1 "*.DWG"`
+- 한글 경로도 정상 변환. RAG 원본 보호를 위해 임시 폴더에 복사 후 변환 (`Code/교각모델링/convert_dwg.py`)
+- 콘솔 출력 한글이 깨지면 `PYTHONIOENCODING=utf-8` 지정 (파일 내용 자체는 정상)
+
+## DXF 판독
+- Python 3.12에 ezdxf 1.4.4 설치되어 있음. matplotlib는 2026-10-07에 설치(3.11.2) — 렌더링용
+- ezdxf TEXT에는 `char_height` 속성이 없음(MTEXT만). `e.dxf.get("char_height")`는 TEXT에서 예외 발생 → dxftype 분기
+- ezdxf 렌더 PNG에서 한글은 □로 표시됨(폰트 미매핑). 문자는 survey JSON으로 읽을 것
+
+## Rhino MCP (Rhino 8, 헤드리스 slot)
+- `get_viewport_image`가 **회색 빈 화면만 반환**함(Perspective/Front, 카메라 지정 모두). 시각 확인은 대체 수단 필요 — 동일 방식 재시도 금지, 단면 재투영 수치 검증 또는 사용자 육안 확인으로 대체
+- 새 문서 기본 단위 mm, 허용오차 0.001. 스크립트는 `__rhino_doc__` 사용, 보관 파일은 `exec(open(path, encoding="utf-8").read(), {...})`로 실행
+- 객체 삭제·이동(Transform deleteOriginal) 후 저장하면 **삭제 객체(undo 기록)가 저장 개수에 포함**됨(34 → 68). 저장 전 `doc.ClearUndoRecords(True)` 실행
+- `save_doc`은 직전 파일을 `.3dmbak`으로 남김 → 폴더 `backup/`으로 이동
+- 검증은 저장 파일을 **새 slot에 open_doc 후 재실행**하면 파일 실재성과 정확성을 함께 확인할 수 있음
+- Rhino slot이 작업 도중 닫힐 수 있다(2026-10-07 aardvark, 원인 미확인). `rhino_closed` 오류가 나면 다른 slot을 쓰거나 spawn_slot으로 새로 띄운다
+- **`Brep.CreatePipe(..., fitRail=True, ...)`는 직선-원호-직선 레일에서 빈 결과를 내고, 대량 실행 시 헤드리스 Rhino가 크래시함(2026-10-07)** → `fitRail=False` 사용. 동일 방식 재시도 금지
+- 대량 생성 전에 형상 종류별로 1개씩 먼저 시험한다
+
+## 검증 설계 교훈
+- 음성 대조(일부러 객체를 옮겨 FAIL이 나오는지 확인)는 반드시 **위치 이동과 높이 이동을 모두** 넣는다. 2026-10-07 대좌 검사기가 Z 검사만 있어 X 3mm 이동을 놓쳤다 → 간격·절대위치 검사를 추가해 해결
+- 피복·내부 검사에서 여러 부재의 `ClosestPoint`를 쓰면 부재 간 내부 접합면까지 거리를 재서 음수 피복이 나온다 → 콘크리트를 `CreateBooleanUnion`으로 합친 외곽면 기준으로 잰다
+- 검사 정의는 재료표 정의와 맞춘다(예: 재료표 L에 커플러 길이 포함 여부). 1차 FAIL은 증거 파일로 보존한다
+- **`for o in doc.Objects`는 숨긴 객체를 건너뛴다.** 사용자가 Rhino 창에서 객체를 숨기면 검증이 '없음'으로 오판한다 → `ObjectEnumeratorSettings(HiddenObjects=True, LockedObjects=True)`로 센다 (2026-10-07 P1-FT)
+- `open_doc(clearFirst=True)`는 숨긴 객체를 지우지 않는다 → 다른 파일을 열어 비교할 때는 새 slot을 띄운다
+- 여러 조각을 이은 곡선의 `Domain.Mid`는 길이 중간이 아니다(세그먼트 매개변수). 비대칭 철근(갈고리 한쪽)의 위치는 바운딩 상자로 잰다
+- `Brep.CreateBooleanUnion`은 입력 순서에 따라 실패할 수 있다 → 순서를 바꿔 재시도한다
+- 음성 대조는 마크마다 **수평 위치와 절대 높이**를 모두 변형해 본다. 길이·범위 검사만으로는 평행 이동을 못 잡는다(2026-10-07 B9 +5mm 미검출 → 하단 높이 검사 추가)
+- MCP 호출은 300초 제한이 있다. 철근 관 1,000개 이상의 `VolumeMassProperties`는 제한을 넘는다 → 철근 관 지문은 바운딩 + 면 수로 잰다
+- Rhino slot이 다른 호출 중 응답 불능이 되면 MCP가 자동으로 새 slot을 띄워 **빈 문서에서** 다음 스크립트를 실행할 수 있다 → 파일을 연 직후 객체 수(숨김 포함)를 반드시 확인한다. 실패한 열기가 남긴 객체로 문서가 오염되면 slot을 닫고 새로 띄운다
+- 갈고리 방향처럼 추정한 형상은 곡면(하면 원호) 근처에서 콘크리트를 뚫을 수 있다 → 콘크리트 내부 표본 검사로 반드시 확인
+- 바운딩 최고점·최저점으로 '높이'를 재면 위·아래로 꺾인 갈고리를 잡는다 → 수평부 중간점을 쓴다
+- 사각 부재의 '교축방향'을 긴 변으로 판별하지 않는다(받침 NO.3는 교축직각 변이 더 김) → 방향(축과의 각도)으로 판별한다 (2026-10-08)
+- 검사 항목 설계 시 높이·크기·각도만 넣고 **수평 위치(평면 중심)**를 빠뜨리기 쉽다 → 음성 대조 전에 수평·높이 각각에 대응하는 검사가 있는지 먼저 확인한다
+- 세션이 바뀌면(익일) Rhino slot이 모두 종료되어 있다 → 저장 파일을 새 slot에 열고 객체 수부터 확인
+
+## 보고서 PDF (reportlab)
+- 2026-10-08 reportlab 5.0.1·pypdf·pypdfium2 설치. 한글은 `C:\Windows\Fonts\malgun.ttf`/`malgunbd.ttf`
+- **맑은 고딕에는 음수 기호 U+2212(−) 글리프가 없어 빈칸으로 출력** → 변환 시 '-'로 치환. 다른 기호는 fontTools cmap으로 사전 점검
+- 표의 짧은 열이 글자 단위로 줄바꿈됨 → 열 최소 폭 = 가장 긴 단어 폭
+- 결과 확인은 pypdfium2로 페이지를 PNG 렌더링해 육안 점검 + pypdf 텍스트 추출
+
+## Rhino 화면 이미지 만들기 (2026-10-14, 발표자료용)
+- **뷰포트 캡처는 쓰지 말 것**: 이 PC에서 `/runscript`로 띄운 Rhino는 Shaded 모드를 지정해도 `ViewCapture`·`CaptureToBitmap` 결과가 항상 와이어프레임(면 채움 없음). 동일 방식 재시도 금지
+- **Rhino 렌더러는 됨**: 스크립트에서 `RunScript("_-Render")` → `_-SaveRenderWindowAs "<ASCII경로>.png"` → `_-CloseRenderWindow`. 해상도·배경은 `doc.RenderSettings`(`UseViewportSize=False`, `ImageSize`, `BackgroundStyle.SolidColor`, `BackgroundColorTop`). 이미지 1장 약 30초
+- 앱 .3dm은 `File3dm.Read`로 읽어 새 문서에 `Objects.Add`로 복사(활성 문서 새로 열린 상태, `OpenHeadless` 아님). 레이어 색은 객체 색으로 복사, 재질을 객체별로 만들어 `Transparency`(0~1)로 콘크리트 반투명 + 철근 색 유지
+- **콘크리트(Brep)는 Mesh로 변환해 추가**해야 렌더에 나옴(`Mesh.CreateFromBrep(QualityRenderMesh)` → 합쳐서 추가). 철근 파이프 Brep은 그대로 됨
+- 카메라: `vp.SetCameraLocations(target, camera)` — **인자 순서가 (목표점, 카메라점)**(거꾸로 넣으면 아래에서 올려다봄) 후 `ZoomBoundingBox`
+- 간섭 확대 이미지: 철근 마크별 색 지정 + 나머지 회색, 포커스 점 ± pad 상자로 맞춤. 스크립트 `scratchpad/shot.py`(세션 임시 — 필요하면 `tools/`로 옮길 것)
+
+
+## 앱 시험 일괄 실행·셸 함정 (2026-10-16)
+- **시험 일괄 실행기**: `Code/교각모델링앱/tools/run_all_tests.py <fast|rhino|all> [시험명...]` — 시험마다 로그 `검증/_rerun_<이름>_<날짜>.log`, 요약 `검증/_rerun_summary_<그룹>_<날짜>.json`. fast = Rhino 없는 12개(약 40초), rhino = 실제 Rhino 7개(수십 분). 같은 그룹명으로 이름 일부만 다시 돌리면 요약 파일이 덮어써지므로 그룹명을 바꿔 돌릴 것(예: rhino2)
+- **Windows 콘솔(cp949)에서 em dash(—) 등 출력 시 UnicodeEncodeError** — 실행기 상단에서 `sys.stdout.reconfigure(encoding="utf-8")`, 하위 시험은 `PYTHONIOENCODING=utf-8`. 동일 방식 재시도 금지
+- **Bash 도구에서 큰 python 헤레독(`python - <<'E'`)에 `'''` 삼중 따옴표가 있으면 "unexpected EOF"로 실패** → 스크립트를 파일로 쓰고 실행(패치 스크립트는 어차피 `Code/`에 보관해야 함). 짧은 코드는 가능
+- 백그라운드 `nohup ... &` 로 띄운 작업은 하네스가 완료를 추적하지 않음 — 시작한 셸의 종료 알림이 먼저 오므로 완료로 오해하지 말고 출력 파일의 `DONE` 줄로 확인
+- 같은 시험을 재실행하면 `검증/*_data` 폴더는 시험이 다시 만든다(실제 `data/` 교각은 건드리지 않음). 단 `test_okseong`·`test_rampa`·`test_saejae`는 실제 `data/<교각>/runs/current`의 게이트 보고서를 읽으므로 웹 일괄 시험이 덮어쓰면 실패 → 엔진 `tools/run_gates.py <data> <data>/runs/current`로 개별 실행해 복원(OPEN #25)
+- Rhino 렌더(위 절)로 모델 육안 확인이 가능함 — 새 교각 육안 확인(OPEN #3)에 쓸 수 있는데 아직 안 했음
+
+## 앱 시험 작성 함정 (2026-10-19)
+- **`web/store.py`는 `DATA`를 import 시점에 읽는다.** 시험에서 `store`(또는 `app`)를 `PIERAPP_DATA` 환경변수를 설정하기 **전에** import하면(헬퍼 함수 안의 지연 import 포함) 이후 `create_pier` 등이 실제 `data/`에 쓴다 — 2026-10-19 `test_anchors` 첫 실행이 `data/앵커시험`·`data/복사시험`을 실제 데이터에 만들었다(삭제함). 시험은 `os.environ["PIERAPP_DATA"] = ...` → `import app, store` 순서를 지키고, `assert store.DATA == TD`로 확인한다
+- 시험 간 상태 의존: `test_pier_batch_button`은 `test_web_batch`가 만든 `배치P1`(전 게이트 승인 상태)을 읽으므로 반드시 바로 뒤에 실행(사이에 `test_individual_after_batch`가 끼면 FAIL). `run_all_tests.py`의 RHINO 목록 순서 유지
+- 앵커 따라가기 시험 결과(같은 도면 틀 A 45건 중 오답 0, 다른 틀 36쌍 A·B 0)는 `tools/test_anchors.py`에서 재현 가능 — 재조사 불필요
+- 화면 확인 방법: `tools/make_ui_check_data.py`로 임시 데이터를 만들고 `tools/serve_ui_check.py`(포트 5057)를 띄운 뒤 헤드리스 Edge `--screenshot`으로 캡처(`검증/ui_check_shots/`). 서버는 시험 뒤 종료(PowerShell `Get-CimInstance Win32_Process`로 `serve_ui_check` 찾아 `Stop-Process`)
+- **기하(선 길이) 앵커 시도(2026-10-19) — 동일 방식 재시도 금지**: 앵커 없는 숫자 필드에 콘크리트·철근·중심선 레이어 선분 길이를 대응시켜 새 도면에서 같은 위치·방향 선분을 따라가는 방식은 값이 바뀐 필드를 하나도 복원하지 못했고(울산 P1↔P2, 운곡교 P1↔P2), 철근 위치 목록(좌표)을 길이로 오인해 오답 A가 섞였다. 위치·외곽 점열은 뷰 기준점 대비 좌표라 뷰 기준점을 도면 틀마다 확정해야 한다. 문자 앵커 + 표 교차 확인이 현재 최선
+- 운곡교 P3·P4 `pier.json`의 template은 `운곡교p2`(P2를 복사해 만든 교각)다 — 그래서 현재 값 = P2 값, 도면 = 자기 것. 앵커는 `운곡교P1형`을 불러왔고 값은 반영하지 않았다
+
+## 도면 읽기 도구(`engine/geomread.py`)의 규칙과 함정 (2026-10-20)
+- **틀**: 운곡교 P1 도면 틀(P1~P4)만. 첫 도면(D1) 좌표가 P1 도면과 같음: 코핑 평면 중심 (12162.4, 26412.3), 정면도 중심 x 12159.4, 단면도 기초 중심 x 30133.6, 기초 하면 y 8115.6 = 기초 EL, 코핑 EL = y + (최고 단 옆 'EL.' 글자 − 그 단 y). 틀 일치율은 템플릿 앵커의 랜드마크 글자 비율(70 % 미만이면 거절). 새재1교·옥성교는 0 %.
+- **재현 검증이 먼저**: 읽기 규칙은 완성된 교각(P1)에서 같은 값이 나오는지 확인한 뒤에만 믿음 — `tools/test_geomread.py`(P1·P3·P2·P4, 초기 P4 백업 144~150건 = 검증값).
+- **비교 허용오차는 값의 출처에 따라**: 글자·재료표에서 온 값(기초·말뚝·기둥·철근 개수·길이·반경·재료표 셀·코핑 상단 철근 a)은 **정확 비교**, CAD 선·원·폴리라인에서 잰 값만 1.5 mm(각도 0.05). **동일 방식 재시도 금지**: 모든 숫자에 1.5 mm 를 주면 개수 36 대 37, 재료표 17.247 대 17.377, 상단 철근 a 11855 대 11856 이 '같다'로 가려진다(P2 첫 반영에서 재료표 사본·후프 개수가 빠졌고 P4 G4 C1·C4 2 mm 실패의 원인).
+- **C14 점은 템플릿 점 좌표에 맞춰 찾지 않는다**: x 오프셋이 교각마다 다름(P1·P3·P4: 13/913…, P2 상단 두 줄: 0/900…). 도면의 철근 원(R27, CS-RBAR-MAJR)을 읽고, 템플릿 C14 높이(+ 높이 이동) 5 mm 안의 원만 취함(기둥 후프 점은 x≈±902 이고 한 점은 C14 높이에서 23 mm 떨어짐, P2 의 C14 x=900 과는 2 mm). 오른쪽 반만 그려져 있어 좌우 대칭, 가운데(|x|≤20)는 한 번, 템플릿에서 왼쪽 짝이 없던 점(P1 x 2913 근처)은 오른쪽 전용.
+- **재료표의 직경 칸 '"' 는 표 순서상 바로 윗 줄**이다(마크 번호 순서가 아님) — P1~P6 을 번호 순으로 이어받으면 틀림.
+- **재료표 B9 개수는 격자(체스판)로 계산**: 38×29/2 = 551 = 모델이 놓는 개수, 재료표 493 과 다르면 계획된 FAIL 로 등록(P2·옛 P2). P3·P4 는 격자와 재료표가 같음.
+- **작도 한쪽만 그려진 값(C14, 기초 중간 층 B11·B12, 좌측 스터럽 윗면)은 좌우 대칭 가정** — 재료표 개수와 어긋나면(P4 B11 30 대 32) 작도를 채택하고 계획된 FAIL 등록 후 설계자 확인.
+- **`hooks_up` 처럼 점 좌표로 대상을 지정하는 목록은 점이 바뀌면 조용히 깨진다**(P3 G4 코핑 밖 점 56개) — 앱 확인 C9 가 `hooks_up ⊂ c14.points` 를 검사함.
+- **교각 이름을 바꾸면 모델 객체 이름 접두어(`P1-FT`)가 바뀐다** — `params.display.hidden_ids` 도 같이 바꿔야 함(안 바꾸면 일괄 실행이 마지막 단계에서 오류로 중단).
+- **고정(F) 항목(pier_id·display)을 도면에서 읽기로 바꾸면 앱 확인 C7 이 사유 기록을 요구** — 반영 화면이 `edit_log.json` 에 자동 기록하도록 수정함(이전 서버 프로세스는 재시작해야 반영).
+- **실제 사용 데이터에 의존하는 시험은 깨진다**: 사용자가 `운곡교p2`·`운곡교P4` 를 삭제·재작성하면서 시험 6종이 깨짐 → 시험은 G5 까지 승인된 복사본(`testlib.verified_pier`)·휴지통 복사본(`testlib.pier_dir`)을 쓴다. Windows 의 글로빙은 대소문자를 구분하지 않아 `운곡교p2_*` 가 `운곡교P2_*` 를 집는다 — 이름 접두어를 대소문자 구분으로 다시 거른다.
+- **Flask 는 디버그 꺼짐이면 템플릿을 캐시한다** — 화면·라우트를 고친 뒤에는 사용자가 앱을 껐다 켜야 새 메뉴·버튼이 보인다(2026-10-20 '도면에서 읽기가 없다'의 원인).

context-migration/디자인지침_경로.md

@@ -0,0 +1,28 @@
+# 디자인 지침 경로
+
+```
+소유자: 심영표
+확정일: 2026-10-07
+최근확인일: 2026-10-15
+재확인 조건: 디자인 지침 폴더가 이동·개편될 때 / 조직의 디자인 지침이 신설·폐지될 때
+```
+
+> [F15] 디자인 판단이 필요한 Task는 아래 경로의 디자인 지침을 근거로 씁니다.
+> 경로가 `[미등재]`이면 Agent는 `[CLARIFICATION NEEDED]`로 정지하고 경로를 묻습니다.
+> 조직에 디자인 지침이 없으면 `없음`이라고 적습니다. 그 경우 [R8] 수용 기준을 착수 전에 확정하는 것으로 대신합니다.
+
+| 항목 | 값 |
+| :--- | :--- |
+| 디자인 지침 폴더 경로 | `RAG/design system_v0.1.1` — Prism Design System v0.1.1 (2026-10-15 심영표 지정. 2026-10-07~14에는 '없음') |
+| 네트워크 드라이브 경로 (있는 경우) | 없음 |
+| 현행 디자인 시스템 하위 폴더 (있는 경우) | `webapp/` (M3 웹앱 모듈). 앱 적용 프로파일: `DOC/01_기획/웹앱디자인시안/design.md` |
+
+## [R8] 대체 수용 기준 등재
+
+| 적용 대상 | 확정일 | 기준 |
+| :--- | :--- | :--- |
+| T형 교각 모델링 앱 화면 (Flask, 로컬 전용) | ~~2026-10-12~~ → **대체 2026-10-15 / 심영표 (OPEN #29 UX1)** | **Prism 앱 프로파일로 대체**(`DOC/01_기획/웹앱디자인시안/design.md`): 서체 Pretendard 내장, 판정 색은 Prism 상태색(do·dont·caution·tip)+마커 도형(●▲■◆◇, UX4 승인), 색과 글자 병기 유지, 1280px 가로 스크롤 없음 유지. 철근 팔레트는 Rhino 모델·범례 전용. 이전 기준(참고): 내부 업무 도구. 시스템 글꼴(맑은 고딕) 14px, 흰 배경, 장식 없음. 판정 색은 철근 팔레트 재사용: PASS 녹 (44,160,44) / FAIL 적 (214,39,40) / 계획 FAIL·주의 주황 (255,127,14), **색과 글자(PASS/FAIL/계획 FAIL) 병기 — 색만으로 구분 금지**. 화면 문구 한국어. 판정: 1280px 폭에서 표 외 가로 스크롤 없음, 모든 판정 셀에 글자 표기 100% |
+| 운곡교 P1 Rhino 모델 철근 색상 | 2026-10-07 | 직경별 고대비 5색, 강종(S/H) 무관 같은 색. D32 (214,39,40) / D29 (255,127,14) / D25 (188,60,160) / D19 (44,160,44) / D16 (31,119,180). 관 솔리드에 객체 색으로 적용, 중심선은 레이어 색(회색) 유지. 판정: 직경별 색 일치율 100%, 직경 5종 = 색 5개 |
+| 산외교 울산 P1 철근 색상 (위 팔레트 확장) | 2026-10-13 (Agent 제안 — 사용자 확정 대기, OPEN #22) | 위 5색 유지 + 울산에만 있는 직경 2색 추가: H22 (23,190,207) / H13 (140,86,75). 같은 직경 같은 색 원칙 동일. 판정: 직경별 색 일치율 100% (G3·G4 검사기 '색상 불일치 0') |
+| Ramp-A교 P1 철근 색상 (위 팔레트 확장) | 2026-10-13 (Agent 제안 → **사용자 확정 2026-10-13** "H35 철근 색은 보라 (148,103,189) 로 확정") | 기존 7색 유지 + H35 (148,103,189). 같은 직경 같은 색 원칙 동일. 판정: rebar_colours 불일치 0 |
+| 발표자료 '교각 도면 모델링(AI) · 웹앱' (16:9, 대상: 구조엔지니어 고급기술자·팀장) | 2026-10-14 (Agent 제안 — **최종 시각 확정은 사용자 HITL**) | 조직 디자인 지침 없음 → 슬라이드는 연한 바탕 + 짙은 청회색 글 + 포인트색 1(Rhino 철근 팔레트 주황 (255,127,14))·정보색 1(청 (31,119,180)). 서체 2종(제목·본문 한글 산세리프). 글자 24px 이상, 슬라이드당 한 가지 주장. 이미지는 Rhino 8 렌더(콘크리트 반투명 + 철근 직경별 색)를 실제 모델에서 캡처하며, **색만으로 구분 금지**(범례·글자 병기). 숫자(본수·항목 수)는 앱 결과 파일·보고서에서 인용하고 [출처] 표기. 판정: 표 외 글자 24px 미만 0건, 모든 이미지에 캡션(무엇을 보여주는지) 100%, 인용 숫자 출처 일치 100%, 과장 표현(100% 자동 등) 0건 |

context-migration/운곡교P1교각_모델링기준.md

@@ -0,0 +1,90 @@
+# 운곡교 P1 교각(완도방향) 모델링 기준·확정 치수
+
+```
+소유자: 심영표
+확정일: 2026-10-07
+최근확인일: 2026-10-07
+재확인 조건: RAG 교각도 3매(C0050205-025/026/027)가 개정·교체될 때(SHA-256 변경) / 받침 대좌·r=1,100 원 미해결 항목이 해소될 때 / 좌표계·단위 기준을 바꿀 때
+```
+
+## 정본 위치
+- 입력 파라미터(정본): `Code/교각모델링/params.json` — 모든 수치에 도면·엔티티 핸들 출처(`src`)
+- 생성: `Code/교각모델링/build_rhino.py` / 검증: `verify_rhino.py` (기대값은 도면 문자에서 독립 입력)
+- 모델(현행): `Code/교각모델링/출력/실행_운곡교P1교각모델_2026-10-08_v0.1.09.3dm` (3,190객체 = 콘크리트 34 + 받침대좌·패드 20 + 철근 기둥 240조각·기초 832·코핑 486(각 관+중심선) + 교량받침 10 + 솔플레이트 10). 구판 v0.1.00~v0.1.08은 `출력/backup/`. **P1-FT·P1-CP 숨김 상태로 저장 — 사용자 결정 '숨김 유지'**
+- 재생성 순서: `build_rhino.py` → `build_rebar_rhino.py` → `build_footing_rebar_rhino.py` → `build_coping_rebar_rhino.py` → `apply_rebar_colors.py` → `build_bearing_plates_rhino.py`. 검증: `verify_rhino.py`·`verify_rebar.py`·`verify_footing_rebar.py`·`verify_coping_rebar.py`·`verify_bearing_plates.py` (숨김 객체 포함 집계)
+- 근거 문서: `DOC/02_분석/분석_운곡교P1교각도면판독_2026-10-07_v0.1.01.md`, `DOC/03_설계/설계_운곡교P1교각모델링_2026-10-08_v0.1.10.md`
+
+## 좌표·단위 (2026-10-07 설계 확정)
+- mm, X=교축직각(정면도 좌→우), Y=교축(단면도 좌→우), Z=절대표고 EL×1000, 원점 X=Y=0 교각 중심
+- 도면 좌표 환산: D1 정면도 x−12159.4 / 단면도 x−30133.6 / 평면도 (x−12162.4, y−26412.3) / D2 기초평면도 (x−29072.6, y−16871.3). 정면도 y 16515.6 ↔ EL 40.411 (기둥 파단선 위쪽에만 유효)
+
+## 확정 치수 (검증 근거 — 재계산 불필요, 58/58 PASS·재로드 확인)
+| 부재 | 값 |
+| :--- | :--- |
+| 버림 | 9,550×8,000×100, EL 26.108~26.208, 말뚝 관통부 제거 |
+| 기초 | 9,350×7,800×2,200, 하단 EL 26.208, 기둥 동심 |
+| 기둥 | 원형 D2,000, H12,003 (EL 28.408~40.411). 도면은 파단 축약 작도 → 작도 길이 사용 금지 |
+| 코핑 | 하단 12,400 / 폭 3,100 / 하면 평탄 ±1,100 @40.411 / R12,000 원호 → 선단 하단 ±6,200 @41.911 / 선단 경사(상단 ±6,000) / 상면 5단 43.411·43.483·43.555·43.627·43.698 (경계 X −3,801/−1,296/1,210/3,715) |
+| 말뚝 | Φ600 L24,400, 6×5 간격 1,550 연단 800, 두부 기초 내 100 근입 |
+| 체적 m³ | 버림 6.792 / 기초 160.446 / 기둥 37.709 / 코핑 89.586 / 말뚝 1본 6.899 |
+
+## 사용자 결정 (2026-10-07, HITL)
+- 받침 대좌 제외(높이 기준 211mm 충돌 → OPEN #1), 코핑 하면 띠형 해석(OPEN #2), 말뚝 포함
+- 기각안: 대좌를 작도 높이로 [검토용] 생성 / 하면 원형 평탄부 해석 / 말뚝 제외(Agent 제안이었으나 사용자가 포함 선택)
+
+## 받침 대좌 높이 기준 (2026-10-07 해소, 검증 근거 — 재계산 불필요)
+- 사용자 지정 기준: **EL.'X' = 코핑 상면 + h1 + h2**. 10개소 모두 일치(최대 −1mm, NO.3·4). 근거: `Code/교각모델링/calc_bearing_seat.py` → `검증/bearing_seat_check.json`
+- 3500kN(NO.1~5) h1 164, 2800kN(NO.6~10) h1 139, h2 50, h3 181, h4 30, E = h1+h2+h3+h4 (425/400) 10개소 모두 성립
+- NO.1~5와 NO.6~10은 각각 거더선 1~5(정면도 좌→우, 코핑 소단 1~5)에 대응. EL.'X'가 좌→우로 증가하는 것과 소단 상승이 일치
+- **동일 방식 재시도 금지**: EL.'X'−E로 대좌 하단을 구하면 211mm 차이가 생긴다(해석 오류)
+- 미결: D1 단면도의 대좌 작도 높이 169.4는 표 h1 164와 5.4mm 차이 (OPEN #5)
+
+## 받침 대좌·패드 모델 (2026-10-07 v0.1.01, 172/172 PASS·재로드 확인 — 재계산 불필요)
+- 전열 = 3500kN NO.1~5 (Y −698), 후열 = 2800kN NO.6~10 (Y +600). 근거: S1 852 + S2 1,298 + S1 950 = 3,100
+- 대좌: 거더선마다 2,500×1,200(회전 4.405°)를 전·후열로 분할, 높이 h1. 패드: (A+200)×(B+200) → (A+100)×(B+100), h2 50, 회전 전열 4.403° / 후열 3.102°
+- X 위치: 후열 받침 중심 = 코핑 하단 좌단 + 1,232 + (k−1)×2,505.33. 평면도 기준 패턴 = 거더선 5, 거더선 1·2는 평행 이동 [추론] (사용자 승인, 거더선 3·4 검산 ≤0.23mm)
+- 판독 데이터: `params.json` → `bearing_seats` (`extract_bearing_seats.py`가 생성)
+
+## 도면 특성 (재조사 불필요)
+- D1 도면틀 = x 0~48,500, y 0~34,500. 그 밖 엔티티(교량 선형·횡단면도·사본 뷰)는 시트 외 잔여물로 판독 제외
+- DIMENSION 엔티티 0건 — 치수는 분해된 선+`CS-DIMT` 문자. 콘크리트 외곽 레이어 `CS-CONC-MAJR`, 은선 `CS-CONC-MINR`, 중심선 `CS-CNTL`
+- D3(-027-)은 철근 재료표·가공도·커플러만 있어 콘크리트 형상 근거 없음
+- 받침 회전각: 전열 약 4.4°, 후열 약 3.1° (곡선교), 받침 위치는 코핑 하단 좌단 기준 1,232 + 4×2,505
+
+## 기둥 철근 P1~P6 (2026-10-07 모델 v0.1.02, 43/43·172/172 PASS·재로드 확인 — 재계산 불필요)
+- 재료표 해석(D3 가공도): P1 XIV = a 16,213 + 원호 b 534(=π/2×R340) + 갈고리 c 500 → 17,247 / P2 XVI 직선 16,553 / P3 VI = 반원 2×2,818(=π×897) + 갈고리 4×200 → 6,436 / P4 V = 2×2,753 + 커플러 2×65 / P5 IX = 5,571 + 커플러 65 / P6 III = 1,836 + 2×150. 재료표 `"`(상동): P2 S32, P3~P5 H19, P6 H16
+- **재료표 L은 커플러 길이 b를 포함한다** → 원길이 검사는 본체 + 커플러
+- 주철근: 0° 시작 46등분, 바깥 P1 r 870.5(갈고리 바깥쪽), 안쪽 P2 r 825.5 (H2), 하단 EL 26.508, 상단 43.061 (H1)
+- 띠철근 R 897, 67단: P4 27.388~28.348 @120 / P5 28.468~30.988 @120 / P3 31.288~41.788 @300. P3 이음은 단마다 90°/0°로 엇갈림, 갈고리는 안쪽 135°
+- 크로스타이 9단 27.388~41.788 @1,800 (+17.5, 띠철근 위), 0/45/90/135°, 반지름 918에서 갈고리 150 아래로
+- 굽힘: 도면 명시 R 우선, 그 외 박스 기준 최소 반지름(H19 42.75, H16 24)
+
+## 확대기초 철근 B1~B12 (2026-10-07 모델 v0.1.04, 73/74(B12 −6 예정 FAIL)·재로드 확인 — 재계산 불필요)
+- 층(기초 하면 기준 z, F1 작도): 하면 Y B2(U 다리 1,950)+B4 교대 @125 z122 / X B6(U)+B8 교대 @125 z178 / Y B3 z227.5 / X B7 z277; 상면 Y B1 z2,073, X B5 z2,127; 중앙 B11(X)·B12(Y) 4단 550/950/1,350/1,750 각 28; 둘레 B10 9단 z350~1,950 @200; B9 34×29 격자 체크무늬 (i+j 짝수) 493, z127.5~
+- 위치 사슬: Y철근 X = ±4,575 + (−4,375~4,375 @125 또는 @250), X철근 Y = ±3,800 + (−3,625~3,625 @125 또는 @250). U자 철근은 양끝 + 안쪽 교대의 첫 번째
+- 재료표 `"` 상동은 표의 그룹 순서로 해석: B2·B4 S25, B6·B8 S29, B7·B10 S19, B12 S16. B9 수량은 빈칸 → 총연장 1,062.415/2.155 = 493
+- 형상 원길이: XII·III = a+2b, XIII = 2(a+b), XI = a+b+c (B9 상단 180° 갈고리는 반원 R=c/π)
+
+## 철근 색상 (2026-10-07, 디자인지침 '없음' → R8 대체 기준)
+- 직경별 5색, 강종 무관: D32 (214,39,40) / D29 (255,127,14) / D25 (188,60,160) / D19 (44,160,44) / D16 (31,119,180). 관 솔리드 객체 색, 중심선은 레이어 회색. `apply_rebar_colors.py`
+
+## 코핑 철근 C1~C16·S1·S2 (2026-10-07 모델 v0.1.08, 112/117(K1 결정 FAIL 5)·재로드·음성 대조 확인 — 재계산 불필요)
+- 판독서: `DOC/02_분석/분석_운곡교P1코핑철근판독_2026-10-07_v0.1.02.md`, 데이터: `params.json` → `coping_rebar`
+- **재료표 변길이 L 관례**: 변하는 치수는 (최대+최소)/2로 L을 계산. 스터럽 IV L = 2a+2b+2c, 폐합 X L = 2a+2b+4c
+- **재료표 치수 = 작도 중심선 + 54.3** (스터럽 높이 b, 폐합 길이 a 모두) — 범위 양끝 검산에 사용
+- 상면 C1~C6: 수평 3단 EL 43.311/43.211/43.111, 양끝 선단면과 평행한 다리(98°/96°). 하면 C7·C8: 평탄 40.511 + 하면 동심 R 12,100 원호(호 5,273) + 다리 650. 하면 오프셋 원과 평탄부 교점 X = 6,951.9 − √(12,100² − 10,576.4²)
+- 스터럽 47곳×3(폭 1,160/1,740/1,160), 수평 폐합 9단×3(폭 1,106/1,686/1,106, 단 끝 = 하면 원 또는 선단면 −100.8)
+- C14 41곳(정면도 점), C15·C16 상단 소단부, S1·S2 대좌(4.405° 회전)마다 10+21
+- 결정: 1차 범위→전체, K1 작도 폭(스터럽·폐합), K5 ①CYCLE부터, C14 문제 4본만 갈고리 위, P1-CP 숨김 유지
+
+## 교량받침·솔플레이트 (2026-10-08 모델 v0.1.09, 184/184·재로드·음성 대조 확인 — 재계산 불필요)
+- 높이 구성(D2 ELEVATION TABLE): 코핑 상면 → h1 대좌 → h2 패드(상단 EL.'X') → h3 181 교량받침 → h4 30 솔플레이트 (E = h1+h2+h3+h4)
+- 교량받침 = (L−100)×(W−100) = 재료표 A×B, 검정. 솔플레이트 = L×W(L = A+100 교축, W = B+100), 하면 수평·상면 교축방향 경사 S, 중심 두께 T 30, 두꺼운 쪽 −Y `[추론]`, 회색 (150,150,150)
+- 방향·중심 = h2 패드(교축방향은 패드의 A 방향. **NO.3는 W 890 > L 800이라 '긴 변 = 교축'이 아님**)
+- 데이터: `params.json` → `sole_plates` (`extract_sole_plates.py`)
+
+## 도면 검토보고서 (2026-10-08 확정 v0.1.01)
+- 정본: `DOC/06_보고서/보고서_운곡교P1교각도면검토_2026-10-08_v0.1.01.md`, PDF 사본: `Code/교각모델링/출력/보고서_운곡교P1교각도면검토_2026-10-08_v0.1.01.pdf` (사용자 결정: PDF는 출력 폴더 유지, F3)
+- 지적 22건(오류·불일치·확인 필요 E-01~E-12, 누락 M-01~M-10), 부록 B에 OPEN # 대응표. OPEN 항목이 해소되면 보고서도 판 올림 대상
+- 재료표 집계: `compile_rebar_schedule.py` → `검증/rebar_schedule_compare.json` (SD400 5,801.619 m / 19.388 t, SD500 4,990.106 m / 21.552 t)
+- PDF 재생성: `python Code/교각모델링/md_to_pdf.py <md> <pdf> <머리말>`

context-migration/템플릿구분기준과도면기반추천_논의.md

@@ -0,0 +1,54 @@
+# 앱 템플릿 구분 기준과 도면 기반 추천 — 논의 기록
+
+```
+소유자: 심영표
+확정일: 2026-10-15 사용자 결정(심영표) — 각도=값, 기초=말뚝 유무만, S02 도면 먼저. 구현은 대기(OPEN #30)
+최근확인일: 2026-10-15
+재확인 조건: 보호 템플릿이 추가·통합될 때 / 적합성 판별 화면(S02)을 구현할 때
+```
+
+> 출처: 2026-10-15 사용자 질문 3건에 대한 답변 정리. 근거 파일: `DOC/01_기획/기획_입력묶음확인확정개편_2026-10-15_v0.1.01.md` 4.4절, `DOC/01_기획/웹앱디자인시안/PRD.md` S02, 각 교각 `params.json`. `[추론]`은 확인이 필요한 판단이다.
+
+## 1. 도면을 먼저 올리면 가장 비슷한 템플릿을 추천할 수 있는가
+
+가능하다. 단, 추천은 후보를 좁히는 용도이고 최종 답은 사람이 확인한다(D1: 앱 확인 + 사람 확정).
+
+| 적합성 질문 | 도면에서 읽는 단서 | 난이도 |
+| :--- | :--- | :-- |
+| 기초 형식 | "말뚝"·"PILE" 문자, 말뚝 배치 레이어, 기초판 치수 | 쉬움 |
+| 기둥 단면 | 지름 기호 Ø, 원형 단면 치수 | 쉬움 |
+| 철근 형상 종류 | 재료표 형식 열, 마크 이름 | 쉬움 |
+| 받침 배치 구조 | 받침 ELEVATION TABLE 행 수, 대좌 표기 | 중간 |
+| 코핑 하면 형상 | 정면도의 "R" 문자(곡선), 외곽선 모양 | 어려움 |
+| 평면 형식 | 평면도의 각도 표기(°, ∠), 외곽선 기울기 | 중간 |
+
+- 방식: 단서로 6문항 값을 추정 → 5개 템플릿과 일치 문항 수로 순위 → 추정값을 미리 채우되 사람이 바꾼다. 맞는 템플릿이 없으면 "판단 불가" 표시가 정상 동작.
+- 화면 영향: S02 순서가 "이름 → 템플릿 → 6문항"에서 "도면 올리기 → 추천 순위(근거) → 템플릿 → 6문항 확인"으로 바뀐다. 교각 폴더 생성 시점 조정 필요.
+- R 문자 주의: 평면 모서리 R(울산 R500), 철근 굽힘 반경 r 등과 섞이므로 정면도 영역·코핑 하면 외곽선 근처로 한정해야 한다. 각도 문자도 철근 상세와 구분하려면 평면도 영역으로 한정한다.
+
+## 2. 템플릿을 구분하는 기준 (사용자 지적과 현황)
+
+사용자 지적(2026-10-15): ① 사각(비스듬한 평면)과 직각은 같은 템플릿을 쓸 수 있지 않은가 ② 현장타설말뚝 유무는 구분이 합리적이나 직접기초·말뚝 배치는 무엇이 기준인가 ③ 새재1교는 기초 회전이 있는데 템플릿을 구분해야 하는가. **[정정 2026-10-15 / 심영표] 새재1교에는 기초 회전이 없다. 이 질문의 전제와 이후 답변의 '기초 회전 확인 필요'는 잘못된 정보였다.**
+
+| 항목 | 현황 (2026-10-15 확인) | 판단 |
+| :--- | :--- | :--- |
+| 평면 skew | 옥성교 `coping.skew_deg` 18.0, 새재1교 0.0. 새재1교는 skew 0을 허용하는 검사기 `g1_pedestal.py`를 새로 복사해 만들었다(옥성교 `g1_skew.py` 회귀 위험 때문) | 구조 차이가 아니라 **이력 차이**. 각도는 값(V1)으로 두고 통합할 수 있다 `[추론]` |
+| 기초 | 운곡교: 확대기초 + 말뚝, 울산·옥성·새재1: 직접기초, Ramp-A: 기초판 없는 단일 말뚝 | 기준은 "생성기가 만드는 객체 구성이 다른가". 말뚝 **유무**만 형식, 말뚝 개수·배치는 값(V1·V2) |
+| 직접기초 3개가 따로 있는 이유 | 기초가 아니라 코핑 형상, 받침 구조, 철근 생성 방식이 달라서 | 도면이 들어온 순서대로 생긴 결과 |
+| 회전 | 새재1교 입력값에서 회전은 받침 10개(약 −2.17°). 코핑 skew 0. 기초 회전 값은 데이터에 없음 → **정정: 실제로 기초 회전이 없는 것이 맞음** | 새재1교가 별도인 이유는 회전이 아니라 앞뒤 받침이 공유하는 대좌 5개와 코핑 상면 5단. 기초 회전은 없으므로 확인 불필요 |
+| 다른 교각의 회전 | Ramp-A 받침 4.403°, 대좌 4.405° | 회전은 교각마다 흔함 → 값 |
+
+## 3. 제안된 구분 기준 (사용자 결정 대기)
+
+- 템플릿을 가르는 것: **형상 구성**(말뚝 유무, 대좌 공유 여부, 코핑 하면 곡선·직선·나팔형, 철근 생성 방식)
+- 템플릿을 가르지 않는 것: 각도(받침 회전, 코핑 skew, 기초 회전), 말뚝 개수·간격, 치수
+- 효과: 적합성 질문 6개 중 "평면 형식"은 값 확인으로 바뀌고 자동 추정이 어려운 부분이 줄어든다.
+- 선행 조건: 옥성교(skew 18°)와 새재1교(0°) 통합 시 검사기 `g1_skew.py`·`g1_pedestal.py`, `g4_okseong.py`·`g4_sj.py` 정리와 두 교각 시험 재실행.
+- 상태: **2026-10-15 사용자가 3건 모두 권고안으로 결정**(각도 값 통합 / 말뚝 유무만 / S02 도면 먼저). 기획서 v0.1.02 4.4절과 PRD S02에 반영했다. 코드·템플릿 변경은 아직 없다. (새재1교 기초 회전은 없음으로 정정되어 남은 확인 없음.)
+
+## 4. 이행 현황 (2026-10-15 갱신)
+
+- **G1 검사기 통합 완료**: `g1_skew.py` 폐기, 옥성교·새재1교 모두 `g1_pedestal.py` 사용. G1 재실행 옥성교 147/147, 새재1교 138/138 PASS(음성 시험 검출). 백업: `Code/교각모델링앱/backup/2026-10-15_g1통합전/`. 재검증 불필요, 동일 방식 재실행만 하면 된다(`tools/run_gates.py <data> <run> --gates G1`).
+- **G4 통합 보류**: `g4_okseong.py`·`g4_sj.py`는 각도가 아니라 철근 배치 규칙(C7 줄, 스터럽 구간, 받침좌 철근)이 달라 이번 기준("각도=값")의 적용 대상이 아니다. 통합 여부는 사용자 결정 대기.
+- **S02 도면 먼저 추천 구현 완료**: `Code/교각모델링앱/engine/recommend.py`, 웹 `/recommend`(교각 목록의 [도면 읽고 추천 받기]). 3문항만 추정(말뚝 유무 = '말뚝' 문자, 하면 형상 = 정면도 R≥10 m이면 곡선·1~10 m은 나팔형(약함)·없으면 직선 경사, 받침 개수 = ELEVATION TABLE 행). 철근 형상·생성 방식 등은 추정 불가라 사람이 답한다. 9개 도면 세트로 확인, 일반화 미검증. 동일 방식 규칙 재조사 불필요.
+- 옥성교 `runs/current/G1_gate.json`은 구 검사기 기록이므로 앱에서 G1 재실행 필요(OPEN #25와 같은 상태).