installer/windows: the GUI installer does not report success when it installed nothing (#1181)

[gen16k]

What this is about

On a Windows host where Smart App Control refused waired-agent.exe,
WairedSetup-0.0.3-rc5-x64.exe /VERYSILENT recorded
CreateProcess failed; code 4551. twice in its log, carried on, ran
waired.exe claude enable, and finished as a successful install with exit
code 0. The host was left with no service and a Claude Code pointed at a
gateway that would never listen — every turn failed with
API Error: Unable to connect to API (ConnectionRefused).

The ruling this breaks is already on file:
docs/decisions/20260829/1730-installer-refuses-programs-that-cannot-run.md
(owner, 2026-08-29) — 「インストールでも更新でも、waired.exe か
waired-agent.exe のどちらかがこの機で実行できないなら、そこで止める」.
install.ps1 implements it (#1153). The GUI installer never did, and
getting-started/update.mdx already promised "A fresh install behaves the
same way: it stops rather than leaving a computer with programs that cannot
run."

Fixes #1181
Refs waired-ai/waired#1312 (L96)

What I found first: an Inno installation can only be declined in one place

I went in expecting to raise from a [Files] AfterInstall. That does not work,
and neither do the other two candidates. Measured against the Inno Setup 6
sources (jrsoftware/issrc, tag is-6_7_3) and confirmed on a Windows 11 host
with Inno Setup 6.7.3:

hook	can it fail the installation?	why
PrepareToInstall returns a message	yes — exit code 7, before [Files], before the service is stopped, before Claude Code is looked at	Setup.WizardForm.pas ClickThroughPages
[Files] AfterInstall / BeforeInstall raises	no — Inno swallows it deliberately: "Don't allow exceptions raised by Before/AfterInstall functions to be propagated out"	Setup.MainFunc.pas NotifyInstallEntry
[Run] entry fails	no — the result is discarded	Setup.MainForm.pas ProcessRunEntries
CurStepChanged(ssPostInstall) raises	no — SetStep(ssPostInstall, True) handles it and carries on	Setup.MainForm.pas SetStep
[Files] Check raises	fails, but unusable — evaluated twice (Ready page CalcFilesSize, then CopyFiles)	Setup.Install.HelperFunc.pas

I measured the AfterInstall row rather than trusting the reading: a build
that raised there exited 0 with everything installed. The whole design
follows from that row, and it is written down in
docs/knowledges/20260904/0210-inno-can-only-decline-before-it-installs.md.

Also measured, and load-bearing: Inno routes Application.HandleException
through a suppressible box, so an exception cannot hang a
/VERYSILENT /SUPPRESSMSGBOXES run (the waired#760 hazard does not apply
here); and rollback keeps files that existed before the install
(utDeleteFile_ExistedBeforeInstall), so a restored binary survives it.

What changed

packaging/windows/waired-setup.iss — everything that can fail now happens
in PrepareToInstall:

• The three programs are embedded once with dontcopy, extracted, copied
  into {app}\.waired-staging and actually run there before anything on
  the computer is created, stopped or replaced. The table of what to ask each
  one is install.ps1's Get-StagedBinaryChecks, unchanged: waired.exe version --json (exit code read) and waired-agent.exe -h are fatal, the
  Waired app only warns. Staging sits under the install directory for the same
  reason install.ps1 puts it there. The two Inno installs are external
  entries reading those extracted copies, so the setup executable carries one
  copy, not two.
• waired-agent.exe is placed by Setup itself, and its service registered,
  started and confirmed Running — inside PrepareToInstall, because that is
  the last moment Setup can still decline. [UninstallDelete] removes it.
  waired-agent.exe start already waits for Running and exits non-zero
  otherwise, so its exit code is the answer and no localised sc query output
  is parsed.
• An upgrade keeps the waired-agent.exe it replaces and puts it back,
  restarting the service, when the new one will not come up — the rollback half
  of the ruling, for the case the pre-flight cannot cover (the verdict moves on
  its own).
• Claude Code is touched last, and only with a running daemon. The
  claude enable step moved out of [Run] into ssPostInstall behind
  gAgentRunning, so it cannot be reached by a computer with no service. When
  it fails on its own it is not fatal — Claude Code keeps talking to
  api.anthropic.com, which is where it was — but it is no longer silent.
• SetupLogging=yes. WairedSetup: the GUI installer reports success and enables the Claude Code integration although the agent service was never installed — leaving Claude Code broken #1181 was only diagnosable because that run happened to
  have a log; a person hitting this never passes /LOG.
• AllowCancelDuringInstall=no (by then the service is up and the remaining
  work is a few seconds of copying), and the dead WipeStatePage variable is
  gone.

Tests. scripts/install/waired_setup_iss_test.go is the first check in the
repo that reads the .iss at all — install-script-lint is shellcheck,
ps-script-lint covers the .ps1 files, ARGTEST is install.ps1-only. It
pins, by set equality: what Setup executes; that nothing hangs off a hook that
cannot fail; that the programs are embedded once and tried before they are
installed; that claude enable sits behind the service check; and it holds the
pre-flight table against install.ps1's, because two copies of one table
forget different things. Each assertion was checked to fail on the defect it
names.

The install test's -ExeVariant leg (every PR) gains three behaviours, driven
by deliberately broken payloads — a policy refusal cannot be produced on demand
— the same technique the #1087 asserts use for the update path:

• a fresh install whose waired-agent.exe will not run,
• a fresh install whose service will not start (where.exe stand-in),
• an upgrade whose service will not start, asserting the previous
  waired-agent.exe is back byte-for-byte and the service Running.

Those runs deliberately do not pass /MERGETASKS=!claudeproxy, so "no
managed-settings.json afterwards" means Setup stopped before the integration
rather than that the task was unchecked. They use a new build-time
/DNoCompression switch so a throwaway payload does not cost a minute of
lzma2/ultra; shipping builds never pass it. Each run is bounded by
WaitForExit(180s) so a Setup stopped on a dialog fails this leg in three
minutes with a clear message instead of hanging it. The positive path now
asserts the service is already Running when the installer returns, instead
of starting it by hand — the harness comment claiming a fresh Inno install does
not start the service was stale.

scripts/ci/docs-surface-guard.sh: packaging/windows/ joins the list.
The GUI installer was the one install path outside it — packaging/install/
has been there from the start — and that gap is why update.mdx could promise
a behaviour the GUI installer did not have with nothing failing.

Docs: a new "If Windows refuses to run a program" section on the Windows
install page (EN + ja), quoting the product output verbatim, which makes
update.mdx's "a fresh install behaves the same way" checkable.

Verification on real hardware

Windows 11, Inno Setup 6.7.3, from a genuinely clean machine, all four paths:

run	exit	after
fresh, waired-agent.exe will not run	7	%ProgramFiles%\Waired empty, no service, no registry key, no Start Menu, Claude Code untouched
fresh, service will not start	7	same — including the waired-agent.exe Setup had placed
fresh, good	0	service already Running when the installer returned, start mode Auto, managed-settings.json written
upgrade, new agent's service will not start	7	service Running, waired-agent.exe byte-for-byte the one that was there (9368638…), managed-settings.json unchanged, no .displaced-* left

Two things worth recording from the same session:

• On a Windows 11 host with Smart App Control on, a freshly compiled
  unsigned WairedSetup.exe was refused outright (CodeIntegrity 3077 + 3033 +
  3118, policy {0283ac0f-…}), so the GUI installer would not start at all
  there. That is why the functional verification ran on a host with SAC off and
  why the CI cases use broken payloads. The event records went to installer(windows): find out what makes Smart App Control refuse a Waired program, and what makes the refusal lift #1191.
• install.ps1's Checking the new programs run on this computer before replacing anything is now printed by the GUI installer too, so docs-site can
  quote one line for both.

Local: gofmt, go build ./..., go test ./scripts/..., golangci-lint run --max-same-issues=0 (0 issues), install-script-lint, docs-surface-guard
(fires and is satisfied), npm run i18n:check (32 pairs in sync).

Known follow-up

The assert-count floor in scripts/dev/installtest-windows.ps1
($floor = if ($Contract) { 139 }) has to be re-measured from a green run of
this branch rather than estimated; I will update it from the first CI run
before merging.

🤖 Generated with Claude Code

https://claude.ai/code/session_0172JQqxQSWDFbQauMDuCbJ2

[github-actions]

📘 Docs preview — the preview channel for this PR has been deleted now that it is closed.

[gen16k]

Addendum — what CI's first run of this changed, and the measured floor

CI found a hole in the change itself, and closing it made the installer better.

The Windows leg's stand-in for a broken agent is where.exe, the same one the
#1087 asserts use. On the GitHub runner, waired-agent.exe start became
where.exe start, the runner's PATH had something matching start, and
where.exe exited 0 — so Setup believed the report and called the upgrade a
success over a service that was Stopped. The same stand-in exits 1 on a
developer machine: where.exe's exit code depends on what is on PATH. Every
other Windows failure in that run was downstream of this one (the bad upgrade
left where.exe as waired-agent.exe, so waired-agent.exe uninstall never
deregistered the service, the Inno uninstall timed out waiting for it, and each
later assert saw a service that should not have existed). main's Windows leg
has no failures.

The fix is the distinction #1087 is already about — a report is not a state.
waired-agent.exe start does wait for Running and exit non-zero otherwise, but
the installer does not know that the program it just placed is really
waired-agent. So it now asks the SCM: sc.exe interrogate waired-agent, exit
codes only — 0 running, 1062 registered-but-stopped, 1060 not registered — so
nothing parses localised sc query output.

Proven on real hardware with a Go stub that exits 0 for every argument, so
both install and start "succeed":

EXIT=7  svc=Running  interrogate=0  agent 936863804B7B -> 936863804B7B
waired-agent service setup failed: the service is registered but is not running

Declined, previous binary back byte-for-byte, service running again.

Assert floor: raised 139 → 156, measured from the green run
33786027609 of this exact configuration, which executed 187 asserts with no
failures. 156 rather than 187 because the floor is a minimum every green run
must clear, not a pin on today's total; 17 is what this PR always contributes
(5 for the refused upgrade, 6 each for the two refused fresh installs; the
positive path swapped one assert for another).

All seventeen pass on the runner, including will-not-run : nothing was left in C:\Program Files\Waired and will-not-run : Claude Code was not touched (#1181).

Follow-up filed: #1202 — the setup program ships on every release and every
edge prerelease and is documented nowhere. This PR adds only the one section
it owed (what happens when Windows refuses to run a program); the rest is that
issue.