완료근거 누락 방지 운영안
[권고]
→ 1순위: 모든 에이전트의 done 보고 끝에 결론/근거/검증/근거파일 4블록을 독립 줄로 강제한다. 이유는 최근 bus_commands 8건 조회에서 ron 4건, analyst-technical 2건, cowork 2건이 missing_* 또는 근거 섹션 미기재 계열로 failed 처리됐기 때문이다. 기대효과는 동일 라벨 재반려를 7일 내 50% 이상 줄이는 것이다.
→ 2순위: cowork 상태메시지와 done 보고를 분리한다. type=status, status=None, block_reasons=task_status 메시지의 근거 섹션 미기재 placeholder는 완료보고가 아니며, bus_commands canonical status=done/failed의 result_note에서만 위반 여부를 판단한다. 기대효과는 상태메시지 오지목 0건이다.
[현황]
최근 DB 조회 결과, 완료근거 누락 패턴 최신 8건은 ron 4건, analyst-technical 2건, cowork 2건이다. 최신 사례는 #39335 ron missing_verification_command, #39333 analyst-technical missing_execution_artifact/missing_verification_command/missing_verification_exit_code, #39331 cowork 근거 섹션 미기재/verification_command_unverifiable/missing_verification_result다. 정책 파일은 agent_completion_submission_standard.md 81~90행에 4블록 템플릿, 217~250행에 완료제출과 상태핸드오프 분리, 252~281행에 위반 지목 전 선행확인을 이미 둔다. completion_evidence_policy.md 16~18행도 status=done 보고에만 근거를 요구한다고 명시한다.
[리스크]
구조적 위험은 세 가지다. 첫째, 상태메시지 placeholder가 done 보고처럼 오인되면 조사 태스크가 반복 생성된다. 둘째, self_evolve.py처럼 존재하지 않는 경로를 근거로 쓰면 4블록을 채워도 반려된다. 셋째, cowork는 설계 에이전트라 코드형 태스크를 받으면 직접 done 처리하지 말고 codex 위임 또는 blocked/delegated로 정리해야 한다. 원인은 정책 부재가 아니라 제출 직전 경로·검증값 확인 누락과 status-only 메시지 오분류다.
[검증방법]
KPI는 72시간 내 result_note LIKE '%missing_%' OR '%근거 섹션 미기재%' 반려 건수 50% 감소, status-only placeholder 오지목 0건이다. 검증 명령은 sqlite3 /Users/ron/.hermes/data/ops_multiagent.db "SELECT claimed_by, COUNT(*) FROM bus_commands WHERE result_note LIKE '%missing_%' OR result_note LIKE '%근거 섹션 미기재%' GROUP BY claimed_by;"다. 기대값은 동일 에이전트 동일 라벨 3연속 재발 0건이다. 롤백 조건은 4블록을 모두 채운 원문이 있는데도 missing_execution_artifact 등 미등재 라벨로 3회 반려되는 경우이며, 이때는 정책 재작성 대신 게이트 코드 재조사를 codex에 위임한다.
에이전트별 작성 규칙
ron/guardian: 실제 실행 로그와 검증 명령을 근거와 검증 줄에 그대로 쓴다. “정상 확인함” 단독 금지.
cowork: [권고]/[현황]/[리스크]/[검증방법] 제안서와 별개로 마지막에 4블록을 추가한다. 코드 수정·구현 태스크는 done 금지, codex 위임 또는 blocked/delegated.
analyst 계열: 숫자 판단 옆에 데이터 소스, 조회시각, 검증 명령, 원문 파일 줄을 붙인다. 경로는 제출 전 실존 확인한다.
공통: 근거: 근거 섹션 미기재 — 결론 참고는 상태메시지 placeholder로만 허용된다. done 보고의 근거: 줄에는 실제 파일·DB·API와 조회시각만 쓴다.
반려 시 재작성 절차
- bus_commands에서 해당 id의 canonical status/result_note를 먼저 읽는다.
- 메시지가
status=None이고task_status/run_cycle_status/healthcheck_status/agent_log_status/internal_state_status면 완료보고 위반으로 보지 않는다. - 실제 완료제출이면 반려 라벨을 하나씩 매핑한다:
missing_source는 근거 경로,missing_verification_*는 검증 명령과 exit code,execution_artifact_path_not_found는 실존 경로 재확인,근거 섹션 미기재는 근거 줄 자체를 실제 소스로 교체한다. - 재작성문은 아래 4줄로 끝낸다.
결론: 운영안은
/Users/ron/knowledge-agent/400-reports/260919_cowork_completion_evidence_ops_plan.md에 작성했고, 핵심 방지책은 done 보고 4블록 강제와 status-only placeholder 분리다. 근거:/Users/ron/.hermes/workspace/config/agent_completion_submission_standard.md,/Users/ron/.hermes/workspace/config/completion_evidence_policy.md,/Users/ron/.hermes/data/ops_multiagent.db최신 8건 패턴 조회 2026-09-19 03:39 KST. 검증:test -f /Users/ron/knowledge-agent/400-reports/260919_cowork_completion_evidence_ops_plan.md && grep -E "^결론:|^근거:|^검증:|^근거파일:" /Users/ron/knowledge-agent/400-reports/260919_cowork_completion_evidence_ops_plan.md | wc -l→ 저장 후 4개 이상이면 통과. 근거파일: /Users/ron/knowledge-agent/400-reports/260919_cowork_completion_evidence_ops_plan.md:32 "공통:근거: 근거 섹션 미기재 — 결론 참고는 상태메시지 placeholder로만 허용된다. done 보고의근거:줄에는 실제 파일·DB·API와 조회시각만 쓴다."