guardian 완료보고 반려 재발 방지안 — 24시간 분류표 기반 보고 템플릿

조회 시각: 2026-10-06 03:35 KST / DB: /Users/ron/.hermes/data/ops_multiagent.db (sqlite3 -readonly) 이 문서는 config/agent_completion_submission_standard.md §9-3-1(570행~)과 config/completion_evidence_policy.md에 이미 있는 일반 규칙을 반복하지 않고, guardian 특화 차이만 쓴다. 코드는 수정하지 않았다.

[현황] CMD#40950 분류표 재확인 결과

재확인 1 (분류표 그대로): #40950 분류표(261006_hermes_needs_evidence_분류.md)의 8건·guardian 7건(87.5%)은 03:05 시점 스냅샷으로는 맞다. 다만 지금 라이브 bus_commands 테이블(전체 23행)만 조회하면 최근 24시간 반려는 6건이고 guardian 4건(#40869, #40902, #40947, #40949)이다. 나머지는 bus_commands_archive(2,594행)로 이동했다. 라이브 테이블만 보면 반려 건이 사라져 분포가 왜곡된다.
재확인 2 (라이브+아카이브 합산, 이 제안서의 기준): 최근 24시간 needs_evidence·failed 44건. guardian 26건(59.1%), analyst-pm 7, analyst-macro 6, cowork 3, ron 2. 즉 "guardian 최다"는 확인되지만 비율은 87.5%가 아니라 59.1%다. 87.5%는 분모가 라이브 테이블이라 과대 집계된 값이다.
guardian 26건 중 상태는 failed 24, needs_evidence 2. failed는 게이트 재시도 소진 후 최종 실패다(보완 사유 라벨은 result_note에 남음).
guardian 26건 사유 라벨(복수 라벨 가능): execution_artifact_path_not_found 16, verification_command_unverifiable 13, source_log_path_not_found 7, 타임아웃/인프라 각 3, exit code 계열(missing/invalid_verification_exit_code) 3, 라벨 없이 "검증 근거가 없음" 2(#40906, #40925).
40950은 사유 1위를 missing_verification_value(5/8)로 봤지만 합산 표본에서는 존재하지 않는 경로 인용(execution_artifact_path_not_found)이 1위다. exit code 누락은 3건뿐이다.
존재하지 않는 경로 인용 실측(ls/os.path.exists로 확인, 모두 False): /Users/ron/.hermes/workspace/jobs.json 14회(최초 #40867), workspace/stdout.log 3회·stderr.log 1회(#40919), workspace/fi-morning-brief.sh 2회(#40939), workspace/scripts/migrated/fi-morning-brief.sh 1회(#40943). 실제 크론 장부는 /Users/ron/.hermes/cron/jobs.json(159개 잡, 존재 확인).
작업 유형: guardian 반려 26건 중 제목에 "크론"이 들어간 건 10건. 대부분 주간 크레딧 요약 크론(잡 id 5c45c26045be, 일요일 09:00) 실행 결과 점검 계열이다. 이 잡의 장부 값은 last_status=ok, last_run_at=2026-10-04T09:02:45+09:00, failure_streak=0이라 점검 대상은 정상인데 보고 형식 때문에 반려가 반복됐다.

[guardian 점검류에서 흔히 빠지는 필드] (표준 문서와의 차이만)

근거파일의 점검 대상 경로를 실제 존재하는 크론 장부로 쓰지 않고 작업 디렉터리 기준 상대 추정(workspace/jobs.json)으로 지어낸다. 표준 §9-3-1은 "점검 대상 실제 로그/DB 경로"를 요구하지만, 크론 점검의 정답 경로가 무엇인지는 적혀 있지 않다. 프로세스 점검의 정답 경로(/Users/ron/.hermes/logs/gateway.log)도 마찬가지다.
검증 줄에 exit code <숫자> 리터럴이 없다. guardian은 "정상 확인함/통과" 서술로 끝낸다. 게이트는 exit code|exit_code|returncode|rc + 숫자만 읽는다(scripts/agent_queue_worker.py:7030 정규식, 7150행 missing_verification_exit_code 반환). 파이프에 → 3 passed 형태가 아닌 sqlite3/python3 -c 조회에서는 exit code 숫자를 직접 써야 한다.
검증 명령에 임시 복사본 경로(/tmp/ex_copy/executions.db, #40867)나 닫힌 DB를 쓴다. 재실행 불가라 verification_command_path_not_found가 된다. 실측: /Users/ron/.hermes/cron/executions.db는 이 세션에서 sqlite3 -readonly로 열면 "unable to open database file"이 났다. 검증 명령으로 인용하지 말고 jobs.json의 last_status/last_run_at 필드를 쓴다(아래 템플릿).
라이브 테이블만 조회해 건수를 보고한다. bus_commands는 몇 시간 단위로 archive로 이동하므로 "최근 N시간 건수" 보고는 UNION ALL 쿼리가 아니면 재실행 시 값이 달라져 검증 불일치가 된다.
반려 사유 조사를 요청받은 meta 작업(#40869, #40902, #40947, #40949)에서 "해야 할 일 목록"을 결론으로 쓴다. 조회가 끝났다는 완료형 문장과 조회 행 수가 없다.

[권고]

1순위: guardian이 쓰는 완료보고 예시에 "점검 대상별 정답 경로 표 + 아래 템플릿 1종"을 추가한다(codex 반영, 이 문서는 문안만 제공). 기대효과: 합산 표본 guardian 반려 26건 중 경로 계열(execution_artifact_path_not_found 16 + source_log_path_not_found 7 = 중복 포함 23라벨)을 겨냥. 목표는 72시간 guardian 반려 26건 → 10건 이하.
2순위: 건수 보고 쿼리는 bus_commands UNION ALL bus_commands_archive를 표준으로 못박는다. 라이브만 조회한 건수는 보고에 쓰지 않는다. 기대효과: 분모 왜곡(87.5% vs 59.1%) 재발 0건.
3순위: 같은 과제의 재발행 루프(#40947 → #40949 → #40950, 주간 크레딧 크론 점검 10건)는 첫 반려 시 "점검 대상 정답 경로 3종(jobs.json, agent.log, executions 결과)" 힌트를 재시도 메시지에 붙인다.

[guardian용 완료보고 예시 템플릿 1종 — 크론 점검형]

아래 값은 2026-10-06 03:35 KST 실제 조회 결과이며 두 명령 모두 exit code 0으로 직접 실행해 확인했다.

결론: 주간 크레딧 요약 크론(5c45c26045be)의 최근 실행이 정상(last_status=ok, failure_streak=0)임을 장부에서 확인했다
근거: /Users/ron/.hermes/cron/jobs.json 에서 id=5c45c26045be 잡 필드를 읽음, 조회 2026-10-06 03:35 KST. 최근 실행 2026-10-04T09:02:45+09:00(예정 09:00 대비 지연 7초, kind=on_time)
검증: python3 -c "import json;x=[k for k in json.load(open('/Users/ron/.hermes/cron/jobs.json'))['jobs'] if k['id']=='5c45c26045be'][0];print(x['last_status'],x['last_run_at'],x['failure_streak'])" → ok 2026-10-04T09:02:45.264552+09:00 0, exit code 0
근거파일: /Users/ron/.hermes/cron/jobs.json:7962 "\"id\": \"5c45c26045be\","
다음 행동: 추가 조치 없음 (다음 실행 2026-10-11 09:00 KST)

반려 건수 보고가 필요한 DB 점검형은 검증 줄만 아래로 바꾼다.

검증: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT claimed_by,count(*) FROM (SELECT claimed_by,status,updated_at FROM bus_commands UNION ALL SELECT claimed_by,status,updated_at FROM bus_commands_archive) WHERE status IN ('needs_evidence','failed') AND updated_at>=datetime('now','localtime','-24 hours') GROUP BY 1 ORDER BY 2 DESC" → guardian 26, analyst-pm 7, analyst-macro 6, cowork 3, ron 2 (5행), exit code 0

작성 규칙 3줄: - 근거파일은 반드시 ls로 존재를 확인한 절대경로만 쓴다. workspace/jobs.json, stdout.log, stderr.log, fi-morning-brief.sh는 실존하지 않으므로 인용 금지. - 검증 줄 끝에 exit code 0 리터럴을 붙인다. 명령을 실제로 실행하지 않았으면 쓰지 않는다. - 건수 보고는 UNION ALL 쿼리 결과와 그 행 수를 함께 적는다.

[리스크]

이 템플릿은 jobs.json 줄번호(7962)가 크론 추가/삭제로 바뀌면 근거파일 줄 인용이 어긋난다. 인용 시점에 grep -n '"id": "<잡id>"'로 줄번호를 다시 확인해야 한다.
수치(26건, 59.1%)는 24시간 이동 창이라 시간이 지나면 달라진다. 기준 시각을 항상 함께 적는다.
라이브 테이블이 23행뿐이라 반려 조회가 archive 이동 타이밍에 따라 흔들린다. 이동 주기는 코드로 확인하지 못했다(미확인).
반려 본문은 게이트 재시도 메시지만 저장되어 guardian 원래 제출문을 볼 수 없어, 위 "빠지는 필드" 5종 중 일부는 라벨에서 추정한 것이다.

[검증방법]

KPI: guardian 72시간 needs_evidence·failed 건수. 기준선은 24시간 26건(합산 기준).
명령: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT status,count(*) FROM (SELECT claimed_by,status,updated_at FROM bus_commands UNION ALL SELECT claimed_by,status,updated_at FROM bus_commands_archive) WHERE claimed_by='guardian' AND status IN ('needs_evidence','failed') AND updated_at>=datetime('now','localtime','-72 hours') GROUP BY 1"
기대값: 반영 72시간 후 합계 10건 이하, execution_artifact_path_not_found 라벨 0~2건.
롤백 조건: 72시간 내 guardian 반려가 기준선(26건/24h 환산 78건/72h) 이상이거나 guardian done 완료율이 낮아지면 예시 추가분을 되돌린다.

guardian 완료보고 반려 재발 방지안 (24시간 분류표 기반 보고 템플릿 제안서)