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

[cursor]

A caller-selected workflow_dispatch Deep run can publish the same Strix check name for up to six hours. Required merge evidence stays pull_request_target and repository_dispatch strix-scan.

What to do next

Review this slice on its own. Do not fold it into #1054 (official quick|standard|deep mapping). After this lands, a manual Deep scan on a PR head will not park, fail, or satisfy the merge scheduler.

Keep #1054 as the only mode-mapping vehicle. After exact-head quality is green there, add the doctoring residual-risk sentences on that branch.

Change

• Read checkSuite.workflowRun.event and ignore workflow_dispatch check runs in Strix merge evidence, failed-check collection, action-required, and job reruns.
• A completed required Strix check run wins over a later pending strix commit status.
• Non-central active_review_run_refs skips same-head Deep runs so they cannot return already_running and block strix-scan.
• A successful strix commit status can still supersede a failed required check.

Doctoring: docs/doctoring/strix-manual-dispatch-not-merge-evidence.md (APA 7th).

Local evidence: pytest tests/test_pr_review_merge_scheduler.py tests/test_required_workflow_queue_contract.py — 161 passed; interrogate 100% on the scheduler module.

  

[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