feat(OMN-15169): steel dispatch golden chain — topic to event_ledger row

[jonahgabriel]

Summary

Infra-side golden chain: onex.evt.steel-onslaught.match-terminal.v1 → dispatch → event_ledger row, on the stability-test lane. Scoped to what omnibase_infra owns (hostile finding #1 — does not claim steel-side coverage; the steel-side driver test is steel_onslaught/tests/live/test_omn15170_live_driver.py, OMN-15170, which already passed live 2026-07-26: correlation_id ad230e9e-b336-4599-b870-f6746033be47, consumed back at offset 5).

• tests/fixtures/golden_chains/steel_dispatch_ledger_success.json — checkpoint spec (pattern from dynamic_registration_success.json).
• tests/fixtures/golden_chains/steel_dispatch_ledger_negative_evidence.json — structured, durable record of the OMN-15002-precedent negative case (see below).
• tests/integration/runtime/test_steel_dispatch_golden_chain_live_runtime.py — pattern-B live-runtime test (test_golden_chain_live_runtime.py style): negative-case evidence-consistency check (no live infra needed) + a live positive case that publishes a synthetic event with a minted correlation_id to real stability-test Kafka and asserts a real event_ledger row via direct SQL (never bare "producer.flush() succeeded").

Deployed-contract preflight (this ticket, live, 2026-07-26)

The DEPLOYED node_ledger_projection_compute contract on the stability-test lane predated PR #2469 (OMN-15168's paired subscribe_topics+handler_routing diff):

$ ssh omni-201-ts docker exec omninode-stability-test-runtime-effects \
    sed -n '30,40p' /app/src/omnibase_infra/nodes/node_ledger_projection_compute/contract.yaml
contract_version:
  major: 1
  minor: 1
  patch: 0
node_version: "0.2.0"
$ ... grep -c steel .../contract.yaml
0

Natural-experiment proof (the steel topic already carried 14 real events — offsets 0-13, from steel's own OMN-15170 live-driver runs — while this old contract ran):

$ psql -h 100.109.203.94 -p 15436 -U postgres -d omnibase_infra \
    -c "SELECT count(*) FROM event_ledger WHERE topic = 'onex.evt.steel-onslaught.match-terminal.v1';"
 count
-------
     0
(1 row)
$ ssh omni-201-ts docker exec omnibase-infra-stability-test-redpanda \
    rpk topic describe onex.evt.steel-onslaught.match-terminal.v1 -p
PARTITION  LEADER  EPOCH  REPLICAS  LOG-START-OFFSET  HIGH-WATERMARK
0          0       1      [0]       0                 14

This is the OMN-15002-class allowlist-gate proof (zero rows ≠ automatic dispatch), recorded durably in tests/fixtures/golden_chains/steel_dispatch_ledger_negative_evidence.json and asserted self-consistent by TestSteelDispatchGoldenChainNegativeCase (passes without live infra).

Refresh action taken

Ran the sanctioned, pre-authorized, restart-scoped stability-lane warm refresh, per omnibase_infra/scripts/runtime_build/refresh_stability_lane.sh (health-gated, rollback-on-failure; recreates only omninode-runtime/runtime-effects/runtime-worker/projection-api):

$ ssh omni-201-ts (login shell, OMNI_HOME=/data/omninode/omni_home) \
    ./scripts/runtime_build/refresh_stability_lane.sh --ref origin/dev --execute
...
[refresh-stability-lane] health-gate result: PASS (exit 0)
{"lane":"stability-test","digest_changed":true,"manifest_count":295,"manifest_floor":288,
 "health_ok":true,"cluster_healthy":true,"consumer_groups_stable":true,
 "revision_readback_ok":true,"overall":"PASS"}
[refresh-stability-lane] result: SUCCESS

Post-refresh contract re-verified to include the steel topic (comment + subscribe_topics + handler_routing entry, 3 matches via grep -c).

Positive case: BLOCKED (new issue filed, not this PR's scope)

Two independent synthetic publishes to the real topic (one before, one after an additional targeted restart of just omninode-stability-test-runtime to rule out a cold-start race — the first boot logged a NOT-READY: topic metadata did not converge skip, the second did not) each got confirmed Kafka delivery but zero event_ledger rows within a 60s poll. rpk group list shows zero live consumer groups for node_ledger_projection_compute on the steel topic or any of the 18 other topics added since OMN-15006 (ruling out an OMN-15168-specific cause — other nodes' consumers on those same topics, e.g. node_build_loop_write_effect, node_dlq_replay_effect, show Stable groups, so this is scoped to node_ledger_projection_compute specifically).

Filed as OMN-15215 (blocks OMN-15169): https://linear.app/omninode/issue/OMN-15215

test_golden_chain_positive_topic_to_ledger_row is written to the correct, intended behavior. Run live today it correctly FAILS (not skipped) with a message citing OMN-15215:

FAILED ...::test_golden_chain_positive_topic_to_ledger_row
AssertionError: event_ledger has no row for correlation_id=e86ba59e-40bc-468d-ad0d-c896f243adeb
(topic=onex.evt.steel-onslaught.match-terminal.v1, ...) within 60.0s of a confirmed Kafka
delivery. ... Known live blocker as of 2026-07-26: OMN-15215 ...
1 failed, 1 passed in 64.46s

It is pytest.mark.skipif-gated on live reachability (Kafka TCP + a STABILITY_TEST_POSTGRES_DSN env var), so it skips structurally in CI (no route to the private .201/Tailscale network) — same pattern as the existing test_golden_chain_live_runtime.py. It is expected to pass once OMN-15215 clears; no code change in this PR can make it pass sooner (the gap is in the deployed runtime's dispatch wiring for this contract, not in this PR's contract/test).

CI state (occ-separated)

• Local gates (this repo, .200): ruff check / ruff format --check / SPDX header check / full pre-commit run on changed files — all green. mypy not run on tests/ (matches repo convention: CI only runs uv run mypy src/omnibase_infra; the existing test_golden_chain_live_runtime.py precedent file also fails strict mypy on the same generic-dict class of finding).
• occ/receipt gate: not yet evaluated by CI on this PR — will self-clear via autobind per the OCC#5006 precedent named in the dispatch prompt; not asserted here as already-green.
• This PR does not merge itself (Codex owns the merge queue) and carries no --auto/draft state.

Not in scope for this PR

Fixing OMN-15215 itself (the runtime dispatch-attach defect) — that's real infra/runtime work, independently ticketed and blocking this ticket's positive leg, not something a test-only PR should silently absorb.

Evidence-Ticket: OMN-15169
Evidence-Source: OCC#5046

Evidence-Commit: eb91a9e6ccae6fa0c02f255aac2064e71c115201

[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: 55 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: c4f9562e-fe92-4e33-9ea3-a599cda62bd8

📥 Commits

Reviewing files that changed from the base of the PR and between edf57f9 and 34515aa.

📒 Files selected for processing (3)

• tests/fixtures/golden_chains/steel_dispatch_ledger_negative_evidence.json
• tests/fixtures/golden_chains/steel_dispatch_ledger_success.json
• tests/integration/runtime/test_steel_dispatch_golden_chain_live_runtime.py

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jonah/omn-15169-steel-golden-chain

---

_{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)