| 0.1 Projekt-Setup & Infrastruktur | GitLab-Repo-Struktur, CI/CD-Pipeline (GitLab CI mit Build/Test/Deploy-Stages), Docker-Konfiguration für alle drei Services (Angular, Kotlin/Spring Boot, Python/FastAPI), Kubernetes-Manifeste (Azure AKS), PostgreSQL-Schema-Initialiserung, Keycloak-Realm-Setup mit den drei Rollen (GU-Resource-Manager, Partner-Manager, Admin), Entwicklungsumgebung (Docker Compose für lokale Entwicklung), Amazon Bedrock Zugang (EU Frankfurt), Langfuse-Integration, OpenTelemetry-Grundkonfiguration. Einmaliger Aufwand, Voraussetzung für alle Feature-Stories. | 13-21 | 17.0 |
| 1.1 Profil hochladen und KI-Extraktion starten | PrimeNG FileUpload-Komponente (Drag-and-Drop + Dialog), Kotlin/Spring-Boot Multipart-Endpoint, asynchroner Aufruf des Python/FastAPI Intelligence Service, Lade-Indikator während der Extraktion, Fehlerbehandlung für nicht unterstützte Formate und Service-Fehler. Erfordert Cross-Service-Integration und Tests gegen den Intelligence Service. | 8-13 | 10.5 |
| 1.2 Extraktionsergebnis reviewen und korrigieren | Editierbare Angular-Formularmaske für hierarchisch strukturierte Extraktionsdaten (Skills, Zertifikate, Projekterfahrungen), Unsaved-Changes-Guard, explizite Speicheraktion, Sichtbarkeits-Toggle (Profil erst nach Review suchbar). Komplexe Formularlogik mit dynamischen Listen und Validierung. | 5-8 | 6.5 |
| 2.1 Experten nach Kriterien suchen und Trefferliste sehen | Multi-Kriterien-Suchmaske (PrimeNG MultiSelect, Datepicker, Slider), PostgreSQL Full-Text-Search mit kombinierten Filtern inkl. Datumsfilter "verfügbar ab/bis", systemweit erzwungene Anonymisierungsdurchsetzung auf API-Ebene (Trennung personenbezogener Felder, kein Bypass möglich), aktive Filter als entfernbare Chips, Tenant-Isolation. 9 Akzeptanzkriterien, zentraler Wertbeitrag der Plattform. | 8-13 | 10.5 |
| 2.2 Expertenprofil im Detail einsehen | Angular-Detailansicht (Read-only) mit Navigation aus der Trefferliste, Anzeige aller fachlichen Felder unter Wahrung der Anonymisierung (Name der Person ausgeblendet, Partnerfirma sichtbar), UI-Hinweis auf anonymisierte Darstellung, direkter Einstieg in den Anfrage-Workflow (Epic 5). | 3-5 | 4.0 |
| 3.1 Verfügbarkeit per E-Mail-Reminder aktualisieren | E-Mail-Template mit Deep Link zur Verfügbarkeitsmaske im System, Deep-Link-Routing im Angular-Frontend (nach Login direkt auf Verfügbarkeits-Übersicht), per-Experte Verfügbarkeitsformular mit Bestätigungsfeedback. Kein Token-Mechanismus — Standard-Auth-Flow. | 2-3 | 2.5 |
| 3.2 Automatische Verfügbarkeits-Reminder konfigurieren (Optional) | Admin-Konfigurationsformular für Reminder-Intervall, Scheduled-Job im Kotlin-Backend (Spring Scheduling), Persistierung des letzten Versanddatums pro Partner-Manager, E-Mail-Versand an alle aktiven Partner. | 2-3 | 2.5 |
| 4.1 Eigene Expertenpool-Übersicht im Dashboard einsehen | Angular-Dashboard-Seite mit PrimeNG-Tabelle, Kotlin-Backend-API mit Tenant-Isolation, DB-Abfrage mit Berechnung der Datenfrische für das Ampelsystem (grün/gelb/rot), systemseitig konfigurierbare Schwellwerte. Rein lesend, kein Schreibpfad. | 3-5 | 4.0 |
| 4.2 Skill-Matrix des eigenen Expertenpools einsehen | PrimeNG Chart-Komponente (Balken- oder Säulendiagramm) für die Skill-Häufigkeitsverteilung, Backend-Aggregationsabfrage (GROUP BY Skill, COUNT verfügbare Experten) über den Expertenpool, automatische Aktualisierung bei Profil- oder Verfügbarkeitsänderungen. | 3-5 | 4.0 |
| 5.1 Teilabruf zusammenstellen und Experten anfragen | Multi-Experten-Auswahl-UI (aus Trefferliste und Profildetail), Teilabruf-Datenmodell (Bezeichnung, Zeitraum, Anforderungen), asynchroner E-Mail-Versand pro betroffenem Partner-Manager (Spring Async), Status-Tracking-Ansicht (Gesamtstatus + Status je Einzelanfrage: offen/bestätigt/abgelehnt), anonyme Profildarstellung in der Anfrageliste bis zur Freigabe. 8 Akzeptanzkriterien, komplexester Workflow der Plattform. | 8-13 | 10.5 |
| 5.2 Anfrage bestätigen oder ablehnen und Identität freigeben | Eingehende-Anfragen-Ansicht im Partner-Dashboard, Bestätigen/Ablehnen-Aktion mit optionalem Kommentar, Zustandsautomat im Backend (freigegeben/nicht freigegeben pro Anfrage und Experte), explizite De-Anonymisierungs-Freigabe als bewusste UI-Aktion beim Bestätigen, bedingte Datenexposition im API je nach Freigabestatus, Sicherheitstests auf unautorisierte De-Anonymisierung, Benachrichtigung des GU-Resource-Managers per E-Mail. | 8-13 | 10.5 |
| 5.3 Freigegebenes Expertenprofil nach Bestätigung einsehen | Bedingte Darstellung de-anonymisierter Profildaten im Angular-Frontend (Name, Kontaktdaten sichtbar nach Freigabe), Statusanzeige pro Experte im Teilabruf (freigegeben / ausstehend), Anfrage-gebundene Datenisolation (in anderen Kontexten bleibt der Experte anonym). Backend-Zustandslogik in Story 5.2 bereits abgedeckt. | 2-3 | 2.5 |
| 5.4 Übersicht aller laufenden Teilabrufe einsehen | Angular-Übersichtsseite (GU-Dashboard) mit Liste aller Teilabrufe, aggregierte Kennzahlen (offene Anfragen, bestätigte Experten), visuelle Hervorhebung von Teilabrufen mit Handlungsbedarf, Backend-API mit Statusaggregation (bestätigt/abgelehnt/offen pro Teilabruf). | 2-3 | 2.5 |
| 5.5 Benutzer und Partner-Accounts verwalten | Admin-UI für Keycloak-Benutzer-Management (Anlegen, Einladen, Deaktivieren, Löschen), RBAC-Rollenzuweisung für drei Rollen, rollenspezifische Routing-Guards im Angular-Frontend, System-Konfigurationsverwaltung (Reminder-Intervalle, Ampel-Schwellwerte). Berührt Authentifizierungsinfrastruktur (Keycloak-Integration). | 8-13 | 10.5 |
| 5.6 Mindest-Abnahmemenge pro Partnerfirma konfigurieren (Optional) | Konfigurationsfeld im Teilabruf-Workflow (Story 5.1) für Mindestmengen pro Partnerfirma, Validierungslogik im Backend (Soft-Constraint: Hinweis, keine Sperre), per-Abruf anpassbar, UI-Hinweis bei Unterschreitung. | 2-3 | 2.5 |