Publish every beta and stable release to the Home Assistant add-on repository

[HuggeK]

Summary

Every FTW beta and stable release should reach Home Assistant users through the official add-on repository, srcfl/home-assistant-addons, without a manual step per release:

• beta cut (beta.yml, tag vX.Y.Z-beta.N) → add-on ftw-beta publishes version X.Y.Z-beta.N, built from the exact Core image digest of that beta.
• stable promotion (release-assets.yml, tag vX.Y.Z) → add-on ftw publishes version X.Y.Z by re-tagging the add-on beta image whose Core digest FTW just promoted. No rebuild, same rule FTW itself follows.

Two pull requests implement this; links are in the comments below once they are up.

Why it does not work today

The add-on repository is pinned to add-on 0.1.0-beta.1 = Core v1.10.0-beta.1 (July 2026) and has not moved since 2026-08-17, while Core has shipped every beta from v2.x through v3.4.2-beta.4.

The three blockers

1. The add-on image is built on the retired optimizer image. ftw/Dockerfile there is FROM ${FTW_OPTIMIZER_FROM} and its run.sh starts /opt/venv/bin/ftw-optimizer. refactor: retire Python optimizer and separate updates #1083 removed that image on 2026-09-07; the compiled Energyplan worker now ships inside ghcr.io/srcfl/ftw. No add-on can be built from any Core newer than that.
2. The sync gate waits for evidence FTW never writes. scripts/upstream_sync.py refuses a Core pin unless the GitHub release body contains a live pilot link into srcfl/ftw. FTW's generated release notes never carry one, so the hourly Sync upstream FTW run has logged Core vX has no labeled live-pilot evidence; retrying later for four weeks.
3. FTW never notifies the add-on repository. Its sync-upstream.yml already accepts repository_dispatch of type ftw-release, but nothing in beta.yml or release-assets.yml sends it.

What the pull requests do

srcfl/ftw (small, CI only):

• beta.yml gains a final job that sends repository_dispatch ftw-release with channel: beta, the tag and the commit to srcfl/home-assistant-addons after the prerelease and its digest receipt exist.
• release-assets.yml sends the same with channel: stable after the stable release is public.
• Both steps use a new secret HA_ADDON_DISPATCH_TOKEN. When it is unset they log a notice and succeed, because the add-on repository still polls hourly. The release is never blocked by the add-on.

srcfl/home-assistant-addons (the bulk):

• Build the add-on FROM the pinned Core digest only. Drop the optimizer image, worker supervisor loop, Unix socket and Python health check; Core already bundles Energyplan and its Go planner fallback.
• Add the ftw-beta add-on next to ftw. Both share one image, ghcr.io/srcfl/home-assistant-addons/ftw, tagged by version.
• The add-on version mirrors the Core version (3.4.2-beta.4, 3.4.2). One upstream component no longer needs a separate version line.
• The sync verifies each pin against the registry (multi-arch index, revision and version labels) and against FTW's own release receipt (ftw-image-digests.json for beta, ftw-promotion-receipt.json for stable) instead of a release-body regex.
• Stable promotion stays a retag of the tested add-on beta digest, and stays blocked until one Home Assistant OS and Supervisor pilot is recorded in compatibility.yaml.

Owner setup, and what is deliberately not automated

• Secret. HA_ADDON_DISPATCH_TOKEN in srcfl/ftw: a fine-grained PAT (or GitHub App token) with Contents: read and write on srcfl/home-assistant-addons only. The job-scoped GITHUB_TOKEN cannot dispatch to another repository. This is repository setup, like the registry credentials in AGENTS.md, not a release step.
• First stable. The add-on's stable channel only publishes after a person records a passed HA OS pilot. HuggeK has volunteered to run that pilot on the first beta built from these changes.
• Cadence. Every Core beta becomes an add-on beta. Core cut eight betas in the last five days, so ftw-beta users will see that many update prompts. That is what a beta slug is for; the stable slug moves only when FTW promotes.
• Switching channels. ftw and ftw-beta are separate Home Assistant apps with separate /data. Moving between them means restoring a backup into the other app.

[HuggeK]

Both pull requests are up:

• ci: notify the Home Assistant app repository on every beta and stable release #1238 adds the ftw-release dispatch to beta.yml and release-assets.yml (CI-only, plus one paragraph in AGENTS.md about the HA_ADDON_DISPATCH_TOKEN secret).
• feat: build from Core alone and publish beta and stable apps home-assistant-addons#8 rebuilds the app from the Core image alone, adds the ftw-beta app next to ftw, and makes the sync verify pins against FTW's release receipts. It is seeded to Core v3.4.2-beta.4, so merging it publishes the first beta.

Order does not matter: the app repository keeps polling hourly, and the dispatch is a no-op until the secret exists.

Testing plan after #8 merges: install FTW (beta) from the repository, run the checks in pilot/README.md, and record the result in compatibility.yaml with a small PR. That unlocks the stable app for the next FTW stable promotion.