Validate the Benchmark Before Trusting the Score: Spec Gaps, Verifier Gaps and Presentation Hardening in an Evidence-Driven API Migration Task

I present a Terminal-Bench style task in which a coding agent must finish a TypeScript port of a request signer by recovering the final signing scheme from about 75k tokens of migration documents. Five of the seven rules the agent needs were reversed in meeting notes after being recorded in a decision register that reads like a specification, and two exist only in syscall captures of the system being replaced. The task is graded byte-exact against hidden request sets re-run from the agent's own code in a separate container. Before trusting any model result I validated the grader: mutation testing with 23 single-fault variants of the reference solution, a red-team pass in which every claimed gap had to be proved by running code over the graded sets, and a per-attempt diagnosis that reads which form of each rule an attempt implemented and whether its trajectory ever showed the text that settles it. The validation found two grading errors that would otherwise have been reported as model behaviour. The first version of the instruction scored Claude Opus 5.5 at 0 of 3 while every signing rule in its code was correct, because two rules of the output contract were never stated. The corrected task then awarded a full score to a Claude Haiku 4.5 attempt that verified any Authorization header whose signature matched, whatever key the header named, because no hidden record exercised that sentence; a third hidden set now grades the contract sentence by sentence, and every stored attempt was re-graded. On the validated task, a presentation-hardened variant that removes every announcement of a changed rule, adds rules that changed twice and proposals that were declined, and plants a decoy scheme in the same notes, did not change the outcome for Opus 5.5 or Claude Sonnet 5.5, which solved both variants in every attempt by collapsing the generated filler with a few commands. It did change what Haiku 4.5 does with text it has already read: on the base documents Haiku applied every deciding passage it retrieved (31 of 31 rule instances); on the hard documents it applied 18 of 28; one paragraph in the instruction pointing at the notes brought that to 13 of 16. The contribution is a task whose grader has been checked against itself, and tooling that turns a pass or a fail into a statement about which rule was wrong, what the agent read, and whether it applied what it read.