From 6a052ebc4b0371a4c68deb42742e4aea0dca865d Mon Sep 17 00:00:00 2001 From: Douglas Ezra Morrison Date: Sun, 2 Aug 2026 21:17:52 -0700 Subject: [PATCH] ums: hedge the mechanism to match github.md, and cite its sibling snippet Round 1's two non-blocking observations. The empty pending-list read is observed on two repos; why it comes back empty is not. memories/github.md offers auto-requesting as the likeliest reconciliation and marks it explicitly untested, deliberately, since probing consumes the quota that is usually the real reason Copilot is absent. Asserting the mechanism flatly overstated a cause claim against the corpus's own hedge, so this restates the observation and keeps the hedge -- the operational point holds either way. Also cites github.md's single-ruleset form beside this loop, so the two snippets are visibly siblings. --- shared/workflow/pr-on-claim.md | 16 ++++++++++++++-- 1 file changed, 14 insertions(+), 2 deletions(-) diff --git a/shared/workflow/pr-on-claim.md b/shared/workflow/pr-on-claim.md index 94693eaa4..d8d48211e 100644 --- a/shared/workflow/pr-on-claim.md +++ b/shared/workflow/pr-on-claim.md @@ -71,13 +71,25 @@ A POST response alone is not enough; if the pending request disappears and no cu Do not leave it as "review owed". **That blocked-request test has a false positive, and it is on exactly the repos the section above describes.** -Where a ruleset auto-requests Copilot, the pending request disappears *by design*: the POST returns success naming the reviewer, and `reviewRequests` reads **empty** moments later, because the auto-management consumes it. +Where a ruleset auto-requests Copilot, the POST returns success naming the reviewer and `reviewRequests` reads **empty** moments later. That is the literal signature the test above calls blocked --- request gone, no review yet --- so the two paragraphs contradict each other on any repo with `review_on_push: true`, and the earlier one is the one that is wrong there. +The empty read is observed, on two repos; *why* it comes back empty is not. +[`memories/github.md`](../../memories/github.md) records the same +201-then-empty sequence and offers auto-requesting as the **likeliest +reconciliation, explicitly untested** --- deliberately so, since probing it +consumes the per-user quota that is usually the real reason Copilot is absent. +Keep that hedge: what matters operationally is that an empty pending-list is +uninformative on such a repo, which holds whatever the mechanism turns out to +be. + Reading it as blocked costs more than a wasted call. It routes you to the self-review fallback while a working reviewer is queued, which [`fully-clean`](fully-clean.md) treats as a fallback for when *no* external reviewer is reachable --- so the PR ends up carrying a weaker verdict than it could have. -Settle it by reading the ruleset rather than by polling harder: +Settle it by reading the ruleset rather than by polling harder. +[`memories/github.md`](../../memories/github.md) gives the single-ruleset form; +this loop is the same query when you do not already know the id, so keep the +two in sync if either changes: ```bash for id in $(gh api "repos///rulesets" --jq '.[].id'); do