Repository navigation
ci(OMN-12574): port boundary clone retry to main - #2085
Closed
jonahgabriel wants to merge 1 commit into
Closed
jonahgabriel wants to merge 1 commit into
jonahgabriel wants to merge 1 commit into
Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Contributor
Author
|
Closing/replacing with a main-target-guard-compliant hotfix/* branch for the same one-file OCC main action fix. |
3 tasks
jonahgabriel
added a commit
that referenced
this pull request
Aug 17, 2026
…eads OCC#6589's own Contract Compliance Check BLOCKed: both PR-scoped dod_evidence items used bare `gh pr view <n> --json ...`, which the OMN-15309 evidence-admissibility predicate treats as the paradigm "PR-existence probe" anti-pattern -- not falsifiable, proves only that a PR object exists. Bare `gh` is not in the admissible-command vocabulary (only the compound `gh api` token is), and the module's own comment names `gh pr view/list/status` as "trivially true via almost every ticket's own generated self-bind check" -- exactly the shape both merged precedents this companion was modeled on (occ#6573, occ#6583) also used. Neither precedent's Contract Compliance Check ever actually ran on its head (confirmed live: absent entirely from both PRs' check-runs, ~100 runs each) -- apparently because the job needs the ci:ready label to fire for real, which this companion has and the autobind-minted/earlier precedents evidently didn't at authoring time. So this is the first time this exact companion shape has been checked for real, and it fails honestly. Replaced two of the three items with genuinely admissible probes (EXECUTED, FALSIFIABLE, OUTSIDE ITS OWN DIFF per the predicate): dod-OmniNode-ai-omnimarket-pr-2085: reads uv.lock content at #2085's pinned head ref via `gh api .../contents/uv.lock?ref=<sha>` and asserts mcp==1.29.0 -- proves the CVE-2026-59950 fix actually landed in the file, not just that a PR exists. RED-verified against the vulnerable 1.28.0 string. dod-OmniNode-ai-omnimarket-pr-2085-ci: reads the actual diff via `gh api .../pulls/2085/files` (admitted per the module's own BLOCK-message guidance -- "/pulls/<n>/files ... returns the actual diff") and asserts the file list is exactly ["uv.lock"]. RED-verified against a fabricated two-file list. occ-self-bind-pr-6589 is left unchanged and stays individually INADMISSIBLE (WARN, not BLOCK) -- self-bind is structurally incapable of being "outside its own diff" (the predicate's own module comment acknowledges this class exists), and `_has_effective_check` only requires ONE admissible item across the contract, not all three, to avoid the hard BLOCK. Locally verified via `onex_change_control.validation.evidence_admissibility.classify_evidence` directly: both new items -> ADMISSIBLE; self-bind -> still NOT_EXECUTED as expected. contract_entry_sha256 recomputed for the two changed items via the canonical validator_receipt_gate hashers; occ-self-bind-pr-6589's own per-entry hash is byte-identical (unaffected, confirming the append-immunity property). validator_occ_append_only re-run against the origin/dev merge-base: ok:true (this ticket still diffs as pure 'A' -- the whole OMN-16112 corpus is net-new to dev). Local validator_occ_merge_eligibility re-run for omnimarket#2085's real Evidence-Source binding: eligible:true, unchanged. Evidence-Ticket: OMN-16112
jonahgabriel
added a commit
that referenced
this pull request
Aug 17, 2026
…6589) * evidence(OMN-16112): author OCC companion for OmniNode-ai/omnimarket#2085 The autobind writer never minted a companion for this product PR (verified live: no OCC PR, no branch, no contract entry references it) — its diff is a single-package uv.lock bump (mcp 1.28.0 -> 1.29.0, CVE-2026-59950) with no RED-derivable source file, which is outside autobind's current derivation surface. That gap is tracked separately as OMN-16118. Authored by hand on the occ#6573/OMN-10221 manual-companion precedent per controller authorization. Adds a net-new contract + two dod_evidence entries and their receipts, mirroring the #6573 template field-for-field: dod-OmniNode-ai-omnimarket-pr-2085 gh pr view 2085 --json number,state dod-OmniNode-ai-omnimarket-pr-2085-ci gh pr view 2085 --json files Both probes were executed live against omnimarket#2085's real head (2b4fac8076f5667c1ac44a3e87cdcac0c2efd51f); probe_stdout is the byte-exact capture, emitted as a literal block scalar so the yamlfmt v0.21.0 folded-scalar rewrite (OMN-15479) cannot touch it. Receipts carry both contract_sha256 (whole-file) and contract_entry_sha256 (per-entry, OMN-13888) computed via the canonical validator_receipt_gate hashers after a first yamlfmt pass stabilized the contract bytes. runner/verifier are this lane's own handles rather than the writer's (node_pr_lifecycle_fix_effect / occ-evidence-source-autobind) — this companion was not machine-minted and must not claim to have been. Local `validator_occ_merge_eligibility` run against omnimarket#2085's live title/branch/commit-sha with this commit's on-disk contract+receipts as the evidence source returns eligible:true. STILL REQUIRED before this can pass occ-preflight on its own PR: the occ-self-bind-pr-<N> entry + receipt, which cannot exist until the PR number does — same two-commit shape as the merged #6573/#903 companions. Evidence-Ticket: OMN-16112 * evidence(OMN-16112): occ-self-bind-pr-6589 Appends the mandatory self-bind evidence item for OCC companion PR #6589, per the merged #903/#6492/#6573 pattern (OMN-14650). This item cannot exist before the PR number does, so it lands as a second commit after opening #6589. Uses contract_entry_sha256 (per-entry, OMN-13888) rather than the legacy whole-file scheme #6573 used: appending this entry left the two existing receipts' own per-entry hashes byte-identical (verified via the canonical validator_receipt_gate hashers), so neither needed re-stamping. Only the whole-file contract_sha256 changed (file grew); both existing receipts carry contract_entry_sha256, which the gate treats as authoritative over contract_sha256, so they remain valid unmodified. Local verification, all green: - validator_occ_append_only --ticket-id OMN-16112 (in-repo, base = merge-base with origin/dev) -> ok:true. - validator_occ_merge_eligibility run twice: once as onex_change_control's own in-tree PR (#6589, its own title/branch/commit) -> eligible:true, and once simulating omnimarket#2085's real body with a live 'Evidence-Source: OCC#6589' line appended -> eligible:true. - check-receipt-honesty, check-contract-substance-floor, check-contract-shape-v1, check-dod-authoring-hygiene, check-receipt-hardening all Passed locally. Evidence-Ticket: OMN-16112 * fix(OMN-16112): replace PR-existence probes with admissible content reads OCC#6589's own Contract Compliance Check BLOCKed: both PR-scoped dod_evidence items used bare `gh pr view <n> --json ...`, which the OMN-15309 evidence-admissibility predicate treats as the paradigm "PR-existence probe" anti-pattern -- not falsifiable, proves only that a PR object exists. Bare `gh` is not in the admissible-command vocabulary (only the compound `gh api` token is), and the module's own comment names `gh pr view/list/status` as "trivially true via almost every ticket's own generated self-bind check" -- exactly the shape both merged precedents this companion was modeled on (occ#6573, occ#6583) also used. Neither precedent's Contract Compliance Check ever actually ran on its head (confirmed live: absent entirely from both PRs' check-runs, ~100 runs each) -- apparently because the job needs the ci:ready label to fire for real, which this companion has and the autobind-minted/earlier precedents evidently didn't at authoring time. So this is the first time this exact companion shape has been checked for real, and it fails honestly. Replaced two of the three items with genuinely admissible probes (EXECUTED, FALSIFIABLE, OUTSIDE ITS OWN DIFF per the predicate): dod-OmniNode-ai-omnimarket-pr-2085: reads uv.lock content at #2085's pinned head ref via `gh api .../contents/uv.lock?ref=<sha>` and asserts mcp==1.29.0 -- proves the CVE-2026-59950 fix actually landed in the file, not just that a PR exists. RED-verified against the vulnerable 1.28.0 string. dod-OmniNode-ai-omnimarket-pr-2085-ci: reads the actual diff via `gh api .../pulls/2085/files` (admitted per the module's own BLOCK-message guidance -- "/pulls/<n>/files ... returns the actual diff") and asserts the file list is exactly ["uv.lock"]. RED-verified against a fabricated two-file list. occ-self-bind-pr-6589 is left unchanged and stays individually INADMISSIBLE (WARN, not BLOCK) -- self-bind is structurally incapable of being "outside its own diff" (the predicate's own module comment acknowledges this class exists), and `_has_effective_check` only requires ONE admissible item across the contract, not all three, to avoid the hard BLOCK. Locally verified via `onex_change_control.validation.evidence_admissibility.classify_evidence` directly: both new items -> ADMISSIBLE; self-bind -> still NOT_EXECUTED as expected. contract_entry_sha256 recomputed for the two changed items via the canonical validator_receipt_gate hashers; occ-self-bind-pr-6589's own per-entry hash is byte-identical (unaffected, confirming the append-immunity property). validator_occ_append_only re-run against the origin/dev merge-base: ok:true (this ticket still diffs as pure 'A' -- the whole OMN-16112 corpus is net-new to dev). Local validator_occ_merge_eligibility re-run for omnimarket#2085's real Evidence-Source binding: eligible:true, unchanged. Evidence-Ticket: OMN-16112
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.
Summary
devto protectedmainWhy
Infra workflows invoke
OmniNode-ai/onex_change_control/.github/actions/validate-boundaries@main. OCC#2083 fixed this ondev, butmainstill degrades when the caller repo clone flakes, causing optional infra boundary jobs to fail even when the requested check passes.Evidence-Ticket: OMN-12574
Evidence-Source: OCC#2083
Verification
LC_ALL=C LANG=C uv run pre-commit run --files .github/actions/validate-boundaries/action.yml