@brokkai/slopcop 0.0.10 → 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
@@ -307,7 +337,7 @@ Flags:
 | `--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 |
 | `--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 |
+| `--verbose` | print the resolved request to stderr, and name each inconclusive check in `human` |
 
 ### What is sent
 
@@ -384,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.
@@ -406,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.

package/package.json

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