fix(OMN-15732): break infra-dev merge deadlock -- exempt vendor files from OMN-15361 legacy-schema lint

[jonahgabriel]

Summary

infra dev is merge-deadlocked as of 2026-08-08 13:35Z: node-migration-sync (OMN-13332) forces every open infra dev PR to vendor two upstream omnimarket migrations verbatim —

• node_canary_score_reducer/0003_capability_scores_tenant_id_to_uuid.sql
• node_projection_registration/0004_node_service_registry_no_force_rls.sql

— but vendoring them trips Application Database Domain Enforcement (OMN-15361), a required CI Summary STRICT_GATE_JOBS member, in the "Enforce schema qualification in changed SQL (trusted)" step of scripts/ci/check_application_database_sql.py. Not vendoring → red node-migration-sync. Vendoring → red OMN-15361. Both are hard required gates; neither can be waived. The failure reproduces identically on 5 other open PRs (#2681, #2680, #2677, #2676, #2668) plus #2682 (head 1aa87f7e2a, run 31259117513 / job 93107117177), which currently carries the only PR-side reproduction of the OMN-15361 half.

Root cause

Both files are new migrations in existing streams whose physical tables (public.capability_scores, public.node_service_registry) have been unqualified/default-schema since their original CREATE, pending the separate, larger governed OMN-15359 schema cutover. This is exactly the case _LEGACY_DEFAULT_SCHEMA_SQL_EXACT_PATHS in check_application_database_sql.py already exists to cover — it carries 11 precedent entries (OMN-15503, OMN-15655) exempting sibling follow-up migrations in the same physical-table-stays-in-public state, most directly node_canary_score_reducer/0002_capability_scores_tenant_id_and_rls.sql, which 0003 in this PR directly continues (same table, same fail-closed tenant-mapping pattern, next step of the OMN-15356 program).

Fix — STATUS: DRAFT, AC2 finding open, plan below supersedes the original claim

Correction (2026-08-08, post-merge-sweep review): the paragraph originally here claimed both new exemption entries were in-class with their cited precedents and that "the migration content is already correct for its precedented class." That claim is false for the 0003 entry. 0003_capability_scores_tenant_id_to_uuid.sql introduces a new function, house_tenant_map_slug_to_uuid, and the 0003 exemption-list entry lets that new function permanently escape ownership declaration — an OMN-15732 AC2 violation ("no new object may be exempted from ownership declaration via the legacy-default-schema list"). Every precedent in _LEGACY_DEFAULT_SCHEMA_SQL_EXACT_PATHS (OMN-15503, OMN-15655, 0002_capability_scores_tenant_id_and_rls.sql) exempts a pre-existing unqualified object carried forward from before OMN-15361 existed — none mints a new function. 0004's entry remains in-class (pre-existing dynamic-SQL block on an already-exempted table) and is unaffected by this correction.

Real plan (option c — content fix, not registry exemption): topology/application_database.py:113-118 declares four schemas: public, tenant, omninode_internal, platform_catalog. platform_catalog is bootstrapped at docker/migrations/forward/_ledger/bootstrap.sql:32 and omninode_internal at src/omnibase_infra/migration/cutover/sql/bootstrap.sql:6 — both already exist, independent of tenant-bootstrap sequencing and independent of the OMN-15359 schema-cutover decision. Qualifying house_tenant_map_slug_to_uuid into omninode_internal (or platform_catalog) and declaring ownership there satisfies OMN-15361 directly for the new function, with no exemption-list entry and no dependency on OMN-15359. This PR stays draft until that content fix supersedes the 0003 exemption entry.

• Add both new file paths to the existing exemption set, with inline comments citing the precedent and this ticket. This does not touch validator logic, add a skip token, or weaken what the gate checks for any non-exempt file — but per the correction above, the 0003 entry itself is the wrong mechanism for a new object and is pending replacement by the option-(c) content fix.
• Also vendors the two migrations for real (scripts/sync-node-migrations.sh, matching PR feat(OMN-15730): CI concurrency auto-cancel — omnibase_infra #2682's approach) and adds their declaration rows to docker/migrations/forward/_ledger/application-migrations.tsv (checksums 8bf81c98../adb21c75.. — byte-identical to the content already vendored on feat(OMN-15730): CI concurrency auto-cancel — omnibase_infra #2682, confirmed via sha256sum), bumping tests/unit/scripts/validation/test_application_migration_manifest.py's declaration-count assertion 94→96 — so this PR clears both sides of the deadlock, not just the gate in the abstract.

Validator proof

Reproduced the exact 5 findings from live CI job 93107117177 by running check_application_database_sql.py against the exact vendored SQL content from PR #2682 head 1aa87f7e2a (git show 1aa87f7e2a:<path>) with the pre-fix script:

application_database_sql_gate=FAIL
docker/migrations/forward/nodes/node_canary_score_reducer/0003_capability_scores_tenant_id_to_uuid.sql: application relation target 'house_tenant_map_slug_to_uuid' must be schema-qualified
docker/migrations/forward/nodes/node_canary_score_reducer/0003_capability_scores_tenant_id_to_uuid.sql: application relation target 'public.capability_scores' is prohibited in public
docker/migrations/forward/nodes/node_canary_score_reducer/0003_capability_scores_tenant_id_to_uuid.sql: application target public.capability_scores requires exactly one ownership declaration
docker/migrations/forward/nodes/node_canary_score_reducer/0003_capability_scores_tenant_id_to_uuid.sql: procedural block contains dynamic SQL whose relation targets cannot be proven statically
docker/migrations/forward/nodes/node_projection_registration/0004_node_service_registry_no_force_rls.sql: procedural block contains dynamic SQL whose relation targets cannot be proven statically

Byte-identical to the live log. Same content with this fix applied, using the exact 3-manifest CI argument set (omnimarket + both omninode_infra manifests):

application_database_sql_gate=PASS

At the real committed HEAD of this branch: same command → application_database_sql_gate=PASS.

Re-vendor cascade

None beyond the normal git-history mechanism. This fix changes no content on the two SQL files and no checksums vs the #2682 precedent, so it carries no separate TSV re-sync obligation for other branches. Once merged to dev, every other deadlocked PR (#2681/#2680/#2677/#2676/#2668) clears the OMN-15361 half of the deadlock as soon as it (a) vendors the same two files — forced by node-migration-sync regardless of this fix — and (b) is based on/rebased onto a dev commit containing this exemption-list change. The exemption keys on a fixed logical file path, not git ancestry or content hash, so no per-branch checksum resync is required.

Local proof

• uv run ruff format / ruff check --fix — clean
• uv run mypy scripts/ci/check_application_database_sql.py — clean
• pre-commit run (full chain, real commit, no --no-verify) — all hooks passed, including ONEX Node Migration Vendor Sync Check (previously red without the vendored files)
• uv run pytest tests/ci/test_application_database_sql_gate.py tests/ci/test_application_database_sql_authority_isolation.py tests/ci/test_application_database_domain_enforcement_contract.py tests/unit/validation/test_application_database_sql_enforcement_regressions.py tests/unit/scripts/validation/test_application_migration_manifest.py — 131 passed
• governed pre-push impacted-test selector (OMN-13973) — 3011 passed, 5 skipped, 331.34s

Resolution (2026-08-08 adjudication, supersedes "Fix" section above)

STATUS UPDATE: AC2 finding CLOSED — not via the option-(c) content fix
described above. That plan proposed qualifying
house_tenant_map_slug_to_uuid into omninode_internal or
platform_catalog on the infra side. Adjudication (full text: omnimarket
PR #2026 comment
#5226942902;
one row in docs/tracking/ROLLING_WORK_LEDGER.md,
[mergesweep-0808-domain-adj]) rejected both of those targets for a
node:% migration stream: _ALLOWED_DOMAINS /
schema_migrations_stream_domain_check restrict node streams to exactly
{tenant, omninode_internal}, and platform_catalog is topology domain
PLATFORM_CATALOG -- inadmissible at either enforcement point regardless
of which schema hosts the function. omninode_internal itself also fails
apply-time presence under the forward-migration stream (created only by
the cutover-only initializer -- confirmed at
src/omnibase_infra/migration/cutover/sql/bootstrap.sql:4-5, no
CREATE SCHEMA omninode_internal anywhere under
docker/migrations/forward/).

The actual fix landed upstream in omnimarket (PR #2026, revised): the
house_tenant_map_slug_to_uuid function had exactly one DDL-time consumer
and no runtime caller, so it was deleted outright and its closed mapping
inlined directly into 0003_capability_scores_tenant_id_to_uuid.sql's own
USING clause (fail-closed via a pre-guard RAISE plus a CASE-without-
ELSE, backed by the column's NOT NULL constraint). There is no
0004 file and no new catalog object of any kind -- so there is nothing
left to schema-qualify on either side.

No structural change to this PR as a result. The exemption entry this
PR already added to _LEGACY_DEFAULT_SCHEMA_SQL_EXACT_PATHS and the TSV
ledger row already name the exact pre-split path,
docker/migrations/forward/nodes/node_canary_score_reducer/0003_capability_scores_tenant_id_to_uuid.sql,
with domain=tenant -- both remain correct and become truthful (not
just permitted) once re-vendored, because the file's only target,
public.capability_scores, is itself topology domain TENANT
(src/omnibase_infra/topology/instances/{local,onex-dev,onex-prod}.yaml).
The comment block explaining the exemption
(scripts/ci/check_application_database_sql.py) was updated to drop the
now-inaccurate "the mapping function it defines" clause -- the file no
longer defines one. The TSV row's content checksum will be refreshed by
node-migration-sync once it re-vendors from the omnimarket branch; no
other file in this PR changes.

Update (2026-08-08, applied): re-vendored 0003_capability_scores_tenant_id_to_uuid.sql locally against omnimarket jonah/omn-15732-0003-optc@09c53bfd via scripts/sync-node-migrations.sh (OMNIMARKET_SRC override), refreshed the TSV row's checksum to d1eeefff11fbec255216154ba26aa6f0f29602a0b6fd8fd89e8de5d8d3282b2c, and added the Omnimarket-Source-Ref field above so node-migration-sync resolves the same unmerged branch instead of defaulting to dev (which does not yet carry the omnimarket-side fix). check_application_database_sql.py re-run against this content with the real ownership manifests: application_database_sql_gate=PASS. No exemption-registry or gate-logic edit.

Ticket: OMN-15732 (root-cause fix lane for the infra-dev deadlock diagnosed 2026-08-08 13:35Z; see docs/tracking/ROLLING_WORK_LEDGER.md [mergesweep-0808-deadlock] entries in omni_home for the full incident trail, including the earlier #2682 declaration-gap fix (OMN-15730) that first exposed this OMN-15361 side).

Omnimarket-Source-Ref: jonah/omn-15732-0003-optc
Evidence-Ticket: OMN-15732
Evidence-Source: OCC#6195

Summary by CodeRabbit

• Database Updates

  • Converted capability score tenant identifiers to UUIDs for improved consistency and validation.
  • Preserved tenant isolation and access controls during the conversion.
  • Removed forced row-level security from the node service registry while retaining existing policies.

• Maintenance

  • Updated migration validation and tracking to include the latest database changes.

[onexbot-occ-writer]

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.

[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: 52 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: b700a343-04db-40e4-b89e-7a04acb11439

📥 Commits

Reviewing files that changed from the base of the PR and between 9b83171 and e2c379c.

⛔ Files ignored due to path filters (1)

• docker/migrations/forward/_ledger/application-migrations.tsv is excluded by !**/*.tsv

📒 Files selected for processing (2)

• docker/migrations/forward/nodes/node_canary_score_reducer/0003_capability_scores_tenant_id_to_uuid.sql
• scripts/ci/check_application_database_sql.py

📝 Walkthrough

Walkthrough

The pull request adds idempotent migrations for capability-score tenant UUID conversion and node service registry RLS behavior. It also updates SQL validation exemptions and the migration manifest test.

Changes

Database migration changes

Layer / File(s)	Summary
Capability-score tenant UUID conversion docker/migrations/forward/nodes/node_canary_score_reducer/0003_capability_scores_tenant_id_to_uuid.sql	Maps omninode to its canonical UUID, rejects unmapped values, converts tenant_id from TEXT to UUID, restores the UUID default, recreates tenant isolation, and grants SELECT to app_dashboard.
Node registry RLS adjustment docker/migrations/forward/nodes/node_projection_registration/0004_node_service_registry_no_force_rls.sql	Removes FORCE ROW LEVEL SECURITY when node_service_registry exists and leaves RLS enabled.
Migration validation registration scripts/ci/check_application_database_sql.py, tests/unit/scripts/validation/test_application_migration_manifest.py	Adds exemptions for the migrations and updates the expected declaration count from 94 to 96.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Possibly related PRs

• OmniNode-ai/omnibase_infra#2633: Extends the same capability-score tenant and RLS migration sequence.
• OmniNode-ai/omnibase_infra#2666: Adds the related node service registry NO FORCE RLS migration and manifest update.
• OmniNode-ai/omnibase_infra#2672: Contains the same tenant UUID, node service registry RLS, and manifest test changes.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly identifies the merge deadlock fix and the exemption of vendor files from the legacy-schema lint.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch jonah/omn-15732-migration-domain-fix

---

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

[github-actions]

✅ Hostile Reviewer — PASSED

Blocking findings (critical): 0
Total findings: 0
Models succeeded: qwen3-review,qwen3-review-b

---

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)

[jonahgabriel]

Held as DRAFT — AC2 violation found (OMN-15732).

The 0003 entry added to _LEGACY_DEFAULT_SCHEMA_SQL_EXACT_PATHS is not in the same class as its cited precedents. 0003_capability_scores_tenant_id_to_uuid.sql introduces a new function, house_tenant_map_slug_to_uuid, which the exemption list suppresses ownership-declaration checking for. Every precedent in the list (OMN-15503, OMN-15655, 0002_capability_scores_tenant_id_and_rls.sql) exempts existing unqualified objects carried forward from before OMN-15361 existed — none of them mint a brand-new function and route it around ownership declaration. This 0003 entry lets a new function permanently escape ownership declaration, which is exactly the OMN-15732 AC2 condition ("no new object may be exempted from ownership declaration via the legacy-default-schema list").

The PR body's claim — "the migration content is already correct for its precedented class; only the infra-side CI exemption registry ... was missing the two new entries" — is false for the 0003 half. It is not the same class: 0002 continues an existing unqualified table; 0003 is a new function with no qualification at all, exempted instead of declared. (0004's entry is in-class — a pre-existing dynamic-SQL block on an already-exempted table — and stays as-is.)

Content fix (option c), not exemption: topology/application_database.py:113-118 declares four schemas: public, tenant, omninode_internal, platform_catalog. platform_catalog is bootstrapped at docker/migrations/forward/_ledger/bootstrap.sql:32, and omninode_internal at src/omnibase_infra/migration/cutover/sql/bootstrap.sql:6 — both exist today, independent of the tenant-bootstrap sequencing and independent of the OMN-15359 schema-cutover decision. Qualifying house_tenant_map_slug_to_uuid into omninode_internal (or platform_catalog) and declaring ownership there satisfies OMN-15361 directly, with no new exemption-list entry and no dependency on OMN-15359 landing first.

This PR stays draft until the 0003 fix is content (schema-qualify + declare ownership), not registry (exempt), and the PR body is corrected to reflect that.

Checker source cited: omnibase_infra/scripts/ci/check_application_database_sql.py (exemption list) and src/omnibase_infra/validation/application_database_domain_enforcement.py (ownership-declaration enforcement).