fix(ci): protect current review evidence from stale runs

[seonghobae]

현재 검증 — main 통합 후 원격 반영

• 현재 head: 623891f2e74af44ff244b7d9e3ed397e7440a6c8; tree: d77c91b7c7b8ecd829c5abbca1a6877ca7af8cfb.
• 일반 merge의 두 부모는 이전 PR head 7c7e611280902c381dc5773cd525473b04810254와 실제 main f250638827f8252b0d9e5cb2601f4d333f96162f입니다. push 직전 로컬 head·원격 head·추적 파일의 변경 없음을 확인하고 이력 재작성 없이 반영했습니다. 미추적 uv.lock은 보존하고 커밋에서 제외했습니다.
• main의 #1922는 두 CI 전용 fixture 실패와 기존 품질 workflow의 scheduler 경로·검사 선택 누락을 고쳤습니다. 이 부모는 사용자가 허용한 Actions chicken-and-egg 예외로 병합됐습니다. 정상 보호 병합이나 hosted Checks 통과로 기록하지 않습니다. 이번 #1899에는 그 예외를 적용하지 않았으며 아직 병합되지 않았습니다.
• 현재 head의 일반 전체 검사: 2,960 passed, 1 skipped, 21 subtests passed, 119.91초, exit 0.
• 같은 head의 GITHUB_ACTIONS=true 전체 검사: 2,960 passed, 1 skipped, 21 subtests passed, 117.42초, exit 0. 기존 review-repair 4개 모듈은 **658 statements / 222 branches / missing 0 / partial 0 / 100%**이며 관련 5개 파일의 docstring도 100%입니다.
• 같은 head의 5개 workflow는 ShellCheck를 포함한 전체 actionlint에서 exit 0, 출력 없음입니다. 검증에는 앞서 격리 빌드한 공식 upstream 011a6d15e749bb3f2d771eed9c7aa0e7e3e10ee7을 사용했습니다. 시스템 설치나 프로젝트 의존성 변경은 없습니다.
• 전체 검증 로그에서 Timeout/Fatal/Warn/Denied 출력을 확인하지 못했습니다. skip 한 건은 이 Mac에 검토된 LLVM 19 Linux 도구가 없어서 실행하지 못한 경로입니다. 통과에 포함하지 않았습니다. 기존 프로젝트 환경 결과이며 새 clean-lock 설치, 실제 Linux 도구 실행, hosted 보안 검사, 실제 재실행 취소 안전성 또는 적체 해소 완료를 입증하지 않습니다.
• 별도로 수행한 두 구형 Strix push 실행의 정상 취소 기록은 당시 실제 상태와 후속 성공 실행을 검증한 수동 조치입니다. 이 미병합 workflow 코드의 실행 효과로 계산하지 않습니다.
• 새 head의 hosted Checks와 독립 검토를 다시 확인해야 합니다. 이전 head의 승인·실패·검사는 이 head의 증거로 승계하지 않습니다. Project #1의 In Progress 상태를 유지하고, 전체 목표의 신규 완료 수는 올리지 않습니다.

실행 명령:

uv run pytest tests -q -ra
GITHUB_ACTIONS=true uv run python -m pytest -q -ra \
  --cov=scripts.ci.pr_review_conflict_scope \
  --cov=scripts.ci.pr_review_autofix_context \
  --cov=scripts.ci.zdr_policy \
  --cov=scripts.ci.contextual_orchestrator_review_policy \
  --cov-branch --cov-fail-under=100
uv run python -m interrogate --fail-under 100 \
  scripts/ci/pr_review_conflict_scope.py \
  scripts/ci/pr_review_autofix_context.py \
  scripts/ci/zdr_policy.py \
  scripts/ci/contextual_orchestrator_review_policy.py \
  scripts/ci/contextual_orchestrator_review_launcher.py

아래에는 이전 head에서 실제로 재현한 실패와 수정 이력을 보존했습니다. 과거의 미해결 표시는 해당 head 기준이며 위 통합 결과를 대신하지 않습니다.

변경 목적

G-02/G-03 후속 수정입니다. 오래된 Actions 실행을 재실행하면 최신 PR 실행과 같은 동시성 그룹에 들어가 최신 검증을 취소할 수 있었습니다. 작업 내부의 최신 HEAD 확인은 이 취소보다 늦어 충돌을 막지 못합니다.

Strix·Noema·Required OpenCode의 workflow 그룹, Strix 정리 job, 중앙 OpenCode 실행 job 등 5곳에서 두 번째 시도부터 rerun-<run_id> 그룹을 사용합니다. 첫 실행의 workflow/대상 저장소/PR별 중복 정리와 cancel-in-progress: true는 유지합니다. OpenCode 검토 결과 도착 후 rerun-failed-jobs로 재개하는 경로도 유지합니다.

job·의존성·권한·모델 설정·보안 예외를 추가하지 않았습니다. 필요한 스킬과 운영 절차를 정리한 문서 PR #1885와 분리된 실제 workflow 수정입니다.

실제 REST 응답에서는 오래된 실행의 head_sha가 그대로인데 pull_requests[].head.sha만 최신 값으로 바뀌는 사례도 확인했습니다. 같은 HEAD 중복 정리의 공통 판정 함수가 이런 연결 정보만으로 오래된 실행을 최신 증거로 인정하지 않도록 수정했습니다. 실행 환경의 GITHUB_SHA와 REST 실행 revision은 별개입니다. 실행 ID와 전체 SHA를 남긴 RCA에 읽기 전용 관측과 한계를 기록했습니다.

기존 Required OpenCode·Strix 정리 경로에는 갱신된 PR 연결 정보 때문에 오래된 실행을 최신 실행으로 잘못 보존하는 역방향 문제도 있었습니다. 목록 선택과 취소 직전 정확한 실행 조회에서 같은 jq 조건을 재사용합니다. 활성 상태·대상 PR·workflow·event·기록된 SHA를 확인하고, ID 불일치·잘못된 JSON·알 수 없는 상태나 revision이면 취소하지 않습니다. OpenCode의 현재 PR은 열림·비-Draft·동일 HEAD여야 합니다. Strix의 명시적인 종료/Draft 정리는 유지합니다. 성공 로그도 취소 완료가 아닌 요청 성공으로 고쳤습니다.

첫 branch push의 Strix 실행도 저장소와 전체 ref로 묶었습니다. 실제 main의 서로 다른 세 SHA 실행이 2026-09-05 08:28:26–08:45:01 UTC에 겹쳤고, 당시 식은 push마다 별도 run ID를 사용했습니다. 새 식은 PR 그룹과 재실행 격리를 유지하며, tag·schedule·manual·비-PR dispatch·누락 ref는 서로 분리합니다. 새 job·sleep·정리 API는 추가하지 않았습니다. 이는 새 workflow 버전의 향후 중복 예방이며 기존 실행의 취소나 60-job ceiling 해소 증거가 아닙니다.

이전 커밋 검증 — HEAD 7c7e611

검증 HEAD는 7c7e611280902c381dc5773cd525473b04810254입니다. 1d422702790a200224a76da401cb1fed085448bd에 현재 main 7fcada597d5b79bdb14445f24322b2c9f6ed4b19을 일반 merge했습니다. main에서 추가된 AGENTS.md·CLAUDE.md 지침을 보존했으며 이력을 재작성하지 않았습니다.

• 앞선 705개 집중 검사에 dispatch blob-pin 계약 두 건이 빠져 있었습니다. 실제 workflow blob은 fec6de078c2f206bcd82a99638d0b5e2867a05cb인데 테스트 상수가 이전 ade10b37c43d0f2b46490b2196c893244afc3d49를 유지해 2 failed를 재현했습니다. 현재 main에서는 이전 해시가 정확하므로 이 PR의 동반 갱신 누락입니다.
• 기존 상수 한 곳만 갱신하고 doctoring의 실행 명령에 두 계약 파일을 추가했습니다. assertion·독립 해시 검사는 유지했습니다. 수정 트리의 두 파일 검사는 31 passed, 1 skipped in 4.42s, exit 0입니다.
• 새 HEAD의 uv run pytest tests -q -ra: 2,953 passed, 1 skipped, 21 subtests passed in 171.12s, exit 0. 전체 로그에 Timeout/Fatal/Warn/Denied 신호가 없음을 별도로 확인했습니다. skip 한 건은 이 macOS에 고정 경로의 LLVM 19 도구가 없어 Linux 전용 허용 경로를 실행하지 못한 것으로, 통과에 포함하지 않았습니다.
• 같은 HEAD에서 GITHUB_ACTIONS=true로 doctoring의 16파일 집중 검사를 실행한 결과는 2 failed, 734 passed, 1 skipped in 72.04s, exit 1입니다. 따라서 이 PR은 CI clean이 아닙니다.
• 실패한 두 테스트는 test_inspect_pr_closes_empty_pull_request_even_if_the_comment_call_fails와 test_main_reconciles_the_durable_admission_gate_when_a_state_path_is_given입니다. 별도 clean worktree의 main 7fcada597d5b79bdb14445f24322b2c9f6ed4b19에서도 같은 두 실패를 재현했습니다. 하나는 가짜 run(args)의 누락된 키워드 인자이고 다른 하나는 실제 SHA 검증 경로로 들어간 합성 head 값입니다.
• 기존 근본 수정 test(scheduler): isolate remaining CI-only recovery calls #1922, exact head 64bf199b468ecf271819c7739e9ce109822268d0가 바로 이 두 fixture의 startup-recovery 경계를 격리합니다. 소스 diff를 확인했으며 #1899에서 복제하지 않았습니다. #1922의 보호 병합 이후 main을 승계하고 최종 HEAD에서 CI 환경 검사까지 다시 통과해야 합니다. 그 전에는 hosted Checks 대기와 별도로 이 재현 가능한 실패가 남습니다.
• 독립 로컬 검토는 해시 일치, 기존 assertion 유지, doctoring의 누락 검사 편입을 확인했습니다. GitHub 공식 승인이나 hosted 보안 검사를 대신하지 않습니다. 미추적 uv.lock은 보존하고 커밋에서 제외했습니다.

이전 커밋 검증 — HEAD 1d42270

• 일반 merge로 반영한 최신 main: a01ffc1edee2e5fc9c56e4351f90a0ce4a75e77b. 원래 작업 기준 6d7fbebec8aec31d88a30a36e71ca5b3925d241d에서 전진한 커밋을 이력 재작성 없이 승계한 뒤 다시 검사했습니다.
• 검증 HEAD: 1d422702790a200224a76da401cb1fed085448bd
• branch push 회귀는 수정 전 1 failed, 27 passed, 수정 뒤 28 passed였고, 명시적 manual/비-PR dispatch 사례를 더해 최종 30 passed입니다. 문자열 비교는 GitHub의 대소문자 무시 규칙을 따릅니다.
• 수정 전 실제 그룹 식 평가: 17 failed, 5 passed. 오래된 재실행이 최신 PR 그룹과 충돌하는 조건을 재현했습니다.
• 최신 main 승계 후 관련 14파일 테스트 705 passed in 45.36s, exit 0. 이전 base의 수정 트리에서는 681개가 통과했으며, 이 수치를 새 HEAD 결과로 옮겨 쓰지 않았습니다. 실행 명령은 doctoring 기록에 있습니다. 새 테스트는 실제 YAML 식을 제한된 표준 라이브러리 AST 해석기로 평가하며 eval이나 새 패키지를 쓰지 않습니다.
• 연결 정보 갱신 결함은 수정 전 6 failed로 재현했습니다. 앞선 51345839f78d269ecf192aa386f1679508581a32에서 취소 로직의 별도 3파일 테스트 57 passed, 문장·분기 커버리지 100%(252 statements, 118 branches)를 확인했습니다. 이 3파일 테스트는 최신 705개 실행에도 포함됐지만 coverage 명령은 새 HEAD에서 다시 실행하지 않았습니다. 다른 PR·저장소·base·진행 상태 보호도 유지합니다.
• 오래된 실행 정리의 역방향 문제는 실제 jq 테스트 2건 RED로 재현했습니다. 중간 수정에서 위험한 Strix 취소 4건 RED도 재현한 뒤 최종 응답 검증을 추가했습니다. 실제 셸 테스트는 완료된 실행·최신 HEAD·다른 PR·API 실패·누락/알 수 없는 상태·다른 실행 ID·배열·부분/잘못된 응답에서 cancel과 force-cancel이 모두 호출되지 않음을 검증합니다. 위 705개 결과에 포함됐으며, GitHub의 실제 취소 완료 증거는 아닙니다.
• 기존 Noema 정리 스크립트와 중앙 Strix/OpenCode 정리 테스트에 첫 실행·재실행 사례를 추가했습니다. OpenCode는 실제 Required OpenCode Review 호출이 OpenCode Review Dispatch 실행을 찾는 조합을 검증합니다.
• git diff --check 통과. 기본 actionlint 1.7.12는 외부 검사기 입력 전달 중 멈춰 통과로 계산하지 않았습니다. 원인이 수정된 공식 upstream 011a6d15e749bb3f2d771eed9c7aa0e7e3e10ee7을 격리 빌드해 확인했습니다. 같은 기존 진단 29건을 head/base에서 확인한 뒤, 불필요한 패턴·중복 redirect·파일 탐색을 정리하고 의도된 literal에만 명령 단위 annotation을 붙였습니다. 최신 변경을 포함한 네 workflow의 ShellCheck 포함 전체 actionlint: exit 0, 출력 없음. 시스템 설치·프로젝트 의존성·hosted gate 변경은 없습니다.
• 중간 lint 정리에서 주석이 여러 줄 printf를 끊은 실수는 메인 검토에서 발견해 커밋 전에 제거했습니다. 실제 본문 생성 함수를 Bash로 실행하는 테스트에서 ## Findings: command not found RED 후 GREEN을 확인했습니다. lint 통과와 실제 셸 실행 검증은 구분했습니다.
• 독립 로컬 검토의 테스트 호출 이름 지적을 수정했습니다. 로컬 검토는 GitHub의 공식 승인이나 hosted Checks를 대신하지 않습니다. 생성된 미추적 uv.lock은 커밋에서 제외했습니다.

남은 검증과 한계

격리된 오래된 재실행은 새 첫 실행이 직접 취소하지 못합니다. 기존 정리 경로가 runner를 확보한 뒤 회수합니다. 중앙 OpenCode는 scheduler가 dispatch 단계까지 도달해야 정리하므로 Strix 대기나 조기 반환 시 즉시 회수되지 않을 수 있습니다. 정리 API 요청을 검증한 테스트는 GitHub의 실제 completed/cancelled 상태를 입증하지 않습니다.

뒤늦게 도착한 첫 실행의 순서 역전은 별도 미해결 항목입니다. 이미 생성된 실행은 원래 workflow 버전을 재사용하므로, 보호 병합 뒤 새 버전으로 생성된 실행에서 오래된 PR 이벤트를 재실행하고 최신 실행이 보존되는지 확인해야 합니다.

hosted lint·보안 Checks, 최신 HEAD의 독립 승인, 정상 보호 병합과 실행 증거가 남았습니다. Admin 우회는 요청하지 않습니다. 이 로컬 수정으로 전체 41개 목표의 완료 수를 올리지 않습니다.

근거와 인계

GitHub 공식 concurrency 문서, context 문서, 재실행 문서를 확인했습니다. 구체적인 설정 결함 수정이므로 별도 논문 PDF는 추가하지 않았습니다.

담당: Codex, 2026-09-05 KST. 다음 담당자는 위 HEAD의 Checks·검토 스레드를 새로 확인하고, 보호 병합 이후 새 workflow 버전의 실제 재실행 보존 증거를 남겨야 합니다. 정리 작업 추가나 조직 전체 순회로 runner 포화 해결을 대신하지 않습니다.

Project #1의 기존 In Progress 항목을 계속 사용합니다. CLI의 read:project 권한이 없어 실제 Edge 브라우저로 이 PR의 프로젝트 필드를 확인했고 In Progress 상태를 재확인했습니다. 이전 회차의 Mac 잠금 제한은 이번 조회에서 해소됐습니다. Done 처리는 하지 않았습니다. PR #1885는 스킬·운영 절차 담당, 이 PR은 실행 취소 안전성의 구현 담당입니다. 전체 목표의 이번 신규 완료는 **0/41(0%p)**이며, 로컬 검증·PR 갱신을 실제 적체 해소 완료로 계산하지 않습니다.

[coderabbitai]

Warning

Review limit reached

Next included review available in 37 minutes.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Team

Run ID: ce29175c-d986-4990-ae57-4a6763b1638f

📥 Commits

Reviewing files that changed from the base of the PR and between fe827e1 and a60163b.

📒 Files selected for processing (17)

• .github/workflows/noema-review.yml
• .github/workflows/opencode-review-dispatch.yml
• .github/workflows/opencode-review.yml
• .github/workflows/strix.yml
• docs/doctoring/current-head-run-coalescing.md
• docs/doctoring/review-rerun-concurrency-isolation.md
• docs/product-technical-gap-baseline.md
• scripts/ci/current_head_run_coalescer.py
• tests/test_current_head_run_coalescer.py
• tests/test_current_head_run_coalescer_review_regressions.py
• tests/test_noema_review_gate.py
• tests/test_opencode_required_verdict_regression.py
• tests/test_opencode_workflow_shell_syntax.py
• tests/test_pr_review_autofix_nvidia_nim_contract.py
• tests/test_pr_review_merge_scheduler.py
• tests/test_required_workflow_queue_contract.py
• tests/test_review_rerun_concurrency.py

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[seonghobae]

구형 main 검증 2건의 종료 확인

2026-09-05 10:44 UTC에 primary가 일반 cancel API로 아래 두 실행만 정리했습니다. 취소 직전에 event=push, branch=main, path=.github/workflows/strix.yml, attempt=1, 원래 head와 active 상태를 다시 확인했습니다.

구형 run / head	실제 점유 job	확인한 종료
33928897846 / a9aeee8fc94ad6002a059b380b268590ce496ef0	101238385024	completed/cancelled, 10:44:40 UTC
33932271770 / 1b65dbc35e7183722ad77894e2d80b39993be90d	101245581186	completed/cancelled, 10:44:41 UTC

같은 workflow와 branch의 후속 33933530334는 b5efbc2762e472e4a380b0503b1f050f76fbb008에서 completed/success였습니다. GitHub compare API로 두 구형 head의 strict descendant(각 2·1 commits ahead, behind=0)임을 직접 확인했습니다. 이는 후속 실행의 GitHub 상태이며, 이 기록이 보안 보고서 내용을 별도로 인증한다는 뜻은 아닙니다.

단순히 현재 main의 조상이라는 이유만으로 취소하지 않았습니다. 같은 workflow의 더 새로운 실행을 추가 확인했으며, 최신 eligible Strix 33956092119의 c4a89b31a02caa1f1a5be1c36d54252cb8e57f8b 대기 상태를 보존했습니다. 후속 검증이 진행 중인 33938197561도 이번 수동 취소에서 제외했습니다.

새 workflow나 dispatch, force-cancel, ruleset 변경은 없었습니다. 현재 PR·배포·릴리스·이미지·마이그레이션 작업은 취소하지 않았습니다. Noema 33926849327은 취소하지 않았고, 후속 조회에서 자연 종료한 completed/failure를 발견해 별도 원인 조사로 넘겼습니다.

영구 수정은 이 PR의 branch-push concurrency 변경입니다. 수동 종료 2건은 그 미병합 수정의 효과나 조직 전체 60-job ceiling 해소를 입증하지 않습니다. #1922의 공통 CI 복구를 실제 main에서 받은 뒤 이 PR의 새 exact head를 다시 검증합니다.

[seonghobae]

I filed #1917 for the stale comment at opencode-review.yml:513-518, then found this PR already removes it. Verified against this PR's own diff rather than reporting from the issue:

@@ -511,14 +512,9 @@ jobs:
-    # bootstrap group is now `cancel-in-progress: false` (see its own comment):
-    # nothing is ever preempted there, by design, to structurally close the
-    # #1568 stale-cancels-fresh race regardless of arrival order. This job
+    # Native concurrency coalesces first attempts; this cleanup also reaches

That is the whole defect: the file has exactly one cancel-in-progress (:26, true), and false existed only inside the comment claiming it. The replacement describes what the job actually does. No separate PR is needed — please don't let #1917 cause a duplicate. I'll close it against this PR once it lands.

Two additions to consider while these two comment blocks are already open. Both are one sentence; neither changes behaviour.

1. The forward-looking instruction (@@ -511 @@ block). The real hazard in the old comment was never the wrong value — it was that it told a reader "nothing is ever preempted there, by design", i.e. that they need not defend against preemption themselves. The new text accurately describes this job, but a future author adding another cancellation path still has nothing telling them the obligation is theirs. The live-head revalidation in cancel-superseded-opencode-review-runs is a property of that job, not of the file. Suggested:

Any new cancellation path must revalidate the live head itself, immediately before selecting candidates and again before each cancel call; nothing at file scope provides that guarantee.

2. The expiry condition (@@ -17 @@ block). Measurements from 2026-09-05, across 537 cancelled jobs in 120 runs of 5 workflows: zero were cancelled after being assigned a runner. So cancel-in-progress: true currently costs no runner time. But the reason is the saturation itself — created_at→started_at is 1–2 hours right now (measured: 6814s and 9953s on two jobs that did run), while pushes to the same PR arrive every 10–30 minutes, so cancellation reliably beats runner assignment. If allocation gets fast relative to push cadence, assigned-then-cancelled becomes common and the cancellation does start burning runner minutes. Since draining the queue is the goal, that condition is expected to change. Suggested:

This is cheap because allocation currently lags push cadence (0/537 cancelled jobs had been assigned a runner, 2026-09-05); if allocation latency drops below push interval, re-measure before assuming cancellation is free.

Writing down what would make this wrong is what the removed comment lacked — it was not false when written, it just carried no condition, so nothing flagged it when the design changed underneath.

Separately — a cross-PR pairing worth knowing about. This PR implements rerun isolation in the group key:

+    github.run_attempt > 1 && format('rerun-{0}', github.run_id) ||

#1885 (codex/document-actions-event-admission, AGENTS.md-only) documents exactly that rule: "Use the PR number only when github.run_attempt == 1; isolate reruns with a rerun- prefix and github.run_id." They are the code and doc halves of one change and were, as far as I can tell, opened independently. Worth ordering so AGENTS.md does not describe a rule main has not adopted yet — merging this one first, or together, avoids that window.

🤖 Generated with Claude Code