needs_evidence 81건 재발 방지안 (조회 2026-10-27 11:44 KST)

상태: 운영 문서. 코드·DB·크론 변경 없음. 수정이 필요한 소스는 6절에 목록만 둔다.

1. 결론

81건 전부 "차단 사유" 필드를 직접 읽어 분류했다. 인프라 지연(llm_infra_failure)이 차단 사유에 들어간 건은 0건이다. 81건 모두 제출 규율 문제다: 4블록 라벨 누락·검증 exit code 누락(a), 미존재 경로 인용(b).
가장 큰 덩어리 두 개는 "결과 확인 보류"(33건, 40.7%)와 missing_verification_exit_code(23건, 28.4%)다.
새 규칙은 만들지 않는다. 필요한 규칙은 두 기준 문서에 이미 있다. 부족한 것은 (1) 태스크 본문에 자동으로 붙는 안내문이 규칙과 어긋나는 점, (2) 에이전트가 안내문을 그대로 복사해 제출하는 점이다.

2. 실측 집계

조회: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT claimed_by, status, result_note FROM bus_commands WHERE status='needs_evidence'" → 81행 (id 40276~42798, updated_at 2026-09-28 13:11 ~ 2026-10-27 04:12). 최근 7일(10-20 이후) 26건.

2-1. 에이전트별

에이전트	건수	비율
guardian	58	71.6%
cowork	12	14.8%
analyst-macro	6	7.4%
analyst-pm	4	4.9%
ron	1	1.2%
합계	81	100%

2-2. 반려 라벨별 (한 건에 라벨 여러 개 가능, "차단 사유:" 필드 기준)

라벨	건수	비율	유형
결과 확인 보류 (게이트의 일반 사유)	33	40.7%	원인 미분리, 아래 3절
missing_verification_exit_code	23	28.4%	(a)
검증 근거 없음	18	22.2%	(a)
결과물과 검증 근거가 없음	15	18.5%	(a)
missing_result_or_verification	14	17.3%	(a) analyst 계열
invalid_verification_exit_code	10	12.3%	(a) exit code 0 아님
missing_verification_command	9	11.1%	(a)
completion_result_note_forces_rework	5	6.2%	(a)
missing_execution_artifact	4	4.9%	(a)
verification_command_unverifiable	3	3.7%	(a)
execution_artifact_path_not_found	5	6.2%	(b)
llm_infra_failure (차단 사유 필드)	0	0%	(c)

주의: 같은 result_note 본문에 "llm_infra_failure"라는 단어가 16건에 보이지만, 모두 guardian·cowork가 "인프라 지연 0건"이라고 쓴 분석문 인용이다. 차단 사유 필드에는 한 건도 없다. 단순 문자열 검색으로 세면 (c)가 16건으로 잘못 나온다.

2-3. guardian 집계 md와 대조

찾은 파일: ~/.hermes/workspace/memory/2026-10-26_needs_evidence_aggregation.md (조회 2026-10-26 04:22 KST, 76행).
대조: 에이전트별 guardian 56→58, cowork 9→12, analyst-macro 6=6, analyst-pm 4=4, ron 1=1. 라벨은 결과 확인 보류 30→33, missing_verification_exit_code 21→23. 증가분(+5)이 모두 기존 상위 라벨에 붙어 구조가 같다. 그 파일의 "llm_infra_failure 차단 0건" 결론도 이번 실측과 일치한다.
같은 날 cowork 제안서 ~/knowledge-agent/400-reports/261027_claude_needs_evidence_backlog_policy.md, 261026_cowork_needs_evidence_76_prevention_plan.md 등 선행 문서가 다수 있다(이 문서는 그것들과 별개로 81건 실측만 반영).

3. 상위 2개 라벨 대표 사례 (result_note 원문)

3-1. "결과 확인 보류" (33건)

이 문구는 게이트가 구체 사유를 덮어쓴 일반 문구다. 원문을 읽어야 진짜 원인이 보인다.

CMD#41101 (guardian, 24시간 needs_evidence 원인 분류). 원문: 결론: 결과 확인 보류 / 근거: 결과물과 검증 근거가 없음. 차단 사유: 결과 확인 보류. … 원본 요약: 결론: 최근 24시간 … 3종으로 분류했다. … 근거: sqlite3 -readonly …(2026-10-07 14:18 KST). 에이전트는 결론·근거를 썼으나 "검증:"·"근거파일:" 줄이 요약에 남아 있지 않다. 유형 (a) 4블록 중 검증·근거파일 누락.
CMD#41151 (guardian, 19건 라벨 집계). 원문 요약에 sqlite3 명령은 있으나 검증 결과(exit code)와 근거파일 줄이 없다. 유형 (a).
판정: 대표 2건 모두 (a). (b)·(c) 아님. 33건 중 차단 사유가 이 문구 하나뿐인 건 15건이라 이 15건은 구체 라벨이 없어 개별 원문 판독이 필요하다.

3-2. missing_verification_exit_code (23건 / guardian 20, cowork 3)

CMD#40346 (guardian, 옛 경로 MCP 헬스서버 중복 조회). 원문 요약은 결론과 ps -ax 근거를 갖췄지만 검증 줄에 exit code 리터럴이 없다. 유형 (a).
CMD#40276 (guardian, agent_queue_worker 타임아웃 패치 반영 확인). 원문 요약의 "결론:"이 수행한 일과 현재 상태를 완료형 한 문장으로 적는다.다. 즉 태스크 본문 말미의 자동 보강 안내문을 에이전트가 값으로 그대로 복사해 냈다. 유형 (a), 그중 안내문 복사 사례(81건 중 1건 확인).
공통점: 이 라벨 23건 중 원문 요약에 exit code·rc=·returncode 리터럴이 있는 것은 1건뿐이다. 검증 명령은 돌렸으나 결과 숫자를 적지 않았다.

3-3. 보조 사례: (b) 미존재 경로 5건

CMD#42762 (cowork): 인용 경로 /Users/ron/.hermes/workspace/261026_cowork_needs_evidence_76_resolution_policy.md. 이 경로는 workspace 최상위로, 실제 저장 위치(~/knowledge-agent/400-reports/…)와 다르다.
CMD#41323 (guardian): /Users/ron/.hermes/workspace/jobs.json (실제는 ~/.hermes/cron/jobs.json). CMD#42062: /Users/ron/.hermes/workspace/ne_agg.py (실제는 /tmp/ne_agg.py). CMD#42314: 경로 칸에 "tmp_ne_agg.py와 tmp_ne_agg2.py입니다" 문장이 들어감. CMD#42778(cowork): 경로 칸에 "scripts/server.py 1006~1015행"처럼 줄 범위 포함.
판정: 허구라기보다 경로 오기·임시 파일 인용·줄범위 혼입이다. 유형 (b).

3-4. 눈에 띄는 구조 하나

cowork 12건 중 제목에 needs_evidence·반려 방지안·정책안이 들어간 태스크가 11건이다(제목 직접 확인, 나머지 1건은 #42778 코드 경로 수정)(예: #41348, 41495, 41715, 41782, 41917, 42083, 42503, 42762, 42781). 방지안 문서를 쓰는 태스크가 같은 이유로 반려되는 순환이 생겼다. 본 문서의 태스크도 같은 계열이다.

4. 원인 유형별 판정

유형	건수(차단 사유 기준)	판정
(a) 4블록 라벨·exit code·검증 명령 누락	76건 (81건 중 (b) 5건 제외)	압도적 다수
(b) 미존재·오기 경로 인용	5건	소수, 개별 교정
(c) 인프라 지연 llm_infra_failure	0건	해당 없음

(b) 5건은 (a)의 missing_verification_command·missing_verification_exit_code와 동시 발생했다(CMD#41323, 42062, 42778 등).

5. 원인 유형별 재발 방지안 (이미 문서화된 규칙 인용)

5-1. 유형 (a) 4블록·exit code 누락

인용 규칙: config/agent_completion_submission_standard.md 3-1절 (119~127행) "짧은 운영 문구". 원문 일부: "결과 확인 보류"를 다시 결과로 제출하지 않는다. 4줄 틀은 결론/근거/검증/근거파일이며 "검증"은 <실행한 검증 명령 또는 계산> → <실제 결과값/건수/exit code>다.
인용 규칙: 같은 문서 177~181행 — exit code가 0이 아니면 이유를 묻지 않고 invalid_verification_exit_code로 반려한다. 부재 확인은 부정형 명령(! grep -rlq ...; echo "exit code $?")으로 exit code 0을 만든다(245행 표).
인용 규칙: 같은 문서 625~668행 — analyst-fundamental·codex는 "검증:" 값에 exit code 0 리터럴이 필수다. analyst-macro/technical/pm에는 적용되지 않는다고 적혀 있으나, 이번 analyst-macro·pm 10건은 missing_result_or_verification 단일 사유이므로 별도 점검 대상이다(미확인: 그 문서가 가정한 범위와 현재 게이트의 일치 여부).
운영 행동(문서 인용 범위): 제출 직전에 검증 줄 끝에 exit code 0을 숫자로 적는다. 명령 결과가 exit 1인 grep이면 부정형 명령으로 바꿔 돌린다.

5-2. 유형 (b) 경로 오기

인용 규칙: config/completion_evidence_policy.md 1000~1003행 — execution_artifact_path_not_found는 정상 동작이며 "게이트가 너무 빡빡하다"로 오인하면 안 된다. 같은 문서와 agent_completion_submission_standard.md 243행 표: 필드에 실존 경로만 기입하고, 없으면 필드 자체를 뺀다.
운영 행동: 제출 전 ls -l <경로>로 실존을 확인한 결과를 검증 줄에 쓴다. 임시 파일(/tmp/...)은 근거파일로 쓰지 말고 workspace 또는 knowledge-agent 아래에 저장한 경로만 인용한다. 경로 칸에는 경로만 쓰고 줄 범위·설명 문장은 뒤 인용부에 둔다.

5-3. 유형 (c) 인프라 지연

이번 81건에는 해당 건이 없다. 인프라 지연 판정 기준은 기존 문서 그대로 두고, 이 문서에서 새 기준을 만들지 않는다. 다만 집계 시 본문 단어가 아니라 "차단 사유:" 필드로만 세어야 한다(2-2절 주의).

5-4. 메타 순환 (방지안 작성 태스크가 방지안 대상이 되는 문제)

신규 방지안 문서 작성 태스크는 cowork 12건 중 11건이 같은 계열이다. 새 문서를 또 만들기 전에, 2-3절의 기존 문서 목록과 본 문서를 먼저 읽고 건수만 갱신하는 것을 기본으로 한다(문서 가이드: 새 규칙 없이 인용).

6. 코드 수정 필요 항목 (목록만, 직접 수정하지 않음)

scripts/orchestrator.py 1146행 — 태스크 본문에 붙는 [자동 보강: 완료보고 4블록 필수 …] 안내문 생성부. 안내문 문장이 에이전트에게 그대로 복사될 수 있다(CMD#40276 사례).
scripts/shared/agent_task_quality.py 1048행 — [자동 보강: 완료보고 4블록 설명형 라벨 보충] 안내문. 이번 태스크 본문에도 "검증: exit code 0; 통과" 형태가 들어가 있어 "exit code 0 또는 통과"라는 안내와 게이트가 어긋날 수 있다.
scripts/server.py 733행 _STORAGE_EXIT_CODE_RE — 게이트가 exit code 숫자를 요구한다(선행 문서 261027_hermes_needs_evidence_prevention.md 이전 판에서 안내문과의 모순을 지적함). 이 문서에서는 정규식 자체를 재검증하지 않았다(미확인).
게이트가 구체 사유를 "결과 확인 보류"로 덮는 부분(scripts/shared/public_result_formatter.py 계열): 33건 중 15건은 구체 라벨이 없어 원인 분류가 어렵다. 사유 라벨을 항상 남기게 하는 수정 후보.
서버·워커의 재시작 반영 여부: CMD#42778 원문에 "서버와 워커가 수정 전 코드를 메모리에 올린 채 돌고 있다"는 주장이 있다. 이 문서에서는 미확인이다.

7. 미확인·한계

33건 중 구체 라벨 없는 15건은 원문을 개별로 읽지 않았다. 대표 2건(#41101, #41151)만 읽었다.
5-1의 analyst-macro/pm 게이트 범위는 코드를 열어 확인하지 않았다.
6절의 server.py·public_result_formatter.py 줄 번호는 이 문서에서 일부만 재확인했다(733행 존재, 1048행·1146행 존재 확인).

needs_evidence 81건 재발 방지안 (DB 실측, 원인 유형별)