[jonahgabriel]

fix(OMN-20331): CI reads every sibling repo at its pinned version, never a live branch

Rule

Operator ruling 2026-10-01: each repo checks only itself; any read of a sibling uses the version this repo has PINNED (uv.lock rev or version, release tag, recorded sha), never the sibling's live branch, so a merge in one repo cannot turn another repo red. New sibling version is integration-tested by the consumer before it moves its pin.

What changed (70 files, .github/workflows plus scripts/validation plus tests)

Workflow caller updates

• occ-preflight.yml (omnibase_core): @main -> @52851458622f368c3b596c82bf810bc6acce1d5e in 55 workflow callers.
• zone-filter.yml: @main``@7631ef3321e1a6561f4b2c70019ee57d24160620 (same shas omnimarket uses).
• docs-validate: validate-docs.yml -> 52851458.

onex_change_control updates

• validate-boundaries (ci.yml boundary-parity) and validate-contract (contract-validation.yml): @main -> @47342e562a516b0278e22a974f35cbf2a64b33eb (uv.lock OCC rev).
• pr-title-check-reusable: @main -> @babdd13ce68f07df20f989f52ff1c4514d03d896 (the sha ci_summary_gate.py records its mirror as read from).

Checkouts and clones resolved from uv.lock

Checkouts/clones are now resolved from uv.lock by an in-workflow step (no new scripts):

• ci.yml: check-handshake and canon-shape-ratchet use omnibase_core tag v<lock version> (was no ref / dev).
• golden-chain-integrity and registry-consistency: use the omnimarket rev uv.lock pins, 750808959945 (was dev and the feature branch codex/omn-20001-m3-fg2).
• skill-contract-validation and precommit-suite: use onex_change_control lock rev (was main).
• receipt-honesty and skill-receipt-mode-gate: use omnibase_core tag.
• hostile-reviewer: uses omniintelligence lock rev, omnibase_core and omnibase_compat lock tags (was branch dev).
• onex-schema-compat, validate-agent-configs: use OCC lock rev.
• validate-skill-aspiration, validate-skill-backing-node: use omnimarket lock rev.
• validate-pr-contracts: uses omnibase_infra lock tag.
• call-occ-autobind and call-occ-companion-effect callers: use omnimarket lock rev.
• Reusables' omnimarket-ref default: dev -> release tag v0.4.278 (the omnimarket version uv.lock records; the tag contains the pinned rev 750808959945).

Producer reusables

• deploy-gate-reusable and required-check-skip-guard-reusable read omniclaude at the validated job.workflow_sha (the pattern kb-doc-gate-reusable already uses), with an assert-at-pin step.
• deploy-gate composite action is used from that checkout instead of @main.

Tests

• New tests/ci/test_sibling_reads_pinned_omn20001.py scans every workflow.
• Run against origin/dev it reports 79 violations; on this branch 0.
• Includes a positive control (a dirty synthetic workflow yields 5 findings) and a clean control.
• Updated six tests that encoded the old live-branch behaviour: four in the first revision, plus the hostile-reviewer clone test (now asserts the pinned reads) and the dispatch-drift sha-literal scan (now ignores uses: lines).

Not changed, with reasons

• sibling-lock-refresh.yml: reads omnimarket dev on purpose (it is the sanctioned pin-mover).
• ci.yml: dod-evidence-check and contract-compliance read OCC evidence data at the exact sha a ticket names (a resolved 40-hex commit, not a branch).
• reject-deploy-gate-skip.yml: reads the OCC bypass allowlist from OCC main through the API (a live central registry, not code, not in the finding list).

How pins move

• uv.lock-resolved reads: move with the lock (sibling-lock-refresh / dependency bump PR).
• sha pins in uses: lines (omnibase_core 52851458 and 7631ef33, OCC 47342e56 and babdd13c) and the omnimarket-ref defaults: move only by a consumer PR after the consumer integration-tests the new sibling rev.

Supersedes

• Supersedes fix(OMN-20001): registry-consistency jobs read the omnimarket rev pinned in uv.lock #2478 (omnimarket jobs) and fix(OMN-20001): skip-guard reusable reads its validator at the caller's pinned sha #2479 (skip-guard reusable reads its validator at job.workflow_sha; fix(OMN-20331): CI reads every sibling repo at its pinned version, never a live branch #2480 carries the same change with an added workflow-repository check and file-existence assert, and now also carries fix(OMN-20001): skip-guard reusable reads its validator at the caller's pinned sha #2479's test tests/ci/test_skip_guard_validator_pinned_omn20001.py). Both are closed.

Rebase and pin

• Branch omn-20001-sibling-pin-fix was rebased onto origin/dev 89d74d586.
• Four conflicts were resolved: ci.yml, pyproject.toml, and uv.lock (twice).
• The registry checkout step in ci.yml keeps the PR side, where the ref is the omnimarket rev read from uv.lock, not dev.
• The pin is read from uv.lock: omnimarket rev 750808959945ef7e4ddf5e6da5c4faac8caef530, locked version 0.4.278.
• Dev already carried this pin through a bot lock refresh, so dev's side was kept for it.
• The pin descends from d471dcb96d054e85089a63437aa05c1ef68bfee5 (0.4.277) and contains 5dac7e4a, the commit that registers the 11 work.ledger.typed.* event types.
• Verified via git merge-base --is-ancestor 5dac7e4a for both revs.
• The rev e11987165b96, named in earlier text in this PR, is the parent of 5dac7e4a and lacks the 11 types; it is no longer the pin.
• omninode-intelligence is pinned to 43be97b1f47435dfbbd835ff8f5b4484c4dee282 (this PR's own commit; the hostile-reviewer job needs gpt-oss-review).
• Drift is strict: scripts/validation/check_registry_consistency.py and scripts/validation/generate_event_registry.py are byte-identical to origin/dev and fail on any event type omniclaude has that the pinned omnimarket registry lacks. This PR changes neither script.

Strict drift proof and lab readback

• Against omnimarket at 750808959945:
  • check_registry_consistency.py exits 0 ("Registry consistency gate passed.")
  • generate_event_registry.py --check exits 0 ("77 event types match")
• Positive control, against omnimarket at e11987165b96:
  • check_registry_consistency.py exits 1, naming all 11 work.ledger.typed.* types missing
  • generate_event_registry.py --check exits 1
• New tests in tests/hooks/test_registry_consistency_script_omn19513.py prove both directions:
  • A daemon registry mirroring omniclaude passes (exit 0)
  • The same registry minus one event type fails (exit 1, names the type)
• Not runtime-affecting: this changes CI workflows, validation scripts, and tests only.
• Lab run on host h202 (lane rebase-2480-strict, in the pushed worktree) at head 0d1d39452afddeb18de14ad26adb0885f25d5648:
  • Tests run:
    • tests/hooks/test_registry_consistency_script_omn19513.py
    • tests/hooks/test_generate_event_registry.py
    • tests/hooks/test_registry_consistency.py
    • tests/hooks/test_hostile_reviewer_workflow.py
    • tests/test_dispatch_drift_authority.py
    • tests/ci/test_sibling_reads_pinned_omn20001.py
    • tests/ci/test_skip_guard_validator_pinned_omn20001.py
    • tests/ci/test_ci_summary_gate_bot_skip_omn19167.py
  • Result: 112 passed, exit 0
  • uv lock --check: consistent
  • The onex_lab_run placement tool refused:
    • Bus mode: no interpreter configured, exit 64
    • Ssh mode: exit 75, h200 over the load bar, other hosts unreadable
  • The run was not placed through onex_lab_run

Red causes on the previous head 912009498 and their fixes:

• Tests (Split 2/5), Hooks System Tests (1/2): tests/hooks/test_hostile_reviewer_workflow.py still asserted the clones track --branch dev; updated to assert the uv.lock pinned reads.
• Tests (Split 4/5), tests+coverage (shadow): tests/test_dispatch_drift_authority.py forbade any 40-hex literal in omnimarket-dispatch-drift-gate.yml, including the new uses: pin of the omnibase_core reusable; the scan now ignores uses: lines.
• reason-graph, CI Summary, Tests Gate: followers of those test failures.
• Skip Count Ratchet: caused by a stale copy of tests/skills/test_lab_onboarding_script_omn20150.py (22 macos_only skips) from before dev's version, which has none; resolved by the rebase. skip_count_baseline is unchanged.
• occ-autobind / outcome: companion evidence is change-control PR 12244 (onex_change_control) (merged, carries contracts/OMN-20331.yaml). The autobind effect returned a 422 'No commits between dev and auto/window-omninode-ai-omniclaude-occ-autobind', i.e. it had no new delta to add; no companion was hand-authored.

dod_evidence

Verification

• Head 190debe9e11e67e014d9bcdb6a612d722546b9d4 (rebased on origin/dev 89d74d586); its last commit moves the two OCC reusable omnimarket-ref defaults to v0.4.278 and passed 46 focused tests.
• Focused pytest on lab host h202 at head 0d1d39452afddeb18de14ad26adb0885f25d5648: 112 passed, exit 0 (files listed under the lab readback below); then tests/workflows and tests/ci together on h202 after the reusable-default change: 1158 passed.
• Strict drift at the pin: both registry scripts exit 0 against omnimarket 750808959945; both exit 1 against e11987165b96 (positive control). Both directions are also proven by unit tests.
• ruff format and check clean on the touched test files; uv lock --check consistent.
• yaml parse of every workflow ok. actionlint is not installed on this host.
• Not runtime-affecting: CI workflows, validation scripts and tests only.
• Companion: the change-control companion for OMN-20331 is the already-merged change-control PR 12244; autobind did not mint a new one and none was hand-authored here.

Evidence-Ticket: OMN-20331
Evidence-Source: OCC#12244

[github-actions]

✅ Hostile Reviewer — PASSED

Blocking findings (critical/error): 0
Total findings: 13
Models succeeded: qwen3-review,gpt-oss-review

Findings

Severity	Location	Finding
warning	.github/workflows/ci.yml, .github/workflows/receipt-honesty.yml, .github/workflows/hostile-reviewer.yml, .github/workflows/skill-receipt-mode-gate.yml, .github/workflows/validate-pr-contracts.yml:1	ai-reviewer:qwen3-review:correctness awk version extraction from uv.lock is fragile and likely broken | The awk one-liner awk -v n=omnibase-core '$0 == "name = \"" n "\"" {getline; print $3; exit}' uv.lock assumes that the line immediately following name = "omnibase-core" contains the version as the third whitespace-delimited field. In uv.lock, the version field is on the next line, but the exact spacing and field position can vary. More critically, the comparison $0 == "name = \"" n "\"" constructs the string name = "omnibase-core"
warning	.github/workflows/deploy-gate-reusable.yml:1	ai-reviewer:qwen3-review:security deploy-gate-reusable.yml fetches omniclaude at job.workflow_sha without verifying the commit exists in the repo | The new pin resolution step in deploy-gate-reusable.yml uses job.workflow_sha to checkout omniclaude. However, job.workflow_sha is the SHA of the workflow file as pinned by the caller, not necessarily a commit that exists in the omniclaude repository. If the caller pins a SHA that is a merge commit or a commit that was force-pushed away, the checkout will fail. More importantly, there is no
warning	.github/workflows/call-occ-autobind.yml, .github/workflows/call-occ-companion-effect.yml, .github/workflows/ci.yml, .github/workflows/hostile-reviewer.yml, .github/workflows/validate-skill-aspiration.yml, .github/workflows/validate-skill-backing-node.yml:1	ai-reviewer:qwen3-review:correctness grep pattern for uv.lock rev extraction may not match the actual format | The grep pattern grep -oE 'omnimarket\.git\?rev=[0-9a-f]{40}' uv.lock assumes that the uv.lock file contains a line with the exact format omnimarket.git?rev=<40-hex>. However, in the diff, the uv.lock shows the format as git = "https://github.com/OmniNode-ai/omnimarket.git?rev=750808959945ef7e4ddf5e6da5c4faac8caef530". The grep pattern will match, but the sed 's/.*rev=//' will extract the SHA correctly. However, if the uv.lock
warning	tests/ci/test_sibling_reads_pinned_omn20001.py:1	ai-reviewer:qwen3-review:completeness Test for pinned sibling reads does not cover all workflow files | The new test test_no_workflow_reads_a_sibling_at_a_live_branch in tests/ci/test_sibling_reads_pinned_omn20001.py iterates over all .yml files in .github/workflows/, but the test only checks for violations in the YAML structure. It does not verify that the actual workflow files have been updated to use pinned refs. The test is a detector, not a verifier. If a workflow file is not updated, the test will pass vacuously because it only ch
info	.github/workflows/hostile-reviewer.yml:1	ai-reviewer:qwen3-review:performance Multiple git clone operations in hostile-reviewer.yml may be slow | The hostile-reviewer.yml workflow now performs three separate git clone operations (omniintelligence, omnibase_core, omnibase_compat) with retry logic. Each clone is a network operation that can be slow, and the retry logic adds additional latency. The previous implementation used a single git clone with --branch dev, which was faster. The new implementation is more correct but may be slower. | Evidence: for attempt in {1..4}; do
info	tests/ci/test_sibling_reads_pinned_omn20001.py:1	ai-reviewer:qwen3-review:correctness Test for registry consistency does not verify the actual pinned rev | The new test test_registry_gate_pins_omnimarket_to_the_lock_not_a_branch in tests/ci/test_sibling_reads_pinned_omn20001.py verifies that the registry-consistency job in ci.yml uses ${{ steps.om_pin.outputs.rev }} as the ref, but it does not verify that the om_pin step actually extracts the correct rev from uv.lock. The test only checks that the resolver step references uv.lock, not that it extracts the correct value. | Evi
info	.github/workflows/ci.yml, tests/ci/test_sibling_reads_pinned_omn20001.py:1	ai-reviewer:qwen3-review:completeness No test for the new pin resolution steps in ci.yml | The new pin resolution steps in ci.yml (for omnibase-core, omnimarket, and onex_change_control) are not covered by any test. The tests in tests/ci/test_sibling_reads_pinned_omn20001.py only check that the workflow files do not contain live branch refs, but they do not verify that the pin resolution steps work correctly. | Evidence: The new steps in ci.yml are not referenced in any test file. | Fix: Add tests that verify the pin resolution steps
hint	.github/workflows/call-occ-autobind.yml, .github/workflows/call-occ-companion-effect.yml, .github/workflows/ci.yml, .github/workflows/hostile-reviewer.yml, .github/workflows/validate-skill-aspiration.yml, .github/workflows/validate-skill-backing-node.yml:1	ai-reviewer:qwen3-review:style Inconsistent use of set -euo pipefail in new steps | Some of the new pin resolution steps use set -euo pipefail, while others do not. This inconsistency can lead to unexpected behavior if a command in the pipeline fails. For example, the grep command in the omnimarket rev extraction will fail if the pattern is not found, but without set -o pipefail, the failure of grep will not cause the pipeline to fail. | Evidence: Some steps have set -euo pipefail, others do not. | Fix: Standardize the use
error	.github/workflows/deploy-gate-reusable.yml:1	ai-reviewer:gpt-oss-review:correctness Invalid GitHub Actions context variables in pin validation steps | The new pin‑validation steps in deploy-gate-reusable.yml and required-check-skip-guard-reusable.yml reference job.workflow_sha and job.workflow_repository. These variables are not defined in the GitHub Actions context; the correct variables are github.workflow_sha and github.repository. As a result the validation logic will always fail (or be skipped) and the gate may either abort incorrectly or run without the intended pin verif
error	.github/workflows/required-check-skip-guard-reusable.yml:1	ai-reviewer:gpt-oss-review:correctness Same invalid context variables in required‑check‑skip‑guard workflow | The required-check-skip-guard-reusable.yml workflow also uses job.workflow_sha and job.workflow_repository to validate its pin. These variables are undefined, causing the pin validation to malfunction and potentially allowing the guard to run with an unintended version of the validator. | Evidence: In required-check-skip-guard-reusable.yml: ```yaml - name: Resolve the check-skip-vectors pin id: pin env: WORKFLOW_SHA: ${{
warning	Multiple workflow files (e.g., .github/workflows/ci.yml, .github/workflows/deploy-gate-reusable.yml, .github/workflows/required-check-skip-guard-reusable.yml, etc.):1	ai-reviewer:gpt-oss-review:architecture Brittle reliance on uv.lock parsing via shell commands | Multiple workflows now extract version pins by grepping and awk‑parsing uv.lock. This tightly couples CI logic to the exact text format of uv.lock. Any change in uv.lock layout (e.g., additional whitespace, reordered fields, or a different lock format) will cause these steps to fail, breaking the CI pipelines. | Evidence: Examples across many workflows, e.g., in ci.yml: ```sh rev="$(grep -oE 'omnimarket.git?rev=[0-9a-f]{40}' uv.lock | head -
info	All workflows that resolve pins via grep/awk (e.g., .github/workflows/ci.yml, .github/workflows/deploy-gate-reusable.yml):1	ai-reviewer:gpt-oss-review:correctness Assumes first matching entry in uv.lock when multiple entries exist | The pin‑resolution scripts use head -1 to select the first occurrence of a sibling in uv.lock. If a repository appears more than once (e.g., due to different extras), the script may pick an unintended revision or tag, leading to inconsistent builds. | Evidence: In ci.yml and other workflows: sh rev="$(grep -oE 'onex_change_control\.git\?rev=[0-9a-f]{40}' uv.lock | head -1 | sed 's/.*rev=//')" | Fix: Parse uv.lock structural
info	Multiple workflow files (e.g., .github/workflows/ci.yml, .github/workflows/deploy-gate-reusable.yml, .github/workflows/required-check-skip-guard-reusable.yml, etc.):1	ai-reviewer:gpt-oss-review:performance Added pin‑resolution steps increase CI runtime | Each workflow now includes extra steps to parse uv.lock, run git init, fetch specific revisions, and validate pins. While functionally correct, these steps add network I/O and CPU overhead, lengthening the overall CI execution time. | Evidence: New steps such as Resolve the pinned omnimarket rev, Resolve the pinned omnibase-core version, and similar appear in many workflows. | Fix: Cache the resolved pins as workflow artifacts or compute them once in

---

Gate semantics (pilot phase)

Verdict	Meaning	Blocks merge?
passed	No critical/error findings	No
blocked	CRITICAL or ERROR findings found	Yes
degraded	Reviewer ran but every model failed mid-run	No (pilot)
infra_error	cli_review failed to run at all (install/crash) after 2 attempts	Yes
unavailable_fork_isolation	Fork PR — the LAN-only model is unreachable and the fleet is off limits	Yes

Powered by omniintelligence.review_pairing.cli_review — node-based adversarial review via HandlerLlmCliSubprocess (OMN-8524)

[jonahgabriel]

Hold placed on this PR at head 50608e2 (ledger HOLD id 2026-10-01T23:37:50Z-hold-2480). This head carries a registry-drift tolerance that the operator ruling of 2026-10-01T23:26:53Z (lane ruling-pin-strict-drift) forbids. The strict restore cannot be committed yet: with drift strict, 11 work.ledger.typed.* types registered here are absent from the omnimarket rev that uv.lock pins (e11987165b96).

Release condition: an omnimarket release containing the work.ledger.typed.* types is published, AND this PR's omnimarket pin is bumped to that release with drift strict. Path: omnimarket#3207 merges, omnimarket releases, then this PR bumps the pin and lands strict. Do not arm or merge before then. Auto-merge is currently not armed.

[onexbot-occ-writer]

OCC autobind rebound this PR's evidence-source stamp line to OCC#12244.

The receipt gate's own eligibility validator, run against the change-control tree the gate pins for OCC#12244, returned eligible for head 162f068a02bc2c702a67b5b336b297863b95687c. The body now carries exactly one stamp line. Displaced: OCC#12242.

Reported by occ_companion_emitter (OMN-18853).