multi-agent-mux/.agents/reports/reviewer-opencode-01/report-58fba2b1.md

[reviewer-opencode-01] Issue #6 통합 보고서 검토 의견

• Job: 58fba2b1 / 검토자: reviewer-opencode-01 (원 1차 리뷰 Job 17f2e688의 작성자)
• 검토 대상: .agents/reports/issue_6_consolidated_review_report.md (오케스트레이터 작성, 4인 리뷰 종합)
• 검토 방법: 통합 보고서의 모든 핵심 주장을 라이브 소스·실측으로 독립 재검증 — direct 경로(:200-232), 레지스트리 CLI/엔진 CAS 코드, Herdr 0.8.2 CLI 실도움, 좀비 잡 포렌식, mock_herdr 커버리지. 내 1차 리뷰(17f2e688)의 권고 대비 증감도 대조했다.

---

1. 총평 및 통합 보고서 정합성 평가

정합성 높음 — 종합적으로 충실하고 정확한 통합이다. 핵심 판정(①② 모두 실재, 상호 증폭, 국소 패치로 해결 가능)은 나를 포함한 4인 리뷰의 실측과 일치하며, 통합 과정에서 왜곡·축소는 발견되지 않았다. 오히려 내 1차 리뷰를 초월하는 두 가지 실질 기여가 있다:

1. --type direct 숨은 결함 발견 (§2.1-2): 나는 loop/discuss 경로(:351-361, :375-378)만 추적했으나, 오케스트레이터가 실제로 타는 경로는 runner.py:269의 --type direct이고 이 경로(:213 run_agent 무가드, :227 wait "$sub_pid" || true, 상태 전이 부재, exit 0)가 완전 침묵이라는 발견 — 직접 확인했다. 이것이 통합 보고서의 가장 큰 기여다.
2. CAS 선행조건 (expected_status in (pending, running)): 내 1차 리뷰가 "이미 terminal이면 덮어쓰지 않는 가드"를 논점으로만 언급한 반면, 통합 보고서는 이를 구체적 메커니즘(엔진의 기존 CAS 계약 재사용 + CLI 노출)으로 발전시켰다. 실측: engine.py:188에 expected_status 선행조건이 이미 존재하나 registry.py status 서브커맨드(:292-295)는 --job/--set만 받고 이를 노출하지 않는다 — 보고서의 §4.1-1이 정확히 이 누락 배선을 메우는 제안임을 확인.

실증 포렌식 검증 (강력한 1차 증거): 보고서 §2.1-3이 인용한 좀비 잡 3건을 내가 직접 재확인: 93a44347와 2961b822는 지금 이 순간에도 status: "pending"으로 방치되어 있고, ee242671(바로 내가 이전에 "인터럽트된 라운드"로 진단했던 내 잡)은 running에 started 이벤트 하나만 남은 채 표류 중 — 즉 그때의 중단은 인터럽트가 아니라 direct 경로가 내 subscriber 실패를 침묵시킨 것이었을 개연성이 높다. 결함 ①의 라이브 피해 사례로서 이보다 좋은 증거는 없다.

2. 누락되거나 보강이 필요한 핵심 사항 (Missing)

1. run_agent 반환값 접수의 명문화 필요 (내 1차 리뷰 4-3의 핵심이 통합 보고서에 암묵적): finalize_unfinished는 "구독자 rc≠0 + 비터미널 디스크"에서 발동하므로 주입 실패를 간접적으로만(주입 실패 → started 미발행 → 구독자 idle timeout → rc=2 → finalize) 포착한다. 이는 동작하나 (a) 주입 실패를 잡는 데 최대 120초(구독자 idle timeout)가 걸리고, (b) run_agent가 이미 rc=1로 실패 사실을 즉시 알고 있는데 이를 버리는 구조는 그대로다. 권고: run_agent 실패 시 즉시 finalize 호출을 명시적으로 설계에 포함하라 — 실패 전파가 120초 → 수 초로 단축되고, "주입은 실패했으나 에이전트가 늦게 started를 발행하는" 엣지에서 두 경로의 경합을 없앤다.
2. herdr agent wait 실패 모드 표준화: wait가 타임아웃/대상 부재로 실패할 때의 rc와 출력 계약(성공과 실패를 구별할 수 있는가)이 §4.2에 명시되지 않았다. 폴백 휴리스틱 진입 조건이 이 rc에 의존하므로, Phase 0 스파이크에 "wait 실패 rc 실측" 항목을 추가해야 한다.
3. MAM_SKS_* 환경변수 문서화: 기존 SKS_QUIESCENT_TRIES/INTERVAL과 신규 네이티브 타임아웃(15000/5000ms)의 튜닝 변수군을 .mam.env.example에 문서화하는 항목이 §5에 빠져 있다(과거 v4.1.x 패치의 표준 절차).

3. 불필요하거나 과도한 제약/설계 (Unnecessary)

과도한 설계는 없다. 명시적으로 검토한 결과:

• --expect-status 신설이 아닌 기존 CAS 엔진(:188)의 CLI 노출 — 새 메커니즘이 아니라 배선. 최소 비용 최대 효과.
• agent wait --until idle --until done의 done 포함: 에이전트가 턴이 아니라 대화 자체를 종료하는 상태를 놓치지 않는 정당한 포함.
• 0.7.x 화면 휴리스틱 폴백 유지: 제거가 아닌 2차 계층 유지 — 호환성 보험이며 비용이 낮다.
• 유일한 사소한 지적: §4.2-2의 "잔여 busy 토큰 사전 캡처 대조" 가드는 폴백 경로에서만 필요하다. 1차 게이트(wait --until idle)를 통과한 뒤에는 상태가 이미 idle이므로 네이티브 경로에서 이 가드는 중복 — 구현 시 폴백 경로에 한정해 배치하는 것이 코드를 줄인다 (동작에는 무해하므로 차단 사항 아님).

4. 간과된 잠재적 위험 및 엣지 케이스 (Overlooked)

1. agent prompt --wait --until working의 턴 비추적성: 실측한 herdr 도움말에 "It does not track turns: if the agent is already working, that active turn's completion may match" — 즉 working 상태에서 제출하면 이전 턴의 완료가 새 입력의 수락 증거로 오판될 수 있다. 통합 보고서의 1차→2차 순서(wait로 idle 확보 후 prompt)가 이를 구조적으로 방지하지만, 이 보장이 순서에 의존한다는 사실이 문서에 명시되지 않았다. "prompt는 반드시 wait 성공 후에만 호출"을 계약 조건으로 못박아야 한다.
2. wait 무한 대기 함정: agent wait는 --timeout 없으면 무한 대기한다(실측). §4.2-1이 15000ms를 명시한 것은 정확하나, 타임아웃 누락 시 새로운 교착 유형이 생긴다 — 구현 가드(타임아웃 인자 강제)와 테스트(--timeout 없는 호출 금지 lint성 단언)가 필요.
3. 구독자 rc=3(broker_unavailable)과 finalize의 상호작용: loop 경로의 기존 디스크 우선 병합(:342-347)이 finalize와 만날 때, 브로커 장애 중 도착한 늦은 completed 이벤트와의 경합이 새 패치로 어떻게 정렬되는지 테스트 매트릭스에 명시적 시나리오가 필요하다 (§5-1의 CAS 보존 테스트가 이를 커버하나 rc=3 변형 포함 권고).
4. 좀비 잡 청소: 93a44347/2961b822는 패치 후에도 pending으로 남는다 — 패치는 신규 실패만 막는다. 구현 잡에 과거 좀비 잡 수동 정리(status --set error 또는 삭제)를 부수 절차로 포함할 것.

5. 구현 착수를 위한 최종 제안 및 권고사항

1. 착수 승인: 공수 산정(2.0~3.5 인일)은 터치포인트 실측(3개 finalize 호출부 + CLI 인자 ~15줄 + 러너 파싱 ~10줄 + 핸드셰이크 게이트 ~60줄 + mock ~50줄 + 테스트 2파일)과 정합 — 타당하다.
2. 구현 순서 권고: (1) registry.py CLI --expect-status 노출(독립 테스트 가능, 무위험) → (2) finalize_unfinished direct+loop 적용 → (3) 러너 rc-관용 파싱 → (4) 네이티브 핸드셰이크 + 폴백 → (5) mock/회귀 테스트. 각 단계 후 750 전체 스위트 유지 확인.
3. 테스트 보강: §5의 2개 신규 파일에 위 §4의 엣지 3건(wait 실패 rc, 턴 비추적성 방지 계약, rc=3 경합)과 내 1차 리뷰 §5-1(주입 실패 → 즉시 error 전이 연쇄)을 시나리오로 추가.
4. 문서 동기화: MESSAGING.md(§5.1 wapper 종료 계약 갱신)와 .mam.env.example(타임아웃 변수군)을 패치 커밋에 포함 — v4.4.0 문서 원장 체계의 표준 절차.

6. 최종 판정

통합 보고서는 4인 리뷰를 왜곡 없이 종합했고, direct 경로 발견과 CAS 선행조건 설계로 원 리뷰들(내 것 포함)을 실질적으로 초월했다. 포렌식 증거(좀비 잡)는 라이브 레지스트리에서 재검증되었으며, 해결안은 기존 CAS 엔진과 Herdr 0.8.2 네이티브 API의 정확한 재사용으로 과설계 없이 최소 비용이다. 내가 보강한 4개 항목(run_agent 즉시 finalize, wait 실패 rc 계약, 턴 비추적성 순서 계약 명문화, 좀비 청소)은 모든 것이 구현 착수 전/중 반영 가능한 권고 사항이지 통합 보고서의 결함이 아니다. 구현 착수 준비 완료 판정에 동의한다.

[VERDICT: PASS]