Die Produktfrage.
Placement-Koordination umfasst Menschen, aufnehmende Organisationen, Betreuer, Meilensteine und Stunden. Ein nützliches Board muss einfache betriebliche Fragen schnell beantworten: Wer ist blockiert, was ist fällig und welcher Datensatz braucht Aufmerksamkeit?
Das ursprüngliche akademische Konzept wurde als bewusst begrenzte statische Anwendung neu gebaut. Öffentliche Daten sind fiktiv, Änderungen bleiben im Browser und jeder Demo-Zustand kann zurückgesetzt werden.
Was die öffentliche Ausgabe verspricht.
Die Rekonstruktion hält ihre Grenze klein und prüfbar:
- Jede Person und Organisation im ausgelieferten Datensatz ist fiktiv.
- Suche und Statusfilter arbeiten auf einem einzigen ausdrücklichen Placement-Modell.
- Meilensteinänderungen bleiben nur im lokalen Browser-Speicher und lassen sich zurücksetzen.
- Es gibt weder Konto, Datenbank, Analytics-Endpunkt noch entfernte Schreib-API.
Den Betrieb vor dem Dashboard modellieren.
Ein Dashboard wird brüchig, wenn Summen, Labels und Zeilenzustand den Status jeweils anders herleiten. Zuerst mussten Placement-Zustand und Stundenberechnung zu einem getesteten Modell werden.
Die Oberfläche wurde dann zur Projektion dieses Modells: Kohortenmetriken, Filter und individueller Fortschritt nutzen dieselben Funktionen; lokal gespeichert wird nur der fiktive Arbeitszustand.
Eine vollständige statische Produktgrenze.
Ein eingecheckter fiktiver Datensatz speist das Placement-Modell. Suche, Filter, Kohortenübersichten und Meilensteinübergänge lesen denselben abgeleiteten Zustand. Der Browser speichert Änderungen lokal; Reset stellt die ursprüngliche Fixture wieder her.
Entscheidungen für eine vertrauenswürdige Demo.
Die öffentliche App leistet weniger, aber jede sichtbare Interaktion ist echt.
Fiktive Datensätze ausliefern
Die gesamte Kohorte wurde für die Demonstration entworfen; die Anwendung benötigt keine redigierten Produktionsdaten.
Die Demo kann weder Prozess noch Datenvolumen einer realen Institution beanspruchen.
Metriken aus dem Modell ableiten
Status- und Stundenberechnungen werden von Karten, Filtern und Einzeldatensätzen gemeinsam genutzt und durch Node.js-Tests abgedeckt.
Neue Workflow-Zustände müssen zuerst den Modellvertrag erweitern, bevor sie in der Oberfläche erscheinen.
Persistenz lokal halten
Meilensteinänderungen überstehen einen Refresh im local storage; Reset stellt die ursprüngliche Fixture wieder her.
Diese Ausgabe bietet keine Zusammenarbeit, Authentifizierung oder geräteübergreifende Synchronisierung.
Verifikation der statischen Site.
Der lokale Server bildet den genauen GitHub-Pages-Basispfad ab, damit Fehler absoluter Links vor dem Deployment auffallen. Node.js-Tests prüfen das Datenmodell und Playwright die Browser-Erfahrung.
Stabile Releases paketieren deterministische ZIP- und TAR-Archive mit Inventar, CycloneDX SBOM, Quell-Commit-Evidenz und SHA-256-Prüfsummen.
Was das Board unterstützt.
Ein Operator kann nach Student, Host oder Betreuer suchen, die Kohorte nach Status filtern, Fortschritt prüfen, einen Meilenstein weiterschalten und nach einem Refresh denselben lokalen Zustand vorfinden.
VECTOR ist ein fokussierter Demonstrator, kein gehosteter Placement-Dienst. Sein Wert liegt in einem kohärenten, funktionierenden Interaktionsmodell mit ungewöhnlich klarer Datengrenze.
Evidenzprotokoll.
Die öffentliche Ausgabe liefert eine bewusst kleine, testbare Fixture:
- Fixture
- Sechs fiktive Placements in vier Statuszuständen; zwei aktiv und zwei in Prüfung.
- Abgeleitete Ansicht
- Die geprüfte Fixture weist 67% Gesamtfortschritt aus 160/180-Stunden-Zielen aus.
- Verifikation
- 30 Node.js- und fünf Browser-E2E-Deklarationen, darunter 390 px Mobile und exakte Overflow-Prüfung bei 320 px.
- Grenze
- Die gesamte Persistenz gehört zu einem Browser. Das Projekt ist kein produktives Placement-System für mehrere Benutzer.