feat: build from Core alone and publish beta and stable apps

[HuggeK]

Part of srcfl/ftw#1233. Companion: srcfl/ftw#1238 makes FTW send the ftw-release dispatch this repository already listens for.

Why

The app has been stuck at 0.1.0-beta.1 (Core v1.10.0-beta.1) since July. Its image was built on the optimizer image that srcfl/ftw#1083 retired, and the sync waited for a "live pilot" link that FTW's generated release notes never contain, so every hourly run since 2026-08-17 ended with retrying later.

What changes

App	Slug	Follows	Version
FTW (beta)	ftw-beta	every FTW beta	X.Y.Z-beta.N
FTW	ftw	every FTW stable, once the pilot is recorded	X.Y.Z

• Core only. ftw/Dockerfile is FROM ghcr.io/srcfl/ftw@<digest> plus run.sh and a wget-based healthcheck.sh. No apt, no optimizer loop, no Unix socket, no Python in the app layer. Supervisor's default init reaps; run.sh execs Core as uid 100.
• Two apps, one image. ftw-beta/config.yaml is new. ftw/config.yaml appears at the first stable promotion; the sync renders it from the beta manifest. Both install ghcr.io/srcfl/home-assistant-addons/ftw:<version>, and the app version mirrors the Core version.
• Sync. upstream_sync.py pins the newest FTW beta into ftw-beta, and the newest FTW stable into ftw by promoting the app beta whose Core digest FTW's ftw-promotion-receipt.json names. Every pin is checked against FTW's receipt and the registry (multi-arch index, revision and version labels). The signed stable driver manifest is recorded at pin time; the gate verifies the live manifest's signature rather than requiring equality with a July snapshot, which would have failed the first publish.
• Workflows. sync-upstream.yml keeps its hourly schedule and the ftw-release dispatch, stages both apps and dispatches auto-publish.yml (was auto-publish-beta.yml), which dispatches Publish beta and Promote stable for versions without a tag. Publish beta builds from the Core digest; Promote stable still re-tags the beta digest and never rebuilds.
• Pilot. The per-version pilot/*.yaml records give way to one qualification.home_assistant_os_supervisor block; stable promotion refuses to run until it says passed. pilot/README.md is the checklist.
• compatibility.yaml moves to schema 2; validate.py, release_gate.py, the workflows, docs and tests follow.

Seeded state

ftw-beta is pinned to Core v3.4.2-beta.4 (commit fc1c7af9, digest sha256:06ab3751d55527dc557c239307124ab9c131401bba83057b3cb4b52c0643864c), checked against FTW's ftw-image-digests.json and the GHCR manifest. Merging publishes that beta through Auto publish → Publish beta.

Validation

• Fork CI on this branch: repository checks (validator, unit tests, shellcheck), the Home Assistant linter on ftw-beta, and the container smoke test on amd64 and aarch64. Run: https://github.com/HuggeK/home-assistant-addons/actions/workflows/check.yml?query=branch%3Aha-core-only-channels
• The smoke test also ran locally against the fixture Core: start, health, bundle environment, unprivileged Core, config and user-driver persistence across a restart, no updater process, and container exit when Core dies.
• Not run: Publish beta and Promote stable themselves (they run only from main here) and a Home Assistant OS install. HuggeK has volunteered to run the pilot in pilot/README.md on the first published beta.

Decisions worth an explicit yes or no from the owner

• The app version mirrors the Core version. RELEASING.md used to say the app keeps its own SemVer because Core and Optimizer had separate lines; with one upstream component that rule no longer buys anything.
• Every Core beta becomes an app beta. Core cut eight betas in five days, so ftw-beta users see that many update prompts.
• The driver baseline is recorded, not gated on equality, because the stable driver channel moves independently.
• The sync pins only the newest beta. If FTW later promotes an older beta that was never built here, stable waits for the next promotion; RELEASING.md documents it.
• Anyone who installed the old ftw 0.1.0-beta.1 sees the app leave the store until the first stable promotion; the stable changelog says so.

🤖 Generated with Claude Code

https://claude.ai/code/session_014Mn3h7AgWsYcNgPGSCBU62

[miravoss26]

Solid simplification. Drops the whole ftw-optimizer sidecar (socket, PID file, monitor/restart loop in run.sh) now that Core ships the optimizer worker itself — the wrapper shrinks from 159 to ~20 lines and the Dockerfile loses a whole build stage + two ARG pairs. healthcheck.sh swaps the old Python health checker for the wget Core already carries, matching the "no apt, no Python in the app layer" goal stated in the description.

Two things worth a second look, not blockers:

• The two-app split (ftw-beta always tracks the newest beta, ftw promotes once qualification.home_assistant_os_supervisor says passed) is a real behavior change for existing ftw 0.1.0-beta.1 installs — they lose the app until first stable promotion. The PR body already flags this and says the stable changelog covers it, so that's the right place for it, just confirm it actually lands before merge.
• release-beta.yml's marker check (__PUBLISHED_BY_BETA_WORKFLOW__) is removed rather than adapted — worth a beat to confirm that guard wasn't catching a real race (double-publish), not just dead code from the old optimizer-coupled flow.

CI green across repo checks, addon lint, and both amd64/aarch64 smoke builds. Not on the auto-merge allowlist (home-assistant-addons isn't a listed repo), so this needs a human merge regardless — safe to merge from my read.