[Brian Krabach (bkrabach)]

Change

Problem. The Windows setup file is published as AmplifierUnifiedSetup-<version>-windows-x64.exe. The name contains the version, so no stable link exists, and the README cannot point a person at "the current setup file".

Result. Each release also publishes the identical setup bytes under a name without a version:

https://github.com/microsoft/amplifier-unified/releases/latest/download/AmplifierUnifiedSetup-windows-x64.exe

• Canonical owner: scripts/windows_consumer_release.py (STABLE). The file is a copy, not another build. It embeds exactly its own release's plan, as today.
• The producer's verifier refuses a version-less file whose bytes differ from the release's setup file, a missing one, and a link. WINDOWS_SHA256SUMS lists both names with the same digest.
• The publisher (scripts/release.py) accepts exactly two asset sets: the current one, and the set of a selected source from before this change. Nothing else is published.
• release.yml uploads the new name explicitly; the existing pattern with a version does not match it.
• A release that is not marked latest (a repair of an older line) does not move the link. The publisher creates the release as a draft, uploads, then publishes, so the link has no window without the file.
• The link depends on one rule, now stated in the design note and guarded by a test: only the application publisher marks a release as latest. Component releases (scripts/scheduling_release.py) publish with make_latest=false.

Weighed and not done: a version-independent setup file that reads the latest release plan at run time. Its unchanged bytes might build download reputation while unsigned; that effect is not verified. It would give up the one integrity property the unsigned file has: the downloaded bytes fix exactly what is installed, and the published receipt attests that chain. Every saved copy would also follow the moving latest pointer for ever. Astra (gpt-6-astra) and Fable (claude-fable-5-1) each reviewed the three options from one brief and both answered "ship the copy". The reasons are in the design note.

Not in this PR: the README "Windows 11" section. Its link must not be dead, so it follows in its own PR after the first release that carries this file.

Validation

Source 7428ed065.

• All PR checks on 7428ed065: 10 pass; default-installed, integration and windows-bootstrap-offline are declared conditional skips on pull requests.
• Real handoff, run locally: the real publisher function release.consumer_assets ran the real producer command (windows_consumer_release.py verify, as a subprocess, as in the release job) on synthetic release folders with real compiler-input digests. Results: the current producer returns the five files; a folder without the copy is refused; the producer of the previous release (v0.95.0 scripts) with today's publisher returns its original four files.
• tests/test_windows_consumer_release.py (40 pass with the native-builder file): the version-less name has no version; both names have one digest in the checksum file; other bytes, a missing copy and a link are each refused; the publisher accepts the two exact sets and refuses an extra file, a missing setup file and a second versioned name; the workflow uploads the new name.
• Release automation, qualification and post-release suites: 489 pass. Two cases in test_release_qualification.py need the prepared web client folder and fail in a checkout without it, unchanged from main; CI prepares that folder.
• Source search: nothing else reads WINDOWS_SHA256SUMS or the setup asset names.

Not proven here. The producer's build step runs only on the Windows release runner (it compiles setup); its one new line, the copy, has not run there. No test publishes a release. The first release after this merge shows whether the new asset is uploaded and whether the link returns the file; I will check that link before the README section is merged.