prompt: hand the Clipper phase-2 campaign over to a GPU session - #191
Merged
Conversation
The cloud session did everything this campaign needs except run it. Adds a SESSION HANDOVER block to the campaign prompt itself rather than a separate handover doc, so the context travels with the file a GPU session will actually open -- the same property #188 was merged to preserve. What it carries: - The three PyAutoFit changes that landed AFTER phase 1 (#1478 clip count in search.summary, #1479 NumpyEncoder, #1480 atomic writes), and the fact that all four are UNRELEASED. The task must run against a checkout at or after b6e89cd with autofit.__file__ verified, never a PyPI wheel. - Which of this prompt's traps are now fixed rather than live -- and why the mitigations stay anyway: the step-count assertion catches every no-op cause, not only the float32 one. - That the clip count is now a VALIDITY CHECK, not a statistic. A ClipperPriorBox arm reporting zero clips has not exercised the clipper and its "no change" result is meaningless -- a broken arm, not a null result. - A seconds-long smoke test discovered while verifying #1478: the #128 mechanism reproduces on a toy 3-parameter Gaussian (378 value-NaN lane-steps unclipped, 0 clipped, 414 clips at rate 0.958). Cheap way to confirm the clipper is wired up and firing before spending GPU time on imaging/mge. - The mge-lane-death GPU/float64/multi-seed confirmation and the owed hazard-index entry, which want the same session and share these arms. - Sequencing: this campaign, then ell_comps_trapping_unmasked.md on the same arms, which must not re-derive 27.79% from the prior-neutered arm. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01FzF2XmKQaqZRWZfZMxvTNR
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A cloud CPU session did everything the phase-2 campaign needs except run it. This carries the handover.
Written into the campaign prompt itself, not a separate handover doc — so the context travels with the file a GPU session will actually open. That is the same property #188 was merged to preserve, and a handover note nobody opens is worth nothing.
What it carries
The three PyAutoFit changes that landed after phase 1, each clearing a trap this prompt used to work around:
1f4b66aClipperitselfbbceff6n_clipped_lane_steps+n_constrained_lane_stepsnow insearch.summaryb6e89cdNumpyEncoder— the float32save_jsoncrash is fixedAll four are unreleased. The task must run against a PyAutoFit checkout at or after
b6e89cdwithautofit.__file__verified to resolve there — a PyPI wheel has none of it.Which traps are now belt-and-braces rather than live — and why the mitigations stay anyway. The step-count assertion catches every no-op cause, not just the float32 one, so it is not retired along with the bug that motivated it.
The clip count is now a validity check, not a statistic. A
ClipperPriorBoxarm reporting zero clips has not exercised the clipper, and its "no change" result is meaningless — a broken arm, not a null result. That is the cheapest way to catch a mis-wired arm before reading anything into it.A seconds-long smoke test, found while verifying #1478. The autolens_profiling#128 mechanism reproduces on a toy 3-parameter Gaussian — unclipped
Value-NaN Lane-Steps = 378(94.5%), clipped0, withClipped Lane-Steps = 414at rate0.958. Worth running before spending GPU time onimaging/mge, to confirm the clipper is wired up and firing at all.What else wants the same session: the
mge-lane-deathGPU/float64/multi-seed confirmation and the owed hazard-index entry, both of which share these arms.Sequencing: this campaign, then
ell_comps_trapping_unmasked.mdon the same arms — which must taken_constrained_lane_stepsfrom the clipped run and explicitly must not re-derive the 27.79% from the prior-neutered diagnostic arm.Bookkeeping
lifecycle.py checkOK;dashboard.mdregenerated.🤖 Generated with Claude Code
https://claude.ai/code/session_01FzF2XmKQaqZRWZfZMxvTNR
Generated by Claude Code