fabro/lib/apps
Bryan Helmkamp 0c569638fe
Map an environment onto one sandbox spec for every provider
Three copies of the same mapping turned an environment into a sandbox:
Docker had its own options type built from the environment, Daytona a
config type with its own network enum and minute-and-gigabyte units,
and plugin kinds a third options type, each with its own spec builder,
constructor, and attach function, and the run spec had a variant per
provider carrying them. The mapping now runs once. SandboxOptions is
what any environment asks of any provider; options_from_environment
builds it, and one base spec carries the source, name, labels,
variables, resources, and network policy. Docker and Daytona are
overlays on that spec: Docker fixes its working directory, supplies the
default image, and pulls; Daytona replaces the source with the snapshot
it ensures from the same image or Dockerfile, fixes its working
directory and name, and sets the timers. The snapshot's content-addressed
name is unchanged, since the identity still hashes the image or
Dockerfile and the resources in whole gigabytes.

SandboxSpec has two variants, Local and Provider, and the worker and
the server preflight build the Provider one without knowing which kind
it is; provider_sandbox and attach_provider_sandbox connect any kind
through the single construction function and lay the repository out
where that kind keeps it. The per-provider constructors, the config
module, and the environment mapping module are gone, and the SDK
reference and the integration tests use the one constructor.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
2026-09-09 22:41:09 -06:00
..
fabro-cli Pin the driver PR stack and run its own plugin executables 2026-09-09 22:19:26 -06:00
fabro-mcp-server Refactor MCP config argument handling 2026-08-26 09:01:37 -04:00
fabro-server Map an environment onto one sandbox spec for every provider 2026-09-09 22:41:09 -06:00
fabro-spa refactor: organize crates into three layers 2026-07-23 17:59:34 -04:00