fix(OMN-15137): provision omnibase_spi via a shared sibling-clone manifest

[jonahgabriel]

OMN-15137

Fixes ensure_runner_clones.sh never provisioning omnibase_spi under the deploy runner's private OMNI_HOME, which blocked OMN-14900 stability deploy-hop re-fire iteration N+3 (run https://github.com/OmniNode-ai/omnibase_infra/actions/runs/30175447119, 2026-07-25). Rollback was clean, no prod/judge impact.

Root cause

RUNNER_CLONE_REPOS in ensure_runner_clones.sh hardcoded a 5-repo list. stage_workspace.sh's sibling-pin preflight (PREFLIGHT_REPO_ARGS → check_sibling_lock_pins.py's DEFAULT_PACKAGE_REPO_DIRS) has required a live OMNI_HOME/omnibase_spi clone since OMN-12977 — a 6-repo list. The two lists were independently hardcoded and drifted apart silently; the gap only surfaced 3 deploy hops deep, after OMN-15122 and OMN-15131 were fixed and a run finally reached this step.

Fix (root pattern, not just the one repo)

Added scripts/runtime_build/sibling_clone_manifest.sh as the single source of truth for the full 6-repo sibling-clone set the workspace build resolves clones for: omnibase_infra, omnibase_core, omnibase_spi, omnibase_compat, onex_change_control, omnimarket. Both ensure_runner_clones.sh (RUNNER_CLONE_REPOS) and stage_workspace.sh (PREFLIGHT_REPO_ARGS) now source this file instead of independently hardcoding their own copy — they can never diverge again. ensure_runner_clones.sh's existing existence/operability loop already fails fast and names any missing clone; feeding it the complete manifest makes that loop the "preflight names any missing clone before deploy starts" behavior the ticket asks for, with no new logic needed.

Audited full sibling set (Dockerfile.runtime + stage_workspace.sh):

• omnibase_infra — Docker build context itself, never vendored as a "sibling," but still needs a clone for RUNNER_CLONE_REPOS/RT-1.
• omnibase_core, omnibase_compat, onex_change_control, omnimarket — vendored as source via stage_workspace.sh's SIBLING_REPOS.
• omnibase_spi — installed from the published PyPI wheel via uv sync (never staged from local source), but still needs a live OMNI_HOME clone so the pin-preflight can read its pyproject.toml version + git SHA against the consuming lock.

No 7th sibling exists in any lock file — check_sibling_lock_pins.py's DEFAULT_PACKAGE_REPO_DIRS has exactly these 6 entries, confirmed by the new parity test below.

Tests (new)

• tests/scripts/test_ensure_runner_clones.py — end-to-end against real file:// git remotes: proves all 6 repos including omnibase_spi are cloned, idempotent re-run, fail-closed + named-repo error on missing upstream, fail-closed on an unwritable clone .git dir, fail-closed on missing OMNI_HOME. Confirmed RED against the pre-fix 5-repo manifest (7/8 assertions fail without omnibase_spi in the list).
• tests/scripts/test_sibling_clone_manifest_parity.py — cross-language recurrence ratchet: asserts sibling_clone_manifest.sh's bash arrays exactly match check_sibling_lock_pins.py's DEFAULT_PACKAGE_REPO_DIRS, so a future 7th sibling added on one side and forgotten on the other fails CI immediately instead of failing 3 deploy hops deep on a real runner.

Verification (.200, env -u PYTHONPATH uv run pytest, homebrew bash 5.3 on PATH)

• New files: 8/8 passed.
• Full regression set (new + existing stage_workspace/check_sibling_lock_pins coverage): 67/67 passed.
• ruff format --check + ruff check: clean.
• shellcheck --severity=warning (all 3 shell files): clean.
• bash -n: syntax OK.
• pre-commit (scoped to changed files): all hooks passed, including SPDX.

Aside (not fixed here, out of scope): macOS system /bin/bash 3.2 has a pre-existing, unrelated nounset-on-empty-array bug that reproduces at stage_workspace.sh line ~204 (preflight_extra[@]: unbound variable) when tests invoke bash and it resolves to the system binary instead of a modern one. Confirmed identical on unmodified dev tip (not a regression from this PR); GNU bash 4.4+ (what the real Linux deploy runner uses) does not have this bug.

dod_evidence

• Ticket: OMN-15137 (parent OMN-14900).
• Root cause reproduced live, per ticket run https://github.com/OmniNode-ai/omnibase_infra/actions/runs/30175447119.
• Acceptance per ticket: a fresh release-train-lab.yml stability-lane execute=true run reaching past check_sibling_lock_pins.py without an omnibase-spi clone-pin resolution error. This PR does not itself trigger that run (requires a fresh cut/deploy hop, out of scope for this PR); a RED-confirmed test now proves the fix, and the next stability deploy hop is the live acceptance readback.

Not merging this PR myself — Codex owns merge queue / merge per repo policy.

Evidence-Ticket: OMN-15137
Evidence-Source: OCC#4877

Evidence-Commit: d798061a08b31457c2213ba410d89bf9b12612c8

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your recent review volume is higher than typical usage, so adaptive limits are currently applied.

Next review available in: 17 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: f7a071b6-10ea-400b-93c9-a0974708c859

📥 Commits

Reviewing files that changed from the base of the PR and between 3e7e487 and 5f2427f.

📒 Files selected for processing (6)

• scripts/runtime_build/ensure_runner_clones.sh
• scripts/runtime_build/sibling_clone_manifest.sh
• scripts/runtime_build/stage_workspace.sh
• tests/scripts/test_ensure_runner_clones.py
• tests/scripts/test_sibling_clone_manifest_parity.py
• tests/unit/scripts/test_runner_private_omni_home_safe_directory.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jonah/omn-15137-ensure_runner_clonessh-never-provisions-omnibase_spi-sibling

---

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

⚠️ Hostile Reviewer — DEGRADED (informational)

Blocking findings (critical): 0
Total findings: 0
Models succeeded: none

Note: All reviewer models failed or were unavailable. Degraded results are informational during the pilot phase (OMN-8468/OMN-8524) and do not block merge. Error: all review endpoints [192.168.86.201:8000 192.168.86.201:8001 ] unreachable — preflight short-circuit (no models available)

---

Gate semantics (pilot phase)

Verdict	Meaning	Blocks merge?
passed	No critical findings	No
blocked	CRITICAL findings found	Yes
degraded	All models unavailable (infra)	No (pilot)

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