@brokkai/slopcop 0.0.9 → 0.0.11

package/README.md

@@ -145,9 +145,22 @@ present, and names what it did:
 A skill that is already there is left alone by init, so running it again is
 safe. `slopcop login` and every check also install the skill in those
 directories, rewriting one that differs from the skill bundled into the binary,
-so an agent follows the instructions of the slopcop version it runs; local
-edits to an installed skill do not survive them. `slopcop init --no-skill`
-skips the install and any update of it.
+so an agent follows the instructions of the slopcop version it runs. Each
+install records the version that wrote it, and what each file held, in
+`.slopcop-skill.json` in the skill folder. An update names the version it
+replaces, the new one and the files that changed, for example:
+
+```
+slopcop: updated the slopcop skill at ~/.claude/skills/slopcop from v0.0.9 to v0.0.10 (changed: SKILL.md). Reread it if you loaded the old one.
+```
+
+It removes the files the new skill no longer has. A skill with local edits,
+one that matches neither its record nor any release, is copied first to
+`skill-backups/<harness>-<time>` next to the slopcop configuration, outside
+every skills directory so no harness loads it as a second skill, and the
+notice says where. A check's `json` and `sarif` reports carry the same update
+(see below). `slopcop init --no-skill` skips the install and any update of
+it.
 
 Init also adds a `Stop` hook for each harness installed here, and leaves
 everything else in the file as it was:
@@ -166,13 +179,28 @@ When the agent stops, the hook checks the working tree through the same
 hosted API, but only when all of these hold:
 
 - the session wrote files in the repository with its edit tools (a Codex
-  session's subagents included);
+  session's subagents included), or the working tree has a changed
+  dependency manifest or lockfile (see below);
 - slopcop is signed in, and the workspace a check would use
   (`$SLOPCOP_WORKSPACE`, or the login's) has the repository active
   (`slopcop repo list`), so nothing is sent from other repositories;
 - the tree differs from the last check in the session, including a check the
   agent ran by hand.
 
+An agent often adds a dependency through its shell, with `npm install`,
+`pnpm add`, `cargo add` or `uv add`, which no edit tool records. So the hook
+also checks when git shows one of these files changed, added or untracked in
+any directory of the repository: `package.json`, `package-lock.json`,
+`npm-shrinkwrap.json`, `pnpm-lock.yaml`, `yarn.lock`, `Cargo.toml`,
+`Cargo.lock`, `pyproject.toml`, `uv.lock`, `poetry.lock`, `requirements*.txt`,
+`go.mod` and `go.sum`. Files git ignores and those under `node_modules` do
+not count. The hook recognises these files by name only: it never reads
+them, runs a package manager or asks an advisory database; the hosted check
+reads them like any other file in the change. A changed dependency file
+counts as one the session wrote, since the hook cannot tell which command
+changed it, so its new findings are handed to the agent like those in files
+it edited, even if the file was already changed when the session began.
+
 New findings in files the session wrote are handed to the agent to fix, once
 for a given tree and at most twice in a row; then the agent is let go and you
 are told what remains. A finding ignored with `slopcop ignore` is not handed
@@ -197,8 +225,10 @@ slopcop login                           # browser device flow
 slopcop login --token "$SLOPCOP_TOKEN"  # existing credential, for CI and agents
 ```
 
-The browser flow prints a URL and a code and stores the token once the login is
-approved. The service URL defaults to `https://slopcop.com`; `--service`,
+The browser flow prints a link that opens the approval page with the code
+filled in, plus the page and code to type in instead, and stores the token once
+the login is approved. Approve only if the page shows the code your terminal
+printed. The service URL defaults to `https://slopcop.com`; `--service`,
 `$SLOPCOP_SERVICE`, or a stored value override it.
 
 The credential lives in `slopcop/config.json` under the user config directory
@@ -248,29 +278,43 @@ add`: a first check adds a repository. When the workspace would then pay for
 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 `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
-otherwise, as `ignore` does.
+[y/N]`, and on a yes sends the check again and says `added owner/name to
+"Workspace"` on stderr. With no terminal, as for an agent or CI (a pipe or the
+null device is not one), nothing is asked: the check exits `4` with the
+service's remedy, a line naming the command that confirms it, and, in `json`,
+a `failed` report naming the code. A no at the terminal ends the same way.
+Once the person has approved it, `check --add-repository --workspace
+<name|id>` confirms without a terminal; the flag needs `--workspace` (the
+flag itself, not `$SLOPCOP_WORKSPACE`), so an approval given for one
+workspace cannot add the repository to the one the login happens to point at.
+The flag changes nothing for a repository already in that workspace. 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 otherwise, as `ignore` does.
 
 ## Check
 
 ```console
 slopcop                          # check the change in the current checkout
 slopcop check --format json      # same, machine-readable
-slopcop --root ../repo --base HEAD~1
+slopcop --root ../repo --base origin/main
 ```
 
 The base commit defaults to the merge base with the branch upstream, then 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.
+right after a push still covers the branch. `--base REV` names the branch the
+change started from and, like `git diff REV...HEAD`, uses the merge base of
+`REV` and `HEAD`, so commits that landed on `REV` after the branch point are not
+sent as reverse edits. `--base-exact REV` diffs against `REV` itself. 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. The CLI then asks origin for its default
+branch (`git ls-remote`, no prompt, 10 second limit) and adds a line when the
+clone explains the failure: origin's default branch was renamed and
+`origin/HEAD` still names the old one, or the base is not on origin's default
+branch.
 
 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
@@ -284,14 +328,16 @@ Flags:
 | Flag | Meaning |
 | --- | --- |
 | `--root PATH` | repository to check (default `.`) |
-| `--base REV` | base commit or revision for the change |
+| `--base REV` | branch or revision the change started from; the base is its merge base with `HEAD` |
+| `--base-exact REV` | exact base commit or revision, without a merge base |
 | `--format human\|json\|sarif` | report format (default `human`) |
 | `--fail-on never\|finding\|note\|warning\|error` | exit-1 threshold for new findings (default `finding`) |
 | `--policy PATH` | repository-relative `.rqlp` file to evaluate (repeatable) |
 | `--no-policy-discovery` | skip `.slopcop/policies` rules |
 | `--timeout DURATION` | how long to wait for the result (default `10m`) |
 | `-w`, `--workspace NAME\|ID` | check in, and bill, this workspace of the account instead of the login's |
-| `--verbose` | print the resolved request to stderr |
+| `--add-repository` | add the repository to the workspace `--workspace` names, which then pays for it, without asking at a terminal; for after the user approved it |
+| `--verbose` | print the resolved request to stderr, and name each inconclusive check in `human` |
 
 ### What is sent
 
@@ -368,8 +414,13 @@ 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`, `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 its `id`), `incomplete`, `inconclusive`, `failure` when the analysis did not
+complete, and `emptyChange` when the patch was empty. When the check
+installed or updated the skill, `skillUpdated` lists each skill directory it
+wrote: `dir`, `from` (a release, `unknown`, or absent for a fresh install),
+`to`, `changed` and, for a skill with local edits, `backup`; the failed and
+pending reports carry it too, and `sarif` puts it in
+`properties["slopcop.skillUpdated"]`. `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.
@@ -390,10 +441,18 @@ reached the service; after, a service that received it keeps running it, and
 running the same check again picks up its result.
 
 An inconclusive check, one that ran but could not prove there is nothing
-more to find, never changes the exit code and is not named in any format.
-Complete proof is rare in static analysis, typically at a library boundary,
-so this is the norm rather than a gap. `summary.inconclusive` counts them in
-`json`, as does `slopcop.inconclusive` in `sarif`. A check that timed out or
+more to find, never changes the exit code or the status. Complete proof is
+rare in static analysis, typically at a library boundary, so this is the norm
+rather than a gap. Each report still says where they are, so a reviewer can
+judge what a `clean` result is worth: `human` prints one `Inconclusive:` line
+with the count and how many concern only files the change does not write, and
+`--verbose` names each check. `json` lists them in `inconclusive`, each with
+`policyId`, `reason` and `elsewhere` (true when it concerns only files the
+change does not write), beside the `summary.inconclusive` count. `sarif` adds
+a `note` notification per check with `slopcop.inconclusive` and
+`slopcop.elsewhere` properties. The service names at most 50; the counts
+cover the rest. It does not yet say which files or lines each one concerns,
+or what evidence was missing. A check that timed out or
 that Bifrost judged unreliable is incomplete and counts wherever it is.
 
 The service applies `--fail-on` and sets the status; the exit code follows it.
@@ -420,9 +479,11 @@ rewrite them. The remedies name no client, so the CLI adds its own command
 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 check exits `4` when only a person can clear the
-refusal (`auth_required`, `auth_expired`, `account_required`,
+disabled it is the one this login is bound to, `--workspace` after
+`owner_required`, and `--add-repository --workspace "Name"`, with the
+workspace the check would have added the repository to, after
+`repository_add_unconfirmed`. 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`,
@@ -451,11 +512,11 @@ The CLI calls `POST <service>/v1/check` with a bearer token:
 }
 ```
 
-`addRepository` is sent only after a person confirms adding the repository. The
-service rejects any other field. With `--workspace`, every request, the
-check's, the ignore's and the account routes', carries the workspace's id in
-the `SlopCop-Workspace` header; a name is first looked up with
-`GET <service>/v1/whoami`. The response carries `status`,
+`addRepository` is sent only after a person confirms adding the repository, at
+the terminal or with `--add-repository`. The service rejects any other field.
+With `--workspace`, every request, the check's, the ignore's and the account
+routes', carries the workspace's id in the `SlopCop-Workspace` header; a name
+is first looked up with `GET <service>/v1/whoami`. The response carries `status`,
 `baseCommit`, `applied`, `summary`, `findings`, `incomplete`, and `failure`
 when the analysis did not complete. Against a service from before findings
 were marked `new`, the CLI treats every finding as new, as that service gated

package/package.json

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