Opus Vela Voice 0.6.2: one contract from installer to taskbar

Released and payload-verified1 min readOpus Vela Voice

How Voice joined signing, immutable downloads, updater verification, installed-payload parity and Windows taskbar identity into one release acceptance path.

Journey 2026-08-21 → 2026-08-24

Source: Public Opus Vela download surfaces and privacy-screened Voice release, updater and installed-payload evidence

The build, in five parts.

01 Built
A signed Voice 0.6.2 installer, explicit update path, persistent Windows identity and a verified installed payload for the local-first dictation application.
02 Process
Source, packaged files, signatures, immutable public download and installed output were compared before the release was accepted.
03 Learned
Matching versions are weak evidence; a desktop release must prove the bytes users install and the identity Windows continues to display.
04 Skills
ElectronAuthenticodeinstaller QAWindows identityupdater design
05 Saved
Release metadata, hashes, signature evidence, payload comparison, updater tests and the taskbar/tray acceptance record.

See the milestone, not only the summary.

Opus Vela Voice product page explaining local private dictation with current application media
The production Voice surface connected to the signed 0.6.2 release, update path and local-first product boundary.
Opus Vela Voice local dictation history
The local-first history surface retained through the verified upgrade.

Exactly what was built#

Opus Vela Voice 0.6.2 combined the local dictation product with a signed immutable installer, an explicit in-app update path, persistent taskbar and tray identity, and a release metadata surface the application can verify before asking a person to update. The product remains local-first: recognition and dictation history stay on the operator's machine.

The process#

The release path checked application and security tests, updater behavior, Windows signing and timestamp state, executable and window identity, tray residency and the installed file set. The public installer was downloaded back and compared with the accepted release artifact. Disposable install tests tracked their own processes and were cleaned without touching the live installation until lifecycle QA had passed.

What we learned#

A semantic version can match while the installed payload drifts. Release evidence therefore has to compare files and hashes, not only labels. Windows identity is also part of the product: the icon, application ID, taskbar presence and hide-to-tray behavior must survive packaging rather than being left to development defaults.

Skills gained#

The work deepened Electron release engineering, Authenticode signing, immutable artifact delivery, updater UX, installed-payload comparison, Windows AppUserModel identity and safe process-scoped QA.

What was saved#

The release retained machine-readable metadata, cryptographic identity, signing evidence, focused test results, installed-file parity and taskbar/tray checks. A fresh-computer acceptance pass remains a distinct proof gate rather than being inferred from same-machine success.

Into the knowledge loop#

The reusable rule is simple: every Voice release gets a new immutable URL, a verified download, an explicit user prompt and a payload-parity check. That rule can be retrieved by future release harnesses without granting them signing keys, publication authority or control of the operator's installed application.