knowledge(마스터값): 품셈재료 삭제조건 정리 — 178줄(139·17·22) 갈래별 조건 · 변수참조 제안

build_로직_재료_고르기.py --보기 로 오늘 다시 셈(139+17+22=178, 드리프트 없음).
갈래별 「지우려면 무엇이 있어야」 한 줄씩 · {변수} 22줄 못 바꾸는 까닭 셋 · 고르기 규격칸에
변수 그대로 두는 제안(파형강관 GF000176 전례 근거, 구현 안 함).
삭제 뒤 남을 이름표 정보는 별도 매핑 파일로 옮기는 안 제안(자재품목 원자료는 안 건드림).

resources/master_data/ref/_품셈재료_삭제조건.md

@@ -0,0 +1,43 @@
+# 품셈재료 테이블 삭제 조건 (2026-09-21)
+
+`재료_품셈재료.json`(품셈재료)을 지울 수 있는 상태인지 정리 — 로직이 아직 이 테이블을 바로 가리키는 줄 세기 · 갈래별 조건 · 삭제 뒤 남길 정보 자리 제안.
+
+## 지금 남은 옛 방식 줄 — 178줄(살아있음, 오늘 날짜로 다시 셈)
+
+`build_로직_재료_고르기.py --보기` 로 로직 파일을 다시 훑은 값(글 셈 · 데이터는 안 고침) — `ref/_남은_옛재료줄.md`(2026-09-21 작성) 과 같음, 드리프트 없음.
+
+| 갈래 | 줄 | 확인 방법 |
+|---|---|---|
+| ① 자재품목에 짝 없음 | 139 | `build_로직_재료_고르기.py --보기` 「옛 방식 그대로」 156 중 모래·자갈·전력 17 을 뺀 나머지 |
+| ② 지역·계약종별 계산 때 풀림(모래·자갈·전력) | 17 | 로직 키 고정 목록(`ref/_남은_옛재료줄.md` ②) — grep 으로 17줄 그대로 확인 |
+| ③ 이름에 `{변수}` 든 참조 | 22 | `grep -o '"요소": "\(MP\|MT\):[^"]*"' 로직_*.json` — 오늘 다시 세도 22(파형강관 규격 `"{관경}"` 줄은 이 22 에 안 든 별개 사례) |
+
+## 갈래별 — 지우려면 무엇이 있어야 하나
+
+- **① 139줄** — `ref/_없는_재료.md`(111) · `ref/_관리자값_미확보.md`(45, 겹침 있음) 의 재료를 자재품목에 채워야(구분·상세구분 확보) `build_품셈재료_고르기.py` → `build_로직_재료_고르기.py` 를 다시 돌리면 자동으로 줄어듦 — 사람이 로직을 직접 고치는 갈래 아님.
+- **② 17줄** — 모래·자갈은 원문 단위(㎥↔㎏) 환산 계수를 사용자가 확정해야(산림 12장 방식을 건설품셈에 그대로 옮기는 안, `ref/_남은_옛재료줄.md` ② 에 이미 적음) · 전력은 계약종별 입력을 고르기 조건으로 옮길지부터 확정해야 — 둘 다 확정 뒤에 로직 17줄을 고르기 조건으로 바꾸는 작업이 남음.
+- **③ 22줄** — 아래 절.
+
+세 갈래가 다 0 이 된 뒤에도 품셈재료 테이블 자체를 지우려면, 그 테이블이 쥔 「원문 이름 ↔ 자재품목 묶음」 대응표를 다른 자리로 옮겨야 함 — 맨 아래 절.
+
+## ③ `{변수}` 22줄 — 왜 못 바꾸나(셋) · 제안(구현 안 함)
+
+**못 바꾸는 까닭 셋**
+
+1. 두 꼴이 섞여 있음 — `MT:{철선}` 류(19줄, 로직 입력값으로 구분·상세구분 자체를 고르는 꼴)와 `MP:VR관 ∅{관경}㎜` 류(3줄, 이름 전체에 `{관경}` 이 박힌 꼴)가 다른 문제라 하나의 규칙으로 못 묶음.
+2. `MT:{철선}` 류는 품목 7가지(철선·결속선·각재·못·합판·박리제·용접봉)마다 어느 구분·상세구분으로 좁힐지가 다 다름(예: GF000173 은 「합판」 입력에 `고르기: ["MT000018"]` 처럼 이미 자재품목 키 후보를 입력 칸에 박아 둠 — 고르기 조건 객체가 아니라 입력 목록으로 푼 자리도 섞여 있어, 표본 확인 없이 한 번에 바꾸면 틀린 후보가 걸릴 수 있음.
+3. `MP:이름 ∅{관경}㎜` 류는 `build_로직_재료_고르기.py` 의 매치 조건(`"(MP|MT)\d{6}"` 6자리 키 형식)에 아예 안 걸림 — 지금 스크립트가 이 패턴을 못 읽어 자동 변환 대상 밖.
+
+**제안(설계만 · 구현 안 함)**
+
+- 고르기 조건 객체의 `규격` 칸에 `{관경}` 같은 원문 변수 표기를 그대로 두고, 로직 실행(`master_formula.run`) 때 그 안의 `{이름}` 을 그 줄의 입력값으로 치환한 뒤 자재품목 매칭에 쓰는 안 — 같은 파일(`로직_산림품셈_12장_철근콘크리트.json`) 의 파형강관 줄(GF000176)이 `"규격": "{관경}"` 을 이미 쓰고 있어(이번 22줄과는 별개 사례) 엔진이 `{…}` 를 검사에서 빼고 치환한다면 전례가 있는 셈 — 엔진이 실제로 그렇게 도는지는 표본 하나로 시험해야 확인됨(이번엔 확인 안 함).
+- `MT:{철선}` 류는 규격이 아니라 「구분」 자체를 로직 입력이 고르는 꼴이라, 고르기 조건 스키마에 `"구분": "{입력이름}"` 처럼 입력값을 그대로 넣는 자리를 허용하는 확장이 있어야 함 — 지금 스키마엔 없음(제안만).
+
+## 삭제 뒤에도 남아야 할 정보 — 어디에 둘지 제안(구현 안 함)
+
+품셈재료가 지금 쥔 것 = 「원문이 부르는 이름」 ↔ 「자재품목 구분·상세구분 묶음」 대응 · 원문이 적힌 요구절 목록.
+
+- **안 A** — `재료_자재품목.json` 에 「품셈이름」(별칭) 칸을 더해 원문 이름을 구분·상세구분 줄에 직접 적어 둠. 자재품목이 조달청·물가지 원자료 성격이라, 파생 정보(원문 이름표)를 섞으면 원자료 갱신(가격 새로 받기)때 같이 흔들릴 위험.
+- **안 B(권함)** — 별도 작은 매핑 파일(`재료_이름표.json` 류)을 새로 둠 — 키 = 원문이 부르는 이름, 값 = `{구분, 상세구분, 요구절}`. 자재품목 원자료는 안 건드리고, 품셈재료가 하던 「이름 대응」 역할만 옮김 — 품셈재료보다 훨씬 얇은 표(대응 정보만, 연결·고르기·비고 등 지금 품셈재료가 쥔 중간 작업용 칸은 삭제 시점엔 다 필요 없음).
+
+값·데이터는 이번에 고치지 않음 — 세 갈래 모두 0 이 되기 전엔 품셈재료 테이블은 아직 못 지움(지금도 178줄이 씀).