nisse-review: approve PRs where its approval counts #173

New Issue

2026-10-20T00:36:41Z

dev-agent commented

2026-10-20 00:36:41 +00:00

For much later consideration (operator, 2026-10-20).

nisse-review should be able to approve PRs in repositories where it has the right permissions. It should work out for itself whether it has them, with no per-repo setting.

Today: sign_off posts a COMMENT review. The reviewer is read-only (R3): it stops if it can write, and it can't resolve threads (Gitea 403; #169 hands that to the PR's author).

Constraints to keep in mind

R3 stays. "The right permissions" must not mean write access. Gitea's branch protection can count approvals from an approvals allowlist (users or teams with read access), which gives the reviewer an official approval without write.
Detecting it on its own. Options:
- read the base branch's protection (GET /repos/{o}/{r}/branch_protections/{branch}); a read-only account may not be allowed to see it;
- check a review's official flag on one it has posted;
- an APPROVED review from an account outside the allowlist is just a non-binding approval, so the question is whether it counts, not whether Gitea accepts it.
This should be structural: code decides whether an approval is possible, never the model's guess.
When to approve versus comment. Probably exactly where it would sign_off today, and maybe still_happy after a push, once the approval goes stale. A push dismisses stale approvals, so it would have to approve again at the new head.
Operator control. Should the operator be able to turn it off per repository even where it's allowed? And how does this fit with the trust dial (M3.3), since nisse-dev merges on approvals? An approval from nisse-review could let nisse-dev merge with no human approval at all. That needs a deliberate decision.

Lands in: not yet scheduled (Part R, after M7.7).

🤖 Generated with Claude Code

https://claude.ai/code/session_01J5Utyfzw7gF7UhjRDEtjTk

**For much later consideration** (operator, 2026-10-20). nisse-review should be able to approve PRs in repositories where it has the right permissions. It should work out for itself whether it has them, with no per-repo setting. **Today:** `sign_off` posts a COMMENT review. The reviewer is read-only (R3): it stops if it can write, and it can't resolve threads (Gitea 403; #169 hands that to the PR's author). **Constraints to keep in mind** - **R3 stays.** "The right permissions" must not mean write access. Gitea's branch protection can count approvals from an **approvals allowlist** (users or teams with read access), which gives the reviewer an official approval without write. - **Detecting it on its own.** Options: - read the base branch's protection (`GET /repos/{o}/{r}/branch_protections/{branch}`); a read-only account may not be allowed to see it; - check a review's `official` flag on one it has posted; - an APPROVED review from an account outside the allowlist is just a non-binding approval, so the question is whether it *counts*, not whether Gitea accepts it. This should be structural: code decides whether an approval is possible, never the model's guess. - **When to approve versus comment.** Probably exactly where it would `sign_off` today, and maybe `still_happy` after a push, once the approval goes stale. A push dismisses stale approvals, so it would have to approve again at the new head. - **Operator control.** Should the operator be able to turn it off per repository even where it's allowed? And how does this fit with the trust dial (M3.3), since nisse-dev merges on approvals? An approval from nisse-review could let nisse-dev merge with no human approval at all. That needs a deliberate decision. **Lands in:** not yet scheduled (Part R, after M7.7). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01J5Utyfzw7gF7UhjRDEtjTk

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dev/nisse#173