reviewlisted

# /tml:review — did it work, and what did it cost Adversarial by construction. The default posture is that the change **did not do what it claims**, and the review's job is to find out whether that default survives contact with the diff. ## Hard rules 1. **Read-only.** No edits, no writes, not even to `./.tml/`. Verdicts only. 2. **Three questions, always, in order**: did the mechanism engage, is the measurement still valid, what did it silently break. 3. **"Improved throughput" is not an answer** to any of them. 4. **A verdict without a check behind it is an opinion.** Name the file, the line, the trace, or the number. ## Procedure ### 1. What is claimed, and what would falsify it State the claim in one sentence, then its **radius** (`references/evidence-grades.md` §3.1) read mechanically off the diff, then what observation would show it false. If nothing would, say so — an unfalsifiable claim is the finding. ### 2. Did the mechanism engage The most common failure is a change that is present in the source and inert at runtime: - A flag set after the object it configures was constructed. - A fast path guarded by a condition that never holds — dtype, shape, contiguity, device, or a version check. - A compiled path recompiling every step (count the recompilations; a recompilation per step is worse than no compilation). - A kernel that silently fell back because its workspace did not fit — which is also why an interior batch-size optimum can appear (`tier-b-