needs_evidence 19건 반려 집중 조합 방지안 제안서
needs_evidence 19건 반려 집중 조합 방지안 (CMD#41112, cowork)
1. [권고]
1순위 — guardian × missing_verification_exit_code (6건 / 19건 = 31.6%, 라벨 중복 포함 7건): 검증 줄 끝의 exit code 0이 사라지는 두 경로를 문구로 막는다. (가) 노트 아무 데나 missing_verification_exit_code 4건처럼 라벨 뒤에 숫자를 붙이면 서버 정규식이 그 4를 종료 코드로 읽는다. (나) 노트가 600자를 넘으면 정규화가 검증 줄을 약 295자에서 자르는데, exit code 0을 줄 끝에 두면 같이 잘린다. (다) 노트 자체에 exit code가 없는 경우(#40276은 "수행한 일과 현재 상태를…" 자동 보강 안내문을 그대로 제출, #40994는 검증 줄에 exit code 없음). 6건 재생 결과: (가) 라벨 숫자 오독 2건(#40854, #40902), (나) 절단 소실 1건(#40346), (다) 원문 자체에 없음 2건(#40276, #40994), 재현 안 됨 1건(#40633, 정규화 후 게이트 통과이므로 반려 시점과 현재 코드가 다를 수 있음). 기대효과: 재현된 5건 기준 7일 내 같은 조합 신규 0~1건이 목표다.
2순위 — analyst-pm × missing_result_or_verification (4건 = 21.1%) 및 analyst-macro 같은 라벨 2건(10.5%): 노트 원문은 게이트를 통과하는데(#41067, #41035 원문을 worker 게이트에 재생하면 gaps 0건) 600자 정규화본이 truncated_unverifiable_evidence, missing_source_log_path로 떨어진다. 원인은 정규화기가 긴 결론/근거 뒤에 스스로 붙이는 ...와, 근거파일 인용 안의 닫히지 않는 {가 만나는 것이다. 결론 250자, 근거 340자 이하로 쓰고 인용에서 중괄호를 빼도록 문구를 넣는다. 재생 결과 6건(#40408, #40518, #40874, #40960, #41035, #41067)의 정규화본 gap은 truncated_unverifiable_evidence+missing_source_log_path 3건(#40874, #40960, #41067), verification_command_unverifiable 2건(#40408, #41035), verification_command_path_not_found 1건(#40518)으로 갈린다. 큰 원인(600자 절단 후 근거·검증 형식 훼손)은 같지만 세부 gap은 한 가지가 아니며, { 미닫힘이 직접 원인임은 #41067에서만 확인했다. 기대효과: 7일 내 analyst-pm/macro 해당 조합 6건 → 2건 이하 목표.
참고(3위 동률, 2건): guardian × 결과 확인 보류(#40825, #41101)는 노트 본문이 이전 반려 문구 결과 확인 보류를 따옴표로 인용해 하드블록 구문에 걸린 경우다. 3순위 문구로 같이 처리한다.
2. [현황] 조회 결과
- 조회: sqlite3 -readonly ops_multiagent.db, status='needs_evidence' → 19행, 조회 2026-10-07 17:40 KST. 에이전트별: guardian 10, analyst-pm 4, analyst-macro 2, cowork 2, ron 1.
- 대표 라벨(result_note의 '차단 사유' 첫 항목) 기준 (에이전트, 라벨) 상위: guardian/missing_verification_exit_code 6, analyst-pm/missing_result_or_verification 4, analyst-macro/missing_result_or_verification 2 (guardian/결과 확인 보류 2와 동률). 라벨 전체를 세면 guardian/missing_verification_exit_code 7.
- guardian이 15:42에 완료한 #41105는 "합계 21건(needs_evidence 19 + failed 2), 최다 guardian missing_verification_exit_code 7건"으로 집계했고, 라벨 중복 포함 기준과 일치한다. 이 제안서는 대표 라벨 1개 기준 6건을 1위 수치로 쓴다.
- 이 19건 중 인프라 실패(llm_infra_failure)가 사유인 건은 없다. #41108(cowork, failed)은 별도 건이다.
- 재생 실험(코드 수정 없음, worker/server 게이트 함수를 읽기 전용 호출):
- 정규화 600자 후 검증 줄 길이 실측: 검증 텍스트 192자까지
exit code 0유지, 292자부터 소실 → servermissing_verification_exit_code. - 결론 250자는 전문 유지, 400자는
...삽입. 근거도 250자 유지, 400자...삽입. -
40854/#40902 원문: 서버 정규식 첫 매치가 라벨 인용
...exit_code: 4건의 4라서invalid_verification_exit_code. exit code는 0처럼 조사를 끼우면 정규식이 숫자를 못 잡아 servermissing_verification_exit_code.-
41067 원문: worker gaps 0건이지만 정규화본은
['truncated_unverifiable_evidence', 'missing_source_log_path'], server['missing_verification_exit_code'].
3. 4블록 규칙 대조: 어느 항목이 누락인가
| 조합 | 4블록 중 | 직접 원인 | 기존 문서 |
|---|---|---|---|
| guardian × missing_verification_exit_code | 검증 줄의 exit code 0 (3번째 블록) |
라벨 뒤 숫자 오독, 정규화 절단 | standard 245행 invalid_verification_exit_code 표, standard 641행 "exit code 0 리터럴" (analyst-fundamental/codex 전용으로만 설명됨) |
| analyst-pm/macro × missing_result_or_verification | 근거/근거파일 블록 형식 (정규화 후) | 정규화기 ... 삽입 + 근거파일 { |
standard 244행 truncated_unverifiable_evidence (잘린 JSON 붙여넣기만 다룸) |
| guardian × 결과 확인 보류 | 결론/근거에 반려 문구 인용 | 하드블록 구문 매치 | policy 273행 근처 R8 자기참조 차단(가정은 있으나 프롬프트 문구 없음) |
기존 문서와의 관계: 261006_claude_needs-evidence-prevention.md 5절 규칙 1~5가 라벨 숫자 문제와 ...·{ 문제를 이미 다룬다. 이번 제안은 그 문서에 없는 2가지를 더한다 — 600자 정규화 절단 길이 한도(검증 줄, 결론, 근거)와 exit code는 0 조사 함정.
4. 추가할 방지 문구안 (AGENTS.md에는 쓰지 않음, 제안 문안만)
AGENTS.md "대행 태스크 완료보고 검증 근거 정책" 절 끝에 붙일 문안:
- 완료 보고 길이 한도(2026-10-07 실측): result_note가 600자를 넘으면 정규화가 줄을
자른다. 결론 250자, 근거 340자, 검증 줄 190자 이하로 쓴다. 검증 줄은
`<명령> → <결과값 한두 단어>, exit code 0` 순서로 쓰고 exit code 0은 반드시
한 줄 안에서 끝에 둔다. `exit code는 0`, `exit code: 영`처럼 조사나 한글을 끼우지
않는다. 긴 설명은 400-reports 파일에 쓰고 노트에는 그 경로만 인용한다.
- 반려 라벨 이름 뒤에 숫자를 붙이지 않는다(`missing_verification_exit_code 4건`
금지). 건수가 필요하면 `4건(missing_verification_exit_code)`처럼 숫자를 앞에 쓴다.
이전 반려 문구 `결과 확인 보류`는 따옴표로 인용하지 말고 "반려됨"으로 쓴다.
- 근거/근거파일 인용에 `{`, `}`, `...`, `…`를 쓰지 않는다. JSON 줄은
`파일:행 "키 값 한 구절"` 형태로 줄이고 중괄호는 빼서 적는다.
guardian 프롬프트(agent_registry.py guardian 항목)와 analyst-pm/macro 프롬프트 말미에 붙일 한 줄:
제출 전 점검: 결론 250자·근거 340자·검증 줄 190자 이하인가, 검증 줄이 `→ 결과, exit code 0`으로 끝나는가, 노트에 `{`·`...`·반려 라벨+숫자가 없는가.
5. [리스크]
- 길이 한도는 정규화기의 현재 실측값(max_len=600, agent_queue_worker.py 4239행 정의)이다. 정규화기 코드가 바뀌면 한도도 바뀐다. 한도가 너무 짧아 근거가 줄면 제3 반려(근거 빈약)로 번질 수 있어 근거 상세는 파일로 보내라고 같이 적었다.
- 서버 정규식이 노트 어디든 첫 매치를 종료 코드로 읽는 구조(server.py 814·825행) 자체는 이번 범위 밖(코드 수정)이라 문구로만 막는다. 문구를 어기면 같은 반려가 재발한다.
- 같은 취지의 문서가 이미 여러 개(261005~261007 분량 6건 이상) 있어 에이전트 프롬프트에 실제로 반영되지 않으면 또 한 장이 늘 뿐이다. 반영 경로가 단일 장애점이다.
6. [검증방법]
- 반영 후 7일간:
sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT claimed_by, count(*) FROM bus_commands WHERE status='needs_evidence' AND updated_at >= date('now','-7 day') GROUP BY claimed_by"에서 guardian 10→3 이하, analyst-pm 4→1 이하. - 라벨별: 같은 기간 result_note LIKE '%missing_verification_exit_code%' 건수 0~1.
- 회귀 확인: 반영 문구대로 쓴 샘플 노트를
_normalize_agent_result_minimal_basis후_completion_storage_required_result_gaps에 넣어[]가 나오는지(이번 실험에서 검증 줄 136자·196자 샘플은[]). - 롤백/재검토 조건: 반영 후 7일에도 같은 두 조합이 3건 이상이거나, 새 라벨(근거 빈약류)이 3건 이상 생기면 한도 문구를 되돌리고 codex에 정규화기 절단 정책 수정(별도 태스크)을 위임한다.
완료 보고 4블록
결론: needs_evidence 19건을 조회해 상위 3개 (에이전트, 라벨) 조합을 확인하고, 4블록 중 검증 줄 exit code 누락과 정규화 후 근거 형식 훼손이 원인임을 재생으로 확인해 방지 문구안을 제안서로 작성했다. 근거: sqlite3 -readonly ops_multiagent.db status='needs_evidence' → 19행 조회, 2026-10-07 17:40 KST. 검증: grep -c "결론:|근거:|검증:|근거파일:" 이 파일 → 라벨 줄 확인, exit code 0. 근거파일: /Users/ron/.hermes/workspace/scripts/server.py:814 "result_match = _STORAGE_EXIT_CODE_RE.search(raw)"