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/prds/0011-per-file-md-manifest.md

@@ -132,7 +132,7 @@ Each test runs against a temporary `$HOME` and a temporary `$CWD`:
   can revisit, but the v1 of this PRD is one file = one bottle.
 
 - **Hot-reload.** Changes to manifest files take effect at next
-  `./cli.py start`; we do not watch the directory.
+  `bot-bottle start`; we do not watch the directory.
 
 ## Scope
 

docs/prds/0018-compose-per-instance.md

@@ -290,7 +290,7 @@ After this PRD:
 
 ### Cleanup CLI
 
-`./cli.py cleanup` switches from "list every container with prefix
+`bot-bottle cleanup` switches from "list every container with prefix
 `bot-bottle-` and every network with prefix `bot-bottle-net-`
 or `bot-bottle-egress-`" to:
 
@@ -369,7 +369,7 @@ Sized for one PR each, in order.
    `docker compose up -d` + attach + teardown. Per-sidecar `start()`/
    `stop()` lifecycle methods deleted in the same chunk. Compose-
    log dump on teardown added.
-4. **Cleanup CLI on compose.** Switch `./cli.py cleanup` to
+4. **Cleanup CLI on compose.** Switch `bot-bottle cleanup` to
    `docker compose ls`-based discovery; keep prefix-scan as
    fallback for one release.
 5. **Dashboard.** Decide on the discovery question (open question

docs/prds/0019-active-agents-in-dashboard.md

@@ -37,7 +37,7 @@ Two rough edges in the current dashboard:
    shows only pending proposals. If no agent has called a tool,
    the screen reads "no pending proposals" — even when five
    bottles are quietly working. The operator has to `docker
-   compose ls` (or `./cli.py cleanup -n` to see the y/N preview)
+   compose ls` (or `bot-bottle cleanup -n` to see the y/N preview)
    to find out what's actually live.
 
 2. **`e` / `p` re-discover-and-disambiguate every invocation.**
@@ -82,12 +82,12 @@ the "operator wants to make an unprompted change" case.
   global across bottles. Filtering ("show me only this agent's
   proposals") might be a follow-up but isn't this PRD.
 - **Agent lifecycle from the dashboard.** Starting / stopping
-  agents stays in `./cli.py start` / `./cli.py cleanup`. The
+  agents stays in `bot-bottle start` / `bot-bottle cleanup`. The
   dashboard reads state; it doesn't change it.
 - **Preserved-but-not-running bottles.** The active-agents list
   is strictly "what's running now" (cross-referenced from
   `docker compose ls`). Preserved state dirs without a live
-  project don't appear — `./cli.py resume <identity>` is the
+  project don't appear — `bot-bottle resume <identity>` is the
   path for those.
 - **A separate per-agent detail view.** The agent rows are
   one-line summaries. Pressing Enter on a proposal still drops
@@ -125,7 +125,7 @@ the "operator wants to make an unprompted change" case.
 - Changes to proposal handling (`a` / `m` / `r` / Enter all
   unchanged).
 - Changes to the queue-dir / supervise sidecar protocol.
-- New CLI surface beyond what's in `./cli.py dashboard`.
+- New CLI surface beyond what's in `bot-bottle dashboard`.
 - Touching the manifest, compose renderer, launch lifecycle.
 
 ## Proposed design

docs/prds/0020-start-and-attach-from-dashboard.md

@@ -14,8 +14,8 @@
 Today the dashboard is read-only: it surfaces pending proposals
 and active agents (PRD 0019) but can't *start* an agent or
 *re-enter* one. The operator's path is split — they launch
-agents from one terminal (`./cli.py start <name>`), and watch
-them from another (`./cli.py dashboard`).
+agents from one terminal (`bot-bottle start <name>`), and watch
+them from another (`bot-bottle dashboard`).
 
 This PRD collapses that split. The dashboard becomes the
 operator's single surface: pressing a key opens an agent picker,
@@ -31,7 +31,7 @@ claude session AND the dashboard process. Exit claude → back to
 dashboard, bottle still running. Start another agent → two
 bottles up at once. Quit the dashboard → bottles continue
 running. Teardown is **always explicit**: the operator presses
-`x` on an agent, or runs `./cli.py cleanup` later.
+`x` on an agent, or runs `bot-bottle cleanup` later.
 
 ## Problem
 
@@ -45,7 +45,7 @@ Two real frictions today:
    open and the dashboard's "active agents" pane is hopelessly
    behind reality because they just spawned three in a row.
 
-2. **`./cli.py start` ties the bottle to a single claude
+2. **`bot-bottle start` ties the bottle to a single claude
    session.** The start command's `ExitStack` brings the bottle
    up, runs claude, and tears down on Ctrl-D — fine for a one-
    shot session, wrong for "let me bounce in and out of this
@@ -60,7 +60,7 @@ captures full-merged logs per bottle (PRD 0018). It already
 
 ## Goals / Success Criteria
 
-1. From inside `./cli.py dashboard`, pressing `n` (new) opens
+1. From inside `bot-bottle dashboard`, pressing `n` (new) opens
    an agent picker listing every agent defined in the manifest.
    Selecting one runs `prepare → preflight → launch`.
 2. The preflight Y/N summary renders cleanly — either as a
@@ -83,7 +83,7 @@ captures full-merged logs per bottle (PRD 0018). It already
    state cleanup) without quitting the dashboard.
 7. Quitting the dashboard (`q`) leaves every running bottle
    running. Bottle teardown is always explicit (per-bottle `x`
-   or `./cli.py cleanup`). The next `./cli.py dashboard`
+   or `bot-bottle cleanup`). The next `bot-bottle dashboard`
    invocation re-discovers them via `list_active_slugs()` and
    surfaces re-attach for any it can reconstruct context for
    (see "Cross-dashboard re-attach" below).
@@ -94,13 +94,13 @@ captures full-merged logs per bottle (PRD 0018). It already
   embedded-emulator option from the research doc is out of
   scope. The handoff (option 1) is the v1; option 2 is a
   separate PRD if and when handoff is observably insufficient.
-- **Adopting bottles started by an out-of-dashboard `./cli.py
+- **Adopting bottles started by an out-of-dashboard `bot-bottle
   start` invocation.** Those have their own ExitStack-owner and
   the dashboard treats them as read-only-watch (already does
   today). Re-attach only applies to bottles the *current
   dashboard process* started.
 - **Resurrecting an out-of-process bottle into a new dashboard
-  with full re-attach.** A bottle started by `./cli.py start`
+  with full re-attach.** A bottle started by `bot-bottle start`
   in another terminal — or by a previous dashboard run, now
   exited — appears in the agents pane (already does, PRD 0019)
   and can be re-attached via `docker exec -it claude` because
@@ -109,12 +109,12 @@ captures full-merged logs per bottle (PRD 0018). It already
   context object to drive teardown — e.g., the
   ExitStack-tracked CA + state cleanup `_settle_state` performs
   today. Cross-dashboard re-attach uses the existing
-  `./cli.py cleanup` for teardown, not an `x` keypress (see
+  `bot-bottle cleanup` for teardown, not an `x` keypress (see
   open questions).
 - **Multi-window UI.** Single curses window, two existing
   panes (proposals + agents); the agent picker is a modal, not
   a third pane.
-- **Removing `./cli.py start`.** Stays as the script-friendly /
+- **Removing `bot-bottle start`.** Stays as the script-friendly /
   legacy entry point. The dashboard is the new default.
 
 ## Scope
@@ -140,7 +140,7 @@ captures full-merged logs per bottle (PRD 0018). It already
 
 ### Out of scope
 
-- Changes to `./cli.py start` itself. It keeps its current
+- Changes to `bot-bottle start` itself. It keeps its current
   shape; the dashboard reuses its internal pieces (backend.
   prepare / backend.launch) without reaching through the CLI
   layer.
@@ -157,7 +157,7 @@ captures full-merged logs per bottle (PRD 0018). It already
 Today's flow:
 
 ```
-./cli.py start agent
+bot-bottle start agent
   └─ with backend.launch(plan) as bottle:        ← bottle alive while inside `with`
        bottle.exec_agent([...], tty=True)       ← blocks until claude exits
      # context exits → compose down → state cleanup
@@ -166,7 +166,7 @@ Today's flow:
 The proposed dashboard-driven flow:
 
 ```
-./cli.py dashboard
+bot-bottle dashboard
   └─ bottles: dict[str, tuple[ContextManager, DockerBottle]] = {}
 
      # operator presses `n`, picks agent
@@ -205,7 +205,7 @@ Two shifts:
    evaluation, state-dir reap) doesn't fire on a quit-while-
    running bottle. It DOES fire when the operator explicitly
    stops via `x`, because that calls `cm.__exit__`. For
-   bottles a previous dashboard quit on, `./cli.py cleanup`
+   bottles a previous dashboard quit on, `bot-bottle cleanup`
    is the path — its compose-down + state-reap logic
    already covers the case.
 
@@ -213,7 +213,7 @@ Two shifts:
 
 When the dashboard discovers a bottle in `discover_active_agents`
 that it didn't itself start (a previous-dashboard or external
-`./cli.py start` bottle), Enter still attaches via `docker exec
+`bot-bottle start` bottle), Enter still attaches via `docker exec
 -it … claude` — the agent container is running `sleep infinity`
 exactly the same way regardless of who started it. The only
 thing the current dashboard lacks for those bottles is the
@@ -221,8 +221,8 @@ launch-context object needed to drive a clean teardown via
 `x`.
 
 For v1 we surface this honestly: pressing `x` on a non-owned
-agent shows a status hint pointing at `./cli.py cleanup` (or
-`./cli.py cleanup` targeted at the slug if we add that flag
+agent shows a status hint pointing at `bot-bottle cleanup` (or
+`bot-bottle cleanup` targeted at the slug if we add that flag
 later). The agent stays alive; the operator handles teardown
 out-of-band. Enter (re-attach) works for both owned and
 non-owned bottles.
@@ -288,7 +288,7 @@ agents pane.
 
 `x` on a non-owned agent (discovered via `list_active_slugs`
 but not in `bottles` dict): no-op with status hint pointing
-at `./cli.py cleanup` (the existing path that tears down
+at `bot-bottle cleanup` (the existing path that tears down
 ANY bot-bottle compose project plus reaps state dirs).
 
 ### Dashboard quit
@@ -300,7 +300,7 @@ the `docker compose` project keeps running. The next dashboard
 invocation discovers the bottles via `list_active_slugs` and
 surfaces re-attach.
 
-This is a real departure from today's `./cli.py start`
+This is a real departure from today's `bot-bottle start`
 semantics (which couples bottle lifetime to the process via
 ExitStack). It's intentional: the dashboard is a watching +
 acting surface, not a lifetime owner.
@@ -322,7 +322,7 @@ Sized for one PR each.
    dashboard's ExitStack; handoff invokes `attach_agent`.
 3. **Re-attach via Enter on owned agents-pane row.** Looks up
    the slug in the dashboard's `bottles` map; if present →
-   handoff; else → status-line hint pointing at `./cli.py
+   handoff; else → status-line hint pointing at `bot-bottle
    resume`.
 4. **Explicit per-bottle stop (`x` keybinding).** Pop the
    bottle's `close` callback off the stack, call it, refresh.
@@ -369,7 +369,7 @@ Sized for one PR each.
    bottles dict goes out of scope without invoking `__exit__`,
    so the `docker compose` projects keep running. Bottle
    teardown is always explicit: per-bottle `x` (for
-   dashboard-owned), or `./cli.py cleanup` (for everything).
+   dashboard-owned), or `bot-bottle cleanup` (for everything).
 
 ## Open questions
 

docs/prds/0021-dashboard-tmux-split-pane.md

@@ -46,7 +46,7 @@ window, two panes, no terminal handoff.
 
 ## Goals / Success Criteria
 
-1. When the operator runs `./cli.py dashboard` from inside a
+1. When the operator runs `bot-bottle dashboard` from inside a
    tmux session (`$TMUX` set), the dashboard establishes a
    two-pane layout: dashboard in the left pane, an initially-
    empty right pane reserved for claude sessions.
@@ -313,7 +313,7 @@ Sized small.
 3. **Dashboard launched OUTSIDE tmux but tmux is installed.**
    Should the dashboard auto-exec itself inside a fresh tmux
    session to get the split-pane experience? Convenient but
-   surprising (`./cli.py dashboard` shouldn't silently
+   surprising (`bot-bottle dashboard` shouldn't silently
    change what session you're in). v1 leaves this off —
    operators who want split-pane mode start tmux themselves
    and then run the dashboard.
@@ -332,7 +332,7 @@ Sized small.
    PRD-0019 focus indicator?
 
 6. **Concurrent dashboards in different tmux windows.**
-   Multiple `./cli.py dashboard` invocations in different
+   Multiple `bot-bottle dashboard` invocations in different
    tmux windows would each create their own right pane —
    probably fine, each has its own state, but worth
    verifying that `tmux list-panes` is scoped to the right

docs/prds/0026-agent-provider-templates.md

@@ -14,7 +14,7 @@ Today bot-bottle is hard-wired around Claude Code assumptions. When Claude runs
 
 ## Goals / Success Criteria
 
-- A Codex agent can be started from the dashboard and via `./cli.py start` alongside a Claude agent.
+- A Codex agent can be started from the dashboard and via `bot-bottle start` alongside a Claude agent.
 - The manifest can express the agent provider/template and, where needed, a custom agent Dockerfile.
 - Claude-specific default egress/auth behavior is no longer implicit; provider-specific auth is expressed through explicit bottle egress routes and roles.
 - The launcher preserves required infrastructure behavior for sidecars, egress, pipelock, supervisor MCP, CA handling, git, and shell basics.

docs/prds/0048-ssh-deploy-key-provisioning.md

@@ -30,7 +30,7 @@ across every bottle spin-up. This has several consequences:
   to grant that access.
 - **Manual rotation burden.** Operators must manage key files on disk, keeping
   them secure, rotating them on a schedule, and distributing them across hosts
-  that run `./cli.py start`.
+  that run `bot-bottle start`.
 
 ## Goals / Success Criteria
 

docs/prds/0049-strip-dashboard-to-supervisor-tui.md

@@ -6,7 +6,7 @@
 
 ## Summary
 
-The `./cli.py dashboard` command has grown from its PRD 0013 roots
+The `bot-bottle dashboard` command has grown from its PRD 0013 roots
 (triage supervise proposals) into a parallel-agent control surface
 (PRDs 0019/0020/0021): an active-agents pane, agent picker + start,
 re-attach, per-bottle stop, tmux split-pane handoff, operator-
@@ -21,7 +21,7 @@ proposals, approve / modify / reject each one, write audit entries,
 deliver the response that unblocks the agent's tool call. Everything
 that's about *starting / re-entering / stopping* bottles, or about
 *operator-initiated* config edits, comes out. The command is renamed
-`./cli.py supervise` so the name matches what it does after the cut.
+`bot-bottle supervise` so the name matches what it does after the cut.
 
 Future agent-management UX is explicitly punted: if and when a
 control surface for parallel agents resurfaces, the working
@@ -41,9 +41,9 @@ Three concrete pains, all downstream of the dashboard's growth:
   ExitStack-free bottle ownership are intricate enough that
   shipping the next polish increment costs more than it returns.
 2. **No clear ownership of "starts and stops bottles".** Today
-  that responsibility is split: `./cli.py start` owns one-shot
+  that responsibility is split: `bot-bottle start` owns one-shot
   sessions; the dashboard owns multi-session bottles it started
-  itself; `./cli.py cleanup` owns everything else. The dashboard
+  itself; `bot-bottle cleanup` owns everything else. The dashboard
   tracking its own `bottles: dict[str, (cm, bottle, identity)]`
   that doesn't survive a quit is a confusing third lane.
 3. **Wrong target shape for a "manage many agents" UI.** The
@@ -97,12 +97,12 @@ problem is everything that got bolted onto that core after.
   dashboard. After this PRD they don't exist anywhere — operators
   who need ad-hoc edits use the same path the agents do (call the
   supervise tool from inside the bottle) or hand-edit the host-
-  side files and restart the sidecar. Adding a `./cli.py routes
+  side files and restart the sidecar. Adding a `bot-bottle routes
   edit <slug>` verb is a follow-up if the loss bites.
-- **Removing `./cli.py start` or changing its semantics.** Start
+- **Removing `bot-bottle start` or changing its semantics.** Start
   remains the one-shot launch path. PRD 0020's bottle-outlives-
   process model is removed; the only path to a long-running
-  bottle is `./cli.py start` (foreground) plus `cli.py cleanup`
+  bottle is `bot-bottle start` (foreground) plus `cli.py cleanup`
   for teardown.
 - **Removing the supervise-sidecar protocol or any of the three
   block-remediation engines.** PRDs 0013–0016 stay Active. The
@@ -122,8 +122,8 @@ problem is everything that got bolted onto that core after.
 
 ### In scope
 
-- **Rename the subcommand.** `./cli.py dashboard` becomes
-  `./cli.py supervise`. The module moves from `bot_bottle/cli/
+- **Rename the subcommand.** `bot-bottle dashboard` becomes
+  `bot-bottle supervise`. The module moves from `bot_bottle/cli/
   dashboard.py` to `bot_bottle/cli/supervise.py`. The dispatcher
   in `bot_bottle/cli/__init__.py` and the help text both update.
 - **Strip the curses loop to proposal-only.** The remaining
@@ -167,7 +167,7 @@ problem is everything that got bolted onto that core after.
 
 - Any new feature in the supervise TUI. The cut is purely
   subtractive (except for the rename).
-- Behavior changes in `./cli.py start`, `cli.py cleanup`,
+- Behavior changes in `bot-bottle start`, `cli.py cleanup`,
   `cli.py resume`, `cli.py list`, `cli.py info`, `cli.py edit`,
   `cli.py init` — unchanged.
 - Changes to the supervise sidecar (`supervise_server.py`,
@@ -181,7 +181,7 @@ problem is everything that got bolted onto that core after.
 
 ### Final shape of the TUI
 
-After this PRD the `./cli.py supervise` curses surface is:
+After this PRD the `bot-bottle supervise` curses surface is:
 
 ```
 bot-bottle supervise  (3 pending)
@@ -307,8 +307,8 @@ The PR closes issue #174.
 
 1. **`e` / `p` operator-initiated edits — gone for good or
   moved to a separate CLI verb?** The PRD removes them with no
-  replacement. The simplest replacement is `./cli.py routes
-  edit <slug>` and `./cli.py pipelock edit <slug>`, sharing
+  replacement. The simplest replacement is `bot-bottle routes
+  edit <slug>` and `bot-bottle pipelock edit <slug>`, sharing
   the existing `apply_routes_change` / `apply_allowlist_change`
   engines. If the loss is felt within the first parallel
   run after this lands, that follow-up is a small PR. Leaving

docs/prds/0051-launch-selector.md

@@ -7,12 +7,12 @@
 
 ## Summary
 
-When `./cli.py start` is run without an agent name, or without a backend
+When `bot-bottle start` is run without an agent name, or without a backend
 explicitly specified, the user currently gets an argparse error (missing
 positional) or falls through to the `docker` default silently. This PRD
 adds a terminal UI that appears in those gaps: a filter-select screen
 built with `curses` that lets the operator pick the agent and/or backend
-interactively rather than memorising names or consulting `./cli.py list`.
+interactively rather than memorising names or consulting `bot-bottle list`.
 
 ## Problem
 
@@ -29,15 +29,15 @@ visible.
 
 ## Goals / Success Criteria
 
-1. `./cli.py start` (no arguments) shows an interactive agent selector;
+1. `bot-bottle start` (no arguments) shows an interactive agent selector;
    the selected name is used exactly as if it had been passed on the
    command line.
-2. `./cli.py start <name>` (no `--backend`, no `BOT_BOTTLE_BACKEND`)
+2. `bot-bottle start <name>` (no `--backend`, no `BOT_BOTTLE_BACKEND`)
    shows an interactive backend selector; the selected backend is used
    exactly as if `--backend=<selected>` had been passed.
-3. `./cli.py start <name> --backend=<b>` (both explicit) shows neither
+3. `bot-bottle start <name> --backend=<b>` (both explicit) shows neither
    screen — no behavioural change from today.
-4. `./cli.py start` (no arguments, no env backend) shows the agent
+4. `bot-bottle start` (no arguments, no env backend) shows the agent
    selector first, then the backend selector.
 5. The filter-select widget is a standalone utility
    (`bot_bottle/cli/tui.py`) shared by both selectors.
@@ -57,7 +57,7 @@ visible.
 - No pagination beyond what fits in the terminal window (scroll via
   cursor movement is sufficient for typical agent counts).
 - No multi-select; exactly one item is chosen per invocation.
-- No changes to `./cli.py resume`, `./cli.py list`, or any other
+- No changes to `bot-bottle resume`, `bot-bottle list`, or any other
   subcommand.
 
 ## Design
@@ -83,7 +83,7 @@ def filter_select(
 
 The widget renders to the tty file descriptor opened via `curses.initscr`
 (or `curses.newterm` on the tty fd so stdout remains clean for callers
-that pipe `./cli.py`).
+that pipe `bot-bottle`).
 
 Layout (full-width, minimal):
 
@@ -140,7 +140,7 @@ agent picker can populate itself from the real manifest. The same
 `filter_select` opens `/dev/tty` and feeds it as the input file to
 `curses.wrapper`-equivalent code (using `curses.newterm` to avoid
 clobbering the caller's stdout/stderr). This keeps the picker
-composable — callers can pipe `./cli.py` output without the curses
+composable — callers can pipe `bot-bottle` output without the curses
 draw sequences contaminating the pipe.
 
 ## Implementation chunks

docs/prds/0060-commit-bottle-state.md

@@ -30,12 +30,12 @@ snapshot before a planned host reboot or hardware migration.
 
 ## Goals / Success Criteria
 
-- `./cli.py commit [<slug>]` takes a snapshot of the running agent and
+- `bot-bottle commit [<slug>]` takes a snapshot of the running agent and
   stores it as a local artifact.
 - Without a slug argument the command shows the same interactive picker
   as `start` (the list of active slugs).
 - The committed artifact reference is stored in per-bottle state so
-  that the next `./cli.py resume <slug>` automatically uses the
+  that the next `bot-bottle resume <slug>` automatically uses the
   snapshot instead of rebuilding from the Dockerfile.
 - `mark_preserved` is called so the state dir survives the normal
   session-end cleanup.
@@ -81,7 +81,7 @@ to the committed `.smolmachine` artifact.
 ### `commit` command
 
 ```
-./cli.py commit [<slug>]
+bot-bottle commit [<slug>]
 ```
 
 1. Resolve slug (arg or interactive picker from `enumerate_active_agents`).

docs/prds/0066-separate-agent-bottle-selection.md

@@ -37,7 +37,7 @@ egress policy), the operator must duplicate the agent file and change the
    selection order, as the effective bottle for the session.
 5. Confirming with an empty selection falls back to the agent's `bottle:` field.
    If neither is set, a ManifestError is raised pointing the operator at the fix.
-6. The ordered bottle list is stored in launch metadata so `./cli.py resume`
+6. The ordered bottle list is stored in launch metadata so `bot-bottle resume`
    uses the same bottles.
 7. The preflight summary (`y/N` screen) shows the effective bottle name(s).
 8. The multi-select picker supports incremental filtering, Space/Enter to toggle
@@ -52,7 +52,7 @@ egress policy), the operator must duplicate the agent file and change the
 - Reordering the selection list from within the picker (order = insertion order;
   drag-and-drop is out of scope).
 - Storing bottle selection history / MRU.
-- Changes to `./cli.py edit`, `./cli.py list`, or `./cli.py info`.
+- Changes to `bot-bottle edit`, `bot-bottle list`, or `bot-bottle info`.
 - Removing the `bottle:` key from the agent schema (it stays, now optional).
 
 ## Design

docs/prds/0068-smolmachines-linux.md

@@ -74,7 +74,7 @@ macOS-only for v1. Three concrete blockers:
 
 ## Goals / Success Criteria
 
-- `BOT_BOTTLE_BACKEND=smolmachines ./cli.py start <agent>` launches,
+- `BOT_BOTTLE_BACKEND=smolmachines bot-bottle start <agent>` launches,
   runs, and tears down a bottle on a Linux host with `/dev/kvm`.
 - The TSI allowlist is enforced on Linux: PRD 0022's
   `tests/integration/test_sandbox_escape.py` passes against

docs/prds/0077-macos-container-ci-runner.md

@@ -39,7 +39,7 @@ end-to-end runner that would catch the *next* macOS-only launch regression.)
 PR #470 (#414) already made the integration suite backend-agnostic:
 `skip_unless_selected_backend_available()` gates on the *selected* backend's
 own `is_backend_ready()` rather than `docker_available()`, and each
-integration job runs `./cli.py backend status --backend=<name>` as a preflight
+integration job runs `bot-bottle backend status --backend=<name>` as a preflight
 that fails loudly when the backend is missing. That is the machinery this job
 plugs into; this PRD supplies the runner and the job.
 
@@ -98,7 +98,7 @@ Modeled on `integration-firecracker`:
 - `concurrency: { group: integration-macos-infra, cancel-in-progress: false }`
   to serialize runs against the singleton.
 - **Preflight** — `command -v container`, `container system status`, then
-  `./cli.py backend status --backend=macos-container`; any failure exits
+  `bot-bottle backend status --backend=macos-container`; any failure exits
   non-zero so a misprovisioned runner fails loudly instead of silently
   skipping.
 - Run the integration suite under coverage with

docs/prds/0078-install-script.md

@@ -16,7 +16,7 @@ verifies host prerequisites after install.
 ## Problem
 
 There is currently no install path for new users. The only way to run
-bot-bottle is to clone the repo and invoke `./cli.py`. This blocks any
+bot-bottle is to clone the repo and invoke `bot-bottle`. This blocks any
 public demo: readers want `curl | sh` or `pipx install`, not a manual
 clone-and-configure flow. There is also no single command that tells a
 user whether their host is actually ready to run a bottle.