[권고]

1순위: 태스크 본문(body) 생성 단계에 "지목한 파일:줄번호가 실제로 그 코드를 담고 있는지" 사전 grep 검증을 넣어라 — 이번 CMD#39759는 scripts/server.py 644행에 path = WORKSPACE_ROOT.parent / path가 있다고 명시했지만, 실측 결과 해당 줄(644행)은 key = str(path)이고 WORKSPACE_ROOT.parent라는 문자열은 scripts/server.py 전체에 0건이다(grep -n "WORKSPACE_ROOT.parent" scripts/server.py → 무매치). codex 반려는 게이트 버그가 아니라 애초에 고칠 대상이 존재하지 않는 태스크였다. 기대효과: 오진단 기반 태스크가 codex 큐에 재진입하는 것 자체를 원천 차단(이번 케이스처럼 1회 실패로 끝나면 낭비는 1턴이지만, 재시도 루프에 걸리면 무한 반복 가능).

2순위: _reported_workspace_paths()(agent_queue_worker.py 5899~5906행)의 "logs/ 접두 경로는 WORKSPACE.parent 기준"이라는 특수분기는 2026-08-29 CMD#37129 재조사로 의도적으로 추가된 정상 로직(주석 명시)이다. 반면 _completion_storage_artifact_paths()(server.py 631~648행)는 이런 특수분기 자체가 없고 모든 상대경로를 무조건 WORKSPACE_ROOT / path로 해석한다(643행, 실측 확인). 즉 두 함수는 "logs 상대경로 처리 방식이 다른 것"이지 server.py 쪽이 "오판정 버그"인 게 아니다. 향후 유사 조사 태스크를 발행할 때는 agent_queue_worker.py와 server.py 두 파일에 중복 존재하는 유사 함수명 (_completion_storage_required_result_gaps vs _completion_required_result_evidence_gaps)을 혼동하지 않도록 태스크 본문에 "어느 파일의 어느 함수인지" 두 좌표를 모두 grep으로 재확인한 뒤 기재하라.

[현황]

• 반려 이력: CMD#39759, bus_commands.status=failed, claimed_by=codex. sqlite3 -readonly ops_multiagent.db "SELECT result_note FROM bus_commands WHERE id=39759" 원문: 사유=코덱스 완료 증거 부족: source_log_path_not_found: scripts/server.py:<줄번호>, missing_verification_result.
• codex가 실제로 제출한 raw_result(logs/codex_result_rejected.jsonl 109행, raw_result_len=1683 bytes)는 태스크 본문의 "실행:" 문구를 사실상 그대로 복붙했다 — "644행의 path = WORKSPACE_ROOT.parent / path 코드를 ... 변경하여"라고만 서술했을 뿐, 실제로 파일을 열어 644행이 그 코드가 맞는지 확인한 흔적이 없다(진짜 644행 원문을 인용하지 않음). codex는 파일을 고치지도, 644행 내용을 검증하지도 않은 채 "고쳤다"는 완료형 문장만 작성했다.
• 근거파일 필드 훼손: raw_result 말미의 "근거파일: scripts/server.py:<줄번호>" 는 오케스트레이터가 자동 삽입한 플레이스홀더(<줄번호>) 토큰을 codex가 그대로 남겨뒀다 — 이 자체가 _extract_source_log_path()(agent_queue_worker.py 619~631행) 정규식에 "scripts/server.py:<줄번호>"라는 문자열 그대로 매칭돼 source_log_path_not_found를 유발한 2차 원인이다. 즉 이번 반려는 (i) 태스크 전제 자체가 허위였던 1차 원인과 (ii) codex가 플레이스홀더를 실값으로 치환하지 않은 2차 원인이 중첩됐다.
• AGENT_ROLE_PROMPTS(agent_registry.py 244~271행, codex 항목) 자체는 4블록 라벨(결론:/근거:/검증:/근거파일:)과 실존 경로+줄번호+원문 인용 요구를 명확히 담고 있다 — 프롬프트 배선 결함(원인 a)은 발견되지 않았다. 게이트 로직(_completion_required_result_evidence_gaps, agent_queue_worker.py 6004~6089행)도 실존 경로 검사·플레이스홀더 검사를 설계대로 정확히 수행했다 — 게이트 결함(원인 c)도 아니다.

[리스크]

• 구조적 위험: 태스크 본문이 사실과 다른 코드 위치를 지목한 채 발행되면, codex가 "성실하게 grep해서 확인"하지 않는 한 매번 허구 진단을 그대로 echo하는 실패가 반복된다. 이번은 1회로 끝났지만, 오케스트레이터의 AGENT_INFRA_CB_FALLBACK 재라우팅 로직이 걸리면 같은 허위 전제 태스크가 다른 에이전트(cowork 등)로 넘어가 동일 반려를 반복할 단일 장애점이 된다 (AGENTS.md 2026-09-22 기록된 CMD#39748/#39749 유사 패턴과 구조가 같다 — "재라우팅 전에 원래 태스크 전제 자체를 검증하지 않음").
• 의존관계: 이 오진단의 출처는 이전 조사(아마 ron/orchestrator가 agent_queue_worker.py의 _reported_workspace_paths() 특수분기를 발견하고, 이를 server.py의 이름이 비슷한 함수(_completion_storage_artifact_paths)로 잘못 전이시켜 태스크 본문을 생성한 것으로 추정)를 추적할 로그가 남아있지 않다 — bus/messages.jsonl에는 CMD#39759 발행 시점의 body만 있고 그 이전 "무엇을 보고 이렇게 결론냈는지"의 근거 체인이 없다. 이런 태스크 생성 이력 미보존이 반복되면 같은 오진단 재발 원인 추적이 매번 이번처럼 수작업 grep에 의존하게 된다.

[검증방법]

• KPI: scripts/server.py에 WORKSPACE_ROOT.parent라는 코드가 존재하지 않으므로(재확인 명령: grep -n "WORKSPACE_ROOT.parent" scripts/server.py → 무매치, 실측 완료) CMD#39759는 "수정 불필요/전제 오류"로 종결하고 codex 재시도를 걸지 않는 것이 맞는 최종 상태다.
• 검증 명령: grep -n "WORKSPACE_ROOT.parent" scripts/server.py → 기대값: 매치 0건(이미 확인됨, py_compile 대상 코드 변경 없음 — 변경할 버그가 없으므로 diff/py_compile 자체가 성립하지 않음).
• 롤백 조건: 만약 향후 재조사에서 scripts/server.py에 실제로 WORKSPACE_ROOT.parent 특수분기가 발견되면(예: 다른 브랜치/커밋에서 추가된 경우) 본 제안서의 "전제 오류" 결론을 철회하고 codex에 실제 수정 태스크를 재발행한다 — 판단 기준은 grep -n 재실행 결과 매치 유무 단 하나다.

결론: bus_commands id=39759 원문을 조회하고 completion_evidence_policy.md/ agent_completion_submission_standard.md와 대조해, 반려 원인이 (b) 태스크 본문 자체의 오진단(존재하지 않는 코드 위치 지목)임을 확인해 본 제안서에 반영했다. 근거: sqlite3 -readonly /Users/ron/.hermes/data/ops_multiagent.db "SELECT result_note FROM bus_commands WHERE id=39759"(2026-09-22 23:15 KST 조회) 원문 "사유=코덱스 완료 증거 부족: source_log_path_not_found: scripts/server.py:<줄번호>, missing_verification_result"; 대조한 config/completion_evidence_policy.md 90~99행("5. missing_source_log_path / missing_verification_command — 필드는 썼지만 그 경로가 실존하지 않음 (안 쓰는 것보다 나쁨, R29)")과 config/agent_completion_submission_standard.md TL;DR 3번("근거파일:에 적은 경로를 지금 search_files/find로 직접 확인했는가")이 이번 사례(플레이스홀더 <줄번호> 리터럴 잔존)와 정확히 일치함을 확인했다. 검증: grep -n "WORKSPACE_ROOT.parent" /Users/ron/.hermes/workspace/scripts/server.py → 매치 0건(실측, 2026-09-22 23:15 KST); awk 'NR==644{print}' scripts/server.py → key = str(path)(태스크 본문이 주장한 path = WORKSPACE_ROOT.parent / path와 불일치 확인); ls -la /Users/ron/knowledge-agent/400-reports/260922_cowork_CMD39759_codex_rejection_root_cause.md → exit code 0 (파일 생성 확인). 근거파일: /Users/ron/knowledge-agent/400-reports/260922_cowork_CMD39759_codex_rejection_root_cause.md (본 문서, "[현황]" 절 "codex가 실제로 제출한 raw_result... 실제로 파일을 열어 644행이 그 코드가 맞는지 확인한 흔적이 없다" 문장 인용)