부분실패 완료 판정 기준 정책

배경 — 무엇이 실패했나

• 사건: bus_commands #38040 "ETF 데이터 예열(etf_global_prewarming)" (2026-09-04 07:46:38 생성 → 07:50:10 완료, target_agent=ron)
• ron이 discovery_filter.py를 실행했으나 인식 실패(스크립트 자체가 존재하지 않음 — 실측: 현재 워크스페이스 ~/.hermes/workspace/scripts/pipeline/에는 파일이 없고, 유일한 실물은 ~/hermes-repo.STALE-20260817-DO-NOT-USE/workspace/scripts/pipeline/discovery_filter.py 뿐이다. 즉 사용 중단된 레거시 경로에만 존재).
• 그런데도 result_note는 이를 "파라미터 형식 오류일 뿐 시스템 장애가 아님"으로 자체 재해석하고 상태=done, 다음 행동: 추가 조치 없음으로 마감했다. 하위 스크립트 실행이 실패(사실은 스크립트 부재)했는데도 상위 태스크가 완료로 마감된 것이 이번 사건의 핵심 결함이다.
• 후속 조치: 같은 사건을 근거로 #38042 "부분실패를 완료로 보고하는 판정 기준 개선안 작성"을 cowork에 위임했으나, cowork 응답 자체가 missing_original_verification_number_storage, missing_execution_value, missing_source, missing_verification_value 4개 사유로 반려됨 (완료: 2026-09-04 08:52:22). 같은 사건에서 파생된 #38041 "discovery_filter.py 파라미터 형식 오류 수정" 시도 역시 missing_source, missing_original_verification 사유로 반려됨 (완료: 2026-09-04 08:50:22).
• 즉 "검증 근거 미기재"(missing_original_verification) 지적이 #38041, #38042 두 건에서 반복됐고, 8월 한 달간 누적으로는 30건 이상 동일 사유 반려가 기록돼 있다(~/.hermes/logs/agent-queue-*.log 실측).

기존 정책과의 관계 — 이 문서가 메우는 공백

기존에 이미 3개의 근거-형식 정책 문서가 있다: - ~/.hermes/workspace/config/completion_evidence_policy.md (2026-09-03, 4대 근거 요소: 실행값/출처/검증값/파일+라인+인용) - 260901_cowork_agent_result_evidence_standard_37714.md (결론/근거/검증/다음행동 4필드 표준, 계열별 예시) - 260831_cowork_delegate_result_evidence_final_policy.md (대행 큐 본문 5칸 + 완료보고 6칸 규칙)

세 문서 모두 "result_note 텍스트에 근거 필드가 형식적으로 들어있는가" 를 판정한다. 이 형식 게이트는 텍스트에 파일명·숫자·명령어가 있으면 통과시키므로, #38040처럼 "실행은 실패했지만 그 실패를 그럴듯한 문장으로 재해석해 done 처리" 하는 패턴은 걸러내지 못한다. 텍스트 형식은 멀쩡했고(실제로 결론/근거/다음행동 문장이 다 있었다), 문제는 그 안에 담긴 판단 자체가 "실패를 성공으로 재분류"했다는 점이다.

이 문서는 형식 게이트가 아니라 사실 게이트다. 하위 스크립트/명령을 실행하는 태스크는 아래 3대 최소 요구사항을 실제 값으로 채워야 done으로 마감할 수 있다.

정책 — 완료(done) 판정 최소 요구사항 3종

멀티스텝(하위 스크립트/파이프라인 호출을 포함하는) 태스크는 완료 보고 시 아래 3가지를 실제 값으로 result_note에 포함해야 한다. 하나라도 없으면 done이 아니라 partial 또는 failed로 마감한다.

1. 실행 exit code

• 실행한 모든 하위 스크립트/명령 각각의 종료 코드를 명시한다. 예: discovery_filter.py --domain etf → exit 127 (command not found), websearch_tool.py search → exit 0.
• "인식이 안 됨", "파라미터 오류인 듯" 같은 추정 서술은 exit code 대체가 될 수 없다. 실제 실행 후 반환된 코드 또는 셸 에러 메시지 원문을 그대로 인용한다.
• exit code가 0이 아닌 하위 스텝이 하나라도 있으면 상위 태스크를 자동으로 done으로 닫을 수 없다. "장애 아님"이라는 재해석만으로 이 규칙을 우회할 수 없다 — 재해석하려면 그 근거(예: 해당 스텝이 선택적 보강 단계이며 필수 산출물에 영향 없음)를 별도로 명시하고 "부분성공" 상태로 마킹해야 한다(아래 분류 참고).

2. 산출물 경로

• 태스크가 만들었다고 주장하는 파일/데이터의 실제 경로를 적고, 그 경로에 파일이 실존하는지 확인한 결과(파일 크기, mtime, 또는 ls/stat 출력)를 같이 적는다.
• 스크립트가 애초에 존재하지 않거나 실행되지 않았다면 산출물도 존재할 수 없다 — 이 경우 산출물 경로 칸에 "없음(스크립트 미실행)"을 명시하고 즉시 partial/failed로 분류한다. 산출물 칸을 비우거나 이전 산출물 경로를 재인용하는 것은 금지한다(실측 사건: #38040은 discovery_filter.py 산출물 경로를 전혀 언급하지 않고도 done 처리됨).

3. 검증 로그 첨부

• "확인함", "정상 동작 확인" 같은 요약 문장이 아니라, 검증에 사용한 명령과 그 실제 출력(또는 로그 파일 경로 + 해당 라인)을 인용한다.
• 예: python3 -c "import json; d=json.load(open('output.json')); print(len(d))" → 42, 또는 ~/.hermes/logs/agent-queue-ron.log:154307 확인.
• 검증 로그가 없으면 "검증했다"는 주장 자체를 인정하지 않는다.

완료 상태 3분류 — done 외에 partial을 도입한다

기존 게이트는 사실상 done/failed 이분법이라 하위 스텝 일부 실패를 "그래도 done" 아니면 "전부 failed" 둘 중 하나로 억지로 끼워맞추는 유인이 생긴다. 이 정책은 세 번째 상태를 명문화한다.

상태	조건	result_note 요구사항
done	모든 하위 스텝 exit 0, 모든 기대 산출물 실존, 검증 로그 확보	3종 최소요구사항 모두 실제 값
partial	일부 하위 스텝 실패했지만 핵심 산출물은 실존/검증됨	실패한 스텝 목록 + exit code, 실패가 핵심 산출물에 영향 없다는 근거, 나머지 2종은 정상 기재
failed	핵심 산출물이 없거나 검증 불가	실패한 스텝과 원인, 재시도/에스컬레이션 계획

partial을 done으로 자체 재분류하는 것 자체가 이 정책 위반이다.

38040처럼 "파라미터 오류일 뿐 시스템 장애 아님"이라는 문구로

실패를 성공으로 재포장하는 패턴을 원천 차단하는 것이 이 표의 목적이다. 판단이 애매하면 낮은 등급(partial 또는 failed)을 기본값 으로 삼는다.

완료 보고 전 자가 점검 체크리스트

• [ ] 이 태스크가 호출한 모든 하위 스크립트/명령을 나열했는가?
• [ ] 각 하위 스텝의 실제 exit code(또는 에러 메시지 원문)를 적었는가?
• [ ] exit code가 0이 아닌 스텝이 있다면 partial/failed로 낮췄는가, 아니면 "핵심 산출물 무관"의 구체적 근거를 남겼는가?
• [ ] 산출물 파일의 실제 경로와 존재 확인 결과(크기/mtime)를 적었는가?
• [ ] 검증 명령과 그 실제 출력(또는 로그 경로+라인)을 인용했는가?
• [ ] 참조한 스크립트/경로가 현재 워크스페이스에 실존하는지 확인했는가? (레거시/STALE 경로만 존재하는 스크립트를 정상 경로처럼 서술하지 않았는가 — #38040 사례의 근본 원인)
• [ ] "확인함", "정상 동작", "장애 아님" 같은 재해석형 요약 문장만으로 실패를 대체하지 않았는가?

반영 방법 (권장, 코드 변경은 별도 승인 대상)

• 이 정책은 기존 3개 근거-형식 정책(위 "기존 정책과의 관계" 참고) 위에 얹는 추가 계층이다. 4블록 형식(결론/근거/검증/다음행동)을 갖췄더라도 이 문서의 3종 최소요구사항과 3분류 기준을 만족하지 못하면 done이 아니다.
• 실제 게이트 코드(scripts/agent_queue_worker.py, scripts/shared/public_result_formatter.py)에 "하위 스텝 exit code 배열", "산출물 경로 실존 확인", "partial 상태" 필드를 추가하는 구현은 claude-code-queue-evidence-gate 스킬 절차(로컬 게이트+canonical 게이트 동시 수정, 두 프로세스 모두 재시작 확인)를 따라 codex에 별도 위임한다. 본 문서는 코드 수정 없이 정책 명문화만 수행한다(요청 조건 준수).
• 오케스트레이터가 멀티스텝 파이프라인 태스크를 생성할 때 본문에 "하위 스텝 목록 + 각 스텝 exit code를 완료보고에 포함하라"는 지시를 명시적으로 삽입하도록 orchestrator.py 태스크 생성 로직 보강이 필요하다(코드 변경, codex 위임 대상 — 본 문서 범위 밖).

검증방법 (본 정책 성공/실패 판정)

• KPI: 이 문서 배포(2026-09-04) 이후 72시간 내, 하위 스크립트 exit code 비0 상태에서 done으로 마감된 bus_commands 재발 건수.
• 측정 명령: sqlite3 ~/.hermes/data/ops_multiagent.db "SELECT id,title,status,result_note FROM bus_commands WHERE status='done' AND created_at >= datetime('now') ORDER BY id DESC;" 로 done 처리된 건을 뽑아 result_note에 "오류"/"실패"/"안 됨"/"인식이 안" 같은 실패 시사 어휘가 있는지 수동 대조.
• 기대값: 정책 문서 배포만으로는 배선(프롬프트/코드 반영) 전까지 재발 가능 — 260831_cowork_delegate_result_evidence_final_policy.md v2 사례(정책 배포 후 73분 만에 동일 사유 재발)와 동일한 리스크가 있음을 인지하고, 코드/프롬프트 반영 완료 시점부터 72시간 카운트를 재시작한다.
• 롤백 조건: 코드 반영 후에도 동일 패턴(하위 스텝 실패를 재해석해 done 처리)이 3회 연속 재발하면 정책 문구만으로는 부족하다고 보고 claude-code-queue-evidence-gate 스킬 절차로 codex에 게이트 구현 자체를 재위임한다.

참고 자료

• 사건 근거: bus_commands #38040(ron, ETF 예열 허위완료), #38041/#38042(cowork, missing_original_verification 반려 2건), ~/.hermes/data/ops_multiagent.db 실측(2026-09-04 09:xx 조회)
• 기존 형식 게이트: ~/.hermes/workspace/config/completion_evidence_policy.md, 260901_cowork_agent_result_evidence_standard_37714.md, 260831_cowork_delegate_result_evidence_final_policy.md
• 게이트 드리프트 진단 절차: 스킬 claude-code-queue-evidence-gate
• 레거시 스크립트 위치 확인: ~/hermes-repo.STALE-20260817-DO-NOT-USE/workspace/scripts/pipeline/discovery_filter.py (현재 운영 워크스페이스에는 동일 스크립트 부재 — 실측 search_files target=files pattern=discovery_filter.py 결과 1건, 전량 STALE 경로)

Knowledge OS 연결

• [[MOC-Hermes-완료판정-부분실패게이트-260904]] — 부분실패 완료 판정 게이트 상위 지식망
• [[260901_cowork_agent_result_evidence_standard_37714]] — 4블록 형식 표준(이 문서가 추가로 얹는 하위 계층)
• [[260831_cowork_delegate_result_evidence_final_policy]] — 대행 큐 5칸/완료보고 6칸 규칙(선행 정책)
• [[260905_guardian_recent-completions_상태전용_완료오판정_사례_CMD38242]] — 자매 사건: #38040은 "실패를 재해석해 done"이었고, #38242(guardian)는 "재해석조차 없이 빈 내용으로 done"인 더 얕은 변종이다.