felhom-controller/REPORT.md

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.