meta(bridge): PR/CI 상태 변화를 세션이 실시간으로 인지할 경로가 없음 (PR #906 사례)

[seoseo-ai]

배경

PR #906 작업 중 "CI가 아직 도는 중"이라고 2세션에 걸쳐(2026-08-03 생성 → 2026-08-05 재확인 요청 시점까지, 약 2일) 보고했으나, 실제로는 PR #906이 생성 44분 만에 duplicate으로 closed되어 있었다. CI 자체는 정상적으로 6분 만에 통과했다. 즉 실패한 건 "CI 완료"가 아니라 **"CI/PR 상태 변화를 세션이 인지하는 경로"**다.

라이브 증거 (2026-08-05 재조사, gh CLI 직접 조회)

타임라인 (전부 2026-08-03, UTC):

시각	이벤트
09:36:03	PR #906 (fix/configurable-max-buffer-size) open, author seoseo-ai (gongyung 브릿지 identity)
09:36:07	harness-ci / codeql 워크플로 트리거
09:39:18	PR #908 open (jinon86) — 같은 근본원인(claude-agent-sdk 1MB 고정 버퍼)에 대한 별도 수정
~09:42	PR #906 CI 완료 — harness-ci success(6m12s), codeql success(1m11s), 회귀 0건
10:07:23	PR #908 MERGED
10:26:37	PR #906 CLOSED — jinon86 comment: "Duplicate of #908 which already implemented this fix with comprehensive tests and documentation."
16:06:51	Issue #907(인시던트 기록) closed — "Resolved by #908 (commit 7ca16ee) ... Closing as implemented."

gh pr view 906: state=CLOSED, mergeable=CONFLICTING, statusCheckRollup=[] (closed PR은 check rollup이 사라짐 — 이것도 "왜 지금 보면 체크가 안 보이나" 혼란의 원인 중 하나였다).

그런데 세션 메모리(Wiki pages/team/gongyung/TASKS.md 다음 액션 / Honcho 요약)는 이 사건이 다 끝난 뒤에도 계속 "PR #906 CI 진행 중, 대기"로 carry-forward 되었고, 2026-08-05 세션 재개 시점까지도 재검증 없이 그대로 사용자에게 보고되었다.

원인 분석

1. Push형(이벤트 기반) 추적 경로가 없다. GitHub Actions/PR 이벤트를 gongyung 브릿지로 전달하는 webhook이 연결돼 있지 않다 (webhook-subscriptions Hermes skill은 존재하지만 이 용도로 활성화된 적 없음 — hermes webhook list 기준 미확인).
2. Poll형(주기 확인) 추적 경로도 없다. crontab -l에 gongyung 자신이 연 PR(gh pr list --author seoseo-ai --state open 등)을 주기적으로 재확인하는 job이 없다. 기존 cron은 Wiki facts.json 갱신(facts-refresh.sh)과 일반 메모리 리프레시(memory-refresh-safe.sh)만 하고, GitHub PR/이슈 상태는 건드리지 않는다.
3. 유사 인프라는 있지만 이 케이스를 커버하지 않는다.
   • pages/a2a/pr-shepherd-operations.md의 "PR Shepherd" — A2A GitHub patch task가 만든 PR 전용 systemd timer 설계다. gongyung은 Termux(systemd 없음)이고, PR #906은 A2A 태스크가 아니라 세션이 직접 연 PR이라 범위 밖이다.
   • LOG-20260716-bangtong-4 — Seoseo에 "ccc-node 새 PR 3분마다 검토·병합" cron이 있다고 기록돼 있으나, 이건 신규 PR을 검토·병합하는 용도지 자기 PR의 상태 변화를 원 세션에 되돌려주는 용도가 아니고, gongyung 노드에는 없다.
4. 세션 인계(hand-off) 시 stale 클레임을 강제로 재검증하는 훅이 없다. Wiki/Honcho에는 "가변 사실은 live-check 후 주장하라"는 정책이 이미 문서화돼 있지만(§Operational facts are mutable), 이걸 기계적으로 강제하는 장치가 없어서 "PR 대기 중" 같은 구체적 클레임이 정책 위반인 채로 그대로 반복 보고됐다.

영향

• 사용자에게 2일간 잘못된 상태("CI 진행 중")를 반복 보고.
• PR fix(bridge): expose claude-agent-sdk max_buffer_size as CLAUDE_MAX_BUFFER_SIZE #906/#908이 같은 근본원인을 3분 차이로 독립적으로 고쳐서 중복 작업 발생 — 코디네이션 갭의 방증이기도 함(범위 밖이면 별도 이슈로 분리 가능).
• 이번엔 "이미 끝난 좋은 결과(duplicate/merged)"였지만, CI가 실패로 끝난 경우였다면 2일간 실패 상태를 인지하지 못했을 수 있다 — 더 심각한 실패 모드.

제안 (택1 또는 조합)

1. Poll 기반 최소 구현부터: gongyung cron에 gh pr list --author seoseo-ai --repo jinwon-int/ccc-node --state open --json number,url,statusCheckRollup,updatedAt 주기 조회 스크립트 추가. 상태 변화(open→closed/merged, check pending→completed) 감지 시 Wiki 세션 상태 파일 갱신 + (선택) Telegram 알림.
2. 세션 인계 훅: Wiki team TASKS.md/Honcho에 "PR #NNN 대기 중" 류의 클레임을 다음 세션이 그대로 재사용하기 전, 자동으로 gh pr view를 1회 강제 실행하는 pre-flight 체크 추가.
3. (중기) webhook 경로: webhook-subscriptions skill로 GitHub Actions/PR 이벤트를 gongyung 브릿지에 연결 — 이미 인프라는 있으니 활성화 + ccc-node repo에 webhook 등록.

열린 질문

• 이 gap을 ccc-node(브릿지 자체 기능)에서 고칠지, gongyung 노드 운영 스크립트(node-local cron)에서 고칠지 — 다른 노드(Seoseo 등)의 guarded PR cron과 중복 설계 아닌지 먼저 확인 필요.
• Seoseo의 "3분 guarded PR review+merge" cron이 지금도 살아있는지, 있다면 gongyung도 같은 패턴을 재사용할 수 있는지 live-check 필요.

관련

• fix(bridge): expose claude-agent-sdk max_buffer_size as CLAUDE_MAX_BUFFER_SIZE #906 (closed, duplicate)
• bug(bridge): claude-agent-sdk 1MB max_buffer_size 고정값 → 대형 MCP 도구결과가 턴을 죽이고 'Cannot write to terminated process'로 표면화 #907 (closed, resolved by fix(bridge): pass explicit max_buffer_size to the Claude SDK #908)
• fix(bridge): pass explicit max_buffer_size to the Claude SDK #908 (merged — 실제 수정)
• bug(bridge): CLAUDE_PROCESS_TIMEOUT 900s가 여전히 부족 — 무거운 tool-call turn이 exit 143로 죽고 진단정보 없이 'Claude turn failed'만 노출 #901 (같은 세션에서 나온 자매 인시던트, CLAUDE_PROCESS_TIMEOUT)

[seoseo-ai]

중복 점검 결과 + close 제안 (2026-08-06, dungae 라이브 확인)

옵션별 중복 점검

옵션	실태	판정
1. Poll cron	#966(3266e7b) 구현 + gongyung 실배포·가동 중: */17 cron, 추적 설정 jinwon-int/ccc-node seoseo-ai(사고 identity 그대로), 최근 실행 result=ok	✅ 완결
2. Pre-flight 재검증	브릿지에 기존 handoff 재검증 메커니즘 없음. Seoseo agent-cron에 PR 관련 태스크 0건	중복 없음, 미구현
3. Webhook	seoseo webhook-subscriptions엔 lotto-autobuy뿐(GitHub 이벤트 경로 없음). gongyung은 Termux/Tailnet이라 인바운드 불가 → seoseo 측 신규 인프라 필요	중복 없음, 미구축

열린 질문의 전제 정정

"Seoseo의 3분 guarded PR review+merge cron이 살아있는지" → 없다. LOG-20260718-seoseo-1: 2026-07-18 오너 요청으로 제거됨. 재사용할 패턴이 아니며, 그 자리는 #966 poll이 더 가벼운 대안으로 이미 채움.

Close 근거

사고 클래스("세션이 PR/CI 상태 변화를 모름")는 현재 2중으로 커버됨:

1. feat(bridge): poll gh for PR/issue status changes (ccc-node#962) #966 poll — 브릿지 identity가 연 PR의 상태 전이를 주기 감지·통보 (gongyung 가동 확인)
2. durable wait(external_wait, feat(bridge): GitHub CI 외부 대기를 durable하게 등록하고 완료 시 대화를 자동 재개 #740) — 세션이 PR을 연 시점에 exact-head wait를 등록하면 CI terminal state에서 브릿지가 세션을 깨워 재개 (오늘 fix(nunchi): per-scope collection status in audience-scoped mode (#985) #986~fix(bridge): smoke-import binary extensions after dependency reconcile (#969) #990 머지에서 7회 실전 사용)

잔여 옵션 2/3(pre-flight 강제 재검증, webhook)은 deferred — 동일 사고가 poll+durable wait 하에서 재발하면 그때 발동. reopen은 자유.

[seoseo-ai]

Closing as sufficiently addressed: #966 poll (deployed, live on gongyung) + durable external_wait cover the incident class; options 2/3 deferred until recurrence. 상세는 직전 코멘트.