[jonahgabriel]

Summary

• OccCompanionEmitter clones the OCC repo once (_clone_and_branch, shallow clone) and captures a single base SHA; the two force-pushes that follow never fetch/merge/rebase. If a sibling product PR mints a companion for the SAME ticket and merges to OCC between this run's clone and either of its pushes, this run cannot see it: it silently treats the ticket as still companion-less, re-writes the ticket-scoped write-once admissibility-validator receipt, and force-pushes a stale full-regenerate diff that orphans the sibling companion or produces an add/add conflict at merge time.
• This adds a cheap git ls-remote <occ-url> HEAD freshness check immediately before EACH force-push. A moved OCC default branch now raises a new StaleCompanionBaseError instead of pushing. The existing finally still releases the single-producer lease on this path, so the abort is fail-fast and safe to retry: the emitter is re-invoked on the product PR's next lifecycle event (synchronize, etc.) and will clone a fresh base then.
• No live git merge/rebase is attempted mid-mint — that would require recomputing the "did this ticket already have a companion" signal and every downstream receipt, a materially larger and riskier change than this fix's own direction justifies. A per-ticket lease re-keying follow-up (related to the existing single-producer lease mechanism) remains open if fail-fast retries prove insufficient in practice.
• Checked and not reproduced: the companion ticket's described "unscoped self-bind evidence id" sub-defect. occ_companion_emitter.py's self-bind id (occ-self-bind-pr-<occ_pr_number>) and the sibling compute handler are already PR-scoped everywhere; no unscoped self-bind id exists anywhere in src/ or scripts/. No change made for this sub-defect.
• Out of scope, untouched: the parallel, not-yet-live compute/effect producer pair, and the single-producer lease keying itself.

Test plan

• New RED-then-GREEN test module tests/unit/nodes/node_pr_lifecycle_fix_effect/test_occ_companion_emitter_stale_base_omn_15845.py: fails to even import against pre-fix source (no StaleCompanionBaseError export — confirmed by stashing the source change and re-running); passes after the fix. Covers: stale base before the first push raises and the push never fires; a base that moves between the first and second push is caught on the second; the single-producer lease is still released in finally; the unchanged-base happy path still pushes normally on both force-pushes (regression guard).
• Updated the git-mock harnesses in three sibling test files (test_occ_companion_emitter.py, test_occ_companion_emitter_friction_omn_14741.py, test_occ_autobind_contention_omn_15247.py) to answer the new git ls-remote call with a SHA matching their existing mocked base, so their own (unrelated) properties keep passing.
• uv run pytest tests/unit/nodes/node_pr_lifecycle_fix_effect/ -m "not kafka": 286 passed, 18 skipped.
• uv run mypy src/omnimarket/nodes/node_pr_lifecycle_fix_effect/handlers/occ_companion_emitter.py --strict and full-package uv run mypy src/omnimarket/ --strict: both clean.
• uv run ruff format --check / uv run ruff check: clean.
• Full pre-commit hook chain on git commit: all hooks passed.
• Governed impacted-test selector (pre-push): 7643 passed, 22 skipped, 1 xfailed.

Also addresses: OMN-16116

Evidence-Ticket: OMN-15845
Evidence-Source: OCC#6670

[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

Limit details: You’ve used all 1 included review currently available under your plan. You completed 111 included PR reviews in the past 7 days; at that activity level, included reviews refill at 1 review per hour.

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: 0901d040-639d-408e-a2d7-61350ae2b3d7

📥 Commits

Reviewing files that changed from the base of the PR and between 88f62b9 and c4ef00c.

📒 Files selected for processing (5)

• src/omnimarket/nodes/node_pr_lifecycle_fix_effect/handlers/occ_companion_emitter.py
• tests/unit/nodes/node_pr_lifecycle_fix_effect/test_occ_autobind_contention_omn_15247.py
• tests/unit/nodes/node_pr_lifecycle_fix_effect/test_occ_companion_emitter.py
• tests/unit/nodes/node_pr_lifecycle_fix_effect/test_occ_companion_emitter_friction_omn_14741.py
• tests/unit/nodes/node_pr_lifecycle_fix_effect/test_occ_companion_emitter_stale_base_omn_15845.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 — PASSED

Blocking findings (critical/error): 0
Total findings: 0
Models succeeded: qwen3-review,qwen3-review-b

---

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]

Hostile Reviewer red — root-caused, both check names trace to one infra event, not two review failures.

Investigated the two red "Hostile" checks on this PR (run 32147768558):

• Hostile Reviewer (adversarial gate) (job 95787976884, completed 17:21:11Z, conclusion failure)
• Hostile Review Gate (job 95802879247, completed 17:48:50Z, conclusion failure)

The full log of the reviewer job shows it never reached an actual review step: it failed while cloning sibling repos needed for context (omniintelligence retried and recovered on attempt 2/4; omnibase_core retried and failed all 4/4 attempts, ##[error]clone omnibase_core failed after 4 attempts), so VERDICT was never set (Resolved verdict: unknown) and the job exited 1 before invoking either reviewer model — zero adversarial findings were produced. Hostile Review Gate is a separate downstream job that only reads needs.hostile-reviewer.result and fails closed on any non-success value (OMN-15296) — it is not a second independent review attempt, it's the designed propagation of the same one clone-infrastructure failure through a second required-check name.

Conclusion: this is one infra event (git-clone contention against omnibase_core), not a real adversarial finding and not two independent failures. Per repo convention ("re-run the reviewer rather than merging on it" — the job's own error text), firing one rerun now that fleet capacity has eased. Not re-running reflexively if it fails again for the same reason — will escalate instead.