fix(installer): declare Imager device metadata so the documented flow reaches FTW

[HuggeK]

The install flow in docs/rpi-image.md does not work with Raspberry Pi Imager. Three separate things go wrong, in the order a user hits them.

1. The doc points at the wrong control. Imager 2.x's Content Repository dialog has three radio options: Raspberry Pi (default), Use custom file, and Use custom URL. The doc says Use custom file and then supplies a URL — but that option opens a file picker for a manifest already on your computer, with no field to paste a web address into. The hosted FTW manifest belongs in Use custom URL.

2. The device chooser is empty and Next is disabled. Imager 2.x opens on "Select your Raspberry Pi device" and builds that list solely from imager.devices in whichever manifest it was pointed at — a custom repository replaces the stock manifest rather than extending it. FTW's manifest had no imager object at all, so HWListModel::reload() bailed with missing imager and the list stayed empty. Next is gated on hasDeviceSelected || (osListUnavailable && hwlist.count === 0); the OS list had loaded, so the offline escape hatch did not apply. The wizard dead-ends before FTW is ever reachable.

3. The entry claims no hardware. os_list[].devices was absent. Imager keeps a devices-less entry only when the selected device matches inclusively — Raspberry Pi 5 matches exclusively, so FTW would have been filtered out even once a device was selectable. The field is also required by Imager's published schema.

Where each behaviour lives in rpi-imager

Behaviour	Source
Three repository options	src/wizard/dialogs/RepositoryDialog.qml — Use custom file = "Load operating system list from a JSON file on your computer"; Use custom URL = "Download operating system list from a custom web address"
Device list built from imager.devices	src/hwlistmodel.cpp — reload() returns early on missing imager
Next gated on a selected device	src/wizard/DeviceSelectionStep.qml — nextButtonEnabled: hasDeviceSelected || (osListUnavailable && hwlist.count === 0)
devices-less entries dropped	src/imagewriter.cpp — filterOsListWithHWTags() keeps them only if (inclusive)
Exclusive vs inclusive	src/hwlistmodel.h — isInclusive() is true only for matching_type == "inclusive"; upstream ships Pi 5 as exclusive
devices required	doc/json-schema/os-list-schema.json

What this changes

• deploy/imager/os_list.json — adds imager.devices (Pi 5, Pi 4, and "No filtering", using Imager's own tag names and icons) and tags the FTW entry pi5-64bit / pi4-64bit, matching the arm64 image actually built.
• docs/rpi-image.md — Use custom URL instead of Use custom file, with a note on why they differ; adds the device-selection step; rewrites the closing rationale, which had it backwards.
• CI — rpi-image-build.yml asserts both lists exist and agree; release-assets.yml warns rather than fails.

Why the release-assets check warns instead of failing

That step mirrors the already-published os_list.json from the rpi-installer release onto a version tag. Until a new installer image is built, that published file still lacks the new fields. The installer image is explicitly independent of application releases, so failing there would block an unrelated version release on a stale artifact. It emits a ::warning:: naming the fix (rerun rpi-image-build.yml) instead.

The old rationale, and why it was backwards

The doc previously read:

The Imager repository entry intentionally has no devices filter. Custom repositories do not receive Raspberry Pi Imager's stock hardware list, so a filter would hide FTW from the chooser even though the image supports Pi 4/5.

The first sentence is right about the mechanism — a custom repository genuinely does not inherit the stock hardware list — but draws the opposite conclusion. Because the stock list is not inherited, the manifest must supply one; omitting it doesn't widen compatibility, it removes the chooser entirely. And an untagged entry is less reachable, not more, since exclusive matching drops it.

Verification

• Both jq guards run against the manifest, and are rejected by three regression fixtures: imager deleted, os_list[].devices deleted, and a tag (pi3-64bit) the chooser never offers.
• The CI render step was simulated end to end; the rendered manifest keeps imager.devices, drops all placeholders, and passes both guards.
• The rendered manifest satisfies the schema's required-field and init_format enum contract (cloudinit-rpi is valid and was never the problem). Checked directly rather than with jsonschema, which isn't installed locally.
• The release-assets.yml warning branch was exercised both ways: silent on the fixed manifest, warns and still exits 0 on a stale one.

Not verified: no Raspberry Pi Imager run against the published manifest — that needs a rebuilt installer release, since the live os_list.json only picks up these fields once rpi-image-build.yml republishes it.

🤖 Generated with Claude Code