ci(release): point the updater at this repository, and ship on the tested Node

[PathGao]

Three places where how we ship still names something that has moved on.

(a) The updater endpoint named the repository we no longer are

src-tauri/tauri.conf.json pointed auto-update at alecdotdev/Markpad. Now sftwrdotdev/Markpad.

Verified this session:

claim	how
It was a transfer, not a rename	GET /repos/alecdotdev/Markpad and GET /repos/sftwrdotdev/Markpad both return repository id 734498718 — one repository, reachable by both paths
alecdotdev is a separate, still-live account	user id 18179415, created 2016-03-31, type User — distinct from the sftwrdotdev organization, id 311965959, created 2026-08-02
The old URL still works	curl -IL on https://github.com/alecdotdev/Markpad/releases/latest/download/latest.json → HTTP 301 → sftwrdotdev/Markpad → the release asset. The body it lands on is v2.7.0's feed ("version": "2.7.0")
That feed's keys are all unsuffixed	darwin-aarch64, darwin-x86_64, linux-x86_64, windows-aarch64, windows-x86_64

The one-line change is the smaller half. The endpoint is compiled into the binary, so every installed copy up to and including v2.7.0 asks for the old URL and will use that redirect forever. And GitHub deletes a transfer redirect permanently if the old location is occupied again — from Transferring a repository:

If you create a new repository or fork at the previous repository location, the redirects to the transferred repository will be permanently deleted.

Note "or fork": forking sftwrdotdev/Markpad back to alecdotdev would void it just as a fresh repository would.

So alecdotdev/Markpad may never exist again, and nothing in the tree said so. tauri.conf.json is strict JSON and cannot carry a comment, so the constraint goes in RELEASING.md as a new §5, beside the other permanent release constraint (the un-rotatable pubkey). The failure it prevents is silent: latest.json 404s, the updater reports no update available, and users on old versions just stop being offered new ones.

Not a security issue, and the PR says so. The pubkey in tauri.conf.json is pinned and tauri-plugin-updater calls verify_signature(&buffer, &self.signature, &self.config.pubkey) in download before install (v2.10.1, src/updater.rs:712). Whoever ended up serving that URL could not produce a minisign signature that verifies, so they could not ship an update that installs. The exposure is broken or stalled updates, not code execution.

(b) build.yml built the shipped app on an end-of-life Node

It pinned node-version: '20' in two places, while test.yml and test_build.yml use lts/*. We tested on one Node and shipped on another.

Node 20 reached end-of-life in April 2026 and was removed from the runner images' toolcache in May. Confirmed in the v2.7.0 release run (30972242008) — all five jobs:

Attempting to download 20...
Acquiring 20.20.2 - x64 from .../node-20.20.2-linux-x64.tar.gz

against the most recent test_build.yml run, where lts/* is a cache hit:

Found in cache @ /opt/hostedtoolcache/node/24.18.0/x64

Both pins become lts/*. The risk is already retired: test_build.yml builds macOS universal, Linux and Windows on lts/*, and its latest run passed all three.

(c) A conditional coupling worth recording

__TAURI_BUNDLE_TYPE fails to be stamped into the Windows and Linux binaries. In the v2.7.0 build, three times (Windows x64, Windows arm64, Linux — never macOS):

Warn Failed to add bundler type to the binary: __TAURI_BUNDLE_TYPE variable
not found in binary. ... Updater plugin may not be able to update this
package.

Re-verified against tauri-plugin-updater v2.10.1 (the version in Cargo.lock) rather than taken from the warning text:

• get_urls (src/updater.rs:568) pushes {os}-{arch}-{installer} only inside if let Some(installer) = installer, then unconditionally pushes {os}-{arch}.
• installer_for_bundle_type(bundle_type()) is None when the variable is absent, so Windows/Linux clients look up the plain key and nothing else.
• macOS is unaffected for a reason: tauri_utils::platform::bundle_type() returns Some(BundleType::App) on macOS in the fallback arm, without reading the variable.
• build.yml's generate-update-feed job emits exactly the five unsuffixed keys, and the live latest.json confirms it.

It holds — this is harmless for us, so it gets a comment rather than a fix. The comment at the latest.json step records that adding a per-installer key (windows-x86_64-nsis, say) would make the missing bundle type suddenly load-bearing: Windows and Linux clients cannot ask for that key, so they would silently ignore it — and if the unsuffixed key were removed in the same edit, they would get TargetsNotFound and stop updating.

Tests

Three contract tests in scripts/releaseWorkflow.test.ts, each locking a fact that now exists in more than one place. Each was verified by breaking the property it protects:

broken	message
build.yml back to node-version: '20'	build.yml must request the same Node as the workflows that test the code it ships
build.yml pinned to '24' (i.e. right version, wrong mechanism)	same — it asserts against the test workflows, not against a literal
test.yml → '22', so the two test workflows disagree	the test workflows disagree on Node: 22, lts/*
a windows-x86_64-nsis key added to latest.json	latest.json key "windows-x86_64-nsis" carries an installer suffix; Windows and Linux clients cannot ask for one until the missing bundle type is fixed
endpoint reverted to alecdotdev/Markpad	tauri.conf.json points the updater at alecdotdev/Markpad while RELEASING.md documents sftwrdotdev/Markpad
RELEASING.md drops the statement	RELEASING.md must state which repository the updater endpoint names

The endpoint test failed falsification on its first shape and was rewritten. It originally asserted "the endpoint's repo is mentioned somewhere in RELEASING.md" — which passed with the endpoint reverted to alecdotdev/Markpad, because the new section warning against recreating that repository necessarily names it. The guard was satisfied by the very text that documents the hazard. It now matches the single sentence that states the endpoint's target.

npm run check — 0 errors, 651 files. npm test — 749/749.

What I could not verify

• None of this can be proven by running it. (a) and (c) only fully execute during a release, and (b) only on a release runner. I read the v2.7.0 logs and the plugin source; I did not cut a release.
• I did not test the negative case for the redirect. I have GitHub's documented statement that occupying the old location voids the redirect, and I confirmed the redirect currently works. I obviously did not create alecdotdev/Markpad to watch it break.
• lts/* is a moving target. It resolved to 24.18 in the runs I looked at; a future LTS rollover changes what the release builds on, with no commit here. That is the same exposure the test workflows already accept, and the test now guarantees all three move together — but it is not a pin.
• I did not confirm Node 20's toolcache removal date from an actions/runner-images changelog. What I confirmed is the behaviour: 20 downloads on every run, lts/* is a cache hit.
• I have not observed a Windows or Linux client actually performing an update. (c) is a source-level argument that the two lookup keys reduce to one, plus the published feed matching that one. The end-to-end path is untested here.

Out of scope

The remaining alecdotdev references are the author's identity, not the repository's location, and are deliberately untouched: FUNDING.yml, the Chocolatey nuspec <authors>, the Windows registry Publisher value, and the bundle identifier com.alecdotdev.markpad — which must not change, or installed copies stop recognising themselves as upgradable. README.md, snapcraft.yaml and the in-app "source code" links still point at the redirect; they work, they are not compiled into a released binary's update path, and they belong in a separate pass.

🤖 Generated with Claude Code