Product Updates

pip install --pre --upgrade snowglobe
# or, if you use uv:
uv pip install --prerelease=allow --upgrade snowglobe

# version 0.9.x — headless poller for all eligible simulations
snowglobe-connect start

# version 1.0.x — dedicated to one simulation
snowglobe connect --simulation-id <simulation-id>

You are migrating a repository's usage of the Snowglobe CLI client from version
0.9.x to 1.0.x. The changes are entirely in how the `snowglobe-connect` CLI is
installed and invoked. Make the edits below, then report a summary of every file
you changed.

## Scope

Search the ENTIRE repo for references to the old CLI, including:
- shell scripts (*.sh), Makefiles, justfiles, Taskfiles
- CI/CD configs (.github/workflows/*.yml, .gitlab-ci.yml, CircleCI, Jenkinsfile,
  Azure Pipelines, etc.)
- Dockerfiles and docker-compose files
- package.json scripts, npm/yarn/pnpm scripts, tox.ini, noxfile
- README / docs / *.md / *.mdx
- any wrapper scripts, .env files, or process managers (systemd units,
  supervisor, pm2, Procfile)

Do NOT change unrelated text. Do NOT touch references that are intentionally
pinned to "snowglobe<=0.4.x" / "0.4.x" legacy docs.

## Rename rules (apply in this order, longest match first)

1. `snowglobe-connect auth`  ->  `snowglobe login`
2. `snowglobe-connect start` ->  `snowglobe connect`   (then apply rule 4 below)
3. Any remaining `snowglobe-connect <subcommand>` (init, test, simulate, replay,
   select-organization, list-agent-profiles, init-metric, test-metric,
   connect-metric, --version, --help, etc.)  ->  `snowglobe <subcommand>`
4. A bare `snowglobe-connect` used as the command/binary name (including in
   prose and install instructions like `pip install snowglobe-connect`)
   ->  `snowglobe`

## Required behavioral change: `--simulation-id`

In 1.0.x, `snowglobe connect` (formerly `start`) REQUIRES `--simulation-id`.
A bare `snowglobe connect` now errors.

- If an old invocation already passed `--simulation-id <X>`, keep it.
- If an old `start` invocation had NO simulation id (it relied on the headless
  "process all simulations" behavior, which no longer exists), you cannot
  invent an ID. In that case:
  - For automated/CI usage, prefer rewriting it to create-and-connect in one
    step: `snowglobe simulate ./config.yml` (or `snowglobe replay ./config.yml`
    for trace-regression). Only do this if a simulate/replay config file exists
    or the surrounding context makes the intent clear.
  - Otherwise, replace it with `snowglobe connect --simulation-id <SIMULATION_ID>`
    and leave `<SIMULATION_ID>` as an explicit placeholder. Add a brief comment
    next to it (in whatever comment syntax the file uses) explaining that the
    user must supply the target simulation's ID, because 1.0.x dedicates each
    connect process to a single simulation.
  - Flag every such spot in your final summary so a human can fill in the ID.

## Installation references

- The pip package name is still `snowglobe` (unchanged).
- `1.0.1a1` is a pre-release. Where you see an install command, ensure pre-
  releases are allowed: `pip install --pre snowglobe` (or
  `uv pip install --prerelease=allow snowglobe`).
- If the repo installs an old distribution name (`snowglobe-connect` or
  `snowglobe-mirror`), change it to install `snowglobe` and note that the old
  one should be uninstalled.

## Verify

- After editing, grep the repo to confirm no `snowglobe-connect` invocations
  remain except intentionally-pinned legacy 0.4.x references.
- Confirm every `snowglobe connect` invocation either has `--simulation-id`
  or was deliberately left with a flagged `<SIMULATION_ID>` placeholder.
- Do not run the CLI or network calls; this is a source-edit-only task.

## Report

List each changed file with a one-line description, and a separate list of any
`<SIMULATION_ID>` placeholders that a human still needs to fill in.