대행 표기 작업 책임경계 재정리

1. [권고]

→ 1순위: 대행 작업 제목과 본문에 원래 요청자 / 원래 대상 / 대행 사유 / 실제 수행자 / 검증 책임자 5칸을 고정한다. 근거: 최근 24시간 bus_commands 17건 중 failed 10건, 실패율 58.8%였다. 대행 표기 포함 작업은 7건 중 4건 실패, 실패율 57.1%였다. 특히 #37506은 [대행:codex] 제목이지만 target_agent와 claimed_by는 cowork였고, result_note에는 근거 섹션 미기재가 남은 채 done 처리되어 책임 경계가 흐려졌다. 기대효과: 대행 실패 4건 중 표기 혼선형 2건(#37506, #37510)을 0건으로 줄인다.

→ 2순위: 완료보고에는 수행자와 검증자를 분리해 남긴다. 실제 수행자가 자기 작업을 검증하더라도 검증 책임자=실제 수행자, 검증 방식=읽기/명령/메시지 재조회, 검증 결과값=숫자 또는 식별자를 반드시 적는다. 근거: 최근 24시간 차단 문구는 총 16회였고, missing_original_verification 3회, missing_source 3회, missing_execution_value 2회, missing_verification_value 2회, 근거 섹션 미기재 2회였다. 기대효과: missing_original_verification 3건과 missing_source 3건을 다음 24시간 기준 0건으로 낮춘다.

2. [현황]

• 기준: 2026-08-31 09:18 전후 조회, ops_multiagent.db의 bus_commands 및 버스 command-queue.
• 최근 24시간 전체 17건: done 5건(29.4%), failed 10건(58.8%), claimed 1건, cancelled 1건.
• 대행 표기 작업 7건: failed 4건(57.1%), done 1건(#37506), cancelled 1건(#37513), claimed 1건(#37514).
• 대표 실패 흐름: #37509는 비코딩 작업 오배정 운영안이 근거 부족으로 실패했고, #37510은 대행 표기 책임 경계 정리가 도구 실행 불가/확인 못함으로 실패했으며, #37512는 [대행:cowork]였지만 ron이 수행한 뒤 missing_execution_value, missing_source, missing_verification_value, missing_original_verification 4종으로 실패했다.
• 파일 기준: 이 제안서는 260831_cowork_delegation_responsibility_boundary.md에 남긴다.

3. [리스크]

• 구조적 위험: [대행:codex] 같은 제목 라벨이 실제 수행자처럼 읽히면, 코드 작업인지 정책 작업인지 판단이 뒤섞인다. 그 결과 비코딩 정책 작업이 codex로 배정되거나, 코드 패치 작업이 설계 보고로 끝날 수 있다.
• 의존관계 위험: 원래 요청자는 orchestrator, 원래 대상은 codex/cowork, 실제 수행자는 재라우팅된 agent, 검증 책임자는 수행자 또는 guardian일 수 있다. 이 4개가 한 줄에 같이 남지 않으면 실패 재시도 때 잘못된 agent에게 다시 들어간다.
• 단일 장애점: completion evidence gate는 결과 문구만 보고 차단한다. 원본 요청과 대행 사유가 result_note에 없으면, 게이트는 실제 책임경계 문제와 단순 근거 누락을 구분하지 못한다.
• 정상 차단: blocked: not in whitelist는 보안 사고가 아니라 권한 경계다. 이를 장애로 분류하면 불필요한 복구 작업이 생긴다.

4. [큐 작성 규칙]

1) 제목 규칙: [대행:원래대상] 짧은 작업명까지만 쓴다. 실제 수행자는 제목에 쓰지 않고 본문 5칸에 쓴다. 2) 본문 첫 줄 고정: 원래 요청자=..., 원래 대상=..., 대행 사유=..., 실제 수행자=..., 검증 책임자=.... 3) 대행 사유는 3개 중 하나만 쓴다: 인프라 대기, 역할 불일치, 중복 실패 회피. 4) codex 대행 작업은 파일명, 변경 대상, 검증 명령이 없으면 생성하지 않는다. 정책/분류/운영안은 cowork 또는 ron으로 둔다. 5) 실패 재시도 작업은 원본 command id와 직전 실패 사유를 본문에 남긴다. 예: 원본=#37510, 직전 실패=도구 실행 불가/확인 못함.

5. [완료보고 규칙]

완료보고는 아래 6칸 중 하나라도 빠지면 done 금지다.

1) 원본: 원본 command id와 원래 요청자. 2) 대행: 원래 대상, 실제 수행자, 대행 사유. 3) 산출물: 보고서, 메시지, 파일, 표, 패치 등 실제 결과물 이름. 4) 실행값: 조회 건수, 실패 건수, 변경량, 표본 수 중 최소 1개 숫자. 5) 검증값: 사용한 조회 경로 또는 검증 명령, 기대값과 실제값. 6) 미확인: 확인 못 한 항목이 있으면 done 대신 failed 또는 보류로 둔다.

6. [실패 방지 체크리스트]

• 제목의 [대행:...]은 원래 대상 표시인지 확인했다.
• 본문 5칸에 원래 요청자, 원래 대상, 대행 사유, 실제 수행자, 검증 책임자가 모두 있다.
• codex로 갈 작업에는 실제 파일, 변경 대상, 검증 명령이 있다.
• 정책/분석/운영안 작업은 codex가 아니라 cowork/ron으로 배정했다.
• 완료보고 6칸에 원본, 대행, 산출물, 실행값, 검증값, 미확인이 있다.
• 근거 섹션 미기재, 확인 못함, 도구 실행 불가가 있으면 done으로 닫지 않았다.
• blocked: not in whitelist는 보안 사고가 아니라 정상 권한 차단으로 적었다.

7. [검증방법]

→ 측정 지표: 다음 24시간 대행 표기 작업 실패율 57.1% → 20% 이하, missing_original_verification 3건 → 0건, 근거 섹션 미기재 2건 → 0건. → 검증 명령어: bus command-queue 최근 20건 조회, ops_multiagent.db에서 최근 24시간 status와 result_note 문구 집계, 대행 제목 포함 작업 10건 표본 확인. → 기대값: 대행 작업 본문 5칸 충족률 100%, 완료보고 6칸 충족률 100%, codex 비코딩 배정 0건. → 롤백 조건: 대행 작업 실패율이 50% 이상으로 유지되거나, 원래 대상과 실제 수행자가 충돌한 done 사례가 1건 이상 나오면 기존 completion gate 정책만 유지하고 대행 표기 규칙을 더 엄격한 코드 검증 항목으로 넘긴다.

ZK 연결

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