fix(codeql): wake required jobs with the exchanged target app token

[seonghobae]

Current authority

Status: OPEN / Draft / Proposed / do not merge.

• protected base: main@e6334e229581a918e2f22de18733b76fa65d7e71
• exact head: bd039185ddf8df88480971cdd3b69c38f4558609
• purpose: keep the CodeQL wake/dispatch path on current-user head-derived GitHub App authentication rather than mutable or user-token shortcuts

Exact-head acceptance

Fresh exact-head hosted evidence is mixed and therefore not GREEN:

• SAST Semgrep 35706035099: SUCCESS
• Security Scan 35706035091: SUCCESS
• Python Security 35706035103: FAILURE. Detect Python and Bandit are GREEN; pip-audit (Python dependency audit) job 106725528592 fails at Run pip-audit (hard gate on any known vulnerability). This is a real dependency-audit gate failure and must not be suppressed or relabeled as scheduler noise. The active shared dependency owner chore(deps): bump anyio from 4.14.0 to 4.14.2 #2278 remains separate and is not assumed to be the causal fix without exact audit-log/CVE evidence.
• CodeQL PR 35706035119: FAILURE. Python receiver 106725681922 and Actions receiver 106725681960 each successfully read the current-head dispatch verdict and then failed at Release runner or enforce current-head CodeQL verdict; the later coordinator 106770747682 obtained a runner and Dispatch current-head CodeQL scan completed SUCCESS. The earlier failed receivers did not reconcile afterward.

The CodeQL sequence is a same-head reproduction of the terminal publication/reconciliation ordering defect already tracked by #1929. A later successful coordinator is not retroactive terminal acceptance for receivers that already failed.

Landing order

This PR remains a foundation prerequisite, not a consumer-side place to synthesize required statuses or rerun leaf jobs blindly. Repair the CodeQL publication/reconciliation owner, resolve the dependency-audit failure through its canonical dependency owner once causality is proved, then reacquire all exact-head required checks and an independent current-head review before normal protected merge.

No force push, destructive rebase, self-approval, review dismissal, gate weakening, source-neutral wake commit, synthetic status, or predecessor-GREEN transfer is authorized.

[seonghobae]

Exact-head owner repair at 652764a37fc8af032f03cbe75da84ca88aee96bb (tree evidence follows from the published branch):

• RED e70094b3d85b2fdb54c0d24ef9a1fe0299e09237: production-path tests cover ContextualWisdomLab/repo..name and ContextualWisdomLab/repository., and a direct probe of the predecessor guard reproduced acceptance of both.
• GREEN 90445aa5494fabf2dbc4d685271348132d39981e: the real validate-dispatch shell block extracts the repository component and rejects embedded .. or a trailing . before any gh api call.
• Contract supplement 652764a37fc8af032f03cbe75da84ca88aee96bb: explicitly preserves ContextualWisdomLab/.github and ContextualWisdomLab/repo.name.
• Scope: the RED child changed exactly one test path (+27/-0); the GREEN child changed exactly one workflow path (+3/-0). No scheduler, credential, payload, or settlement semantics changed.
• Local exact-blob verification: Python compile PASS for the contract module; Bash syntax PASS for the extracted production validation block; four-way guard probe rejects the two hostile slugs and accepts the two canonical dotted slugs.

Fresh exact-head hosted Checks and a qualifying independent approval remain mandatory; predecessor evidence does not transfer. @coderabbitai review

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

repo="ContextualWisdomLab/.github"
pr="2040"
head="652764a37fc8af032f03cbe75da84ca88aee96bb"

echo '== Pull request metadata =='
gh pr view "$pr" --repo "$repo" \
  --json headRefOid,baseRefOid,isDraft,mergeable,reviewDecision,statusCheckRollup \
  --jq '{headRefOid,baseRefOid,isDraft,mergeable,reviewDecision,checks:[.statusCheckRollup[]|{name,status,conclusion,workflowName}]}'

echo '== Repair commits =='
git log --format='%H %P %s' -3 "$head"

echo '== Exact repair range =='
git diff --check e70094b3d85b2fdb54c0d24ef9a1fe0299e09237.."$head"
git diff --stat e70094b3d85b2fdb54c0d24ef9a1fe0299e09237.."$head"
git diff --name-status e70094b3d85b2fdb54c0d24ef9a1fe0299e09237.."$head"
git diff --no-ext-diff --unified=25 e70094b3d85b2fdb54c0d24ef9a1fe0299e09237.."$head" -- \
  .github/workflows/codeql-scan-dispatch.yml \
  tests/test_codeql_scan_dispatch_workflow_contract.py

echo '== Validation block =='
rg -n -C 30 -e 'TARGET_REPOSITORY' -e 'target outside ContextualWisdomLab' .github/workflows/codeql-scan-dispatch.yml

echo '== Relevant production-path contract assertions =='
rg -n -C 15 -i -e 'repo\.\.name' -e 'repository\.' -e '\.github' -e 'repo\.name' \
  tests/test_codeql_scan_dispatch_workflow_contract.py

echo '== Reviews =='
gh api "repos/$repo/pulls/$pr/reviews?per_page=100" --paginate \
  --jq '.[] | {user:.user.login,state,commit_id,submitted_at}'

Length of output: 78383

---

@seonghobae The current head 652764a37fc8af032f03cbe75da84ca88aee96bb addresses the repository-admission P1.

The validation block now rejects a repository component that contains .. or ends in .. It performs these checks before its first gh api call.

The contract verifies both hostile inputs fail before API access:

• ContextualWisdomLab/repo..name
• ContextualWisdomLab/repository.

The contract also preserves these valid inputs:

• ContextualWisdomLab/.github
• ContextualWisdomLab/repo.name

The repair range changes only the handler workflow and its contract file. I found no new issue in this repair scope.

I cannot approve the PR. It remains Draft, all current hosted checks are queued, and GitHub reports CHANGES_REQUESTED. A qualifying current-head approval and terminal successful checks are still required.

---

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

You are interacting with an AI system.

[seonghobae]

Terminal Trusted uv failure 35452353616 is not a uv-materializer defect. The focused materializer suite is GREEN (108 tests, 100% statement/branch coverage), but the subsequent repository-wide pytest tests -q collection imports scripts/ci/noema_review_document.py, which requires defusedxml. This job installs only requirements-opencode-review-ci-hashes.txt; the canonical Noema document lock already owns defusedxml==0.7.1 in requirements-noema-document-ci-hashes.txt. The causal fix is to make this repository-wide quality job install both existing hash-locked requirement surfaces (and cache both), not to weaken coverage, skip Noema tests, or duplicate an unpinned dependency. I will first bind this dependency closure as a workflow-contract RED, then minimally repair the workflow.

[seonghobae]

Naruon consumer fresh-read found an owner-overlap repair finding on current #2040 exact 7901ca565fb93a9e869cd4136476384ac3a07bdf.

The two commits after 652764a... are valid RED→GREEN for the Trusted uv repository-wide dependency closure (82a4e2a... test, 7901ca5... workflow), but that contract is already canonically owned by #1911. #1911 explicitly owns trusted-uv-materializer-quality-ci.yml full-suite dependency closure and already carries the same required invariant: trigger/cache/install requirements-noema-document-ci-hashes.txt alongside the OpenCode lock under --require-hashes.

Do not drop the new #2040 evidence, but do not let #2040 become a second Trusted-uv owner either. Before #2040 can be accepted, reconcile this overlap ordinary/non-force through the canonical #1911 path: first bring #1911 onto current protected main@e6334e229581a918e2f22de18733b76fa65d7e71 without losing its broader full-suite contracts, then adopt/adapt the accepted owner delta into #2040 only if #2040 still needs it as a prerequisite. If the canonical owner completely carries the two new #2040 commits, reduce the #2040 effective diff accordingly while preserving ancestry/evidence. No force push, Close-as-superseded, hand-edited generated lock/hash material, or receipt transfer.

Separately, the current #2040 body correctly treats Runtime Quality as a Strix command-level RCA lane; do not mix the Trusted-uv ownership repair with speculative Strix/path-policy changes.

[seonghobae]

Fresh Naruon consumer audit confirms that this branch's Trusted-uv dependency-closure delta overlaps canonical owner #1911. Current #1911 is dfeadc7adfb02d73e166104f2987f14fbf7fe82e; it owns trusted-uv-materializer-quality-ci.yml as the repository-wide/full-suite quality gate. This PR remains the broader CodeQL scheduler/credential/no-restamp/runtime-quality lane, but it should not independently own the same Trusted-uv workflow repair.

Please converge losslessly through #1911: preserve #2040's distinct CodeQL/scheduler/runtime-quality contracts, ordinary/non-force adopt the accepted/current #1911 owner result once #1911 is reconciled to protected main@e6334e229581a918e2f22de18733b76fa65d7e71, and remove any duplicate Trusted-uv ownership from the effective child delta. Do not close either PR merely because of overlap, and do not transfer predecessor checks/reviews.

Current central execution pressure is still abnormal (fresh observation: 223 queued / 1 in progress, with the sole in-progress run a long-lived Strix job on protected main), so queued exact-head evidence is not a reason for a no-op wake commit or blind rerun.

[seonghobae]

Fresh exact-head acceptance update (2026-09-20 KST): current head remains bd039185ddf8df88480971cdd3b69c38f4558609. The Trusted-uv convergence with canonical #1911 is still structurally valid: fresh compare #1911@c965664a... -> #2040@bd039185... is ahead-only with merge base exactly c965664a..., and neither Trusted-uv workflow nor its contract test appears in the remaining delta. However, hosted acceptance is not GREEN: SAST 35484975926, Security 35484975879, Python Security 35484975909, Trusted uv 35484975956, and Runtime Quality 35484975898 are terminal CANCELLED; CodeQL PR 35484975910 remains pending. Treat this as control-plane/queue evidence, not a reason to mutate source. Keep Draft; no source-neutral wake commit, blind rerun, predecessor receipt transfer, or reopening of parallel Trusted-uv ownership.

[seonghobae]

Lifecycle authority repair: live PR metadata had drifted to Ready (draft=false) while this PR's own current-authority body says OPEN / Draft / Proposed and its exact bd039185ddf8df88480971cdd3b69c38f4558609 lacks accepted hosted evidence/independent approval. I returned #2040 to Draft without changing its head or source. This matters to downstream LineageWeave #1039/#899 CodeQL settlement: the handler/scheduler owner must not present as review/merge-admitted while its current exact evidence is cancelled/nonterminal and queue lifecycle ownership remains #712. No source-neutral commit, rerun, review dismissal, or gate weakening was used.

[seonghobae]

Current exact-head CodeQL evidence has advanced beyond the PR body snapshot. Producer 35754606100 settled the exact required run successfully (settle exact required run job 106924536948 SUCCESS), and required run 35706035119 is now attempt 2. The Actions receiver 106963403700 consumes authenticated terminal evidence and passes. Python receiver 106963403949 consumes authenticated terminal evidence and fails because the producer itself is terminal RED: Python dispatch job 106870962325 preserved SARIF and failed the Medium+ gate on py/incomplete-url-substring-sanitization in tests/test_organization_commercial_readiness_loop_receipt_contract.py.

That source delta had previously existed on the #2106 lineage (298e6c14...) but did not survive its final protected merge. New canonical successor #2351 exact 657d10402d4d502249423a85faa1f953542cd719 restores only the lost exact-set membership assertion on current protected main. Keep this PR Draft: #2351 must normally integrate, then this branch must ordinary/non-force reconcile and reacquire exact-head CodeQL plus Python Security evidence. The existing pip-audit failure remains a separate dependency-owner prerequisite. No blind rerun or wake commit is warranted.

[seonghobae]

Fresh current-generation evidence from .github#2352@f1a8dc813e6dba4e4905bf3e1b770b6d44344944 preserves this PR's wake/reconciliation ownership boundary but corrects the previous queued-state assumption.

Required CodeQL run 35805450471 is now terminal FAILURE. Python receiver 107036649617 and Actions receiver 107036649620 both completed their first-attempt current-head verdict read with pending and failed closed before coordinator 107076139478 later ran at 09:13Z and successfully dispatched the producer. Exact producer run 35841640640 is bound to #2352's (repo, PR, base, head, required run) identity and its validate-dispatch job 107117846461 is still queued at the latest read.

So there is not yet producer SARIF for this specimen and no basis to call #2352's CodeQL RED a source finding. If 35841640640 is clean and the exact failed receivers remain failed, this is a direct current-main canary for the publication/wake/reconciliation owner. If it yields a real SARIF finding, route that finding to its canonical source owner instead. No leaf source-neutral commit, broad rerun, synthetic status, or gate weakening is justified.

[seonghobae]

Read-only handoff to this lane, which owns the CodeQL dispatch/verdict files. Routed here by path ownership: this PR touches .github/workflows/codeql-pr.yml, .github/workflows/codeql-scan-dispatch.yml, docs/doctoring/codeql-rerun-pre-runner-cancellation-recovery.md and tests/test_codeql_pr_rerun_recovery_contract.py, i.e. the requeue semantics themselves. No file was edited by us; nothing was re-run.

Case: late-life-anxiety-reanalysis#257 at 706a81e5a6f88ad74544ab9cf89d4da2b9e6a44d. CodeQL compatibility analysis (python) — run 35808205558 / job 107046179304 — exited 1 with the dispatch reported as succeeded but the verdict still pending, and a later dispatch job 107084906428 succeeded while the old shard stayed failed.

Decisive fact, from two single GETs (no polling): job 107084906428 is run_id=35808205558, run_attempt=1, conclusion=success, started 2026-09-23T09:58:57Z; run 35808205558 is run_attempt=1, conclusion=failure. No attempt 2 was ever created, so the requeue never fired.

That also removes a reading trap: rerun-failed-jobs would create attempt 2 with a new job id for the python shard, so attempt-1 job 107046179304 would read failure forever even after a successful requeue. Here it is not a stale-id artifact — the run never advanced past attempt 1.

Two more points worth stating plainly:

• Job 107084906428 is the coordinator (Dispatch current-head CodeQL scan). Its success means the repository_dispatch POST was accepted, nothing more. It is neither a verdict nor a requeue.
• On attempt 1 the shard structurally always reads pending: it reads statuses before the coordinator (needs: analyze-head) has dispatched anything, so pending → exit 1 (codeql-pr.yml:288-300) is the designed path, and the requeue is the only thing that can replace that shard's conclusion. With RUN_ATTEMPT != 1 there is no pending fallback (:264-267).

Where the mechanisms live, for whoever picks this up:

• Verdict publication: codeql-scan-dispatch.yml:632-712, step Publish CodeQL dispatch status. It posts a commit status on the exact HEAD_SHA, context codeql-dispatch/<language> for legacy-v1 (:683-685) or codeql-dispatch/<language>/<BASE_SHA> for v2 (:687-689), and is blocked unless Preserve CodeQL SARIF evidence succeeded (:652-655). The publish helper accepts the status only if creator.login is opencode-agent/opencode-agent[bot] (or github-token for .github itself).
• A context mismatch was ruled out: codeql-pr.yml:463 sends event_type: "codeql-scan" → legacy-v1 → context codeql-dispatch/<lang>, which is what both readers match (codeql-pr.yml:205 in the shard, :399 in the coordinator).
• Requeue: the settle job, codeql-scan-dispatch.yml:768-1060, POST repos/<target>/actions/runs/<REQUIRED_RUN_ID>/rerun-failed-jobs (mode failed, :1006, :1023). It is gated on the required shard being completed with conclusion == "failure" and a unique id/run_id/head_sha/name match (:944-965), on no unrelated failed jobs in that run outside the language map (:967-974), on exactly one handler job with a terminal gate step and a non-expired SARIF artifact for the current attempt (:983-1004), and on a rerun budget (:931-934).

Suggested first check: the triggered CodeQL Scan Dispatch late-life-anxiety-reanalysis#257@706a81e5…/bcea8006…/35808205558 run — its settle-job conclusion and any ::error::codeql_settlement phase=… line. Source-visible blockers, in likelihood order for this run: SARIF upload not success (which kills publication and settlement), the unrelated-failed-jobs guard, job-identity ambiguity, rerun budget, or every wake token failing.

Not verified without a hosted run: whether a codeql-dispatch/python status was published on 706a81e5… at all, and if so whether its creator.login satisfied the trusted-creator filter. That needs the target repo's statuses for that SHA plus the dispatch run's logs.

The separate late-life#257 defect — the central Pingora policy rejecting a tracked DOCX as invalid UTF-8 — is fixed in #2355 and does not belong to this lane.