Release Checklist¶

Use this checklist before and after cutting a release from main.

Before Tagging¶

Confirm main branch protection matches the Rust-native required checks.
```
make verify-branch-protection
```
Run the local merge-equivalent gates.
```
make verify-assurance
make ci
```
Exercise the checked-in release packaging path.
```
make smoke-release
make release-emulate
```
Confirm the docs/download surface still builds and link-checks cleanly.
```
make docs-check
```

Confirm the security assurance report can be generated for the candidate.

python3 scripts/security_assurance_gate.py \
  --json-out dist/security-assurance-report.json \
  --markdown-out dist/security-assurance-report.md

If you are validating an already-published tag, verify the public release surface directly.
```
make verify-published-release TAG=paranoid-passwd-v3.7.0
```

After Publishing¶

Verify that the release workflow produced every expected CLI and GUI artifact plus checksums.txt, including Linux .deb packages, macOS GUI .dmg images, and the Windows GUI .msi.
Verify that payload-layout validation passed for every archive, .dmg, Debian package, and MSI package, not just the host-runnable smoke artifacts.
Verify there are no stale browser-era or otherwise unexpected assets attached to the release.
Verify GitHub attestation for at least one downloaded artifact from each packaging family you ship.
Confirm the release download verification matrix ran the Windows GUI MSI row on a Windows runner.
Re-run installer validation against the published release surface if needed.
Confirm Homebrew, Scoop, and Chocolatey manifests were generated and published through their PR flow.
Do not describe artifacts as platform-signed unless the matching platform checks in Platform Installers and Signing passed for the published release.
When validating a platform-signed release candidate, run the release validation path with PARANOID_RELEASE_SIGNING_MODE=signed on hosts that can verify the relevant platform signature.
For macOS signed candidates, confirm the release workflow imported the Developer ID certificate and that scripts/macos_sign_notarize.sh signed/notarized both Paranoid Passwd.app and the GUI .dmg before publication.
For Windows signed candidates, confirm the release workflow imported the signing certificate into the current-user certificate store, that scripts/windows_sign_artifact.sh signed the staged GUI executable before WiX packaging, and that it signed and verified the GUI .msi before publication.

Canary Expectations¶

The first release after a pipeline change should be treated as a canary:

inspect the archive matrix
inspect the Debian package set
inspect the macOS GUI .dmg set
inspect the Windows GUI .msi
verify the checksums
verify provenance
verify install.sh
confirm the docs download links resolve
confirm the public docs still describe unsigned artifacts as checksummed and attested, not as platform-signed

If any of those fail, treat the release pipeline as untrusted until the failure is fixed and the validation path passes again.