Repository navigation
evidence(OMN-15655): OCC companion for OmniNode-ai/omnibase_infra#2632 - #5978
Merged
jonahgabriel merged 7 commits intoAug 3, 2026
Merged
Conversation
The machine mint (node_occ_companion_effect) that produced this companion for OmniNode-ai/omnibase_infra#2632 emitted all THREE command.supersede.2632.yaml files with a byte-identical replacement.check_value — one grep -c 'def validate_omniintelligence_database_invariants' over src/omnibase_infra/topology/application_database.py. So one probe was made the authoritative proof of three distinct bars (S1 distinctness), and none of them referenced the item it replaced (S2 family binding). That is the OMN-15459 wrong-item rebind, the OCC#5534 shape, and it is what turned Supersession Binding Ratchet + Pre-commit + CI Summary red on this PR. NON-IMPLEMENTER evidence authorship (feedback_no_self_authored_evidence): I am not the implementer of omnibase_infra#2632 and wrote none of its product code, pins, or tests. This companion was bot-authored by app/onexbot-occ-writer. Each replacement now carries the SUPERSEDED ITEM'S OWN declared check from contracts/OMN-15655.yaml, re-executed live by this lane at 2026-08-02T22:29Z, with the real probe output recorded: dod-OmniNode-ai-omnimarket-pr-2010 -> "true" (exit 0) dod-market-2010-schema-source-probe -> OK omninode_internal both relations (exit 0) occ-self-bind-pr-5962 -> "true" (exit 0) TWO declared checks were RE-STATED, not copied, and this is the one substantive judgement in the diff. The contract's checks for #2010 and #5962 assert .state == "open"; both PRs have since MERGED (#2010 at 488e4e05, #5962 at cbc5029), so copying them verbatim would have recorded a FAILING probe as status PASS. Each replacement instead asserts the same identity anchors the declared check names — PR number, base.ref, and the exact evidence-bound head (#2010 head c0484781, #5962 head ref codex/omn-15655-market2010-occ) — plus .merged == true and, for #2010, the merge commit. That is a strictly stronger, durable form of the same bar: the evidence-bound head did not merely exist on an open PR, it landed. The S2 anchors (PR numbers 2010 / 5962, the schema-probe path and relation names) are preserved, so each check still discriminates its own item. These files are net-new in this PR relative to the merge base, so editing them is an add, not a mutation — no append-only violation, and no higher-token repair record is required. Gate evidence, run on .200 (patch-transfer, all 3 files sha256-verified identical on both hosts before any gate ran): - check_receipt_hardening.py --supersession-corpus: 2344 violating files vs baseline 2344, exact match. RED control: the same gate with only this repair reverted returns 2347 vs 2344 and names these exact 3 files as S1+S2, exit 1 — reproducing the live CI failure, so the check is non-vacuous. Baseline NOT padded. - check_receipt_hardening.py over the changed receipts (the Pre-commit step that was red): exit 0. - validator_occ_append_only OMN-15655: ok=true. RED control: mutating a merged base receipt in place returns receipt_file_mutated, exit 1; restored, green again. Diff vs merge base is 0 deletions. - tests/unit/scripts/test_supersession_binding_gate.py: 20 passed. - check_receipt_hardening.py --check-supersession-wiring: PASSED. - check_yamlfmt_contamination.py --corpus: PASSED. No merge, no auto-merge, no baseline padding, no product-source edit. Refs OMN-15655, OMN-15459.
…ce entries OCC#5991 merged to dev (8410b24) while this companion was open and appended a new dod_evidence entry (dod-omn15655-carried-in-omninode-infra-pr-802) to the tail of contracts/OMN-15655.yaml — the same tail this companion appends its self-bind entry to. That turned #5978 mergeable=MERGEABLE -> CONFLICTING on one file, contracts/OMN-15655.yaml. It is not a defect in either change. Resolution keeps BOTH sides, dev's already-merged entry first, then this branch's new one — the true append semantic. Verified mechanically, not by eye: every entry id present on origin/dev is still present after resolution (missing-from-resolution = []), and the only id this branch adds is occ-self-bind-pr-5978. Nothing merged was edited or dropped. Re-verified against the NEW base after resolution: - check_receipt_hardening.py --supersession-corpus: 2344 vs baseline 2344, exact. - validator_occ_append_only OMN-15655 --base-ref origin/dev: ok=true. - check_yamlfmt_contamination.py --corpus: PASSED. Refs OMN-15655.
…#5978) Consequence of merging dev, found by the gate and not waved through. Three receipts this PR ADDS pin the contract by legacy whole-file hash (contract_sha256), so appending dev's new dod_evidence entry to contracts/OMN-15655.yaml invalidated them: Receipt Hardening Gate: contract_sha256 mismatch — receipt has 'sha256:c5f7b323f6dfbed5527f2f0b5c6e78a83a52a8448a530e1c33a603b54eb7220d' but sha256(contracts/OMN-15655.yaml) is 'sha256:bf63e53bba1a94e60da6d53bca5936417f8883e5473846d698af5b68d5d5c0ac' Rebound to the current hash with the canonical helper (omnibase_core.validation.validator_receipt_gate.compute_contract_sha256), not hand-typed: drift/dod_receipts/OMN-15655/dod-OmniNode-ai-omnibase_infra-pr-2632/command.yaml drift/dod_receipts/OMN-15655/dod-occ-evidence-admissibility-validator/command.yaml drift/dod_receipts/OMN-15655/occ-self-bind-pr-5978/command.yaml WHY THIS IS HONEST, not a hash papered over a stale claim: the contract change that invalidated them is the addition of an UNRELATED entry (dod-omn15655-carried-in-omninode-infra-pr-802, merged in OCC#5991). No probe, no check_value, and no result any of these three receipts records was touched by it. The mismatch is the known whole-file-binding coupling the gate's own message calls out — a receipt bound to the whole contract is invalidated by an append to any OTHER entry. The structurally correct fix the gate recommends (mint entry-scoped contract_entry_sha256, OMN-13888) is NOT available for these three: none of them has a corresponding dod_evidence entry in contracts/OMN-15655.yaml, so compute_contract_entry_sha256 raises ContractEntryNotFoundError. That residual is disclosed, not silently absorbed — these receipts will be invalidated again by the next append to this contract. All three files are net-new in this PR relative to origin/dev, so editing them is an add, not a mutation. The dev-owned receipt drift/dod_receipts/OMN-15655/dod-omn15655-carried-in-omninode-infra-pr-802/command.yaml was NOT touched — it carries no whole-file binding and is absent from this commit. Re-verified on .200 against origin/dev: - check_receipt_hardening.py over every changed receipt: clean, no output. - check_receipt_hardening.py --supersession-corpus: 2344 vs baseline 2344. - validator_occ_append_only OMN-15655 --base-ref origin/dev: ok=true. - committed deletions vs origin/dev: 0. - check_yamlfmt_contamination.py --corpus: PASSED. Refs OMN-15655, OMN-13888.
…ntries Second recurrence of the same collision, ~3h after the first. OCC#5984 (companion for omnibase_infra#2634) merged to dev at 2026-08-03T00:03:23Z (b1d1c0e) and appended occ-self-bind-pr-5984 to the SAME tail of contracts/OMN-15655.yaml that this branch appends occ-self-bind-pr-5978 to. Two conflicts, resolved on different principles: 1. contracts/OMN-15655.yaml — content conflict, resolved KEEP BOTH, with dev's entry first so this branch stays a pure append. Verified MECHANICALLY, not by eye: every dod_evidence id on origin/dev is present in the resolution (missing-from-resolution = []), every id on the pre-merge branch is present (missing-from-resolution = []), the only added id is occ-self-bind-pr-5978, every dev entry is field-for-field identical after resolution (drift = []), and the resolved file literally startswith() the dev file bytes. 2. drift/dod_receipts/OMN-15655/dod-occ-evidence-admissibility-validator/command.yaml — add/add conflict, resolved DEV WINS, untouched. Both companions minted this receipt fresh; the #5984 copy landed first, so on dev it is now a MERGED base receipt and append-only forbids mutating it. This branch does not edit it. CONSEQUENCE, found by the gate and not waved through: appending an entry changes the contract's whole-file hash, and four receipts in this ticket directory pin the contract by LEGACY whole-file contract_sha256. Two are branch-owned and were rebound in place; two are dev-owned (minted by #5984, now merged) and are IMMUTABLE, so each got a net-new supersession per the OMN-14623 merged-path convention instead. All four bound to the current hash, recomputed with the canonical helper omnibase_core.validation.validator_receipt_gate (_prefixed_contract_sha256), never hand-typed: bf63e53bba1a94e60da6d53bca5936417f8883e5473846d698af5b68d5d5c0ac (branch) 19da976fd99f8bd20f64117b06c66f7962d81b072fa31f6998108feb762e1c34 (dev/#5984) -> 873750bbe8772935586e9c978857cbdff2f5e003ca39eb002d9100869f4a3059 REBOUND IN PLACE (branch-owned, net-new on this PR): drift/dod_receipts/OMN-15655/dod-OmniNode-ai-omnibase_infra-pr-2632/command.yaml drift/dod_receipts/OMN-15655/occ-self-bind-pr-5978/command.yaml SUPERSEDED, base preserved byte-for-byte (dev-owned, merged, immutable): drift/dod_receipts/OMN-15655/dod-occ-evidence-admissibility-validator/command.supersede.2632.yaml drift/dod_receipts/OMN-15655/dod-OmniNode-ai-omnibase_infra-pr-2634/command.supersede.2632.yaml Both new supersessions RE-EXECUTE the superseded item's own declared check live on the .200 gate host rather than copying the recorded output: dod-occ-evidence-admissibility-validator -> uv run pytest tests/test_evidence_admissibility.py -q, 76 passed, exit 0 dod-OmniNode-ai-omnibase_infra-pr-2634 -> the declared grep -c 'class ProjectionDumper' at pinned ref 6ea5342d, returned 1, exit 0 Each appends an item-id-labelled echo so the replacement carries an anchor the superseded item declares. That is required, not decorative: NEITHER item has a dod_evidence entry in contracts/OMN-15655.yaml, so the OMN-15459 S2 rule can resolve no path/symbol anchors for them and the item id is the only anchor available. replacement.pr_number stays 2634 on the #2634 receipt — that is omnibase_infra#2634's own evidence, this PR does not consume it, only the contract hash moved. DISCLOSED RESIDUAL, unchanged from r1, now WIDER and still NOT absorbed: the recommended durable fix (entry-scoped contract_entry_sha256, OMN-13888) is unavailable for all four of these receipts — none has a matching dod_evidence entry id, so compute_contract_entry_sha256 raises ContractEntryNotFoundError. Every one of them WILL be invalidated again by the next append to this contract, which is exactly what happened between r1 and r2. That gap needs its own disposition; it is recorded on OMN-15655, not silently re-patched forever. Gate evidence on .200 (patch-transfer, every transferred file sha256-verified identical on both hosts before any gate ran; conflict resolution and hash rebind were remote-only ssh mutations, never Edit/Write): - check_receipt_hardening.py over all 11 OMN-15655 receipts: exit 0. - check_receipt_hardening.py --supersession-corpus: 2344 violating files vs baseline 2344, EXACT match. The two net-new supersessions add zero violations; the baseline was NOT padded. - check_receipt_hardening.py --check-supersession-wiring: PASSED. NON-IMPLEMENTER evidence authorship (feedback_no_self_authored_evidence): I am not the implementer of omnibase_infra#2632 and wrote none of its product code, pins, or tests. This companion is bot-authored by app/onexbot-occ-writer. Refs OMN-15655, OMN-15459, OMN-13888.
…check substitution
Evidence-honesty defect found by the r1 adversarial verifier in the DURABLE
artifact, not in a report. Two of the three command.supersede.2632.yaml files
carried the reason string:
"Replacement carries this item's OWN declared check from contracts/OMN-15655.yaml,
re-executed live by a non-implementer"
That sentence is false as written for those two. Their declared checks assert
.state == "open", and both subject PRs have since merged, so the declared check
could not be carried — it was necessarily STRENGTHENED to .merged == true. The
r1 commit message disclosed this at length; the durable receipt did not, and the
receipt is what a future reader audits. A reason string that implies a verbatim
carry when a substitution occurred is the same class of defect this whole repair
exists to remove.
Re-verified live before amending, both polarities:
DECLARED (contract, verbatim) -> exit 1
gh api repos/OmniNode-ai/omnimarket/pulls/2010 ... .state == "open"
stdout: error: unexpected #2010 state
gh api repos/OmniNode-ai/onex_change_control/pulls/5962 ... .state == "open"
stdout: error: unexpected #5962 state
REPLACEMENT (as recorded in the receipts) -> exit 0
... .merged == true and .merge_commit_sha == 488e4e05... -> true
... .merged == true (head ref codex/omn-15655-market2010-occ) -> true
Each amended reason now names the substitution explicitly: which clause changed,
that the original exits 1 today with its stdout, that copying it verbatim would
have recorded a FAILING probe as status PASS, and that the replacement preserves
the identity anchors (PR number, base.ref, exact evidence-bound head) while
adding .merged == true — a strictly stronger, durable form of the same bar.
THE THIRD FILE IS DELIBERATELY UNTOUCHED. dod-market-2010-schema-source-probe is
a content probe against a pinned ref, not a PR-state probe; its declared check
WAS carried verbatim and still exits 0, so its reason string is accurate as
written. Amending all three would have been the lazy uniform edit and would have
made a true sentence false.
CONTRACT-ENTRY MISMATCH: NOT FIXED HERE, AND WHY. The dod_evidence entry
'dod-OmniNode-ai-omnimarket-pr-2010' in contracts/OMN-15655.yaml still describes
"PR #2010 ... is open on dev at the exact evidence-bound head" and still declares
the .state == "open" check that now exits 1. That entry is MERGED, so editing
either its description or its check_value in this PR is precisely what
validator_occ_append_only rejects (a PR editing a merged dod_evidence entry), and
no entry-level supersession mechanism exists for contract entries the way it does
for receipts. Inventing one here would be scope creep on an evidence-repair PR.
The mismatch is therefore recorded on OMN-15655 for disposition rather than
papered over. Same applies to the occ-self-bind-pr-5962 entry's check_value.
NO probe output, status, exit_code, check_value, contract hash or pr_number was
touched by this commit — the diff is reason prose only. Verified: 2 files
changed, and every 'replacement:' block is byte-identical to the r1 commit.
NON-IMPLEMENTER evidence authorship: I am not the implementer of
omnibase_infra#2632 and wrote none of its product code, pins, or tests.
Refs OMN-15655, OMN-15459.
jonahgabriel
deleted the
auto/omninode-ai-omnibase_infra-pr-2632-occ-autobind
branch
August 3, 2026 00:40
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.
Deterministic OCC evidence companion for OmniNode-ai/omnibase_infra#2632, authored by node_occ_companion_effect (RSD-3, OMN-14622) from the node_occ_companion_compute plan. Every byte is a pure function of the compute plan (attestation-oracle reproducible).