@clear-capabilities/agentic-security-scanner 0.195.3 → 0.195.5

package/CHANGELOG.md

@@ -9,6 +9,23 @@
 > make the history less accurate, not more.
 
 
+## 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.
+
+- **The local early release gate is opt-in (`ship --local-gate`).** By default `ship` runs only the eight publish blockers locally after the merge, requires the hosted blocking checks to be green, and leaves the full gate to the hosted release workflow, whose `publish` job needs every leg. What is given up: a local run of the execution half of the release closure before the tag. Nothing is bypassed and no gate was removed from the hosted path.
+- **`TIMINGS` ends with `release-clock=Ns`** (merge, verify, tag and release) when all four phases finished. This is the figure the 10 minute requirement is measured on; the registry's listing delay and the pre-merge work are outside it.
+- **Measurement:** not claimed here. The next `TIMINGS` line from a default `ship` is the first.
+
 ## 0.195.3 - The VS Code extension's build tool no longer pulls in a vulnerable minimatch
 
 Why: the 0.195.2 release workflow stopped at its dependency check. A new advisory (GHSA-g3hv-75wg-m249, moderate, denial of service in minimatch before 11.0.1) reached `ide/vscode` through `@vscode/vsce`, which asks for `minimatch ^10.2.6`. The check passed on the same tree 16 minutes earlier, so the advisory was published during the release. Nothing was published to npm for 0.195.2; its tag exists and points at a commit that failed the gate, so the fix ships as 0.195.3.