Repository navigation
fix(OMN-19550): declare session_content ownership so omnibase_infra#4154 can vendor the migration - #2937
Merged
Conversation
…154 can vendor the migration The OMN-15361 SQL ownership gate resolves table ownership from this repo's scripts/application-relation-ownership.yaml on omnimarket's dev tip, never from a node's own contract.yaml db_io block and never from a PR branch. omnibase_infra#4154 (vendoring node_projection_session_ content's 0001_create_session_content.sql ahead of omnimarket#2905, per the node-migration-vendor-parity-gate) failed Application Database Domain Enforcement with "requires exactly one ownership declaration" because omninode_internal.session_content had no entry on dev. Step 1 of the standard forced three-part order (see the work_events/ lab_lane_health/dod_verify_runs comments in the same manifest): this PR carries the db_io.db_tables declaration alone (access: write, role: session_content, mirroring the node's own contract.yaml exactly). The node package and its own create migration land separately in omnimarket#2905 (step 3), once omnibase_infra#4154 has vendored the migration (step 2), which this declaration unblocks. Regenerated the derived evidence file and bumped the test_application_relation_inventory.py source_declared_tables ratchet (80 -> 81, ahead of source_created_tables, the step-1 shape shared with OMN-18999/OMN-18769); source_created_tables and minimum_unreconciled_live_base_tables are untouched here since the create migration is not part of this PR.
Contributor
|
OCC autobind did not mint a companion for this PR: no changed-file candidate could be proven RED against the merge base, and emitting a PR-existence probe instead would be non-falsifiable evidence (OMN-15247). Hand-authored evidence is required. |
✅ Architectural Review — PASSEDErrors: 0 What this checks
No architectural violations found. Static architectural lint — no model inference (OMN-14176). |
jonahgabriel
enabled auto-merge (squash)
September 26, 2026 08:01
✅ Hostile Reviewer — PASSEDBlocking findings (critical/error): 0 Gate semantics
Powered by omniintelligence.review_pairing.cli_review — node-based adversarial review via HandlerLlmCliSubprocess (OMN-8524) |
jonahgabriel
added a commit
to OmniNode-ai/onex_change_control
that referenced
this pull request
Sep 26, 2026
…market#2937 (#11438) * evidence(OMN-19550): hand-authored OCC companion for OmniNode-ai/omnimarket#2937 occ-preflight/eligibility declined PR #2937 terminally with skip:NO_RED_DERIVABLE_CHECK: the diff is a db_io.db_tables ownership declaration in scripts/application-relation-ownership.yaml plus its regenerated evidence json and a test-count assertion, none of which is a code path the producer can derive a RED from. Per OMN-15247 the remedy is hand-authored evidence. Appends two dod_evidence entries to the existing OMN-19550 contract (which already carries entries for omnibase_infra#4154, merged via #11418, and omnimarket#2905, open via #11275) plus their receipts: - dod-OmniNode-ai-omnimarket-pr-2937: content-bound probe. The session_content ownership declaration (role: session_content) is present at the PR head 7826cc6baf and absent at the merge base cd220fd03a. No AC of OMN-19550 is bound: #2937 is step 1 of the forced three-part order (declare, vendor, create) and proves none of AC1-AC6 itself. - dod-OmniNode-ai-omnimarket-pr-2937-scope: product diff scope, 3 files, 0 migration SQL files, confirming the PR's own declaration- only claim. Purely additive: every existing OMN-19550 entry and receipt is byte-identical (verified: recomputed contract_entry_sha256 for the three pre-existing entries and reproduced their recorded values byte for byte). Local checks: check_contract_change_rebinds_receipts.py, check_receipt_hardening.py, check_contract_substance_floor.py and check_contract_dod_authoring.py all pass; full pre-commit run over the touched files passes. OMN-19550 * evidence(OMN-18921): mint the owed OCC self-bind for PR #11438 --------- Co-authored-by: onexbot-occ-writer[bot] <onexbot-occ-writer[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Step 1 of the standard forced three-part order documented throughout
scripts/application-relation-ownership.yaml(see thework_events/lab_lane_health/dod_verify_runscomments): declaresomninode_internal.session_contentas adb_io.db_tablesentry(
access: write,role: session_content, mirroringnode_projection_session_content's owncontract.yamlexactly), withno accompanying migration SQL, so the node-migration-vendor-parity-gate
short-circuits on this PR.
omnibase_infra#4154(vendoring0001_create_session_content.sqlahead of
omnimarket#2905, per the node-migration-vendor-parity-gate)is currently real-red on
Application Database Domain Enforcement(
requires exactly one ownership declaration) because that gatereads this file from omnimarket's dev tip, not from any PR branch.
omnibase_infra#4154can vendor the migration(step 2), which unblocks
omnimarket#2905's ownnode-migration-vendor-parity-gate(step 3).No CREATE TABLE lands here, so
source_created_tablesandminimum_unreconciled_live_base_tablesare unchanged;source_declared_tablesmoves 80 -> 81, the same step-1 shape as theOMN-18999/OMN-18769entries in the same file.Test plan
uv run python scripts/generate_application_relation_inventory.py --checkpasses (evidence regenerated with--write)uv run pytest tests/unit/scripts/test_application_relation_inventory.py -q-- 12 passeduv run ruff checkon both changed Python files -- cleanuv run mypy tests/unit/scripts/test_application_relation_inventory.py --strict-- cleanpre-commit run --files ...on the three changed files -- passedOMN-19550, related to omnimarket#2905 and omnibase_infra#4154.
Evidence-Source: OCC#11438
Evidence-Ticket: OMN-19550