ron 완료보고 근거누락 반복 문제 개선안

작성: cowork(다듬), 2026-09-05 05:0x KST
근거 커맨드: #38156 (원 대상 ron, 인프라 CB 트립으로 cowork 대행)
상태: 코드 변경 없음. 제안서만.

[권고]

1순위: _handle_ron()의 암묵적 위임(delegate) 분기가 "위임 완료"를 "원본 태스크 완료"로 오제출하는 구조적 문제부터 정책 문서에 명문화한다. 근거 — scripts/agent_queue_worker.py 4717~4738행의 _COWORK_KW = {"볼트","노트","수신함","분류","승격","연결","아카이브"} 매칭 분기는 title+body에 이 키워드가 하나라도 있으면 _delegate_to_cowork()를 호출하고 그 반환값 ("[위임] 코워크 작업 큐에 등록됨\n[분석] task_id=... cmd_id=...\n[판단] 다음 세션 대기가 아니라 실제 코워크 실행 큐로 넣었습니다")을 원본 커맨드의 result_note로 그대로 제출한다. ZK/원자노트 작업은 본문에 "노트"·"연결"이 필연적으로 들어가므로 이 분기가 LLM 호출(llm_execute, 5037~5039행)에 도달하기도 전에 가로챈다. 실측 3건(모두 completion_evidence_blocked.jsonl note_preview 동일 패턴) — CMD#38144(2026-09-05 03:25:24), CMD#38146(03:41:55), CMD#38154(04:33:05), 전부 reasons=["missing_execution_value", "missing_source","missing_verification_value","missing_original_verification"] 로 동일 반려. 기대효과: 이 분기를 거친 태스크가 "완료"로 잘못 표시되는 오탐을 제거하면 위 3계열(현재 관측 빈도 recent 72건 중 3건, 4.2%) 반려가 원천 감소. 단, 근본 수정(라우팅 로직 자체가 status=delegated로 분기하도록 하는 것)은 .py 코드 변경이라 codex 위임 대상 — cowork는 이 문서로 요건만 명문화.

2순위: TOOL_USE_AGENTS용 "실행 가능 환경 가드" 프롬프트에 차단된 도구 결과를 근거로 쓰지 말라는 대체 지시를 명시한다. 근거 — CMD#38153(대행:cowork, ron이 재대행)이 04:32:28에 reasons=["차단됨", "확인 못함","확인할 수 없음"]로 반려. note_preview 확인: 크론 상태조회 명령이 (blocked: not in whitelist)로 막히자 ron이 그 차단 메시지 자체를 "확인할 수 없음"의 근거로 제출했다. 현재 agent_queue_worker.py 2664~2670행 가드 문구는 "차단이나 실패가 있으면 실행 명령과 오류를 그대로 보고하라"까지만 지시하고, config/completion_evidence_policy.md §5(Whitelist 도구 기반 검증 근거 요건)이 요구하는 "대체 도구(sqlite3/grep/read_file 등)로 재시도"를 프롬프트에 전혀 담지 않는다 — 정책 문서와 실제 주입 프롬프트가 어긋나 있다. 기대효과: 이 문구 보강만으로 동일 유형(도구 1개 차단 시 조기 포기) 재발을 7일 내 0건으로 낮출 수 있다(코드 변경 없이 프롬프트 텍스트만 patch 가능한 범위).

[현황]

completion_evidence_blocked.jsonl(11,924줄) 전수 대비, agent="ron" 반려 중 title에 "IG OAS"/"ZK" 포함 3건이 동일 note_preview 접두어 "[위임] 코워크 작업 큐에 등록됨"로 시작 — 재현율 100%(3/3), 우연이 아니라 결정론적 코드 분기 결과임을 뜻함.
harry에게 실제 전달된 "결과 확인 보류: 결과물과 검증 근거가 없음" 메시지 (bus/messages.jsonl 조회)는 정확히 2건: 2026-09-04T19:32:28Z(#38153 유래), 2026-09-04T19:33:05Z(#38154 유래) — 본 작업요청서가 지목한 "2건"과 일치.
AGENT_ROLE_PROMPTS["ron"](scripts/agent_registry.py 181~236행) 전체를 읽은 결과, "## 출력 형식" 절은 [액션]→[분석]→[판단] 3태그만 지시하고 config/agent_completion_submission_standard.md가 요구하는 4블록(결론/ 근거/검증/근거파일) 라벨은 단 한 글자도 언급되지 않는다(grep 재확인: agent_registry.py 전체에서 "결론:"/"근거:"/"검증:"/"근거파일" 0건 매치, "completion_evidence"/"submission_standard" 0건 매치). 이는 정책 문서에 이미 §v2(2026-09-03)가 cowork에 대해 지적한 "정책은 있는데 프롬프트에 안 실렸다" 문제가 ron에도 동일하게 존재한다는 뜻이다(단, ron은 대부분 결정적 Python 핸들러를 타므로 이 프롬프트 갭이 실제 반려에 기여하는 비중은 LLM fallback 경로에 한정 — 아래 [리스크] 참고).
3계열 위임-가로채기 사례는 모두 동일 요청 그룹(IG OAS 배경요인 ZK 노트, 같은 30분 창 안에 orchestrator가 반복 재생성)에서 나왔다 — orchestrator가 실패한 태스크를 제목만 살짝 바꿔 재생성하는 패턴(#38144→#38146→#38151/#38152 →#38154→#38155, 이 중 #38151/#38152/#38155는 duplicate_failed_guard로 cancelled)까지 겹쳐, 같은 근본원인이 반복 재발하며 큐를 소모하고 있었다.

[리스크]

단일 장애점: _COWORK_KW/_CODEX_KW 암묵적 위임 매칭은 _handle_ron() 최상단 근처(할일 관리 다음, run-cycle/헬스체크보다 먼저)에 위치해 ron이 받는 모든 태스크의 1차 관문이다. 볼트/노트 관련 키워드가 흔한 ron의 업무 특성상(지식사랑방 인사이트, ZK 링크 보강 등이 ron 역할 정의 자체에 포함), 이 분기는 앞으로도 계속 유사 태스크를 가로챌 구조적 위험을 안고 있다 — 1건 패치로는 재발을 못 막는다(코드 변경 필요 지점).
정책-프롬프트 불일치가 cowork에도 동형 반복 중: 지금 이 조사를 수행하는 cowork 자신의 AGENT_ROLE_PROMPTS["cowork"](agent_registry.py 258~) 역시 4블록 라벨을 요구하지 않고 [권고]/[현황]/[리스크]/[검증방법]만 요구한다. completion_evidence_policy.md §4-1/v3가 이미 지적했듯 이 4태그 형식 자체가 _completion_has_cowork_advisory_report() 완화조건과 매치해 코드 구현류 태스크에서도 증거 게이트를 건너뛸 수 있다 — 즉 cowork 프롬프트를 건드리지 않고 ron 프롬프트만 고치면 "같은 유형 문제가 아직 살아있는 에이전트가 남는다"는 반쪽 조치가 된다.
2순위(도구 차단 시 대체 지시) 보강만으로는 3계열(위임 가로채기)이 전혀 해결되지 않는다 — 서로 다른 코드 경로(결정적 라우팅 vs LLM 프롬프트)이므로 1순위 없이 2순위만 하면 harry가 보는 "결과 확인 보류" 빈도가 최대 절반(#38153류)만 줄고 #38144/#38146/#38154류(3/4, 75%)는 그대로 남는다.

[검증방법]

KPI: 이 문서 배포 이후 72시간, claimed_by='ron'이고 result_note 또는 completion_evidence_blocked.jsonl의 note_preview가 "[위임] 코워크 작업 큐에 등록됨"으로 시작하면서 그 커맨드 자신이 status=failed(needs_evidence 계열)로 떨어지는 건수.
측정 명령: sqlite3 /Users/ron/.hermes/data/ops_multiagent.db \ "SELECT id,title,status FROM bus_commands \ WHERE claimed_by='ron' AND result_note LIKE '%[위임] 코워크 작업 큐에 등록됨%' \ AND datetime(created_at) >= datetime('now') ORDER BY id;" 및 grep -c '"agent": "ron"' logs/completion_evidence_blocked.jsonl # 배포 전 기준값
기대값: 1순위(라우팅 구조 변경, codex 위임)가 실제 반영되기 전까지는 정책 문서만으로 근본 차단은 안 됨 — 과도기 완화책으로 2순위(프롬프트 문구 patch)만 먼저 적용 시, CMD#38153류(도구 차단 조기포기) 반려는 7일 내 0건이 목표. 3계열(위임 가로채기) 반려는 1순위 코드 반영 후 7일 내 0건.
롤백 조건: 2순위 프롬프트 patch 적용 후에도 동일 유형(차단 메시지를 근거로 제출)이 3회 연속 재발하면, 프롬프트 문제가 아니라 _call_llm_with_ guardrails가 실제로 이 가드 문구를 전달하지 못하는 배선 누락일 가능성 — claude-code-queue-evidence-gate 스킬 절차로 codex 재위임.

개선 전/후 result_note 비교

사례 A — CMD#38154류 (위임-가로채기, 3건 공통 패턴)

개선 전(실제 제출, 반려됨):

[위임] 코워크 작업 큐에 등록됨
[분석] task_id=t-ron-20260904193305-7d9c24 cmd_id=38155
[판단] 다음 세션 대기가 아니라 실제 코워크 실행 큐로 넣었습니다

→ 반려: missing_execution_value, missing_source, missing_verification_value, missing_original_verification (원본 태스크 "IG OAS 배경요인 ZK 노트 확장 조사"에 대해 실제로 아무 조사도 하지 않고 위임 사실만 보고했기 때문 — 위임 자체는 정당한 행동이나, 위임을 원본 완료로 제출한 것이 문제)

개선 후(제안 형식 — 코드 변경 후 목표 상태):

결론: 원본 태스크는 cowork에 위임했으며 아직 미완료 상태다. 본 제출은 위임
  행위의 완료(status=delegated)이지 원본 조사의 완료가 아니다.
근거: _delegate_to_cowork() 호출로 bus_commands.id=38155(cowork 대상) 생성,
  조회 2026-09-05 04:33 KST
검증: sqlite3 ops_multiagent.db "SELECT id,status,target_agent FROM
  bus_commands WHERE id=38155" → status=queued, target_agent=cowork
근거파일: (원본 태스크 완료 시 cowork가 별도 제출 예정 — 이 제출은 위임
  단계만 증거)
다음 행동: cowork 완료 후 원본 CMD#38154에 결과 반영 필요(status='delegated'
  유지, 'done'으로 전이 금지)

사례 B — CMD#38153 (도구 차단 후 조기 포기)