needs_evidence 42건 반복 반려 원인별 방지안 (cowork, 읽기 전용 조사)

조회 시각 2026-10-15 13:50 KST. DB는 sqlite3 -readonly와 mode=ro 연결로만 열었다. 소스 코드·DB·설정은 수정하지 않았다. 이 문서 안의 정책 문구는 "초안"이며 config/ 문서에는 아직 반영하지 않았다.

[권고]

1순위 (문서 규칙만으로 해소, 대상 12건): missing_verification_exit_code 12건은 전부 guardian이다. 검증 줄을 "→ 결과값, exit code 0"으로 쓰고 exit code 뒤에 조사(는/가/은)를 붙이지 않는다. 기대효과: guardian 점검형 태스크의 해당 라벨 신규 0건.
2순위 (문서 규칙만으로 해소, 대상 14건): 집계·분류 보고에서 게이트 차단 구절("결과 확인 보류" 등)은 반드시 백틱이나 따옴표로 감싸서 인용한다. 결론·검증 줄에는 풀어 쓴다. 기대효과: 라벨 없는 보류 템플릿 신규 0건.
코드 수정이 필요한 부분은 codex 위임 후보로만 적는다 (아래 [codex 위임 후보]).

[현황]

SELECT count(*) FROM bus_commands WHERE status='needs_evidence' → 42행 (13:48 KST). 에이전트별: guardian 30, cowork 5, analyst-pm 4, analyst-macro 2, ron 1. result_note의 "차단 사유:" 구간 라벨을 기준으로 분류했다 (한 행에 라벨이 여러 개면 중복 집계).

순위	사유	건수	에이전트
1	missing_verification_exit_code	12	guardian 12
2	라벨 없는 보류 템플릿 ("결과 확인 보류"/"검증 근거 없음"만 있음)	14	guardian 12, cowork 2
3	invalid_verification_exit_code	7	guardian 5, ron 1, cowork 1
4	missing_result_or_verification	8 (라벨 중복 포함)	analyst-pm 4, analyst-macro 2, cowork 1, guardian 1
5	그 외 (verification_command_unverifiable 1, missing_next_action_section 1 등)	소수	cowork 중심

건수 순으로는 라벨 없는 보류 템플릿(14)이 1위, missing_verification_exit_code(12)가 2위다. 이하 이 두 사유를 "상위 2개"로 본다. 참고: guardian #41712가 11:53에 보고한 41건과 이번 42건의 차이는 1건이다 (재조회 사이에 #41715가 needs_evidence로 저장됨). #41712의 result_note에는 조회 시각 "2026-10-15 11:53 KST"와 코드·DB 미수정이 적혀 있고, 41건 안에서 "최근 24시간"은 실제와 다르다고 스스로 정정했다. 날짜 분포: 09-28 ~ 10-15, 17개 일자. 10-05 ~ 10-12 사이 하루 1~5건씩 쌓였다 (10-05 4건, 10-06 4건, 10-11 5건, 10-12 5건). 인프라 지연(llm_infra) 계열 라벨은 "차단 사유" 구간에 0건이다.

상위 2개 사유 — 기존 규칙으로 해소되는가

사유 A. 라벨 없는 보류 템플릿 14건 (guardian 12, cowork 2)

태스크 유형: 전부 제목에 needs_evidence/반려 분류가 들어간 메타 과제다 (#40825, #41101, #41151, #41233, #41316, #41387, #41435, #41485, #41494, #41495, #41504, #41627, #41628, #41715). 전체 42건 중 제목에 needs_evidence 또는 반려가 있는 행은 30건(guardian 25, cowork 5)이다.
게이트 로그(logs/completion_evidence_blocked.jsonl)에서 14건 모두 surface=server.close_bus_command, reasons는 "결과 확인 보류", "검증 근거 없음", "결과물과 검증 근거가 없음" 중 하나 이상이다.
실측 (직접 함수 호출): shared.public_result_formatter.completion_result_note_forces_rework 에 아래 두 입력을 넣었다.
표 셀에 차단 구절을 그대로 쓴 경우 (| 결과 확인 보류 | 7 |) → True (차단)
작은따옴표로 감싼 경우 ('결과 확인 보류' 라벨이 7건) → False (통과)
차단 구절만 있는 note (결론: 결과 확인 보류) → True (차단, 정상 동작)
따라서 이 게이트는 이미 따옴표·백틱·각종 인용부호 구간을 제외하도록 만들어져 있다 (scripts/shared/public_result_formatter.py 3588행 strip_quoted_citations). 표 셀처럼 부호 없이 쓴 구절만 걸린다.
규칙 해소 여부: 기존 규칙으로 부분 해소. 인용부호를 쓰라는 규칙은 코드에는 있으나 두 정책 문서 어디에도 "집계 보고에서 차단 구절을 인용할 때는 반드시 부호로 감싼다"는 지시가 없다 (grep -n "차단 구절\|차단 문구" 두 문서 → 0건). 새 문서 규칙이 필요하다.
정정: 같은 날 이전 문서(memory/2026-10-15_needs_evidence_41_prevention_plan.md)의 codex 후보 3번은 "백틱·따옴표 안 인용을 제외하도록 _completion_hard_block_phrase_reasons를 고치자"고 적었는데, 이 제외 로직은 이미 agent_queue_worker.py 466행 함수 안(scan = _strip_quoted_citations(raw) or raw)에 있다. 그 항목은 코드 수정이 필요 없다.
증폭 구조: 이 메타 과제가 반려되면 건수가 늘고, 늘어난 건수를 다시 분류하는 과제가 발행된다. 이 보고서 자체도 같은 유형이다.
미확인: 14건 중 2건(#41494, #41504)은 저장된 앞부분 221자에서 구절이 따옴표 안에 있는데도 차단됐다. result_note는 221자로 잘려 저장돼 있어 뒷부분의 부호 없는 구절 때문인지 직접 확인하지 못했다.

사유 B. missing_verification_exit_code 12건 (전부 guardian)

대상 CMD: 40276, 40346, 40633, 40842, 40854, 40902, 40994, 41274, 41323, 41431, 41498, 41640. 게이트 로그에서 12건 모두 server.close_bus_command가 missing_verification_exit_code를 기록했다.
실측 (직접 호출): server._completion_storage_required_result_gaps 에 검증 줄만 바꿔 넣었다.
... → 1행, exit code 0 → gaps [] (통과)
... → 1행, exit code는 0이다. 통과. → ['missing_verification_exit_code'] (차단)
... → 1행 통과 → ['missing_verification_exit_code'] (차단)
원인 식: scripts/server.py 733행 _STORAGE_EXIT_CODE_RE가 exit code 바로 뒤 숫자(구분자는 :/=/공백만)만 인정한다. "exit code는 0"과 "통과"는 인정하지 않는다.
유도 구조: 12건 중 5건(#40633, #40842, #41274, #41431, #41640)의 태스크 body에 "exit code 0 또는 통과를 적는다"류 문구가 있다. 전체 42건 중 같은 문구가 body에 있는 행은 9건이다. 이 문구는 scripts/orchestrator.py 1104, 1131, 1137, 1795행과 scripts/shared/agent_task_quality.py 1004행의 자동 보강 상용구에서 나온다 (grep -n 실측 5곳).
규칙 해소 여부: 기존 규칙으로 해소 안 됨. config/agent_completion_submission_standard.md 186~188행은 "exit code 0 리터럴을 쓰라"고 하지만 exit=0 표기만 다룬다. "exit code는 0", "통과 대체"는 grep -c "exit code는" 두 문서 모두 0건으로 금지돼 있지 않다. 새 문서 규칙이 필요하다.

정책 문서 초안 (반영 전, 코드 수정 없음)

config/agent_completion_submission_standard.md §3-1 아래에 넣을 후보 문구.

검증 줄 exit code 표기 (needs_evidence 42건 조사, 2026-10-15):
- 검증 줄은 "검증: <실행한 명령> → <결과값>, exit code 0" 형태로 쓴다.
  "exit code" 바로 뒤에 숫자 0을 붙이고 조사(는/가/은)나 마침표를 끼우지 않는다.
- "통과", "성공", "정상"은 exit code 숫자를 대체하지 못한다. 태스크 body가
  "exit code 0 또는 통과"라고 적혀 있어도 exit code 0 리터럴을 쓴다.
- 부재 확인 등으로 명령이 exit 1을 내면 부정형 명령을 써서 exit code 0을 만든다 (기존 §3 부재 확인 소절).

집계·분류 보고의 차단 구절 인용:
- 반려 사유를 설명하려고 게이트 차단 구절("결과 확인 보류", "검증 근거 없음",
  "결과물과 검증 근거가 없음")이나 라벨 이름을 쓸 때는 반드시 백틱이나 따옴표로 감싼다.
  표 셀 안에 부호 없이 쓰지 않는다.
- 결론·검증 줄에는 구절을 쓰지 않고 "인프라 지연 0건", "4블록 누락 N건"처럼 풀어 쓴다.
- 같은 분류 과제는 직전 정본 문서가 있으면 새로 만들지 않고 SELECT 한 줄로 건수만 갱신한다.

[리스크]

게이트가 3곳(scripts/shared/public_result_formatter.py, scripts/agent_queue_worker.py, scripts/server.py)에 있고 server.py는 장기 실행 프로세스다. 이전 문서 기록 기준 09-28 기동이라 코드 변경분이 반영됐는지 이번에 직접 확인하지 못했다 (미확인).
문서만 고치고 자동 보강 상용구(5곳)를 그대로 두면 body에 "또는 통과"가 계속 붙어 B 사유가 재발한다.
이 보고서와 같은 메타 과제가 계속 발행되면 건수가 다시 늘어난다 (30/42건이 메타 과제 제목).

[검증방법]

지표: needs_evidence 신규 일 건수, missing_verification_exit_code 신규 건수, 제목에 needs_evidence가 든 신규 과제 수.
명령: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT claimed_by,count(*) FROM bus_commands WHERE status='needs_evidence' AND updated_at>='<반영시각>' GROUP BY 1" → 기대값 24시간 내 0~2행.
롤백 조건: 문서 반영 후 7일 안에 같은 라벨이 3건 이상 재발하면 문서만으로는 부족하다고 보고 아래 codex 후보를 진행한다.

[codex 위임 후보] (코드 수정 필요분, 이 문서에서는 수정하지 않음)

자동 보강 상용구의 "또는 통과" 제거
대상: scripts/orchestrator.py 1104, 1131, 1137, 1795행 / scripts/shared/agent_task_quality.py 1004행
같은 파일 함수명은 해당 행을 감싸는 태스크 보강 함수 (codex가 확인).
게이트 재시도 안내문 구체화
대상: scripts/agent_queue_worker.py 4172행 _RETRY_ITEM_BY_GAP 의 missing_verification_exit_code 항목 ("검증 결과의 exit code").
표 셀 인용 구절 제외 (선택)
대상: scripts/shared/public_result_formatter.py _QUOTED_CITATION_RE / strip_quoted_citations 에 마크다운 표 셀 인용을 포함할지 검토. 문서 규칙(부호로 감싸기)으로 충분하면 불필요.
반려 분류 과제 중복 발행 억제
대상: scripts/orchestrator.py create_task().
운영 중 scripts/server.py 프로세스 재시작은 해리 승인 후에만.