Summary
`strix` is a required status check in `main`'s branch protection (`repos/{org}/.github/branches/main/protection` → `required_status_checks.contexts` includes `strix`). It is produced only by `.github/workflows/strix.yml`'s `strix` job, which is gated by a workflow-level `paths-ignore` on both its `push` and `pull_request_target` triggers (markdown, common image extensions, LICENSE*, COPYING, `.github/ISSUE_TEMPLATE/**`).
When every file in a PR's diff matches those ignored paths, the entire `strix.yml` workflow run is skipped by GitHub (not just the job — `paths-ignore` at the trigger level skips the whole run), so no `strix` check-run or status is ever posted for that commit. Branch protection then shows the required `strix` context as permanently pending/"Expected", and the PR can never satisfy required-status-checks — `gh pr merge` fails with "the base branch policy prohibits the merge" even after every other required check is green.
This is a known GitHub gotcha specifically with `pull_request_target` + `paths-ignore` + required checks: GitHub's native "mark skipped required checks as passing" auto-behavior is documented to work reliably for `pull_request`/`push`-triggered workflows, not `pull_request_target`.
Reproduction
PR #1024 ("docs(ai): standardize adaptive contextual-orchestrator consumers") changes only:
- `AGENTS.md`
- `docs/doctoring/contextual-orchestrator-consumer-contract.md`
- `docs/standards/contextual-orchestrator-consumer-contract.md`
All three match `strix.yml`'s `paths-ignore: ['**/*.md', ...]`. Confirmed via:
```
gh api repos/ContextualWisdomLab/.github/commits//check-runs --jq '.check_runs[] | select(.name=="strix")'
```
→ zero results, even though every other required check (CodeQL, osv-scan, scorecard, noema-review, opencode-review, coverage-evidence, etc.) is green.
Existing partial mitigation
`strix.yml` already has a `publish-manual-pr-evidence-status` job that posts a synthetic `strix` status — but only for `github.event_name == 'repository_dispatch'` (cross-repo dispatch use case). There is no equivalent fallback for same-repo `pull_request_target` runs skipped by `paths-ignore`.
Suggested fix (not applied here — flagging for review before implementation)
A small, separate workflow (no shared trigger/path filter with `strix.yml`, so it always runs on `pull_request_target`) that:
- Reads the PR's actual changed-file list via the GitHub API (not a static path guess).
- If every file matches the exact same ignore patterns `strix.yml` uses, posts a synthetic `success` status with `context: strix`.
- Otherwise does nothing and lets the real `strix` job's own result stand.
Flagging this as a suggested design rather than opening the PR directly: this logic sits right next to a security-scan trust boundary, and the ignore-pattern list would need to be kept byte-for-byte in sync with `strix.yml`'s own `paths-ignore` (in both its `push` and `pull_request_target` blocks) to avoid silently marking a real, unscanned diff as "passed" if the two lists ever drift. That synchronization mechanism deserves its own review rather than a rushed same-session fix.
Impact
Currently blocks: #1024. Will silently and permanently block any future doc/image-only PR against `.github` until fixed.
Summary
`strix` is a required status check in `main`'s branch protection (`repos/{org}/.github/branches/main/protection` → `required_status_checks.contexts` includes `strix`). It is produced only by `.github/workflows/strix.yml`'s `strix` job, which is gated by a workflow-level `paths-ignore` on both its `push` and `pull_request_target` triggers (markdown, common image extensions, LICENSE*, COPYING, `.github/ISSUE_TEMPLATE/**`).
When every file in a PR's diff matches those ignored paths, the entire `strix.yml` workflow run is skipped by GitHub (not just the job — `paths-ignore` at the trigger level skips the whole run), so no `strix` check-run or status is ever posted for that commit. Branch protection then shows the required `strix` context as permanently pending/"Expected", and the PR can never satisfy required-status-checks — `gh pr merge` fails with "the base branch policy prohibits the merge" even after every other required check is green.
This is a known GitHub gotcha specifically with `pull_request_target` + `paths-ignore` + required checks: GitHub's native "mark skipped required checks as passing" auto-behavior is documented to work reliably for `pull_request`/`push`-triggered workflows, not `pull_request_target`.
Reproduction
PR #1024 ("docs(ai): standardize adaptive contextual-orchestrator consumers") changes only:
All three match `strix.yml`'s `paths-ignore: ['**/*.md', ...]`. Confirmed via:
```
gh api repos/ContextualWisdomLab/.github/commits//check-runs --jq '.check_runs[] | select(.name=="strix")'
```
→ zero results, even though every other required check (CodeQL, osv-scan, scorecard, noema-review, opencode-review, coverage-evidence, etc.) is green.
Existing partial mitigation
`strix.yml` already has a `publish-manual-pr-evidence-status` job that posts a synthetic `strix` status — but only for `github.event_name == 'repository_dispatch'` (cross-repo dispatch use case). There is no equivalent fallback for same-repo `pull_request_target` runs skipped by `paths-ignore`.
Suggested fix (not applied here — flagging for review before implementation)
A small, separate workflow (no shared trigger/path filter with `strix.yml`, so it always runs on `pull_request_target`) that:
Flagging this as a suggested design rather than opening the PR directly: this logic sits right next to a security-scan trust boundary, and the ignore-pattern list would need to be kept byte-for-byte in sync with `strix.yml`'s own `paths-ignore` (in both its `push` and `pull_request_target` blocks) to avoid silently marking a real, unscanned diff as "passed" if the two lists ever drift. That synchronization mechanism deserves its own review rather than a rushed same-session fix.
Impact
Currently blocks: #1024. Will silently and permanently block any future doc/image-only PR against `.github` until fixed.