A feature can work in the development folder and disappear from the installer because a file is missing or the developer environment helped it. My verification therefore follows the executable back to the actual installer instead of stopping at a successful source test.
The installer name does not establish identical contents
The 0.1.110 distribution record retains installer size and SHA-256 plus comparison of seventy-two files extracted from the actual NSIS payload. Checking a build directory differs from inspecting bytes recovered from the deliverable. Different bytes under the same version name would break that chain.
A digest establishes identity, not code signing or product safety certification. The record explicitly leaves codeSigned and real-other-computer testing false. It also says the existing installed binaries were unchanged. Evidence about a candidate deliverable must not be rewritten as evidence that the person's installation was already updated.
Reduce help from the development environment deliberately
The packaged test uses separate userData, empty APPDATA and LOCALAPPDATA, and a PATH without developer CLI or Python. It checks app.isPackaged, fresh data locations and absence of personal conversations or configuration. The question is whether the browser itself starts without incidental development-machine paths.
That does not establish that every Python workflow needs no external dependency. Browser startup and program execution have different requirements. Recording removed variables and newly created folders lets a reader assess the actual conditions behind the phrase clean environment. The specific setup matters more than an attractive label.
Check whether test-only capabilities entered production files
The retained packaged test scans the asar listing for development-only folders and main code for certificate bypass, a harness or a fixed debugging port. A transport used to control a test differs from a capability permanently shipped in the application. Those distinctions keep test instrumentation from becoming a hidden product assumption.
Filename and regular-expression checks are useful, but not a complete vulnerability analysis. The recorded eight passing items answer eight stated questions. I read the assertions beside the results rather than treat a growing automated count as evidence about unspecified properties of the deliverable.
Reconnect MCP and Python paths in the installed app
The later project-isolation record separately reports fifteen source and fifteen packaged Electron/MCP/Python/UI checks. It also records reuse of an existing public-page reading plugin without a new tab. Those are installed-path observations, not copies of source-success checkmarks.
Owned fixture execution still differs from actual public-page reading, and neither becomes a complete new publication or upload journey. Current external MCP documentation follows removal of embedded models, so an old distribution record cannot define the present app's internal capabilities. Architectural change between versions belongs in the verification chain too.
Verify a shared package before and after extraction too
For this site's modules, tests run in the authored folder, then again after ZIP extraction into another folder. Actual public-download bytes and hashes are compared separately. Each package earns its own evidence rather than borrowing the original installed browser's results.
I did not install the original app or alter a customer environment for this article. It compares historical receipts and assertions. Other-computer compatibility, signing and supply-chain review remain open where untested. A deliverable should carry a traceable connection to the conditions under which those exact files were checked, not merely an executable and a confident version label.