docs(arbeitskacheln): Open-Source-/HiOrg-Vergleich ausgewertet, 14 neue Kacheln ausgearbeitet

Vergleich mit InvenTree, Snipe-IT, Grocy, Shelf.nu, Resgrid, KP Front, FleetMS,
HiOrg-Server ergibt neue Kacheln (ASSET-010 Custody, FILE-008 Hash-Audit-Journal,
FILE-009 Notizen, NOTIF-003, MAINT-007 Tankbuch, ZUST-003 Standort-Scoping,
FOUND-007 Import/Export, FOUND-008 Fristen-Dienst, READY-006 Statistik-Dashboard,
UI2-006..010) sowie Referenz-Ergänzungen bei bestehenden Lücken. Alle Design-
Entscheidungen (Datenmodell, Sicherheitsanforderungen bei ASSET-010) geklärt.

Neues Epic 23 (Flutter-Begleit-App, Sondierungs-Prototyp FLUT-001) inkl. geklärtem
TLS-Blocker (Domain mabea.perlbach-edv.de mit Let's-Encrypt-Zertifikat statt
selbstsigniertem Server-Zertifikat).

Alle Kacheln bleiben offen/ungeplant, nur ausgearbeitet, keine Implementierung.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVgbozhYmuEhiEJHffRXCV

arbeitskacheln/03_digital_file.md

@@ -1,6 +1,8 @@
 # Epic 03 — Digital File (Akte)
 
-Details zu FILE-001 … FILE-007 (vollständig).
+Details zu FILE-001 … FILE-009. FILE-001-007 vollständig, FILE-008 ergänzt am 2026-09-09
+aus Open-Source-Vergleich (KP Front/InvenTree), FILE-009 (Notizen) ergänzt am
+2026-09-10 — beide offen/ungeplant.
 
 ---
 
@@ -155,6 +157,72 @@ Details zu FILE-001 … FILE-007 (vollständig).
   Personal/Objekt-Änderungen ohne Audit-Eintrag) schon einmal real gefunden und gefixt
   wurde. Diese Kachel ist der methodische Nachfolgeschritt: systematisch statt punktuell.
 
+## FILE-008 — Manipulationssicheres Audit-Journal (Hash-Kette, P2, neu)
+
+- **Ziel:** Nachweisen können, dass ein Audit-Log-Eintrag nachträglich nicht verändert
+  wurde — über reines Vorhandensein (FILE-007) hinaus.
+- **Beschreibung:** Jeder Audit-Log-Eintrag bekommt zusätzlich einen Hash über
+  (Eintragsinhalt + Hash des Vorgängereintrags) — bricht die Kette erkennbar, sobald
+  irgendein historischer Eintrag verändert wird. Betrifft insbesondere Kontroll-
+  Ergebnisse, Wartungsprotokolle und Soll/Ist-Korrekturbuchungen (WH-006), wo
+  BOS-Dokumentationspflichten Nachweisbarkeit verlangen.
+- **Benutzerwert:** Rechtssicherer Nachweis bei Prüfungen/Vorfällen, dass Protokolle
+  echt und unverändert sind — nicht nur „es gibt einen Log-Eintrag", sondern „der
+  Log-Eintrag ist beweisbar unverändert".
+- **Abhängigkeiten:** FOUND-006 (Audit-Log), FILE-007
+- **Datenmodell:** `historie.hash` (SHA-256 über Inhalt+Vorgänger-Hash) — **nicht**
+  `audit_log`, MABEAs reale Tabelle heißt `historie` (`FOUND-006`). **Entschieden
+  (2026-09-09): Kette läuft pro Ressource (Objekt-ID)**, nicht global — jedes
+  Objekt hat seine eigene Kette, erster Eintrag je Objekt mit fixem
+  Genesis-Wert. Verifikations-Endpoint prüft/meldet damit je Objekt einzeln statt
+  eine einzige globale Bruchstelle für die ganze `historie`-Tabelle.
+- **Backend:** Hash-Berechnung beim Schreiben, Verifikations-Endpoint (Kette prüfen,
+  Bruchstelle melden falls vorhanden)
+- **Frontend:** „Integrität geprüft ✓"-Anzeige im Akte-Historienbereich (FILE-005),
+  Warnung bei Kettenbruch
+- **Mobile:** nein
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** Vertrauensanzeige im Historienbereich
+- **Rechte:** Verifikation: Administrator; Anzeige „geprüft"-Status: wie Lese-Recht
+- **Audit:** ist Gegenstand dieser Kachel selbst
+- **Akzeptanzkriterien:** nachträgliche Änderung eines historischen Eintrags (z.B. direkt
+  in der DB) wird vom Verifikations-Lauf erkannt und gemeldet.
+- **Tests:** Kettenbruch-Erkennungstest (Eintrag nachträglich manipuliert → Verifikation
+  schlägt fehl), Normalfall-Test (unveränderte Kette → Verifikation erfolgreich).
+- **DoD:** offen. **Referenz (Open-Source-Vergleich 2026-09-09):** KP Front
+  (`feuerwehr-oberwil/kp-front`, AGPL-3.0-or-later — nur Muster) nutzt genau dieses
+  Hash-Ketten-Prinzip für sein Einsatzjournal. Kombiniert mit InvenTree-Vorbild
+  (lückenloser Stock-History-Trail bei jeder Bestandsänderung) — WH-006-Korrekturbuchungen
+  sollten ebenfalls durch diese Kette laufen, sobald WH-006 umgesetzt wird.
+
+## FILE-009 — Freitext-Notizen in der Akte (P2, neu, 2026-09-10)
+
+- **Ziel:** Formlose, freie Notizen zu einer Ressource festhalten — Dinge, die in
+  keinen strukturierten Teilbereich (Prüfung/Mangel/Wartung) passen.
+- **Beschreibung:** Einfaches Freitextfeld je Ressource, mehrere Notizen möglich
+  (chronologische Liste, nicht nur ein einzelnes Textfeld), mit Autor+Zeitstempel.
+  Kein Rich-Text/Formatierung nötig, reiner Text reicht.
+- **Benutzerwert:** Raum für Kontext, der sonst mündlich verlorengeht (z.B.
+  „Funkgerät klemmt manchmal beim Einschalten, noch kein reproduzierbarer Fehler
+  für ein Mangel-Ticket" oder „Rücksprache mit Hersteller am 12.03. — Ersatzteil
+  in 2 Wochen").
+- **Abhängigkeiten:** FILE-001
+- **Datenmodell:** `akte_notiz` (id, entitaet_typ, entitaet_id, text, autor_id,
+  erstellt_am) — polymorph wie `dokument` (DOC-001), gleiches Kopplungsmuster
+- **Backend:** POST/GET/DELETE (Löschen nur eigene Notiz oder Administrator)
+- **Frontend:** Notiz-Panel in der Akte (FILE-006-Übersichtsseite), Eingabefeld +
+  chronologische Liste
+- **Mobile:** Anzeige + Erfassung (einfaches Textfeld, kein Zusatzaufwand)
+- **QR-Code/Seriennummer/Inventarnummer:** nein
+- **Akte:** ist dieser Bereich selbst
+- **Rechte:** Anlegen: Mitarbeiter+; Löschen: eigene Notiz oder Administrator
+- **Audit:** Anlegen/Löschen geloggt
+- **Akzeptanzkriterien:** mehrere Notizen chronologisch je Ressource sichtbar,
+  Löschen nur durch Autor oder Administrator möglich.
+- **Tests:** CRUD-Test, Berechtigungstest (fremde Notiz nicht löschbar außer als
+  Administrator).
+- **DoD:** offen.
+
 ---
 
 **MABEA-Ist-Stand-Abgleich (aktualisiert 2026-09-05):** FILE-001…006 sind umgesetzt und