@sr-connect/cli 0.1.0 → 0.1.2

package/README.md

@@ -8,7 +8,7 @@ npm i -g @sr-connect/cli             # then: sr-connect
 npx @sr-connect/cli cli get-readme   # prints this document from the installed copy
 ```
 
-Node 22 or newer. An older runtime gets one warning line per run and most commands still work, but live log streaming does not. Every example below spells the CLI as `npx @sr-connect/cli`, which is also how it refers to itself in its own hints. For daily use install it globally: `npx` spends most of a second resolving the package before the CLI starts, and the installed `sr-connect` answers in a fraction of that.
+Node 22 or newer. An older runtime gets one warning line per run and most commands still work, but live log streaming does not. Every example below spells the CLI as `npx @sr-connect/cli`. For daily use install it globally: `npx` spends most of a second resolving the package before the CLI starts, the installed `sr-connect` answers in a fraction of that, and a global install refers to itself as `sr-connect` in its own hints rather than telling you to run `npx`.
 
 ## Getting started
 
@@ -49,7 +49,7 @@ A **workspace lock** rides the same record but is not a default, so clearing the
 
 `local-workspace clone` writes a workspace to disk as a TypeScript project: one file per script under `scripts/`, one module per API connection under `scripts/api/`, the parameter types in `ev-params.ts`, the README, the test payloads, and a `workspace.json` recording where it all came from. Open it in an editor, get type checking against the real API packages, commit it to git.
 
-**The clone answers the scope questions.** Any command run at or below the directory takes its team, workspace and environment from `workspace.json`. On a terminal you are asked once, `Use the local workspace in ~/dev/x …?`. Without one the CLI prints a note and carries on, so this applies to agents as much as to people. A flag that names a different team or workspace wins, and the whole record is set aside for that run with a note, so the other two have to be passed as well. A flag naming a different environment of the same workspace keeps the record's team and workspace and replaces only the environment, which is how `-e <staging>` inside a clone of `Default` reads the other environment. `--no-local-workspace` switches the behaviour off.
+**The clone answers the scope questions.** Any command run at or below the directory takes its team, workspace and environment from `workspace.json`. On a terminal you are asked once, `Use the local workspace in ~/dev/x …?`. Without one the CLI prints a note and carries on, so this applies to agents as much as to people. A flag that names a different team or workspace wins, and the whole record is set aside for that run with a note, so the other two have to be passed as well. A flag naming a different environment of the same workspace keeps the record's team and workspace and replaces only the environment, which is how `-e <staging>` inside a clone of `Default` reads the other environment. **The destructive verbs are the exception** — the ones taking `--yes` read neither the record nor a session default unless a human is there to see the confirmation naming what is about to go, so a scripted `script delete` inside a clone still has to pass `-w`, `-e` and `--team` (their flags say `session default on a TTY only`, their `--explain` spells out what that leaves out, and the exit 2 names the rule). `--no-local-workspace` switches the behaviour off.
 
 Commands that change something the clone contains also keep the clone current. See [Local sync](#local-sync).
 
@@ -400,6 +400,7 @@ npx @sr-connect/cli event-listener update --explain
 ### cli
 
 - `cli get-readme` — Print the CLI's own README
+- `cli check-updates` — Check the NPM registry for a newer version of this CLI
 - `cli settings` — View or change the CLI's own switches
 - `cli set-session` — Remember team/workspace/environment as defaults for this shell session
 - `cli clear-session` — Forget the session defaults for this shell session