fix(OMN-15597): re-pin the AC5 census to the ticket's OCC SHA and correct its false provenance

[jonahgabriel]

OMN-15597 — G4: re-pin the AC5 census to the ticket's SHA and state its provenance truthfully

Repairs a false-provenance defect that is already on dev. Merged #1998 (3cb2633c) closed both of the lane-G verifier residuals correctly — the census oracle is genuinely un-vacuated and AC5 genuinely runs on hosted CI — but it did so against the wrong OCC SHA, and then asserted, in a green test, that it was the right one.

Nothing about the runner changes here. This PR touches two test files and no src/: the corpus snapshot and the assertions that describe it.

---

The defect

Three sites claimed the committed AC5 corpus is this ticket's blast-radius census:

• omn_15597_occ_census_pinned.py docstring — "That is the ticket's blast-radius census reproduced exactly: 59 checks / 33 contracts"
• TestAc5PinnedCorpusReCensus::test_pinned_corpus_is_the_census_the_ticket_names — asserts OCC_CENSUS_SHA == "9089ffa9…" and the 59 / 33 pair as "the ticket's numbers"
• the fix(OMN-15597): un-vacuate the AC5 census oracle and pin AC5 to a committed OCC corpus #1998 PR body

It is not. The corpus was pinned at onex_change_control@9089ffa9; OMN-15597's census point is d7b16271 (OCC#5760, 2026-07-31T20:57:21Z — the last OCC dev commit before the ticket was filed at 21:09:23Z).

The 59 / 33 agreement is a cardinality coincidence over a different contract set. The two 33-sets differ by two elements each way: the pin has OMN-14587 + OMN-15142, the ticket has OMN-15239 + OMN-15488. contracts/OMN-15239.yaml and contracts/OMN-15488.yaml do not exist at 9089ffa9 at all. OMN-15488 is the live motivating case the ticket names — the 12th steel instance tracked in OMN-15596, "carries three items in this exact nested-quote shape, so the next steel Done-flip hits this defect again unless the runner is fixed". The pinned corpus structurally could not contain the case AC5 exists to protect.

A green assertion that encodes a false provenance claim is exactly the defect class — "an assertion whose green means something other than what it says" — that #1998 was opened to close.

Provenance of the finding: raised by the #1998 adversarial verifier (fable-ws0-0731/laneG2-verify, Linear comment 7d7e31ff), which measured the SHA-by-SHA table and marked the ac5_option claim REFUTED on its second clause. Independently re-measured and confirmed by lane G3 (921b6c7b), which found no vehicle — #1998 merged 2026-08-01T11:51:46Z before G3 could push — and specified this repair. This lane is that repair; nothing here is taken on either lane's word (see the control below).

---

What changed

	before (#1998)	after
OCC_CENSUS_SHA	9089ffa9338b…	d7b162710514…
OCC_CENSUS_TOTAL_COMMAND_CHECK_VALUES	32564	32593
TOKENIZER_DAMAGE_CLASS	59 values	63 values
OCC_CENSUS_DAMAGE_CLASS_CONTRACT_COUNT	33	35
TOKENIZER_DAMAGE_PATH_COMMANDS	{gh, printf, test}	unchanged — re-derived, same set
NO_EVIDENCE_BUILTIN_CANDIDATES	28	28 — re-derived at the new SHA

The new class is a strict superset of the old 59: all 59 values are still present, plus exactly OMN-15239.yaml#0 and OMN-15488.yaml#0/#1/#2. Nothing was dropped to reach a number.

Regenerated by the fixture's own documented re-pin procedure — git archive <sha> contracts | tar -x, then rebuilding the three constants with the selectors that already live in test_omn_15597_command_substitution_shape_guard.py. There is still deliberately no generator script (it would be a second copy of the census oracle). AC6 respected: the OCC clone was read read-only via git archive; no contracts/*.yaml and no drift/dod_receipts/** file was written — git -C onex_change_control status shows no tracked modification.

---

Why the numbers changed — two independent axes, and this is the part #1998 got wrong

The counts are oracle-dependent AND SHA-dependent. #1998 carried 59 forward as though it were invariant. It is neither.

oracle	@ 9089ffa9	@ d7b16271 (the ticket's census point)
the oracle committed in this repo — vendored pre-fix guard REJECTS ∧ current guard ACCEPTS	59 / 33	63 / 35 ← this snapshot
the ticket's stated oracle — "the guard rejects AND a token at/before the judged index contains an unbalanced $("	52 / 30 (measured by the #1998 verifier)	56 / 32 (measured by lane G3)

So no oracle reproduces the ticket's literal 59 / 33 at its own census point. The 59 is an earlier reading under a different rule. It is now recorded as superseded, not reproduced — in the module docstring and in the renamed test — rather than being made to agree by editing a number.

Three independent signals put the ticket's census at d7b16271:

1. Its own stated scan total. The ticket's blast-radius section says "32,593 command check_values scanned" — exactly this SHA. 9089ffa9 scans 32,564.
2. Its own enumerated contract list. All 33 names it prints are present in this snapshot's 35. They are not all present at 9089ffa9, which lacks OMN-15239 and OMN-15488.
3. The motivating live case. OMN-15488's three items are precisely three of the four values this re-pin adds.

---

Provenance is now asserted, not implied

• test_pinned_corpus_is_the_census_the_ticket_names → test_pinned_corpus_is_the_ticket_census_point_under_the_committed_oracle. The name now states what it checks. It asserts the SHA, the scan total (32593 — signal 1 above, in-test), and 63 / 35, and its docstring keeps the two claims apart: the SHA is the ticket's census point; the counts are not the ticket's literal numbers.
• New — test_pinned_corpus_covers_every_contract_the_ticket_enumerates. This is the assertion fix(OMN-15597): un-vacuate the AC5 census oracle and pin AC5 to a committed OCC corpus #1998 lacked, and the reason a re-pin is the right remedy rather than a docstring edit: it requires containment of the ticket's 33 enumerated contract names, which a cardinality coincidence cannot satisfy, and pins OMN-15488.yaml#0/#1/#2 explicitly. The 33 names are transcribed from the ticket body into the test file, not the generated corpus module, so the check compares two independently sourced sets rather than a snapshot against itself. A len(...) == 33 guard catches a transcription typo that would silently weaken it.
• The corpus docstring now leads with a provenance block that names which oracle at which SHA, records the ticket's 59 as superseded, and explains why the pin moved.
• Also corrected, same docstring, same family (minor finding from the fix(OMN-15597): un-vacuate the AC5 census oracle and pin AC5 to a committed OCC corpus #1998 verifier): "the identical census returns 63 at OCC 1e6b75f8, one day later" — 1e6b75f8 is 2026-07-31T21:08:02Z and 9089ffa9 is 19:51:59Z. 76 minutes, same day. The count 63 was right; the interval was wrong by ~19×, and it understated how fast the corpus moves.

---

RED-before / GREEN-after — against the artifact that runs

The new assertions were run against the merged 3cb2633c corpus (only the corpus module reverted, tests held constant):

E  AssertionError: assert '9089ffa9338b...eeea5224663b0' == 'd7b162710514...534a9fef04da9'
E  AssertionError: 2 contracts the ticket enumerates are absent from the pinned
   census at OCC 9089ffa9: ['OMN-15239.yaml', 'OMN-15488.yaml']
FAILED ...::test_pinned_corpus_is_the_ticket_census_point_under_the_committed_oracle
FAILED ...::test_pinned_corpus_covers_every_contract_the_ticket_enumerates
2 failed, 6 passed

The containment failure names OMN-15488 on its own — the RED is the defect, not a number mismatch. The corpus was restored and re-hashed (sha256 175d09b4…) before every subsequent run; same class then reports 8 passed.

GREEN-after, OCC clone deliberately unreachable (OMNI_HOME and ONEX_CC_REPO_PATH cleared — the hosted-runner condition): 212 passed, 2 skipped. Up from #1998's 211 by the one new test. The only 2 skips remain TestOccLiveCorpusDriftDiagnostic, host-only by design and excluded from AC5.

Anti-fabrication control — the oracle is faithful, only the SHA moved

Before regenerating, the same procedure was run at the outgoing pin:

CONTROL @9089ffa9
  total scanned          : 32564 | recorded in the merged snapshot: 32564
  class size / contracts : 59 / 33
  resolved path cmds     : ['gh','printf','test'] | recorded: ['gh','printf','test']
  CLASS  exact dict match with the committed snapshot : True
  CANDS  exact dict match with the committed snapshot : True   (28 == 28)

It reproduces the merged snapshot key-for-key and byte-for-byte, so the divergence is the SHA, not the method. And the regenerated class was re-verified under the restricted which stub the committed test actually uses ({gh, printf, test} only): 0 of 63 still RED under the current guard, 0 of 63 accepted by the vendored pre-fix guard — the class is real at the new SHA, not just larger.

---

Gates — all on stickybeatz-studio (.200), push included

Remote-only lane. Every mutation was made over ssh (heredoc / python - / git); no Edit/Write tool call touched this worktree, so the edit-locality trap does not apply and there is nothing to patch-transfer or hash-compare across hosts.

• ruff format --check — 2 files already formatted; ruff check — all checks passed.
• Changed-file pre-commit run --files — RC=0, 21 passed / 47 skipped / 0 failed, no hook skipped by hand (OMNIBASE_INFRA_PATH exported for topic-naming-lint, same disclosure as R3/G2).
• Focused test_omn_15597_command_substitution_shape_guard.py — 212 passed, 2 skipped.
• Whole tests/unit/nodes/node_dod_verify/ — 517 passed, 3 skipped.
• Governed impacted-test selector at git push (pre-push, OMN-13973), no hand-narrowing, no --no-verify — 5284 passed, 16 skipped, 1 xfailed in 4m46s; [prepush-smart-tests] impacted tests passed; allowing push.

Disclosed, pre-existing, not diff-caused: mypy on these two test files reports 6 "object" has no attribute … errors. The identical 6 reproduce on the origin/dev copies of the same files (same errors, line-shifted only), and tests/ is outside the repo's configured mypy scope (mypy_path = "src"; the pre-push mypy hook reports no files to check for this diff). Not introduced here, not fixed here.

Capacity: the lane held for .200 capacity before starting and again before the heavy pre-push gate — pushed at load 7.9/24 cores, Pages free 683613, vm.swapusage byte-identical across a 20s interval (a pinned lifetime figure on a 25-day uptime, not active paging).

---

Scope discipline

This PR does not re-litigate #1998's substance. The verifier upheld its gates_green, both RED reproductions, the AC5 option-(b) rationale, AC6, and companion #5827's born-admissibility; the census oracle single-sourcing and the hermetic AC5 structure are kept intact and untouched. Only the pin, the derived counts, and the three provenance statements move.

Closes OMN-15597

Evidence-Ticket: OMN-15597
Evidence-Source: 51e0dc7695f5f5ebddee945382ccb7d5bfd5ef54

[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: 50 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: cf553588-1714-4c77-a9e5-50046ee5b5ec

📥 Commits

Reviewing files that changed from the base of the PR and between 3cb2633 and b0ddcb8.

📒 Files selected for processing (2)

• tests/unit/nodes/node_dod_verify/omn_15597_occ_census_pinned.py
• tests/unit/nodes/node_dod_verify/test_omn_15597_command_substitution_shape_guard.py

---

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

[github-actions]

✅ Hostile Reviewer — PASSED

Blocking findings (critical/error): 0
Total findings: 0
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)

[github-actions]

✅ Architectural Review — PASSED

Errors: 0
Warnings: 0

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

---

No architectural violations found.

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