refactor!: rename project to bot-bottle

Assisted-by: Codex

docs/research/host-dispatch-to-container-agents.md

@@ -2,7 +2,7 @@
 
 ## Question
 
-Can host Claude decide which claude-bottle container to spin up for a task, while guaranteeing the work executes in the container and not on the host?
+Can host Claude decide which bot-bottle container to spin up for a task, while guaranteeing the work executes in the container and not on the host?
 
 ## Claude Code Agent Mechanisms
 
@@ -16,7 +16,7 @@ Claude Code provides two mechanisms for defining reusable agent behavior:
 
 ## The Reliability Problem
 
-The previous approach used an MCP server to bridge host Claude and claude-bottle containers. It failed because host Claude had both work-capable tools (Edit, Write, Bash) and MCP dispatch tools. Claude could choose to do the work itself rather than dispatch, with no enforcement mechanism to prevent it.
+The previous approach used an MCP server to bridge host Claude and bot-bottle containers. It failed because host Claude had both work-capable tools (Edit, Write, Bash) and MCP dispatch tools. Claude could choose to do the work itself rather than dispatch, with no enforcement mechanism to prevent it.
 
 ## Why Tool Restriction Solves It
 
@@ -26,7 +26,7 @@ Claude Code's subagent `tools:` allowlist is architecturally enforced — not a
 
 Three pieces in combination give a 100% guarantee:
 
-1. **Restricted host subagent** — a `.claude/agents/claude-bottle-dispatch.md` with `tools:` limited to MCP container tools and git-read operations. No Edit, Write, or arbitrary Bash.
+1. **Restricted host subagent** — a `.claude/agents/bot-bottle-dispatch.md` with `tools:` limited to MCP container tools and git-read operations. No Edit, Write, or arbitrary Bash.
 
 2. **MCP server** — exposes tools the restricted host can call:
    - `list_agents()` — available agents from the manifest (host Claude decides which to use)
@@ -40,11 +40,11 @@ Three pieces in combination give a 100% guarantee:
 
 Build host-dispatch-to-container in two deliverables:
 
-**Deliverable 1: Non-interactive run mode for claude-bottle**
+**Deliverable 1: Non-interactive run mode for bot-bottle**
 
 Extend `cli.py` with a `run <agent> <task>` subcommand. Starts the container, writes the task prompt to a file inside it (same `docker cp` pattern used for `--append-system-prompt-file`), invokes `claude --print` with the prompt, streams stdout back to the host, and exits when Claude finishes. Results committed and pushed from inside the container as usual.
 
-**Deliverable 2: MCP server wrapping claude-bottle**
+**Deliverable 2: MCP server wrapping bot-bottle**
 
 A minimal MCP server (bash or node) exposing `list_agents`, `run_agent`, `get_status`, `get_output`. Registered in the host Claude Code settings so a restricted dispatch subagent can call it.
 
@@ -52,7 +52,7 @@ The combination enforces the container boundary at the tool layer, not the promp
 
 **Critical:** the tool restriction only applies within the dispatch agent's context. A normal Claude session has its full toolset and may never invoke the dispatch agent regardless of its description. The dispatch agent must be the *entry point* for the session, not an optional subagent a full-tool host might call. Two ways to enforce this:
 
-- Launch with `claude --agent claude-bottle-dispatch` — makes the dispatch agent the primary agent for the session.
-- Set `agent: claude-bottle-dispatch` in the project `.claude/settings.json` — same effect automatically for any `claude` invocation in that directory.
+- Launch with `claude --agent bot-bottle-dispatch` — makes the dispatch agent the primary agent for the session.
+- Set `agent: bot-bottle-dispatch` in the project `.claude/settings.json` — same effect automatically for any `claude` invocation in that directory.
 
 Without one of these, the guarantee does not hold.