fix(strix): map official modes without branch-selected dispatch

[cursor]

Prefer this over #1054.

Why

#1054 correctly maps official Strix CLI modes (quick, standard, deep) and stops every trigger inheriting Quick. It also restores workflow_dispatch on the privileged org-required strix.yml. GitHub's manual UI/API lets the caller select a branch, and that revision supplies the workflow YAML (id-token: write plus statuses: write for the strix commit-status context) before any in-job trusted-source checkout can run. A feature-branch dispatch can skip the scan and publish a fake passing strix status. The same class of defect already failed test_no_central_workflow_exposes_branch_selected_manual_dispatch on the quality job (docs/doctoring/strix-legal-git-paths.md).

What landed

• Keep the dual-flow mapping: required pull_request_target / repository_dispatch / push to develop stay Quick; push to main/master and the Monday 03:00 UTC schedule use Standard with the existing 120/100/90/95 budget.
• Do not restore workflow_dispatch, release:, v*-rc*, or client_payload.scan_mode on this privileged file.
• Leave Deep unwired here. A later pre-production Deep path must be a separately reviewed default-branch-only dispatcher.
• Keep the gate allowlist quick|standard|deep and reject normal.
• Record the trusted-source boundary and official scan-mode citations in docs/doctoring/strix-scan-mode-dual-flow.md (APA 7th; Strix, n.d.; NIST SP 800-218; CWE-345).

Next action

Review and merge this head. Do not merge #1054. Do not add workflow_dispatch back onto strix.yml to recover Deep.

Evidence

• python3 -m pytest tests/test_strix_scan_mode_policy.py tests/test_required_workflow_queue_contract.py tests/test_strix_workflow_dependency_hashes.py tests/test_strix_changed_path_policy.py tests/test_strix_quality_timeout_fixture_budget.py — 89 passed
• bash scripts/ci/strix_required_workflow_smoke.sh — passed

  

[seonghobae]

Rebased onto current origin/main c47bee5 and retained the official Strix mode mapping without branch-selected dispatch.

Current HEAD: 9f35847

Validation on this HEAD:

• pytest -q tests/test_strix_scan_mode_policy.py tests/test_required_workflow_queue_contract.py: 75 passed
• bash -n for the touched Strix scripts passed
• actionlint and git diff --check passed

@OpenCode review this exact HEAD after the rebase.

[seonghobae]

@opencode-agent

Rebased PR #1062 onto current protected main and revalidated the dual Strix scan-mode contract.
Exact current head: 74079e5

The privileged Strix workflow keeps required pull_request_target/repository_dispatch/push-to-develop on Quick, schedules and main/master pushes on Standard, rejects branch-selected workflow_dispatch, and leaves Deep unwired until a separately reviewed default-branch dispatcher exists.

Proof at this exact head: 89 tests plus 16 subtests passed; Strix required-workflow smoke passed; actionlint, bash syntax, compileall, and git diff --check passed.

The PR remains Draft. Please obtain independent exact-head review and protected Checks before changing readiness or merging; no bypass or merge is claimed.

[seonghobae]

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

This PR's base commit 2cce96f8671bfde7e354effef931c14a5928c23b is not an ancestor of current main:

$ git merge-base --is-ancestor 2cce96f8671bfde7e354effef931c14a5928c23b 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): worth checking first whether .github/workflows/strix.yml on current main already maps quick/standard/deep correctly without a branch-selectable workflow_dispatch — companion PR #1054 was itself closed unmerged around the same time this history diverged. If the gap is still real, reimplement as a fresh branch cut from current main; this is a privileged required workflow so any redo needs careful review of the trust boundary this PR describes. 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