Repository navigation
fix(OMN-17440): deliver the remaining 26 topology TABLE grants, ratchet 27 -> 1 - #3162
Conversation
…et 27 -> 1 The generated topology declares 65 TABLE grants. Before this change 38 were issued by a migration and 27 were issued by nothing, so a lane that has never been hand-patched -- a fresh staging namespace, a rebuilt onex-dev, prod -- authenticates fine and then refuses every write with InsufficientPrivilege while the runtime reports healthy and commits its offsets. That is the OMN-16993 / OMN-17379 shape, and it has now recurred five times in a fortnight (OMN-15701, OMN-16436, OMN-16993, OMN-17290, OMN-17374). MEASURED, NOT ASSUMED. Two probes, both run 2026-09-03 at dev 4053dc3: corpus `uv run python scripts/validation/check_topology_grant_delivery.py` -> `topology grant delivery: 27 undelivered (of 65 declared)`, exit 0 (the gate PASSES at its own ratchet -- the bound was the defect's bookkeeping, not its bound) lane read-only SELECT against information_schema.role_table_grants in omnidash_analytics on the .201 dev lane (compose project omnibase-infra), diffed against the checked-in topology: declared 65 present live 63 present live AND issued by a migration 38 present live and issued by NOTHING 26 <- delivered here declared, absent live 2 (nightly_loop_configs, delegation_shadow_comparisons; both relations absent) live, declared by nothing 4 (AC3, not this change) So this is not a hypothetical residual. All 26 are ALREADY live dependencies of the dev lane that exist only because somebody typed the GRANT by hand, which is exactly why the gap stayed invisible for as long as it did. WHAT LANDS: 21 new node-owned migrations, one per owning lineage, issuing the 26 grants. Each is a pure forward ADD next to an untouched creating migration -- none of the 21 parents is edited, because each is applied on the .201 dev lane with a recorded content_sha256 and an in-place repair would raise "conflicting migration checksum in canonical node history" (the OMN-16705 constraint that 083/087 and 0032/0033 already hit). Each file grants SELECT/INSERT/UPDATE and deliberately no DELETE, re-asserts its schema USAGE rather than assuming a sibling ran, and asserts BOTH the INSERT and the SELECT took, with the fail-loud `SELECT 1 / count(*)` shape flat 099 and node_projection_session_replay/0002 already use. Not one bulk grant file, for the OMN-15701 reason: a shared cross-node grant block is precisely how a relation added to a node later silently misses its grant. RATCHET: MAX_UNDELIVERED 27 -> 1. The 1 is nightly_loop_configs, which NO migration can deliver -- nothing in the corpus issues a CREATE TABLE for it, so there is no lineage to land a grant in and no relation for a grant to bite on. `test_the_two_tranches_together_are_the_whole_deliverable_set` is added so the bound is a FLOOR rather than a reading: it asserts the undelivered set is exactly that one pair, so a future change cannot satisfy the count by leaving a DIFFERENT grant undelivered. Closing it to 0 (AC2) is a contract decision -- either node_nightly_loop_controller grows a CREATE TABLE for the relation its contract declares under db_io.db_tables, or that declaration is removed -- and is deliberately not made by adding a GRANT for a relation that does not exist. The sequence half is unaffected: MAX_UNDELIVERED_SEQUENCES stays 0, because the sequence requirement is derived from DECLARED grants and the corpus's applied column shapes, not from delivered ones. Re-verified: 0 undelivered (bound 0). TDD, RED proven before GREEN. With the 21 SQL files moved aside and only the tests present: 29 failed, 37 passed. With them restored: 66 passed. The manifest exactness ratchet moves 150 -> 171 in the same change. Vendored into omnibase_infra first per the node-migration-vendor-parity-gate ordering, ahead of the omnimarket source PR; the 21 application-migrations.tsv rows are what make that infra-ahead-by-one state legal rather than drift, read by sync-node-migrations.sh --check as preserved history via the OMN-15717 legacy-declared exemption (`--check: in sync`, exit 0). Local gates, all green, no bypass of any kind: pre-commit run --all-files exit 0, 103 hooks Passed, 0 Failed scripts/sync-node-migrations.sh --check exit 0 scripts/validation/validate_application_migration_manifest.py exit 0 (171 active, 0 blocked, 2 historical, 30 cloud aliases) scripts/validation/validate_migration_sequence.py exit 0 scripts/validation/check_migration_rls_policy_atomicity.py exit 0, clean scripts/validation/validate_migration_freeze.py exit 0 uv run pytest tests/ci/test_topology_grant_delivery.py -q 66 passed uv run pytest tests/unit/scripts/validation/test_application_migration_manifest.py -q 20 passed scripts/validation/check_topology_grant_delivery.py 1 undelivered (bound 1) No lane mutation: the .201 probes were SELECT-only and read no secret value; prod, stability-test and judge were not contacted at all. Refs: OMN-17440 (AC1, AC2 to its floor), OMN-17374, OMN-17447, OMN-16993, OMN-17379, OMN-17377, OMN-15701, OMN-16436, OMN-17290, OMN-16705, OMN-15717
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hostile Reviewer — adversarial findings (OMN-17492)
Models succeeded: glm-review
Models failed: codex
New finding threads: 1
Deduped (already posted on this PR): 0
Nit-level findings suppressed: 1
The model is the FINDER, never the gate: merge is gated only by the
deterministic Hostile Review Thread Gate, which blocks while
hostile-reviewer threads are unresolved. Resolve each thread after
addressing (or rejecting, with a reply) its finding.
Findings not anchored to a changed file
-
[MAJOR] hostile-reviewer (glm-review)
No sequence grants despite table-only INSERT/UPDATE grants | The manifest's pre-existing convention shows numerous sibling migrations of the form
grant_tenant_projection_writer_*_sequence.sql, indicating that tables in this corpus commonly use sequence-backed identifiers. These 22 new files grant SELECT, INSERT, UPDATE on tables but issue no USAGE/SELECT on any sequence. In PostgreSQL, INSERT into a table whose key is backed by a serial/identity sequence requires USAGE on that sequence for non-owner rolesResolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MINOR] hostile-reviewer (glm-review)
Point-in-time probe claims hardcoded in 22 permanent migration headers | Every file embeds an identical narrative: probe date 2026-09-03, '27 undelivered (of 65 declared)', '63 of 65 present live, only 38 issued by any migration, the other 26 by hand'. This snapshot becomes false the moment this PR merges (the 26 hand grants become migration-delivered) and it is duplicated verbatim, including per-node lists, in 22 files. Anyone auditing the headers later inherits a self-contradicting record, and the block m
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MINOR] hostile-reviewer (glm-review)
Schema USAGE re-assertion is claimed topology-derived but is a blanket public grant repeated 22 times | Each file re-issues GRANT USAGE ON SCHEMA public TO omninode_runtime on the stated theory that 'a migration must not assume a sibling file ran'. Granting USAGE on
publicis a broad, non-relation-scoped privilege; embedding it in per-node files means the privilege's provenance is scattered across 22 ownership-scoped migrations, and revoking it later requires finding all 22. If the intent is node ownershiResolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MINOR] hostile-reviewer (glm-review)
Assertion mechanism referenced but its verification is not evidenced | The files announce a fail-loud assertion block ('fail the migration if a grant did not take. Division by zero when the grant is absent'), but for at least the two largest files (node_deployment_evidence_reducer, node_evidence_dashboard_reducer) the excerpts truncate before the assertions, and no test exercises the assertion path. Two failure modes need coverage: has_table_privilege evaluated for the wrong role (must explicitly target omn
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492).
Findings demoted from threads (anchor rejected)
-
[MINOR] hostile-reviewer (glm-review)
Inconsistent migration numbering will break lexical ordering | Twenty-one files use zero-padded three-digit prefixes (0002_, 0003_, 0035_, 080_) while node_nightly_loop_controller uses
002_grant_omninode_runtime_nightly_loop_tables.sql. If the node-owned runner orders migrations lexically,002_and0002_do not sort together, and the prefix space becomes ambiguous: a future0002_file in this node's lineage would collide or interleave unpredictably. The grant also depends on the creating migration hResolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492).
|
| Surface | Meaning | Blocks merge? |
|---|---|---|
| Review threads | Per-finding, posted by the reviewer | No (informational) |
Hostile Review Thread Gate |
Deterministic: unresolved hostile-reviewer threads exist | Fails until resolved (not yet a required context) |
degraded verdict |
Fewer than 2 models succeeded (infra) | No |
Powered by omniintelligence.review_pairing.cli_review — multi-model adversarial review: qwen3-review, qwen3-review-b, glm-review (OMN-8468/OMN-8524/OMN-17492)
…ibase_infra#3162 (#8140) * evidence(OMN-17440): author OCC companion for OmniNode-ai/omnibase_infra#3162 OCC companion by node_pr_lifecycle_fix_effect (OMN-13317 F1 / OMN-13990 / OMN-14285). Product PR head 8a88d57fb4c23248806efff85f9009c2844c8c62. * evidence(OMN-17440): self-bind OCC#8140 + rebind contract_sha256 --------- Co-authored-by: omnimarket-bot <bot@omninode.ai>
There was a problem hiding this comment.
Hostile Reviewer — adversarial findings (OMN-17492)
Models succeeded: glm-review
Models failed: codex
New finding threads: 0
Deduped (already posted on this PR): 0
Nit-level findings suppressed: 1
The model is the FINDER, never the gate: merge is gated only by the
deterministic Hostile Review Thread Gate, which blocks while
hostile-reviewer threads are unresolved. Resolve each thread after
addressing (or rejecting, with a reply) its finding.
Findings not anchored to a changed file
-
[MAJOR] hostile-reviewer (glm-review)
Grant migrations assume creator ran first; no existence guard | Each new file issues GRANT statements against concrete relations (e.g. public.llm_delegation_daily_projection, public.capsule_store) but contains no existence check or ordering dependency on the creating migration. The comments state the creator lives in a node lineage in this or another repo ('No migration in either repo has ever ISSUED them'), yet nothing in the diff guarantees the creator precedes the grant file in every deployment path. On
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MAJOR] hostile-reviewer (glm-review)
Verification only covers one lane; prod drift unproven | The 'MEASURED, NOT ASSUMED' section reports probe results exclusively from the .201 dev lane. The declared count (65) and undelivered count (27) are asserted to hold across local, onex-dev, and onex-prod topology instances, but no probe of prod or a clean rebuild is cited. The PR's own thesis is that hand-patched lanes mask drift; the dev lane being hand-patched is exactly the evidence base being used to size and validate the fix. The 27-undelivered f
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MAJOR] hostile-reviewer (glm-review)
Validation script and test changes absent from reviewable diff | scripts/validation/check_topology_grant_delivery.py (+28/-13) and tests/ci/test_topology_grant_delivery.py (+133/-0) are changed in this PR but no patch excerpt is included in the review target. For a PR whose stated purpose is closing the gap between declared and delivered grants, the detection logic is the load-bearing component; the SQL files are mechanical output. Reviewing the migrations without the checker changes certifies half the chan
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MINOR] hostile-reviewer (glm-review)
21 copies of ~110 lines of boilerplate narrative | Every added file duplicates an identical narrative header (WHAT IS BROKEN, MEASURED, WHY THIS LINEAGE, PRIVILEGES) differing only in table names and creator filename. This is approximately 2300 lines of prose that must be manually kept in sync with the checker's counts, ticket references, and privilege rationale. When the next grant tranche changes the totals or the privilege set, 21 files will silently disagree with each other. The stated rationale for per
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MINOR] hostile-reviewer (glm-review)
Numbering scheme inconsistency across added files | Most grant files use zero-padded three-digit sequence numbers (0002, 0003, 0035, 0022), but node_nightly_loop_controller uses '002' and node_projection_capsule_store uses '080' against a creator numbered 078. If the migration runner orders lexicographically, '080' sorts after '08' through '079' correctly only under fixed-width conventions; the single inconsistent '002' suggests no lint rule enforces padding. A lexicographic runner could order '002' before
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MINOR] hostile-reviewer (glm-review)
Schema USAGE re-granted in every file without justification for scope | Every file re-asserts GRANT USAGE ON SCHEMA public TO omninode_runtime. Individually harmless and idempotent, but 21 independent migrations now each widen the runtime principal's schema-level access, and any future node accidentally templated from these files will re-assert it even if its topology declaration omits the SCHEMA grant. The files claim 'This widens NOTHING beyond what the generated topology already declares' for the TABLE g
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492).
…merge
omnimarket#2285 merged at 2026-09-04T00:47:17Z as 8863472ce4730652d5074cdaad0cdf7f63215554,
declaring CATALOG ownership for the 24 public-schema relations this PR's grant
migrations target. `Application Database Domain Enforcement (OMN-15361)`
resolves the ownership manifest from `.proof-dependencies/omnimarket` at THIS
pin, so without the advance the gate still reads the pre-merge manifest and
still fails `Enforce schema qualification in changed SQL` with 24
`requires exactly one ownership declaration` lines.
Forward-only, as check_omnimarket_contract_pin_advance.py requires:
a0941e08 -> 8863472c, and 8863472c is omnimarket dev tip with a0941e08 as an
ancestor.
NO regeneration accompanies it, and that is a verified fact rather than an
omission. The pin file's own header requires regenerating the grants and the
rendered catalogs whenever it moves by hand, so both were run:
scripts/generate_application_database_table_grants.py --contracts-root
<omnimarket@8863472c>/src/omnimarket/nodes --write
-> loaded 69 db_io.db_tables declaration(s) plus 2 state_io and 1 legacy
instances updated: (none)
catalogs rendered: (none)
which is the expected result: #2285 changed `scripts/application-relation-ownership.yaml`
and the generated relation inventory, neither of which is a `db_io.db_tables`
input, so the derived TABLE grants cannot move. Re-proved with --check --prove:
PASS=55 FAIL=0 RESIDUAL=0 on every one of the six shipped profiles (local,
onex-dev, onex-prod, prod, stability-test, test).
The gate this unblocks now passes locally against the merged manifest:
`application_database_sql_gate=PASS`, exit 0 -- against `FAIL` with one line per
relation before #2285.
PROVENANCE NOTE, recorded rather than hidden: this one-line edit appeared in the
worktree at 00:49Z, two minutes after #2285 merged, written by an out-of-band
pin-refresh process rather than by this lane's own hand. It was not accepted on
sight -- the value was independently verified to equal #2285's merge commit,
the diff was confirmed to be exactly one line, and the regeneration the header
mandates was executed and proved to be a no-op before committing.
Refs: OMN-17440, OMN-17292, OMN-15361, OMN-15701
There was a problem hiding this comment.
Hostile Reviewer — adversarial findings (OMN-17492)
Models succeeded: glm-review
Models failed: codex
New finding threads: 3
Deduped (already posted on this PR): 0
Nit-level findings suppressed: 2
The model is the FINDER, never the gate: merge is gated only by the
deterministic Hostile Review Thread Gate, which blocks while
hostile-reviewer threads are unresolved. Resolve each thread after
addressing (or rejecting, with a reply) its finding.
Findings not anchored to a changed file
-
[MAJOR] hostile-reviewer (glm-review)
No sequence grants for serial/identity columns | The migrations grant SELECT, INSERT, UPDATE on tables but no USAGE on any backing sequences. Projection writers using INSERT ... ON CONFLICT DO UPDATE against tables with serial/identity primary keys will fail with permission denied for sequence on any fresh lane, reproducing the exact InsufficientPrivilege outage shape this PR claims to eliminate. The topology grant generator is stated to derive from db_io.db_tables declarations; if those declarations omit s
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MAJOR] hostile-reviewer (glm-review)
27 declared grants, 26 hand-granted, 21 files added; remainder unaccounted | The files claim the checker reported 27 undelivered grants of 65, of which 26 existed only via hand-grants on the dev lane. The PR adds 21 grant files. No file in the visible diff reconciles the arithmetic: either one declared grant remains undelivered, or the counts conflate table-level and schema-level grants. If any declared grant is left out, fresh environments will still hit the outage this PR exists to prevent, and the checke
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MAJOR] hostile-reviewer (glm-review)
No reconciliation of pre-existing hand-granted privileges | The comments acknowledge 26 grants exist out of band on the dev lane. The PR only ADDs grants; it never inspects or normalizes what the hand-grants contain. If an operator granted DELETE, TRUNCATE, or ALL on any of these tables during the drift window, the effective privilege on that lane now exceeds both the topology declaration and this migration's stated invariant of no DELETE. The drift detection closes, the drift itself persists per-lane. | Ev
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492).
Findings demoted from threads (anchor rejected)
-
[MINOR] hostile-reviewer (glm-review)
Inconsistent migration prefix numbering risks ordering ambiguity | node_nightly_loop_controller uses 002_grant_... while every other node uses the zero-padded 0002_/0003_/0035_ form. If the node-owned migration runner sorts lexicographically within a lineage, 002 may collide with or sort inconsistently against a future 0002/0020 file in the same node. The grant must run after the table-creating migration; a prefix collision or misordering would break that dependency silently. | Evidence: nodes/node_nightly_
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MINOR] hostile-reviewer (glm-review)
Contract pin bump coupled to an unrelated migration tranche | The omnimarket contract pin advances from a0941e0 to 8863472 in the same PR as 21 grant migrations and a validation-script change. A pin bump changes the cross-repo contract surface; if the grant tranche needs revert, the pin revert is entangled, and bisecting a future grant drift failure now crosses a contract boundary. The comments themselves cite OMN-15701, a pin-regeneration incident, as motivation for this PR's architecture. | Evidence: omni
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492). -
[MINOR] hostile-reviewer (glm-review)
No automated equivalence check between generated SQL and topology declaration | The PR's own thesis is that handwritten grant SQL drifts from the machine-generated topology declaration. Yet each migration is handwritten prose plus handwritten GRANT statements. tests/ci/test_topology_grant_delivery.py adds 133 lines but the visible diff does not show a test that regenerates the expected GRANT statements from db_io declarations and diffs them against the migration files. Without that, the next added table rep
Resolve this thread when addressed — the
Hostile Review Thread Gateblocks while hostile-reviewer threads are unresolved (OMN-17492).
Closes part of OMN-17440 (AC1 in full; AC2 to its provable floor).
The defect, measured twice
The generated topology declares 65 TABLE grants. Before this change 38 were issued by a migration and 27 by nothing at all, so a lane that has never been hand-patched — a fresh staging namespace, a rebuilt onex-dev, prod — authenticates fine and then refuses every write with
InsufficientPrivilegewhile the runtime reports healthy and commits its offsets. That is the OMN-16993 / OMN-17379 shape, and it is the fifth recurrence of this class in a fortnight (OMN-15701, OMN-16436, OMN-16993, OMN-17290, OMN-17374).Corpus probe, omnibase_infra dev
4053dc3c065b0bc94e98001a28ea9415ffd782cb:The gate passed at its own ratchet. The bound was the defect's bookkeeping, not a bound on it.
Lane probe, read-only SELECT against
information_schema.role_table_grantsinomnidash_analyticson the.201dev lane (compose projectomnibase-infra), diffed against the checked-in topology, 2026-09-03:nightly_loop_configs,delegation_shadow_comparisons— both relations absent from the lane)So none of this is a hypothetical residual: all 26 are already live dependencies of the dev lane that exist only because somebody typed the GRANT by hand. That is exactly why the gap stayed invisible.
What lands
21 new node-owned migrations, one per owning lineage, issuing the 26 grants:
node_projection_consumer_flow/0003omninode_internal.consumer_flow_windows,topic_produce_windowsnode_deployment_evidence_reducer/0002deployment_evidence_projection,deployment_readiness_projectionnode_evidence_dashboard_reducer/0002evidence_correlation_trace_projection,evidence_dashboard_projection,evidence_readiness_aggregate_projectionnode_nightly_loop_controller/002nightly_loop_decisions,nightly_loop_iterationsnode_projection_baselines_quality/003baselines_quality_snapshotsnode_projection_baselines_roi/003baselines_roi_snapshotsnode_projection_capsule_store/080capsule_storenode_projection_cost_by_repo/0002cost_by_repo_snapshotsnode_projection_delegation/0035generation_eventsnode_projection_event_chain/0002event_chainnode_projection_llm_cost/0002llm_call_metricsnode_llm_delegation_projection/0002llm_delegation_daily_projectionnode_projection_llm_routing/0002llm_routing_decisionsnode_projection_mcp_tools/0002mcp_toolsnode_projection_registration/0006node_service_registrynode_renderer_capability_projection/0002renderer_capability_projectionnode_projection_sandbox_decisions/0002sandbox_decisionsnode_projection_session_outcome/0022session_outcomesnode_projection_swarm/0002swarm_runsnode_projection_traces/0002tracesnode_projection_voice_sessions/0002voice_sessionsEvery file is a pure forward ADD next to an untouched creating migration. No parent is edited: each is applied on the
.201dev lane with a recordedcontent_sha256, so an in-place repair would raise "conflicting migration checksum in canonical node history" (the OMN-16705 constraint that 083/087 and 0032/0033 already hit).Each grants
SELECT, INSERT, UPDATEand deliberately no DELETE (a projection writer upserts, it does not reshape the table), re-asserts its schemaUSAGErather than assuming a sibling ran, and asserts both the INSERT and the SELECT took using the fail-loudSELECT 1 / count(*)shape flat 099 andnode_projection_session_replay/0002already use.Not one bulk grant file, for the OMN-15701 reason: a shared cross-node grant block is precisely how a relation added to a node later silently misses its grant.
The ratchet, and why the floor is 1 and not 0
MAX_UNDELIVERED27 → 1. The 1 isnightly_loop_configs, which no migration can deliver: nothing in the corpus issues aCREATE TABLEfor it, so there is no lineage to land a grant in and no relation for a grant to bite on.A new test,
test_the_two_tranches_together_are_the_whole_deliverable_set, makes the bound a floor rather than a reading — it asserts the undelivered set is exactly that one pair, so a future change cannot satisfy the count by leaving a different grant undelivered and calling it the floor.AC2's literal
== 0is not taken here, and that is deliberate: closing the last one is a contract decision (eithernode_nightly_loop_controllergrows aCREATE TABLEfor the relation its contract declares underdb_io.db_tables, or that declaration is removed), and it must not be faked by adding a GRANT for a relation that does not exist.The sequence half is unaffected —
MAX_UNDELIVERED_SEQUENCESstays 0, because that requirement is derived from declared grants against the corpus's applied column shapes, not from delivered ones. Re-verified:0 undelivered (bound 0).TDD — RED proven before GREEN
With the 21
.sqlfiles moved aside and only the new tests present:With them restored:
Vendor ordering
Vendored into omnibase_infra first per the node-migration-vendor-parity-gate ordering, ahead of the omnimarket source PR — an omnimarket PR touching
src/omnimarket/nodes/*/migrations/*.sqlcannot land until omnibase_infra@dev already carries a byte-identical copy. The 21application-migrations.tsvrows are what make that infra-ahead-by-one state legal rather than drift;sync-node-migrations.sh --checkreads them as preserved history via the OMN-15717 legacy-declared exemption. Same ordering #3108 used for tranche 1.dod_evidence
pre-commit run --all-filesuv run pytest tests/ci/test_topology_grant_delivery.py -quv run pytest tests/unit/scripts/validation/test_application_migration_manifest.py -quv run python scripts/validation/check_topology_grant_delivery.pysequence … 0 undelivered (bound 0)/topology grant delivery: 1 undelivered (bound 1), exit 0uv run python scripts/validation/validate_application_migration_manifest.pybash scripts/sync-node-migrations.sh --checkcheck: in sync, exit 0uv run python scripts/validation/validate_migration_sequence.pyuv run python scripts/validation/check_migration_rls_policy_atomicity.pyclean, exit 0uv run python scripts/validation/validate_migration_freeze.pyREMOTE_WRAPPER_EXIT=0Pre-existing failure recorded rather than hidden:
scripts/validation/check_migration_conflicts.pyexits 1 identically at dev tip4053dc3c0and on this branch — 3 cross-repo prefix/table conflicts, all in sibling repos under$OMNI_HOME(omnidash,steel_onslaught,omninode_infra), none in this diff. It is not wired as a pre-commit hook in this repo.Gate-fidelity concern filed, not relied on: the remote leg reports
h105 ran 0 tests greenand that is accepted in place of the whole-suite-equivalent selection. A zero-test run proves nothing. It is not what this PR leans on — the 66 + 20 local test results and the 103-hookpre-commit --all-filespass above are independent proof, run in this worktree.No
--no-verify, noSKIP=, noPREPUSH_*, noENABLE_SMART_TESTS=off, nocore.hooksPath, no gate edited and no gate timeout raised.No lane mutation. Every
.201contact was aSELECTor adocker ps/docker inspectread; prod, stability-test and judge were not contacted; no secret value was printed or transported (DSN roles were extracted with the password masked bysed).Refs: OMN-17440, OMN-17374, OMN-17447, OMN-16993, OMN-17379, OMN-17377, OMN-15701, OMN-16436, OMN-17290, OMN-16705, OMN-15717
Evidence-Ticket: OMN-17440
Evidence-Source: OCC#8140