@usepowerplant/cli 0.4.4 → 0.4.5

package/README.md

@@ -24,7 +24,11 @@ re-run at any time — finished steps are skipped with a note:
    ones in scope. If recent sessions name repositories under a macOS-protected
    location such as Documents, init lists the location and asks before reading
    Git metadata there; declining leaves those sessions local. The service
-   starts on login and keeps itself running.
+   starts on login and keeps itself running. On macOS, init also installs
+   the Powerplant menu bar app from this package into `~/Applications` and
+   launches it; the app registers itself to start at login (turn that off
+   from its More menu), and the background service keeps it on the same
+   version as the CLI after every update.
 3. **Add MCP to your agents.** Init lists the agents it found — Claude Code,
    Codex, and Cursor — as checked boxes. They all start selected; use the arrow
    keys and Space to turn off any you want to skip, then press Enter (`--yes`,
@@ -98,6 +102,9 @@ day-to-day upload path on machines that can't run it; asked for explicitly, it
 still runs while paused and says so. `disconnect` is the
 inverse of `connect`: it removes each agent's Powerplant MCP entry and the
 sign-in stored with it, and agents that were never connected just say so.
+Use `powerplant disconnect --client claude` to remove only Claude's connection.
+The `--client` option also accepts `codex` and `cursor`, and can be repeated.
+Omitting it disconnects all detected agents.
 
 ## Updating
 
@@ -136,34 +143,43 @@ it is no longer tested or fixed, so update when you see it.
 
 ### How a release reaches production
 
-Every release is published to npm as `latest`. Machines pinned to the
-staging environment (and our own development and agent machines) follow
-npm, so a release soaks on our own machines first. Production machines
-never follow npm: they ask the production API which version is promoted
-and install exactly that, pinned. When a release has held up on staging,
-dispatch the Promote CLI workflow with the version; production machines
-with automatic updates install it within the hour, and everyone else sees
-it in the menu bar and `powerplant status`. Until something is promoted,
-production sees no update at all, only the supported-version floor.
-Promoting an older version than the current one is a hold: production
-stops advancing, and no machine downgrades. A bad release is undone by a
-new release and a new promotion.
+Every release is published to npm's `next` dist-tag. Machines pinned to
+the staging environment (and our own development and agent machines)
+follow `next`, so a release runs on our own machines first. Production
+machines never follow npm: they ask the production API which version is
+promoted and install exactly that, pinned. When a release has held up on
+staging, dispatch the Promote CLI workflow (leave the version blank to
+promote what `next` points at) with a current one-time code for the
+`forestwalklabs` npm account from 1Password: it moves npm's `latest` to
+the same artifact staging tested, so a fresh `npm install -g` always gets
+exactly what production runs, and points production machines at it;
+machines with automatic updates install it within the hour, and everyone
+else sees it in the menu bar and `powerplant status`. Until something is
+promoted, production sees no update at all, only the supported-version
+floor. Promoting an older version than the current one is a hold:
+production stops advancing, `latest` moves back for new installs, and no
+enrolled machine downgrades. A bad release is undone by a new release and
+a new promotion.
 
 ### Staging beside production on one Mac
 
 A machine has one global `powerplant` by default, and the background sync
-for each environment runs whatever copy `init` was run from. To soak
+for each environment runs whatever copy `init` was run from. To try
 releases on staging while production keeps the promoted version, give
 staging its own copy under its own npm prefix and set it up from there:
 
 ```bash
-npm install -g --prefix ~/.powerplant-staging @usepowerplant/cli
+npm install -g --prefix ~/.powerplant-staging @usepowerplant/cli@next
 ~/.powerplant-staging/bin/powerplant init --env staging
 ```
 
+The `@next` pin matters: a bare install resolves `latest`, the production
+channel, so the new staging copy would start on the promoted release and
+test nothing until its first update.
+
 The staging daemon runs that copy and updates it in place (the updater
 pins npm to the prefix the running copy lives under), so
-`~/.powerplant-staging` follows npm's newest release while the production
+`~/.powerplant-staging` follows the `next` channel while the production
 install follows the promoted one. Run staging commands through that path,
 `~/.powerplant-staging/bin/powerplant status --env staging`, or put the
 directory on your PATH after the production one. `powerplant doctor` names