2026-07-29 세션 — 미반영 A·B 그룹 운영배포(화물앱 배차 · 월마감)

지시

페페: (code-qa P0 착수 방식을 묻자) "미배포건이 있다. A,B 그룹 먼저 운영배포한다." → 07-27 선별배포(C·D·E) 때 남겨둔 A 화물앱 배차 3건 · B 월마감 5건을 운영 반영. 이어진 질문("A그룹에 배차사진 경로 버그 D005 한 줄 같이 태울까?")에는 "배포만, 버그는 P0에서".

1. 배포 경계 산출 — patch-id 28건이 아니라 파일 37개로 판정

git log --no-merges --cherry-pick --right-only origin/deploy-live...origin/master = 28건이지만, 07-27 배포가 파일단위 포워드라 커밋 해시·내용이 달라 이미 반영된 것도 계속 잡힌다 → 커밋 수는 신뢰 못 한다.
판정은 git diff --name-only origin/deploy-live origin/master = 37파일로 했다. 여기서 A(8) · B(14) · AL 미배포분(15, 범위 밖)으로 갈랐다.
⚠공유 파일 2개를 먼저 확인한 게 핵심: api/config.py의 미반영 diff는 월마감 2줄뿐(AL은 이미 반영됨), common/database/mysql_util.py는 A의 execute_id뿐. 둘 다 통째 포워드해도 AL이 안 딸려온다. (시드 경고 "config.py 통째 포워드 금지"는 미배포 monthly_close가 딸려오던 상황 기준 — 이번엔 그 monthly_close가 배포 대상이라 조건이 반대로 뒤집혔다. 경고를 기계적으로 적용하지 말고 diff를 매번 볼 것.)

2. DB 선행 (코드보다 먼저)

orderpaper-sync/monthly_close_seed.py(멱등)의 ENV_PATH만 pfs-live.env로 바꿔 SSM 실행. BEFORE 스냅샷을 앞에 붙여 적용 전 상태를 근거로 남겼다 → tables: [], menu row: None.
결과: monthly_close · monthly_close_item 생성, menu_catalog 1행 menu_no=46(시드 문서의 "메뉴 시드 46"과 일치).
권한 추가작업 불요 — has_menu_permission은 자사(company_type='1')에 명시 row가 없으면 기본 허용(신규 페이지 자동 접근). 운영 user_permission 83행 중 월마감 관련 0행 = 제한 없음. 외부 업체 계정은 원래 차단.

3. 코드 배포 (deploy-live, 2커밋 + push 1회)

커밋	그룹	내용
`83540c8`	A	화물앱 접수 연동(차량 15톤수·차종·상하차·큐 API·배지) + `dispatch_no` 0 반환 수정(`execute_id`) + 상태 PATCH 500→400
`70ba185`	B	월마감 페이지+API+엑셀 + 합계 수동보존 + jQuery `super()` + Decimal 500 + 가족합 배지
- 방법 = `git checkout origin/master -- <files>` 파일단위 포워드. **그룹마다 `git diff --cached --stat origin/master -- <files>`가
비는지(=master와 정확히 일치) 확인하고 커밋했다. push는 1회**(운영 재시작 1회).
- 커밋 전 `python -m py_compile` 10파일 통과.
- ⚠`git reset --hard`는 위험작업 훅에 걸렸고(RISK-20260729-YJHQ 미응답 만료) 애초에 불필요했다 —
로컬 `deploy-live`가 origin과 0/0이라 `checkout`만으로 충분. 훅에 막히면 명령을 쪼개기 전에 정말 필요한 명령인지 먼저 본다.

4. 검증 (SSM 실측)

운영 HEAD 70ba185 · pfs-live.uwsgi.service active · /login 200
/estimate/monthly-close 200 · /api/monthly-close?close_ym=2026-07 200 · /api/dispatch 405(GET 미지원 = 라우트 등록됨)
execute_id 1건 · dispatch 컨트롤러 freight 4건 · api/pfs/monthly_close/service/ 파일 존재
남은 diff = AL 미배포분 15파일뿐 재확인.
로그의 Table 'monthly_close_item' already exists(1050) 경고는 DAO ensure_tables()가 매번 도는 설계 탓 — 무해. 같이 찍히는 pymysql.err.Error: Already closed(MySQLDatabase.__del__)는 기존 구조 이슈로 이번 배포와 무관(code-qa platform-core 소관).

5. 안 한 것 (의도적)

마감 데이터 시딩(1~7월 15건)은 테스트에만 존재. 운영 견적 기준 재판단이 필요해 별건 — 지시에 없어 안 했다.
D005 배차사진 경로 버그는 페페 지시대로 손대지 않음(code-qa field-dispatch 파트에서 처리).
AL발주서 QA 8건(b69d325·f6bcfb2·6f9732c)은 범위 밖 — devplan pfs.html PENDING에 4건으로 갈아끼웠다.

6. 문서 갱신

devplan pfs.html: PENDING 8건(A·B) → AL 4건으로 교체, DONE에 83540c8·70ba185 추가(검증 내역 포함). HTTP 200 확인.

7. 후속 — 페페 QA: 화물앱 접수 버튼 비작동 (같은 세션, 운영배포까지)

지시: /dispatch/list #dcFreightBtn → "기능 비작동으로 설정. 버튼 눌릴시 '준비중입니다' 텍스트로 대체. 운영배포"
수정 = requestFreight() 앞에 게이트 3줄. 기존 로직은 지우지 않고 보존(재개 시 FREIGHT_ENABLED만 true). js var FREIGHT_ENABLED = false; function requestFreight(){ if(!FREIGHT_ENABLED){ dcToast('준비중입니다'); return; } 안내는 앱 관용 방식인 dcToast를 썼다(alert은 pfs에서 걷어내는 방향).
배포 = master 4433226(+검증 스크립트 3288f1e) → deploy-live af4b72d(템플릿 1파일 포워드, diff 3줄).
검증 = 신설 scripts/_dispatch_freight_ui_check.py로 실제 버튼 클릭 — 테스트 9항목·운영 9항목 ALL PASS: 토스트 문구 준비중입니다 · confirm/alert 0 · /freight API 호출 0 · 모달 유지 · 콘솔 에러 0.