fix(OMN-15660): arm the terminal correlation predicate in host mode and stop reading a missing status as success (OMN-17567)

[jonahgabriel]

OMN-15660 — the terminal isolation the runtime was never actually applying

RuntimeLocal.__init__ defaults host_handlers=True, and no production caller passes False — the only occurrences outside runtime_local.py are in tests/unit/runtime/test_runtime_local_client_mode.py. onex delegate therefore always runs host mode. Both OMN-17304 remedies sat behind if not self.host_handlers, so neither has ever executed in production:

• the terminal correlation predicate (_expected_correlation_id) was never armed, and _terminal_correlation_matches returns True unconditionally when unarmed;
• the terminal consumer group was never run-scoped, so every invocation joined the fixed group local.omnibase_core.runtime_local_terminal.consume.v1.__i.<instance>.__t.onex.evt.omnimarket.delegate-skill-completed.v1.

On a durable broker that means a run inherits the previous run's committed offset and adopts whatever terminal is still retained.

Observed live, 2026-09-02

On a Kafka-backed single-tenant lane (read-only rpk probes, no mutation): the terminal topic held 3 records under 7-day retention with the group at CURRENT-OFFSET 2 / LOG-END 3 / LAG 1. Run 61ff0925 joined that group, was served the 11:59 terminal for correlation 109c2285 sitting at offset 0, accepted it with no correlation check, and returned result=completed in the same second with no LLM call. Its own terminal arrived 3s later at offset 2 and was never joined — that is the standing lag. The state is self-perpetuating: a run that adopts a stale terminal returns before publishing its own, leaving that one retained-and-uncommitted for the next run.

Only the CLI-side OMN-17295 correlation join (omnibase_infra/src/omnibase_infra/cli/receipt_mode.py:474-500) caught it, because the CLI is the last boundary that still knows which correlation id it minted.

Not lane-specific: the same shared group exists on the stability-test lane. Tier-0 (in-memory bus, dies with the process) is immune; any configured Kafka/Redpanda transport is exposed. This is the beta delegation path.

OMN-17567 — a FAILED terminal reported as completed

_on_terminal_event read payload.get("status", "success") against the envelope top level. Two terminal shapes coexist on that one topic: the single-output adapter path publishes the bare domain payload (status at the top), the fan-out path publishes a ModelEventEnvelope (status under payload). An envelope-shaped terminal has no top-level status, so it defaulted to "success" and _classify_result returned COMPLETED. Envelope-shaped terminals could never surface a failure through this path at all — and the terminal the probe above adopted was status=failed with quality_gates_failed populated.

What changed

src/omnibase_core/runtime/runtime_local.py:

1. Arm the predicate in both modes. _expected_correlation_id is now set from the already-resolved wire correlation id with no host_handlers guard. This is the actual isolation boundary. None only when nothing correlated reached the wire; client mode already refuses that case, host mode keeps first-terminal-wins there.
2. Run-scope the terminal group whenever the predicate is armed (runtime_local_terminal_run_<run_id[:12]>). Deliberately gated on armed rather than made unconditional: a brand-new group reads the retained log from the beginning, so scoping without a filter would trade "the uncommitted tail" for "the entire retention window" — strictly worse. Group uniqueness alone was never sufficient, which is why OMN-15660 AC3 required both.
3. Read the status at both levels, with no default. _terminal_status_declarations collects status from the envelope and the domain payload using the same precedence _terminal_correlation_matches already uses for correlation ids. A failure declared at either level fails closed. An envelope that declares no status anywhere is UNKNOWN and is refused — symmetric with the existing refusal of an envelope that names no correlation. A bare domain terminal with no status (e.g. {"kind": "completed"}) is the long-standing offline shape and keeps the _classify_result heuristics; the refusal is scoped to envelope-shaped messages, which structurally carry a domain payload that declares its own status.
4. tests/unit/runtime/test_runtime_local_client_mode.py::test_host_mode_terminal_is_not_correlation_filtered asserted the behaviour this PR removes. It is inverted to ..._is_correlation_filtered_too, with the superseding reason in its docstring rather than a silent deletion.
5. tests/gates/test_consumer_group_name_authorization.py now also derives the run-scoped terminal group name. That is the name onex delegate actually mints against MSK now, and an unauthorized name here is the OMN-15639 failure mode again (GroupAuthorizationFailedError before publish). Verified authorized under the managed environment: onex-dev.omnibase_core.runtime_local_terminal_run_<hex>.consume.v1 matches onex-dev.*.
6. pyproject.toml + uv.lock: 0.47.2 -> 0.47.3 (OMN-13411 release-identity gate — packaged source changed).

Production callers checked, none relied on first-terminal-wins

grep over omnibase_core / omnibase_infra / omnimarket / omniclaude / omnibase_spi / omnibase_compat: the only production RuntimeLocal(...) sites are omnibase_infra/src/omnibase_infra/cli/receipt_mode.py:669 and omnibase_infra/src/omnibase_infra/cli/cli_node.py:289. Neither passes host_handlers, and receipt_mode.py was compensating for the missing filter with its own correlation join, not depending on its absence. No caller to fix.

Tests (RED first)

New: tests/unit/runtime/test_runtime_local_terminal_isolation.py. It stands up a retaining broker double with per-(group, topic) committed offsets and broker-level subscribers, because the in-memory bus dies with the process and cannot express this defect at all. 12 of the 14 cases fail on dev; the 2 that pass are counter-assertions pinning what must not break.

• test_host_mode_never_adopts_a_retained_terminal_from_an_earlier_run — the sequential case that actually bit: run A gone, its terminal still retained-and-uncommitted, run B must ignore it.
• test_host_mode_refuses_a_retained_failed_terminal_from_an_earlier_run — the compounded case; passes only when both fixes are present.
• test_host_mode_terminal_group_is_run_scoped, test_two_sequential_host_runs_do_not_share_a_terminal_group.
• test_a_slow_host_run_does_not_adopt_a_concurrent_runs_terminal — OMN-15660's original concurrent framing, on the host path. The handler's think-time is driven off the prompt so the slow run is deterministically parked in its terminal wait when the fast run's terminal lands; without that, two gathered run_async coroutines run one after the other and the "concurrent" assertion passes vacuously.
• Envelope status: failed/failure/error/ERROR all classify FAILED; payload-level failure beats an envelope-level success; no-status-anywhere is refused and names the missing status in last_error.
• Counter-assertions: envelope-level success still COMPLETED; bare {"kind": "completed"} still COMPLETED.

Local proof, re-run on the rebased tree (da55f8d7, off origin/dev@d191ffb2) rather than inherited from the earlier lane:

uv run pytest tests/unit/runtime tests/gates/test_consumer_group_name_authorization.py -q
419 passed, 1 warning in 65.68s

uv run pytest tests/unit/runtime/test_runtime_local_terminal_isolation.py -q
14 passed in 2.61s

uv run mypy src/omnibase_core/runtime/runtime_local.py --strict
Success: no issues found in 1 source file

uv run ruff format <the 4 changed source/test paths>   -> 4 files left unchanged
uv run ruff check  <the same 4 paths>                  -> All checks passed!
uv run python scripts/check_release_identity.py --base origin/dev
OK: version 0.47.3 is ahead of latest published 0.47.2.

The RED was re-proven, not asserted

The claim "12 of the 14 cases fail on dev" is easy to inherit and wrong to assume, so it was re-run: origin/dev's pre-fix runtime_local.py was swapped into this tree under a trap that always restores, and the new module was run against it.

12 failed, 2 passed in 7.72s

The two that pass are the counter-assertions, as claimed. The on-point failures are the defect stated in its own words:

test_host_mode_never_adopts_a_retained_terminal_from_an_earlier_run
  AssertionError: host mode adopted an earlier run's retained terminal
test_host_mode_refuses_a_retained_failed_terminal_from_an_earlier_run
  AssertionError: this run reported another run's FAILED terminal as its own
test_host_mode_terminal_group_is_run_scoped
  AssertionError: host-mode terminal subscription reused the shared runtime-local group id
  'local.omnibase_core.runtime_local_terminal.consume.v1'; a fresh run resumes another run's committed offset
test_envelope_shaped_failed_terminal_is_classified_failed
  AssertionError: assert <EnumWorkflowResult.COMPLETED> is <EnumWorkflowResult.FAILED>

The inverted client-mode test was checked the same way — against the pre-fix source test_runtime_local_client_mode.py is 1 failed, 9 passed, the failure being test_host_mode_terminal_is_correlation_filtered_too. That confirms the inversion is a real behavioural flip, not a rename. Restore was verified: zero dirty paths afterwards.

Hook status

pre-commit run --files <the 6 changed paths> — the check that actually gates a commit — is RC=0, zero failures.

pre-commit run --all-files reports 19 failed / 98 passed. None of the 19 names any file this PR touches, checked mechanically: grepping the log for runtime/runtime_local.py, test_consumer_group_name_authorization, test_runtime_local_client_mode, test_runtime_local_terminal_isolation, pyproject.toml and uv.lock returns 0 hits each. Those 19 are the repo's standing --all-files baseline (print-statement, exception-handling, hardcoded-path and TODO-marker scans over pre-existing source). The one hook that was attributable to this change, check-release-identity (OMN-13411), is fixed by the version bump and now passes.

Residual, stated rather than hidden

_run_single_handler still subscribes its terminal topic with the bare shared group (runtime_local.py:787). That path resolves no correlation id at all, so there is nothing to arm — run-scoping it alone would be the strictly-worse trade described above. Left unchanged deliberately; it is not the delegation path.

Version bump: 0.47.3 is a pyproject bump only — no tag, no release cut

scripts/check_release_identity.py requires project.version to be strictly greater than the
highest published tag, and the highest published tag is v0.47.2. Packaged source under src/
changed here, so the gate demands a bump; without it check-release-identity is the one hook that
fails and it fails because of this diff.

This PR bumps pyproject.toml + uv.lock to 0.47.3 and does nothing else about releases: no
git tag is created, no release is cut, nothing is published. That is deliberate rather than
incidental — 0.47.3 is spoken for by OMN-17842 (delegation v2, Task 1.3), whose own step 1 reads
"bump the version — reclaiming 0.47.3 from the abandoned worktree (fact 25) or taking the next
free number". This worktree is that abandoned worktree, so landing 0.47.3 on dev is that
ticket's documented first option, not a collision with it. The release cut remains OMN-17842's to
make.

Evidence-Ticket: OMN-15660
Evidence-Ticket: OMN-17567
Evidence-Source: OCC#8192