feat(bin): add bounded PR delivery loop - #2631
Conversation
b84868b to
7b1f35f
Compare
ed38fe8 to
be75174
Compare
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains. Reviews (3): Last reviewed commit: "no-mistakes: apply CI fixes" | Re-trigger Greptile |
Discover and classify open PRs for merge-capable projects on the watcher poll cadence and at locked session start, maintain a reason-coded blocked queue, and queue check: pr-delivery wakes for merge-eligible or post-merge obligations without relying on secondmate handoffs. Co-authored-by: Cursor <cursoragent@cursor.com>
1559c20 to
2e51ee2
Compare
|
Speaking as Kun's firstmate: VISION: mixed. Bounded PR delivery discovery is real command-layer work, but the scan is wired into the watcher and locked session-start with Class: default-behavior. Watcher/session-start always run the delivery scan. Not a captain-flag this pass because it is not fully green. Security: none after review. Main-home only; secondmate homes refuse. Merge is not executed by the scan; skill handling still requires configured authority via Overlap: CI: HEAD Workflows approved: yes (CI 32579112463, NM 32579112537). Not land-eligible. Waiting on CI, not the captain. Flag captain ONLY if later fully green (default-on scan). |
|
Closing per captain decision: Firstmate-repo development is paused, focus is on RecruitMagic only. |
Intent
Push PR delivery loop via fork; five captain fixes only; defer secondmate/post-merge orchestration
What Changed
check: pr-deliverywake for eligible PRs.Risk Assessment
✅ Low: The change is bounded and the reviewed durable-fix paths correctly guard merge heads, delivery-state symlinks, closed-PR state, and ambiguous task bindings.
Testing
Inspected the target change from a clean worktree, ran the focused delivery-discovery and guarded-merge suites, and exercised the public delivery CLI in an isolated fake-forge home; it emitted the merge-eligible wake and left no eligible PR in the blocked queue.
Evidence: End-to-end PR delivery CLI transcript: eligible PR wake and empty blocked queue
Evidence: Reproducible isolated CLI evidence harness
Source: Reproducible isolated CLI evidence harness
Pipeline
Updates from git push no-mistakes
✅ **intent** - passed
✅ No issues found.
✅ **Rebase** - passed
✅ No issues found.
🔧 **Review** - 1 issue found → auto-fixed (3) ✅
bin/fm-pr-merge.sh:100---expected-headis checked before the merge but is not passed to the forge. A contributor can push a new head afterfm-pr-check.shrecords the expected OID and before this command runs, causing the delivery path to merge that unreviewed new head. Enforce the OID at the final merge boundary (GitHub CLI’s--match-head-commit; extend the approvedgh-axiwrapper to forward it if necessary).🔧 Fix: Enforce PR heads at GitHub merge boundary
2 errors still open:
bin/fm-pr-delivery.sh:137-ensure_dirsfollows a pre-existingstate/pr-deliverysymlink while creating its child directories, then checks whether the parent is a symlink only afterward. A malicious/stale symlink can therefore causescanoraccelerateto create and later modify delivery state outside the home. Validate/create each delivery-state directory without following symlinks before traversing it..agents/skills/pr-delivery/SKILL.md:38- The intent says “defer secondmate/post-merge orchestration,” but this new runtime skill directs a successful merge to runfm-fleet-sync.sh. Confirm whether this post-merge action is intentionally in scope; otherwise remove/defer it.🔧 Fix: Reject symlinked PR delivery state directories
2 errors still open:
bin/fm-pr-delivery.sh:720- A successful open-PR inventory never retires state for PRs absent from that inventory. After an eligible PR is closed (or merged), its delivered fingerprint and blocked-queue row remain; if it is later reopened unchanged,new_fp == marker_fpsuppresses the new merge wake indefinitely. On completion of a full repository inventory, retire queue/fingerprint/delivered/accelerate state for absent PRs (while preserving it on partial/deadline scans).bin/fm-pr-delivery.sh:249- Multiple same-project task metadata files may record the same PR URL, but this returns the first glob-ordered task. A staleyolo=ontask can therefore win over the actual task’s hold/approval state and authorize a merge under the wrong task. Treat more than one matching task as an ambiguous hold rather than selecting one.🔧 Fix: Retire closed PR state and hold ambiguity
✅ Re-checked - no issues remain.
✅ **Test** - passed
✅ No issues found.
rtk git status --shortand target-diff inspectionrtk tests/fm-pr-delivery.test.shrtk tests/fm-pr-merge.test.shrtk bash /Users/byronhsu/.no-mistakes/evidence/01M0EM5A27AF4GYWTW09JQDPBH/pr_delivery_e2e.sh /Users/byronhsu/.no-mistakes/worktrees/497bd902d278/01M0EM5A27AF4GYWTW09JQDPBH✅ **Document** - passed
✅ No issues found.
🔧 **Lint** - 1 issue found → auto-fixed ✅
🔧 Fix: Fix ShellCheck issues in PR delivery loop
✅ Re-checked - no issues remain.
✅ **Push** - passed
✅ No issues found.