@usepowerplant/cli 0.4.10 → 0.4.12

package/README.md

@@ -140,6 +140,9 @@ report the current choice, and `powerplant update --automatic on` or
 release already out installs now rather than at the next hourly check. A
 release that fails to install is not retried by itself; the menu bar shows
 the failure with a retry and the update log, and the next release clears it.
+The one exception is a registry that does not serve the release yet (npm's
+cache can lag a publish by a few minutes): the sync tries that release
+again on its next hourly checks, up to three times, and the menu says so.
 
 Powerplant also publishes the oldest version it still supports. When yours
 is older, `powerplant status`, `powerplant doctor`, the menu bar app, and
@@ -162,7 +165,11 @@ to test `next` while keeping your production install on its promoted version.
    while the service is running. Sleeping machines, disabled updates, and
    failed installs can leave a machine behind. Verify the installed staging
    version and exercise sync and the menu actions you changed before
-   promoting; elapsed time alone is not evidence of testing.
+   promoting; elapsed time alone is not evidence of testing. Promote only
+   after the workflow's "Wait until npm serves the release" step is green:
+   npm's CDN caches the package document for about five minutes after a
+   publish, and a production machine that checks inside that window gets
+   "no matching version" and waits an hour to try again.
 2. **Promote.** From a repo checkout with npm package access and `gh`
    signed in, name the version you tested:
 
@@ -219,11 +226,12 @@ npm install -g --prefix ~/.powerplant-staging @usepowerplant/cli@next
 ~/.powerplant-staging/bin/powerplant init --env staging
 ```
 
-`init --env staging` also points each selected agent's shared `powerplant`
-MCP connection at staging. Separate npm prefixes do not isolate that entry.
-After testing, run `powerplant connect` from your production install to
-restore the agents' production connection; the staging sync service keeps
-running. Include `--env staging` on every staging command.
+`init --env staging` registers its own MCP entry, `powerplant-staging`, in each
+selected agent, beside the production `powerplant` entry. Agents see its tools
+as `mcp__powerplant-staging__*`. A CLI older than this change registered
+staging as `powerplant`: if that entry still points at staging, run a bare
+`powerplant connect` from your production install once to restore it. Include
+`--env staging` on every staging command.
 
 The `@next` pin matters: a bare install resolves `latest`, the production
 channel, so the new staging copy would start on the promoted release and