feat(acquisition): a resumed session gets its configuration back - #203
Merged
Merged
Conversation
"when i resume a session, i do not have all the acquisition configuration restoration." Two things were lost. The orchestrator checkpoints its runtime state to timelapse.yaml every round — cadence, the DIC channel, every embryo's ending and timepoint count — and nothing ever read it back: load_state() existed with no caller. A resumed run would have restarted its numbering from whatever the conversation snapshot last said (on the rig tonight: t1, while the checkpoint said t15), over the volumes on disk. And the plan the operator composed on the Acquisition pane lived in the form and nowhere else, so a resumed session came back with the defaults — five minutes, fifty slices, no DIC, manual. Now: - A run's plan is kept as acquisition.yaml in the session when it starts, from the pane and from the library/agent alike. - The checkpoint is applied on both resume paths (boot --resume and the in-app switch), and the orchestrator is pointed at the resumed session first — it learned its session once, at construction, so an in-app switch left it filing checkpoints under the previous one. - GET /api/devices/timelapse/plan serves the plan back; a session that predates the plan file gets one derived from the checkpoint and the last volume's sidecar, so the sessions already on the rig read back. - The pane fills its form from it on entry, once per page life, never over something the operator has already typed, and says where the plan came from. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This was referenced Sep 26, 2026
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
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.
Two things were lost.
The run's state. The orchestrator checkpoints to
timelapse.yamlevery round — cadence, the DIC channel, every embryo's ending and timepoint count — and nothing ever read it back:load_state()existed with no caller. A resumed run would have restarted its numbering from whatever the conversation snapshot last said (on the rig tonight: t1, while the checkpoint said t15), over the volumes on disk. Now the checkpoint is applied on both resume paths (boot--resumeand the in-app switch). The orchestrator is also pointed at the resumed session first: it learned its session once, at construction, so an in-app switch left it filing checkpoints under the previous one.The plan. What the operator composed on Operate › Acquisition lived in the form and nowhere else, so a resumed session came back with the defaults. Now a run's plan is kept as
acquisition.yamlin the session when it starts (from the pane, and from the library/agent path alike),GET /api/devices/timelapse/planserves it back, and the pane fills its form from it on entry — once per page life, never over something the operator has already typed — and says where the plan came from. A session that predates the plan file gets one derived from the checkpoint and the last volume's sidecar, so the sessions already on the rig read back too.Verified headless with the plan route stubbed: entering the pane fills cadence 5 min, 40 slices, 12 ms, "488 only", DIC on every 2 rounds from a pinned position at 20 ms, ending at hatching with embryo 2 at 12 timepoints, expression monitoring; the sentence says all of it; typing 33 slices then leaving and re-entering keeps 33. Seventeen tests in
tests/test_acquisition_restore.pycover the store round trip, the checkpoint-derived plan, the restore helper (live run left alone, missing checkpoint not a failure), the start route keeping the plan, the plan route, and the pane's wiring.🤖 Generated with Claude Code