Scaled-Tech-Consulting/Gitea-Tools
2
0
Fork 0
Code Issues 73 Pull Requests 9 Actions Packages Projects Releases Wiki Activity

Reviewer approval must prove prior request-changes blockers are resolved or invalid #326

New Issue
Closed
opened 2026-07-07 01:49:32 -05:00 by jcwalker3 · 1 comment
jcwalker3 commented 2026-07-07 01:49:32 -05:00
Owner
Copy Link
Copy Source

A PR can have a prior REQUEST_CHANGES review on a given head SHA. If a later reviewer approves the same head SHA, the workflow must prove why the previous blocker no longer applies.

Problem

Approving an unchanged head after a request-changes review can accidentally override a valid blocker.

Required behavior

  1. Before approving, fetch current PR review feedback.
  2. If there is a prior REQUEST_CHANGES, report:
    • blocking reviewer
    • blocking review timestamp
    • blocking head SHA
    • current head SHA
    • blocker text
    • whether head changed since blocker
  3. If the head did not change, approval requires proof that:
    • the earlier blocker was incorrect, or
    • the validation environment was wrong, or
    • the issue was resolved externally in a way that does not require PR head changes
  4. If this proof is missing, do not approve. Request changes or stop.

Acceptance criteria

  • Unchanged-head approvals after request-changes require explicit override proof.
  • Reports must include blocker text and reason for override.
  • Tests cover changed head, unchanged head resolved, unchanged head unresolved, and missing feedback.

Context

Related: gitea_get_pr_review_feedback, has_blocking_change_requests, author_pushed_after_request_changes, review_feedback_stale (#167, #244). Distinct from queue-skip blocker proof (#318) and broad review state-machine hardening (#290).

A PR can have a prior `REQUEST_CHANGES` review on a given head SHA. If a later reviewer approves the same head SHA, the workflow must prove why the previous blocker no longer applies. ## Problem Approving an unchanged head after a request-changes review can accidentally override a valid blocker. ## Required behavior 1. Before approving, fetch current PR review feedback. 2. If there is a prior `REQUEST_CHANGES`, report: - blocking reviewer - blocking review timestamp - blocking head SHA - current head SHA - blocker text - whether head changed since blocker 3. If the head did not change, approval requires proof that: - the earlier blocker was incorrect, or - the validation environment was wrong, or - the issue was resolved externally in a way that does not require PR head changes 4. If this proof is missing, do not approve. Request changes or stop. ## Acceptance criteria - Unchanged-head approvals after request-changes require explicit override proof. - Reports must include blocker text and reason for override. - Tests cover changed head, unchanged head resolved, unchanged head unresolved, and missing feedback. ## Context Related: `gitea_get_pr_review_feedback`, `has_blocking_change_requests`, `author_pushed_after_request_changes`, `review_feedback_stale` (#167, #244). Distinct from queue-skip blocker proof (#318) and broad review state-machine hardening (#290).
jcwalker3 added the status:in-progress label 2026-07-07 01:51:21 -05:00
jcwalker3 commented 2026-07-07 01:51:22 -05:00
Author
Owner
Copy Link
Copy Source

Claimed. Branch: feat/issue-326-request-changes-override-proof. Worktree: branches/feat-issue-326-request-changes-override-proof.

Scope: assess_request_changes_approval_proof in review_proofs + tests per acceptance criteria.

LLM-Agent-SHA: llm-4b8e1d7a3c92

Claimed. Branch: `feat/issue-326-request-changes-override-proof`. Worktree: `branches/feat-issue-326-request-changes-override-proof`. Scope: `assess_request_changes_approval_proof` in review_proofs + tests per acceptance criteria. LLM-Agent-SHA: llm-4b8e1d7a3c92
sysadmin removed the status:in-progress label 2026-07-07 02:59:35 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
allocator
Controller-owned work allocator
 anti-stomp
Prevent concurrent LLM session stomping
 architecture
Architecture / structural design
 bug
chore
codex
OpenAI Codex client / workflow session surface
 concurrency
Concurrent session safety
 contamination
Workflow or session contamination incident
 control-plane
MCP control-plane coordination and allocation authority
 dashboard
MCP operational dashboard/queue view
 database
Internal coordination storage (SQLite/Postgres)
 design
Design / investigation, no implementation
 documentation
Docs / runbooks
 enhancement
New feature or improvement
 gitea
Gitea MCP workflow
 glitchtip
GlitchTip integration
 important
incident
Operational or process incident requiring durable audit trail
 incident-bridge
Sentry-to-Gitea incident bridging
 integration
Integration testing
 jenkins
Jenkins integration
 labels
Label taxonomy management
 leases
Lease adopt/release/expire lifecycle
 mcp
MCP server / tooling
 mcp-health
MCP namespace and runtime health
 mcp-menu
MCP menu surface
 multi-project
Work spanning multiple monitoring projects or Gitea repos
 mutating
Mutating action; requires gating
 nice-to-have
observability
Observability, metrics, traces, error reporting
 portability
Cross-platform / portability
 preflight
Shared preflight gates before mutation
 protected-branch
Protected branch / stable-branch policy concern
 queue
Work queue visibility and allocation
 read-only
Read-only, no mutation
 reconnect
MCP client reconnect/reload recovery path
 recovery
Recovery paths for stale/foreign leases
 refactor
Code refactor / restructure
 release
Release / versioning
 reliability
Reliability / failure handling
 resumable-review
Persist and resume prepared review verdicts across sessions
 reviewer
Reviewer workflow tooling
 roadmap
Roadmap / umbrella issue
 safety
Safety rails and fail-closed mutation guards
 security
Security / trust boundary
 self-hosted
Self-hosted infrastructure integration
 sentry
Sentry error monitoring integration
 stale-runtime
Stale backend daemon / runtime-vs-master parity failures
 status:blocked
Issue is blocked
 status:in-progress
Issue is being worked on
 status:pr-open
Issue has an open pull request
 status:ready
Issue is ready for work
 terminal-lock
Terminal review lock (#332) path
 testing
Tests / test coverage
 tracker
Issue tracker hygiene / meta
 type:bug
Bug or defect
 type:feature
Feature or enhancement
 type:feature
Feature or enhancement
 type:guardrail
Safety gate or guardrail
 visibility
Workflow state visibility for LLMs/operators
 workflow
Cross-tool workflow
 workflow-hardening
LLM workflow coordination hardening
 workflow-hardening
LLM workflow coordination hardening
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
jcwalker3 sysadmin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Scaled-Tech-Consulting/Gitea-Tools#326