prompt: the phase-2 arms collide — the clipper is not in the search identifier

[Jammy2211]

A campaign-invalidating trap that the phase-2 handover was missing. Urgent, because the campaign is about to be handed to a GPU session.

The trap

The clipper does not enter the search identifier. Verified empirically against PyAutoFit main:

af.MultiStartAdam(name="x")                             -> 2bada4747f74bc46bf812605a762def9
af.MultiStartAdam(name="x", clipper=ClipperNone())      -> 2bada4747f74bc46bf812605a762def9
af.MultiStartAdam(name="x", clipper=ClipperPriorBox())  -> 2bada4747f74bc46bf812605a762def9

All three resolve to the same output directory. Arms 1 and 2 of the validation campaign differ in nothing else, so they collide. Stacked with the .completed short-circuit (is_complete → result_via_completed_fit, which skips the search entirely), arm 2 can silently return arm 1's numbers and look like a clean run — invalidating the campaign's central comparison while producing output that looks perfect.

This is not a bug in itself: it is what keeps existing runs' output directories stable across the phase-1 change. It is just precisely wrong for a campaign whose arms differ only in the clipper.

Mitigation written into the prompt

1. Unique name per arm — do not rely on the clipper to separate them, because it does not.
2. Delete output/<name>/ between arms anyway.
3. Assert the recorded step count equals n_steps. A short-circuited run reports the previous run's numbers rather than zeros, so a zero-check alone does not catch this.

Also sharpens the clip-count validity check: an arm showing no clipping lines at all is the signature of this collision, since arm 1's summary carries no Clipper line.

Credit and provenance

This was first identified by #189, a parallel session's phase-1 ship PR that is still open. I re-verified it against main rather than relaying the claim, and the identifier hash above is from that check.

#189 overlaps my #190 — both wrote a phase-1 completion record, under different slugs (autofit-prior-support-clipper.md there, prior-support-clipper.md here). I did not check for open PRs before starting, which is how the duplication happened. #189 is now behind main and would conflict. It also carries content that has not landed anywhere — the LBFGS optimize process lesson, several harness traps, and two follow-ups (declaring LogGaussianPrior's (0, ∞) support on the prior itself, and whether the clipper belongs in the identifier). That needs a human decision, so I have left #189 alone.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FzF2XmKQaqZRWZfZMxvTNR

---

Generated by Claude Code