Repository navigation
receipt(OMN-13751,OMN-13753): OCC evidence for infra alerting + prod secrets PRs - #3356
Merged
Merged
Conversation
|
Warning Review limit reachedYou’ve reached a temporary PR review limit under our Fair Usage Limits Policy. Next review available in: 36 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 (8)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
jonahgabriel
enabled auto-merge
June 29, 2026 15:16
jonahgabriel
added this pull request to the merge queue
Jun 29, 2026
jonahgabriel
pushed a commit
that referenced
this pull request
Sep 9, 2026
…d consumer (#8783) * evidence(OMN-18048): bind OMN-18048 to omnibase_infra#3356 as a second consumer #3356 fails occ-preflight with reason=pr_ticket_mismatch: "no PASS receipt binds to PR #3356 or one of its commit SHAs". Every receipt OMN-18048 has on dev carries pr_number 3351, so nothing binds to the follow-up PR. Corrected premise, from Jonah's landing review: OCC#8774 is NOT the companion that unblocks #3356. Its supersession receipts also carry pr_number 3351, so merging it would not clear this. The two PRs are sequential in ticket only, not in gate dependency. I had recorded the opposite and was wrong. Two second-consumer supersessions, the OMN-14623 merged-path pattern, neither editing a merged base receipt: - dod-omn-18048-qualifier-and-emphasis -> reads the SAME handler file the base entry reads, at #3356's head, for _TRAILING_EMPHASIS_RE, the marker the MAJOR hostile-review fix introduces. Returns 2. - dod-omn-18048-red-first-module-exists -> reads the same PR-files surface the base entry reads, for #3356 rather than #3351. Returns 1. Both anchor to their superseded item's own declared artifact family, which is what S2 requires, and their check_values differ from each other, which is what S1 requires. The first check is RED-derivable and I proved it rather than asserting it: _TRAILING_EMPHASIS_RE returns 2 at #3356's head and 0 at #3351's head (exit 1). It discriminates this PR from its predecessor rather than passing for both. * evidence(OMN-18048): append the occ-self-bind entry for PR #8783 Eligibility fails #8783 with missing_occ_self_bind: OCC evidence for OMN-18048 verifies, but no receipt binds it to this OCC PR itself (I3 — an OCC PR validates its own in-tree contract and receipts). Appended, not edited. The four existing entries are byte-identical to origin/dev, verified entry-by-entry before committing. That matters because all four merged receipts carry contract_entry_sha256, and _contract_hash_violation validates the per-entry hash and returns without ever reaching the whole-file comparison (check_receipt_hardening.py:1486). Their entries are untouched, so they stay bound and no merged receipt needs rewriting. The eligibility message asks for contract_sha256 to be recomputed on the existing receipts. That is not required here and would mean editing four receipts already merged on dev — an append-only violation of exactly the shape that blocked OCC#8774 this morning. * evidence(OMN-18048): PASS receipt binding OMN-18048 to OCC PR #8783 Discharges missing_occ_self_bind on #8783. The probe was run live, not composed: gh pr view 8783 returned {"headRefName":"lakshman/omn-18048-occ-bind-pr-3356","number":8783,"state":"OPEN"} at exit 0, and that is the stdout recorded in the receipt. commit_sha 3036449 is the pushed contract-append commit, confirmed to resolve via the GitHub API before the receipt was written (COMMIT_SHA_EXISTS). Gate proven load-bearing rather than assumed: run bare, the hardening check exits 0 even against a deliberately corrupted hash, because it validates nothing without --paths-file0. Scoped the way CI invokes it (ci.yml:273), it exits 1 on the corrupted entry hash and 0 on the real one. The passing run is only meaningful because the failing one was watched first. The four receipts already merged on dev are untouched, and the control confirms they stay bound: occ-self-bind-pr-8762 still hashes to 494f0c53, exactly what its merged receipt carries.
Patel230
added a commit
that referenced
this pull request
Sep 9, 2026
omnimarket#2427 fails occ-preflight with pr_ticket_mismatch: every OMN-18035 receipt binds to PR #2405, so the AC3 test PR has no evidence bound to it. Same class of failure #3356 had, same fix (OMN-14623). A net-new supersession record, not an edit: the merged base receipt command.yaml is untouched, and its entry hash 0cb25648 is byte-identical to what it already carries — verified before writing. The replacement reads the SAME test file the base entry reads, at #2427's head, for the marker the AC3 test introduces. It discriminates rather than passing on anything: that grep returns 2 at #2427's head d5043489 and 0 at #2405's merged head f695e525, so it cannot pass on the old content. Both runs were executed, not composed. Gate proven load-bearing rather than assumed: scoped as ci.yml:273 invokes it, over the supersede AND the merged base receipt, corrupting the replacement entry hash gives exit 1 naming the exact mismatch; restored, exit 0.
jonahgabriel
pushed a commit
that referenced
this pull request
Sep 9, 2026
…8794) * evidence(OMN-18035): bind AC1 and AC2 to the tests that execute them The OMN-18056 sweep holds this ticket at gap_ac_unbound: 5 of 5 criteria bound to no verified probative check. Its remediation — add binds_ac to the dod_evidence item that proves it — cannot be applied here. All four existing entries are merged on dev, and the Append-Only Gate holds merged entries immutable (ci.yml:1446: "Existing entries are immutable; corrections must be net-new add-only supersession files"). Measured rather than assumed: adding binds_ac to a merged entry moved its entry hash 8a232746 -> fbeb2619 and took the Receipt Hardening gate to exit 1. So these are net-new entries, which is both what the gate prescribes and what OMN-18062 already does (ac1-*, ac2-* purpose-built binding entries). Verified before committing: all four merged entries byte-identical to origin/dev, two added. Each entry runs the ONE test that executes its criterion's own sentence, rather than binding both ACs to a whole-file run — a file-level pass cannot say which criterion it covered, which is the very thing this hold exists to stop. Not bound here, deliberately: - AC3 — its test lives in omnimarket#2427 and is not on dev yet. - AC4 — the mutation proof is a watched-failure procedure. No automated check proves a guard was seen failing in both directions, and binding it to a passing test would be the surrogate this gate refuses. * evidence(OMN-18035): PASS receipts for the AC1 and AC2 bindings Both probes were run, not composed. In the omnimarket clone at origin/dev 86513e25: ::test_complete_page_advertises_no_cursor -> 1 passed, exit 0 ::test_truncated_page_advertises_a_cursor -> 1 passed, exit 0 and that exact stdout is what each receipt records. commit_sha fd16037 is the pushed contract commit, confirmed to resolve through the GitHub API before the receipts were written. The merged receipts are untouched and provably still bound: after the append, occ-self-bind-pr-8661 still hashes to 8341a8e5, byte-identical to what its merged receipt carries. Gate proven load-bearing rather than assumed. Scoped as ci.yml:273 invokes it, over both new receipts AND the merged 8661 one: corrupting the AC1 entry hash gives exit 1 naming the exact mismatch; restored, exit 0. The green run only counts because the red one was watched first. * evidence(OMN-18035): rebind to omnimarket#2427 as a second consumer omnimarket#2427 fails occ-preflight with pr_ticket_mismatch: every OMN-18035 receipt binds to PR #2405, so the AC3 test PR has no evidence bound to it. Same class of failure #3356 had, same fix (OMN-14623). A net-new supersession record, not an edit: the merged base receipt command.yaml is untouched, and its entry hash 0cb25648 is byte-identical to what it already carries — verified before writing. The replacement reads the SAME test file the base entry reads, at #2427's head, for the marker the AC3 test introduces. It discriminates rather than passing on anything: that grep returns 2 at #2427's head d5043489 and 0 at #2405's merged head f695e525, so it cannot pass on the old content. Both runs were executed, not composed. Gate proven load-bearing rather than assumed: scoped as ci.yml:273 invokes it, over the supersede AND the merged base receipt, corrupting the replacement entry hash gives exit 1 naming the exact mismatch; restored, exit 0.
Patel230
added a commit
that referenced
this pull request
Sep 9, 2026
All three probes were run, not composed. In a worktree at omnibase_infra origin/dev a4393794, post-#3356 so the module is final: TestQualifiedHeadingsAreRecognised -> 13 passed, exit 0 TestBoldPrefixedItemsAreSeen -> 3 passed, exit 0 TestWideningDoesNotBecomeOverMatching -> 3 passed, exit 0 That exact stdout is what each receipt records. commit_sha d4bccbc is the pushed contract commit, confirmed to resolve through the GitHub API before the receipts were written. Merged receipts untouched and provably still bound: after the append, occ-self-bind-pr-8783 still hashes to 73e4a07a, byte-identical to what its merged receipt carries. Gate proven load-bearing rather than assumed. Scoped as ci.yml:273 invokes it, over all three new receipts AND the merged 8783 one: corrupting AC1's entry hash gives exit 1 naming the exact mismatch; restored, exit 0. The green only counts because the red was watched. Note on where the tests ran: the canonical omnibase_infra clone is blocked by the OMN-15620 venv-purity gate — uv run pytest exits 1 before collecting, because omnimarket==0.4.41 provides entry points not declared in uv.lock. A uv sync repair would strip omnimarket, so it is not a safe workaround; a worktree at the same dev sha is.
This was referenced Sep 9, 2026
jonahgabriel
pushed a commit
that referenced
this pull request
Sep 9, 2026
…e them (#8809) * evidence(OMN-18048): bind AC1, AC2 and AC5 to the classes that declare them The OMN-18056 sweep holds this ticket at gap_ac_unbound: 5 of 5 criteria bound to no verified probative check. Net-new entries, not edits. All seven pre-existing entries are merged on dev and the Append-Only Gate holds them immutable (ci.yml:1446). Measured earlier today on this very contract: adding binds_ac to a merged entry moved its hash 8a232746 -> fbeb2619 and took the Receipt Hardening gate to exit 1. Verified before committing: 7 merged entries byte-identical to origin/dev, 3 added. The mapping is TRANSCRIBED, not inferred. Each class states its own criterion in its docstring: TestQualifiedHeadingsAreRecognised "AC1 - a qualifier must not hide an otherwise-recognised heading" TestBoldPrefixedItemsAreSeen "AC2 - the same criteria must parse identically however they are written" TestWideningDoesNotBecomeOverMatching "AC5 - recognising more headings must not start inventing criteria" One class per criterion rather than the whole module: a file-level pass cannot say which criterion it covered, which is the defect this hold exists to catch. Not bound, deliberately: - AC3 is a corpus measurement over Linear tickets (14.5% of 110, 12 distinct spellings, recorded in the module docstring). Discharged as evidence but with no hermetic gate-runnable check. - AC4's mutation half is a watched-failure procedure. No automated check proves a guard was seen failing in both directions, and pointing binds_ac at a passing test would be the surrogate this gate refuses. #3356 added three further classes that strengthen AC2 and AC5, but they declare no AC in their docstrings, so binding them would be inference rather than transcription. Left unbound. * evidence(OMN-18048): PASS receipts for the AC1, AC2 and AC5 bindings All three probes were run, not composed. In a worktree at omnibase_infra origin/dev a4393794, post-#3356 so the module is final: TestQualifiedHeadingsAreRecognised -> 13 passed, exit 0 TestBoldPrefixedItemsAreSeen -> 3 passed, exit 0 TestWideningDoesNotBecomeOverMatching -> 3 passed, exit 0 That exact stdout is what each receipt records. commit_sha d4bccbc is the pushed contract commit, confirmed to resolve through the GitHub API before the receipts were written. Merged receipts untouched and provably still bound: after the append, occ-self-bind-pr-8783 still hashes to 73e4a07a, byte-identical to what its merged receipt carries. Gate proven load-bearing rather than assumed. Scoped as ci.yml:273 invokes it, over all three new receipts AND the merged 8783 one: corrupting AC1's entry hash gives exit 1 naming the exact mismatch; restored, exit 0. The green only counts because the red was watched. Note on where the tests ran: the canonical omnibase_infra clone is blocked by the OMN-15620 venv-purity gate — uv run pytest exits 1 before collecting, because omnimarket==0.4.41 provides entry points not declared in uv.lock. A uv sync repair would strip omnimarket, so it is not a safe workaround; a worktree at the same dev sha is.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Evidence-Ticket: OMN-13751
Evidence-Ticket: OMN-13753
Evidence-Source: OmniNode-ai/omnibase_infra#2157
Evidence-Source: OmniNode-ai/omnibase_infra#2158
Adds central OCC contracts and command receipts binding the two omnibase_infra manifest PRs:
dod-manifest-valid(all 5 manifests valid YAML; PublicSurfaceDown +for: 90spresent),dod-no-pre-merge-deploy(manifests only; operator-gated by OMN-13418),dod-occ-self.dod-manifest-lint(both manifests valid YAML; no literal secrets),dod-no-pre-merge-deploy,dod-occ-self.Each code receipt is bound to its feature PR head SHA;
dod-occ-selfself-binds this OCC PR. No runtime mutation — all activation is operator-gated (OMN-13418).