v0.279.0: after_install (decision 45), known default logins on the page, Part D empty-backup alarm, night chain (R-705), R-706

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0159rPz1ZhFKsS53msqPYxtS
2026-09-28 18:38:30 +02:00
parent 2e9a948cbd
commit 0c702f834a
35 changed files with 1119 additions and 16 deletions
@@ -1916,6 +1916,10 @@ that folder is never a dead end, and an install never runs into it silently (R-6
 - **Where it lives.** `<drive>/kept/` is beside `appdata/` and `userdata/`, inside neither: no app bind, FileBrowser
  userdata source, Samba share or backup leg reads it. It is in `ProtectedHDDPaths`.
 - **The drive-full warning** ends with the kept folders on that drive and their sizes (`fillwatch.SetExtra`).
+- **`after_install:` (v0.279.0, decision 45)** — `{service, user?, env: [NAMES], command: [...], success: MARKER}`: one
+  command in the app's own container after a FRESH install (never after a restore or a kept-data load), with the named
+  deploy values filled into `${NAME}`; the output must carry `success`. Recorded in `app.yaml` `after_install`; the app
+  page hides the default-login card once it succeeded and warns while a default login is in effect.
 - **R-704 (v0.278.0).** A new install (plain or "use my kept data") drops an update or crash-loop hold left by an EARLIER
  install of the app, and a removal clears both kinds; a restore hold (R-379) stays operator-cleared.
 - **R-690 (fixed here).** The removed-app restore (R-487) never found a unit on a DATA drive — it asked