needs_evidence 37건·failed 3건 반려 라벨별 해소 방안 (조회 2026-10-13 17:10 KST, 읽기 전용)

대상: /Users/ron/.hermes/data/ops_multiagent.db, 테이블 bus_commands. DB·코드·크론은 수정하지 않았다. 선행 자료: guardian 집계표 /Users/ron/.hermes/workspace/memory/reports/needs_evidence_breakdown_20261013.md (조회 16:38 KST, 8행 합계 42건: needs_evidence 37 + failed 5).

1. [권고]

1순위 — 게이트 오탐 2종을 고치는 코드 수정 (codex 위임) - 무엇을: "검증:" 값에 exit code는 0입니다처럼 조사가 붙거나, 줄을 바꿔 불릿으로 적은 exit code를 게이트가 못 읽는 결함 2건, 그리고 [자동 보강] 문구가 실제 지시문을 덮는 결함을 고친다. - 왜: 재현으로 확인됐다. guardian 원문 5건을 서버 게이트에 다시 넣어 보니 #40854·#40994·#41274·#41295·#41498이 missing_verification_exit_code로 재현됐다. 이 중 #41274·#41295·#41498·#40854는 원문이 "exit code는 0입니다" 형태였다. 같은 문장을 exit code 0으로 쓰면 통과한다. - 기대효과: 종료코드 계열 18건(missing 11 + invalid 7, 전체 라벨 중 최대)의 일부(조사형 4~5건)가 사라지고, 에이전트가 정직하게 쓴 보고가 반려되는 일이 없어진다.

2순위 — 자기참조 루프 차단 (태스크 body 템플릿 + 발행 규칙) - 무엇을: "needs_evidence N건 분류" 태스크가 같은 이유로 반려돼 다시 발행되는 루프를 끊는다. 이 제목의 태스크가 현재 건 중 26건(37+3건 중 65%)이다. - 왜: 이번 조회에서 제목에 "needs_evidence"가 들어간 반려 건이 26건이었다(guardian 23, cowork 3). 분류 과제가 반려되면 새 분류 과제가 발행되고, 그 과제도 반려된다. 건수가 8→37로 늘어난 주된 원인이다. - 기대효과: 신규 발행을 멈추고 이 제안서 하나로 대체하면, 신규 반려 증가분이 일 3~5건에서 0건 근처로 떨어진다(updated_at 기준 10/9~10/12 일 3,4,5,5건, 평균 4.25건).

3순위 — 분석 에이전트(analyst-pm/macro) 완료 보고 표준 보강 (에이전트 프롬프트 + 완료 보고 표준) - 무엇을: 도메인 판단문 뒤에 4블록을 붙이도록 프롬프트와 표준에 "분석 결과도 파일로 저장하고 근거파일에 경로:줄번호를 쓴다"를 명시. - 기대효과: missing_result_or_verification 7건(analyst-pm 4, analyst-macro 2, cowork 1) 해소.

2. [현황]

조회 명령과 반환 행 수 (이번 작업에서 직접 실행) - sqlite3 -readonly .../ops_multiagent.db "SELECT status,count(*) ... GROUP BY 1" → 2행: failed 3, needs_evidence 37 (합계 40). - 요청서의 확인 쿼리 SELECT claimed_by, status, substr(result_note,1,120) ... ORDER BY id DESC → 40행. - 집계표의 failed 5건 중 2건은 조회 시점(17:10)에 bus_commands에 더 이상 없다(#41597, #41599 조회 결과 0행, 보관 이동으로 추정 — 미확인). 현재 failed 3건은 #41601, #41602, #41604이며 모두 guardian이다. - 에이전트별(needs_evidence): guardian 26, analyst-pm 4, cowork 4, analyst-macro 2, ron 1. - 최신 id 41609, 가장 오래된 반려 건은 9/28 #40276.

반려 라벨 집계 (result_note의 "차단 사유/누락·차단" 절에서 python3로 추출, 40행, 한 건에 라벨 여러 개 가능)

라벨	건수	에이전트
(라벨 없는 "결과 확인 보류/검증 근거 없음" 템플릿)	12	guardian 11, cowork 1
missing_verification_exit_code	11	guardian 11
invalid_verification_exit_code	7	guardian 5, cowork 1, ron 1
missing_result_or_verification	7	analyst-pm 4, analyst-macro 2, cowork 1
missing_verification_command	3	guardian 3
source_log_path_not_found	2	guardian 2
verification_command_unverifiable	2	guardian 1, cowork 1
missing_execution_artifact	2	guardian 2
missing_source_log_path / truncated_unverifiable_evidence / execution_artifact_path_not_found / completion_result_note_forces_rework	각 1	guardian 3, cowork 1

• 인프라 지연(llm_infra_failure 계열)이 차단 사유인 건: 0건. (이 단어는 다른 분석 보고를 인용한 본문 11행에만 나온다.)
• 요청서가 언급한 missing_source, missing_execution_value, missing_original_verification은 차단 사유로 걸린 건이 0건이다.

3. 라벨별 상위 3개 원인과 수정 위치

라벨 A. 종료코드 계열 (missing 11 + invalid 7 = 18건, guardian 16건)

원인 1 — 게이트가 읽지 못하는 표기 (게이트 오탐) - 실측: 원문 재현에서 "검증: ... python3 /tmp/ne2.py의 exit code는 0입니다"는 missing_verification_exit_code, 같은 내용을 "exit code 0"으로 쓰면 통과. 조사(는/은/가)가 붙은 표기, 그리고 "검증:" 다음 줄에 불릿으로 적은 exit code가 못 읽힌다. - 수정 위치: 게이트 → 코드 수정 필요 - codex 위임 대상 - scripts/server.py _completion_storage_required_result_gaps (정규식 _STORAGE_EXIT_CODE_RE, "검증:" 줄만 보는 verification_lines 로직) - scripts/agent_queue_worker.py _codex_has_verification_result_field (_CODEX_VERIFICATION_RESULT_FIELD_RE) - 완화 방향(구현은 codex): 조사 허용(exit code(?:는|은|가)?\s*0), "검증:" 이후 같은 블록의 불릿 줄까지 탐색.

원인 2 — 에이전트가 리터럴 exit code 0을 안 쓰는 습관 (프롬프트·템플릿 미준수) - 실측: #40276은 원본 요약이 "수행한 일과 현재 상태를 완료형 한 문장으로 적는다"라는 양식 안내문 그대로여서 실제 보고가 없었다. - 수정 위치: 태스크 body 템플릿. [자동 보강] 문구가 지시문 앞쪽 실제 요구("합계 35건 일치 여부와 ls -l 결과 및 exit code 0")를 덮고 에이전트가 안내문 자체를 답으로 복사한다. - scripts/shared/agent_task_quality.py _completion_evidence_supplement_lines / _supplement_bare_completion_evidence_description → 코드 수정 필요 - codex 위임 대상: 안내문 앞에 "(아래는 작성 안내이며 답이 아니다)" 표시를 붙이고 검증: 기본 문구를 항상 "<명령> → <결과값>, exit code 0" 형태 한 줄 예시로 통일. - scripts/orchestrator.py _ensure_completion_evidence_block (1095행, 같은 안내문 생성부).

원인 3 — 반려 라벨명 뒤에 숫자가 붙는 자기참조 보고 (분류 태스크 특유) - 실측: "missing_verification_exit_code 8건"처럼 라벨명 바로 뒤에 숫자를 쓰면 exit_code 8을 종료코드 8로 읽던 문제. 10/13 패치(CMD#41573)로 정규식 왼쪽 경계가 이미 반영됐다(agent_queue_worker.py 7043행, public_result_formatter.py 3256행). 반영 이전 건 #40869·#41233·#41295·#41385·#41420이 이 유형으로 남아 있어 재처리하면 풀린다. - 수정 위치: 에이전트 프롬프트 (scripts/agent_registry.py 334/429/506행에 이미 금지 문구 있음) → 추가 코드 수정 불필요. 재처리 대상으로만 표시.

라벨 B. 라벨 없는 "결과 확인 보류" 템플릿 (12건, guardian 11)

원인 1 — 4블록 일부 누락 시 게이트가 개별 라벨 대신 일반 템플릿으로 덮어씀. 에이전트 원본은 "원본 요약" 뒤 일부만 남아 판정 불가(41504 보고가 같은 한계를 명시). - 수정 위치: 완료 보고 표준 → config/agent_completion_submission_standard.md에 "라벨 없는 보류의 우선 점검 순서(검증 줄 exit code 리터럴 → 근거파일 경로:줄 → 결론 완료형)" 1절 추가. 문서만 수정. 원인 2 — 자기참조 분류 과제(2순위 참조). 수정 위치: 태스크 body 템플릿. 원인 3 — result_note 360~486자로 잘려 원인 추적 불가. 수정 위치: scripts/agent_queue_worker.py의 하드블록 템플릿 생성부(결과 확인 보류 문자열 4166행 인근)에 차단 라벨 전체와 원문 전체 보존 경로를 남기도록 → 코드 수정 필요 - codex 위임 대상.

라벨 C. missing_result_or_verification (7건: analyst-pm 4, analyst-macro 2, cowork 1)

원인 1 — 분석 에이전트가 도메인 판단문(결론)만 내고 결과물 경로·검증 명령을 안 씀. 실사례 #40874·#40960·#41035: 원본이 "결론: 격차가 확대 국면입니다 ..."로 시작해 파일 경로가 없다. 원인 2 — 같은 주제(미국 IG·HY OAS)가 제목만 바꿔 6건 재발행 (#40408, #40518, #40874, #40960, #41035, #41067). 앞 건이 반려된 이유가 해소되지 않은 채 반복. 원인 3 — 최근 건(#41600)은 4블록과 근거파일(memory/us_credit_pm_judgment_20261013.md:17)을 갖춰 done이다. 즉 프롬프트(agent_registry.py의 analyst-pm 1358자, analyst-macro 1867자 모두 근거파일:과 exit code 포함)는 이미 반영돼 있고 과거 건이 반영 전 산물이다. - 수정 위치: 에이전트 프롬프트는 수정 불필요(이미 반영). 이 7건은 재처리 대상. 태스크 body 템플릿에는 "결과를 memory/ 아래 md로 저장 후 경로:줄 인용"을 한 줄 추가(orchestrator.py 태스크 생성 시 analyst 대상 body 보강, 코드 수정 필요 - codex 위임 대상: create_task, _ensure_completion_evidence_block).

라벨 D. 경로 허구·불일치 (source_log_path_not_found 2, execution_artifact_path_not_found 1, missing_source_log_path 1, missing_execution_artifact 2, truncated_unverifiable_evidence 1, 합계 약 7건, 전부 guardian)

원인 1 — 존재하지 않는 경로 인용: #41601은 /Users/ron/.hermes/data/ops_multiagent.db를 근거 경로로 쓰다 걸렸고 게이트가 "유사 실존 파일: /Users/ron/.hermes/workspace/data/ops_multiagent.db"를 제시했다(경로가 실제로 두 곳에 있는 혼동). #41323은 jobs.json을 워크스페이스 아래 경로로 오인. 원인 2 — 근거파일에 DB 경로를 쓰면서 줄번호·원문 인용이 없음(DB는 줄 단위 인용이 불가). 원인 3 — #41604는 result_note가 중간에서 잘려 truncated_unverifiable_evidence로 판정됐다(잘림 원인은 미확인). - 수정 위치: 태스크 body 템플릿(근거파일은 "분석 결과 md 파일을 만들어 그 파일 경로:줄번호 인용"을 요구; DB 직접 인용 금지). 완료 보고 표준에 "DB·스크립트는 근거 조회 대상이고 근거파일은 반드시 저장한 md" 한 줄 추가. 코드 변경 없음.

4. [리스크]

• 단일 장애점: guardian이 반려의 65~70%(26+3건 / 40건)를 차지한다. 한 에이전트의 프롬프트·템플릿이 문제를 키우는 구조다.
• 의존: 게이트 정규식은 server.py와 agent_queue_worker.py에 이중 구현돼 있다(같은 exit code 패턴을 두 군데에서 따로 유지). 한쪽만 고치면 서버가 다시 반려한다. 두 파일을 한 번에 고치고 같은 테스트로 검증해야 한다.
• 게이트 완화는 "근거 없는 완료" 통과 위험이 있다. 허용 범위는 exit code라는 글자와 숫자 0이 같은 검증 줄(또는 바로 아래 불릿)에 있는 경우로 한정해야 한다.
• 이 제안서는 현재 37+3건을 직접 풀지 않는다. 재처리나 상태 변경은 하지 않았다.
• 한계: result_note가 게이트 템플릿으로 덮여 있어 원본 4블록 존재 여부는 DB만으로 판정할 수 없다. 라벨은 차단 사유 문구 기준이다. 일부 원문은 agent-queue-guardian.log에서 확인했다.

5. [검증방법]

• KPI: needs_evidence 건수 37 → 10건 이하, 일 신규 반려 3~5건 → 1건 이하, "needs_evidence N건 분류" 제목 신규 발행 0건.
• 게이트 수정 검증(codex): 조사형 표기 ("exit code는 0입니다")와 불릿형 입력 2건이 _completion_storage_required_result_gaps(...)에서 missing_verification_exit_code 없이 통과하고, exit code 1 입력은 계속 invalid로 반려되는지 pytest 3건 이상. 기대값: 전부 passed.
• 건수 확인 명령: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT claimed_by,count(*) FROM bus_commands WHERE status='needs_evidence' GROUP BY 1" → 합계 기대값 10 이하(적용 3일 후).
• 롤백 조건: 수정 후 24시간 안에 근거 없는 보고(빈 검증 줄, 비실존 경로)가 done으로 저장되는 건이 1건이라도 나오면 정규식 변경을 되돌린다.