docs(admin): t-paliad-072 — m greenlighted all 5 open Qs

DB-backed (Q1), subjects customisable with SYSTEMAUSFALL comment in seed
(Q2), base.html editable (Q3-A), 20-version retention (Q4), note field
kept (Q5). Coder shift unblocked from the inventor side.

docs/design-email-templates-2026-04-29.md

@@ -506,41 +506,23 @@ one PR or split.
 
 ---
 
-## 8. Open questions for m
+## 8. Open questions for m — RESOLVED 2026-04-29
 
-1. **DB-backed editing confirmed?** The brief recommends DB; this design
-   builds on that. If you want filesystem-only, scope shrinks to "preview +
-   variable docs" (no edit, no save, no versions) and the admin card text
-   should change to match.
-2. **Subject moves into templates.** Today `buildDigestSubject` and
-   `inviteSubject` are Go code. After this design they become the `subject`
-   column of the (`deadline_digest`, lang) and (`invitation`, lang) rows.
-   That means the SYSTEMAUSFALL / DRINGEND / URGENT subject framing
-   becomes admin-editable. **OK?** Risk: an admin softens "SYSTEMAUSFALL"
-   to "Bitte beachten" and the SLO-no-overdue framing weakens. Mitigation:
-   leave a comment in the seeded subject template explaining the framing
-   (`{{/* keep the SYSTEMAUSFALL phrasing — see docs/design-reminder-redesign-2026-04-28.md */}}`)
-   so the next admin who edits sees the rationale.
-3. **`base` editable, or locked?** The shared wrapper sets the brand
-   colours, lime header, footer link. Letting admins edit it lets them fix
-   a footer typo without code, but they can also break every email at
-   once. Two options:
-   - **A**: Editable like the others, full versioning. Risk above accepted.
-   - **B**: Read-only in the editor (preview + variable docs only); only
-     content templates are editable. Admin who needs to change the
-     wrapper opens a Gitea issue.
-   I lean **A** — the version log + reset-to-default + render-time fallback
-   on parse error is enough safety net, and the alternative leaves a
-   foot-gun where the only escape is "redeploy". Confirm.
-4. **Versioning depth.** Proposed 20 per (key, lang). Going to 5 (task
-   suggestion) saves nothing meaningful (table is tiny) and increases the
-   chance the version a user wants is already gone. Going to "unbounded"
-   is fine too — scale is negligible. **20 OK?**
-5. **Edit log on the version rows: does it include the `note` text field?**
-   I added `note` to capture intent ('reset', 'restore from <version_id>',
-   user-provided "Korrektur Apr-29 nach Anwalts-Feedback"). The save form
-   would have a small optional "Notiz" input. **Worth it, or strip the
-   field?**
+1. **DB-backed editing confirmed?** → **YES, DB.**
+2. **Subjects move into templates (admin-editable)?** → **YES, customisable.**
+   Mitigation kept: seeded `deadline_digest` subject ships with a
+   `{{/* keep the SYSTEMAUSFALL phrasing — see docs/design-reminder-redesign-2026-04-28.md */}}`
+   comment so the next admin who edits the SLO-critical framing sees the
+   rationale.
+3. **`base.html` editable, or locked?** → **A. Editable like the others.**
+   Version log + reset-to-default + render-time fallback on parse error
+   are the safety net.
+4. **Versioning depth** → **20 per (key, lang). Confirmed.**
+5. **`note` field on version rows + optional "Notiz" input on save?** →
+   **YES, keep.**
+
+All decisions baked into §1–§7. No remaining blockers from the inventor
+side; coder shift can start once head greenlights.
 
 ---