nunchi: verify Codex judge fallback actually triages on claude-unauthenticated nodes (#1264 ③ 정정)

[seoseo-ai]

요약

#1264 인수인계서의 ③ 항목(judge codex 어댑터 구현)은 이미 구현·머지되어 있습니다. 남은 것은 구현이 아니라 실측 검증입니다. 이 이슈는 그 검증 범위를 정의합니다.

정정 — 인수인계서 ③의 전제는 무효

인수인계서(/root/nunchi-1264-handoff-20260825.md, 2026-08-25 12:1x 작성)는 아래처럼 적었으나, 작성 시점 이후 머지된 코드와 어긋납니다.

인수인계서 주장	현재 main 실측
judge_item()이 claude -p 고정	judge_candidates()가 claude → codex 순서로 시도 — judge-batch.py:264-281
claude 전용 플래그라 drop-in 불가	_codex_judge() 전용 어댑터 존재 — judge-batch.py:336-361
NUNCHI_JUDGE_CMD=codex로 못 바꿈	NUNCHI_JUDGE_PROVIDER (auto|claude|codex) + NUNCHI_JUDGE_CMD 오버라이드 지원 — judge-batch.py:64-65

근거 커밋: f23ab50 — feat(nunchi): add fail-closed Codex judge fallback (#1278) (#1280)

원인: 인수인계서를 쓰면서 인수인계서 작성 시점과 f23ab50 머지 시점의 선후를 확인하지 않았습니다. #1264 코멘트에 정정을 남겼습니다.

현재 구현 동작 (소스 기준)

• auto 모드는 Claude 우선, 호출/출력 실패 시에만 Codex 폴백 (judge-batch.py:264-281)
• human 판정은 결과이지 실패가 아니므로 두 번째 모델 호출을 소비하지 않음 (:268-270)
• Codex 경로는 격리 실행: codex exec --ephemeral --ignore-user-config --ignore-rules --sandbox read-only --skip-git-repo-check --output-schema <judge-verdict.schema.json> --output-last-message <tmp> --config approval_policy="never" (:336-361)
• 모든 백엔드 소진 시 fail-closed — verdict=human, backend=null (:456-462)

검증해야 할 것 (이 이슈의 범위)

claude 미인증 노드에서 Codex 폴백이 실제로 판정을 내는지 실측. 코드 존재는 동작을 보장하지 않습니다.

대상 노드 (2026-08-25 실측, claude loggedIn: false):

노드	유효 큐
gwakga	237
sogyo	24
bangtong	5
jingun	2

• 각 노드에서 codex 바이너리 존재 및 인증 상태 실측 (shutil.which 경로 + codex login status)
• dry-run으로 judge-batch 1회 실행, backend=codex로 판정이 나오는지 확인
• judge-audit.jsonl의 backend / attempts 필드 확인 — claude:* 실패 후 codex 성공 경로가 기록되는지
• --output-schema 스키마 검증이 실제로 통과하는지 (파싱 실패 시 codex:* failure로 떨어짐)
• 판정 품질 표본 검토 — Codex 판정이 Claude 판정과 비교 가능한 수준인지
• NUNCHI_JUDGE_CODEX_MODEL 미설정 시 기본 모델이 무엇인지, 적절한지

통과 기준

• 대상 4대 중 최소 1대(gwakga 우선 — 큐 237로 최대 수혜)에서 backend=codex 판정이 dry-run으로 재현됨
• fail-closed 경로가 오탐 없이 동작 (백엔드 정상인데 human으로 떨어지지 않음)

⚠ 실행 노드 제약

yukson · nosuk에서 수행하지 마십시오. 두 노드는 08-27~28 APPLY 파일럿 관측 대상이고, 관측 변수가 유입률입니다. 세션 distill이 리뷰 큐에 fact를 새로 쓰므로 작업 자체가 측정에 섞입니다.

실측 근거: yukson 유효 큐가 2026-08-25 하루 동안 740 → 968 → 1034로 상승. 큐 적체가 아니라 작업 세션의 distill 유입입니다.

검증 대상 노드(gwakga 등)에서 직접 수행하면 이 제약과 충돌하지 않습니다.

계수 방식

큐 수치는 조건과 함께 인용하십시오:

값	조건	출처
유효 큐	valid_to IS NULL AND review=1	nunchi.py:1073
스냅샷 검토대기	위 − G5 차단분	nunchi.py:940-955 (#1272)
배치 소진 가능량	위 + AND created_at <= ?	judge-batch.py:187

관련

• nunchi/mempalace 개선 로드맵: decision 근거 보존(G5), review 큐 분류, 연상 회상, 태스크 조건 스냅샷 #1264 (모 이슈)
• feat(nunchi): add a Codex adapter and fail-closed judge fallback #1278 / PR feat(nunchi): add fail-closed Codex judge fallback #1280 (f23ab50) — Codex 폴백 구현
• fix(nunchi): read the codex auth verdict from stderr, where codex writes it (#1264) #1273 — codex 인증 프로브 stderr 결함 수정 (이 결함 때문에 "codex 미인증"으로 오판했었음)

[seoseo-ai]

실측 — 검증 조건은 이미 갖춰져 있고, 남은 건 첫 실행뿐입니다

2026-08-26 00:3x KST, 대상 4대에 read-only SSH로 확인했습니다.

배포·인증 상태 — 4대 전부 준비 완료

노드	유효 큐	claude	_codex_judge 배포	감사 backend 필드	judge 크론	codex 인증
gwakga	237	loggedIn: false	✅ (2회)	✅	✅ 1건	Logged in using ChatGPT
sogyo	24	loggedIn: false	✅ (2회)	✅	✅ 1건	Logged in using ChatGPT
bangtong	5	loggedIn: false	✅ (2회)	✅	✅ 1건	Logged in using ChatGPT
jingun	2	loggedIn: false	✅ (2회)	✅	✅ 1건	Logged in using ChatGPT

큐는 valid_to IS NULL AND review=1 기준입니다.

즉 코드 수정 없이 한 번 돌리기만 하면 검증됩니다.

judge 배치가 4대 모두 한 번도 실행된 적이 없습니다 — 결함 아님

• ~/.nunchi/judge-audit.jsonl 파일 없음 (4대 전부)
• ~/.nunchi/judge.cron.log 파일 없음 — >> 리다이렉트는 실행만 되면 빈 파일이라도 생성하므로, 이는 명령이 한 번도 수행되지 않았다는 뜻입니다

원인은 단순합니다:

항목	gwakga	jingun
judge 크론 설치 시각	applied_at 2026-08-24T23:41:33Z = 08-25 08:41 KST	2026-08-25T04:17:14Z = 08-25 13:17 KST
crontab 파일 mtime	Aug 25 08:41 (일치)	—
크론 실행 시각	매일 41 4 * * *	동일

설치 이후 04:41이 아직 한 번도 오지 않았습니다. 첫 실행은 2026-08-26 04:41 KST입니다.

cron 데몬은 정상입니다 — 같은 시간대 journal에 ingest-cron.sh가 08-25 04:50에 실행된 기록이 있습니다(journalctl -u cron). 다른 nunchi 크론 로그도 최근까지 갱신 중입니다.

검증 경로 — 새 작업이 거의 필요 없습니다

08-26 04:41에 4대가 dry-run으로 자동 실행되면 검증 데이터가 저절로 생깁니다. dry-run도 판정은 수행하므로(APPLY는 적용 여부만 좌우) backend 기록에는 영향이 없습니다.

08-26 04:41 이후 확인할 것:

• ~/.nunchi/judge-audit.jsonl 생성 여부 (4대)
• backend 필드가 codex인 판정이 존재하는지 — claude 미인증이므로 claude:* 실패 후 폴백해야 정상
• attempts 배열에 claude: 실패 사유가 기록되는지
• class=judge 항목의 rationale이 실제 모델 출력인지 (fail-closed 시 verdict=human, backend=null)
• --output-schema 검증 통과 여부 — 실패 시 codex:* failure로 떨어짐
• NUNCHI_JUDGE_CODEX_MODEL 미설정 시 기본 모델 적절성

만약 04:41에도 실행되지 않으면 그때는 실제 결함이므로 별도 조사가 필요합니다.

⚠ 감사 스키마 변경 주의

backend / attempts 필드는 f23ab50(08-25 14:52, #1280)에서 추가됐습니다 — judge-batch.py:631. 그 이전에 생성된 감사 행에는 이 필드가 없습니다.

yukson의 기존 40행이 그 예로, 전부 f23ab50 이전 산출물이라 backend가 없습니다. 검증에는 신규 실행분만 사용하십시오. 옛 행에 backend가 없는 것은 폴백 실패의 증거가 아닙니다.

참고 — LLM judge 자체는 동작 확인됨

yukson 감사 40건 중 class=judge 11건의 rationale이 실제 모델 출력입니다(사실 비교 수행, 한국어·영어 혼재). 판정 경로 자체는 살아 있습니다. 미검증인 것은 codex 폴백 경로뿐입니다.