### [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]