code-review: suggested Spec brief improvement after a false 5xx retry clearance

### Skill code-review ### What went wrong The Spec review marked a 5xx retry criterion as verified. But the 529 test hand-built an `InternalServerError` carrying a 529 response, while the SDK actually produces `OverloadedError`. The code did not retry that exception. Test and code shared the same wrong assumption, so the harness passed (308/0). Criterion 4 required: > "a 429, a 5xx, a connection error and a timeout are retried under the existing loop" The builder's committed closeout records the Spec review as: > "Verified by the axis: criteria 1–5, 7, 8 against production code and the harness" That includes criterion 4. The predicate's docstring also called 529 an `InternalServerError`. This quotation comes from the builder's closeout, not a recovered original subagent transcript. My separate `/verify` step constructed errors through the SDK's own mapping and reproduced the failure through both batch callers. Adding `OverloadedError` to the predicate and correcting the tests resolved it; the harness then passed 374/0. Caught before merge. The previous polling loops retried all errors, so this was a regression: a sustained overload could have stopped an unattended batch and required manual resume. **Context:** Claude Code, version unknown; repository-local mattpocock/skills installed through skills.sh, exact upstream revision unconfirmed. Builder: Fable 5.1, reviewers: Opus, verifier: Opus 5. **Local modifications:** `/implement`, `/tdd` and code-review's Standards source had additional boundary-testing instructions. Those additions did not change the Spec brief. ### Proposed change Add to the Spec brief: > When marking a criterion verified, identify the supporting check; where its result depends on a stand-in for dependency behaviour, check that assumption against the dependency's contract or qualify the verification claim. Checking dependency behaviour adds work. I suggest limiting this to assumptions that determine whether a criterion holds, rather than auditing every mock. This is one case; I can't say how often it occurs. This supplies a concrete wrong review result of the kind requested in [#582's closing comment](https://github.com/mattpocock/skills/issues/582#issuecomment-6016323180).