Eine lokale Browser-App für den WK: Dienstleistung vorbereiten → mit PISA abgleichen → als Personenarchiv nachschlagen, dazu Tagesbefehle aus dem Kp-WAP (Druck, .xlsx aus der offiziellen Vorlage, PDF je Tag als 01_Mo.pdf … 07_So.pdf). Die App arbeitet offline, ohne Server und ohne Datenbank.
Importierte Dateien, Personendaten, Projektstände, Archive und sämtliche erzeugten Ausgaben dürfen das Gerät nicht durch Uploads, Hosting, Synchronisation, Telemetrie oder Weitergabe an Dritte verlassen. Diese Grenze ist nicht verhandelbar. «Datei hochladen/importieren» bedeutet hier ausschliesslich, eine lokale Datei im Browser einzulesen.
- Verarbeitung, Suche, Planung, Validierung und Exporte erfolgen lokal. Es gibt keinen Datenserver und keine geteilten Online-Projekte. Die App übermittelt nichts an PISA, Google oder andere Dienste.
- Keine Analyse-, Tracking-, Sitzungsaufzeichnungs-, Fehlerberichts- oder externen Logging-Dienste. Datei- und Projektinhalte sowie daraus abgeleitete Angaben gehören auch nicht in Konsolenlogs, URLs, Netzwerkaufrufe, Tool-Ausgaben, KI-Anfragen, Screenshots mit Echtdaten, Support-Tickets oder CI-Artefakte.
- Reale Eingaben und Ausgaben gehören nicht in Git, Pull Requests, Test-Fixtures oder Deployments. Für Entwicklung, Demonstrationen und Tests werden ausschliesslich erfundene Daten verwendet.
- Öffentlich verteilt werden darf nur die Anwendung mit datenfreien Assets. Eine HTML-Datei mit eingebettetem Projekt ist ein privater lokaler Export und darf niemals als Website veröffentlicht werden. Laufzeitbibliotheken und Assets werden lokal gebündelt; die Anwendung muss ohne externe Dienste und ohne Internetverbindung funktionieren.
- Kontakt-CSV, JSON, Excel und HTML werden ausschliesslich lokal erzeugt und gespeichert. Ein kompatibles Exportformat ist keine Erlaubnis, die enthaltenen Daten zu einem externen Dienst hochzuladen.
Diese Vorgabe gilt ebenso für Wartung, Coding-Agenten, Debugging, Tests, CI und Support. Sie ist in AGENTS.md verbindlich festgehalten. Bei Implementierungsänderungen sind Offline-Betrieb, ausbleibende Datenübertragung und datenfreie Veröffentlichungen mit fiktiven Daten zu prüfen; die Dokumentation allein ist kein technischer Nachweis.
Die fertige Anwendung liegt nach dem Build in dist/index.html (identisch: dist/offline.html). Diese Datei lässt sich lokal öffnen; alle Bibliotheken, Styles und Lizenztexte sind enthalten. Der Quelltext-index.html ist nur der Einstieg für Vite, kein fertiger Download.
Die Seitenleiste führt durch vier Schritte und zeigt bei jedem den aktuellen Stand; der Knopf «Weiter» oben rechts öffnet den nächsten Schritt. Alte v2/v3/v4-Projekte bleiben ladbar; neue Projekte verwenden v5. Personen, Rohdaten, unbekannte Felder und bisherige Zuteilungen bleiben erhalten. Unklare alte Zuordnungen werden angezeigt und nicht stillschweigend umgedeutet.
- Personen laden: PISA- und/oder MILOFFICE-Liste auswählen oder auf die Karte ziehen; die Datei wird nur im Browser gelesen. Eine gesicherte JSON-Projektdatei lässt sich hier ebenfalls öffnen. Die Übersicht zeigt, wer eingeplant ist, wessen Teilnahme noch zu klären ist und wo eine Identität geprüft werden muss.
- Planen: «Neues Detachement» (oder Taste N, oder Doppelklick auf die Fläche) erzeugt sofort eine Karte; Name und EC lassen sich direkt bearbeiten. Die Liste «Noch frei» zeigt alle Personen ohne direktes Detachement: auf eine Karte ziehen oder markieren und «Zuteilen». «Personen auswählen» öffnet die Auswahl mit kombinierbaren Filtern (Shift+Klick wählt einen Bereich); Ausschnitt und Zoom bleiben dabei unverändert. Karten am Kopf verschieben, über «Verbinden» oder den Punkt rechts den anschliessenden Dienst festlegen. Das Menü ⋯ einer Karte bietet Angaben, Duplizieren, Verbindung lösen, Position ändern und Entfernen (mit Bestätigung; die Personen bleiben erhalten). Konflikte und fehlende Angaben erscheinen direkt auf den Karten. Rückgängig/Wiederholen umfasst die letzten 30 Änderungen der laufenden Sitzung; viele Meldungen bieten «Rückgängig» direkt an.
- In PISA übertragen: Links die Checkliste der erforderlichen Haupt-/Zusatz-Einträge mit Fortschritt, rechts jedes Feld in PAT-Reihenfolge mit Kopierknopf (Datumsangaben im Format TT.MM.JJJJ). Ein reiner Zusatz erhält keine direkte Personenzuteilung; die Personen erscheinen bei ihrem zugehörigen Haupt-MB. Zusätzlich benötigte EC werden einmal vergeben und bleiben stabil. Nach «als abgeglichen markieren» springt die Ansicht zum nächsten offenen Eintrag. Änderungen machen frühere Abgleichsmarker ungültig. «Übersicht» zeigt alle Einträge als Tabelle.
- Sichern & archivieren: JSON, Excel-Arbeitsliste, Offline-HTML und Kontakt-CSV lokal erzeugen. Ein unveränderlicher lokaler Snapshot öffnet danach die Personensuche. Eine spätere Bearbeitung erstellt eine eigene Arbeitskopie. Unvollständig abgeglichene Stände bleiben als solche erkennbar.
Bedienhilfen: Ctrl/⌘+K sucht Personen, Detachemente und Befehle; Ctrl/⌘+Z bzw. Shift+Ctrl/⌘+Z für Rückgängig/Wiederholen; Ctrl/⌘+S lädt eine JSON-Sicherung herunter; Alt+1…8 wechselt die Ansicht; ? zeigt alle Tastenkürzel. Hell/Dunkel und die eingeklappte Seitenleiste werden als reine Oberflächeneinstellung im Browser gemerkt.
KVK/WK: Die PAT widerspricht sich auf S. 85 und S. 93–94. Verbundene Aufgebote benötigen deshalb eine pro Dienstleistung dokumentierte KF-Auskunft: separate MB oder ein durchgehender MB. Bis dahin bleibt die Vorschau mit Aufgebotsart noch bestätigen gekennzeichnet und enthält keine verbindlichen Übertragungsanweisungen. Ein gewöhnliches Einzelaufgebot benötigt diese Auswahl nicht. Die App sendet nichts an PISA und erstellt keine amtlichen Marschbefehle.
Eine Verbindung hat aktuell ein Folgedetachement; mehrere Spezialdetachemente können dasselbe Ziel haben. Verbindungsketten werden mit einer verständlichen Meldung abgelehnt. Bereits explizit gespeicherte Haupt-/Zusatz-Gruppen aus alten Projekten bleiben erhalten, wenn eine Zusammenlegung ihre Bedeutung verändern könnte. Hinweise zeigen den Klärungsbedarf.
Im Dienst wird vor Ort in Events gearbeitet, z. B. «KVK» vom … bis …. Ein Event enthält eigene Detachemente wie «Det Mat», «Det VT» und «Det Kp» mit Chef sowie Auftrag/Ort. Die PISA-Detachemente (Planungskarten) dienen nur als Filter: Sie legen fest, wer zur Auswahl steht, und lassen sich jederzeit umstellen, z. B. «KVK DET» und ein zweites KVK-Detachement zusammen; ohne Filter stehen alle nicht ausgeschlossenen Personen zur Auswahl. Die Seite Vor Ort (Seitenleiste, Alt+8 oder ⋯ auf der Karte → «Vor Ort aufteilen», das ein Event mit dieser Karte als Filter und ihren Daten vorbereitet) legt die üblichen Detachemente mit einem Klick an; weitere Namen lassen sich mit Komma getrennt ergänzen. Personen werden pro Zeile mit einem Klick eingeteilt, per Mehrfachauswahl («Alle Treffer auswählen») oder mit der Tastatur: Zeile fokussieren, 1–9 für das Detachement bzw. 0 für «nicht eingeteilt» drücken; der Fokus springt zur nächsten Person. Stammen die Personen aus mehreren PISA-Detachementen, steht die Herkunft bei jeder Person. Eine Person gehört pro Event zu höchstens einem Detachement; verschiedene Events sind unabhängig. Kopieren übernimmt ein Event samt Detachementen, Chefs, Aufträgen und Einteilung, z. B. für die nächste Woche. Events verändern weder EC, Zuteilungen, Prüfungen noch PISA-Abgleiche; wird eine Planungskarte entfernt, verschwindet sie nur aus den Filtern.
Liste ausgeben erstellt pro Event oder pro Detachement eine A4-Liste mit Zeitraum, Einrückungsangaben der gefilterten PISA-Detachemente, Bestand (Of / Höh Uof / Uof / Mannschaft), Fahrausweisen, Chef, Auftrag und wählbaren Spalten (bei mehreren PISA-Detachementen deren Name, dazu Funktion, Fahrausweise, Zug, Telefon, E-Mail, Versicherten-Nr., Spalte zum Abhaken; Zug ist standardmässig dabei), sortiert nach Grad. Optional kommt eine breite Visum-Spalte mit eigener Überschrift dazu, z. B. für den Materialempfang, sowie ein Zusatztext, der im Event gespeichert und auf die Liste gedruckt wird (z. B. «Der AdA bestätigt den Erhalt von:» mit Zeilen «- Schutzmaske»; solche Zeilen erscheinen als Aufzählung). Optional beginnt jedes Detachement auf einer neuen Seite. Ausgabe als Druck/PDF über den Druckdialog, als Excel-Datei (Gesamtliste, ein Blatt pro Detachement, Angaben) oder als Text in die lokale Zwischenablage. Alles entsteht auf dem Gerät; Ausdrucke und Dateien enthalten Personendaten.
Personen durchsucht Namen, Versicherten-Nummern, Funktionen, Gruppen und Orte. Das Dossier zeigt Aufgebote, Teilnahme, Kontaktangaben und Originaldaten. Eine eindeutige Nummer führt importierte Quellen zusammen; optionaler Namensabgleich markiert die Identität zur Nachkontrolle. Verschiedene Nummern werden nie aufgrund gleicher Namen zusammengeführt.
Kontakt-CSV zeigt eine lokale Vorschau im Google-Kontakte-Format. Geplante, erreichbare Personen sind vorausgewählt; Filter verändern die Anzeige, nicht die Auswahl. Grad und Detachements-Labels sind optional. CSV und alle anderen Exporte bleiben lokal. Formatkompatibilität ist keine Erlaubnis zur Weitergabe an einen externen Dienst.
JSON, Excel-Arbeitsliste, Kontakt-CSV und HTML mit eingebetteten Daten werden auf dem Gerät erzeugt. Das HTML kann erneut geöffnet und exportiert werden. Browserablage ist geräte- und browsergebunden; für unabhängige Sicherungen lokale Projektdateien herunterladen. Bei Speicherfehlern bleibt die Arbeitskopie im Speicher, und eine dauerhafte Warnung fordert zum Sichern auf. Beschädigte Ablagen werden nicht automatisch überschrieben.
Die Produktionsdatei setzt eine Content Security Policy mit connect-src 'none', enthält keine externen Laufzeitressourcen und entfernt Konsolenausgaben auch aus Abhängigkeiten. Release-Prüfungen verlangen einen leeren Anwendungscontainer ohne eingebettete Projektdaten, ein festes Dateiset und einen erfolgreichen Start mit gesperrten Netzwerk-APIs. Reale Daten dürfen auch während Entwicklung und Support niemals in Logs oder Artefakte gelangen.
Voraussetzung: Node.js 24.15 oder neuer innerhalb Version 24 sowie Python 3 für die Oracle-Tests. Abhängigkeiten sind exakt versioniert und durch package-lock.json gesichert.
npm ci
npm run dev
npm run check
npm run test:oracle
npm run build
npm run previewnpm run check führt strikte TypeScript-Prüfung, Biome und Vitest aus. npm run build erzeugt den eigenständigen Offline-Build und prüft dessen Release-Inhalt und Startverhalten. npm run dev ist ausschliesslich für Entwicklung mit fiktiven Daten vorgesehen. HTML-Export mit Daten ist im Produktionsbuild verfügbar; im Entwicklungsmodus steht JSON bereit.
Die Anwendung verwendet React 19, TypeScript 7, Vite 8, TanStack Router, Table 9, Form und Store. TanStack übernimmt Navigation, Tabellen, Formulare und lokalen Zustand. React Flow zeichnet die verschiebbaren Detachement-Karten und Verbindungen; Motion animiert Karten, CSS die Seitenbereiche. Reduzierte Bewegung wird berücksichtigt. Es gibt keine Server-Komponente.
src/model/ Reine Planungsregeln, Migration, PISA-Ableitung und Prüfung
src/io/ Lokale Dateien, Quellenimport, Browserablage und Exporte
src/components/ Wiederverwendbare Dialoge, Tabellen und Personenauswahl
src/pages/ Planung, PISA, Vor Ort, Personen, Kontakte und Dateien/Archiv
src/store.ts Lokaler Zustand und atomare Änderungen
src/App.tsx Navigation und Anwendungshülle
src/theme.css Responsive Oberfläche
tests/ Fiktive Domain-, Import-, Speicher-, UI- und Privacy-Regressionen
tools/ Offline-Build, Release-Prüfung und PISA-Oracle
Beitragshinweise stehen in CONTRIBUTING.md, die verbindliche Agenten-Anleitung in AGENTS.md. Implementierungsplan und Entwurfsnotizen dokumentieren Entscheidungen. Änderungen werden in Pull Requests geprüft; GitHub Pages veröffentlicht ausschliesslich den geprüften, datenfreien dist-Inhalt von main.
Das PISA-Oracle hält Regeln, Belegstellen und offene Quellenkonflikte zur PAT vom 12.02.2026 fest. Das Original-PDF und personenbezogene Dateien gehören nicht ins Repository. Das Oracle ist eine quellengebundene Erfassungshilfe, kein Nachweis aktueller PISA-Genehmigung oder Zustellung.
Die Anwendung steht unter der MIT-Lizenz. Der Offline-Build enthält zusätzlich die Lizenzhinweise der gebündelten Abhängigkeiten.