docs: name bot-bottle, not ./cli.py, in every instruction

`doctor` told users to run `./cli.py backend setup`. cli.py is a four-line
wrapper at the repo root that calls bot_bottle.cli:main, and it does not ship —
[tool.setuptools.packages.find] includes only bot_bottle*, so anyone who
installed rather than cloned has no such file. Confirmed against a real
install: the user's tree contains exactly one executable, `bot-bottle`, and no
cli.py anywhere, while doctor recommended `./cli.py` three times. Invisible in
development, where ./cli.py works fine from a checkout, which is why only a
clean-install test surfaced it.

The two entry points are the same code, so the fix is to name the one that
always exists. 141 replacements across 45 files: the runtime messages that
caused this, plus README, docs, PRDs, research notes and test prose, so nothing
teaches the invocation a user cannot run.

scripts/demo.sh is deliberately untouched — it *executes* ./cli.py from a
checkout, where that is the correct and available path.

Verified end to end: a sandbox install now reports
"Run: bot-bottle backend setup --backend=firecracker", and bot-bottle is on
that user's PATH. Unit suite unchanged against the pre-existing baseline.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WEfZZhakx13bxTfXcZCoS5

docs/research/built-in-supervisor-design.md

@@ -6,7 +6,7 @@ Can bot-bottle grow a built-in supervisor — TUI inventory plus PR-feedback rou
 
 ## Context
 
-bot-bottle today is a fleet *executor*: `./cli.py start <agent>` brings up one bottle (agent container + pipelock + optional git-gate + optional cred-proxy on a per-bottle internal network), and `cli.py` tears it down when the session ends. There is no inventory view, no idle-detection, no automated reaction to PR or CI events. In parallel use, a human is the supervisor — opening one terminal per bottle, switching between them, and watching upstream PR state by hand.
+bot-bottle today is a fleet *executor*: `bot-bottle start <agent>` brings up one bottle (agent container + pipelock + optional git-gate + optional cred-proxy on a per-bottle internal network), and `cli.py` tears it down when the session ends. There is no inventory view, no idle-detection, no automated reaction to PR or CI events. In parallel use, a human is the supervisor — opening one terminal per bottle, switching between them, and watching upstream PR state by hand.
 
 A separate survey of the broader ecosystem ([agent control dashboards research, mid-2026](https://gitea.dideric.is/didericis/consilium-research/src/branch/main/developer-workflow/agent-control-dashboards-2026-05-24.md)) sorts dashboards into five tiers (session managers, parallel runners, Kanban boards, mission-control SPAs, observability backends). The earlier first-pass conclusion was that a full SPA tier conflicts with bot-bottle's isolation model. This doc reconsiders the smaller question: a TUI supervisor in the existing Python CLI.
 
@@ -25,13 +25,13 @@ A supervisor doesn't have to be heavy. A TUI built into the existing Python CLI,
 
 Three layers, each independently useful, in order of ambition:
 
-### 1. `./cli.py status` — read-only inventory
+### 1. `bot-bottle status` — read-only inventory
 
 Reads `docker ps` filtered by a bottle label and tails each bottle's session log. Reports per bottle: name, agent, uptime, last-activity timestamp, token spend if available, associated PR/branch if recorded.
 
 No new daemons. No new ports. No new credentials. ~100 lines.
 
-### 2. `./cli.py watch` — TUI over the same data
+### 2. `bot-bottle watch` — TUI over the same data
 
 Same data as `status`, rendered with auto-refresh and keyboard shortcuts that shell out to the existing `cli.py attach / stop / start` commands.
 
@@ -39,7 +39,7 @@ Library choice: prefer the stdlib `curses` module to stay stdlib-first; fall bac
 
 This is the Claude Squad / tmux-agent-status pattern, applied to bottles instead of tmux sessions. The whole category exists *because* a TUI is the lightweight shape that doesn't require what the SPA tier requires.
 
-### 3. `./cli.py supervise` — PR feedback router
+### 3. `bot-bottle supervise` — PR feedback router
 
 The optional, more ambitious layer. The bottle manifest gains an optional field:
 
@@ -49,7 +49,7 @@ pr_watch:
   branch: agent/task-42
 ```
 
-`./cli.py supervise` polls the named upstream for new review comments and CI failures on `branch`. When one fires, it surfaces as a desktop notification or a flash in the TUI. The human decides what to do with the feedback — there is no autonomous loop that feeds the comment back into a bottle's next prompt (see "Where to be conservative" for why).
+`bot-bottle supervise` polls the named upstream for new review comments and CI failures on `branch`. When one fires, it surfaces as a desktop notification or a flash in the TUI. The human decides what to do with the feedback — there is no autonomous loop that feeds the comment back into a bottle's next prompt (see "Where to be conservative" for why).
 
 The polling token is a **host** token (the same `GH_PAT` / Gitea token the host already keeps in shell env), not a bottle credential. The supervisor never holds bottle secrets.
 
@@ -62,7 +62,7 @@ The load-bearing question is whether the supervisor introduces the privileged-ch
 | Reaching into running bottles | Supervisor reads `docker ps` and host-side log files. The host already sees both — Docker is the trust boundary, the supervisor is on the host side of it. |
 | Holding bottle credentials | The polling token is a host token. The supervisor never receives `bottle.cred_proxy.routes` entries; it has no path to them. |
 | Bridging between bottles | The supervisor does not relay state from bottle A to bottle B. It relays *upstream PR state* to a bottle's next prompt — and only if the manifest opts in. |
-| New attack surface | All "control" actions go through `./cli.py start <agent>`, which already enforces the manifest. The supervisor is an automated caller of the existing CLI, not a parallel control plane. |
+| New attack surface | All "control" actions go through `bot-bottle start <agent>`, which already enforces the manifest. The supervisor is an automated caller of the existing CLI, not a parallel control plane. |
 
 The boundary stays at the bottle wall. The supervisor looks outward at git/PR state and downward at Docker; it does not look *inward* through pipelock.
 

docs/research/claude-code-pane-in-dashboard.md

@@ -13,11 +13,11 @@ What's the cheapest path to that, and where does it bottom out?
 
 ## What "interact" means
 
-Today the flow is bimodal. `./cli.py start <agent>` brings the
+Today the flow is bimodal. `bot-bottle start <agent>` brings the
 bottle up and immediately drops you into an interactive
 `docker exec -it bot-bottle-<slug> claude ...` — claude-code
 owns the whole terminal until you Ctrl-D out, at which point the
-bottle tears down. The dashboard (`./cli.py dashboard`) is a
+bottle tears down. The dashboard (`bot-bottle dashboard`) is a
 *separate* invocation that watches across bottles but never
 exposes the claude TUI itself.
 
@@ -107,7 +107,7 @@ What's not good:
 
 This is the v1 the project's existing code-shape strongly
 prefers. It clears the bar of "let me talk to claude-code
-without quitting `./cli.py dashboard`."
+without quitting `bot-bottle dashboard`."
 
 ## Option 2: Embedded emulator
 

docs/research/malicious-commit-scanning.md

@@ -84,7 +84,7 @@ dangerous changes before they left*.
    (`supervise_gitleaks_allow`, [`git_gate_render.py`](../../bot_bottle/git_gate_render.py)).
    Extend the same flow to **high-risk file classes**: any commit touching
    CI/build/deploy scripts, auth/crypto code, egress config, or
-   adding/changing dependencies → route to `./cli.py supervise`. This is
+   adding/changing dependencies → route to `bot-bottle supervise`. This is
    attribution/policy, not detection, and it's the strongest thing here —
    a human on exactly the temporal-escape surfaces.
 4. **LLM semantic diff-review — the behavioral backstop.** The only
@@ -146,7 +146,7 @@ preserves the bottom-up distribution funnel.
   **governed code-egress review**, not "we resell inference" (the
   monetization notes explicitly warn against reselling compute).
 - **The web-console supervise/review flow — the strongest anchor.** Turn
-  the CLI `./cli.py supervise` approval into a real review surface:
+  the CLI `bot-bottle supervise` approval into a real review surface:
   rendered diff + finding context, approve/reject, **who-approved audit
   trail, RBAC on approvers, mobile/phone-control** (ties to the
   dashboard/vault north star). This is "central enforcement +

docs/research/manifest-format-and-grouping.md

@@ -100,7 +100,7 @@ resolver globs each directory.
   becomes file ops (mkdir, mv, rm) instead of editing one file.
   Power users prefer that; new users may not.
 - Discovery requires `ls`, not "grep one file." Tooling helps
-  (e.g. `./cli.py list`) but the manifest is no longer a single
+  (e.g. `bot-bottle list`) but the manifest is no longer a single
   artifact to email or ship.
 - Atomicity: swapping a bottle name across agents touches
   multiple files. Git handles this fine; a one-shot text editor
@@ -364,7 +364,7 @@ wins; none of the body-prose or dependency story.
   warns / ignores / breaks. If it warns, we'd want a different
   field name (e.g. `bot-bottle-bottle`) or a namespaced block.
 - **Migration story.** Is the project willing to ship a one-shot
-  `./cli.py migrate-manifest` command that does the JSON → MD
+  `bot-bottle migrate-manifest` command that does the JSON → MD
   conversion? Or do users just rewrite by hand from the new docs?
 - **Bottle file body content.** If most bottle .md files have an
   empty body, is the MD-with-frontmatter format still warranted?

docs/research/polish-priorities.md

@@ -34,7 +34,7 @@ on top of working onboarding.
 
 A first-time user today goes through five steps: install Docker,
 install `uv`, set `BOT_BOTTLE_CLAUDE_OAUTH_TOKEN`, write
-`bot-bottle.json`, run `./cli.py start`. One of those is
+`bot-bottle.json`, run `bot-bottle start`. One of those is
 "author a JSON manifest." Polished tools in this category let
 users skip that step on day one. The fix is an `init` subcommand
 that drops a working `bot-bottle.json` with a default `coder`

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

@@ -131,7 +131,7 @@ The minimum-viable workflow, no bot-bottle code changes:
 3. SSH in.
 4. `git clone` bot-bottle on the VM, drop a manifest in place,
    inject `BOT_BOTTLE_CLAUDE_OAUTH_TOKEN` via the provider's secrets path.
-5. `./cli.py start <agent>` — the existing launcher handles the rest.
+5. `bot-bottle start <agent>` — the existing launcher handles the rest.
 6. On exit: destroy the VM. No host artifacts persist.
 
 For the "VPN pivot" failure mode, see