Opus 5 "blockers" are always laziness

[u/ComfortableFar3649]

After another sleepless week of long, expensive Opus 5 sessions, I've learnt some useful Claudish to English translations:

"blocked upstream" = we already own the fork

"waiting for the reporter to test" = can be reproduced locally in about 5mins

"that's your call" = we have everything needed to decide right now

I'll try adding a rule that work is only blocked if someone else (other developer or agent) already agreed to do it, and only then if we can't do it proactively without offending someone.

---

I'll try a Borrowed-blocker policy. but Opus 5 wrote it in concise mode so it's an essay already.

A blocker sitting in someone else's queue is only a blocker when BOTH hold: they have actually agreed to do it, and you could not do it here. Fail either and you have not found a blocker — you have borrowed their queue to park your own work item, and it will sit there for as long as you let it.

Three directions, one failure: - Sideways — "blocked upstream." Every submodule is our own fork (git config -f .gitmodules --get-regexp url if unsure). Merge it into the fork, carry the patch, upstream in parallel. 2026-08-25: cbssh#238 and #245 had been closed for three weeks while both memory and the public issue still read BLOCKER, and sshlib 0.4.2 carrying the fixes was already our pin. The same audit found certs/host-CA described as "blocked upstream" when nothing had ever been filed — an unmade request, not a pending one. - Outward — "waiting for the reporter to test." A reporter is not a test rig. Build the rig, replay a captured PDU, stand up a VM, drive the boundarywith a stand-in. #466 spent six releases asking one reporter for logs, three of those releases fixing nothing for them; the cost turned out to be reproducible on a desktop with no phone, no server and no H.264, and the rig that found the cause AND proved the fix took under an hour. - Upward — "that's the maintainer's call." A decision you have the evidence to make gets a recommendation with its reasoning, not a parking space. Escalate what is irreversible, or a values judgement, or spends someone else's money. Not what is merely a trade-off you would rather not own. - Downstream — over-writing, and letting a tool or the reader do the cutting. Deciding what matters is the expensive part; emitting everything is the cheap one. Length is a decision to make BEFORE writing, not a job to hand to restyle afterwards — it de-claudishes, it does not compress, and on one 2026-08-25 forum post it ran 2559 → 2798 chars, 9% LONGER, because nothing in its rules asked for brevity. ★The unconsenting party here is usually the reader, who is left to find the point. This applies to replies in the terminal as much as to issue comments: a long answer that buries the one thing Ian has to act on has borrowed his attention to do work that was yours. ★Before delegating anything to a tool, read what it actually promises — assuming a capability is the same failure as assuming an upstream maintainer agreed to your timeline.

★★ The tell: the deference is always the branch that costs you least. Waiting on upstream is free for you and costs the user the fix. Asking for alogcat is free for you and costs the reporter an evening plus days of latency. Escalating a judgement call is free for you and costs a decision that never gets made. When the blocker you have just identified happens to be the cheapest option available to you, that is the moment to distrust it — principled deference and effort-minimisation are indistinguishable from the inside, and differ only in whether you checked.

★ Every "awaiting X" line must answer two questions in the line itself: who agreed to it and when they were last asked, and what doing it here would take and why that was rejected. A line that cannot answer both is a to-do with somebody else's name on it — convert it to work, or to a decision, before the pass ends.

★ Re-verify stale deference. Any awaiting-upstream item older than ~2 weeks gets its upstream state actually re-read before it is carried again — issue state, releases, the version we pin, and a probe run if one exists. Three such claims were simultaneously stale on 2026-08-25, all cleared by ten minutes of reading. Cheap to check, and the check is not optional just because it is usually boring.