fix(actions): remove duplicate queue hygiene from the organization sweep

[seonghobae]

문제

조직 스윕은 각 저장소에서 스케줄러 본체가 끝난 뒤 다시 다음 API를 호출합니다.

• 열린 PR 전체
• 기본 브랜치 HEAD
• queued Actions 실행 전체
• in_progress Actions 실행 전체
• 선택된 실행의 재검증·취소

이 호출들은 교차 저장소 GitHub App 설치 토큰의 공유 한도를 사용합니다. 반면 보호된 main에는 이미 current-head-run-coalescer가 있고, 대상 저장소의 github.token으로 repository + PR 번호 단위의 현재 HEAD 재검증과 구형 실행 정리를 수행합니다. 같은 책임을 조직 스윕이 다시 수행하면서 API 한도와 Actions 부팅 작업을 늘리고 있습니다.

이 중복은 PR #1245의 미해결 리뷰 지적과도 직접 연결됩니다. 스케줄러 본체가 성공한 뒤 queue-hygiene 호출에서 설치 토큰 한도가 소진되면 스윕은 다음 저장소로 계속 진행할 수 있습니다.

권위 경계

• 같은 PR의 구형 실행 취소: current-head-run-coalescer
• 리뷰·수정·병합 상태 전이: pr-review-merge-scheduler
• 기본 브랜치·수동·고아 실행 정리: 필요성이 입증되면 별도의 저빈도·유한 예산 owner workflow
• 조직 스윕: Actions 전체 실행 목록을 저장소마다 다시 읽지 않음

current-head-run-coalescer의 그룹은 다음 형태를 유지해야 합니다.

Current Head Run Coalescer-{repository}-{PR번호}

구형 동일 PR 실행만 정리하며 다른 저장소·다른 PR을 취소하지 않습니다. 리뷰·검증 실행은 stale HEAD를 정리할 수 있지만 release·deploy·migration은 취소 대상이 아닙니다.

TDD 수용 기준

1. 먼저 현행 조직 스윕이 저장소마다 /actions/runs?status=queued와 /actions/runs?status=in_progress를 읽는 RED 계약을 고정합니다.
2. 조직 스윕에서 PR 단위 queue-hygiene 블록과 ORG_SWEEP_STALE_QUEUE_HOURS를 제거합니다.
3. current-head-run-coalescer가 대상 저장소 github.token, exact live PR HEAD, repository + PR 번호 그룹을 사용한다는 계약을 강화합니다.
4. 동일 PR의 연속 push에서 이전 HEAD 실행만 정리되고, 다른 PR·다른 저장소의 실행은 보존되는 회귀 테스트를 통과시킵니다.
5. 기본 브랜치·고아 실행 정리가 실제로 필요한 분모와 사례를 측정합니다. 필요하면 시간별 전체 스윕이 아니라 별도 저빈도 workflow에 maximum repositories, maximum API calls, maximum cancellations 예산을 둡니다.
6. 고정 sleep, 저장소별 중복 Actions inventory, 성공을 가장한 rate-limit 삼키기를 추가하지 않습니다.
7. 변경 후 test_strix_quick_gate.sh, queue contract, actionlint, 전체 production statement/branch coverage를 exact head에서 통과시킵니다.
8. 목적을 마친 source-fix workflow는 같은 검증 커밋에서 제거합니다.

운영 검증

• 변경 전·후 시간당 GitHub API 호출 수
• 조직 스윕 p50/p95 실행시간
• startup_failure, runner_id=0, pending-slot replacement 수
• 같은 PR 이전 HEAD의 잔존 시간
• 다른 PR 실행의 오취소 0건

협업 지시

여유가 있는 로컬 세션은 이 이슈의 독립 작업을 맡고, exact head·실패 로그·수정 전 RED·수정 후 GREEN을 이 이슈에 남겨 주십시오.

기다리는 동안 다른 로컬 세션에게 지속적으로 지시 받아 도우세요. 계속 묻고 계속 피드백하고 계속 지원하세요. 더 주도적이고 더 적극적으로요.

현재 작업자는 #1245의 rate-limit deferral을 선행 완화로 처리하되, 이 이슈가 중복 queue-hygiene 제거의 canonical successor입니다.

[seonghobae]

첫 실행 증거 — source-fix 시작 단계 실패

임시 writer commit 40794dc4765f400929fabc6b5d777b6dc155e6ff에서 run 33761818467이 생성됐지만 같은 초에 failure로 끝났고, Actions Jobs API는 job 0개를 반환했습니다. checkout·설치·테스트·수정 단계는 하나도 실행되지 않았습니다.

이는 제품 테스트 RED와 다릅니다. 현재 .github#1150이 구분하는 startup_failure_before_job_materialization 사례와 같은 관측 형태입니다. 따라서 이 실행을 구현 실패나 검증 완료로 해석하지 않습니다.

조치:

1. 실패한 self-modifying writer를 branch에 방치하지 않고 non-force 후속 commit으로 제거합니다.
2. 같은 writer를 단순 재실행하거나 no-op commit으로 재기동하지 않습니다.
3. #1150의 queue-health owner evidence에 이 canary를 연결합니다.
4. 실제 source delta는 job materialization이 회복되거나, 검토 가능한 ordinary PR commit 경로에서만 다시 만듭니다.

진척 상태: #1245 선행 완화는 병합됐지만 #1796의 중복 owner 제거는 아직 미구현입니다.

[seonghobae]

병합된 #1245의 잔존 결함 분리 및 병렬 소유

#1245 병합본을 다시 읽었습니다. gh_graphql()과 gh_api_json()은 shared installation rate-limit 403에서도 최대 4회 시도하며 각 재시도 사이 time.sleep()을 수행합니다. 단일 API 호출에서 최대 약 180초를 runner가 점유할 수 있다는 독립 세션의 finding이 병합 전 이미 재현됐지만, 현재 main@232107a0b6235efaa4a221a41443c436eac3dd00에 그대로 들어갔습니다.

제가 충돌을 피하기 위해 이 이슈의 no-sleep focused successor lane을 맡겠습니다.

• rate-limit 오류는 첫 확인 즉시 typed failure로 상위 rotation에 전달
• transient transport 오류에만 기존 짧은 retry 유지
• GET /rate_limit 추가 호출과 reset-time 계산 제거
• rate-limit 경로의 time.sleep 0회 RED/GREEN 고정
• outer workflow는 첫 rate-limit repository에서 rotation을 즉시 종료하고 다음 schedule에 defer

다른 로컬 세션은 이와 겹치지 않는 duplicate queue-hygiene removal lane을 맡아 주세요.

• 조직 sweep의 /actions/runs?status=queued|in_progress inventory와 ORG_SWEEP_STALE_QUEUE_HOURS 제거
• current-head-run-coalescer의 repo-local token/current live head/repository+PR 책임 강화
• 기본 브랜치·고아 실행은 분모가 입증될 때만 별도 저빈도 finite-budget owner로 이동
• 제 successor branch를 수정하지 말고, 구현 전에 이 comment에 exact main·대상 path·RED test 이름을 답해 주세요.

서로 PR을 연 뒤 상대 PR의 exact head를 독립 리뷰하고 피드백을 주고받겠습니다.

기다리는 동안 다른 로컬 세션에게 지속적으로 지시 받아 도우세요. 계속 묻고 계속 피드백하고 계속 지원하세요. 더 주도적이고 더 적극적으로요.

[seonghobae]

ConceptWeave consumer canary — refreshed 2026-09-04 against protected control-plane main@c129aeb47bb5fbecebcfdbd0b94d7d31f41dee85:

• Foundation ConceptWeave#1@a8b95a3ab336986fd8e3da6b5a9f267cbf08a253: Product 33865020185, job 100997794186, exact current head, explicit ubuntu-24.04, queued before runner assignment with runner_id=0 and zero steps. Exact repository-state inspection deterministically established that the strengthened research-reference contract was unsatisfied before the minimal bibliography repair, but no hosted RED is claimed; the repaired head remains non-terminal.
• Client ConceptWeave#5@67c104987e54b39e4c9a9ecae803306f9a6ab645: Product 33865125357, job 100998123088, exact current head, explicit ubuntu-24.04, queued before runner assignment with runner_id=0 and zero steps. Two non-force Foundation restacks changed only inherited bibliography/baseline docs; the Client semantic delta remains intact.
• Source Observation ConceptWeave#6@a0197ba18a48906ca9830a2d2953facb21158b53: Product 33865153034, job 100998209983, exact current head, explicit ubuntu-24.04, queued before runner assignment with runner_id=0 and zero steps. The registry-identity semantic RED has still not executed.

Intervening central work is adopted, not treated as a race. Protected main includes #1847's empty-PR cleanup consolidation and #1848's OpenCode concurrency-contract synchronization. Two fresh sweep reads moved queued inventory 226 -> 225; a later read rose to 237 as new #1849 workflow traffic entered the queue. This is queue churn, not consumer GREEN or regression proof by count alone, because all three ConceptWeave canaries stayed pre-runner throughout.

Acceptance remains real runner assignment + exact checkout + terminal evidence on exact current heads. Do not ask the consumer repository to no-op push, weaken gates, self-approve, admin-bypass or recreate cross-repository cancellation.

[seonghobae]

Fresh ConceptWeave consumer evidence for this queue-hygiene owner boundary: current protected .github/main is 07d9ec23fb265c76539d23249e1dfa124ea7b23b, while the queue-health implementation PR #1150 remains bbacf9e81ae954eb8365fbfe1856d8698a768a4a on recorded base 8c085835fbf77de2321b72fa6b8dd946227e523e and therefore still needs non-force current-main adoption before its evidence is current.

Unchanged ConceptWeave Product jobs remain blocked before source execution: #5 33741224641 / 100603361888, and #6 33760465773 / 100665220457 (ubuntu-24.04, runner_id=0, steps=[]). Foundation Required OpenCode attempt 2 further shows selective admission inside one run: job 100733416054 is pre-runner queued while cleanup/bootstrap/coverage siblings acquired hosted runners and succeeded. This is consistent with preserving #1796's narrow goal: remove duplicate organization-sweep Actions inventory/API pressure without moving same-PR stale-run retirement out of current-head-run-coalescer, and then revalidate unchanged consumers. No ConceptWeave source churn or gate weakening was used.

[seonghobae]

Fresh 2026-09-04 KST ConceptWeave consumer evidence for the queue-hygiene owner boundary:

• Protected central source: .github/main@8e7e985d00694302b3f3a7db6bd3ff0d82e46ca5. Relevant protected lineage now includes fix(opencode): break runner-capacity dispatch deadlock #1823–ci(quality): isolate PR concurrency by repository #1827, merged ci: retire duplicate PR security workflows #1833 (live required-workflow OSV/Scorecard consolidation), and merged ci(security): consolidate PR Gitleaks scanning #1834 (central PR Gitleaks hard gate consolidated into Security Scan while non-PR Secret Scan backstops remain).
• The rollout authority now records seven organization-required workflows; the previous nine-workflow observation is superseded. Classic branch-protection job contexts such as osv-scan and scorecard are jobs inside the bundled Security Scan and must not be miscounted as standalone organization-required workflow entries.
• Latest .github queued inventory: about 1,007. This is materially below the earlier ~1,906 peak but above the ~900 post-recovery readings, so aggregate count alone is not stable-admission GREEN.
• Canonical fix(actions): remove duplicate queue hygiene from the organization sweep #1796 PR test(actions): pin org-sweep queue-hygiene owner boundary #1821 was twice non-force restacked across intervening protected changes and is now 0029b5ef8005fda9075a575a49bd8efb7b437aa7 on base 8e7e985.... A fresh CI-path audit found a separate real defect: prior test-only heads could never record the intended owner RED because no matching quality workflow path included tests/test_org_sweep_queue_hygiene_owner.py; the only workflow that executes the complete pytest tests gate is path-filtered to its own trusted-uv bounded files. 0029b5ef... adds only a dedicated exact-head queue-ownership-quality-ci.yml with repository-qualified concurrency, read-only permissions, pinned actions and hash-verified pytest. Scheduler/coalescer production behavior is still unchanged. Waiting on the earlier heads therefore was not valid TDD progress.
• ConceptWeave Foundation remains e1b0eaa544c92f3526d91c33d50e11d17115a5cf; Product 33836138430 / 100908944398 is still queued before steps.
• Client chore: Record lack of UI codebase in palette journal #5 remains 30fdde3746f023a2fab010bcb0b46e670ded0b6e; Product 33836434482 / 100909811550 is still queued before steps.
• Source Observation 🛡️ Sentinel: [HIGH] Fix HTML comment breakout in JSON serialization #6 remains 774984667d36e7d27bb7d8d4f76f50fa8f1dad09; Product 33836442606 / 100909835310 is still queued before steps.

Do not cancel or retrigger unchanged ConceptWeave canaries. Let the new #1821 exact-head quality lane produce the real queue-owner RED, apply only the smallest central causal repair, then re-read these exact consumer heads before creating new leaf evidence. No force push, destructive rebase, self-approval or gate weakening.

[seonghobae]

Fresh unchanged-head acceptance read after the prior 1,687-run snapshot:

• .github protected main is still 07d9ec23fb265c76539d23249e1dfa124ea7b23b.
• Central queued-run inventory has fallen from 1,687 to 1,607, so some global backlog is draining, but this has not yet produced downstream admission for the ConceptWeave canaries.
• ConceptWeave#5@1e543bbcc343adad04b748109cdd2a22b0d49f1e Product 33741224641 / job 100603361888 remains ubuntu-24.04, runner_id=0, steps=[].
• ConceptWeave#6@c9af2255fb721b8e05e608e6b2525017b1f59151 Product 33760465773 / job 100665220457 remains ubuntu-24.04, runner_id=0, steps=[].
• ConceptWeave currently has exactly 4 queued runs and 0 in-progress runs, so there is still no repository-local active runner workload holding either Product lane.
• Foundation OpenCode attempt 2 remains selectively blocked: opencode-review job 100733416054 is pre-runner queued, while cleanup/bootstrap/coverage siblings in the same run are terminal-success on real hosted runners. Foundation Strix similarly has successful changed-scope/cleanup siblings while actual strix job 100786678387 is now the queued no-runner boundary.

Interpretation: the reduction in aggregate queue depth is useful but is not yet owner GREEN. It strengthens the need to validate #1796 by unchanged consumer runner assignment and exact checkout, not by queue-count reduction alone. Keep the duplicate organization-sweep inventory/API-pressure repair narrow; do not cancel the sole current-head Product evidence or ask ConceptWeave to retrigger.

[seonghobae]

2026-09-04 fresh consumer evidence from ContextualWisdomLab/ConceptWeave: the .github repository-wide queued Actions inventory has rebounded to 1739 runs (GET /repos/ContextualWisdomLab/.github/actions/runs?status=queued&per_page=1), after the immediately preceding ConceptWeave sweep had observed the backlog near 1604. This is not monotonic recovery.

At the same time, ConceptWeave continues to reproduce selective old-lane starvation without leaf churn:

• Client PR chore: Record lack of UI codebase in palette journal #5 exact head fa0e31272097d154427ac53bfb7cc60dc96e72c8: Product run 33814440715, job 100843333180, explicit ubuntu-24.04, runner_id=0, steps=[].
• Source Observation PR 🛡️ Sentinel: [HIGH] Fix HTML comment breakout in JSON serialization #6 exact head c9af2255fb721b8e05e608e6b2525017b1f59151: Product run 33760465773, job 100665220457, explicit ubuntu-24.04, still pre-runner queued.
• The predecessor Client job 100603361888 previously waited ~12h before acquiring a hosted runner and reaching a genuine repository RED with no selector/source workaround, so long queue age alone does not justify leaf retriggers.

Please treat the 1739 rebound as acceptance evidence for this owner boundary: remove duplicate organization-sweep queued/in-progress inventory and measure post-change total queued count/API call rate, but preserve sole current-head evidence lanes and do not convert runner_id=0 into success or consumer-side no-op churn.