mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-09-15 23:32:46 +00:00
29e7e77c75
Fabro named Daytona snapshots by an HMAC of the image or Dockerfile, the resources, and the API key, ensured them through the driver's snapshot service before every create, and threaded that work through a create plan so the sandbox could learn the snapshot it came from. The driver's Daytona provider now does this inside create: an image or Dockerfile spec is built once into a snapshot named by its inputs under the API key and reused for the same inputs, with the build reported through the create's events. Fabro's overlay only fixes the working directory, names the run, sets the timers, and falls back to Daytona's default snapshot; the sandbox reads the snapshot it came from off the driver's status after the create. The snapshot identity module, the ensure step, the create plan, and fabro-sandbox's hashing dependencies go. Snapshot names change from fabro-<uuid> to the driver's sandbox-driver-<hex>, so existing snapshots are rebuilt once. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| fabro-acp | ||
| fabro-agent | ||
| fabro-automation | ||
| fabro-checkpoint | ||
| fabro-dump | ||
| fabro-environment | ||
| fabro-github | ||
| fabro-graphviz | ||
| fabro-hooks | ||
| fabro-install | ||
| fabro-interview | ||
| fabro-llm | ||
| fabro-manifest | ||
| fabro-mcp | ||
| fabro-mcp-store | ||
| fabro-sandbox | ||
| fabro-slack | ||
| fabro-store | ||
| fabro-tool | ||
| fabro-tracker | ||
| fabro-validate | ||
| fabro-variable | ||
| fabro-workflow | ||
| fabro-workflow-version | ||