prompt: retire loggaussian-prior-support, file and work its four follow-ups - #350
Merged
Merged
Conversation
The fix shipped 2026-08-25 as PyAutoFit#1527 (merged, `34d6dff`, `pending-release`), closing PyAutoFit#1526. The Mind-side close-out never landed: that session's PyAutoMind branch `claude/loggaussian-prior-support-buv5xe` was condemned the same day, so the prompt stayed in `draft/bug/autofit/` and kept rendering on the dashboard as pickable backlog. Writes the completion record from PyAutoFit#1526/#1527 and from `main` itself, retires the prompt, refreshes `complete/index.md` and regenerates the dashboard. No PyAutoFit changes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0173PAAaCQ7myTu9SUboYA4Y
Filed from the follow-up list in complete/2026/08/loggaussian-prior-declares-own-support.md: - refactor/autofit/optimisation_state_limit_guard_truthiness.md - refactor/autofit/redundant_prior_limits_overrides.md - research/graphical_ep/transformed_message_declares_support.md - test/autogalaxy/prior_passing_loggaussian_lower_bound.md Also corrects that record's follow-up 1. PyAutoFit#1527 describes `OptimisationState.valid`'s guard as "falsy at 0.0", implying the fix disabled a limit check for the prior it gave a 0.0 lower limit. It did not: `lower_limit` there is a `VariableData` dict, so the guard tests non-emptiness, and the EP path reads limits off the message, which #1527 left at +/-inf. What remains is a readability defect, not a live bug — the prompt is filed as refactor on that basis. Follow-up 2 likewise gains the `float()` coercion caveat that makes it a type change rather than a pure deletion. Dashboard regenerated in the same commit; `lifecycle.py check` OK. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0173PAAaCQ7myTu9SUboYA4Y
- 1 and 2 implemented together on PyAutoFit claude/loggaussian-prior-support-ngh59x (4c0f79b); status appended to both prompts, which stay in draft/ until a PR is opened. - Doing 1 exposed a live bug: VariableData.any reduced through var_all, so OptimisationState.valid reported a parameter vector valid when only SOME components were outside their limits. Fixed in the same commit. - 3 partly answered and the measurements appended: EP's check_limits does not enforce LogGaussian's support, but the message's own density returns a clean -inf, so nothing is wrong today. Design question stays open, lower priority. - 4 done, null result, retired to complete/2026/08/ — neither PyAutoGalaxy nor PyAutoLens constructs a LogGaussianPrior, so there is no downstream exposure. Dashboard regenerated; lifecycle.py check OK. Co-Authored-By: Claude <noreply@anthropic.com>
…undant overrides PyAutoFit#1532 merged as 6e2d8c8; issue #1531 closed. Two prompts retired, since both shipped in that one PR: - complete/2026/08/optimisation-state-limit-guard-truthiness.md - complete/2026/08/redundant-prior-limits-overrides.md The find worth keeping: VariableData.any reduced through var_all, so OptimisationState.valid accepted a parameter vector with only SOME components outside their limits, and MeanField's validity count under-reported the same way. Neither had any test coverage, so the suite stayed green through it — the #1477 process lesson, third time in this lineage. Also repoints the parent record's follow-up list, whose "No PR opened yet" the merge falsified. complete/index.md refreshed, dashboard regenerated, reconcile clean (0 suspects of 136), lifecycle.py check OK. Co-Authored-By: Claude <noreply@anthropic.com>
The branch was 10 commits behind. Both conflicts were in GENERATED files -- complete/index.md and dashboard.md -- so they were resolved by regenerating from the merged sources rather than hand-picking hunks: lifecycle.py index --apply -> 1159 records pyauto-brain intake --apply dashboard -> 134 prompts Both --check legs report current and lifecycle.py check is OK. No source-of-truth file conflicted: the four completion records, the retired prompts and the research prompt all merged cleanly. Co-Authored-By: Claude <noreply@anthropic.com>
Jammy2211
pushed a commit
that referenced
this pull request
Aug 27, 2026
The branch was behind main by PyAutoMind#348/#349/#350. Merged, never rebased. All three conflicts were in generated files — complete/index.md, dashboard.md, dashboard.html — and were resolved by regenerating from the merged sources (lifecycle.py index --apply, pyauto-brain intake --apply dashboard), never by hand-editing. No source-of-truth file conflicted. All four PR gates re-run green after the merge: lifecycle check, lifecycle index --check, registry_toc --check, intake dashboard --check, plus the spawn privacy suite (240 passed). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KmWbYJw4cJJnt4eK6NoZjL
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.
Summary
Mind state for the
loggaussian-prior-supportlineage. Three commits, no code.1. The close-out that never landed (
046acb2b).draft/bug/autofit/loggaussian_prior_declares_own_support.mdshipped 2026-08-25 as PyAutoFit#1527 (merged34d6dff), closing PyAutoFit#1526 — but the Mind half was lost when that session's branchclaude/loggaussian-prior-support-buv5xewas condemned the same day. The prompt stayed indraft/, rendering on the dashboard as pickable backlog, and a/start_devrun on 2026-08-27 rediscovered the work already merged. This writes the completion record from the issue, the PR andmainitself, and retires the prompt.2. The four follow-ups filed (
ba71d5c2). From that record's follow-up list.3. The four follow-ups worked (
442a67ec).refactor/autofit/optimisation_state_limit_guard_truthiness.mdrefactor/autofit/redundant_prior_limits_overrides.mdresearch/graphical_ep/transformed_message_declares_support.mdtest/autogalaxy/prior_passing_loggaussian_lower_bound.mdcomplete/2026/08/Two corrections this carries
PyAutoFit#1527's own follow-up list was wrong about follow-up 1. It describes
OptimisationState.valid's guard as "falsy at0.0", implying #1527 disabled a limit check for exactly the prior it gave a0.0lower limit. It did not:lower_limitthere is aVariableData(adictsubclass), so the guard tests non-emptiness and there is no0.0for it to be falsy at — and the EP path reads limits off the message, which #1527 deliberately left at±inf. The prompt is filed asrefactoron that basis rather than as the bug it was written up as.A real bug was underneath it.
VariableData.anyreduced throughvar_all, soOptimisationState.validreported a parameter vector valid when only some components were outside their limits. Found only because rewriting the guard needed a test andOptimisationState.validhad no coverage at all. Fixed in PyAutoFit#1532.Note on follow-up 4
A null result, recorded explicitly rather than quietly dropped: neither PyAutoGalaxy nor PyAutoLens constructs a
LogGaussianPrioranywhere (only an API-docs autosummary line in each), and it is the only prior whoselimits#1527 changed — so the prior-passing change has no downstream exposure. The alternative, retiring the prompt because "nothing was found", leaves the next reader unable to tell a completed check from an abandoned one.Checks
lifecycle.py check— OKintake dashboard --check—dashboard.md + dashboard.html are currentlifecycle.py dates— 3 undated prompts remain, all pre-existing and unrelated to this branchGenerated by Claude Code