Cloudflare's Issues for Workers needs a triage step before errors reach a coding agent

The dev.to post describes Issues as grouping three inputs: recurring exceptions, server errors and error logs ^[2]. A failure reaches the agent only if the Worker reports it through one of those. So the first triage decision is made in code, before any agent runs. A Worker that throws when a slot is already taken, or logs the refusal at error level, puts a working rule in the same queue as a broken one. The agent then receives the grouped error plus the Worker version that produced it ^[3]. In the post's example, "Booking failed" could mean a defect, a sold-out appointment or a temporary connection problem, and each needs a different remedy ^[5].

The post's author says they would classify the incident before asking for a patch, because otherwise a request to make the error go away can quietly turn into removing the rule that protected the app ^[6]. An AI can produce a convincing code change for a correct refusal, an outside outage or an unpromised feature, the author notes, and none of them necessarily needs one ^[7].

Every worked case comes from a booking app the author calls hypothetical ^[8]. When two customers reserve the same slot and one sees a confusing error, the reservation rule may be working. Removing it would buy a friendlier screen and a real scheduling problem ^[9]. The post sends the repair to the recovery path instead: explain that the slot is gone, offer alternatives, keep the customer's other choices, then retest the two-customer case to confirm the rule still holds ^[9].

Outages fail worse. If the confirmation email provider is down, no patch to booking code makes it healthy ^[10]. An eager rewrite might even create a second booking while trying to resend the email ^[10]. Here the author would show the saved booking in the app, report email delivery status separately, and treat any retry investigation as its own question ^[11].

Limits sit in between. An import that works for ten appointments and fails for ten thousand might be a defect, or it might be hitting an explicit file-size, processing-time or service limit ^[12]. The post warns against asking the AI to disable a limit just because it interrupted a test ^[12]. Choosing a smaller batch or a background process is a product decision ^[12].

Just one of the five cases goes straight to a narrow code repair ^[16]. There the app says "Confirmed," but the booking is missing on refresh, and the failure repeats with a disposable test account ^[13]. The author's brief to the agent is a repeatable example plus a test that fails before the repair and passes after, scoped as "Repair booking persistence" ^[13]. A customer asking for several locations and recurring group classes goes to the backlog ^[14].

This sorting carries over to a production Worker when someone has written down the expected behavior, the observed behavior and which part of the promise broke ^[15]. Cloudflare's described workflow puts the owner's review between the agent's proposal and the deploy ^[4]. That reviewer needs the written promise to reject a patch that deletes a refusal. The post does not describe what the agent is allowed to change. In my view the cheapest triage step is in the Worker itself. A taken slot returned as an expected response and logged below error level is not an exception, a server error or an error log, so it has no route into the feed as the post describes it ^[2].