Skip to content

sweep: post a per-head verdict on clean convergence; list past gh's 30-PR cap#39

Merged
Octember merged 1 commit into
mainfrom
fix/per-head-verdict-and-list-limit
Jul 1, 2026
Merged

sweep: post a per-head verdict on clean convergence; list past gh's 30-PR cap#39
Octember merged 1 commit into
mainfrom
fix/per-head-verdict-and-list-limit

Conversation

@Octember

@Octember Octember commented Jul 1, 2026

Copy link
Copy Markdown
Owner

The flake, root-caused

On 6 of 33 bunion ready-pit tickets the factory shipped with STUPIFY_FLAKED: the final commit of the PR never got a stupify review, while every earlier commit was reviewed within minutes of push. The sweep on stupify-bevyl-ai-bevyl-ai was in fact reviewing every final head promptly — and then deliberately posting nothing:

2026-06-30T14:47:04Z reviewing PR #6644 @ 6c5f4378   (head pushed 14:46:22)
2026-06-30T14:49:21Z   #6644 nothing new — staying silent
2026-06-30T17:20:19Z reviewing PR #6600 @ b48ff4ab   (head pushed 17:15:03)
2026-06-30T17:22:07Z   #6600 fixed-signal but no open threads — staying silent
2026-06-30T17:23:56Z reviewing PR #6596 @ 4d0c0096   (head pushed 17:04:50)
2026-06-30T17:28:33Z   #6596 fixed-signal but no open threads — staying silent
2026-06-30T17:36:26Z reviewing PR #6598 @ e2049222   (head pushed 17:22:57)
2026-06-30T17:38:12Z   #6598 nothing new — staying silent

Silence leaves no <!-- stupify:<sha> --> marker covering the new head. On GitHub the last review keeps pointing at an old commit, so anything that asks "does a stupify review cover HEAD?" — bunion's wait tool, or any per-head merge gate — reads "never reviewed", times out, and treats the reviewer as flaked. It also breaks the header's own stated invariant (durable per-head dedup via the marker): the silent paths lean entirely on local reviewed.json, which dies with the VM.

Fix: when nothing is outstanding (no open stupify threads), post a one-line marker-bearing still ✅ instead of staying silent — one short note per pushed head, still converged. Silence remains only while stupify's own findings are open (a fresh non-✅ note there would fight a reasoned inline pushback), and a stray fixed-signal on a never-flagged PR still posts nothing.

Second defect: gh's default --limit 30

listPrs ran gh pr list with no --limit, which defaults to 30, newest-first. bevyl-ai/bevyl.ai has 129 open PRs; everything past the newest 30 fell off the sweep's radar entirely — PR #6559 (list position 57) took fresh pushes for two days with zero sweep log lines, not even a skip. Fixed with an explicit --limit 500.

Third: upstream the bevyl VM's hand-patch

The deployed ~/.stupify/review-sweep.ts on stupify-bevyl-ai-bevyl-ai is hand-patched to review bot-authored PRs carrying the bunion label (the factory authors PRs as a GitHub App). Redeploying stock code would silently drop ALL factory PRs from scope. This PR generalizes the existing force-include: REVIEW_LABEL now also overrides the bot-author exclusion, so that deployment just sets REVIEW_LABEL=bunion in config.env and runs stock code.

Verification

  • bun run typecheck clean, bun test 44/44 pass (added a test pinning the convergence note's ✅/marker contract).
  • After deploy, bunion's wait tool sees still ✅ + marker covering head → PASS instead of STUPIFY_FLAKED on converged-clean pushes (its parseReview requires exactly: stupify login, stupify:<sha> covering the latest code commit, in the body).

Deploy note: the fix only takes effect once re-deployed to ~/.stupify/review-sweep.ts on stupify-bevyl-ai-bevyl-ai / stupify-octember-stupify, with REVIEW_LABEL=bunion added to the bevyl config.env (replacing the hand-patch).

🤖 Generated with Claude Code

…0-PR cap

Root-causes the bunion factory's STUPIFY_FLAKED shipments (6 of 33 tickets
shipped without a review on the final commit):

1. Silent convergence left the newest head unreviewed-looking. When a PR
   stupify had already reviewed got a new push and codex found nothing new
   (NOOP token), or emitted the fixed-signal with no threads left to resolve,
   the sweep posted NOTHING — so no `<!-- stupify:<sha> -->` marker ever
   covered the new head. Per-head consumers (the factory's `wait` tool, any
   "does a review cover HEAD?" merge gate) read that as "never reviewed" and
   timed out. Evidence from stupify-bevyl-ai-bevyl-ai sweep.log:
     #6644 @ 6c5f4378 "nothing new — staying silent"        (head, never covered)
     #6600 @ b48ff4ab "fixed-signal but no open threads — staying silent"
     #6596 @ 4d0c0096 "fixed-signal but no open threads — staying silent"
     #6598 @ e2049222 "nothing new — staying silent"
   Fix: when nothing is outstanding (no open stupify threads), post a
   one-line marker-bearing `still ✅` instead of silence. Silence remains
   only while stupify's own findings are open (posting a non-✅ note there
   would fight a reasoned inline pushback). A stray fixed-signal on a
   never-flagged PR still posts nothing, so it can't manufacture approval.
   This also restores the header's stated invariant — durable per-head dedup
   via the marker — instead of leaning on local reviewed.json (lost on VM
   recreation).

2. gh pr list defaults to --limit 30, newest-first. With 129 open PRs on
   bevyl-ai/bevyl.ai, every PR past the newest 30 fell off the sweep's radar
   entirely — PR #6559 (list position 57) got fresh pushes for two days with
   zero sweep log lines. Fix: explicit --limit 500.

3. Upstream the hand-patch running on the bevyl VM: REVIEW_LABEL now also
   force-includes bot-authored PRs (the factory authors PRs as a GitHub App;
   stock code would silently drop ALL its PRs from scope on redeploy). Set
   REVIEW_LABEL=bunion in that deployment's config.env.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@Octember Octember merged commit 4b09012 into main Jul 1, 2026
2 checks passed
@Octember Octember deleted the fix/per-head-verdict-and-list-limit branch July 1, 2026 22:35

@exe-dev-github-integration exe-dev-github-integration Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM ✅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant