[jonahgabriel]

Problem

ci.yml's test and type-check jobs carried:

if: needs.zone-filter.outputs.docs_only != 'true' && (github.event_name != 'pull_request' || github.base_ref != 'dev')

For a non-docs-only pull_request event targeting dev (the everyday case — dev is this repo's default branch), that condition is false, so both jobs were unconditionally skipped on every ordinary dev-targeting PR. The smart-test-select job appears to have been meant to cover that path instead (its if: is the exact complement: github.event_name == 'pull_request' && github.base_ref != 'dev' && ...), but nothing downstream ever consumed its selected_paths/split_count/matrix/is_full_suite outputs — no job in ci.yml carried needs: smart-test-select. It computed a selection and discarded it. ci-summary's generic rollup (contains(needs.*.result, 'failure') || contains(needs.*.result, 'cancelled')) does not catch skipped, so both jobs read as passing.

Net effect: zero unit tests and zero type-checking ran on essentially all normal OCC dev traffic.

Provenance

Git-blamed and confirmed via git show:

• The base_ref != 'dev' carve-out on test/type-check, and the matching if: on smart-test-select, were both introduced by e5048f853c3346389f264a3fa2953724ee90057e (OMN-14098 / PR ci(OMN-14098): OCC evidence-only fast-lane — docs_only-gated code analysis + CodeQL skip-with-success (canary: onex_change_control) #3665, 2026-07-07, "OCC evidence-only fast-lane"). Before that commit, both jobs ran unconditionally modulo the pre-existing docs_only fast lane — that commit's own message even notes "(type-check + test were already gated on docs_only.)"; the base_ref clause was new there.
• smart-test-select itself predates that commit (7166bbd22, OMN-10763, change-aware-selection port), but its output was never consumed by test even before OMN-14098 — test has always run the unfiltered uv run pytest --cov=onex_change_control ... regardless of what the selector computed. So the underlying "selector output goes nowhere" gap existed since the selector's introduction; OMN-14098 additionally made the skip total by gating test/type-check themselves off on dev PRs.

Fix

Simplest fail-closed shape, per CLAUDE.md rule 4's dev-boundary default (OCC's suite is small, so full-suite-on-dev matches the fail-closed default until a governed selector is deliberately wired — a separate follow-up, not a silent-skip default):

1. Removed the base_ref != 'dev' carve-out from test's and type-check's if: — both now run on every non-docs-only PR (restores pre-OMN-14098 shape).
2. Deleted the orphaned smart-test-select job rather than wire it. It was never consumed; keeping a decoy job that looks like it's doing something is worse than deleting it.
3. Added an explicit strict success-only check for test/type-check in ci-summary, mirroring the OMN-15484 (merge-hold-gate) pattern. This is not a bare "must be success" check — test/type-check are legitimately skipped on docs-only PRs (the OMN-14098 evidence-only fast lane), so the new block distinguishes that skip from an illegitimate one via needs.zone-filter.outputs.docs_only.

Dev-tip audit (per ticket instruction — check for latent breakage this hole allowed)

Full local run on origin/dev @ c9b86d152 (before this fix), in worktree omni_worktrees/OMN-15731-testfix/onex_change_control:

• uv run pytest tests/ -q → 5915 passed, 47 skipped, 0 failed
• uv run mypy src/ tests/ → Success: no issues found in 396 source files

Both clean. No dev-tip test repair is carried in this PR's payload — the CI hole did not (as of this audit) let a real regression slip through, but it was fully capable of doing so silently.

New regression test

tests/unit/scripts/test_test_typecheck_wiring_omn15731.py renders the real ci-summary bash block out of the shipped ci.yml (not a hand-built fixture) and executes it under bash:

• both test/type-check success → passes
• either job skipped/failure/cancelled outside the docs-only lane → fails closed, names OMN-15731
• both skipped with docs_only == 'true' → still passes (the legitimate fast lane)
• RED-before control: stripping only the new strict block (leaving the jobs in needs:) restores the exact pre-fix bypass — the generic rollup alone reports "All required jobs passed" on a skipped test/type-check
• asserts the base_ref carve-out and the smart-test-select job are gone from the live file

13/13 pass locally; uv run mypy src/ tests/ and uv run ruff check/format clean on the new file.

Tracking ticket

OMN-15755 — filed by the OMN-15731 label-gated-CI pilot lane after it independently found and explicitly scoped out this exact gap while building OCC#6216 (see OMN-15755's "Related" section for the disclosure chain). This PR is the direct code fix that ticket asks for.

Interaction with OCC#6216 (OMN-15731 pilot)

OCC#6216 has open ci.yml changes in flight (label-gates pre-commit for ci:ready, adds a Pre-commit strict block in ci-summary) touching a different job in the same file. Based on origin/dev; whichever PR lands second should rebase onto the other's ci-summary shape.

Evidence-Ticket: OMN-15755
Evidence-Source: OCC#6222

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 41 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 8555e977-9d14-455a-a623-afe536ba2464

📥 Commits

Reviewing files that changed from the base of the PR and between e6d94bd and c06b4ce.

📒 Files selected for processing (2)

• .github/workflows/ci.yml
• tests/unit/scripts/test_test_typecheck_wiring_omn15731.py

---

_{Comment @coderabbitai help to get the list of available commands.}