[Review pipeline] Zero PRs mergeable in fast-mlsirm/LineageWeave: hash-pinning, cross-repo status 403, dispatch throughput

[seonghobae]

Problem

Zero PRs are currently mergeable in ContextualWisdomLab/fast-mlsirm (60 open) or ContextualWisdomLab/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 (reviewDecision is REVIEW_REQUIRED, CHANGES_REQUESTED, or empty on every open PR — none APPROVED). 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/.../annotations on recent opencode-review-dispatch.yml and *-hourly-review-repair.yml runs. Three independent, concrete root causes found:

1. LineageWeave's uv.lock cannot be hash-pinned because two dependencies are git-sourced

scripts/ci/materialize_base_python_requirements.py requires the base branch's uv.lock to export as a fully hash-pinned requirements closure before the sandboxed coverage-evidence job (and therefore the whole approval decision) can run. LineageWeave's uv.lock pins fast-mlsirm and RankWeave via source = { git = "https://github.com/ContextualWisdomLab/....git?rev=<sha>#<sha>" }. uv export cannot 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's main lock fails _is_fully_hash_pinned_requirement, and _export_uv_lock raises "uv export for tracked base lock uv.lock was not fully hash-pinned". Every dispatch run against a LineageWeave PR fails at the coverage-evidence job 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-mlsirm commit (5006c38...) is 477 commits ahead of the latest tagged release (v0.6.0), and fast-mlsirm's release-tag.yml only runs gh 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's PYPI_API_KEY secret already being available. Same shape of problem likely applies to RankWeave.

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):

• Add a maturin build --release (or equivalent) step to fast-mlsirm's and RankWeave's release workflow that builds sdist + wheels and attaches them as GitHub Release assets (or publishes to PyPI using the existing PYPI_API_KEY).
• Cut a release close to the commit LineageWeave currently depends on.
• Switch LineageWeave's pyproject.toml entries for fast-mlsirm/RankWeave from git sources to a versioned PyPI dependency (or a direct release-asset URL dependency, which uv can hash), then regenerate uv.lock.

2. Cross-repo opencode-review status publish always fails with 403

In opencode-review-dispatch.yml, the step that publishes the optional opencode-review commit status back to the target repo (e.g. repos/ContextualWisdomLab/LineageWeave/statuses/<sha>) using the opencode-app exchanged token fails every time with gh: Resource not accessible by integration (HTTP 403) (confirmed on runs against appguardrail#969, LineageWeave#373). The OpenCode GitHub App does not appear to have statuses:write granted 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 generic pr-review-merge-scheduler.yml) invoke scripts/ci/pr_review_fix_scheduler.py / pr_review_merge_scheduler.py with MAX_DISPATCHES: 1 per run, i.e. at most ~1 new review dispatch per repo per scheduled run. Against a backlog of 60 open PRs in fast-mlsirm alone, 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 for fast-mlsirm). Recommend widening the retry budget/backoff for transient GraphQL errors before concluding failure, and revisiting MAX_DISPATCHES once root cause #1 is fixed and the backlog is under control (raising throughput without fixing #1 would just burn compute on runs that fail at coverage-evidence anyway).

Evidence

• gh run view 32529248149 --repo ContextualWisdomLab/.github (LineageWeave#373 dispatch, coverage-evidence failure 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 error x3 then abort)
• gh run view 32536566379 --repo ContextualWisdomLab/.github (cross-repo status 403 against appguardrail#969)
• gh pr list --repo ContextualWisdomLab/fast-mlsirm --state open --json reviewDecision / same for LineageWeave: zero APPROVED among 72 combined open PRs.

Suggested scope for follow-up PRs (do not bundle into one PR)

1. fast-mlsirm, RankWeave: add release-asset (or PyPI) publishing to the release workflow.
2. LineageWeave: once (1) ships a release, switch the two git-sourced pyproject.toml entries to the released, hash-pinnable versions and regenerate uv.lock.
3. .github: fix or remove the cross-repo opencode-review status-publish step (403).
4. .github: widen the scheduler's GraphQL retry budget; revisit MAX_DISPATCHES after (1)-(2) land.

[seonghobae]

Progress on recommended-fix item 1 (fast-mlsirm/RankWeave release-asset publishing): opened ContextualWisdomLab/fast-mlsirm#1207, which adds a publish-pypi.yml workflow (sdist + linux/macos/windows wheels via maturin-action, published to PyPI + attached as release assets on release: 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/RankWeave git-source uv.lock entries 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. RankWeave still needs the equivalent workflow — not done yet, tracking as follow-up.

[seonghobae]

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 working publish.yml (trusted-publisher/OIDC based, no token secrets needed) — but PyPI currently only has 0.1.0 published while LineageWeave's git pin is exact-identical to RankWeave's v0.18.0 tag (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.0

This is a PyPI project-settings problem (Trusted Publisher config on the rankweave PyPI project no longer matches the repo/workflow/environment claims RankWeave's Actions run presents) — not something fixable from the GitHub side or via gh/git. It needs whoever administers the rankweave PyPI project to fix/re-add the trusted publisher at https://pypi.org/manage/project/rankweave/settings/publishing/ (matching repo ContextualWisdomLab/RankWeave, workflow publish.yml, environment pypi), then re-run publish.yml (workflow_dispatch with release_tag=v0.18.0) to catch PyPI up.

Once that's done, LineageWeave's RankWeave git-source uv.lock entry can switch to rankweave==0.18.0 from PyPI immediately (no code/build work needed on RankWeave's side, unlike fast-mlsirm).

[seonghobae]

New finding via static analysis (actionlint): pr-review-fix-scheduler.yml's "Resolve immutable called-workflow source" step references a nonexistent context, unconditionally fails

Ran 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_path are not properties of the GitHub Actions job context (which only exposes container, services, and status). 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_REPOSITORY is always "" and $expected_repository is "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.yml runs from 2026-08-16 (older workflow revision, before this step existed — job logs show only pr_review_fix_scheduler.py --self-test, no "Resolve immutable..." step). The step first appears in the 2026-08-20 repository_dispatch-triggered runs (32360044573 failure, 32360412990 cancelled) — 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, and pr-auto-rebase.yml do not contain this pattern (checked via the same actionlint/grep pass) — the blast radius looks isolated to pr-review-fix-scheduler.yml's repository_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 are github.workflow_ref / github.workflow_sha (current workflow file's ref/SHA) and, for a workflow invoked as a reusable workflow via uses:, github.job_workflow_ref / github.job_workflow_sha on the caller's side. Whoever owns this script should confirm which of those (or a different mechanism entirely, e.g. parsing github.workflow_ref server-side) was actually intended before changing it, since the four-way split (repository/sha/ref/file_path) suggests the author meant to parse a combined owner/repo/.github/workflows/file.yml@ref string 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,createdAt
• gh 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)

[seonghobae]

Opened #1221 for root cause #3 (the actionlint-caught nonexistent job.workflow_* context references in pr-review-fix-scheduler.yml). Also found and fixed the same broken pattern in exact-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 via gh attestation verify rather than silently bypassing signer verification. Full test suite green (1330 passed / 1 skipped, unrelated env-only failure).