# REPORT — D53: the hub learns which apps are held — committed, NOT released (2026-10-26 evening)

**Plain words first.** A held app (stopped on purpose until a person acts) now reaches the hub: the box sends one
message when a hold appears or changes, one when it goes, and repeats every hold once a day. The hub shows the list
and mails the operator after a waiting time (felhom.eu `7e57e824`). Not released (this run allows no release).

## The change (`5bd03ad`, CI 2377 ✓)

- `internal/holdreport`: one observer of the hold store, ticked every minute by the scheduler (`hold-report`). It sends
  `app_held` (stack, reason, since, the hold's sentence) for a new or changed hold, `app_hold_cleared` when a hold is
  gone — also one cleared while the controller was down (`settings.reported_holds`) — and every hold again daily and at
  start. Severity info.
- `settings.RestoreHold.Why()` / `WireReason()`: the hold sentence lives in one place (`holdWhy` calls it); the legacy
  empty reason is sent as `restore_failed`.
- Tests `internal/holdreport/holdreport_test.go` (8). Red-proved: an inert `Tick` failed all six behaviour tests; the
  scheduler line commented out failed the wiring test.

## Live proof (felhom.eu `documentation/audits/d53-held-apps-2026-10-26/`)

9202 ran a local-only image of this commit (`0.346.0-d53test`, never pushed to the registry) against a test hub process.
A throwaway Radicale, crashed seven times, was stopped and held by the box (17:37:52Z); `app_held` reached the hub at the
next tick; one operator reminder after the 3-minute test grace; the household's Start lifted the hold and
`app_hold_cleared` removed the row. The first tick also reported four holds 9202 has carried since 2026-09-24 for apps
that are not installed (felhom.eu R-1298). 9202 is back on 0.343.0 with its own config.