iceboundrock / iceboundrock/AutoForge
Re-verify the clean review comment on GitHub before MERGE writes
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 0
- Forks
- 0
- Avg merge
- 8h 56m
- Merged PRs (30d)
- 40
Description
Follow-up from #68 / PR #93.
Context
Since #68 the merge gate requires the persisted binding (reviewed_pr_url, reviewed_head_sha, reviewed_base_ref) and checks current_pr_url and the PR GitHub returns against it by identity. The binding is written by _apply_review after the review comment was verified on GitHub (right PR, right round, right HEAD, unique marker), and MERGE trusts that persisted record.
Gap
The gate does not re-read the review comment at merge time. A state file whose last_review_result, reviewed_* fields and last_review_comment_url were edited by hand (or written by a controller bug) after the review is accepted by the gate as long as the fields are shape-valid and consistent with current_pr_url and the PR's current HEAD/base. GitHub is the source of truth for every other claim before MERGE; the clean review itself is the one fact still taken from state alone.
Proposed direction
Before READY_FOR_MERGE accepts and before MERGE writes, re-read last_review_comment_url through the GitHub client and require: the comment exists on the reviewed PR (same_target), its ai-review-result marker names review_round and reviewed_head_sha, and needs_fix_round is false. Mismatch → BLOCKED (conclusive), a transient read failure → the bounded inconclusive path already used by the gate. Reuse the marker parsing in claims.py / _verify_review_comment; dry-run stays read-only.
Acceptance
- A state parked in READY_FOR_MERGE whose review comment is missing, is on another PR, names another round/HEAD, or says
needs_fix_round: true→BLOCKED, nomerge_prcall. - The happy path performs exactly one extra comment read per gate pass.
docs/agent-guides/github-safety.md"Before MERGE" gains the bullet.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with claims.py and _verify_review_comment, then trace the READY_FOR_MERGE and MERGE gate paths described in the issue. Check the existing bounded inconclusive handling and dry-run behavior before adding the extra comment read. Done means the listed mismatches block without merge_pr, transient failures use the existing path, the happy path reads once, and docs/agent-guides/github-safety.md includes the new Before MERGE bullet.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github, python
- Domain
- api, backend, documentation, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 58/100