@clear-capabilities/agentic-security-scanner 0.195.4 → 0.195.6

package/CHANGELOG.md

@@ -9,6 +9,30 @@
 > make the history less accurate, not more.
 
 
+## 0.195.6 - A release has to fit in ten minutes: the push no longer waits for the local suites, a tag push schedules one release leg, and the affected-tests check is cached
+
+Why, for the first two: the requirement is a release in under 10 minutes from the commit. On 0.195.5 the path was 35 minutes: push 1401 s (the local gate), hosted checks 332 s, merge to publish 268 s, and the release workflow spent 3 of its 4.2 minutes waiting for a runner behind seven legs that each ran for 2 seconds and exited.
+
+- **`ship` pushes under the gate's new hosted tier.** `AGENTIC_SECURITY_PUSH_GATE=hosted` runs only the in-process guards (worktree matches the push, blast radius, bundle sidecar, package contents) and skips every suite and bench with its reason printed. The pull request's blocking checks are the merge gate and the hosted release workflow runs the whole gate with the cache off before the publish, so a miss is a red pull request, never a bad release. The background gate the post-commit hook starts still runs: a failure it has recorded stops `ship` before the push, and one it records while the hosted checks run stops `ship` before the merge. `--local-gate` restores the previous push (await the background run, reuse its verdicts) together with the early release gate. A hosted-tier pass is never recorded as a pre-push pass.
+- **A tag push schedules only the `rest` leg of the release workflow.** The matrix `include` is now an expression: every leg on `workflow_dispatch`, `rest` alone on a tag. `scanner/test/release-workflow-structure.test.js` reads both lists out of it; a heavy leg added to the tag list, or an empty tag list, fails the test (two new mutations). The step-level `full_only` guards stay.
+- **The first push of this release was stopped by the hosted checks at 345 s**, not by anything local: `test/release-closure/closure-plan.test.js` read the matrix in its YAML spelling (`group: closure,`) and the expression spells it `"group":"closure"`. It now accepts either. That is the hosted tier working as described: a red pull request, nothing tagged or published.
+- **Expected, not measured:** push about 10 s, hosted checks about 5.5 min (`language-stress` at 309 s is the long pole), merge to publish about 4 min. The next `TIMINGS` line is the measurement, and the registry's own listing delay after the publish is outside it.
+
+Why, for the cache: the 0.195.5 push phase took 23 min 21 s. The post-commit background gate had already passed in 608 s, and the push still ran its own gate for another 790 s. Reading the push log and the verdict cache showed why: every check was reused from the background run (`self-scan-gate`, `ci-parity`, `mutation-gate` and the rest, all `cached (inputs unchanged ...)`) except `test-suite-affected-992dff56`, the affected-tests run (367 of 1029 test files), which has no npm script and was excluded from the cache in both directions by `cacheable = Boolean(check.npmScript)` in `scripts/gate-run-checks.mjs`. It was never looked up and never recorded, so the heaviest check of the fast tier ran twice on every push.
+
+- **An affected-tests check is cached like the full suite.** It is recorded on a pass and reused when the whole-tree key is unchanged. Its id embeds a hash of the selected file list, so a different selection is a different record: a subset pass is never read as another selection's pass, or as the full suite's. A failure is never recorded. Proven both ways: the new test fails on the old executor and passes on the new one.
+- **Expected effect, not yet measured:** the push should take about as long as the background run (about 10 minutes for a change like 0.195.5's) instead of that plus 13 more. The next `TIMINGS` line is the measurement.
+- **Not changed:** the gate's contents, the limits, the test selection or the test concurrency. The background run itself, the 9 minutes of affected tests it executes, is still the floor for a change that touches `scripts/`.
+
+## 0.195.5 - The open release-path items are closed: version bumps keep history, the VS Code types match their floor, and the time-to-first-finding gate is classified and stable
+
+Why: three items were left open after 0.195.4.
+
+- **`release-prepare --bump` replaces the version only where it is the version.** It used to replace every occurrence of the old version in `CLAUDE.md` and `README.md`, so a note such as "(since 0.195.0)" became the new version on the next bump and had to be repaired by hand (it happened on 0.195.1). It now rewrites the `**Version:**` line, the README badge and the `"version"` keys of the JSON files, and nothing else. A test caught a bug in the first draft of this change (a single capture group made the replacement callback append the match offset: `1.2.435`).
+- **`@types/vscode` is pinned exactly at the declared floor, 1.95.0.** The types (`^1.125.0`) were ahead of `engines.vscode` (`^1.95.0`), which made `vsce package` refuse to run, and a caret range would still have resolved to 1.125.0 in the lockfile. The extension builds, type-checks against the 1.95.0 API, packages and audits clean. The supported VS Code range is unchanged. The hold in `.dependency-holds.json` is updated to say it is resolved and why the pin is exact.
+- **`ttff` is classified blocking, and a single slow sample no longer fails it.** The publish gate already treated it as blocking, but it was unlisted, so `ship` ignored it and the 0.195.2 release stopped at verify on one 15.6 s sample against a 15.0 s limit (green on a re-run of the same tree). The limit is unchanged. A miss is now re-measured in two fresh processes (an in-process repeat would be warm) and fails only when the best of three is still over. Checked both ways: a normal run exits 0; against a deliberately impossible baseline it takes three samples and exits 1.
+- **Not changed:** nothing about the release clock, the gates or the hosted workflows.
+
 ## 0.195.4 - `ship` stops running the local early release gate by default, and reports the release clock
 
 Why: on 0.195.3 the hosted checks were green after 6.6 minutes, but the merge waited another 5 minutes for the local early release gate (the release closure on the PR head), which the hosted release workflow's full gate then repeats with the cache off. The release requirement is under 10 minutes from a merged, green `main` to a successful publish.

package/dist/{064fcd1f7550d0cb9b8c.json → af0905b43ac094f334a2.json}

@@ -1,6 +1,6 @@
 {
   "name": "@clear-capabilities/agentic-security-scanner",
-  "version": "0.195.4",
+  "version": "0.195.6",
   "description": "Scanner engine for the agentic-security Claude Code plugin: SAST, SCA with reachability and CISA KEV, secrets, IaC, Haskell and Nix/NixOS, prompt-injection, MCP/agent-tool audit, authZ analysis, SBOM, compliance attestation, and more.",
   "type": "module",
   "main": "src/index.js",