WeKan could always have shipped this and simply did not. All three suppliers
publish the architecture: nodejs.org builds node-v24.19.0-win-arm64.zip
itself, wekan/FerretDB publishes
ferretdb-win-arm64.exe, and
wekan/mongo-tools-patches
publishes every tool as -win-arm64.exe.

releases/resolve-node-source.sh gains the platform and resolves it to
nodejs.org with a published SHA256, so it needs no node-patches build at all.
The job is the win64 one with the architecture changed: it builds on the x64
Windows runner exactly as win32 does, because the Meteor bundle is JavaScript,
the native modules are installed with --ignore-scripts and are not compiled
for the runner's architecture either way, and the only architecture-specific
things in the zip are the three binaries above, which are downloaded rather
than built.

What cannot be added, checked at the same time: armv5 and armel. FerretDB
and the MongoDB tools publish armel - they are Go, and Go still targets it -
but Node.js does not exist for either, and it cannot be built either: V8's
accepted --arm-arch list stops at armv6. No Node.js means no bundle, so no
Docker image and no snap either. armv6 was checked in the same pass and looked
like the same answer - nodejs.org publishes no 32-bit ARM at all for v24.19.0
and unofficial-builds has no armv6l - but there the SUPPORT was still in the
source and only the build was missing, which is what the next entry does.

Every piece of the chain exists now, and the piece that was missing was
Node.js. nodejs.org dropped its ARMv6 binaries after Node 11 and
unofficial-builds has none, so
wekan/node-patches gained an armv6
target - V8 still accepts --arm-arch=armv6 and configure.py still carries
is_arch_armv6() with vfp among its valid ARM FPUs, so only the build was
missing - and wekan/FerretDB and
wekan/mongo-tools-patches
gained GOARM=6 targets beside their armhf ones.

Their armel is GOARM=5 and WOULD run on these boards, which is exactly why
it looks like a substitute and is not one: GOARM=5 does floating point in
software, and an ARMv6 board has VFPv2.

The bundle builds in a linux/arm/v6 container and takes node-armv6, and
releases/resolve-node-source.sh resolves it - naming linux-armv6l as the
upstream spelling even though nothing upstream will ever answer to it, so the
search it prints is honest about where it looked.

No snap, and that is not an oversight. The Snap Store has no armv6
architecture at all - its only 32-bit ARM is armhf, which is ARMv7-A
hard-float and will not run on an ARMv6 board. So armv6 ships as a bundle zip
and a linux/arm/v6 Docker image, and models/lib/snapArchitectures.js
records that reason in NOT_SNAP_ARCHITECTURES beside i386's and armv7's.

Four tests found the four places a new platform has to be registered, which is
what they are for: releases/expected-assets.sh (or "Release all missing"
never notices the asset is absent), the resolver's mapping table, the
non-native bundle list, and the snap-platform exemption. Each list was updated
rather than the guard loosened.

What is not verified: none of these binaries has been built yet. The
Node.js one is a multi-hour ARM cross compile and the first CI run is its test.
Everything checkable from source was checked - V8's accepted --arm-arch
values, configure.py's ARM handling, Go's GOARM semantics, and that zlib's
ARM SIMD is gated on arm_fpu == "neon", so an armv6 build selects the scalar
code by itself and needs none of the NEON patching armv7 does.

TARGETARCH does not identify a 32-bit ARM platform. linux/arm/v6 and
linux/arm/v7 both arrive in the Dockerfile as TARGETARCH=arm; the CPU
generation is in TARGETVARIANT. The architecture case mapped arm straight
to armhf, so the moment armv6 existed as a bundle, an ARMv6 build would have
been handed the armhf zip — ARMv7-A instructions for a CPU that cannot execute
them. It now branches on the variant: v6 takes the armv6 bundle, v7 and an
unset variant take armhf, and anything else exits. v5 is armel: FerretDB and
the MongoDB tools publish it, but Node.js does not exist for ARMv5, so there is
no bundle and refusing is the only honest answer.

linux/arm/v6 is in the docker job's optional platform list beside the others,
and the release then asks a question it never asked before: does the base
image publish this platform? For every other architecture that question is
uninteresting, because a base that lacks one fails the build. For 32-bit ARM it
does not fail — containerd treats a lower ARM variant as compatible, so a
linux/arm/v6 request against a base with arm/v5 and arm/v7 quietly
resolves to arm/v5, Debian armel, soft float. The image would build on a
userland whose loader cannot start the hard-float node-armv6 inside the
bundle. A silent downgrade is worse than a dropped platform.

So the job reads the base name out of the Dockerfile — no second copy of it —
asks docker buildx imagetools inspect what that base publishes, and drops a
candidate it lacks with a warning saying why. Today debian:trixie is 386,
amd64, arm64/v8, arm/v5, arm/v7, ppc64le, riscv64, s390x: no
arm/v6, because Debian has no ARMv6 port — its 32-bit ARM ports are armel
and armhf, and ARMv6 hard-float is Raspberry Pi OS territory. The armv6
bundle zip is unaffected, and that is how an ARMv6 board runs WeKan today; the
image platform is wired end to end and turns itself on the day a base publishes
the variant, with nothing else to change.

Checked against the real registry rather than assumed: debian:trixie's
manifest list was read, and the decide step was run against both that list
(armv6 drops, the other seven build) and a base that does publish arm/v6
(armv6 is included, paired with the armv6 bundle).
tests/releaseDockerPlatforms.test.cjs pins the variant split, the refusal of
v5, the platform-to-bundle pairing, and that both loops ask the base — the
last one so that "just delete the check" cannot quietly become an image whose
Node.js will not start.

Admin Panel / Settings / Version was ONE table of 38 rows, in which the WeKan
version, the OS load average, the DDP transport and a V8 heap counter were the
same kind of thing: a flat list read top to bottom, with no way to jump to the
part you came for.

It is five tables now, each under a small heading, in the order somebody
debugging reads them — Platform (what this is), OS (what it runs on),
Meteor (how it talks to the client), Database and Node. Reactivity,
reactivity order and the DDP transport moved to Meteor, where they belong: they
are how the client is fed, and they were the rows most often read as database
settings. Whether an OpLog exists stays with the database, because that is a
property of it. Nothing was dropped — a test lists all 38 rows by name and
requires each to still be shown.

The new row is what WeKan is installed as: bundle.zip, Snap, Docker or
Sandstorm. It is the first thing a support answer turns on and the pane
never said it: the same version keeps its data somewhere else, carries a
different database and gives the admin different reach in each of the four.
The row's label is translated (package, "Package"); the four values never
are, and none of them is a translation key — they are the names of the things
themselves, not words describing them, so what an admin reads is the same string
they can put in an issue, search the docs for and grep a log with, in every
language.
models/lib/platformPackaging.js decides it most-specific-first — an explicit
WEKAN_PACKAGING wins, then Sandstorm, then snapd's own SNAP/SNAP_NAME,
then a container runtime's marker file, then the bundle. Sandstorm and Snap are
asked BEFORE the container markers on purpose: a grain is a container and a
confined snap can look like one, so the other order answers "Docker" for both.
It claims nothing it cannot know: there is no "source checkout" answer, because
a meteor run and an unpacked bundle are identical from inside the process.

The detection is a pure function — it takes the environment, the Sandstorm flag
and a file-exists callback — so all nine of its tests run in a sandbox with no
snap, no container and no grain: that an empty SNAP is not a snap, that an
empty WEKAN_PACKAGING falls through instead of blanking the field, and that an
unreadable filesystem root answers bundle.zip rather than throwing away an
admin's Version page.

The headings are deliberately smaller than the pane title above them, and a test
compares the two font sizes instead of trusting the CSS to stay that way: five
headings at the pane title's size read as five pane titles, and "Version" is
lost among them.

Two failures in the v10.78 snap jobs, neither of them a problem with WeKan.

armhf asked for a Caddy architecture that does not exist. With the
libcurl4t64 fix in, the armhf build got past the stage-packages and died
further along:

:: Downloading Caddy 2.11.4 (linux/armhf) from GitHub releases...
:: curl: (22) The requested URL returned error: 404
'override-build' in part 'caddy' failed with code 1.

Caddy is built by Go and its release assets carry Go's architecture names,
not Debian's. There is no linux_armhf archive and there never has been - the
32-bit ARM ones are armv5, armv6 and armv7 - and the case statement had no
armhf branch, so it fell through to a default that passed the Debian name
straight into the URL. The "fall back to the pinned version" path then retried
the same wrong name, so the failure read as "Caddy stopped publishing this
architecture" when it was this file's mapping all along.

armhf maps to armv7, not armv6: Debian armhf's baseline is ARMv7-A with
VFPv3-D16 hard-float, and Go's armv7 build is GOARM=7, which is exactly that.
This is not the armhf/armv7 distinction that matters for Node.js in
wekan/node-patches - that one is about
NEON, and GOARM=7 does not use NEON. Checked against the actual release: all
six mapped URLs answer and linux_armhf 404s. The default branch now names the
problem and stops, instead of guessing a name and letting a 404 blame the wrong
project.

Three good snaps were lost to a store hiccup. riscv64, ppc64el and s390x
each built on Launchpad, downloaded, and were then refused:

Status: error while processing
Issues while processing snap:
- binary_sha3_384: Error checking upload uniqueness.

That is the store failing its own duplicate check on a digest it had just
computed - a server-side error, not a bad snap - while the message the job
printed was about "is not a valid file", credentials and ACLs, none of which
applied. The upload is retried three times with a backoff now, and the give-up
message says the snap is fine and nothing here needs changing. The retry stays
narrow on purpose: a rejected file, unparseable credentials or a missing ACL
will be rejected identically three times, and retrying those only buries the one
message that says what to fix - so the classifier is tested against all four,
not just the one that happened.

snapcraft.yaml declares six platforms — amd64, arm64, armhf, ppc64el, riscv64,
s390x — and every one is built: two natively, four on Launchpad.
snapcraft-core26.yaml declared five. armhf was missing, and nothing could
notice: that file is not built by any release, it is the next base kept so the
move can be tested before it is made. The day core26 becomes the base, armhf
would simply stop being published, and the only symptom would be a store column
going stale — exactly as wekan-ondra's armhf did at 0.22.

Adding the platform alone would have been nominal. The same file still carried
the pre-t64 stage-package names — libssl3, libcurl4,
libgoogle-perftools4 — and those are precisely what failed armhf on core24
twice: Ubuntu's 64-bit time_t transition renamed them, the 64-bit
architectures kept a compatibility Provides so the old spelling resolves
there, and armhf did not. armhf on core26 would have failed on the first thing
it tried, in the way this repository has already debugged. It has the t64 names
now, and its Caddy branch — which already mapped armhf to Go's armv7 — no
longer claims to be unreachable.

Two guards, both checked in the failing direction as well: the two snapcraft
files must declare the SAME set of architectures, and the stage-package check
runs over BOTH files instead of only the one the release builds.

Nothing here changes what the release builds today. core24 stays the built base,
and wekan's armhf snap is still waiting on the Caddy armhf fix above.

The amd64 build failed with exit 127, after the bundle had been zipped and
checksummed:

a95d331b…  wekan-10.78-amd64.zip
bash: releases/record-provenance.sh: No such file or directory
bash: releases/ferretdb-latest-tag.sh: No such file or directory

The step runs cd .build first, so nothing relative in it means what it looks
like it means - and that is two bugs, of which only the second had ever been
visible. bash releases/record-provenance.sh resolves against .build/, which
has no releases/, so it had printed "No such file or directory" on every run
since it was written and the || true on the end swallowed it. amd64 had
therefore never recorded any provenance at all, and the only symptom was its
absence from the table - so the missing-directory fix above repaired the half
that showed and left the half that did not.

What made it loud is that the FerretDB tag lookup added alongside it is an
assignment. Under set -e, and every GitHub run: is bash -e,
VAR="$(cmd)" ends the step when the command fails - so a line that had been
quietly doing nothing for months became a hard failure of the whole amd64 build.

Every path in that step is absolute now, and every FERRET_TAG assignment
across all seven sites ends || true: the bundle is the deliverable, and which
version string reaches a markdown cell is not worth failing a good build for.
Only amd64's step cds - the other six run from the workspace root, which is
exactly what the v10.77 run showed, since all six uploaded provenance and amd64
did not.

The guard added with it is the general form rather than this one line: it walks
back from every provenance call to its step header and requires an absolute path
whenever a cd runs inside that step.

"Which CPUs is this published for, and why not that one" was answerable for the
snap and nowhere else, so the same page now exists for the image:
docs/Platforms/FOSS/Container/Docker/CPU-platforms.md. It carries the
platform matrix with each platform's TARGETARCH, TARGETVARIANT and bundle,
how the set is decided on every release from what the base image publishes and
which bundles landed, the three names that differ between Docker, Debian and the
WeKan bundles, and one section per platform that is deliberately NOT an image:
loong64 (no base image exists at any tag), armv6 (gated on a base with
arm/v6), armv7 (the one 32-bit ARM slot must carry the armhf baseline) and the
Windows and macOS bundles. It ends with why the FerretDB image covers more
platforms than the WeKan one — FROM scratch around a static Go binary needs no
userland at all.

The snap's page gains the matching armv6 section — the Snap Store has no armv6
architecture, and its only 32-bit ARM is armhf, which an ARMv6 board cannot
run — and a table of all fifteen bundles against which six become snaps, so
"it is missing" and "it cannot be there" stop looking alike. The two pages link
each other, because the answer differs between them.

docs/Databases/FerretDB/1/README.md said the per-architecture FerretDB binary
was embedded in the bundles "for ppc64le, s390x, riscv64". Every bundle carries
one; those three are part of a longer list of platforms where it is the DEFAULT
because MongoDB publishes no server. It now lists all seventeen built binaries
and separates the three 32-bit ARM builds that are not variants of each other:
armhf is GOARM=7, armv6 is GOARM=6, armel is GOARM=5 software
floating point.