Summary

The README tells users to download Waza binaries from https://github.com/microsoft/waza/releases/latest, but that URL currently resolves to the azd extension release, whose assets are extension packages rather than the standalone waza-* binaries.

I could not find a .github/ISSUE_TEMPLATE directory in this repository, so I am using this plain bug report format.

Evidence

README binary install section links native Windows users and direct binary downloads to /releases/latest:

• waza/README.md

  Lines 17 to 19 in 0f5f245

  	The script auto-detects the OS and architecture of the environment where Bash is running (linux/darwin/windows, amd64/arm64), downloads the binary, verifies the checksum, and installs to `/usr/local/bin` (or `~/bin` if not writable). On Windows, piping this command to `bash` from PowerShell may invoke WSL and install the Linux binary inside WSL. For native Windows, download `waza-windows-amd64.exe` or `waza-windows-arm64.exe` directly from the [latest release](https://github.com/microsoft/waza/releases/latest), rename it to `waza.exe`, and place it in a directory on your `PATH`.
  	Or download binaries directly from the [latest release](https://github.com/microsoft/waza/releases/latest).

Current GitHub latest release resolves to:

• Waza azd Extension v0.33.0
• tag azd-ext-microsoft-azd-waza_0.33.0
• assets such as microsoft-azd-waza-darwin-amd64.zip, microsoft-azd-waza-linux-amd64.tar.gz, etc.

The standalone binary release is:

• Waza v0.33.0
• tag v0.33.0
• assets waza-darwin-amd64, waza-darwin-arm64, waza-linux-amd64, waza-linux-arm64, waza-windows-amd64.exe, waza-windows-arm64.exe, and checksums.txt.

The install script already works around this by filtering for v* release tags:

Expected

When docs say "download binaries directly from the latest release", users should land on a release containing standalone waza-* binary assets.

Actual

/releases/latest lands on the azd extension release, which does not contain the documented standalone binary asset names.

Suggested fix

Any of these would avoid the trap:

• Mark the standalone v* release as GitHub's latest release instead of the azd extension release.
• Change README links to point to the latest standalone binary tag or to a filtered/releases page with explicit instructions.
• Publish azd extension releases as pre-releases or otherwise prevent them from owning /releases/latest.
• Add a note that /releases/latest may point at the azd extension and that standalone binary users should choose the latest v* release.