needs_evidence 29건 공통 원인별 처리 기준 제안서

작성: cowork, 조회 2026-10-11 08:20 KST. 읽기 전용 조회만 했고 DB 상태 변경, 코드 수정, 재발행은 하지 않았다. 선행 집계: guardian CMD#41409(done, 2026-10-11 07:09 조회, needs_evidence 29건·failed 3건)의 result_note를 먼저 읽었고 재집계는 하지 않았다. 아래 건수는 그 결과와 같은 29건(guardian 19, analyst-pm 4, cowork 3, analyst-macro 2, ron 1)이며, 이번에 한 일은 "묶음별 원인 구분 + 처리 기준 확정"이다. 대조 문서: config/agent_completion_submission_standard.md, config/completion_evidence_policy.md, config/needs_evidence_27_agent_policy_20261010.md, config/needs_evidence_29_label_prevention_proposal_20261010.md.

[권고]

1순위 — 29건 중 23건(79%)을 "폐기 후보"로 해리에게 올린다. 근거: 23건은 (a) 반려 집계·분류 스냅샷 16건(guardian), 중복 제안서 1건(#40691), (b) 시효가 지난 점검 3건(#40276, #40297, #41323), (c) 같은 주제 중복 분석 3건(#40960, #41035, #41067)이다. 집계 스냅샷의 최신판은 #41409(done)이고, 그 뒤에 집계 태스크를 더 돌릴수록 그 태스크가 다시 needs_evidence가 되는 자기참조가 생긴다(집계류 16건 + cowork 집계 #41348 = 17건/29건 = 59%). 기대효과: 큐의 needs_evidence 29건 → 6건(-79%).

2순위 — 4건은 "재제출 가능"(#40346, #40518, #40954, #41348), 2건은 "지시문 수정 후 재발행"(#40408, #40874)으로 처리한다. 재제출 4건은 산출물 파일이 실존하므로 내용을 다시 만들 필요가 없고 result_note 표기만 고치면 된다. 재발행 2건은 데이터 기준일이 낡았고(아래 현황) 지시문이 중괄호가 열린 소스 줄 인용을 시켜 게이트 오탐을 유도했기 때문이다.

3순위(참고) — 게이트 코드 결함은 이미 codex 위임 후보로 두 문서(27건·29건 제안서 §4)에 정리돼 있다. 이 제안서는 그 내용을 반복하지 않고, 처리 기준에서 "게이트 수정 전/후"만 구분했다.

[현황] 반려 사유 묶음 5개와 원인 구분

구분 기호: (가) 제출 규율 문제 = 에이전트가 형식을 어김. (나) 태스크 지시문 문제 = body가 실패를 유도하거나 요구 불가능한 것을 요구. (게이트) = 형식을 맞췄는데 판정 코드가 오독(참고 구분, 지시문·규율 어느 쪽도 아님). "원문 확인"은 이전 문서가 로그 원문으로 재현한 것을 인용했다는 뜻이며 이번에 재현한 것이 아니다. DB 저장본 result_note는 382자 안팎으로 압축돼 4블록 판별이 안 된다.

묶음 1. missing_verification_exit_code — 7건 (#40276, #40346, #40633, #40854, #40902, #40994, #41274)

• (가) 확정 2건: #40276(검증 줄이 "pytest"뿐, 결론 줄이 지시문 템플릿 문장 그대로), #40902(결론이 포맷터 기본 문구 "작업 결과가 정리됨"). 근거: 27건 문서 §2-A-3.
• (나) 4건: #40276, #40854, #40902, #40994는 body 지시부(자동 보강 문구 앞)에 "exit code"라는 단어가 없다(이번에 body 29건을 정규식으로 직접 확인: 지시부에 "exit code" 없는 건은 #40276, #40854, #40869, #40902, #40954, #40994, #41295 7건).
• (게이트) 2건: #40854, #41274는 4블록이 모두 있고 검증 줄이 "exit code는 0입니다"인데, config/agent_completion_submission_standard.md의 반려 규칙이 쓰는 exit code 뒤 숫자 정규식은 조사가 낀 표기를 못 읽는다(scripts/agent_queue_worker.py 7030-7033행 정규식 원문 확인).
• 미확인 3건: #40346, #40633, #40994는 원문 재현을 하지 못했다.
• 판정: (나)+(가) 혼합. 지시문에 "검증 줄 끝에 exit code 0(조사 없이)"를 넣어도 (게이트) 2건은 표기만 바꿔서 통과 가능하다.

묶음 2. invalid_verification_exit_code — 6건 (#40297, #40869, #41295, #41348, #41377, #41385)

• (나) 1건: #40297(ron). 지시가 "지정 스크립트 실행 → exit code 기록"이어서 성공 말고는 통과 경로가 없었는데, 당시 스크립트가 시작 즉시 exit 1이었다. 에이전트는 실패를 솔직히 보고했다(27건 문서 §2-F).
• (게이트) 2건: #40869, #41295는 반려 분류 보고서가 라벨 이름 missing_verification_exit_code 4건처럼 쓰자 게이트가 exit_code 4를 검증 결과로 읽었다(scripts/server.py 733-736행 정규식에 왼쪽 경계가 없음). 에이전트 잘못이 아니다.
• 추정 3건: #41348, #41377, #41385는 같은 반려 분류 보고서라 같은 구조로 추정되나 원문 재현은 미확인이다.
• 판정: (나)+(게이트). (가) 확정 0건.

묶음 3. missing_result_or_verification — 6건 (analyst-pm #40874, #40960, #41035, #41067 / analyst-macro #40408, #40518)

• (가) 0건: 29건 문서가 6건 전부 4블록과 exit code 0이 있었다고 원문으로 확인했다.
• (나) 6건: body가 "근거파일에는 ... 원문 한 줄 인용"을 요구하고 대상이 scripts/pipeline/market_indicator_tracker.py 882행 부근의 "IG_SPREAD": {"series": ... 같은 딕셔너리 줄이어서, 중괄호가 열린 줄을 인용하게 된다. 이 줄이 "잘린 증거"로 오판됐다(completion_has_truncated_inline_evidence, 27건 문서 §2-C).
• 판정: (나)+(게이트). 지시문에서 인용 대상 줄을 중괄호 없는 줄로 지정하면 게이트 수정 전에도 통과한다.

묶음 4. 일반 문구 반려 ("결과 확인 보류/검증 근거 없음") — 6건 (#40825, #41101, #41151, #41233, #41316, #41387)

• 전부 guardian의 반려 집계·분류 태스크다. 구체 라벨 없이 일반 문구만 남아 있다. 선행 문서가 원문으로 재현한 건은 #41298·#41304(이번 29건 밖)뿐이고, 이 6건 자체는 원문 재현 미확인이다.
• 선행 문서의 설명: 집계 보고서가 다른 건의 반려 문구를 본문에 인용하면 게이트가 그 문구를 하드블록으로 읽는다(27건 문서 §2-B).
• 판정: (나) 구조 문제로 분류한다. 이유는 태스크 유형(반려 집계)이 인용 문구를 필연적으로 만들기 때문이다. (가)로 단정할 근거는 없다.

묶음 5. 경로·명령·재작업 라벨 — 4건 (#40842, #41323, #40691, #40954)

• 40842: (가). missing_execution_artifact + missing_verification_command + missing_verification_exit_code 3중 라벨, 템플릿 복사 4건 중 하나(27건 문서 A-3).

• 41323: (가). 라벨 execution_artifact_path_not_found:/Users/ron/.hermes/workspace/jobs.json. body는 /Users/ron/.hermes/cron/jobs.json을 읽으라고 정확히 지정했는데 에이전트가 존재하지 않는 workspace/jobs.json을 인용했다. 이번에 ls로 workspace/jobs.json이 없고 cron/jobs.json은 있음(315229B)을 확인했다.

• 40691, #40954(cowork): 미확인. 두 건 모두 현재 게이트 함수로 재현되지 않았다는 선행 기록이 있다(27건 문서 §2-C·E).

묶음 판정 요약

묶음	건수	(가) 규율	(나) 지시문	(게이트)	미확인
1 missing_verification_exit_code	7	2	4	2	3
2 invalid_verification_exit_code	6	0	1	2	3
3 missing_result_or_verification	6	0	6	6	0
4 일반 문구	6	0	6(유형)	-	6
5 경로·명령·재작업	4	2	0	0	2
합계	29	4	-	-	14

한 건이 여러 칸에 겹칠 수 있어 가로 합이 건수와 다를 수 있다. 확정된 (가) 규율 문제는 4건(#40276, #40902, #40842, #41323)뿐이다. 나머지 25건 중 상당수는 에이전트가 형식을 지켰는데 지시문 또는 게이트 때문에 걸렸다. 따라서 에이전트에게 "더 잘 쓰라"는 경고를 다시 보내는 처리는 근거가 없다.

[현황] 처리 기준과 건별 분류

처리 기준 3종: - 재제출 가능: 산출물 파일이 실존하고 고유 내용이 다른 문서에 없다. result_note만 다시 쓴다. 조건은 아래 "재제출 작성 규칙". - 폐기 후보: 산출물이 후속 건·기존 문서로 대체됐거나, 점검 시효가 지났거나, 같은 주제가 중복이다. 상태 변경은 해리 확인 후에만 한다. - 지시문 수정 후 재발행: 산출물 가치는 있으나 데이터 기준일이 낡았거나 지시문이 오탐을 유도한다. 새 CMD로 재발행하고 원 건은 폐기 후보로 같이 올린다.

A. 재제출 가능 — 4건

id	에이전트	근거
40346	guardian	산출물 logs/guardian_legacy_mcp_dup_20260929.md 실존(5106B, 9/29 03:05, ls 확인). 검증 줄에 test -f ... && echo ok → ok, exit code 0 추가만 필요. 단, 표의 PID 정보는 9/29 기준이므로 "기준 시점 2026-09-29"를 근거에 명시. kill·재시작 판단은 이 건과 별개로 해리 확인 사항
40518	analyst-macro	산출물 /Users/ron/knowledge-agent/100-inbox/260930_hermes_us-ig-oas-trend.md 실존(1833B, 9/30 23:15). 근거파일 줄을 중괄호 없는 줄로 교체. 데이터 기준일 2026-09-28 표기 필수
40954	cowork	산출물 /Users/ron/knowledge-agent/400-reports/261006_cowork_guardian_24h분류표_보고템플릿_제안서.md 실존(9124B, 10/6 03:37). guardian 특화 보고 템플릿은 다른 문서에 없는 고유 내용
41348	cowork	산출물 config/needs_evidence_29_label_prevention_proposal_20261010.md 실존(8923B, 10/10 12:11). 이번 제안서가 인용한 선행 문서다

B. 지시문 수정 후 재발행 — 2건

id	사유	지시문 수정점
40408	등급별 격차(BBB-AA 등) 산출. 입력 us-ig-weekly-latest.json의 as_of가 당시 2026-09-24에서 현재 2026-10-08로 바뀌었다(직접 확인). 결과값이 낡음	근거파일 인용 줄을 중괄호 없는 줄로 지정, "검증 줄은 exit code 0(조사 없음)"을 body 지시부에 명시, 기준일은 as_of를 읽어 적게 함
40874	HY-IG 격차 종합. 주제 대표로 선정(#40960, #41035, #41067이 같은 주제). BAMLC0A0CM.json·BAMLH0A0HYM2.json 마지막 관측일이 현재 2026-10-07로 갱신됨(직접 확인)	위와 동일. 데이터 기준일이 오늘보다 며칠 뒤처지는지 적게 하는 기존 문구 유지

C. 폐기 후보 — 해리 확인용 목록 (23건, 실행하지 않음)

C-1. 반려 집계·분류 스냅샷 16건 (guardian). 최신판 #41409(done)가 29건을 이미 집계했고, 선행 제안서 5종이 같은 내용을 다뤘다. 이 건들의 산출물 파일(예: memory/needs_evidence_breakdown_20261010.md 7000B)은 폐기해도 파일은 그대로 남는다. 40633, 40825, 40842, 40854, 40869, 40902, 40994, 41101, 41151, 41233, 41274, 41295, 41316, 41377, 41385, 41387

C-2. 중복·시효 지난 건 7건. | id | 사유 | |---|---| | 40276 | 워커 8개 시작시각이 9/27 07:55였을 때의 질문이다. 지금은 ps로 확인한 워커 시작시각이 2026-09-29 01:27~02:16이라 9/28 12:28 패치 이후다. 질문 자체가 해소됨. 다만 agent_queue_worker.py 수정시각이 10/3 05:15라서 그 이후 수정분은 워커에 반영되지 않았을 수 있다. 이는 미확인이며 워커 재시작은 해리 승인 사항이라 이 제안서에서 실행하지 않았다 | | 40297 | 9/28 ETF 예열 건. 당일치 데이터 요구라 지금 재제출해도 의미 없음. 같은 스크립트가 10/9 16:46에 returncode 0으로 실행된 로그가 있다(logs/prewarm/20261009T074641Z.attempt1.meta.json). 휴장일 SKIP이었음 | | 41323 | 10/11 09:00 크론(5c45c26045be) 사전 점검이었다. 점검 시한이 지난다. 직접 확인한 값: enabled true, schedule 0 9 * * 0, state scheduled. 스크립트 build_weekly_credit_house_summary.py는 실존하나 수정시각이 10/11 08:20이라 오늘 수정됐다(py_compile은 이번에 돌리지 않음, 미확인). 09:00 이후 실행 결과 확인으로 대체 | | 40691 | missing_next_action_section 방지안. 같은 내용이 config/needs_evidence_repeat_rejection_prevention_20261005.md와 config/knowledge_salon_insight_gate_prevention_proposal_20260930.md에 있다(grep으로 라벨 존재 확인). 이 건의 산출물 경로는 확인하지 못했다 | | 40960, 41035, 41067 | 미국 IG·HY 스프레드 종합 판단. #40874 재발행으로 대체. 기준일이 10/1~10/2로 현재 10/7 데이터보다 낡음 |

[리스크]

• 폐기 23건이 모두 "산출물이 대체됐다"는 판단에 기댄다. #40691은 산출물 경로를 확인하지 못했으므로 해리가 이 한 건은 보류로 돌릴 수 있다.
• 폐기해도 게이트 오독은 그대로 남는다. 코드 수정 없이 재제출·재발행하면 같은 라벨이 다시 생긴다. 이번 제안서의 재제출·재발행 기준은 "표기 회피 규칙"을 지키는 것을 조건으로 했다.
• 묶음 1·2·4의 일부(미확인 14건)는 원문 재현을 하지 못했다. 이 분류는 라벨과 선행 문서에 의존한다.
• 집계 태스크가 자기참조로 계속 needs_evidence를 늘린다. 오케스트레이터가 같은 제목군("needs_evidence N건 ... 집계")을 계속 발행하는 한 29건을 정리해도 며칠 뒤 같은 수가 쌓인다. 근거: 집계류 17건/29건.
• 재제출 시 에이전트가 이번 규칙을 모르면 같은 실수를 한다. 규칙은 태스크 body에 넣어야 한다.

[검증방법]

재제출 작성 규칙(재제출·재발행 body에 반드시 넣는다): 1. 검증 줄은 exit code 0으로 끝낸다(조사 없이 한 칸 띄움). 2. 반려 라벨 이름을 쓸 때 밑줄을 공백으로 바꾼다(missing verification exit code 7건). 3. 근거파일은 한 줄에 경로:줄번호 "인용"으로 쓰고, 열린 중괄호가 있는 줄은 인용하지 않는다. 4. 지시문 끝 자동 보강 문구("수행한 일과 현재 상태를 완료형 한 문장으로 적는다" 등)는 결과가 아니므로 복사하지 않는다. 5. 존재하지 않는 경로는 인용하지 않는다(인용 전 ls로 확인).

KPI와 측정: - 폐기 확정 후 needs_evidence 잔여: 기대값 6건(재제출 4 + 재발행 원건 2, 재발행 원건도 폐기 처리하면 4건). 명령: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT COUNT(*) FROM bus_commands WHERE status='needs_evidence'" - 재제출 4건의 통과 여부: 기대값 4건 모두 status가 done으로 바뀜. 명령: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT id,status FROM bus_commands WHERE id IN (40346,40518,40954,41348)" - 집계 태스크 재발행 억제: 7일간 제목에 "needs_evidence"가 들어간 신규 태스크 중 needs_evidence 상태가 된 건수, 기대값 0건. - 롤백 조건: 재제출 4건 중 2건 이상이 같은 라벨로 다시 반려되면 게이트 코드 수정(27건·29건 제안서 §4, codex 위임)을 먼저 하고 재제출을 멈춘다. 폐기 확정 후 해리가 특정 건을 되살리려면 해당 id만 재발행한다(상태 복구 대신 새 CMD).

해리 확인용 목록 (실행하지 않음)

• 폐기 후보 23건 id: 40276, 40297, 40633, 40691, 40825, 40842, 40854, 40869, 40902, 40960, 40994, 41035, 41067, 41101, 41151, 41233, 41274, 41295, 41316, 41323, 41377, 41385, 41387
• 재제출 가능 4건 id: 40346, 40518, 40954, 41348
• 지시문 수정 후 재발행 2건 id: 40408, 40874
• 합계 23 + 4 + 2 = 29