[jonahgabriel]

What the approver is being asked to do

Merge this PR. That merge is the approval act (OMN-13418) — an agent structurally cannot complete a CODEOWNERS-gated merge to main, which is exactly why the merge, not any field in the file, is the anti-self-issue anchor. No agent will merge this.

Ticket: OMN-16799.

After this lands, the operator surface is two more things, in order: un-draft + merge omninode_infra#1044, then have the dispatcher fire the deploy. Nothing else.

---

What this grant authorizes

Exactly one gated deploy-onex-prod.yml dispatch, run with deploy_target=onex-api AND reclaim_api_hostname=true in the same run. Those are deliberately coupled: omninode_infra#1044's Validate reclaim_api_hostname input step refuses reclaim_api_hostname=true unless deploy_target is onex-api/all, precisely so api.omninode.ai can only ever be pointed at an onex-api digest this gate has already cleared. Promotion and hostname reclaim ride one dispatch.

It authorizes no other prod mutation, and no prod mutation has occurred.

Two entries, both mechanically required

deploy-onex-prod.yml runs the OMN-14209 grant gate twice on a deploy_target=onex-api dispatch:

Step	Guard	Digest it resolves	Covered by
Enforce prod-promotion grant — runtime image	none — runs unconditionally	RUNTIME_IMAGE_REF from k8s/onex-prod/runtime/kustomization.yaml → sha256:13c96028…	grant-7ebd7674-9b25-466c-920d-a74a0f3efadb
Enforce prod-promotion grant — onex-api image	if: deploy_target != 'runtime-only'	ECR lookup on the dispatched commit_sha → sha256:bc95b9bc…	grant-7013b49e-f714-4ead-8910-e6ffda84df56

The runtime step's own comment states it: "Runtime image is deployed unconditionally for every deploy_target value … so this check also runs unconditionally." A single-entry grant covering only the onex-api digest would have blocked at the first gate before ever reaching the second. Entry 1 is a same-digest authorization — sha256:13c96028… is what onex-prod's runtime plane is already running and what is pinned on omninode_infra main (8a4ebe69) and dev (ab92b08b) alike, so kubectl apply -k is a no-op for the runtime image and no runtime pod is rescheduled.

Digest provenance (entry 2 — the real promotion)

• Registry: 272493677981.dkr.ecr.us-east-1.amazonaws.com/omnicloud/core
• Digest: sha256:bc95b9bc5a1860dd666ecea4e82e278ff4ddb2d08da5d280ba8472b7041309ab
• Built by Build and push onex-api image to ECR run 33179880143 — conclusion success, 2026-08-28T14:23:12Z, headBranch: main, headSha: 8a4ebe6919a52f8de272fb908e90866e8514e3cd (the current main HEAD), tagged with that commit SHA.
• Trivy CRITICAL/HIGH clean. Contains docker/onex-api/tenant_event_outbox.py.
• deploy-onex-prod.yml resolves it via resolve-ecr-digest in exact-match-only mode (fallback-to-latest is not passed, fail-on-missing: 'true'), so a wrong commit_sha fails loud rather than silently resolving some other image.

It replaces sha256:b4c325545e1012aef53772d1a3f5a30eb9af3809b9a4036e28a156db906581bc, the digest pinned in k8s/onex-prod/api/deployment.yaml.

expires_at is a PROPOSAL

expires_at: 2026-08-30T16:00:00Z (~49h from staging) is a proposal — the approver may amend it before merge; merging is approving. Same for approved_by.

approved_by — disclosed, not claimed away

As staged, the PR author and approved_by are both jonahgabriel. On this branch's own header rule ("The approver MUST differ from the PR author") that is self-approval as staged, and it is written down here rather than argued around. The approver closes it by confirming or replacing the value at merge time.

It is a real login and not a placeholder string for the reason OCC#7213 recorded: the schema requires a non-empty string, and the consumer enforces approved_by != requested_by against github.actor — a synthetic placeholder would compare unequal to every dispatcher and would silently disable the only mechanical anti-self-approval check on this path.

Anti-self-approval is satisfied on the dispatcher side, not here. With the staged value the workflow_dispatch actor must be daniyalabbas96 — the same identity that dispatched the proven-shape run 33117155819 on 2026-08-27 against the jonahgabriel-approved batch-92a794cd. If approved_by changes at merge time, re-derive the permitted dispatcher.

Validation — run locally, both directions, against the real implementations

Producer side (this repo's own schema suite, includes the OMN-13424 at-rest invariant that refuses any expired entry):

uv run pytest tests/test_prod_promotion_grants.py -q
18 passed in 0.03s

Consumer side — omninode_infra/scripts/validate_prod_promotion_grant.py, the exact script the workflow runs, driven offline against this file via its own --grants-file path:

dispatcher	digest	result
daniyalabbas96	sha256:13c96028…	PASS: grant grant-7ebd7674… approved_by=jonahgabriel expires_at=2026-08-30T16:00:00Z
daniyalabbas96	sha256:bc95b9bc…	PASS: grant grant-7013b49e… approved_by=jonahgabriel expires_at=2026-08-30T16:00:00Z
jonahgabriel	sha256:13c96028…	BLOCKED (self_granted)
jonahgabriel	sha256:bc95b9bc…	BLOCKED (self_granted)

The BLOCKED rows are the point: the interlock is live, not asserted.

Pruned in this PR — and why nothing is lost

The two OMN-16626 entries added by OCC#7213 (grant-3c885a33… runtime, grant-9c23ed5d… omniintelligence) both carry expires_at: 2026-08-28T20:00:00Z — hours from this staging. The OMN-13424 invariant refuses to let any expired entry remain, so this file cannot pass CI with them present once that timestamp passes, which is likely before the approver reaches it. They are removed rather than silently extended.

• grant-3c885a33… was consumed in substance by run 33117155819 (2026-08-27, runtime-only, dispatcher daniyalabbas96) — its runtime gate passed and the apply succeeded. Entry 1 re-authorizes the identical digest, so the runtime gate loses no coverage.
• grant-9c23ed5d… (omniintelligence sha256:a66ff063…) was never mechanically read by any gate — its own reason says so — and the pin it recorded is already merged on omninode_infra main (docs(OMN-11024): add delegation wire DTO evidence #1016, f127b84) and was applied by that same run. If a fresh omniintelligence authorization is wanted it must be re-issued in its own PR; this batch authorizes an onex-api cutover and nothing else.

Header lines 1–46 (the durable schema / invariant / four-step process block) are carried forward byte-identical from main. The only text dropped is the OMN-16626 per-request paragraph, which documents the entries this PR prunes.

Rollback

The workflow's own Rollback deployment on failure step covers deployment/onex-api (returning it to the prior ReplicaSet on sha256:b4c32554…) plus objects newly created by a partially-failed apply.

The Ingress DELETE is not covered by that rollback. Re-applying the onex-dev/onex-api Ingress by hand would restore the pre-existing dual-claim defect, not a healthy state — so the declared rollback target for the hostname half is "leave onex-prod/onex-api as sole claimant and fix forward". That is precisely why #1044 refuses the delete unless onex-prod's onex-api is Available=True, its onex-api-tls Certificate is Ready=True (verified Ready=True on 2026-08-28), and onex-prod already claims the host.

Routing

Consumer is omninode_infra's scripts/validate_prod_promotion_grant.py (k3s/EKS cloud plane, OMN-14209) — not the .201 compose-lane node_redeploy_orchestrator path. No raw SSH/kubectl retag/recreate path is used or implied.

Evidence-Ticket: OMN-16799

---

main-target-guard trailers — what the two fields below actually point at

main-target-guard (the version resolved from main) accepts a main-targeting PR from a hotfix/* head only when the body carries both a hotfix-evidence: and a backmerge: line. Both are stated literally rather than satisfied with a placeholder:

• hotfix-evidence: OCC-7420 — OCC#7420, the hand-authored evidence companion for omninode_infra#1044 on this same ticket. It carries the behaviour proof for the gated hostname reclaim that this grant authorises the other half of.
• backmerge: #7420 — the same PR, and this needs saying plainly: there is no content backmerge of the grants file into dev, deliberately. onex_change_control@dev carries a grants registry with zero grant_id entries (verified: git show origin/dev:grants/prod_promotion_grants.yaml | grep -c grant_id: finds only header/schema prose, no entries; main has the live entries). The registry lives on main on purpose — that is the branch the consumer resolves from. Backmerging grant rows into dev would create a second registry that no gate reads and that the OMN-13424 at-rest expiry invariant would then start failing on independently. #7420 is named here as the dev-side PR of record for OMN-16799, which is the same convention OCC#7213 (OMN-16626) used on this identical base (hotfix-evidence: OCC-7211 / backmerge: #7211, both naming that ticket's dev-side companion).

CI fix applied after the first push (aaa0a0f56)

Contract Compliance Check hard-BLOCKed on dod-prod-promotion-grant-consumer-gate-omn16799: its command was rooted at $OMNINODE_INFRA, an env var the hosted gate does not set, so it resolved to python3 /scripts/validate_prod_promotion_grant.py → No such file or directory, exit 2.

Fixed by declaring the check cross-repo the way the runner asks for (OMN-16824): cwd: "${OMNI_HOME}/omninode_infra", with the grants-file argument moved to a required OCC_GRANTS_FILE env var so it fails loud instead of silently validating the wrong checkout. The hosted gate checks out exactly one product repo and leaves ${OMNI_HOME} empty, so it now reports NOT-EVALUATED [cwd] for this item — non-blocking, and an honest "this gate did not evaluate it" rather than a verdict about a tree it was never pointed at. Same shape OCC#7403 (OMN-16838) ran live on this gate earlier today.

The evidence itself did not weaken: all four consumer-gate rows were re-executed against the new command shape with real exit codes read from the processes (daniyalabbas96→exit=0 on both digests; jonahgabriel→exit=1 BLOCKED (self_granted) on both), and contract_entry_sha256 / contract_sha256 were recomputed.

hotfix-evidence: OCC-7420
backmerge: #7420

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 07807e02-6f0a-4586-8a4b-3ab5a1a9324b

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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