[jonahgabriel]

OMN-18622

Advances the omnimarket pin in omniclaude from the dev commit fa7f0d26f37a638f3985c1b19c43728a118a7dba (version 0.4.95, 2026-09-15) to 00aefdee52166dfa1d63e0adb776a7eb04b982d0, the v0.4.113 release commit published 2026-09-17T15:58:51Z, which is also the release-synced main of that repo.

version	0.4.95 -> 0.4.113
commits in range	58
pinned rev date	2026-09-15 -> 2026-09-17

Authorization

Operator ruling, in-session 2026-09-17T19:40:00Z, firm: "if we need to pin then pin. What's the benefit. Bump the pin." Durable record: the RULING row at ROLLING_WORK_LEDGER.md@2026-09-17T19:40:00Z, whose RESOLUTION names this exact surface and its restore path (revert this PR).

Why this was stale

.github/workflows/sibling-lock-refresh.yml runs daily and lists omnimarket in its default package set, but refreshes with uv lock --upgrade-package, which cannot move an immutable rev in [tool.uv.sources]. The workflow header records that limitation and names omnibase-infra as the example; omnimarket is in the same state and is not named. So the bot reported nothing to do while the pin decayed 58 commits. Same silent-no-op class as OMN-17176.

The previous rev was also a dev commit rather than a tag, so the pin never tracked the release line at all. That is why the version numbers look adjacent while the commit range is not. This PR pins a release commit, and both comment blocks now say to keep doing that.

Changes

• pyproject.toml — both omnimarket references (the dependency entry and the [tool.uv.sources] override) advanced, with comments recording why a bump here is a deliberate act.
• uv.lock — regenerated with uv lock --upgrade-package omnimarket, never a whole-tree upgrade. The diff is 4 lines: the version, the source URL, and two dependencies back-references. No other package moved, and the transitive dependency list of omnimarket is unchanged.
• .secrets.baseline — the detect-secrets pre-commit hook rewrote its generated_at timestamp on commit. Timestamp only; no finding added or removed.

The [tool.uv.sources] git override is retained deliberately. scripts/check_dep_provenance.py requires direct VCS provenance for this package and a PyPI source is structurally rejected (OMN-16528). The right fix for the automation gap is a refresh path that can move an immutable rev, which is the parent ticket OMN-13902, not a weaker provenance rule.

Verification run locally

check	result
uv lock --upgrade-package omnimarket	Updated omnimarket v0.4.95 (fa7f0d26) -> v0.4.113 (00aefdee)
uv sync --frozen then importlib.metadata.version('omnimarket')	0.4.113
import smoke over all 7 src/ modules importing omnimarket	7 OK, 0 failures
focused tests, batch 1 (11 files)	213 passed, 1 skipped
focused tests, batch 2 (6 files)	66 passed
scripts/check_dep_provenance.py	exit 0, no forbidden override
uv run ruff format --check src/ tests/	1465 files already formatted
uv run ruff check src/ tests/	All checks passed
uv run mypy src/ --strict	no issues in 740 source files
pre-commit run --all-files	exit 0
governed pre-push	green, no bypass flag and no env override

Test files run were every one covering a module that imports omnimarket under src/ and plugins/: tests/hooks/test_emit_client_wrapper.py, test_event_registry.py, test_hooks_bus_bootstrap.py, test_generate_event_registry.py, test_golden_path_session_lifecycle.py, test_node_session_lifecycle_reducer.py, tests/lib/core/test_bus_bootstrap.py, tests/unit/delegation/test_bus_bootstrap.py, tests/unit/hooks/test_hook_emit_drainer.py, test_node_event_emit_effect_dispatch.py, tests/unit/routing/test_routing_recorder.py, tests/unit/verification/test_evidence_writer.py, tests/runtime/test_lifecycle.py, test_lifecycle_bootstrapper.py, tests/scripts/test_install_hook_emit_drainer.py, test_install_hook_emit_drainer_status.py, tests/unit/runtime/test_golden_chain_skill_lifecycle.py.

Blast radius

58 commits of omnimarket change reach every omniclaude surface that imports it. The operator accepted that in the ruling. Nothing broke locally. If CI exposes an API change, a call-site rename or a model field move is fixed in this PR; a behaviour change that resists two attempts is diagnosed rather than worked around.

Follow-up after merge

The plugin CLI venv is built with uv sync --frozen, so it follows this lock. It is rebuilt through scripts/repair-plugin-venv.sh and read back once this lands.

Evidence-Ticket: OMN-18622
Evidence-Source: OCC#10080

[github-actions]

✅ Hostile Reviewer — PASSED

Blocking findings (critical/error): 0
Total findings: 11
Models succeeded: deepseek-r1,qwen3-review-b

Findings

Severity	Location	Finding
warning	pyproject.toml, [tool.uv.sources] section:1	ai-reviewer:deepseek-r1:security Immutable rev pin defeats supply-chain integrity verification | The diff replaces a dev-tip pin with a release commit pin, but the fundamental mechanism remains an immutable git rev in [tool.uv.sources]. The comment explicitly states that 'uv lock --upgrade-package cannot move an immutable rev', meaning the lockfile is the sole source of truth for which commit is used. There is no cryptographic signature verification, no tag-based pinning (which would allow git verify-tag), and no SBOM attestation. The co
warning	uv.lock, [[package]] name = "omnimarket":1	ai-reviewer:deepseek-r1:correctness Version jump 0.4.95 to 0.4.113 with no intermediate compatibility validation | The lockfile shows omnimarket jumping from version 0.4.95 to 0.4.113, a 18-minor-version gap. The diff contains no evidence of a compatibility matrix, no changelog review, and no test that exercises the delta between these versions. The comment says the previous pin 'predates the canonical projection adapter query surface this PR exercises', implying the jump was necessary for a specific feature. However, 18 minor versions of a l
warning	pyproject.toml, override-dependencies and [tool.uv.sources]:1	ai-reviewer:deepseek-r1:architecture Dual pinning in override-dependencies and [tool.uv.sources] creates a single point of failure | The diff updates the omnimarket rev in three places: the override-dependencies list, the [tool.uv.sources] section, and the uv.lock file. The comment in the workflow file states that 'sibling-lock-refresh.yml names omnimarket in its default package set but cannot move it, because uv lock --upgrade-package cannot move an immutable rev in [tool.uv.sources]'. This means the [tool.uv.sources] pin is the authoritative
info	.github/workflows/omnimarket-dispatch-drift-gate.yml:1	ai-reviewer:deepseek-r1:completeness No automated check that the pinned commit is actually a release commit | The comment states 'Advance it to a RELEASE commit, never a branch head', but there is no automated enforcement of this rule. A future operator could pin a branch head commit and the build would succeed. The workflow file mentions 'this baseline is a mechanical diff against gh release list', but the actual check is not present in the diff. Without an automated gate, the 'release commit only' policy is a comment, not a constraint. | Evi
info	N/A (test files not in diff):1	ai-reviewer:deepseek-r1:testing No test coverage for the specific feature that motivated the pin bump | The comment says the previous pin 'predates the canonical projection adapter query surface this PR exercises'. This implies there is a test that exercises this surface, but the diff does not include any test file changes. If the test already exists, it is not shown. If it does not exist, the pin bump is unvalidated. The diff should include or reference the test that confirms the canonical projection adapter query surface works in 0.4.11
hint	.github/workflows/omnimarket-dispatch-drift-gate.yml:1	ai-reviewer:deepseek-r1:style Comment block is overly verbose and mixes operational context with code | The comment in the workflow file is 12 lines long and includes operational context ('Operator ruling, in-session 2026-09-17T19:40:00Z, firm'), ticket numbers, and historical narrative. While the context is useful, it bloats the code and makes the actual pinning logic harder to find. The 'firm' qualifier is not a code comment; it is a meeting note. | Evidence: # OMN-18622: bumped fa7f0d26 -> 00aefdee, which is the v0.4.113 RELEASE comm
error	pyproject.toml:1	ai-reviewer:qwen3-review-b:security Unpinned git dependency allows supply-chain compromise | The diff pins omnimarket to a specific commit SHA (00aefdee), but the source is a git URL. Unlike PyPI packages, git dependencies are not signed by default. An attacker who compromises the GitHub repository or the git protocol could push a malicious commit and, if the SHA is ever updated or if the lock file is regenerated, the malicious code would be pulled. More critically, the comment explicitly states the pin is a 'release commit' and 'release-sync
warning	uv.lock:1	ai-reviewer:qwen3-review-b:correctness Version jump from 0.4.95 to 0.4.113 lacks compatibility verification | The diff updates the omnimarket version from 0.4.95 to 0.4.113. This is a 18-version jump. The diff does not include any changes to the consuming code in this repository. If the API surface of omnimarket changed between these versions (e.g., breaking changes in the 'canonical projection adapter query surface' mentioned in the comment), the existing code may fail at runtime or exhibit subtle behavioral changes. The comment claims the new
warning	N/A:1	ai-reviewer:qwen3-review-b:completeness Missing test coverage for the new dependency version | The diff updates a critical dependency but does not add or modify any test files. The comment mentions that 'ordered/query metadata tests' were failing against the older adapter and are now expected to pass. However, there is no evidence in the diff that these tests have been added or updated to reflect the new version's behavior. If the tests are pre-existing, they may not cover the new features or edge cases introduced in 0.4.113. This creates a risk
info	pyproject.toml:1	ai-reviewer:qwen3-review-b:architecture Inconsistent pinning strategy across dependencies | The diff pins omnimarket to a release commit, but other dependencies like onex-change-control and omninode-intelligence are pinned to arbitrary SHAs. The comment justifies this for omnimarket by stating that 'uv lock --upgrade-package cannot move an immutable rev'. However, this creates an inconsistent architecture where some dependencies are pinned to releases and others to arbitrary commits. This makes it difficult to reason about the overall system's st
hint	pyproject.toml:1	ai-reviewer:qwen3-review-b:style Redundant comments in pyproject.toml | The diff adds multiple comments to the pyproject.toml file that repeat the same information. For example, the comment above the override-dependencies and the comment above the [tool.uv.sources] section both explain the same rationale for pinning to a release commit. This redundancy makes the file harder to read and maintain. If the rationale changes, it must be updated in multiple places. | Evidence: # OMN-18622: advanced to the v0.4.113 release commit ... # OMN-18622:

---

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)