feat(dekon): der Dekon-Platz ist nicht dokumentierbar — Dekon-P und Platzführung fehlen

This is a cross-cutting module spanning the listed Domain, persistence, sync, UI, master-data, PDF, and test files; first read the CO measurement module and the referenced related issues, especially #381, before proposing work. The issue identifies migration V21→V22, sync round-trip, ViewModel, acceptance render tests, and the screenshot requirement in AGENTS.md. Done requires resolving the scope and sequencing questions, then implementing and testing the agreed Dekon-P and site-management work; this is explicitly beyond a first-timer-sized contribution.

Rückmeldung aus der Praxis

Apropos... Doku für den Dekon Platz wäre auch noch etwas was wir integrieren
könnten. Aber dann wieder als extra Android App mit Datentransfer

Heute

Vom ABC-Einsatz kennt Lagebuch nichts.

grep -riE "dekon|kontamin|gefahrgut|gsg|strahlenschutz|messtrupp" \
  src/ docs/*.md README.md ROADMAP.md CHANGELOG.md

→ kein Treffer. Der einzige Treffer im ganzen Repo ist ein Link-Name
„Gefahrgut" in einer Testfixture
(tests/LageBuch.AppLogic.Tests/LinksViewModelTests.cs:108).

Vier Dinge kommen nahe und reichen jeweils nicht:

• Atemschutz kennt den CSA-Trupp längst als eigenen Typ — 3 Personen,
  kürzere Einsatzzeit:

  // src/LageBuch.Domain/Atemschutz/AtemschutzTrupp.cs
  public const string ChemicalTruppDesignation = "CSA-Trupp";
  public const int DefaultChemicalMaxDurationMinutes = 20;
  

  Wer zu dekontaminieren ist, steht also schon namentlich in der Einsatzdatei:
  TruppMember (src/LageBuch.Domain/Atemschutz/TruppMember.cs) ist der
  einzige Ort, an dem einzelne Personen modelliert sind. Was nach dem
  Rückzug mit dem Trupp passiert, endet dort.
• Kräfte sind Zahlen, keine Personen — ForceUnit trägt
  PersonnelCount, ScbaCount, OfficerCount. Ein Dekon-Platz schleust aber
  Personen durch, keine Stärken.
• Checklisten gibt es, aber genau eine je Richtung (Aufbau/Abbau) aus den
  Stammdaten. Der Aufbau eines Dekon-Platzes ist eine eigene Liste, die nur in
  der ABC-Lage gebraucht wird.
• CO-Messung (src/LageBuch.Domain/CoMeasurement/,
  CoMessprotokollViewModel, CoMessprotokollSection) ist das einzige
  vergleichbare Protokollmodul — und damit die Bauvorlage.

Die „extra Android App" gibt es schon — den Datentransfer auch

Die Android-App ist kein zweites Programm, sondern der Android-Head desselben
Codes (src/LageBuch.App.Android/, net10.0-android), und sie ist
ausdrücklich ein Begleitgerät:

Android kann beitreten, aber selbst keinen Einsatz freigeben. Die App ist
ein Begleitgerät.
— docs/datenschutz-und-sicherheit.md:211

Der „Datentransfer" ist die vorhandene Synchronisation: TLS mit
Trust-on-First-Use, vierstellige PIN, SignalR über Port 5859
(src/LageBuch.Sync/SyncProtocol.cs, src/LageBuch.Sync.Hosting/IncidentHost.cs).
Die Ansichten liegen ohnehin gemeinsam in LageBuch.App.Shared und laufen auf
beiden Köpfen.

Ein Tablet am Dekon-Platz braucht also kein neues Repo und keine zweite
App — es braucht einen Reiter DEKON in der vorhandenen, und der Weg der Daten
in den ELW ist bereits gebaut. Ein separates Programm hätte dagegen kein
Übergabeformat: .fwincident ist eine nackte SQLite-Datei mit einem
*.files/-Verzeichnis daneben, es gibt weder Einsatz-Import/-Export noch QR,
Bluetooth oder NFC.

Ein Haken bleibt: #381 — die veröffentlichte APK deklariert keine
INTERNET-Berechtigung, Beitreten kann damit gar nicht funktionieren. Solange
das offen ist, ist jedes Begleitgerät-Feature Theorie.

Vorschlag

Fachlich zwei Hälften: Dekon-P (Einsatzkräfte nach FwDV 500) und
Platzführung/Ressourcen. Dekon-V und Geräte-/Fahrzeugdekon bleiben
ausdrücklich draußen, siehe „Zu klären".

1. Domain — src/LageBuch.Domain/Dekon/ nach dem Muster von
   CoMeasurement/: eine Personenzeile (Name, Herkunft/Trupp, Dekon-Stufe,
   angemeldet um, fertig um, Status, Bemerkung) und ein Platz-Kopf (Standort,
   betriebsbereit ab, Stufe, verantwortliche Funktion, Personal am Platz).
   Status als Enum, dessen Werte nur angehängt werden dürfen — Enums werden
   ordinal persistiert (EtbDirection).
2. Incident — neue Sammlung plus Mutationsmethoden mit EnsureOpen() und
   automatischem ETB-Systemeintrag („Dekon-Platz betriebsbereit", „Trupp 2
   dekontaminiert"). Achtung: Incident.Rehydrate ist positional, die Signatur
   und alle drei Aufrufer müssen mit.
3. Persistenz — ApplyV22 in src/LageBuch.Persistence/Sqlite/Migrations.cs
   (CurrentVersion 21 → 22), Tabellen dekon_platz / dekon_persons, in
   IncidentRepository.Save löschen-und-neuschreiben wie jede andere.
4. Sync — neue [JsonDerivedType]-Kommandos in SyncCommand.cs, dazu
   IIncidentSession, CommandApplier, LocalIncidentSession,
   RemoteIncidentSession, IncidentSnapshot und SnapshotMapper. Das ist der
   „Datentransfer" aus der Rückmeldung — er entsteht hier, nicht in einer
   zweiten App.
5. UI — DekonViewModel + DekonView.axaml, ein
   <TabItem Header="DEKON"> in IncidentWorkspaceView.axaml. Die Anmeldung
   einer Person sollte die Atemschutztrupps als Quelle anbieten: die Namen
   stehen dort bereits, abtippen am Dekon-Platz ist der falsche Ort.
6. Stammdaten — Dekon-Stufen und Vorgabezeiten als Felder in
   IncidentSettings (src/LageBuch.Persistence/MasterData/MasterDataSet.cs),
   mitsamt docs/master-data.example.json und
   docs/samples/demo-stammdaten.json. Eine eigene Dekon-Aufbau-Checkliste
   wäre die zweite Stammdaten-Erweiterung.
7. Bericht — Flag in IncidentPdfSections, Abschnitt unter
   src/LageBuch.Documents/Sections/, Haken in PdfExportOptionsViewModel.
8. Tests — Domain, Migration V21→V22, Sync-Roundtrip, ViewModel und ein
   Render-Test in tests/LageBuch.Acceptance.Tests; für den PR gilt die
   Screenshot-Pflicht aus AGENTS.md.

Größenordnung, ehrlich: das CO-Messprotokoll (955862d) waren rund 2000 Zeilen
über 38 Dateien. Das hier ist kein Feierabend-Issue.

Zu klären

• Reihenfolge. #381 muss vorher zu, sonst kann das Begleitgerät gar nicht
  beitreten. Und die Roadmap sagt für v0.6 ausdrücklich „nichts Neues" und für
  v0.7 Sicherheit — ein neues Modul kollidiert damit. Der ehrliche Platz ist
  „Beyond 1.0" neben der Wasserförderung, oder direkt nach #351: vor dem
  Formatfreeze darf eine neue Tabelle noch wandern, danach nicht mehr.
• Reicht das Netz bis zum Dekon-Platz? Der Dekon-Platz liegt an der Grenze
  des Absperrbereichs, der ELW steht woanders. Die Synchronisation braucht
  LAN oder Tailscale, und ein beigetretener Client hält keine eigene Autorität
  (RemoteIncidentSession) — reißt die Verbindung ab, kann am Dekon-Platz
  nichts mehr geschrieben werden. Entweder man nimmt das in Kauf, oder das
  Modul braucht Offline-Pufferung. Letzteres wäre ein eigenes, größeres Thema
  und nicht Teil dieses Issues.
• Dekon-V ist bewusst draußen. Die Dekon von Verletzten und Betroffenen
  brächte Gesundheitsdaten (Art. 9 DSGVO) in eine Einsatzdatei, die heute
  Einsatzkräfte und Bewohnernamen kennt. Das ist eine eigene Entscheidung mit
  eigenem Datenschutzkapitel, kein Nachziehen.
• Datenschutz auch bei Dekon-P. „Diese Person wurde dekontaminiert" ist
  eine neue Kategorie personenbezogener Daten und muss in
  docs/datenschutz-und-sicherheit.md nachgetragen werden, samt Löschkonzept —
  dieselbe Auflage wie bei #427.
• Elf Reiter. IncidentWorkspaceView.axaml hat heute zehn; auf einem
  Android-Tablet ist das bereits eng. Ein Reiter, der nur in der ABC-Lage
  gebraucht wird, sollte vielleicht nicht immer sichtbar sein — dieselbe Frage
  stellt #405.
• Welche Norm, und wo stehen die Zahlen? Dekon-Stufen und der Begriff
  Dekon-P kommen aus der FwDV 500. Die Werte gehören in die Stammdaten, nicht
  als Regel in den Code — genau die Lehre aus #398 und #418.

Verwandt: #381, #351, #399, #405, #418, #427.