[jonahgabriel]

The seam nothing in this repository can see

In a test the producer and the consumer are the same commit. Version skew is therefore inexpressible as an in-repository test, and version skew is the entire defect.

omnimarket#2692 added published_at to ModelDelegateSkillRequest. Every check passed. The deployed consumer was an older released wheel whose model forbids extras, so it refused the payload at the decode boundary and dead-lettered every delegate (OMN-18852). 771 golden-chain files did not catch it and could not have.

A version comparison could not have caught it either, and this repository already has one. The postmortem records producer and consumer both reporting 0.4.134, because the consumer image had been baked fifteen minutes earlier from a different tree. Only decoding the new shape with the old model answers the question.

What the gate does

For every wire model module a pull request changes:

1. resolve the last released version from the release tags this tree descends from;
2. read that release's src/ out of git with git archive, no checkout, no second clone;
3. ask the working tree, in its own subprocess, which keys each model can emit;
4. push those keys through the released model's own model_validate, in a second subprocess whose sys.path is rooted in the released tree;
5. fail on that validator's own refusal, naming the field, the model and the release.

Two versions of one package cannot share an interpreter, which is why each tree gets its own process and the two exchange JSON.

Proof against real history, not only fixtures

Anchored at v0.4.133, the last release before published_at landed, against today's tree:

WIRE_COMPAT_REFUSED: the last released consumer (v0.4.133, version 0.4.133) cannot
decode this tree's wire payloads.
  src/omnimarket/models/delegation/wire/model_delegate_skill_request.py: the released
  consumer ModelDelegateSkillRequest at v0.4.133 REFUSES the key 'published_at':
  Extra inputs are not permitted

That last clause is the live terminal's own words from 2026-09-20T01:43:38Z, reproduced rather than paraphrased.

Positive control, same command against the current release: every wire model in the tree passes, WIRE_COMPAT_PASS on v0.4.166. Both are tests, not one-off runs.

Two decisions worth reviewing

It grades keys, not values. Every key carries one placeholder and only extra_forbidden and missing are findings. Synthesising a type-correct value per annotation means shipping a factory library, and every gap in it reddens a change that broke nothing, which is how a gate gets switched off. The two graded error types are exactly the two a placeholder cannot manufacture: one fires on a key being present, the other on it being absent, and neither reads the value.

It does NOT take the release-identity gate's shallow-clone fallback, deliberately. There, widening to the full tag list is the stricter answer. Here the arithmetic inverts: fewer reachable tags resolve an older consumer that knows fewer fields, so --merged is the strict direction and the full list is the permissive one. git tag --merged is used unconditionally and an unresolvable anchor raises.

Controls

Fourteen, split so neither half can stand alone. A gate with only falsifiers is a blanket freeze; a gate with only positive controls has never been proven able to fail.

• Falsifiers — added field the release refuses; dropped field the release still requires; and the one that separates this from a same-commit test, a tree whose own model tolerates the payload while the release does not, with a first assertion proving the tree really is blind.
• Positive controls — a field the release already declares; a release that tolerates extras; a change outside the wire package; a module the release does not contain; and the current release decoding today's wire models.
• Fail-closed arms — no release tag, a release carrying no source tree, a released module that will not import, and the guard against a probe resolving the working tree as the release.
• Drift guard — the declared wire-model set is asserted against every wire/ package in the tree, so a new one turns a test red until someone decides in writing whether it is graded.

Enforcement

Registered in the strict gate-job set, so it blocks through the existing required CI Summary context. No branch-protection change is required and none is requested, on the same terms as the release-identity gate: that context is already required on dev and main, so a pull request whose wire payload no released consumer can decode cannot be required-green.

Limits, stated rather than left to be found

• Top-level keys only. A nested model's shape change is graded when that model's own module is in the changed set, not transitively through its parent. A nested type living outside the wire package is out of scope.
• No waiver list. One was considered and rejected: a waiver is the hole the gate exists to close, and the sanctioned escape is the release order it is enforcing.
• It grades the maximal shape the producer can emit, so a new optional field is a finding even where the producer omits it while unset. That is the rule working, not over-strictness: published_at is excluded when None today and is still refused the moment anything stamps it, which is the reason the field exists.

Ticket: OMN-18868. Parent: OMN-18864. Cause: OMN-18852, OMN-18633.

Evidence-Ticket: OMN-18868
Evidence-Source: OCC#10788

The change-control citation above was moved from the earlier companion to OCC#10788, which adds a record binding the wire-compatibility proof to the current head d5d5ece of this pull request. The earlier companion records describe superseded heads.

[github-actions]

⚠️ Architectural Review — WARNINGS

Errors: 0
Warnings: 1

What this checks

Rule	Description
ARCH-TOPIC-001	No hardcoded Kafka topic strings in handler code
ARCH-DI-001	No event_bus=None bypass
ARCH-DI-002	No direct Handler instantiation outside workflow_runner/adapters
ARCH-DI-003	No reinvented DI containers
ARCH-TOPIC-002	contract.yaml topics follow `onex.{cmd

---

ARCH-DI-002: Direct Handler instantiation (warning)\n\n```\nsrc/omnimarket/nodes/node_delegate_skill_orchestrator/ports/port_local_delegation_dispatch.py:796: self._effect_handler = effect_handler or HandlerLlmDelegationCall()

src/omnimarket/nodes/node_delegate_skill_orchestrator/ports/port_local_delegation_dispatch.py:797: self._projection_handler = projection_handler or HandlerProjectionDelegation()
src/omnimarket/nodes/node_delegate_skill_orchestrator/ports/port_local_delegation_dispatch.py:817: self._judge = judge if judge is not None else HandlerJudgeAdequacy()\n```\n\nHandler classes should be wired only in workflow_runner.py or adapter modules. Direct instantiation elsewhere bypasses the contract system.\n\n

Static architectural lint — no model inference (OMN-14176).

[github-actions]

✅ Hostile Reviewer — PASSED

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

---

Gate semantics

Verdict	Meaning	Blocks merge?
passed	>=2 models succeeded, no critical/error findings	No
blocked	CRITICAL or ERROR findings found	Yes
degraded	Fewer than 2 models succeeded (infra unavailable/timeout)	Yes (OMN-15110)

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

[jonahgabriel]

Pre-PR proof countersign: receipt sha256=9f422e1dc77b995c2d5a46efbdfd77d245f443d7f2698c6d6f85b633318ef5af actor=prepr-countersign verdict=COUNTERSIGNED-WITH-LIMITS

Third-actor confirmation of the OMN-19050 latch fix on this chain. The digest above is the attempt-scoped supersede record in the companion. The fresh-event claim holds and the resolver behaves exactly as the semantics require. I also found one thing the lane did not ask me to look for, at the end, and it is the reason this is a limits verdict rather than a clean one.

This was a fresh event, not a replay, on six independent discriminators. Any one could have failed and none did.

	the FAIL	the PASS
Actions run	35620477201	35654233846
run attempt	1	1
head commit	bab99887	b5c6f7a4
created	15:39:58Z	20:57:04Z
duration	15607 ms	16885 ms
tests	1 failed, 12 passed, 1 skipped	18 passed, 2 skipped

Two run identifiers with both attempts reading one rules out a re-run, which mints a second attempt on the first identifier rather than a new run. The test totals differ, fourteen against twenty, so the two executions did not see the same tree. The timing is tight in the right direction: the merge commit was authored at 20:56:58Z and the run created six seconds later.

It executed merged code. The omnimarket half merged at 20:50:18Z and its merge commit is an ancestor of this head with nothing behind. The other two merged at 20:12:35Z and 20:35:00Z, both before the run was created. I re-asserted the merged-code point the way the lane asked, but by content rather than by git diff: both modules I ran were staged as immutable archives addressed by their merge commits and their digests compared against the authoritative blobs at those same commits.

I ran the merged resolver rather than reading it, against the three real record files, unmodified.

A positive control: FAIL record alone        -> FAIL  from ...supersede.2751.yaml
B real chain, records unmodified             -> PASS  from ...supersede.2751.0002.yaml
C negative control: PASS at the FAIL head    -> FAIL  from ...supersede.2751.yaml
D positive control: PASS at any other sha    -> PASS  from ...supersede.2751.0002.yaml

Case B is the selection this confirmation is about, and it matches what the lane reported. Case C is the negative control the semantics require: the only field differing from B is the passing record's commit identifier, set to the failing record's own head, and the resolver returns the failing record. A pass re-filed at the head that already failed does not clear it, so the chain cannot be used as a retry-until-green channel. Case D exists because C alone would not separate the rule from the mutation; moving the identifier anywhere else restores the pass.

Worth noting as correct rather than incidental: the guard compares against the latest prior failure and then stops, so an old failure at an unrelated head cannot be resurrected by a later pass that happens to share its commit.

The finding. The two halves of this fix disagree on the negative control, and I measured it. The gate helper the third pull request changed is not a caller of the resolver; it is a second, independent implementation of the same selection, and the guard was added to only one of them. Running the merged gate helper over the identical four cases:

case	merged resolver	merged gate helper
A FAIL alone	the FAIL	the FAIL
B real chain	the PASS	the PASS
C PASS at the FAIL head	the FAIL	the PASS
D PASS at another sha	the PASS	the PASS

The gate helper ranks purely by dotted-numeric sequence and applies no commit-identity guard, so on case C it selects the record the resolver refuses. On the live chain this changes nothing, because the real records carry different commits and both halves agree on case B, which is why this is a limits verdict and not a refusal.

I am not calling it an open hole, because I did not establish which of the two binds the evidence outcome. The gate's own documentation names the resolver as the authority for the active receipt and casts the gate as validating the replacement, which if correct makes this a defence-in-depth gap rather than a bypass. That is the question for the owners, and the answer decides the severity. The durable fix is the same either way: have the gate call the resolver rather than reimplement its ranking, so a future rule cannot be added to one and missed by the other. One rule with two implementations is how this class of divergence recurs.

Not proven, and not substituted for. This pull request has not merged and its preflight is still red, which the lane stated plainly and which I am not treating as part of the claim. The cause is a formatting hook in the companion wanting to re-wrap the failing record's captured output scalar, red since before any of this work existed and handed to another lane. What is countersigned here is the resolution behaviour on the live chain, not mergeability today.