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

[seonghobae]

Owner session: fast-mlsirm-commercialization

Outcome

Canonical combined successor for the central CodeQL producer/handler cycle, exact required-run recovery, strict head-envelope validation, and stacked-PR check admission.

Current authority after non-force reconciliation:

• protected central base: main@fb17ef556f94f673234aa557254ae52779e9a7b0;
• exact PR head: 85522306949bada2b5939608dc911f6374125f1b;
• exact tree: fe8ca79a4fd410e68eb790258820a511fa6cdc70;
• fresh compare: 150 ahead / 0 behind, merge base exactly protected main, 29 effective changed files;
• state: open, Draft / Proposed because current-head review identifies an unresolved protected-main bootstrap cycle; no merge authorization.

Root causes and repair retained

1. A handler superseded after initial validation cannot publish a status: publication requires the second live PR/base/head validation to succeed.
2. The unsafe head-only compatibility context is replaced with base-bound codeql-dispatch/<language>/<base_sha> receipts.
3. Publication requires exact SARIF preservation and authenticates the returned status creator.
4. Producer receipts bind exact base/head/run, protected workflow source/title, actor, successful validation/required jobs, gate, SARIF, artifact, and response creator.
5. One run-wide settlement owner revalidates live PR/base/head, exact required run/jobs, handler gates and unexpired artifacts before one run-level rerun mutation.
6. Same-ref forward base advancement restarts the exact required run; rewritten/divergent bases fail closed.
7. Raw nested pr_head schema/types and legacy scalar fields must agree.
8. The target App → PR_REVIEW_MERGE_TOKEN → OPENCODE_APPROVE_TOKEN → same-repository token fallback remains explicit and authenticated.
9. Direct evidence authenticates handler runtime source against protected .github/main, not target-PR synthetic ancestry.
10. Destructive-boundary active-run refresh uses the same host-scoped Actions credential selector as cancellation.
11. The stacked-PR security contract rejects both branches and branches-ignore filters.
12. failed dispatch keeps one top-level required_jobs authority compatible with the protected pre-cutover handler; only whole-attempt all uses the nested envelope.
13. The scheduler no longer manufactures same-tree commits for zero-job workflow startup failures or last-push approval; it reports the exact failed run IDs and waits for a real repair or independent approval on the unchanged head.

The branch continues to carry all valid predecessor delta from #1902, #2004, #2043 and #2044. Those predecessors are not treated as shipped merely because their delta is inherited here.

Protected-main reconciliation

Fresh review found predecessor 6706c231ab06a3c91c43fdb5b989cfcd79fff593 had diverged from current protected main by 144 ahead / 32 behind. The protected-side 32 commits affected eleven effective files and did not overlap this PR's 24 effective files. A concurrent central writer then performed the same ordinary merge-forward tree that had been independently prepared here:

• merge commit 3b2de64c2c4c95c56d2f5099a480a0825304d038;
• parents: predecessor 6706c231... and protected main@cb0872c9...;
• resulting tree eb8d6351193519afca23d448f70b9ab59f5eb5a4;
• branch update is ordinary/non-force; no valid proposal delta was discarded.

The independently prepared tree had the identical SHA eb8d635...; its ref update was correctly rejected as non-fast-forward after the concurrent merge landed first. The concurrent commit is therefore adopted rather than rewritten or force-replaced.

Verification boundary

Historical predecessor suites remain diagnostic only after the merge-forward. Local verification for tree da7514aa... is focused 9 passed, scheduler/related 336 passed, repository 3127 passed / 1 skipped / 21 subtests, statement/branch/public-doc coverage 100%, and diff check clean. The exact head must still obtain fresh hosted current-head workflow, security, coverage and independent-review evidence before normal merge. CodeQL run 34629071379 attempt 50 was a zero-job startup_failure on predecessor head 3b2de64c...; it is evidence for this repair, not authorization for the new head.

This branch is the central prerequisite lane for the producer-after-consumer Required CodeQL failure repeatedly reproduced by fast-mlsirm exact heads. Do not repair that defect in product repositories through copied workflows, synthetic statuses, no-op retriggers, or bypasses.

Exact-head replay-gate repair

Current-head OpenCode run 34684439092, coverage job 103528902332, supplied the RED: the trusted pr_head_replay_guard observed the intentional retirement of obsolete restamp tests in tests/test_pr_review_merge_scheduler.py but no added replacement test module, so it failed before coverage measurement.

The repair moves the two positive no-mutation contracts into tests/test_pr_review_merge_scheduler_source_neutral_commit_contract.py. It retains the complete scheduler test module and makes replacement evidence structurally visible to the protected guard. A transient Git-data upload commit be25a767... truncated the large existing test blob; it was never promoted as valid evidence and the immediate ordinary child 6476b919... restored the full blob. Fresh compare from a9b18b4b... to this head is exactly 46 lines moved out of the existing test module and 60 lines added in the replacement module, with no source or workflow path changed.

Exact-tree verification: focused 9 passed / 325 deselected; full 3127 passed / 1 skipped / 21 subtests; statement and branch coverage 100%; public-doc coverage 100%; git diff --check clean; and the production pr_head_replay_guard reports PASS with one added test file and no reverted protected-main path.

Latest protected-main and Runtime Quality reconciliation

Runtime Quality run 34686471090 on predecessor 798a5d4f... failed because its selected canonical fixture tests/test_javascript_materializer_docstrings.py was absent. Protected main had already merged the owner contract through #2095 and the queue-history contract through #2092. Ordinary two-parent commit 85522306949bada2b5939608dc911f6374125f1b now joins predecessor 798a5d4f... with protected main@fb17ef55... at exact tree fe8ca79a...; the overlapping Runtime Quality workflow preserves both the main-side JavaScript materializer contract and this PR's scheduler selector.

Exact-tree verification is focused 72 passed, repository 3133 passed / 1 skipped / 36 subtests, all scripts/ci/*.py statement/branch coverage 100% (13,155 statements / 5,322 branches), public-doc coverage 100%, compileall PASS, and diff checks clean. Exact-head Runtime Quality 34686930839, Python Security 34686930820, Trusted uv Materializer 34686930788, Security 34686930789, and SAST 34686930806 are GREEN. CodeQL 34686930801 is terminal failure only because actions job 103535474643 and python job 103535474644 both have DISPATCH_OUTCOME=success, VERDICT_STATE=pending; no leaf source finding is inferred.

Landing gate

Current-head review at 85522306949bada2b5939608dc911f6374125f1b confirms the merge-forward itself is valid but the protected-main pre-cutover handler and this post-cutover client cannot yet validate one another. Keep Draft until a backward-compatible protected bootstrap, provenance-bound temporary legacy discovery, one run-wide settlement owner with split-wake fixture, ADR-0025/gap removal condition, ordinary restack, and fresh terminal CodeQL evidence are present. Normal merge requires terminal applicable checks, zero valid unresolved findings, and a qualifying independent current-head approval. No self-approval, auto-merge authorization, protection bypass, manual-rerun loop, synthetic status, force update, destructive rebase, source-neutral commit, predecessor-success transfer, or valid-delta close.

Exact protected-handler prerequisite — 2026-09-12

The canonical owner prerequisite is now #2106 at exact head 50adc03d2afbe4a370782e9b7985636f0fcf12fc, based on protected main@fb17ef556f94f673234aa557254ae52779e9a7b0; its two parents are the prior canonical head 2c163e92983156739bdeeac87bd8c21383c38145 and complete overlapping predecessor #2105 head fde889ad611054cad0c1be5a14289b7eb881b124. It stages the backward-compatible v1/v2 handler, one shared concurrency owner, one run-wide settlement mutation, exact producer/base/head/ordered-parent provenance, split-language evidence, legacy-removal condition, and the credential-response isolation repair. Overlapping #2105 is Draft and remains evidence-preserving until protected integration is verified.

Keep this consumer/producer stack Draft. After #2106 lands through ordinary protection, non-force merge-forward this branch onto the new protected tip, switch the producer to the versioned event, and require fresh exact-head terminal CodeQL plus independent review. The queued runs created by the corrected Ready transition do not waive this dependency and cannot authorize merge.

[seonghobae]

Additional exact-current-head settlement-race evidence (2026-09-12 UTC): .github#2114@2a0154bfd0b010e7ac4b2b0a8d085516dbf5f4d9, CodeQL PR 34702734305.

• Attempt 1 admitted the exact PR/base/head and dispatched successfully; both python and actions compatibility jobs failed closed with DISPATCH_OUTCOME=success, VERDICT_STATE=pending.
• The automatic exact-job rerun started before an authenticated terminal receipt existed. Rerun job 103578501085 (python) has RUN_ATTEMPT=2 and terminates with Exact CodeQL job was rerun without an authenticated terminal verdict; rerun job 103578501972 (actions) also remains failed.
• The canonical Dispatch current-head CodeQL scan job 103578827970 completed SUCCESS only after those compatibility jobs had failed. Thus scan dispatch success did not settle/wake the exact required jobs in a usable order.
• The same exact head independently has Runtime Quality, Security, Python Security, and Semgrep GREEN plus fresh local 3104 passed / 1 skipped / 36 subtests; this is a producer/settlement ordering defect, not a leaf source or SARIF finding.

Keep fail-closed. Do not manually rerun, synthesize a status, or copy the producer into the consumer. #2040 remains the canonical owner for terminal receipt publication and exact-run settlement.

[seonghobae]

2026-09-12 UTC settlement RED after terminal dispatch

contextual-orchestrator#1149@684cf28fa59e800c0db4886a08f25dd2edd156fc had native CodeQL and Dispatch current-head CodeQL scan job 103573576494 terminal success. Because the three initial compatibility shards had ended earlier with VERDICT_STATE=pending, one failed job (103572985635) was rerun once after that cause change.

The resulting attempt created new compatibility jobs 103581168613 (actions), 103581169407 (python), and 103581169326 (javascript-typescript). Python and JavaScript again reached DISPATCH_OUTCOME=success but ended VERDICT_STATE=pending; Actions remained queued at observation. This confirms that a terminal central scan alone is insufficient when the authenticated downstream verdict/status cannot be settled or discovered. No further rerun was requested, and leaf source is not implicated.

[seonghobae]

Exact-head downstream settlement reproduction — 2026-09-13

ContextualWisdomLab/.github#2114@5a7f9c3d3257dee0d571eca74d9e79a82f6a6cdf reproduces the central settlement ordering defect on CodeQL PR run 34704914974.

• python job 103583359994: DISPATCH_OUTCOME=success, VERDICT_STATE=pending, terminal failure;
• actions job 103583360079: DISPATCH_OUTCOME=success, VERDICT_STATE=pending, terminal failure;
• coordinator job 103583820572: dispatch succeeded only after both compatibility jobs had already failed.

The same exact head has GREEN Runtime Quality, Security, Python Security, and SAST. This is evidence for the canonical receipt/settlement owner, not a leaf-source finding and not permission to synthesize GREEN or reuse a predecessor verdict. No manual rerun was requested.

[seonghobae]

Read-only prerequisite correction for downstream BandScope settlement: this PR body still names #2106 predecessor 50adc03d.... Current canonical bootstrap is #2106 exact 24bb6591ab7df23558cb793b4af60c567ff9da97, Open/Ready/mergeable on protected main@fb17ef556f94f673234aa557254ae52779e9a7b0; replacement CodeQL run 34692079677 attempt 4 is terminal GREEN and remaining admission is Noema/Strix/OpenCode + independent approval. Canonical telemetry successor #2114 is exact 3c43dd165009d503b2ebf56324b975db440e2fdb, Open/Draft/mergeable; #2115 is closed/unmerged after complete carryover. #2114 CodeQL 34706027995 is a no-SARIF protected-handler settlement/order RED, not a leaf source finding. Keep #2040 Draft until #2106 lands normally, then ordinary/non-force reconcile and reacquire the fresh producer/handler canary. No source edit, rerun, merge, bypass, synthetic status or provider fallback is requested here.

[seonghobae]

New protected-main canary for the post-bootstrap cutover: fast-mlsirm#1717@ba5e16677d216d3b92940461e86eeeca5de0bfbd produced handler 34710239337 for required run 34710004025. Both language scans and SARIF Medium+ gates succeeded; the handler failed only because protected legacy settlement could not publish target statuses (HTTP 403 Resource not accessible by integration) and each matrix shard reached the wake step without an Actions-capable credential (GH_TOKEN empty, WAKE_TOKEN_SOURCE=unavailable). This is executable evidence for the credential owner that #2040 is intended to provide after #2106 lands; it is not a product-repo CodeQL finding. Keep #2040 Draft until #2106 is protected, then ordinary non-force restack/cutover and require fresh exact-head convergence. Do not copy the credential logic into fast-mlsirm or manufacture a rerun.

[seonghobae]

Fresh Orgmetra #64 canary reproduces the producer-after-consumer settlement ordering defect on a new exact head.

Exact consumer:

• ContextualWisdomLab/Orgmetra#64
• protected base develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f
• exact head 77c8e027035f1118ec7b12e01e2855eb2a0a1e55
• CodeQL PR run 34720440223

Observed ordering:

• Python compatibility job 103625572510: Read current-head CodeQL dispatch verdict completed, then Release runner or enforce current-head CodeQL verdict failed at 21:44:42Z.
• Actions compatibility job 103625572549: same sequence, enforcement failed at 21:46:14Z.
• Producer dispatch job 103626405883 did not start until 21:50:29Z and completed SUCCESS at 21:50:36Z.

Thus both required consumers terminal-failed before the exact-head producer dispatch even started. This is fresh evidence for the central bootstrap/settlement cycle; no Orgmetra no-op retrigger, copied workflow, synthetic status, or predecessor verdict is being used. Preserve this canary through the #2106 prerequisite and this canonical successor's ordinary reconciliation.

[seonghobae]

Fresh immutable consumer canary from ContextualWisdomLab/linux-cluster-ops#306@6ca30fc6ef2c3c02f11fa752a783d1c353a7ee1f confirms the target-token dispatch defect on the protected consumer generation.

• Required run: 34683056632
• detect job 103525115519: GREEN
• actions consumer 103525356684: terminal FAILURE before a verdict
• python consumer 103525356787: terminal FAILURE before a verdict
• coordinator 103525928667: starts later and obtains OIDC + /exchange_github_app_token successfully, then fails the actual POST repos/ContextualWisdomLab/.github/dispatches with HTTP 403 Resource not accessible by integration at 2026-09-12T08:28:59Z.
• exact payload binds target repo, PR 306, base develop@7d6c0e6f488dffb609eded3f8980ded570b54362, head 6ca30fc..., required run ID and both required job IDs.

RCA/acceptance: the exchanged target-repository App token is not sufficient authority to dispatch into the central .github repository. Preserve exact target/base/head/run/job provenance, but the central dispatch mutation must use the versioned backward-compatible owner credential/handler path that is actually authorized for .github; do not repair this consumer with PAT widening, sleep/poll loops, synthetic verdicts, or source-neutral retriggers. After the protected handler/bootstrap lands, this exact leaf class must go RED→GREEN without changing leaf source.

[seonghobae]

Fresh consumer canary from linux-cluster-ops#307@f69ccbff0ae8178cbf0cbb79bb43a6107e1b0b2c narrows the remaining producer bootstrap failure. Required run 34724779491: Actions compatibility job 103636976617 failed its verdict read at 23:14:11Z, Python 103636976611 at 23:14:21Z; coordinator 103637179946 did not start until 23:15:17Z. More importantly, coordinator OIDC/token exchange succeeded, then the repository-scoped exchanged app token failed exactly at POST repos/ContextualWisdomLab/.github/dispatches with HTTP 403 Resource not accessible by integration at 23:15:20Z.

This proves the current leaf producer is using a target-repository credential to mutate the central .github repository, and also terminalizes compatibility consumers before that dispatch can complete. No CodeQL/SARIF source finding is implicated (linux-cluster quality/Security/SAST are GREEN on the same head).

Owner acceptance after #2106 bootstrap: central dispatch mutation must be authorized by a credential scoped to .github (or a versioned central endpoint that owns the mutation); target App credentials remain scoped to target-repository read/status/rerun duties. Then hold/wake compatibility consumers on an exact base/head/run producer receipt rather than terminal failure before producer start. Required immutable canary: same consumer repo/PR/head gets actions+python authenticated terminal verdicts, no Resource not accessible by integration, no synthetic status/no-op commit/manual rerun, and the receipt binds exact target repository, PR, base SHA, head SHA, required run and ordered language jobs.

[seonghobae]

Fresh Orgmetra exact-head consumer canary reproduces the producer-after-consumer settlement failure on ContextualWisdomLab/Orgmetra PR #64.

• protected base: develop@eb9757f8649aaad026a9865508d9aad50c1a7a4f
• exact head: d9cc516d54b4642f59fe126c331a19945fdf75f1
• CodeQL parent run: 34731010344 → terminal FAILURE
• detect languages 103653708946: SUCCESS
• Python compatibility 103653724724: reads current-head dispatch state, then fails Release runner or enforce current-head CodeQL verdict at 01:41:06Z
• Actions compatibility 103653724766: same failure at 01:41:19Z
• producer dispatch 103654071761: created only after the compatibility jobs settled; starts 01:41:24Z and succeeds 01:41:31Z

Thus this exact consumer again fails closed before the producer can publish/wake the terminal current-head evidence. No Orgmetra source/SARIF finding is inferred, no predecessor verdict is transferred, and no leaf no-op retrigger or synthetic status is appropriate. Please retain this as a current public-consumer fixture for the #2040/#2106 bootstrap + run-wide settlement repair.

[seonghobae]

Evidence from a dispatch run on current main, offered because it points at a different failing layer than root cause 1 in this PR's body ("a handler superseded after initial validation cannot publish a status"). Not a review, and I am not touching this branch — it is your lane.

Run 34733576667, job 103660988908 (CodeQL dispatch scan (python)), 2026-09-13 02:51Z, target ContextualWisdomLab/.github.

The scan is not the problem, and neither is validation ordering on this run. The job reaches the end of its work successfully: database built, 45 query packs loaded, UrlRedirect.bqrs and the rest resolved, Exporting results to SARIF... completes, artifact uploaded. validate-dispatch in the same run is success with 4 steps recorded.

It then fails at publication, on both credentials, with the same status:

##[notice] CodeQL dispatch status publish using target-app-token did not succeed:
           gh: Resource not accessible by integration (HTTP 403)
##[notice] CodeQL dispatch status publish using github-token did not succeed:
           gh: Resource not accessible by integration (HTTP 403)
##[error]  Could not publish the CodeQL dispatch status after all configured credentials
           failed; the exact required job will remain failed and will not be woken with
           stale or missing evidence.

The refused call is gh api -X POST repos/${TARGET_REPOSITORY}/statuses/${HEAD_SHA} (log line 1925). What makes this worth reporting separately: the matrix job on main already declares the permission it is being refused —

# .github/workflows/codeql-scan-dispatch.yml:279-284
    permissions:
      actions: write
      contents: read
      security-events: read
      id-token: write
      statuses: write # Required for downscoped OIDC status publication.

— and TARGET_REPOSITORY here is .github itself, the same repository the workflow is running in, so this is not the cross-repo case where GITHUB_TOKEN would have no standing at all. A declared statuses: write being refused 403 in its own repository is consistent with the effective permission being capped below what the block requests (org- or repo-level "Workflow permissions: read repository contents", which caps rather than errors) — and, separately, with the App installation not carrying statuses for target-app-token. Both of those are owner settings, not code. I have not verified either setting, so treat that as the hypothesis the evidence points to, not a finding.

Why it matters beyond this run: the required CodeQL compatibility analysis (<lang>) check fails fast by design and waits to be woken by this publication, so while POST /statuses/ is refused, no PR in the queue can turn that check green — including ones whose scan found nothing. Eight of the eight most recent CodeQL Scan Dispatch runs are completed/failure.

One correction to a nearby assumption, since it changed my own reading: this is no longer the pre-runner cancellation class tracked in #1929. Those runs showed validate-dispatch with zero steps recorded — never scheduled onto a runner. These runs execute 15–17 steps and produce SARIF. The queue moved past starvation into a permissions wall.

If the cap hypothesis holds, the code change in this PR cannot make the publication succeed on its own, and the two would need to land together. Your call — you have the full context on this branch and I do not.

Refs #1929, #2137.

---

Generated by Claude Code

[seonghobae]

Correction to my evidence above — I mislabelled the run, and the diagnosis was wrong

Two errors in my earlier comment. Retracting both before they inform anyone's work on this branch.

1. The run I cited does not target .github. I wrote "Run 34733576667 … target ContextualWisdomLab/.github." Its actual name is:

CodeQL Scan Dispatch ContextualWisdomLab/naruon#1676@2a3ddd16…/042b0c70…/34733368279

It targets naruon. I then used it to argue "this is not the cross-repo case where GITHUB_TOKEN would have no standing" — when it is precisely the cross-repo case. The dispatch workflow runs in .github, so its jobs create check runs on .github's head regardless of target, and I read the check-run list without checking each run's target.

2. The status-publish 403 is real but is not what keeps required checks red. The wake step does not stop there. After the publish attempt fails it falls through to POST /repos/${TARGET_REPOSITORY}/actions/jobs/${REQUIRED_JOB_ID}/rerun, and for a same-repository target that call succeeds. Demonstrated on this repo, this hour:

.github#2137's own dispatch, run 34734286494 — CodeQL Scan Dispatch ContextualWisdomLab/.github#2137@3d39fe7c…:

job	wake	required check
CodeQL dispatch scan (actions)	publish 403 → rerun succeeded (CodeQL job status was success)	CodeQL compatibility analysis (actions) → success 03:13:05Z
CodeQL dispatch scan (python)	publish 403 → rerun refused	still failure

Same run, same credentials, same repository, opposite outcomes. A missing statuses grant or an org workflow-permission cap would fail both identically, so my hypothesis does not survive this.

What actually failed on the python shard:

gh: The workflow run containing this job is already running (HTTP 403)

POST /actions/jobs/{id}/rerun re-runs the containing run. Both language shards target jobs in the same run (34733728747), so the shard that gets there first wins and the second is refused by GitHub. That is a concurrency race between language shards, which is what this PR's siblings #2051 ("coordinate failed-job wake once") and #2056 ("serialize exact dispatch wakeups") describe. My "owner settings" framing pointed away from the fix that already exists.

What does still hold, and is genuinely separate. For a cross-repo target the wake never reaches the rerun at all — it exits earlier:

##[error] Actions-capable CodeQL wake credential is unavailable.

Confirmed identically on the naruon run above and on contextual-orchestrator#995 (run 34730169632). Waking a job in another repository needs Actions write there, which GITHUB_TOKEN cannot have and the App token evidently does not carry. So there are two failure modes, not one org-wide wall:

• same-repo (.github PRs): reachable today; loses only to the inter-shard rerun race;
• cross-repo (naruon, contextual-orchestrator, and every other sibling): blocked on an Actions-capable credential for the target.

I have not verified any repository or org setting — the actions/permissions/workflow endpoints are blocked to me by my own tooling proxy, not by GitHub — so nothing here should be read as a settings finding.

Still your lane; still not touching this branch. Sorry for the noise of a correction on top of the original.

---

Generated by Claude Code

[seonghobae]

Fresh Orgmetra exact-head consumer canary reproduces the protected producer-after-consumer settlement defect on 2026-09-13.

• target repo/PR: ContextualWisdomLab/Orgmetra#64
• protected base: eb9757f8649aaad026a9865508d9aad50c1a7a4f
• exact head: c0ba482c57a77820128f259b4a43c06df643c0f3
• required CodeQL run: 34747271161
• actions compatibility job 103697626932: terminal FAILURE with DISPATCH_OUTCOME=success, VERDICT_STATE=pending; enforcement failed at 2026-09-13T08:22:28Z
• python compatibility job 103697626984: terminal FAILURE on the same pending-verdict path
• coordinator/producer job 103698066725: did not start until 2026-09-13T08:22:35Z, then dispatched successfully at about 08:22:36Z

So both consumers settled fail-closed before the producer job even began. This is current exact evidence for the #2040/#2106 central bootstrap/settlement dependency, not an Orgmetra source/SARIF finding. Orgmetra did not use a no-op retrigger, predecessor verdict, synthetic status, copied workflow, or protection bypass.

[seonghobae]

Fresh downstream evidence from ContextualWisdomLab/accounting-information-platform#59: predecessor exact 19ccc70c8e89469574a69ac0ba297af29679b0de establishes the 84th consecutive receiver-before-dispatch generation. In required CodeQL run 34753334781, Actions receiver 103713863824 completed FAILURE at 11:09:23Z and Python receiver 103713863852 completed FAILURE at 11:09:53Z; producer 103714441167 was only then materialized and started at 11:12:21Z, completing dispatch SUCCESS at 11:12:28Z. This remains central producer/consumer ordering evidence, not a leaf source-analysis finding.

AIP current exact cb4cde2253441e5049d98ac2d45dbb80e6ed12da has a new intentional accounting behavior RED while exact dependency/security/SAST and standalone Security/SAST are GREEN; its CodeQL run 34756137679 is still nonterminal, so no 85th generation is claimed yet. No leaf workflow copy, polling/status synthesis, no-op retrigger, PAT fallback, or gate weakening was introduced.

Fresh canonical prerequisite read: #2106 is open Ready/mergeable at exact 611ccd73460ab0188e0085956ade6180bb28a91a; this does not alter #2040's Draft/non-mergeable consumer boundary or authorize downstream workarounds.

[seonghobae]

AIP downstream terminal follow-up: accounting-information-platform#59 exact cb4cde2253441e5049d98ac2d45dbb80e6ed12da now establishes the 85th consecutive receiver-before-dispatch generation. Required run 34756137679: Actions receiver 103720730374 completed FAILURE at 12:08:33Z, Python receiver 103720730404 completed FAILURE at 12:08:34Z; producer 103721073189 was created only after both terminal, started 12:08:44Z, dispatched 12:08:46Z, completed SUCCESS 12:08:50Z. Leaf Accounting Foundation failure is separately an intentional accounting behavior RED; exact security/SAST/dependency evidence is GREEN. No leaf workaround was introduced. Canonical prerequisite #2106 remains the owner path; this evidence does not authorize #2040 merge.

[seonghobae]

Fresh source-changing external canary for the canonical producer-after-consumer defect: gyeot#52@557cda8d49844b0f43be7ad7b2b24e51beac57ae, base 4aa02cc83fcf16725118c228137b21dcccae8900, Required CodeQL run 34756562356.

Exact ordering is now unambiguous:

• actions consumer 103722183864 read the current-head verdict from 12:18:10Z through 12:20:43Z, then failed closed at 12:20:43Z;
• javascript-typescript consumer 103722183858 read from 12:21:14Z through 12:23:50Z, then failed closed at 12:23:50Z;
• only after both consumers had terminalized did producer job 103722913857 become runnable: created at 12:23:52Z, started 12:24:20Z, and successfully dispatched at 12:24:24Z;
• protected central handler run 34757001954 was then created at 12:24:28Z for the exact {repo, PR, head, base, required_run} tuple.

So the leaf consumers are not failing because a terminal CodeQL/SARIF finding was returned; their receipt deadline expires before the same workflow generation is permitted to publish the dispatch that can create that receipt. This is direct executable RED for this PR's documented producer-after-consumer prerequisite, on a real source-changing authentication repair rather than a no-op retrigger.

GREEN acceptance remains: after #2106's protected bootstrap and this stack's ordinary non-force restack/cutover, the same generation must admit producer dispatch early enough for authenticated terminal receipts to settle both required consumers; no leaf sleep, manual rerun, source-neutral commit, copied workflow, predecessor receipt, or synthetic status. Gyeot remains Draft and no central source/refs were modified here.

[seonghobae]

AIP consumer evidence update from ContextualWisdomLab/accounting-information-platform#59.

Predecessor exact head 67d8311f5c82b706c4133721ccaf17d6edda3789 now establishes the 86th consecutive receiver-before-dispatch generation in that lane. Required run 34758789451: Python receiver 103727993371 completed FAILURE at 2026-09-13T13:10:12Z; Actions receiver 103727993395 completed FAILURE at 13:11:54Z; dispatch producer 103728752777 did not start until 13:17:33Z and completed SUCCESS at 13:17:43Z. The same head's Accounting Foundation reached its intentional behavior RED after environment/setup, while exact security/SAST/dependency gates were GREEN. This remains central producer/consumer ordering evidence, not an AIP CodeQL source finding.

AIP has moved ordinarily to exact 5a06e9a23cbcd13c7b8182ec2e3e9037fddcd3d1 for a separate accounting RED; its required CodeQL generation is new and is not counted until terminal chronology exists. No leaf workflow copy, synthetic status, source-neutral retrigger, polling loop, PAT fallback, or protection weakening has been added.

[seonghobae]

AIP consumer evidence update from ContextualWisdomLab/accounting-information-platform#59.

Exact head 5a06e9a23cbcd13c7b8182ec2e3e9037fddcd3d1 now establishes the 87th consecutive receiver-before-dispatch generation in that lane. Required run 34761487213: Actions receiver 103735185408 completed FAILURE at 2026-09-13T14:11:11Z; Python receiver 103735185416 completed FAILURE at 14:13:16Z. Dispatch producer 103736427908 was created only at 14:13:17Z, then started at 14:24:42Z and completed SUCCESS at 14:24:47Z. Both required consumers were therefore terminal before their authenticated producer existed. Standalone Security 34761487209 and SAST 34761487234 are terminal SUCCESS; Accounting Foundation 34761487239 reached the intentional AIP behavior RED after PostgreSQL/setup.

AIP has since advanced by one ordinary test-only descendant to 66974820f884906fed17566958719a5e62fe1ae6; that new generation is not counted until its own chronology is terminal. This remains central producer/consumer ordering evidence, not an AIP source-analysis defect. AIP still has no copied central workflow, synthetic status, source-neutral retrigger, polling loop, PAT fallback, manual rerun loop, or gate weakening.