Repository navigation
evidence(OMN-15232): re-land falsifiable content probes displaced by the autobind companion - #5129
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 31 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the 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 configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
CI is RED and that is the finding, not an oversight — do not skip-token itBoth required gates ( Nothing is missing and nothing is failing — the three OMN-15232 receipts exist and PASS. The gate rejects this PR only because none of them binds to this PR number. Clearing that would require a self-bind receipt for #5129, which requires a new The result is the sharpest available proof of the defect in OMN-15247: once autobind lands a hollow contract, the eligibility gate freezes the ticket evidence surface and actively blocks anyone from supplementing it with stronger evidence. Recorded in full as a comment on OMN-15247. Decision needed from the landing owner (this lane does not merge; Codex owns landing). Options as I see them, least to most invasive:
I recommend (1) for this PR and (3) as the durable fix. No auto-merge armed. |
…autobind The autobind companion that landed for OMN-15232 carries only PR-existence checks (gh pr view --json number,state / --json files), which pass for any existing PR regardless of fix correctness. The hand-authored companion OCC#5115 carried falsifiable content probes and was displaced. Re-runs those probes read-only against the merge commit 6e91834b and its pre-fix parent f7fb7cde, recording a real RED/GREEN pair for all three. Lands as a narrative evidence doc rather than receipts because check_receipt_hardening.py rejects receipts whose evidence_item_id is absent from the merged contract, and the contract must not be modified. Mechanism gap filed as OMN-15247.
c6e7092 to
877284e
Compare
What
Re-lands the falsifiable content-probe evidence for OMN-15232 that was displaced when the OCC autobind producer opened a competing companion.
Single net-new evidence file:
docs/evidence/OMN-15232/falsifiable-content-probes-2026-07-27.md. Codex landing repair appendsocc-self-bind-pr-5129tocontracts/OMN-15232.yamlplus a matching PASS receipt so OCC eligibility can bind this evidence-supplement PR.Why
The companion that landed for OMN-15232 (OCC#5118, autobind-authored) carries only PR-existence checks:
These exit 0 for any PR that exists, in any state, carrying any diff. They cannot go RED given the PR exists, so they do not distinguish a correct fix from a revert or an empty PR. The Linear Done flip on OMN-15232 (2026-07-27T14:11:06Z) rides receipts minted from those checks.
A hand-authored companion (OCC#5115, branch
jonah/omn-15232-occ, head1d604ccb5) carried probes that grep the changed source for the specific introduced construct. Autobind opened OCC#5118 for the same ticket and that shape landed instead.Evidence supplied
All three probes re-run read-only at 2026-07-27T14:27Z against the GitHub contents API, forming a real RED/GREEN pair across the merge boundary of omnibase_infra#2497:
6e91834b(merged)f7fb7cde(pre-fix parent)event_bus_kafka.pybindsdlq_result = await self._publish_raw_to_dlq(1, exit 00, exit 1mixin_kafka_dlq.pycarriesOMN-15232: surface the real persistence outcome1, exit 00, exit 1test_no_dlq_publish_call_site_discards_its_persistence_result1, exit 0That non-zero-at-merge-base property is exactly what the landed autobind checks lack.
Why a doc and not receipts
This was a forced choice, and it is itself a finding.
scripts/validation/check_receipt_hardening.pyrejects any post-cutoff receipt whoseevidence_item_idis absent from the ticket contract:The stronger evidence ids exist only in the displaced hand-authored contract. Re-landing the stronger displaced probe ids as receipts would require changing the already-merged acceptance contract shape. This PR instead adds only the OCC self-bind receipt needed for landing this evidence supplement; it does not claim those displaced probes are now receipt-gated.
Scope note (no overclaim)
These are static content probes against merged source. They prove the gating code and its regression test are present at the merged SHA. They are not runtime proof that a DLQ write failure rewinds the fetch position in a live lane; no fault injection was run and none is claimed. An earlier framing of this evidence as establishing recoverability was an overclaim and is corrected here.
Separation of powers
Probes executed by
fable-plan-0727-omn15232-evidence, independent of the implementer of #2497. No fix code was authored by this lane.Follow-up
Mechanism gap filed as OMN-15247 — autobind should defer when a hand-authored companion is open for the same ticket, and/or bind its checks to diff content rather than PR existence. Do not cite autobind-contract green as proof that OMN-15232 was fixed correctly.
Evidence-Ticket: OMN-15232
Merge
Do not auto-merge. Codex owns landing.