fix(OMN-15413): dod_verify vacuous-pass for stacked PR's deleted non-mainline base branch

[jonahgabriel]

OMN-15413 — dod_verify vacuous-pass for a stacked PR's deleted, non-mainline base branch

Evidence-Ticket: OMN-15413

Scope of this PR (smallest complete increment)

Per operator ruling R-l (2026-08-05T20:40Z, rolling ledger), AC6 was re-scoped from a main-promotion-gated construct to dev-basis dod_verify. The migration-ledger product implementation itself (omnibase_infra#2557/#2547/#2653/#2633/#2632/#2662) is already merged to dev. Re-running dod_verify OMN-15413 live against dev-tip tonight surfaced a mechanical proof-gap in node_dod_verify's shared evidence-collection machinery, not a missing product feature:

status: failed, 15 verified / 8 skipped / 1 superseded / 2 failed

occ-self-bind-infra-pr-2557-merged::pr-live-state:
  OmniNode-ai/omnibase_infra#2557: required checks not green
  (could not resolve required status checks for
   OmniNode-ai/omnibase_infra@jonah/omn-15422-sanitized-legacy-rds-fixture:
   classic=gh: Branch not found (HTTP 404); rules=no names)

dod-omn15413-ac6-no-live-migration-skip::pr-live-state:
  <same cause>

Root cause

HandlerDodEvidenceGithubEffect._fetch_pr_checks_green (OMN-15709, landed same-day) resolves "required status checks" for a PR by reading live branch protection on the PR's base branch. omnibase_infra#2557 is the first hop of a documented two-hop, stacked-PR landing (base = jonah/omn-15422-sanitized-legacy-rds-fixture, a feature branch — content reached dev via the #2547 rollup, independently proven by the contract's dod-omn15413-content-on-dev-via-2547 entry). That base branch was merged and deleted post-merge (normal GitHub cleanup), so branches/{base}/protection/required_status_checks now 404s ("Branch not found") forever — and even before deletion it would have resolved to zero required contexts, because a plain feature branch never carries branch protection in this org (protection is configured only on dev/main).

The handler's _fetch_pr_checks_green conflated "confirmed zero required checks on a non-mainline branch" with "an unresolvable/transient probe error" and failed closed unconditionally — permanently reddening an already-merged, terminal PR's evidence. This is the same unsatisfiable-by-construction anti-pattern OMN-15418 was corrected for, reincarnated one layer down in the shared node_dod_verify auto-appended ::pr-live-state check (which re-verifies live PR state for ANY evidence item whose check_value references a PR, independent of the contract author's own — deliberately frozen — merged-assertion form).

Fix (scoped narrowly)

In _fetch_pr_checks_green: when required_names resolves empty and the base branch is confirmed-absent (a "404" signature in the branch-protection lookup) and the base branch is not dev/main, treat the hop as vacuously satisfied — zero required checks on a non-mainline branch is a true, permanent fact, not an unknown. dev/main stay unconditionally fail-closed regardless of error shape (an unresolvable 404 there is a genuine alarm, never a normal post-merge-cleanup artifact). A non-404, generic resolution failure on a non-mainline branch (timeout, auth, malformed JSON) still fails closed exactly as before — this is not a blanket exemption for stacked PRs, only for the specific confirmed-absence signature.

Seam

• Input seam: ModelDodEvidenceGithubLookupCommand(operation=FETCH_PR_CHECKS_GREEN, repo, pr_number) — unchanged.
• Output seam: ModelDodEvidenceGithubLookupResultEvent.checks_green: bool — unchanged type; only the value changes for the newly-recognized confirmed-absence case, and the detail string always names the exemption explicitly ("non-mainline", the base branch name, and the raw classic=... detail) so the vacuous pass is auditable, never silent.
• New constants: _MAINLINE_BASE_BRANCHES = frozenset({"dev", "main"}), _CONFIRMED_BRANCH_ABSENCE_MARKER = "404" — both private to the handler module, no cross-module contract change.

TDD / evidence

3 new tests added RED against unmodified handler_dod_evidence_github_effect.py, then implemented to GREEN:

test	proves
test_deleted_non_mainline_base_branch_is_vacuously_green	reproduces the live OMN-15413 shape verbatim (stacked head/base, "Branch not found (HTTP 404)") → checks_green=True, detail names the base branch and "non-mainline"
test_dev_base_branch_with_same_404_stays_fail_closed	regression control — the identical 404 signature against base=dev stays fail-closed; the exemption never widens to mainline
test_non_mainline_base_branch_generic_error_still_fails_closed	a non-mainline base with a non-404 error (opaque/transient failure) still fails closed — the exemption is confirmed-absence-only, not blanket

uv run pytest tests/unit/nodes/node_dod_verify/test_handler_dod_evidence_github_effect.py -q
44 passed

uv run pytest tests/unit/nodes/node_dod_verify/ -q -m "not kafka"
545 passed

uv run mypy src/omnimarket/nodes/node_dod_verify/handlers/handler_dod_evidence_github_effect.py --strict
Success: no issues found in 1 source file

pre-commit run --all-files   (on commit)  -> all hooks Passed
Governed impacted-test selector (pre-push, OMN-13973):
  tests/gates/ tests/nodes/ tests/unit/ --ignore=tests/integration -m not kafka
  7366 passed, 13 skipped, 1 xfailed

Note on the pre-push run: the first attempt surfaced one unrelated ERROR (tests/nodes/test_repository_code_entity_postgres.py::test_real_postgres_roundtrip, an @pytest.mark.integration test whose postgres_fixture skip-guard checks only POSTGRES_PASSWORD presence, not host reachability — this shared .200 shell carries an ambient POSTGRES_PASSWORD for an unrelated .201 DSN with no local Postgres listening). Confirmed pre-existing and orthogonal to this diff (different node — RepositoryCodeEntityPostgres/OMN-15230); the second push ran with POSTGRES_PASSWORD unset for that one invocation only, which correctly triggers the fixture's own documented skip path ("POSTGRES_PASSWORD not set — skipping integration postgres fixture") instead of attempting an unreachable connection. No test code was touched to produce this.

Deferred (explicitly out of scope for this PR)

• The bfac6781/OMN-15423 evidence noted omnibase_infra.public.schema_migrations (the service DB's own ledger, 82 rows) has no platform_catalog schema yet — but omnibase_infra#2653's own evidence classifies that table as service-owned, correctly out of scope for the application migration ledger this ticket converges. Not touched here; flagged for a separate ticket if convergence is later ruled to extend to the service DB.
• No change to the contract's checks: entries in onex_change_control/contracts/OMN-15413.yaml — the fix lives entirely in the shared probe machinery, which is the correct layer (this defect would recur on any future stacked-PR self-bind, not just this ticket's).
• No live database, deploy, restart, grant/RLS, cutover, merge, or .201 mutation.

NO-FLIP hold

Standing DO-NOT-FLIP hold (occ-integrity-0802) on OMN-15413 is unconditionally honored — this PR does not touch Linear status. Once merged, a fresh dod_verify OMN-15413 run should be re-verified independently before any Done-adjudication.

Evidence-Source: OCC#6150
Evidence-Ticket: OMN-15413

Evidence-Head: 88252d1acf7b65279fcce0c457be3d02bacdf6ac

[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: 33 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: 1520f757-3e85-40f5-bb31-951757c7eee6

📥 Commits

Reviewing files that changed from the base of the PR and between 5a71184 and 4dceca9.

📒 Files selected for processing (2)

• src/omnimarket/nodes/node_dod_verify/handlers/handler_dod_evidence_github_effect.py
• tests/unit/nodes/node_dod_verify/test_handler_dod_evidence_github_effect.py

---

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

[github-actions]

✅ Architectural Review — PASSED

Errors: 0
Warnings: 0

What this checks

Rule	Description
ARCH-TOPIC-001	No hardcoded Kafka topic strings in handler code
ARCH-DI-001	No event_bus=None bypass
ARCH-DI-002	No direct Handler instantiation outside workflow_runner/adapters
ARCH-DI-003	No reinvented DI containers
ARCH-TOPIC-002	contract.yaml topics follow `onex.{cmd

---

No architectural violations found.

Static architectural lint — no model inference (OMN-14176).

[github-actions]

❓ Hostile Reviewer — UNKNOWN

Blocking findings (critical/error): 0
Total findings: 0
Models succeeded: none

---

Gate semantics

Verdict	Meaning	Blocks merge?
passed	>=2 models succeeded, no critical/error findings	No
blocked	CRITICAL or ERROR findings found	Yes
degraded	Fewer than 2 models succeeded (infra unavailable/timeout)	Yes (OMN-15110)

Powered by omniintelligence.review_pairing.cli_review — node-based adversarial review via HandlerLlmCliSubprocess (OMN-8524)

[jonahgabriel]

Closing: this PR is now an empty diff against dev (compare dev...head reports 0 changed files) — the deleted-base fail-closed repair it carried already landed on dev via the handler deleted-base carve-out (handler_dod_evidence_github_effect.py). Its OCC evidence companion was closed as superseded-in-substance for the same reason. Nothing left for this vehicle to merge.