opencode-review-dispatch rejects the current dispatcher identity: allowlist says github-actions[bot], sender is opencode-agent[bot]

[seonghobae]

요약

opencode-review-dispatch.yml의 인가 게이트가 현재 디스패처 신원을 거부합니다. 허용 목록 변수는 github-actions[bot]인데 실제 디스패처는 opencode-agent[bot]입니다. 그 결과 verdict가 생산되지 않고, 상위 opencode-review job이 Fail closed without a current-head OpenCode verdict로 종료됩니다.

이것이 열린 PR 어느 것도 리뷰 증거를 얻지 못하는 이유입니다.

증거

변수 OPENCODE_REPOSITORY_DISPATCH_ACTOR = github-actions[bot]   (updated 2026-07-16)

opencode-review-dispatch.yml 누적:   success 466 / failure 9611 / completed 17311   (실패율 95.4%)

repository_dispatch run 표본 각 40건:
  success  actor: github-actions[bot] 40건        최신 2026-08-26T18:22:23Z
  failure  actor: opencode-agent[bot] 27건 / github-actions[bot] 11 / seonghobae 2
                                                  최신 2026-09-05T07:07:04Z

최근 실패 10건 전부 첫 job에서 종료:
  validate-pr-metadata → "Bind workflow inputs to live organization pull request metadata"

게이트 조건(.github/workflows/opencode-review-dispatch.yml:107 이하):

if [ -z "$ALLOWED_DISPATCH_ACTOR" ] ||
  [ "$DISPATCH_ACTOR" != "$ALLOWED_DISPATCH_ACTOR" ] ||
  [ "$DISPATCH_SENDER" != "$ALLOWED_DISPATCH_ACTOR" ]; then
  exit 1

디스패치를 보내는 쪽은 opencode-review.yml:431이고 앱 토큰을 씁니다:

GH_TOKEN="$app_token" gh api -X POST repos/ContextualWisdomLab/.github/dispatches --input -

그 앱 토큰 경로는 4a5dfd82 (2026-08-31, #1497)에서 도입됐고, 그때부터 sender가 opencode-agent[bot]이 됩니다. 허용 목록은 그보다 6주 전에 마지막으로 갱신됐습니다.

하류 영향 (다른 세션들이 측정한 값)

• 열린 non-draft PR 99건 중 현재 head에 성공한 opencode-review run을 가진 것 0건
• 그중 24건은 현재 head에 failure가 있는데, 표본 12건 전부 실패 스텝이 Fail closed without a current-head OpenCode verdict
• 해당 job들은 steps=4에 실제 runner_id를 받았습니다 — 러너 기아가 아니라 상류 verdict 부재입니다

즉 지금까지 "리뷰가 큐에서 굶는다"로 설명하던 것의 상당 부분이, 실제로는 verdict 생산자가 인가 단계에서 거부되는 것입니다.

주장하지 않는 것

이것이 유일한 원인이라고 주장하지 않습니다. 마지막 성공이 2026-08-26이고 앱 토큰 전환은 2026-08-31이라 그 사이 5일의 실패는 이 설명으로 덮이지 않습니다. 실패 표본에 github-actions[bot] 11건이 있는 것도 같은 이야기입니다 — 그 건들은 신원이 일치하는데도 실패했으므로 별개의 원인이 최소 하나 더 있습니다(대상 허용 목록, 또는 이후 스텝).

확정된 것은 이것뿐입니다: 현재 디스패처 신원은 현재 허용 목록과 일치하지 않으며, 그 조건에서 모든 앱 토큰 디스패치가 첫 게이트에서 거부됩니다.

수정 방향 — 소유자 판단 필요

두 갈래이고, 어느 쪽이 옳은지는 앱 토큰 전환의 의도에 달려 있어 제가 정할 수 없습니다.

1. opencode-agent[bot]이 의도된 신원이라면 → OPENCODE_REPOSITORY_DISPATCH_ACTOR를 그 값으로 갱신. 한 줄이지만 인가 허용 목록이라 자가 승인하지 않았습니다.
2. github-actions[bot]이 유지돼야 한다면 → opencode-review.yml:431이 앱 토큰 대신 github.token으로 디스패치해야 합니다. 다만 #1497이 앱 토큰을 도입한 이유가 따로 있을 것이므로 그 근거를 먼저 봐야 합니다.

어느 쪽이든 두 값을 일치시키는 계약 테스트를 함께 넣는 것을 권합니다. 이 저장소는 이미 같은 계열의 드리프트를 한 번 겪었고(#1747: 스케줄러 매트릭스와 OPENCODE_REPOSITORY_DISPATCH_TARGETS 변수가 갈라져 매시간 조용히 fail-closed), 그때의 처방이 두 목록을 계약으로 묶는 것이었습니다. 이번은 같은 패턴의 신원 축 버전입니다.

재현

gh api repos/ContextualWisdomLab/.github/actions/variables/OPENCODE_REPOSITORY_DISPATCH_ACTOR --jq .value
gh api "repos/ContextualWisdomLab/.github/actions/workflows/opencode-review-dispatch.yml/runs?status=failure&per_page=5" \
  --jq '.workflow_runs[]|"\(.created_at) \(.triggering_actor.login)"'

[seonghobae]

같은 근본 원인을 #1927이 먼저 등록해 두었습니다 — 독립적으로 도달했고 커밋(4a5dfd82, 2026-08-31)까지 같습니다.

#1927이 추가로 담고 있는 것:

• 이 변수를 소비하는 워크플로가 셋입니다: opencode-review-dispatch.yml:116, codeql-scan-dispatch.yml:142, pr-review-fix-scheduler.yml:115. pr-review-fix-scheduler는 마지막 성공이 2026-08-16으로 20일째입니다.
• codeql-pr.yml:258도 같은 앱 토큰 패턴으로 디스패치하고, 최근 codeql-scan-dispatch run 8건이 전부 actor=opencode-agent[bot]입니다.
• #1925와 순서 의존이 있습니다. codeql-scan-dispatch는 지금 149행 SUPPLIED_MATRIX 템플릿 오류로 인가 검사에 도달조차 못 합니다(인가 검사가 같은 run: 스크립트 안이라 env 평가 실패 시 한 줄도 실행 안 됨). #1925의 toJSON() 수정이 들어가면 155행 인가 검사에 도달하고, 이 변수가 그대로면 실패 지점이 한 칸 이동할 뿐 초록이 되지 않습니다.

이 이슈가 #1927보다 나은 것: 실패율 95.4% 정량화, 그리고 **실패 표본 40건 중 11건이 github-actions[bot]**이라는 반례. 후자가 중요합니다 — 신원이 맞는데도 실패한 경로가 최소 하나 더 있다는 뜻이고, 변수만 고쳐서는 안 끝난다는 근거입니다. #1927 제목이 "every dispatch is rejected"로 되어 있는데 그건 과한 표현이라 그쪽에 정정 코멘트를 달았습니다.

어느 쪽도 닫지 않는 편이 낫겠습니다 — 범위가 다르고(이쪽은 단일 워크플로 심층, 저쪽은 소비처 전체 + 순서 의존), 증거가 상호 보완적입니다. 조치하실 때 둘을 함께 보시면 됩니다.

관련: #1927, #1925

[seonghobae]

수정 방향 정정 — 값을 바꾸면 다른 디스패처가 막힙니다

위에서 제가 제시한 선택지 1("변수를 opencode-agent[bot]로 갱신")은 그대로 적용하면 안 됩니다. 디스패처가 하나가 아닙니다.

두 개의 디스패처

event_type: opencode-review를 보내는 워크플로가 둘입니다.

.github/workflows/opencode-review.yml            GH_TOKEN="$app_token"        → opencode-agent[bot]
.github/workflows/pr-review-merge-scheduler.yml  secrets.PR_REVIEW_MERGE_TOKEN
                                                 || secrets.OPENCODE_APPROVE_TOKEN
                                                 || steps.scheduler_app_token
                                                 || github.token                (:211, :487)

그리고 인가 변수는 단일 값입니다(쉼표 구분 목록이 아닙니다):

OPENCODE_REPOSITORY_DISPATCH_ACTOR = github-actions[bot]

게이트는 DISPATCH_ACTOR와 DISPATCH_SENDER가 둘 다 그 하나의 값과 같아야 통과시킵니다.

실측 근거

repository_dispatch 실패 run 100건 표본의 신원 분포와 시간축입니다.

opencode-agent[bot]   56건   최신 2026-09-05T07:13:12Z
github-actions[bot]   42건   최신 2026-09-04T17:01:10Z
seonghobae             2건

두 신원이 실제로 디스패치해 왔습니다. 그리고 실패 지점이 서로 다릅니다 — opencode-agent[bot]은 첫 job의 인가 스텝에서 전량 죽고, github-actions[bot]은 인가를 통과한 뒤 coverage-evidence/opencode-review의 실제 작업 스텝에서 죽습니다(별도 원인, 아래 참조).

즉 현재 허용 목록은 스케줄러 경로에 대해서는 올바르게 작동하고 있고, opencode-review.yml의 앱 토큰 경로에 대해서만 틀렸습니다. 값을 opencode-agent[bot]로 교체하면 방향만 뒤집혀 스케줄러 디스패치가 막힙니다.

그래서 수정은 셋 중 하나입니다

1. 허용 목록을 다중 값으로 — ALLOWED_DISPATCH_TARGETS가 이미 쉼표 목록 파싱을 하므로 같은 형태로 액터도 목록화. 두 신원 모두 인가.
2. 디스패처 신원을 하나로 통일 — opencode-review.yml을 스케줄러와 같은 토큰 우선순위로 맞추거나 그 반대. #1497이 앱 토큰을 도입한 이유를 먼저 확인해야 합니다.
3. 값 교체 — 권장하지 않습니다. 위 이유로 반대편을 막습니다.

1번이 가장 작고 되돌리기 쉽지만, 인가 면적을 넓히는 변경이라 그 자체가 소유자 판단입니다.

확정과 추정 구분

• 확정: 디스패치 워크플로가 둘이다 / 변수는 단일 값이다 / 게이트는 정확 일치를 요구한다 / 두 신원이 실제로 디스패치했고 실패 지점이 다르다.
• 추정: github-actions[bot] 디스패치가 스케줄러 경로에서 온다는 것. 스케줄러의 토큰이 시크릿 존재 여부에 따라 넷 중 하나로 해소되므로 런타임 신원을 정적으로 확정하지 못했습니다. 다만 opencode-review.yml이 앱 토큰 고정이므로 github-actions[bot] 디스패치는 그쪽에서 올 수 없습니다.

두 번째 원인은 이미 해소된 것으로 보입니다

별도 세션이 추적한 결과, github-actions[bot] 실패 44건은 전부 #1883 병합(2026-09-05T08:10:23Z) 이전이고 최신도 15시간 앞섭니다. 그 실패들이 죽는 Measure test and docstring evidence는 병합 전 main의 coverage 99% / interrogate 98.3% 상태와 일치하며, #1883 이후 fresh clone 측정은 2883 passed / 100% / 100% 입니다.

다만 검증된 적은 없습니다 — #1883 병합 이후 인가를 통과한 dispatch가 0건이라(전부 opencode-agent[bot]이라 A에서 먼저 걸림) B의 해소는 실행으로 확인되지 않았습니다. 정확한 표현은 **"A를 고치면 B는 이미 해소돼 있을 가능성이 높고, 아니라면 그때 드러나는 것이 세 번째 원인"**이며, A 수정이 진단 도구를 겸합니다.

[seonghobae]

원인이 셋입니다 — 이 이슈는 그중 하나입니다

다른 세션이 github-actions[bot] 실패 44건을 전수 분류했습니다. 의존 순서(validate-pr-metadata → coverage-source-tree → coverage-evidence → opencode-review)에서 처음 실패한 job으로 재분류해 하류 캐스케이드를 제거한 결과입니다.

원인 A  낡은 인가 변수 (이 이슈)        4/16  + 2026-09-04T17 이후 앱 토큰 디스패치 전량   미해소
원인 B  병합 전 main의 깨진 coverage/docstring 게이트   14/44                          #1883 이 해소
원인 C  큐 지연 중 base SHA 드리프트                    12/16                          미해소, 구조적

세 원인은 독립입니다. A를 고쳐도 C는 남고, #1883은 B만 덮습니다.

원인 C에 대해 이 이슈가 기여하는 사실 하나

C의 실패는 이 형태입니다 — 인가는 통과하고 그 다음 단계에서 죽습니다.

Authorized repository_dispatch actor=github-actions[bot] sender=github-actions[bot]
##[error]repository_dispatch metadata does not match the live pull request: base_sha.
  supplied_base=main/76969152...   live_base=main/5d55a31e...
  supplied_head=...fd964d24        live_head=...fd964d24      ← head 는 일치

검증 코드를 하류까지 따라가면 이렇습니다.

:190  검증   [ "$SUPPLIED_BASE_SHA" = "$live_base_sha" ] || mismatches+=("base_sha")   → 불일치 시 exit 1
:199  출력   printf 'base_sha=%s\n' "$live_base_sha"                                   → live 를 내보냄
:295  소비   PR_BASE_SHA: ${{ needs.validate-pr-metadata.outputs.base_sha }}
:328         git fetch ... "$PR_BASE_SHA" "$PR_HEAD_SHA"
:332         git checkout --detach "$PR_BASE_SHA"

base_sha는 하류에서 실제로 쓰이지만, 넘어가는 값은 live_base_sha입니다. SUPPLIED_BASE_SHA는 비교에만 쓰이고 버려집니다. 즉 동등성 요구는 데이터 의존이 아니라 staleness 정책이고, 그것을 풀어도 파이프라인은 live 값으로 정상 동작합니다.

head_sha는 다릅니다 — exact-head 규율의 근간이므로 엄격히 유지해야 합니다.

드리프트 빈도(오늘 origin/main 시간당 커밋): 09시 2 · 10시 2 · 11시 6 · 13시 5 · 14시 6 · 17시 11. 관측된 완주 실행이 15시간 37분 걸렸으므로 그 대기에서 base가 안 움직일 확률은 사실상 0입니다.

이 이슈의 범위

이 이슈는 원인 A(인가 변수)만 다룹니다. C는 검증 의미론에 대한 설계 결정이라 별도로 추적하는 것이 맞고, 측정한 세션이 별건으로 올립니다. A를 고쳐도 C가 남는다는 것이 요점이므로, A 수정으로 이 이슈가 닫혀도 C는 닫히지 않아야 합니다.

다만 순서는 A 먼저입니다. 지금은 앱 토큰 디스패치가 인가 단계에서 전량 죽어 C가 얼마나 남는지 실행으로 보이지 않습니다. A 수정이 C의 진단 도구를 겸합니다.

[seonghobae]

원인 C가 #1931로 별건 등록됐습니다. 위 분류표의 이슈 대응은 이렇습니다.

원인	이슈	상태
A 낡은 인가 변수	이 이슈 · #1927(같은 원인, 소비 워크플로 범위)	미해소
B 병합 전 깨진 coverage/docstring 게이트	—	#1883 이 해소(실행 검증은 아직)
C 큐 지연 중 base SHA 드리프트	#1931	미해소, 구조적

관련: #1925(codeql-scan-dispatch 미실행), #1928(게이팅하지 않는 저장소가 큐의 약 47%).

A를 고쳐 이 이슈가 닫혀도 #1931은 닫히면 안 됩니다. 세 원인이 독립이고, 지금은 A가 앞단에서 전량 차단해 C가 얼마나 남는지 실행으로 보이지 않을 뿐입니다. 순서는 A 먼저이고, A 수정이 C의 진단 도구를 겸합니다.

[seonghobae]

원인 A의 코드 측 수정: #1932

게이트가 여러 신원을 표현할 수 있도록 하는 PR을 올렸습니다 — ALLOWED_DISPATCH_ACTOR를 ALLOWED_DISPATCH_TARGETS와 동일하게 쉼표 구분 목록으로 파싱합니다. 의미는 보존됩니다(actor·sender가 같은 목록 항목과 일치해야 하고, 빈 목록은 아무것도 허용하지 않으며, 단일 값 변수는 그대로 동작).

변수는 손대지 않았습니다. 어떤 신원을 목록에 올릴지는 인가 결정이라 소유자 몫입니다. #1932는 그 결정을 내렸을 때 게이트가 받아들일 수 있게 하는 것뿐입니다.

수정 후 필요한 소유자 조치는 하나입니다:

gh variable set OPENCODE_REPOSITORY_DISPATCH_ACTOR --repo ContextualWisdomLab/.github \
  --body 'github-actions[bot],opencode-agent[bot]'

검증: 확장 계약 테스트가 수정 전 게이트에서는 실패(음성 대조군), 2890 passed / coverage 100% / interrogate 100%. 이 파일의 100~140행을 건드리는 열린 PR 없음(7개 전수 확인).

[seonghobae]

Wardnet adds a fresh exact downstream acceptance specimen after the earlier runner queue cleared.

ContextualWisdomLab/wardnet#155 remains Ready/mergeable at exact unchanged head f74ff25a321dfb1d7109719e2a1fc77e47dc4898 on protected main@5829a0f08d78de464dd24393ce5d0f25fba9d126. Wardnet-owned exact-head lanes are terminal GREEN: CI 33904633002, Fuzz 33904632999, Security Scan 33904633208, and SAST Semgrep 33904633082 all succeeded.

Required OpenCode run 33904630655 has now fully materialized, so the old coverage-evidence queue specimen is superseded. Bootstrap, cancellation guard, exact-head admission, coverage-source-tree, and coverage-evidence all completed SUCCESS. The sole failing job is opencode-review 101281544719.

That job acquired a real Ubuntu 24.04 runner, verified the live open/Ready PR and exact head, loaded the trusted receipt gate, found no current-head substantive receipt, obtained OIDC and the repository-scoped app token, and successfully POSTed event_type=opencode-review to ContextualWisdomLab/.github/dispatches with exact repository/PR/base/head/run identity. Four seconds later the fail-closed verifier found no APPROVED or CHANGES_REQUESTED review from opencode-agent on the same SHA and terminated with:

No APPROVED or CHANGES_REQUESTED from opencode-agent on the current head. The dispatch workflow will rerun this failed job after publishing an authenticated exact-head verdict.

So for this current specimen the consumer-side required workflow and runner are healthy through dispatch; the missing artifact is specifically the authenticated downstream verdict. Branch-side reruns or source churn are non-causal.

GREEN acceptance from Wardnet: repair the dispatcher identity contract without breaking the scheduler dispatcher, then on unchanged #155@f74ff25a... allow the repository_dispatch handler to bind the exact payload, execute the substantive current-head review, publish its authenticated receipt/review, and rerun only the failed required opencode-review job to terminal success. Preserve the already-green coverage and repository/security evidence; do not synthesize approval or use predecessor/model-fallback evidence.

[seonghobae]

#1932 범위를 소비 워크플로 셋 전부로 넓혔습니다(d44aa07d). 다른 세션이 짚은 대로 같은 변수를 codeql-scan-dispatch.yml:155와 pr-review-fix-scheduler.yml:156도 읽고 있었고, 하나만 고치면 그 둘은 계속 거부합니다. 세 게이트가 동일한 쉼표 목록 파싱을 쓰고, 각각 계약 테스트가 확장돼 있으며, 셋 다 수정 전 게이트에서는 실패합니다(음성 대조군). 2891 passed / 100% / 100%. 변수는 여전히 미변경입니다.