Publish v0.8.1 to the AUR once Arch re-enables pushes

[jeremy]

v0.8.0 is published on GitHub and is Latest, but the AUR is still on 0.7.2-1.

Why

The release-time publish failed because the AUR was unreachable, and the manual
recovery run failed for the same reason. This is not a maintenance window: Arch
disabled AUR pushes entirely on 2026-07-30
while handling a wave of malicious package adoptions.

We have now disabled pushes altogether as well for the moment, while we handle
the situation.

So retrying cannot help until Arch re-enables pushes. The SSH endpoint still
answers with the generic "down due to maintenance" banner, which is misleading.

What to do when pushes are back

Dispatch the Publish to AUR workflow with version 0.8.0.

scripts/publish-aur.sh builds the PKGBUILD from the published release assets
and no-ops when the AUR copy is already current, so it needs no new tag and is
safe to re-run.

If a newer release has shipped by then, publish that version instead — the
workflow refuses to downgrade, and a newer release supersedes this gap entirely.

Nothing else is outstanding

Everything else from the v0.8.0 release is verified and complete:

• Release notes carry the full v0.7.2..v0.8.0 range including all six breaking changes
• Windows and macOS signing verified on both arches
• Nix flake vendorHash verified
• Homebrew tap and Scoop updated
• Skills synced to basecamp/skills (024f56a8)

Refs #600.

[jeremy]

Correction — the "Nothing else is outstanding" list above was wrong.

The Nix flake in v0.8.0 cannot build. go.mod requires Go 1.26.5 (since #533,
2026-07-13) while flake.lock pins a nixpkgs from 2026-06-28 carrying 1.26.4:

go: go.mod requires go >= 1.26.5 (running go 1.26.4; GOTOOLCHAIN=local)

I listed "Nix flake vendorHash verified" as complete. That was a false positive I
should have caught: update-nix-flake.sh ran nix build ... || true and then treated
the string building '...basecamp-0.8.0-go-modules.drv' as proof of success — nix
prints that when the build starts. So the check printed vendorHash: verified (build succeeded) on a hard failure, and I reported it as verification.

Verifying the vendor hash never established that the thing compiles. And nix-verify,
which would have caught it, was both continue-on-error and skipped entirely when the
AUR failure reddened the release job.

Fixing the Go error then exposed a second defect it had been masking — the recorded
vendorHash was stale too.

Both fixed in #606, along with making the release-time check fail closed, making
nix-verify blocking, and adding a PR-time flake build so the drift is caught where
it is introduced.

This does not change what is tracked here — AUR is still stuck at 0.7.2-1 pending
Arch re-enabling pushes. But when it reopens, publish the newest stable version, which
will likely be 0.8.1 rather than 0.8.0.

[jeremy]

Recovery target is now v0.8.1, not v0.8.0. Retitled accordingly.

v0.8.1 published 2026-08-03 and is Latest. Its release-time AUR publish failed for the
same reason — Arch still has pushes disabled:

The AUR is down due to maintenance. We will be back soon.

Three attempts with backoff, all refused. AUR remains on 0.7.2-1.

When pushes return, dispatch Publish to AUR with version 0.8.1. Publishing 0.8.0
would now be refused anyway: the downgrade guard added in #600 compares against the AUR's
own RPC and only permits a version at or above what is published, and 0.8.1 supersedes it
regardless.

What changed since this issue was opened

The isolation from #600 did its job on this release. AUR failed as its own job, and unlike
v0.8.0 it took nothing down with it:

Job	v0.8.0	v0.8.1
Verify Nix flake	skipped	success
Verify macOS signing (both arches)	skipped	success
Verify Windows signing (both arches)	skipped	success
Sync skills	skipped	success (no-op; skills/ unchanged)
Overall run	failure	success

Also corrected: the Nix flake defect reported above is fixed in
#606 and shipped in v0.8.1. Verify Nix flake is now a blocking job and passed on its first
real run, which is the first independent confirmation the flake builds.

So AUR is the only outstanding item, and it is entirely on Arch's side.

[jeremy]

Consolidating #607 here. This issue is the canonical AUR-publish tracker and now
carries the aur-publish label, which is what the notifier dedupes on as of
#609.

#607 was a duplicate of this one, opened by release.yml when v0.8.1's AUR
publish failed. It appeared because both workflows deduped on --search "in:title …" and I had retitled this issue — so the lookup missed and filed a
new one. #609 replaces that with a label-based lookup that survives retitling,
shared by both the release and recovery workflows, and fails closed rather than
filing a duplicate when the lookup itself errors.

Verified against live GitHub before merge: the notifier now resolves to this
issue and takes the comment branch.

Still open for its original reason — AUR pushes have been disabled since
2026-07-30, and the package is stale at 0.7.2-1. Recovery target is v0.8.1.
Re-run the Publish to AUR workflow with version 0.8.1 once Arch re-enables
pushes.

[github-actions]

Publishing v0.9.0 to the AUR failed. The GitHub release is unaffected — only the Arch package is stale. Re-run the Publish to AUR workflow with version 0.9.0 once the AUR is reachable.