[jonahgabriel]

Why

RSD lane-2 audit finding R1 (2026-08-10, [lane:rsd-corrections-15767]): the corpus-wide producer_send/consumer_subscribe counts this ticket's own extractor produces (OMN-15779's symbol-resolution landing, #2041) mix real inter-service application seams with test substrate that is shipped inside a scanned src/ tree rather than under tests/ — e.g. omnibase_core's event_bus/testing/contract_event_bus_substrate.py (18 hits) and runtime/transport/runtime_transport_conformance.py (6 hits). "Production" in the prior derivation meant non-self-hit, not inter-service application seam. The finding explicitly states a second split is required before any gate or golden-generation work (OMN-15756, OMN-15767) consumes these numbers.

This PR is that precursor split — required before OMN-15767 (golden generation) or OMN-15756 (the PR-time gate) can honestly consume corpus counts.

What changed

src/omnimarket/seams/models/model_seam_graph.py:

• ModelSeamGraphCodeObservation.is_test_harness — a @computed_field derived from source_path (always correct, never a constructor input that could drift or be forgotten). Matches event_bus/testing/**, runtime/transport/*conformance*, and defensively tests/** (already excluded upstream in every real caller today — no discovery root passed by node_seam_graph_compute includes a tests/ dir, but the classification holds if one ever did).
• ModelSeamGraphObservationKindSummary + ModelSeamGraphV1.observation_summary — per-kind total/test_harness/production_application counts, computed (not constructor input), sorted by kind, omitting zero-observation kinds. Replaces the ad hoc manual grep/count a prior verification pass produced by hand with a durable, code-computed value any gate/golden consumer can read directly.

No change to extraction logic itself — purely additive classification on top of the existing code_observations.

RED-before / GREEN-after

9 new tests in tests/test_seams_extraction.py (TestTestHarnessSourceClassification, TestObservationSummarySplitsHarnessFromProduction), all failing against the unmodified model (AttributeError: 'ModelSeamGraphCodeObservation' object has no attribute 'is_test_harness' / same for observation_summary on ModelSeamGraphV1) — confirmed RED by running against origin/dev's unmodified model before writing the implementation. All 9 pass after.

Verification

• Targeted: tests/test_seams_extraction.py + tests/test_seams_registry_contract.py + tests/test_seams_registry_match_integration.py + node_seam_graph_compute/node_seam_match_compute node tests — 109 passed, 0 failed.
• mypy --strict src/omnimarket/seams/ — clean.
• ruff format / ruff check --fix — clean.
• Full local suite (pytest tests/ -q -m "not kafka") — 16,377 passed, 0 failed, 76 skipped, 9 deselected, 1 xfailed.
• Governed pre-push selector (OMN-13973) escalated to full suite (changed_test_unnarrowable — shared model diff) — 15,232 passed, 0 failed, 47 skipped, 3 deselected, 1 xfailed. Gate passed, push allowed.
• pre-commit run --all-files-equivalent (--files on the two touched files) — all hooks passed.

Live corpus reproduction (real 3-repo scan, omnimarket this branch, omnibase_infra 487cb8c2, omnibase_core c031bec0 — the same sibling SHAs the R1 audit finding cited):

kind	total	self-hit	test-harness-in-src	production-application
producer_send	38	0	16	22
consumer_subscribe	30	0	8	22
ref_pin	1	1	0	0

24 harness hits total (18 event_bus/testing/contract_event_bus_substrate.py + 6 runtime/transport/runtime_transport_conformance.py) — exact match to the audit finding's numbers. Determinism re-verified: two in-process runs over the identical pinned tree produce byte-identical model_dump_json() output.

One disclosed discrepancy: at the identical sibling SHAs the prior derivation cited, this pass's consumer_subscribe total is 30, not the previously-recorded 29 (producer_send=38 and ref_pin=1 both match exactly). Same extraction code, same trees — flagged rather than silently reconciled; full per-observation breakdown available in the PR discussion on request.

Evidence-Ticket: OMN-15779
Evidence-Source: OCC#6338

[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: 13 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: add86560-ccbb-4546-90fc-6fd251e6736e

📥 Commits

Reviewing files that changed from the base of the PR and between b8d79f1 and 9fc5445.

📒 Files selected for processing (2)

• src/omnimarket/seams/models/model_seam_graph.py
• tests/test_seams_extraction.py

---

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

[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).

[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)