⚠ 서브 창 제보(유로폼 12-38-3 이 참조로 찍혀 읽히지도 않던 것)를 파고 들어가
더 넓은 결함을 찾음. `REFERENCE_MARKS` 의 `"단 위"` 하나로 **41건이 참조로
버려지고 있었고**, 그 안에 **돌쌓기(장비) 13-4-5·13-4-2**(우리 매핑이 실제로
쓰는 코드) · 12-2 표면 마무리 · 9-19-1 면고르기 · 9-20 뿌리다듬기 ·
13-8 막돌쌓기 · 11-2 규준틀 같은 명백한 공종이 섞여 있었음.
- 원래 겨냥은 품셈 1-2-2 「단위 표준」 표였는데 **1장은 chapter 규칙이 이미
거르므로** 그 표지는 넓기만 했음. 「단위 열이 있다」는 소요량표의 흔한
모양이지 참조표의 표지가 아님. 제거.
- reference 98 → 58, requirement 246 → 287. 돌쌓기(장비) 둘이 공종으로 섬.
작업조 표 깃발(`crew_table`) 16건 — 「형틀목공 4인 + 보통인부 1인 / 시공량 35㎡」
의 「4」는 소요량이 아니라 **인원**이라 그냥 읽으면 35배 부픔. 값을 바꾸지 않고
표시만 함(`expression_cells`·`partial_ratio` 와 같은 취급). 평떼 시비도 잡힘 —
서브가 실물에서 트럭 한 대를 빠뜨린 그 표.
유로폼 조각에 `incomplete_note` — 물량은 섰으나 **자재 몫(패널 0.89매/10㎡ ·
부자재 24/52/79 % · 소모자재 5 %)이 자재 단가가 없어 안 붙음**. 「못 채움」과
달리 값이 있으므로 「부분」으로 갈라 보임 — 부분 성공이 완전 실패보다 위험함.
검증 — 품셈 39건 통과, 전체 605 passed, tsc 오류 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
「원문이 이미 정해 둠」 **네 번째** — 품셈 12-38-3 [주]④ 「보통: 측구, 수로,
옹벽, 일반적인 벽체, 박스」. 앞선 셋(거푸집 사용횟수 1-7-1 · 철근 갈래
12-3 [주]① · 밑수는 표 위 본문)과 같은 자리라 사람이 고를 칸을 안 만듦.
옹벽 → `FP-12-38#보통`, 근거 문구를 조각에 함께 실음.
- ⚠ 12-38-1 「사용횟수」는 1-7-1 과 **다른 자리**임. 그쪽은 유로폼(강재)의
잔존율(12회 25% · 25회 10%)로 임대료·손료 산정용이고, 1-7-1 은 소모성
거푸집 전용 횟수(옹벽 3회)임. 이름이 같아 하나로 이으면 조용히 틀림 —
데이터에 그 구분을 적고 시험으로 못 박음.
- 유로폼 자재는 12-38-2 가 10㎡당 패널 0.89매로 냄. B08 은 **면적(㎡)** 으로
보내고 매수 환산은 밑수를 아는 B09 가 함 — B08 이 환산하면 밑수가 두 벌.
`composite_not_ready` 를 `{code, reason}` 구조로 바꿈. 받는 쪽이 「단가 없음」과
「물량 없음」을 갈라야 함(기초잡석이 후자).
원단위 자체가 없으면 조각을 늘어놓지 않고 한 줄로 말함 — 같은 사유가 조각마다
다섯 번 반복되면 진짜 사유가 묻힘(화면에서 실제로 그렇게 보였음).
시험 추가 — 같은 공종코드가 지반만 달리해 여러 줄 오는 표본(도자 토사·리핑암).
실물에서 잡힌 모양이라 고정 자료에도 넣음.
검증 — 인계 59건 통과, 전체 600 passed, tsc 오류 0.
화면 그리기는 실제 모듈을 그대로 돌려 확인(사용자 프로젝트·DB 무접촉).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
옹벽 네 조각이 B09 에 다 서서 이제 물량을 실어 보냄.
- `composite_parts` 에 조각마다 수량·단위·근거(`basis_kind`)를 실음. 코드만
보내면 받는 쪽이 상세 줄을 못 세움. 조각은 **원단위 성분 이름으로** 찾고
못 찾으면 0 이 아니라 사유와 함께 `not_ready` 로 남김.
- ⚠ 철근은 ㎏ → ton 환산. 단가가 원/ton 인데 원단위는 ㎏ 이라 안 맞추면
1000배 틀림. D13 13.45 + D16 30.42 = 43.87㎏/m × 10m = 0.4387ton.
- 철근 갈래는 **품셈 12-3 [주]① 원문**이 정함 — 「간단: 중력식 옹벽 /
보통: 반중력식 옹벽 / 복잡: 부벽식 옹벽」. 거푸집 사용횟수(1-7-1)와 같은
자리라 사람이 고를 칸을 만들지 않음. 캔틸레버식은 예시에 없어 「보통」으로
때우지 않고 미확보로 드러냄.
- 전개 결과에 저장 제원(`options`)을 실어 뒤 단계가 형식을 읽게 함. 치수를
다시 쓰라는 뜻이 아니라 읽으라는 것 — 치수 정본은 여전히 하나.
- 화면(구조물 원단위 탭)에 묶음 조각과 갈래를 보임.
⚠ 옛 시험 하나를 계약 변경에 맞춰 옮김 — `composite_not_ready` 가
「일위대가가 아직 안 선 공종」에서 「물량을 못 채운 조각」으로 뜻이 바뀜.
검증 — 인계 54건 통과, 전체 594 passed, tsc 오류 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
타설 방식 — 「무엇을 정해야 하는지」만으로는 부족하고 「정하면 얼마나 달라지는지」가
보여야 사용자가 판단함. 세 방식 단가 차이가 6배라 조용히 기본값을 쓰면 총액이 갈림.
- 방식 이름을 늘 값 옆에 보임(「적용 중: 레디믹스트 (기본값 — 확인 필요)」).
코드(12-01-01)만으로는 무엇을 쓰는지 모름.
- 참고 단가 세 줄을 안내로 띄움 — 레디믹스트 65,826 · 기계비빔 163,508 ·
인력비빔 408,327 원/㎥. ⚠ **표시 전용**이며 B08 의 어떤 계산에도 안 들어감
(금액은 B09 몫). 출처·산출일을 데이터에 함께 적음.
품셈 마스터 — 값 자리에 식이 적힌 칸에 깃발(`expression_cells`).
`0.2 × 30%`(기초잡석 소할)처럼 계산이 그대로 적힌 칸은 값이 숫자로 안 읽혀
그 성분이 조용히 빠짐. 형태 판정은 통과하고 배분율 딱지도 없어 아무 검사에도
안 걸리던 자리(서브 창이 실물에서 부딪힘 — 기초잡석이 부설다짐 0.6인만으로 섬).
⚠ 식을 계산하지 않고 드러내기만 함 — 뜻을 잘못 읽으면 조용히 틀림.
31표에서 잡힘(9-12·9-13 터파기 계열 · 12-24 뒷채움 · 12-25 기초잡석 등).
검증 — 품셈 34건 통과, 전체 588 passed, tsc 오류 0.
화면에서 방식 이름·기본값 표시·단가 세 줄 확인.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
목록에만 있고 화면에 없으면 사용자는 그것이 잠정인 줄도 모름. 셋 다
「지금 어떤 값으로 돌고 있는지 + 왜 잠정인지」를 함께 보임.
- 콘크리트 타설 방식을 좌측 패널 칸으로 냄. ⚠ 금액에 바로 걸리는 값이라
기본값으로 돌고 있으면 「기본값 「레디믹스트」로 계산 중 — 아직 안 정한 값」
안내를 띄움. 설정 기본을 None 으로 바꿔 「안 정함」과 「일부러 레디믹스트를
고른 것」을 가름 — 값을 미리 넣으면 그 구별이 사라짐. 되돌리기도 됨.
- 물구멍 근거에 잠정값을 적음 — 「관 Ø 미정(법 3~6㎝ / 실무 Ø50) ·
간격 2.0㎡당 1개소(법 2~3㎡당 1개소 이상)」. 「미확정」만으로는 무엇을
정해야 하는지 모름.
- 준비공의 벌목 줄에 공종 미확정 사유와 후보를 함께 적음(수확베기·단목베기·
위험목 베기 중 어느 것인지 원본이 말하지 않음).
검증 — 전체 580 passed, tsc 오류 0. 화면에서 셋 다 뜨는 것과 타설 방식
저장·되돌리기까지 확인 후 검증으로 바꾼 값은 원래대로 복원.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
조율 창 판정 반영. 타설 공종은 타설 방식 × 구조물 종류로 갈림.
- **구조물 종류는 자동 판정** — 원단위 성분에 철근이 있으면 철근구조물.
사람이 고르는 값이 아님. 옹벽 관측 원단위의 D13·D16 에서 그대로 나옴.
- **타설 방식은 설계 판단**이라 프로젝트 설정(`quantity.concrete_placing_method`)이
고르고 기본은 레디믹스트(FP-12-01-01). 잠정이며 사용자 확정 대기.
모르는 방식이면 기본으로 떨어지되 그 사실을 알림.
- 옹벽 묶음의 타설 코드를 `FP-12-01-01#철근구조물` 로 좁힘.
- ⚠ 묶음 넷 중 `FP-12-03`·`FP-12-25` 는 B09 일위대가가 아직 안 섬.
`composite_not_ready` 로 함께 알림 — 지금 세우면 절반짜리가 됨.
검증 — 인계 48건 통과, 전체 578 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
서브 창 제보(기준 단위 없이 도는 단가 125 중 122)의 뿌리. 밑수는 표 안이 아니라
**표 바로 위 본문**에 있음 — `### 12-2. 표면 마무리` 다음 줄의 `(단위: ㎡당)`.
표만 보면 못 찾고, 못 찾은 채 두면 「10㎡당」 표를 1㎡당으로 알아 곱셈이 10배 틀림.
- 원문 md 를 함께 열어 표 위 6줄에서 밑수를 읽음. **본문이 정본, 표 안 긁기는 보조** —
13-3-1 이 본문 `(단위: ㎥당)` 인데 표 안 긁기가 비고의 `10㎡` 를 물어 오던 자리.
- `(단위: 인/㎡당)` 꼴은 **분모가 밑수** — 값의 단위(인)를 밑수로 읽으면 뜻이 뒤집힘.
- ⚠ 「당」도 「단위:」도 없으면 밑수가 아님. 처음에 조건을 느슨히 두어
`(무한궤도,0.7㎥)` 를 「0.7㎥당」으로 읽어 5건이 잘못 잡혔음 — 조여서 고침.
- 위로 거슬러 보되 **다른 표에 닿으면 멈춤** — 앞 표의 밑수를 물어 오면 조용히 틀림.
밑수 확보 13 → 183 (그중 묶음 기준 36건: 떼채취 100㎡ · 큰돌쌓기 10㎡ ·
뒷채움 100㎡ · 묘목 1000본 · 헬기방제 160ha 등). 못 찾은 144건은
`basis_missing_2026-01-01.json` 으로 냄 — 곱해야 하는 형태만 담아 잡음을 줄임.
빈칸으로 두면 1단위당으로 오해되므로 목록으로 드러냄.
앞서 확인한 「밑수가 밀렸나」와는 다른 물음이었음 — 이번은 「아예 안 적혔나」.
검증 — 품셈 30건 통과, 전체 575 passed.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
⑬ 운반 사슬 실증 중 발견. 정본에 저장되는 것은 유토곡선 한 벌(`mass_haul`)이고
배분은 그 안의 `haul_plan` 인데, 라우터가 바깥 껍데기를 그대로 넘기고 있었음.
`blocks` 를 못 찾아 운반 표가 항상 빈 표가 됨. [확정] 전에는 어차피 빈 표라
화면에서 티가 안 나던 자리임.
검증은 사용자 프로젝트를 건드리지 않고 서버 계산 코드(Node 번들)를 시험 노선으로
직접 돌려 실제 배분을 받아 확인함.
- 운반거리 표: 무대 3.90㎥/10m · 도자 7.80㎥/40m · 덤프 3,712.29㎥/288.12m
- 인계: 무대 in_bill=false + 수량 그대로, 도자 FP-10-11 · 덤프 FP-10-12
- 검산: 합 3,723.99 vs hauled 3,724.00 (차 0.01 — 배분 자체의 반올림)
- 장비 한계: 무대 20m · 도자 60m 이내 확인
저장 정본 모양을 그대로 넣은 시험 2건으로 못 박음.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
⑪ 준비공·사방공 — 자리를 만들되 없는 값을 지어내지 않음.
- ⚠ 벌목은 값을 안 냄. 토공집계의 「지장목제거」로 이미 서 있어 또 세우면 같은
나무를 두 번 벰. 참고 면적만 보이고 「다른 표에서 이미 섬」으로 가리킴.
- 못 서는 줄에 사유를 적음 — 표토제거(두께·구간 미정) · 제근(입목 본수 없음) ·
규준틀(개소 기준 미정). 공종코드는 미리 적어 둠.
- 사방공은 레지스트리의 실제 type_id 로 봄. 없으면 「해당 없음」 — 0 을 적지 않음.
이름을 지어내면 영영 안 걸리므로 레지스트리와 대조하는 시험을 둠.
⑫ 최종 점검 — 탭 6장 전수를 실화면에서 돌려 값으로 서는 것 확인
(토적표 65측점 · 토공집계 10줄 · 운반거리 안내 · 준비공 5줄 · 구조물 원단위 10줄 ·
자재총괄 4줄). 전체 566 passed, tsc 오류 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- 거푸집 사용횟수는 **관측값이 아니라 법**임. 품셈 1-7-1 이 구조물 종류별로
정해 둠(옹벽 3회 · 보호공 기초 6회). 원문 문구를 데이터에 싣고 우리 구조물이
어느 예시에 걸리는지 적음. 걸리는 예시가 없으면 「사용횟수 미확보」.
- ⚠ 횟수별 재료 환산(품셈 12-4 합판 3회 46.1 %)은 **하지 않음**. 그 비율은
일위대가 재료비에 걸리는 값이라 B08 이 곱하면 B09 와 겹쳐 두 번 줌.
B08 이 내는 것은 접촉 면적 그대로 + 몇 회짜리인가까지. 시험으로 못 박음.
- 동바리는 슬래브를 떠받칠 때 쓰는 것이라 지금 서는 구조물(옹벽·집수정)은
대상이 아님. 0 으로 적지 않고 「대상 없음 + 사유」로 냄.
- 거푸집 이름은 정확 일치로만 봄 — 부분일치면 「거푸집씻기」(공사용수)가 걸림.
공종코드 잇기
- 집수정 → FP-12-15, 물넘이포장 → FP-12-06 로 이음.
- 옹벽은 **품셈 12장에 그 이름의 공종이 없음**. 빈 코드로 두면 「매핑을 못 찾은
줄」과 구별이 안 되므로 `composite` 로 묶음(타설+거푸집+철근+기초잡석)을 적음.
일위대가 조립은 B09 몫이고 B08 은 물량과 묶음만 넘김.
검증 — 거푸집 8건 · 인계 45건 통과, 전체 558 passed. tsc 오류 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
⑩ 콘크리트 구조물. 품셈에 구조물별 표준 물량표가 없어(구조물_수량.md ·
배수공_수량.md §2) 실무 설계원본 관측값을 데이터 파일로 둠.
- `resources/data_structure_unit/` — 반중력식옹벽 H=2.0(m당) · 돌집수정 ㄷ/ㄴ형 ·
집수정 Ø800 · 콘크리트포장 T=20cm. 줄마다 출처를 실음.
- 규격 정확 일치로만 씀. 보간하지 않음 — H=1.6 을 H=2.0 에서 줄여 쓰면 틀림
(기초·벽 두께는 높이에 비례하지 않음). 안 맞으면 「원단위 미확보」로 드러내고
표에 있는 규격을 함께 알림.
- BOX암거·세월교는 관측값도 없고 저장 제원에 두께가 없어 전개식도 못 세움.
`not_found` 에 사유와 함께 남기고 미확보로 냄 — 두께를 지어내면 콘크리트·
거푸집·철근으로 번져 나감.
- 성분마다 `basis_kind`(derived/observed)를 달아 화면에 「치수 전개 / 실무 관측」
으로 보임. 두 근거가 한 표에 섞이므로 안 적으면 되짚을 수 없음.
- 배수관의 유입부 집수정을 별도 줄로 세움. 품셈도 관부설과 집수정을 다른
공종으로 둠 — 한 줄로 합치면 어느 쪽 물량인지 못 가름.
품셈 몫 표시 (조율 창 제보 교차 확인)
- `인력(10%)`·`장비(90%)` 처럼 딱지가 비율을 달고 오는 표 25건 확인. 형태 판정은
정상(requirement)이었으나 **장비 몫이 시공능력 공식이라 값이 아님**을 아무도
알 수 없었음. `resource_shares`·`partial_ratio` 를 실어 「단가가 일부만 선 것」이
정상으로 흘러가지 않게 함. 공식 기호는 첫 표에만 있고 뒤 표가 물려받으므로
기호 유무가 아니라 몫 유무로 판정 — 기호로 세면 절반을 놓침(9-13-2).
반영률 계약 갱신 — breakdown 을 늘 실음(`application_ratio_breakdown` ·
`quantity_breakdown`). `application_ratio_pct` 는 두 율이 같을 때만 채우는 편의값.
검증 — 관측 원단위 17건 · 인계 43건 · 품셈 23건 통과, 전체 548 passed. tsc 오류 0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- 반영률: `quantity`(적용 후) · `quantity_gross`(적용 전) · `application_ratio_pct`
세 칸을 함께 실음. 곱하기는 B08 한 곳에서만 하고 B09 는 산출근거에만 적음.
100 % 인 줄도 율을 적음 — 칸이 비면 받는 쪽이 적용 여부를 단정 못 함.
`verify_ratio_math()` 가 세 값의 정합을 재고 `build_handoff()` 가 실제로 부름.
- 할증 상태를 세 갈래로: `applied` / `not_applied` / `rate_unavailable`.
두 갈래면 「율을 못 찾아 안 붙인 것」이 「붙였다」로 나가 나중에 진짜 율이
들어왔을 때 한 번 더 붙음. 옛 깃발은 실제로 붙었을 때만 참으로 둠.
- 관급구분 `unknown` 이 세 번째 계약값임을 주석에 명시. B09 는 관급자재대에도
도급 재료비에도 넣지 않고 missing 으로 뺌.
- 운반 줄이 실제로 실리는지 시험으로 못 박음(무대 in_bill=false 포함 4줄).
⚠ 반영률 누락 지적은 사실이 아니었음 — 실서버 확인 결과 네 반영률이 전부 100 %
이고, 성토면다짐·층따기가 같은 사면 면적에서 나와 값이 겹친 것임. 곱셈은
정상 동작 중. 다만 세 칸 계약은 이중 적용을 막으므로 그대로 반영.
검증 — 인계 40건 통과, 전체 523 passed. 실서버에서 세 칸 정합·할증 상태
`rate_unavailable`·검산 경고 0 확인.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
- 암 시공법(ripping/blasting)을 갈래 비율 칸 아래에 붙임. 갈래 이름만으로는
품셈 공종(암절취 FP-09-04 / 발파암 FP-09-05)을 못 고르던 자리. 기본은
「안 정함」이고, 안 정하면 인계에서 사유와 함께 드러남. 비율 미입력 상태의
「암」 한 줄에도 칸을 냄.
- 관급/사급은 표 안에서 줄마다 고름. 관급 줄에만 설치주체가 열리고 사급으로
되돌리면 잠기며 비워짐. 만진 줄은 표시가 남음.
- 산출 요약(최소·중앙·최대)을 원단위·자재총괄·인계에 붙임. 단위별로 갈라 냄 —
값이 있기만 하면 시험이 못 잡는 자릿수 어긋남을 사람이 훑게 하는 장치.
화면에서 걸려 고친 것 둘
- 관급을 골라도 설치주체 칸이 잠긴 채 남던 것. 고른 즉시 열고 닫게 함.
- 한 번 고른 시공법을 되돌릴 길이 없던 것. 설정 저장이 병합이라 빈 값을 보내도
옛 값이 남았음. `save_section(replace_keys=…)` 로 되돌릴 수 있어야 하는 칸만
통째로 갈아 끼움. 나머지는 그대로 병합.
앞 커밋에서 온 타입 오류 2건도 고침 (`slopeColumnCount` 미사용,
`variant: "outlined"` 는 없는 값). 앞선 확인에서 npx 가 엉뚱한 패키지를 실행해
「오류 없음」으로 잘못 봤음 — tsc 는 config/node_modules 것으로 부를 것.
검증 — 새 시험 5건 + 인계 28건 통과, 전체 509 passed. tsc 오류 0.
화면 실조작으로 시공법 저장·되돌리기, 관급/설치주체 저장·되돌리기 확인 후
검증으로 바꾼 값은 원래대로 복원.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
일감 9. 수량 결과(작업 공종 축)와 자재 총괄(자재 축)을 각각 낸다.
- 자재 줄에는 공종코드를 붙이지 않음. 붙이면 자재가 내역 줄로 오해되어
이중계상이 됨. `verify_no_code_on_materials()` 로 코드에 못 박음.
- `in_bill` 을 실어 무대·합계 줄을 가름. 수량은 그대로 넘김 —
무대+도자+덤프 = 총 운반토량 검산에 쓰이는 값이라 빼면 검산이 죽음.
- `ground_class_set` 동봉. 「연암」이 몇 갈래 중 하나인지 알아야 예산내역서가 섬.
- 매핑표는 데이터 파일(`resources/data_work_item_mapping/`). 못 이은 줄은
빈 코드로 두지 않고 `unmatched_work_items` 로 냄.
품셈 형태 판정 교차 확인 — 「첫 칸이 갈래 딱지이고 이름이 둘째 칸」인 표에서
직종을 첫 세 행에서만 찾아 12장 구조물 표 8건이 미판정으로 빠져 있었음.
딱지를 알아보는 규칙을 맨 마지막에 두어 앞 판정을 흔들지 않고 해소
(미판정 85 → 77, 생산량형 16건 불변). 비율 지시를 먼저 보면 강관동바리 같은
소요량표가 참조로 넘어가므로 소요량을 먼저 보게 순서를 잡음.
검증 — 인계 22건 + 품셈 5건 통과, 전체 500 passed.
실서버 `GET /quantity/handoff` 200 (내역 10줄·제외 1·자재 4, 갈래세트 5).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
조율 창 지적으로 건설공사 표준품셈 1-3-1 을 대조함. 결과를 데이터 파일에
근거와 함께 남김.
- 야면석·고임돌·물구멍 — 산림·건설 두 품셈 모두 이름 없음(`not_found`).
건설품셈이 다루는 석재는 해상 사석과 원석(마름돌용)뿐이고 제7장 돌공사에는
재료 할증률표 자체가 없음. 확인한 범위를 `checked` 로 함께 기록.
- 막자갈 — 건설품셈 2호 노반재료에 4 % 로 있으나 우리 쓰임은 뒤채움이라
조건이 다름. `candidates_pending_user` 에 조건과 함께 두고 엔진은 쓰지 않음
(지식DB 는 근거 가이드이지 값을 확정하는 곳이 아님).
- 산림품셈 값에는 `pumsem: forest` 표시. 보완 출처를 섞지 않기 위함.
- 물구멍은 공제 대상이 아니라 관 자재임을 코드에 명시. 관 규격(법 Ø3~6㎝ /
실무 Ø50)과 간격(법 2~3㎡ / 엔진 2.0)이 미확정임을 잠정으로 표시.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
일감 6 엔진. PLAN 8-6·8-8·8-15.
식을 발명하지 않음 — 실무 원본을 옮김
울진 설계원본 5. 구조도(기번3).xlsx 에 구조물 31종 계산식이 살아 있는 수식으로
남아 있음(8-15). 그 식을 옮기되 식 안에 상수로 박혀 있던 값(돌 뒷길이 0.45 ·
고임돌 0.15 · 돌중량 0.88 등)은 **계수표로 뺌** — 뒷길이가 바뀌어도 식을 안 고침.
실무 방식의 약점을 여기서 고친 자리.
치수 정본은 하나 — structures.json 의 type_id·options 를 읽어 계산.
자기 치수표를 따로 들지 않음(도면은 H=1.5 인데 수량은 옛 치수로 도는 사고 방지).
⚠⚠ 이중계상 셋을 코드로 막음
㉢ 배합을 분해하지 않음 — 콘크리트 ㎥·모르터 ㎥ 에서 멈춤. 시멘트·모래로 쪼개는
것은 B09 일위대가 몫이고 양쪽이 쪼개면 시멘트가 두 배가 됨.
verify_no_mix_components() 가 산출물에 배합 성분이 나타나면 알림.
⚠ 정확히 같은 이름으로만 봄 — 부분문자열로 재니 「막자갈」(뒤채움 재료)이 배합
「자갈」로 오탐됐음. 개발 중 실제로 걸린 자리라 시험에도 박음.
㉠ 할증을 안 붙임 — surcharge_applied=False 로 응답에 못 박음. 할증은 자재총괄 한 곳뿐.
· 성분마다 destination 을 담 — earthwork(토공 대분류로 합산) / material(자재총괄) /
unit_price(일위대가 재료비). 울진 토적집계 D12~D14 가 구조물 터파기 1,248/30㎥ ·
되메우기 739㎥ 를 개별 줄이 아니라 토공으로 합산한 것이 근거.
⚠ 공제 규칙을 주석에 원문째 — 품셈 1-2-1 「물구멍·이음줄눈·모따기·철근은 공제하지
않음」. 치수를 곧이곧대로 빼면 실무값과 어긋남. 빼는 것은 관 통과 단면처럼 실제로
비어 있는 자리뿐.
원본에 없는 칸은 지어내지 않음 — 뒷길이 60㎝ 돌중량이 원본 표에 비어 있어 야면석을
내지 않고 그 사실을 notes 로 알림(8-8 ㉮).
⚠ 실무값과 0.012 차이 — 우리 쪽이 맞음
터파기 1.5375 vs 실무 1.55. 평균두께가 0.825 인데 실무 시트는 표기값 0.83 으로
다시 계산해 1.545 가 됨. 품셈 1-2-2 는 표기 규칙이고 계산은 전정밀(8-16).
맞추려고 식을 비틀지 않고 허용오차를 그 차이만큼 둠.
검증 — 17건 통과. 배합 금지·할증 금지·행선지 표시·계수표 교체·빈 칸 미생성을 각각 못 박음.
실데이터(route 150 의 돌쌓기(찰) H=2.5·L=10)로 확인 — 성분 10개, 배합 위반 0.
전체 회귀 450 passed (실패 1건은 B05 코리도 기존 깨짐).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
일감 4·5 화면 마무리. 앞 `auto:` 커밋(4756f0fe)은 토적표 그리드·로케일 배선분임.
우측 — 실무 산출서 시트를 탭으로
토적표 · 토공집계 · 운반거리. 탭을 눌러 갈아 끼움.
토공집계 열은 거창 실무 시트 그대로(구분·공종·규격·단위·계·비고).
운반계획이 아직 없으면 빈 표 대신 「종단설계에서 확정하면 생김」을 보임.
좌측 — 산출 조건 입력
⚠ 암 갈래 칸 수를 코드에 안 박음 — 프로젝트 세트가 정함(지금 거창5 = 5칸).
반영률 4칸, 기본 100 %. 실무 관측 80/50/80 은 기본값 아님(PLAN 8-11 · 법대로).
반영률 이름을 사람 말로 보임 — 서버 키(fill_slope_compaction)를 그대로 띄우면
설계자가 못 읽음. 로케일 키 4개 추가.
[저장] 신설 (CLAUDE.md 5장 데이터 3층)
조작은 캐시에만 쌓이고 [저장]에서만 정본(project_settings.json)으로 감.
자동저장 안 만듦. quantity 구획만 감 — estimation 은 B09 것이고 서버가 막고 있음.
저장 뒤 표를 다시 받아 그림 — 조건이 바뀌면 집계·운반 값이 달라짐.
저장 안 한 변경이 있으면 나갈 때 알림(beforeunload).
⚠ [초기화]는 안 달았음 — 5장의 [초기화]는 초기값을 작업본에 덮어쓰는 것인데
설정에는 대응 초기값이 없어 재계산 단추로 오해될 자리임. TODO(미결) 주석으로 남김.
검증 — 공용 브라우저 실화면, 타입검사 0.
탭 3장 · 입력칸 9개(암 5 + 반영률 4) · 단추 [저장][확정].
토공집계 10행, 값 일치 — 흙깎기 토사 2,526.99 · 측구 90.51 · 보정량계 6,511.06.
[저장] 실제로 눌러 확인 — 연암 60·보통암 40 을 넣으니 암 3,512.09 가
2,107.25 / 1,404.83 으로 갈리고(60:40 안분), 성토면다짐 80 % 를 넣으니
13,518.6 → 10,814.9 로 바뀌며 비고에 「성토면 80 % 반영」이 남음.
⚠ 넣었던 값은 전부 원래대로(0·0·100) 되돌려 놓았고 화면도 사용자가 보던 주소로 복귀.
⚠ 개발 중 발견 — vite 가 옛 모듈을 물고 있어 첫 확인이 옛 화면이었음.
쿼리를 붙여 새로 물린 뒤 재확인(계획서 7-2 의 그 함정).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
일감 4·5 화면의 표 부품. 이 커밋 시점에는 **아무 데서도 import 하지 않음** —
「신규 파일 먼저, 등록 줄 나중」 두 걸음 규칙(공용 파일 동시 편집 사고 예방).
토공집계표 — 열은 거창 실무 시트 그대로(구분·공종·규격·단위·계·비고).
같은 구분이 이어지면 한 번만 적음(실무 시트가 병합해 두는 자리).
비고에는 설계자가 정한 값만 남음 — 반영률을 바꿨을 때, 비율 합이 100 이 아닐 때.
기본값 그대로면 비움. 안내가 매번 뜨면 잡음이 됨.
운반거리 — 내역 줄(가중평균)과 근거 구간 수를 함께 보임.
⚠ 무대 줄에 「내역 제외」 표시 + 「품셈 1-2-7 소운반 20m 이내는 품에 포함」을 적음.
「제외」만 있으면 빠뜨린 것으로 오해됨. 규칙이 코드에만 있으면 잊히므로 화면에 남김.
운반계획이 아직 없으면(=[확정] 전) 빈 표 대신 「종단설계에서 확정하면 생김」을 보임.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
일감 4·5 의 API 덩어리.
한 응답에 실음
earthwork-table 이 토적표(체적) · slope(사면 4계열) · haul(운반 가중평균) ·
summary(토공집계표) · settings 를 함께 냄. 실무 산출서가 한 벌로 움직이는 값이라
나눠 부르면 같은 측점 목록을 여러 벌 들게 됨.
운반계획이 없으면 빈 표가 정직함
운반계획은 [저장]·[확정]에서 정본에 남는 값임(longitudinal.data.mass_haul).
아직 안 돌린 프로젝트는 없음 — haul_available 로 알려 화면이 「확정하면 생김」을
말할 수 있게 함. 지어내지 않음.
산출 조건 저장 — PUT /quantity/settings
⚠ 자동저장이 아님(CLAUDE.md 5장). 조작은 캐시에 쌓이고 여기서만 작업본으로 넘어감.
⚠ quantity 구획만 씀 — estimation 은 B09 것이고 모듈이 구조로 막고 있음.
보내지 않은 칸은 저장분을 그대로 둠.
프로젝트 경로를 못 찾아도 조회는 기본값으로 서게 함 — 설정은 계산을 거드는 값이지
없으면 못 도는 값이 아님.
암 비율 안분을 비고에 드러냄 (조율 창 지적)
설계자가 60/30 을 넣으면 총량 보존을 위해 66.7/33.3 으로 안분됨. 값이 말없이
바뀌는 것이라 「입력 합 90 % → 100 % 로 안분」을 비고에 남김. 합이 100 이면
비고를 비움 — 제대로 넣었는데 안내가 뜨면 잡음이 됨.
검증 — 회귀 433 passed (실패 1건은 B05 코리도 기존 깨짐).
엔드포인트 3종 등록 확인(earthwork-table 2 + settings 1).
안분 비고는 시험으로 못 박음(합 90 이면 비고 있음 · 100 이면 없음).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
**㉣ 작업효율을 두 곳에 넣지 않는다 — 계획서에 없던 네 번째 규칙**
- 품셈은 작업효율 `E` 를 **작업량 산정**에 넣음(`Q = n·q·f·E`, 8-1-4). 시간당 사용료는
**1일 8시간**으로 나눔(8-1-6 「관리비는 1일 8시간 초과해도 8시간으로 계산」).
**양쪽에 넣으면 같은 효율이 두 번 곱해짐.**
- 실무 관측이 효율을 사용료 쪽에 미리 넣어 두어(굴착기 0.7㎥ 노무 55,700/hr =
일당 ÷ 5.09h), 그 값을 보고 나눗수를 고치는 사고가 정확히 이 자리에서 남.
- `reject_efficiency_in_hourly_rate()` · `check_operator_hours_basis()` 추가하고
**`hourly_machine_cost()` 안에서 실제로 호출** — 함수만 있고 안 부르면 없는 것과 같음.
- PLAN 9-6 의 금지 규칙을 셋 → **넷**으로 늘리고 근거·경위 기록.
기계 사용료 11 % 차이는 **「설명된 차이」**임을 표로 못 박음(맞추려 손대지 말 것).
**`B09_Estimation_UnitPrice.py` 신설 — 층을 실제로 쌓음**
- `S 취득가 · L 노임 · M 연료 → X 시간당 사용료 → B 일위대가`.
**시간당 사용료를 미리 계산해 넣지 않음** — 쌓아야 화면이 「무엇으로 이루어졌나」를
보일 수 있음(8-13 계산 과정을 감추지 않음).
- 조종원 수량 = `인/일 ÷ 8` 로 상세에 들어가 ㉣이 데이터로도 드러남.
- 자원이 하나도 안 붙은 공종은 **빈 줄로 안 세움** — 0 원 일위대가가 내역에 서면 안 됨.
- ㉠ 가드를 `verify_surcharge_once()` 로 실제 호출 — 일위대가 재료비는 **할증 전** 값.
산출 — 제목 **189**(일위대가 64 · 기계 층 3 · 노임·연료), 건너뛴 공종 0.
실측 `X-0201-0070` 굴착기 0.7㎥ = 재 26,130 + 노 35,412 + 경 24,554.
자체검증 — 신규 5건 포함 `pytest tmp/tests/ -q` **116 passed** · ruff 통과.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
일감 4·5 의 엔진 덩어리. PLAN 8-11·8-3·8-7.
프로젝트 설정 (common_util/common_util_project_settings.py)
자리 = <project_root>/project_settings.json, 루트의 project_manifest.json 옆.
매니페스트 stages 는 단계 산출물 목록이고 설정은 두 페이지가 함께 읽는
프로젝트 값이라 단계 폴더에 넣으면 주인이 애매해짐.
구획 quantity(B08) · estimation(B09) — 남의 구획은 읽기만.
⚠ 경계를 코드로 막음 — save_section() 이 이름 붙은 한 구획만 갈아 끼우고
통째로 쓰는 함수를 두지 않음. 두 페이지가 같은 파일을 쓰므로 통째로 덮으면
상대 값이 사라짐(오늘 main.py 에서 같은 모양의 사고를 이미 겪음).
⚠ *_override 기본은 None — 「안 정했으면 config 정본을 씀」. 기본값을 복사해
넣으면 정본이 바뀌어도 옛 프로젝트가 안 따라옴.
⚠ dataset_versions 는 기록이지 정본이 아님 — 되살릴 때 쓰는 정본은 프로젝트
스냅샷이고 어긋나면 스냅샷이 이김.
estimation.rate_dataset 은 「연도」가 아니라 판을 가리킴 — 제비율은 연중에도
개정됨(현행판 2026-04-13). B09 확정 반영.
토공집계표 (열 = 구분·공종·규격·단위·계·비고, 거창 실무 시트 그대로)
⚠ 암 갈래 개수를 코드에 안 박음 — 울진 2 · 거창 5 · BOM 1 로 공사마다 다름.
프로젝트 설정의 세트를 받아 그만큼 줄을 냄. 비율이 아직 없으면 지어내지 않고
「암」 한 줄로 냄. 비율 합이 100 이 아니어도 준 비율끼리 안분해 총량 보존.
⚠ 반영률 기본 100 % — 실무 관측 80/50/80 은 참고이지 기본값 아님(법대로).
바꾼 경우에만 비고에 「80 % 반영」이 남음 — 누가 정한 값인지 보이게.
운반 가중평균 ((운반수단 x 지반유형)별 1줄)
실무 울진이 도자 토사/암 · 덤프 토사/암 4줄을 올림. 가중평균 = Σ(토량x거리)/Σ토량
으로 단순평균이 아님. 개별 구간은 근거로 함께 냄 — 어느 구간이 그 평균을
만들었는지 되짚게.
입력은 이미 있는 HaulPlan — 띠·장거리이동에 equipment·haul_distance_m·
지반유형별 물량(ea/rr/br)이 다 있어 다시 세지 않음.
⚠ 무대(free_haul)는 in_bill=False — 품셈 1-2-7 로 품에 포함이고 인력운반 10-6
도 「소운반 20m 초과분」이라 붙일 단가가 없음. 값은 내되 내역 줄만 뺌 —
「무대+도자+덤프 = 총 운반토량」 검산에 씀.
검증 — 28건 통과 (토공집계·설정 19 + 운반 9).
가중평균이 단순평균과 다름을 못 박음(도자 토사 600@40+400@50 → 44m, 45 아님).
울진2·거창5 두 세트가 같은 코드로 서는 것, 무대가 내역 줄이 아닌 것,
구획을 따로 저장해도 상대 값이 안 지워지는 것을 각각 시험함.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
**빈 두 성분을 채움** — `mach_fuel_rate`·`mach_operator_map` 0건이라 시간당 중기사용료의
재료비·노무비가 비어 있던 자리(손료만 있으면 실제의 4분의 1). 건설품셈 **8-4 운전경비
산정** 표에서 뽑아 **92 기종** 확보.
⚠ **표가 열 단위로 뭉쳐 옴** — PDF 추출 탓에 `분류번호` 한 칸에 코드 31개,
`주연료` 한 칸에 값 31개가 공백으로 이어 붙어 있음. **위치로 짝짓되 개수가 안 맞으면
그 줄을 통째로 버림**(10건 버림, 목록으로 남김). 어긋난 채 짝지으면 **다른 기종의
연료값이 조용히 붙는** 자리라 억지로 안 맞춤.
- 코드는 앞자리를 이어받음 — `0201-0012 0020 0040` → `0201-0020`·`0201-0040`.
- ⚠ **이름 칸은 못 씀** — 표 전체 기종명이 한 덩어리로 옴. **코드로 613 기종
카탈로그에서 이름·규격을 가져옴**(카탈로그에 없는 코드는 버리고 목록에).
**검증(굴착기 무한궤도 0.7㎥)** — 주연료 11.6 ℓ/hr · 잡재료 22 % · 조종원 1인/일.
시간당 = 재료 26,130(연료 21,418 + 잡재료 4,712) + 노무 35,412 + 경비 24,554 = **86,096**.
STC 2024 관측 96,829 과 **11 % 차** — 손료·재료는 근사하고 **노무가 갈림**
(관측 55,700/hr = 445,600/일로 어느 직종보다 높음). **맞추려 손대지 않음** — 관측값은
대조용이고 우리는 법대로 감. ⚠ 조종원 직종 확인 항목으로 올림.
- **잠정 표시** — 조종원 **직종명이 품셈 8-4 에 없어** `aliases` 기반 규칙(트럭 계열 =
화물차운전사, 그 밖 = 건설기계운전사)으로 매김. 결과에 `operator_mapping_is_provisional`
로 드러남. TODO(미결 9-6).
- **유가는 전국평균 잠정**, 지역 파라미터 자리(`region`)만 뚫어 둠 (품셈 8-1-7 5호).
- **파생 파일로 냄** — `resources/data_cost_machine_operating/`, 기준자료 안 건드림.
`derived_from` 에 `mach_base` 판의 세 쪽을 적어 낡으면 드러나게 함.
자체검증 — 신규 6건 포함 `pytest tmp/tests/ -q` **110 passed** · ruff 통과.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
B06 담당(랩탑) 실측 회신 반영. 미교차는 드문 예외가 아니라 상시임 —
route 169 는 22/105(21 %), 이 노선은 17/65(26 %). 매번 요란하면 곧 무시당함.
고친 것 셋
· 붉은 오류 → **주의 표시**(테두리를 danger 에서 muted 로). 잘린 줄 표시도 같게.
· 목록을 `details` 로 **접어 둠**. 필요할 때만 폄.
· 문구를 **한 덩어리**로 묶음 — 절·성토 면적 · 사면길이 · 사면적이 전부 같은 사유로
잘리므로 항목마다 따로 띄우지 않음.
안 넓히는 까닭 (주석에 남김)
미교차 절반 이상이 계곡·절벽처럼 지형이 설계 사면에서 멀어지는 자리라 반폭을 늘려도
영원히 안 닫힘. 닫히는 쪽도 중앙값 +3m 인데 꼬리가 +292m 이라 전역 확대는 값이 안 남.
2026-09-03 사용자 확정 「경고로 대체」가 그대로 유효함.
정본 키 대조 — StationSlope.unclosed 가 design.slope_unclosed 에서 나오는 것 확인
(B06_Section_Engine_Design.py:807 이 내는 그 값).
검증 — 공용 브라우저 실화면. 타입검사 오류 0.
접힌 상태 `details[open=false]` · 요약 문구 한 줄 · 측점 단추 17개.
펴면 목록이 보이고, 첫 단추(NO.13)를 누르면 그 줄로 가서 강조됨.
조작한 화면은 사용자가 보던 주소로 되돌려 놓음.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
일감 3 의 API·화면 덩어리. 토적표 오른쪽 절반(실무 V~AI)이 화면에 섬.
한 응답으로 냄
실무 토적표가 한 장이라 화면도 한 장임. 나눠 부르면 두 번 왕복하고 같은 측점
목록을 두 벌로 들게 됨. earthwork-table 응답에 slope 를 함께 실음.
열 구성 — 계열 4 x 성토면/절토면 = (거리, 면적) 7쌍
층따기[성토면] · 면고르기 · 법면보호공(종자파종) · 지장목제거.
거리 = 그 측점 사면길이, 면적은 토적표와 같은 평균단면적법.
합계행은 면적만 — 거리(사면길이)는 합이 뜻이 없음(실무 시트도 비움).
⚠ 잘린 측점을 감추지 않음 (PLAN 8-4b)
사면이 원지반을 못 만난 측점은 사면길이·면적이 그 지점에서 잘려 있음.
경고 문구에 **무엇이 잘렸는지**를 적고(「실제 값은 이보다 큼」), 측점 단추를
누르면 그 줄로 가서 잠깐 강조됨 — 17곳을 눈으로 찾게 하지 않음.
잘린 줄은 측점 칸 왼쪽에 표시가 남음.
검증 — 공용 브라우저 실화면. 타입검사 오류 0.
머리글 3단 13/12/28셀, 대분류에 층따기·면고르기·법면보호공·지장목제거,
3단에 거리/면적 쌍. 본문 65행 x 34열(토공 20 + 사면 14).
NO.1 사면값 6.4/64.4 · 3.5/93.0 등이 엔진값과 일치.
잘린 줄 17개 표시 · 경고 문구 · 측점 단추 17개 확인.
합계 면고르기 성토 13,518.6㎡ · 절토 5,433.7㎡ 로 엔진 합계와 같음.
회귀 404 passed (실패 1건은 B05 코리도 기존 깨짐).
조작한 화면은 사용자가 보던 주소로 되돌려 놓음.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
**`B09_Estimation_MachineCost.py` 신설 — 취득가 → 시간당 사용료 두 단계**
- `mach_base_2026.json` 실사: `mach_price` **613 기종**(`machine_code`+`specification`),
`mach_loss_coef` 387건(시간당 손료계수·내용시간·연간표준시간).
- **시간당 손료 = 취득가 × 손료계수.** 취득가가 **천원 단위**라 환산을 놓치면 1,000배
틀리는 자리 — 테스트로 박음. 굴착기(무한궤도) 0.7㎥ → **24,554원/hr**
(STC 2024 관측 23,128 과 같은 자릿수, 취득가 판 차이로 설명됨).
- ⚠ **빠진 성분을 0 으로 안 때움** — `mach_fuel_rate`·`mach_operator_map` 이 **0건**이라
연료(재료비)·운전사(노무비)를 못 채움. `HourlyMachineCost.gaps` 로 **공백을 알림**.
실측 비중이 노무 53·재료 20·경비 27 % 라 손료만 쓰면 **4분의 1**이 됨 — 조용히
총액에 섞이면 안 되는 자리.
- 손료계수 없는 기종 **230건**도 0 으로 안 때우고 멈춤.
**자원 축에 기종 매칭 추가**
- 기종 셀은 괄호 안에 **형식과 규격이 섞여** 있음 — 「굴착기(무한궤도, 0.7㎥)」는
이름 `굴착기(무한궤도)` + 규격 `0.7`. 형식은 이름의 일부이고 숫자 조각만 규격임.
- **규격이 옆 칸에 있는 표**가 많아(`['굴착기 (무한궤도)','굴착기(무한궤도,0.2㎥)','hr',…])
뒷 칸에서 규격 후보를 찾아 고름. 규격 없이 매칭 성공으로 치지 않는 규칙은 그대로.
- 산출 갱신 — 매칭 86 → **91행**(노무 86 + 기종 5), 미매칭 274 → **269건**.
자체검증 — 신규 7건 포함 `pytest tmp/tests/ -q` **104 passed** · ruff 통과.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
메인 창의 공종 축(`resources/data_work_item_master/`)은 **읽기만** 하고, 결과는
**내 소관 경로** `resources/data_cost_resource_axis/` 에 냄 — 메인이 품셈을 다시
돌리면 그 폴더가 덮이므로 안에 섞으면 사라짐.
- ⚠ **`pum_form` 을 먼저 봄** — `productivity` = 1 ÷ 값 · `requirement` = 값 ÷ 기준수량.
**뒤집으면 20배 틀림.** 형태를 모르는 표(`undetermined`)는 **값을 안 씀**, 한쪽으로
단정하지 않고 멈춤. 테스트가 뒤집힘을 자릿수로 잡음.
- `coefficient`(19)·`reference`(94)는 공종이 아니므로 **일위대가 항목으로 안 세움**.
- **규격이 없으면 매칭 성공으로 안 침** — 「굴착기」와 「굴착기 0.7㎥」는 단가가 다름.
이름이 여럿이면 규격 없이는 못 고르고 `unmatched` 로 감.
- **못 맞춘 것은 빈칸이 아니라 목록** — 다만 표 머리글·소계·기호(`f`·`E`)·규격 구간
(`10∼12`·`50이상`)·절번호는 자원이 아니므로 먼저 걷어냄. 안 걸렀을 때 1,550건이던
목록이 **274건의 실제 공백**으로 줄어 쓸 수 있는 목록이 됨.
산출 — 매칭 **86행**(노무, 7직종: 보통인부 59·특별인부 19·조경공 4 등) ·
못 맞춘 **274건**(상위: 치즐소모량·자재·굴착기(무한궤도) 등).
⚠ **노임 카탈로그만 있어 노무만 맞음** — 기계·자재 카탈로그가 아직 없어 그 계열은
전부 못 맞춘 목록으로 감. 사유 문구에 그 사실을 적어 「이름이 틀림」과 구분함.
자체검증 — 신규 12건 포함 `pytest tmp/tests/ -q` **97 passed** · ruff 통과 · 409줄.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PLAN 8-4b 의 「사면적 없음」 구멍을 메움. 일감 3 의 엔진 덩어리.
⚠ B06 무접촉 — 저장분만으로 유도
설계 엔진이 cut_slope_segments 를 내기는 하나 **정본에 저장되지 않음**
(실측: route 150 측점 20.0 의 저장 design 키 33개에 그 키 없음. 저장되는 것은
화면이 보낸 설계 지정이고 조회는 저장분을 그대로 실음). 그 값을 원천으로 쓰면
사면적이 조용히 0 이 됨.
대신 design_line + 저장된 경사비로 유도함 — 노체 끝 바깥으로 나아가며 기울기가
설계 경사비와 맞는 연속 구간이 사면이고, 원지반은 경사비가 안 맞아 저절로 끊김.
성토도 같은 원리로 잡힘(원지반선이 없어도 됨). 2단 사면(암/토사)은 경사비가
달라 그대로 갈림.
⚠ 측구를 사면으로 세지 않음 — 개발 중 실제로 났던 결함
측구 벽 경사가 n=1.0 으로 토사 절토비와 같아 그대로 걸렸음. 사면 시작점을
노체 끝이 아니라 **측구 바깥 끝**(road_edges ± ditch.top_width_m)으로 옮겨 고침.
그 형상을 실측 그대로 시험에 세워 재발을 막음.
사면 4계열 x 성토면/절토면 = (거리, 면적) 7쌍
층따기[성토면만] · 면고르기 · 법면보호공 · 지장목제거.
거리 = 그 측점 사면길이, 면적 = 토적표와 **같은 평균단면적법**(계산을 두 벌로 안 짬).
법면보호공은 면고르기를 참조하되 끊을 수 있게 둠 — 실무 시트가 값이 같았던 것은
엑셀 복사였고 오솔길 산출에는 보호공 4열이 0 이었음.
반영률은 법정값 아님 — 기본 100 %, 설계자 입력(PLAN 8-11 · 8-10 법대로).
TODO(미결) — 실무 관측 80/50/80 중 지장목제거는 밑수가 안 맞아(14,061 != 10,782)
쫓지 않고 100 % 로 둠.
잘린 측점을 감추지 않음 — slope_unclosed 를 물고 와 unclosed_stations 목록으로 냄.
사면이 원지반을 못 만나면 사면길이도 잘려 있으므로 화면이 드러내야 함.
검증 — tmp/tests/test_b08_slope_area.py 15건 통과.
실측 설계선을 그대로 세워 측구 제외·2단 암토사 분리·성토 유도·원지반 끊김을 못 박음.
실데이터(route 150, 65측점) — 면적이 있는데 사면길이가 0 인 경우 0건,
잘린 측점 17곳 검출.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
데스크탑 창이 「법정 경사 검사가 빈 값을 볼 수 있다」고 알려 와 확인함. **검사 자체가 없어
문제 없음** — 별표2 검사는 오늘 폐기됐고(`cc428d7e`, 암질을 횡단도에서 안 고르기로 사용자
확정), 지금 이 값을 읽는 코드는 **한 곳도 없음**(계산해 내보내기만 함).
같이 확인한 사실 — 저장분에도 안 들어감. 실측(공용 DB) `cross_sections.data.design` **33키**에
`cut_slope_segments` 없음(같은 자리에 `cut_area_m2` 는 있음). 저장되는 것은 화면이 보낸
**설계 지정값**이라 엔진 출력 전체가 아님.
그런데 주석 셋이 아직 「법정 경사 검사가 읽는다」로 남아 있어 **다음 사람이 저장분에서 읽으면
된다고 오해**할 자리였음. 그 셋을 고쳐 ① 지금 읽는 곳 없음 ② 저장분에도 없음 ③ 남겨 두는
까닭은 소단 기하가 이 셈 위에 서 있어서 ④ **되살릴 때는 저장분에서 읽지 말고 계산해서 쓸 것**
을 적음. 코드는 한 줄도 안 바뀜(주석만).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
**단수 처리를 「출력 위치」에 바인딩** (`B09_Estimation_Rounding.py`)
- `단수처리_규칙.md` §1 — 같은 수량×단가라도 **내역서 본체는 절사, 집계표는 반올림**.
함수가 항목이 아니라 **표 종류**에 붙음. 자리를 안 대고 부르는 길을 안 둠(기본값 없음).
- ⚠ **집계표와 본체의 합이 어긋나는 것이 정상** — 「합계가 1원 틀린다」에 계산을 고치지
않도록 `summary_vs_body_gap()` 으로 차이를 값으로 드러내고 화면 문구를 상수로 둠.
- 계산은 전정밀, 자르는 것은 표 그리는 자리에서. 값은 원문에서 복사 안 하고 문서를 가리킴.
**단가 계층 — 표를 세 벌 만들지 않음** (`B09_Estimation_PriceBook.py`)
- 「제목 + 상세」 한 쌍 + 종류 구분. 층은 `S 중기취득가 → X 시간당사용료 → B 일위대가 →
D 단가산출`, 바닥은 `M 자재`·`L 노임`, `W 일식·견적`은 **단가 0**(무대처리, 8-7 ㉡).
- 금액은 어느 층이든 **재료·노무·경비 3분할**, 합계 = 셋의 합.
- **단가 슬롯 6개** — 번호 고정, **이름은 프로젝트 설정**. 기본 채택 6번(`JUKNM=6`).
슬롯별 **근거 쪽수**(STC `PG_` 열) 자리도 둠.
- 안전장치: 채택 슬롯이 비면 **0 으로 안 때우고 멈춤** · 없는 코드는 `unmatched_codes()`
로 **목록으로 냄** · 참조 순환 감지.
**프로젝트 스냅샷** (`B09_Estimation_Storage.py`)
- 채택 단가를 `<project_root>/B09_Estimation/v1/` 에 사본으로. 기준자료가 갱신돼도
**옛 프로젝트 결과가 안 바뀜**. `dataset_version` 은 `dataset_id`+`effective_date`+
`sha256` **세 쪽**. 사본이 바뀌면 지문 불일치로 멈춤. 차수(당초·1~3차) 자리 비워 둠.
자체검증 — 신규 13건 포함 `pytest tmp/tests/ -q` **85 passed** · ruff 통과 ·
파일 최대 534줄. 중기 실측값(`X00005` 96,829 = 노 55,700 + 재 18,001 + 경 23,128)으로
3분할 유지·층 쌓임 확인.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
`단수처리_규칙.md` §3 원문을 읽다 **입력 의미를 잘못 잡은 것**을 찾음.
실무 서류의 「관급자재대 69,850,000」은 이미
`ROUNDUP(순자재대 69,474,220 + 조달수수료 375,160, −3)` 한 값인데,
그 합계를 순자재대 자리에 넣고 있었음. 그래서 안전관리비 관급항이 부풀었고,
그 어긋남을 「조달수수료 차감 옵션」으로 덮고 있었음.
- **입력을 순자재대·수수료로 나눠 넣는 것으로 정정.** 그러면 ㉮ 관급자재대 천원 올림
㉯ 안전관리비 관급항 `순자재대 ÷ 1.1` 이 **둘 다 저절로 맞음**.
- ⇒ `deduct_procurement_fee_for_safety` **옵션 제거**(엔진·법정경비·라우터).
8-10 의 「차감은 규정 문구가 아님」과 결론은 같되 이유가 더 단순함 —
**애초에 수수료는 관급금액에 안 들어감.**
- 잘못 넣는 사고를 테스트로 박음 — `test_owner_supplied_input_is_net_material_not_total`
(합계를 넣으면 안전관리비가 8,629 원 = 375,160 ÷ 1.1 × 2.53 % 커짐).
- 필드 주석에 「실무 서류의 관급자재대를 그대로 넣지 말 것」 경고 추가.
자체검증 — **관행 옵션 없이 기본값만으로** 두 벌 재현:
2024 요율 → 안전 16,586,996 · 총공사비 1,201,879,000 / 현행 요율 → 안전 **18,586,091**.
화면 실측(5174) — 안전관리비 A 18,586,091 채택 · 관급자재대 69,850,000.
pytest 72 passed · ruff 통과 · tsc 통과 · 백엔드 재시작 후 200.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
B08 토적표 라우터와 B09 원가계산 라우터가 main.py 의 같은 자리(import 블록·
include_router 목록)를 각자 한 줄씩 늘려 충돌함. 둘 다 필요한 줄이라 양쪽을
그대로 살림 — 어느 쪽도 버리지 않음.
확인 — 충돌 표시 0건, 앱 import 성공, 두 라우터 경로가 모두 등록됨
(quantity 3건 · estimation 3건).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PLAN 8-4b 열 명세를 화면에 세움. 일감 2 의 마지막 덩어리(엔진 → API → 화면).
왜 실무 서식 그대로인가
이 화면의 첫 사용자는 「프로그램이 맞나」를 확인하려는 설계자임. 보기 좋게
재배치하면 실무 산출서와 눈으로 대조를 못 함. 열 순서·머리글 문구를 실무
토적표(= 오솔길 1.BOM 36열)에 맞춤.
소수 자리는 표기 규칙일 뿐 (PLAN 8-16)
서버는 전정밀 값을 주고 자르는 것은 화면뿐임. 실무 시트 관측대로
단면적·체적 2자리 · 보정량계·유용토·차인·누가 1자리 · 거리 정수.
원가 쪽(줄마다 원 단위 절사)과 규칙이 반대라 그 코드를 옮기지 말 것.
구성
좌측 = 산출 조건 읽기 전용(산출법·토량환산계수). 계수는 서버 상수가 유일
정의처라 화면이 값을 다시 적지 않음.
우측 = 시트 탭 + 표. 지금 서는 장은 토적표 하나, 나머지 6장은 차례로 붙임.
표는 한 번만 받아 좌측·우측이 함께 씀(중복 호출 없음).
측점 열·머리글은 sticky — 가로로 굴러도 어느 줄인지 보임.
locale 은 B08 키 8개만 추가 (다른 창과 겹치는 파일이라 기존 줄 무접촉).
검증 — 공용 브라우저 실화면.
타입검사 오류 0. 탭 「토적표」, 3단 머리글 3행(9/5/14셀), 본문 65행 x 20열,
합계행 표시. 둘째 줄이 API 값과 일치: NO.1 거리 20 · 절토토사 1.96/22.34/20.10
· 암 2.54/25.43/29.24 · 측구 0.08/2.58/2.33 + 0.10/1.02/1.17 · 보정량계 52.8
· 성토 4.82/48.79 · 유용 48.8 · 차인 4.0 · 누가 4.0.
⚠ 어두운 테마에서 머리글이 묻히던 것을 프로젝트 테마 변수로 바꿔 고침 —
대비 실측 머리글 10.51:1 · 본문 11.32:1 (기준 4.5:1).
조작으로 바꾼 화면은 사용자가 보던 주소로 되돌려 놓음.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
eomsangdonandClaude Opus 5