fix(scheduler): ignore manual Strix dispatch as merge evidence

[cursor]

Current exact authority

• exact head: 3840dfeef7a4f4b7c7a3db94ddb64d814288193c
• protected base: main@c9052e607e5f3cc76e73207e7786b21500721b79
• lifecycle: Draft / Proposed
• ancestry: normal merge commit 52964015a6c4161c987d7fe6403dfb4d0f2621f6 preserves the former branch as first parent and protected main as second parent; compare is 9 ahead / 0 behind with merge base exactly protected main
• effective delta: five owner paths only; the stale README/ARCHITECTURE/CLAUDE and pip-lock changes from the historical branch are not replayed

Root cause and repair

A caller-selected workflow_dispatch Strix run can use the same workflow and job display names as required pull_request_target or repository_dispatch evidence. The scheduler deduplicated CheckRuns by workflow and job names, so a newer manual Deep run could hide the required attempt before authority filtering.

The current repair:

• reads checkSuite.workflowRun.event in both initial and paginated GraphQL context queries;
• keys CheckRun attempts by workflow, job, and event;
• excludes manual Strix CheckRuns from Strix evidence, failed-check collection, ACTION_REQUIRED collection, rerun-job selection, and active-run suppression;
• preserves manual non-Strix failures, ACTION_REQUIRED checks, and active runs as scheduler authority;
• preserves missing-event fail-closed behavior;
• preserves a successful classic strix status as the existing bounded reviewer signal; it still cannot replace GitHub's required CheckRun at merge time.

RED → GREEN lineage

• 7da25ace5faab731b73e9e251e7b3cc93399413e: permanent Strix regression, doctoring, CHANGELOG, and Gap baseline on current main
• 9819fb782611153c0039da1a4b108c161e3a2b84: causal scheduler implementation
• 373f0e782e65f1d8393484bb412a4e42f3457a42: public-doc identity alignment
• f27cf2ba0b2a72a16cbfa04b5d4260623dd7e2f6: follow-up RED proving non-Strix manual authority must remain visible
• 3840dfeef7a4f4b7c7a3db94ddb64d814288193c: scopes the exclusion to Strix and aligns current docs

The permanent regressions cover newer-manual-versus-required deduplication, rerun selection, ACTION_REQUIRED debt, active-run suppression, and the non-Strix preservation boundary.

Verification boundary

Remote readback confirms the exact five-file delta, current-main ancestry, source scope guard, and permanent regression contents. Fresh exact-head SAST Semgrep, Agent Review Runtime Quality CI, Security Scan, Python Security, and CodeQL PR runs are queued. There are no unresolved review threads, but no independent approval or hosted GREEN is claimed. No ordinary merge, auto-merge, predecessor-evidence transfer, synthetic status, bypass, force update, or release is claimed.

Doctoring: docs/doctoring/strix-manual-dispatch-not-merge-evidence.md. Gap status remains Proposed until unchanged-head hosted checks, independent review, ordinary protected integration, and post-merge current-main verification complete.

[seonghobae]

Rebased onto current origin/main c47bee5 and preserved the manual Strix-dispatch exclusion from merge evidence.

Current HEAD: 30f79bc

Validation on this HEAD:

• pytest -q tests/test_pr_review_merge_scheduler.py: 111 passed
• interrogate: 100%
• compileall and git diff --check passed

@OpenCode review this exact HEAD after the rebase.

[seonghobae]

@opencode-agent

Rebased PR #1061 onto current protected main and revalidated the manual-Strix evidence boundary.
Exact current head: 3865b1f

workflow_dispatch Strix runs are excluded from merge evidence, while required pull_request_target/repository_dispatch evidence remains authoritative; completed required Strix runs take precedence over later pending statuses, and active manual runs cannot block the required path.

Proof at this exact head: 161 scheduler/queue tests passed; interrogate 100%; compileall and git diff --check passed.

The PR remains Draft. Please rerun independent review and protected current-head Checks before readiness or merge; no bypass or merge is claimed.

[seonghobae]

Current-head merge repair pushed normally at 31576af6 after reconciling the stale main base. The README conflict preserved both standalone/composable operating modes and the exact-head/manual-Strix governance evidence. Please observe Checks for this exact head; no merge bypass is used.

[seonghobae]

Exact-head lock repair pushed as 03c0878 from 31576af. Updated the hashed pip audit runtime from pip 26.1.2 to pip 26.2.1 with exact hashes, without changing the hourly caller implementation. The same lock has already passed local pip-audit in this maintenance loop; hosted checks and exact-head approval must be re-evaluated. No bypass or force push was used.

[seonghobae]

Triage (2026-09-02): base history is orphaned, not a resolvable merge conflict

This PR's base commit 55a8b576725451dfe0a21a57d36a2f1a41619b24 is not an ancestor of current main:

$ git merge-base --is-ancestor 55a8b576725451dfe0a21a57d36a2f1a41619b24 origin/main && echo yes || echo no
no
$ git merge origin/main --no-edit
fatal: refusing to merge unrelated histories

origin/main now has multiple historical roots (a restructuring/history-splice happened after this branch was cut from an older main), so there is no common ancestor for an ordinary 3-way merge. Forcing --allow-unrelated-histories would diff every shared file against an empty tree and manufacture spurious conflicts across the whole tree — not a real fix, and not something to push through mechanically.

The mergeable_state: dirty GitHub reports here reflects that structural gap, not a normal content conflict this session's usual merge-main-and-resolve recipe can repair.

Next action (needs a human/design call): reimplement the intent (ignore workflow_dispatch Strix runs as merge evidence) as a fresh branch cut from current main — worth checking first whether .github/workflows/pr-review-merge-scheduler.yml / its Python helpers on current main already handle this, since companion PR #1054 was itself closed unmerged around the same time this history diverged. Not closing this myself since I haven't verified current-main state.

---

Generated by Claude Code

[seonghobae]

Retraction — the "main history splice" diagnosis was wrong.

An earlier comment on this PR claimed main's history was spliced onto new roots around 2026-08-20/21, that this PR's base predates the boundary, and that an ordinary merge would fail with fatal: refusing to merge unrelated histories requiring a from-scratch re-implementation. That diagnosis is incorrect — please disregard it entirely.

Root cause: the analysis was run from a shallow git clone in the analysis sandbox (git rev-parse --is-shallow-repository → true). A shallow clone's truncation boundary commits look exactly like disjoint history roots, and git merge from inside a shallow checkout genuinely does throw fatal: refusing to merge unrelated histories even when the real, full history is perfectly linear and connected. After git fetch --unshallow, origin/main has exactly one root commit, and this PR's base is a completely normal ancestor of current main.

This PR should be triaged the ordinary way: fetch a full (non-shallow) clone, git fetch origin main && git merge origin/main --no-edit, resolve any real content conflicts, run the repo's gates, and push. There is no history-splice blocker and no need to abandon or re-implement this PR's work.

Apologies for the incorrect guidance. See #1722 for the corrected writeup.

---

Generated by Claude Code