[jonahgabriel]

AGENT SCOPE: OPEN AND VERIFY ONLY — DO NOT MERGE

This PR touches grants/prod_promotion_grants.yaml, CODEOWNERS-protected by @OmniNode-ai/platform-leads. No agent will merge it. The CODEOWNERS merge is the approval act (OMN-13418). This PR reproduces the intent of #7464; the merge event, and nothing prior to it, is the authorization.

Ticket: OMN-16702 (adjacent: OMN-16685).

---

Operator ruling this executes

2026-08-29: re-stage the valkey roll grants. batch-af8142c0-f2bf-4d79-887a-e65d964c9da8 (OCC#7464, merged 2026-08-28T21:51:06Z) expired 2026-08-29T09:00:00Z, unconsumed — no deploy-onex-prod.yml dispatch ever ran against it (last dispatch, run 33209359978, fired at 2026-08-28T20:42:14Z, before the grant merged; nothing has dispatched since). Its four entries were pruned by a concurrent lane (onex_change_control#7554, OMN-15010) for the unrelated reason that main was red on the OMN-13424 no-expired-entry invariant.

One line for the approver, per the operator's instruction: merge = approval; the roll-execution lane dispatches on merge.

Security context, per the operator's instruction: the public-cluster dev/dev-valkey this batch's entry 4 authorizes credentialing is currently unauthenticated and serves dash.omninode.ai session data (until the k8s/onex-public apply moves omnidash off it) plus Infisical's cache. Anything that can route to dev:6379 today reads and writes the whole keyspace — the NetworkPolicy admitting it is namespace-wide, not workload-scoped. That exposure is why this window is being re-staged rather than left to lapse a second time.

Coordination with the concurrent prune (#7554)

#7554 ("prune the four expired batch-af8142c0 prod-promotion grants") was OPEN, MERGEABLE, checks green at the time this branch was cut. This branch is built directly on top of its head commit (hotfix/omn-15010-prune-expired-af8142c0-grants @ 0d203ec77) rather than independently off main, so:

• This PR's diff against main already carries #7554's deletion of the four expired af8142c0 entries, plus this PR's own four new entries under a new batch.
• No grant_id is duplicated, and merge order between the two PRs doesn't matter — whichever lands second finds its removal of the same four lines already applied and merges clean.
• #7554 remains useful and mergeable on its own if the operator prefers to land it first; this PR does not supersede its scope, only builds on it.

What's in the new batch

Same four entries as batch-af8142c0 in substance, new promotion_batch_id: batch-48e48b4c-68f5-4e1c-b12e-818dcf062dfd and new grant_ids (the OMN-13424 validator forbids re-adding an already-expired grant_id):

Entry	Digest	Role
grant-30d406bb	sha256:13c96028… (runtime)	mechanically required — unconditional OMN-14209 runtime grant gate
grant-7f32b169	sha256:50601f9e… (omnidash)	documentary
grant-0bb17fe1	sha256:b4c32554… (onex-api)	documentary
grant-25d6751a	sha256:53ae5378… (dev-valkey)	documentary — the runbook roll

expires_at: 2026-08-30T16:00:00Z — aligned with the still-live OMN-16799 cutover batch (batch-404af076) below it in the file, so both live batches share one expiry.

Preconditions re-verified, not assumed

• Target surfaces unchanged since af8142c0 was authored (2026-08-28T21:08Z SSM capture): runtime digest, k8s/onex-public tree SHA (04c2fe17e6a7478271e1358b78ee9afda6aa544b), omnidash/onex-api/valkey image digests all re-checked live against omninode_infra@main/@dev 2026-08-29 — identical. git log --since=2026-08-28T21:08:00Z on those five manifest paths returns nothing.
• Runbook re-read (omninode_infra/docs/runbooks/OMN-16702-dev-valkey-requirepass-roll.md): Step 0 sequencing (public apply first, roll second) and Step 3 server-first order (reversing it is a hard AUTH failure, not a degradation) are unchanged. Rollback posture unchanged — reverse-order rollout undo, credential Secret not deleted, rollback is a security regression not a neutral outcome.
• Precondition NOT proven true, carried forward honestly: the post-deploy verification gate failed on check 8 in the last dispatch even after the OMN-16799 check-8 fix (d75cbdc) had already merged before that run. No dispatch has run since to re-prove or disprove it — this grant removes the authorization blocker only, same as the original.

Verification

• Producer-side validator (extracted verbatim from .github/workflows/validate-prod-promotion-grants.yml, re-executed): PASS: grants/prod_promotion_grants.yaml — 6 grant(s) validated successfully.
• uv run pytest tests/test_prod_promotion_grants.py -q → 18 passed.
• pre-commit run --files grants/prod_promotion_grants.yaml → clean (yamlfmt reflowed once, re-verified after).
• YAML parses; 6 entries, no duplicate grant_id/promotion_batch_id.

main-target-guard trailers

Same underlying ticket (OMN-16702) as #7464; reusing its evidence companion since nothing new landed on dev for this re-stage.

Evidence-Ticket: OMN-16702
hotfix-evidence: OCC-7441
backmerge: #7441

[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: 4be0f2dd-aa12-4f6f-8a12-7b9877c7612a

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.}