Florian WildeandClaude Opus 5
49ce06f206
Legt die Grundlage, auf der alle weiteren Meilensteine nur noch Fachlichkeit ergänzen: Next 16 mit App Router und TypeScript strict, Tailwind 4, Prisma 7, Vitest 5, Playwright, ESLint, Prettier und die Hooks für Lint und Commits. Zwei Dinge sind bewusst so gebaut und durch Tests festgehalten: Die Datenbank ist im Betriebsstand von außen nicht erreichbar. Sie hat kein ports:-Mapping und hängt allein im Netz "intern", das ohne Gateway läuft; nur "web" kommt zusätzlich nach draußen. tests/betriebsstand.test.ts schlägt an, falls ein Port-Mapping zurückkehrt. Geprüft, nicht behauptet: docker compose up startet den Stack, 5432 ist vom Host aus zu, aus "web" offen. pnpm pruefe:doku hält Dokumentation und Code zusammen — Version im Changelog, Issue-Dateien gegen ihre Übersicht, keine Verweise auf fehlende Dateien, keine fehlenden Bilder. Das Skript wurde gegen vier eingebaute Fehler gegengeprüft. Drei Versions-Obergrenzen sind nötig und in CLAUDE.md begründet: eslint bleibt auf 9.x, weil eslint-plugin-react keinen Nachfolger für eslint 10 hat und das Regelwerk sonst beim Laden abbricht; typescript bleibt auf 6.0.x, weil typescript-eslint TypeScript 7 noch nicht unterstützt; prisma ist exakt auf 7.10.0 gepinnt, weil sein latest-Tag auf einen 8.0-RC zeigt, der von @prisma/client aber nicht. Auth.js entfällt entgegen der ursprünglichen Vorgabe: v5 steht dauerhaft auf Beta, das Projekt ist im Wartungsmodus und sein Prisma-Adapter deckt Prisma 7 nicht ab. Stattdessen openid-client und jose, wie in ProxLedger. Dieser erste Commit geht direkt auf main, weil es noch keinen Branch gibt, von dem abzuzweigen wäre. Ab #006 läuft jedes Issue über einen eigenen Branch. Closes #5 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2.1 KiB
2.1 KiB
#011 M6 – Mitarbeiter, Abteilungen, Geräte
Status: offen Meilenstein: v0.1.0 Labels: phase-1, backend, frontend Geschätzt: 9 h Tatsächlich: –
Ziel
Die Stammdaten, an denen die Historie hängt. Mitarbeiter und Geräte werden nie gelöscht, damit archivierte Läufe für immer auf sie zeigen können.
Aufgaben
- Mitarbeiterliste: Suche über Anzeigename, Mail, UPN und
sam, Filter nach Abteilung und Aktiv-Status - Mitarbeitersuche als wiederverwendbare Komponente: standardmäßig nur aktive, Umschalter „auch deaktivierte" fürs Offboarding
- Mitarbeiterseite: Stammdaten, Abteilung, Vorgesetzter, seine Geräte, alle Läufe chronologisch (Onboarding, Übergaben, Offboarding)
- Mitarbeiter manuell anlegen und bearbeiten (
herkunft = MANUELL); synchronisierte Felder sind beiherkunft = ABGLEICHgesperrt - Deaktivieren statt löschen (
aktiv = false) - Abteilungen: Name (eindeutig je Kunde), Ziel-OU, Standardgruppen (
String[]), Mail-Domain, Notizen - Geräte: Stammdaten nach Vorgabe, Pflichtregel „
hostnameoderbezeichnungmuss gesetzt sein", Besitzer optional - Geräteliste mit Suche über Hostname, Bezeichnung, Seriennummer und
tagCode, Filter nach Typ - CSV-Import für Geräte (
hostname,label,serialNumber,inventoryNumber,type,model),tagCodewird beim Import erzeugt; eigenersrc/lib/csv.ts - Archivieren statt Löschen, sobald Läufe an einem Gerät oder einer Abteilung hängen
- Screenshots Mitarbeiterliste, Mitarbeiterseite, Geräteliste, Abteilungen in
docs/screenshots/m6/
Akzeptanzkriterien
- Test: Mitarbeitersuche liefert standardmäßig nur
aktiv = true; mit Umschalter auch deaktivierte - Test: ein Gerät ohne
hostnameund ohnebezeichnungwird abgelehnt - Test: ein Gerät mit Läufen lässt sich nicht löschen, nur archivieren
- Test:
tagCodeeines bestehenden Geräts lässt sich nicht ändern - Test: CSV-Import erzeugt je Zeile einen
tagCode, meldet fehlerhafte Zeilen einzeln und bricht nicht ab - Test: bei
herkunft = ABGLEICHlehnt der Service Änderungen an synchronisierten Feldern ab