[Deep-Sixed]

Follow-up to #23. A repository's approval policy becomes its default. Operators can now override it for a single operation type. For example, a force push or a branch deletion can need two votes while a lease takeover needs one.

What changes

• Overridable operation types: protected_ref_update, force_update, ref_delete, out_of_scope_push, protected_path_update, lease_takeover.
• What an override can set: the threshold, the approving roles, and whether the requester may vote. Any field an override leaves unset still follows the default, even if the default changes later. --inherit removes an override.
• Migration 008_operation_policies.sql (renumbered from 006; 006 and 007 now hold the ref-update transaction tables from Bind push authorization to Git's reference transaction #30 and Measure claim scopes against the mainline, not every ref #29):
  • Adds operation_approval_policies, operation_approval_roles, and an approval_effective_policy view.
  • Recreates the two vote-eligibility triggers so they enforce the effective policy. Code that writes to the database directly is held to the overrides too.
  • Adds no overrides, so existing repositories behave exactly as before.
  • The store's contract check requires the view by name, before the full schema fingerprint (which covers views too), so a dropped view is reported as such.
• Enforcement: registry.approval_policy(conn, repo_id, operation_type) returns the effective policy. Requests, votes, and consumption all use it, so raising an override invalidates approvals that no longer meet it.
• Invalidated approvals can be topped up. The next vote reopens an approved instance that no longer meets the current policy, and the audit log records it as approval.reopened. Eligible agents can then add the missing votes, or deny it. Before this, such an approval was stuck until the policy was loosened. That also happened when the default threshold was raised, before this PR.
• CLI: quorumgit repo policy <repo> --operation <type> [--threshold n] [--role r]… [--[no-]requester-may-vote] [--inherit]. The plain repo policy <repo> view now lists overrides.
• What stays the same: an agent that approved an operation still can never carry it out, even where an override lets the requester vote.

Testing

• New tests/test_operation_policies.py (9 tests):
  • an override's threshold applies only to its own operation type
  • override roles replace the default roles, enforced both in Python and by the database trigger
  • an override that lets the requester vote still doesn't let an approver carry out the operation
  • raising an override invalidates existing approvals, which a new vote reopens and brings back up to the threshold
  • an invalidated approval can be denied, while one that still meets the policy stays closed to further votes
  • unset fields inherit the default, --inherit removes an override, and changes are audited
  • input validation and operator-only changes
  • the contract check rejects a store missing the view
  • the CLI round trip
• Updated the existing migration-list assertions for 006–008.
• After merging main: pytest 240 passed. ruff check and pyright are clean.

🤖 Generated with Claude Code

https://claude.ai/code/session_0142xh1CDDPxBvB1EHu6PN3m
https://claude.ai/code/session_01Q8BpCkArA34hB1aSyVcnZp

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 2ba93177fd

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".