Skip to content

feat(acquisition): a resumed session gets its configuration back - #203

Merged
pskeshu merged 1 commit into
developmentfrom
feat/acquisition-restore
Sep 26, 2026
Merged

pskeshu merged 1 commit into
developmentfrom
feat/acquisition-restore

Conversation

@pskeshu

@pskeshu pskeshu commented Sep 26, 2026

Copy link
Copy Markdown
Collaborator

when i resume a session, i do not have all the acquisition configuration restoration.

Two things were lost.

The run's state. The orchestrator checkpoints 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. Now the checkpoint is applied on both resume paths (boot --resume and 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.yaml in the session when it starts (from the pane, and from the library/agent path alike), GET /api/devices/timelapse/plan serves 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.py cover 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

"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>
@pskeshu
pskeshu merged commit 33d08fc into development Sep 26, 2026
2 checks passed
@pskeshu
pskeshu deleted the feat/acquisition-restore branch September 26, 2026 06:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant