fix(issue-6): fail-closed registry timeout and TUI turn handshake

- Introduce finalize_unfinished in multi-agent-mux-delegate-job for fail-closed atomic transitions
- Enforce CAS dispatch_token and attempt_id pinning across engine, CLI, and lifecycle scripts
- Integrate Herdr wait_for_agent_idle turn handshake to prevent prompt loss and race conditions
- Resolve bash 3.2 set -u empty array expansion compatibility in lib.sh
- Preserve Issue #5 R2 contract in CAS transition engine (engine.py, publish_event.py, service.py)
- Add comprehensive regression suites (test_issue6_fail_closed.py, test_issue6_turn_handshake.py)
- Bump lockstep framework and skills to v4.4.1 across lib.sh, eager.py, VERSIONS.md, 8 SKILL.md
- Synchronize documentation (IMPROVEMENTS.md, MESSAGING.md, state-transitions.md, task.md, phase5-e2e.md)
- Unanimous PASS achieved across 4 reviewer team leaders (Claude, Codex, OpenCode, Grok)

Closes #6
This commit is contained in:
Godopu committed 2026-09-09 14:02:47 +09:00
1 parent 7b761be7b8
commit ec61511699
51 files changed
+3477 -293

No files matched your search

@@ -0,0 +1,41 @@
### [reviewer-opencode-01] Issue #6 구현 결과물 6차 최종 재검토 의견
- **Job**: `24e28c12` / **검토자**: `reviewer-opencode-01` (4차 `8b455e21`, 5차 `d264ee71`(중단)에 이은 6차)
- **검토 방법**: 라운드-6의 모든 클레임을 라이브 소스에서 라인 단위 검증 + 신규 테스트(T1-21, T2-14) 직접 실행 + **브리프 지정 7개 스위트를 환경 변수를 달리한 3가지 조건(앰비언트/핀-데드/파일 단독)에서 각각 실행**해 재현성을 실측.
---
## 1. 라운드-6 클레임 검증 결과
| 클레임 | 검증 | 판정 |
|---|---|---|
| P1-A: `$pub` 명령에 `--expect-dispatch-token`/`--attempt-id` 고정 바인딩 | wrapper direct(:168-178)·loop(:373-426) 모두 바인딩 확인. **1차 증거: 이번 리뷰를 위해 내가 받은 지시문 자체가 토큰을携带** — 내 `started`/`completed` 발행 명령에 `--expect-dispatch-token f61719bd...`가 실려 있다. publish_event는 와이어 전 rc=4 선차단(:284-290) + sync 측도 토큰 가드. `prepare_event` 디스크 토큰 자동 채택 제거(:145-150, CLI 인자만) 확인 | ✅ |
| T1-21 (지연된 attempt-1 completed가 attempt-2 레코드 오염 차단) | 직접 실행 **PASS** — stale 토큰 발행이 rc=4로 차단됨 | ✅ |
| P1-B: 빈 RPC 출력 폴백 제거 (`lib.sh:2416`) | `|| [ -z "$p_out" ]` 제거 확인(라운드-4에서 넣었다가 정확히 되돌린 조치 — 단일 주입 계약 강화가 옳음). b19 목 herdr가 명시적 `unknown command: agent prompt` 반환하도록 수정 확인 | ✅ |
| T2-14 (빈 RPC 오류 시 paste 0회 + rc=4) | 직접 실행 **PASS** | ✅ |
| P2: SKILL.md rc=1/rc=5 표 충돌 제거, VERSIONS.md:16 정렬 | SKILL.md 단일표(0/1/2/3/5)에 preflight=rc=5로 단일화; VERSIONS.md:16이 래퍼 CLI 코드로 정렬되고 rc=4는 "send_keys_safe 헬퍼 수준, 래퍼에서 rc=1로 수용"으로 명시 — **내가 5차에서 지적한 계층 모호성이 정확히 해소됨** | ✅ |
| test_x03 갱신 (attempt_id 규약) | 65/65 통과 (내 실행); 단정문이 `attempt_id == 1`로 갱신 확인 | ✅ |
## 2. 발견된 잔여 결함 (차단): fail_closed 스위트의 비밀봉(non-hermetic)성
브리프의 핵심 수용 기준인 "지정 스위트 100% 통과"가 **현재 환경에서 달성 불가**함을 3가지 조건에서 실측했다:
1. **앰비언트 환경 (7스위트)**: `test_t1_20` **결정적 실패** (2회 재실행 모두 동일; 파일 단독 실행에서도 실패). 202+1 fail.
2. **브로커 핀-데드 환경** (`MQTT_HOST=127.0.0.1 MQTT_PORT=65534`, 형제 테스트 T1-4/T1-5가 쓰는 패턴): t1_20은 **통과**하지만 **t1_1, t1_2, t1_15, t1_16이 실패로 뒤집힘** (202+4 fail).
3. **원인 규명 (1차 증거)**: 현재 공개 브로커 `broker.hivemq.com`이 **half-open 상태** (TCP는 열리나 CONNACK 무응답 — 내 이벤트 발행 시도의 "no CONNACK from broker" 경고로 실증). 이로 인해:
- t1_20: 구독자가 5초 핸드셰이크 창 내에 rc=2로 사망 → **주입 이전** 조기사망 경로 진입 → R1 유예가 (아직 주입 안 된) idle 에이전트를 보고 정상 스킵 → rc=2 조기 종료. 유예-계속 메시지 없음.
- t1_1/2/15/16: 이 테스트들은 구독자가 라이브 브로커에 CONNACK+SUBSCRIBE 후 idle-timeout(rc=2)으로 죽는 흐름을 전제로 작성됨 → 핀-데드에서는 rc=3(broker_unavailable) 경로로 바뀌어 단정 실패.
- 즉 **T1-14/15/16/20(라운드-5 B1' 신규)은 실제 구독자를 띄우며 공개 브로커의 가용성·응답성을 암묵 전제**한다. 브로커가 완전히 살아있던 오늘 낮(내 4차 40/40 통과 시점)에는 전부 통과했으나, 브로커가 half-open이 된 지금 t1_20이 뒤집혔다. 스위트는 환경의 인질이다.
4. **부수 관찰 (코드 결함 아님)**: 주입 전 조기사망 경로에서 R1 유예를 스킵하는 것은 **정당한 설계**(주입 안 된 에이전트를 기다릴 대상 없음)다. 결함은 어디까지나 테스트의 격리성에 있다.
## 3. 수정 방향 (구체적)
선택지 2가지 (어느 쪽이든 기계적):
1. **권장 — 세션 스코프 로컬 MQTT 브로커 fixture**: `nats-docker`(이미 O-5로 계획된 사설 MQTT 브로커, 포트 1883) 또는 경량 Python 브로커를 conftest autouse fixture로 기동해 전 fail_closed/turn_handshake 실구독자 테스트가 **결정적 로컬 브로커**를 바라보게 한다. 이는 B-15/O-5 궤도와도 정합.
2. **최소 — 각 테스트의 브로커 기대치 명시+일관화**: t1_1/2/15/20 등이 전부 동일한 (핀-데드 또는 로컬-라이브) 조건을 명시하도록 env를 통일. 단, 핀-데드에서 t1_1류가 기대하는 rc=2 흐름은 broker_unavailable(rc=3) 경로로 바뀌므로 **단정문 재작성**이 필요함 — 로컬 라이브 브로커(선택지 1)가 구독자 타임아웃 흐름을 그대로 보존하므로 파괴가 적다.
## 4. 최종 판정
라운드-6의 코드·문서 클레임(P1-A 토큰 바인딩, P1-B 빈출력 폴백 제거, P2 문서 정렬, test_x03 갱신)은 전부 정확하고, T1-21/T2-14 가드도 실효성 있게 통과했다 — 심지어 이번 검토의 지시문 자체가 P1-A의 실전 적용 사례가 되었다. 그러나 **브리프의 명시적 수용 기준인 "지정 테스트 스위트 100% 통과"가 현재 환경에서 물리적으로 불가능**하다: t1_20은 앰비언트에서 결정적 실패, 핀-데드로 돌리면 4개 형제 테스트가 대신 실패한다. 이는 라운드-5 B1'에서 도입된 실구독자 테스트들이 공개 브로커의 상태에 비밀봉으로 결부되어 있다는 테스트 인프라 결함이며, "재현 불가한 타임아웃"이 아니라 3조건 실측으로 원인까지 특정된 **결정적·환경의존적** 실패다. 본 세션의 일관 기준(검증 가능한 '100% 통과' 주장)상 PASS를 줄 수 없다. 수정은 선택지 1(로컬 브로커 fixture)로 일괄 해결 가능하며 코드 본체는 무수정이다.
[VERDICT: NOT PASS]
@@ -0,0 +1,58 @@
### [reviewer-opencode-01] Issue #6 구현 결과물 최종 교차 검토 의견
- **Job**: `512cfec7` / **검토자**: `reviewer-opencode-01` (1차 정밀 리뷰 `17f2e688` 및 통합 보고서 검토 `58fba2b1`의 작성자)
- **검토 대상**: 기준 커밋 `7b761be` 대비 작업 트리 전체 (미커밋, HEAD=7b761be) — Issue #6 Phase 1~5 구현 + v4.4.1 4-way 락스텝
- **검토 방법**: 브리프의 모든 체크포인트를 라이브 소스에서 직접 확인 (wrapper 전 경로, engine CAS 테이블, registry CLI, watcher/runner, lib.sh), 신규 27 테스트 및 전체 스위트를 직접 실행, 라이브 레지스트리·이벤트 로그 대조.
---
## 1. 총평 및 구현 일치도 평가
**일치도: 탁월.** Rev.2 설계(`docs/contracts/issue-6/implementation_plan.md`)와 4인 리뷰(나 포함)의 권고가 충실하게 구현되었을 뿐 아니라, 내 두 차례 리뷰(`17f2e688` §4, `58fba2b1` §2·§4)에서 제시한 보완 4개 항목이 **전부 반영**되었다:
| 내 권고 | 구현 확인 |
|---|---|
| `run_agent` 반환값 접수 (17f2e688 4-3) | `inject_agent` 실패 → `finalize_unfinished error + exit 1` (wrapper :243-247) |
| 즉시 finalize로 실패 전파 단축 (58fba2b1 §2-1) | preflight/idle_wait/inject 실패 시 각 즉시 종결 (:178, :190, :245, :331, :345, :413) — subscriber 120초를 기다리지 않음 |
| 러너 rc-관용 파싱 (58fba2b1 §5-2) | `runner.py delegate_job`이 rc≠0에서도 `registered job:`을 먼저 파싱해 job_id 반환 → `wait_for_job`이 디스크 error를 1초 폴 내 조기 포착; rc=5(session_busy)는 `MAM_SESSION_BUSY_RETRY_S`(30s) 후 1회 재시도 |
| 좀비 잡 수동 정리 (58fba2b1 §4-4) | 실측: `93a44347`/`2961b822`/`ee242671` 3건 모두 **지금 `status: error`**로 정리 완료 |
설계 문서 대비 누락·변형 없음. task.md 체크리스트 35/35 체크, phase5-e2e.md는 4백엔드 실측(claude/grok/codex/opencode 전원 `completed`, 주입 실패·중복 0건)을 기록.
## 2. 핵심 결함 해결 정합성 검증
### 결함 ① (Fail-Closed & CAS) — **완결 확인 (라인 단위 실측)**
- **`close --request {deadline_timeout,cancelled}` CAS 완결**: engine의 `REQUEST_TO_STATUS`에 `deadline_timeout→error`/`cancelled→cancelled` 등록; 터미널 상태에서는 `"conflicting error after terminal X; refusing"` 미커밋 거부(engine :259-262) — **터미널 보호가 호출자 규율이 아니라 CAS 경계 자체에서 시행**된다. CLI `close`는 `--expect-dispatch-token` CAS 토큰까지 지원.
- **`finalize_unfinished` 전 경로 적용**: direct(:269) + loop/discuss의 preflight(:331)/idle_wait(:345)/subscriber-조기사망(:390)/inject(:413)/worker(:436)/reviewer(:459) — 이슈가 지목한 두 break 경로는 물론, 발견되지 않았던 direct 경로와 신규 3개 조기 실패 경로까지 8개소. `MAM_DELEGATE_FAIL_CLOSED=0` 롤백 스위치 보유.
- **B-15 rc=3 broker 장애**: `finalize_unfinished`의 broker_unavailable 분기가 **남은 데드라인 동안 3초 간격 디스크 재관측** 후 completed를 보존(:585-600) — 워커 실패 단정 없이 정확히 B-15 계약대로.
- **`attempt_id` ABA 차단**: loop 경로가 매 dispatch마다 attempt 증가(:321) 후 `update --attempt-id`(:358); `--status pending`은 `STATUS_TO_REQUEST`에서 `redispatch`로 매핑되고, engine이 `attempt_id` 미증가 시 `conflicting... refusing`(redispatch attempt_id guard, :231-236) — worker→reviewer 전환에서의 이전 상태 부활(ABA)이 CAS 경계에서 차단된다. job_subscriber/publish_event도 `attempt_id`(fallback `iteration`)를 일관 전파하도록 수정.
### 결함 ② (사전 TUI 유휴 핸드셰이크) — **정합성 확인**
- **순서 교정**: `wait_for_agent_idle`(:187)이 **subscriber 기동(:203) 이전**에 실행 — 120초 구독자 예산의 자가포식 제거. 실패 시 rc 1/2 → 즉시 finalize(cancelled/session_busy) + exit 5, rc 3(unknown)은 계속 진행하되 폴백 busy-token 게이트로 이어짐(lib.sh:2420) — 네이티브 관측 불가 환경의 소프트 폴백.
- **소켓 격리**: `watcher.py`가 `--session` 인자를 받아 `herdr --session <name> agent wait` 형태로 명시 전달(:66-69, CLI :183-190); lib.sh 호출부도 `--session "${HERDR_SESSION_NAME:-default}"`(lib.sh:2271) — 격리 계약 유지.
- **중복 주입 원천 차단**: 네이티브 경로는 `agent prompt --wait --until working --timeout 5000` **1회**; stalled/timeout 시 **재제출 금지** → `agent get`으로 2초 후 상태 재확인 → `working`이면 수용(rc 0), 아니면 `delivery unknown`(rc 4)로 실패 확정. 유일한 재시도는 `agent_not_found` 뿐이며 이는 입력이 전달되지 않은 상태(대상 부재)이므로 이중 주입 아님 — herdr 계약상 거부는 입력 전송 이전에 확정됨. blocked는 `agent_blocked` 감지 시 rc 2 즉시 거부.
- **1차→2차 순서 계약 준수**(58fba2b1 §4-1): wait(idle 확보) 후 prompt — prompt가 wait 성공 뒤에만 호출되는 구조로 이전 턴 오판 방지.
## 3. 엣지 케이스 및 사이드 이펙트 검토
1. **idle_rc=3(unknown) 진행 경로**: 네이티브 관측 불가 백엔드에서 `SKS_BUSY_TIMEOUT` 폴백 busy-token 게이트가 대기(:2420) — 하지만 이 게이트가 "이전 턴 잔여 busy 토큰"을 새 입력 근거로 쓰는 오판 위험은 통합 보고서 2차 게이트 가드(사전 캡처 대조)로 방지. 설계 요구와 정합.
2. **`update --status pending`의 `redispatch` 매핑**: `STATUS_TO_REQUEST` 매핑으로 무엇보다 `finalize/error` operator 권한 검사(:227-228)가 먼저 시행되므로 비인가 소스의 terminal→pending 되돌리기가 불가. 다만 `attempt_id` 없이 `iteration`만 있는 구형 레코드는 `record["attempt_id"]=iteration`로 보간되어 가드가 유효 — 하위호환 처리 확인.
3. **rc=5 재시도 창**: `MAM_SESSION_BUSY_RETRY_S` 동안 orchestrator가 블로킹되지만(기본 30s), 이는 교착이 아니라 **의도된 유한 대기**이며 재시도 1회로 상한. 무한 재시도 금지 원칙(17f2e688 4-2) 준수.
4. **`wait_for_agent_idle`의 done/blocked 포함**: done 포함 정답(58fba2b1 §3), blocked는 rc 2로 즉시 거부해 session_busy로 종결 — "blocked 방치 대기" 부재.
5. **direct 경로의 MQTT error 발행**: loop에서는 O-1 위반 방지를 위해 error 발행 금지, direct에서만 발행(:615-623) — 이벤트/디스크 이중 갱신의 무결성 유지.
## 4. 테스트 결과 및 릴리스 적합성 평가
- **신규 테스트**: `test_issue6_fail_closed.py`(16) + `test_issue6_turn_handshake.py`(11) = 27개, 내 실행 기준 **27/27 PASS (72.76s)**.
- **전체 회귀**: 내 직접 실행 **777 passed / 0 failed** (1,053s) — 기존 750 + 신규 27, 회귀 없음.
- **4-way 락스텝 v4.4.1**: `lib.sh:32 MAM_VERSION="4.4.1"`, `VERSIONS.md` 헤더/prose/8행 매트릭스/v4.4.1 체인지로그, 8× SKILL.md frontmatter, **README 양 언어 배지까지** — 4번째 leg(배지, 과거 065892e5/71a1b000에서 내가 지적한 소프트 터치포인트)이 정식 관리 편에 합류. `test_version_consistency.py` 3/3 PASS(신규 partial-bump 거부 테스트 포함).
- **E2E 실측**: 4백엔드(claude/grok/codex/**opencode**) 연속 direct 위임 전원 `completed` — 레지스트리에서 재확인. 주목: `17f2e688`(내 세션에 위임된 리뷰 잡)이 이 매트릭스의 4번째 행이며 정상 완료 — **이번 검토를 수행하는 나 자신이 결함 ① 패치 이전에는 좀비가 될 뻤했던 파이프라인 위에서 이제 정상 완료되고 있다**는, 패치 효과의 가장 직접적인 1차 증거다.
- **과거 좀비 3건(`93a44347`/`2961b822`/`ee242671`) 전부 `error`로 정리 완료** — 58fba2b1 §4-4 권고 이행 확인.
**SemVer v4.4.1 PATCH 적정**: 결함 ①② 수정 + 롤백 스위치·타임아웃 변수는 부가 설정으로서 하위 호환. 신규 공개 인터페이스 없음(신규 `close` 서브커맨드는 additive CLI). PATCH 판정 타당.
## 5. 최종 판정
설계(Rev.2)·4인 리뷰 권고(내 2건 포함)·구현·테스트·릴리스가 전 단계에서 정합되며, 결함 ①은 CAS 엔진 경계에서 터미널 불변성·ABA·토큰 선조건이 구조적으로 시행되고, 결함 ②는 네이티브 1차 idle 대기 + 단일 주입 + stalled 재확인(재제출 금지) + 소켓 격리 유지로 완결되었다. 27개 신규 테스트와 777 전체 스위트를 내가 직접 실행해 전부 통과했고, 4-way 락스텝과 E2E 실측(내 세션 포함)이 일치한다. 차단 사항 없음.
[VERDICT: PASS]
@@ -0,0 +1,46 @@
### [reviewer-opencode-01] Issue #6 구현 결과물 8~9차 통합 최종 재검토 의견 (Consolidated Round 8–9 Final Review)
- **Job**: `5d0327b7` (9차 통합) — 중단된 `9bce9b85`(8차)·`f7afc36d`(9차 초안)의 검증을 흡수·통합
- **검토자**: `reviewer-opencode-01` (4차 `8b455e21`, 6차 `24e28c12` NOT PASS의 원 지적자)
- **검토 방법**: 두 라운드의 전 제품 코드 클레임을 라이브 소스에서 라인 단위 검증 + 신규 회귀 테스트(T1-22~T1-25, T2-14) 직접 실행 + **브리프 지정 8-스위트 211개를 2회 연속 실행** + 타임아웃 마진 보강 실측 + 정적 검사.
---
## 1. 제품 코드 클레임 검증 (라운드 8 + 9 전 항목)
| 클레임 | 실측 검증 | 판정 |
|---|---|---|
| R8-1: 엔진 CAS 강화 — 재위임 잡(attempt>1)의 비-오퍼레이터 terminal 전이에 토큰 필수 | `_decide`: `expected_attempt is None and source not in OPERATOR_SOURCES and requested in TERMINAL_STATUSES` + `rec_attempt > 1` → "dispatch token required" 거부. `OPERATOR_SOURCES = ("registry_cli", "operator", "delegate_wrapper")` 확인 | ✅ |
| R8-2: publish_event CLI 발행 전 조기 차단 | `main`: 레코드에 토큰 존재 + `rec_attempt > 1` + terminal 이벤트 + 호출자 토큰/시도 없음 → rc=4 와이어 0회; 토큰 불일치 → rc=4; 시도 불일치 → rc=4 (3분기 로직 :299-321 확인) | ✅ |
| R8-3: service.py 100% 동등성 | `publish_event(expect_dispatch_token, attempt_id)`: CLI와 동일하게 토큰 없는 terminal(attempt>1) → rc=4, 불일치 → rc=4 확인 | ✅ |
| R8-4: `delegate_publish_event` 헬퍼 4·5번째 인자 | lib.sh:1909-1914, 2003-2008 — `tok`/`att` 선택 인자 → `--expect-dispatch-token`/`--attempt-id` 전달 확인 | ✅ |
| T1-24 (4대 CAS 우회 경로 차단) | 직접 실행 PASS — 이전 토큰 CLI/토큰 없는 CLI/서비스 data 토큰/서비스 토큰 없음 전부 rc=4 + 레코드 pending 보존 + 유효 토큰 attempt-2만 completed 전이 | ✅ |
| R9-B1: bash 3.2 `set -u` 빈 배열 | lib.sh 1913/2007 `${extra[@]+"${extra[@]}"}` 교체 확인; `/bin/bash -n` 파스 클린; `set -u` 생존 실측. macOS 기본 bash 3.2에서 세션 생성 롤백 버그 원천 해소 — 8차에서 내가 재현한 크래시 계열의 올바른 수정 | ✅ |
| R9-B2: R2 계약 보존 | 거부 조건이 "토큰 **과** 기대 시도가 모두 없는 경우"로 한정 — `expected_attempt`를 증명한 정당한 호출자(auto-complete 등)는 거부되지 않음; `test_r2_expected_attempt_must_be_proved_not_merely_uncontradicted` PASS (내 실행) | ✅ |
| R9-P2: 세션 라이프사이클 토큰 고정 | `stop_session.sh:157-158`·`create_session.sh:359-360`에서 dispatch_token/attempt_id 고정 후 `delegate_publish_event` 4·5번째 인자로 전달; `cli.py` publish `--expect-dispatch-token` 포워딩; lib.sh `MAM_JOBS_DIR` → `--registry-dir` 자동 포워딩. T1-25 (재위임 잡 stop → cancelled 정상 전이 + attempt-3 재위임 후 stale 토큰 취소 차단) 직접 실행 PASS | ✅ |
| R9-N1: 문서 동기화 | `state-transitions.md:55` 및 `MESSAGING.md:350` — OPERATOR_SOURCES에 `delegate_wrapper`, attempt>1 terminal의 토큰/시도 필수 계약 명문화 확인 | ✅ |
| T1-22/T1-23 | 서비스/구독자 CAS 토큰 계약 — 직접 실행 PASS | ✅ |
## 2. 타임아웃 마진 보강 (이번 라운드의 핵심) — 실측
**배경**: 8차 검토 중 나 자신이 이 결함을 두 번 관측했다 — 4개 에이전트가 동시에 pytest를 돌리는 부하 상황에서 `fail_closed` 파일 실행마다 **서로 다른 테스트**(t1_20 → t1_7/t1_15 등)가 `subprocess.TimeoutExpired`(외부 20~35s 예산)로 산발 실패. 격리 실행에서는 전부 통과. 브리프의 원인 진단(동시 실행 부하)은 내 관측과 정확히 일치한다.
**보강 실측**: `_run_wrapper` 기본 외부 타임아웃 60s(기존 30/35/40s)로 상향 12+곳, `t1_20` subscriber idle 대기 25s, `t1_14` 10s — 코드 확인 완료.
**결과 (내 직접 실행)**:
- issue6 2-파일: **43/43 PASS** (154.78s) — 브리프 주장(43)과 일치
- 브리프 지정 8-스위트: **211/211 PASS** (232.60s, 1 failure 없음)
- fail_closed 단독 재실행: **29/29 PASS** (121s) — 2회 연속 전체 통과로 안정성 확증
- 정적 검사: `git diff --check 7b761be` 클린, `/bin/bash -n lib.sh` 클린
- 4-way 버전 일관성 v4.4.1: `test_version_consistency.py` 3/3 PASS (lib.sh ↔ eager.py ↔ VERSIONS.md ↔ 8 SKILL.md)
## 3. 잔여 관찰 (비차단)
1. **여전히 완전 밀봉은 아님**: 60s 마진은 동시-부하 플레이크를 실측상 해소했지만, 실구독자 테스트의 공개 브로커(broker.hivemq.com) 의존 자체는 잔존한다. 6차에서 내가 제안한 로컬 브로커 fixture(nats-docker, O-5 궤도)는 후속 과제로 유지 권고 — 브로커가 재차 half-open이 되면 유사 민감도가 이론적으로 재현 가능하다. 단, 현재 마진에서는 내 3회 연속 실행 모두 통과했고 이는 수용 기준(100% 통과)을 충족한다.
2. 테스트 수 변동: fail_closed 29 + turn_handshake 14 = 43 (기존 30+13) — t2 14번째 테스트 추가에 따른 것으로 전체 합은 불변, 브리프 수치와 일치.
## 4. 최종 판정
라운드 8~9의 전 제품 코드 결함(CAS 우회 4경로 차단, bash 3.2 호환, R2 계약 보존, 세션 라이프사이클 토큰 고정, 문서 동기화)이 전부 정확히 구현되었음을 라인 단위로 검증했고, 내가 6차(NOT PASS)와 8차(관측)로 지적해온 두 이슈 — 브로커 민감성의 실질 원인이었던 **동시 실행 타임아웃 예산** — 가 이번 라운드의 60s 헤드룸으로 해소되어 211개 전체를 2회 연속 100% 통과했다. T1-22~T1-25와 T2-14 가드가 신규 계약을 봉인했고, 정적 검사와 4-way 버전 일관성도 클린이다. 잔여 사항은 로컬 브로커 밀봉이라는 향후 권고 수준이다. Issue #6 Phase 1~5의 만장일치 합의에 동의한다.
[VERDICT: PASS]
@@ -0,0 +1,40 @@
### [reviewer-opencode-01] Issue #6 구현 결과물 2차 최종 재검토 의견
- **Job**: `e9c5db1d` / **검토자**: `reviewer-opencode-01` (1차 검토 `512cfec7` 작성자)
- **검토 방법**: F1~F5 각 보완을 라이브 소스에서 직접 확인, 신규 테스트 재실행, E2E 문서의 잡 ID 클레임을 **레지스트리 원본 데이터와 대조** (요약을 신뢰하지 않고 원장 검증).
---
## 1. F1~F5 보완 사항 반영 확인
| # | 클레임 | 실측 검증 | 판정 |
|---|---|---|---|
| F1 | `inject_agent` 내 주입 실패 시 `trap - EXIT` 즉시 해제 | `multi-agent-mux-delegate-job` `inject_agent`: `if ! send_keys_safe ...` 실패 블록 **첫 줄**에 `trap - EXIT` (echo/return 이전) — 상위 `exit 1` 시 트랩 재발행 없음. `finalize_unfinished`의 direct 경로 error 발행과의 이중 발행 원천 차단. | ✅ 반영 |
| F2 | `VERSIONS.md:49` 종료 코드 SKILL.md 일치화 | VERSIONS.md v4.4.1 항목 `0/1/2/3/5` ↔ SKILL.md:146-153 표 ↔ 구현 `_rc_for()` (completed→0, error→1, timeout→2, broker_unavailable→3, cancelled→5) 3자 완전 일치 | ✅ 반영 |
| F3 | `test_t2_6` 모킹 갭 해소 (`SKS_PROMPT_WAIT=0` + `pane_id` 실경로) | 테스트 코드 확인: `SKS_PROMPT_WAIT=0`, `SKS_IDLE_HANDSHAKE=0`, 실제 pane buffer("esc to interrupt") + `prompt_wait_result=timeout` 모킹으로 폴백 paste-buffer 경로 + `lib.sh:2483-2489` pre_submit busy-token strip을 실경유. 내 재실행 **11/11 PASS** (t2_6 포함, rc=4 단언). | ✅ 반영 |
| F4 | e2e/task.md 실측 Job ID 갱신 (`e59778a0`, `2286634c`, `f657a7fe`, `512cfec7`) | Job ID 치환 자체는 완료. **그러나 갱신된 표의 내용이 레지스트리 원본과 불일치 — 아래 §2 상세.** | ⚠️ 불완전 |
| F5 | 가상 경로 정정 (`turn_handshake.py`→`watcher.py` 등) | 전체 그레프: 잔여 매칭은 실재 파일명/심볼(`tests/test_issue6_turn_handshake.py` 테스트 파일명, `lib_py/loop/watcher.py`, `lib.sh: wait_for_agent_idle`)뿐 — 가상 경로 0건 | ✅ 반영 |
## 2. 핵심 결함 완결성 최종 평가 (F4 상세 포함)
**코드 완결성 — 1차 검토(`512cfec7`) 결론 유지, 전부 재확인**: `finalize_unfinished` 8경로, `close --request` CAS 터미널 불변성("conflicting ... after terminal; refusing"), `attempt_id` 단조 증가 ABA 방지, `wait_for_agent_idle` 구독자 선행 실행, watcher `--session` 격리, 네이티브 단일 주입 + stalled 재제출 금지(재확인 후 `working`→수용 / rc=4). 이번 라운드 재실행: `test_issue6_fail_closed.py` + `test_issue6_turn_handshake.py` + `test_version_consistency.py` = **30/30 PASS**.
**그러나 F4가 생성한 E2E 문서에 사실 부정확이 있다** — 레지스트리 원본 대조 결과:
- `docs/contracts/issue-6/phase5-e2e.md:35` (3행, `f657a7fe`/codex): 최종 상태 `completed`로 기재 — **실제 레지스트리는 `error`** (subscriber rc=2 timeout → `finalize_unfinished` 종결, 08:30:48 error 이벤트). 게다가 해당 잡의 산출물은 `[VERDICT: NOT PASS]`(F1~F5를 낳은 1차 리뷰)였다 — 어떤 의미로 읽어도 `completed`는 사실이 아니다.
- `:36` (4행, `512cfec7`/opencode — 나의 1차 검토 잡): 최종 상태 `completed`로 기재 — **실제 레지스트리는 `error`** (내 풀스위트 17분 실행이 구독자 idle 예산을 초과, timeout 종결; 리포트는 정상 전달되었고 completed 발행은 CAS가 정당히 거부).
- `:52-53` "subscriber가 completed 이벤트 수신 즉시 rc=0으로 클린 종료됨" — 2행(3·4번)에 대해서는 사실이 아님: 실제 시퀀스는 timeout → fail-closed error 확정 → 늦은 completed CAS 거부였다.
**아이러니**: 이 두 행의 실제 시퀀스는 결함 ① 패치가 **의도한 대로 작동했음을 보여주는 최적의 실측 증거다** (fail-closed 종결 + 터미널 불변성). 문서가 이를 `completed`로 미화하는 바람에, 오히려 진실(fail-closed 실전 검증)이 가려졌다. 이는 본 세션이 일관되게 기각해온 '합의/상태 왜곡' 계열(`aca0b7e8`, `50cb5ac0` 계열)과 같은 유형의 문서 무결성 결함이다.
## 3. 엣지 케이스 및 회귀 위험도 평가
- **코드 측 신규 위험 없음**: 이번 라운드 변경은 F1(트랩 해제, 3줄)·F2(문서)·F3(테스트 보강)·F5(문서)로, 코드 가치에는 무영향. 30/30 재통과 확인.
- **900초 잡 예산 vs 장시간 검토 작업**: 512cfec7/f657a7fe 사례가 드러낸 운영 특성 — 풀스위트(17분)를 돌리는 리뷰어는 구독자 idle 타임아웃(300s)을 초과한다. 이는 버그가 아니라 **문서화할 운영 파라미터**다: 장시간 검토 잡에는 상위 `--timeout/--idle-timeout` 상향 위임이 필요. e2e 문서 수정 시 이 권고를 함께 기입할 것.
- **나머지 2행(e59778a0, 2286634c)과 하단 주석 4건(6f091091 등)은 레지스트리와 일치** (전부 completed 실측 확인) — 오염은 2행 + 클린 종료 서술뿐.
## 4. 최종 판정
F1·F2·F3·F5는 정확히 반영되었고, 코드 수준의 완결성은 1차와 동일하게 훌륭하 (30/30 재검증). 그러나 **F4의 "실측 데이터 동기화"가 오히려 2개 행의 최종 상태를 레지스트리 원본과 반대로 기재**했고, 이는 검증 근거 문서(evidence document)의 사실 정확성 결함으로서 본 세션의 문서 무결성 기준상 차단 대상이다. 수정은 자기조직적이고 경미하다: `docs/contracts/issue-6/phase5-e2e.md:35-36` 두 셀을 `error (subscriber timeout; fail-closed 종결 — 리포트 산출물 정상 전달, completed는 터미널 불변성에 의해 거부됨)` 계열의 사실 서술로 바로잡고, `:52-53`의 클린 종료 서술에 타임아웃-종결 시나리오를 명시하라. 코드 커밋은 이 수정과 함께 진행 가능하다 — 코드 자체는 PASS 수준이며, 본 NOT PASS는 문서 2셀+1서술의 정확화 요구다.
[VERDICT: NOT PASS]
@@ -0,0 +1,40 @@
### [reviewer-opencode-01] Issue #6 구현 결과물 3차 최종 재검토 의견
- **Job**: `8b455e21` / **검토자**: `reviewer-opencode-01` (1차 `512cfec7`, 2차 `e9c5db1d`의 작성자)
- **검토 방법**: 7개 조치 항목을 라이브 소스에서 직접 읽어 라인 단위 확인, 27개 Issue #6 테스트 재실행, **전체 회귀 스위트 직접 실행 (777/777, 19분)**, E2E 문서 진실성 재대조.
---
## 1. 7개 조치 항목 반영 확인 (라인 단위 실측)
| # | 항목 | 실측 검증 | 판정 |
|---|---|---|---|
| F4 | E2E 문서 진실성 | `phase5-e2e.md` 3·4행이 이제 `error` + "fail-closed 확정 실증 (리포트 정상 전달, 후속 completed CAS 정상 거부)"로 기재 — 레지스트리 원본과 100% 일치. :46 서술도 timeout→finalize→CAS-거부의 실제 시퀀스로 정정. 내 2차 지적을 정확히, 그리고 **과하게 미화하지 않게** 반영 | ✅ |
| R1 | Working-agent timeout 재관측 | `finalize_unfinished` timeout 분기(:600-655): subscriber 타임아웃 시 `herdr agent get`으로 `working` 확인 → 남은 데드라인 동안 3초 간격 디스크 재관측, 늦은 completed 수용, agent 정지 시 1초 유예+최종 디스크 확인 후 종료 | ✅ |
| P1 | CAS 토큰 불일치 우회 차단 | close rc=4(토큰 불일치/stale attempt) → "suppressing event emission" 후 이벤트 발행 스킵(:681-685); direct 발행 전 디스크 completed 재확인 → 이중 error 발행 억제 | ✅ |
| P1 | busy-token 만료 안전 반환 | `lib.sh:2420-2435`: `SKS_BUSY_TIMEOUT` 후에도 `still_busy`면 강제 주입 없이 `rc=4` 반환 | ✅ |
| P1 | 불확실 RPC 재시도 방지 | `lib.sh:2395`: 패턴에 `transport_error\|connection` 추가 → paste-buffer 폴백으로 떨어지지 않고 `agent get` 상태 확인 후 `working`이면 수용, 아니면 `rc=4` | ✅ |
| P1 | Runner absent-record hang 방지 | `runner.py:318-333`: 레코드 부재 5회 연속 + 최소 5초 경과 → "aborting wait" 로그 후 `return False` (3,900초 블로킹 제거) | ✅ |
| P2 | Validate hook 도달성 | reviewer 승인/최대 반복 경로가 `final_loop_rc` 설정 후 `break` → 루프 탈출 후 `--validate` 훅 수행 후 `exit "$final_loop_rc"` (:486-520). (worker/reviewer *실패* 경로는 기존대로 즉시 `exit` — 실패 시 검증할 산출물이 없어 의도적이며 SKILL.md 종료 코드 계약과 정합) | ✅ |
## 2. 테스트 검증 (직접 실행)
- `test_issue6_fail_closed.py`(16) + `test_issue6_turn_handshake.py`(11) = **27/27 PASS** (내 실행, -v 확인). t2_6/t2_7/t2_9/t2_11 등 2차 보완 항목의 회귀 가드 전부 통과.
- **전체 회귀**: `pytest tests/ -q` 내 직접 실행 — **777 passed / 0 failed (1,142s)**. 기존 750 + 신규 27, 회귀 없음.
- `test_version_consistency.py` 3/3 (v4.4.1 락스텝 유지).
## 3. 엣지 케이스 및 회귀 위험도 평가
- **R1의 무한 대기 여지**: 재관측 루프는 남은 데드라인(`TIMEOUT - elapsed`)으로 상한이 걸려 있어 유한 — `--timeout` 예산 내에서만 늦은 완료를 수용한다. `remaining=0` 즉시 종결. 안전.
- **R1의 상태 조회 실패**: `agent get` 실패 시 `agent_st=""` → working 아님 → 즉시 finalize 경로로 복귀. fail-open 없음.
- **P2의 의도적 비대칭**: 실패 경로가 validate를 우회하는 것은 산출물 부재 상황에서 정당하며, 종료 코드 계약(`_rc_for`)을 지키기 위한 필수. 승인 경로만 break하는 설계는 옳다.
- **잔여 관찰 (비차단)**:
1. R1의 working-agent 재관측 루프(~50줄)와 P1의 wrapper-level rc=4 발행 억제, P1-3의 transport_error 분기에 **전용 회귀 테스트가 없다** (기존 t1_3/t1_5/t1_11은 인접 계약을 커버하지만 이 신규 분기 자체는 무커버). 후속 패치에서 가드 추가 권고.
2. 브리프가 "총 30개 테스트"로 기재했으나 실제 16+11=27개 — 브리프 측 계수 오류 (코드 결함 아님).
3. 900초 잡 예산 vs 장시간 검토(풀스위트 19분)의 운영 특성은 R1로 완화되었으나, 근본적으로는 상위 위임 시 `--timeout` 상향 위임이 권고됨 (이미 e2e 문서 :46에 기재).
## 4. 최종 판정
2차에서 내가 지적한 문서 진실성 결함(F4)이 사실 그대로 정정되었고, 2차에서 다른 리뷰어들이 지적한 6개 코드 보강(R1, P1×4, P2)이 전부 정확히 구현되었다. 이번 라운드의 신규 변경도 포함해 **27/27 대상 테스트와 777 전체 스위트를 내가 직접 실행해 전부 통과**했으며, v4.4.1 4-way 락스텝도 유지된다. 잔여 사항은 신규 분기의 테스트 가드 부재라는 권고 수준(비차단)과 브리프의 테스트 계수 오류(문서 오탈자 수준)뿐이다. Issue #6은 결함 ①(fail-closed/CAS/ABA)과 결함 ②(턴 핸드셰이크/단일 주입) 모두에서 구조적으로 완결되었고, E2E 실측 문서는 이제 레지스트리 원본과 정확히 일치한다.
[VERDICT: PASS]