refactor!: rename project to bot-bottle

Assisted-by: Codex

docs/research/remote-docker-vm-isolation.md

@@ -1,7 +1,7 @@
-# Remote Docker VM as an isolation upgrade for claude-bottle
+# Remote Docker VM as an isolation upgrade for bot-bottle
 
 Note on the cheapest practical path to stronger isolation than local
-Docker: run claude-bottle unchanged on a remote Linux VM that has
+Docker: run bot-bottle unchanged on a remote Linux VM that has
 dockerd. Complements `stronger-isolation-alternatives.md` (which
 surveys runtime swaps like gVisor, Kata, Firecracker, Apple Container)
 and `local-vs-remote-agent-execution.md` (which surveys the
@@ -10,7 +10,7 @@ local-vs-remote decision broadly).
 ## Summary
 
 If the goal is "stronger isolation than Docker-on-my-laptop without
-rewriting the runtime," the cleanest answer is to keep claude-bottle
+rewriting the runtime," the cleanest answer is to keep bot-bottle
 exactly as it is and run it on a remote Linux VM where you can install
 dockerd. The v1 design — pipelock as a separate container on a
 `--internal` network, ephemeral agent containers, OAuth-token
@@ -91,7 +91,7 @@ work:
   may not allow installing dockerd depending on tier; Fly Machines,
   EC2, GCE, Hetzner, Linode, and self-hosted hypervisors give you full
   control.
-- Enough disk + RAM to host the claude-bottle image, the agent
+- Enough disk + RAM to host the bot-bottle image, the agent
   container, and the pipelock sidecar. Headroom of ~2–4 GB RAM and
   ~5 GB disk is comfortable; less works for short sessions.
 - An interactive reach path. SSH is fine. The launcher uses
@@ -102,7 +102,7 @@ work:
 - **Typing latency.** Interactive Claude sessions over SSH have visible
   per-keystroke latency; usually fine on wired/fiber, less fine on
   Wi-Fi-to-cloud. Mosh helps if it's bothersome.
-- **Token shipping.** `CLAUDE_BOTTLE_OAUTH_TOKEN` has to live on the
+- **Token shipping.** `BOT_BOTTLE_OAUTH_TOKEN` has to live on the
   remote box for the launcher to forward it into containers. Use the
   provider's secret-injection path (cloud-init user-data,
   `flyctl secrets`, Tailscale-served local file, etc.). Never echo the
@@ -122,15 +122,15 @@ work:
 
 ## Operational shape
 
-The minimum-viable workflow, no claude-bottle code changes:
+The minimum-viable workflow, no bot-bottle code changes:
 
 1. `terraform apply` / `flyctl machine run` / `gcloud compute
    instances create` — provision a fresh Linux VM.
 2. Install dockerd via the provider's image or a one-liner
    (`curl -fsSL https://get.docker.com | sh`).
 3. SSH in.
-4. `git clone` claude-bottle on the VM, drop a manifest in place,
-   inject `CLAUDE_BOTTLE_OAUTH_TOKEN` via the provider's secrets path.
+4. `git clone` bot-bottle on the VM, drop a manifest in place,
+   inject `BOT_BOTTLE_OAUTH_TOKEN` via the provider's secrets path.
 5. `./cli.py start <agent>` — the existing launcher handles the rest.
 6. On exit: destroy the VM. No host artifacts persist.
 
@@ -150,14 +150,14 @@ gotchas the abstract pattern leaves implicit.
 
 Build a custom OCI image `FROM docker:dind` that bakes in:
 
-- The claude-bottle repository checkout.
-- A pre-built `claude-bottle:latest` image, saved via `docker save` on
+- The bot-bottle repository checkout.
+- A pre-built `bot-bottle-claude:latest` image, saved via `docker save` on
   your laptop and loaded in at image-build time
-  (`RUN docker load < claude-bottle.tar`) or pushed as a layer into
+  (`RUN docker load < bot-bottle.tar`) or pushed as a layer into
   the dind storage. Without this step, the first in-VM `docker build`
   runs `apt-get` and a global `npm install -g
   @anthropic-ai/claude-code`, which adds 30–90 s to every cold start.
-- A `flyctl secrets`-injected `CLAUDE_BOTTLE_OAUTH_TOKEN`, exposed to
+- A `flyctl secrets`-injected `BOT_BOTTLE_OAUTH_TOKEN`, exposed to
   the VM's PID 1 as an env var.
 - An entrypoint that starts dockerd, waits for it to be healthy, then
   either drops into a shell or directly runs `cli.py start <agent>`.
@@ -166,7 +166,7 @@ Deploy with `flyctl deploy` or `flyctl machine run --image …`.
 
 ### Boot-to-first-prompt timing
 
-Three scenarios, all assuming the custom image above (claude-bottle
+Three scenarios, all assuming the custom image above (bot-bottle
 image baked in, token injected, no in-VM rebuild):
 
 | Phase | Cold (image not cached on Fly host) | Warm (image cached, `machine run` fresh) | Hot (`machine stop`ped, `machine start`) |
@@ -186,7 +186,7 @@ is mostly about cost, not speed.
 ### Cost of standby vs. create-per-session
 
 Stopped Fly Machines stop billing CPU/RAM but continue to bill for
-storage and any allocated IPv4. A reasonable claude-bottle Machine
+storage and any allocated IPv4. A reasonable bot-bottle Machine
 size (2 vCPU / 2 GB / ~3 GB rootfs) costs roughly:
 
 | Item | While stopped | Monthly |
@@ -275,7 +275,7 @@ overhead in any given setting.
 
 If we wanted to land this as a real project direction:
 
-1. Add a short "Running claude-bottle on a remote Docker VM" section
+1. Add a short "Running bot-bottle on a remote Docker VM" section
    to the README pointing at this doc.
 2. Optionally: prototype the `--remote=user@host` launcher subcommand.
 3. Update `stronger-isolation-alternatives.md` to mention the remote