@brokkai/slopcop 0.0.8 → 0.0.9

package/README.md

@@ -101,6 +101,25 @@ installs `slopcop.exe` to `%LOCALAPPDATA%\Programs\slopcop`, and adds that
 directory to the user `Path`. `SLOPCOP_VERSION`, `SLOPCOP_INSTALL_DIR`, and
 `SLOPCOP_NO_MODIFY_PATH` override its defaults.
 
+### Upgrade notice
+
+Every response from the service names its newest release in the
+`SlopCop-Latest-Version` header. When that is newer than the running build,
+the CLI prints one line on stderr, never stdout, so `--format json` and
+`sarif` stay clean:
+
+```text
+slopcop v0.0.9 is available (you have v0.0.7). Upgrade: npm install --global @brokkai/slopcop@latest
+```
+
+The command follows the channel the binary was installed through (npm, npx,
+pip, pipx, or uv), judged by where it lives, and links back here otherwise.
+The notice prints at most once a day; the time of the last one is kept in
+`slopcop/update-notice` next to the config. `dev` builds, `Stop` hook runs, and
+runs with `$SLOPCOP_NO_UPDATE_NOTICE` set to any non-empty value never print
+it. A service that no longer accepts a version answers `client_outdated`
+(HTTP 426), which exits `2`.
+
 ### Go
 
 ```console
@@ -230,7 +249,8 @@ it (it already has an active repository and is charged), the service refuses
 the check with `repository_add_unconfirmed` until a person confirms: at a
 terminal `check` prints what it costs, asks `Add owner/name to "Workspace"?
 [y/N]`, and on a yes sends the check again; with no terminal, as for an agent
-or CI, it exits `2` with the service's remedy. A workspace's first repository
+or CI, it exits `4` with the service's remedy and, in `json`, a `failed`
+report naming the code. A workspace's first repository
 is added without asking. Deleting repositories, archiving
 workspaces, members, credits and repository settings stay in the web app. The
 commands exit `0` on success and `2` with the service's message and remedy
@@ -245,13 +265,19 @@ slopcop --root ../repo --base HEAD~1
 ```
 
 The base commit defaults to the merge base with the branch upstream, then the
-merge base with `origin/HEAD`, then `HEAD`. The service must already have the
+merge base with `origin/HEAD`, then `HEAD` when neither is known. When the
+upstream merge base yields an empty patch, as on a branch whose commits are all
+pushed, the CLI uses the merge base with `origin/HEAD` instead, so a check
+right after a push still covers the branch. The service must already have the
 base commit in its clone; a missing one comes back as the service's
 `base_not_found` message and remedy.
 
 Every run sends one check request, even when the working tree matches the base
 and the patch is empty. A clean result or a failure always comes from the
-service.
+service. A report for an empty patch comes with a note on stderr that suggests
+`--base`, and `json` adds `"emptyChange": true` (`sarif`:
+`properties["slopcop.emptyChange"]`): a clean result then means nothing
+changed was checked.
 
 Flags:
 
@@ -342,8 +368,8 @@ summary line such as `1 new finding across 1 file(s); 72 already in the code |
 Analysis complete`, and any omitted new findings or
 incomplete checks. `json` prints `status`, `baseCommit`, `summary`
 (`newFindings` and `existingFindings` count the split), `findings` (each with
-`new` and its `id`), `incomplete`, and `failure` when the analysis did not
-complete. `sarif` prints a SARIF 2.1.0 log whose results carry `baselineState`
+`new` and its `id`), `incomplete`, `failure` when the analysis did not
+complete, and `emptyChange` when the patch was empty. `sarif` prints a SARIF 2.1.0 log whose results carry `baselineState`
 `new` and the finding id in `properties["slopcop.findingId"]`. `--format` only
 changes the rendering, never the request, so the service answers the same check
 whichever is used.
@@ -354,6 +380,7 @@ whichever is used.
 | `1` | A new finding crossed `--fail-on` |
 | `2` | No new finding crossed `--fail-on`, but a check was incomplete; or the CLI or service failed |
 | `3` | The check was still running when `--timeout` ran out |
+| `4` | The service refused the check, and only a person can clear it |
 | `130`, `143` | Interrupted before the check answered: `130` for Ctrl-C, `143` for SIGTERM |
 
 Only `clean` exits `0`: a status this CLI does not know exits `2`, so a newer
@@ -394,8 +421,20 @@ after some: `slopcop login` when the remedy is to sign in, the listing to
 choose from after `workspace_not_found` or `workspace_repository_not_found`,
 and `slopcop whoami` after `repository_disabled`, since the workspace that
 disabled it is the one this login is bound to, and `--workspace` after
-`owner_required`. A failed request prints no
-report on stdout.
+`owner_required`. A failed check exits `4` when only a person can clear the
+refusal (`auth_required`, `auth_expired`, `account_required`,
+`repo_not_indexed`, `app_not_installed`, `app_no_repo_access`,
+`gitlab_not_connected`, `no_access`, `insufficient_credits`,
+`repository_disabled`, `repository_add_unconfirmed`,
+`workspace_repository_limit_reached`, `active_repository_limit_reached`,
+`owner_required`, and `browser_required`), so a script can stop instead of
+retrying, and `2` otherwise. Stderr starts with the code, as in `slopcop:
+repository_add_unconfirmed: …`. `human` prints nothing on stdout; `json`
+prints `{"status": "failed", "code": …, "message": …, "remedy": …,
+"retryable": …}`, plus `installUrl` or `topUpUrl` when the service sent one;
+`sarif` prints a run with `slopcop.status` `failed`, whose invocation is
+unsuccessful and carries an `error` notification whose descriptor id is the
+code.
 
 ## API
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@brokkai/slopcop",
-  "version": "0.0.8",
+  "version": "0.0.9",
   "description": "Static analysis for coding agents and CI: check a change through the hosted SlopCop API",
   "keywords": [
     "agents",