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

지시

페페: "pfs field/worklog 내용이 너무 많아서 페이지로드 버퍼가 있다. 최근 2주 내용만 보이게 해줘. 나머지 내용은 숨김처리. 일자검색필터로 필요일정 별도 검색, 또는 검색창으로 관련 단어 검색→인라인 아님. 관련 단어 검색도 2주 기간으로 제한. 운영 배포."

진단 (기존 상태 = 2026-06-25 세션의 60일 게이트)

• 기본 노출 = 최근 2개월(date_from 미지정 시 오늘-60), 검색(q)은 같은 게이트 안에서 4컬럼 LIKE.
• 게이트 방식이 HAVING MAX(a.work_date) >= date_from(집계 후) → 현장 묶음만 걸러질 뿐 카드 건수·상태배지에는 창 밖 과거 항목이 그대로 섞이고, 카드를 펼치면 items 쿼리가 그 현장 전체를 로드했다. 즉 "2주만 표시"를 HAVING으로는 만들 수 없다.
• 운영 실측(SSM 읽기): worklog 1,674행(미삭제), 60일 묶음 702개. 2026-06-25 당시 146개에서 poin-agent 자동적재로 급증한 것이 로드 지연의 실체.

결정·설계

• 노출창 단일 출처 = worklog_service.worklog_window(date_from) → (from, to), to는 배타.
• 시작일 미지정(기본) = (오늘-13, None) — 상한 없음.
• 시작일 지정(과거 조회) = (그 날짜, +14일) — 정확히 2주치만.
• 1년보다 이른 시작일은 1년 전으로 클램프(URL/콘솔 우회 방지 · 신뢰경계).
• ⚠기본창에 상한을 두지 않은 이유(운영 실측으로 발견한 함정): work_date에 미래 날짜 = '예정' 항목이 존재한다 (2026-07-27 기준 10건, 07-28~08-20, 전부 진행중/대기). [오늘-13, 오늘]로 잘랐으면 예정 작업이 통째로 사라져 트래커가 무용지물이 될 뻔했다. 잘라내는 대상은 "2주보다 오래된 과거"뿐.
• 게이트를 HAVING → WHERE 창으로 교체. 집계 전에 행을 잘라야 카드 건수가 '보이는 2주'와 일치한다.
• 같은 창을 items(카드 펼침)·status-bulk(일괄 상태변경)·owners(직원별 요약) 에도 적용 → 카드 건수 / 펼친 목록 / 일괄변경 실제 범위가 항상 일치(일괄변경이 창 밖 과거를 조용히 바꾸지 않음).
• 검색: 전체기간 검색 폐지 → 표시 중인 창 안에서만 4컬럼 LIKE(페페 지시).
• work_date 타입 = date, NULL 0건(실측) → 반열림 [from, to)로 통일해도 손실 없음.

산출물·커밋

• pfs: master ed2ea6a → deploy-live 750fdad(worklog 5파일만 포워드 반영 — A 화물앱·B 월마감 미반영 유지).
• worklog_service.py worklog_window() 신설(구 _clamp_date_from 대체), items/bulk/owners에 창 전달
• worklog_dao.py _window_clause() 신설, site summary HAVING 제거·WHERE 창, items 2종·status_bulk·owner_summary 창 적용
• worklog_controller.py /sites·/items·/status-bulk·/owners date_from 수용(60일 기본값 코드 제거)
• field_worklog.html wlWindow()/wlQs()/renderRange()·시작일 라벨·표시기간 배지·reloadView()·일괄변경 확인창에 범위 명시
• scripts/test_worklog_window.py 자체검증 신설
• devplan pfs.html DONE에 750fdad 추가 + KPI done 하드코딩 3 → DONE.length.

검증

• 자체검증 PYTHONUTF8=1 python scripts/test_worklog_window.py → 7항목 PASS (창 계산 6 + SQL 조립: privacy/owner/keyword/window 동적절 조합 12종에서 %s 개수 = 파라미터 개수 일치, HAVING 부재).
• 템플릿 JS 문법 = node new Function() 파싱 OK.
• 테스트 서버(ed2ea6a, pfs-test.uwsgi active): 시작일 6/2 → 46묶음/140항목(최신 06-09, 창 상한 정상), 검색 q=현장+시작일 6/2 → 10묶음(창 안 부분집합), 하한 2000-01-01 → 0(1년 클램프), 미래 2027-01-01 → 0.
• 운영 서버(750fdad, pfs-live.uwsgi active):
• 기본 = 묶음 252 · 항목 565 · 최신작업 2026-07-29 → 60일 대비 묶음 702→252(64%↓)·항목 1674→565(66%↓), 최신작업이 오늘(07-27)보다 미래 = 예정 항목 유지 확인.
• 시작일 2026-07-14 → 247묶음, 최신 07-22 (창 상한 07-28 배타 정상). 시작일 2026-06-02 → 21묶음/155항목.
• 검색 q=현장 → 128묶음(창 안). 하한/미래 우회 → 0.
• 한계: 브라우저 클릭 검증(Playwright) 미수행 — API·마커·JS 파싱으로 갈음. 페페 육안 확인 필요(카드 펼침·일괄변경 확인창 문구).

다음

• 252묶음이 여전히 무거우면 창을 1주로 줄이거나 미연결 묶음을 접어두는 안 — 페페 판단.
• (선택) Playwright 클릭 검증.

관계

• 주제 그룹: talklog (카톡/통화 수집 → 작업 트래커)
• 선행: session-2026-06-25-worklog-fold-period-search.md(60일 HAVING 게이트 — 이번에 WHERE 창으로 교체)
• 관련 문서: projects/pfs/handoff.md, projects/pfs/traps.md