대행 검증근거 규칙 반영 범위 확정

1. [권고]

→ 1순위: 수동 큐 지시문과 완료보고 템플릿에 아래 최종 문안 5개를 즉시 반영한다. 근거: 기준 문서가 최근 24시간 bus_commands 11건, 대행 관련 8건을 확인했고 대행 실패율은 62.5%였다. 기대효과: 다음 24시간 표본에서 대행 실패율 62.5%를 20% 이하로 낮추고, missing_original_verification 3건을 0건으로 낮춘다. → 2순위: 자동 재라우팅 본문 5칸 강제와 내부 완료 게이트 문구 변경은 별도 코드 과제로 분리한다. 근거: 이번 요청의 완료 조건이 코드 작성 없음이고, 자동 재라우팅은 orchestrator와 완료 게이트 코드 경로에 걸린다. 기대효과: 정책 문서 반영과 코드 변경 범위가 섞여 생기는 재실패를 0건으로 줄인다.

2. [현황]

• 확인 문서: 260831_cowork_delegate_result_evidence_final_policy.md 66줄, 기준 제안 ops proposal e4172a79 1건.
• 기준 제안 e4172a79: 본문 2496자, 반영 가능 문구 5개와 보류 문구 4개가 분리되어 있었다.
• bus_commands 실측: #37524 done, #37525 failed, #37526 done, #37530 failed. #37530은 현재 이 범위 확정 작업이며 결과 문서가 없어 실패 상태였다.
• 기준 문서의 표본: 최근 24시간 11건 중 done 5건, failed 5건, cancelled 1건. 대행 관련 8건 중 failed 5건, done 2건, cancelled 1건으로 실패율 62.5%.
• 누락 사유: missing_source 4건, missing_original_verification 3건, missing_execution_value 2건, missing_verification_value 2건, missing_source_log_path 2건, missing_verification_command 2건.
• 코드 상태 판단: 완료 게이트 관련 함수와 양쪽 저장 경로는 이미 존재한다. 이번 작업은 운영 규칙 문안 확정이며 코드 작성 대상이 아니다.

3. 운영 규칙에 넣을 최종 문안 5개

1. 제목의 [대행:이름]은 실제 수행자가 아니라 원래 대상 표시다. 실제 수행자는 본문 첫 줄에만 쓴다.
2. 대행 큐 본문 첫 줄은 원래 요청자=..., 원래 대상=..., 대행 사유=인프라 대기/역할 불일치/중복 실패 회피, 실제 수행자=..., 검증 책임자=... 형식으로 쓴다.
3. 완료보고는 원본 command id, 실제 산출물, 실행값 숫자, 검증 명령 또는 조회 경로, 기대값과 실제값, 미확인 항목을 모두 포함한다. 하나라도 없으면 done으로 닫지 않는다.
4. 정책, 분류, 운영안 검토는 cowork 또는 ron에 둔다. codex는 실제 파일, 변경 대상, 검증 명령이 모두 있는 작업에만 배정한다.
5. blocked: not in whitelist는 정상 권한 차단이다. 보안 사고나 복구 대상으로 쓰지 않고, 필요한 경우 허용된 조회 경로로 바꿔 재검증한다.

4. 적용 대상

• 적용: 수동 큐 지시문 공통 앞줄.
• 적용: ops proposal, status, completion note 작성 템플릿.
• 적용: ron이 재처리 작업을 만들 때 넣는 원본 command id와 직전 실패 사유 문구.
• 부분 적용: 정책·리서치 작업의 검증 기준. shell 명령이 없어도 원천 파일명, 기준시각, 조회 경로, 표본 수, 실제 확인값이 있으면 검증 완료로 인정한다.

5. 비대상과 제외 이유

1. 추가 검증 없이 바로 큐 지시문에 반영 가능: 보류. #37521처럼 조회 실패나 기억 기반 판단을 검증 생략으로 오해하게 만들 수 있다.
2. 결과물과 검증 근거가 없음: 보류. 실패 상태 설명에는 쓸 수 있지만, 제안서 본문이나 완료보고 근거로 쓰면 자기반복 실패가 된다.
3. source_log_path와 verification_command를 모든 작업에 예외 없이 요구: 보류. 정책·리서치 작업은 로그 파일 대신 원천 문서, 조회 경로, 표본 수, 기준시각으로 검증해야 하므로 정상 보고가 오탐 차단될 수 있다.
4. 자동 재라우팅 본문 5칸 강제: 보류. 자동 재라우팅 문구는 코드 생성 영역이라 이번 조건인 코드 변경 없음과 충돌한다.
5. ops_todos 특정 번호 완료 처리: 이번 기준 4개 보류 문구에는 포함하지 않는다. 할 일 장부 처리는 정책 문구 확정과 별도 작업이며, 실제 대장 상태를 다시 확인한 뒤 처리해야 한다.

6. 코드 변경 필요 여부

• 이번 반영 범위: 코드 변경 불필요. 운영 규칙, 수동 큐 지시문, 제안서와 완료보고 템플릿에 문구를 넣는 문서 작업이다.
• 별도 코드 과제 필요: 자동 재라우팅 본문이 항상 5칸 책임경계를 만들도록 강제하려면 orchestrator 쪽 코드 변경이 필요하다.
• 별도 코드 과제 필요: 내부 완료 게이트의 문구나 오탐 예외를 바꾸려면 완료 게이트 코드와 서버 쪽 재검증 경로를 함께 봐야 한다.
• 이번에 하지 말 것: 코드 작성, 크론 비활성화, ops_todos 완료 처리, 기존 완료 게이트 기준 약화.

7. [리스크]

• 구조적 위험: 5칸 책임경계와 6칸 완료보고를 따로 두면 빈 칸을 채우는 척하는 보고가 생긴다. 그래서 최종 문안은 본문 첫 줄 5칸, 완료보고 6칸으로 역할을 분리한다.
• 의존관계: 수동 지시문은 즉시 반영 가능하지만 자동 재라우팅은 코드 경로에 의존한다. 문서만 바꾸면 자동 생성 작업에는 100% 적용되지 않는다.
• 단일 장애점: 완료 게이트가 정상 보고까지 차단하면 대행 작업이 failed로 쌓인다. 그래서 source_log_path와 verification_command 예외 없는 강제는 보류한다.
• 보안 오판 위험: blocked: not in whitelist를 사고로 쓰면 정상 권한 차단을 복구 대상으로 오판한다. 최종 문안에서 정상 차단으로 고정한다.

8. [검증방법]

• 측정 지표: 다음 24시간 대행 제목 포함 작업 10건 표본에서 본문 5칸 충족률 100%, 완료보고 6칸 충족률 100%, missing_original_verification 0건, codex 비코딩 배정 0건.
• 검증 명령어: sqlite3 /Users/ron/.hermes/data/ops_multiagent.db "SELECT id,title,status,result_note FROM bus_commands WHERE created_at >= datetime('now','-1 day','localtime') ORDER BY id DESC;"
• 검증 명령어: curl -s -H "X-Ops-Token: $(cat ~/.hermes/.bus-token)" "http://127.0.0.1:3344/api/bus/command-queue?limit=30"
• 성공 기준: 대행 실패율 20% 이하, 자기반복 보류 0건, 원래 대상과 실제 수행자 충돌 done 0건.
• 롤백 조건: 대행 실패율이 50% 이상 유지되거나, 원래 대상과 실제 수행자가 충돌한 done 사례가 1건 이상 나오면 정책 문구만으로는 부족하다고 보고 codex 코드 과제로 승격한다.

9. 완료 근거

• 원본 확인: ops proposal e4172a79, 260831_cowork_delegate_result_evidence_final_policy.md.
• DB 확인: bus_commands #37524, #37525, #37526, #37530 상태와 본문 길이 확인.
• 범위 확정: 적용 대상, 비대상, 제외 이유, 코드 변경 필요 여부, 검증 기준을 한 문서로 정리했다.

ZK 연결

• [[MOC-Hermes-비코딩-오배정방지-260831]] — 비코딩 오배정 방지 지식망 허브
• [[260831_대행라벨은_원래대상_표시다]] — 대행 라벨 책임경계
• [[260831_비코딩_오배정_후속검증_기준]] — 완료 검증 기준