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>
2026-10-28 11:20:18 +09:00
commit 964a841de1
@@ -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 에서 직접 읽고 그림 잘라 증거에, 도면↔도면·도면↔모델 오류 엑셀 구분 기록(모든 프로젝트)
@@ -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]].
@@ -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).
@@ -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]]
@@ -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]]
@@ -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]]
@@ -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 설계자 확인.
@@ -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).
@@ -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]].
@@ -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.
@@ -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]].
@@ -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).
@@ -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]].
@@ -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.
@@ -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.
@@ -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) 레이어 이름만 보고 프로젝트를 "대호지교"로 추측했다가 정정 — 프로젝트명은 확인된 것만 말할 것.
@@ -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]].
@@ -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 적용은 도면 값 확정 후.
@@ -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]]).
@@ -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]] 먼저 읽기.
@@ -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).
@@ -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`.
@@ -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).
@@ -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 선호).
@@ -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.
@@ -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차 완료.
@@ -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]].
@@ -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 등).
@@ -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]]
@@ -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]]
@@ -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 다각형 군집 → 원 중심).
@@ -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 출력이 안 돌아오므로 파일로 쓸 것.
@@ -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]]
@@ -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]]
@@ -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.
@@ -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.
@@ -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.
@@ -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]].
@@ -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]].
@@ -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).