CodeQL dispatch terminal status publication remains unproven across repositories

현재 상태 — 2026-09-07

원래 actor allowlist 불일치는 복구됐다. Live OPENCODE_REPOSITORY_DISPATCH_ACTOR는 github-actions[bot]과 opencode-agent[bot]을 허용하며, canary run 34069437294는 actor validation을 통과한 뒤 queue 동안 변경된 live head 불일치에서 fail-closed했다.

Issue는 완료되지 않았다. 아직 다음 두 증거가 필요하다.

동일 저장소에서 실제 scan/SARIF upload 뒤 base/head/language/workflow/run-bound terminal receipt가 게시되는 unchanged-head canary.
cross-repository commit-status publication의 HTTP 403 수리와 unchanged-head terminal proof. 실패 증거는 runs 34017996201, 34018021069이다.

.github#1902@4b025af481f3a4fb0bdb4d400a7e055066a496a2는 stale-base terminal reuse를 차단하는 receipt contract를 추가했지만, publication credential 403을 우회하거나 해결한 것으로 간주하지 않는다.

최초 incident 기록

요약

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건이 있는 것도 같은 이야기입니다 — 그 건들은 신원이 일치하는데도 실패했으므로 별개의 원인이 최소 하나 더 있습니다(대상 허용 목록, 또는 이후 스텝).

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

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

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

opencode-agent[bot]이 의도된 신원이라면 → OPENCODE_REPOSITORY_DISPATCH_ACTOR를 그 값으로 갱신. 한 줄이지만 인가 허용 목록이라 자가 승인하지 않았습니다.
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)"'

같은 근본 원인을 #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"로 되어 있는데 그건 과한 표현이라 그쪽에 정정 코멘트를 달았습니다.

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

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

위에서 제가 제시한 선택지 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]로 교체하면 방향만 뒤집혀 스케줄러 디스패치가 막힙니다.

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

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

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 수정이 진단 도구를 겸합니다.

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

다른 세션이 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의 진단 도구를 겸합니다.

원인 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의 진단 도구를 겸합니다.

원인 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개 전수 확인).

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.

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

fix(dispatch): parse the trusted-dispatcher allowlist identically in …

Additional current consumer evidence: ContextualWisdomLab/ConceptWeave#35@a31ae0c2df920f2794f7ddb456795b04797ab472 dispatched central CodeQL run 33961083940 as opencode-agent[bot]. The run finally acquired ubuntu-24.04 and completed at 2026-09-05T13:28:49Z, but died earlier at the independent SUPPLIED_MATRIX sequence-to-env template defect tracked by #1926, so the authorization gate was still not reached. Central main now contains #1932's multi-identity parser (6f8c51d7389c22ebaf294fe8fe9ef495257883c0), but #1932 explicitly does not change OPENCODE_REPOSITORY_DISPATCH_ACTOR. Therefore this ConceptWeave specimen provides a concrete next validation target after #1926 merges: the dispatcher identity reaching the gate will be opencode-agent[bot]. I am not changing the authorization variable from the consumer repo.

Wardnet owner-path handoff after #1932/#1926

The live Wardnet execution contract makes this a central control-plane repair, not a user-choice blocker. The owner plane should decide and execute the least-widening reversible authorization repair from live evidence.

Fresh evidence:

fix(dispatch): parse the trusted-dispatcher allowlist identically in all three consumers (#1929) #1932 is merged (6f8c51d7389c22ebaf294fe8fe9ef495257883c0) and all three consumers can now parse a comma-separated trusted-dispatcher list while still requiring actor == sender for one listed identity.
fix(codeql): serialise the dispatched scan matrix with toJSON #1926 is merged (3f88e13af9dcde4b9da6958c02a78ce3b5c85800), so CodeQL's array-valued matrix no longer dies in the env: binding before authorization.
Wardnet has unchanged exact-head specimens with repository-owned deterministic gates already GREEN. I have triggered one causal retry of their previously failed CodeQL compatibility jobs rather than churning branch source: Enable central OpenCode required workflow path #77 d386d6f57e0c8de3e4839d6c61b593e41f9d7e20, ⚡ Bolt: [성능 개선] REST API 병렬 호출 최적화 #93 4775abc66e5350bdbf07ccefca74c10ddb03701a, fix: use PR base SHA for manual Strix targets #135 fb24394308ccdc835cce344b7e945f5537e99756, and [codex] Bound scheduler review dispatches #155 f74ff25a321dfb1d7109719e2a1fc77e47dc4898.

Given the already-proven two trusted dispatcher paths (github-actions[bot] scheduler path and opencode-agent[bot] app-token path), the minimal current owner-plane acceptance is to express both identities in OPENCODE_REPOSITORY_DISPATCH_ACTOR, not replace one with the other. Keep the same-identity actor/sender check, exact repository/PR/head binding, and fail-closed behavior for unlisted identities.

GREEN: after the live variable is reconciled, an unchanged Wardnet specimen must pass the repository_dispatch authorization stage and publish an authenticated exact-head CodeQL/OpenCode verdict; only the failed consumer job should be rerun. If it then fails on base-SHA drift, hand that distinct structural failure to #1931 rather than broadening this allowlist or touching Wardnet source.

Wardnet consumer handoff after the source-side parser repair: .github#1932 is now merged to protected main (6f8c51d7389c22ebaf294fe8fe9ef495257883c0) and deliberately supports the same comma-separated trusted-dispatcher allowlist in opencode-review-dispatch, codeql-scan-dispatch, and the review-fix scheduler. .github#1926 is also merged (3f88e13af9dcde4b9da6958c02a78ce3b5c85800), so the remaining authorization setting is no longer a Wardnet/user product decision.

The live architecture already establishes two intended trusted senders: the OpenCode GitHub App path emits opencode-agent[bot], while the scheduler path emits github-actions[bot]. Replacing one with the other would knowingly break the second path; the now-merged #1932 grammar exists specifically to represent both without weakening the actor==sender invariant. Owner RED is the still-single-valued setting plus exact-head dispatch failures. Owner GREEN is the least-privilege settings reconciliation to the exact two identities github-actions[bot],opencode-agent[bot], followed by authenticated current-head canaries through both dispatch paths and CodeQL dispatch, with unlisted/mismatched actor-sender negatives still rejected. Do not make leaf repositories rerun repeatedly before that settings convergence is verified.

Status after #1932 (6f8c51d7, list parsing merged) — the variable is still the single value, and every dispatch since is dying on it. Counted independently by host 1 and host 2 with server-side filters (actions/workflows/<file>/runs?status=…&created=>…&per_page=1 → total_count), 2026-09-05 ~16:50Z:

workflow	window	failure	cancelled
`codeql-scan-dispatch.yml`	since `#1926` merged 13:57:04Z	71	0
`codeql-scan-dispatch.yml`	since 15:00Z (after `#1932` landed)	8	—
`opencode-review-dispatch.yml`	since 13:57:04Z	18	—

Newest CodeQL failure, run 33974047812 (15:11:42Z, repository_dispatch, actor opencode-agent[bot]): job validate-dispatch fails at step Bind workflow inputs to live organization pull request metadata with authorization rejected actor=opencode-agent[bot] sender=opencode-agent[bot] because both must match one configured scheduler identity; the CodeQL dispatch scan matrix job is skipped. That is the gate #1932 widened, doing exactly what it should with a one-entry list — and it means #1926's toJSON fix has not executed once since it merged; its behavioural proof is blocked here, not pending. Host 2's probe run 33969658525 (15:07Z) was rejected with the same text.

OPENCODE_REPOSITORY_DISPATCH_ACTOR reads github-actions[bot], last updated 2026-07-16T01:02:39Z. The one-line change from the issue body is unchanged and remains the owner's decision:

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

Until it is set, no PR in the organization can obtain an OpenCode verdict or a dispatched CodeQL scan regardless of queue health (#1937 is confirmed working; the queue is draining), so this is now the sole remaining blocker on the review path.

Status 2026-09-06: the workflow side is done; the only remaining action is the variable's value.

#1932 (6f8c51d7, merged 2026-09-05 13:35Z) made all three consumers parse OPENCODE_REPOSITORY_DISPATCH_ACTOR as a comma-separated allowlist (IFS=',' read -r -a allowed_dispatch_actors).
#1926 (merged 13:57Z) fixed the env: template error that had prevented codeql-scan-dispatch's validate step from ever running. 10 of 10 completed runs since now execute the script and fail at the allowlist check:

##[error]repository_dispatch authorization rejected actor=opencode-agent[bot] sender=opencode-agent[bot]
         because both must match one configured scheduler identity.

The variable itself is unchanged since 2026-07-16:

repos/ContextualWisdomLab/.github/actions/variables/OPENCODE_REPOSITORY_DISPATCH_ACTOR
  value = github-actions[bot]

So the list is parsed but has one entry, and the dispatcher's identity is not in it. codeql-scan-dispatch, opencode-review-dispatch, and pr-review-fix-scheduler are all blocked on exactly this.

Remaining action (repository admin, authorization boundary — not performed by me): set the variable to github-actions[bot],opencode-agent[bot] (or to opencode-agent[bot] alone if the github-actions[bot] dispatcher is retired). Keeping both is the conservative choice while the 11 github-actions[bot] failures noted on #1927 are still unexplained — those passed authorization and died later, so they will persist after the variable change and are the next thing to look at once dispatches flow.

Verification after the change: one repository_dispatch should show step 3 passing the authorization block and reaching the matrix/metadata validation for the first time.

Correction to my previous comment: the allowlist needs to cover three identities, not two. I had recommended github-actions[bot],opencode-agent[bot]. With that value, pr-review-fix-scheduler would still be rejected.

Every dispatching identity actually observed, last 100 runs per workflow (triggering_actor.login, grouped):

workflow	dispatched by
`opencode-review-dispatch.yml`	`opencode-agent[bot]` 92 · `github-actions[bot]` 8
`codeql-scan-dispatch.yml`	`opencode-agent[bot]` 100
`pr-review-fix-scheduler.yml`	`seonghobae` 100

The third row is the standalone repository_dispatch path, sent from pr-review-merge-scheduler.yml with PR_REVIEW_MERGE_TOKEN — a user-account token, so the dispatch arrives as the user, not as an app or github-actions[bot]. The earlier comment on this thread about "two dispatchers of opencode-review" pointed at exactly this and I did not follow it through.

This makes the remaining step a real authorization decision, not a mechanical append. Listing an app (opencode-agent[bot]) grants that app's installation. Listing a user account grants anything holding that user's tokens. The owner has at least three coherent options:

github-actions[bot],opencode-agent[bot],seonghobae — restores all three paths as they dispatch today; widest.
github-actions[bot],opencode-agent[bot] plus migrating pr-review-merge-scheduler.yml's review-fix dispatch to the app token — keeps the allowlist bot-only; needs one workflow change.
opencode-agent[bot] alone plus the same migration — narrowest; retires the legacy github-actions[bot] path (8 of the last 100 opencode-review-dispatch runs).

Not performed by me. Verification after whichever lands: one dispatch on each of the three workflows should pass step 3's authorization block.

Fresh ConceptWeave consumer specimen after the earlier queue wait: central OpenCode owner run 33977685099 for ContextualWisdomLab/ConceptWeave#35@a31ae0c2df920f2794f7ddb456795b04797ab472 is no longer queued. It acquired a real ubuntu-24.04 runner at 2026-09-05T18:32:33Z and completed failure four seconds later.

Job validate-pr-metadata (101337170669) completed app-token exchange successfully, then failed exactly at Bind workflow inputs to live organization pull request metadata; all downstream coverage-source-tree, coverage-evidence, and opencode-review jobs were skipped. Run actor and triggering actor are opencode-agent[bot]. ConceptWeave #35's live base/head are still main@f4f440dd58c77d7cd90dff8a1eb2eeb9a9940425 / a31ae0c2df920f2794f7ddb456795b04797ab472, so this specimen does not introduce a head/base drift explanation.

Given the already-recorded owner evidence on this issue that OPENCODE_REPOSITORY_DISPATCH_ACTOR is still the single value github-actions[bot], and the current workflow checks actor/sender allowlisting before target/live-PR metadata, this is a current post-#1932 ConceptWeave acceptance specimen for the unresolved authorization decision rather than a runner/token/leaf-source failure. I am not changing the central variable or broadening the allowlist from the consumer repository, and I am not replaying this unchanged failed owner run.

Fresh unchanged-head CodeQL terminal-publication canary — `j-planner#2`

Consumer PR: docs: define J플래너 public and licensing baseline j-planner#2
Exact head: 040a97f235f6d7e5eec7d696c7560c87a6cc7608
Exact base: gh-pages@ec030872a0762af8af54d359c88e4c90239e05e4
Consumer run: https://github.com/ContextualWisdomLab/j-planner/actions/runs/36234848958
Failing compatibility job: 108400768211 (actions)
Dispatch coordinator job: 108448280654

Boundary trace

Head checkout, language detection and changed-path classification succeeded.
The compatibility job read no authenticated codeql-dispatch/actions terminal status and no matching completed central dispatch job, emitted VERDICT_STATE=pending, and failed closed at 2026-09-26T17:08:51Z.
The later coordinator obtained GitHub OIDC, exchanged the repository-scoped app token, bound repository/PR/base/head/run/job/language, and successfully POSTed event_type=codeql-scan at 2026-09-26T23:21:22Z.
Fresh commit-status read still contains only successful Devin Review and CodeRabbit contexts; no codeql-dispatch/actions context exists.
Security Scan and SAST on the same head are terminal success, and there is no repository-source CodeQL finding in the available consumer log.

This is an exact controlled canary for the still-open owner acceptance gap: dispatch transport succeeds, but terminal cross-repository status publication and automatic exact-job settlement remain unproven. The leaf stays fail-closed; no rerun, dummy commit, workflow copy, or gate weakening was performed.

Fresh same-repository acceptance canary from foundation PR #2385:

target: ContextualWisdomLab/.github#2385@8e1aba9ce1d52acb36f095da32511da06958733f, protected base main@e6334e229581a918e2f22de18733b76fa65d7e71
required CodeQL run: 36233219805
compatibility python 108403723721 and actions 108403723725: terminal FAILURE after Read current-head CodeQL dispatch verdict succeeded; both enforce steps received DISPATCH_OUTCOME=success, VERDICT_STATE=pending
coordinator 108465173387: later acquired a runner and completed the exact repository_dispatch successfully
fresh exact-head commit-status read: no authenticated codeql-dispatch/python or codeql-dispatch/actions terminal context exists

The PR is now Draft/Proposed. This specimen isolates the remaining owner lifecycle gap after successful transport: the canonical producer has not published/settled a terminal language verdict onto the exact required shards. Runtime Quality, Security Scan, SAST Semgrep, and Python Security are GREEN, so the available evidence does not establish a source/SARIF defect. No manual rerun, synthetic status, no-op wake, bypass, or merge was used.

A new protected-main prerequisite was reproduced and repaired in Draft PR #2532 (25af103312a0b837dd55ff19aefcdfb7954b54ab): Python 3.14 exposed unclosed file-like HTTPError responses in both authenticated GitHub REST clients after fail-closed redirect refusal. Exact protected main@37b10243... RED was 8 failed, 26 passed; the repair gives 34 passed for that contract and preserves no-second-request/no-bearer-forwarding behavior. #2040 must adopt the protected merge before regenerating terminal-status evidence; stale predecessor reruns are not acceptance.

Fresh exact-head handoff specimen:

Target: ContextualWisdomLab/Orgmetra#448@8f3cc0d7fd217cbc7f3b70431286110bbce71f47
Target CodeQL run: 36275869718
Shards: actions job 108800170144, python job 108800170151
Both read DISPATCH_OUTCOME=success and VERDICT_STATE=pending, then failed with CodeQL scan dispatched. The dispatch workflow will rerun this exact failed CodeQL job after publishing its terminal verdict.
The target run remains terminal failure rather than a proven terminal exact-head verdict handoff.

The Orgmetra PR remains Draft and now links this canonical owner incident. No leaf rerun, no-op commit, predecessor evidence transfer, or success claim was used.

Fresh exact-head terminal-receipt specimen — 2026-09-30T12:52Z

Target: ContextualWisdomLab/.github#2532
Exact head: 9d3ec75d6fbca20a6ac56de37408997fcafb01ea
Required CodeQL run: 36682527016, attempt 2

Both compatibility shards failed at the same authenticated-receipt boundary:

actions job 109836593136
python job 109836593228

Observed facts:

live PR/head/base/merge-source validation passed far enough to construct the exact v2 receipt identity;
expected context was codeql-dispatch/<language>/<live_base_sha>;
expected description was cwl1;h=9d3ec75d...;w=codeql-scan-dispatch;r=36682527016;s=<live_merge_sha>;
no matching trusted commit status was present;
no completed repository-dispatch producer matching the exact title/run/source tuple was found;
because this was RUN_ATTEMPT=2, both jobs correctly failed closed with: Exact CodeQL job was rerun without an authenticated terminal verdict;
the dispatch step later reported success, but the current commit-status inventory still contains only Devin Review and CodeRabbit—no CodeQL dispatch receipt.

This is not evidence that the scan passed or failed, and it does not yet distinguish a still-queued/cancelled handler from a completed handler whose status publication/settlement failed. The complete producer run/job/artifact identity is still required before choosing a source repair. No manual rerun, synthetic status, permission broadening, or stale predecessor transfer was performed.

The merged #2405 complete-proof boundary is behaving correctly: incomplete producer evidence remains RED rather than false GREEN. #1929 remains open for the producer publication/settlement completion path.

새로운 unchanged-head 소비자 증거입니다. ContextualWisdomLab/learning-record-store#1 exact head e916fa0f8214ff3e43e2a6f54a0773e95a0fd488, required CodeQL run 33889519102 (2026-09-30).

Detect CodeQL languages와 Dispatch current-head CodeQL scan은 성공했습니다.
CodeQL compatibility analysis (python) job 109848222111과 (actions) job 109848222250은 attempt 3에서 모두 실패했습니다.
두 로그의 최초 실패 경계: Exact CodeQL job was rerun without an authenticated terminal verdict; GHAS identity and preserved SARIF are required for authenticated terminal proof.
후속 enforcement는 DISPATCH_OUTCOME=failure, 빈 VERDICT_STATE를 보고했습니다.
같은 exact head의 Quality 33889519233, Security 33889519453, Semgrep 33889519344은 성공했습니다. 따라서 이 표본은 learning-record-store 소스 결함 또는 CodeQL 취약점 결과가 아니라, dispatch 후 authenticated terminal receipt 부재입니다.

PR #1은 Draft/open으로 유지했고 CodeQL 실패를 성공으로 승격하거나 no-op commit/rerun으로 우회하지 않았습니다. #1929의 cross-repository terminal publication 및 unchanged-head proof acceptance가 충족되기 전에는 병합 근거가 아닙니다.

Fresh unchanged-head canary from ContextualWisdomLab/ThreadWeave#44 (2026-09-30 UTC) confirms the terminal publication/wake gap remains reachable. Exact head afa5378ec807fc69d6a394215b428e7f6367f120; CodeQL PR run 36735357962. Detect job 109955495217 succeeded. Both compatibility jobs failed only at Release runner or enforce current-head CodeQL verdict: python 109955683373, actions 109955683651. The fan-in Dispatch current-head CodeQL scan job 109956035636 completed success, but after the run became terminal no compatibility job had been rerun and no terminal current-head verdict was visible to the caller. Peer exact-head repository gates are clean: CI 36735357918 success (Python 3.10–3.14 + package), SAST 36735358065 success, Security 36735358071 success. This is not a ThreadWeave source finding; keep ThreadWeave#44 unmerged until an authenticated exact-head terminal CodeQL result exists.

새 unchanged-head CodeQL terminal-publication RCA (2026-10-01): ContextualWisdomLab/learning-record-store#1@e916fa0f8214ff3e43e2a6f54a0773e95a0fd488의 CodeQL run 33889519102에서 python job 109848222111과 actions job 109848222250은 dispatch 뒤 세 번째 attempt까지 Exact CodeQL job was rerun without an authenticated terminal verdict; GHAS identity and preserved SARIF are required로 fail-closed했습니다. 같은 exact head의 Quality 33889519233, SAST 33889519344, Security 33889519453은 success이므로 leaf source failure로 축소할 수 없습니다. 재실행만 반복하지 않았고, GHAS identity/SARIF-bound terminal receipt 수리가 canonical owner에서 필요합니다.

새 unchanged-head 소비자 증거입니다 (2026-10-01 KST). ContextualWisdomLab/cwl-telemetry#1 exact head ab81a4d4d7b0754ec1064c2862a2fe27b69338b5, required CodeQL run 36756390363.

Detect CodeQL languages job 110027600118은 성공했습니다.
CodeQL compatibility analysis (python) job 110027944286과 (actions) job 110027944330은 attempt 1에서 모두 실패했습니다.
두 shard의 최초 실패 경계는 DISPATCH_OUTCOME=success, VERDICT_STATE=pending이며, exact error는 CodeQL scan dispatched. The dispatch workflow will rerun this exact failed CodeQL job after publishing its terminal verdict.입니다.
Dispatch current-head CodeQL scan job 110028879560은 성공했습니다. live PR/base/head 재검증, OIDC, repo-scoped app token, language matrix와 required job ID를 포함한 repository_dispatch(codeql-scan-v2) 전송까지 완료됐습니다.
그러나 caller run이 terminal failure가 된 뒤에도 authenticated terminal status 게시와 exact-job 재개가 관측되지 않았습니다.
같은 exact head의 Telemetry contract 36756390393, SAST Semgrep 36756390392, Security Scan 36756390284은 성공했습니다.

따라서 이 표본의 실패 경계는 leaf 소스/SARIF finding이 아니라 canonical .github terminal publication/continuation 경로입니다. manual rerun, no-op push, synthetic status, 권한 확대, 실패 Check 우회는 하지 않았습니다. acceptance는 unchanged head에 authenticated terminal verdict가 게시되고 동일 compatibility job이 그 증거를 소비해 재개되는 것입니다.

Fresh downstream evidence from ContextualWisdomLab/cwl-telemetry PR #1 at exact head 88d3fda62bd35a8808c2eaab0ad5cc590b705e5f:

CodeQL PR run 36824849304 was entirely skipped because the head synchronize event occurred while Draft.
After test-first leaf repairs, exact-head Telemetry contract, Security Scan, and Semgrep succeeded and the PR was restored to Ready for review admission.
The Ready transition did not schedule a successor CodeQL run, so this exact head still has no authenticated CodeQL verdict.

No manual rerun, empty commit, permission broadening, synthetic status, or gate bypass was used. This remains a canonical workflow trigger/terminal-evidence gap; the leaf PR stays unmerged pending a real exact-head result.

Fresh cross-repository terminal-publication evidence routed from #2537 comment 5938121109 to this canonical owner.

Four current-head caller runs share the same causal boundary: repository dispatch succeeds, then the Python/Actions compatibility jobs fail at Release runner or enforce current-head CodeQL verdict because no authenticated terminal verdict settles.

.github#2261@5f71d5f0…: CodeQL PR 36873538750; dispatch job 110407534397 GREEN; enforcement jobs 110407190249 / 110407190617 RED.
.github#2550@4743e7f8…: CodeQL PR 36872425316; dispatch 110403499053 GREEN; enforcement 110403398483 / 110403398648 RED.
fast-mlsirm#2070@d42f64a0…: CodeQL PR 36892998059; dispatch 110474201970 GREEN; enforcement 110473891881 / 110473891844 RED.
fast-mlsirm#2314@0538c1ec…: CodeQL PR 36882464526; dispatch 110437854458 GREEN; enforcement 110437628981 / 110437629028 RED.

Standalone security/CodeQL evidence elsewhere does not satisfy the exact caller contract. This is continuation/terminal-receipt evidence, not a leaf source finding or permission for source-neutral reruns, synthetic status, or bypass. All four consumers remain Draft/merge HOLD.

Fresh same-head terminal-publication canary from .github #2554 at exact 23fd3dd74181b816049bac4037ca4d696fcd551a:

Ready-event CodeQL PR run 36926646328 detected actions and python successfully.
Dispatch job 110585778515 completed successfully after live head/base/source validation, OIDC acquisition, repository-scoped App token exchange, and codeql-scan-v2 publication bound to required run 36926646328.
Compatibility jobs 110585680344 (actions) and 110585681209 (python) both failed with exact DISPATCH_OUTCOME=success, VERDICT_STATE=pending: CodeQL scan dispatched. The dispatch workflow will rerun this exact failed CodeQL job after publishing its terminal verdict.
No authenticated terminal verdict or exact-job continuation followed. On the same head, Security Scan 36926646476, SAST 36926646343, and Python Security 36926646401 succeeded.

The PR is now Draft / merge HOLD. This is a canonical terminal-publication/continuation failure, not a sidecar-source vulnerability and not authority for manual rerun, no-op commit, synthetic status, or gate bypass.

Fresh unchanged-head terminal-publication evidence from clearfolio#662 at exact b1905cfb4b6500eb048f9829648e75096ed5e666:

CodeQL PR 36926554506 detected python, javascript-typescript, actions, and java-kotlin.
All four compatibility jobs failed only at Release runner or enforce current-head CodeQL verdict; Python job 110588179436 records DISPATCH_OUTCOME=success, VERDICT_STATE=pending.
Coordinator job 110591410665 revalidated the live exact head/base/source, obtained OIDC and the repository-scoped App token, bound the exact required job IDs, and successfully submitted one codeql-scan-v2 request.
No authenticated terminal receipt or exact-job continuation followed.
Same-head CI 36926553965, Security 36926553916, SAST 36926554001, and fuzz 36926553970 are terminal GREEN.

This is another canonical terminal-publication/continuation failure, not a leaf source or SARIF finding. The consumer remains Ready for review admission but unmerged. No manual rerun, no-op commit, synthetic status, state toggle, bypass, or predecessor evidence transfer was used.

Current-head Ready admission gap — Korean writing skills #4 (2026-10-02 KST)

Actual ordinary repair e59806d7abf3c7f13478e5997b4d0cbdb20f3ba6 fixes 13 full-PR whitespace errors and preserves original evaluation hashes. Remote push and a single Ready transition are verified; no lifecycle cycling or no-op commit was used.

The synchronize workflows captured Draft before Ready and no Ready-event successor appeared in the freshly enumerated consumer run list. Exact-head CodeQL run 36966902575 is wholly SKIPPED, not GREEN. Strix 36966901142 and OpenCode 36966901145 also skipped actual model execution; Noema 36966901172 success is not an approval. SAST 36966902465 and Security Scan 36966902494 are terminal SUCCESS but cannot substitute for the missing scans/review.

The canonical central merge-scheduler handler's actual protected-main source requires OPENCODE_REPOSITORY_DISPATCH_TARGETS membership. A direct read confirms ContextualWisdomLab/korean-writing-skills is absent. I did not alter that authorization allowlist or send a request guaranteed to fail it. Please identify the authorized central operator and restore normal current-head required-workflow admission/CodeQL evidence via the existing owner path; do not reuse predecessor producer 36930131832, synthesize a status, or manually rerun a compatibility shard without its bound terminal receipt.

Independent approval and Strix scan can proceed independently: new supported, exact-target central requests were accepted and actually admitted as Noema 36967223479 and Strix 36967224264. Both have started real steps against this exact head, but no final verdict/approval is claimed yet. No duplicate requests will be submitted while these are active.

PR #4 remains OPEN/Ready/BLOCKED/REVIEW_REQUIRED, Issue #2 remains OPEN, and no skill is installed. The two skill packages are locally verified and byte-identical to the reviewed predecessor; Mac/S1/S2 transfer dry-runs succeeded. Normal merge and actual merged-main deployment remain the completion condition.

Navigation Menu

Repository navigation

CodeQL dispatch terminal status publication remains unproven across repositories #1929

현재 상태 — 2026-09-07

최초 incident 기록

요약

증거

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

주장하지 않는 것

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

재현

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

두 개의 디스패처

실측 근거

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

확정과 추정 구분

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

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

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

이 이슈의 범위

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

Wardnet owner-path handoff after #1932/#1926

422 remaining items

Fresh unchanged-head CodeQL terminal-publication canary — `j-planner#2`

Boundary trace

Fresh exact-head terminal-receipt specimen — 2026-09-30T12:52Z

Current-head Ready admission gap — Korean writing skills #4 (2026-10-02 KST)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

CodeQL dispatch terminal status publication remains unproven across repositories #1929

Description

현재 상태 — 2026-09-07

최초 incident 기록

요약

증거

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

주장하지 않는 것

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

재현

Activity

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

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

두 개의 디스패처

실측 근거

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

확정과 추정 구분

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

seonghobae commented on Sep 5, 2026

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

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

이 이슈의 범위

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

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

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

Wardnet owner-path handoff after #1932/#1926

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

seonghobae commented on Sep 5, 2026

422 remaining items

seonghobae commented on Sep 27, 2026

Fresh unchanged-head CodeQL terminal-publication canary — j-planner#2

Boundary trace

seonghobae commented on Sep 27, 2026

seonghobae commented on Sep 30, 2026

seonghobae commented on Sep 30, 2026

seonghobae commented on Sep 30, 2026

Fresh exact-head terminal-receipt specimen — 2026-09-30T12:52Z

seonghobae commented on Sep 30, 2026

seonghobae commented on Sep 30, 2026

seonghobae commented on Sep 30, 2026

seonghobae commented on Sep 30, 2026

seonghobae commented on Oct 1, 2026

seonghobae commented on Oct 1, 2026

seonghobae commented on Oct 1, 2026

seonghobae commented on Oct 1, 2026

seonghobae commented on Oct 2, 2026

Current-head Ready admission gap — Korean writing skills #4 (2026-10-02 KST)

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Fresh unchanged-head CodeQL terminal-publication canary — `j-planner#2`