Use SDK for preset VM creation

docs/build-local-debian-pi-image.md

@@ -84,13 +84,7 @@ Or pass a fully composed Containerfile directly:
 sbx image build-debian --containerfile path/to/Containerfile
 ```
 
-By default the subcommand prints only the built image paths and a minimal `sbx` config snippet. To also print a SmolVM SDK usage sketch after building, pass `--sdk-sketch`.
-
-To print the SDK sketch later without rebuilding the image, run:
-
-```bash
-sbx image build-debian --print-sdk-sketch ~/.smolvm/images/debian-sbx
-```
+The subcommand prints the built image paths and a minimal `sbx` config snippet.
 
 The subcommand also writes a local image manifest:
 

docs/fragile-glue.md

@@ -17,3 +17,18 @@ Why: SmolVM has an internal `custom_commands` hook in `_base_init_script()`, but
 Fragility: `_default_init_script()` and `_base_init_script()` are protected SmolVM internals and may change.
 
 Exit: replace with a public SmolVM boot-hook API, e.g. `/etc/smolvm/boot.d/*.sh` or a public `custom_commands`/`boot_hooks` parameter.
+
+## SmolVM preset creation through private facade methods
+
+Used by `src/sbx/smolvm_preset.py`:
+
+```python
+from smolvm.facade import _build_auto_config
+channel = vm._ensure_ssh_for_env()
+```
+
+Why: SmolVM 0.0.28 has public VM lifecycle and preset application APIs, but no public operation that creates a named auto-configured VM with sbx's CPU/port-forward settings and supplies the communication channel required by `apply_preset()`. The preset API also reads `os.environ`, so sbx temporarily activates its credential-filtered environment during provisioning.
+
+Fragility: both methods are private and may change. The SmolVM dependency remains pinned to `smolvm==0.0.28`, and all preset-specific private access is contained in `smolvm_preset.py`.
+
+Exit: replace this module with an upstream public preset creation API that accepts explicit VM resources, mounts, port forwards, timeouts, and host credential/environment inputs; then remove this entry and the adjacent `ponytail:` comment.

docs/per-mount-readonly-writable-draft.md

@@ -122,13 +122,9 @@ Estimated difficulty: medium.
 
 `sbx` could construct `WorkspaceMount` objects directly and use SmolVM's Python API for all normal starts.
 
-This would allow per-mount control without changing SmolVM CLI, but it is more invasive for `sbx` because the normal code path currently shells out to preset commands such as:
+Preset-backed VM creation now goes through sbx's SmolVM SDK compatibility module, so this option no longer requires replacing a preset CLI subprocess. It still requires sbx to model per-mount writability and pass `WorkspaceMount` objects into that creation boundary.
 
-```bash
-smolvm pi start ...
-```
-
-Estimated difficulty: medium/high compared to extending SmolVM CLI.
+Estimated difficulty: medium compared to extending SmolVM CLI.
 
 ## Suggested future `sbx` interface
 

docs/pi-package-node-version-issue.md

@@ -76,13 +76,7 @@ That package points to the older GitHub organization/account:
 badlogic/pi-mono
 ```
 
-`sbx` currently delegates agent installation to SmolVM:
-
-```bash
-smolvm pi start
-```
-
-So this stale package likely comes from SmolVM's Pi preset or prebuilt Pi image, not directly from `sbx`.
+`sbx` delegates agent installation to SmolVM's Pi preset through its SDK compatibility layer. Therefore this stale package likely comes from the SmolVM preset or prebuilt Pi image, not directly from `sbx`.
 
 ### 2. New Pi requires newer Node than the VM provides