[jonahgabriel]

Ticket: OMN-20074

Summary

• Moves the cross-repo boundary checks (boundary-parity and migration-conflicts) out of onex_change_control into omnibase_core: two handlers, their models, the two data files and a composite action. No caller is repointed here; that is a follow-on slice after merge.

Design note

• Data: the Kafka boundary manifest and the migration inventory live beside the handlers as package data in src/omnibase_core/contracts/boundaries/ (kafka_boundaries.yaml, migration_inventory.yaml), copied from onex_change_control main a89a6f30fa, the ref the old action checked out. Parsed data is equal to the source (pinned by sha256 of the sorted JSON dump in tests/fixtures/occ_boundaries/manifest.yaml). The copies add the SPDX header and write the six topic_name values unquoted, the form contracts/topic_registry.yaml uses, because the no-hardcoded-topics hook flags quoted topic literals.
• Handlers: src/omnibase_core/handlers/handler_boundary_parity.py, HandlerBoundaryParity.handle(request: ModelBoundaryParityInput) -> ModelBoundaryParityReport; src/omnibase_core/handlers/handler_migration_conflicts.py, HandlerMigrationConflicts.handle(request: ModelMigrationConflictInput) -> ModelMigrationConflictReport. Pure, no Plugin base, no envelope; main() reads files through NodeSourceFileGatherEffect and passes the clock instant in. Placed as handler modules like handler_cosmetic_lint, because the node-home ratchet refuses a new node directory in this repository.
• Caller surface: .github/actions/validate-boundaries/action.yml, a composite action (not a reusable workflow, so the caller's own job and its context name stay as they are) with the same inputs checks, warn-only, repos and the same defaults. A caller changes only its uses line to OmniNode-ai/omnibase_core/.github/actions/validate-boundaries@; the job names boundary-validation and boundary-parity and the contexts "Cross-repo boundary validation" and "Cross-Repo Boundary Parity" do not change. The action runs uv sync --frozen --no-dev on its own checkout of omnibase_core and runs the two handler modules; it has no step that checks out onex_change_control (onex-change-control is a dev-group dependency, which --no-dev skips). It keeps the peer clone loop: it clones what the caller lists in repos, and three callers list onex_change_control there because one manifest boundary (contract-drift-detected) still has onex_change_control as its producer repository.
• Blocking semantics are unchanged: warn-only false stays false at the callers; boundary-parity fails the job on a mismatch; migration-conflicts still runs with --check-columns --warn-only exactly as before, so it reports and only a degraded clone fails it.

Ported and not ported

• Rules, regular expressions, error strings, exit codes, the 14-day pending grace and the report text are the source's.
• Not ported: --check-schemas and --suppressions-file (the old action never passed either; this repository refuses a new suppression mechanism), and colorama colour codes (colorama is not an omnibase_core dependency; colorama strips them on a non-tty anyway).
• Divergences: a manifest or inventory with a duplicate mapping key fails loudly (the sanctioned YAML loader), and undecodable bytes are read with replacement characters where the source crashed.
• Version bumped to 0.47.40 for the release-identity gate.

Owner check

• The manifest's six boundaries cross four repositories (omniclaude, omniintelligence, omnimarket and onex_change_control, as producers or consumers) and the inventory maps migration sets of seven databases across omnibase_infra, omniintelligence, omnidash-archived, omnimemory, omninode_infra, omniclaude and omniweb. Neither is owned by one repository's runtime, so omnibase_core, the lowest layer every caller pins, hosts them.
• onex_change_control dev carries a newer migration_inventory.yaml than main; the old action read main, and so does this copy.

Lab

Lab: host=h201 lane=occ-ret-boundary-parity-e5-5d21 head=b64e6b32fc394e23f233ac1e80161c24d3be6bbf; command: core installed the way the action does it (git archive of the head, uv sync --frozen --no-dev, uv run --no-sync python -m omnibase_core.handlers.handler_boundary_parity --repos-root <root> and ... handler_migration_conflicts --repos-root <root> --check-columns --warn-only) against origin/dev trees of omniclaude 18cb48afc7b1, omnidash aab5c9a11566, omniintelligence f5b298841b4b, omnibase_infra 7ce6dd18eece, omnibase_core 3fbb43e, omnimemory ad6029122c5f, omnimarket 4ceedeafeb40, onex_change_control da751e728024, next to the onex_change_control scripts at main a89a6f30fa on the same trees (PYTHONHASHSEED=0 for both); observed: boundary-parity exit 0 for both, 6 of 6 boundaries OK, output byte-identical; migration-conflicts exit 0 for both, 81 conflicts and 43 column-reference violations reported by both, output byte-identical (without --warn-only both exit 1); positive control: with claude-hook-event renamed in omniclaude src/omniclaude/hooks/topics.py both exit 1 with byte-identical output naming topic onex.cmd.omniintelligence.claude-hook-event.v1 and "topic not found in producer: omniclaude/src/omniclaude/hooks/topics.py", and exit 0 again after restore; a planted NAME_CONFLICT (one table, two column sets, omnibase_infra and omnimarket) is reported by both (82 conflicts), both exit 1.

Without a fixed hash seed the migration column lines of one file come out in set-iteration order in both tools; sorted, the two outputs are equal.

Tests

• uv run pytest tests/unit/handlers/test_handler_boundary_parity.py tests/unit/handlers/test_handler_migration_conflicts.py tests/ci/test_validate_boundaries_action_omn20074.py -q -n0 -p no:randomly: 24 passed; at the merge base both handler test files fail at collection (modules absent).
• Lab pool run, host h201, sha b64e6b3, exit 0: uv run pytest -n 4 -p no:randomly -q tests/unit/handlers tests/ci/test_validate_boundaries_action_omn20074.py tests/unit/test_pep604_compliance.py tests/unit/validation/test_validate_contracts.py tests/unit/validation/test_checker_naming_convention.py tests/unit/validation/test_validator_node_purity.py tests/unit/validators tests/unit/contracts tests/unit/models/ticket: 2095 passed.
• pre-commit on the changed files, ruff, mypy strict on the new modules: clean. Criteria AC24, AC25 and AC26 are bound in contracts/OMN-20074.yaml.

Callers to repoint (follow-on slice, not in this PR)

repo	file:line (origin/dev)	current pin	checks
omnibase_core	.github/workflows/ci.yml:4927 (job boundary-validation)	@77f63a25b67db14dbca603ed8f841c3c5c4ee93e	boundary-parity
omnibase_infra	.github/workflows/ci.yml:3074	@main	migration-conflicts
omniclaude	.github/workflows/ci.yml:4409 (job boundary-parity)	@47342e562a516b0278e22a974f35cbf2a64b33eb	boundary-parity
omniintelligence	.github/workflows/ci.yml:1265 (job boundary-parity)	@dd2620d18001495b8d0f493b421b38399e9aab4b	boundary-parity,migration-conflicts

Evidence-Ticket: OMN-20074
Evidence-Source: OCC#13658

[onexbot-occ-writer]

OCC autobind rebound this PR's evidence-source stamp line to OCC#13658.

The receipt gate's own eligibility validator, run against the change-control tree the gate pins for OCC#13658, returned eligible for head 1cac0802f772cdae4ad0d2b6c82ba13f52e00245. The body now carries exactly one stamp line. Displaced: OCC#13629.

Reported by occ_companion_emitter (OMN-18853).

[jonahgabriel]

Lab: head=842522ae328964a03682ab0704e9dc1d4b979c05 host=h101 lane=throughput-cause-coredirty-l5-5d21

Base update

• Before: merge_state DIRTY against dev. Branch head was 3078719, dev was 5524cb9.
• Merged origin/dev into the branch as merge commit 1cac080 (no rebase, no force-push). The only conflicted file was contracts/OMN-20074.yaml, three hunks at the same insertion points (requirements, evidence_requirements, dod_evidence): dev appended its AC22 S6 part 1 entries, this branch appended AC24, AC25, AC26 entries. Both kept, dev's first. No line of either side changed; versus origin/dev the file removes 0 lines.
• Follow-up commit 842522a adds one line, " - kind: tests", to the branch's first evidence_requirements entry, which lacked it before the merge, so its description and command keys were duplicates inside the preceding entry. A duplicate-key-strict YAML load now succeeds (25 evidence_requirements, 25 dod_evidence).

Lab proof

• Host h101, worktree of the pushed branch, uv run pytest -n 0 -p no:randomly --no-cov.
• At merge commit 1cac080: 7 files, 118 passed: tests/unit/handlers/test_handler_boundary_parity.py, tests/unit/handlers/test_handler_migration_conflicts.py, tests/ci/test_validate_boundaries_action_omn20074.py, tests/ci/test_s6_part1_cutover_omn20074.py, tests/ci/test_ci_summary_l4_wait_omn20522.py, tests/ci/test_imperative_contract_guard_workflow_omn20918.py, tests/ci/test_version_pin_check_retired_omn20921.py.
• At head 842522a: the first four of those files, 32 passed.
• ruff format --check (17 files), ruff check and mypy (14 source files) on the files this branch adds: clean. Pre-commit hooks passed on both commits.
• Not runtime-affecting (handlers, models and a composite action; no deployed runtime change), so no lab dev lane read was made.
• CI on the new head: not yet read.