알림센터 재감사 결과 — 잘못된 것 3건 수정

09:07 일일감사 vs 09:30 사후점검이 같은 애널리스트 4종에 정반대 결론을 낸 모순에서 출발. 실측 검증으로 진짜 결함 3건 확정 후 수정.

① 감사 freshness 가짜경보 (감사 스크립트 버그)

증상: alarm_center_daily_audit.py 가 macro/fundamental/technical/pm 4종 전부 "최신성 마커 누락" 경보. 실제 데이터는 멀쩡(09:30 사후점검 PASS 4/4).
원인: marker_available 판정이 본문 리터럴 "데이터 기준" + sender 파일 문자열 두 조건만 사용. 실제 리포트는 as_of/data_vintage_by_source/data_dates 등 구조화 메타데이터로 최신성을 담음 → 메타데이터를 판정에서 무시해 가짜 누락. 같은 표의 metadata=True 와 자기모순. sender 조건은 해당 파일에 문자열이 없어 영구 False(죽은 분기).
수정: alarm_center_daily_audit.py analyst_marker_status() — marker_available = marker or sender_supports_marker or has_freshness_metadata 로 메타데이터 반영. 키 목록도 사후점검과 정렬(data_vintage/data_freshness/source_freshness 추가).
검증: 함수 직접 호출 → 4종 전부 marker_available=True.

증상: sector_trace 전 기간(4/15~6/4) 산업 발송 0건. 단순 "오늘 0"이 아니라 처음부터 0.
원인: 4/22 부분 복구(cron-missing-recovery) 때 tanker/refining 만 등록하며 --notify 누락, 나머지 4종(upstream/shipbuilding_cycle/choi_report/company_insight)은 미등록. 발송 모듈·topic_id(7)·섹터명 매핑은 정상. send_sector("industry") 호출 줄까지 도달 자체를 못 함.
수정: ~/.hermes/cron/jobs.json (스케줄러 단일 소스 = cron_store.JOBS_PATH) — tanker/refining 에 --notify 추가, 4종 신규 등록. 백업 jobs.json.pre-industry-fix-20260604125839.
검증: 6종 전부 enabled + 발송 인자 확인. refining dry-run(토큰 차단) → 처음으로 send_sector(industry) 경로 도달. 즉시 대량발송 없음(due 0건, 게이트웨이 fast-forward 방지, 1분마다 jobs.json 재로드라 재시작 불필요).
다음 발송: tanker 06:35 / refining 06:40 / upstream 06:45 / choi 07:10 / company_insight 07:20 / shipbuilding 월 07:00. tanker·refining·upstream 은 "이상치 있을 때만" 발송.

증상: 07:05:56·07:05:57 동일 시장지표 2건. dedup(전체 해시 1h TTL) 통과.
원인: market_indicator_tracker.py 가 동일 발송 함수를 연달아 2회 호출(리포트 1 + 이상치 알림 1, 내용 동일). 1초 차로 해시 우회. 5/29~6/4 매일 재현되는 구조적 버그. 크론은 1개만 등록(중복 아님).
수정: send_anomaly_dm 단일 호출로 통합(리포트+이상치를 한 메시지에). 잉여 호출 제거.
검증: py_compile OK, 코드 흐름 1건. 실환경 1건 발송은 다음 스케줄(이상치 발생 시)에 확인 예정.

지메일 9건/1분36초 → 서로 다른 뉴스레터 9개 묶음 발송. 중복 아님.
동일 preview 7건 vs dedup skip 0 → 모순 아님. preview는 앞 80자 표시 기준, dedup은 전체 해시 1h. 간격 초과/미세 차이로 정상 통과.
리포트 수치 17개 중 16개 정확(나머지 1개는 휘발성 캐시, 재현 불가).

DONE