Das operative Problem.
Praktikumsverwaltung ist mehr als ein Dashboard. Eine Schule koordiniert Kohorten, Schüler, Betriebe, Tutoren, Termine, Stunden, Check-ins und unterschriebene Nachweise. Unterschiedliche Rollen benötigen unterschiedliche Ausschnitte desselben Datensatzes, und eine Korrektur darf den früheren Stand nicht auslöschen.
Die frühere akademische Implementierung eignete sich nicht als Produktbasis. Ich habe VECTOR von Grund auf neu gebaut und nur den Praktikumsbereich als fachliche Referenz verwendet. Weder Legacy-Code noch personenbezogene Datensätze, Namen oder Assets gelangten in das neue Repository.
Was ein schuleigenes System gewährleisten muss.
Die Architektur beginnt mit vier praktischen Vorgaben:
- Jede Installation gehört zu genau einer Schule, die Datenbank, Erscheinungsbild, Sicherungen und Betrieb kontrolliert.
- Berechtigungen und Tutorenzuständigkeit müssen auf dem Server greifen, bevor Datensätze ausgewählt, gezählt oder exportiert werden.
- Jeder Einsatz behält die Programmversion, die Stunden, Check-ins und Nachweise festlegte; Korrekturen erhalten den ursprünglichen operativen Datensatz.
- Import, Export, Aufbewahrung und Wiederherstellung müssen begrenzt, prüfbar und nach einem Fehler sicher wiederholbar sein.
Zuerst die Eigentumsgrenze festlegen.
Mehr Zustand im Browser hätte die schwierigen Fragen offengelassen. Rollenprüfungen könnten in der Oberfläche verborgen bleiben, die gesamte Schule könnte in den Speicher geladen und ein geändertes Feld so behandelt werden, als hätte der frühere Wert nie existiert.
VECTOR verwendet eine Schule pro Installation, statt einen gemeinsamen mandantenfähigen Dienst aufzubauen. Die operative Verantwortung bleibt eindeutig; Sicherung, Aufbewahrung und White-Label-Konfiguration lassen sich leichter nachvollziehen. Das Projekt liefert Software aus, keine verwaltete Cloud-Plattform.
Ein kompakter Server mit klaren Grenzen.
Der Browser spricht mit einer Express-API, die Anmeldung, Rollen, Programmversionen und Zustandswechsel verwaltet. SQLite speichert die Schuldaten im WAL-Modus. AES-GCM-Cursor binden Abdeckung und Aufgabenliste an Schule, Rolle, Filter und stabile Positionen, ohne ihren Inhalt offenzulegen.
Warum diese Technologien.
Der Stack ist für eine Schule dimensioniert, die ihre eigene Installation besitzt und betreibt.
Eine Schule pro Installation.
- Warum
- Datenhoheit, Rollen, White Label, Sicherung und Wiederherstellung bleiben innerhalb einer klaren institutionellen Grenze.
- Was ich ausgeschlossen habe
- Ein mandantenfähiges SaaS bräuchte Kundentrennung, Abrechnung, zentralen Betrieb und Compliance-Zusagen, die nicht zum Produkt gehören.
- Der Preis dafür
- Wir nehmen in Kauf, dass jede Schule Updates, Kapazität und Sicherungen ihrer Instanz selbst verwaltet.
Express als Serverschicht.
- Warum
- Authentifizierung, Rollen, Zuständigkeit und Zustandswechsel greifen, bevor Daten den Browser erreichen.
- Was ich ausgeschlossen habe
- Eine reine Browser-Anwendung ließe Regeln und Daten beim Client, der Berechtigungen nicht verlässlich durchsetzen kann.
- Der Preis dafür
- Wir nehmen Betrieb und Wartung eines Serverdienstes im Netz der Institution in Kauf.
SQLite im WAL-Modus mit Migrationen.
- Warum
- Transaktionen, Portabilität und Snapshots einer einzelnen Datei passen zur Last einer einzelnen Schule.
- Was ich ausgeschlossen habe
- PostgreSQL oder eine Cloud-Datenbank würden Dienst, Zugangsdaten und Administration ohne belegte Multi-Tenant-Skalierung hinzufügen.
- Der Preis dafür
- Wir nehmen Grenzen bei parallelen Schreibvorgängen und fehlende automatische Hochverfügbarkeit in Kauf.
Docker mit ausdrücklichen Werkzeugen für Sicherung und Wiederherstellung.
- Warum
- Die Institution erhält eine reproduzierbare Installation und einen prüfbaren Wiederherstellungsweg auf eigener Infrastruktur.
- Was ich ausgeschlossen habe
- Eine verwaltete Plattform vereinfachte den Betrieb, verlagerte Kontrolle und Abhängigkeit aber zu einem Anbieter.
- Der Preis dafür
- Wir nehmen in Kauf, dass der Operator Speicher überwacht, Wiederherstellungen testet und Updates plant.
Entscheidungen für einen sichereren Arbeitsalltag.
Das Produkt bevorzugt sichtbare Regeln gegenüber bequemem, verborgenem Zustand.
Regeln versionieren, nicht nur den Einsatz
Eine veröffentlichte Programmversion ist unveränderlich. Neue Regeln gelten für neue Zuweisungen; ein bestehender Einsatz behält Zielstunden, Check-in-Minimum und Nachweise seines Starts.
Der ZielkonfliktEine Korrektur braucht eine neue Version, und unberührte Einsätze werden nur ausdrücklich neu zugewiesen. Der Abschluss ändert sich nicht rückwirkend.
Planungslücken vor Ausnahmen zeigen
Die Abdeckung wird je Kohorte und Zeitraum berechnet und unterscheidet gültige Zuweisung, fehlende Zuweisung und Überschneidung. Eine Lücke startet einen vorausgefüllten Einsatz im gleichen Kontext.
Der ZielkonfliktDie Ansicht ist bewusst operativ begrenzt und kein allgemeines Berichtssystem. Dadurch bleibt das Ergebnis handlungsnah und rollenkorrekt.
Aufmerksamkeit aus vorhandenen Datensätzen ableiten
Die Queue leitet fällige Arbeit aus Nachweisen, Stunden, Terminen und Tutorzuweisungen ab, statt eine zweite Aufgabenliste zu pflegen. Der Server wendet die Rolle vor Zählung und Paging an.
Der ZielkonfliktBeliebige Erinnerungen gehören nicht in die Queue. Sie bleibt mit dem Einsatzdatensatz konsistent und vermeidet eine zweite Wahrheitsquelle.
Self-Hosting und Wiederherstellung.
Schulen können Name, Farben, Logo und Supportdaten mit Revisionsschutz für gleichzeitige Änderungen festlegen. Das gepinnte Node-24-Alpine-Image läuft als unprivilegierter Benutzer, enthält root-eigenen Anwendungscode und keinen Paketmanager und unterstützt ein schreibgeschütztes Root-Dateisystem. Health und Doctor stoppen den Start bei unsicherer Konfiguration, Schema- oder Speicherzuordnung.
Die Werkzeuge erstellen einen größenbegrenzten privaten SQLite-Snapshot, prüfen ihn ohne Anwendungsstart und stellen ihn über einen geschützten Pfad wieder her, der Pfadersetzung und Quelländerungen erkennt. Die Automatisierung scannt Container und Quellen auf Schwachstellen und Geheimnisse, veröffentlicht ein SBOM, baut das Archiv zweimal und prüft vor Veröffentlichung den entpackten Abnahmepfad.
Was VECTOR heute unterstützt.
Eine Schule kann Programmregeln veröffentlichen, Kohortenabdeckung prüfen, Einsätze aus Planungslücken erstellen und eine rollenbezogene Aufgabenliste abarbeiten. Derselbe Datensatz trägt Stunden, Check-ins, Nachweishistorie, Audit, atomaren Import, gefilterten Export und geregelte Aufbewahrung.
VECTOR ist selbst betriebene Open-Source-Software. Es ist kein verwaltetes SaaS und beansprucht weder Compliance-Zertifizierung noch Hochverfügbarkeit oder SSO. Für Institutionen mit solchen Anforderungen bleiben diese Punkte Produkt- und Betriebsarbeit.
Evidenzprotokoll.
Das signierte Release 3.4.0 verknüpft seine Produktversprechen mit konkreten Kontrollen:
- Programmrichtlinie
- Koordinatoren veröffentlichen unveränderliche Versionen mit Zielstunden, Mindestzahl an Check-ins und Nachweispflichten. Bestehende Einsätze behalten ihre zugewiesene Version.
- Begrenzter Betrieb
- Indizierte stabile Seitennavigation für Schüler und Betriebe, gebündelte Importvalidierung und datenbankgestützte Kapazitätsgrenzen halten Listen, Einsatzhistorie, Sitzungen und Benutzerverwaltung in ausdrücklich festgelegten Betriebsgrenzen.
- Speicherung und Wiederherstellung
- Start, Doctor, Sicherung, Prüfung, Verdichtung und Wiederherstellung weisen unsichere SQLite-Aliase und Schemaabweichungen zurück, prüfen WAL-Begleitdateien und halten Integritätsprüfung und Snapshot auf derselben abgesicherten Verbindung.
- Anfrage- und Sitzungsgrenze
- Exakte Produktionsursprünge, identitätsneutrale Anmeldefehler, Ablehnung doppelter Cookies, Timing-sichere CSRF-Prüfungen und höchstens zehn Sitzungen greifen, bevor der rollenbezogene Arbeitsbereich Schuldaten offenlegt.
- Verifikation und Release
- Gates für Node 22 und 24, Chromium- und WebKit-Abnahme, native Abdeckungsschwellen, Skalierungs- und CRUD-Proben, Trivy-Scans und zwei bytegleiche Builds schützen das Release. Das verifizierte signierte Tag löst auf Commit fb802e5 auf; das unveränderliche GitHub-Release veröffentlicht acht digestgebundene Artefakte einschließlich CycloneDX-SBOM.
Geprüftes Release v3.4.0 Geprüft am
Diese Fallstudie beschreibt das unveränderliche Release 3.4.0 und seine Self-Hosting-Kontrollen am Commit fb802e5. GitHub Pages ist eine Produkttour; die operative Anwendung läuft aus dem Serverpaket. Reale Schuldaten, institutionelle Integrationen und Ergebnisse werden nicht dargestellt; das Release beansprucht weder verwaltete Verfügbarkeit noch Compliance-Zertifizierung.