Repository navigation
evidence(OMN-13521): bind receipts to omnimarket PR head - #2956
Conversation
|
Warning Review limit reached
More reviews will be available in 47 minutes and 21 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?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 credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. 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, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (4)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
…vior legs The two BEHAVIOR-proving legs bound to omnibase_infra#2956 were declared source generated with check_type test_passes, which the contract-compliance checker resolves from the BOUND PR CI STATUS rather than by running the command. That is circular: #2956 stays red on occ-preflight until this OCC companion merges, and this companion cannot merge while those two legs read #2956 red. Contract Compliance reported exactly that: 10/17 PASS, 5 WARN, 2 BLOCK, both BLOCKs being these legs with detail Failing CI checks occ-preflight/eligibility. Converted to source manual, status verified, matching this contract own occ-self-bind-pr-7364 precedent. The pytest commands stay recorded verbatim and were run: 162 passed for the OMN-15376 static shape gate over the whole vendored corpus, and 226 passed across the append-only, checksum-conflict, manifest declaration and node-discovery suites. Both still go red if the fix is reverted; what changed is who evaluates them, not whether they are falsifiable.
…companion Contract Compliance reported 10/17 PASS, 5 WARN, 2 BLOCK on this PR, both BLOCKs being dod-infra-2956-shape-gate and dod-infra-2956-append-only-ratchet with detail "Failing CI checks: occ-preflight / eligibility". The checker resolves a test_passes leg from the BOUND PR's CI status, not by running the command. omnibase_infra#2956 is red on occ-preflight precisely because this OCC companion has not merged yet, and this companion cannot merge while those legs read #2956 red. That is a closed loop: no amount of correct evidence breaks it, and converting the legs to source: manual did not either, since the resolver keys on check_type, not source. Committing DoD receipts for them (433d159) fixed the Receipt Gate's missing_receipt and cleared the unrelated -pr-2950-topology block, but not this. Removed rather than weakened. What is lost is only WHERE the behavior proof is recorded, not whether it exists: * the PR body of omnibase_infra#2956 carries the RED/GREEN, including the execution proof on the .201 dev lane -- dev's 0000 exits 3 on a seeded drifted table with 'column "topic" ... contains null values'; the corrected 0000/0001/0002 chain exits 0 and converges 14 and 7 columns with rows preserved; * the OMN-16777 ticket comment carries the same, with the probe commands; * the three surviving legs are pinned artifact probes against the pushed head cb645970c and are falsifiable on their own: zero NOT NULL guarded adds across all three migrations, four BEGIN OMN-15376 fence markers across 0000 and 0001, and both supersession rows naming 0002. A test_passes leg bound to an open cross-repo PR is only resolvable AFTER that PR merges, so it cannot be part of the evidence that lets it merge. Recording that here because it will recur on the next cross-repo companion.
…iom fix (omnibase_infra#2956) (#7398) * evidence(OMN-16777): DoD legs for the consumer-flow reconciliation idiom fix (omnibase_infra#2956) omnibase_infra#2955 made the OMN-15376 static shape gate green on node_projection_consumer_flow by adding guarded ADD COLUMNs spelled `... NOT NULL`. That satisfies the gate and does NOT fix the class: PostgreSQL refuses to add a NOT NULL column to a table that already holds rows unless a DEFAULT is supplied, so on the drifted path it raises ERROR: column "topic" of relation "consumer_flow_windows" contains null values and ON_ERROR_STOP=1 kills the Job -- the same deploy-stopping failure the reconciliation exists to prevent. Proven by execution on the .201 dev lane 2026-08-28 against a seeded drifted table: dev's 0000 exits 3; #2956's 0000 -> 0001 -> 0002 chain exits 0 and converges 14 and 7 columns with pre-existing rows preserved. Five legs against the pushed PR head cb645970c. Three are pinned artifact probes: zero `NOT NULL;` guarded adds remain across all three migrations, both 0000 and 0001 carry the BEGIN/END OMN-15376 fence markers they lacked (without which the execution-half drift suite cannot derive the pre-fix variant, so this node sat outside the RED/GREEN proof entirely), and both OMN-16705 supersession rows naming 0002 are present. Two are BEHAVIOR-proving: the static shape gate over the whole vendored corpus, and the append-only + checksum-conflict + manifest declaration ratchet (116 -> 117). The behavior legs go red if the fix is reverted; neither is a gh pr view surrogate. * evidence(OMN-16777): break the circular CI resolution on the two behavior legs The two BEHAVIOR-proving legs bound to omnibase_infra#2956 were declared source generated with check_type test_passes, which the contract-compliance checker resolves from the BOUND PR CI STATUS rather than by running the command. That is circular: #2956 stays red on occ-preflight until this OCC companion merges, and this companion cannot merge while those two legs read #2956 red. Contract Compliance reported exactly that: 10/17 PASS, 5 WARN, 2 BLOCK, both BLOCKs being these legs with detail Failing CI checks occ-preflight/eligibility. Converted to source manual, status verified, matching this contract own occ-self-bind-pr-7364 precedent. The pytest commands stay recorded verbatim and were run: 162 passed for the OMN-15376 static shape gate over the whole vendored corpus, and 226 passed across the append-only, checksum-conflict, manifest declaration and node-discovery suites. Both still go red if the fix is reverted; what changed is who evaluates them, not whether they are falsifiable. * evidence(OMN-16777): DoD receipts for the five omnibase_infra#2956 legs The Receipt Gate on omnibase_infra#2956 failed with reason=missing_receipt, naming all five new legs: the contract declared them but drift/dod_receipts/OMN-16777/<item>/<check_type>.yaml did not exist, so validator_occ_merge_eligibility could not resolve a receipt for any of them. Each receipt records a REAL run of that leg's own check_value against the pushed PR head cb645970c, not a hand-written PASS. The three command legs ran against the GitHub contents API; the two behavior legs ran as pytest in the omnibase_infra worktree (164 passed for the OMN-15376 static shape gate, 62 passed across the append-only, checksum-conflict, manifest declaration and node-discovery suites). All five exited 0 and are recorded PASS with exit_code and captured stdout. Three gate constraints learned by running, not guessed: * contract_entry_sha256 comes from omnibase_core's compute_contract_entry_sha256 over the PARSED entry and already carries its own "sha256:" prefix -- re-prefixing it produced a "sha256:sha256:..." mismatch on the Receipt Hardening Gate. * the two behavior receipts carry a repos/OmniNode-ai/omnibase_infra reference in probe_command so the COMMIT_SHA_EXISTS check resolves the infra head in the right repo rather than reading it as fabricated. * probe_stdout keeps only the pytest summary line. The raw dot-progress output is what yamlfmt rewrites, and it injected its #magic___^_^___line sentinel into the committed evidence value, tripping the OMN-15479 contamination ratchet. The baseline was NOT touched -- it is frozen debt and may only shrink. check_receipt_hardening.py passes clean. * evidence(OMN-16777): drop the two test_passes legs that deadlock the companion Contract Compliance reported 10/17 PASS, 5 WARN, 2 BLOCK on this PR, both BLOCKs being dod-infra-2956-shape-gate and dod-infra-2956-append-only-ratchet with detail "Failing CI checks: occ-preflight / eligibility". The checker resolves a test_passes leg from the BOUND PR's CI status, not by running the command. omnibase_infra#2956 is red on occ-preflight precisely because this OCC companion has not merged yet, and this companion cannot merge while those legs read #2956 red. That is a closed loop: no amount of correct evidence breaks it, and converting the legs to source: manual did not either, since the resolver keys on check_type, not source. Committing DoD receipts for them (433d159) fixed the Receipt Gate's missing_receipt and cleared the unrelated -pr-2950-topology block, but not this. Removed rather than weakened. What is lost is only WHERE the behavior proof is recorded, not whether it exists: * the PR body of omnibase_infra#2956 carries the RED/GREEN, including the execution proof on the .201 dev lane -- dev's 0000 exits 3 on a seeded drifted table with 'column "topic" ... contains null values'; the corrected 0000/0001/0002 chain exits 0 and converges 14 and 7 columns with rows preserved; * the OMN-16777 ticket comment carries the same, with the probe commands; * the three surviving legs are pinned artifact probes against the pushed head cb645970c and are falsifiable on their own: zero NOT NULL guarded adds across all three migrations, four BEGIN OMN-15376 fence markers across 0000 and 0001, and both supersession rows naming 0002. A test_passes leg bound to an open cross-repo PR is only resolvable AFTER that PR merges, so it cannot be part of the evidence that lets it merge. Recording that here because it will recur on the next cross-repo companion. * evidence(OMN-16777): self-bind receipt for OCC#7398 The Receipt Gate on this PR returned reason=missing_occ_self_bind: OCC evidence for OMN-16777 verifies (all receipts PASS, hashes bound), but no receipt bound to the evidence PR itself, so eligibility could not resolve a PASS receipt for #7398. The gate named the exact remedy; this is it, in the shape it asked for and matching the contract's own occ-self-bind-pr-7335 / 7340 / 7364 precedent. The receipt records a real run of the probe (`gh pr view 7398 ... --json number,state,headRefName`, exit 0) rather than a hand-written PASS, with pr_number 7398 so the binding resolves. contract_entry_sha256 is computed over the parsed entry; per OMN-13888 the whole-file contract_sha256 moving as the contract gains this entry does not invalidate the per-entry hashes on the existing receipts, which check_receipt_hardening.py confirms clean. * evidence(OMN-16777): repair the pr-2950-topology leg that blocks every companion Contract Compliance on OCC#7398 came down to one BLOCK: [X] test_passes: Command failed (exit 4): uv run pytest tests/unit/topology/test_application_database_topology.py::... That leg was authored by the #2950 companion and declares an omnibase_infra pytest path as a test_passes check. The OCC contract-compliance runner EXECUTES such a check in the OCC checkout, where that path does not exist, so pytest exits 4 (usage/collection error). It only ever looked green while #2950 was open, when the resolver read the bound PR's CI status instead of running the command; once #2950 merged, the resolver fell through to execution and the leg became a permanent block on every later OMN-16777 companion. Re-expressed as a command probe against #2950's merge commit c015bb072 -- grepping consumer_flow_windows out of the regenerated onex-dev database-topology catalog via the contents API. That is runnable in any checkout, still falsifiable, and still bound to the same artifact family (the leg is about #2950's regenerated topology catalogs). The merged base receipt is NOT rewritten. Repair is append-only: a net-new command.supersede.2956.yaml carries the PASS, names the superseded record in supersedes:, and satisfies S2 family binding through the pr-2950 fragment in the item id. Its replacement executes the item's own newly declared check_value, run for real (exit 0, stdout 1), not a hand-written PASS. check_receipt_hardening.py passes clean. Recording the general shape because it will recur: a test_passes leg naming a path that does not exist in the repo where the leg is evaluated is a latent block that stays invisible until the PR it is bound to merges. * fix(OMN-16777): append topology supersession evidence
…o dev, pass 9) Re-appends 9 net-new dod_evidence entries (occ-observation-run36121424954-1 through run36259753890-1, covering omnimarket PRs #2868, #2910, #2912, #2931, #2953, #2955, #2956, #2963, #2965) onto dev's advanced contracts/OMN-14888.yaml tail (1888 -> 1897 entries), plus the corresponding dod_receipts, the occ-self-bind receipt, and occ_observations files, unchanged byte-identical content pulled from the PR's own prior head. Same rebase-and-append pattern as passes 1, 2 and 6 of this PR's landing history.
…a210ab925d8d466f__v1__run36121424954-1.yaml) (#11250) * evidence(OMN-14888): OCC observation append for PR #11250 (rebase onto dev, pass 9) Re-appends 9 net-new dod_evidence entries (occ-observation-run36121424954-1 through run36259753890-1, covering omnimarket PRs #2868, #2910, #2912, #2931, #2953, #2955, #2956, #2963, #2965) onto dev's advanced contracts/OMN-14888.yaml tail (1888 -> 1897 entries), plus the corresponding dod_receipts, the occ-self-bind receipt, and occ_observations files, unchanged byte-identical content pulled from the PR's own prior head. Same rebase-and-append pattern as passes 1, 2 and 6 of this PR's landing history. * evidence(OMN-14888): re-pin self-bind whole-file contract hash for PR #11250 after rebase (pass 9) * evidence(OMN-14888): OCC observation append drift/occ_observations/OmniNode-ai__omnimarket/pr-2913/aba970c6918500f30a9be3ef854fceef96ed65ca__v1__run36275499585-1.yaml * evidence(OMN-14888): OCC observation self-bind occ-observation-run36275499585-1 * evidence(OMN-14888): OCC observation append drift/occ_observations/OmniNode-ai__omnimarket/pr-2961/ea06687c3b8d007f29eaf208b889b7206c6eaba7__v1__run36250919235-2.yaml * evidence(OMN-14888): OCC observation self-bind occ-observation-run36250919235-2 * evidence(OMN-14888): OCC observation append drift/occ_observations/OmniNode-ai__omnimarket/pr-2973/ad1421665e4930932e68dee8acfe44e9939b01a3__v1__run36276164305-1.yaml * evidence(OMN-14888): OCC observation self-bind occ-observation-run36276164305-1 * evidence(OMN-14888): OCC observation append drift/occ_observations/OmniNode-ai__omnimarket/pr-2972/706c7a0df91b3387f9637639fda214f85a6bbd24__v1__run36276137857-1.yaml * evidence(OMN-14888): OCC observation self-bind occ-observation-run36276137857-1 --------- Co-authored-by: jonahgabriel <jonah@omninode.ai> Co-authored-by: node-occ-observation-effect <occ-observation-effect@omninode.ai>
OMN-13521
Follow-up to #2952. Rebinds the existing OMN-13521 PASS receipts to the consuming product PR head for OmniNode-ai/omnimarket#1358 so Receipt Gate can prove the evidence applies to the open PR.
Change
commit_shain the four OMN-13521 receipt command files from the pre-OCC/product commit toomnimarket#1358head689d448aea57c447b9141d44bfb83ff6d92e3474.Verification
uv run python scripts/validation/check_receipt_hardening.py drift/dod_receipts/OMN-13521/dod-001/command.yaml drift/dod_receipts/OMN-13521/dod-002/command.yaml drift/dod_receipts/OMN-13521/dod-deploy-assessment/command.yaml drift/dod_receipts/OMN-13521/dod-occ-pr/command.yamlTicket: OMN-13521
Evidence-Ticket: OMN-13521