@miosa/sdk 3.0.0 → 3.0.1

package/README.md

@@ -55,7 +55,6 @@ await sbx.pause();
 | `miosa.sandboxes` | Lightweight code-execution VMs — exec, files, snapshots, previews |
 | `miosa.computers` | Full Linux desktop VMs with desktop control for agents |
 | `miosa.deployments` | Versioned production releases with rollback |
-| `miosa.appDocuments` | Durable generated apps with exact-version review approvals and immutable publication bindings |
 | `miosa.databases` | Managed Postgres / Redis lifecycle |
 | `miosa.storage` | S3-compatible object storage |
 | `miosa.volumes` | Persistent block storage |
@@ -70,38 +69,6 @@ await sbx.pause();
 | `miosa.completions` | OpenAI-compatible chat completions with SSE streaming |
 | `miosa.embeddings` | OpenAI-compatible embedding vectors |
 
-## Durable generated apps
-
-App Documents persist the generated app contract outside the browser.
-They are workspace-scoped and include the view, declared capabilities, connectors, collections, automations, and component pins.
-Native rendering authority is a separate approval pinned to the current canonical version hash.
-Editing the document changes the hash and invalidates the old approval.
-
-```ts
-const app = await miosa.appDocuments.create({
-  workspaceId: "workspace-id",
-  name: "Clinic triage",
-  document: {
-    id: crypto.randomUUID(),
-    name: "Clinic triage",
-    format: "miosa-app/v1",
-    view: { kind: "generated", source: "<main>Triage</main>" },
-    capabilities: ["computer.exec"],
-    collections: ["tickets"],
-    connectors: ["linear"],
-    automations: [],
-    pins: [],
-  },
-});
-
-const approval = await miosa.appDocuments.approveExactVersion(
-  app.id,
-  "Reviewed for exact release publishing",
-);
-
-await miosa.appDocuments.revokeApproval(app.id, approval.id);
-```
-
 ## Connect vs Egress
 
 Use **Connect** when your product needs to manage provider credentials for
@@ -244,25 +211,7 @@ const result = await sbx.exec.run("python /workspace/app.py");
 for await (const event of sbx.exec.stream("tail -f /var/log/app.log")) {
   if ("line" in event) console.log(event.line);
 }
-```
-
-> **`sbx.exec.stream()` vs `computer.exec.stream()` - not the same thing.**
-> They share a name and nothing else, by design:
->
-> | | `sbx.exec.stream(command)` (Sandbox) | `computer.exec.stream({ command, tty })` (Computer) |
-> |---|---|---|
-> | Transport | SSE, one-way (server → client) | WebSocket, full duplex |
-> | Purpose | Tail output from a batch command | Interactive shell/PTY session |
-> | Input | Takes a fixed command string up front | `sendStdin()` any time after connecting; supports `tty`/`rows`/`cols` |
-> | Event shape | `{ type: "stdout" \| "stderr" \| "exit", ... }` parsed from JSON lines | Raw `Uint8Array` frames over the wire protocol |
->
-> Use the Sandbox one to watch a log or long-running batch job finish.
-> Use the Computer one to drive an interactive terminal. They will not be
-> merged into one API - a one-way log tail and a duplex PTY session need
-> different guarantees (backpressure, input, framing) that a single shape
-> would blur.
 
-```ts
 // Snapshots
 const snap = await sbx.snapshots.create("pre-migration");
 const restored = await sbx.snapshots.restore(snap.id);
@@ -309,30 +258,6 @@ const deployment = await sbx.deploy({
 });
 ```
 
-To publish the exact snapshot that passed QA instead of whatever the editable
-sandbox holds right now, use `deploySnapshot`. It forks the snapshot into a
-temporary release sandbox, deploys that fork, and destroys it again, so the
-source sandbox is never mutated:
-
-```ts
-const snap = await sbx.snapshots.create("qa-approved");
-
-const release = await sbx.deploySnapshot(snap.id, {
-  name: "clinic-intake",
-  outputPath: "/workspace/dist",
-  entrypoint: "index.html",
-});
-
-console.log(release.source_snapshot_id, release.release_sandbox_id);
-```
-
-The result always carries `source_snapshot_id` and `release_sandbox_id` for
-provenance. Pass `{ cleanup: false }` as the third argument to keep the release
-sandbox for inspection. If the release sandbox could not be destroyed, the
-deployment still succeeds and `release.release_cleanup_error` explains why; when
-the deploy itself fails and the release sandbox survives, the thrown error
-carries the same fields so the leftover sandbox can be cleaned up by id.
-
 For workspace App Engine, publish from the same sandbox but choose the
 App Engine target:
 
@@ -445,32 +370,6 @@ const miosa = new Miosa({
 });
 ```
 
-### Two sandbox streams need the sandboxes base URL
-
-The API serves two routers, selected by Host header. Two SSE routes exist
-only on the `sandboxes.miosa.ai` router, so they return `404` against the
-default `api.miosa.ai` base URL:
-
-| Method | Route |
-|---|---|
-| `sbx.files.watch()` | `GET /sandboxes/{id}/files/watch` |
-| `sbx.processes.stream(pid)` | `GET /sandboxes/{id}/processes/{pid}/stream` |
-
-Both are implemented server-side; only the platform router is missing them.
-Point the client at the sandboxes host to use them:
-
-```ts
-const miosa = new Miosa({
-  apiKey: process.env.MIOSA_API_KEY!,
-  baseUrl: "https://sandboxes.miosa.ai/api/v1",
-});
-```
-
-The alternative is polling: `sbx.files.list()` / `stat()` instead of
-`watch()`, and `sbx.processes.logs(pid)` instead of `stream(pid)`. Calling
-either against the default base URL raises a `NotFoundError` that names this
-gap rather than a bare `404`.
-
 ## Links
 
 - [Full documentation](https://miosa.ai/docs/sdks/typescript)