[charneykaye]

Summary

Three fixes from the pre-release audit of the v0.4.0 pipeline (#495). Each finding was checked by a separate agent trying to refute it, and none was refuted. None is a regression since v0.2.9. All three must be in the workflow before the v0.4.0 and demo runs, because each takes effect at run time.

1. Find steam_api64.dll under both Cargo build-dir layouts

What the step does. The Windows step "Package Windows portable depot layout for Steam depot" ships the Valve-signed steam_api64.dll that steamworks-sys copies into its build-script OUT_DIR. It only matched build\steamworks-sys-<hash>\out.

Why it would break. The release installs dtolnay/rust-toolchain@stable, resolved at run time, with no toolchain pin. Rust 1.100 becomes stable on Thu 2026-11-12, and Cargo's new build-dir layout then puts OUT_DIR at build\steamworks-sys\<hash>\out. The verifier reproduced this with a probe crate:

• rustc 1.99.1: build/steamworks-sys-9e36ed8f527f94b5/out/steam_api64.dll;
• rustc 1.100.0-beta.13: build/steamworks-sys/376c70e31367f0ee/out/steam_api64.dll.

On the new layout the filter matches nothing, and the step exits 1. That fails the Windows leg, which skips the release, Steam and Defender jobs, for any full or demo build started after the toolchain release. It is the only build-dir-dependent path in the Windows steps.

The fix. The filter accepts both layouts. It keeps the same one-line form v0.2.9 ran, and the Valve signature checks after it are unchanged:

Where-Object { $_.Directory.Name -eq 'out' -and ($_.Directory.Parent.Name -like 'steamworks-sys-*' -or $_.Directory.Parent.Parent.Name -eq 'steamworks-sys') }

Pinning the toolchain was considered and left out. With the filter fixed nothing depends on the layout, and a pin needs someone to keep bumping it.

2. Keep the depot artifacts 90 days instead of 7

The Steam depot is assembled from the Release run's desktop-* / demo-desktop-* artifacts, not from the GitHub release. That happens in the chained steam job, and also in a later Steam Deploy dispatch with that run_id, which is how publishing/STEAM_NEXT_FEST_DEMO.md §3 puts the demo on beta and default. The demo timeline puts that weeks after the build. With 7-day retention, that dispatch would find nothing to download, and only a rebuild with a new BuildID would recover.

• The upload now keeps the artifacts 90 days. That is GitHub's maximum, and what this workflow already uses for the VirusTotal and Defender scan records.
• The demo guide says what to do past 90 days: rebuild from the tag, or set the staged BuildID live in Steamworks, which needs no artifacts.

3. Refuse a full-edition dispatch whose tag already points elsewhere

A full-edition Run workflow creates the release tag on its own commit when the tag doesn't exist (#571). When it already exists, GitHub leaves it in place; softprops logs "Updating commit" and changes nothing. A dispatch from a newer main would therefore stage a Steam build the tag does not point to, and a demo dispatched from the tag would come from different source.

Validate now fails such a run before any build. It is the same comparison the demo guard makes, and it passes when the tag is missing or is the run's commit. The release checklist's validate row says so.

Closes #

---

Checklist

Tests and CI

• All existing tests pass locally (workflow and docs changes)
• New behaviour is covered by new or updated tests: these steps run only in a release. Each was exercised as described below, and CI's Workflow lint checks the file.
• Smoke check passes: bash scripts/smoke-check.sh

Documentation

• Links in new or modified docs resolve correctly (no links added)

---

Testing notes

DLL filter, modelled with Windows path semantics (Directory is the file's parent folder):

• matches build\steamworks-sys-<hash>\out\steam_api64.dll (Rust ≤ 1.99);
• matches build\steamworks-sys\<hash>\out\steam_api64.dll (Rust 1.100);
• rejects build\other-sys\<hash>\out, build\other-sys-1234\out, and a steamworks-sys\<hash> folder with no out.

PowerShell itself isn't available in this container.

Tag guard: I pulled the step's script out of the workflow, shellchecked it (clean), and ran it against origin:

Case	Result
TAG=v9.9.9 (missing)	exit 0, "tag v9.9.9 does not exist yet; the release job creates it on …"
TAG=v0.2.9, GITHUB_SHA=dbf4750f… (the tag's commit)	exit 0, "tag v0.2.9 is this run's commit"
TAG=v0.2.9, GITHUB_SHA=6bd5f6bd…	exit 1, ::error::tag v0.2.9 already exists at dbf4750f…, but this run is on 6bd5f6bd…

v0.4.0 doesn't exist yet, so the next dispatch from main takes the first path. A demo dispatch skips this step and runs the existing demo guard.

Other checks: the YAML parses, and bash scripts/smoke-check.sh exits 0.

🤖 Generated with Claude Code

https://claude.ai/code/session_013J2EUgaGKdJEx9AhbrXLmS