build.ps1 would have shipped last month's UI without saying so

Audited before its first run, because deploy.sh taught us what a script
nobody has executed contains.

PowerShell's $ErrorActionPreference = "Stop" governs PowerShell errors. A
native .exe returning non-zero is not one, so `npm ci` and `npm run build`
were unchecked and the script sailed past them. That matters here more
than anywhere else: a built frontend/dist is COMMITTED to this repository
so `go build` type-checks without npm, which means a silently failed npm
build leaves the old one in place and it embeds perfectly. The output is
an installer that builds, installs, opens and shows a stale UI, with
nothing anywhere saying so - the silent-wrong outcome, reached through
the single most likely failure on a fresh Windows box.

A Run() helper now throws on any non-zero native exit, across nine call
sites: venv, both pip installs, pytest, pyinstaller, npm ci, npm build,
both go builds, and the frozen engine's own smoke test.

The pip installs were also piped to Out-Null, so a failure there produced
no output AND no stop. run-local.sh has already been caught making
exactly that mistake, where it "exited at step 5 with no output at all -
the single hardest failure to diagnose, and it took three runs to find".
Not worth repeating in a script that runs on a machine nobody is sitting
at.

Two smaller ones from the same read:

- frontend\dist\index.html is deleted before npm runs, and its absence
  afterwards is an error. Checking the exit code is not enough when the
  artefact it was meant to produce is already sitting there from git.
- `go build -o dist\...` does not create its target directory, and dist\
  is gitignored. It exists on a fresh clone only because PyInstaller ran
  first and made it - an ordering dependency nothing stated. Stated now,
  and created explicitly.

None of this has been run on Windows. It cannot be from here - PyInstaller
freezes the interpreter and native wheels of the machine it runs on. What
this buys is that the first Windows run fails for a real reason rather
than for a bug in the script.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KGcjxF1cNLcuwc3DAPcnfj

installer/build.ps1

@@ -38,31 +38,60 @@ function Need($exe, $hint) {
   }
 }
 
+# Run a NATIVE command and stop if it fails.
+#
+# $ErrorActionPreference = "Stop" does not do this. It governs PowerShell
+# errors; a .exe returning non-zero is not one, so the script sails past it.
+# That is not theoretical here: `npm ci` failing on a fresh Windows box would
+# have let the build continue, and `go build` would then have embedded the
+# STALE frontend/dist that is committed to this repository - producing an
+# installer that works, opens, and shows last month's UI, with nothing
+# anywhere saying so. The silent-wrong outcome, from the most likely failure.
+#
+# Output is NOT swallowed. `| Out-Null` on a failing install is how
+# run-local.sh once exited with no output at all, which took three runs to
+# diagnose; the same mistake is not worth repeating in a script that will be
+# run on a machine nobody is sitting at.
+function Run($exe) {
+  $rest = $args
+  & $exe @rest
+  if ($LASTEXITCODE -ne 0) {
+    throw "$exe $($rest -join ' ') failed with exit code $LASTEXITCODE"
+  }
+}
+
 Need python "Install Python 3.11+ and tick 'Add to PATH'."
 Need go      "Install Go 1.21+ from https://go.dev/dl/."
 Need npm     "Install Node.js LTS from https://nodejs.org/."
 
 Step "Python environment"
 Push-Location $root
-if (-not (Test-Path ".venv")) { python -m venv .venv }
+if (-not (Test-Path ".venv")) { Run python -m venv .venv }
-& .\.venv\Scripts\python -m pip install --upgrade pip | Out-Null
+Run .\.venv\Scripts\python -m pip install --upgrade pip
-& .\.venv\Scripts\python -m pip install -r requirements.txt pyinstaller | Out-Null
+Run .\.venv\Scripts\python -m pip install -r requirements.txt pyinstaller
 
 Step "Engine tests"
 # The package is not worth building if the engine is broken, and finding that
 # out after the installer is signed is the expensive order to do it in.
-& .\.venv\Scripts\python -m pytest tests -q
+Run .\.venv\Scripts\python -m pytest tests -q
-if ($LASTEXITCODE -ne 0) { throw "engine tests failed" }
 
 Step "Engine (PyInstaller, one-folder)"
 if (Test-Path (Join-Path $root "build")) { Remove-Item -Recurse -Force (Join-Path $root "build") }
-& .\.venv\Scripts\pyinstaller behavision.spec --noconfirm --distpath (Join-Path $dist "engine-build")
+Run .\.venv\Scripts\pyinstaller behavision.spec --noconfirm --distpath (Join-Path $dist "engine-build")
-if ($LASTEXITCODE -ne 0) { throw "pyinstaller failed" }
 
 Step "Desktop app (Wails)"
 Push-Location (Join-Path $root "desktop\frontend")
-npm ci
+# A built dist is COMMITTED to this repository so `go build` type-checks
-npm run build
+# without npm (the //go:embed directive requires the directory to exist). That
+# convenience is a trap at package time: a silently failed npm build leaves
+# the old one in place and it embeds perfectly. So the marker is removed
+# first, and its reappearance is what proves this build produced the UI being
+# shipped rather than inheriting one.
+$marker = Join-Path $root "desktop\frontend\dist\index.html"
+if (Test-Path $marker) { Remove-Item -Force $marker }
+Run npm ci
+Run npm run build
+if (-not (Test-Path $marker)) { throw "npm run build reported success and produced no dist\index.html" }
 Pop-Location
 Push-Location (Join-Path $root "desktop")
 # Wails v2 talks to WebView2 through pure-Go bindings, so no cgo and no
@@ -71,14 +100,17 @@ Push-Location (Join-Path $root "desktop")
 # from brand/loyaly-icon-512.png), and `wails build` would add a second copy
 # of both and fail the link with duplicate resources.
 $env:CGO_ENABLED = "0"
-go build -tags desktop,production -ldflags "-H windowsgui -X main.version=$Version" -o (Join-Path $root "desktop\build\bin\Behavision.exe") .
+Run go build -tags desktop,production -ldflags "-H windowsgui -X main.version=$Version" -o (Join-Path $root "desktop\build\bin\Behavision.exe") .
-if ($LASTEXITCODE -ne 0) { throw "desktop build failed" }
 Pop-Location
 
 Step "Headless agent"
 Push-Location (Join-Path $root "agent")
 $env:CGO_ENABLED = "0"   # the cgo resolver forces external linking
-go build -o (Join-Path $root "dist\behavision-agent.exe") .
+# `go build -o` does not create the target directory, and on a fresh clone
+# dist\ is gitignored and absent. It exists here only because PyInstaller ran
+# first and made it - an ordering dependency nothing states, so state it.
+New-Item -ItemType Directory -Force -Path $dist | Out-Null
+Run go build -o (Join-Path $root "dist\behavision-agent.exe") .
 Pop-Location
 
 Step "WebView2 bootstrapper"
@@ -104,8 +136,11 @@ Copy-Item (Join-Path $root "LICENSE") $stage -ErrorAction SilentlyContinue
 
 $engineExe = Join-Path $stage "engine\behavision.exe"
 if (-not (Test-Path $engineExe)) { throw "engine exe missing at $engineExe" }
-& $engineExe paths
+# The frozen engine has to START, not merely exist. A PyInstaller build that
-if ($LASTEXITCODE -ne 0) { throw "the frozen engine cannot start - `paths` failed" }
+# is missing a native DLL links fine and dies on first launch - the classic
+# "works in the venv, dies in the bundle" - and finding that out on a shop
+# counter is the expensive order to do it in.
+Run $engineExe paths
 
 Pop-Location