Found while fixing #9876. The latch fix there is correct and unfreezes the affected PRs — but it exposes what the freeze was accidentally hiding.
The situation
JSONbored/awesome-claude has screenshotTableGate.action: close and review.visual.enabled: true with production_url: https://heyclau.de. The BEFORE shot works. The AFTER shot needs a preview deployment of the PR head — and this repo produces none:
GET /repos/JSONbored/awesome-claude/deployments?sha=<head> → 0
- the
validate-pr-preview check reports skipping on every PR
So visualCaptureSatisfiedSha can never be set for any PR in this repo. The bot exhausts its preview-poll budget (5 x 90s — the six deferral audit events per PR seen live), the durable budget then suppresses previewPending, and the capture concludes with nothing.
The gate’s CLOSE therefore rests on evidence that is structurally unobtainable for the repo, not merely missing. Every contributor PR touching apps/web/src/{components,routes}/** without a hand-authored screenshot table is closed one-shot, and no contributor action other than hand-authoring the table can ever change that.
Until #9876 the latch froze those PRs instead, which masked the outcome.
Why this is a product gap, not just a config mistake
Nothing tells the maintainer that the enforcement they configured cannot be satisfied by the mechanism they enabled. review.visual.enabled: true plus action: close reads like "the bot will capture evidence, and close if there is none" — but on a repo with no preview deploys the first half silently never happens.
Suggested direction
- Detect the condition: a repo where the preview-poll budget is exhausted with no discoverable deployment, repeatedly, is not producing captures. That is observable from data already recorded.
- Do not let a CLOSE rest on it. Degrade to advisory for that repo and say why, rather than closing PRs for evidence the pipeline could never generate.
- Surface it to the maintainer (ops anomaly / readiness check): "visual capture is enabled for this repo but has not produced a successful capture in N PRs — the screenshot-table gate is closing PRs on evidence it cannot obtain."
Note on the action enum
ScreenshotTableGateAction is "close" | "advisory" only. There is no middle setting — no way to say "hold and ask for screenshots, but do not destroy the PR". A block-style tier is worth considering: for a one-shot contributor pipeline, close and no-op are both wrong answers when evidence is merely absent.
Found while fixing #9876. The latch fix there is correct and unfreezes the affected PRs — but it exposes what the freeze was accidentally hiding.
The situation
JSONbored/awesome-claudehasscreenshotTableGate.action: closeandreview.visual.enabled: truewithproduction_url: https://heyclau.de. The BEFORE shot works. The AFTER shot needs a preview deployment of the PR head — and this repo produces none:GET /repos/JSONbored/awesome-claude/deployments?sha=<head>→0validate-pr-previewcheck reportsskippingon every PRSo
visualCaptureSatisfiedShacan never be set for any PR in this repo. The bot exhausts its preview-poll budget (5 x 90s — the six deferral audit events per PR seen live), the durable budget then suppressespreviewPending, and the capture concludes with nothing.The gate’s CLOSE therefore rests on evidence that is structurally unobtainable for the repo, not merely missing. Every contributor PR touching
apps/web/src/{components,routes}/**without a hand-authored screenshot table is closed one-shot, and no contributor action other than hand-authoring the table can ever change that.Until #9876 the latch froze those PRs instead, which masked the outcome.
Why this is a product gap, not just a config mistake
Nothing tells the maintainer that the enforcement they configured cannot be satisfied by the mechanism they enabled.
review.visual.enabled: trueplusaction: closereads like "the bot will capture evidence, and close if there is none" — but on a repo with no preview deploys the first half silently never happens.Suggested direction
Note on the action enum
ScreenshotTableGateActionis"close" | "advisory"only. There is no middle setting — no way to say "hold and ask for screenshots, but do not destroy the PR". Ablock-style tier is worth considering: for a one-shot contributor pipeline, close and no-op are both wrong answers when evidence is merely absent.