prompt: ship autofit-prior-support-clipper (PyAutoFit#1477) - #189
prompt: ship autofit-prior-support-clipper (PyAutoFit#1477)#189Jammy2211 wants to merge 8 commits into
Conversation
…arm collision, new counter, missing momentum reset)
…ofiling#129) with handoff notes
…olens_profiling#129)
…llow-ups filed (#194) Two sessions independently wrote a completion record for the prior-support Clipper. #189 was opened first, by the session that actually shipped PyAutoFit#1477; #190 (mine) landed later because I never listed open PRs before starting. This consolidates them so main holds one record, not two. complete/2026/08/prior-support-clipper.md is now the union. The detailed body comes from #189 and is materially richer than what I wrote: the bound-kind design decision (why one relative margin is wrong in two silent ways), eight traps measured against a running install, the verification log (bit-identity 10/10, core promise 8/8, guards verified by inversion), and the process lesson -- a first commit shipped an undefined `optimize` in LBFGS._fit and the full 1790-test suite passed against it, because nothing in the suite executes an LBFGS fit. My "what shipped after" section is appended, since #189 predates #1478/#1479/#1480 and so records follow-ups 1 and 2 as open when they are now fixed. #189's phase-2 harness traps salvaged into the campaign prompt -- the .completed short-circuit, fit() rebuilding search.paths so instance-level patches are discarded, search_internal being deleted on success, seeding both random AND numpy, and a box containing the optimum never exercising the clipper. Also that arm 3 does not exist yet (phase 1 ships the mask, no reset) and two phase-1 measurements to carry in as priors. Follow-ups 3 and 4 filed as prompts rather than left in a record: loggaussian_prior_declares_own_support.md and clipper_in_search_identifier.md. The second is Autonomy: human-required -- both answers orphan or collide someone's stored results, and it is best decided BEFORE phase 3 so the re-baseline and any re-keying are not entangled. One correction absorbed from #189: test_nautilus single_core_builds_no_pool PASSES in CI and fails only in local venvs (both 3.12 and 3.13, two independent sessions). "Not caused by this work" is right; "pre-existing on clean main" -- the looser phrasing used in #1479 and #1480's bodies -- is wrong. Recorded. Claude-Session: https://claude.ai/code/session_01FzF2XmKQaqZRWZfZMxvTNR Co-authored-by: Claude <noreply@anthropic.com>
|
Closing as consolidated into Two sessions independently wrote a completion record for the prior-support Consolidated by #194 ( Where each piece landed
A "What shipped after this record was first written" section is appended, because this PR predates three further merges and so lists follow-ups 1 and 2 as open when they are now fixed:
The arm-collision hazard was landed separately and urgently in #193, because the campaign was about to be handed to a GPU session. I re-verified it against Follow-ups 3 and 4 are now prompts rather than lines in a record: One thing this PR got right that I got wrongThe correction here about The branch Generated by Claude Code |
2 participants
The Mind ledger for the prior-support
Clippertask, from intake through toshipped. The code landed as PyAutoFit#1477 (
1f4b66a, squash), closingPyAutoFit#1476; this carries the workflow state that went with it.
What this changes
complete/2026/08/autofit-prior-support-clipper.mddraft/prompt folded in as a rename (R053)complete/index.mdlifecycle.py recorddashboard.mdpyauto-brain intake --apply dashboarddraft/feature/autofit/clipper_validation_campaign.mdactive.mdnets to no change — the task was added on routing and removed oncompletion, which is the intended lifecycle.
lifecycle.py checkisOK.What the record holds
The completion record is deliberately heavy on traps, because several of them
were expensive and none are obvious from the diff:
half-open) rather than one relative margin. The obvious single-margin form is
-inf + inf=NaNfor aGaussianPrior, which would have made the featureactively harmful on exactly the models it targets, with a symptom
indistinguishable from the bug being fixed.
bounds_from_model→ scipy:minimizereads a(lower, upper)tuple as asequence of
(min, max)pairs, silently mis-fitting two-parameter models.optimizeinLBFGS._fit, and the full 1790-test suite passed against it, because nothingin the library suite ever executes an LBFGS fit. A green suite is not coverage.
.completedshort-circuit,fit()rebuildingsearch.paths, the deletedsearch_internalfolder, andthe need to seed
randomandnumpybefore every comparison fit.Phase-2 prompt update
The most load-bearing addition. Phase 1 verified that the
clipperdoes notenter the search identifier —
no clipper/ClipperNone/ClipperPriorBoxall resolve to the same output directory. That is good for back-compat and
dangerous for the validation campaign, whose arms 1 and 2 differ in nothing else.
Stacked with the
.completedshort-circuit, arm 2 can silently return arm 1'snumbers and look like a clean run. The prompt now says so, with the mitigation
and the open question of whether the clipper should enter the identifier.
Also recorded there: arm 3 (momentum reset) does not exist yet — phase 1 ships
the mask it would need but no reset; the new
n_clipped_lane_stepscounter torecord; and that the
float32save_jsonbug is unfixed, so counters must becaptured independently of the result object.
Follow-ups filed, not fixed
float32not JSON serializable in result output (paths/directory.py:80).JSONDecodeError.LogGaussianPrior's(0, ∞)support on the prior itself.🤖 Generated with Claude Code
Generated by Claude Code