Repository navigation
[Review pipeline] Zero PRs mergeable in fast-mlsirm/LineageWeave: hash-pinning, cross-repo status 403, dispatch throughput #1212
Description
Activity
Progress on recommended-fix item 1 (fast-mlsirm/RankWeave release-asset publishing): opened ContextualWisdomLab/fast-mlsirm#1207, which adds a
publish-pypi.ymlworkflow (sdist + linux/macos/windows wheels via maturin-action, published to PyPI + attached as release assets onrelease: published).This PR is itself blocked by the exact gate this issue describes — it can't get the required bot approval until the pipeline is fixed, which is exactly the chicken-and-egg this issue flags. Flagging here so it's visible to whoever reviews/repairs the pipeline: merging #1207 (or applying it directly) unblocks a real fix path rather than just working around the symptom.
Once #1207 lands and a release is cut, LineageWeave's
fast-mlsirm/RankWeavegit-sourceuv.lockentries can switch to the released PyPI versions (item in the original recommended-fix scope), which resolves root cause #1 for every LineageWeave PR at once.RankWeavestill needs the equivalent workflow — not done yet, tracking as follow-up.Checked RankWeave separately (the other git-sourced dependency in LineageWeave's
uv.lock): unlike fast-mlsirm, RankWeave is already on PyPI and already has a workingpublish.yml(trusted-publisher/OIDC based, no token secrets needed) — but PyPI currently only has0.1.0published while LineageWeave's git pin is exact-identical to RankWeave'sv0.18.0tag (0 commits ahead/behind). The last publish attempt (2026-08-06, run 31067753363) failed at the trusted-publishing OIDC exchange:invalid-publisher: valid token, but no corresponding publisher — claims:sub: repo:ContextualWisdomLab/RankWeave:environment:pypi,workflow_ref: .../publish.yml@refs/tags/v0.18.0This is a PyPI project-settings problem (Trusted Publisher config on the
rankweavePyPI project no longer matches the repo/workflow/environment claims RankWeave's Actions run presents) — not something fixable from the GitHub side or viagh/git. It needs whoever administers therankweavePyPI project to fix/re-add the trusted publisher at https://pypi.org/manage/project/rankweave/settings/publishing/ (matching repoContextualWisdomLab/RankWeave, workflowpublish.yml, environmentpypi), then re-runpublish.yml(workflow_dispatch withrelease_tag=v0.18.0) to catch PyPI up.Once that's done, LineageWeave's
RankWeavegit-sourceuv.lockentry can switch torankweave==0.18.0from PyPI immediately (no code/build work needed on RankWeave's side, unlike fast-mlsirm).New finding via static analysis (
actionlint):pr-review-fix-scheduler.yml's "Resolve immutable called-workflow source" step references a nonexistent context, unconditionally failsRan
actionlint(v1.7.12) against the review-pipeline workflows in this repo to look for issues the runtime logs hadn't already surfaced. It flagged.github/workflows/pr-review-fix-scheduler.yml:225-228:pr-review-fix-scheduler.yml:225:36: property "workflow_repository" is not defined in object type {check_run_id: number; container: ...; services: ...; status: string} [expression] WORKFLOW_REPOSITORY: ${{ job.workflow_repository }} pr-review-fix-scheduler.yml:226:29: property "workflow_sha" is not defined ... pr-review-fix-scheduler.yml:227:29: property "workflow_ref" is not defined ... pr-review-fix-scheduler.yml:228:35: property "workflow_file_path" is not defined ...job.workflow_repository/job.workflow_sha/job.workflow_ref/job.workflow_file_pathare not properties of the GitHub Actionsjobcontext (which only exposescontainer,services, andstatus). Each of these${{ }}expressions evaluates to an empty string at runtime rather than erroring — so the four env vars the "Resolve immutable called-workflow source" step (line 221) sets are always empty, unconditionally, on every run that reaches this step.That step immediately does:
if [ "$WORKFLOW_REPOSITORY" != "$expected_repository" ]; then ... exit 1 fi
Since
$WORKFLOW_REPOSITORYis always""and$expected_repositoryis"ContextualWisdomLab/.github", this check can never pass — the step fails every single time it executes.Confirmed against real runs, not just static analysis: this step doesn't appear at all in
pr-review-fix-scheduler.ymlruns from 2026-08-16 (older workflow revision, before this step existed — job logs show onlypr_review_fix_scheduler.py --self-test, no "Resolve immutable..." step). The step first appears in the 2026-08-20repository_dispatch-triggered runs (32360044573failure, 32360412990cancelled) — i.e. every run that has hit this code path since it was added has failed here.pr-review-merge-scheduler.yml,opencode-review-dispatch.yml,pr-review-autofix.yml, andpr-auto-rebase.ymldo not contain this pattern (checked via the sameactionlint/grep pass) — the blast radius looks isolated topr-review-fix-scheduler.yml'srepository_dispatch(auto-repair-dispatch) path specifically, not the main review/approval/merge flow this issue already tracks.Likely intended fix (not applied — this is a security-relevant workflow-identity check and I don't want to guess-patch it): GitHub Actions doesn't expose "which exact commit of the currently-executing workflow file is running" under
job.*. The relevant built-ins aregithub.workflow_ref/github.workflow_sha(current workflow file's ref/SHA) and, for a workflow invoked as a reusable workflow viauses:,github.job_workflow_ref/github.job_workflow_shaon the caller's side. Whoever owns this script should confirm which of those (or a different mechanism entirely, e.g. parsinggithub.workflow_refserver-side) was actually intended before changing it, since the four-way split (repository/sha/ref/file_path) suggests the author meant to parse a combinedowner/repo/.github/workflows/file.yml@refstring rather than read four separate fields.Evidence commands:
actionlint -shellcheck= -pyflakes= pr-review-fix-scheduler.yml(reproduces the four warnings above)gh run list --repo ContextualWisdomLab/.github --workflow pr-review-fix-scheduler.yml --json databaseId,conclusion,event,createdAtgh api repos/ContextualWisdomLab/.github/actions/jobs/95141441945/logs(2026-08-16 success — step absent) vs the 2026-08-20 failing run logs (step present, fails)
Opened #1221 for root cause #3 (the actionlint-caught nonexistent
job.workflow_*context references inpr-review-fix-scheduler.yml). Also found and fixed the same broken pattern inexact-artifact-sbom-attestation.yml(3 occurrences) while I was in there — its trusted-verifier checkout and signer-repository resolution had the identical bug, though it happened to fail closed downstream viagh attestation verifyrather than silently bypassing signer verification. Full test suite green (1330 passed / 1 skipped, unrelated env-only failure).- added
on Aug 22, 2026 - added a commit that references this issue
on Aug 22, 2026 Root cause #3 landed: #1221 merged. Note this ended up being a two-part fix — the original PR only replaced the nonexistent
job.workflow_*context references withgithub.workflow_ref/github.workflow_sha, but those still don't identify a called reusable workflow's own file (they reflect the top-level caller inside aworkflow_calltarget), so the scheduler's identity guard would have kept failing closed on every real hourly-caller invocation even after that first push. Caught via Devin review and fixed properly before merge: validategithub.repositoryinstead, since every current caller uses a local same-repouses: ./.... Watching fast-mlsirm#1207 and TEPP#153 as bellwethers for whether main-branch PRs start getting real bot APPROVE decisions now.New finding after #1214/#1235/#1236/#1240/#1241 (all merged, confirmed working end-to-end in production)
Every GitHub-API-layer issue in the mention-dispatch pipeline is now fixed: retry-with-backoff on the shared installation-token rate limit (scoped safely to avoid resending non-idempotent writes), a wall-clock time budget so the sweep job exits cleanly instead of hitting its 15-minute Actions timeout, unbuffered output so diagnostics actually reach the log, and isolation so one repo's listing failure doesn't crash the whole cycle. Confirmed live: a recent sweep run cleanly logged
"Agent mention sweep stopped before its time budget (480s)...; 0 dispatch(es) and 7 isolated failure(s) so far."and exited in 9m21s instead of hanging or crashing.But the org-wide dispatch budget (1 per 5-minute cycle) is still dominated by a small set of repos (bandscope, pg-erd-cloud, newsdom-api) that get re-dispatched repeatedly, while fast-mlsirm/TEPP/LineageWeave never reach the front of the queue.
Checked one repeat target closely — bandscope#895: dispatched at least 3 times in ~4 hours (its
updatedAtkeeps refreshing), yetgh api repos/ContextualWisdomLab/bandscope/pulls/895/reviewsshows zeroopencode-agentreviews ever posted — only 2 unrelatedgithub-advanced-securitycomments from 2026-08-17.agent-mention-opencode-dispatch.ymlonly forwards the request to an external service (api.opencode.ai) via a 5-secondvalidate-and-forwardjob. The actual review-generation happens entirely outside GitHub Actions — opaque togh/anything I can inspect from here. If that external service is silently failing or never completing for some PRs while the dispatch step still reports success (consuming a budget slot each time regardless), that would explain the queue starvation even with a fully healthy dispatch mechanism.This isn't diagnosable or fixable with the tools available to me — flagging for whoever has access to OpenCode's own service-side dashboard/logs to check why bandscope#895 (and similar repeat-dispatch targets) never receive a posted review verdict despite repeated dispatch.
Root cause for the remaining gap is now identified — it's
.github#624, not opaqueCheckpoint at 2026-08-22T19:19:30Z above diagnosed the remaining gap after #1214/#1235/#1236/#1240/#1241 as an opaque external-service failure: dispatch reaches
api.opencode.aisuccessfully but a posted review never follows for some PRs (e.g.bandscope#895, dispatched repeatedly with zeroopencode-agentreviews ever posted).Another investigation thread (
.github#624, "Migrate OpenCode review model pool off GitHub Models before 2026-07-30 retirement") root-causes exactly this symptom precisely — not opaque, just tracked in a different issue:- GitHub Models was fully retired 2026-07-30; org-attributed inference was already cut off from 2026-07-25. The stopgap PAT mitigation stopped working the day of cutoff.
- OpenAI returns
insufficient_quota; OpenRouter returns HTTP 402 (credit-exhausted). With GitHub Models also dead, the entire configured model pool foropencode-reviewis exhausted org-wide →OPENCODE_MODEL_POOL_OUTCOME: exhausted→MODEL_OUTPUT_UNAVAILABLE. No review can be produced, so no approval evidence, so every main-targeted PR org-wide staysREVIEW_REQUIRED/blocked regardless of how healthy the dispatch/scheduler mechanism is. - Migrate OpenCode review model pool off GitHub Models before 2026-07-30 retirement #624's most recent comment (2026-08-23T06:36:30Z) traces this deeper: even the default, non-retired
nvidia-nim/nvidia/llama-3.3-nemotron-super-49b-v1.5candidate fails, but via a different failure mode —CONTROL_REJECTED: no top-level current-run control JSON object was found→NO_CONCLUSION(a content-shape/schema-validation rejection, not a billing/reachability error). This means restoring OpenRouter credit or OpenAI quota alone may not be sufficient if the default NVIDIA NIM candidates keep failing the anti-replay control-JSON schema check first and burn most of the 30-attempt ceiling before ever reaching a paid fallback.
Combined with the dispatch-mechanism fixes already landed here (#1214/#1235/#1236/#1240/#1241), the full picture is now: the dispatch/scheduler layer is healthy end-to-end; the sole remaining blocker is the model-pool exhaustion + a possible secondary control-JSON schema-rejection bug on the default candidate, both tracked in #624. Not attempting a fix from this thread either — no NVIDIA NIM/OpenAI credentials to reproduce locally, and #624's own investigator already correctly declined to guess-and-check on this deliberately hardened, actively-maintained shared scheduler logic. Recording the cross-link here so anyone reading either issue gets the complete picture without re-deriving it.
Follow-up to the cross-link comment above: opened #1246 fixing the content-shape/schema-rejection half of #624's newest finding (int-typed
run_id/run_attemptin a model's control JSON always failing the anti-replay identity check, regardless of billing). Full evidence (tests proven to fail pre-fix, 100% coverage/docstring, safety reasoning) in the PR. The billing/model-pool-exhaustion half still needs a human with OpenRouter/OpenAI billing access — this PR alone won't fully unblock main-targeted approvals.- added a commit that references this issue
on Aug 24, 2026 New root cause found: Strix's own benign MODEL QUALITY WARNING startup banner false-fails every clean scan on the org's configured default model
Independent of the review-approval gap this issue tracks, the required
strixcheck itself was blocking merges via a separate false positive. Strix prints a box-drawnMODEL QUALITY WARNINGbanner at startup whenever the configured model isn't on its own hardcoded "recommended frontier model" list — a static disclaimer about model choice, unrelated to the scan's outcome. Its literalWARNINGtext satisfiesstrix_quick_gate.sh's genericFatal|Denied|Warn|Warninginfra-failure matcher, so any clean, 0-vulnerability scan on the org's configured default model (nvidia_nim/nvidia/nemotron-3-super-120b-a12b, not on Strix's recommended list) fails closed even though the scan itself succeeded with zero findings.Reproduced directly: TEPP#214's
strixcheck failed withStrix run emitted provider infrastructure or failure-signal output; failing closed.while its own transcript shows a complete pentest summary reporting "Low" risk and "Vulnerabilities 0". The same banner (6 occurrences across fallback attempts) also appears in fast-mlsirm#1237'sstrixjob log, so this isn't TEPP-specific — it fires wherever the org's default model resolves to a non-"frontier" model, i.e. broadly.Fix opened: #1311 — sanitizes the banner out of both the console transcript and report-artifact logs before the infra-failure matchers run (does not touch vulnerability-severity classification; a real finding still fails closed as before). New regression test reproduces the exact TEPP#214 failure on the pre-fix script and passes post-fix.
Fresh downstream canary after #1002 integration shows a fail-open review-evidence regression that belongs to the central review pipeline, not OriginWeave product code.
ContextualWisdomLab/OriginWeave#37at exact heade1fca7c65ce738de3406b0e408708e08c283552e/ live basemain@f658f329c83a106b68385e17cb714c4147c12f49has centralcoverage-evidencecheck run98391429201= success andopencode-reviewcheck run98391443246= success (workflow run33033609031). The same-head Reviews API has no qualifyingAPPROVEDorCHANGES_REQUESTEDOpenCode verdict; the newest current-head formal review activity is COMMENTED/Devin only. Live organization ruleset18156473still requires one approval.That is the exact consumer failure #1002 was intended to prevent: a green
opencode-reviewcheck exists without a substantive exact-head Reviews API verdict. Please treat this as a current regression canary, reproduce it at the first central causal boundary, add a RED contract that forbids success without the exact-head formal verdict, then repair/revalidate the central workflow without adding a leaf OriginWeave workaround or synthesizing approval. The OriginWeave lane will remain non-mergeable-by-policy until real exact-head approval exists.Orgmetra exact-head canary: required OpenCode context fails only because no current-head verdict materialized
Fresh downstream evidence from
ContextualWisdomLab/Orgmetra#100isolates the first failing boundary to the central review-verdict path, after required-workflow bootstrap and coverage evidence have already succeeded.- target PR/head:
ContextualWisdomLab/Orgmetra#100@57cb9e461bf594e96c0b125349325f35cba95d20 - live base:
develop@9e3e4847510e1e612b48474ba42b177b8ed824df - required OpenCode workflow run:
33139299589 required-workflow-bootstrapjob98746318056: terminal SUCCESScoverage-source-treejob98746532800: terminal SUCCESScoverage-evidencejob98746587038: terminal SUCCESSopencode-reviewjob98746893380: terminal FAILURE- first/only failing step in that job:
Fail closed without a current-head OpenCode verdict
This canary does not prove whether the missing verdict is caused by dispatch throughput, mention/router concurrency, model/provider availability, Reviews API publication, or another central control-plane boundary. It does prove that no Orgmetra source/test/coverage repair is justified for this failure: the central required context reaches its explicit no-current-head-verdict fail-closed branch after evidence jobs succeed.
RED acceptance: an exact target head with successful bootstrap/source-tree/coverage-evidence must never be represented as review-passing without a qualifying formal Reviews API verdict for that same SHA, but the owner path must produce a durable, machine-readable causal failure when that verdict cannot be materialized rather than leaving the leaf to guess or mutate product code.
Required GREEN: identify and repair the first central dispatch/review-publication boundary that prevented a verdict; preserve reviewer identity, exact-head binding, fail-closed behavior, and coverage requirements; then rerun unchanged/current Orgmetra #100 and require a formal current-head OpenCode verdict plus terminal-success required context. Do not use a status-only substitute, stale review, self-approval, or downstream workflow shim.
This comment advances the existing central review-pipeline owner path only. No
.githubsource/ref/workflow/settings/PR state was mutated from the Orgmetra loop.- target PR/head:
Fresh Inkspan canary adds a current consumer failure to the existing review-dispatch throughput lane without asserting a provider failure that has not yet been reached.
Affected target:
ContextualWisdomLab/inkspan#391- protected live base:
128a239f8b71ca16add4b9e15e21752d1ad63ff0 - exact current head:
3edd7495a20f96b91eee97afa0f0dd62a8adc55c - required-workflow run:
33146959271 - fail-closed verifier job:
98771103570
Observed sequence: the required OpenCode workflow started at 06:08:51Z. Its source/coverage placeholder jobs completed successfully, then the
opencode-reviewverifier ran at 06:17:55Z and failed at 06:18:02Z with the exact messageNo APPROVED or CHANGES_REQUESTED from opencode-agent on the current head. This required check is not a review and must not succeed until the authenticated dispatch posts a current-head verdict.The PR's current review inventory has noopencode-agentverdict for3edd7495.... A fresh inspection of the 100 most recent centralrepository_dispatchruns after the verifier failure contained active OpenCode dispatches for other targets (including.github#897@4a5f29f...) but no dispatch titled forContextualWisdomLab/inkspan#391@3edd7495...; the Inkspan PR comment stream likewise has no durable OpenCode receipt marker for this head.First causal boundary for this canary is therefore dispatch admission/throughput/receipt before model execution, not application source and not yet a demonstrated model-provider failure. This is falsifiable: if an authenticated dispatch for this exact target/head exists, record its run id/receipt and move the boundary to that run's first failing job; otherwise the scheduler must ensure an eligible exact-current head is dispatched early enough that the required verifier cannot expire first.
Smallest acceptance: preserve fail-closed verifier semantics; do not synthesize a review/status. For the unchanged or successor Inkspan head, require a durable authenticated dispatch receipt + central run id bound to exact repository/PR/head, followed by an actual formal
opencode-agentAPPROVEDorCHANGES_REQUESTEDreview on that same head before the required verifier can pass. Queue/backlog handling must not silently starve a current required head.- protected live base:
DiskSage exact-head canary for the central OpenCode dispatch/throughput lane (owner handoff only; no foreign source mutation):
ContextualWisdomLab/disksage#267is currently at exact headccb395ed5b3ceb7ec3180012b06a3d30c2000dbbon basemain@79067c1160ddedf7fc962cbf8067ce7e83c4564a. Required-workflow run33187827737, job98906719264(opencode-review) failed closed. The first failing boundary isFail closed without a current-head OpenCode verdict: the job queried Reviews API foropencode-agent/opencode-agent[bot]on the exact SHA and found noAPPROVEDorCHANGES_REQUESTED. Fresh/pulls/267/reviewslikewise contains no OpenCode review for this head. Same-head centralcoverage-evidenceandcoverage-source-treeare successful, so this is not a DiskSage source/coverage failure. Acceptance: authenticated central dispatch submits a non-synthetic OpenCodeAPPROVEDorCHANGES_REQUESTEDreview bound toccb395ed…; then the unchanged-headopencode-reviewgate is rerun and reaches terminal success only for a valid verdict. Please preserve the exact-head/fail-closed semantics; no leaf status synthesis or gate relaxation is requested.Fresh downstream canary from
ContextualWisdomLab/Orgmetra#55shows the review-pipeline throughput/liveness problem can now consume the target required-check lifetime even when exact-head coverage is already green and the central scheduler eventually accepts the same-head dispatch.Exact evidence:
- target PR/head:
Orgmetra#55@27f09897507182f8ddcb090dd7273dcbaf182e36 - target required
opencode-reviewjob99631473020: started2026-08-31T21:33:14Z, polled for an exact-current-headopencode-agent[bot]APPROVED/CHANGES_REQUESTEDverdict every 30s for 180 attempts, then failed closed at2026-08-31T23:04:28Z; exact-headcoverage-evidencewas already SUCCESS and no qualifying OpenCode formal review appeared - central repository_dispatch run
33441942494: created2026-08-31T21:33:19Z, butscan-pr-queuejob99651996585did not start until2026-08-31T22:51:12Z(~78 min of Actions queue delay) - once scheduled, the central job did identify the same exact head and logged acceptance of the same-head OpenCode review dispatch at about
22:52:04Z - this left only ~12 minutes before the target's original 90-minute polling budget expired; the target therefore failed without a formal verdict even though the control-plane dispatch was eventually accepted
This is not repairable by an Orgmetra source change or a no-op head churn. The first causal boundary is the central review scheduler/required-check liveness contract: the consumer wait budget starts before the central dispatch worker may actually be scheduled under organization Actions contention.
RED acceptance: reproduce a same-head consumer where central queue latency consumes most of the target polling window, central dispatch is eventually accepted, but the target gate expires without a formal verdict.
Required GREEN semantics: preserve fail-closed exact-head review requirements, but decouple the substantive verdict wait budget from pre-dispatch scheduler queue delay (for example by exposing durable accepted-dispatch state/timestamp that the target can observe and budgeting from that boundary, or an equivalent owner design). On the unchanged Orgmetra #55 head above, a post-repair run must obtain a formal current-head OpenCode verdict and let the required target gate reflect that verdict without branch churn, synthetic status, predecessor evidence, or relaxed review requirements.
#1150is useful read-only Actions queue-health evidence for this class of delay, but it intentionally does not repair review-scheduler liveness; this comment is routed here because this issue already owns OpenCode dispatch throughput/retry behavior.- target PR/head:
A second fresh Orgmetra canary narrows the same review-pipeline liveness defect further: the fixed target OpenCode wait budget is consumed not only by central Actions queue latency, but by the scheduler's intentional prerequisite ordering before OpenCode can even be dispatched.
Exact evidence:
- target:
ContextualWisdomLab/Orgmetra#57@6ca554791595d925a76587378b543e7dbc3dc20b - target required
opencode-reviewjob99636447752: started2026-08-31T21:42:06Z, then polled every 30s for 180 attempts for an exact-headopencode-agent[bot]APPROVED/CHANGES_REQUESTED; it failed closed at2026-08-31T23:13:24Zwith no formal current-head verdict. Exact-headcoverage-source-treeandcoverage-evidencewere already SUCCESS. - central merge-scheduler repository_dispatch run
33442679292: created about2026-08-31T21:42:15Z; itsscan-pr-queuejob99654383906did not obtain a runner until2026-08-31T22:53:25Z(~71 minutes later). - the central job then validated the unchanged exact 🛡️ Sentinel: [CRITICAL] Fix HTML Comment Breakout in JSON Serialization #57 head and at
22:53:39Zmade this explicit decision:security_dispatch: current head has no completed Strix evidence; same-head Strix dispatched,contract_decision: WAIT. - therefore OpenCode was still not eligible/dispatched on that central pass. Instead central Strix run
33448297677was created at22:53:41Zfor exactlyOrgmetra#57@6ca554...; a fresh refetch still reports that Strix run aspending, with no target exact-head Strix check materialized yet.
This rules out an Orgmetra source repair: the target OpenCode timer is already running while the central owner deliberately sequences missing Strix ahead of OpenCode, and organization queue delay can consume most of that timer before prerequisite security work even starts. With a 90-minute target polling budget, a correct fail-closed scheduler can therefore cause OpenCode failure before substantive OpenCode review has had a viable start boundary.
RED acceptance: exact head has no completed Strix; target OpenCode waiter starts; delayed central scheduler eventually runs and correctly dispatches Strix-only/WAIT; target OpenCode wait budget expires before a formal OpenCode review can be dispatched and published.
Required GREEN semantics: preserve exact-head fail-closed security and review requirements, but do not consume the substantive OpenCode verdict budget before prerequisite security evidence and an accepted OpenCode-dispatch phase make that verdict achievable. A durable phase/receipt boundary or equivalent owner design is acceptable; absent/cancelled/neutral/stale Strix and absent/stale/model-only OpenCode evidence must remain non-passing. After the owner repair reaches protected main, the unchanged #57 head should be able to progress through exact-head Strix and then obtain a formal current-head OpenCode verdict without branch churn, synthetic status, predecessor evidence, or relaxed gates.
- target:
Fresh independent downstream canary from
ContextualWisdomLab/Orgmetra#56reproduces the same central review-liveness defect with a prerequisite WAIT, not an Orgmetra source failure.Exact evidence:
- target PR/head:
Orgmetra#56@68af42cb80807b6638d745d1687fd3c6a814d64f, live basedevelop@9e3e4847510e1e612b48474ba42b177b8ed824df - target Required OpenCode run
33262099911, attempt 2, job99630478791: started2026-08-31T21:21:25Z; authenticated OIDC/app-token dispatch succeeded, then the verifier polled Reviews API every 30s for 180 attempts and failed closed at22:52:30Zbecause no exact-headopencode-agent[bot]APPROVED/CHANGES_REQUESTEDverdict existed - corresponding central scheduler run
33440932661was created at21:21:29Z, butscan-pr-queuejob99648671891did not start until22:42:07Z(~80m38s control-plane queue delay) - once scheduled, it validated the exact Orgmetra repository/PR/head and at
22:42:22Zcorrectly returnedWAIT:current head has no completed Strix evidence; same-head Strix dispatched - that prerequisite decision is correct, but it arrived after ~80 minutes of the target's fixed ~90-minute verdict budget had already elapsed, leaving only ~10 minutes before the target verifier failed
- the newly dispatched exact-head Strix run is central
.githubrun33447442798; it is currentlyin_progress, hence non-passing and not a reason to synthesize an OpenCode verdict
First causal boundary: the required-check lifetime is consumed while the central worker is queued and while exact-head prerequisites are legitimately unresolved. There is no correct Orgmetra-local code change or no-op head churn that can repair this ordering/liveness contract.
Smallest GREEN acceptance: preserve fail-closed exact-head semantics; record a durable authenticated dispatch/phase receipt bound to repository/PR/head, do not consume the substantive OpenCode-verdict budget before the central worker has actually started and prerequisite state can be evaluated, and require a real formal
opencode-agentAPPROVEDorCHANGES_REQUESTEDreview on that same exact head before the target required verifier can pass. A prerequisiteWAIT, status-only record, or synthetic fallback must remain non-passing.- target PR/head:
Orgmetra #59 independent RED: target waiter exhausted while its accepted central scheduler dispatch never left queue
Fresh unchanged-head evidence from
ContextualWisdomLab/Orgmetra#59@f361012212d4c90e20acb9edaa5302850a340573isolates the liveness failure before any substantive OpenCode execution.Target required workflow
33279409143, attempt 2, job99688748116started at2026-09-01T01:30:03Z. Its authenticatedRequest current-head OpenCode review executionstep succeeded at01:30:06Z, POSTing themerge-schedulerrepository dispatch. The target then polled the Reviews API for a real exact-headopencode-agentAPPROVEDorCHANGES_REQUESTEDverdict for 180 × 30 seconds and failed at03:02:01Zbecause none materialized.The corresponding central dispatch window materialized
Required PR Review Merge Schedulerruns33458985379(created01:30:08Z) and33458986030(created01:30:09Z) on central policy SHA1186a9f4e5eda7683b23ae63d2c806831743432a. Fresh refetch after the target waiter had already failed still shows both runsqueued; in each run the causalscan-pr-queuejob (99704928025/99704929696) is itself stillqueued, while the other jobs are skipped. In other words, an accepted target dispatch had no opportunity to inspect exact-head Strix/prerequisite state or dispatch substantive OpenCode before the target's entire ~90-minute verdict window expired.This is stronger than a model/provider failure and independently reproduces the phase-budget defect already captured by the #56/#57 canaries: the target verifier's substantive-verdict timeout is not coupled to an actually-started central worker or prerequisite-ready phase. There is no correct Orgmetra-local source repair or no-op head change for this.
RED acceptance: target exact-head dispatch succeeds; central scheduler run/job remains queued past the target verdict budget; no exact-head formal review can possibly materialize; target fails closed.
Smallest GREEN semantics remain: preserve fail-closed exact-head Strix and formal-review requirements, but bind the required-check lifetime to durable authenticated phase/receipt state so queue/prerequisite time does not consume the substantive OpenCode verdict budget. A target may pass only after a real exact-head formal
opencode-agentverdict exists; queued/pending/WAIT/status-only/model-only evidence stays non-passing. After the owner repair reaches protected centralmain, validate with a fresh central event on unchanged Orgmetra #59 head rather than rerunning an old trusted workflow snapshot.Fresh independent canary from
ContextualWisdomLab/Orgmetra#40removes the earlier coverage ambiguity from this review-delivery lane.- target PR exact head:
6917e41f9053fab6f7e99f8185f2137e8fc5fca5; live base:develop@9e3e4847510e1e612b48474ba42b177b8ed824df - current exact-head
coverage-source-treecheck99422518429: SUCCESS - current exact-head
coverage-evidencecheck99422518803: SUCCESS - required OpenCode job
99422517837: FAILURE - that job successfully obtained OIDC, exchanged a repository-scoped App token, and dispatched the central scheduler; it then polled exact-head formal reviews for 180×30s and failed only because no authenticated
opencode-agentAPPROVEDorCHANGES_REQUESTEDverdict arrived before the window expired - the earlier OpenCode
COMMENTED/COVERAGE_BLOCKEDreview is therefore stale as a diagnosis and remains non-authoritative; Orgmetra's current coverage evidence itself is green
This is not an Orgmetra source/coverage repair candidate. Please use this unchanged-head canary for the scheduler/verdict-delivery acceptance already tracked here: prerequisite/queue time must not consume the substantive verdict window, and GREEN requires a qualifying authenticated formal verdict on the same
6917e41f…head without a no-op consumer commit or gate weakening.- target PR exact head:
Fresh independent unchanged-head canary from
ContextualWisdomLab/Orgmetra#42confirms the current OpenCode failure is no longer the earlier coverage-wrapper diagnosis.- target exact head:
fb03c0837b38424412fa774576a8ded0f9847896; live base:develop@9e3e4847510e1e612b48474ba42b177b8ed824df coverage-source-treecheck99423491065: SUCCESScoverage-evidencecheck99423453333: SUCCESS- required OpenCode job/check
99423452804: FAILURE - the job successfully obtained OIDC, exchanged a repository-scoped App token, and dispatched the central scheduler, then polled the exact head for 180×30 seconds; it failed only because no authenticated
opencode-agentAPPROVEDorCHANGES_REQUESTEDformal review arrived - the historical
COMMENTED/COVERAGE_BLOCKEDreview remains non-authoritative and its coverage diagnosis is stale on this unchanged head
No correct Orgmetra source/coverage repair remains at this boundary. Please include #42 as another RED→GREEN acceptance canary for the existing scheduler/verdict-delivery contract: prerequisite/queue time must not consume the substantive verdict window, and GREEN requires a qualifying authenticated formal verdict on this same exact head without a no-op consumer commit, gate weakening, or predecessor evidence.
- target exact head:
Problem
Zero PRs are currently mergeable in
ContextualWisdomLab/fast-mlsirm(60 open) orContextualWisdomLab/LineageWeave(12 open) because the required branch-protection review (required_approving_review_count: 1) has not been satisfied by any bot on any current-head PR in either repo (reviewDecisionisREVIEW_REQUIRED,CHANGES_REQUESTED, or empty on every open PR — noneAPPROVED). PR authors cannot self-approve (GitHub platform rule), so this is a hard blocker on the whole PR backlog in both repos, not a per-PR defect.Investigated via
gh run view/gh api .../check-runs/.../annotationson recentopencode-review-dispatch.ymland*-hourly-review-repair.ymlruns. Three independent, concrete root causes found:1. LineageWeave's
uv.lockcannot be hash-pinned because two dependencies are git-sourcedscripts/ci/materialize_base_python_requirements.pyrequires the base branch'suv.lockto export as a fully hash-pinned requirements closure before the sandboxedcoverage-evidencejob (and therefore the whole approval decision) can run. LineageWeave'suv.lockpinsfast-mlsirmandRankWeaveviasource = { git = "https://github.com/ContextualWisdomLab/....git?rev=<sha>#<sha>" }.uv exportcannot emit a--hash=sha256:...for a git dependency (there is no fixed sdist/wheel artifact to hash — installing from git means running the package's build backend), so every export of LineageWeave'smainlock fails_is_fully_hash_pinned_requirement, and_export_uv_lockraises"uv export for tracked base lock uv.lock was not fully hash-pinned". Every dispatch run against a LineageWeave PR fails at thecoverage-evidencejob for this reason (confirmed on PR #373, #387, #258, #349 dispatch runs 2026-08-21 21:3x UTC), regardless of what the PR itself changes.Reproduced: LineageWeave's pinned
fast-mlsirmcommit (5006c38...) is 477 commits ahead of the latest tagged release (v0.6.0), andfast-mlsirm'srelease-tag.ymlonly runsgh release create— it does not build or attach an installable sdist/wheel asset, and the package is not published to PyPI (pypi.org/pypi/fast-mlsirm/json→ 404) despite the org'sPYPI_API_KEYsecret already being available. Same shape of problem likely applies toRankWeave.Recommended fix (do not relax the sandbox's hash-pinning requirement — that requirement is a real supply-chain control, since installing an unpinned/unhashed git dependency in an untrusted-PR sandbox means running arbitrary build-backend code from a mutable ref class):
maturin build --release(or equivalent) step tofast-mlsirm's andRankWeave's release workflow that builds sdist + wheels and attaches them as GitHub Release assets (or publishes to PyPI using the existingPYPI_API_KEY).pyproject.tomlentries forfast-mlsirm/RankWeavefromgitsources to a versioned PyPI dependency (or a direct release-asset URL dependency, whichuvcan hash), then regenerateuv.lock.2. Cross-repo
opencode-reviewstatus publish always fails with 403In
opencode-review-dispatch.yml, the step that publishes the optionalopencode-reviewcommit status back to the target repo (e.g.repos/ContextualWisdomLab/LineageWeave/statuses/<sha>) using theopencode-appexchanged token fails every time withgh: Resource not accessible by integration (HTTP 403)(confirmed on runs againstappguardrail#969,LineageWeave#373). The OpenCode GitHub App does not appear to havestatuses:writegranted on these target repos, or is not installed there with that permission. This step is non-authoritative (the doc string says "the exact-head formal review remains authoritative") but it fails loudly on every run and wastes a job step; either grant the App the permission on all org repos it dispatches to, or drop the step.3. Review-dispatch throughput is far below the PR creation rate
fast-mlsirm-hourly-review-repair.yml(and the genericpr-review-merge-scheduler.yml) invokescripts/ci/pr_review_fix_scheduler.py/pr_review_merge_scheduler.pywithMAX_DISPATCHES: 1per run, i.e. at most ~1 new review dispatch per repo per scheduled run. Against a backlog of 60 open PRs infast-mlsirmalone, this cannot keep the queue current even before accounting for root cause #1 above. Separately, the scheduler's own GitHub GraphQL calls (listing open PRs) intermittently fail after only 3 retries with a 1s/2s/4s backoff (Transient GitHub GraphQL error on attempt 1..3/4), aborting the entire scheduled run with no partial progress (confirmed failures at 2026-08-21T22:00 and 21:01 UTC forfast-mlsirm). Recommend widening the retry budget/backoff for transient GraphQL errors before concluding failure, and revisitingMAX_DISPATCHESonce root cause #1 is fixed and the backlog is under control (raising throughput without fixing #1 would just burn compute on runs that fail atcoverage-evidenceanyway).Evidence
gh run view 32529248149 --repo ContextualWisdomLab/.github(LineageWeave#373 dispatch,coverage-evidencefailure annotation:Could not materialize base Python locks: uv export for tracked base lock uv.lock was not fully hash-pinned)gh run view 32531069679 --repo ContextualWisdomLab/.github(fast-mlsirm-hourly-review-repair,Transient GitHub GraphQL errorx3 then abort)gh run view 32536566379 --repo ContextualWisdomLab/.github(cross-repo status 403 againstappguardrail#969)gh pr list --repo ContextualWisdomLab/fast-mlsirm --state open --json reviewDecision/ same forLineageWeave: zeroAPPROVEDamong 72 combined open PRs.Suggested scope for follow-up PRs (do not bundle into one PR)
fast-mlsirm,RankWeave: add release-asset (or PyPI) publishing to the release workflow.LineageWeave: once (1) ships a release, switch the two git-sourcedpyproject.tomlentries to the released, hash-pinnable versions and regenerateuv.lock..github: fix or remove the cross-repoopencode-reviewstatus-publish step (403)..github: widen the scheduler's GraphQL retry budget; revisitMAX_DISPATCHESafter (1)-(2) land.