fix: three false positives found by re-triaging warnings and notes

[HimanshuJanbandhu]

Read all 283 findings across the seven repos — individually, and at every severity, not just errors. The errors had already been re-read three times across this work. TG007 had never been looked at since it shipped, because it never produces an error. It was the worst rule in the set.

TG007 was 6/6 false, and every finding was the rule reporting its own advice

correct += (predicted == labels).sum().item()

That is verbatim what TG007's hint tells you to write: "Do the reduction on the device and sync once — (preds == targets).sum().item()." All six findings were this shape, in a validation loop nested inside a training loop.

The rule already had a batch-loop exemption — but it matched iterable names (loader, dataloader, batches), so it missed dev_iter and valloader.

Lengthening that list would have patched the instance. Instead the rule now requires evidence of per-element iteration: a loop over range(...) indexes elements, a loop over anything else yields batches whatever it happens to be called. That is also the shape the rule's own docstring uses to explain itself.

TG002 reported a .backward() nine lines above the call

fgsm_tutorial.py's test() was reported as "runs a forward pass with autograd enabled but never calls .backward()". It calls it on line 292 — an adversarial attack iterates test_loader and backwards through it deliberately, to get gradients with respect to the input.

The carve-out at fault exists for functions that both train and validate, where a backward elsewhere shouldn't excuse the validation loop. It just has to check the backward isn't in this loop.

TG001's bare-name return rule was too blunt

From #43: a returned bare name is not evidence of a deferred backward. Correct for return losses, where the container itself is handed back. Wrong here:

logps = torch.cat(all_logps, dim=0)
return logps, entropies, aux_loss      # not the container -- a reduction of it

Returning that hands the caller a graph the GRPO objective backwards. A returned bare name now counts unless it is itself a holder — which can't be decided until every holder has been seen, so it resolves at leave_Module. Six findings across trl and torchtune.

Result

	errors	warnings	notes
before	21	55	207
after	13	49	207

14 removed, zero new findings.

What came out clean

• TG004 is accurate. A sample of the 207 notes were all genuine DataLoader calls missing num_workers or pin_memory. The problem was only volume and actionability, which making it a note under RFC 0003 already solved. No rule bug.
• TG003 ×3 are true, and already fixed upstream in pytorch/examples#1424.
• The 8 torchtune running_loss += current_loss warnings are true, at the right severity since the severity split.

Left open, recorded in the TODO

• TG013 (10) is the one rule not carried to a verdict — mixed shapes, needs individual reads.
• TG008 (31) deserves a decision rather than a fix: factually right, but mostly synthetic-data examples where seeding changes nothing observable. Same profile that moved TG004 to note, so it should face the same test — is this code defective, or merely untuned?
• Two false-positive causes remain, both surfacing in TG002: non-model callables read as forward passes (tokenizer(...), feature_extractor(...)), and deliberate gradient use for attribution.

Testing

443 tests, 3 new — one per fix, each reduced from the file that exposed it.