A Package Build Is Not a Deployed Fix

Walz passed its JavaScript syntax check, Rust checks, tests, and Arch package build, but none of that changed the application already running on the desktop. The artifact was ready; the fix was not deployed.

This sounds obvious until a long debugging session ends with a green build and everyone starts speaking in the present tense: "the paste bug is fixed" or "the renderer dependency is installed." The accurate claim at that point is narrower: a package containing the change was built successfully.

Four states can look like one

For a locally packaged desktop application, the relevant states are distinct:

1. Source changed: the repository contains the intended patch.
2. Artifact built: makepkg produced a package with those files and dependencies.
3. Artifact installed: the package database and filesystem contain that package version.
4. Runtime restarted: the process under test was launched from the installed files after the upgrade.

A check at one boundary cannot prove the next. Inspecting the package archive can show that injection.js contains the new clipboard guard. pacman -Qi can show which package release is installed. A process start time can show whether Walz predates that installation. Only an interaction test after restart proves the user-facing behavior.

Arch's package metadata separates the upstream pkgver from 1, which exists specifically so packaging changes can produce a new package release without a new upstream version. Incrementing it matters only after the new release is installed.

Verification should follow the artifact

Closing the verification gap required this sequence:

• Run source-level checks and tests.
• Build the package and inspect its file list and metadata.
• Install that exact artifact.
• Stop every old Walz and WebKit child process.
• Launch the installed application.
• Reproduce the original paste or renderer scenario.

The final step cannot be replaced by a compiler. Clipboard handling depends on trusted browser events and the target web application. Renderer startup depends on the host's GStreamer plugins and WebKit process. Both cross boundaries that unit tests intentionally simulate.

State the highest verified boundary

During the original work, the built Walz package reached the artifact boundary, while installation, restart, and live paste confirmation remained outstanding. Recording that distinction prevented a green packaging command from erasing the real next step.

This is a small discipline with a large effect on desktop debugging: name the highest boundary you verified. "Built," "installed," "restarted," and "reproduced" are different results, and using the right one tells the next person exactly what remains.