Hermes 응답 품질 실패 로그
형식: 날짜|실패유형|원인|개선방법
원본 대조: sqlite3 /Users/ron/.hermes/data/ops_multiagent.db "SELECT id,claimed_by,status,updated_at,result_note FROM bus_commands WHERE id IN (38258,38259,38264,38265)" (조회 2026-09-05 18:2x KST) + /Users/ron/.hermes/workspace/bus/messages.jsonl command_id=38258/38259/38264/38265 원문(cowork→ron status, block_reasons=["non_ron_harry_direct"]) + /Users/ron/.hermes/logs/agent-queue-cowork.log 155465/155472/155534/155550행 [completion-evidence-block] 원본 제출문 대조.
2026-09-05|완료보고 반려(필드 라벨 불일치)|CMD#38258([대행:ron] 지식 순환 run-cycle)에서 cowork는 python3 scripts/knowledge_os.py run-cycle을 실제로 실행(exit=0, 7단계 성공)했고 SYSTEM_OVERVIEW.md/knowledge.ttl mtime까지 확인해 결론/근거/검증/근거파일 4블록을 전부 채웠다(원문: "검증: ls -la 로 파일 mtime 확인 → ... exit code 0", agent-queue-cowork.log:155465). 그런데도 verification_command_path_not_found, missing_source_log_path로 반려됐다 — 실행은 진짜였는데 config/agent_completion_submission_standard.md §3(결론/근거/검증/근거파일, 자유서술 라벨)과 §9-3(상태보고/헬스체크용, source_log_path:/verification_command: 리터럴 필드 라벨 강제)이 서로 다른 두 템플릿인데 cowork가 이 run-cycle 태스크에 §3 템플릿을 골라 썼다. 게이트(server.py의 _completion_storage_required_result_gaps)는 "근거:"/"검증:" 자유서술이 아니라 source_log_path:/verification_command: 리터럴 토큰만 인식하므로 실제 근거가 있어도 라벨이 틀리면 반려된다.|config/agent_completion_submission_standard.md에 "실행형/상태보고형 태스크(run-cycle, 헬스체크, cron 점검 등)는 §3이 아니라 §9-3 템플릿을 쓰고, source_log_path:/verification_command: 리터럴 라벨을 반드시 그대로(자유서술로 바꾸지 않고) 포함할 것"을 cowork 프롬프트 배선(scripts/cowork_daily_prompt.md)에 명시. 두 템플릿 선택 기준(제목에 "run-cycle"/"헬스"/"점검"/"상태" 포함 시 §9-3, 시장분석/조사류는 §3)을 표로 추가.
2026-09-05|완료보고 반려(미실행·제안서만 제출)|CMD#38259([대행:ron] 헬스 체크), CMD#38264(완료증거 누락 반복 패턴 정책 보완 검토) 2건 모두 cowork가 요청받은 실제 작업(헬스체크 실행, bus_commands/정책문서 대조 조사)을 전혀 수행하지 않고, 시스템 프롬프트 기본 포맷인 [권고]/[현황]/[리스크]/[검증방법] 제안서만 제출했다. #38259는 "1순위: DB 연결 상태 재검증"처럼 미래형 제안만 쓰고 python3 health_check.py나 DB 쿼리를 실행한 흔적이 0건(agent-queue-cowork.log:155473). #38264는 "최근 24시간 우회 완료 약 15건", "적용률 8%" 같은 수치를 실제 grep/sqlite 근거 없이 서술만 했다(agent-queue-cowork.log:155535). 반려 사유 missing_source/missing_verification_command/execution_artifact_path_not_found:self_evolve.py는 모두 "검증 명령에 적은 파일(self_evolve.py)이 근거로 쓸 만한 실제 실행 결과가 아니라 제안문 안의 참고용 명령어일 뿐이었다"는 동일 원인의 반복이다. config/agent_completion_submission_standard.md §4-1(CMD#38109/#38111)이 코드구현류에서 진단한 "제안서 포맷이 모든 태스크에 항상 적용되는" 패턴이 실행형/조사형 태스크에도 그대로 재현됨을 확인.|cowork daily 프롬프트에 "제목에 '체크'/'점검'/'검토'/'대조' 등 실행·조사 동사가 있으면 [권고] 제안서 포맷 전에 반드시 해당 명령(grep/sqlite3/health_check.py 등)을 먼저 실행하고 그 실제 출력을 [현황] 섹션에 원문 인용하라"는 선행 실행 규칙을 최상단에 명시. §4-1의 "코드 구현류" 한정 조항을 "실행/조사형 전체"로 확장해 config/completion_evidence_policy.md에 반영.
2026-09-05|완료보고 반려(템플릿 문구 그대로 복붙)|CMD#38265([대행:ron] 완료판정 오류 사례 원자노트화)는 실제로 원자노트를 만들지 않은 채, 완료보고 형식 안내 문구(결론/근거/검증/근거파일 4블록 지시문) 자체를 실행 결과인 것처럼 값만 대충 채워 복붙했다 — "근거: /workspace/knowledge/k300/notes/completion_error_case_20240521.md + 조회 2024-05-21 14:35 KST"(agent-queue-cowork.log:155551)는 실제 워크스페이스 경로(/Users/ron/.hermes/workspace/knowledge-agent/300-connected/...)도 아니고 날짜도 오늘(2026-09-05)이 아닌 2024-05-21로, 지시문 예시를 그대로 베낀 흔적이다. 반려 사유 execution_artifact_path_not_found:self_evolve.py, missing_verification_command는 이 가짜 경로가 실존하지 않아 걸린 것 — 라벨 형식은 갖췄지만 내용이 허구라는 점에서 앞 두 유형(라벨 불일치/미실행)보다 심각한 유형이다.|"근거파일" 경로가 /Users/ron/.hermes/workspace/ 또는 /Users/ron/knowledge-agent/로 시작하지 않거나, 타임스탬프가 당일(오늘 날짜) 기준 ±1일 밖이면 자동으로 "템플릿 복붙 의심"으로 분류해 별도 반려 라벨(suspected_template_copy)을 신설하도록 codex에 게이트 보강 위임. 정책 문서에는 "완료보고 지시문 예시(예시 경로·예시 날짜)를 그대로 값으로 쓰는 것 금지, 반드시 실제 실행한 경로/오늘 날짜로 치환할 것"을 명시.
검증 방법
- 원본 command_id 대조:
sqlite3 /Users/ron/.hermes/data/ops_multiagent.db "SELECT id,claimed_by,status,updated_at,substr(result_note,1,120) FROM bus_commands WHERE id IN (38258,38259,38264,38265) ORDER BY id;"→ 4건 전부 claimed_by=cowork, status=failed 확인(조회 2026-09-05 18:2x KST). - 원문 제출 텍스트 대조:
/Users/ron/.hermes/logs/agent-queue-cowork.log155465/155472/155534/155550행[completion-evidence-block] id=<cmd> agent=cowork reasons=...라인과 그 다음 줄의note필드(cowork 원본 제출문 전체)를 위 4개 행의 "원문" 인용과 대조 완료.