docs: rename Cartridge → Cassette throughout

Author: misaelzapata

README.md

@@ -59,9 +59,9 @@ make build kernel-unpack
 
 That's it — alpine boots in ~80 ms (warm OCI cache), runs the command, and exits. No kernel build required: the repo ships gzipped guest kernels under [artifacts/kernels/](artifacts/kernels/) for both x86_64 and arm64. `make kernel-unpack` decompresses them in place. To build a custom kernel from source, run `make kernel-guest` (x86_64) or `make kernel-guest-arm64` (arm64) instead — that takes ~10 min the first time.
 
-## Cartridge Deploys — one VM, infinite versions
+## Cassette Deploys — one VM, infinite versions
 
-> **The base VM never changes. Only the cartridge does.**
+> **The base VM never changes. Only the cassette does.**
 
 Every platform that runs user code faces the same problem: how do you deploy a new version without rebooting every running instance? The standard answer is containers (rebuild the image, restart the process) or blue/green deploys (spin up a new fleet, cut traffic over). Both require teardown and cold boot.
 
@@ -132,8 +132,8 @@ What this unlocks that no other open-source platform does today:
 | Deploy time | Minutes (build + push + pull) | Seconds (code only, no runtime) |
 | Rollback | Pull previous image tag | Point to previous ext4 |
 | Preview environments | Full container per PR | One ext4 per PR, shared base VM |
-| A/B testing | Two container fleets | Two VMs, same snapshot, different cartridge |
-| AI code execution | Docker per session (heavy) | One cartridge per conversation, warm VM |
+| A/B testing | Two container fleets | Two VMs, same snapshot, different cassette |
+| AI code execution | Docker per session (heavy) | One cassette per conversation, warm VM |
 | Isolation | Shared kernel (containers) | KVM hardware per tenant |
 
 The base snapshot is built **once** when you define your stack (e.g. `node:20-alpine` + Express + your deps). Every deploy after that only touches the code disk. Runtime cold-start is eliminated because the snapshot is already warm in the pool.
@@ -156,7 +156,7 @@ The base snapshot is built **once** when you define your stack (e.g. `node:20-al
 
 **Sandbox control plane** -- [gocracker-sandboxd](sandboxes/cmd/gocracker-sandboxd/) — HTTP daemon that wraps the runtime with warm pools (`~1.5 ms p95 lease`), content-addressed templates (`~80 µs cache hit`), HMAC-signed preview URLs, and Python / Go / JS SDKs with typed errors and context-manager sandbox lifecycle. Per-sandbox Firecracker-style UDS at `<state-dir>/sandboxes/<id>.sock` speaks directly to a baked-in toolbox agent on vsock 10023 (framed exec + files + git + secrets + `SetNetwork` re-IP). See the [Sandboxd overview](#sandboxd-sandbox-control-plane).
 
-**Cartridge deploys** -- Separate ext4 disk carries application code, mounted inside the guest at boot via `gc.code_disk=` kernel cmdline. The base VM snapshot never changes; swap the cartridge to deploy a new version. Attach multiple cartridges to one running VM for side-by-side version comparison without rebooting. See [Cartridge Deploys](#cartridge-deploys--one-vm-infinite-versions).
+**Cassette deploys** -- Separate ext4 disk carries application code, mounted inside the guest at boot via `gc.code_disk=` kernel cmdline. The base VM snapshot never changes; swap the cassette to deploy a new version. Attach multiple cassettes to one running VM for side-by-side version comparison without rebooting. See [Cassette Deploys](#cassette-deploys--one-vm-infinite-versions).
 
 ## Examples
 

site/index.html

@@ -25,7 +25,7 @@
 <nav class="topnav">
   <a href="#install">install</a> ·
   <a href="#features">features</a> ·
-  <a href="#cartridge">cartridge</a> ·
+  <a href="#cassette">cassette</a> ·
   <a href="#numbers">numbers</a> ·
   <a href="#sdk">sdk</a> ·
   <a href="https://github.com/misaelzapata/gocracker">github</a> ·
@@ -97,8 +97,8 @@ <h2>── features ────────────────────
   <dt>sandbox control plane</dt>
   <dd><code>gocracker-sandboxd</code> — warm pools, content-addressed templates, HMAC-signed preview URLs. Python · Go · JS SDKs.</dd>
 
-  <dt>cartridge deploys</dt>
-  <dd>Application code lives on a separate ext4 disk — not baked into the rootfs. The base VM (runtime + deps) is a frozen snapshot. Swap the cartridge to deploy a new version. The VM never reboots. Multiple cartridges in one running VM for instant version comparison. <a href="#cartridge">→ full explanation</a></dd>
+  <dt>cassette deploys</dt>
+  <dd>Application code lives on a separate ext4 disk — not baked into the rootfs. The base VM (runtime + deps) is a frozen snapshot. Swap the cassette to deploy a new version. The VM never reboots. Multiple cassettes in one running VM for instant version comparison. <a href="#cassette">→ full explanation</a></dd>
 
   <dt>warm runtime</dt>
   <dd><code>base-node-warm</code> template pre-loads V8 inside the snapshot. Node.js code eval goes from ~50 ms cold to ~5–10 ms warm, no reboot.</dd>
@@ -113,8 +113,8 @@ <h2>── features ────────────────────
 
 <hr>
 
-<section id="cartridge">
-<h2>── cartridge deploys ─────────────────────────────────</h2>
+<section id="cassette">
+<h2>── cassette deploys ─────────────────────────────────</h2>
 
 <p class="lede">Every platform today bakes code and runtime into the same container image. gocracker separates them — permanently.</p>
 
@@ -124,14 +124,14 @@ <h2>── cartridge deploys ─────────────────
          → image pull    <span class="muted">(on every node)</span>
          → container restart  <span class="muted">(cold boot)</span>
 
-<span class="muted"># gocracker cartridge:</span>
+<span class="muted"># gocracker cassette:</span>
 git push → pack code into ext4  <span class="muted">(seconds, code only)</span>
-         → attach cartridge     <span class="muted">(warm VM, no reboot)</span>
+         → attach cassette     <span class="muted">(warm VM, no reboot)</span>
          → <span class="ok">live in &lt; 100 ms</span></pre>
 
-<p>The base VM — kernel, runtime, all dependencies — is a <strong>frozen snapshot built once</strong>. It never changes across deploys. Only the cartridge (an ext4 disk carrying your application code) is swapped. This is the same separation Vercel achieves with bundles and V8 isolates, but with real KVM hardware isolation per tenant.</p>
+<p>The base VM — kernel, runtime, all dependencies — is a <strong>frozen snapshot built once</strong>. It never changes across deploys. Only the cassette (an ext4 disk carrying your application code) is swapped. This is the same separation Vercel achieves with bundles and V8 isolates, but with real KVM hardware isolation per tenant.</p>
 
-<pre class="term"><span class="muted">console (VM snapshot, frozen)    cartridge (ext4, swappable)</span>
+<pre class="term"><span class="muted">console (VM snapshot, frozen)    cassette (ext4, swappable)</span>
 ┌──────────────────────────┐     ┌──────────────────────────┐
 │ node:20-alpine           │     │ app-v42.ext4             │
 │ + Express + all deps     │ ←── │ ├── index.js             │
@@ -142,19 +142,19 @@ <h2>── cartridge deploys ─────────────────
 
 <dl class="feat">
   <dt>instant rollback</dt>
-  <dd>Point to the previous cartridge. No image rebuild, no container restart. The VM is already running.</dd>
+  <dd>Point to the previous cassette. No image rebuild, no container restart. The VM is already running.</dd>
 
   <dt>preview environments for free</dt>
   <dd>Each pull request gets its own ext4. They all share the same base VM snapshot — no extra memory for the runtime.</dd>
 
   <dt>A/B deploys</dt>
-  <dd>Two VMs, same snapshot, two different cartridges. Route traffic split between them. Swap one cartridge to promote the winner.</dd>
+  <dd>Two VMs, same snapshot, two different cassettes. Route traffic split between them. Swap one cassette to promote the winner.</dd>
 
   <dt>AI code execution</dt>
-  <dd>AI agents (Claude, Copilot, GPT) that execute code don't need to rebuild a container per session. One cartridge per conversation — the runtime VM is always warm. Swap in the user's code, run it, tear down the cartridge. No Docker, no heavy orchestration.</dd>
+  <dd>AI agents (Claude, Copilot, GPT) that execute code don't need to rebuild a container per session. One cassette per conversation — the runtime VM is always warm. Swap in the user's code, run it, tear down the cassette. No Docker, no heavy orchestration.</dd>
 
   <dt>multiple versions, one VM</dt>
-  <dd>Attach several cartridges simultaneously. Exec into any version without rebooting — useful for migration testing and benchmarking across versions.</dd>
+  <dd>Attach several cassettes simultaneously. Exec into any version without rebooting — useful for migration testing and benchmarking across versions.</dd>
 </dl>
 
 <pre class="term"><span class="hash"># two versions, one running VM</span>
@@ -165,7 +165,7 @@ <h2>── cartridge deploys ─────────────────
 toolbox exec node /data/v41/app.js   <span class="muted"># → v41 output</span>
 toolbox exec node /data/v42/app.js   <span class="muted"># → v42 output — same VM, no reboot</span></pre>
 
-<p class="note">To our knowledge, no other open-source microVM project exposes cartridge-style code-disk attach as a first-class API. · <a href="https://github.com/misaelzapata/gocracker/tree/main/examples/code-disk">examples</a></p>
+<p class="note">To our knowledge, no other open-source microVM project exposes cassette-style code-disk attach as a first-class API. · <a href="https://github.com/misaelzapata/gocracker/tree/main/examples/code-disk">examples</a></p>
 </section>
 
 <hr>
@@ -195,7 +195,7 @@ <h2>── sdk ─────────────────────
 
 client = Client(<span class="str">"http://127.0.0.1:9091"</span>)
 
-<span class="hash"># cartridge deploy — swap the ext4, not the VM</span>
+<span class="hash"># cassette deploy — swap the ext4, not the VM</span>
 sb = client.create_sandbox(
     image=<span class="str">"node:20-alpine"</span>,
     network_mode=<span class="str">"none"</span>,