Release status#

PacketBench is not distributed the way a finished desktop app is. The source tree is at 0.13.1, Windows installers exist for five versions and have never been uploaded anywhere, nothing is code signed, and there is no auto-updater. None of that is an oversight to be worked around; it is the current state, and every consequence of it is listed below.

This page records what has been built, what has been published, what has been signed, and what the packaged acceptance matrix has actually proved. Read it before you decide how to get PacketBench onto a machine — Install & first run then tells you how.

Three things that are easy to confuse#

Source, local builds, and published downloads are three different artefacts at three different versions.

Every build in that middle row is recorded in CHANGELOG.md with its filename, size, SHA-256, and the commit it was built from. That table is the only integrity check available for an unsigned installer, so check a build against it before running it. Each artifact maps to exactly one commit because builds are made from a committed tree with a clean working directory — an earlier 0.12.0 pair that spanned a source edit was deleted for failing that rule, on the grounds that an installer you cannot attribute is worse than none.

The published download is one rename behind#

The newest release asset set on GitHub is v0.5.0 from 4 May 2026, and its files are named PacketADE_0.5.0_x64-setup.exe, PacketADE_0.5.0_x64_en-US.msi and packetade-0.5.0-x64.exe — the product was still called PacketADE then. It was renamed to PacketBench on 2026-08-26.

So the published installer installs an app called PacketADE; predates the Flight Deck rework, the agent picker as it now stands, the sidecar protocol v6–v11 additions, project memory and dictation analytics; and is not an upgrade path to current code, because there is no updater to carry you forward from it.

Two later tags exist — v0.10.2 (2026-07-28) and v0.10.3 (2026-08-02) — and their artifacts were deliberately not published. The 0.10.2 release record is explicit that the builds are "local build evidence; they are not signed, uploaded, or claimed as trusted public distribution" (dev/release-v0.10.2.md:44-46). A tag in this repository is not a release.

Nothing is code signed#

There is no Windows Authenticode certificate and no Apple Developer ID. src-tauri/tauri.conf.json carries no bundle.windows block at all, and its bundle.macOS block carries only minimumSystemVersion. Every artifact table in CHANGELOG.md, for every version, says unsigned.

The release gate refuses to count the updater key as a signature#

pnpm release:gate:strict adds --require-clean --require-signing --require-updater to the ordinary gate (package.json:47). Those checks are opt-in precisely because the credentials do not exist.

The signing check deliberately excludes TAURI_SIGNING_PRIVATE_KEY from counting as a code-signing credential (scripts/release-gate.mjs:250-258). Installer code signing and updater signing are unrelated credentials protecting different things: the minisign keypair signs update manifests and says nothing about whether the installer carries a trusted publisher signature. Counting it produced a "Signing credentials present" pass on a build with zero Authenticode configuration, which is the exact failure a signing gate exists to prevent. The gate now names which platform credential is missing and adds a warning if the updater key is set while no code-signing credential is.

There is no auto-updater#

dev/updater-setup.md is a runbook, not a shipped feature. There is no tauri-plugin-updater dependency in src-tauri/Cargo.toml, no tauri_plugin_updater::init() in src-tauri/src/lib.rs, and the Tauri config has no plugins key at all, let alone plugins.updater. Status: Planned.

The runbook describes a full-installer strategy. Diff-patch updates are deliberately out of scope because of the bundled sidecar and the externalBin Node runtime. Enabling it needs a signing keypair and an HTTPS update server, both intentionally deferred, which is why it is an ops task rather than a code change.

New versions are installed manually. Installing a newer package over an older one does work on Windows — see below — but nothing in the app will tell you a newer version exists.

macOS and Linux have never been published#

No macOS or Linux artifact has ever been uploaded, and none appears in any CHANGELOG.md artifact table. Every recorded build for every version is Windows NSIS + MSI.

That is not the same as untested. macOS builds, bundles a DMG, and runs from source, and has been run on a Mac by the maintainer for months; three June 2026 commits fix defects that can only be observed on real Apple hardware. What it has never been is signed, notarized, or interactively accepted (dev/multi-platform-build.md:115). dev/macos-release-plan.md owns Developer ID, entitlements, hardened runtime, notarytool and stapling end to end, and its status line reads "ACTIVE PLAN — not executed. No step below has been run."

The asymmetry that keeps macOS unpublished is stated in that plan: on Windows an unsigned build can ship publicly with hashes and a SmartScreen warning, and on current macOS an unsigned, unnotarized downloaded app has no equivalent contingency.

Linux is build-from-source only. Debian dependencies are declared in the bundle config — libgtk-3-0, libwebkit2gtk-4.1-0, libasound2 — and distributions that ship libwebkit2gtk-4.0 instead of 4.1 (Ubuntu 20.04 and older) reject the binary.

What the acceptance matrix has actually proved#

dev/acceptance.md is the packaged acceptance matrix, currently targeting 0.13.1. It is one evolving checklist rather than a per-release artifact, and its filename carries no version deliberately: renaming it on every retarget permanently broke every link that pointed at it, to the point where the 0.12.0 and 0.12.1 entries in CHANGELOG.md cited a filename that had not existed for two releases.

Counted from the checkboxes in that file:

Sections 2–5 are substantially unrun, and the reason it matters is quoted in the matrix itself from dev/proof-audit-2026-08-01.md: "fresh binaries prove compilation and bundling only." Most green ticks in CHANGELOG.md for those sections still describe source tests, not packaged runs. Section 3 needs a person at the keyboard with a headset attached — the Bluetooth salvage paths cannot be confirmed any other way — and sections 4 and 5 need a real dictation history and a two-display machine respectively.

A separate table in the matrix records five gates as blocked rather than failed, each for a missing environment: SSH remote sidecar parity needs a pinned host; Issue↔Flight mirroring needs two disposable repositories and both credentials; PacketAgent live e2e needs a running instance and a minted credential; PacketCode release proof needs published signed artifacts; macOS and Linux need those hosts.

What packaged upgrades did prove#

Three packaged installs have happened, all silent per-user, and between them they closed the two upgrade rows in section 1 and the first row of section 2.

0.13.1 is also the first build whose UI anyone has looked at. That row closes the "needs eyes on it" caveat against 0.13.0 and nothing more: the window opened on a secondary monitor with its left edge clipped, so the Left Rail was off-screen and navigation ran through the command palette instead. The rail is still unexercised on a packaged build, and the only screens examined were the two agent routes.

Two limits on what those runs proved#

Being specific is more useful than a general disclaimer.

• localStorage does not survive a pre-rename upgrade. WebView2 keys its profile by bundle identifier, and the rename moved it from com.packetade.desktop to com.packetbench.desktop. A package upgraded from a PacketADE build gets an empty profile, and twelve keys — including unsent composer drafts — are stranded rather than deleted; the old profile stays on disk. Filed in backlog.md, needs an owner decision, and accepted as a consequence of the rename. Upgrades between two PacketBench versions are unaffected.
• The pre-rename data-dir migration is still unproven on a real installed upgrade. ~/.packetbench already exists on the machine doing the testing, so migrate_data_dir_in correctly returns early and the legacy ~/.packetade is left untouched, exactly as designed. Proving that row needs a host or VM snapshot carrying ~/.packetade and no ~/.packetbench.

Gate counts at 8dc13780, the commit 0.13.1 was built from: cargo check clean, 976 Rust library tests with 2 ignored, tsc --noEmit 0 errors, pnpm lint 0 errors with 9 pre-existing warnings, vitest run 2,765 of 2,765 across 286 files. There is no CI; every one of those gates is local.

Where the app's own status card overstates#

Settings → Tools carries a read-only Release Trust card (src/components/views/ToolsView.tsx:500). Three of its four rows match this page. The first does not.

The card's own body text is correct where the row is not: "Signing certificates and the Tauri updater are planned release-trust gates, not active guarantees in the current repo."

One provenance discrepancy is worth recording alongside it. CHANGELOG.md deliberately restores the pre-rename PacketADE_0.10.5_* filenames for builds made before 2026-08-26, because a hash table whose filename never existed proves nothing, and instructs that no future brand sweep touch them. The two release records in dev/ were not restored: dev/release-v0.10.2.md:38-42 and dev/release-v0.10.3.md:68-69 still list PacketBench_0.10.x_* filenames for builds dated 2026-07-28 and 2026-08-02, a month before the rename. Those hashes are still good; the filenames beside them are not what the bundler produced.

Related#

• Install & first run — the build-from-source path this page recommends, and the prerequisites for it.
• Troubleshooting — the SmartScreen, Gatekeeper and stranded-localStorage symptoms, with their workarounds.
• Upgrades & migration — the upgrade procedure itself and the pre-rename migrators.
• Build & release — the toolchain, the sidecar prune, and the release checklist that produces these artifacts.
• Testing & gates — the local gates whose counts are quoted above, and why there is no CI.
• Settings — the Release Trust card in the context of the rest of the surface.