pi-agent-browser-native 0.9.7 → 0.9.8

package/CHANGELOG.md

@@ -2,6 +2,19 @@
 
 ## Unreleased
 
+## 0.9.8 - 2026-11-01
+
+<!-- npm-release:unreleased:start -->
+<!-- npm-release:unreleased:end -->
+
+- Skip release inference when the packed runtime is unchanged (#342) ([deda9b2](https://github.com/fitchmultz/pi-agent-browser-native/commit/deda9b225865e6277018a5ee1144f4bebad0354d))
+
+### What's Changed
+
+- Skip release inference when the packed runtime is unchanged by @fitchmultz in https://github.com/fitchmultz/pi-agent-browser-native/pull/342
+
+**Full Changelog**: https://github.com/fitchmultz/pi-agent-browser-native/compare/v0.9.7...v0.9.8
+
 ## 0.9.7 - 2026-11-01
 
 <!-- npm-release:unreleased:start -->

package/docs/RELEASE.md

@@ -99,7 +99,9 @@ PI_AGENT_BROWSER_RELEASE_TARBALL=/absolute/path/to/candidate.tgz \
 
 Package verification inspects the supplied archive and its packaged Markdown, checks its name, version, and integrity, and installs a private copy of those same bytes for the isolated Pi smoke. The configured-source lifecycle installs a private copy of the candidate and adds its test-only sentinel to that copy's compiled entrypoint for reload/relaunch checks. The required platform-build suites still pack their target-local checkout, then install the supplied candidate and check its SHA-256 before and after installation on each target. The verifier does not rebuild or delete the supplied file. The caller must compare the candidate with the shared preparation receipt before and after qualification and publish those verified bytes.
 
-The reusable `release-qualification.yml` runs the same candidate against the selected official and fork Pi hosts. It runs the default verification and package/lifecycle checks, plus `scripts/verify-live-sites.mjs`: an interactive Pi session visits CERN and React documentation, navigates an observed ref, verifies a screenshot delivered to a vision model, reloads, and closes its owned browser. The hosted checks use `zai/glm-5.3-flash` with `ZAI_API_KEY` from the main-only `release` environment. The macOS SSH and Ubuntu container Crabbox jobs run both required suites on separate native runners, each checking the candidate identity before and after. Windows remains best-effort.
+The reusable `release-qualification.yml` runs the same candidate against the selected official and fork Pi hosts. Default verification, packaged Pi loading, and the macOS/Ubuntu Crabbox suites run without inference. Before model-backed checks, `scripts/release-live-scope.mjs` compares every packed `dist/` file and the module-loading, dependency, engine, and Pi resource declarations with the actual latest npm package. These are the Pi agent runtime inputs. Version, docs, workflow, verification-harness, and standalone CLI changes alone reuse the published agent runtime's live evidence. CLI scripts remain covered by default verification and packaged CLI probes, not model-backed browser sessions. The retained scope receipt identifies both tarballs and records changed runtime paths; an unchanged runtime records `not_required`, not a new live pass. A baseline lookup or extraction failure stops qualification without making model calls.
+
+When the packed Pi agent runtime changes, the selected-host job runs lifecycle checks and `scripts/verify-live-sites.mjs`: an interactive Pi session visits CERN and React documentation, navigates an observed ref, verifies a screenshot delivered to a vision model, reloads, and closes its owned browser. These necessary hosted calls use only direct `zai/glm-5.3-flash`, with `ZAI_API_KEY` from the main-only `release` environment. The key is required only for this branch. The macOS SSH and Ubuntu container Crabbox jobs run both required suites on separate native runners, each checking the candidate identity before and after. Windows remains best-effort.
 
 When using the documented, maintainer-approved [local macOS alternative](platform-smoke.md#alternate-native-transports), run and inspect that target-local suite separately alongside the remaining release checks. The default composition still requires macOS/Ubuntu; alternate evidence must not be labeled a passing Crabbox matrix.
 
@@ -133,7 +135,7 @@ The Crabbox gate is only green when suite assertions and artifact manifests unde
 
 The deterministic dogfood mode clean-builds the compiled package, uses the extension harness and real `agent-browser` on `PATH` against a deterministic loopback HTTP fixture, then verifies persistent browser code aggregation, flat advanced QA/actions, native batch, screenshot artifact verification, and explicit session close. Use `npm run verify -- dogfood --keep-artifacts` or `--artifact-dir <path>` only while debugging, then delete retained screenshots. This smoke complements, but does not replace, human-readable interactive transcript evidence.
 
-Every release also requires interactive `tmux`-driven Pi dogfood with the native `agent_browser` tool against real sites. For extension-focused release smokes, use `pi --approve --no-extensions --no-skills -e .` from the trusted checkout before publish so auto-loaded dogfood/QA skills cannot replace the bounded smoke workflow; omit `--approve` only when the smoke is explicitly testing Pi's Project Trust prompt. Run separate skill-enabled dogfood only when validating skill routing or report-generation behavior. Drive prompts with `tmux send-keys`, exercise at least one simple static site and one real documentation/product site, include advanced QA, code, or native batch when those surfaces changed, close every opened browser session, remove screenshots/temp artifacts, and record the outcome in the release notes or support-matrix evidence. Do not paste raw multi-line prompts into a tmux Pi pane: plain newlines submit separate queued user messages. For scripted smoke driving, collapse prompt files to one line before sending (`PROMPT=$(tr '\n' ' ' < /tmp/smoke-prompt.md); tmux send-keys -t "$SESSION":0.0 -l "$PROMPT"; tmux send-keys -t "$SESSION":0.0 Enter`). For manual multi-line editing, use Pi's external editor shortcut (`Ctrl+G`) or configure tmux extended keys so Pi can receive `Shift+Enter` for newlines; see the installed Pi `docs/tmux.md` guidance. Automated localhost, fake-upstream, and deterministic dogfood gates do not replace this human-readable live-site transcript evidence. When code changes, add a persisted-session `agent_browser_code` pass that aggregates at least two real pages, exercises a conditional branch, compares selected output with an ordinary-call baseline, verifies selected screenshot bytes reach the model, and checks browser/auth continuity on a later direct/code call with fresh JS globals. Review ordered custom transition entries and interrupted/replayed state, not only the outer result. Exercise handled failures, timeout/cancellation, whole-cell ordering, and child reaping; close only test-owned browsers afterward and retain Pi transcripts. Never use `--no-session` for code dogfood. When `agent_browser_web_search` or package config changed, add one key-free smoke proving the optional tool is absent without config, one fake/unit-backed smoke in the default suite, and one opt-in live Exa or Brave Search check with a real key while confirming the key does not appear in transcripts, stdout/stderr, config status, PR text, or artifacts. When `electron.*` surfaces, attached-session diagnostics, or `qa.attached` changed, add a local Electron pass against a disposable fixture app, never the operator's installed desktop apps such as Slack or Obsidian: wrapper launches open real app windows on the operator's desktop even with isolated profiles. Install the stock `electron` npm package into a temp directory (run its `install.js` if npm skipped the binary download) next to a minimal app whose hidden window (`new BrowserWindow({ show: false })`, plus `app.setActivationPolicy('prohibited')` and `app.dock?.hide()` on macOS) loads a known page so nothing appears on the operator's desktop, then run `electron.list` (discovery only) → `electron.launch` with `executablePath` set to that package's Electron binary and `appArgs` set to the fixture app directory (expect isolated profile behavior) → `snapshot -i` or `electron.probe` / `qa.attached` → `electron.cleanup` with the returned `launchId`, verifying status/mismatch guidance if you simulate a dead renderer or stale refs. Delete the fixture afterwards. For dense-dashboard stress coverage, use the [public Grafana stress checklist](#public-grafana-stress-checklist) below; it is a maintainer workflow, not bundled product skill or recipe runtime.
+Releases that change the Pi agent runtime also require interactive `tmux`-driven Pi dogfood with the native `agent_browser` tool against real sites. For extension-focused release smokes, use `pi --approve --no-extensions --no-skills -e .` from the trusted checkout before publish so auto-loaded dogfood/QA skills cannot replace the bounded smoke workflow; omit `--approve` only when the smoke is explicitly testing Pi's Project Trust prompt. Run separate skill-enabled dogfood only when validating skill routing or report-generation behavior. Drive prompts with `tmux send-keys`, exercise at least one simple static site and one real documentation/product site, include advanced QA, code, or native batch when those surfaces changed, close every opened browser session, remove screenshots/temp artifacts, and record the outcome in the release notes or support-matrix evidence. Do not paste raw multi-line prompts into a tmux Pi pane: plain newlines submit separate queued user messages. For scripted smoke driving, collapse prompt files to one line before sending (`PROMPT=$(tr '\n' ' ' < /tmp/smoke-prompt.md); tmux send-keys -t "$SESSION":0.0 -l "$PROMPT"; tmux send-keys -t "$SESSION":0.0 Enter`). For manual multi-line editing, use Pi's external editor shortcut (`Ctrl+G`) or configure tmux extended keys so Pi can receive `Shift+Enter` for newlines; see the installed Pi `docs/tmux.md` guidance. Automated localhost, fake-upstream, and deterministic dogfood gates do not replace this human-readable live-site transcript evidence. When code changes, add a persisted-session `agent_browser_code` pass that aggregates at least two real pages, exercises a conditional branch, compares selected output with an ordinary-call baseline, verifies selected screenshot bytes reach the model, and checks browser/auth continuity on a later direct/code call with fresh JS globals. Review ordered custom transition entries and interrupted/replayed state, not only the outer result. Exercise handled failures, timeout/cancellation, whole-cell ordering, and child reaping; close only test-owned browsers afterward and retain Pi transcripts. Never use `--no-session` for code dogfood. When `agent_browser_web_search` or package config changed, add one key-free smoke proving the optional tool is absent without config, one fake/unit-backed smoke in the default suite, and one opt-in live Exa or Brave Search check with a real key while confirming the key does not appear in transcripts, stdout/stderr, config status, PR text, or artifacts. When `electron.*` surfaces, attached-session diagnostics, or `qa.attached` changed, add a local Electron pass against a disposable fixture app, never the operator's installed desktop apps such as Slack or Obsidian: wrapper launches open real app windows on the operator's desktop even with isolated profiles. Install the stock `electron` npm package into a temp directory (run its `install.js` if npm skipped the binary download) next to a minimal app whose hidden window (`new BrowserWindow({ show: false })`, plus `app.setActivationPolicy('prohibited')` and `app.dock?.hide()` on macOS) loads a known page so nothing appears on the operator's desktop, then run `electron.list` (discovery only) → `electron.launch` with `executablePath` set to that package's Electron binary and `appArgs` set to the fixture app directory (expect isolated profile behavior) → `snapshot -i` or `electron.probe` / `qa.attached` → `electron.cleanup` with the returned `launchId`, verifying status/mismatch guidance if you simulate a dead renderer or stale refs. Delete the fixture afterwards. For dense-dashboard stress coverage, use the [public Grafana stress checklist](#public-grafana-stress-checklist) below; it is a maintainer workflow, not bundled product skill or recipe runtime.
 
 When reviewing saved session JSONL after a failed smoke or QA reclassification, expect browser tool rows to carry `isError: true` whenever `details.resultCategory` is `failure`. The model-visible observation must also report failure. Canonical JSON stays parseable and unchanged. Final public results return `isError` directly, with a prose failure notice outside explicit JSON, so Pi's transcript matches the wrapper contract ([`TOOL_CONTRACT.md`](TOOL_CONTRACT.md#details)). Preserve a normal Pi session directory for those checks; avoiding `--no-session` keeps this evidence intact ([`AGENTS.md`](https://github.com/fitchmultz/pi-agent-browser-native/blob/main/AGENTS.md) preferred validation workflow).
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "pi-agent-browser-native",
-	"version": "0.9.7",
+	"version": "0.9.8",
 	"description": "pi extension that exposes agent-browser as a native tool for browser automation",
 	"type": "module",
 	"author": "Mitch Fultz (https://github.com/fitchmultz)",