Repository navigation
docs(OMN-17437): make the grant registry header describe the gate that now exists - #7946
Conversation
…eipts Adds the occ-self-bind-pr-7946 entry and its PASS receipt per the eligibility validator's own remediation text, and recomputes contract_sha256 on the two existing OMN-17437 receipts — the whole-file hash moves when the contract gains an entry, while per-entry contract_entry_sha256 values do not (OMN-13888).
|
Merge-sweep attribution (read-only pass, no mutation made to this PR). This PR was escalated to a deeper sweep on the claim that a required status check —
So there is no missing check and no workflow bug. The actual reason That review cannot come from this lane, and it cannot come from the author: GitHub forbids self-approval, and the author is a member of the reviewing team. The team now has two members, so an approval from the other member is the unblock. No gate change, no CODEOWNERS broadening, and no bypass actor was considered or applied. Left open deliberately. Recorded so the next sweep does not re-escalate this as a workflow defect. |
|
Manual merge-sweep update: live checks are green ( |
|
OCC autobind stood down for |
|
codex-merge-sweep update: disabled auto-merge again on head |
|
codex-merge-sweep update: disabled auto-merge again on head |
|
OCC autobind stood down for |
…t now actually exists The header asserted that landing a grant on main is 'the anti-self-issue anchor an agent structurally cannot complete'. Until 2026-09-01 that was false: main carried requiresApprovingReviews=false and requiresCodeOwnerReviews=false, and the only ruleset was DISABLED with no PULL_REQUEST rule, so the CODEOWNERS entry auto-requested a reviewer and blocked nothing. Every grant PR in that window was merge-blocked by CI breadth alone. Records where the requirement actually lives now, why the branch-wide controls (required_approving_review_count, require_last_push_approval) are deliberately off while the path-scoped require_code_owner_reviews is on, the window in which the gap was live, and the consequence that matters operationally: platform-leads has one member, so a grant PR authored by that member cannot be approved by anyone. That is the property working, and the header now says so rather than implying the flow is unchanged.
…eipts Adds the occ-self-bind-pr-7946 entry and its PASS receipt per the eligibility validator's own remediation text, and recomputes contract_sha256 on the two existing OMN-17437 receipts — the whole-file hash moves when the contract gains an entry, while per-entry contract_entry_sha256 values do not (OMN-13888).
9ab973c to
17fb4ff
Compare
|
codex-merge-sweep update: disabled auto-merge again on head |
…is-not-author basis
The header asserted that platform-leads has a single member and that a grant PR
authored by that member could not be approved by anyone. That was accurate on
2026-09-01 and is not accurate now: the team has two members, verified live via
gh api orgs/OmniNode-ai/teams/platform-leads/members, so a grant PR authored by
one member is approvable by the other and the code-owner review is a review a
second person actually performs.
Restates the anti-self-issuance property on its real basis — approver-is-not-author
refusals evaluated against the grant's own fields — rather than on an approver set
too small to approve anything. Names both refusals and where each one runs:
- the dispatch gate in omninode_infra scripts/validate_prod_promotion_grant.py,
which refuses approved_by == the requesting identity as self_granted;
- the authoring-time refusal in this repo's grants validator, which per a live
tree read is present on dev and ABSENT on main, the branch grant PRs target,
so it does not run on this path.
Stating that second half rather than implying it, because the header exists to
stop this file from asserting a control it does not have.
Doc-only. One file, comments only. No entry, schema, runtime or src change.
Amended: the approver-set paragraph now says two members, on the approver-is-not-author basisAddresses the review finding that three lines asserted a one-member reviewing team. That was accurate when the header was written on 2026-09-01. It is not accurate now. Live member count, read at amend time: Two members. The header names the count only, not the people — a governance document should not go stale on a roster change. What changedOne file, comments only: Before (the three lines the review flagged, plus their conclusion): After, in substance: the team has two members, so a grant PR authored by one is approvable by the other, and the code-owner review above is a review a second person actually performs rather than a requirement nobody can satisfy. The anti-self-issuance property does not rest on an approver set too small to approve anything. It rests on approver-is-not-author refusals evaluated against the grant's own fields. The closing guidance is unchanged: a stalled grant PR is waiting on a review a colleague can give, and is never repaired by relaxing branch protection, adding bypass actors, or broadening the CODEOWNERS rule. One thing I found while writing it, which you should read before approvingThe amendment names both approver-is-not-author refusals and where each one actually runs, because on this PR's base branch they are not both live:
State
I have not approved this, have not landed it, and have not requested review from anyone — |
jake-b-omni
left a comment
jake-b-omni
left a comment
There was a problem hiding this comment.
Approved. Verified the header's claims against live state on 2026-09-18 rather than reading them:
mainbranch protection: require_code_owner_reviews true, required_approving_review_count 0, dismiss_stale_reviews true, enforce_admins true, require_last_push_approval false — matches the block as written.- platform-leads has two members, so the code-owner review is one a second person can actually give.
src/onex_change_control/scripts/validate_prod_promotion_grants.pyis present ondev(f42ba1fb) and 404s onmain, so the authoring-time half genuinely does not run on the branch grant PRs target.omninode_infra/scripts/validate_prod_promotion_grant.py: SELF_GRANTED enum member at :175,approved_by == requested_bycomparison at :503. The dispatch refusal is the surviving mechanical control, as stated.
One operational consequence worth naming somewhere, since the dispatch gate compares approved_by against the dispatching identity: on the grants I author, you have to be the one who dispatches the promotion, or the gate refuses it as self_granted.
2 participants
Follow-up to #7939 (merged as
3022d69e). Closes OMN-17437 AC-4, and doubles as the behavioural proof of AC-1.hotfix-evidence: OCC-7938
backmerge: #7938
Why
The header of
grants/prod_promotion_grants.yamlasserts that landing a grant onmainisUntil 2026-09-01 that was false.
maincarriedrequiresApprovingReviews: false/requiresCodeOwnerReviews: false, and the repo's only ruleset (Merge Queue) wasDISABLEDwith noPULL_REQUESTrule, so the CODEOWNERS entry auto-requested a reviewer and blocked nothing. Every grant PR merged in that window — #7084, #7213, #7418, #7464, #7554, #7561, #7662, #7731 — was merge-blocked by CI breadth alone, an accident rather than a control.#7939 installed the requirement. This PR makes the header say what is actually true, rather than leaving doctrine that asserts an absent gate — the defect class OMN-16847 names.
What the header now records
mainbranch protection,requiresCodeOwnerReviews: true,isAdminEnforced: true— not the CODEOWNERS file on its own.required_approving_review_countandrequire_last_push_approvalgate every PR intomainregardless of code ownership.require_code_owner_reviewsis the path-scoped one and covers exactly this file andallowlists/skip_token_approvals.yaml.platform-leadshas one member, and GitHub forbids self-approval, so a grant PR authored by that member cannot be approved by anyone. That is the anti-self-issue property working, not a misconfiguration — and the header says explicitly not to "fix" it by relaxing branch protection, adding bypass actors, or broadening CODEOWNERS.This PR is itself the proof, twice over
It touches
grants/prod_promotion_grants.yaml— a CODEOWNERS-covered path — so it should demonstrate both halves of OMN-17437 live:reviewDecisionshould beREVIEW_REQUIREDand the PR should not be mergeable without a platform-leads approval. Before fix(OMN-17437): make the prod-promotion grant merge mechanically gated on OCC main #7939 the same diff would have been mergeable the moment checks went green.auto-merge.ymlonmainnow carries the OMN-16117 governance-path exclusion, so this PR must not be armed for auto-merge (autoMergeRequest: null).Both are recorded on OMN-17437 as the closing evidence.
Blast radius
Comment-only.
entries: []is byte-unchanged and the file still parses with zero grant entries. No grant is issued, approved, consumed or modified; no prod, stability or judge mutation.