📦 인수인계서 — 다음 대화방용

새 방은 이 페이지 먼저 읽고 복원. 견적 스키마=schema-estimate.md, 함정=traps.md, 완료 상세=archive.md, 세션=sessions.md(개별 session-*.md 인덱스), 인프라/규약 레퍼런스=memory.md, 설계=design.md.

🆕 NOW (2026-08-26) — 한샘 전용 견적 모듈 신설 ✅운영배포 완료

[페페] 「pfs에 견적서 목록(한샘)을 생성해줘. 견적 양식 및 단가표 데이터 db추가해서 작성할수 있게. 엑셀파일도 올려서 엑셀파일에 넣는 형식으로. 기존 견적서 양식으로 한샘분 제작은 그대로 유지, 별도로 새 양식과 단가표 관리해서 운영. 운영배포.」 → 그릴링 5차(결정 12건) 후 착수.

• 왜 별도 계통인가 = 계산체계가 다르다. 포인 자당(300mm)×부위비율×마진 vs 한샘 폭/10×단가×유형배수×적용률. 기존 estimate 계통은 코드 변경 0.
• 🔑금액을 PFS 가 엑셀에 쓰지 않는다 — 치수·마감·등급·적용률과 단가표만 양식 사본에 주입하고, 금액은 파일 안 LOOKUP 체인(단가기준→백데이터→내역서 6탭→갑지)이 계산한다. 한샘이 열어 검산할 때 수식이 보인다. 목록 총액만 hansem_calc 가 같은 식으로 따로 낸다(참고값).
• 신설 = 테이블 8(hansem_price_book/price/finish/furn_type/form/estimate/estimate_type/estimate_detail) · 화면 3(/estimate/hansem/list|regist|price) · API 10(/api/hansem/*) · 메뉴 3(display_order 140~142). 마이그레이션 migrations/patch47_hansem_estimate.sql(멱등, 시드 = 마감 12 · 유형 14 · 2019 판 단가 192칸[값 156]).
• 엔진 api/pfs/hansem/hansem_excel.py — openpyxl 로 load→save 하면 이미지 10·도형 9·메모·x14 데이터유효성이 사라져서 zip XML 외과수술로 간다. 값 셀만 쓰고 수식 셀은 안 건드리며, 낡은 캐시 <v> 를 지우고 fullCalcOnLoad 로 재계산시킨다. 평형명은 A4 한 칸만 쓰면 E2·A54·갑지 A19~A21 이 따라온다. 지원 평형 수 = 양식이 가진 내역서 쌍 수(초과하면 막는다 — 런타임 탭 복제 안 함).
• 검증 = ①서버계산 vs 엑셀 캐시값 48/48 원 단위 ②왕복 동일성 582/582 ③구조 보존(이미지10·도형9·파트82) ④E2E(양식 업로드→아산 실데이터 견적→엑셀 수신) 총액 20,818,331 일치 · 입력셀 291/291 — 테스트·운영 양쪽 ⑤사이트 점검 화면3+API5 테스트·운영 8/8 ALL PASS.
• 배포 = master 2d16739+8c5ac83+dcd61c8 → 운영 b3fbba9(파일 19개 선별 포워드). merge 안 쓴 이유 = deploy-live 미반영 커밋이 138건이라 통째로 끌려온다. 진입점 2파일 (api/config.py·web/__init__.py)은 deploy-live↔master 차이가 한샘 등록 4줄뿐임을 확인하고 넘겼다. 운영 RDS patch47 적용 완료 · E2E 흔적 hard delete(견적 0 · 양식 1 활성 · 단가 192칸). 사이트맵 재빌드 = 그룹 8 · 페이지 54→57 · 미반영 0. devplan hansem-estimate.html + 허브 카드 등록.
• ⚠배포 중 걸린 사고 2건 = ①MySQLUtil.execute 가 빈 파라미터에도 포맷을 돌려 SQL 리터럴 % 에서 워커 사망 ②pymysql DECIMAL → jsonify 500. 둘 다 rules.md 🆕 등재.
• ℹ양식 자체 결함 발견(안 고침) = 수납 내역서의 파우더장·픽스도아는 단가행 라벨이 「단가 (50%)」인데 수식엔 배수 없음(×1), 공틀도어는 라벨 없이 ×0.7. 주방은 전부 일치. 수식을 정본으로 시드했고 유형 마스터에서 고칠 수 있게 뒀다.
• ⏳페페 = ①운영 육안 1회(/estimate/hansem/price 단가표·양식 → /estimate/hansem/regist 실견적 1건 → 엑셀) ②옵션 7,148,000 배분 규칙 결정(2차 착수 전제 — 자재비 실비/적용률 상향/등급 상향 중).
• 2차(미착수) = 자재비·운반비·추가분견적 탭 · 기존 견적 전환 도구 · 평형 4개 이상 확장 양식 · 월마감 편입 여부.

🆕 실견적 3건 등록 (2026-08-26 후속) ✅

페페 「2개 견적서 한샘 양식으로 작성했어? 목록에 안보인다」 → 그때는 그릇만 있었다(0건). 지금 운영 3건.

• 페페 결정(26.8.26) = 「GS원주는 견적목록 V1·V2 2가지로 생산한다. V1은 추천(3분류)대로, V2는 금액차 상관없이 치수 기준으로만」.
• 3분류 배분(V1) = ①유리류 2,325,000(유리도어 1,520,000·유리선반 605,000·유리 200,000) → 자재비 탭 실비 별도(생산비 미포함) ②판넬류 3,168,000(EP 6종 1,805,000·픽스판넬 360,000·후면장 373,000·후면픽스 60,000·메지판 90,000·12T휠라 300,000·9T쫄대 180,000) ③하드웨어·식세기도어 1,655,000(HK-TOP 800,000·플랩암 450,000·언더레일 150,000·밥통장레일 75,000·식세기도어 180,000) → ②③ 4,823,000 은 행별 적용률 상향으로 생산비 흡수. 생산비 22,193,970 + 유리 자재비 2,325,000 = 24,518,970 (포인 763 행총액 24,327,000 대비 +191,970). ⚠등급은 D가 상한이라 「등급 상향」은 물리적으로 불가 — 전부 적용률 레버로만 흡수했다.
• 763 → 한샘 매핑(스크립트 scripts/_hansem_from_est.py, 763 21행 전부 주방·수납 0행): 상부장·장식장 상부장·후면 유리하부장 → b4 / 하부장·장식장 하부장 → b11 / 아일랜드 하부장 → b25 오픈장 (양식 원본 세트라벨이 C(아일랜드) 라 근거 있음. b11 과 단가군·배수 동일이라 금액 무관) / 장식장 키큰장·냉장고장·가전소물장 → b32 / 팬트리도어 → b46 공틀도어(KIT_TALL×0.7). 평형 슬롯 3개 = 84A / 84C / 84C(F) (763 의 type_name + field_type. K=주방·F=일반). 🔑치수분이 이전 보고(16,648,450)보다 722,400 크다(17,370,850) — 팬트리도어를 상하부장×0.7 로 봤던 게 오류고, 양식 수식 정본은 키큰장×0.7 이다.
• 🔴엑셀 산출물엔 아직 양식(아산) 잔존값이 섞인다 — 자재비 5,654,155 · 운반비 1,060,000 · 추가분 1,010,000 · 시공비 리터럴 12,930,000 · 절사 5칸이 갑지에 그대로 뜬다. 1차 범위가 「본오더 내역서」뿐이라 그렇다. 아산(견적1)은 원본 재현이라 오히려 맞고, GS(견적2·3)만 틀리다. → 2차 과제(자재비·운반비·추가분 탭) 또는 빌드 시 0 처리. ⏳페페 결정.
• ⏳운영배포 대기 = master dd677a7(탭 rename 교차 버그 수정). 배포 전까지 운영에서 GS 엑셀을 받으면 탭이 교차된 파일이 나온다. 로컬 검증은 끝(scripts/_hansem_local_build.py).
• 검증 도구 신설 = scripts/_hansem_from_est.py(763→한샘 등록) · _hansem_local_build.py(운영배포 전 로컬 산출·구조 점검) · _hansem_state.py(현황) · _hansem_field_find.py · _est763_table.py.

(이전) 2026-08-26 — 한샘 단가표 전환 현황파악(보고만) + 한샘 양식 xlsx 외부링크 정리 ✅

[페페] ①「기존 견적(GS 원주 763)을 한샘 신규 양식에 맞춰야 한다. 한샘 단가표가 기존보다 금액이 적다. 추가금액·옵션금액 규칙을 확인해 손실 최소로 옮길 방법을 찾아야 한다. 우선 치수만 반영해 금액차를 본다 — 이번엔 실제 작업 없이 현황 보고만」 ②「양식 파일 수식이 외부 디스크 경로를 참조한다 → 파일 내 단가기준 탭 참조로 고쳐라. 동일폴더에 새폴더 만들어 원본 백업」 ③당장 안 봐도 되는 탭 = 추가분견적·자재비·운반비·가격적용분.

① 현황 (보고만 · 코드/DB 변경 0)

• 한샘 계산식 = 폭(mm)/10 × 단가(원/10mm) × 적용률. 단가는 가구유형 × 마감 12종 × 등급 A~D 매트릭스 (단가기준 탭). 주방 벽장·밑장 2500~3900 · 키큰장 5300~8400 · 수납 일반장 6100~9000 · 낮은장 4000~5900. 등급 = 도어사양(A평판 / B투톤·매입손잡이·메지홈 / C자체손잡이·AL1면·휘모·후레임 / D AL4면엣지바·AL후레임·슬라이딩). 단가 배수 = FIX PANEL 50% · 공틀도어 70%. 적용률 = 도어만 30% / 바디일부 50% / 도어+바디 70% / 전체 100%(수기).
• 포인 계산식(pfs) = (Σ치수−Σ코너)/300 × 자당단가 × 부위비율 × (1+마진) 천원 올림 + Σ추가금액. → rules.md 💰항목.
• 763 실측 = 21행 · 유효폭 37,755mm(125.8자) · 행총액 24,327,000(= 자당몫 17,179,000 + 추가금액 7,148,000)
• 시공비 6,500,000 + 운반비 400,000 = 31,227,000. 자당단가 원/10mm 환산 = 상부 3,583 · 하부 4,163 · 냉장고장 4,583 · 팬트리도어 4,600 · 키큰장/가전소물장 8,337.
• 치수만 반영한 금액차(PUR계열, 적용률 100%·공틀도어 70%): A 11,684,100 / B 13,000,650 / C 13,878,350 / D 16,648,450. 🔑D등급이면 포인 자당몫(17,179,000)과 −530,550(−3.1%) 밖에 차이가 없다 — 단가표 자체는 거의 같다. 행총액 대비 −7,678,550(−31.6%) 인 것은 전부 추가금액 7,148,000 이 한샘 생산비 단가표에 자리가 없어서다.
• 손실의 실체 = 옵션(추가금액) 7,148,000(행총액의 29.4%) — 유리도어 1,520,000 · EP 810,000 · HK-TOP 800,000 · 유리선반 605,000 · 플랩암 450,000 · 아일랜드EP 420,000 · 후면장 373,000 · 픽스판넬 360,000 …
• 한샘 양식의 청구 경로 3개 = 생산비(단가표) · 자재비 탭(보드·엣지·유리·거울·AL엣지바/손잡이바/후레임도어 실비, 단가표 비고 「수입경면·무늬목·허니컴 = A단가 평균×50% 자재비 별도」가 근거) · 추가분견적 탭(본오더 이후 설계변경·재생산·샘플 등 사후 발생분, 옵션 정가표 아님). ⚠자재비 탭에 하드웨어(블럼 플랩암·HK-TOP·레일)는 없다 → 유리·AL 은 자재비로 넘길 여지가 있으나 하드웨어·EP·픽스판넬은 아직 갈 곳이 없다(다음 결정 사항).
• ⏳다음(설계 판단 필요) = ⓐ GS 원주 도어사양 → 한샘 등급 확정(D 가정 시 −3%) ⓑ 옵션 7.1M 배분 규칙 (자재비 실비 / 적용률 상향 / 등급 상향 중 택) ⓒ 그 뒤에 치수 자동전개. 착수 시 그릴링 + 계획 3단계 대상.

② 양식 xlsx 외부링크 정리 (실작업)

• 대상 = NAS 2026현장\견적\넥서스\한샘 견적 양식(가구,시공)\1.생산비 거래명세서_라인건설 아산테크노밸리_26년 06월.xlsx
• 외부링크 정의 13개 중 실제 수식이 쓰던 건 2개뿐([11]=…\한샘\2019년\8월\…\롯데광명철산 생산비.xlsx, [13]=…라인 아산테크노밸리 MH 수납 거래명세표 260604.xlsx). 나머지 11개는 유령(A:\·\김석곤부장\… 등).
• 고친 것 = ①내역서 6탭(77/84A/84B × 주·수)의 LOOKUP 276곳에서 [11] 접두 제거 → 같은 파일의 백데이터(건들지마세요!!) 탭 참조 ②그 백데이터 C열 156셀을 =단가기준!D7 식으로 바꿔 단가기준 탭이 단일 출처가 되게 함(값 변경 0 — 156셀 전수 대조 일치, 빈칸 36은 원래 빈 수입경면 B~D) ③fullCalcOnLoad + calcChain 폐기.
• 🔑openpyxl 로 다시 쓰지 않았다 — 이 파일엔 이미지 10·도형 9·메모·데이터유효성 확장이 있어 재저장하면 깨진다. zip 안 XML 만 외과수술(fix_links.py). 파트 109→108(calcChain 만 빠짐), 바뀐 파트 10개.
• 검증 = LOOKUP 17셀을 로컬 백데이터로 재현 → 전부 일치 · 캐시 총액 유지(주방 17,479,999.5 / 수납 11,050,000.2) · 워크시트에 남은 외부참조 1건 · NAS 파일 md5 = 로컬 산출물과 동일.
• ✅2차(같은 날, 페페 「파일 닫았어. 재검토 + 두 탭 단가 일치 확인」) — 전수 대조 + 외부링크 완전 제거
• 백데이터 ↔ 단가기준 전수 대조 = 일치 156 · 빈칸 36 · 불일치 0. 라벨(마감 12종 × 등급 A~D)·수식 대상셀· 캐시값 3중 대조. 역방향도 확인 — 단가기준 단가영역 값셀 68개 전부 백데이터가 참조, 빈칸 12개(수입경면·무늬목· 허니컴의 B~D)도 서로 일치. 내역서 6탭 LOOKUP 92셀 로컬 재현 전부 일치.
• 수납!O34 정체 판명 = 자재비·운반비 탭은 현장 전체 합계(자재비 5,654,155 / 운반비 1,060,000)이고 주방 시트가 그 전액을 이미 가져간다(주방!O32=자재비!H124, O33=운반비!I18). 즉 수납 칸에 연결하면 이중 계상이다 → 바로 위 수납!O33(자재비) 처럼 빈칸이 맞다. 값이 이미 0 이라 금액 영향 0.
• → 죽은 수식 제거 후 외부링크 잔재 전부 삭제 : externalLink 파트 13개(+rels 13) · externalReferences 블록 · Content_Types Override 13 · 외부파일을 가리키는 definedName 26개(전부 미사용, 대부분 이미 #REF! — 워크시트 수식·데이터유효성에서 쓰이는 것 0건 확인 후 삭제). 이제 엑셀이 「링크 업데이트」를 안 묻는다.
• 파트 108→82 · 바뀐 파트 4개 · 탭 15개 유지 · 총액 불변(주방 17,479,999.5 / 수납 11,050,000.2 / 생산비총 28,529,999.7 / 생산비+시공비 41,459,999.7) · 남은 외부참조 0건 · NAS md5 대조 일치.
• ✅3차(같은 날, 페페 「외부 데이터 연결 메시지 아직도 뜬다」) — 진범 = x14 확장 데이터유효성 링크 정의를 다 지웠는데도 경고가 남은 이유 = <extLst> 안 <x14:dataValidation> 4건이 드롭다운 목록을 절대경로 다른 통합문서로 잡고 있었다 — 주방(H34:K34 D32:G34)·수납(H35:K35 D33:G35)은 D:\0.박진수-pc\…\[201804 롯데 청량리_생산비(나움).xlsx]Sheet3'!#REF!, 추가분견적 주방(K3 F22:G22 G8)· 일반(K3)은 G:\영업\…\[라인 광주일곡 MH 거래명세표 .xlsx]Sheet3'!#REF!. 전부 이미 #REF! = 죽은 목록. 🔑openpyxl 은 이걸 못 본다(로드 시 경고만 찍고 버린다) → zip XML 직접 grep 으로 찾았다. → rules.md 🔴.
• 각 시트의 <extLst> 는 이 항목 하나만 담고 있어 블록째 제거(4파트만 변경, 파트 수 82 유지).
• 남는 일반 데이터유효성은 그대로 — 내역서 6탭의 마감 12종 목록·"A,B,C,D" 등급 목록 살아 있다.
• 사라지는 것 = 위 4곳의 드롭다운(원래 #REF! 라 아무것도 안 뜨던 것). 셀 값·서식은 그대로.
• 재검증 = 백데이터↔단가기준 156/0 · LOOKUP 92셀 일치 · 총액 불변 · 외부 흔적 0건 ([n] · [파일.xlsx] · TargetMode="External" 전 파트 스캔). NAS md5 3920c11d… 대조 일치.
• 유일하게 남은 경로 문자열 = workbook.xml 의 x15ac:absPath(마지막 저장 위치 힌트) — 링크 아님, 경고와 무관.
• 백업 = 같은 폴더 _원본백업_2026-08-26\(md5 원본과 동일). ⚠파일에 ~$… 잠금(소유자 poinpc)이 있어 첫 덮어쓰기가 Device or resource busy 로 막혔다 — 임시명 write + rename 으로 넣었다(원자적 교체).

(이전) 2026-08-26 — 에넥스 금호 구미 견적 3차수 작성 + 엑셀 3종 NAS 저장 ✅운영 완료 (코드변경 0)

[페페] estimate/modify-v2/764 본건 작성 후 = 「총 3개 견적서 엑셀 파일 작성. 1차=현재건 24,058,000원 / 2차=전체 마진율 20% 각 항목 조금씩 조정해 1900만원 약간 초과(목표 1900만) / 3차=2차 기준 5% 인상. pfs 에도 차수별로 저장하고 비고에 수정내용 저장. 엑셀은 NAS 2026현장\견적\09월\에넥스\금호 구미 견적 에. 운영배포 작업건이다」 + 추가 2건 = 「3차는 퍼센트 조금 더 올려 2000만원을 조금 넘게, 파일명 퍼센트는 소수점 없이 정수로」 · 「전체 파일 모두 운임은 건드리지 않는다」.

• 해석 결정(페페 확인받음) = 「전체 마진율 20%」 = 할인 20% = margin_percent -20. 근거 = 이 견적의 추가금액이 이미 −20% 를 할인으로 쓰고 있었고, 플랫 −20% 를 걸면 총액이 19,009,000 원 = 「1900만원 약간 초과」에 원 단위로 떨어진다(단가·추가금액·운반비 손 안 대고). 3차는 페페 지시로 마진율 −14% 계산식 + 파일명은 (5) 표기(규칙 외 명명) 로 확정.
• 차수(운영 DB) — 앱의 재작성 API(POST /api/estimate/<no>/rewrite {copy_items:'1'})로 만들었다. | 차수 | 견적번호 | 이름 | 마진율 | 항목합계 | 운반비 | 총액 | 상태 | |---|---|---|---|---|---|---|---| | 1차 | 764 | 금호 구미 MH 견적서 | 자동 10 | 23,608,000 | 450,000 | 24,058,000 | 보관 | | 2차 | 765 | 〃 (2차) | −20 | 18,559,000 | 450,000 | 19,009,000 | 보관 | | 3차 | 766 | 〃 (3차) | −14 | 19,570,000 | 450,000 | 20,020,000 | 보관 | | 4차 | 767 | 〃 (4차) | +24 | 25,962,000 | 450,000 | 26,412,000 | 사용 중 | 비고(estimate.comment)에 차수별 수정내용 저장 — 마스터 비고는 엑셀에 안 나간다(엑셀 비고 3줄은 고정문구)라 내부 메모로 안전하다. 운반비 450,000 은 3차수 전부 동일(지시대로 미변경).
• 4차 추가 지시(같은 날) = 「1차 금액 기준 10% 인상, 파일이름에도 동일하게 (10)」. 정수 마진율 중 +24% 가 1차 항목합계 대비 +9.97%(목표 25,968,800 대비 −6,800원)로 가장 근접 → 파일명 (10) 과 정합. (24.1% 면 +10.05% 지만 소수 마진율이라 채택 안 함.)
• 엑셀 4종 = NAS \\192.168.0.101\공유폴더\2026현장\견적\09월\에넥스\금호 구미 견적 (md5 대조 일치) …견적서(원본단가).xlsx(1차) · …견적서.xlsx(2차) · …견적서(5).xlsx(3차) · …견적서(10).xlsx(4차) ℹ️2026-08-26 4차 저장 시점에 2차 파일이 …견적서(최종).xlsx 로 이름이 바뀌어 있었다(페페가 손댄 것으로 보임, 그대로 둠).
• 검증 = ①계산식 재현으로 1차 20행·총액이 원 단위 일치 ②복사본을 원본과 전 컬럼·전 sub 대조(PASS) ③엑셀 실파일에서 상세블록 수량×단가 합 + 물류비 = 총액 3파일 ALL PASS.
• 🔑새 규칙 3건(계산식 단일출처 · estimate_detail 컬럼/FLOAT 함정 · 엑셀 단가=SET단가·파일명 quirk) = rules.md 🆕.
• 코드 변경 0 · DDL 0 → 배포·사이트맵 재빌드 대상 아님.

(이전) 2026-08-26 — 견적 v2 행 UI 3건 (치수 블록선택 · 폴딩 아이콘 · 분류 드롭다운) ✅운영배포 완료

[페페] qa_helper(/estimate/modify-v2/764) 3건 = ①「치수칸, 코너칸 클릭시 데이터가 있는 경우 블록으로 잡히게 해줘. 수정시 바로 숫자입력으로 덮어쓸수 있게」 ②「폴딩 아이콘을 전체 1개의 아이콘으로 변경해줘. 현재 아이콘 세모 모양이 정중앙이 아니다. 세모모양과 프레임조합으로 보인다. 디자인적으로 별로임. 허용된 범위안에서 크기를 최대한 키워줘. 클릭하기 편하게. 추가금액 항목이 있는 경우 버튼의 컬럼 배경을 사이안계열로 변경해줘」 ③「글씨 크기 1포인트 키워주고 색상 좀 더 진하게. 드롭리스트 글씨 가로 안잘리게 리스트 프레임 확장. 리스트 스크롤 없이 전체 목록 보이게」 + 「전체 작업내용 모두 운영배포 진행」

• 고친 것 = 2파일 +39 −12줄(web/static/css/estimate_regist_v2.css · web/static/js/estimate_regist_v2.js). 서버코드 0 · DDL 0 · DB 변경 0.
• ①클릭 즉시 블록선택 = 위임 한 줄 $(document).on('focus click', '.dim-cell, .corner-cell', …) 에서 값이 있으면 select(). 🔑focus 만 걸면 안 된다 — 마우스 클릭은 focus 뒤에 mouseup 이 따라와 선택을 캐럿으로 풀어버린다. click 은 mouseup 다음이라 최종 승자다(탭·방향키 이동은 focus 가 담당). 🔑type=number 는 selectionStart 를 못 읽지만(Chrome 이 null) select() 자체는 동작한다 — 실측으로 확인하고 갔다. 본문·모달(#itemModal)·계산기(#calcFrame) 가 같은 클래스라 한 줄이 전부 덮는다.
• ②폴딩 아이콘 = ▶ 글리프 + 1px 테두리 상자 조합을 버리고 border 로 그린 CSS 삼각형 ::before 하나로. inset:0 + margin:auto 라 기하학적 정중앙(실측 좌우 8=8 · 상하 6=6) — 글리프 메트릭 치우침이 애초에 없다. 크기는 18 → 26px: 🔑칸 폭 30px 은 columnSettings(사용자별 DB 저장)라 건드리면 기존 사용자에게 안 먹는다 → td 패딩을 9/8 → 4/2 로 줄여 같은 폭 안에서 버튼을 키웠다. 펼침 표시는 종전 그대로 90도 회전(색만 --primary).
• ②추가금액 사이안 = cellForCol('twirl') 이 subs.length > 0 이면 td 에 has-sub → 배경 #cdf0f7. sub 추가/삭제가 renderDetailTable() 을 부르므로 접힌 상태에서도 자동 동기된다(별도 배선 0).
• ③분류 칸 = input 12 → 13px, 색은 td 상속 --ink-2 → --ink(굵기는 안 건드렸다 — 페페 UI 규칙 = 강조는 색으로만). 드롭다운은 right:0 을 빼고 width:max-content + min-width:100%(칸 폭 48px 에 묶여 항목명이 잘리던 것) + max-height:220px 제거 → 공통코드 15종이 스크롤 없이 한 번에(450px).
• 검증 = 신설 scripts/_est_qa826_ui_check.py [test|prod] [견적번호] — 테스트(707) 36/36 ALL PASS · 운영(764) 읽기전용 37/37 ALL PASS. 운영에서 추가금액 3행 사이안 rgb(205,240,247) · 없는 1행 흰색까지 같이 잡혔다. 회귀 = _dim_wheel_check(휠 가드) · _size_unit_check(치수 mm 자동부착) · _actcol_vert_check(액션열) 테스트·운영 전부 0 FAIL, 콘솔 0.
• 배포 = master abf3e36 → deploy-live b83d8c6(2파일 선별 포워드, --detach 워크트리). 포워드 전 git diff origin/deploy-live origin/master -- <2파일> 이 내 커밋 diff 와 바이트 동일함을 확인하고 넘겼다(그 파일에 걸린 미반영 커밋 11개는 전부 이미 반영돼 있었다). 사이트맵 = 그룹 8 · 페이지 54 · 미반영 0. devplan/pfs.html DONE AE 등재.
• ⚠따로 발견(내 변경 아님, 손 안 댐) = 항목표 헤더에 drag · twirl 이 영문 그대로 노출된다. labelForCol() 이 labels[key] || key 라 라벨이 빈 문자열('')이면 폴백이 키 이름을 찍는다 (drag:'', twirl:''). 지시 범위 밖이라 안 고쳤다 — 고치려면 || '' 분기 한 줄.
• ⏳페페 = 운영 육안 1회(/estimate/modify-v2/764 → 치수칸 클릭 · 폴딩 아이콘 · 분류 드롭다운).

🆕 NOW (2026-08-25 · 7차) — 견적 현장검색 모달에 상차일 미확정 노출 + 맨 위 ✅운영배포 완료

[페페] qa_helper(/estimate/regist-v2, #btnFieldSearch) 「견적용 현장 모달에서 리스트에 상차일 미확정분이 나오지 않는다. 상차일 미확정분도 나오게 하고, 순서상 리스트 상단에 배치시켜라. 운영배포」

• 🔑원인은 정렬이 아니라 WHERE 절이었다. 5차(현장목록)는 정렬만 고치면 됐지만 여기는 select_site_search 의 AND f.shipping_date >= date_from 이 NULL 을 통째로 걸러내 미확정 현장이 결과에 아예 없었다(모달 기본 = 1개월 전~무제한). 같은 함정을 이미 두 번 고쳤는데 (생산현황 리포트 SQL = 배포 X · 현장목록 검색 = 배포 Y) 견적 현장검색에 한 곳 남아 있었다.
• 고친 것 = 2파일 +12 −4줄. ①DAO 기간조건 2개를 (f.shipping_date IS NULL OR …) 로 감싸고 ②ORDER BY (f.shipping_date IS NULL) DESC 를 맨 앞에 — LIMIT 50 이라 정렬을 안 바꾸면 미확정이 꼬리에서 잘려나간다(WHERE 만 고치면 반쪽) ③프론트 siteSortCmp 는 상차일 키에서 빈 값을 정렬 방향과 무관하게 맨 위(헤더로 오름/내림 뒤집어도 상단 유지) ④fmtShipDate('') = 「미확정」 표기 — 종전엔 빈 칸이라 맨 위에 와도 뭔지 안 보인다. 서버 DDL 0 · DB 변경 0.
• 같은 API 를 쓰는 다른 화면도 함께 고쳐졌다 = AL발주서 현장명 드롭리스트(al_orderpaper.js)· 자재관리 현장목록(orderpaper_material.js). 둘 다 빈 상차일을 이미 안전하게 처리해서 회귀 0 (_al_combo_check 테스트·운영 ALL PASS 로 확인).
• 검증 = 신설 scripts/_estimate_site_tbd_check.py [test|prod] — 테스트 22/22 ALL PASS (상차일 없는 임시 현장 1건 생성 → 검색결과 최상단 확인 → 소프트삭제), 운영 읽기전용 17/17 ALL PASS (미확정 3건 = 금호 구미·GS 원주 단구·롯데 화성 향남 이 표 맨 위 3행 「미확정」, 4행째부터 20260916 내림차순, 정렬 뒤집기·초기화에도 상단 유지, 콘솔 0). 회귀 = _al_combo_check 테스트·운영 ALL PASS · _ship_tbd_check 테스트 ALL PASS.
• 배포 = master ac24be5 → deploy-live 845285e(2파일 선별 포워드, --detach 워크트리). 사이트맵 = 그룹 8 · 페이지 54 · 미반영 0. devplan/pfs.html DONE AD 등재.
• ⏳페페 = 운영 육안 1회(견적 등록 → 🔍 검색 → 맨 위 3행이 「미확정」).

🆕 NOW (2026-08-25 · 6차) — 거래처 개명: 넥서스 → 한샘 ✅운영배포 완료

[페페] 「pfs 업체명 변경을 한다. "넥서스"를 "한샘"으로 변경하고 관련 지침에서 용어 교체를 같이해서 시스템에 오류가 안생기도록 해라. db수정도 승인한다. 운영 배포」

• 그릴링 6문 페페 확정 = ①범위 = 마스터+화면 키만(과거 표시텍스트·실물참조 제외) ②발주서 동기화는 파서에서 정규화 ③표기 = 한샘 / 출력 (주)한샘 ④과거 마감표는 8월분부터만(1~7월은 당시 사명 보존) ⑤안전장치 = 롤백 스크립트 + RDS 스냅샷 ⑥지침문서는 치환 + 최초 1회 「구 넥서스」 병기.
• 🔑가르는 기준 = 「실물이 같이 바뀌었나」. 상세 규칙·목록 = rules.md 🆕 맨 위. 바꾼 것 = company.name(company_no=1 — 현장 825건·담당자 22명이 FK 로 자동 추종) · orderpaper.furniture_company · orderpaper_site_map · monthly_close.company_name(2026-08 만) · vendors.json. 안 바꾼 것 = NAS 파일명 · 카톡방명 · 녹음파일명 · 통화원문 · estimate_name · field.name · worklog.site_name · nexus_close_form.xlsx · 적용완료 마이그레이션.
• 🔑함정 1 — DB 만 고치면 되돌아간다. orderpaper_sync 가 ON DUPLICATE KEY UPDATE furniture_company=VALUES(…) 로 매 동기화마다 파일명 파싱값으로 덮고, 도어발주서는 H6 셀을 재파싱한다. NAS 파일명은 옛 사명 그대로다. → orderpaper_parse._COMPANY_ALIAS(단일 출처, door_order_parse 가 import) 에서 적재 시점 정규화. _KNOWN_COMPANIES 엔 옛 이름을 남겨 옛 파일명이 계속 파싱되게 했다. 순서 = 파서 먼저, DB 나중 — 자동동기화가 로컬 실행(30분 주기)이라 파서를 고치는 순간 발효돼 동기화를 멈출 필요가 없다.
• 🔑함정 2 — vendors.json 은 거래처에 「없는 이름만」 보충하는 폴백이다. 마스터만 바꾸면 스냅샷의 옛 이름 18행이 중복제거를 피해 AL발주서 자동완성에 유령으로 남는다 → 같이 교체.
• 코드 = master b1ef589 → deploy-live a449d3e(22파일 선별 포워드, --detach 워크트리). 전 파일 deploy-live↔master 차이가 내 변경뿐임을 파일별 diff 줄수 대조로 확인하고 넘겼다. DDL 0.
• DB(SSM scripts/_hanssem_rename_apply.py, 파일 내 상수 EXECUTE 게이트) = 운영 company 1 / orderpaper 1561 / site_map 18 / monthly_close 1(2026-08) · 테스트 1 / 1382 / 16 / 5. RDS 스냅샷 pfs-pre-hanssem-20260825(03:02Z=12:02 KST, available 확인 후 집행). 롤백 = scripts/_hanssem_rename_rollback.py(역조건 UPDATE — 변경 전 '한샘'이 4개 컬럼 전부 0건이라 행단위 백업이 필요 없다. ⚠롤백은 파서 정규화 제거가 먼저다).
• 검증 = 신설 scripts/_hanssem_rename_check.py [test|prod] — 테스트 16/16 · 운영 20/20 ALL PASS (업체필터 2종·월마감 거래처목록·운영 2026-08 마감행+시공비 컬럼·2026-07 은 「넥서스 (9)」로 보존· AL발주서 vendors 유령 0·자재관리 datalist·생산현황 색상맵·콘솔 0). 회귀 = _field_list_qa5_check 테스트·운영 ALL PASS · _monthly_close_ui_check 테스트 19/19·운영 19/19 · _ship_tbd_check 테스트 ALL PASS · _field_status_print_ivision_check ALL PASS · test_monthly_close_excel ALL PASS · test_door_order_parse 8/8 · 견적서 A6 접두 단위검사 7/7.
• 실증(가장 중요) = 파서 수정 뒤 자동동기화가 실제로 1회 돌았고(round R1787627337 ≈ 12:09 KST, prod, 50파일 1861항목) 그 직후 운영 /api/orderpaper/all-items 업체별 집계 = 한샘 1276 / 넥서스 0. NAS 파일명이 아직 옛 사명인데도 되돌림이 없다는 게 확인됐다.
• ⚠선반영 발견(내 변경과 무관) = _mc_aug_row_ui_check.py 가 운영 2 FAIL — 추가금액·합계 기대값이 2026-08-24 「월마감 금액 = 견적 실시간 재계산」 배포 이전의 굳은 값이었다(추가 6,295,000/합계 28,975,000). 견적 실측(735 total 20,370,000·시공 8,000,000 / 753 total 10,467,000·시공 2,310,000)과 화면이 정확히 일치 → 고정숫자를 항등식 대조로 교체(8/24 에 _monthly_close_ui_check 에 한 것과 같은 교정). 재실행 10/10 PASS.
• 사이트맵 = 그룹 8 · 페이지 54 · 미반영 0. devplan/pfs.html DONE AC 등재.
• ⏳페페 = 운영 육안 1회(현장목록/견적목록 업체 필터 「한샘」 · 견적서 출력 A6 「(주)한샘」).

🆕 NOW (2026-08-25 · 5차) — 현장목록 상차일 미확정을 맨 위로 ✅운영배포 완료

[페페] 「pfs 현장 목록에서 상차일 미확정분이 리스트에서 안 보인다. 정렬순서 규칙때문인데, 미확정분을 목록 상단으로 기본 배정해줘. 운영 배포」

• 🔑원인 = 3차에서 상태 그룹 정렬을 롤백하며 정렬이 「상차일 내림차순 한 줄」로 돌아갔는데, 내림차순에서 빈 값(미확정)은 맨 뒤다. 운영 129행이면 7페이지째로 밀려 사실상 안 보였다. 2차 정렬은 미확정을 0번 그룹으로 맨 위에 뒀었는데, 롤백이 그 효과까지 같이 걷어간 것이다.
• 고친 것 = field_list.html 한 파일(+13 −3줄). fieldListOrder(a, b) 부활 — 다만 이번엔 상태를 안 본다: 미확정 여부 먼저(미확정이 앞) → 상차일 내림차순 → 미확정끼리는 field_no 내림차순. 「진행현장」 토글의 오름차순 분기는 빈 값이 원래 맨 앞이라 안 건드렸다. 서버코드 0 · DDL 0 · DB 변경 0.
• 3차에서 뺀 「대기중/진행중/완료」 상태 그룹 정렬은 여전히 없다(검사로 고정) — 상태는 표 위 탭으로 고른다.
• 검증 = _field_list_qa5_check.py 갱신(단조 비교를 order_ok() 판정으로 교체, 탭 안 정렬도 같은 규칙 적용). 테스트 57/57 ALL PASS · 운영 읽기전용 34/34 ALL PASS. 운영 육안 = 첫 페이지 상위 3행이 금호 구미 / GS 원주 단구 / 롯데 화성 향남 전부 미확정, 4행째부터 20260916 내림차순.
• 배포 = master 1640a2f → deploy-live b1958ab(1파일 선별 포워드, --detach 워크트리). 사이트맵 = 그룹 8 · 페이지 54 · 미반영 0. devplan/pfs.html DONE AB 등재.

🆕 NOW (2026-08-25 · 4차) — 등록·수정 폼 현장상태 토글 = 진행중 ↔ 대기중 둘만 ✅운영배포 완료

[페페] qa_helper(/field/modify/2157, button[name=field_status]) = 「토글버튼 순서 수정. 진행중 대기중 2가지 순환만 적용한다. 이 버튼에서 완료는 제외한다. 운영배포」

• 「이 버튼」 = 등록·수정 폼의 현장상태 토글만이다. 목록 상태 컬럼 버튼은 종전대로 3단계 (대기중→진행중→완료) — 완료 표시를 목록에서 뺄 수는 없으니 둘이 서로 다른 순환표를 쓴다.
• 고친 것 = pfs-component.js 에 PFS_STATUS_FORM_NEXT = {'20':'10', '10':'20', '30':'20'} 신설, initFieldStatusToggle 이 PFS_STATUS_NEXT 대신 이걸 본다. 템플릿 2개는 버튼 title 문구만 「클릭: 진행중 ↔ 대기중」. 3파일 / +8 −3줄 · 서버코드 0 · DDL 0 · DB 변경 0.
• 🔑30 → 20 매핑을 남긴 이유 = 완료로 저장된 현장을 수정으로 열면 완료를 그대로 보여줘야 하고 (자동으로 바뀌면 저장 순간 상태가 조용히 뒤집힌다), 누르는 순간 두 상태 순환으로 들어오게 하려면 출구가 필요하다. 완료로 되돌리려면 목록 상태 컬럼 버튼을 쓴다.
• 검증 = _field_list_qa5_check.py 갱신. 테스트 55/55 ALL PASS(등록·수정 각 4클릭이 대기중/진행중 왕복이고 「완료」 미출현 + 완료 현장을 열었을 때 완료 유지 → 1클릭에 진행중) · 운영 읽기전용 32/32 ALL PASS. 회귀 _ship_tbd_check 테스트 ALL PASS. ⚠검사 함정 = 콘솔 500 필터(기존 /children)를 페이지를 더 열기 전에 적용해 두면 그 뒤에 생긴 500 이 남아 거짓 FAIL 이 난다 → 필터는 마지막 한 번만.
• 배포 = master a998988 → deploy-live f739d33(3파일 선별 포워드, --detach 워크트리). 사이트맵 = 그룹 8 · 페이지 54 · 미반영 0. devplan/pfs.html DONE AA 등재.
• ⏳페페 = 운영 육안 1회(현장 등록/수정 현장상태 버튼).

🆕 NOW (2026-08-25 · 3차) — 현장목록 상태 정렬 롤백 + 현장상태 필터 탭 ✅운영배포 완료

[페페] 「현장목록 상태 정렬순 취소한다. 다시 롤백해줘. 대신 테이블 상단 검색결과 텍스트 지우고 그 위치에 현장상태 필터용 탭을 달아줘. 대기중,진행중,완료. 나머지 완료 작업은 그대로 유지. 운영 배포」

• 고친 것 = field_list.html 한 파일(+53 −23줄). 서버코드 0 · DDL 0 · DB 변경 0.
• 롤백 = applyFieldFilter 의 기본 정렬을 상차일 내림차순 한 줄로 되돌렸다(2차 이전과 바이트 동일). fieldListGroup·fieldListOrder·STATUS_RANK 삭제. ⚠상차일 없는 현장이 맨 뒤로 밀려 안 보이는 부작용이 났다 → 5차에서 미확정만 맨 위로 되돌렸다(아래 5차 절). 「대기중/진행중/완료」 상태 그룹 정렬을 뺀 것은 그대로 유효하다.
• 신설 = <h5 class="card-title">검색결과</h5> 를 지우고 그 자리에 #status-tabs(대기중 10 / 진행중 20 / 완료 30). 한 번에 하나만 걸리고 같은 탭 재클릭 = 전체 해제 — 바로 위 업체 필터 버튼과 같은 방식이라 따로 배울 게 없다. 업체 필터·「진행현장」 토글과는 AND 로 겹쳐 걸린다. 활성 탭은 그 상태 색(--pfs-st-*)으로 밑줄까지 물든다. 죽은 CSS(h5.card-title) 제거.
• 그대로 둔 것 = 상태 컬럼 토글 · 등록/수정 현장상태 칸 · 탭 이동 · 20행. ⚠상차일 기간검색 NULL 통과(IS NULL OR …)도 유지한다 — 그건 정렬이 아니라 「미확정 현장을 목록에 띄우는」 수정이라 롤백 대상이 아니다. 빼면 미확정 현장이 목록에서 다시 사라진다.
• 검증 = _field_list_qa5_check.py 갱신. 테스트 51/51 ALL PASS(탭 3종 × 필터 결과·활성표시·탭 안 정렬· 재클릭 복귀 + 기존 항목 전부) · 운영 읽기전용 30/30 ALL PASS. 회귀 _ship_tbd_check 운영 ALL PASS. 육안 = 테스트 스크린샷 2장(전체/진행중). 운영 실측 = 대기중 6 / 진행중 8 / 완료 114(전체 128). ⚠검사 함정 = 상차일 없는 행은 내림차순에서 맨 뒤라 1페이지에 없다 → 상태버튼 토글 검사는 manageDataTable.search(이름) 으로 끌어올린 뒤 누른다.
• 배포 = master 6fda185 → deploy-live 89e5c9d(1파일 선별 포워드, --detach 워크트리). 사이트맵 = 그룹 8 · 페이지 54 · 미반영 0. devplan/pfs.html DONE Z 등재.
• ⏳페페 = 운영 육안 1회(현장목록 표 위 탭).

🆕 NOW (2026-08-25 · 2차) — 현장목록 QA 5건 ✅운영배포 완료

[페페] 「PFS 현장목록 수정 작업 추가 …①기본 정렬을 미확정/대기중/진행중/완료 순 + 항목별 상차일 내림차순 ②상태 컬럼 내용버튼 토글화(대기중-진행중-완료 순환·바로 DB) ③등록·수정에서 현장명 폭을 줄이고 유형과 상차일 사이에 현장상태 토글(기본 진행중·저장 반영) ④현장담당자 → 업체담당자 → 시공담당자 탭 직행 ⑤페이지당 10 → 20 · 운영배포」

• 고친 것 = 7파일 / +201 −49줄. DDL 0 · DB 변경 0 · 신규 API 0.
• ①정렬 = ~~그룹(미확정→대기중→진행중→완료) 정렬~~ → 3차에서 페페 지시로 롤백(아래 3차 절 참고). 지금은 상차일 내림차순 한 줄이고, 상태는 표 위 필터 탭으로 고른다. 🔑같이 고친 것 = 목록이 첫 진입에 기본 검색기간(과거6개월~미래1년)을 스스로 채우는데 select_field_search_list 의 상차일 비교가 NULL 을 걸러내 미확정 현장이 아예 안 나왔다 → (a.shipping_date IS NULL OR …). 어제 리포트 SQL 함정의 2차 발현 — 남은 자리는 rules.md 🆕 에 적었다.
• ②상태 컬럼 = statusBtnHtml() 한 곳에서만 마크업을 만들고 컬럼 렌더·클릭 후 갱신이 같이 쓴다. 저장은 확장행 칩과 같은 PATCH /api/field/status/<no>(서버 화이트리스트 그대로). 낙관적 반영 후 실패하면 되돌린다. 확장행 「현장 상태」 칩도 같이 맞춘다. ⚠클릭해도 행이 즉시 재정렬되진 않는다(커서 밑에서 행이 튀지 않게) — 다음 검색/새로고침에 새 순서로 온다.
• ③현장상태 칸 = 현장명 col-md-5→4 로 줄인 한 칸(col-md-1). 값은 버튼 data-st 하나에만 있고 저장할 때 읽는다(공용 initFieldStatusToggle in pfs-component.js). 서버 = insert_field 의 하드코딩 '20' 을 파라미터로, update_field 는 값이 올 때만 field_status 를 SET(안 그러면 목록 토글로 바꾼 상태를 폼 저장이 조용히 덮는다). select_field 에 d.field_status 추가(수정화면 초기값).
• ④탭 = 자동으로 채워지는 칸(직위·부서·업체명) tabindex="-1". 수정화면은 담당자 검색버튼까지 빼야 직행이라 같이 뺐고, 대신 이름칸 Enter 로 그 줄 팝업이 열리게 했다 — 수정화면은 팝업이 담당자를 고르는 유일한 길이라 그냥 빼면 키보드로 못 고른다. 등록화면은 인라인 검색(Enter 선택)이라 원래대로.
• ⑤ pageLength: 20.
• 현장상태 색(--pfs-st-*)을 pfs.css 단일 출처로 옮겨 목록·등록·수정이 같이 쓴다. field_list 의 사본과 STATUS_NEXT 중복 제거(확장행 칩 라벨만 칸이 좁아 '대기' 로 남겨둠).
• 검증 = 신설 scripts/_field_list_qa5_check.py [test|prod]. 테스트 38/38 ALL PASS = 임시 현장 2건 생성(미확정·완료 / 상차일 있음·대기중) → 등록·수정 상태 왕복 → field_status 미전송 시 값 유지 → 기간검색에 미확정 생존 → 화면 정렬 실측(그룹 단조증가 + 묶음 내 내림차순) → 상태버튼 3바퀴 후 DB 대조 → 폼 좌표(유형<상태<상차일)·기본값·순환 → 탭 홉 실측 → 소프트삭제 정리. 운영 읽기전용 16/16 ALL PASS(현장 생성 안 함·저장 안 누름). 운영 첫 페이지 = 미확정 2건 → 대기중 묶음 순. 회귀 _ship_tbd_check 테스트·운영 ALL PASS.
• 배포 = master c45cd33·adb7c2a → deploy-live f082d28(7파일 선별 포워드, --detach 워크트리). 사이트맵 재빌드 = 그룹 8 · 페이지 54 · 미반영 0. devplan/pfs.html DONE Y 등재.
• ⏳페페 = 운영 육안 1회(현장목록 정렬·상태버튼 · 현장 등록/수정 현장상태칸·탭).
• ℹ️④는 「엔터로 선택」이 등록화면에만 있는 동작이라 지시는 등록 기준이지만, 수정화면에도 같이 넣었다 (같은 탭 순서). 등록만 원하면 알려달라.

🆕 NOW (2026-08-25) — 상차일 「미확정」 토글 ✅운영배포 완료

[페페] qa_helper(/field/modify/2134, input[name=shipping_date]) = 「상차일 좌측에 미확정 토글버튼을 만들어줘. 상차일 미확정시 토글버튼 활성화후 날짜 미선택시에도 현장 등록, 수정이 가능하게 한다. 날짜를 입력하면 미확정 버튼은 자동 비활성화 시킨다. 반대로 미확정버튼을 활성화하면 상차일을 비운다. field/print/status 에서도 상차일 미확정인 경우 날짜 대신 "미확정"으로 표기. 운영배포」

• 설계 = 컬럼을 안 만든다. 미확정 = field.shipping_date IS NULL 하나뿐. char(8) NULL 허용 컬럼이라 DDL 0. 토글 버튼은 그 값의 거울이라 「날짜 있는데 미확정」 같은 모순 상태가 아예 없다.
• 고친 것 = 7파일 / +54 −13줄. ①web/static/js/pfs-component.js 공용 initShippingTbd($input, $btn) 21줄 — 등록·수정 두 화면이 같이 쓴다. btn-info↔btn-outline-secondary 로 활성 표시, 날짜가 들어오면(change) 자동 해제, 이미 미확정일 때 버튼을 누르면 달력을 연다. ②field_modify.html·field_regist.html = 버튼 마크업(input-group-prepend) + 호출 1줄씩. ③field_service.py = 상차일 필수검증 해제(값이 있을 때만 date 형식 검사) + None 방어. ④field_dao.py = insert_field·update_field·insert_shipping_history 에 CONVERT_EMPTY_STRING_TO_NULL(%s) (기존 sticker_dao 의 IS NULL 조건이 그대로 걸린다). ⑤production_status_dao.py·field_status_print.html = 리포트 포함조건 + 「미확정」 표기·정렬.
• 🔑근본원인 2건 — 둘 다 안 고쳤으면 기능이 겉으로만 되는 자리다(상세 = rules.md 🆕): ①리포트 SQL WHERE date_format(a.shipping_date,'%Y') >= 올해-1 이 NULL 을 통째로 걸러내 미확정 현장이 표에 아예 안 나왔다 → (a.shipping_date IS NULL OR …). ②daterangepicker 는 typeof null === 'object' 라 startDate: null → moment(null)=Invalid date → 달력이 안 그려져 미확정 현장에서 날짜를 다시 고를 수 없었다 → resultData.shipping_date || moment().format('YYYY-MM-DD') 로 열고 입력칸만 비운다.
• 정렬 = 미확정 행은 맨 뒤(byDate 에서 8e15). 표기는 fmtDate 한 곳(생산·AS 표 둘 다 여기를 탄다).
• 검증 = 신설 scripts/_ship_tbd_check.py([test|prod], scripts/_* 는 gitignore). 테스트 27/27 ALL PASS = 임시 현장 생성(상차일 빈 값)→저장값 NULL 확인→리포트 API 포함·date 없음→날짜 왕복 (20260921↔NULL, 히스토리 경로 포함)→UI 토글 4항·등록화면 2항→fmtDate(null)=미확정·표 셀 실측·맨 뒤 정렬 →소프트삭제 정리. 운영 17/17 ALL PASS(읽기 전용 — 현장 생성 안 함, 저장 안 누름).
• 배포 = master a6da396·86c168f → deploy-live 7b8d622(7파일 선별 포워드, --detach 워크트리). DDL 0 · DB 변경 0. 사이트맵 재빌드 = 그룹 8 · 페이지 54 · 미반영 0 · 공용API 5. devplan/pfs.html DONE X 등재.
• ⚠별건(이번 변경과 무관·미수정) = /api/field/<no>/children 은 하위 AS 가 0건이면 500 ('tuple' object has no attribute 'sort' — fetchall 이 빈 결과에 tuple 을 준다). 기존 현장 2134·2142 도 동일.
• ⏳페페 = 운영 육안 1회(현장 > 수정 > 상차일 좌측 「미확정」 · 현장 > 생산현황 출력).
• ℹ️착수 절차 = 계획 3단계(Fable 계획 → 코덱스 상의 → devplan 계획페이지)를 건너뛰고 바로 실행했다. 단일 QA 코멘트 · 사양이 확정돼 있어 기계적 작업으로 봤다. 다르게 원하면 알려달라.

🆕 NOW (2026-08-24 · 3차) — 월마감 담당자 지정 · 견적서 담당자 예외 · 월마감 금액 견적서 연동 ✅운영배포 완료

[페페] ①월마감 담당자는 업체 「참조」 체크된 사람이 기본이되 넥서스=장동욱 차장 / 에넥스=강동식 차장 / 봉적=김양훈 차장 / 아이비젼글로벌=은지호 대표로 고정. 「하드코딩 아니다」 ②견적서 엑셀 담당자도 참조인원 연계인데 넥서스만 해당 현장 담당자 이름+직책 예외 ③월마감에 견적항목을 담은 뒤 금액이 굳어 견적 수정이 반영 안 된다 → 자동반영. 운영배포.

• 그릴링 3문 확정 = 조회할 때마다 재계산 / 과거 마감월도 같은 규칙 / company_member 컬럼 신설 + 「견적참조」 다음 컬럼으로 UI 연동. 참조 체크 4명 정리는 페페가 직접 했다(운영 확인 완료).
• DDL(운영·테스트 선행) = company_member.close_manager_yn · company.estimate_manager_field_yn (둘 다 CHAR(1) DEFAULT '0', 기존 동작 불변). 스크립트 = scripts/op_close_manager_cols.py.
• ①담당자 = close_manager_yn 체크 > 「견적참조」 체크 > 빈칸. 이름+직책으로 조립. 거래처 목록 API 와 마감 헤더 양쪽에 폴백 — 새 마감·기존 마감 모두 채워진다. 저장값이 있으면 그게 우선. UI = 업체 > 담당자 화면 입력폼·표에 「월마감담당」 체크박스(견적참조 바로 다음).
• ②견적서 담당자 = company.estimate_manager_field_yn 켜면 현장담당자, 끄면 참조인물. _compose_manager 한 곳만 보므로 엑셀·PDF·HTML 이 같이 따라간다. UI = 업체 > 수정 「견적서 담당자 = 현장 담당자로 표기」. 넥서스만 ON(scripts/op_nexus_estimate_manager.py).
• ③금액 연동 = 견적번호가 붙은 항목은 조회할 때마다 견적서에서 재계산(_relink_amounts). 본건·추가건 각각, 시공비 분리 거래처는 담기 모달과 같은 _CONS_EXPR 로 떼서 본건 행에 누적. 목록 합계도 같은 규칙(상세를 열기 전에도 안 어긋난다). 되쓰기 없음 — 조회가 DB 를 안 건드린다. 손입력 행(견적번호 없음)·확정금액·완료청구일·비고는 불변.
• 🔑근본원인 1건 = 담당자 폴백이 「일부만」 안 걸리던 이유 = SELECT h.* 에 같은 이름 별칭을 얹어 DictCursor 가 원본(NULL)을 남기고 계산값을 버린 것. 별칭을 manager_name_default 로 분리. rules.md 등재.
• 검증 = 신설 scripts/_mc_manager_amount_check.py [test|prod] 테스트·운영 각 ALL PASS (거래처 100개 담당자 기본값 전수 대조 · 스위치 ON/OFF 견적 각 3건 · 마감 헤더 폴백 · 연동 항목 운영 13행·테스트 56행이 견적총액과 일치 · 목록합계=상세합계). 🔑연동 실증 = 테스트 DB 에서 견적 총액 +1,000,000 → 마감이 즉시 51,793,000 으로 따라 움직이고 원복도 반영, DB 저장값은 안 건드림 확인. 회귀 = _monthly_close_ui_check 운영·테스트 19/19(고정 기대값 252,970,000 을 자기정합 대조로 교체 — 금액이 견적을 따라가니 숫자를 박으면 거짓 FAIL) · _kst_timezone_check · _kf_softdelete_page_check 운영 ALL PASS.
• 배포 = master f5aa495+ → deploy-live 6c7088f(12파일 선별 포워드). 사이트맵 그룹8·페이지54·미반영 0.
• 운영 실효 = 견적과 어긋나 있던 11행 해소 · 넥서스 월마감=장동욱 차장 / 견적서=현장담당자(조세영 대리) 확인.
• ⏳페페 = 운영 육안 1회(월마감 새 거래처 담기 시 담당자 자동입력 · 넥서스 견적서 출력 담당자칸).

🆕 NOW (2026-08-24 · 2차) — 시간대 전면 KST 전환 ✅운영배포 완료

[페페] 「PFS 생산현황 메모수정 알람을 보니 시간대를 KST 로 계산 안 하고 있다. PFS 전수 검사해서 시간대는 모두 KST 기준으로 수정하고 운영배포해.」 + 「코디 기본 지침도 KST 로 보고·표기하게 고쳐놔라」

• 뿌리 = EC2 OS(Etc/UTC) 와 RDS(time_zone=UTC) 가 둘 다 UTC. NOW()·CURDATE()·datetime.now() 전부 9시간 밀림.
• 전수 검사 = Python naive now 15곳 · SQL NOW() 155곳 · CURDATE() 9곳 · 서버 DATE_FORMAT(%H:%i) 10여곳 · DATETIME 79컬럼(전부 UTC 저장 확인) · TIMESTAMP 22 · DATE 78 · API 21개가 GMT 라벨 datetime 송출. 🔑지금 「맞게」 보이던 화면 21개는 우연이었다 — Flask 1.0.2 가 naive datetime 에 GMT 를 붙이고 브라우저가 +9 해서 맞은 것.
• 그릴링 6문 페페 확정 = ①저장까지 전면 KST ②과거 데이터 백필 ③RDS 파라미터그룹 레버 ④즉시 집행(앱 중지) ⑤테스트도 같이 ⑥EC2 서버 전체 TZ.
• 집행(다운타임 10:32~10:36 KST, 4분)
• RDS 파라미터그룹 pfs-custom-params-84 time_zone=Asia/Seoul(dynamic·무재부팅) — 앱뿐 아니라 사무실 PC 러너·직접 조회까지 한 번에 정합.
• EC2 timedatectl set-timezone Asia/Seoul + 테스트DB 백업 크론 30 17→30 2(02:30 KST 유지) + cron 재시작.
• 테스트 도커 MySQL SET PERSIST time_zone='+09:00' — 재기동 실측으로 커맨드라인 --default-time-zone=+00:00 을 이기는 것 확인(컨테이너 재생성 불필요).
• 백필 scripts/kst_backfill.py = DATETIME 78컬럼/45테이블 +9h. 운영 120,719행 · 테스트 15,968행. 제외 = TIMESTAMP 22(세션tz 자동변환·백필하면 이중) · DATE 78(상차일 등 사용자 입력) · door_order_file.file_mtime(사무실PC 파일시각 = 이미 KST). 테이블당 단일 UPDATE(나눠 쏘면 같은 행 ON UPDATE 컬럼이 현재시각으로 튄다) + 컬럼마다 전후 MAX 차이 ±9h 검증.
• 생산 메모 JSON(web/static/uploads/memo/field_memo.json) 도 +9(운영·테스트).
• 코드(master f318745 → deploy-live f69d3d8, 6파일 선별 포워드)
• KstJSONEncoder(web/init.py) — GMT 라벨 → KST 평문. 값을 그대로 찍던 화면(견적·사용자·현장 목록 DataTables)과 sticker.html 의 String(v).slice(5,16)(원래 YYYY-MM-DD HH:MM:SS 전제였던 잠복버그)까지 같이 옳아졌다.
• pfsParseDateTime() 신설(pfs-utils.js) — 공백형식을 T 로 바꿔 ES2015 「오프셋 없으면 로컬시간」 규정으로 확정 파싱. convertDateYYYYMMDD* 는 getUTC* 라 그대로 두면 하루 밀림 → 로컬 게터로. field_orderpaper 5곳·field_kakao_rooms 1곳 교체.
• orderpaper_dao 의 CONVERT_TZ('+00:00','+09:00') 보정 제거(두면 이중이동).
• 🔴사고 1건(복구 완료·잔여 0) = ssm_run.py 가 원격에 인자를 안 넘겨 --dry 가 무시되고 실집행(14테이블 +9). 즉시 -9 원복 → 그 사이 INSERT 된 audit_log 4행(PK 109052~109055)을 PK 로 특정해 +9 정정(시각 구간으로 고르면 정상행 126개가 섞인다). 이후 위험 스위치를 파일 내 상수 EXECUTE=False 로 교체. rules.md 🆕 등재.
• 검증 = RDS 스냅샷 pfs-pre-kst-20260824(01:22Z = 백필 이전) · 신설 scripts/_kst_db_check.py(SSM) 운영·테스트 ALL PASS(NOW=UTC+9 · 신규 저장값이 KST · 미래시각 0건 = 이중적용 없음 · 크론 보정) · 신설 scripts/_kst_timezone_check.py [test|prod] 각 ALL PASS(GMT 라벨 0건 · 평문 2,160개 · 브라우저 실파싱 09:37 · 날짜 안 밀림 · 콘솔 0) · 회귀 _kf_softdelete_page_check 운영·테스트 ALL PASS · _field_status_print_date_check 17항 · _field_status_print_ivision_check ALL PASS. 사이트맵 그룹8 · 페이지54 · 미반영 0.
• 전역 지침도 갱신(페페 지시 2번째) = C:\dev\CLAUDE.md §2-3 = 「날짜 26.7.27(화) · 시각 = KST」, 단일 출처 = rules/tooling.md 「날짜·시각 표기」 — 보고·표기물 전부 KST, 서버 로그 인용은 00:29 UTC = 09:29 KST 병기.
• ⏳페페 = 운영 육안 1회(메모 저장 시 텔레그램 알림 시각이 지금 시각과 맞는지).

🆕 NOW (2026-08-24) — 생산현황 출력 타입 카운트에서 소프트딜리트 타입 제외 ✅운영배포 완료

[페페] qa_helper(/field/print/status, div.muted 「(3/3)」) = 「타입 카운트를 소프트딜리트한 항목까지 같이 계산하고 있다. 타입이 소프트딜리트(remove_yn) 1이 되면 카운트에서 제외해줘. 운영배포」

• 고친 것 = api/pfs/field/dao/production_status_dao.py 2줄. select_production_status_print()(생산현황 출력)와 select_calendar_print()(월간계획표)의 LEFT JOIN field_type AS f ON 절에 AND f.remove_yn < 1. 둘이 같은 KF CASE 식을 복사해 쓰고 있어 한쪽만 고치면 화면마다 숫자가 또 갈린다 → 같이 고쳤다.
• 🔑WHERE 가 아니라 ON — WHERE 로 넣으면 LEFT JOIN 이 INNER 가 돼 타입 0개 현장이 표에서 사라진다 (리포트 9행 중 4행이 타입 0개). rules.md 🆕 등재.
• 왜 어긋나 있었나 = 현장목록(field_dao)은 예전부터 remove_yn < 1 서브쿼리로 센다. 리포트만 안 걸렀다.
• 운영 실데이터 영향 17개 현장 — 일레븐 파크사이드 (3/3)→(2/1) · GS 오산 양산 (13/5)→(10/3) · 욕실 샘플장 (F:3)→공백 등. 오늘 리포트에 뜬 진행중 9건엔 삭제 타입이 없어 화면 숫자는 오늘 그대로다.
• 검증 3겹 ① 운영 RDS 에서 DAO SQL 원문을 그대로 떠 A/B 대조(scripts/_kf_sql_ab_gen.py → _kf_sql_ab_check.py) — 행 집합·KF 외 전 컬럼 동일, KF 만 기대값대로. ALL PASS. 캘린더도 319행 동일·KF 3건만 변화. ② 신설 scripts/_kf_softdelete_page_check.py [test|prod] = 앱 안 교차대조(리포트·캘린더 API 의 KF ↔ 현장목록 API 의 field_type_10/20/30). 배포 전 운영 FAIL(욕실 샘플장) → 테스트 ALL PASS → 배포 후 운영 ALL PASS(대조 커버리지 154/319행). ③ 회귀 = _field_status_print_date_check.py 17항 · _field_status_print_ivision_check.py 운영 ALL PASS.
• ⚠함정(rules.md 🆕 등재) = 캘린더 API 는 field_no 를 안 내려줘 조인 키가 없으면 0건 대조로 조용히 ALL PASS가 된다. 커버리지 체크를 먼저 넣어야 검증이 검증이 된다.
• 배포 = master f9eb62e → deploy-live a3bc435(1파일 선별 포워드, --detach 워크트리). DDL 0 · DB 변경 0 · 프론트 0. 사이트맵 재빌드 = 그룹 8 · 페이지 54 · 미반영 0. devplan/pfs.html DONE 에 a3bc435 등재 + 허브 재빌드(pfs 카드 2026-08-24).
• ⏳페페 = 운영 육안 1회(현장 > 생산현황 출력 — 삭제한 타입이 개수에서 빠졌는지).

🆕 NOW (2026-08-21 · 2차) — 파레트용지 「현장명」·「상세」 글자크기 칸 안 최대치 자동조절 ✅운영배포 완료

[페페] qa_helper(/production/sticker, div.ps-detail) = 「상세내용 메모 글자 크기를 실시간으로 프레임 구역 안에서 최대치로 자동조절해서 보이게 해줘. 줄바꿈 상황도 고려해서 조정. 운영배포」 → 이어서 채팅 = 「현장명 이름도 글자크기 최대 자동조절 되게 해줘. 이것도 운영배포까지 진행」(현장명 = 현장명 입력값).

• 고친 것 = web/templates/default/sticker.html 한 파일(CSS 2줄 + JS 22줄). 라이브러리 0.
• 공용 이분탐색 fitFont(el, fits) = 1~50mm 12회. fits() 가 참인 최대 mm 를 인라인 font-size 로 박는다. fitSheetText() 가 상세·현장명 둘을 각자 판정식으로 부르고, fitPallet() 끝에서 호출된다 → 타이핑마다(input→renderPallet) 실시간 + 탭 전환·창 리사이즈에도 재계산.
• 상세(.ps-detail) = min-height:0; overflow:hidden 추가. flex 자식의 min-height:auto 를 풀어야 긴 글이 칸을 늘리지 않고 넘침이 측정된다. 판정 = scrollHeight<=clientHeight && scrollWidth<=clientWidth.
• 현장명(.ps-site) = overflow:hidden + 값을 <span> 으로 감쌌다. 가운데 정렬 flex 는 위로 넘친 만큼이 scrollHeight 에 안 잡혀 못 믿는다 → 안쪽 span 의 offsetWidth/offsetHeight 를 칸 안쪽 치수와 직접 대본다.
• 인쇄에도 그대로 간다 — printPallet() 이 #stk-pallet-sheet HTML 을 통째로 복사하니 인라인 font-size 가 따라가고, 웹 196mm(테두리 0.5mm×2, border-box) = 인쇄 195mm(테두리 없음) 로 내용 높이가 같다.
• 🔑함정(rules.md 🆕 등재): 안 넘치는 블록은 scrollHeight == clientHeight 라 안전여유 -4px 를 빼면 조건이 항상 거짓 → 1차 테스트배포에서 모든 길이가 1.0mm 로 나왔다. 등호 비교로 수정.
• 검증 = scripts/_stk_pallet_fit_check.py(기존 배율 11항 + 상세 12~17 + 현장명 18~23, scripts/_* 는 gitignore). 테스트 ALL PASS · 운영 ALL PASS(각 0 fail). 상세 = 짧은글 35.9mm / 12줄 3.5mm / 24줄 1.8mm, 현장명 = 짧은 50.0mm / 보통 25.7mm / 아주긴(70자) 17.2mm. 세 경우 모두 세로·가로 안 넘침 + 칸 치수(196mm·62mm) 유지 + 콘솔 에러 0. 스크린샷 4장 육안 확인 (%TEMP%\stk_pallet\detail_short|detail_huge|site_short|site_long.png). ⚠검사 스크립트는 페이지 JS 가 IIFE 라 S·renderPallet 을 못 부른다 → 현장명은 span 텍스트를 직접 넣고 window.dispatchEvent(new Event('resize')) 로 fitPallet→fitSheetText 를 발화시켜 잰다.
• 배포 = master f63fc25·8f956da·c8e0798·0c81e76 → deploy-live a5c7b20·9ad83ea (sticker.html 1파일 선별 포워드, --detach 워크트리). 그 파일의 deploy-live↔master 차이가 이 변경뿐임을 git diff --stat 로 먼저 확인(옛 스티커 커밋들은 이미 cherry-pick 반영돼 있었다). DDL 0 · DB 변경 0. 사이트맵 재빌드 = 그룹8 · 페이지54 · 미반영 1→0 · 공용API 5. devplan/pfs.html DONE 에 9ad83ea 등재.

🆕 NOW (2026-08-21 · 1차) — 생산현황 출력 헤더 날짜: 수동선택 + 기본 자동표기 ✅운영배포 완료

[페페] qa_helper(/field/print/status, #rpt-date) = 「①날짜를 수동으로 바꿀 수 있게. 가능한 캘린더 형식으로 사용자가 날짜선택 되게 한다. ②기본 자동표기 = 당일 0~9시 출력이면 당일 날짜, 당일 9시~24시면 내일 날짜. 운영배포」

• 고친 것 = web/templates/basic/field/field_status_print.html 한 파일(26줄 추가·5줄 삭제, JS·CSS·HTML만). ①네이티브 <input type="date"> 를 우상단 날짜 옆에 붙였다(.rpt-datewrap flex). 라이브러리 0. class="no-print" 라 기존 인쇄 CSS(.no-print{display:none!important})가 출력물에선 자동으로 숨긴다 → 종이에는 종전대로 8.21(금) 텍스트만 나간다. ②headerDate()(무조건 오늘) → defaultHeaderDate() = if (d.getHours() >= 9) d.setDate(d.getDate()+1). loadReport() 에서 pick.value = ymd(defaultHeaderDate()) 로 채우고 change → applyHeaderDate(). 칸을 비우면 기본값으로 되돌아온다(빈 헤더 방지).
• ⚠날짜는 표시 전용 — 데이터는 안 바뀐다. /api/field/status/report 는 날짜 파라미터가 없고 진행중 현장을 전량 내려준다. 즉 날짜칸을 바꿔도 표 내용은 그대로다(페페 지시 범위 = 「날짜 표기」뿐). 날짜별 필터가 필요하면 API부터 손대야 한다 — 별건.
• 검증 = 신설 scripts/_field_status_print_date_check.py(Playwright, 읽기 전용, scripts/_* 는 gitignore 라 로컬 보관). 페이지 안에서 window.Date 를 잠깐 교체해 시각별 기본값 7건을 실측(00시·08:59=당일 / 09:00·23:59=익일 / 월말 8.31 10시→9.1 / 연말 12.31 22시→익년 1.1 / 12.31 03시=당일) + UI 7건 (type=date·기본값·M.D(요일) 포맷·수동변경 12.25(금)·칸비움 복귀·인쇄 시 캘린더 display:none·텍스트 유지)
• 콘솔 0. 테스트 17/17 ALL PASS · 운영 17/17 ALL PASS. 회귀 = _field_status_print_ivision_check.py 테스트 ALL PASS · 운영 ALL PASS.
• 배포 = master 918b79b → deploy-live 1fca652(1파일 선별 포워드, --detach 워크트리). DDL 0 · DB 변경 0 · 서버코드 0. 사이트맵 재빌드 = 그룹 8 · 페이지 54 · 미반영 0.
• ⏳페페 = 운영 육안 1회(현장 > 생산현황 출력 → 우상단 날짜 옆 캘린더칸).

🆕 NOW (2026-08-20 · 1차) — 스티커 파레트용지 미리보기 자동배율 ✅운영배포 완료

[페페] qa_helper(/production/sticker) = 「A4용지 미리보기 크기가 너무 작다. 남는 화면을 최대한 채워서 볼수 있게 수정해줘. 운영배포」

• 고친 것 = sticker.html 한 파일. 고정 scale(0.4)(428px) → fitPallet() 이 남는 폭·뷰포트 높이에서 배율을 계산해 --ps 로 박는다(CSS mm = 96dpi 고정이라 283mm=1069.6px 로 계산이 결정론적). 미리보기 열 = .stk-pallet-prevcol{flex:1 1 0;min-width:0} → 그 열 clientWidth 가 곧 가용폭이라 순환참조 없다. 호출 3곳 = renderPallet() 끝 · 탭 전환(숨김 상태에선 폭 0 이라 표시 후 재계산) · window resize. 하한 0.4 = 예전보다 작아지지 않음.
• 검증 = scripts/_stk_pallet_fit_check.py(Playwright, 11항) — 테스트·운영 ALL PASS. 1920×1080 = 428 → 1182px(배율 1.105, 2.76배) · 1366×768 = 788px(0.737) · A4 비율 1.444 유지 · 화면 밖 넘침 0 · 콘솔 0.
• 배포 = master 2b732e8 → deploy-live f938944(1파일 선별 포워드, --detach 워크트리). DDL 0 · DB 변경 0 · 인쇄 CSS 무관. 사이트맵 재빌드 = 그룹 8 · 페이지 54 · 미반영 0.
• ⏳페페 = 운영 육안 확인.

🆕 NOW (2026-08-19 · 8차) — AL QA 5건: 설정 인라인검색·자동저장 · 큰손/작은손 갭·짝 묶기 ✅운영배포 완료

[페페] qa_helper 5건(/field/al-profile 4 + /field/al-orderpaper 1, 「아래 모든 작업 처리 후 운영배포한다」): ①업체 인라인 검색 + 「공통」처럼 수동입력도 허가 ②검색칸에 뜨는 null 안 보이게 ③수정·추가는 자동저장 ④그래서 저장 버튼 삭제 ⑤「큰손·작은손 도어의 갭빼기 치수도 적용. 목대 0.5는 버림해서 정수. 짝으로 나오면 갭을 뺀 뒤 실질적으로 같은 목대·유리가 나와야 하는데 각 행이 짝인지 모르니 NO 칼럼에 2행 이상을 연결하는 기능을 달아라」 + 발주서 작성법 5단계(엑셀 원식 ((D-10-VLOOKUP(,6))/2)+VLOOKUP(,7)).

배포 = master 7758a18·e06d62a·3b807a1 → deploy-live 2bbc552(9파일 선별 포워드, --detach 워크트리). 운영 DDL 선행(SSM) = al_orderpaper_item.pair_link CHAR(1) NOT NULL DEFAULT '0' 추가만, 데이터 변경 0. ⏳페페 = 운영 육안 1회(현장 > AL발주서 NO칸 🔗 · AL설정 관리 자동저장).

• 🔑⑤의 핵심 = 빠져 있던 항이 큰손마감(설정 7열) 하나였다. W=(장외경-10-큰손갭)/2 만 있었다 → +큰손마감 을 붙이자 같은 장외경 800 에서 작은손 383.5 / 큰손 406.5 로 갈린다. 목대·유리는 정수 버림 (370.5→370 · 377.5→377). 버림 범위는 페페 텔레그램 확정(ASK-FA7446 = 「둘다 정수버림」, 규격W·AL치수는 유지).
• 짝 묶기 = NO칸 🔗 토글(pair_link = 이 행은 윗행과 한 짝, 2행 이상 연속 가능). 묶으면 ①장외경 공유 (한 칸에 치면 묶음 전체가 따라간다) ②목대·유리를 첫 행 값으로 통일 ③원래 달랐던 행은 NO칸 노랑. 같은 규칙이 서버 al_calc.compute_rows() 에도 있어 엑셀·인쇄까지 화면과 같은 값이 나간다. ⚠조용히 덮지 않는 게 설계 요점 — 정상 짝은 설정 상수가 이미 맞춰져 있어(AA-303/304 목대뺄 13/36, 차이 23 = 큰손마감) 통일이 no-op 이고, 값이 갈리면 그건 상수 미입력 신호다(AA*494/495 = 목대뺄 0/0).
• ③④ 자동저장 = 타이핑 멎고 0.9초 뒤 1콜. 🔑저장 후 load() 로 다시 그리지 않는다(커서·스크롤 소실) → 응답에 신규행 번호 nos 를 실어 화면 행에 물린다. 안 물리면 다음 저장이 같은 행을 또 INSERT 한다. 안전장치 = 품명 0행이면 저장 스킵(표 전멸 방지) · 숫자 아닌 값이면 보류 · 저장된 행 × 는 1회 확인.
• ① 인라인 드롭리스트를 web/static/js/al_combo.js 공용 모듈로 분리(CSS 자체 주입) → 발주서·설정 두 화면이 같은 동작. 후보 = 설정표에 이미 쓰인 업체 + PFS 거래처, 목록에 없는 값도 그냥 타이핑(=「공통」).
• ⚠②는 재현 실패 — 운영·테스트 실측 #apSearch placeholder 는 둘 다 업체·품명 검색 이고 소스·git 이력에 null 이 없다(el.placeholder = null 을 넣는 코드도 없다). 코드에서 값을 한 번 더 못박아 두었다. 또 뜨면 캡처 + 브라우저/확장 정보 필요.
• 검증 = 신설 scripts/_al_qa5_check.py(설정표는 임시행 1개 추가→삭제 후 전/후 스냅샷 대조, 발주서는 운영에서 저장 안 함). 테스트 37 ALL PASS · 운영 33 ALL PASS(B19~22 = 저장 영속·엑셀은 테스트 전용). 회귀 = _al_orderpaper_e2e_test.py 20 PASS · _al_recv_check.py ALL PASS · _al_combo_check.py ALL PASS · al_calc.py 자체검사(짝 공유·통일·버림) PASS. 사이트맵 = 그룹8·페이지54·미반영 0.
• 파일 = api/pfs/al_orderpaper/{al_calc,service/al_orderpaper_service,dao/al_orderpaper_dao,dao/al_profile_dao}.py · web/static/js/{al_combo(신규),al_orderpaper,al_profile}.js · web/templates/basic/field/field_al_{profile,orderpaper}.html. → projects/pfs/rules.md 🆕

🆕 NOW (2026-08-19 · 7차) — AL발주서 QA 3건: 유리 입고처 · 전화면 가로폭 · 거래처 담당자 실시간 ✅운영배포 완료

[페페] QA 3건(/field/al-orderpaper, 같은 세션 연속 지시 · 셋 다 "운영 배포"): ①「유리는 AL업체에 넣어줘야 하니 입고처 컬럼이 필요. 마지막에 생성, 기본은 발주서에 연결된 업체, 인라인 검색·Enter 수동입력, 지정 업체는 거래처 주소까지 참고해 엑셀 입고처 업체명·주소칸에 넣는다. 한 유리업체에 입고처 2곳 이상이면 입고처별로 행을 그룹화하고 입고처 행은 그 그룹 바로 아래. 행을 추가하지 말고 기존 블록행 개수 안에서 교체」 ②「기본정보·데이터입력 프레임 가로폭 부족 — 사이드메뉴 뺀 전화면 폭 + 컬럼폭 절약」 ③「대진아트와이어 담당자를 바꿨는데 갱신이 안 들어온다」

배포 = master fffd408·b98e683·b23cf72 → deploy-live 9963dd5·75172d2(파일 5개 선별 포워드, --detach 워크트리). 운영 DDL 선행 적용(SSM) = al_orderpaper_item.receive_place VARCHAR(100) 컬럼 추가만, 데이터 변경 0. ⏳페페 = 운영 육안 1회(현장 > AL발주서 → 새 발주서 → 표 맨 오른쪽 입고처).

• 🔑③의 근본원인 = 업체 자동완성이 DB 가 아니라 번들 JSON 스냅샷이었다(assets/vendors.json = 원부자재발주서.xlsx 업체탭, 381행 + 프로세스 캐시). 거래처를 고쳐도 발주서엔 구조적으로 못 들어온다. 운영 실측 = company_member 대진아트와이어(136) 는 신동환차장 삭제(remove_yn=1) · 김정현대리 활성 (modify_date 2026-08-19)인데 화면은 신동환차장. → company+company_member 실시간 조회로 교체, 거래처에 없는 이름만 스냅샷 보충, 캐시 제거. 운영 407→414행(스냅샷 전용 1건 = 거래처에 없는 업체). ⚠이미 저장된 발주서의 헤더 담당자칸은 그대로 둔다 — 그때 팩스 받은 사람 기록이다. 업체명을 드롭리스트에서 다시 고르면 새 담당자로 갱신된다(pickCombo 가 값이 같아도 change 를 쏜다).
• ①은 양식 블록 구조를 그대로 쓴 게 핵심 — 유리시트 블록(29행)마다 입고처 행이 이미 있다(C 업체명 · D 주소/담당자, 원본은 업체시트 참조 수식). 그래서 행 삽입 없이 유리 그룹 키를 「업체」→「업체+입고처」로 바꾸는 것만으로 지시(그룹화·바로 아래·행 교체)가 전부 충족된다. 화면 기본값은 _recvAuto 플래그로 「사람이 손댄 행은 안 덮는다」(헤더 업체명을 한 글자 칠 때마다 덮이면 안 된다). 미리보기·인쇄 미러도 같은 그룹·입고처 행을 그려 팩스로 나가는 종이와 엑셀이 어긋나지 않는다.
• 🔴중간에 잡은 기존 버그(같은 블록 로직) = 유리 항목 17개 이상이면 엑셀 다운로드가 500이었다. 양식 24행이 캡노트(C24:H24 병합)인데 항목행 판별이 병합 시작열을 B 만 봐서(AL 캡노트는 B16:N16) 항목행으로 셌고, 그 행 D 셀은 MergedCell 이라 기입 순간 read-only 예외. 판별을 B·C 로, 유리 ipb 18→17.
• 검증 = 신설 scripts/_al_recv_check.py(읽기전용 + 테스트만 저장·삭제). 배포전 테스트 9 FAIL → 테스트 24 ALL PASS → 운영 18 ALL PASS. 회귀 = _al_combo_check.py 19 ALL PASS · _al_orderpaper_e2e_test.py 20 PASS/0 FAIL · 엑셀 모듈 자체검사(입고처 분리·17/18 경계·주소없는 입고처). 운영 검증은 기존 발주서 1(금강 부산에코 · AL 대진아트와이어 · 유리 지앤티)의 엑셀을 GET 만 해서 입고처 = 대진아트와이어 + 거래처 현재 담당자로 나오는지 대조. 사이트맵 = 그룹8·페이지54·미반영 2 (미반영 2건은 내 작업 아님 = 견적서 등록·수정 v2, master 전용).
• ⚠검증이 두 번 잡아낸 것(둘 다 배포 후 즉시 수정) = ①입고처에 거래처 주소가 없으면 주소칸이 포인 주소로 폴백해 「업체명은 남의 것, 주소는 포인」이 나갔다(or 폴백을 recv 유무 기준으로 분리) ②입고처 주소칸이 발주서에 저장된 옛 담당자로 나갔다 → 거래처 마스터를 1순위로 뒤집었다(페페 지시 "거래처 주소까지 참고").
• 파일 = api/pfs/al_orderpaper/{al_orderpaper_excel,dao/al_orderpaper_dao,service/al_orderpaper_service}.py · web/static/js/al_orderpaper.js · web/templates/basic/field/field_al_orderpaper.html. → projects/pfs/rules.md 🆕

🔶 루트 NOW 이관 — 진행·미결 (2026-08-19 대청소, 페페 지시)

루트 HANDOFF.md를 pncad 만 남기고 비웠다. 아래는 그때 옮겨온 원문(문구 무변경).

• 🆕intake-check 자재 입고 체크 [코디] 26.8.10 가동 중 — 카톡 「포인01」 명세서 사진 → 판독 → 운영 pfs orderpaper 1:1 매칭분만 완료+입고일. 매일 16:30 예약작업 IntakeCheck-1630. 운영 반영 7건 완료, 정확도 = 정밀도 100%(7/7, 오탐 0) · 재현율 46.7%(누락 8 = 헤펠레 경첩 별칭 미보유). 카톡 보고 = 신동승(정확도 포함) + 포인 신동혁 대리(자재만). ✅막혀 있던 신동혁 발송 해소 — 방 이름이 계정마다 달랐다(PC 신동혁 ↔ 폰 포인 신동혁 대리) → 테스트 발송 11:15 수신 확인. ✅발송 대상은 이제 devplan 카톡관리(kakao-ops)의 「자재입고 발송」 체크가 단일 출처(fail-closed·마지막 발송시각 표시) + 방 목록 자동 등록(16:30 예약작업이 rooms.py list 선행 — 신동혁 방이 안 뜬 원인은 8/5 스냅샷 고착). ✅번호↔카톡이름 매핑 poin-agent/people_map.py(find로 발송 이름 조회). ⏳남은 것 = ①오늘 16:30 첫 정규 실행 검증(사진 원본 대조 → runs/*.verdict.json → --accuracy) ②업체코드↔pfs 품명 별칭 사전으로 재현율 올리기 ③확인요청 2건(상원보드 LPM4.5 HS2329 / 프린테크 PTA261) ④rules/tooling.md 전역함정 2건(schtasks /tr raw string · 폴더명 끝 점). → .claude/skills/intake-check/SKILL.md · projects/{pfs,talklog}/rules.md

🆕 NOW (2026-08-20 · 2차) — 견적목록 추가건 폴딩 발견성 ✅운영배포 완료

[페페] 「estimate/list-v2 에서도 추가건들 폴딩으로 볼수 있게 해줘. 그래야 입금여부 설정을 내가 할 수 있다」 + 「운영배포」

🔑기능은 이미 1차에 들어가 있었다 — 화면에서 찾을 수가 없었을 뿐이다. 실측 = 기본 목록 36행·페이지당 10행인데 추가건 보유 본건 5건이 전부 6~7월 건이라 최신순 1페이지에 ▶ 가 0개(visibleFold=0). 1차 E2E 가 이걸 못 잡은 이유 = 검증이 datatable.page.len(-1) 로 전 페이지를 펼쳐놓고 셌다.

• 「추가건 있는 건만」 체크박스 신설(검색 필터, 「보관 포함」 옆). 이미 받은 결과에서만 거른다 ($.fn.dataTable.ext.search, 서버 왕복·신규 API 0). 운영 실측 10행 → 5행 · ▶ 0개 → 5개.
• ▶ 라벨에 건수 — ▶ 추가 3 + btn-info. 접었다 펴도 건수는 남는다.
• 추가건 입금여부 토글은 원래부터 정상이었다 — 하위행 배지 클릭 → PUT /api/estimate/<no>/deposit → DB 반영·3회 순환 원상복귀까지 실측 확인(테스트). 페페가 못 만졌던 건 순전히 폴딩을 못 찾아서다.

검증 = _mc_pick_check.py 에 발견성·하위행 토글 8항목 추가 → 테스트 59/59 · 운영 53/53 (운영은 쓰기 항목 skip). 회귀 = _deposit_mark_check 운영 12/12. 사이트맵 그룹8·페이지54·미반영 0. 커밋 = master 1f3954a → deploy-live efeab22(1파일 선별 포워드).

⏳페페 = 운영 육안 1회 — 견적서 관리 → 검색필터 「추가건 있는 건만」 체크 → ▶ 추가 N 클릭 → 하위행 입금여부 버튼 클릭.

🆕 NOW (2026-08-20) — 월마감 견적 담기(추가건 매핑) + 견적목록 추가건 폴딩 + 자동수집=미입금 ✅운영배포 완료

[페페] 「월마감 매핑 기능이 필요하다. 항목추가시 견적서 목록 기준 현장명 검색 및 선택. 이때 추가건도 지정 선택이 되어야 하고 같은 본건 현장 기준으로 한 행으로 묶는다. 추가건은 추가1,2번호에 상관없이 선택된 항목을 본건컬럼 뛰어넘고 추가건 첫번째부터 순서대로 들어가게. 필요사항 그릴링. 운영 배포」

그릴링 6배치 · 페페 확정 13건 = 검색범위 = 거래처 한정 + 「전체」 해제 / 기간 없음 최신 50 / 모달 표 + 추가건 하위행 / 묶음키 = 본견적 estimate_no / 중복은 기존 행에 병합 / 추가칸 순서 = 견적번호 오름차순 / 추가건 번호 = add_amounts 확장 [{no,amt}] / 본건 미선택 행의 매핑 = 부모 본견적 번호 / 검증 = 담은 것 합(확정금액은 검증 무관 — 네고 수기값) / 「행 추가」 유지 + 「견적 담기」 신설 / 자동수집 = 미입금만 / 목록 폴딩 = ▶ 하위 요약행 + 추가건 상태 별도 / 소급연결 66행은 범위 밖 / 배포 = 한 세션 전부 · 운영 1회.

🔴착수 전 페페 지시 = 「6월까지 견적서는 모두 마감처리」 — 자동수집 혼선 제거용. is_deposit '0'→'2', 견적일(없으면 등록일) ≤ 2026-06-30, 기존 입금('1') 5건은 제외. 운영 609건 · 테스트 659건 적용, 롤백용 번호목록 백업 = /home/ubuntu/pfs-backup/is_deposit_{prod,test}_*.json. 결과 = 미입금 본견적 608 → 11건.

🔑근본 문제였던 것 = 마감 항목이 견적서와 반쪽만 붙어 있었다 — 운영 78행 중 estimate_no 12행뿐이고 (1~6월 수기행은 현장만) 추가건은 금액 배열이라 번호가 아예 없었다. 그래서 ①검증 배지가 무엇과 대조하는지 불분명 ②추가건 입금여부를 파생할 근거 없음 ③배지가 링크도 아님. → add_amounts 를 [{"no","amt"}] 로 확장한 게 이 기능 전체의 전제. 운영 DDL 0(TEXT 컬럼 그대로, 숫자배열 하위호환).

• 담기 모달(estimate_monthly_close.html + GET /api/monthly-close/estimate-search) = 견적서 목록과 같은 기준 (본견적·보관 제외) 현장명·업체명 검색 + 본건 아래 추가건 들여쓰기 체크. 「미입금만」·「전체 업체」·「전부 선택」. 담기 = 본견적 1건 = 1행(있으면 병합·중복번호 무시), 추가건은 견적번호 오름차순으로 추가금액 1번 칸부터, 본건 미체크면 본건금액 0 + 매핑은 부모 번호. 금액은 자동수집과 같은 서비스 함수(넥서스 시공비 분리).
• 검증 배지 = 담은 견적 합 vs 합계 · 견적 #711 +6 ⚠(⚠=미담김 있음) · 클릭 시 견적서 새 탭. ⚠레거시(번호 없는) 행은 JSON_CONTAINS_PATH 로 갈라 옛 기준으로 폴백 — 안 그러면 배포만으로 전부 빨강. 기존 7월 마감 12행 중 자동수집이 만든 2행은 번호를 정확 복원(개수·금액 전부 일치할 때만, add_amounts_*.json 백업).
• 견적목록 폴딩(estimate_list_v2.html) = 추가건 있는 본건에 ▶(운영 5건). 펼치면 견적명·견적일·금액·입금배지·수정. 추가건 배지 = 본건과 같은 depositBtnHtml — 수동은 그 행 is_deposit, 파생은 마감행 add_amounts 안 번호+확정금액.
• 자동수집 = 같은 모달을 「미입금만」 켠 채로 여는 것. 구 /candidates 제거(404).

검증 = 신설 scripts/_mc_pick_check.py 배포전 7 FAIL → 테스트 50/50 → 운영 46/46(운영은 저장 왕복 제외). 회귀 = _deposit_mark_check 테스트 17/17·운영 12/12 · _monthly_close_ui_check 테스트·운영 각 19/19 · 엑셀 생성 테스트·운영 각 4/4(추가금액1..N 컬럼 유지) · 신규 SQL 6/6(운영 직접 실행) · 운영 배포 파일 4개 해시가 테스트와 완전 일치 · 사이트맵 그룹8·페이지54·미반영 0. 커밋 = master c65e484·b9bd8bd → deploy-live 75fd745(7파일 선별 포워드).

⏳페페 = 운영 육안 1회 — 견적>월마감 → 마감 골라 「견적 담기」(현장명 검색·추가건 체크·담기) / 「견적 자동수집」이 미입금 켜진 모달로 열리는지 / 견적서 관리 목록의 ▶ 펼침. ⏳남은 것 = 1~6월 수기행 66건 견적 소급 연결(범위 밖으로 뺀 건, 이제 담기 모달로 한 달씩 가능). → projects/pfs/rules.md 🆕 신규 5줄

🔎 조사 (2026-08-19 · 6차) — 월마감 항목 ↔ 견적서 매핑 실태 (코드 변경 없음)

[페페] 질문 = 「월마감 지정된 현장별 견적이 실제 견적서와 매핑은 안 되나? 검증에 적힌 견적서 번호가 다야?」

결론 = 매핑 자체는 있다(DB 컬럼 2개). 다만 ①실데이터 대부분이 안 붙어 있고 ②추가견적 번호는 아예 저장 안 되고 ③검증 배지는 링크가 아니다.

• 링크 컬럼 = monthly_close_item.estimate_no(본견적 FK) + field_no(현장 FK). 검증 배지 = 그 estimate_no 표시 + select_items 가 계산한 estimate_total(본견적 + 자식견적 합)과 행 합계를 대조해 초록/빨강.
• 🔴운영 실측(읽기전용 프로브) = 항목 78행 중 estimate_no 12행(전부 실재, dangling 0) · field_no 75행 · 배지 없음 66 / 초록 7 / 빨강 5. 1~6월 수기 시딩분은 견적 링크 0, 7월 자동수집분(넥서스9·넵스2·에넥스2)만 견적에 붙어 있다 → 입금여부 판정이 「견적번호 우선 + 현장 폴백」인 이유가 이 분포다.
• 🔴추가견적은 번호가 없다 — add_amounts 가 금액 JSON 배열([912000,1206000,…])뿐이라 행 하나에 남는 견적번호는 본견적 1개. 예 = item 140 GS 오산 양산 견적 #711 + 추가 6건(자식견적도 6건 실재하지만 번호는 미보존).
• 배지는 <span class="badge"> 텍스트 — 견적서로 가는 링크 없음(클릭 불가).

개선 후보(미착수·페페 결정 대기) = ①배지를 /estimate/modify-v2/<no> 링크로(1줄) ②추가견적 번호 보존 (add_amounts 를 [{no,amt}] 로 or 별도 컬럼) ③1~6월 수기행 견적 소급 연결(현장+금액 대조).

🆕 NOW (2026-08-19 · 5차) — 입금여부 「마감」 수동 선택 + QA 도구 버튼 정리 ✅운영배포 완료

[페페] QA(qa_helper, /estimate/modify-v2/730) = 「마감 버튼도 추가해줘. 월마감 초안 정리하면서 마감 표시를 코디가 생성했는데 내가 선택할 수 있는 항목은 없다. 운영배포」 + 같은 세션 추가지시 = 「qahelper 에서 채티용 복사 버튼 이름을 그냥 「복사」로, 텍스트 보기 버튼은 삭제」.

배포 = master 08e0944 → deploy-live 97e596a(4파일 선별 포워드, --detach 워크트리). DDL 0 · DB 변경 0. ✅페페 운영 육안 확인 완료(26.8.19) — 견적 수정화면 마감 선택 확인. 이 건 종결.

• 🔑직전(4차 이전) 작업이 만든 반쪽 상태를 메운 것 — 26.8.19 3차에서 list-v2 입금여부를 월마감 초안 기준 3상태(입금/마감/미입금)로 바꿨는데, 「마감」은 파생값으로만 존재해 사람이 고를 수단이 없었다. → is_deposit 을 3상태로 승격 = 1 입금 / 2 마감 / 0 미입금(=자동 판정에 맡김). 컬럼이 이미 char(1) 이라 DDL 없음(rds-map 실측).
• 손댄 4곳 = ①견적 폼(estimate_regist_v2.html, regist·modify 공용) 라디오에 「마감」 ②list_v2 depositBtnHtml 이 '2' 를 최우선 마감으로(마감 초안 유무와 무관) ③토글을 0→1→2→0 순환(안 하면 폼에서 고른 마감을 목록에서 한 번 클릭하는 순간 잃는다) ④set_deposit 이 '2' 를 통과시킨다(종전엔 '1' else '0' 으로 뭉갰다).
• qa_helper = 버튼 라벨 「채티용 복사」→「복사」, 「텍스트 보기」 버튼 삭제. showExportDialog 함수는 남긴다 — 클립보드 API 실패 시 폴백이라 지우면 그 경우 QA 항목이 통째로 날아간다.
• 검증 = scripts/_deposit_mark_check.py(기존 스크립트 확장 · scripts/_* 는 gitignore 라 미추적). 배포전 테스트 4 FAIL → 테스트 17 ALL PASS → 운영 12 ALL PASS. 테스트는 토글 3상태 왕복 + 새로고침 후 data-deposit=2 확인(DB 영속), 운영은 읽기전용(폼 라디오만). 검증 중 켠 테스트 견적 721·797 의 is_deposit 은 '0' 으로 원복(SSM). 사이트맵 = 그룹8·페이지54·미반영 2 — 미반영 2건은 내 작업이 아니라 아래 4차(통합현장, master 전용)다.
• ⚠같은 리포에서 다른 세션이 동시에 작업 중이었다(4차 통합현장). 검증 도중 origin/master 가 08e0944 → a784e25 로 바뀌고 내 워킹트리의 미커밋 WIP 이 사라졌다. 파일 지정 add + 선별 포워드라 서로 안 섞였다 (deploy-live 커밋 diff = 내 4파일 19+/9−). git add -A 였으면 남의 미완성 코드가 운영에 갔다.

🆕 NOW (2026-08-19 · 4차) — 통합현장 탭 재설계 = 코디가 정리한 「통합 게시글」 ✅1차 운영배포 완료(별도 세션 전담 · 페페 지시 26.8.19)

✅1차 끝났다(운영배포까지). 담당 세션이 master a784e25~93a748e · deploy-live f10e839~7d5e2c7 로 반영 완료. 이 건 파일(worklog dao/service/controller · kakao_board dao/service · field_worklog.html)은 2차 작업도 같은 세션이 잡는다 — 같은 워크트리 동시편집이면 서로 덮어쓴다.

[페페 지시 · QA 코멘트 /field/worklog #wl-tab-fusion] "카톡·통화 2가지를 각각 보는 게 아니라 현장 기준으로 통합한다. 단순 그룹분류가 아니라 코디가 내용을 수집·정리해 카톡 게시글처럼 정리한다. 통화내용도 현장 관련이면 출처가 통화임을 표기해 게시글에 통합한다. 최종적으로 카톡 게시글로 모든 정보가 통합되어 거래처와 포인 직원이 한눈에 공유하게 하는 것." → 그릴링 5배치 15문 진행, 아래 전부 페페 확정.

착수 전 확인한 구조(코드 실측)

• 3탭은 지금 읽기전용 나열이다 — GET /api/worklog/fusion(worklog_service.get_worklog_fusion)이 worklog 이번주분 + kakao_board 미러를 현장카드로 묶기만 한다. 정리·요약·문장생성 없음.
• 게시글 원본은 PFS 가 아니다 — 로컬 PC poin-agent/<방>/board.md. PFS 는 미러(kakao_board) + 명령 큐(kakao_board_op). 큐 액션 = hide/restore/edit/delete 4개뿐 — 「행 추가」가 없다(신설 대상).
• board.md 가 바뀌면 sgc/watcher.py(30초 루프)가 해시로 감지해 자동으로 카톡방 게시글 수정 + 공지 고정. = 게시글에 줄 하나 넣으면 그대로 거래처가 본다.
• 게시글 방 = board_edit:true 7방, 현장방은 4개(SGC 용두동·금강 부산에코·에넥스 대우 용인·롯데 화성 향남). PFS 현장 수천 건 대부분은 카톡방 자체가 없다. 섹션 구성도 방마다 다르다(「확인중·요청」 4방 / 금강은 「확인중·대기」 / 에넥스는 없음).
• 통화 전사본 = 타임스탬프·화자 없는 한 덩어리 평문(pipeline_worker.py:83 이 seg.start/end 를 버린다). 녹음은 모노 1채널(ffprobe 실측)이라 채널로 화자를 못 가른다.
• 원본 m4a 는 전사·적재 후 삭제한다(purge 3,005건, 잔존 17개) → 과거 1,111건은 재전사 불가 = 시각·화자 소급 복원 불가.
• 전사본 1,111개 · 총 1.29MB(평균 1.2KB) — DB 부담 0. 단 지금은 로컬 PC 에만 있다(PFS 로 올리는 경로 없음).
• 연결키는 이미 있다 — worklog.note = "audio=<파일명> / number=<번호>"(pipeline_worker.py:218).
• 통화량 = 26-06 404건 · 07 643건 · 08 63건(8/11까지). 월 400~650건 ≈ 월 20시간.
• 통화 파이프라인은 하루 1회 02:00(PFS-Night-Worklog). 카톡 board sync 는 1분, watcher 는 30초.
• 통화 수집은 폰 앱이 PC 로 push(talklog_server.py 8792 /calls·/upload-audio). 앱에 TriggerReceiver 가 있어 밖에서 브로드캐스트로 깨울 수 있다. 지금 부르는 건 NightRunner(밤)·MainActivity(수동)뿐 — 통화종료 감지는 없다.

페페 확정 15건 (그릴링)

1. 착지점 = 자동 즉시 반영 프로세스로 간다. 단 통화내용은 PFS 에 먼저 뜨고 페페가 확인 후 카톡 게시글 반영 여부를 결정한다. 현장·거래처에 따라 사전 전체승인으로 돌릴 수 있다. 게시 후 오탐은 PFS 화면에서 사용자가 직접 수정해 보완한다.
2. 작성자에 코디 언급만 빼면 항목 내용 자체엔 큰 위험이 없다(페페 판단).
3. 정리 문장 생성 주체 = 코디(LLM) 배치.
4. 게시글에 나가는 통화 항목 = 코디 재작성 1줄 + 출처 태그. 원문·화자 이름은 게시글에 안 나간다. is_private=1 은 원천 제외.
5. PFS 에서 통화 항목을 클릭하면 그 통화 전문 전사를 보여준다 — 시간·화자별로 정리하고 그 항목의 근거 구문을 형광 강조한다.
6. 전사 수준 = 기존 1,111건은 평문+구문강조만. 신규 통화부터 화자분리를 한다.
7. 신규 전사 엔진 = Groq(whisper-large-v3-turbo) 전사 + sherpa-onnx 로컬 화자분리(pyannote-segmentation-3.0 ONNX 6.6MB). 둘 다 무료·무제한. Groq 키는 .secrets/.env 에 이미 있다.
8. 화자 라벨 = 코디가 맥락으로 판정. 힌트 = 「나」 = 포인 신동승 차장, 상대는 보통 나를 「신차장·신동승 차장·차장님」이라 부른다. ⛔전사·산출물에 「페페」라는 말은 절대 쓰지 않는다.
9. 전사본 PFS 업로드 = 전량(worklog 항목이 생긴 통화만). 단 1차는 진행중 현장분 먼저 → 보고, 그 뒤 최근 일자 → 과거 일자 순으로 나머지 → 완료 보고.
10. 승인 UI = 통합현장 탭 안(행별 ✔게시/✖버림/✎수정 + 방별 「사전 전체승인」 스위치).
11. 초안 생성 주기 = 30분마다(카톡 게시글 주기에 맞춘다). 이에 맞춰 폰 통화수집도 통화 종료 즉시로 당긴다.
12. 중복 = 코디가 현재 게시글 전문까지 읽고 판단. 이미 있으면 초안에서 빼고, 진행이 바뀐 건은 새 행이 아니라 기존 행 수정 제안으로 낸다(edit 명령은 이미 있다).
13. 게시글 섹션 = 코디가 그 방의 기존 섹션 목록을 보고 고른다. 맞는 게 없으면 「확인중 · 요청」 신설. 초안에 섹션명을 적어 승인 전에 보인다.
14. 카톡방 없는 현장 = 초안은 똑같이 만들고 PFS 전용으로 본다(게시 버튼 자리에 「카톡방 없음」).
15. 즉시수집 구현 = PC 가 주기적으로 adb 트리거(앱 수정·APK 재설치 0). 범위 = 단계 분할, 완료 경계 = 바로 운영배포까지.

✅ 1차 결과 (운영배포 완료)

배포 = pfs master a784e25·ee39821·eb3aa2e·ef38616·4eb6cc3·93a748e → deploy-live f10e839·73d8fbd·4ed5557·7d5e2c7(6파일 선별 포워드, 별도 워크트리 — 다른 세션이 같은 리포를 쓰고 있었다). poin-agent c818a8a · talklog 1a78d82. DDL 선행 없음 — 테이블 2개는 첫 호출에 자가생성.

• 테이블 2개 신설(기존 ALTER 0) = fusion_row(코디 정리본 행 + 카톡 반영 상태) · call_transcript(전사 평문, audio 가 PK).
• API 4개 = POST worklog/fusion/post(현장 통째 교체) · POST worklog/fusion/decide(대기/게시/제외) · GET worklog/transcript/<no> · GET|POST worklog/transcript/sync. 기존 GET worklog/fusion 에 post·room_name·cnt_wait 추가.
• 게시글 「행 추가(add)」를 양쪽에 신설 = PFS kakao_board_op.action='add'(row_id 칸이 섹션명이다 — 고칠 행이 없다) + 데몬 board_rows.add. restore 와 공용 _append_to_section 으로 묶어 중복 판정을 한 곳에 뒀다. 섹션 대조는 「■」 유무를 무시한다(_sec_name) — 안 맞추면 같은 이름 섹션이 하나 더 생긴다.
• 🔑핵심 불변식 = 30분마다 다시 만들어도 사람 결정이 살아남는다. 지문 fp = 섹션 + 첫 줄(구두점·공백·「※수정」 표기 제거). upsert 는 kakao_state·decide_* 를 건드리지 않는다. 검증에서 이 왕복(제외 → 재생성 → 제외 유지)을 실제로 돌린다.
• 검증 = 신설 scripts/_fusion_post_check.py {--logic|test|prod}(미추적 — scripts/_* 는 gitignore). 배포 전 테스트 9 FAIL → 테스트 33 ALL PASS(쓰기 왕복 포함) → 운영 17 ALL PASS(읽기 전용). 기존 회귀 _worklog_fusion_check.py 테스트·운영 각 38 ALL PASS. 콘솔 오류 0. 사이트맵 그룹8·페이지54·미반영 0. ⚠운영에서는 쓰기를 안 돈다 — 「게시」가 실제 거래처 단톡방에 들어간다. 쓰기 왕복은 테스트 전용 방으로만.
• 전사본 업로드 완료 = 진행중 현장 관련 20건(1차 보고분) → 나머지 전량, 운영 call_transcript 1,110건.
• 정리본 생성 실행 = 진행중 10현장 중 재료가 있는 2곳. 롯데 화성 향남 2행 생성(둘 다 「(통화 확인)」 출처 표기), 대우 용인 0행(게시글에 이미 있는 내용이라 안 냄 = 규칙 2 정상 동작).

🔴 잡은 함정 4개 (전부 실측)

1. _ensure_fusion() 이 자기 자신을 불렀다 — DDL 1회 실행으로 바꾸며 일괄치환이 함수 안쪽 호출까지 먹었다. 증상 = 통합현장 API 500 "maximum recursion depth exceeded". 일괄치환 뒤엔 그 함수 본문을 눈으로 본다.
2. flask_restplus 라우트 변수는 메서드 인자로 받아야 한다 — def get(self) 로 두면 500 get() got an unexpected keyword argument 'worklog_no'. 테스트엔 통화 항목이 0건이라 운영에서 처음 드러났다.
3. 🔑근거(excerpt)는 전사문의 인용이 아니라 「요약」이다 — 통째로 찾는 형광은 실측 매치 0%. → 구두점·공백을 뺀 글자열끼리 최장 공통 조각(6자 이상)을 앞에서부터 훑는 방식으로 교체 → 운영 12건 실측 12건 전부 형광 · 근거 글자의 91% 덮음. ⚠중간에 파이썬 측정이 SKIP + "*".join(...) 연산자 우선순위 때문에 「각 글자 0회 이상」 정규식이 돼 92%라는 가짜 합격을 냈다. 매치율을 잴 땐 만들어진 정규식을 한 건 찍어서 눈으로 본다.
4. 게시 버튼 판단은 카드가 아니라 「행이 겨냥한 방」으로 한다 — 방 연결이 나중에 바뀌면 둘이 어긋나고, 버튼은 실제로 나갈 곳을 따라야 한다.

🔴 지금 이 기능의 실질 병목 — 카톡 게시글 방 3개가 「현장 미연결」

운영 실측 = 게시글 방 5개 중 자재방 2개(아이비젼·오엠씨)는 현장이 없는 게 맞고, 나머지 3개가 현장이 있는데도 미연결이다. → 그 방들의 게시글이 현장 카드에 안 붙어 코디가 정리할 재료가 없다(배치가 8현장을 그냥 건너뛴다). 근본원인 = 동명 현장이 여럿이라 _match_room_field 의 「유일 승자」 게이트에 걸린다. 실측 = 「SGC 광주 용두동」 3건(본건 MH 1 + AS 2 · #2129/#2151/#2164) · 「금강 부산 에코」 2건 · 「대우 용인」 2건. ⏳페페 판단 필요 — 카톡방을 본건에 붙일지 AS 에 붙일지는 업무 판단이다(진행중으로 뜨는 건 AS 쪽 #2164 인데 게시글의 주인은 보통 본건이다). 정해주면 kakao_board.field_no 직접 연결 또는 매칭 규칙에 그 기준을 넣는다.

✅ 1-2차 추가 (같은 날, 페페 지시) — 본건 우선 규칙 + 수동 연결 + 게시 승인

[페페] "카톡방은 기본적으로 본건에 붙이는 것을 규칙으로 한다. 이후에도 규칙 해당이 없어 미연결 되는 것은 현장연결 버튼을 만들어서 내가 직접 연결해주겠다." + "통화 내용 확인 여부에 제외 버튼만 있고 승인 버튼이 없다."

배포 = master 61a149a·9010333 → deploy-live efc046e·f362fe0.

• ① 본건 우선 — _match_room_field 동점 tie-break 에 field_div != '60'(AS 제외)을 active 판정보다 먼저 넣었다. 실측 효과 = 미연결 방 5 → 3(SGC 용두동·금강 부산에코가 본건 #2129·#2142 에 붙었다). 남은 3 = 자재방 2(현장 없음이 맞다) + 롯데 향남. 🔎롯데 향남이 남은 이유는 동점이 아니라 점수 미달이다 — 방 이름 롯데건설 화성 향남(포인) vs 현장 롯데 화성 향남 은 부분일치가 안 되고(「건설」이 끼어 있다) 토큰 점수 64점(< 80). 이건 규칙으로 못 붙인다 = 수동 연결 대상.
• ② 방↔현장 수동 연결 = POST worklog/fusion/link {room_name, field_no}. 미연결 방 카드의 🔗 현장 연결 + 이미 붙은 방도 카드 머리의 🔗 버튼으로 옮긴다(현장 후보에 AS/MH 태그·#번호·상차일이 뜬다). 기존 현장 검색 UI(loadFieldsForLink·wlFieldRowHtml)를 그대로 재사용했다. field_no=null 이면 연결 해제. 🔑데몬 미러 upsert 는 field_no 컬럼을 안 건드리므로 이 연결은 30초 동기화에도 살아남는다.
• ③ 카톡방이 없어도 「📤 게시 승인」 — 상태에 승인 추가(대기/승인/반영/제외). 방이 없으면 거절하지 않고 승인만 걸어 두고, 방이 연결되는 순간 그 현장의 승인분이 그대로 게시글 명령 큐로 나간다(link_board_room 이 _publish_row 를 돈다). 게시글로 나가는 문은 _publish_row 하나뿐이다.
• 🔴본건 규칙의 부작용을 그 자리에서 잡았다 — 「본건은 완료 · 진행중인 건 AS」인 현장(SGC·금강)에서 방이 완료 현장에 붙자 카드가 아예 안 만들어져 게시글이 화면에서 사라졌다(미연결일 땐 하단 그룹에라도 보였다 = 회귀). → 게시글 방이 붙어 있으면 완료 현장이어도 카드는 만든다(내용 표시 규칙 「완료=미출고·신규만」은 그대로). 카드가 있어야 🔗 버튼으로 옮길 수 있다. 카드 room_name 도 거르기 전 방 목록에서 뽑는다.
• 검증 = _fusion_post_check.py 테스트 42 ALL PASS(방 없이 승인 → 방 연결 → 자동 게시 → 반영행 잠금 → 연결 해제 원상복구 전 구간 왕복) · 운영 17 ALL PASS(읽기 전용) · 기존 회귀 38 ALL PASS · 콘솔 오류 0 · 사이트맵 그룹8·페이지54·미반영 0. 운영 육안 = 게시 승인 2 · 카톡 게시 1 · 현장 연결 3 · 방 이동 3 버튼 렌더, 연결 박스 검색 「용두동」 → AS #2164·AS #2151·MH #2129.
• ⏳페페 = 운영에서 판단 2개 ①롯데건설 화성 향남(포인) 방을 #2134 에 🔗 연결 ②SGC·금강 게시글을 완료된 본건(#2129·#2142)에 둘지, 진행중 AS(#2164·#2163)로 옮길지 — 카드 머리 🔗 버튼으로 바꾼다.

✅ 1-3차 (같은 날) — 완료 현장도 연결된 AS 가 진행중이면 살린다

[페페] "완료 현장도 AS가 발생 및 본건과 연결처리 되어 있으면 지금 처리한 것처럼 방 활성화하기." + 그릴링 확인. 배포 = master 628a15f → deploy-live af128b5.

• 그릴링 3문 확정 = ①활성화 범위 = 진행중처럼 전부(게시글 전문 + 코디 정리 대상), 단 출고완료분은 접힘 그룹 ②판정 = field.parent_field_no + 그 AS 가 진행중('20') ③본건 카드에 AS 진행중 배지.
• 🔑충돌은 한 곳뿐이었다 = 26.8.7 「완료 현장은 미출고·이번주 신규만」(filtered). 살린 현장만 그 규칙을 면제한다 (revived = (st=='30' and AS 진행중 있음) → filtered = (st=='30' and not revived)). 나머지 규칙(본건 우선 매칭·방 있으면 카드 생성)은 같은 방향이라 충돌 없다.
• 실측 근거 = AS↔본건 연결은 field.parent_field_no 에 진짜 있다(#2151·#2164→2129 · #2163→2142). 단 AS 1,040건 중 parent 가 있는 건 30건(2.9%), 진행중 AS 는 4건 → 규칙 사정거리가 좁다. 「완료 본건인데 동명 AS 진행중」 = 2건(SGC·금강) = 정확히 이 케이스. AS 가 끝나면 자연히 다시 접힌다(상태 플래그가 아니라 계산값).
• 살린 현장은 정렬도 진행중 급으로 올린다(맨 아래면 살린 의미가 없다). 상태 라벨은 「완료」 그대로 두고 배지·안내문으로 구분.
• 게시글 출고 완료분은 접힘 그룹(fs-done) — 전 카드 공통. 살린 현장은 게시글이 통째로 길어진다.
• 검증 = 운영 실측 #2142 게시글 34행 · #2129 21행이 되살아났다(직전 0행). AS 배지 2 · 살림 안내문 2 · 출고완료 「8건(숨김)」 접힘 → 펼치면 8행 · 콘솔 오류 0. _fusion_post_check 테스트 45 · 운영 20 ALL PASS, 기존 회귀 38 ALL PASS, 사이트맵 그룹8·페이지54·미반영 0. ⚠검증 중 항상 참이 되는 가짜 체크를 하나 넣었다가 잡았다(sites.index(x) < len(...)+len(sites)) → 「살린 현장이 안 살린 완료현장보다 앞」이라는 실제 조건으로 교체.

✅ 3차 (2026-08-21) — 수시(5분)·주기(30분) 수집 상시화 + 통화 143건 회수 + 현장별 반영 완료

2차 ⏳「페페가 폰을 꽂아 줘야 통화가 들어온다」가 해소(무선 adb 접속포트 자동탐색). 통화 143건 적재 → autolink 27건 연결 → 정리본 19행. PFS 제품코드 변경 0 → deploy-live 없음(데이터 반영이 곧 운영 반영). 검증 = 운영 통합현장 탭 렌더·콘솔 0. 원문·미결(무선adb Wi-Fi 종속 / 분류 현장명 품질) → projects/talklog/handoff.md NOW 2026-08-21 · projects/talklog/rules.md 🆕.

✅ 2차 (2026-08-19) — Groq 전사 + 화자분리 · adb 즉시수집 · 30분 배치 완료

커밋 = talklog 7202a6c. PFS 제품코드 변경 0 → 운영배포 없음(1차가 만든 call_transcript.segs API·화면을 그대로 채우는 작업이라 서버 쪽에 고칠 게 없다). 사이트맵 그룹8·페이지54·미반영 2 = 전부 남의 세션 것(AL발주서).

① 착수 전 실측 벤치 (페페 지시 — 실통화 5건 · server/_bench_stt_diar.py)

• 🔑sherpa 기본 파이프라인은 안 쓴다 — 그쪽은 자기 segmentation(10초 창) 경계로 임베딩을 뽑아 76.2%. Groq 이 준 발화 경계로 잘라 발화당 임베딩 1개를 뽑으면 88.0%. 코사인 2-means, 중심점은 1초 이상 발화로만.
• 임베딩 모델 = 3dspeaker campplus(zh_en). wespeaker voxceleb CAM++ 는 같은 조건에서 64.7% 로 확연히 나쁘다.
• ⛔고역 에너지로 「내 마이크 vs 통신망」을 가르는 건 안 된다(62.2% = 다수결 수준) — 녹음이 통화 스트림이라 양쪽 다 전화 대역이다. 모노 1채널이라 채널 분리도 불가.
• 편차 = 통화별 66.7%(월드산업 · 발화가 1~2초로 잘게 쪼개진 건) ~ 95.7%. 짧은 맞장구가 약점. 파라미터 스윕(가장자리 트림·중심점 최소길이·교대 사전확률)은 전부 ±1pp 라 더 안 만졌다.

② 만든 것

• server/stt_groq.py 신설 = transcribe(m4a) → (평문, [{s,e,spk,text}]). Groq 실패는 예외로 올려 기존 faster-whisper medium 으로 폴백(원본 m4a 는 적재 후 지워지므로 여기서 놓치면 영영 못 살린다). 화자분리만 실패하면 삼키고 평문·시각은 살린다.
• pipeline_worker = 전사 1순위를 Groq 로. segs 는 data/calls/transcripts_segs/<audio>.json. 🔑「나/상대」 라벨은 분류 LLM 이 고른 me 로 덮어쓴다 — 분류가 어차피 전사문을 다 읽으므로 API 왕복 증가 0. _classify_system.txt 에 me 필드 규정 추가(단서 = 상대는 나를 「신차장·차장님」이라 부른다).
• fusion_post = segs 를 transcript/sync 에 실어 올린다(서버 upsert 가 COALESCE 라 옛 통화 덮어쓰기 없음).
• 🔴현장별 「입력 지문」 변화 게이트 신설(data/_fusion_state.json) — 30분마다 도는데 이게 없으면 ①재료가 그대로인데 모델을 계속 부르고 ②모델이 같은 사실을 조금 다르게 써서 fp 가 바뀌면 사람이 이미 「제외」한 행이 새 「대기」 행으로 되살아난다(put_fusion_post 는 새 판에 없는 행을 지운다). 실측 = 1회차 14초·모델 2회 → 2회차 2초·모델 0회(unchanged: 2). --force 로 무시 가능.
• server/run_fusion30.py + .vbs = ①수집서버(8792) 자가기동 ②adb 역터널·즉시수집 트리거 ③정리본 생성. 예약작업 PFS-Fusion-30m(30분 주기, wscript.exe 숨김 실행). 강제실행 실측 rc=0.

③ 🔴 이 기능의 진짜 병목을 찾았다 — 통화 수집이 8/12부터 멈춰 있다

• 수집서버 talklog_server(8792) 가 죽어 있었다. 야간 파이프라인(PFS-Night-Worklog 02:00)은 매일 정상 실행됐지만 새 파일이 0건이라 조용히 아무것도 안 했다 — 실패 로그도 안 남는다. 30분 배치가 이제 자가기동한다.
• 녹음 폰이 PC 를 못 찾는다. 앱 후보(Config.FALLBACKS)는 Tailscale 100.108.234.45 와 192.168.45.2 뿐인데, 폰엔 Tailscale 이 없고 이 PC 의 실제 LAN IP 는 192.168.45.48 이다 → 둘 다 실패(server_unreachable). → 배치가 adb reverse tcp:8792 로 역터널을 깔고 setserver http://127.0.0.1:8792 를 넣는다(앱 수정 0).
• ⚠지금 USB 로 붙어 있는 폰은 poin-agent 용 노트20(SM-N981N)이고 거기엔 talklog 앱이 없다. am broadcast 는 받는 앱이 없어도 result=0 으로 성공한다 = 엉뚱한 폰을 두드리며 「트리거 OK」로 찍힌다. → 배치가 pm list packages 로 앱이 깔린 폰을 골라서 두드리고, 없으면 그렇다고 로그에 적는다. 녹음 폰(갤럭시 S25 Edge 100.106.4.88)은 Tailscale 6일째 offline.

④ 검증

• 신설 talklog/server/_stt_check.py — 로직 11 PASS(라벨 뒤집기·미배정 보존·별칭 금지·파싱) · 실전사+라벨+PFS 왕복 19 PASS(Groq 1.9초 → segs 28개 → 분류 me → 나/상대 → 테스트 PFS 업로드 → 뷰어 API 로 다시 읽어 28개 대조 → segs 없이 재업로드해도 보존 → 원상복구).
• 🔑테스트 PFS 에 통화 항목이 0건이라 전사 뷰어 경로가 통째로 미검증이었다(1차에서 라우트 버그가 운영에서 처음 터진 이유). pfs/scripts/_stt_seed_test.py 로 테스트 RDS 에 통화 항목을 심고 검증 후 지웠다.
• 육안(테스트 PFS) = 전사 모달에 00:00 나 / 00:01 상대 … 28행 + 근거 형광 1건 렌더. 콘솔 오류 0.
• 회귀 = _fusion_post_check.py --logic·test·prod 전부 ALL PASS · _worklog_fusion_check.py test·prod ALL PASS. ⚠운영 회귀 2건이 FAIL 로 떠 있던 걸 잡았다 — 「완료 카드는 전부 filtered」라는 검사가 1-3차의 살린 현장(revived) 규칙과 정면으로 어긋난다(#2142·#2129). 제품이 아니라 검사를 규칙에 맞췄다 (안 살린 완료 / 살린 완료를 갈라서 본다). 내 변경은 PFS 제품코드를 안 건드렸다.

⑤ ⏳ 남은 것

• 페페 몫 = ①녹음 폰(S25 Edge)을 이 PC 에 USB 로 꽂거나 Tailscale 을 켜 준다 — 그래야 통화가 다시 들어온다. 꽂히면 30분 배치가 알아서 역터널·수집한다. ②롯데건설 화성 향남(포인) 방 🔗 연결(규칙 64점이라 자동 불가) ③SGC·금강 게시글을 완료 본건(#2129·#2142)에 둘지 진행중 AS(#2164·#2163)로 옮길지.
• (선택·미착수) 방별 「사전 전체승인」 스위치 — 지금은 행마다 사람이 누른다.
• 신규 통화가 실제로 들어오면 화자 라벨 정확도를 운영 데이터로 재측정한다(지금 88%는 8월 통화 4건 기준). 지금은 배치를 손으로 돌린다(PYTHONUTF8=1 python C:/dev/talklog/server/fusion_post.py --live --active-only). 방별 「사전 전체승인」 스위치도 2차 — 1차는 행마다 사람이 누른다.

🆕 NOW (2026-08-19 · 3차) — 견적 v2 그룹 소계 실시간 갱신 + 출력 담당자칸 직책 ✅운영배포 완료

[페페] QA(qa_helper, /estimate/modify-v2/749) 2건 = ①「310,000원 소계가 실제 금액과 잘 안 맞는다. 검토 후 수정보완. 운영배포. 749 견적 기준」 ②「견적서 엑셀파일에서 담당자 이름만 나오고 직책이 같이 안 나온다. 기존엔 「은지호 팀장」식으로 이름+띄어쓰기+직책이었다. 이것도 수정 후 운영배포」.

배포 = master 4114abf → deploy-live 7aab4ad(estimate_regist_v2.js + estimate_dao.py 2파일 포워드, --detach 워크트리). DB 변경 0 · 749 데이터 무변경(검증 후 재조회로 확인).

• 🔑①의 근본원인 = 부분 갱신 누락. 749 는 항목 4개 합 420,000(80,000+200,000+80,000+60,000)인데 소계는 310,000 으로 멈춰 있었다. recalcDetailRow() 가 행 최종합계 + 종합합계만 갱신하고 그룹 소계 행은 손대지 않아, 마지막 renderDetailTable() 시점 값이 그대로 남는다. updateGroupSubtotal() 은 이미 있었지만 part_mode 토글 한 경로에서만 호출됐다(그래서 QA 재현에서 part 토글만 유일하게 통과했다). → 호출자 4곳(치수/코너 입력·인라인 편집·단가 자동조회·SUB 재계산)이 전부 지나는 recalcDetailRow 한 곳에서 부르게 통합하고, part_mode 쪽 중복 호출은 제거.
• 🔑②의 근본원인 = SELECT 누락. _compose_manager() 는 참조인물 없으면 현장담당자 이름+직책 폴백인데 select_estimate 가 d.position 을 안 뽑아 pos 가 늘 빈값이었다 → d.position AS position 한 줄 추가. 749 는 참조인물 없음 + 현장담당자 은지호/대표 → 「은지호」 → 「은지호 대표」. 참조인물 보유 인원은 전체 417명 중 33명뿐이라 폴백 경로가 다수다. 엑셀·PDF·HTML 이 _build_common_header 한 곳을 공유해 함께 복구.
• 검증 = 신설 scripts/_est_grouptot_manager_check.py {test|prod} [견적번호](읽기전용 — 저장 버튼 안 누른다). 로드 직후·단가·수량·치수·마진·part 토글 6시점에서 행합 = 그룹소계를 대조하고, print/data 헤더와 실제 다운로드 xlsx 의 A8 셀까지 본다. 운영 배포 전 7 FAIL(단가/수량/치수/마진 4건 + 직책 3건) → 테스트 15 ALL PASS → 운영 15 ALL PASS(749 실측: 420,000→430,000→520,000→700,000→718,000 전부 동기, 엑셀 종합!A8 = "은지호 대표"). 콘솔 에러 0. ⚠테스트 RDS 엔 749 항목이 없어 스크립트가 항목+직책 있는 견적으로 자동 대체한다(테스트는 797 사용).
• 사이트맵 재빌드(배포 후) = 그룹 8 · 페이지 54 · 미반영 0.
• ⏳[페페] 운영 육안 1회 — 749 에서 단가/수량 고쳐 소계가 즉시 따라오는지 · 엑셀 받아 담당자칸 「은지호 대표」.

🆕 NOW (2026-08-19 · 2차) — 견적 list-v2 입금여부 = 월마감 초안 기준 ✅운영배포 완료

[페페] "pfs 견적서 월마감 초안 기준으로 estimate/list-v2 에 입금/미입금 여부 표시 변경해줘. 운영배포 작업."

배포 = master d2940ee → deploy-live 3ed47d7(estimate_dao.py + estimate_list_v2.html 2파일 포워드, --detach 워크트리). DB 변경 0.

• 착수 전 그릴링 3문 → 페페 확정 = ①판정 = 확정금액 있으면 입금 · 마감행만 있으면 「마감」 · 마감 초안에 없으면 미입금(3상태) ②매칭 = 견적번호 우선 + 현장(field_no) 폴백 ③기존 수동 토글(is_deposit)이 '1' 이면 그게 우선(토글 유지).
• 🔑바꾼 이유의 실측 근거 = 수동 토글은 사실상 안 쓰인다 — 운영 견적 640건 중 is_deposit='1' 은 5건(2026년 2건), 마감에 걸린 견적 12건은 전부 '0' 이었다. 반면 마감 초안은 16건·78행이 이미 서 있다.
• 매칭 규칙(마감행 단위) = i.estimate_no = a.estimate_no OR (i.estimate_no IS NULL AND i.field_no = a.field_no). 마감행이 다른 견적을 명시하고 있으면 현장 폴백으로 끌어오지 않는다. 마감 78행 중 75행이 붙는다 (안 붙는 3행 = 반도 부산 EDC · 일레븐 오피스텔 SH · 별도 비용 — 전부 field_no 자체가 없다).
• 서버 = select_estimate_search_list 에 서브쿼리 2개(mc_confirm_cnt·mc_close_ym)만 추가. 마감행이 없으면 mc_close_ym 이 NULL 이라 「마감/미입금」이 이걸로 갈린다(행수 세는 세 번째 서브쿼리는 불필요). ⚠집계는 COUNT·MAX 만 — SUM() 은 Decimal 이 돼 jsonify 500(마감 기능 기존 함정).
• 화면 = 판정이 depositBtnHtml() 한 곳. 색 = 입금 btn-info · 마감 btn-warning · 미입금 btn-danger, 툴팁에 판정 근거(「2026-07 마감 · 확정금액 반영」 / 「2026-07 마감표 포함 · 확정금액 미기재」 / 「수동 입금 표시」). 토글은 그대로 — 끄면 마감 기준 표시로 되돌아간다(버튼을 통째로 다시 그린다. 종전처럼 텍스트만 갈면 「미입금」으로 굳는다).
• 검증 = 신설 scripts/_deposit_mark_check.py {test|prod}. 전 행의 라벨·색·툴팁을 서버 원자료로 재계산해 대조한다. 운영 배포 전 2 FAIL → 테스트 12 ALL PASS(토글 왕복 마감→입금→마감 실검증) → 운영 9 ALL PASS(운영은 쓰기 없이 읽기 전용). 운영 기본 목록 36행 분포 = 입금 13 · 마감 2 · 미입금 21, 전량(627행) 기준 = 입금 16 · 마감 4. 콘솔 에러 0. SQL 단독 검증 = scripts/_deposit_mc_sql_probe.py(SSM).
• ⚠옛 견적에 「마감」이 붙는 건 오류가 아니다 — 넥서스 1~4월 마감표는 미확정 현장을 매달 이월해 반복 기재한다. 실제로 분당파크뷰(견적 565·2022년)·용인 진산마을(594·2023년)이 2026-01~04 마감행에 그대로 살아 있어 「마감」으로 뜬다.
• ⏳[페페] 운영 육안 1회 — 견적서 목록에서 노랑 「마감」 배지와 툴팁 확인. 색/문구 바꾸려면 depositBtnHtml() 한 곳.

🆕 NOW (2026-08-19) — AL발주서 드롭리스트 근본수정 + 현장명 드롭리스트 신설 ✅운영배포 완료

[페페] QA(qa_helper, /field/al-orderpaper 품명칸) = "드롭리스트가 제대로 작동 안된다. 프레임에 갇혀서 조금만 움직여도 모달이 닫히는 현상이 빈번. 가운데 휠도 제대로 작동 안됨. 보이는 높이도 2배로. 수정 후 운영배포." + 추가 = "현재 페이지 다른 드롭박스들도 동일 문제 — 모두 수정보완" + "현장명 드롭리스트를 견적서 현장검색 리스트 기준으로".

배포 = master de0ba09 → deploy-live ec2c87a(al_orderpaper.js + field_al_orderpaper.html 2파일 포워드). DB 변경 0.

• 🔑근본원인 1줄 = window.addEventListener('scroll', closeCombo, true). 캡처라 드롭리스트 자신의 스크롤까지 잡아 휠 한 칸에 닫혔고(=「휠 안 됨」), 그리드 overflow-x 래퍼의 가로 스크롤도 같이 걸렸다(=「조금만 움직여도 닫힘」). → 닫지 말고 따라가게(box.contains(e.target) 면 무시, 나머진 placeCombo() 재배치 + resize).
• 「프레임에 갇힘」 = position:absolute+pageOffset 이라 하단 행에서 목록이 화면 밖으로 잘리던 것 → fixed(뷰포트) + 아래 공간 좁으면 위로 뒤집기 + 남는 공간만큼만 높이 + 좌우 클램프.
• 목록 mousedown 무조건 preventDefault → 스크롤바 드래그·여백 클릭에 포커스가 빠져 blur 로 닫히던 것도 차단.
• 높이 max-height 242 → 484px(2배) + overscroll-behavior:contain(끝에서 페이지로 안 넘어감).
• 드롭박스 전부 = 같은 attachCombo() 한 곳이라 품명·업체명이 한 수정으로 덮인다(항목행 AL/유리업체는 네이티브 <select>라 애초에 무관).
• 현장명(#fSite) 드롭리스트 신설 = 견적서 「현장 검색」과 같은 API GET estimate/site-search (상차일 최근 30일 이후 · 키워드 = 현장명 OR 업체명 · 최대 50건), 200ms 디바운스 서버조회. attachCombo(input, getItems, fetchItems) 3번째 인자 신설(비동기 목록) — 기존 두 콤보 동작 무변경. 클라 필터가 보조설명(업체명)까지 보게 고침 — 서버가 업체명으로 찾아준 현장이 화면에서 걸러지던 것.
• 검증 = 신설 scripts/_al_combo_check.py {test|prod}(읽기전용). 배포 전 8 FAIL → 테스트 19 ALL PASS · 운영 19 ALL PASS. 기존 _al_orderpaper_ui_check.py 회귀 = 테스트·운영 각 27 ALL PASS. 콘솔 에러 0. 운영 현장 목록 34건이 견적서 현장검색 결과와 완전 일치.
• 사이트맵 재빌드(배포 후) = 그룹 8 · 페이지 54 · 미반영 0.
• ⏳[페페] 운영 육안 1회 — 현장명칸 클릭(현장 목록) · 품명칸에서 휠로 목록 굴리기 · 맨 아래 행에서 목록이 위로 뒤집히는지.

🆕 NOW (2026-08-18 · 3차) — 견적 v2 치수/코너 칸 휠 스크롤 값증감 차단 ✅운영배포 완료

[페페] QA(qa_helper, /estimate/modify-v2/751 치수3 입력) = "모든 치수칸에서 스크롤로 숫자 증감이 되는 버그가 있다. 치수입력칸에서 스크롤 사용은 금지다. 수정보완해. 운영배포."

배포 = master 387ba62 → deploy-live b827551(estimate_regist_v2.js 1파일 포워드 · 순수 7줄 추가). DB 변경 0.

• 원인 = 치수/코너 칸이 <input type="number"> 라 포커스 중 휠 = 브라우저 기본 증감.
• 조치 = bindEvents() 에 위임 1줄. $(document).on('wheel', '.dim-cell, .corner-cell', …) 에서 this === document.activeElement 면 blur() — 포커스가 없으면 기본 증감이 아예 일어나지 않는다. 🔑preventDefault 는 안 쓴다 = ①크롬은 document 위임 wheel 을 passive 로 잡아 안 먹고 ②먹더라도 그 칸 위에서 페이지 스크롤까지 막혀 표가 안 굴러간다.
• 🔑한 곳으로 전부 덮인다 — 본문 행 · 임시계산기 #calcFrame · 항목모달 #itemModal 이 같은 클래스를 쓴다 (모달 치수칸은 type="text" 라 무해). 코너칸도 같은 블록·같은 사고라 함께 막았다.
• 검증 = 신설 scripts/_dim_wheel_check.py {test|prod} [견적번호](읽기 전용 — 저장 안 누른다). 운영 배포 전 6 FAIL → 배포 후 14검사 ALL PASS, 테스트 ALL PASS(계산기 칸 기준 — 테스트 RDS 견적엔 항목이 없다).
• 사이트맵 재빌드(배포 후) = 그룹 8 · 페이지 54 · 미반영 0.
• ⏳[페페] 운영 육안 — 치수칸에 커서 두고 휠 굴려 값이 안 변하는지(포커스는 풀린다).

🆕 NOW (2026-08-18 · 2차) — 월마감 UI: 마감월 좌우 화살표 + 컬럼 폭 조정 ✅운영배포 완료

[페페] QA = "마감월 이동이 불편하다. 기존 형태 그대로 유지하면서 좌우 화살표로 넘어갈 수 있게. 현장명 가로폭 절약. 완료/청구일 가로폭 증가. 운영 배포."

배포 = master b60787d → deploy-live a8d8f30(템플릿 1파일 포워드). DB 변경 0.

• mcShiftMonth(delta) = #mc-ym 값을 Date 로 굴려 ±1개월. 연 넘김(2026-01 ◀ 2025-12)이 공짜로 따라온다. <input type="month"> 는 손대지 않고 좌우에 화살표 버튼만 붙였다(기존 형태 유지 지시).
• 컬럼 폭 = 현장명 26% → 17%, 완료/청구일 무지정 → 12%(운영 실측 221px · 156px). 「행신동 포함」·「타현장에 포함」이 잘리던 게 해소됐다.
• 검증 scripts/_monthly_close_ui_check.py 19항목(화살표 6 신규) — 테스트·운영 각각 ALL PASS. ⚠행수·금액 단정은 운영/테스트 분리했다 — 테스트 RDS 는 07-23 옛 시딩본(7월 넥서스 7행·176,113,000)이라 운영 기준(9행·252,970,000)으로 보면 무관한 FAIL 5건이 뜬다.
• 사이트맵 재빌드 = 그룹 8 · 페이지 54 · 미반영 0.

🆕 NOW (2026-08-18) — 월마감 26년 1~7월 운영 1차 초안 시딩 완료 (상세: session-2026-08-18-monthly-close-prod-seed.md)

07-29에 코드만 운영배포하고 미뤄둔 「마감 데이터 시딩」을 NAS 마감표 기준으로 집행. 마감 16건·78행.

• 그릴링 2문 확정 = 기존 견적만 연결(백필 생성 안 함) / 기존 2026-07 넥서스 자동수집본(close_no=1)은 마감표로 교체.
• 정본 파일 판정(이름으로 특정 불가 → 내용으로) = 넥서스 1~7월 · 에넥스 1~7월(+-포인확정 확정액) · 넵스 3·7월. 5월은 (포인)넥서스 5월 마감.xlsx, 6월은 넥서스 6월 마감.xlsx((포인,7월마감건에 참조)…는 7월 작성용 참조본이라 계가 다름).
• 매핑 = 현장 75/78(미연결 = 일레븐 오피스텔 SH · 별도 비용 · 반도건설 부산 EDC), 견적 12행. 견적 연결엔 금액 게이트(가족합 ±10% 또는 정확일치)를 걸어 이름만 비슷한 오연결을 막았다.
• 검증 = 저장본 재조회 16/16 PASS · UI scripts/_monthly_close_ui_check.py prod 12/12 ALL PASS · 엑셀 3건 · 사이트맵 미반영 0.
• ⏳페페 확인 2건 = ①넥서스 1~4월은 이월 현장 7~8행이 매달 반복(마감표 원본 구조) — 그대로 둘지 ②7월 마감표에 없는 학동매장 3건·금강 부산에코(교체 전 자동수집본엔 있었음)가 마감표 누락인지 8월 이월인지.

🆕 NOW (2026-08-10 · 5차) — 숨김 현장 관리 모달 = 견적서 현장 검색 표 양식(기간+현장명 검색, 기본 3개월) ✅운영배포 완료

[페페] QA(qa_helper, /field/orderpaper 「🗂 숨김 현장 관리」 버튼) = "숨김 현장 모달을 견적서 현장명 검색 모달과 동일한 형식으로 수정해줘. 모달에 별도 검색창 추가한다. 날짜 기간+현장명 검색 용도. 모달 기본 로드는 3개월 이전 현장까지 띄운다. 운영 배포."

배포 = master eac466b → deploy-live e965a65(2파일 선별 포워드, --detach worktree). DB 변경 0.

• 종전 = 폭 560px 모달에 검색 입력 1개 + .op-map-row 한 줄 리스트(현장명 + 「업체 · 연결현장 · 항목 n」 메타). 지금 = 폭 900px + 견적서(estimate_regist_v2)와 같은 표 6컬럼 (업체명 / 현장명(발주서)+연결현장 / 구분 / 상차일 / 최근 입고일 / 항목) + 활성화 열 + 결과 건수 + 헤더 클릭 정렬.
• 검색창 = 상차일 기간(from~to) + 현장명 키워드. 기본 = 오늘−3개월 ~ 비움(이후 전체) — 견적서 모달의 「최근 1개월~이후 전체」와 같은 방식(종료일을 비워 미래 무제한). 키워드는 현장명·연결현장명·업체명 3필드.
• 🔑데이터는 모달 열 때 한 번만 받고 필터·정렬은 화면에서 한다 — 숨김 현장은 수십 행(운영 27·테스트 6)이라 서버 왕복·신규 API 가 필요 없다. 컨트롤러·서비스 무변경(GET /api/orderpaper/hidden-sites 그대로).
• DAO select_hidden_sites() 에 ship_date(field.shipping_date) · field_div_name(common_code FIELD_DIV) · order_date_min 추가. 🔑field 값은 LEFT JOIN 대신 서브쿼리 — GROUP BY o.site_name_raw, m.field_no 라 조인 컬럼을 SELECT 에 얹으면 ONLY_FULL_GROUP_BY 에 걸린다(기존 field_name 도 같은 이유로 서브쿼리였다).
• 🔴상차일 없는 숨김 현장은 기간과 무관하게 항상 보인다(fail-open) — 날짜로 걸러 사라지면 활성화할 길 자체가 없어진다(숨김 현장은 이 모달이 유일한 해제 창구). 현재 실측 0건이지만 field.shipping_date 는 nullable.
• 검증 = 신설 scripts/_op_hidden_modal_check.py {test|prod} — 읽기 전용(GET + 모달 조작만, 「활성화」는 존재만 확인하고 누르지 않는다 = 운영 데이터 무변경). 테스트 35검사 ALL PASS · 운영 35검사 ALL PASS (기본 3개월 컷 실측 = 운영 27→25, 테스트 6→5 / 시작일 비우면 전체 복귀 / 종료일 필터 / 키워드 매치 / 헤더 정렬·토글·초기화 / 모달·표 가로 넘침 0 / 콘솔 0 / 발주서정리 카드 회귀 8카드).
• 사이트맵 재빌드(배포 후) = 그룹 8 · 페이지 50 · 미반영 0.
• ⚠같은 시각 다른 세션이 같은 파일(field_orderpaper.html)에 「미입고 필터」 QA 를 진행 중이었다 — 착수 시점 워킹트리는 깨끗했고(그 세션 미착수) 편집 구역도 겹치지 않아 그대로 진행, 커밋은 파일 2개 명시 add.
• ⏳[페페] 운영 육안 — /field/orderpaper → 「🗂 숨김 현장 관리」(기간·현장명 검색 · 정렬 · 활성화).

🆕 NOW (2026-08-10 · 4차) — 발주서 「입고처」 행 파싱 → 오엠씨 자재관리를 오엠씨 입고 시트로 한정 ✅운영배포 완료

[페페] QA(qa_helper, /omc/material 품명칩 BNS-24E117 PP) = "원부자재발주서 읽는 스킬 보완해줘. 이 품목은 한솔아트에서 피앤알로 입고되는 품목이다. 품목 아래로 병합된 라인이 있고, 입고처 셀과 오른쪽에 업체명셀, 그 오른쪽으로 주소가 있다. 입고처 행 위쪽에 있는 데이터가 발주서 해당 탭 업체에서 입고처 업체로 발송되는 것이다. 따라서 BNS-24E117 PP은 오엠씨로 가는게 아니고 피앤알이 맞고, 오엠씨 자재 관리에는 보이면 안된다. 수정 운영 배포."

배포 = master ba33cfc → deploy-live efa4593(5파일 선별 포워드, --detach worktree). 운영 RDS 는 동기화가 선적용(orderpaper.receiver 멱등 ALTER) — 배포 전에 컬럼이 있어야 DAO 가 SELECT 한다.

• 발주서 「입고처」 행 실측 구조(전 파일 전수조사 = 45파일 · 543행) — A열(A:B 병합) 입고처 · C열 입고처 업체 · D열~J열(병합) 주소. 한 탭(섹션)에 여러 개일 수 있고 각 입고처 행이 자기 위 묶음을 끊는다 (실측 엠제이실업 탭 = r10 오엠씨 / r13 진영LDM / r39 상원테크 / r42 세영M테크). 대부분 탭은 표 아래 r26·r28 에 포인 1개(우리 공장 입고)만 있다.
• 파서 orderpaper_parse.py = _receivers(ws,sr,er) + _receiver_of(rcvs,r) → 항목 dict 에 receiver. 항목의 입고처 = 그 항목 아래에서 가장 가까운 입고처 행. 아래에 없으면 ''(미기재). 원자재(오엠씨) 분기·부자재 분기 양쪽 다 한 줄씩. 입고처 행 자체는 종전대로 _is_label 이 걸러낸다.
• 동기화 orderpaper_sync.py = orderpaper.receiver VARCHAR(100) 신설(CREATE + 멱등 ALTER 목록) + INSERT/UPDATE 에 추가. 🔑item_key/block_key 해시에는 넣지 않았다 — 넣으면 다음 동기화가 전 행을 새 행으로 만들어 사용자 편집(*_user)·상태·사용이력이 끊긴다(실측 ins 0 / upd 1769 = 키 churn 0).
• 화면 field_orderpaper.html 오엠씨 필터 = 종전 발주처=오엠씨 OR 시트(T) → 발주처=오엠씨 OR (시트 AND 입고처∈{오엠씨, 미기재}). dao.select_all_items 에 receiver 노출. 🔑미기재는 fail-open(종전대로 노출) — 근거가 없을 때 입고 누락이 오노출보다 위험. 현재 미기재 시트는 0건.
• 영향 실측 — 오엠씨 화면 집합: 테스트 229→181(-48), 운영 216→170(-46). 빠진 것은 전부 목적지가 오엠씨가 아닌 시트다(피앤알·바사디자인·헤브론·호선우드·청솔산업·삼성산업·월드산업, 그리고 포인 직입고).
• 🔎운영 화면에서 지금 시트 그룹이 비어 보이는 건 정상이다 — 숨김 제외 시트 17건 중 오엠씨행 13건이 전부 완료, 이 화면은 완료를 접는다(foldcfg.done=false). 남아 있던 미완료 시트 1건이 바로 피앤알행이었다(= 페페가 지적한 그 줄). 새 오엠씨행 시트가 들어오면 다시 뜬다. 카드 전체 펼침(opExpandCardAll)으로 13건 렌더 확인함.
• 검증 = ①신설 scripts/_op_receiver_probe.py 파서 자체검사(합성 3케이스 + NAS 실파일 대조) ALL PASS ②신설 scripts/_op_receiver_db_check.py(SSM, 읽기전용) 테스트·운영 ALL PASS — 컬럼 존재·적재 (운영 1705행 중 1608 기재)·시트 입고처 분포·집합 축소·한솔아트 BNS-24E117 = 피앤알 ③scripts/_omc_material_check.py 확장(입고처 한정 2검사 추가) 테스트 ALL PASS + 운영 ALL PASS. ⚠검사 2건이 데이터 모양에 묶여 있어 같이 고쳤다 — 「시트 그룹 맨 위」·「타업체 품명 편집」이 첫 카드/기본 펼침 상태에 기대고 있었다 → 전 카드 opExpandCardAll 후 시트 섹션이 있는 모든 카드를 본다.
• 사이트맵 재빌드(배포 후) = 그룹 8 · 페이지 50 · 미반영 0.
• ⏳[페페] 운영 육안 — /omc/material 에 한솔아트 BNS-24E117 PP 가 없는지, 현장 카드 「완료 업체」를 펼치면 오엠씨행 시트 13건이 보이는지.
• ❓[페페] 판단 1건 = 화면에 입고처 컬럼을 보여줄지. 지금은 필터에만 쓰고 표에는 안 띄운다(지시 범위 밖).

🆕 NOW (2026-08-10 · 3차) — 생산현황 레포트 아이비젼글로벌 업체명 2줄 표기 ✅운영배포 완료

[페페] 지시 = "field/print/status 아이비젼글로벌 업체명이 길어서 셀을 넘어선다. 줄바꿈 적용. 아이비젼 후에 글로벌은 다음줄. 이 업체만. 운영배포."

배포 = master 4406fe2 → deploy-live 09c60ff(1파일 선별 포워드, --detach worktree). DB 변경 0.

• [코디] 원인 = td.comp { white-space: nowrap } + col.c-comp { width: 8% }(실측 60px). 폭을 넓히면 다른 칸이 밀리므로 이 업체명만 <br> 로 끊는다 — <br> 은 nowrap 도 무시하고 개행한다(CSS 무변경). field_status_print.html 에 compName() 신설, compTd() 가 esc() 대신 이걸 쓴다.
• 🔴함정 = 테스트와 운영의 업체명 표기가 다르다. 운영 = 아이비젼글로벌, 테스트 = 글로벌아이비젼(순서 반대). 1차 구현(아이비젼글로벌 고정 매칭)은 테스트에서 아무 것도 안 걸렸고 그게 검증에서 잡혔다. → 정규식 /(아이비[젼전])\s*(글로벌)|(글로벌)\s*(아이비[젼전])/ → '$1$3<br>$2$4' 로 두 표기 다 받되 이름 순서는 그대로 둔다(업체명을 뒤집지 않는다). rules 🆕. ※orderpaper_parse.py 는 별개로 글로벌아이비전 → 아이비젼글로벌 정규화를 이미 하고 있다(발주서 경로 한정).
• 검증 = 신설 scripts/_field_status_print_ivision_check.py {test|prod}(읽기 전용 — 페이지의 compTd() 를 그대로 호출해 임시 행을 넣고 scrollWidth>clientWidth 실측 후 행 제거). 테스트·운영 둘 다 ALL PASS — 2줄 표기·셀 넘침 0(60=60)·표 가로 넘침 0·넥서스 등 다른 업체 <br> 없음·실데이터 업체셀 넘침 0·콘솔 0. 운영 실데이터엔 해당 업체 2셀이 아이비젼<br>글로벌(담당 은지호)로 나온다 = 페페 지시 그대로.
• 사이트맵 재빌드 = 그룹 8 · 페이지 50 · 미반영 0.
• ⏳[페페] 운영 육안 + 실제 인쇄 — 화면은 확인했으나 A4 인쇄(font-size 11px)는 눈으로 볼 것.

🆕 NOW (2026-08-10 · 2차) — 견적 재작성에 「내용 복사」 선택 신설 + 차수 버튼 표기·위치·모달 폭 ✅운영배포 완료

페페 지시 = "함정 주의하고 pfs 에 기능으로 추가해라. 본건 견적서 새로 생성시 복사 기능 추가 (사용자 선택예정, 0으로 시작하는 경우도 있음) 운영배포." + QA 3건(/estimate/list-v2) = "차수 1·차수 2 로 표기되는 버튼을 1차·2차로", "버튼을 삭제 왼쪽으로", "차수 이력 모달 가로폭 — 줄이 밀린다".

배포 = master e25e3e7 → deploy-live e659f80(4파일 선별 포워드, --detach worktree). DB 변경 0.

• ① 재작성 = 시작 방식을 사람이 고른다. 종전엔 confirm('…항목은 복사하지 않습니다') 하나뿐이라 빈 견적서가 유일한 길이었다. 이제 모달 #rewrite-modal 에서 「내용 복사해서 시작」 / 「빈 견적서로 시작」 / 취소. 🔑confirm 2번으로 안 물었다 — 「취소」가 「빈 견적서」로 읽혀 금액 문서를 오조작한다. API = POST /api/estimate/<no>/rewrite body copy_items:'1'|'0'(기본 '0' = 종전 동작, 회귀 0).
• ② 복사 범위 = estimate_detail + estimate_detail_sub + estimate_extra_cost + estimate_material
• 마스터 금액 4컬럼(총액·마진총액·시공비·운반비). 헤더(현장·업체·지불조건·마진)는 종전 재작성 그대로 승계, comment 는 종전대로 빈 값(내용 복사의 범위가 아니다).
• 🔴함정 1 = FLOAT(어제 708→747 수동 복사에서 발견) → estimate_dao.copy_estimate_contents 는 값을 MySQL 밖으로 안 꺼낸다. 전부 INSERT .. SELECT, 파이썬은 정수 PK 만 만진다.
• 🔴함정 2 = display_order 로 부모-자식을 짝지으면 안 된다 — 실데이터에 중복이 있다 (테스트 견적 33·35·36·37·47 = 19행인데 distinct 6). → 항목을 한 건씩 INSERT 하고 그 자리에서 SELECT LAST_INSERT_ID()(같은 커넥션·트랜잭션)로 새 detail_no 를 받아 그 자식만 붙인다. rules 🆕.
• 🔴함정 3 = % 포맷 조립 — values 조각에 %%s 를 쓰면 바깥 포맷의 인자라 escape 이 안 돼 %%s 가 그대로 남는다(1차 구현 버그, 완성 SQL 을 print 해서 잡았다). rules 🆕.
• 복사 실패 = 재작성 자체를 되돌린다 — 새 차수 delete_estimate + 원본 update_archive('0') 후 예외 전달. 빈 차수가 남아 사람이 치우는 상태를 안 만든다.
• ③ 차수 버튼 = 라벨이 「차수 N(현장의 차수 개수)」였다 → 「N차(이 행이 몇 차인가)」. 🔑개수는 그 행이 몇 차인지 말해주지 않아 보관된 1차 행이 "차수 2" 로 보였다. 번호 매김은 차수 모달과 같은 estimate_no 오름차순 순번(DAO 서브쿼리 revision_no 신설). 개수는 툴팁으로 남겼다. 위치 = 삭제 왼쪽.
• ④ 차수 이력 모달 = modal-lg(800px) → 1140px(calc(100vw-40px) 상한) + 견적명 외 nowrap. 실측 = 폭 1140 · 가로 넘침 0 · 셀 잘림 0 · 행 높이 균일(53=53).
• 검증 = 신설 scripts/_est_rewrite_copy_check.py {test|prod} [--write] [--empty] + _est_rewrite_db_verify_test.py(SSM, 서버측 <=> 대조) — 테스트 E2E 3회전(복사 → 정리 → 빈 견적서 → 정리 → 복사 재확인 → 정리) 전부 ALL PASS. 대상 = 테스트 견적 707 일레븐 파크사이드 (항목 52·sub 215·별도 2·자재 4 = 네 테이블 전부 덮는다). DB 대조 = 4테이블 전 컬럼 비트 일치 0불일치 · SUM(amount)·SUM(margin_total_amount) <=> 1 · 마스터 금액 4컬럼 동일 · 이름 (2차) · 원본 보관·항목 보존. 화면 대조 = 원본 707 과 복사본 804 의 견적 총액이 같다(둘 다 195,760,580). 🔑테스트 DB 는 원상복구했다 — 만든 차수 802·803·804 를 자식까지 삭제하고 707 보관 해제(실측 확인). 운영은 읽기 전용 검증만(라벨·위치·툴팁·모달 폭·재작성 모달 3버튼·콘솔 0) — 운영에서 재작성은 안 눌렀다.
• 사이트맵 재빌드 = 그룹 8 · 페이지 50 · 미반영 0.
• ⏳페페 = 운영 육안 — 목록에서 「N차」 위치·툴팁, 차수 이력 모달 폭, 재작성 → 두 갈래 선택.

🆕 NOW (2026-08-10) — 대우 용인 MH 견적서 1차(708) → 2차 재작성건(747) 내용 복사 ✅운영 반영 완료

페페 지시 = "pfs 운영서버 에넥스 대우 용인 견적서 본건 1차를 2차 본건 재작성건에 내용 복사해. 운영 작업 승인". 코드 변경 0 — 운영 RDS 데이터 작업만(배포 없음, 사이트맵 무관).

• 대상 = 현장 field_no 2109(대우 용인, 에넥스·김동연). 본건 1차 = 견적 708(2026-06-10, archive_yn='1' 보관됨, 총액 43,563,000) → 2차 = 견적 747(대우 용인 MH 견적서 (2차), 2026-08-10 생성, 완전히 비어 있었다). 둘 다 parent_estimate_no NULL = 본건, 추가건 0건(복사 대상도 본건뿐).
• 복사한 것 = estimate_detail 50행 + estimate_detail_sub 53행(전 컬럼 원본 그대로, PK만 신규 채번) + 마스터 total_amount·margin_total_amount = 43,563,000. estimate_extra_cost·estimate_material 은 원본이 0건. 마스터 나머지(지불조건 현금·마진 -10·구분·시공비/운반비 0)는 747 이 이미 708 과 같아 손대지 않았다.
• 🔴함정 = FLOAT 정밀도. 1차 시도(파이썬으로 읽어 되넣기)는 값이 미세하게 달라졌다 — MySQL 텍스트 프로토콜이 FLOAT 를 유효 6자리로 잘라 보내 SUM(amount) 33,419,453.09375 → 33,419,442.0(11.09 차이). 행 단위 파이썬 대조로는 차이 0 으로 보여 못 잡는다(읽는 순간 양쪽 다 뭉개짐). → 넣은 행을 지우고 서버측 INSERT .. SELECT 로 재복사(자식은 display_order 조인으로 새 detail_no 매핑). rules 🆕 등록.
• 검증 = ①서버측 NOT (a.col <=> b.col) 전 컬럼 조인 → detail·sub 불일치 0행 ②SUM(amount)·SUM(margin_total_amount) 708 = 747 완전 일치 ③708 무변경 확인(50행·합계 그대로) ④운영 화면 실브라우저(scripts/_est_daewoo_ui_check.py prod) ALL PASS — 747 에 타입 5개(59A·59B·84A·84B·84C)·주방(K)5/가구(F)4·견적 총액 43,563,000 표시, 콘솔 에러 0.
• 롤백 = 747 의 detail_no 35494~35543(+그 자식 sub) 삭제 + 마스터 합계 0 복원. 스크립트는 전부 pfs/scripts/_est_daewoo_*.py(미추적).
• ⏳페페 = 운영 육안(/estimate/modify-v2/747 — 타입별로 항목 확인 후 2차 내용 수정).

🆕 NOW (2026-08-10) — 생산 스티커 출력 회수 초기화 버튼(총관리자 전용) ✅운영배포 완료

페페 QA(qa_helper, 도어 표의 ✓2회 09 Aug 2026 신동승 셀) = "출력 회수 초기화 버튼을 추가해줘. 관리자만 사용가능. 관리자 아이디만 볼 수 있게 설정. 페이지 이동 버튼 행의 우측 끝에 추가." (1차 지시엔 운영배포 말이 없어 테스트까지만 했고, 같은 날 페페가 채팅에 「운영배포 진행」 직접 입력 → 배포.)

배포 = master b590f3e → deploy-live 84fcb2f(3파일 선별 포워드). 운영 RDS DDL 선행 적용 완료. 🔑같은 파일에 실려 8/7 백로그도 함께 반영됐다 = sticker_controller sync target 한 줄 (운영 화면 「엑셀 동기화」가 테스트 DB 를 갱신하던 것 → FLASK_CONFIGURATION 기준 prod/test 결정). → 사이트맵 미반영 1 → 0.

• 범위 = 현재 선택된 도어발주서 파일 전체(모든 페이지) — 페페 택1. "이 발주서 다시 처음부터 뽑는다"가 실제 상황.
• 권한 2겹 = ①템플릿 {% if is_super_admin %} 로 버튼 자체가 관리자에게만 렌더 ②서버 POST /api/sticker/print-log/reset 가 session.is_super_admin 을 다시 확인. 비로그인은 기존 게이트가 401.
• 🔑DELETE 가 아니라 소프트 딜리트 — sticker_print_log.remove_yn='1' + removed_by·removed_at. 누가 언제 지웠는지 남고, 잘못 눌러도 DB 에서 되살릴 수 있다. 조회 2곳(select_print_logs, select_print_log_history)에 remove_yn='0' 필터 추가.
• 확인 대화상자에 대상 품목 수·"기록은 남아 복구 가능" 을 적어 오조작을 줄였다. 버튼은 붉은 테두리로 페이지 버튼과 구분(우측 끝, .pn-reset).
• 스키마 scripts/codi_sticker_printlog_reset_schema.py(멱등 — 컬럼 3 + ix_spl_live). ⚠.gitignore 의 scripts/codi_* 라 추적 안 됨(옛 codi_sticker_.py 는 규칙 생기기 전에 들어간 것). 테스트·운영 RDS 둘 다 적용 완료(운영은 _codi_sticker_printlog_reset_schema_prod.py = ENV_PATH 만 다른 사본, 코드 배포보다 먼저 실행). 운영 적용 후 실측 = 컬럼 3개 존재 · 기록 3행 전부 remove_yn='0'(데이터 무변경*).
• 검증 = 신설 scripts/_sticker_printlog_reset_check.py {test|prod} — 테스트 19 + 운영 13 ALL PASS (소스 게이트 6 · 비로그인 401 · 버튼 노출/행 마지막/우측 끝 · 실제 초기화 ✓3→0 · 표 25행 보존 · 다른 발주서·다른 source 기록 보존 · 원상복구 · 콘솔 0). prod 모드는 읽기 전용(버튼·권한·소스만, 초기화 안 누름).
• 🔴검증 함정 = 테스트 DB 엔 「진행중 현장에 연결된 살아있는 도어발주서」가 0건이라 화면에 표가 안 뜬다. 기록이 있던 file 222 는 door_order_file.remove_yn='1' 인 삭제 파일(칩 0개)이었다 → 살아있는 file 241(금강 부산에코, 264품목)을 진행중 현장 2142 에 임시 연결 + 기록 시드 → 검증 → 연결 해제 + 시드 행 삭제. 원복 확인 = 로그 16행 전부 remove_yn='0' · file222→2099 · file241→NULL(SSM 실측).
• ⚠운영에서는 초기화를 안 눌렀다 — 운영 기록 3행이 실데이터라 지우면 안 된다. 운영 검증은 읽기 전용 (버튼 노출·위치·권한 게이트·비로그인 401·소스 게이트)까지. 실제 초기화 동작 확인은 테스트에서 끝냈다.
• 🔴배포 함정 = 다른 세션이 deploy-live 워크트리를 잡고 있으면 git worktree add가 거부된다. 이번엔 그 경로에 .git 이 없는 깨진 등록이었는데도 브랜치가 묶여 있었다 → git worktree add --detach <경로> origin/deploy-live 로 붙고 git push origin HEAD:deploy-live. 남의 등록을 지우지 않고, 충돌하면 non-fast-forward 로 안전하게 실패한다(rules 🆕).
• ⏳페페 = 운영 육안(총관리자로 /production/sticker → 발주서 연결된 현장 → 우측 끝 ↺ 출력 회수 초기화).

🆕 NOW (2026-08-10) — 생산 스티커 현장 검색을 견적서 등록과 같은 표 양식으로 ✅운영배포 완료

페페 QA(qa_helper, #stk-field-input) = "견적서 등록의 현장명 검색 리스트 양식을 여기에 적용해줘. 너무 간단하게 나오고 내용이 잘 안 보임. 운영배포"

배포 = master fa34a53+cda67b2+582593a → deploy-live ae9e767(2파일 선별 포워드 · 임시 worktree).

• 종전 = 폭 340px 드롭다운 한 줄(현장명 + 회색 업체명 · 2026-08-17). 지금 = 견적서 등록(estimate_regist_v2)과 같은 5컬럼 표 — 업체명 / 현장명 / 구분 칩 / 상차일 / 담당자 + 헤더 클릭 정렬 + 결과 건수. 폭 780px (max-width:100vw-60px), 최대높이 320→420px, 헤더·컬럼헤더 sticky.
• 모달이 아니라 인라인 드롭다운을 넓힌 것(페페 택1) — 견적서는 모달이지만 생산팀은 현장을 자주 바꾸므로 클릭 수를 늘리지 않는다. 리스트 양식만 가져왔다.
• DAO = field_div_name(기존과 같은 CONVERT_MULTI_COMMON_CODE, common_code 조인 안 씀)· company_member_name 추가, 키워드가 업체명까지 검색(a.name LIKE OR b.name LIKE — 견적 site-search 와 동일). 진행중(production_status.field_status='20') 게이트·3개월전~1년후 창·LIMIT 100 은 무변경.
• 상차일 = 26.8.17(월)(페페 날짜 규칙). 빈 값은 정렬 방향과 무관하게 항상 뒤로(상차일 미정 현장이 맨 위를 차지하지 않게). 선택 흐름·스티커 헤더 표기는 손대지 않았다(field_name 그대로 사용).
• 🔴자체검사가 실버그 1건 적발 = 정렬 한 번 누르면 패널이 닫혔다. 정렬 핸들러가 .html()로 표를 다시 그리는데, 뒤이어 도는 「패널 밖 클릭이면 닫기」 핸들러가 볼 때 e.target(클릭한 th)은 이미 DOM 에서 떨어져 나가 closest('.stk-field-pick')가 0 → 밖 클릭으로 오판. → 정렬·초기화 핸들러에 stopPropagation(rules 🆕 등록).
• 검증 = 신설 scripts/_sticker_field_search_check.py {test|prod}(미추적) — 테스트 40 + 운영 40 ALL PASS (응답 키 8·컬럼/정렬키 일치·건수 일치·폭 780·가로스크롤 0·날짜 형식·정렬 3종+패널 유지 회귀·업체명 검색· 행 클릭 회귀·콘솔 0). 읽기 전용이라 운영 실행 무해(GET + 화면 조작만, 쓰기 없음).
• 사이트맵 재빌드 = 그룹8·페이지 50·미반영 1 — 남은 1건은 sticker_controller.py sync target 한 줄 (8/7 백로그, 워커 이중결정으로 동작은 정상). 이번 건은 전부 반영됨.
• ⏳페페 = ①운영 육안 ②sticker_controller 한 줄 운영배포 지시 여부.

🆕 NOW (2026-08-10 · 3차) — 품명 인라인 편집 전 항목 확대 + 시트 입고일정 병합 주석행 제외 ✅운영배포 완료

페페 = "작동 확인 완료. 모든 항목 자재관리·오엠씨 자재관리에서 품명 수정 가능하게. 피앤알건 : 시트가 포함된 행이 기존 블록양식이 아닌 병합된 행이면 제거한다. 시트 입고 일정에 대한 정보다." 운영배포.

배포 = master d1cb28e → deploy-live b295283(2파일 선별 포워드 · --detach worktree).

• ① 품명 편집 — 오엠씨 외 전 항목도 표에서 클릭 편집(nameChip/opEditName/setItemName). 저장은 전면/후면과 같은 item_name_user 라 기존 자재관리 탭과 그대로 연동(추가 배선 0).
• ② 병합 주석행 제외 — 🔎엑셀 실물 확인이 답이었다: 포인 발주서 표준은 품명 B:C·규격 D:E 를 각각 병합하는데, 주석행은 B:G 한 칸으로 합쳐 쓴다(피앤알 탭 행68 = 시트 : 7.22(수) 13미터 1롤 차량 입고). → 파서가 품명칸 병합이 규격칸까지 덮으면 주석행으로 보고, 그중 '시트'가 든 것만 수집 제외. 🔑JARVIS 1096.19 / 9T MDF 시트/재고PP(행66)는 정상 항목행이라 그대로 둔다 — 그 행은 계속 시트(T)로 분류된다 (페페 규칙이 "규격에 시트"이므로). 빼려면 그 행 규격에서 '시트'를 지우면 된다. 기존 적재분 = 테스트 4건 soft delete(del_manual='1'), 운영은 동기화가 이미 정리해 0건. ✅사이드카 재시작 불필요 — orderpaper_sync.py 는 subprocess 로 돈다(업로드 파서만 sys.modules 캐시).

검증 = scripts/_omc_material_check.py 테스트·운영 ALL PASS(품명칸 전량 편집 가능·시트 주석행 0) + 신설 scripts/_pnr_sheet_row_probe.py 파서 자체검사(합성 4케이스 + NAS 실파일 대조) ALL PASS. 사이트맵 = 그룹8·페이지50·미반영 0.

⏳페페 = 운영 육안(품명 클릭 편집 · 시트 그룹에서 입고일정 메모 사라졌는지).

🆕 NOW (2026-08-10 · 2차) — 시트(T) 자재분류 신설 + 오엠씨 전면/후면 편집 + 오엠씨 화면 펼침·시트 우선 ✅운영배포 완료

페페 QA 3건 = ①"전면·후면 품명 수정 가능하게. 기존 자재관리페이지와 수정결과 연동. 기존 발주서 정리 탭에서도 전면/후면 분리 — 오엠씨 테이블만" ②"부자재로 분류되던 시트 항목을 별도 시트 항목으로 분리. 필터도 추가. 자재관리 전 페이지 적용. 기존분·추가분 모두. 시트는 규격에 항상 '시트'가 포함" ③"오엠씨 자재관리 현장별 그룹 기본 펼침(완료항목은 그대로 숨김), 현장 카드 상단에 시트 그룹 먼저 — 오엠씨에서 시트 입고 체크용". 운영배포.

배포 = master 945ab51+26d2533 → deploy-live 5222bed(8파일 선별 포워드 · 임시 worktree). DB 변경 0.

• ① 전면/후면 편집 — PATCH /api/orderpaper/{no}/item-name(=item_name_user)에 합친 품명 한 필드로 저장하니 기존 자재관리 탭·목록이 자동으로 같은 값을 본다(연동 별도 코드 0). 재조립 규약 = 파서 omc_raw_fields 와 동일. 🔑규격의 양면/단면도 같이 맞춘다 — 후면을 비워도 규격이 '양면'이면 opFaceParts 가 후면=전면으로 되살려 편집이 안 먹은 것처럼 보인다. 분리·편집은 발주처가 오엠씨인 블록만(오엠씨 화면·기존 탭 공통 규칙).
• ② 시트(T) — 컬럼을 안 채우고 조회 시점에 파생시켰다(orderpaper_dao._MT, 규격에 '시트' → T). 🔑저장값을 바꾸면 item_key/block_key 가 sha1(…,material_type) 이라 다음 동기화가 전 행을 새 행으로 만들어 사용자 편집·상태·사용이력이 끊긴다. 파생이라 기존 85건 + 추후 추가분이 마이그레이션 0으로 같은 규칙을 탄다. 화면 4곳(발주서정리·입고일정·자재관리 탭·오엠씨) 전부에 필터 버튼·색상(#2563eb)·정렬 반영. ⚠저장된 필터가 S.mat 를 통째로 덮어써 신규 분류가 undefined=제외가 되므로 복원 시 기본값과 병합. 🔴파생의 대가 = 한 블록에 시트/비시트가 섞인다(운영 59블록 중 23) → 블록 일괄조작 4종 (block-status·block-receive-date·…-bulk·block-delete)에 자재분류를 같이 넘겨 그 섹션만 바꾸게 좁혔다. 안 고쳤으면 시트 섹션의 「상태 일괄」이 화면에 없는 부자재 행까지 바꿨다(오엠씨 화면엔 그 행이 안 보인다).
• ③ 오엠씨 화면 — 현장 카드·업체 블록 기본 펼침(OP_FOLDCFG.card/block=true, 완료 항목만 접힘) + 시트 섹션 최상단. 🔎시트는 오엠씨 발주가 아니다 — 시트업체(조운IMT·데코밸리·미림·엠제이실업…)에 발주해 오엠씨로 입고된다. 실측 발주처 오엠씨 + 규격 '시트' = 운영 0건 → 오엠씨만 걸면 시트 그룹이 영원히 빈다. 그래서 이 화면 데이터 = 발주처 오엠씨 OR 자재분류 T. ⚠부작용 = 오엠씨 발주가 없고 시트만 있는 현장 카드도 뜬다(운영 4→5카드).

검증 = scripts/_omc_material_check.py {test|prod} 확장 — 테스트 ALL PASS + 운영 ALL PASS. 테스트에서만 쓰기 왕복 2건(①전면/후면 저장 → 서버 합친 품명 확인 → 원복 ②혼합 블록에 시트 한정 상태일괄 → 시트 2행만 바뀌고 비시트 3행 무변경 → 전량 원복). 운영은 읽기전용(펼침·스크롤·인페이지 함수만). 사이트맵 = 그룹8·페이지50·미반영 1(/production/sticker, 다른 세션 진행분).

⏳페페 = 운영 육안 — /omc/material(시트 그룹 최상단·전면/후면 편집) · /field/orderpaper(시트 필터·오엠씨 전면/후면). ❓판단 필요 1건 = 규격 9T MDF 시트/재고PP(피앤알, 1행)는 보드인데 규격에 '시트'가 있어 시트로 잡힌다. 아니면 자재관리 탭에서 그 행 규격을 고치면 된다.

🆕 NOW (2026-08-10) — QA 2건: 사이드 메뉴 스크롤 + 오엠씨 전용 자재관리(/omc/material) ✅운영배포 완료

페페 QA(qa_helper) = ①"사이드 메뉴 현재상태에서도 스크롤 되게. 하단 메뉴가 너무 밑에 있어 선택이 어려움. 하단 스크롤 시 시스템관리 이하로는 상단에서 벗어나지 않게 기준선 지정. 운영배포 승인" ②"오엠씨 전용 자재관리 페이지 생성. field/orderpaper 발주서 정리 탭 기준. 없어도 되는 것 = 현장별/업체별 토글· 동기화 사이드카 버튼·삭제/숨김(오엠씨 유저 작동 불가)·원자재 필터 동일 라인 모든 버튼·빠른필터 라인. 품명을 전면/후면 컬럼 분리해 후면 자재 표시(합친 컬러 때 있던 괄호 표기 제거). 운영배포"

배포 = master f956d27+3e80d33 → deploy-live f68f155(5파일 선별 포워드 · 임시 worktree). 운영 RDS에 patch45 선적용(menu_catalog OMC_MATERIAL 1행 + company_permission 오엠씨(196) 1행, 멱등).

① 사이드 메뉴 스크롤 — 🔴원래 스크롤이 아예 안 됐다. 테마가 .left-sidebar와 .scroll-sidebar를 둘 다 height:100%로 잡는데 그 위에 로고+사용자 블록(114px)이 얹혀 있어 스크롤 영역 아래 114px가 화면 밖이고, scrollHeight==clientHeight라 perfect-scrollbar가 스크롤을 안 만든다(휠 실측 scrollTop=0). → pfs_layout.css §10 사이드바 세로 flex(스크롤 영역 = 남은 높이) + pfs.js pfsSidebarPad()가 기준선(시스템 관리)이 상단에 서는 만큼만 스크롤되도록 ul 하단 여백을 넣는다. 🔑여백은 계산이 아니라 실측 보정 — 짧은 콘텐츠는 scrollHeight가 잘리고, ps 레일(절대배치)이 8.5px를 더한다 (1차 구현이 기준선을 8.5px 넘겨 올라간 원인). 2패스 보정 후 오차 0.5px. 상세 = rules.md 🆕.

② 오엠씨 자재관리 — 화면을 새로 만들지 않았다. /omc/material(omc_controller)이 field_orderpaper.html을 omc_view=True로 렌더한다(인라인 JS 1,000줄 복제 0). 템플릿·JS가 그 플래그로 갈라진다 — 탭바·다른 탭 컨테이너/JS 3파일·분류토글·툴바(자재/숨김관리/업로드/동기화)·빠른필터 라인·칩·상세필터/업로드/숨김 모달 제외, op-del-btn·블록삭제·숨김·현장연결/연결변경 제외(발주처가 pfs 현장 매핑을 바꿀 자리가 아니라 지시 목록에 없어도 뺐다), OP_ALL을 적재 직후 발주처='오엠씨'로 필터(카운트·필터 옵션까지 이 집합 기준), OP_MODE='site' 고정, opLoadState/opSaveState 스킵(메인 화면과 같은 localStorage 키라 해제 UI 없이 필터에 갇힌다). 품명 → 전면/후면 2컬럼(opFaceParts, 표 7→8컬럼). 편집(상태·입고일·발주량·비고)은 그대로 둔다. - 🔴괄호가 자재넘버의 일부인 행이 실제로 있다(70-113(PP)·유사PP(WH240EMT)) → 공백 있는 ' (' 만 합친 표기로 본다. rules.md 🆕. - 숨김 현장은 기존과 똑같이 제외한다(운영 오엠씨 130항목 중 99가 숨김 현장 → 화면엔 4현장 31항목). 숨김은 「유지·오엠씨 유저 작동 불가」라는 지시대로 버튼만 없애고 동작은 그대로 뒀다. - 권한 = 오엠씨(196)만 부여. 에넥스(4)는 OMC_SHEET/BOARD 권한이 있지만 이 화면은 전 현장의 오엠씨 발주를 보여줘 제외. 포인(자사)은 명시 row 없으면 기본 허용이라 자동 노출.

검증 = 신설 scripts/_omc_material_check.py {test|prod} [뷰포트높이](미추적, 읽기전용 — 카드·블록 펼침과 스크롤만 건드리고 저장 버튼은 안 누른다, localStorage 원복) — 테스트 ALL PASS(뷰포트 700/800/1080) + 운영 ALL PASS. 전면/후면 규칙 9케이스를 페이지의 opFaceParts로 직접 호출해 검증 + 기존 /field/orderpaper 회귀(탭4·7컬럼·삭제버튼·탭JS 3개) 포함, 콘솔 0. 사이트맵 재빌드 = 그룹8·페이지 50(/omc/material 신규, live 반영 확인)·미반영 1 = /production/sticker(다른 세션 진행분, 본건 무관).

⏳페페 = 운영 육안 — ①사이드바 끝까지 스크롤(시스템 관리가 상단에 서는지) ②/omc/material 화면.

🆕 NOW (2026-08-07) — field/worklog 3탭 「통합현장」(통화+카톡 융합) ✅운영배포 완료

페페 지시 = "s25에서 읽는 내용(통화수집·카톡)과 pfs worklog 카톡방 내용을 융합. 모든 정보를 현장 매칭해 한 장소에서. 기존 탭 유지 + 새 탭. 진행중 현장 기준 + 최근 접수 있는 완료현장(미출고·신규접수 위주). 운영 배포 승인."

배포 = master 844fff8 → deploy-live c6277a9(4파일 선별 포워드 — worklog dao/service/controller + field_worklog.html).

• 신규 API GET /api/worklog/fusion — worklog 이번주 창(source 게이트 없음 = 통화+향후 카톡 적재분 자동 포함, privacy·숨김현장은 기존 절 재사용) + kakao_board 미러를 production_status.field_status('10'대기중/'20'진행중/'30'완료) 기준 현장 카드로 조립. 진행중=전부 노출, 완료('30')=미출고 섹션+이번주 항목만(출고완료·기타 비움), 대기중/미상=내용 있으면 전부.
• 방→현장 매칭 = kakao_board.field_no 직접 연결 우선 → 없으면 auto-link와 같은 게이트(점수80·유일승자·3자·커버리지)로 site_name→alias→room_name 순 유사도. 실패분은 「현장 미연결」 그룹으로 화면 하단 노출(정보 유실 금지). 게시글 섹션 분류는 '미출고' 판정을 '출고'보다 먼저('미출고'에 '출고'가 부분문자열). 「변동 반영 이력」은 로그라 제외.
• 화면 = 모아보기 전용(편집은 1·2탭), 검색(클라 필터)·전체펼침·새로고침. 탭 배지=현장 수.
• 검증 = 신설 scripts/_worklog_fusion_check.py {--logic|test|prod}(미추적) — 로직 17 + 테스트 38 + 운영 38항목 ALL PASS (API 구조 8·창·정렬·완료필터 + UI 탭전환·카드수 일치·펼침·검색·1/2탭 회귀·콘솔 0). 읽기전용 GET이라 운영 실행 무해.
• 운영 실측 = 진행중 6현장(금강 부산에코에 카톡 20행 매칭), 미연결 방 3(오엠씨 자재방·SGC 용두동·아이비젼 소물량방), 미연결 통화묶음 9. 🔎SGC 용두동 방이 미연결인 이유 = pfs 현장 목록에 유사명 현장이 없음(방 site_name "SGC 용두동 MH") → 현장 등록되면 자동 매칭, 또는 poin-agent state.json의 site를 pfs 현장명에 맞추면 된다.
• 사이트맵 재빌드 = 그룹8·페이지49·미반영 1(/production/sticker — 기존 백로그, 본건 무관. AL 잔여는 걷힘). /field/worklog 주황 없음.
• ⏳페페 몫 = 운영 육안(/field/worklog → 3탭 「🧩 통합현장」) + 미연결 방·묶음 연결 판단.

🆕 NOW (2026-08-07) — qa_helper 다중선택(드래그 범위지정 + Ctrl선택) ✅운영배포 완료

페페 지시 = "qahelper 선택기능에 드래그·Ctrl선택 추가. 상황 판단해줘" → 판단 보고 후 "A로 진행. pfs 운영배포".

배포 = master adca587 → deploy-live ff85064(2파일 선별 포워드 = web/static/js/qa_helper.js + web/static/css/qa_helper.css).

A안 = N개를 1항목(묶음) + 코멘트 1개. 표 20칸에 코멘트 20개 쓸 일이 없다는 게 근거. - Ctrl(⌘)+클릭 = 후보 토글 · 후보가 하나라도 있으면 그냥 클릭도 토글(모으는 중엔 클릭=토글이라 후보를 잃지 않는다) - 드래그 = 밴드 범위 · Enter 또는 [🧺 묶음 담기] 로 확정 · Esc = 후보만 비움(검증 모드 유지) - 후보 0에서 단순 클릭 = 종전 그대로 즉시 1항목(기존 동작 무변경) - 항목 스키마는 members:[] 하나만 추가 → renderList·마크다운의 기존 경로를 그대로 쓰고 묶음 블록만 덧붙임

🔑 드래그의 핵심은 이벤트가 아니라 "밴드 안에 뭐가 잡히느냐"였다. 교차 기준이면 표 하나에 조상 컨테이너·tbody·tr·td·안쪽 span 까지 수백 개가 걸린다 → ①완전 포함만 ②후보의 조상은 제외(=최말단만, Set에 조상 표시 O(n·depth) — 전수 비교 O(n²)보다 싸다) ③6px 미만 제외 ④상한 50(초과분은 토스트로 알림). 이벤트는 mousedown/mousemove/mouseup + 5px 임계(미만 = 단일 클릭), mousedown preventDefault(안 하면 페이지 텍스트가 같이 드래그 선택됨), 드래그 종료 직후 따라오는 click 1회 억제(안 하면 시작점 element 가 덤으로 잡힌다), 드래그 중 호버 하이라이트 OFF.

🔴 자체검사가 잡은 실버그 3건(전부 rules.md 🆕 에 함정으로 등록) 1. 밴드가 자기 자신을 후보로 잡는다 — #qa-helper-band 는 자기 rect 안에 완전 포함 + 자식 없음 = 완벽한 "최말단". isInsidePanel 제외 목록에 추가. 2. Enter 가 통째로 먹통 — picker 가 mousedown 을 preventDefault 하니 포커스가 사이드바 이름칸에 남는다. "패널 밖일 때만 Enter" 로 걸었더니 항목을 한 번이라도 담은 뒤엔 영영 안 먹었다 → textarea 만 제외. 3. 덤 = 「텍스트 보기」 다이얼로그가 검증 모드에서 안 닫혔다(기존 버그). 오버레이에 id 가 없어 isInsidePanel 에 안 걸렸고, document capture 의 stopImmediatePropagation 이 target 의 onclick 보다 먼저다 → id="qa-helper-export" 부여.

검증 - 신설 scripts/_qa_helper_multiselect_check.py — 로그인·서버 없이 도는 정적 하네스(임시 http.server + 실제 js/css 그대로) Playwright 37항목 ALL PASS. td 6개 드래그에서 조상 0 · 4px 박스 제외 · 60개 중 상한 50 · 콘솔 0. - 신설 scripts/_qa_helper_live_check.py — 실서버. 테스트 26 + 운영 26 ALL PASS(/field/list, 셀 120개). 운영 드래그 = 후보 50 전부 leaf(A/BUTTON/SPAN/TD/TH), 포함관계 0, 페이지 이동 0, 콘솔 0, localStorage 원상복구. - ⚠운영에서 돌려도 안전한 이유 = qa_helper 는 서버에 아무것도 안 쓰고(localStorage 뿐), 검증 모드가 클릭을 preventDefault 해서 조작이 서버로 안 나간다. - 사이트맵 재빌드 = 그룹8·페이지49·미반영 1(= /production/sticker 생산 스티커, 이번 건과 무관한 별건 백로그). meta 에 test adca587 / live ff85064 반영 확인. - 배포는 임시 worktree 로 했다 — 작업트리에 페페의 미커밋 수정(orderpaper-sync/*)이 있어 git checkout deploy-live 가 그걸 건드린다.

⏳페페 = 운영 육안(🔍 토글 → Ctrl+클릭 몇 개 → Enter → 사이드바에 🧺 배지 / 표 위에 드래그). ⏳안 한 것 = devplan 쪽 assets/qahelper.js 포팅(지시가 pfs 만이라 그대로 뒀다).

🆕 NOW (2026-08-07) — 부자재 발주서 업로드 "안전하지 않은 접속" 운영배포 완료

페페 QA = 「＋ 부자재 발주서 업로드」로 파일을 고르면 "안전하지 않은 접속"이라며 진행이 안 됨.

원인 = 브라우저가 HTTPS 페이지에서 사설 IP(HTTP)로 form POST 했다. opUpload() 가 http://192.168.45.2:8791/upload(사무실 PC 사이드카)로 새 탭 form POST → 크롬 혼합콘텐츠 차단. 게다가 그 경로는 이미 두 겹으로 더 막혀 있었다 — 26.7.29 보안조치로 사이드카가 127.0.0.1 바인딩 + 토큰 필수 (브라우저는 토큰을 못 붙인다). 즉 LAN 직결은 되살릴 값이 아니라 없앨 경로였다.

고친 방식 = 이미 있던 서버 업로드 API 를 쓰고, 사이드카는 릴레이로 돌린다(동기화 sync-request 와 같은 모양). 1. 화면 → POST /api/orderpaper/upload(같은 오리진 HTTPS·FormData) → EC2 가 blob 을 orderpaper_upload(pending)에 저장. 🔑이 엔드포인트·테이블은 원래 있었는데 화면이 안 쓰고 있었다(운영 테이블 0행 = 한 번도 안 탄 죽은 경로). 2. 사무실 PC 사이드카(orderpaper_sync_server.py)의 upload_poll_loop 가 20초마다 POST /api/orderpaper/upload/claim → 파싱(orderpaper_upload_parsers) → 적재(orderpaper_upload_load, SSM) → POST /api/orderpaper/upload/finish. 인증 = X-PFS-Agent-Token(door_sync_watch 와 같은 토큰). 3. 화면은 upload_no 로 /api/orderpaper/uploads 를 폴링 — 대기 → 분석·적재 중 → ✅완료(목록 자동 갱신)/❌사유. 4. 사이드카의 LAN 전용 POST /upload 삭제(경로 이중화 방지) · running 10분 초과 건 자동 재점유.

덤으로 잡은 것 3개 - 🔴insert_upload 가 항상 upload_no=0 을 반환(= MySQLUtil.execute + 별도 SELECT LAST_INSERT_ID() 는 커넥션이 달라진다) → execute_id 로 교체. 그대로 뒀으면 업로드가 성공해도 화면이 영원히 "대기"였다. - 🔴nginx client_max_body_size 가 아예 없어 기본 1MB(실측 1.43MB → 413) → nginx.conf http 블록 20m (서버 파일·git 밖, nginx -t 통과 후 reload, 백업 nginx.conf.bak_20260807). 화면도 413 이면 크기 초과라고 안내. - 🔴사이드카 폴링 try 가 env 루프 바깥이라 운영 401(미배포) 하나로 테스트 폴링까지 굶었다 → 안쪽으로. 같이 _sidecar.log 신설(창 없는 상주라 출력이 사라져 진단 불가였다).

파서는 서버에 안 올렸다 — EC2 py3.6 에서 pdfplumber 가 chardet 5.0(앱 requests 2.21 과 충돌)·cryptography 40 (certbot)을 끌고 온다(pip download 실측). xlrd·pdfplumber 는 사무실 PC(Python39)에만 설치.

검증 = ①테스트 릴레이 E2E 12항목(에넥스 양식 .xls 를 xlwt 로 만들어 실파서 통과 · blob 바이트 동일 · 적재·원상복구까지) ②live 사이드카 8항목(상주 프로세스가 집어가는 실경로) ③실브라우저(테스트 = 업로드→ ✅ 2건 적재·콘솔 0 / 운영 = 새 코드 적재 확인, OP_SYNC_URL 소멸) ④운영 스모크 4항목(미등록 양식 .txt 로 경로만 태우고 행 삭제 — 운영 데이터 무변경). 사이트맵 = 그룹8·페이지49·미반영 2(기존 AL 백로그, 증가 없음).

배포 = 테스트 12a9b31 · 운영 bac884b(master 1f497ea+58b6809+12a9b31 7파일 선별 포워드). ⚠사무실 PC 사이드카가 꺼져 있으면 업로드는 "대기"에서 멈춘다(2분 뒤 시간초과 안내).

🆕 후속(같은 날) — 페페 실업로드에서 적재 내용이 깨졌다 → 파서 재작성·재적재 완료

증상 = 대우 용인 에넥스 발주서를 올렸더니 128행이 들어왔는데 절반이 빈 품명, 업체는 전부 '천일'. 원인 = 파서가 양식을 몰랐다. 에넥스 .xls 는 한 시트에 발주 페이지가 반복되는데(수신처=업체 1곳당 1페이지, 실측 407행·11페이지) 옛 파서는 첫 페이지 머리만 읽고 11행~끝을 통째로 한 업체 항목으로 봤다 → 라벨행('품 목/규 격/수량'·'계'·'특이사항'·'발 주 일'…)까지 자재로 적재되고 나머지 10개 업체는 소실.

수정(orderpaper_upload_parsers.parse_enex) — A열 '수 신 처'를 페이지 머리로 블록 분할, 페이지마다 업체·발주일·납기 읽기, 표는 머리+6행부터 '계' 전까지, 표 안 고정 안내문('포인 : …') 제외, 비고 열 오타 8↔9 수정, 납기 문자열('추후통보')은 날짜 비움, 🔑같은 업체 2페이지(쿠스코)는 block_key 가 겹쳐 뒤가 앞을 덮어쓰므로 sheet에 페이지 번호를 넣어 분리.

재적재 = 사용자 편집·사용량 이력 0건 확인 → 원문 128행 JSON 백업(/home/ubuntu/backup/ orderpaper_daewoo_badload_2026-08-07.json) → 삭제 → 업로드행 pending 되돌림 → 사이드카 재처리 (⚠파서는 sys.modules 캐시라 사이드카 재시작 필수) → 11블록·55항목. 검증 = 실파일 파서 체크 12항목 ALL PASS(scripts/_op_enex_parse_check.py) · 운영 DB 55행·업체 10곳 (쿠스코 2블록) · 표본 20행 품명/규격/수량/비고 정상 · 운영 화면 55건·콘솔 0. 배포 = master 674102e · 운영 2d0bbd2(사이드카 파일이라 서버 앱과 무관, 브랜치 동기화용).

🆕 2차 후속 — 품명 상속(페페 지시 "①규격·발주량은 있는데 품명이 없으면 위 품명을 이어받는다 ②품명이 쌍따옴표면 동일"). 원본은 같은 품목이 이어지면 품명칸을 비우거나 "(〃)로 쓰는 수기 관행이라 그대로 넣으면 화면·발주에서 품명 없는 행이 된다(실측 빈칸 10 · 따옴표 3). 상속은 블록(업체) 안에서만. 🔑재적재는 삭제 없이 pending 되돌림만 — item_key 가 그대로라 로더가 같은 행을 UPDATE(55행 유지· 삭제 0·*_user 편집 보존). 검증 = 파서 18항목 ALL PASS · 운영 DB 빈칸 0·따옴표 0·업체 10·블록 11 · 운영 화면 55건·콘솔 0(예: 헤티 2~4행이 이노텍 아티라레일470 을 물려받음). 배포 = master 971fed7 · 운영 bdaff93. ⏳페페 = 화면 육안(업체별 블록·품명 상속).

NOW (2026-08-06) — AWS 비용절감 Phase A 완료(A1~A5·A7) · ⏳페페 승인 = A6(RDS-test 삭제)

세션 인계용 요약: 테스트 DB를 RDS에서 EC2 안 Docker MySQL 8.4.8로 옮겼다. 앱은 이미 전환 완료·검증 통과. RDS-test 는 아직 살아 있다(롤백 자료). 남은 것 = ①페페 육안 ②A6 삭제 승인 ③Phase B RI 구매.

발단 = 페페 질문 "pfs 테스트 서버를 미니PC로 빼면 어떤가(AWS 비용). 환경이 달라져 관리가 달라지나?"

판정 — 미니PC 이전은 접었다(실익 대비 리스크 과다)

• 🔴전제가 틀렸다 = 테스트는 별도 EC2가 아니다. 운영·테스트가 같은 t3.medium 1대(i-03225ba8bc12a929e)에 8000/8001 로 얹혀 있다 → 앱만 빼도 EC2 절감 0. 따로 있는 건 RDS 뿐.
• 실측 비용(2026-07) = 총 $86.4/월 — EC2 compute $37.44 · EC2-Other $6.43(EBS gp3 59GB $5.47) · RDS $42.44(db.t4g.micro 2대 $37.20 + GP2 20GB×2 $5.24) · S3 등 $0.09. → 미니PC 이전의 실제 절감 = RDS-test 1대 $21.2/월뿐.
• 환경 차이가 크다 = 미니PC는 Windows / 운영은 Ubuntu+nginx+uWSGI+systemd. ①uWSGI 가 Windows 에서 안 돈다 ②배포가 SSM send-command 라 미니PC 는 대상이 아니고 → 배포 절차 자체를 테스트 못 하게 된다 ③pfs-test.poin.co.kr+Let's Encrypt 경로 상실 ④검증 러너가 미니PC 다운·터널 끊김에 묶임 ⑤고객정보가 사무실 밖 PC로.
• 채택안 = ①RI + ②RDS-test 흡수 → 월 $46.2(절감 $40.2 = 47%, 연 $483 ≈ 67만원), 선결제 0, 환경 변화 거의 0.
• AWS 정책 위배 없음(점검 7항목) — RI 는 정식 요금제, EC2 자유 설치는 정상 용법, MySQL Community=GPLv2 자체사용, Docker Engine=Apache 2.0(유료는 Desktop 뿐), 자기 자원 삭제. 실질 유의점은 ①1년 약정 구속(중도취소 불가, RDS RI 는 재판매도 불가) ②백업·패치 책임이 AWS→우리로 이동(공유책임모델) ③데이터 위치(②안은 같은 리전이라 무변화).

실행 결과 (Phase A · 2026-08-06 완료분)

• MySQL 5.7 정체 = 페페 추측 적중 — auto.cnf 2019-05-29 설치, pfs DB 2020-01-06, 테이블 23개 1.1MB (현 운영 23.1MB), 테이블명이 현행과 같은 계열(estimate_detail·field·company…) = RDS 이전 전 운영 DB의 전신. 「안 쓴다」 증거 = Uptime 93.5일 동안 Com_insert/Com_update/Com_delete 전부 0, 모든 테이블 update_time NULL, PROCESSLIST 앱 접속 0, 소켓 사용자 자기 자신뿐. 덤프 보관 = /home/ubuntu/backup/mysql57_pfs_2026-08-06.sql.gz(23테이블).
• 컨테이너 파라미터 = RDS-test 와 전량 일치(이식 확인) — utf8mb4 / utf8mb4_0900_ai_ci / time_zone=+00:00 / 🔑sql_mode=NO_ENGINE_SUBSTITUTION(8.4 기본은 STRICT·ONLY_FULL_GROUP_BY 포함이라 안 맞추면 기존 쿼리가 깨진다) / explicit_defaults_for_timestamp=ON / local_infile=ON / lower_case_table_names=0 / buffer_pool 128MB(RDS와 동일).
• 데이터 대조 = 87개 중 85개 CHECKSUM TABLE 일치, estimate·estimate_detail 2개만 불일치 → 행수·MAX(PK) 동일하고 --order-by-primary 정렬 덤프 MD5 완전 일치(f2ef384c…)로 동일 확정. 차이의 정체 = CHECKSUM 이 물리적 행 순서를 타는 것(수정이 잦은 두 테이블만 순서가 흐트러져 있었다). 한글 샘플 양쪽 동일(넥서스/한특/에넥스 · 쌍용 홍은동 · 「대우 용인 MH 견적서 (2차)」).
• 앱 전환 확정 근거 = 로그인 API probe 5회 → 컨테이너 Com_select +6 / RDS 는 +1(내 조회 자체뿐), 앱 로그 08:35:19 응답 5건이 probe 횟수와 일치. RDS 앱 트래픽 0.
• A5 검증 = ①_p0e_platform_core_check.py test 0 fail ②test_worklog_autolink_infer.py 10 PASS ③신설 scripts/_db_migration_smoke_check.py {test|prod}(미추적) 8 OK/0 FAIL — 로그인 → /field/orderpaper 현장 카드 25개 → /field/worklog 렌더 · 한글 · 날짜 · 콘솔 에러 0. ④운영 무영향(pfs-live active, HTTP 200). ⚠미확정 1건 = _al_profile_ui_check.py test 가 104줄 「업체 3필드 같은 줄」에서 DOM null 로 중단. 그 앞 항목(로그인·목록·그리드·레이아웃)은 전부 OK 이고 스모크 8항목도 통과라 DB 이전과 무관한 AL 화면 셀렉터 문제로 추정(AL 은 QA 8건 미배포 상태로 화면이 계속 바뀌던 중). 확정하려면 운영 대조가 필요한데 운영 러너 실행은 위험작업이라 페페 판단 대기.
• A7 = swap 2GB(+fstab 등록) · 재부팅 내성 확인(docker enabled · 컨테이너 unless-stopped · mysql(5.7) disabled · pfs-test.uwsgi enabled) · 일일 백업 /usr/local/bin/pfs_test_db_backup.sh + /etc/cron.d/pfs-test-db-backup (매일 03:15, 7일 보관) — 드라이런 1.3MB·gzip 무결성 OK. 현재 여유 = 디스크 31G · RAM available 2,352MB · load 0.09.

✅ A6 완료 (2026-08-07) — RDS-test 삭제 · 그리고 🔴백업 구멍을 하나 메웠다

• 삭제 전 하루 관찰 결과 정상 — 컨테이너 15시간 무중단 · DB 접속 에러 0 · 실사용 Com_select 4,527 · Com_insert 261 · Com_update 184(읽기뿐 아니라 쓰기 경로까지 하루치를 견뎠다).
• 최종 수동 스냅샷 poin-dbinstance-test-final-2026-08-07(available·20GB·8.4.8·태그 Purpose=pre-delete-rollback) → delete-db-instance --skip-final-snapshot. 🔑자동 스냅샷 9건은 인스턴스와 함께 사라진다 — 그래서 수동 스냅샷을 먼저 available 까지 확인하고 지웠다. 결과 = DBInstanceNotFound, RDS 2대 → 1대(운영만).
• ⚠삭제 명령은 코디가 못 돌렸다 — 비대화형 세션이라 broker 게이트 전에 거부(rules/tooling.md 🆕) → 페페가 직접 실행.
• 삭제 후 검증 = 스모크 8 OK/0 FAIL(삭제 전과 동일) · test·live HTTP 200 · 컨테이너 Up 16h · DB 88테이블/field 2,041/estimate 722 · DB 접속 에러 0 · env 분리 확인(테스트 127.0.0.1 / 운영 poin-dbinstance).

🆕 A8 — EBS 백업 신설 (페페 질문 "백업·스냅샷 설정됐나?" 에서 발견)

🔴실사 결과 EC2 백업이 아예 없었다 — 원래부터. DLM 0 · AWS Backup 0 · EBS 스냅샷 0 · AMI 0. 지금까지 티가 안 났던 이유 = 중요한 게 전부 RDS 에 있었기 때문. 이번 이전으로 테스트 DB 가 그 무방비 영역에 들어왔고, 🔴일일 논리 백업마저 루트와 같은 볼륨(stat device 동일 실측)이라 볼륨 사고 시 DB와 백업이 동시에 사라지는 구조였다.

• 신설 = DLM 정책 policy-027b7852ca6ddfea3(ENABLED) — 대상 VOLUME + 태그 Backup=daily, 매일 18:00 UTC(=KST 03:00), 7개 보관, CopyTags. 볼륨 vol-0f57e223d0a89419b(60GB gp3, 1개뿐)에 태그 부착. → 볼륨 전체를 뜨므로 테스트 DB·운영 앱 설정·nginx·인증서·env 가 한 번에 커버되고 기존 구멍(운영 앱 서버)도 같이 메워진다.
• 선행 = IAM 역할 AWSDataLifecycleManagerDefaultRole 신규 생성(계정에 없었다) + 관리형 정책 AWSDataLifecycleManagerServiceRole 연결. 🔑DLM --description 은 영숫자·공백·_- 만 허용 — 쉼표를 넣으면 InvalidRequestException(실측 1회 실패).
• 즉시 기준 스냅샷 snap-0c40a5eabe84b0ab0(이전 직후 상태 보존) 생성 — DLM 첫 실행이 18시간 뒤라 공백을 메운다.
• 백업 2층 구조 확정 = ①논리(빠른 복원) pfs_test_db_backup.sh 17:30 UTC=KST 02:30·7일 보관 ②물리(재해 복구) DLM 18:00 UTC=KST 03:00·7개. 🔑논리가 먼저, 스냅샷이 나중 — 그래야 스냅샷 안에 그날 덤프가 들어간다. cron 을 03:15→17:30 으로 옮긴 이유 = 옛 설정은 KST 12:15 점심시간에 돌았다(서버 TZ=Etc/UTC).
• 비용 = 증분이라 월 $1.5~2.5 추정. RDS-test 절감 $21.2 중 일부라 순절감 $19선 유지.

⏳ 다음 (인계)

1. 페페 육안 — pfs-test.poin.co.kr 로그인 → 발주서정리·견적·worklog 가 평소와 같은지.
2. 내일 확인할 것 = ①DLM 첫 스냅샷이 실제로 생성됐는지(KST 8/8 03:00 이후 describe-snapshots) ②cron 논리 백업 pfs_test_daily_2026-08-08.sql.gz 생성 여부 ③기준 스냅샷 snap-0c40a5eabe84b0ab0 completed ④RDS RI pfs-prod-rds-ri-2026-08 이 active 로 넘어갔는지 ⑤Cost Explorer 에 RI 할인 반영(하루 뒤부터 보인다).
3. ✅Phase B RI 구매 완료(2026-08-07 · 페페가 CLI 로 실행) — 코디가 offering ID 를 조건별 유일 매치로 특정해서 넘기는 방식을 썼다(옵션 오선택 여지 0). B1 EC2 eccbe392-a683-43e3-b6f0-9ef4d3a9528e = t3.medium · Linux/UNIX · standard · Region 스코프 · No Upfront · 수량 1 · state active · 2026-08-07~2027-08-07 · $0.0314/h. B2 RDS pfs-prod-rds-ri-2026-08 = db.t4g.micro · mysql · Single-AZ · No Upfront · 수량 1 · $0.02/h(구매 직후 payment-pending → active. 선결제 0 이어도 이 상태를 거치며 할인은 StartTime 부터). 매칭 실측 대조 = EC2(t3.medium·Linux/UNIX·tenancy default·온디맨드·running) / RDS(db.t4g.micro·mysql· MultiAZ false·available) 전 항목 일치 → 별도 연결 작업 없이 자동 적용. Region 스코프라 인스턴스가 ap-northeast-2c 여도 무관. ⚠B1 은 t3 패밀리를 벗어나면 무효(1년 내 Graviton 전환 계획 있으면 재검토).
4. 곁가지(오늘 주제 밖, 사실만) = EC2 가 Ubuntu 18.04 + Python 3.6.9(2023 EOL). 언젠가 교체 필요 — 그때가 인스턴스 재선정 기회. apt 저장소는 아직 살아 있다(EC2 미러 + security 정상 응답).

코드 변경 = pfs 리포에 검증 러너 1개 신규(scripts/_db_migration_smoke_check.py, 미추적 유지 — 커밋 없음). 사이트맵 재빌드 불요(페이지·라우트 변화 0).

🆕 (참고) 원 검토 메모 — 미니PC 이전 타당성

• 🔴전제가 틀렸다 = 테스트는 별도 EC2가 아니다. 운영·테스트가 같은 t3.medium 1대(i-03225ba8bc12a929e)에 8000/8001 포트로 얹혀 있다. 앱만 미니PC로 빼도 EC2 절감 0. 따로 있는 건 RDS 뿐(poin-dbinstance-test).
• 실측 비용(2026-07 · Cost Explorer) = 총 $86.4/월 — EC2 compute $37.44(t3.medium 720h) · EC2-Other $6.43(EBS·EIP) · RDS $42.44(인스턴스 $37.20 = db.t4g.micro 2대 + GP2 20GB×2 $5.24) · S3 등 $0.09. → 테스트 이전으로 실제 줄어드는 돈 = RDS-test 1대 $21.2/월(≈3만원, 전체의 24%). ※6월 RDS $57.83은 7월보다 높다(스냅샷·클래스 이력 추정, 미조사) — 러닝레이트는 7월 기준이 맞다.
• 환경 차이 = 관리가 갈린다(나쁜 쪽): 미니PC는 Windows, 운영은 Ubuntu+nginx1.14+uWSGI+systemd. ①uWSGI는 Windows에서 안 돈다 → waitress 등으로 갈아타면 테스트에서 통과한 게 운영 보증이 안 된다 (uwsgi-die-on-term-killsignal-conflict 같은 배포계층 사고를 테스트가 못 잡는다) ②배포경로 = push→Actions→SSM send-command인데 미니PC는 SSM 대상이 아니라 러너를 따로 만들어야 하고, 그러면 배포 절차 자체를 테스트할 수 없다(현재 테스트의 최대 가치) ③pfs-test.poin.co.kr+Let's Encrypt → Funnel/사설 경로로 바뀜 ④검증 러너 scripts/_*_check.py {test|prod}가 미니PC 다운·터널 끊김에 묶인다 (vscode-remote-ssh-poin-mini-timeout 전례) ⑤운영 데이터 사본이 사무실 밖 PC에 앉는다.
• 더 싸고 안 아픈 대안(코디 추천 순) = ①RI/Savings Plan 1년 무선결제(환경변화 0) — 공표요율 대략 EC2 -$11~14/RDS 운영분 -$6 = 월 $17~20 절감 ②RDS-test 삭제 → EC2 안에 MySQL 8.4 직접 설치 (같은 OS·같은 배포경로 유지, 절감 $21 전액, t3.medium 4GB에 테스트 부하는 미미) ③RDS-test 야간·주말 정지 (-$12, 단 7일 뒤 자동 재시작이라 스케줄러 필수). ①+② = 월 $39(45%) 절감, 환경 변화 거의 0.
• ⏳페페 몫 = 방향 택1(①+② 추천 / 미니PC 이전 강행 / 현상 유지).

🆕 NOW (2026-08-06) — 견적서 재작성 + 현장 단위 차수 이력 ✅운영배포 완료

• 운영 커밋 = deploy-live ff48c8b ← master c69c2d8+641ff82 5파일 선별 포워드(merge 아님). 대상 파일에 다른 미반영 커밋이 걸쳐 있었지만 git diff origin/deploy-live origin/master -- <file> 실측이 내 변경분뿐임을 확인하고 진행했다(커밋 목록은 cherry-pick 이력 탓에 과대계상 — playbook §2).
• 운영 RDS 선행 = ALTER TABLE estimate ADD COLUMN archive_yn CHAR(1) NOT NULL DEFAULT '0' AFTER remove_yn → 674행 전부 '0' 확인 후 배포(scripts/_estimate_archive_ddl.py, ENV_PATH=pfs-live.env, 멱등).
• 운영 검증(신설 scripts/_est_revisions_prod_check.py) = 18항목 ALL PASS · 읽기 전용. 🔑Playwright page.route 로 POST/PUT/DELETE(/select·/rewrite·/archive·삭제)를 아예 차단해 두고 돌렸다(차단기 발동 0 = 오조작 없었다는 증거). 확인 = 본견적 32건·보관 0·차수2↑ 현장 0 · 행에 「차수 1」·「재작성」 · 모달 GET 만으로 렌더(쌍용 홍은동 1차 6항목 6,500,000 「사용 중」, 사용 중 행엔 전환 버튼 없음) · 견적 단건·출력 200 · 현장검색 34건 카운트 1 · 월마감 후보 11건 불변 · 콘솔 0.
• 사이트맵 재빌드 = 그룹8·페이지49·미반영 10 → 2(남은 2 = 기존 AL 백로그). devplan pfs.html PENDING→DONE.
• ⏳페페 몫 = 운영 육안(/estimate/list-v2 → 아무 견적 「차수 1」 눌러보기. 실제 재작성은 진짜 현장에서만).

(테스트 단계 기록) 견적서 재작성(1차 보관 + 2차 메인) + 운영 708 이관

페페 지시 = "한 현장 견적서를 새로 작성해야 하는 경우가 있다(도면 디자인이 아예 바뀜). 기존 1차 작성분은 보관처리, 신규 2차 작성분을 본건 메인으로 앞에." → "테스트서버 작업 진행하고 운영서버의 modify-v2/708 현장 견적서를 옮겨줘. 1차 원본으로 삼고 테스트."

• 구현(master c69c2d8 → 테스트 자동배포 확인, 운영 미반영) = estimate.archive_yn char(1) DEFAULT '0' 하나로 끝냈다. 차수 컬럼·이력 테이블 없음. ① 🔑1:1 가드는 한 줄도 안 고쳤다 — select_site_search 의 estimate_count 서브쿼리에 AND e.archive_yn='0' 만 넣으니, 1차를 보관하는 순간 그 현장이 다시 선택 가능해진다. ② 목록 = 보관건 기본 숨김 + 「보관 포함」 체크박스, 「보관」 배지 + 배경 #eceff1(글자색은 안 건드림). ③ 「재작성」 = 1차 보관 → 헤더(현장·업체·담당자·지불조건·마진)만 물려받은 빈 2차 생성 → 그 수정화면으로 이동. 항목 복사 없음. 이름 … (2차) → … (3차)(정규식으로 차수 증가). ④ 「보관해제」는 그 현장에 활성 본견적이 없을 때만(1:1 유지). 추가건은 본건과 함께 보관(OR parent_estimate_no=). ⑤ 월마감 후보(select_candidates)에서 보관건 제외 — 안 빼면 1차·2차가 이중 집계된다.
• 🔴덤으로 잡은 것 = 실패가 성공으로 새어나간다 — 공용 ajaxSuccessProcess 는 code "2000" 만 실패로 보는데 서버 예외는 "9999" 라, 보관해제 거부 사유가 화면에 안 뜨고 성공처럼 지나간다 (RestResponse PFS-D002 미이관 구간). 이 화면 두 호출만 _v2ApiFail(data) 로 code 직접 판정.
• 운영 708 이관 = 「대우 용인 MH 견적서」(field 2109·에넥스/김동연, detail 50·sub 53·extra 0·43,563,000) → 테스트 견적 797. 테스트 708 은 이미 다른 견적(일레븐 파크사이드, 삭제됨)이라 번호를 못 쓴다. 참조(field 2109·company 4·member 400·user 1)가 테스트에 같은 번호로 이미 존재해 그대로 붙였다. 행 대조 50/53 전량 일치. ⚠합계만 11.09원 차이 = 운영 float 컬럼의 표시 밖 잔재(490417.03125 류)가 이관 때 정수로 정리된 것. 화면값·total_amount 는 동일.
• 검증 = 신설 scripts/_estimate_archive_check.py(미추적) 테스트 32항목 ALL PASS — 재작성 클릭→2차 수정화면 도착·헤더 프리필·항목 0·목록에서 1차 사라짐·「보관 포함」 복귀(배지·배경·버튼 구성)· 현장 견적수 1 유지·보관해제 거부 사유·월마감 후보 교체·콘솔 0, 끝에 원상복구(2차 삭제+1차 보관해제) 까지 확인. 뒤처리 러너 _estimate_archive_cleanup.py(항목 있는 견적은 절대 안 지우는 가드). 현재 테스트 상태 = 797 활성 1건만(페페가 처음부터 눌러볼 수 있게 깨끗이 되돌림).
• 사이트맵 재빌드 = 그룹8·페이지49·미반영 2→10(이번 커밋이 운영 미반영이라 정상 · /archive·/rewrite 신규 라우트 포함). devplan pfs.html PENDING 에 c69c2d8 등록(운영 DDL 선행 필요 명시).
• ⏳페페 몫 = 테스트 육안(/estimate/list-v2 → 현장명 「대우 용인」 검색 → 재작성 눌러보기). 운영 반영은 지시 때 — DDL(archive_yn) 먼저, 그 다음 배포.

🆕 현장 단위 차수 이력으로 개편 (페페 지시 26.8.6 · master 641ff82 테스트 배포)

페페 지시 = "보관 항목은 현장별 이력관리가 맞다. 지금은 보관 항목 찾기까지 과정이 복잡하고 1차·2차 위치가 안 붙어 있어 비교가 오래 걸린다. 한 현장 기준으로 확인·복구 가능한 구조로 개변. 1차를 복구하면 2차는 삭제가 아니라 보관. 항상 보관 안 된 항목 = 선택된 차수, 나머지는 보관."

• 🔑불변식 = 「보관 안 된 것이 곧 지금 쓰는 견적서」(현장당 정확히 1건). 그래서 되돌리기는 '보관해제'가 아니라 자리 바꾸기다 — 옛 차수를 고르면 쓰던 차수가 보관으로 내려간다(삭제 아님).
• 목록 행 「차수 N」(그 현장 차수 개수 = revision_count 서브쿼리) → 모달에 그 현장 전 차수를 한 표로: 차수·견적명·견적일·작성자·항목수·추가건·금액·상태. 최신이 위, 사용 중 행은 배경 #e8f5e9. 옛 차수에만 [이 차수 사용], 모든 차수에 [보기]·출력.
• 보관해제 토글 폐지 — PUT /<no>/archive → PUT /<no>/select. 활성 0 상태를 만들 수 없고, 되돌리기가 삭제를 요구하지도 않는다. count_active_main_on_field(거부 가드)는 죽은 코드라 제거.
• switch_active_estimate = 트랜잭션 2문(그 현장 전부 보관 → 고른 것만 활성). 추가건은 부모로 잡는다 (LEFT JOIN estimate p ON p.estimate_no=e.parent_estimate_no — 추가건은 field_no 가 비어 있을 수 있다). 재작성도 끝에 같은 스위치를 태워 옛 차수가 여럿이어도 한 번에 정리된다.
• 검증 = 신설 scripts/_estimate_revisions_check.py 21항목 ALL PASS(모달 2차 비교·전환· 🔑remove_yn=0 유지 실측·모달 그 자리 갱신·「사용 중」 항상 1건·목록 반영·현장 견적수 1·콘솔 0· 시작 상태 복원). 테스트 현재 = 801 사용 중 · 797 보관(페페가 눌러본 상태 그대로 돌려놓음).

보관건 열람·복구 경로 (페페 질문 26.8.6 · 읽기전용 실측 8항목 ALL PASS · 「보관해제」는 위 개편으로 대체됨)

• 열람 = 목록에서 「보관 포함」 체크 → 검색 → 보관 행(회색+「보관」 배지)의 [수정] 이면 항목·타입·금액이 그대로 열린다(실측 = 타입 5탭·항목 렌더·이름/현장/업체 정상). [출력] 도 됨(print-v2 200 · 엑셀 API 200). URL 직접(/estimate/modify-v2/<번호>)도 열린다. 🔑열어서 저장해도 보관은 안 풀린다 — update_estimate 가 archive_yn 을 안 건드린다(실측 archive_yn=1 유지).
• 복구 = 같은 자리의 [보관해제]. 단 그 현장에 활성 본견적이 없어야 한다(1:1). 2차가 살아 있으면 「이 현장에는 이미 사용 중인 견적서가 있습니다」로 거부 → 2차를 [삭제]한 뒤 해제하면 1차가 항목·금액 그대로 돌아온다.
• 🔴갭 = 2차를 살려둔 채로는 맞바꿀 수 없다. 활성 행에 수동 「보관」 버튼이 없어서(보관 경로가 「재작성」뿐) 2차를 내리려면 재작성으로 빈 3차를 만들거나 2차를 지워야 한다. 최소 수정 = 활성 행에 「보관」 버튼 1개 (API PUT /api/estimate/<no>/archive {archive_yn:'1'} 는 이미 있다 · JS 는 unarchiveV2 대칭 1함수). ⏳페페 지시 대기.
• 테스트 현재 상태 = 797 보관(항목 50 온전) + 801 활성 빈 2차(페페가 재작성을 눌러본 상태 — 코디가 안 건드렸다).

(이전) 계획 확정 기록

페페 지시 = "한 현장 견적서를 새로 작성해야 하는 경우가 있다(도면 디자인이 아예 바뀜). 기존 1차 작성분은 보관처리, 신규 2차 작성분을 본건 메인으로 앞에. 계획 먼저."

• 🔴실측 = 지금은 2차를 만들 방법이 아예 없다 — estimate_regist_v2.js:2142 가 현장 선택 팝업에서 "이미 견적서가 있는 현장입니다. 현장:견적서는 1:1입니다" 로 현장 선택 자체를 막는다. 근거 카운트 = field_dao.select_field_list_for_estimate 의 estimate_count(추가건 포함·remove_yn='0').
• 파급 조사 = estimate 를 참조하는 다른 모듈은 월마감뿐(monthly_close_dao :177 후보수집 · :89 집계). worklog·발주서정리·현장은 field_no 기준이라 무관. 견적 목록 v2 = 본견적만(parent IS NULL)·생성일 desc.
• 확정 계획(P1) = ①컬럼 1개 estimate.archive_yn char(1) DEFAULT '0'(차수 컬럼·이력 테이블 안 만듦) ②1:1 가드는 안 건드린다 — estimate_count 서브쿼리에 AND archive_yn='0' 한 줄이면 1차를 보관하는 순간 그 현장 신규 등록이 저절로 열린다 ③목록 = 보관건 기본 숨김 + 「보관 포함」 체크박스(페페 택1), 보관 행 회색+배지, 정렬 그대로라 2차가 자동으로 위 ④「보관」 버튼 = 본건+추가건 동반, 토글 해제 시 같은 현장에 활성 본견적 있으면 차단 ⑤「재작성」 = 1차 보관 → 새 등록 화면 헤더 프리필(현장·업체· 담당자·마진율만, 1차 항목 복제 안 함 — 페페 택1) ⑥월마감 후보·집계에서 보관건 제외(안 빼면 이중 집계) ⑦검증 러너 scripts/_estimate_archive_check.py {test|prod}(DB+실브라우저), 테스트 배포까지.
• ⏳페페 몫 = 착수 지시(운영배포는 별도 지시 때).

🆕 NOW (2026-08-06) — 대우 용인 오엠씨 탭 1페이지 초기화 + 재입력(운영 데이터, 코드변경 0)

페페 지시 = "\\192.168.0.101\공유폴더\2026현장\원부자재발주서\07월\에넥스 대우 용인 푸르지오 MH 원부자재발주서.xlsx 의 오엠씨 탭 1페이지 내용을 바꿨다. 행자체가 사라지거나 수정을 했으니 기존 동기화 내용을 초기화하고 이 탭만 PFS field/orderpaper 에 새로 입력해줘. 운영배포."

• 오엠씨 탭은 섹션이 1개 = 「1페이지」 = block_key fe00af48…(= sha1(파일|오엠씨|0|R)) 하나로 딱 떨어진다. 엑셀 현재값 = 11항목(발주번호 2·3·5·6·7·8·10·11·12·13·14), 발주 2026-08-06 · 입고 2026-08-11.
• 왜 그냥 동기화로는 안 됐나(초기화가 필요한 실제 이유 2개, 운영 실측): ① 그 블록 4행이 del_manual='1'(화면에서 ✕ 로 지운 상태)이라 동기화 UPDATE 가 remove_yn=IF(del_manual='1','1','0') 로 계속 '1' 을 박는다 → 엑셀에 살아 있어도 화면에 영원히 안 뜬다. ② 남은 7행엔 옛 사용자편집·재고가 붙어 있었다 — receive_date_user='2026-07-14'(화면은 COALESCE 라 엑셀 입고 08-11 대신 07-14 를 보여준다), stock 39/7 등이 발주량과 무관한 옛 라운드 값. item_key 가 sha1(파일|탭|섹션|자재구분|**idx**) 라 중간 행이 빠지면 idx 가 밀려 옛 행의 편집이 다른 자재에 상속된다. 그래서 「초기화」의 실체 = 이 블록만 행을 지우고 신규 INSERT 로 다시 받기.
• 실행 = orderpaper-sync/_reset_daewoo_omc_prod.py(SSM) → 12행 DELETE(active 7 + removed 5, 잔여 0) → python orderpaper_sync.py prod R_omc_reset_20260806 → ins 11 / upd 1746 / removed 0. 가드 = source_file + block_key 정확일치 + 전 행 vendor='오엠씨'·material_type='R'·source_kind='nas', 삭제 전 12행 전량 JSON 출력(롤백 자료). 사용이력(orderpaper_usage_history) 0건 확인 후 삭제(있으면 중단하는 가드). orderpaper_site_map 은 손대지 않아 현장연결 field_no=2109 유지.
• 검증(신설, 미추적) = orderpaper-sync/_verify_daewoo_omc_prod.py(운영 DB 33항목 ALL PASS) + scripts/_op_daewoo_omc_screen_check.py prod(운영 화면 43항목 ALL PASS, 콘솔 0). DB = 11행·엑셀 11항목 전량 대조(품명·규격·발주량)·remove_yn=0·del_manual=0·status=대기· *_user 전부 NULL·stock=발주량·발주 08-06/입고 08-11 · 다른 탭 행수 초기화 전과 동일. 화면 = 발주서정리 「대우 용인」 카드 → 오엠씨 블록 「11건 · 발주 8.6(목) · 기본입고 8.11(화)」, 항목행 11개 렌더 + 자재관리 탭에도 노출(3개월 창 통과 — 입고 8.11 이 창 안).
• 커밋 없음 = 코드 변경 0(운영 RDS 데이터 작업 + 미추적 스크립트). 사이트맵 재빌드 = 그룹8·페이지49· 미반영 2(초기화 전과 동일 · 둘 다 기존 AL al-orderpaper·al-profile 백로그).
• ⏳페페 몫 = 운영 육안(/field/orderpaper → 「대우 용인」 → 오엠씨 블록 11건 · 지웠던 2·3·5·6번이 다시 뜨는지 · 입고일이 8.11 로 보이는지). ⚠재고량이 발주량으로 초기화됐으니 손으로 넣어둔 재고가 있었다면 다시 기입해야 한다.

🆕 NOW (2026-08-06) — 카톡관리 수정창 자동높이 + 편집 중복 방지 3중 게이트 운영배포 완료

페페 지시(QA 보고 /field/worklog) = "수정 내용이 많은데 수정창 높이가 너무 낮다. 텍스트 내용에 맞춰서 수정창 높이도 늘려줘. 그리고 사용자가 편집하면 내용이 중복되지 않게 코디가 체크하는 프로세스 있는지 확인해서 보완해줘. 운영배포."

• 수정창 = .kb-row textarea 가 min-height:64px 고정이라 10줄짜리 항목도 3줄만 보였다. → kbGrow() 가 scrollHeight 로 높이를 맞추고 입력마다 재계산(늘고 줄고 둘 다). 상한 max-height:60vh (그 위로만 스크롤 — 창이 화면을 삼키지 않는다). resize:vertical 은 남겨 사람이 더 늘릴 수 있다. 운영 실측 = 3줄 항목 76px → 15줄 309px → 120줄 570px(=60vh 상한, 그때만 스크롤).
• 중복 검사는 「있는지 확인」의 답이 "어디에도 없었다" — 화면·서버·데몬 어느 층에도 없었다. 3중으로 신설. 판정 기준은 셋 다 같다 = 같은 섹션 · 첫 줄 동일(표기 접두사 [완료]·※추가·※수정 는 떼고 본다). 첫 줄로 보는 이유 = 그게 행 id 의 근거(board_rows._ids = sha1(섹션+첫줄+등장순번))다. 같은 문구가 둘이면 id 가 등장순번으로만 갈려서, 앞 행이 사라지는 순간 뒤 행의 id 가 조용히 바뀐다 → 그 뒤의 수정·삭제가 엉뚱한 행을 잡는다. 그래서 그런 쌍을 애초에 못 만들게 막는 게 근본수정이다. ① 화면(kbDupRow) = 「적용(표시만)」 단계에서 막고 토스트로 알린다. 아직 저장 안 한 표시(KB_PEND)까지 반영해 비교한다 — 수정 표시가 걸린 행은 그 수정문으로, 내려갈 행(완료·취소·삭제)은 대상에서 뺀다. ② 서버(add_op) = 미러(rows_json) 대조로 같은 내용 거부 + 같은 행에 대기 중 명령이 있으면 거부. 뒤엣것이 중요하다 — 미러는 데몬이 반영해야 갱신되니 그 30~60초 사이에 같은 행을 또 고치면 화면은 옛 내용을 보여주고, 나중 명령이 앞 명령을 덮어써 방금 쓴 내용이 조용히 사라진다(중복 등록 → 유실). ③ 데몬(board_rows.edit/restore) = 마지막 관문. 웹이 PFS·devplan 둘이고 ack 유실 시 명령이 재배달 되므로(그때 restore 는 같은 줄을 또 붙인다) 화면 검사만으론 못 막는다.
• 검증 = 신설 scripts/_kakao_board_edit_check.py {test|prod} [--api](미추적) — 테스트 26 + API 6 · 운영 26 ALL PASS. 높이는 픽셀 실측(열자마자 스크롤 0 → 늘림 → 줄임 → 60vh 상한), 중복은 같은 섹션 다른 행 문구로 실제 클릭. 운영은 저장을 누르지 않는다(누르면 고객 단톡방이 바뀐다).
• scripts/test_kakao_board.py 13→15항목(대기 중 같은 행 거부·같은 첫 줄 거부/다른 섹션 허용/자기 자신 제외),
• board_rows.py 자체검사(중복 수정 거부·다른 섹션 허용·복원 재배달 거부).
• 커밋 = master cec85c6+229b61d → deploy-live 11e235e(4파일 포워드, merge 아님). poin-agent a5a5e45(로컬 리포). 데몬 재시작 완료(watcher PID 12084). 사이트맵 3→2(/field/worklog 걷힘).
• ⏳페페 몫 = 운영 육안(카톡관리 → 방 펼쳐 긴 항목 ✎ → 창이 내용만큼 열리는지 · 다른 행 문구를 붙여넣고 「적용」 → 「중복이라 등록하지 않았습니다」 토스트가 뜨는지).

🆕 NOW (2026-08-05) — 카톡관리 「변동 반영 이력」 ✖ = 소프트딜리트(숨김 이력) 운영배포 완료

페페 지시 = "카톡게시글 관리에서 변동 반영 이력 항목은 삭제가 소프트딜리트가 아니라 실제삭제라고 안내메시지가 나온다. 소프트딜리트(숨김항목으로 이동)로 수정해줘. 운영배포."

• 원인은 안내문이 아니라 구멍이었다 — 이력 행은 로그라서 오조작 방지로 ✔완료·⊘취소를 뺐는데(2026-07-28), 그 결과 ✖ 말고 내릴 방법이 없는데 그 ✖ 가 실제 삭제였다. 다른 행은 완료·취소로 이미 소프트 경로가 있다. → 이력 행의 ✖ 만 action:'hide', status:'삭제' 로 바꿔 숨김 이력에 남기고 ↩ 복원이 된다. 다른 행의 ✖ 는 손대지 않았다(2026-07-28 페페 지시 "종결 항목 빠른 정리" — 지시 밖).
• 두 리포를 같이 고쳐야 한다 = PFS VALID_STATUS 와 사무실 PC 데몬 board_rows.STATUSES 가 짝. PFS 만 늘리면 데몬이 ValueError → 화면엔 「반영 실패」로만 뜬다. 순서 = 데몬 먼저 + 재시작 → 배포. 상주 sgc/watcher.py 는 import 를 붙들고 있어 재시작 필요(상승권한 불요·완료), 예약작업 PFS-KakaoBoard-Sync(1분)는 매번 새 프로세스라 파일 수정 즉시 반영. 상세·재시작 명령 → rules.md 🆕
• 판정은 기존과 같은 한 줄(섹션명에 '이력') 재사용 — 새 API·새 컬럼·새 테이블 0. 화면엔 이력 행에 data-log="1", ✖ 툴팁 2종("숨김 이력으로 보냅니다(복원 가능)" / "이력에 안 남습니다"), 숨김 이력 「삭제」 라벨은 빨강. devplan kakao-ops.html 도 같은 라벨색만 맞춰 뒀다.
• 검증 = 신설 scripts/_kakao_board_softdelete_check.py(미추적) — 테스트 28항목 + 운영 24항목 ALL PASS. 테스트는 --api 로 실왕복까지(status=삭제 수락 · 허용 밖 「보류」는 여전히 거부 · 큐 저장 확인 → ack 로 정리). 운영은 저장을 누르지 않는다 — 누르면 고객 단톡방 게시글이 실제로 바뀐다. 클릭→KB_PEND 페이로드까지만 확인.
• board_rows.py 자체검사(실제 「■ 변동 반영 이력」 섹션에서 hide('삭제')→restore 왕복) · test_kakao_board.py 13항목. ⚠1차 실행 5건 오탐 = 검증이 방을 안 가뒀다. 행 id 는 방이 달라도 같은 문구면 같은 값(sha1(섹션+본문+순번)).
• 커밋 = master c0129d2 → deploy-live 0a75e3a(3파일 선별 포워드, merge 아님 — AL 미배포건이 끌려온다). poin-agent 4889937(로컬 리포·리모트 없음). 사이트맵 재빌드 2회 = 배포 전 미반영 3 → 배포 후 2 (/field/worklog 주황 걷힘, 남은 2건은 기존 AL al-orderpaper·al-profile).
• ⏳페페 몫 = 운영 육안(/field/worklog → 카톡관리 → 방 펼쳐 「변동 반영 이력」 행 ✖ → 저장 → 30초 뒤 숨김 이력에 「삭제」로 뜨는지).

🆕 NOW (2026-08-05) — 견적서 엑셀 양식 파일 채우기 전환 · 운영배포 완료 + 운영 다운로드 E2E

페페 판단 = "①「아래와 같이 견적합니다」 타입명 살린 상태 유지 ②결재칸 현재대로 유지. 이 양식으로 pfs 견적서 생성 파일 교체해라. 운영 배포. 실제 견적건 1개 playwright로 다운받아서 동일 test 파일에 저장까지 테스트. 운영서버에서 다운로드 테스트."

• 운영배포 = deploy-live a485b23(4파일 포워드) + 9482849(일자 서식 후속). master 01d5f43·b11c8a5. merge 아님 — 파일단위 포워드. 사전확인 = 대상 4파일에 걸친 미반영 커밋이 내 것뿐임을 --cherry-pick --right-only로 확인. 배포 후 잔여 미반영 = AL 12파일뿐(기존 백로그), 견적서 파일은 전부 반영됨.
• 🆕다운로드 E2E = scripts/_estimate_excel_download_e2e.py {test|prod} [저장경로] [견적번호]. 로그인 → 견적목록 → 품목 있는 건 자동선별 → 출력화면 → 「엑셀」 버튼 클릭 → 실제 내려받은 파일을 열어 템플릿과 서식 대조. 테스트 10항목 PASS / 운영 11항목 PASS(운영 견적 744 「넵스 쌍용 홍은동 MH」 — NAS 실물과 같은 현장, 본건 2블록·품목 6줄·6,300,000 일치, 콘솔 0).
• 🔑함정 3개(전부 이번에 물림): ① 로그인은 폼 submit 이 아니라 JS login() → page.evaluate("() => login()") 후 URL 변화 대기. ② 목록 행에 견적번호가 안 박혀 있다(JS 클릭 핸들러) → /api/estimate/ 응답에서 뽑는다. 봉투 키는 message(data/result 아님). ③ 블록 수를 ws.max_row 로 세면 안 된다 — 인쇄영역($O$n)에서 센다. 템플릿은 인쇄영역 밖에 행높이만 450행까지 있다.
• 후속 수정 1건 = 일자가 비었을 때 텍스트 서식("일자: "@)으로 바꾸던 것을 중단. 빈칸에 「일자: 」만 찍히고 템플릿 서식과도 어긋났다. 날짜로 못 읽는 문자열이 실제로 있을 때만 전환.
• 🔴보고 오류 정정 = 1차 답변에서 "TEST 폴더에 5개 넣었다"고 했으나 실제로 NAS 엔 2개만 갔다. Bash heredoc 의 '\\2026현장' 이 8진 이스케이프로 먹혀 C:\192.168.0.101\공유폴더6현장\... 이라는 로컬 경로에 쓰였고, os.path.exists() 가 True 라 성공으로 보고됐다. 지금은 정리 완료 — 경로는 포워드슬래시, 저장 후 목적지 listdir 로 되읽어 확인.
• 결과물(\\192.168.0.101\공유폴더\2026현장\견적\TEST) = 00_읽어주세요.txt · 01_…(실물과 동일데이터).xlsx/pdf · 01_참고_추가건 포함 샘플.xlsx/pdf · 02_운영서버 다운로드_넵스 쌍용 홍은동 MH 견적서.xlsx/pdf.
• 사이트맵 재빌드 = 배포 전·후 모두 그룹8·페이지49·미반영 2(둘 다 기존 AL — 견적서 출력은 화면 뒷단 API 파일이라 페이지 표시엔 안 잡힌다).
• ⏳페페 몫 = 운영 육안(견적서 출력 → 엑셀) + TEST 폴더 02번 확인.

(1차) 견적서 엑셀을 NAS 양식 파일 채우기로 전환 — 배포 전 결과물 제출

페페 지시 = "실제 결과물(07월\넵스\넵스 쌍용 홍은동 MH 견적서.xlsx)·기본 양식(양식 견적서.xlsx) 2파일 확인해서 PFS 견적서 엑셀 양식 수정. 선굵기·셀배경색·상하좌우 여백 등 모든 것이 동일해야 한다. 양식 파일을 새로 만들기보다 기존 파일을 활용해 데이터 입력하는 쪽으로. 결과물은 견적\TEST 폴더에 작업순번."

• 방식 전환 = 코드로 서식을 다시 그리던 build_excel 을 버리고 NAS 양식 파일 자체를 리포에 두고 값만 채운다. 템플릿 api/pfs/estimate/service/estimate_form.xlsx = NAS 원본 바이트 동일. 앞으로 양식이 바뀌면 코드가 아니라 이 파일을 갈아끼운다. (web/static 밖에 둔 이유 = 정적경로면 표본 견적 내용이 그대로 공개된다.)
• 시트 확보 = 템플릿 「종합」=요약 원본 / 「본건」=금액시트 원본(요약1+상세4 블록). 추가건은 「본건」을 copy_worksheet. 블록이 모자라면 상세 블록(46~90행) 서식을 복제. 「추가1」 템플릿 시트는 버린다.
• 결재칸만 예외 — 템플릿에선 도형 그룹이라 openpyxl 이 못 살린다 → 템플릿 300dpi 실렌더 크롭 PNG로 대체, 앵커는 템플릿 그대로(J39 우측 ~ O 끝 · 39~41행). 도장도 템플릿 원본 jpg(67×71)로 교체.
• 검증 = 신설 scripts/_estimate_excel_form_check.py 58항목 ALL PASS(DB 없이 DAO 스텁). 핵심 = 서식 diff 0 — 내 출력 vs 템플릿을 셀 단위(테두리·배경·폰트·정렬·표시형식) + 행높이·열폭·병합·여백·페이지설정 전수 대조. 케이스 4종(기본 / 타입7종=블록복제 / 부분출력 본건만 / 추가건만). 추가로 내 출력 「종합」 vs NAS 실물 「종합」 서식 diff = 0. Excel COM 실계산 확인 = 종합 6,640,000 = 본건 6,500,000 + 추가1 140,000. 파일 438KB→104KB.
• 결과물 = \\192.168.0.101\공유폴더\2026현장\견적\TEST\01_넵스 쌍용 홍은동 MH 견적서(PFS출력).xlsx(+ 같은 이름 .pdf). NAS 실물과 같은 데이터로 뽑아 1:1 대조 가능.
• 커밋 master 01d5f43. 배포 안 함(테스트 서버 자동배포만). 사이트맵 재빌드 = 그룹8·페이지49·미반영 2(둘 다 기존 AL 건 — 견적서 출력은 화면 뒷단 API 서비스 파일이라 페이지 미반영 표시에는 안 잡힌다).
• 안 한 것 = 이제 안 쓰는 web/static/img/estimate_supplier_block.{jpg,png} 와 tools/gen_supplier_block_png.py· gen_approval_box_png.py 는 그대로 뒀다(지시 밖 · 페페 확인 후 정리).
• ⏳페페 몫 = TEST 폴더 01번 결과물 육안 → 재지시(고칠 곳 지목). 함정·규칙 → rules.md 🆕

🆕 NOW (2026-08-05) — 배차목록 인라인 통합 검색창 추가 + 상단 기사칸 삭제 운영배포 완료

페페 지시 = "배차목록에 모든 항목 통합 검색용 인라인 검색창 추가. 출발도착 검색창 좌측으로 약간의 여백두고. 상단 search filter에서 기사 검색창은 삭제. 운영배포."

• 파일 1개뿐 = web/templates/basic/dispatch/dispatch_list.html(템플릿이라 캐시버스터 불요). master 0d96fe9 → deploy-live 668801e.
• 통합 검색은 서버가 아니라 행 데이터에서 한다 — dcRows의 각 행이 SELECT a.* + 조인컬럼이라 화면 표에 없는 값(기사명·기사연락처·비고·비고2·인수자연락처·물품)까지 이미 들어 있다. rowAllText(r) = 행의 모든 스칼라 값을 한 문자열로 join → 부분일치. 새 API·새 컬럼 0. 운영 실측 = 기사 "박경" 입력 시 56건 중 1건.
• 배치 = 인라인 검색줄(.dc-results-head)의 첫 칸, 출발 입력칸과 여백 22px(래퍼 gap:8px + margin-right:14px). 기존 출발·도착과 AND.
• 상단 SEARCH FILTER의 srchDriver 삭제 = 입력칸 + searchFilter args driver_name + resetFilter 참조 3곳 동반 제거. DAO는 손대지 않았다 — select_dispatch_search_list가 args.get("driver_name","")이라 미전달이면 조건이 안 붙는다(운영 왕복 1,673건 정상).
• 곁다리 수정 1줄 = renderTable() 끝에 applyInlineFilter(). 원래는 「조회」를 누르면 인라인 검색어가 그대로 남은 채 필터만 조용히 풀렸다(기존 출발/도착도 같은 결함). 새 칸만 고치면 셋 중 하나만 맞는 꼴이라 공통 지점에서 잡았다.
• 검증 = scripts/_dispatch_inline_search_check.py(신설·scripts/.gitignore로 커밋 제외) 18항목 × 테스트·운영 ALL PASS — 좌표 실측(통합 right < 출발 left, 같은 줄, 여백 22px) · 숨김필드 검색 · 없는 키워드 0건 · × 복원 · 통합 AND 출발 · 재조회 후 유지 · driver_name 미전달 API · 콘솔 0.
• 선별 배포(merge 아님) = git checkout origin/master -- <파일> 후 커밋. merge하면 AL 미배포건(al-orderpaper·al-profile)까지 끌려온다. 사전확인 = 이 파일에 걸친 미반영 커밋이 내 것 1개뿐임을 git log --cherry-pick --right-only로 확인.
• 사이트맵 재빌드 2회 = 배포 전 미반영 3(/dispatch/list 주황) → 배포 후 2(주황 걷힘, 남은 2건은 기존 AL). devplan pfs.html DONE 배열 갱신.
• ⏳페페 몫 = 운영 육안(/dispatch/list).

🆕 NOW (2026-07-30) — 신영 광주 챔피언스시티 MH 견적서 운영등록 완료 (본건 740 · 추가1 741)

페페 지시 = NAS 견적서 xlsx를 운영서버 등록, "본건 견적 생성 후에 추가건:추가1 항목으로", 현장 field_no 1973(=신영 광주/넥서스/MH), 운영배포 승인.

• 입력이 도어발주서 xlsm이 아니라 견적서 xlsx(단가=고객 확정가) → 기존 스킬로 안 되어 판독부터 재수행. 단일 시트 추가1 = p1 요약(추가1 1,027,000 + 운임 150,000 = 1,177,000) + p2 상세(섹션헤더 2 + 품목 13줄 = 1,027,000).
• 🔑이 양식이 PFS 출력양식(estimate_print_service)과 1:1임을 확인하고, 매핑을 추측하지 않고 렌더러 셀 주소에서 역산했다. 실제로 요약행은 A=현장명 C=항목명이라 A열에서 항목명을 읽으면 '운임'이 현장명으로 잡힌다(초안에서 발생 → 수정).
• 등록 = ①본건 740 신영 광주 챔피언스시티 MH 견적서(빈 컨테이너 0원 — 이 파일에 본건 내용 없고 NAS 전량 검색에도 본건 견적서 파일 없음) → ②추가건 741 추가1(13줄, type_name='추가1', parent 740) → ③기타부가비 운임 150,000 (신규자재 운임).
• 결정 3건: type_name=엑셀 p1 요약행 이름 추가1(선례 738과 일치) · 운임=transportation_cost 아닌 estimate_extra_cost(물류비 라벨 고정·비고 불가) · 마진=master 0+detail NULL(master를 자동으로 두면 넥서스 15.5%가 얹혀 금액이 부풀려진다).
• 미수집 = 섹션헤더 2행(128타입 50-010 몸통재·84D타입 HS2661 몸통재) — PFS detail에 대응 필드 없고, 타입 분리하면 p1 요약이 1→2줄로 바뀌어 이미 발송된 문서와 달라진다.
• 검증 4단 ALL PASS = 금액 3중 교차검증 → VERIFY 사전조회(현장·중복 0) → 등록 왕복 대조 불일치 0 → 출력 엑셀 실제 다운로드(353,851B, 시트 종합/본건/추가1) vs NAS 원본 셀 대조 불일치 0.
• 기존 동작(내 등록 탓 아님, 선례 738 동일 실측): 추가건 시트 요약행 A열 현장명 공백(select_sub_estimates가 field_name 미반환) · 담당자는 업체 refer_man(고재형 이사)로 표기.
• pfs 리포 코드 변경 없음(데이터 등록만) → 커밋·배포 없음. 스크립트 = C:\dev\order-automation\build_and_register_shinyoung_add1.py.
• ⏳페페 몫 = 운영 육안 + 본건 740에 본건 내용 채울지 결정(현재 0원). 상세 → session-2026-07-30-shinyoung-add1-estimate.md · 절차 = playbook.md §7 · 규칙 = rules.md 🆕

🆕 NOW (2026-07-29) — 미반영 A·B 그룹 운영배포 완료

페페: "미배포건이 있다. A,B 그룹 먼저 운영배포한다." (D005 배차사진 경로 버그는 "배포만, 버그는 P0에서")

• A 화물앱 배차 3건 → deploy-live 83540c8(master f39bdd8·1fa41be·3fa0175). DB는 ensure_freight_cols 런타임 멱등 ALTER라 마이그 불요.
• B 월마감 5건 → deploy-live 70ba185(master dae788e·26c49cd·c684883·ce9b34e·34ab1c3). 운영 RDS 선행 완료 = monthly_close·monthly_close_item 생성 + menu_catalog menu_no=46(적용 전 스냅샷 tables:[]/menu:None 확인). 권한 추가작업 불요 — has_menu_permission은 자사에 명시 row 없으면 기본 허용.
• 배포 경계는 커밋 수가 아니라 파일 diff로 판정(07-27 파일단위 포워드 탓 patch-id 비교는 28건으로 부풀려짐) → 37파일을 A 8·B 14·AL 15(범위 밖)로 분리. ⚠공유 파일 사전확인이 핵심: api/config.py 미반영분은 월마감 2줄뿐, mysql_util.py는 A의 execute_id뿐 → 통째 포워드해도 AL 미유입. (시드의 "config.py 통째 포워드 금지" 경고는 monthly_close가 미배포이던 시절 조건 — 이번엔 뒤집혔다. 매번 diff를 본다.)
• 검증 = 운영 HEAD 70ba185 · 서비스 active · /login 200 · /estimate/monthly-close 200 · /api/monthly-close 200 · /api/dispatch 405(GET 미지원=등록됨) · 잔여 diff는 AL 15파일뿐.
• 안 한 것 = 마감 데이터 시딩(운영 견적 기준 재판단 필요, 별건) · D005 배차사진 경로(code-qa field-dispatch 파트).
• 🆕후속 QA(같은 날): 페페 지시로 화물앱 접수 버튼 기능 비작동 — requestFreight() 앞 게이트 3줄(FREIGHT_ENABLED=false → dcToast('준비중입니다')), 기존 로직 보존(재개 시 값만 true). master 4433226(+검증 3288f1e) → deploy-live af4b72d. 검증=신설 scripts/_dispatch_freight_ui_check.py 실제 클릭, 테스트 9/운영 9 ALL PASS(문구·confirm 0·freight API 0·콘솔 0).
• ⏳페페 몫 = 운영 육안(월마감 페이지·화물 배차 목록). 상세 → session-2026-07-29-deploy-ab-freight-monthlyclose.md

🆕 NOW (2026-07-29) — AL발주서 QA 8건 (테스트 배포 · 운영 미배포)

• 페페 QA 리포트 8건(/field/al-orderpaper). #2만 해석이 갈려 착수 전 1문항 그릴링 → 페페 선택 = "헤더에 업체 여러 줄 + 그리드 컬럼에서 선택".
• #1 인쇄: "AL업체 제목 바로 아래 프레임 굵은 선만" = 데이터가 아니라 인쇄 레이아웃 문제. @media print의 body *{visibility:hidden} 토글이 모달(transform:translateX(-50%)+max-height:92vh+overflow:auto) 안 내용을 잘랐다. → CSS를 더 만지지 않고 인쇄 대상만 담은 iframe 문서(printSheets())로 분리. 부수 = 양식 헤더 colspan 합이 본문보다 1 커서 우측에 빈 컬럼이 남던 것(n-3→n-4).
• #2 업체 다중등록: 헤더 +AL업체/+유리업체로 업체행 추가, 그리드에 AL업체·유리업체 select(빈칸 = 첫 업체로 일괄). 미리보기·엑셀은 업체마다 발주서 1장(업체 묶음이 블록을 통째로 차지 — 한 블록에 두 업체가 섞이면 수신처가 틀린 발주서가 나온다). 양식 블록(AL 9·유리 5)보다 필요 장수가 많으면 조용히 누락 금지 → 400 + 사유.
• 저장 = al_orderpaper.vendors(JSON) + al_orderpaper_item.al_vendor/glass_vendor(patch44, DAO ensure_tables()가 멱등 ALTER → 수동 마이그 불필요). 첫 업체는 기존 단일컬럼(al_vendor/glass_vendor)에 그대로 유지 → 목록·검색·구 페이로드 무손상(E2E로 확인).
• #3 색상 지침: 브레이크다운 #94a3b8→#333(블랙 80%). 페페 지시로 "폰트 색상 블랙 70% 이상"을 pfs 기본 지침에 등록 → 신설 projects/pfs/rules.md.
• #4 계산셀(AL치수·목대·유리) font-weight:700→400, 색상 #0f172a 유지. #8 그리드 width:max-content; min-width:100% — 지정폭이 하한이 되어 눌려서 잘리던 컬럼이 늘어난다(입력칸은 width:100%라 스스로 못 늘어남). 품명 150→175px, 목대·유리 100→124px.
• #5 엑셀: 빈 블록을 print_area 밖으로 미루던 것 → 행을 실제 삭제(_trim_blocks, 병합 해제 후 delete_rows; AL 180행→20행). 부수 = _fill_label_row_addr의 조기 return 탓에 입고처가 첫 블록에만 채워지던 것(2장부터 공란) → 전 블록.
• #6 <datalist> 폐기 → 자체 인라인 드롭리스트 attachCombo()(부분일치 목록, Enter = 강조행 자동입력, 부가정보 표시). #7 업체행을 CSS grid(display:contents)로 바꿔 5컬럼 왼쪽 라인 픽셀 일치 + 담당자·전화·팩스 폭 오토(전화 031-355-9705(내선206) 잘림을 스크린샷에서 발견해 담당자 외 2칸까지 확대).
• 커밋 master b69d325(본 구현)→f6bcfb2(#7 보완)→6f9732c(#1 colspan). 테스트 8001 자동배포 확인.
• 검증 = 엑셀 생성기 자체검사(빈블록·업체분리 assert) + 테스트 E2E 18항목 PASS + UI Playwright 27항목 PASS(콘솔오류 0). 상세=session-2026-07-29-al-orderpaper-qa8.md.
• ⏳운영 배포 안 함 — 지시문에 "운영 배포" 문구가 없다(deploy-live 절대 규칙 = 페페가 채팅에 직접 입력해야 함). 페페 지시 대기.
• ⏳페페 육안 = 실제 Ctrl+P 인쇄 결과 + 다운로드 엑셀(헤드리스는 window.print() 무동작이라 iframe 내용까지만 검증). ⚠컬럼 2개 증가로 그리드 총폭 ≈1600px > 래퍼 1210px → 가로 스크롤 발생(#8 지시대로면 정상, 거슬리면 .al-wrap 최대폭 확대가 대안).

🆕 NOW (2026-07-29) — AL설정(엑셀 설정탭) 관리 페이지 CRUD (운영 배포 완료)

• 페페 지시: NAS 원부자재발주서.xlsx 「설정」 탭(AL 프로파일별 공제상수 49행)을 관리 페이지로 만들고 CRUD / AL발주서 페이지에 접속 버튼 / 새 발주서 작업 중에도 추가·수정 가능 / 운영배포. + 추가지시 업체정보 란 컴팩트화(발주내용 테이블 공간 우선).
• ⚠지시문의 첫 경로 부자재 발주서 일지.xlsm은 시트가 주문조회/RawData뿐 → 페페가 원부자재발주서.xlsx로 정정. 이 파일이 기존 al_calc.py의 원 출처.
• 저장소를 JSON 자산 → RDS 테이블 al_profile(patch43)로 이전. 기존 assets/seoljeong_constants.json은 초기 시딩·「엑셀 원본 복구」 버튼의 기준값으로만 남긴다(파일 편집 방식은 배포마다 사용자 편집이 날아가서 탈락). DAO ensure_tables()가 비어 있을 때 1회만 시딩 → 테스트·운영 모두 마이그레이션 수동실행 불필요.
• 행 순서(sort_no) = 엑셀 VLOOKUP 첫매치 순서. 중복 품명 2건(AA*494(작은손)+3면AA-496·AA*495(큰손)+3면AA-496) 실재 → 위 행이 이기고 아래는 死행. 화면 NO칸을 노랗게 칠해 死행을 보이게 함.
• 신규 /field/al-profile(사이드바 미등록 — 접근은 AL발주서 버튼 2곳뿐, 지시 그대로). 저장은 화면 전체 1콜 POST /api/al-orderpaper/profiles → 서버가 soft delete → upsert 순.
• 작업 중 수정 동선 = 새 창(작성 중 발주서 유실 방지) + 창 복귀(window focus) 시 설정 재조회 + 전 행 재계산. al_calc의 모듈 전역 캐시는 편집 가능해지면 uwsgi 워커별로 갈라지므로 요청당 1회 profile_map() 조회로 교체(49행이라 비용 무시).
• 헤더 컴팩트화: 라벨 세로쌓기 폐지 → 업체 1곳당 1줄(placeholder 인라인) + 헤더 접기 토글(요약줄 유지, localStorage). 폼 높이 106px, 그리드 시작 y 262→접으면 195px.
• 🔴잡은 버그: save_bulk가 INSERT 뒤에 soft delete를 돌려 방금 넣은 신규행이 같은 트랜잭션에서 즉시 삭제됐다(응답은 saved:50인데 조회 49행 = 조용한 실패). → soft delete를 INSERT보다 먼저 + UPDATE에 remove_yn='0' 동시 세팅. 테스트 E2E가 잡음.
• 커밋 master f99e739→버그수정 d38661e→스크립트 6f228b9, 운영 deploy-live a0faf03(파일 10개 포워드, api/config.py 무관).
• 검증 = 엑셀↔시딩 정합 실제 불일치 0(공란 50칸이 0 정규화뿐) + 테스트 CRUD E2E 16항목 PASS + UI Playwright 테스트 18 / 운영 18 PASS(콘솔오류 0) + 운영 SSM 실측(HEAD a0faf03·uwsgi active·4경로 200·al_profile 49행 시딩). 상세=session-2026-07-29-al-profile-crud.md.
• ⏳페페 육안 = 설정값 실제 편집 → 발주서 계산 반영. ※팩스발송 버튼은 여전히 스텁(범위 밖).

NOW (2026-07-28) — 현장 내용 = 카톡관리(1탭) + 통화관리(2탭) (운영 배포 완료)

• 페페 지시: "카톡관리를 field/worklog 메인페이지로, 기존 페이지를 탭으로 나눠 첫번째 탭. worklog는 통화관리 탭 2번째, 통화 수집분만. 이번주 월요일부터 기록만 현장별 그룹화, 월요일 이전은 숨김이력. 야간에 서브에이전트로 현장매핑 반복. 운영배포".
• 1탭 카톡관리 = 신규 api/pfs/kakao_board — kakao_board(미러) + kakao_board_op(웹 편집 명령 큐). 원본 board.md는 사무실 PC에 있고 EC2는 거기로 못 들어가므로 방향을 뒤집었다: 데몬이 미러를 push하고 웹 명령을 pull·적용·회신. 폰 조작 주체는 여전히 데몬 하나. 화면은 방별 카드 → 섹션·행 + 접힌 숨김이력, 반영 대기 n건·실패 사유 배너(조용한 미반영 금지).
• 2탭 통화관리 = worklog_dao._source_clause()(source='call')를 조회·집계·묶음변경 전 경로에 적용. 카톡 과거 적재분은 화면에 안 나오고 일괄변경도 안 건드린다.
• 노출창 = 최근 2주 → 이번주 월요일부터(week_start()). scope=hidden이 월요일 이전 전부(1년). 배타 상한이 기본창 시작과 정확히 맞물려 경계 항목 누락·중복이 없다. 상한 없음은 07-27과 같은 이유(미래 '예정' 항목 보호).
• 야간 파이프라인(talklog night_worklog.py, 예약 02:00) = 전사·분류·적재 → 규칙 auto-link → 남은 미연결만 claude 서브에이전트가 pfs 현장과 매칭(confidence≥0.8, 입력에 없는 현장명·번호는 폐기) → 새 전사문을 furniture-expert practice/ops_*_calls.md에 적립.
• ⚠api/config.py는 브랜치 간 파일 통째 포워드 금지 — master엔 미배포 monthly_close가 있어 그대로 가져오면 운영이 임포트에서 죽는다. 이 파일만 deploy-live에서 2블록 직접 추가.
• ⚠배포 중 회귀 1건 잡음: 숨김이력 682장에서 전체 펼침이 XHR을 한꺼번에 쏴 502 → loadItems에 큐(동시 6). 창을 넓히는 기능은 펼침 동시성을 같이 봐야 한다.
• 커밋 master 028fd6a→deploy-live 9e3a049, 502수정 master dd76774→deploy-live a9036c3. + poin-agent 39726f9, talklog 1440777.
• 검증 = 자체검사 18 + 로컬 7 + pfs-test E2E 8 + 운영 UI(Playwright: 카톡 4방 85항목·이번주 2026-07-27~·숨김이력 682현장·카톡배지 0/통화배지 1211·콘솔오류 0) + 운영 무해 왕복 1건(같은 본문 되쓰기 → 40초 내 완료, board.md 해시 불변). 상세=session-2026-07-28-worklog-tabs-kakao-board.md.
• ⏳페페 몫 = 감시 데몬 재시작(상승권한이라 코디 불가 — 지금은 1분 예약작업 PFS-KakaoBoard-Sync가 대신해 기능은 정상) / devplan kakao-ops.html 유지 여부 결정.

NOW (2026-07-28) — 생산 메모 모달 통합: 단일 입력창 (운영 배포 완료)

• 페페 QA 리포트(/field/list): "기존메모·신규메모 창 통합, 한 입력창에서 내용 전부 관리, 운영배포".
• field_list.html 1파일만 수정 — textarea 2개(field-memo-current readonly + field-memo-new) → field-memo-content 1개. 모달 열면 저장본이 그대로 편집창에 들어오고, 저장하면 그 값이 새 저장본. 라벨 = 메모 내용 + (최종 저장 <일시>).
• 빈값 = 차단 → confirm으로 변경. 통합창에선 "비우고 저장" = 메모 삭제 의도라 예전 alert('신규 메모를 입력하세요') 차단이 기능을 막는다.
• 서버 무변경 — GET/POST /api/field/memo·DAO의 previous 밀어내기 그대로.
• ⚠지시문의 "자동저장"은 기존 저장 동작 유지로 해석했다(현 모달엔 autosave 없음). 근거 = pfs는 견적 autosave를 Patch #21로 전면 폐지했고 재도입은 위험작업으로 규정. 진짜 입력 즉시 저장을 원하면 별도 지시 필요. ⏳페페 확인.
• 부작용 1건(미구현) = 저장 안 하고 닫으면 편집분 소실(예전엔 저장본이 readonly로 남아 체감 안 됨). 지시 범위 밖이라 경고 안 넣음.
• 2차 지시(같은 날): 저장 안내 alert 폐기 + 저장 성공 시 모달 자동 닫힘. 닫기 전 입력창/라벨 갱신 코드도 불필요해 함께 제거(다음에 열 때 GET으로 재주입). 실패 시엔 기존대로 모달 유지.
• 커밋 master 6e647fe→deploy-live 7c76774(통합), master 70475a0→deploy-live 8bb6fd9(alert 폐기·자동닫힘). 둘 다 파일 1개 포워드 반영. 사전확인 = git diff --stat origin/deploy-live origin/master -- <file>가 그 커밋 변경분과 정확히 일치해야 A·B 미반영분이 안 딸려온다.
• 검증 = 자체 스크립트 테스트 13항목 PASS(단일 textarea·구 id 소멸·저장본 주입·라운드트립·previous 보존·저장 후 모달 닫힘·alert 없음·재오픈 저장본·원복) + 운영 9항목 PASS(읽기전용 — 운영 메모 미변경, 배포 템플릿 소스로 alert 제거·modal('hide') 확인) + 스크린샷 육안. 상세=session-2026-07-28-field-memo-modal-merge.md.

NOW (2026-07-27) — field/worklog 노출기간 2주 제한 (운영 배포 완료)

• 페페 지시: worklog 내용 누적으로 페이지 로드 버벅임 → 최근 2주만 표시, 나머지 숨김. 과거는 일자(시작일) 필터로 별도 2주창 조회, 검색도 2주 창 안으로 제한.
• 노출창 단일 출처 = worklog_service.worklog_window(date_from) → (from, to) (to 배타). 미지정=(오늘-13, None), 지정=(그날, +14일), 1년 하한 클램프.
• ⚠기본창엔 상한을 두지 않는다 — work_date에 미래 '예정' 항목 존재(실측 10건, 전부 진행중/대기). [오늘-13, 오늘]로 잘랐으면 예정 작업이 통째로 사라짐. 자르는 건 과거뿐.
• 게이트 방식 교체: HAVING → WHERE 창. HAVING(집계 후)은 카드 건수에 창 밖 과거가 섞여 "2주만 표시"가 성립 안 함. 같은 창을 items·status-bulk·owners에도 적용 → 카드 건수=펼친 목록=일괄변경 범위 일치.
• 커밋 master ed2ea6a → deploy-live 750fdad(worklog 5파일만 포워드 반영, A·B 미반영 유지). devplan pfs.html DONE 갱신.
• 검증 = scripts/test_worklog_window.py 7항목 PASS(창 계산 + SQL %s/파라미터 일치) + 운영 실측 묶음 702→252(64%↓)·항목 1674→565(66%↓), 최신작업 07-29(예정 유지). ⏳페페 육안(카드 펼침·일괄변경 확인창 문구). 상세=session-2026-07-27-worklog-2week-window.md, 함정 2건 traps.md.

NOW (2026-07-27) — 미반영 커밋 선별 운영배포(C·D·E) + devplan 배포관리 페이지

• 미반영 커밋 세는 법(중요): 운영은 merge가 아니라 cherry-pick 이력이라 해시가 전부 다르다 → 원시 deploy-live..master 89건은 과대계상. git log --no-merges --cherry-pick --right-only origin/deploy-live...origin/master(patch-id 비교) = 22건, 그중 diff 0인 2건 빼면 실제 20건. 최종 확인은 git diff --stat과 대조.
• 선별 배포(페페 "C·D·E만"): git merge master는 A·B까지 끌고 오므로 파일단위 git checkout origin/master -- <files> 포워드 반영. 위험 낮은 순 E(스크립트)→C(파서)→D(웹UI) 3커밋 + push 1회(운영 재시작 1회). deploy-live 6fe4e38·7b916e8·8ca0389.
• 검증 = 자체 14케이스 PASS(_is_zero_name 6·파일명 파싱 4·num_only 4, D는 colgroup 17개 불변) + SSM 실측(운영 HEAD 일치·pfs-live.uwsgi active·/login 200·css ?v=20260715d 서빙).
• 남은 미반영 8건 = A 화물앱 배차 3건(아래 NOW, 페페 육안 대기) · B 월마감 5건(🔴 patch41_monthly_close.sql 운영 RDS 선행 + 메뉴 시드 46 필요).
• 관리 페이지 신설 = C:\dev\devplan\pfs.html(허브 pfs 카드 → 계획 페이지). 미반영 커밋 관리표(상태·메모 localStorage) + 배포 전 체크리스트 + 배포완료 이력 + '코디용 지시문 복사' 버튼. 데이터 갱신 = 그 파일의 PENDING/DONE 배열 수정. 상세=session-2026-07-27-selective-deploy-cde.md.

NOW (2026-07-26) — 배차 「화물앱 접수」 연동 (테스트 서버 전용)

• 배차 모달 = 화물앱 접수 폼으로 확장: 차량 19종(앱 톤수 15 기준)·차량종류(톤수 종속)·상/하차 방법·일시, 화물중량은 규칙 자동(다마스·라보·1T=0.2, 그 외 톤수×50%). 등록·수정 같은 모달이라 양식 통일. 목록에 화물앱 진행상태 배지.
• 스키마 = dispatch 멱등 ALTER 8컬럼(car_type·load_method·load_time·unload_method·unload_time·freight_status·freight_msg·freight_at). API = GET /api/dispatch/freight-queue, PATCH /api/dispatch/<no>/freight(상태 화이트리스트).
• 근본수정 2건: ①insert_dispatch가 늘 dispatch_no=0 반환(SELECT LAST_INSERT_ID()는 커넥션이 달라 0) → MySQLUtil.execute_id(cursor.lastrowid) 신설·사용 ②flask_restplus에서 return jsonify(...), 400은 500으로 터진다 → dict 반환. (같은 패턴이 DispatchList.post 등에도 남아 있음 — 건드리지 않음.)
• 검증 = scripts/test_freight_api.py 6항목 PASS(테스트서버 실 API) + scripts/test_freight_vehicle_map.js(차량/톤수 매핑·중량식). 실기기 E2E는 poin-agent handoff 참조. 운영(deploy-live) 미반영 — 페페 지시 대기.

한 줄 맥락

pfs(Flask/MySQL on EC2) 웹앱을 견적 v2 + OMC 중심으로 개선. 채티 진단·.md 지시문 → 코디 실행·배포 분업.

확정 사실 (인프라 상세 = memory.md §1)

• 운영(8000/pfs/deploy-live/pfs.poin.co.kr) · 테스트(8001/pfs-test/master/pfs-test.poin.co.kr). EC2 i-03225ba8bc12a929e, RDS 2개. DB pfs/admin(민감값 미기재).
• 배포: push→GitHub Actions→SSM(reset --hard + systemctl restart). master=테스트, deploy-live=운영(사용자 명시 시만).
• estimate v2: autosave 폐지(명시 저장만). v1 라우트 보존. 모바일 분기 = common/utils/ua.py is_mobile_ua()(같은 URL 다른 템플릿).
• AWS MCP SSM로 운영/테스트 RDS 읽기 조회 가능(2026-06-09 실측): EC2에서 env source 후 mysql 로컬 조회(복잡 셸은 base64). 읽기 SELECT만(쓰기는 위험작업·승인). 3306 직결·RDS Data API 불가 → 반드시 SSM.
• RDS 관계도(2026-06-30 신설): 코디 작업 시 스키마/관계 빠른 참조 = pfs/tools/rds-map/docs/RDS_MAP.codi.md(그룹별 70테이블·컬럼·추론관계). 페페용 인터랙티브 다이어그램 = 같은 폴더 rds-map.html. 빌더 build_rds_map.py(운영 RDS information_schema SSM 덤프→추론). MySQL이라 선언 FK 1개뿐 → 컬럼명(<x>_no→해당 PK)·도메인 규칙으로 관계 추론(declared/domain/inferred/audit). 허브=field·company·estimate·user. 워커=스케줄드태스크 pfs_rds_map(시간당, hidden VBS→rds_map_watch.py, 스키마 변경 시 docs/watch.log 기록·last_run.txt heartbeat). 스키마 바뀌면 자동 갱신되니 수동 편집 금지.
• 견적 핵심 스키마(타입·K/F·순서·UI컬럼·마진·RDS 실측) = schema-estimate.md (1번 작업 진단 근거).
• pfs UI 자동화(브라우저) = Playwright MCP + 전용 Chrome 프로필 C:\dev\pw-chrome-profile(2026-06-13 구성). 로그인은 세션 쿠키라 영속 안 됨(브라우저 닫으면 소멸). 로그인 방법 우선순위(페페 지시 2026-06-20): ①1순위 = env 파일 C:\dev\.secrets\pfs_login.env(키 PFS_TEST_URL/ID/PW·PFS_PROD_URL/ID/PW, git 밖) — 이 값으로 로그인 폼 직접 채워 로그인(테스트·운영 공통, 가장 확실). ②2순위 = Chrome 자동완성(프로필에 저장된 id poin01+비번, 폼 미리채움 → 로그인 버튼 클릭). 절차: 도메인 열기 → (env로 폼 채움 또는 자동완성) → 로그인 버튼 → /field/list. 비번 값은 시드·리포트·커밋에 미기록(env에서 읽어 폼 입력만, 출력 시 평문 금지·필요하면 base64 등으로 비노출 전달). poin01 user_no=1(=PFS_USER_NO). MCP 설정·복구노트 = C:\dev\backup_startup\playwright_mcp_profile_change.txt. 운영 자동화는 위험작업 규칙 준수(읽기/조회는 자유, 쓰기·배포는 승인). 상세 메모리 = [[browser-automation-login-default]].
• 로컬 AWS/SSM 복구(2026-06-24) → 🆕정규 설치로 승격(2026-07-25): 이 PC(코디 로컬)에 aws CLI v2 2.36.8 정식 설치 = C:\Program Files\Amazon\AWSCLIV2\(winget Amazon.AWSCLI, 시스템 PATH 등록됨 → 어느 셸에서든 aws 그냥 호출) + session-manager-plugin 1.2.835.0(winget Amazon.SessionManagerPlugin, C:\Program Files\Amazon\SessionManagerPlugin\bin\, 시스템 PATH 등록) → aws ssm start-session --target i-03225ba8bc12a929e 대화형 접속까지 가능. 자격증명 ~/.aws/credentials(IAM poinadmin, account 708397632488; 키는 시드 미기재), ~/.aws/config region ap-northeast-2. 검증(2026-07-25) = aws sts get-caller-identity → arn:aws:iam::708397632488:user/poinadmin, aws ssm describe-instance-information → i-03225ba8bc12a929e Online(Ubuntu). ⚠구 방식(pfs/.venv pip + export PATH=".../.venv/Scripts:$PATH")은 더 이상 불필요(남아 있어도 무해). → python scripts/ssm_run.py <local.py> [remote.py]로 EC2 SSM 직접 가동(ssm_run이 base64→/tmp→python3). EC2는 py3.6(capture_output·f-string 일부 주의), env=/home/ubuntu/env/pfs-test.env(테스트)·pfs-live.env(운영). 테스트 API는 nginx 8001(Host pfs-test.poin.co.kr 필요) 또는 https://pfs-test.poin.co.kr 공개·로그인 불요(/api/... PATCH 가능). 읽기 자유·쓰기/DDL은 위험작업(승인). 과거 "aws 미복구" 메모는 무효.
• 테스트/운영 RDS는 별개 인스턴스: 테스트=poin-dbinstance-test, 운영=poin-dbinstance(둘 다 DB명 pfs). 테스트 DDL은 운영 무영향. orderpaper.stock 컬럼은 테스트·운영 양쪽 존재(2026-06-24 운영 ALTER 완료, VARCHAR(50) NULL AFTER qty_user). 운영 env=/home/ubuntu/env/pfs-live.env(DB pfs)·테스트=pfs-test.env. ~~SSM 러너 aws CLI는 pfs/.venv/Scripts라 export PATH="/c/dev/pfs/.venv/Scripts:$PATH" 선행.~~ → 2026-07-25 무효: aws CLI가 C:\Program Files\Amazon\AWSCLIV2\에 정식 설치·시스템 PATH 등록이라 PATH 선행 불필요(위 "로컬 AWS/SSM" 항목 참조). stock 시드 완료(2026-06-24): 운영 187행=엑셀 재고관리 '남은수량', 나머지 0. 동기화 신규항목은 stock=qty 자동복사(sync/upload INSERT, 재동기화 보존) — 로컬 사이드카 경로(웹 배포 무관).

진행 중 / 최근 완료

완료·배포 끝난 상세 이력은 archive.md(전건)와 sessions.md(세션 인덱스)로 이관함. 여기엔 NOW·미결만.

⏭️ 활성 / 미결 (2026-07-23 갱신)

• 🔶활성 — /production/sticker 1층 생산팀 PC 배치 예정 (2026-08-10, 페페 문의 → 코디 설명). 브라우저(크롬)+로그인만으로 동작(배율 140% 브라우저 인쇄 폴백). 정확한 라벨 크기를 원하면 C:\dev\pfs\print-agent 복사 → install_print_agent.bat(관리자 불필요, 선행=Python 3.8+ PATH, pywin32·pillow 자동설치, 시작프로그램 숨김 vbs, 127.0.0.1:17777). 불필요 = NAS·MSSQL 클라이언트·VPN·엑셀(전부 EC2/사무실PC 쪽). 주의 = 인쇄설정(용지·배율)은 localStorage라 PC마다 최초 1회 조정 · GT800 드라이버 용지 스톡 100×100mm · 파레트용지는 A4 가로(에이전트 미지원, 브라우저 인쇄). ⏳미배포 잔여 = sticker_controller sync target 한 줄(워커 이중결정으로 동작은 정상, 설치 전 배포 권장).
• 🔶활성·테스트 배포 완료 — 월마감 기능 신규 + 26년 1~7월 마감 15건 시딩 (2026-07-22~23, 코디, 페페 지시). NAS \\192.168.0.101\공유폴더\2026현장\견적\{01~07월} 마감표 23개(넥서스7·에넥스7·넵스1 + 참조/포인확정본) 파싱해 기능 설계·구현. 페이지 /estimate/monthly-close(견적서 그룹 메뉴 46): 월+거래처 선택→현장별 본건/추가(+구분입력)/시공비/합계/확정 편집표→견적 자동수집(/candidates)→검증 배지(견적 가족합=본견적+자녀 대조)→거래처 제출 엑셀(원양식 재현). 규칙: 넥서스만 construction_yn='1' 시공비 별도(소계+시공비 컬럼), 타업체 미표기. 합계는 명시값 우선(이월·선지급 사례 보존, 빈값만 자동계산). 테이블 monthly_close/monthly_close_item(patch41, 테스트 RDS 적용, orderpaper-sync/monthly_close_seed.py). master dae788e→26c49cd→c684883→ce9b34e→34ab1c3(jQuery super()픽스·Decimal 500픽스·가족합 배지). 데이터 시딩(테스트): 마감 15건(close_no 1~15, 1~7월) API 시딩 ALL PASS — 72행 중 70행 견적 연결(미연결 2=PFS에 현장 자체 없음: 반도 부산EDC·일레븐 오피스텔). 견적 백필: 워크플로 31에이전트(계획15→적대검증15→적용) + 2차 매칭으로 estimate 백필 70건(comment='2026 월마감 백필(코디)', 본견적 35+추가건 35) + 기존 3건 업데이트(707 파크사이드·710 GS오산 cons 18,970,000/total 74,767,000·737 소요한남). 견적 규약 = 본견적 total=본건+시공비, 추가건=자녀(parent_estimate_no) — 가족합=마감행 합계. 배지 불일치 25건 = 전부 구조적(부분청구·이월·추가건만 청구, 비고로 설명), 전액청구 45건 전부 일치. 엑셀 출력 원본 마감표와 1원 단위 일치 실측(7월 넥서스 176,113,000·에넥스 57,844,000). ⏳다음=페페 육안(테스트), 운영배포 별도 지시(코드 cherry-pick+patch41 prod+시딩은 운영견적 기준 재판단 필요), 잔여=미연결 2행 현장 확정 시 재적용(scratchpad monthclose/apply_plan.py 멱등).

⏭️ 이전 미결 (2026-07-20 갱신)

• 🔶활성·테스트 배포 완료 — AL발주서 페이지 신규(도어입력→계산→발주서 엑셀) (2026-07-19, 코디, master cc3bc10+9f452b0→테스트서버). 신규 패키지 api/pfs/al_orderpaper/(calc al_calc.py=설정49·6공식 / openpyxl 생성기 al_orderpaper_excel.py+템플릿 assets/al_order_template.xlsx / 4계층). 페이지 /field/al-orderpaper(field_al_orderpaper.html+al_orderpaper.js 라이브계산·업체자동완성·미리보기·한글파일명). API /api/al-orderpaper(목록/저장/삭제/profiles/vendors/preview/excel). RDS(테스트) al_orderpaper+al_orderpaper_item(migrations/patch40)+menu 45. E2E PASS(profiles49·vendors381·서버계산정확·엑셀 RFC5987). 🔶미결/다음: ①팩스발송=버튼 스텁(로컬 팩스에이전트 print-agent패턴) ②HTML미리보기=근사미러 ③운영배포 보류(페페 "운영배포" 시 cherry-pick) ④최종비전=가구에이전트 도면판독→발주서 자동작성. 상세=archive/sessions. KB=furniture-expert/06 §14+seoljeong_constants.json.

• 🆕조사완료·설계 그릴링1합의 — 원부자재발주서(AL·유리) 자동작성 파이프라인 연구 (2026-07-19, 코디). 페페 지시=NAS 표준양식 \\192.168.0.101\공유폴더\원부자재발주서.xlsx(8탭) + 현장파일 2026현장\원부자재발주서\{월}\*.xlsx(90여개) 구조파악→자동화 연구, pfs DB 참조. 구조 확정: 계산군=설정(프로파일 공제상수 49종)×AL마감사이즈(도어1행 입력→AL/목대/유리 재단치수 자동계산 SSOT). 출력군=AL업체·유리업체(AL마감사이즈 미러뷰→실업체명 rename, C2가 업체마스터 INDEX/MATCH 조회, AL·유리 동시생성)+발주서(기타자재 범용 수기)+오엠씨(보드). 공식: 규격W=(장외경−10−큰손갭)/2, 목대=(W−목대뺄)×(H−목대뺄), 유리=(W−유리뺄)×(H−유리뺄), 3면엣지 큰손W=+큰손마감. 검증 PASS(누드엣지바 800/400→목대390×395·유리392×397). pfs 연계: orderpaper-sync/orderpaper_parse.py가 이미 이 파일 파싱중(계산4탭 EXCLUDE, rename출력탭만→RDS orderpaper/op_material_spec, 비충돌 동기화) → pfs=하류(발주추적) 완비, 자동화 공백=상류(도어스펙→계산→발주서생성). 그릴링①합의(페페): 입력소스=별도 입력폼(웹/시트) 신규(도어발주서연동/견적BOM 아님). 계산부=설정49행+6공식 Python이식 리스크0, 출력부=openpyxl 원본양식 생성, 동기화=pfs 비충돌패턴. 다음=착수 전 그릴링②(웹 vs 엑셀시트, 스키마/저장위치) 필요 — 미착수(연구·합의 단계). 지식 반영: 가구전문가 KB 06-aluminum-profile-handles.md §14 + seoljeong_constants.json(49행), 메모리 wonbujae-orderpaper-al-glass-engine.

• 미결2 — 운영 백업 테이블 정리 대기(위험작업): orderpaper_no 재번호 시 만든 롤백용 백업 2개가 운영 RDS에 남아있음 → orderpaper_bak_20260707_renum, orderpaper_usage_history_bak_20260707_renum. 며칠 문제없으면 페페 승인 후 DROP 가능(현재 보존). 재번호 결과=orderpaper_no 1..1500 연속, AUTO_INCREMENT=1501.

🔶 미결(운영 미배포·승인 대기) — 06-20 진행 중 2건

아래 2건은 테스트 검증까지 끝났으나 페페 운영배포 지시 대기 상태. 완료 아님.

🔶 미결(진행중, 2026-06-20) — 업체 관리 업체목록 정렬(최근 발주일)+유사업종 필터 (자재관리 발주서 기반) 테스트 배포·1차 초안 (master 5205da2, ?v=20260620e, 운영 미배포)

• 페페: 업체목록에 정렬필터 — ①자재관리 발주서(orderpaper) 기준 최근 발주일 내림차순 ②코디 추론 유사업종 필터. 목적=자재분류/항목 빠른 정리. "1차는 코디 추론 초안". + "테스트RDS를 운영RDS 26년 자료로 갱신하고 26년 자료 중심으로 테스트만 작업".
• ⚠️ 테스트 RDS 갱신(2026-06-20): 운영(pfs-live) 2026 자료 → 테스트(pfs-test). company 340 UPSERT(삭제 없음, 활성 329=운영), orderpaper 테스트 여분 3799건 삭제 후 운영 active 2026 1009건 클린교체(범위 2026-01-02~06-19, vendor 59=운영 동일). 스크립트 scripts/_rds_sync_prod2026_to_test.py(운영=SELECT만, 테스트=트랜잭션 쓰기). 운영은 읽기만·무변경. → 이후 테스트 company/orderpaper = 운영 2026 스냅샷(2026-06-20 기준).
• 데이터 모델 확인: orderpaper.vendor(발주처=업체명 문자열, company_no 아님)↔company.name 매칭. order_date=발주일, item_name=품목, material_type(R원자재/E엣지/S부자재). 활성업체 329 중 발주이력 있는 vendor 59(나머지는 발주이력없음).
• 백엔드(3파일): orderpaper_dao vendor별 최근발주일·건수(select_vendor_order_summary) + 품목분포(select_vendor_item_breakdown). user_admin_service 유사업종 분류기 _classify_industry(INDUSTRY_RULES: 보드/목재·시트/필름·엣지·유리/거울·가죽/패브릭·하드웨어/금속·기타 — 업체명 강신호(50) + 품목 키워드 + 자재타입 힌트(E→엣지·R→보드), 코드/브랜드명 한계는 사용자 보정 전제) + get_company_order_stats. controller GET /api/admin/company/order-stats.
• 프론트(2파일): 좌측 업체목록 상단 .cp-listbar(정렬 셀렉트 최근발주일↓ 기본/업체명/번호 + 유사업종 필터 셀렉트), 행에 최근발주일·건수·색상 업종 배지(indClass). loadOrderStats(업체명 매칭 map), renderCompanyList 재작성(자사 항상 최상단 고정·필터/정렬 무관, 거래처는 passIndustry+sortCmp). 캐시버스터 d→e.
• 테스트 Playwright 검증 PASS: 기본 최근발주일순(피앤알 06/19·53 > 노리콜렉션 51 > 선재기업 35…, 동일날짜는 건수순), 업종필터 유리/거울→4개(제일제경·대림유리·유로글라스·루브글라스, 명진=지글라스 hinge는 '글라스' 키워드 제외로 유리 오분류 안 됨), 정렬 업체명=가나다순, 자사 포인 금색 고정, 배지 색상. 운영 미배포(테스트만, 페페 지시).
• 미결/보정거리(1차 초안): ①분류 경계사례(조운IMT 코드만→기타 실은 시트, 선재기업 가죽/엣지 혼재) 사용자 보정 ②company 동명 중복(이지웨이·봉적 2건씩) — 데이터 정리는 별건 ③업종 규칙은 INDUSTRY_RULES 수정으로 조정. 페페 피드백 후 2차.

🔶 미결(진행중, 2026-06-20) — 사이드바 '현장 기록' 접이식 하위 그룹(현장 내용+대화방 수집관리 묶기) — 테스트 검증 PASS·운영 승인 대기

• 페페 지시(QA 코멘트): 현장 내용(/field/worklog)·대화방 수집관리(/field/kakao-rooms)를 현장 그룹 하위로 분리, 상위이름 추천 → 페페 선택 '현장 기록'.
• 구조: 사이드바 현장(nav-small-cap) 아래 현장 목록(flat) → 현장 기록 접이식 그룹 {현장 내용, 대화방 수집관리} → 자재관리(flat). 기존엔 셋 다 평면 나열이었음.
• 구현 2곳: ① web/templates/base.html 평탄화 분기에 손자 메뉴 있는 자식=접이식(<ul class="collapse">) 렌더 추가(OMC 패턴 일반화). ② menu_catalog 신규 field_log('현장 기록', parent=field, url NULL, order 214) + field_worklog/field_kakao_rooms를 parent='field_log'로 이동(scripts/codi_field_log_group.py, 멱등). 권한 추가행 불필요(리프의 부모는 parent_keys_needed로 자동 포함, 3단계도 동작 확인).
• 테스트 적용·검증 완료: 테스트 RDS 적용(SSM), master 4d82b04 push→테스트 배포 성공, Playwright로 /field/worklog 사이드바 실측 — 현장 기록 접이식(javascript:void(0)) 하위에 현장 내용·대화방 수집관리 중첩·활성 펼침 확인.
• 운영 미적용(승인 대기): 운영 = ① scripts/codi_field_log_group_LIVE.py(운영 env baked) SSM 실행 + ② deploy-live에 base.html 반영. 페페 "운영 배포해줘" 시 진행.

✅ 완료 이력 → archive.md / sessions.md (2026-07-07 정리로 NOW에서 이관)

• 06-19~07-06 전건(자재관리 탭 성능 시리즈 07-07 6건·orderpaper_no 재번호·자재관리 초기구축 06-24·업체관리 자재분류/권한매트릭스·입고일정 재설계·견적 v2/엑셀·worklog·업체휴가일정 등) + 그 이전 운영배포 이력(엣지·분류·필터·생산현황 재구축·권한·dispatch·talklog 등) → projects/pfs/archive.md.
• 견적 등록/수정, 견적서 엑셀(공급자 이미지·도장·reference), estimate sub-item, OMC Phase 1~7(06-08~09) → archive.md. 분류 드롭박스·size_display 영속(06-09) → sessions.md.
• 07-07 자재관리 구조개선 최종본만 위 NOW에 유지(페페 육안 대기).

미결 / 후속

• orderpaper 새 탭 '현장별 입고일정' — 목업 10종 작성·검토 대기(2026-06-19): 발주~입고 기간(그라데이션 바) 강조 + 상차일(◆ 별도) 강조. 현재 페이지와 동일 필터(현장별↔업체별 토글·자재·빠른필터·범위) 공유, 동적. 스타일 10종(①간트 ②주간매트릭스 ③월캘린더 ④D-Day리스트 ⑤입고히트맵 ⑥아젠다 ⑦칸반(주차) ⑧컴팩트표+미니바 ⑨업체스윔레인 ⑩현장카드스테퍼)을 1파일 탭스위처로. 오늘선·지연(입고경과·미완료)빨강·주말음영·D-day·일/주줌 반영. 파일 pfs/mockups/orderpaper_schedule_mockup.html(gitignore). Playwright 전탭 검증(JS에러0). GPT 상의 반영 추천안 = ..._v2.html: 핵심 인사이트="입고 지연?"보다 "상차 전 입고 가능?"(상차 버퍼=상차일−미완료 자재 최종 입고예정일)가 본질 → 상차버퍼 핵심 컬럼·정렬 신설. 기본=리스크 표(8 컴팩트표+4 D-Day 정렬, 블록단위 집계, riskRank 상차초과>지연+상차임박>지연>상차임박>버퍼부족>입고임박), 보조=타임라인(1 간트) 뷰토글, 상단 KPI 4종(지연·상차3일내 미완료현장·버퍼≤1·오늘입고). 그룹토글 용어 명확화(현장/가구업체/발주처 — 기존 vendor=발주처·furniture_company=가구업체 혼용 지적). 페페 보완지시 반영(2026-06-19): 기본 정렬을 상차일 임박순(가까운 먼저, 1순위)→위험도(2순위)로 변경(생산흐름=임박 상차 우선), 그룹도 가장 임박한 상차일 먼저. 타임라인 일자 셀선 진하게(#cdd5df, 주 경계 2px). 상위계층(현장명) 배경 진하게(#cdd7e3)·글씨 키움(표14.5/간트15px)+상단 border, 하위 업체행 들여쓰기로 계층 구분 강화. 2차 보완(2026-06-19): 발주~입고 게이지를 PFS UI 톤 파스텔로(소프트 인디고#aab6f0→민트#7fd9bd, 지연=소프트코럴, 완료=소프트그린, 상차마커=소프트오렌지#fb923c — 원색 탈피). 타임라인 상차일을 오늘선처럼 세로 점선(주황 dashed)+다이아(+라벨)로 행별 강조 — 업체별 모드에서 행마다(이전엔 현장별 그룹에만), 현장별은 그룹~하위행 연속 점선. 개선판 v3(..._v3.html, GPT 2차 상의 + frontend-design 스킬 반영, 2026-06-19): GPT가 v2 코드 직접 읽고 P0/P1 제시 → ①그룹 헤더 위험 요약(상차 D·버퍼·미입고 N/M·자재별 open/total·병목 발주처) ②행 클릭 펼침+조치 버튼(입고일 일괄변경/완료/원본) ③정렬 가능 헤더(위험도/입고예정/상차일/상차버퍼)+sticky 헤더·핵심 2열+스크롤 ④활성 필터 칩+결과 카운트 ⑤KPI/필터 범위 정합(shipSoon/buf/delay에 !done) ⑥검색(/단축키)·localStorage 저장. frontend-design 반영: 전체행 빨강→좌측 accent bar+옅은 배경(색약 대비)·이모지 절제(CSS 점)·tabular-nums·절제된 staggered 로드. frontend-design 플러그인은 설치됨(비활성)·settings 자동토글 차단되어 스킬 가이드를 디스크에서 읽어 직접 적용(상시활성은 /plugin). 파일 v1(10스타일)·v2(추천안)·v3(개선판=최신). v3 추가 보완(2026-06-19): ①현장명 앞 가구업체 칩(amber, 현장별 그룹헤더·발주처별 행·간트 라벨) ②상단 필터 2행 통합(분류+자재+검색+뷰토글 / 빠른필터 — 높이 절약) ③v3 개선 안내배너(gptbox)·제목 문구 삭제(실물 누수 방지) ④테이블 헤더 sticky 고정 확인 ⑤자재 R/E/S 버튼 높이 통일(34px inline-flex) ⑥검색 전체 컬럼 통합. 실제 구현 시 추가 요구(페페): 기존 발주서 정리 페이지에도 전체 컬럼 통합 인라인 검색창 신설(현재 상세필터 모달의 통합검색을 인라인 노출). QA helper 검증도구 부착(2026-06-19): 기존 web/static/{css,js}/qa_helper.*(전 페이지 공용, element picker→코멘트 사이드바→채티용 복사)를 목업에서 상대경로(../web/static/...)로 참조 — 실제 페이지와 동일 동작. 페페가 이걸로 수정사항 정리해 전달 예정(우측 상단 🔍 토글). localStorage 키 pfs.qa.items.v1(file:// 오리진 분리라 운영과 무충돌). QA helper 1차 수정 7건 반영(2026-06-19): ①그룹헤더 부가정보(상차/버퍼/미입고/병목) 삭제→업체칩+현장명+위험도배지만 ②발주일 풀날짜(26.6.16(화)) ③상차버퍼 컬럼 삭제(상차 D-day와 중복, KPI/필터는 유지) ④미완료 컬럼 삭제→타임라인 컬럼에 완료수량/총 카운터+게이지 통합 ⑤검색 단축키(/) 삭제 ⑥이중 스크롤 제거(앱셸: body overflow hidden+wrap 100vh flex, 표/간트만 단일 스크롤)+컬럼 헤더 sticky 고정(타임라인 동일) ⑦빠른필터/KPI 한 번에 한 조건만(라디오식, AND로 데이터 비는 문제 해소). 테스트 배포(2026-06-19): 검토용으로 v3 목업을 테스트 서버 정적 페이지로 배포 — http://pfs-test.poin.co.kr:8001/static/mockup/orderpaper_schedule_mockup_v3.html(무로그인 접근). canonical 편집본=pfs/mockups/(gitignore), 서버 사본=web/static/mockup/(qa_helper 참조를 ../web/static/→../css/·../js/로 교체해 서버·로컬 양쪽 동작, master bf3ccaa). 향후 목업 수정 시 같은 방식 재동기화. 다음=페페 추가 QA 수정 → 반영, 이후 실제 탭 구현(op-* 네임스페이스·item_receive_date 기준 집계·누락데이터 정보누락 rank·인라인 검색)(데이터=orderpaper/all-items+field 상차일, 입고기준=item_receive_date||receive_date, 블록 리스크=미완료 최종입고예정일).
• C:\dev 루트 비-pfs 파일(dwg_convert.exe·poinwg.conf·_notify_*·PDF·정크) 이동 위치 미정 — 페페 결정 대기.
• 추후 'AL' 자재 구분 신설 시 엣지바·AA-xxx 프로파일을 그쪽으로(엣지와 동일 방식).

미결 · 다음 단계

1. 견적 타입SSOT — 운영 DB 잔여 2건(위험작업·별도 승인 대기): ①페이즈 A 시드 — 운영 DB 적용 실행 기록 없음(미적용 추정·확인 필요) ②#7 마감재 숨김 E — 운영DB ui_column_setting finish 1→0(테스트 D는 완료·페페 확인됨). 코드(페이즈 A·B 본체+후속 5건)는 a523d39로 운영 반영 완료 — 이력 = archive.md / session-2026-06-10-phaseB-*.md. 지시문 CODI_estimate_type_order_phaseA_integrated.md(실행 완료)·구 ..._fieldtype_seed.md는 폐기·실행금지.
2. estimate 2/3차 — 인쇄폼 재작성, 단가편집 페이지, 일레벤 가격표 마이그레이션.
3. 재료 집계 product 테이블 — 보류.
4. 잔여 정리: 운영 검증용 견적 705 소프트 삭제(승인 후). 도장 이미지를 공급자 정보 이미지에 1장 합성(원본 고해상도 확보 후).

기본 작업 시스템 (항상 적용)

① 진단(채티·불확실성0) → ② 확정변경 묶음위임(코디 .md, 검증 끝난 것만) → ③ 위험작업 분리승인. 코디 지시문: .md·상단 첫 줄 "…확인 없이 바로 진행하세요."·변경 전 코드+이유 주석. 위험작업(대량삭제·운영배포·DB변경·권한변경)은 별도 승인. 세션 기록: session-YYYY-MM-DD-<슬러그>.md 개별 문서(register_doc.py --category archive) + sessions.md 인덱스 링크. 작업 함정 = traps.md.

최종 갱신: 2026-07-27 (KST) — handoff 완료이력 2차 이관(✅ 11항목 8,167자 → archive.md). 여기엔 NOW·확정사실·미결만 둔다.