완료근거 누락 재발 방지 운영안

1. [권고]

1순위: 모든 신규 bus 태스크 본문 끝에 완료 제출 조건 4줄을 고정 문구로 넣는다. 결론/근거/검증/근거파일 라벨은 줄 맨 앞에 독립 줄로 둔다. 최근 실패 5건 중 5건이 결과 확인 보류 또는 missing_* 계열이었고, 그중 3건은 실행값·출처·검증값이 동시에 빠진 유형이었다. 기대효과는 동일 사유 반려 50% 이상 감소다.

2순위: 반려 후 재발행은 원문 전체 재작성 금지, 반려 라벨별 보완 재발행으로 제한한다. missing_source는 실제 경로+조회시각, missing_verification_value는 검증 명령+결과, execution_artifact_path_not_found는 경로 실존 재확인, verification_command_path_not_found는 실행 가능한 명령으로 교체한다. 기대효과는 2차 재반려 3회 연속 발생 시 즉시 코드 조사로 격상하는 운영 손실 차단이다.

2. [현황]

정책 기준 파일 2개를 확인했다. config/agent_completion_submission_standard.md는 76~103행에서 완료 보고 4블록을 결론/근거/검증/근거파일 순서와 라벨 그대로 요구한다. config/completion_evidence_policy.md는 16~28행에서 실행값·출처·검증값·파일+라인+원문 인용 4대 근거를 요구한다.

최근 DB 조회 결과, 2026-09-20 13:33~14:38 KST 사이 최신 반려 5건이 확인됐다. ron 4건, analyst-macro 1건이다. 대표 사유는 missing_verification_result, missing_execution_value, missing_source, missing_verification_value, missing_original_verification, verification_command_unverifiable, execution_artifact_path_not_found, 도구가 없다였다. 특히 39516, 39509는 8개 누락 라벨이 동시에 붙어 4블록 전무형에 가깝다.

3. [리스크]

구조적 위험은 세 가지다. 첫째, 태스크 본문이 “완료 기준”을 설명하지 않으면 에이전트가 제안서 형식만 맞추고 실제 완료 보고 4블록을 빠뜨린다. 둘째, 반려 후 재발행 때 직전 라벨을 보지 않고 전체를 다시 쓰면 같은 빈칸이 반복된다. 셋째, 존재하지 않는 경로나 차단된 도구를 검증값처럼 쓰면 라벨은 채워도 게이트가 더 강하게 반려한다. blocked: not in whitelist는 보안 정상 동작이지 완료 근거가 아니다.

4. [태스크 본문 작성 기준]

태스크 생성자는 본문 마지막에 아래 문구를 그대로 붙인다.

완료 제출 조건: status=done은 아래 4줄을 모두 채운 경우에만 제출한다. 결론: 실행/작성/확인/수정한 대상을 완료형 한 줄로 쓴다. 제안·예정·보류 금지. 근거: 직접 읽은 파일/DB/API/로그 + 조회 YYYY-MM-DD HH:MM KST를 쓴다. 사유만 쓰지 않는다. 검증: 실행한 검증 명령 또는 계산 → 실제 결과값/건수/exit code를 쓴다. 정상 확인 단독 금지. 근거파일: 실존 경로:줄번호 "원문 일부"를 쓴다. 경로·줄번호·인용 중 하나라도 빼지 않는다.

코드 작성 금지 에이전트가 코드형 태스크를 받으면 done 제출 금지다. codex 재위임 ID를 근거에 쓰고 blocked 또는 delegated로 낸다. 시장 데이터 태스크는 기억으로 스크립트명을 쓰지 말고 먼저 실제 경로를 확인한다.

5. [반려 후 재발행 기준]

1. 직전 result_note의 반려 라벨을 먼저 복사한다.
2. 라벨별로 빠진 값만 채운다. missing_execution_value는 실제 수행 동사와 대상, missing_source는 실존 소스, missing_verification_value는 명령과 결과, missing_original_verification은 파일:줄번호+원문 인용이다.
3. execution_artifact_path_not_found나 verification_command_path_not_found가 있으면 제출 전 경로 실존을 다시 확인한다.
4. 결과 확인 보류, 근거 섹션 미기재, 도구가 없다, 확인 못함은 done 재발행 문구로 금지한다. 실패라면 blocked로 내고 대체 근거 또는 다음 조치를 쓴다.
5. 같은 태스크가 2회 연속 같은 라벨로 반려되면 3회째 재작성하지 않고 게이트 코드 또는 태스크 라우팅 문제로 격상한다.

6. [검증방법]

KPI 1: 향후 72시간 result_note에 결과 확인 보류 또는 missing_*가 포함된 신규 반려 건수. 기준선은 최신 조회 5건이다. 목표는 72시간 내 동일 패턴 2건 이하, 50% 이상 감소다.

KPI 2: 재발행 태스크 중 4블록 라벨 4개가 모두 줄 맨 앞에 있는 비율. 목표는 100%다.

검증 명령: sqlite3 /Users/ron/.hermes/data/ops_multiagent.db "SELECT id,claimed_by,status,updated_at,result_note FROM bus_commands WHERE result_note LIKE '%결과 확인 보류%' OR result_note LIKE '%missing_%' ORDER BY updated_at DESC LIMIT 20;"

기대값: 새 반려가 생겨도 result_note에 보완해야 할 라벨이 하나씩 명확히 나오고, 재발행 본문에는 결론/근거/검증/근거파일 4줄이 모두 남아야 한다.

롤백 조건: 72시간 안에 같은 에이전트가 같은 라벨로 3회 연속 반려되면 운영안 문제가 아니라 게이트 정규식·정제기·라우팅 문제로 보고 codex 조사로 넘긴다.

결론: 완료근거 누락 방지는 태스크 본문 끝에 4블록 완료 제출 조건을 고정하고, 반려 후에는 라벨별 보완만 허용하는 방식으로 운영한다. 근거: config/agent_completion_submission_standard.md, config/completion_evidence_policy.md, ops_multiagent.db 최신 반려 5건 조회 2026-09-20 14:54 KST. 검증: 파일 작성 후 존재 확인과 결론/근거/검증/근거파일 라벨 포함 여부를 검사한다. 근거파일: /Users/ron/knowledge-agent/400-reports/260920_completion_evidence_recurrence_prevention_ops.md:31 "완료 제출 조건: status=done은 아래 4줄을 모두 채운 경우에만 제출한다."