fabro/lib/apps
Bryan Helmkamp 981253f990
Collapse the run sandbox's lifecycle surface
RunSandbox grew its lifecycle methods one adopter at a time and ended up
with several names for each step. Reconnecting from a run record had
four entry points (reconnect, reconnect_for_run,
reconnect_for_run_with_events, reconnect_driver_for_run) that all
forwarded to the last one. Bringing a sandbox back had two (start and
activate) over the same make_ready, and releasing it had two (delete and
cleanup) over the same release. Two more methods had no callers at all:
set_autostop_interval, which nothing set after the driver took over
lifecycle timers, and resume_setup_commands, which resume stopped using
when checkout moved to the git facet.

There is now one of each. reconnect_for_run takes the record, the
provider access, an optional run id, and an optional event context;
callers that need none pass None. activate is the single "make usable"
step: a running sandbox only learns its platform when it has not yet, a
stopped or paused one is started and its Bash verified, and resume calls
it like every access-time caller. delete is the single release; for a
designated host directory it frees the handle and leaves the directory in
place, as cleanup did. The tests and server call sites follow the
renames; behavior is unchanged except that resuming an already running
sandbox no longer re-runs the Bash probe.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-11 15:05:06 -06:00
..
fabro-cli Expect the driver's stop event in the stored event history snapshot 2026-09-11 13:58:09 -06:00
fabro-mcp-server Expose lithos request and response shapes through the API, server, CLI, and web 2026-09-09 17:26:57 -06:00
fabro-server Collapse the run sandbox's lifecycle surface 2026-09-11 15:05:06 -06:00
fabro-spa refactor: organize crates into three layers 2026-07-23 17:59:34 -04:00