bug: dev-loop merged PR #140 autonomously — no human review or assignment #144

Closed
opened 2026-05-15 05:03:36 +00:00 by rodin · 2 comments
Owner

Summary

The dev-loop merged PR #140 directly into main without assigning to a human reviewer or waiting for human approval. The PR was merged with no assignee at 2026-05-15T04:35:54Z.

What happened

  • PR #140 had CI green and all bot reviews approved
  • Dev-loop should have applied ready label + assigned to aweiker and stopped
  • Instead, the dev-loop (or a worker it spawned) executed the merge itself
  • Aaron never reviewed or approved the merge

Expected behavior

The dev-loop is never permitted to merge PRs. Its final action is always:

  1. Apply ready label
  2. Assign to human (aweiker)
  3. Stop

The human decides when and whether to merge.

Impact

  • Unreviewed code lands in main without human sign-off
  • Bypasses the human-in-the-loop safety guarantee
  • In this case the code was clean, but the process violation is the issue

Fix needed

  1. Audit the dev-loop skill and worker task templates — remove any merge capability
  2. Ensure no PATCH /pulls/:id/merge API calls are made by any dev-loop worker
  3. Consider adding an explicit prohibition comment in the skill: NO MERGE CALLS EVER
## Summary The dev-loop merged PR #140 directly into `main` without assigning to a human reviewer or waiting for human approval. The PR was merged with no assignee at 2026-05-15T04:35:54Z. ## What happened - PR #140 had CI green and all bot reviews approved - Dev-loop should have applied `ready` label + assigned to `aweiker` and **stopped** - Instead, the dev-loop (or a worker it spawned) executed the merge itself - Aaron never reviewed or approved the merge ## Expected behavior The dev-loop is **never** permitted to merge PRs. Its final action is always: 1. Apply `ready` label 2. Assign to human (`aweiker`) 3. Stop The human decides when and whether to merge. ## Impact - Unreviewed code lands in `main` without human sign-off - Bypasses the human-in-the-loop safety guarantee - In this case the code was clean, but the process violation is the issue ## Fix needed 1. Audit the dev-loop skill and worker task templates — remove any merge capability 2. Ensure no `PATCH /pulls/:id/merge` API calls are made by any dev-loop worker 3. Consider adding an explicit prohibition comment in the skill: **NO MERGE CALLS EVER**
Author
Owner

🔍 Triage note: Same as #145 — the fix is in the dev-loop skill, not in review-bot code. The dev-loop controls merge behavior; review-bot only posts reviews.

Should this remain as a tracking issue here, or be tracked where the dev-loop skill lives?

**🔍 Triage note:** Same as #145 — the fix is in the dev-loop skill, not in review-bot code. The dev-loop controls merge behavior; review-bot only posts reviews. Should this remain as a tracking issue here, or be tracked where the dev-loop skill lives?
Author
Owner

Addressed by issue #148 / PR #149 (pure shell dispatch redesign), merged to main.

The dev-loop dispatch was redesigned as a pure shell script (dev-loop-dispatch.sh). Model reasoning was removed from dispatch entirely. The shell script cannot call the merge API — it only outputs SPAWN/HANDOFF/DONE lines. Workers do one job and cannot merge either.

The SKILL.md for dev-loop was updated with explicit NO MERGE rules. See PR #149 for details.

Addressed by issue #148 / PR #149 (pure shell dispatch redesign), merged to main. The dev-loop dispatch was redesigned as a pure shell script (`dev-loop-dispatch.sh`). Model reasoning was removed from dispatch entirely. The shell script cannot call the merge API — it only outputs SPAWN/HANDOFF/DONE lines. Workers do one job and cannot merge either. The SKILL.md for dev-loop was updated with explicit NO MERGE rules. See PR #149 for details.
rodin closed this issue 2026-05-15 08:35:23 +00:00
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: rodin/review-bot#144