Issue 350: the report's heading names its own number

04-ISSUES/350-an-agent-waits-for-a-check-by-polling/00-report.md

@@ -0,0 +1,35 @@
+---
+status: open
+opened: 2026-10-09
+located-in: []
+fixed-by:
+amended-design:
+---
+
+# 350. An agent waits for a check by polling
+
+## Symptom
+
+On 2026-10-09 the agents working on the mesh spent about 3.5 of 23 agent-hours in waiting loops: after a push
+they asked the delivery service again and again whether the merge check had answered. A check takes five to ten
+minutes, part of it waiting for a free build agent, so an agent either asks every few seconds or sleeps and
+answers late. Both cost time, and the asking adds load on the controller and the bus.
+
+Measured from the agents' own records that day: of about 8.3 hours spent in tools, 3.5 hours were waits and
+polls, 1.6 hours local runs of `merge-check.sh` and 1.4 hours local test suites. The mesh's own tools answered
+fast: 232 reads of a check's verdict took 3 minutes in total.
+
+## Why it is an issue
+
+The mesh already says what happens as it happens: a build announces itself on the bus (ADR 0157), and a
+delivery moves through states the delivery service keeps. Nothing lets a caller ask once and be answered when
+the verdict exists. So every caller builds its own loop, each with its own interval and its own idea of when
+to give up, and an agent that gives up early reports a check as missing when it is only queued.
+
+## What would close it
+
+A verb of the delivery service that waits: given a repository and a pull request, or a commit, it answers when
+both required checks have a verdict, or when a bound the caller gives runs out, saying which. It answers from
+the delivery's own state changes rather than by polling the forge, and a caller that times out is told where
+the check stands (queued, building, judging). Checked by a test that asks before the check exists, sees no
+answer until the verdict is set, and then receives it once.