The amd64, arm64, win64 and mac-arm64 bundles embedded Node.js with cp $(command -v node) - the runner’s node. A bare binary extracted onto the runner publishes no checksum, so releases/record-provenance.sh could only write no checksum published, and the provenance table at the top of the release could not name the exact Node.js build a platform carried. It was also the wrong build on arm64: build-arm64 has no setup-node step, so $(command -v node) was ubuntu-24.04-arm’s DEFAULT Node 22.x, not the pinned Node 24 every other bundle shipped - and nothing recorded the disagreement. A new releases/embed-verified-node.sh downloads the pinned Node.js for the bundle’s OS+CPU from nodejs.org, verifies the archive against the published SHASUMS256.txt (fatal on a mismatch), and puts its node into the bundle; each native job now calls it and records nodejs.org + the exact version + the verified SHA256. FerretDB is verified the same way, against the .sha256sum wekan/FerretDB now publishes beside every binary, and win64 and mac-arm64 - which recorded no provenance at all - now upload a provenance artifact like amd64 and arm64, so every platform is accounted for. The emulated arches already did this through install-node-for-arch.sh. tests/releaseNodeVerified.test.cjs pins that no native bundle can go back to the runner’s node or an unverified download.

Every bundle except amd64 and arm64 attaches itself with gh release upload --clobber, which fails on a missing file and is verified from the release side. The two base bundles were the exception: the central release job attached them with softprops files:, which does NOT fail on an unmatched file. So when a run produced no base zip, softprops created the release with none of them and reported success - and v10.63 shipped with no amd64 or arm64 bundle at all, which 404’d every snap build (native, wekan-ondra, wekan-gantt-gpl) on wekan-10.63-amd64.zip. softprops also never listed the .sha256sum, so the base bundles had no checksum beside them. The release job now creates the release with softprops (so it exists for the self-attaching jobs) and attaches amd64/arm64 in a following step with gh release upload --clobber - failing the release if a base bundle is missing or empty, rather than 404’ing ten downstream jobs - and it checksums the exact bytes it attaches, so the base bundles get a .sha256sum like the rest. (Why the base zip was missing in the first place is the next entry - the loud, verified attach is what turned that silent gap into a failed release that names it.)

The real reason v10.63 (and then v10.64) shipped with no amd64/arm64 bundle was not softprops - it was the checkout. The release job downloaded the bundles into the workspace and THEN ran actions/checkout for the provenance script. The workspace is not a git repository at that point, so checkout’s very first act is “Deleting the contents of ‘<workspace>’” to make room for a fresh clone - and it does this even with clean: false, which only skips the git clean in an already-checked-out repo, not the initial wipe. The just-downloaded wekan-<version>-{amd64,arm64}.zip were deleted before the attach step, which then failed with “wekan--amd64.zip is missing or empty” - and, because of the loud attach above, that now failed the release outright rather than shipping an empty one. The checkout runs FIRST now, into the empty workspace, and the bundles are downloaded on top of the checked-out tree, where nothing removes them. tests/releaseBundlesSurviveCheckout.test.cjs pins the order (checkout before the bundle download) rather than clean: false, which was never enough.

build-extra-arches failed on i386 and armhf because there is no Node.js to build them against: Node has no linux-x86 build at all, and no source builds Node 24 for armv7l (nodejs.org and unofficial-builds have neither, and the wekan/node fork has not built them yet). A red job every release for a CPU nothing can currently produce a Node for is noise, not news. Both are now marked best-effort (optional: true), and when a best-effort arch’s Node.js is absent everywhere releases/check-arch-binaries.sh emits skip=true (a warning, exit 0) rather than a fatal error; every build step in the job is gated on it, so the arch is skipped cleanly with nothing built. It returns on its own the first release after wekan/node publishes node-i386 / node-armhf. A required arch whose Node.js is missing is still fatal, as before. tests/releaseArchSkipAndBaseAttach.test.cjs pins both this and the base-bundle attachment above.

Opening an admin report by its address - /admin/problems/files typed, bookmarked or refreshed - drew the column headers, “No results” and a “1 / 1” pager over data that was plainly there, while the count method reported five. An earlier fix addressed one half (re-subscribe once the login lands), but the report still came up empty. The onCreated autorun opens the pane and subscribes when the open-pane or the logged-in user changes, and it called openReportPane() / loadReport() directly in its reactive body - so it became reactive on cfg.count (which loadReport reads through pageInfo), and loadReport’s own count method then did cfg.count.set(...). That re-ran the autorun, and a Meteor.subscribe made inside an autorun is AUTO-CANCELLED when the autorun re-runs; the re-run took the “same user, same pane” path, did not re-subscribe, and left the report with no subscription - attachments in minimongo: 0. From the left menu it worked, because that opens the pane from an event rather than a computation, so the subscribe was never auto-managed; only the URL path hit it. The autorun now reads only the pane id and the user reactively and runs its body inside Tracker.nonreactive, so a count re-render no longer cancels the subscription, whose lifetime is managed explicitly (a new onDestroyed stops the last one). tests/adminReportsSubscriptionLifetime.test.cjs pins it.