von mir an den Agenten.
screenshots habe ich in figures/screenshots gelegt.

# Inhaltliche TODOs

- [x] screenshots vom feature in den anhang
- [ ] aktualisieren auf den aktuellen devops stand (alles getested, 1 bug fix, prod deployment)
    -> "3.5 Zeit- und Aufwandsplanung" aktualisieren
    -> "Figure 3.2: Zeitplanung des Projekts" aktualisieren
    -> "5.10.5 Stand bei Abgabe" aktualisieren
    -> allgemein ueber alle chapter nochmal drueber gehen und schauen ob das den aktuellen stand reflektiert
- [x] architektur der implementierung:
    - ich habe in meiner freizeit sehr viel rust programmiert und dort auch das NewType pattern kennen gelernt, an dem ich mich hier orientierte (auch wenn es C# ist), da ich die vorteile besonders hier wo man eigentlich mit den nur mit ganz vielen string keys rum hantiert, sie aus einander baut, und wieder zusammenbaut, erkannte. id input string -> s3 gibt keys zurueck -> parsing -> domain model -> verbarbeitung -> wenn weitere requests gebraucht werden, vom domain model wieder einen key zusammenbauen
    - "parse, don't validate" philosophie
- [x] mit den vom pidi 2 noch relevanten abbildungen ergaenzen
    - houston architektur
    - unicorn prozess
    - etc.
- [x] "Figure 3.1: Zustände eines Work Items in Azure DevOps" sollte mit dem eigentlichem unicorn prozess bild ersaetzt werden. ich arbeite naehmlich nach dem ganz normalen prozess
    - "3.4.1 Entwicklungsprozess" sollte dahingehend auch aktualisiert werden, und nicht *Linus-speziefisch* sein.
- [x] "3.4.2 Schnitt der Product Backlog Items": ein abbild aus dem devops oder eine tabelle mit den PBIs ergaenzen verweisen
- [x] "Figure 3.3: Chronologie der Infrastrukturbeschaffung" sieht komisch aus, die pfeile gehen nach unten Chronologie geht aber nach rechts. sollte gefixed werden.
- [x] "4.3.3 Verhalten bei unbekannten Ordnern" (todo fuer mich) ist das richtig? oder werden unbakannte typ-order einfach nicht angezeigt? bin mir da gerade nichtmal sicher
- [x] "4.4.1 Zuarbeit über einen Clickdummy" bezieht sich rein ueber das UI der Typ-Filterung. alles andere stammt von mir. Hanna Ebner hat in Houston die fuehrende Entscheidungskraft, was das UI angeht, und aus dem Grund habe ich mich mit ihr abgestimmt wie das aussehen soll, und sie hat als Referenz den Clickdummy branch erstellt. Die implementierung liegt immer noch in meiner hand. (das ist wichtig fuer das PIDI, da die Arbeit eigentlich von mir kommen soll).
- [x] in "4.4.2 Flache Liste statt navigierbarer Hierarchie": "Die ursprüngliche Beschreibung sah Dokumentkacheln vor, wurde jedoch auf Zeilen-darstellung geändert" auch das ist eine Entscheidung von Hanna Ebner, die meine überwichtete.
- [x] "4.4.3 Aufbau der Seite": screenshots im anhang einfügen und verweisen
- [x] "4.5.2 Untersuchte Lösungsansätze" Lösungsansätze wurden von allein *mir* erarbeitet und mit Timo und Bianco nur abgesprochen und reviewed.
- [x] "5.4.1 Eigene Symbole statt Symbolschrift": icons im anhang einfuegen, darauf hinweisen, dass die Designs von mir entworfen und in Zusammenarbeit mit Hanna Ebner ausgearbeitet wurden.
- [x] "Nicht umgesetzt ist eine Filterung durch den Speicher. Houston listet die Objekte auf und filtert die Namen anschließend selbst. Im Review stellte Hanna Ebner die Frage, ob sich das nicht direkt über die Schnittstelle lösen lasse, und musste verneint werden.": auf den abschnitt verweisen wo die AU die Search Integration abgelehnt hat
- [ ] "5.8.3 Vorschau in Messengern": auf screenshots verweisen
- [ ] "5.8.4 Sichtbarkeit der Vorschaubilder": darauf verweisen, dass es eigentlich ziemlich elegant ist das gesamte vorschau bild von der base64 encoded id in der url auf dem öffentlichem `/share`-endpunkt zu lesen. somit wird auf diesem öffentlichem endpunkt niemals auch nur ein aufruf nach s3 gemacht.
- [ ] "5.9.5 Symbole für Verknüpfungen": screenshots von symbolen verweisen, maybe mehr info zu den icons (siehe resources/xwiki/urlfile_docs.xwiki)

# Strukturelle TODOs

- [ ] auf etwa 45 Seiten runter bringen (zuletzt machen nachdem der inhalt angepasst wurde)
    - [ ] brauchen wir in "3.6 Beschaffung der S3-Infrastruktur" wirklich eine Bewertung...?
    - [ ] allegemin sowas wie: "Im Review fragte Robin Noack, ob die Einschränkungen ausreichen. Eine zu schwache Normalisierung führt zu Schlüsseln, die der Speicher zurückweist — das wäre erst bei einem Kunden mit ungewöhnlichem Firmennamen aufgefallen. Die Antwort verwies auf die Herstellerdokumentation (IBM 2026; Amazon Web Services 2026c)." das ist vielzuviel text einfach nur um zu sagen "laut der IBM doku passt das so"
    - [ ] "Timo Walter merkte an, dass reale Kundennamen in den Tests verwendet wurden, und schlug Platzhalter vor. Der Hinweis ist klein, in der Sache aber richtig: Testdaten liegen in der Versionsverwaltung und bleiben dauerhaft lesbar; ein realer Kundenname ist eine unnötige Offenlegung, da der Test mit Platzhaltern denselben Zweck erfüllt. Die Daten wurden ersetzt." unnötige details schon wieder...
- [ ] Ein paar der bibreferences sehen komisch aus und zeigen nicht richtig auf den korrekten bib eintrag, sollte gefixed werden.
- [ ] Die Abbildungen nehmen vertikal sehr viel white space ein, das sollte nicht so sein.
- [ ] ähnlich wie ich es in ~/repos/itc.componentware/ gemacht habe, eine flake und ein build output haben.

# Review

- [x] "4.5 Das Lookup-Problem" auf Inhaltliche korrektheit pruefen