2026-08-19(수) 세션 — 4단계 ①CP 마스터 오버레이 · 부재목록 편집 · imos 기준선 갱신

지시 = design-imos-article-full-copy.md 4단계. 착수 전 그릴링 필수 항목이라 그릴링 4배치·결정 12건 후 착수. 페페 결정으로 CP 테이블화를 먼저, 보링 엔진은 다음(방식은 실측 역공학으로 확정). 커밋 = pncad b8b1c74·3fc9089 · pfs master 1b6c9af → deploy-live 59a0228. 운영배포 완료(페페 채팅 지시).

그릴링 결정 12건

순서 = CP 테이블화 먼저, 보링 엔진 나중 2. 보링 방식 = 실측 역공학 우선(imos 9단 체인은 설명·검증용)
CP 정본 = 오버레이(파일=imos, DB=사람) 4. 아티클 재시딩도 같은 오버레이로 같이
CP 오버레이 = 필드 단위 6. 편집 판정 = 시딩 백업판 대조 7. 재시딩 = 수동 버튼 + 미리보기
CP 전 필드 편집 허용 + 안전장치 4종 9. node 연동 = pull 스크립트 10. 신규 CP 생성 금지(수정만)
배리어블도 같은 규칙에 태운다 12. 완료 경계 = 운영까지

핵심 설계 — 「imos 생성물 + 사람 오버레이」로 3종 통일

cp.json (mkcp2 생성물) ─┐
                        ├─▶ applyCpOverride() ─▶ 화면 · node 대조기 (같은 함수·같은 값)
pncad_cp_override (DB)  ─┘

대상	imos 쪽	사람 쪽	갱신 규칙
CP	`data/cp.json`	`pncad_cp_override`(신설, 필드 단위)	mkcp2 재실행해도 오버레이는 별도라 안 날아감
아티클	`data/catalog.json`	`pncad_article`(기존)	기준선 백업판과 같으면 손 안 댐 → 갱신, 다르면 보존
배리어블	`data/vars.json`	`pncad_var`(기존)	위와 동일

고친 문제 2개 (둘 다 근본원인)

_seed_if_empty() 가 빈 테이블에서만 돈다 → convert.mjs 를 아무리 고쳐도 PFS 화면은 최초 시딩판. 단독 8799 는 파일을 읽어 새 값이 나오는데 PFS 만 옛 값이라 지난 세션 트림코드 성과가 화면에 없었다.
CP 정본이 생성물이라 화면에서 못 고친다. DB 로 통째 옮기면 mkcp2 재실행마다 같은 충돌이 재발.

만든 것

pfs — pncad_cp_override 테이블(복합 PK cp_name+field, utf8mb4_bin) · GET/POST /api/pncad/cp/override · POST /cp/override/reset · GET /api/pncad/reseed(미리보기) · POST(실행). 🔴 재시딩에 지우는 동작이 없다 — 손 안 댄 행만 UPDATE, 없던 것만 INSERT, imos 에서 사라진 아티클도 보고만. 실행 직전 자동 백업 1판 + 끝나면 새 기준선 판. 통짜 DELETE 하는 replace_all() 은 백업 복원 전용으로 남겼다.

pncad — schema.applyCpOverride(cpm, over, base)(화면·node 공용) · tools/pull_overrides.py(sync 의 역방향) · convert/verify/verify2 가 data/cp-override.json 을 같이 덮는다 · 부재목록 17필드 편집 + 안전장치 4종 (imos 원값 병기 · 「수정됨」 배지 · 「변경분」 탭 · 필드별 되돌리기) · 「↻ imos 기준선 갱신」 버튼.

구현 중 잡은 함정 3개

🔴 applyCpOverride 의 타입 기준은 imos 원값(base)이라야 한다. 덮인 값을 기준 삼으면 한 번 문자열이 된 숫자칸이 영영 문자열로 굳어 계산이 조용히 틀어진다(자체검사에 「두 번 덮어도 숫자」 케이스로 박아 뒀다).
🔴 화면의 「imos 원값」이 병합본을 가리키던 버그 — cp.json 을 그 자리에서 덮으면 원값이 사라진다. app.html 이 CPBASE = structuredClone(CPM) 로 사본을 먼저 뜬다.
⚠ thk 오버레이는 verify2 를 안 움직인다 — 오더변수 바디자재_*(ctx.bodyThk)가 더 우선한다. 오버레이 실효 확인은 밴드 fixW 60→80 으로 했다(58.3%→58.0%, 대조기가 오버레이를 본다는 증거).

검증

verify2 58.3% 유지 · node schema.js PASS(오버레이 3건 신규) · 로컬 E2E 49/49 · 테스트 129/129(editor2 20 · editor3 15 · cp 17 · pncad 27 · catalog 40 · vars 10) · 운영 128/128(catalog 은 운영에서 복원 검사 1건 미실행이 정상) · 배포 파일 10개 본문 일치(테스트 30초 · 운영 31초) · 사이트맵 그룹8·페이지54·미반영0.

기준선 갱신 실행 결과 = 테스트·운영 양쪽 「아티클 165 갱신 / 보존 0 / 신규 0 / 사라짐 0」 → 사람이 손댄 아티클이 하나도 없었고, 지난 세션 트림코드 성과가 이제 운영 화면에 실제로 뜬다. (재시딩 전 _e2e_editor3 가 「카탈로그에 트림코드 있음 FAIL」로 그 상태를 정확히 잡아냈다.)

보링(가공) 생성 엔진 — 실측 역공학. 2026 가공 123,175행 / 워크그룹 27종 / 조합 57개뿐이고 IDBWG 가 (ORDERID, ID) 로 IDBGPL 과 부재 단위로 맞물려 IP_X/IP_Y/IP_Z·OR_*·DIA·DE·CNT 를 준다 → verify2 와 같은 방식의 좌표 대조기(verify3)를 만들 수 있다. 상위 3종이 77%.
서랍(약 2,700매) — drawer_full.json 이 재료.
힌지 = CP 이름 파싱으로 재설계 · SIZREF 슬롯 방향은 imos 화면 캡처 후.