chapters: Fliesstext auf 57 reine Textseiten kuerzen

Zwei Kompressionsdurchgaenge ueber Kapitel 2-7. Entfernt wurden
Redundanzen, Meta-Kommentare, Ueberklaerungen und Fuellsaetze;
Fakten, Namen, Daten, Entscheidungen samt Begruendung sowie alle
Abbildungen und Tabellen bleiben unveraendert.

Reine Textseiten: 78 -> 57 (Woerter 19613 -> 12451).
Gesamt-PDF: 138 -> 116 Seiten.

.latexmkrc

@@ -2,3 +2,6 @@ $pdf_mode = 4;            # lualatex
 $bibtex_use = 2;          # biber
 $out_dir = out;
 $clean_ext .= ' %R.run.xml %R.bbl %R.bcf %R-blx.bib';
+
+# Never stop for a prompt: a failing listing would otherwise loop forever.
+$lualatex = 'lualatex -interaction=nonstopmode -halt-on-error %O %S';

appendix/appendix-code.tex

@@ -1,10 +1,109 @@
-% TODO: Code-Ausschnitte — je in center-Umgebung mit \captionof{listing}{...} + \inputminted
+\newcommand{\codelisting}[4]{%
+  \par\medskip\noindent
+  \begingroup
+  \captionsetup{type=listing,hypcap=false}%
+  \captionof{listing}{#1}%
+  \label{#2}%
+  \endgroup
+  \nopagebreak
+  \inputminted[
+    fontsize=\scriptsize,
+    linenos,
+    breaklines,
+    breakanywhere,
+    breaksymbolleft={},
+    frame=single,
+    framesep=1.5mm,
+    tabsize=4,
+    numbersep=3mm,
+  ]{#3}{figures/code/#4}%
+  \par\medskip
+}
 
-% Reihenfolge gemäß Kapiteln:
+Die folgenden Ausschnitte stammen aus dem Houston-Repository und geben den Stand
-% s3-settings-registration.cs, s3-documents-client.cs,
+zum Ende des Projektzeitraums wieder. Sie sind auf die jeweils besprochene Stelle
-% documents-page-model.cs, document-view-model.cs, documents-table-body.cshtml,
+gekürzt; Auslassungen sind mit \texttt{// \ldots} gekennzeichnet.
-% document-type-mapping.cs, document-types.resx,
+
-% document-search.cs, pagination-continuation-token.cs,
+\subsection{Anbindung des Objektspeichers}
-% zip-download-action.cs, presigned-url.cs, url-file-parsing.cs,
+
-% org-slug.cs, resolve-customer-prefix.cs, rename-customer-folder.cs,
+\codelisting{Registrierung des S3-Clients als benannter Dienst, einschließlich der
-% authorization-policy.cs, documents-service-tests.cs
+Korrektur des \texttt{x-amz-copy-source}-Headers}{lst:s3-client-registration}{csharp}{s3-client-registration.cs}
+
+\codelisting{Konfigurationsobjekte für Endpunkt, Zugangsdaten und Bucket}{lst:s3-settings}{csharp}{s3-settings.cs}
+
+\codelisting{Autorisierung des Dokumentenbereichs in \texttt{Program.cs}}{lst:auth-policy}{csharp}{auth-policy.cs}
+
+\clearpage
+\subsection{Typisierte Pfade}
+
+\codelisting{\texttt{DocumentKey} — vollständiger Objektschlüssel einschließlich
+Kundenordner, nur über eine validierende Fabrikmethode erzeugbar}{lst:document-key}{csharp}{document-key.cs}
+
+\codelisting{\texttt{DocumentId} — die in URLs verwendete Kennung, die den
+Kundenordner bewusst nicht enthält}{lst:document-id}{csharp}{document-id.cs}
+
+\codelisting{\texttt{DocumentName} — Ableitung von Anzeigename, PDF- und
+Verknüpfungseigenschaft aus der Dateiendung}{lst:document-name}{csharp}{document-name.cs}
+
+\clearpage
+\subsection{Dokumenttypen und Symbole}
+
+\codelisting{Dokumenttypen und Ableitung des Ordnernamens aus der
+Übersetzungsressource}{lst:document-type}{csharp}{document-type.cs}
+
+\codelisting{Einbindung der Typsymbole als CSS-Maske, damit sie die Themenfarbe
+übernehmen}{lst:type-icon-mask}{scss}{type-icon-mask.scss}
+
+\clearpage
+\subsection{Auflistung, Suche und Blätterfunktion}
+
+\codelisting{Durchlaufen aller Antwortseiten über den Fortsetzungs-Token}{lst:pagination}{csharp}{pagination-continuation-token.cs}
+
+\codelisting{Auflisten der Dokumente eines Kunden mit Einstiegspunkt für die
+Folgeseite}{lst:list-documents}{csharp}{list-documents.cs}
+
+\codelisting{Anwendungsseitige Filterung nach Suchbegriff und
+Dokumenttyp}{lst:document-search}{csharp}{document-search.cs}
+
+\codelisting{Tabellenkörper der Dokumentenübersicht}{lst:documents-table}{html}{documents-table-body.cshtml}
+
+\clearpage
+\subsection{Download, Vorschau und Freigabe}
+
+\codelisting{Erzeugung vorsignierter URLs und der zugehörigen
+\texttt{Content-Disposition}-Kopfzeilen}{lst:presigned-url}{csharp}{presigned-url.cs}
+
+\codelisting{Streamen des ZIP-Archivs ohne Zwischenpufferung}{lst:zip-archive}{csharp}{zip-archive.cs}
+
+\codelisting{Handler des ZIP-Downloads einschließlich der gezielten Freigabe
+synchroner Schreibvorgänge}{lst:zip-handler}{csharp}{zip-download-handler.cs}
+
+\codelisting{Anonyme Landeseite für Freigabelinks}{lst:share-page}{csharp}{share-page.cs}
+
+\clearpage
+\subsection{Verknüpfungsdateien}
+
+\codelisting{Der eigene INI-Parser}{lst:ini-parser}{csharp}{ini-parser.cs}
+
+\codelisting{Auswertung einer \texttt{.url}-Datei mit Prüfung des
+Zielschemas}{lst:url-file}{csharp}{url-file-parsing.cs}
+
+\clearpage
+\subsection{Kundenordner}
+
+\codelisting{Bildung des kanonischen Ordnernamens aus dem
+Efecte-Firmennamen}{lst:org-slug}{csharp}{org-slug.cs}
+
+\codelisting{Dreistufiger Lookup des Kundenordners}{lst:resolve-customer-prefix}{csharp}{resolve-customer-prefix.cs}
+
+\codelisting{Umbenennen eines Kundenordners — die in Abschnitt~\ref{sec:race-conditions}
+beschriebene Stelle}{lst:rename-folder}{csharp}{rename-customer-folder.cs}
+
+\clearpage
+\subsection{Tests}
+
+\codelisting{Testdoppel des Objektspeichers: geschriebene Objekte werden für
+spätere Abfragen sichtbar}{lst:tests-empty-bucket}{csharp}{tests-empty-bucket.cs}
+
+\codelisting{Test gegen Pfadmanipulation — die Kennung wird bewusst unter Umgehung
+der Validierung erzeugt}{lst:test-path-traversal}{csharp}{test-path-traversal.cs}

appendix/appendix-tables.tex

@@ -113,3 +113,37 @@ Organisations-ID im Ordnernamen
   & Mutierender Anteil im Anfragepfad (Abschnitt~\ref{sec:race-conditions})
   & \textbf{gewählt} \\
 \end{longtable}
+
+\begin{longtable}{@{} l p{48mm} l c c l @{}}
+\caption{Pull Requests zum Feature 484}
+\label{tab:pull-requests} \\
+\toprule
+\textbf{PR} & \textbf{Titel} & \textbf{PBI} & \textbf{Laufzeit} & \textbf{Threads} & \textbf{Reviewer} \\
+\midrule
+\endfirsthead
+\toprule
+\textbf{PR} & \textbf{Titel} & \textbf{PBI} & \textbf{Laufzeit} & \textbf{Threads} & \textbf{Reviewer} \\
+\midrule
+\endhead
+\bottomrule
+\endfoot
+2154 & Add document explorer                      & 9295        & 4 T   & 21 & Timo Walter \\
+2155 & Add document type icons                    & 9549        & 16 T  & 12 & Timo Walter \\
+2156 & Dokumente Suche                            & 9298        & 16 T  & 4  & Timo Walter \\
+2157 & Dokument download action                   & 9299        & 22 T  & 30 & Timo Walter \\
+2164 & Create document share link previews        & 9294        & 22 T  & 23 & Timo Walter \\
+2169 & Dokumente ZIP Downloads                    & 9296        & 17 T  & 4  & Sarah Hinzmann \\
+2170 & Document PDF preview modal                 & 9300        & 17 T  & 2  & Sarah Hinzmann \\
+2180 & Document explorer URL file support         & 9301        & 9 T   & 6  & Robin Noack \\
+2186 & Add document type filters                  & 9749        & 8 T   & 5  & Robin Noack \\
+2189 & Implement pagination for document explorer & 9731        & 8 T   & 5  & Robin Noack \\
+2196 & Documents folder management                & 9560, 10018 & offen & 1  & --- \\
+\addlinespace
+\multicolumn{4}{@{}l}{\textbf{Summe}} & \textbf{113} & \\
+\end{longtable}
+
+{\footnotesize
+Zusätzlich war die Gruppe \texttt{Development Team} über die Branch-Policy als
+Pflicht-Reviewer an allen elf Pull Requests beteiligt. An den Diskussionen der Pull
+Requests 2154 bis 2156 beteiligte sich außerdem Hanna Ebner. Alle abgeschlossenen Pull
+Requests wurden freigegeben; keiner wurde abgelehnt oder verworfen.\par}

chapters/closure/evaluation.tex

@@ -1,4 +1,36 @@
 \section{Zielerreichung}
 \label{sec:evaluation}
 
-% TODO
+\subsection{Bewertung gegen die Zielsituation}
+
+Die in Abschnitt~\ref{sec:target-situation} beschriebene Zielsituation ist erreicht: Kunden verfügen über einen zentralen, selbstständig nutzbaren Zugang zu ihren Dokumenten. Die zuvor bestehenden Probleme — fehlende Zentralisierung, kein Self-Service, kein strukturierter Überblick, kein mandantengetrennter Zugriff — sind adressiert.
+
+Eine seit Ende 2023 im Backlog liegende Bedarfsnotiz wurde innerhalb eines Projektzeitraums zur produktiven Funktion. Entscheidend war die Konkretisierung: Erst die Ausarbeitung im Juni machte aus zwei Stichpunkten eine umsetzbare Anforderung.
+
+\subsection{Fachliche Ziele}
+
+Sämtliche fachlich geforderten Funktionen sind umgesetzt — über den Kern hinaus auch die nachrangigen Komfortfunktionen: Suche, Einzeldownload, Archivdownload, Vorschau, Freigabelinks und Verknüpfungsdateien.
+
+Der Kern — Auflistung mit Mandantentrennung — war nach vier Tagen zusammengeführt, sodass die Folgearbeiten früh beginnen konnten.
+
+\subsection{Technische Ziele}
+
+Die zentrale technische Herausforderung war nicht in der Zielsetzung enthalten, sondern entstand aus der Kombination von Autorisierung über ein Metadatum, lesbaren Ordnernamen und fehlender Metadatensuche des Speichers.
+
+Die Lösung erfüllt die Anforderung ohne zweite Datenhaltung und heilt bestehende Abweichungen selbsttätig — tragfähiger als die zunächst naheliegenden Ansätze. Dass sie bei Abgabe noch nicht ausgeliefert war, ist festzuhalten.
+
+\subsection{Nicht erreichte Ziele}
+
+Drei Punkte sind offen geblieben.
+
+Die \textbf{Nebenläufigkeit im verändernden Lookup-Pfad} ist analysiert, dokumentiert und mit Lösungsvorschlägen versehen, aber nicht behoben — bewusst abgegrenzt, da die Wahl der Gegenmaßnahme von einer Rückfrage beim Betreiber abhängt.
+
+Die \textbf{Optimierung der Dokumentensuche} bleibt offen, da der Suchdienst des Speicherherstellers nicht bereitsteht; die Auswirkung ist gering, weil die Suche nur mit der Dokumentenzahl eines einzelnen Kunden skaliert.
+
+Der \textbf{Fehlerbericht zur Einheitlichkeit des Suchfeldes} ist erfasst und eingeplant.
+
+\subsection{Gesamtbewertung}
+
+Das Projektziel ist erreicht. Der Dokumentenbereich ist in seinen Kernfunktionen produktiv, erfüllt die fachlichen Anforderungen, und die verbleibenden Arbeiten sind klar benannt und im Backlog erfasst.
+
+Der aussagekräftigste Befund ist die Nebenläufigkeit: Sie wurde durch eigenes Nachprüfen des bereits geschriebenen Codes gefunden — nicht durch Test, Fehlerbericht oder Review. Ein Projekt, das eine solche Schwäche selbst findet und einordnet, steht besser da als eines, in dem sie unentdeckt bliebe.

chapters/closure/outlook.tex

@@ -1,6 +1,44 @@
 \section{Ausblick}
 \label{sec:outlook}
 
-% TODO: PBI 10070 (Race Conditions), Search Integration (von AU noch nicht verfügbar),
+\subsection{Abschluss der begonnenen Arbeiten}
-% Dashboard-Kacheln (Security Assessments, zuletzt hinzugefügte Dokumente),
+
-% Abrechnungsdaten
+Die nächsten Schritte ergeben sich aus Abschnitt~\ref{sec:target-comparison}.
+
+Zusammenzuführen ist der Pull Request zur Ordnerverwaltung, womit die automatische Ordneranlage und der Lookup mit konstanter Aufrufzahl wirksam werden. Da die Lösung bestehende Ordner selbsttätig umbenennt, entfällt ein Migrationsschritt.
+
+Zu beheben ist der Abnahmefehler zur Einheitlichkeit des Suchfeldes, eingeplant für den folgenden Sprint.
+
+\subsection{Absicherung des verändernden Lookup-Pfads}
+
+Die in Abschnitt~\ref{sec:race-conditions} beschriebene Nebenläufigkeit ist das gewichtigste offene Thema. Das Backlog Item ist freigegeben und mit vier bis sechs Stunden veranschlagt.
+
+Welche Maßnahme umgesetzt wird, hängt davon ab, ob der Speicher bedingte Schreibvorgänge unterstützt.\autocite{aws-conditional-writes} Steht die Funktion bereit, ist die Absicherung einfach; andernfalls bleiben die Absicherung des Rücknahmeschritts und eine übergreifende Sperre.
+
+Unabhängig davon ließe sich der verändernde Anteil aus dem Anfragepfad in einen eigenen, einmalig ausgeführten Vorgang lösen; der Lookup könnte dann auf reines Lesen zurückgeführt werden.
+
+\subsection{Suchdienst des Speicherherstellers}
+
+Der in Abschnitt~\ref{sec:lookup-research} betrachtete Suchdienst\autocite{storagegrid-search-integration} wurde vom Betreiber nicht bereitgestellt; ein Folgetermin war vorgeschlagen, aber nicht durchgeführt.
+
+Sollte der Dienst verfügbar werden, ließe sich der Kundenordner-Lookup über eine Metadatenabfrage lösen — die eigene Konstruktion bliebe als Rückfallebene. Zudem könnte die Dokumentensuche serverseitig erfolgen statt anwendungsseitig. Beides sind Optimierungen; die bestehende Umsetzung funktioniert, skaliert aber schlechter.
+
+\subsection{Fachliche Erweiterungen}
+
+In der Feature-Beschreibung sind zwei Erweiterungen genannt, die nicht in Backlog Items überführt wurden.
+
+Die erste betrifft die \textbf{Einbindung in die Übersichtsseite} — etwa eine Kachel mit zuletzt hinzugefügten Dokumenten oder Sicherheitsbewertungen. Für Letztere wäre ein auswertbares Merkmal pro Dokument nötig, das mit der bestehenden Struktur (Typ über den Ordner) nicht abbildbar ist.
+
+Die zweite betrifft die \textbf{Bereitstellung von Abrechnungsdaten}. Fachlich ist zu klären, ob diese über den Dokumentenbereich oder eine gesonderte Ansicht erfolgen, da sie sich in Herkunft und Aktualisierungsrhythmus von den übrigen Dokumenttypen unterscheiden.
+
+\subsection{Bedienung durch die interne Fachseite}
+
+Die Entscheidung, die Dokumentenpflege über den externen Dateibrowser abzuwickeln, war für den Projektzeitraum richtig, aber bewusst als Zwischenlösung getroffen. Sollte die Pflege häufiger oder von mehr Personen übernommen werden, wäre eine Verwaltungsoberfläche im Portal zu bewerten — sie könnte die Ordnerstruktur erzwingen statt auf manuelle Einhaltung zu setzen.
+
+\subsection{Übertragbarkeit}
+
+Das Projekt hat zwei wiederverwendbare Bausteine hervorgebracht.
+
+Der \textbf{Zugriff auf den Objektspeicher} ist als eigener Dienst gekapselt und nicht auf Dokumente zugeschnitten; weitere Anwendungsfälle können darauf aufsetzen.
+
+Die \textbf{Muster für Freigabelinks und Vorschaubilder} — Pfadkodierung, eingeschränkte Auslieferung auf einem nicht angemeldeten Endpunkt, Bereitstellung in einem von Kommunikationsanwendungen unterstützten Format — lassen sich für andere teilbare Inhalte wiederverwenden.

chapters/closure/reflection.tex

@@ -1,5 +1,48 @@
 \section{Reflexion}
 \label{sec:reflection}
 
-% TODO: Lessons Learned — S3-Lookup-Entscheidung, Race Conditions als offenes Thema,
+\subsection{Externe Abhängigkeiten früher klären}
-% Infrastruktur-Vorlauf unterschätzt (AU-Kommunikation 2026-07-22 bis 2026-08-07)
+
+Zwischen Antrag und abschließender Auskunft über die verfügbaren Speicherfunktionen lagen vier Wochen — bei einem Projektzeitraum von wenigen Wochen ein erheblicher Anteil.
+
+Der Fehler lag im Zeitpunkt: Die fachliche Klärung war seit dem 18.~Juni abgeschlossen; der Antrag folgte über vier Wochen später. Hätte er unmittelbar nach der Feature-Analyse vorgelegen, wäre die Frage nach den Speicherfunktionen früher beantwortet gewesen — die Lookup-Recherche hätte nicht auf eine letztlich negative Antwort warten müssen.
+
+Vorgänge, deren Dauer man nicht selbst bestimmt, gehören an den Anfang der Planung. Sie kosten keine Arbeitszeit, aber Wartezeit — und Wartezeit lässt sich nur durch frühes Beginnen verkürzen.
+
+\subsection{Eine Architekturentscheidung ist die Summe ihrer Randbedingungen}
+
+Das Lookup-Problem war die technisch anspruchsvollste Aufgabe des Projekts.
+
+Die zunächst betrachteten Ansätze — Zwischenspeicher, Anmeldetoken, Feld im ITSM-System — waren technisch tragfähig, wurden aber verworfen, weil sie jeweils eine zweite Stelle einführen, an der dieselbe Information gepflegt wird. Die gewählte Lösung ergab sich aus der genauen Betrachtung der Randbedingungen.
+
+Ausschlaggebend war die Unterscheidung zwischen Anforderung und vermuteter Umsetzung: Die interne Pflege verlangte eine \emph{Sortierung nach Kundennamen}, nicht zwingend Ordnernamen, die \emph{ausschließlich} aus dem Kundennamen bestehen. Diese Präzisierung machte die Lösung sichtbar; ohne die Rückfrage bei der internen Fachseite wäre der Lösungsraum enger geblieben.
+
+Wenn alle betrachteten Lösungen unbefriedigend sind, lohnt die Prüfung, ob eine Randbedingung genauer formuliert werden kann als zunächst verstanden.
+
+\subsection{Eigene Arbeit gegenlesen}
+
+Die Nebenläufigkeit wurde nicht durch Test, Review oder Fehlerbericht gefunden, sondern durch erneutes Durchgehen des eigenen, fertiggestellten Codes.
+
+Der Pull Request war eingereicht. Die Fehlerbehandlung des Umbenennens war geschrieben worden, um Datenverlust zu verhindern — und genau sie verursacht ihn unter Nebenläufigkeit. Ein selbst eingebautes Sicherheitsnetz prüft man nicht ohne Weiteres erneut.
+
+Ausschlaggebend war ein Perspektivwechsel: nicht „funktioniert das?", sondern „was passiert, wenn das zweimal gleichzeitig läuft?". Diese Frage ist für jeden verändernden Codepfad einer Anwendung mit mehreren Instanzen zu stellen — sie war beim Schreiben unterblieben, weil der Pfad als seltener Sonderfall galt. Genau diese Einordnung ließ die Prüfung unterbleiben.
+
+\subsection{Pull Requests kleiner und sequenziell schneiden}
+
+Die in Abschnitt~\ref{sec:code-reviews} beschriebene Ballung war Folge einer bewussten, im Rückblick falschen Entscheidung: Vier gleichzeitig eröffnete Pull Requests sollten Wartezeiten auf Reviews vermeiden.
+
+Der erwartete Vorteil trat nicht ein, weil die Arbeiten aufeinander aufbauten: Statt Parallelität entstand eine Warteschlange, deren Auflösung sich in die Woche vor Abnahme und Produktivsetzung verschob. Die Verkettung der Zielbranches brachte eigene Kosten: Jede Umstellung auf den Hauptbranch setzte Freigaben zurück. Bei abhängigen Aufgaben ist sequenzielles Vorgehen vorzuziehen.
+
+\subsection{Konsistenz braucht einen Vergleich, keine Beschreibung}
+
+Der einzige Abnahmefehler betrifft eine Anforderung aus mehreren Backlog Items: Die Bedienung soll sich an den übrigen Seiten orientieren.
+
+Sie wurde nicht verletzt, weil sie übersehen wurde, sondern weil sie sich nicht aus einer Beschreibung ableiten lässt. Eine Schaltfläche zum Leeren des Suchfelds widerspricht keiner Vorgabe — erst der Vergleich mit den bestehenden Seiten macht die Abweichung sichtbar.
+
+Für solche Anforderungen ist ein Abnahmetest durch eine Person, die die Anwendung kennt, unersetzbar — und sollte früher angesetzt werden als hier geschehen.
+
+\subsection{Persönliche Einordnung}
+
+Gegenüber den vorangegangenen Praktika lag der Schwerpunkt auf Entwurfsentscheidungen. Der Anteil für Recherche, Abwägung und Begründung war erheblich — die sechs Lösungsansätze für den Lookup und die Nebenläufigkeitsanalyse erzeugten keine einzige Zeile ausgelieferten Codes.
+
+Zugleich bestimmten diese Anteile den Projektverlauf. Die Erfahrung, dass eine sauber begründete Abgrenzung mehr wert ist als eine schnelle, unvollständige Behebung, ist die wesentliche Erkenntnis dieses Projekts.

chapters/closure/target-comparison.tex

@@ -1,4 +1,53 @@
 \section{Soll-Ist-Vergleich}
 \label{sec:target-comparison}
 
-% TODO: Tabelle Soll-Ist (Zeitplan, Features)
+\subsection{Zeitlicher Verlauf}
+
+Tabelle~\ref{tab:soll-ist} stellt die geplanten den tatsächlichen Zeitpunkten gegenüber.
+
+\begin{longtable}{@{} p{45mm} l l p{40mm} @{}}
+\caption{Soll-Ist-Vergleich der Projektphasen}
+\label{tab:soll-ist} \\
+\toprule
+\textbf{Phase} & \textbf{Soll} & \textbf{Ist} & \textbf{Abweichung} \\
+\midrule
+\endfirsthead
+\toprule
+\textbf{Phase} & \textbf{Soll} & \textbf{Ist} & \textbf{Abweichung} \\
+\midrule
+\endhead
+\bottomrule
+\endfoot
+Feature-Analyse            & 18.06. & 18.06. & keine \\
+Backlog-Schnitt            & 18.06.--08.07. & 18.06.--08.07. & keine \\
+Infrastruktur beantragt    & --- & 22.07. & nicht eingeplant \\
+Infrastruktur verfügbar    & --- & 27.07. & nicht eingeplant \\
+Umsetzung Sprint 15.2026   & 27.07.--12.08. & 27.07.--19.08. & +1 Woche \\
+Umsetzung Sprint 16.2026   & 13.08.--25.08. & 12.08.--offen & Lookup nicht gemergt \\
+Abnahmetest                & ab 13.08. & 13.08.--25.08. & Zugriffsprobleme \\
+Produktivsetzung Kern      & --- & 20.08. & --- \\
+Nebenläufigkeit (10070)    & --- & offen & nach Projektzeitraum \\
+Bugfix aus Abnahme (10134) & --- & Sprint 17.2026 & nach Projektzeitraum \\
+\end{longtable}
+
+Die Analyse- und Planungsphase verlief planmäßig; die Abweichungen treten in der zweiten Projekthälfte auf und haben zwei Ursachen.
+
+\subsection{Ursache 1: Nicht eingeplanter Infrastrukturvorlauf}
+
+Die Beschaffung des Speichers war nicht als eigener Vorgang eingeplant und wurde erst am 22.~Juli beantragt, obwohl die fachliche Klärung seit dem 18.~Juni abgeschlossen war. Die Bereitstellung dauerte fünf Arbeitstage — der Verlust entstand durch den späten Antrag.
+
+Unmittelbare Verzögerung entstand nicht, da die Umsetzung erst am 27.~Juli begann. Die Klärung der Speicherfunktionen zog sich jedoch vom 30.~Juli bis zum 17.~August und fiel in die Umsetzungsphase; die Lookup-Recherche war währenddessen blockiert.
+
+\subsection{Ursache 2: Nachgeschobene Backlog Items}
+
+Von den 14 Backlog Items waren acht zu Beginn geschnitten; sechs kamen während der Umsetzung hinzu — Typfilter, Paginierung, Recherche zur Speicherabfrage, neuer Lookup, automatische Ordneranlage und Nebenläufigkeit.
+
+Sie entstanden nicht aus fachlicher Ausweitung, sondern aus technischen Problemen, die erst bei der Implementierung sichtbar wurden. Die Schätzung wuchs von 35 auf 46 Aufwandspunkte — rund ein Drittel Zuwachs.
+
+\subsection{Abgleich mit den Anforderungen}
+
+Von 13 funktionalen Anforderungen sind zwölf ausgeliefert. Die dreizehnte — automatische Anlage der Ordnerstruktur — ist implementiert, aber im noch nicht zusammengeführten Pull Request.
+
+Bei den nichtfunktionalen Anforderungen sind fünf von sechs erfüllt. Die Skalierbarkeit des Lookups ist gelöst, aber nicht ausgeliefert; bis dahin gilt das lineare Verfahren — konzeptionell erfüllt, betrieblich noch nicht wirksam.
+
+Hinzu kommt die Nebenläufigkeit (Abschnitt~\ref{sec:race-conditions}) — keine unerfüllte Anforderung, sondern eine neu erkannte Eigenschaft, als eigenes Backlog Item erfasst und freigegeben.

chapters/conception/authorization.tex

@@ -1,38 +1,38 @@
 \section{Autorisierungskonzept}
 \label{sec:authorization}
 
-Der Dokumentenbereich verarbeitet Vertragsunterlagen, Abrechnungsdaten und Security Assessments. Ein fehlerhafter Zugriff hätte damit unmittelbar die Offenlegung vertraulicher Kundendaten zur Folge. Das Autorisierungskonzept arbeitet deshalb zweistufig: Eine Rollenprüfung entscheidet, \emph{ob} ein Benutzer den Bereich überhaupt betreten darf, und eine Mandantenprüfung entscheidet, \emph{welche} Dokumente er darin sieht.
+Der Dokumentenbereich verarbeitet Vertragsunterlagen, Abrechnungsdaten und Security Assessments. Das Autorisierungskonzept arbeitet zweistufig: Eine Rollenprüfung entscheidet, \emph{ob} ein Benutzer den Bereich betreten darf, eine Mandantenprüfung, \emph{welche} Dokumente er sieht.
 
 \subsection{Authentifizierung und Claims}
 
-Die Authentifizierung erfolgt wie in der übrigen Houston-Anwendung über Microsoft Entra~ID. Nach erfolgreicher Anmeldung erhält Houston ein Token, das neben der Identität des Benutzers zwei für dieses Projekt wesentliche Angaben enthält:
+Die Authentifizierung erfolgt über Microsoft Entra~ID. Das Token enthält zwei für dieses Projekt wesentliche Angaben:
 
 \begin{itemize}
     \item die \textbf{Efecte-Organisations-ID} des Benutzers, über die seine Zugehörigkeit zu einem Kunden bestimmt wird,
     \item den \textbf{Efecte-Firmennamen}, der über den Claim \texttt{efecte:company\_name} bereitgestellt wird.
 \end{itemize}
 
-Beide Werte lagen bereits vor Projektbeginn im Token vor und mussten nicht neu eingeführt werden. Dass der Firmenname verfügbar ist, wurde erst im Rahmen der Recherche zum Kundenordner-Lookup als relevant erkannt — er ermöglicht es, den Ordnernamen ohne zusätzlichen Efecte-Aufruf zu bestimmen (siehe Abschnitt~\ref{sec:lookup-decision}).
+Beide Werte lagen bereits vor Projektbeginn im Token vor. Dass der Firmenname verfügbar ist, wurde erst bei der Recherche zum Kundenordner-Lookup erkannt — er ermöglicht die Bestimmung des Ordnernamens ohne zusätzlichen Efecte-Aufruf (siehe Abschnitt~\ref{sec:lookup-decision}).
 
 \subsection{Anwendungsrolle Documents.Read}
 
-Für den Zugriff auf den Dokumentenbereich wurde in Entra~ID die Anwendungsrolle \texttt{Documents.Read} angelegt. In der Feature-Analyse war ausdrücklich geklärt worden, dass keine feingranulareren Berechtigungen unterhalb der Menüpunkt-Ebene erforderlich sind: Ein Benutzer sieht entweder alle Dokumente seiner Organisation oder gar keine. Eine Differenzierung nach Dokumententyp — etwa ein Zugriff auf Monitoring-Reports ohne Zugriff auf Vertragsunterlagen — wurde bewusst nicht vorgesehen.
+Für den Zugriff auf den Dokumentenbereich wurde in Entra~ID die Anwendungsrolle \texttt{Documents.Read} angelegt. Eine Differenzierung nach Dokumententyp ist nicht vorgesehen: Ein Benutzer sieht entweder alle Dokumente seiner Organisation oder gar keine.
 
-Die Rolle wirkt an zwei Stellen. Erstens steuert sie die Sichtbarkeit des Navigationspunkts: Ohne die Rolle erscheint „Dokumente" nicht im Menü. Zweitens schützt sie die Seite selbst gegen den direkten Aufruf über die URL. Die zweite Prüfung ist die eigentlich sicherheitsrelevante; das Ausblenden des Menüpunkts ist reine Benutzerführung und darf nicht als Schutzmaßnahme betrachtet werden.
+Die Rolle wirkt an zwei Stellen: Sie steuert die Sichtbarkeit des Navigationspunkts und schützt die Seite gegen direkten URL-Aufruf. Die zweite Prüfung ist sicherheitsrelevant; das Ausblenden des Menüpunkts ist reine Benutzerführung.
 
 \subsection{403 statt 404}
 
-Ein diskutierter Punkt war die Frage, welche Antwort ein Benutzer ohne Berechtigung beim direkten Aufruf von \texttt{/documents} erhalten soll. Die ursprüngliche Fassung der Anforderung sah eine 404-Antwort vor. Die Überlegung dahinter ist verbreitet: Eine 404-Antwort verrät nicht, dass die Ressource überhaupt existiert, und verhindert damit Rückschlüsse auf vorhandene Funktionen.
+Ein diskutierter Punkt war die Antwort bei unberechtigtem Zugriff auf \texttt{/documents}. Die ursprüngliche Anforderung sah 404 vor, um die Existenz der Ressource zu verbergen.
 
-Im Verlauf der Umsetzung wurde die Anforderung auf eine 403-Antwort geändert. Ausschlaggebend waren zwei Argumente. Zum einen ist die Existenz des Dokumentenbereichs kein Geheimnis — es handelt sich um eine allgemein bekannte Funktion des Kundenportals, nicht um eine verborgene Ressource. Der Informationsgewinn eines Angreifers ist damit gleich null. Zum anderen erschwert eine 404-Antwort die Fehlersuche erheblich: Ein Benutzer, dem versehentlich die Rolle fehlt, erhält dieselbe Antwort wie bei einem Tippfehler in der Adresse. Genau dieser Fall trat später im Abnahmetest tatsächlich ein (siehe Abschnitt~\ref{sec:acceptance-testing}) und bestätigte die Entscheidung.
+Die Anforderung wurde auf 403 geändert. Die Existenz des Dokumentenbereichs ist kein Geheimnis. Zudem erschwert 404 die Fehlersuche: Ein Benutzer ohne Rolle erhält dieselbe Antwort wie bei einem Tippfehler. Dieser Fall trat später im Abnahmetest ein (siehe Abschnitt~\ref{sec:acceptance-testing}) und bestätigte die Entscheidung.
 
-Der Trade-off lautet also: minimaler, hier praktisch nicht vorhandener Informationsgewinn für einen Angreifer gegen deutlich bessere Diagnostizierbarkeit im Betrieb. Die Entscheidung fiel zugunsten der Diagnostizierbarkeit.
+Der Trade-off: minimaler Informationsgewinn für einen Angreifer gegen deutlich bessere Diagnostizierbarkeit.
 
 \subsection{Mandantentrennung}
 
-Die zweite Stufe stellt sicher, dass ein berechtigter Benutzer ausschließlich die Dokumente seiner eigenen Organisation sieht. Sie beruht vollständig auf dem Ablagekonzept aus Abschnitt~\ref{sec:s3-layout}: Aus der Organisations-ID im Token wird der zugehörige Kundenordner aufgelöst, und sämtliche Abfragen an den Speicher werden auf dieses Präfix eingeschränkt.
+Die zweite Stufe stellt sicher, dass ein berechtigter Benutzer ausschließlich die Dokumente seiner Organisation sieht. Aus der Organisations-ID wird der zugehörige Kundenordner aufgelöst, und alle Abfragen werden auf dieses Präfix eingeschränkt (siehe Abschnitt~\ref{sec:s3-layout}).
 
-Entscheidend ist dabei, dass die Einschränkung nicht nachträglich auf ein bereits geladenes Ergebnis angewendet wird, sondern bereits Bestandteil der Abfrage ist. Houston lädt zu keinem Zeitpunkt Dokumente fremder Kunden in den Speicher, um sie anschließend herauszufiltern. Ein Fehler in der Darstellungsschicht kann damit nicht zu einer Offenlegung führen.
+Entscheidend ist, dass die Einschränkung bereits Bestandteil der Abfrage ist — Houston lädt nie Dokumente fremder Kunden, um sie nachträglich herauszufiltern. Ein Fehler in der Darstellungsschicht kann damit nicht zu einer Offenlegung führen.
 
 Abbildung~\ref{fig:auth-sequence} stellt den vollständigen Ablauf dar.
 
@@ -45,8 +45,8 @@ Abbildung~\ref{fig:auth-sequence} stellt den vollständigen Ablauf dar.
 
 \subsection{Absicherung der Einzelzugriffe}
 
-Die Auflistung ist nicht der einzige Zugriffspfad. Auch der Download einzelner Dokumente, der ZIP-Download, die PDF-Vorschau und die Freigabelinks nehmen jeweils einen Dokumentschlüssel entgegen. Für jeden dieser Pfade gilt dieselbe Regel: Der angeforderte Schlüssel wird gegen das aufgelöste Kundenpräfix geprüft, bevor auf den Speicher zugegriffen wird.
+Auch Download, ZIP-Download, PDF-Vorschau und Freigabelinks nehmen jeweils einen Dokumentschlüssel entgegen. Für jeden Pfad wird der angeforderte Schlüssel gegen das aufgelöste Kundenpräfix geprüft, bevor auf den Speicher zugegriffen wird.
 
-Zusätzlich wird der übergebene Pfad daraufhin untersucht, ob er Bestandteile enthält, mit denen sich der Kundenordner verlassen ließe. Ohne diese Prüfung könnte ein Benutzer durch Manipulation des Parameters auf fremde Ordner zugreifen, obwohl das Präfix zunächst korrekt gesetzt war. Diese Anforderung (NFA-6) wurde im Approval-Termin ausdrücklich in die Akzeptanzkriterien aufgenommen.
+Zusätzlich wird der Pfad auf Bestandteile untersucht, mit denen sich der Kundenordner verlassen ließe (NFA-6). Ohne diese Prüfung könnte ein Benutzer durch Manipulation des Parameters auf fremde Ordner zugreifen.
 
-Die Freigabelinks stellen dabei keine Ausnahme dar: Sie enthalten keine Anmeldeinformationen und gewähren keinen eigenständigen Zugriff. Ein Empfänger, der nicht über die Rolle und die passende Organisationszugehörigkeit verfügt, erhält beim Aufruf dieselbe 403-Antwort wie bei jedem anderen Zugriffsversuch. Der Link dient ausschließlich dazu, innerhalb des berechtigten Personenkreises auf ein bestimmtes Dokument zu verweisen.
+Freigabelinks stellen keine Ausnahme dar: Sie enthalten keine Anmeldeinformationen und gewähren keinen eigenständigen Zugriff. Ein Empfänger ohne Rolle und passende Organisationszugehörigkeit erhält dieselbe 403-Antwort. Der Link verweist lediglich innerhalb des berechtigten Personenkreises auf ein Dokument.

chapters/conception/document-types.tex

@@ -3,7 +3,7 @@
 
 \subsection{Der Typenkatalog}
 
-Die sieben Dokumententypen wurden fachlich in der Feature-Beschreibung festgelegt und im Projektverlauf nicht verändert. Sie bilden die Kategorien ab, in denen WorkSimple gegenüber Kunden regelmäßig Unterlagen bereitstellt. Tabelle~\ref{tab:document-types} zeigt den Katalog mit dem jeweiligen Ordnernamen im Speicher.
+Die sieben Dokumententypen wurden in der Feature-Beschreibung festgelegt und im Projektverlauf nicht verändert. Tabelle~\ref{tab:document-types} zeigt den Katalog mit dem jeweiligen Ordnernamen im Speicher.
 
 \begin{table}[H]
 \centering
@@ -26,24 +26,24 @@ Die sieben Dokumententypen wurden fachlich in der Feature-Beschreibung festgeleg
 
 \subsection{Feste Kodierung statt Konfiguration}
 
-Im Approval-Termin stellte \emph{Timo Walter} die Frage, ob die Kategorien konfigurierbar sein sollen und ob im Betrieb weitere Typen hinzukommen können. Die Entscheidung fiel auf eine feste Kodierung in Houston. Dafür sprechen mehrere Überlegungen.
+Im Approval-Termin stellte \emph{Timo Walter} die Frage, ob die Kategorien konfigurierbar sein sollen. Die Entscheidung fiel auf eine feste Kodierung in Houston.
 
-Der Typenkatalog ist fachlich stabil. Er leitet sich aus den Leistungen ab, die WorkSimple erbringt, und ändert sich allenfalls im Rhythmus von Jahren. Eine Konfigurierbarkeit würde für diesen Änderungsrhythmus eine Verwaltungsoberfläche, ein Speicherformat und eine Migrationsstrategie erfordern — ein Aufwand, der in keinem Verhältnis zum Nutzen steht.
+Der Typenkatalog ist fachlich stabil und ändert sich allenfalls im Rhythmus von Jahren. Konfigurierbarkeit würde Verwaltungsoberfläche, Speicherformat und Migrationsstrategie erfordern — ein unverhältnismäßiger Aufwand.
 
-Hinzu kommt, dass die Typen nicht nur als Beschriftung auftreten. Jeder Typ benötigt ein Icon und eine Übersetzung, und beide müssten bei einem frei konfigurierbaren Katalog ebenfalls hinterlegbar sein. Ein neuer Typ ohne Icon fiele in der Oberfläche unangenehm auf. Die feste Kodierung stellt sicher, dass Ordnername, Anzeigetext und Icon stets gemeinsam gepflegt werden.
+Hinzu kommt, dass jeder Typ ein Icon und eine Übersetzung benötigt, die bei einem frei konfigurierbaren Katalog ebenfalls hinterlegbar sein müssten. Die feste Kodierung stellt sicher, dass Ordnername, Anzeigetext und Icon gemeinsam gepflegt werden.
 
-Der Preis dieser Entscheidung ist, dass das Hinzufügen eines Typs eine Codeänderung und ein Release erfordert. Angesichts der erwarteten Änderungshäufigkeit ist das vertretbar.
+Der Preis: Das Hinzufügen eines Typs erfordert eine Codeänderung und ein Release. Angesichts der erwarteten Änderungshäufigkeit ist das vertretbar.
 
 \subsection{Verhalten bei unbekannten Ordnern}
 
-Aus der festen Kodierung ergibt sich unmittelbar die Frage, wie mit Unterordnern umzugehen ist, die nicht im Katalog stehen. Ein Kundenbetreuer könnte in Filestash versehentlich einen Ordner \texttt{Sonstiges} anlegen oder sich beim Namen vertippen.
+Aus der festen Kodierung ergibt sich die Frage, wie mit Unterordnern umzugehen ist, die nicht im Katalog stehen — etwa einem Ordner \texttt{Sonstiges} in Filestash.
 
-Das Konzept sieht vor, dass Dokumente in solchen Ordnern nicht verschwinden. Sie werden angezeigt und erhalten ein neutrales Standard-Icon; lediglich die Typzuordnung entfällt. Die Alternative — solche Dokumente auszublenden — wurde verworfen, weil sie ein stilles Fehlverhalten erzeugen würde: Ein hochgeladenes Dokument wäre für den Kunden unsichtbar, ohne dass dies für den Betreuer erkennbar wäre.
+Dokumente in solchen Ordnern werden angezeigt und erhalten ein neutrales Standard-Icon; lediglich die Typzuordnung entfällt. Ausblenden wurde verworfen, weil es stilles Fehlverhalten erzeugen würde: Ein Dokument wäre unsichtbar, ohne dass der Betreuer dies bemerkt.
 
-Zu unterscheiden ist dieser Fall vom Umgang mit unbekannten Ordnern auf der \emph{obersten} Ebene. Dort führt ein fehlendes Marker-Metadatum zum vollständigen Ausschluss (siehe Abschnitt~\ref{sec:s3-layout}). Der Unterschied ist beabsichtigt: Auf oberster Ebene entscheidet die Struktur über die Mandantentrennung, hier gilt im Zweifel Ausschluss. Innerhalb eines Kundenordners ist die Zugehörigkeit dagegen bereits geklärt, und ein unbekannter Unterordner ist lediglich ein Darstellungsproblem.
+Zu unterscheiden ist dieser Fall vom Umgang mit unbekannten Ordnern auf der \emph{obersten} Ebene, wo ein fehlendes Marker-Metadatum zum vollständigen Ausschluss führt (siehe Abschnitt~\ref{sec:s3-layout}). Der Unterschied ist beabsichtigt: Auf oberster Ebene entscheidet die Struktur über die Mandantentrennung; innerhalb eines Kundenordners ist die Zugehörigkeit bereits geklärt.
 
 \subsection{Übersetzung der Anzeigenamen}
 
-Die Ordnernamen im Speicher dienen zwei verschiedenen Zielgruppen. Für die Kundenbetreuer, die in Filestash arbeiten, müssen sie lesbar und eindeutig sein. Für den Kunden in Houston sollen sie sich in die Oberfläche einfügen.
+Die Ordnernamen im Speicher dienen zwei Zielgruppen: Für die Kundenbetreuer in Filestash müssen sie lesbar und eindeutig sein, für den Kunden in Houston sollen sie sich in die Oberfläche einfügen.
 
-Aus diesem Grund wird der Ordnername nicht unverändert angezeigt, sondern über eine Ressourcendatei auf einen Anzeigetext abgebildet. Dieses Vorgehen entspricht dem in Houston bereits etablierten Muster zur Lokalisierung und erlaubt es, den Anzeigetext zu ändern, ohne die Struktur im Speicher anzufassen — eine Umbenennung dort würde bedeuten, sämtliche betroffenen Objekte umzukopieren.
+Der Ordnername wird nicht unverändert angezeigt, sondern über eine Ressourcendatei auf einen Anzeigetext abgebildet. Dies entspricht dem in Houston etablierten Lokalisierungsmuster und erlaubt Änderungen am Anzeigetext, ohne die Speicherstruktur anzufassen — eine Umbenennung dort würde das Umkopieren sämtlicher betroffenen Objekte erfordern.

chapters/conception/lookup-decision.tex

@@ -3,31 +3,31 @@
 
 \subsection{Die zugrunde liegende Idee}
 
-Alle in Abschnitt~\ref{sec:lookup-research} betrachteten Ansätze versuchen, die Zuordnung zwischen Organisations-ID und Ordnername \emph{zusätzlich} irgendwo zu hinterlegen — in einem Cache, in einem Token, in Efecte oder in einer Zuordnungsdatei. Jeder dieser Ansätze führt damit eine zweite Datenhaltung ein, die mit der ersten konsistent gehalten werden muss.
+Alle in Abschnitt~\ref{sec:lookup-research} betrachteten Ansätze hinterlegen die Zuordnung \emph{zusätzlich} irgendwo — in Cache, Token, Efecte oder einer Zuordnungsdatei. Jeder führt eine zweite, konsistent zu haltende Datenhaltung ein.
 
-Die schließlich gewählte Lösung dreht die Fragestellung um. Statt die Zuordnung nachzuschlagen, wird sie \emph{berechenbar} gemacht: Wenn der Ordnername sich deterministisch aus dem Firmennamen ableiten lässt und dieser Firmenname bereits im Anmeldetoken steht, kann Houston den erwarteten Ordnernamen ohne jeden Nachschlagevorgang bestimmen. Aus der Suche wird ein direkter Zugriff.
+Die gewählte Lösung dreht die Fragestellung um: Lässt sich der Ordnername deterministisch aus dem Firmennamen ableiten und steht dieser im Token, kann Houston den Ordnernamen ohne Nachschlagevorgang bestimmen. Aus der Suche wird ein direkter Zugriff.
 
-Voraussetzung dafür ist, dass die Ordner im Speicher tatsächlich so heißen, wie Houston es erwartet. Genau hier setzt die eigentliche Entscheidung an: \textbf{Houston wird zur führenden Instanz für die Namensgebung der Kundenordner.} Weicht ein Ordner vom erwarteten Namen ab, wird nicht der Erwartungswert angepasst, sondern der Ordner umbenannt.
+Voraussetzung ist, dass die Ordner tatsächlich so heißen, wie Houston es erwartet. \textbf{Houston wird zur führenden Instanz für die Namensgebung der Kundenordner.} Weicht ein Ordner ab, wird er umbenannt.
 
-Diese Festlegung ist deshalb vertretbar, weil Houston die Ordnerstruktur ohnehin selbst anlegt (FA-13). Wenn die Anwendung neue Kundenordner erzeugt, ist es folgerichtig, dass sie auch deren Benennung verantwortet. Die Kundenbetreuer verlieren dadurch nichts: Der Ordner heißt weiterhin nach dem Kunden, nur eben in einer normalisierten Form.
+Diese Festlegung ist vertretbar, weil Houston die Ordnerstruktur ohnehin selbst anlegt (FA-13). Die Kundenbetreuer verlieren nichts: Der Ordner heißt weiterhin nach dem Kunden, nur normalisiert.
 
 \subsection{Ableitung des Ordnernamens}
 
-Der Firmenname aus dem Token kann nicht unverändert als Ordnername verwendet werden. Er kann Zeichen enthalten, die im Schlüssel problematisch sind, führende oder abschließende Leerzeichen aufweisen oder beliebig lang sein. Er wird deshalb durch eine Normalisierungsfunktion geführt, die im weiteren Verlauf als \emph{Slug} bezeichnet wird.
+Der Firmenname aus dem Token kann nicht unverändert als Ordnername dienen — er kann problematische Zeichen, führende Leerzeichen oder beliebige Länge aufweisen. Er wird durch eine Normalisierungsfunktion geführt, im Folgenden \emph{Slug} genannt.
 
-Die Normalisierung folgt zwei Leitgedanken. Sie muss \textbf{deterministisch} sein — derselbe Firmenname muss stets denselben Ordnernamen ergeben, sonst funktioniert der direkte Zugriff nicht. Und sie muss das Ergebnis \textbf{lesbar} halten, weil der Ordner in Filestash von Menschen bedient wird. Aus dem zweiten Punkt folgt eine bewusste Abweichung von der üblichen Praxis: Umlaute werden \emph{nicht} ersetzt. Eine Firma „Müller GmbH" erhält den Ordner \texttt{Müller GmbH} und nicht \texttt{Mueller GmbH}, weil der Betreuer sie andernfalls in der alphabetischen Liste an unerwarteter Stelle suchen müsste. Die Zulässigkeit solcher Zeichen in Objektschlüsseln wurde anhand der Herstellerdokumentation geprüft \autocite{aws-s3-naming, ibm-s3-naming}; die Frage war auch Gegenstand des Code-Reviews.
+Die Normalisierung muss \textbf{deterministisch} sein — derselbe Firmenname muss stets denselben Ordnernamen ergeben — und das Ergebnis \textbf{lesbar} halten, weil der Ordner in Filestash von Menschen bedient wird. Umlaute werden bewusst \emph{nicht} ersetzt: „Müller GmbH" erhält den Ordner \texttt{Müller GmbH}, nicht \texttt{Mueller GmbH}, weil der Betreuer die Firma sonst in der alphabetischen Liste an unerwarteter Stelle suchen müsste. Die Zulässigkeit solcher Zeichen in Objektschlüsseln wurde anhand der Herstellerdokumentation geprüft \autocite{aws-s3-naming, ibm-s3-naming}.
 
 \subsection{Umgang mit Namenskollisionen}
 
-Firmennamen sind nicht garantiert eindeutig. Efecte lässt zwei Organisationen mit identischem Namen grundsätzlich zu, und sobald der Ordnername aus dem Firmennamen abgeleitet wird, treffen beide auf denselben Zielnamen. Da eine Verwechslung hier unmittelbar bedeuten würde, dass ein Kunde die Dokumente eines anderen sieht, muss dieser Fall abgedeckt sein.
+Firmennamen sind nicht garantiert eindeutig. Efecte lässt zwei Organisationen mit identischem Namen zu, und beide würden auf denselben Ordnernamen treffen. Da eine Verwechslung bedeuten würde, dass ein Kunde fremde Dokumente sieht, muss der Fall abgedeckt sein.
 
-Das Konzept löst ihn nach dem Prinzip „wer zuerst kommt, mahlt zuerst": Die erste Organisation, die den Namen beansprucht, erhält ihn. Jede weitere erhält einen Ordner, dem die Organisations-ID in Klammern angehängt wird, also etwa \texttt{Beispielkunde GmbH (77)}. Dieser Name ist eindeutig, bleibt lesbar und sortiert weiterhin unmittelbar neben dem gleichnamigen Ordner.
+Die erste Organisation, die den Namen beansprucht, erhält ihn. Jede weitere erhält einen Ordner mit angehängter Organisations-ID, etwa \texttt{Beispielkunde GmbH (77)} — eindeutig, lesbar und alphabetisch neben dem gleichnamigen Ordner.
 
-Maßgeblich ist dabei eine Sicherheitsregel: Ein Zielname wird nur dann beansprucht, wenn er entweder frei ist oder ausweislich seines Markers bereits der eigenen Organisation gehört. Ein fremder Kundenordner wird unter keinen Umständen überschrieben oder umbenannt. Die Zuordnung entscheidet also immer das Metadatum, niemals der Name — der Name ist nur die Optimierung.
+Sicherheitsregel: Ein Zielname wird nur beansprucht, wenn er frei ist oder ausweislich seines Markers der eigenen Organisation gehört. Ein fremder Kundenordner wird unter keinen Umständen überschrieben. Die Zuordnung entscheidet immer das Metadatum, nie der Name.
 
 \subsection{Der resultierende Ablauf}
 
-Aus diesen Überlegungen ergibt sich ein dreistufiges Verfahren, das in Abbildung~\ref{fig:lookup-flow} dargestellt ist.
+Aus diesen Überlegungen ergibt sich ein dreistufiges Verfahren (Abbildung~\ref{fig:lookup-flow}).
 
 \begin{figure}[H]
     \centering
@@ -37,21 +37,21 @@ Aus diesen Überlegungen ergibt sich ein dreistufiges Verfahren, das in Abbildun
 \end{figure}
 
 \begin{enumerate}
-    \item \textbf{Direktzugriff.} Houston bildet den erwarteten Ordnernamen aus dem Firmennamen und ruft die Metadaten des zugehörigen Markers ab. Existiert er und trägt er die richtige Organisations-ID, ist die Auflösung mit einem einzigen Aufruf abgeschlossen. Dies ist der Regelfall.
+    \item \textbf{Direktzugriff.} Houston bildet den erwarteten Ordnernamen aus dem Firmennamen und ruft die Metadaten des Markers ab. Stimmt die Organisations-ID, ist die Auflösung mit einem Aufruf abgeschlossen. Dies ist der Regelfall.
-    \item \textbf{Kollisionsprüfung.} Schlägt der erste Schritt fehl — weil der Marker fehlt oder eine fremde Organisations-ID trägt — wird derselbe Zugriff mit dem um die Organisations-ID ergänzten Namen wiederholt. Damit ist der Kollisionsfall mit zwei Aufrufen abgedeckt.
+    \item \textbf{Kollisionsprüfung.} Fehlt der Marker oder trägt er eine fremde ID, wird der Zugriff mit dem um die Organisations-ID ergänzten Namen wiederholt — zwei Aufrufe für den Kollisionsfall.
-    \item \textbf{Rückfallebene.} Erst wenn auch das nicht greift, kommt das ursprüngliche, lineare Verfahren zum Einsatz. Wird dabei ein Ordner mit passender Organisations-ID gefunden, trägt er offenbar einen abweichenden Namen und wird auf den kanonischen Namen umbenannt. Wird kein Ordner gefunden, existiert der Kunde im Speicher noch nicht und die vollständige Struktur wird angelegt.
+    \item \textbf{Rückfallebene.} Erst dann kommt das lineare Verfahren zum Einsatz. Wird ein Ordner mit passender ID gefunden, wird er auf den kanonischen Namen umbenannt. Wird keiner gefunden, wird die vollständige Struktur angelegt.
 \end{enumerate}
 
 \subsection{Selbstheilung}
 
-Die entscheidende Eigenschaft dieses Verfahrens liegt im dritten Schritt. Die Rückfallebene beseitigt nicht nur den unmittelbaren Fehlschlag, sondern auch dessen Ursache: Nach der Umbenennung trägt der Ordner den erwarteten Namen, und der nächste Zugriff derselben Organisation wird wieder über den Direktzugriff abgewickelt.
+Die entscheidende Eigenschaft liegt im dritten Schritt: Die Rückfallebene beseitigt nicht nur den Fehlschlag, sondern auch dessen Ursache. Nach der Umbenennung trägt der Ordner den erwarteten Namen, und der nächste Zugriff läuft direkt.
 
-Der teure Pfad wird damit pro Kunde höchstens einmal durchlaufen. Bestehende Ordner, die vor Einführung des Verfahrens angelegt wurden und beliebige Namen tragen, migrieren sich beim ersten Zugriff des jeweiligen Kunden von selbst. Eine gesonderte Migration ist nicht erforderlich.
+Der teure Pfad wird pro Kunde höchstens einmal durchlaufen. Bestehende Ordner migrieren sich beim ersten Zugriff von selbst — eine gesonderte Migration entfällt.
 
-Ebenso wenig erfordert das Verfahren eine zusätzliche Datenhaltung. Es gibt keinen Cache, der invalidiert werden müsste, kein Feld in einem Fremdsystem und keine Zuordnungsdatei. Der Zustand liegt vollständig im Speicher selbst, und die Anwendung ist zu jedem Zeitpunkt in der Lage, aus einem beliebigen Ausgangszustand den Sollzustand herzustellen.
+Das Verfahren erfordert keine zusätzliche Datenhaltung: keinen Cache, kein Feld in einem Fremdsystem, keine Zuordnungsdatei. Der Zustand liegt vollständig im Speicher, und die Anwendung kann aus jedem Ausgangszustand den Sollzustand herstellen.
 
 \subsection{Bewusst offen gelassener Bereich}
 
-Das Verfahren hat einen Preis, der bei der Entscheidung bekannt war: Die Rückfallebene ist nicht mehr nur lesend. Sie benennt Ordner um und legt sie an — und das im Rahmen einer gewöhnlichen Seitenanfrage. Da Houston in mehreren Instanzen betrieben wird, können zwei solche Anfragen gleichzeitig auf denselben Ordner treffen.
+Die Rückfallebene ist nicht nur lesend: Sie benennt Ordner um und legt sie an — im Rahmen einer gewöhnlichen Seitenanfrage. Da Houston in mehreren Instanzen läuft, können zwei Anfragen gleichzeitig denselben Ordner betreffen.
 
-Dieser Umstand wurde während der Umsetzung erkannt, in seinen Auswirkungen analysiert und als eigenes Backlog Item vom laufenden Pull Request abgegrenzt. Die Entscheidung, die Abgrenzung so vorzunehmen, wurde mit dem Team abgestimmt. Abschnitt~\ref{sec:race-conditions} behandelt die konkreten Fehlerszenarien und die erwogenen Gegenmaßnahmen im Detail.
+Dieser Umstand wurde analysiert und als eigenes Backlog Item vom laufenden Pull Request abgegrenzt. Abschnitt~\ref{sec:race-conditions} behandelt die Szenarien und erwogenen Gegenmaßnahmen.

chapters/conception/lookup-research.tex

@@ -3,52 +3,46 @@
 
 \subsection{Entstehung}
 
-Der Document Explorer war zum Zeitpunkt seines Merges am 31.~Juli 2026 funktionsfähig, enthielt aber eine Schwäche, die bereits im Code-Review angesprochen worden war. Um den Kundenordner zu einer Organisations-ID zu finden, listete Houston sämtliche Ordner auf der obersten Ebene des Buckets auf, rief für jeden davon die Metadaten ab und verglich die hinterlegte \texttt{efecte-org-id} mit der des angemeldeten Benutzers.
+Der Document Explorer war zum Zeitpunkt seines Merges am 31.~Juli 2026 funktionsfähig, enthielt aber eine im Code-Review angesprochene Schwäche. Um den Kundenordner zu einer Organisations-ID zu finden, listete Houston sämtliche Ordner auf oberster Ebene auf, rief für jeden die Metadaten ab und verglich die \texttt{efecte-org-id} mit der des Benutzers.
 
-Die Ursache liegt in der bereits beschriebenen Eigenschaft von S3: Objekte lassen sich nicht anhand ihrer benutzerdefinierten Metadaten suchen. Die Operation \texttt{ListObjectsV2} liefert Schlüssel, Größe und Änderungszeitpunkt, aber keine benutzerdefinierten Metadaten \autocite{aws-listobjectsv2}. Um an das Marker-Metadatum zu gelangen, ist für jeden Kandidaten ein eigener Aufruf nötig.
+Die Ursache: S3 bietet keine Suche nach benutzerdefinierten Metadaten. \texttt{ListObjectsV2} liefert Schlüssel, Größe und Änderungszeitpunkt, aber keine benutzerdefinierten Metadaten \autocite{aws-listobjectsv2}. Für jeden Kandidaten ist ein eigener Aufruf nötig.
 
-Damit wächst der Aufwand für die Auflösung des Kundenordners linear mit der Anzahl der Kunden — und zwar bei \emph{jedem} Seitenaufruf jedes Benutzers. Bei einer zweistelligen Kundenzahl fällt das kaum auf; bei einigen hundert Kunden bedeutet es einige hundert Netzwerkaufrufe, bevor überhaupt das erste Dokument geladen wird. Das Problem ist also nicht akut, aber strukturell: Es verschlechtert sich mit dem Erfolg des Produkts.
+Der Aufwand wächst linear mit der Kundenzahl — bei \emph{jedem} Seitenaufruf. Bei einigen hundert Kunden bedeutet das einige hundert Netzwerkaufrufe, bevor das erste Dokument geladen wird. Das Problem ist nicht akut, aber strukturell.
 
-Aus dieser Erkenntnis entstand am 28.~Juli ein eigenes Backlog Item. Bemerkenswert ist, dass es bewusst nicht als Umsetzungs-, sondern als \emph{Recherche}-Item angelegt wurde. Das Akzeptanzkriterium lautete nicht „das Problem ist behoben", sondern „es ist sich für einen Lösungsansatz entschieden worden". Diese Zuschnitt-Entscheidung trennt die Frage, welche Lösung die richtige ist, von der Frage, wie sie umzusetzen ist — und macht den Rechercheaufwand als eigenständige Leistung sichtbar, statt ihn in einer Implementierungsaufgabe zu verstecken.
+Am 28.~Juli entstand daraus ein eigenes Backlog Item, bewusst als \emph{Recherche}-Item. Das Akzeptanzkriterium lautete nicht „das Problem ist behoben", sondern „es ist sich für einen Lösungsansatz entschieden worden". So wird der Rechercheaufwand als eigenständige Leistung sichtbar.
 
 \subsection{Untersuchte Lösungsansätze}
 
-Im Zuge der Recherche wurden sechs Ansätze betrachtet und mit \emph{Timo Walter} sowie den Ansprechpartnern für die Speicherinfrastruktur diskutiert. Tabelle~\ref{tab:lookup-tradeoffs} im Anhang fasst die Bewertung zusammen; im Folgenden werden die Ansätze und ihre jeweiligen Schwächen erläutert.
+Sechs Ansätze wurden betrachtet und mit \emph{Timo Walter} sowie den Ansprechpartnern für die Speicherinfrastruktur diskutiert. Tabelle~\ref{tab:lookup-tradeoffs} im Anhang fasst die Bewertung zusammen.
 
 \subsubsection{In-Memory-Cache}
 
-Der naheliegendste Ansatz ist, das Ergebnis der Auflösung im Arbeitsspeicher der Anwendung zwischenzuspeichern. Der erste Aufruf bleibt teuer, alle folgenden sind kostenlos.
+Der naheliegendste Ansatz: das Auflösungsergebnis im Arbeitsspeicher zwischenspeichern. Der erste Aufruf bleibt teuer, alle folgenden sind kostenlos.
 
-Der Ansatz behebt das Problem jedoch nur oberflächlich. Houston läuft in mehr als einer Instanz, sodass jede Instanz ihren eigenen Cache aufbauen müsste. Nach jedem Neustart oder jeder Bereitstellung ist der Cache leer, und es entsteht ein Ansturm teurer Auflösungen. Vor allem aber bleibt der zugrunde liegende lineare Aufwand unverändert bestehen — er wird lediglich seltener bezahlt. Ein Cache ist eine Optimierung, keine Lösung.
+Houston läuft jedoch in mehreren Instanzen, sodass jede ihren Cache aufbauen müsste. Nach jedem Neustart ist der Cache leer, und es entsteht ein Ansturm teurer Auflösungen. Der lineare Aufwand bleibt unverändert — er wird lediglich seltener bezahlt.
 
 \subsubsection{Speicherung im Anmeldetoken}
 
-Alternativ ließe sich der Ordnername bei der Anmeldung ermitteln und als zusätzlicher Claim im Token ablegen. Gegenüber dem Cache verschiebt das den Aufwand von jedem Seitenaufruf auf jede Anmeldung.
+Der Ordnername könnte bei der Anmeldung ermittelt und als Claim im Token abgelegt werden. Der lineare Aufwand bliebe erhalten. Hinzu kommt: Ein Token ist über seine Laufzeit unveränderlich. Wird der Ordner umbenannt, zeigt der Claim auf einen nicht mehr existierenden Ordner, bis das Token erneuert wird.
-
-Auch hier bleibt der lineare Aufwand erhalten. Hinzu kommt ein Konsistenzproblem: Ein Token ist über seine Laufzeit unveränderlich. Wird der Ordner im Speicher umbenannt, während ein Benutzer angemeldet ist, zeigt der Claim auf einen nicht mehr existierenden Ordner, bis das Token erneuert wird.
 
 \subsubsection{Speicherung als Feld in Efecte}
 
-Der Ordnername könnte auch als zusätzliches Feld an der Organisation in Efecte gepflegt werden. Houston würde ihn dann gemeinsam mit den übrigen Organisationsdaten laden.
+Der Ordnername könnte als Feld an der Organisation in Efecte gepflegt werden. Das löst das Problem technisch, führt aber eine Abhängigkeit ein: Die Zuordnung läge an zwei Stellen — im Efecte-Feld und im Marker-Metadatum — die auseinanderlaufen können. Zudem müsste das Feld für jeden Bestandskunden nachgepflegt werden.
-
-Dieser Ansatz löst das Problem technisch, führt aber eine neue Abhängigkeit ein und verlagert die Pflege in ein weiteres System. Die Zuordnung zwischen Kunde und Ordner läge damit an zwei Stellen — im Efecte-Feld und im Marker-Metadatum — die auseinanderlaufen können. Zudem müsste das Feld für jeden Bestandskunden nachgepflegt werden.
 
 \subsubsection{S3 Select}
 
-Die Operation \texttt{SelectObjectContent} erlaubt es, den \emph{Inhalt} eines Objekts serverseitig per SQL-ähnlicher Abfrage zu filtern \autocite{aws-s3-select}. Denkbar wäre gewesen, eine Zuordnungstabelle als Datei im Bucket abzulegen und den passenden Eintrag serverseitig herauszufiltern.
+\texttt{SelectObjectContent} filtert den \emph{Inhalt} eines Objekts serverseitig per SQL-ähnlicher Abfrage \autocite{aws-s3-select}. Denkbar wäre eine Zuordnungstabelle als Datei im Bucket, aus der der passende Eintrag gefiltert wird.
 
-Die Freischaltung wurde beantragt und am 7.~August durch den Betreiber bestätigt (siehe Abschnitt~\ref{sec:infrastructure}). Bei genauerer Betrachtung erwies sich der Ansatz jedoch als unpassend: S3 Select filtert Inhalte einzelner Objekte, nicht Metadaten mehrerer Objekte. Eine Zuordnungsdatei wäre eine zusätzliche, manuell oder programmatisch zu pflegende Struktur — mit demselben Konsistenzproblem wie beim Efecte-Feld, nur ohne dessen Werkzeugunterstützung.
+Die Freischaltung wurde beantragt und am 7.~August bestätigt (siehe Abschnitt~\ref{sec:infrastructure}). S3 Select filtert jedoch Inhalte einzelner Objekte, nicht Metadaten mehrerer Objekte. Eine Zuordnungsdatei wäre eine zusätzlich zu pflegende Struktur mit demselben Konsistenzproblem wie beim Efecte-Feld, nur ohne dessen Werkzeugunterstützung.
 
 \subsubsection{StorageGRID Search Integration}
 
-Der Search Integration Service spiegelt Objektmetadaten in einen Elasticsearch-Index und ermöglicht damit genau das, was S3 selbst nicht bietet: eine echte Suche über Metadaten \autocite{storagegrid-search-integration}. Fachlich wäre dies die sauberste Lösung gewesen, da sie das Problem an der Wurzel behebt, ohne eine zweite Datenhaltung einzuführen.
+Der Search Integration Service spiegelt Objektmetadaten in einen Elasticsearch-Index und ermöglicht eine echte Metadatensuche \autocite{storagegrid-search-integration}. Fachlich die sauberste Lösung, da sie das Problem an der Wurzel behebt, ohne eine zweite Datenhaltung einzuführen. Die Anfrage ergab am 17.~August, dass die Funktion derzeit nicht angeboten wird; der Ansatz wurde in den Ausblick übernommen (siehe Abschnitt~\ref{sec:outlook}).
-
-Die Anfrage über den Betreiber ergab am 17.~August, dass die Funktion derzeit nicht angeboten wird. Damit schied der Ansatz aus. Er wurde in den Ausblick übernommen (siehe Abschnitt~\ref{sec:outlook}).
 
 \subsubsection{Organisations-ID im Ordnernamen}
 
-Der technisch einfachste Ansatz wäre gewesen, die Organisations-ID zum Bestandteil des Ordnernamens zu machen — etwa als Präfix \texttt{42\_Beispielkunde GmbH}. Der Lookup reduzierte sich dann auf eine einzige Präfixabfrage.
+Der einfachste Ansatz: die Organisations-ID zum Bestandteil des Ordnernamens machen — etwa \texttt{42\_Beispielkunde GmbH}. Der Lookup reduzierte sich auf eine Präfixabfrage.
 
-Dieser Ansatz scheiterte an einer fachlichen Anforderung. In der Abstimmung mit \emph{Ralf Schulte} wurde deutlich, dass die Kundenbetreuer die Ordner in Filestash nach Kundennamen sortiert vorfinden müssen, um damit arbeiten zu können. Ein vorangestellter Zahlenschlüssel zerstört diese Sortierung. Der Konflikt ist damit klar benannt: Houston autorisiert über die Organisations-ID, die Betreuer arbeiten über den Kundennamen, und der Speicher bietet keinen Mechanismus, zwischen beiden zu vermitteln.
+In der Abstimmung mit \emph{Ralf Schulte} wurde deutlich, dass die Kundenbetreuer die Ordner in Filestash nach Kundennamen sortiert vorfinden müssen. Ein vorangestellter Zahlenschlüssel zerstört diese Sortierung. Der Konflikt: Houston autorisiert über die Organisations-ID, die Betreuer arbeiten über den Kundennamen, und der Speicher vermittelt nicht zwischen beiden.
 
-Die entscheidende Beobachtung war jedoch, dass die Anforderung eine Sortierung nach Kundennamen verlangt — nicht zwingend, dass der Ordnername \emph{ausschließlich} aus dem Kundennamen besteht. Diese Unterscheidung eröffnete den Weg zu der in Abschnitt~\ref{sec:lookup-decision} beschriebenen Lösung.
+Die entscheidende Beobachtung war, dass die Anforderung eine Sortierung nach Kundennamen verlangt — nicht zwingend, dass der Ordnername \emph{ausschließlich} aus dem Kundennamen besteht. Diese Unterscheidung eröffnete den Weg zur in Abschnitt~\ref{sec:lookup-decision} beschriebenen Lösung.

chapters/conception/s3-layout.tex

@@ -1,17 +1,17 @@
 \section{Ablagekonzept im S3-Speicher}
 \label{sec:s3-layout}
 
-Das Ablagekonzept bildet die Grundlage für alle weiteren Entwurfsentscheidungen. Es muss zwei Aufgaben gleichzeitig erfüllen: Es muss festlegen, welche Dokumente zu welchem Kunden gehören, und es muss den fachlichen Typ eines Dokuments abbilden. Beides geschieht ausschließlich über die Struktur im Speicher, ohne eine zusätzliche Datenbank.
+Das Ablagekonzept muss zwei Aufgaben erfüllen: die Zuordnung von Dokumenten zu Kunden und die Abbildung des fachlichen Dokumententyps. Beides geschieht ausschließlich über die Struktur im Speicher, ohne eine zusätzliche Datenbank.
 
 \subsection{Präfixe statt Ordner}
 
-S3 kennt technisch keine Ordner. Jedes Objekt wird über einen Schlüssel adressiert, der als Zeichenkette in einem flachen Namensraum liegt. Die scheinbare Hierarchie entsteht erst beim Auflisten: Übergibt man der Operation \texttt{ListObjectsV2} ein Präfix und ein Trennzeichen, liefert der Dienst nur die Objekte unterhalb dieses Präfixes zurück sowie die gemeinsamen Teilpräfixe der nächsten Ebene \autocite{aws-listobjectsv2}. Ein Schlüssel wie
+S3 kennt technisch keine Ordner. Jedes Objekt wird über einen Schlüssel in einem flachen Namensraum adressiert. Die scheinbare Hierarchie entsteht beim Auflisten: \texttt{ListObjectsV2} liefert mit Präfix und Trennzeichen nur die Objekte unterhalb eines Präfixes sowie die gemeinsamen Teilpräfixe der nächsten Ebene \autocite{aws-listobjectsv2}. Ein Schlüssel wie
 
 \begin{quote}
 \texttt{Beispielkunde GmbH/Service-Protokoll/Protokoll-2026-07.pdf}
 \end{quote}
 
-wird in einem Dateibrowser wie Filestash als zweistufige Ordnerhierarchie dargestellt, ist im Speicher jedoch nur eine einzelne Zeichenkette. Diese Eigenschaft ist für das Konzept vorteilhaft, weil sie das Auflisten eines Kundenordners auf eine einzige Präfixabfrage reduziert. Sie hat aber auch eine Konsequenz, die im weiteren Verlauf noch bedeutsam wird: Ein „Ordner" existiert erst dann, wenn mindestens ein Objekt mit dem entsprechenden Präfix vorhanden ist. Ein leerer Ordner lässt sich nur simulieren, indem ein Platzhalterobjekt angelegt wird, dessen Schlüssel auf das Trennzeichen endet.
+erscheint in Filestash als zweistufige Ordnerhierarchie, ist im Speicher aber nur eine Zeichenkette. Ein „Ordner" existiert erst, wenn mindestens ein Objekt mit dem entsprechenden Präfix vorhanden ist; ein leerer Ordner lässt sich nur durch ein Platzhalterobjekt simulieren, dessen Schlüssel auf das Trennzeichen endet.
 
 Abbildung~\ref{fig:s3-layout} zeigt die resultierende Struktur.
 
@@ -24,36 +24,36 @@ Abbildung~\ref{fig:s3-layout} zeigt die resultierende Struktur.
 
 \subsection{Kundenzuordnung über ein Marker-Objekt}
 
-Auf der obersten Ebene des Buckets liegt für jeden Kunden genau ein Ordner. Um diesen Ordner einer Organisation zuzuordnen, wird an dem Platzhalterobjekt, das den Ordner repräsentiert, ein benutzerdefiniertes Metadatum \texttt{efecte-org-id} hinterlegt. Dieses Objekt wird im Folgenden als \emph{Marker} bezeichnet.
+Auf der obersten Ebene des Buckets liegt für jeden Kunden ein Ordner. Dessen Platzhalterobjekt trägt ein benutzerdefiniertes Metadatum \texttt{efecte-org-id} zur Zuordnung an eine Organisation und wird im Folgenden als \emph{Marker} bezeichnet.
 
-Der Marker erfüllt zwei Zwecke gleichzeitig. Erstens sorgt er dafür, dass der Kundenordner auch dann existiert, wenn noch kein einziges Dokument abgelegt wurde — andernfalls wäre ein frisch angelegter Kunde im Speicher unsichtbar. Zweitens trägt er die Information, welcher Organisation der Ordner gehört. Damit ist die Zuordnung an genau einer Stelle hinterlegt und muss nicht an jedem einzelnen Dokument wiederholt werden.
+Er sorgt dafür, dass der Kundenordner auch ohne Dokumente existiert, und trägt die Organisationszugehörigkeit an genau einer Stelle.
 
-Die Entscheidung, die Organisations-ID als Metadatum und nicht als Bestandteil des Ordnernamens zu führen, wurde in der Feature-Analyse getroffen (siehe Abschnitt~\ref{sec:feature-analysis}). Sie ist fachlich motiviert: Die Ordner werden von den Kundenbetreuern über Filestash gepflegt, und ein Ordnername wie \texttt{42} oder \texttt{Beispielkunde GmbH (42)} wäre dort schwer zu handhaben. Der lesbare Firmenname bleibt daher der Ordnername, die technische Zuordnung wandert in die Metadaten.
+Die Organisations-ID wird als Metadatum statt als Bestandteil des Ordnernamens geführt (siehe Abschnitt~\ref{sec:feature-analysis}). Die Ordner werden von Kundenbetreuern über Filestash gepflegt; ein Name wie \texttt{42} wäre dort schwer handhabbar. Der lesbare Firmenname bleibt daher der Ordnername, die technische Zuordnung wandert in die Metadaten.
 
-Genau diese Entscheidung erzeugt allerdings das zentrale technische Problem des Projekts, das in Abschnitt~\ref{sec:lookup-research} behandelt wird: Houston kennt aus dem Authentifizierungstoken die Organisations-ID, muss daraus aber den Ordnernamen ermitteln — und S3 bietet keine Möglichkeit, Objekte nach Metadaten zu durchsuchen.
+Genau diese Entscheidung erzeugt das zentrale technische Problem des Projekts (Abschnitt~\ref{sec:lookup-research}): Houston kennt die Organisations-ID, muss daraus den Ordnernamen ermitteln — und S3 bietet keine Suche nach Metadaten.
 
 \subsection{Typisierung über Unterordner}
 
-Innerhalb des Kundenordners liegt für jeden der sieben fachlichen Dokumententypen ein Unterordner. Der Typ eines Dokuments ergibt sich daraus, in welchem Unterordner es abgelegt ist. Dokumente, die direkt im Kundenordner liegen, gelten als untypisiert.
+Innerhalb des Kundenordners liegt für jeden der sieben Dokumententypen ein Unterordner. Der Typ ergibt sich aus dem Unterordner; direkt im Kundenordner liegende Dokumente gelten als untypisiert.
 
-Auch diese Festlegung stammt aus der Feature-Analyse. Die Alternative wäre gewesen, den Typ als Metadatum an jeder einzelnen Datei zu hinterlegen. Der Vergleich beider Ansätze fällt eindeutig aus:
+Die Alternative — den Typ als Metadatum an jeder Datei zu hinterlegen — wurde verglichen:
 
 \begin{itemize}
-    \item \textbf{Pflegeaufwand:} Ein Metadatum müsste bei jedem Upload manuell gesetzt werden. Filestash bietet hierfür keine komfortable Unterstützung. Das Ablegen in einem Ordner ist dagegen die natürliche Bedienhandlung.
+    \item \textbf{Pflegeaufwand:} Ein Metadatum müsste bei jedem Upload manuell gesetzt werden; Filestash bietet hierfür keine komfortable Unterstützung. Das Ablegen in einem Ordner ist die natürliche Bedienhandlung.
-    \item \textbf{Abfragbarkeit:} Der Typ ist als Präfixbestandteil unmittelbar aus dem Schlüssel ablesbar. Beim Auflisten fällt er ohne Zusatzkosten mit an. Ein Metadatum müsste dagegen für jedes Objekt einzeln abgerufen werden, da \texttt{ListObjectsV2} benutzerdefinierte Metadaten nicht mitliefert. Bei $n$ Dokumenten wären das $n$ zusätzliche Aufrufe.
+    \item \textbf{Abfragbarkeit:} Der Typ ist als Präfixbestandteil unmittelbar aus dem Schlüssel ablesbar. Ein Metadatum müsste dagegen für jedes Objekt einzeln abgerufen werden, da \texttt{ListObjectsV2} benutzerdefinierte Metadaten nicht mitliefert — bei $n$ Dokumenten also $n$ zusätzliche Aufrufe.
     \item \textbf{Filterung:} Eine Filterung nach Typ reduziert sich auf eine Präfixabfrage und ist damit serverseitig umsetzbar.
 \end{itemize}
 
-Dem stehen zwei Nachteile gegenüber. Zum einen kann ein Dokument nur genau einen Typ haben, da es nur an einer Stelle liegen kann; eine Mehrfachzuordnung ist ausgeschlossen. Zum anderen erfordert die Typisierung, dass die Ordner überhaupt existieren — was die automatische Anlage der Ordnerstruktur zu einer eigenen Anforderung macht (FA-13). Beide Einschränkungen wurden bewusst in Kauf genommen.
+Dem stehen zwei Nachteile gegenüber: Ein Dokument kann nur einen Typ haben, und die Ordner müssen existieren — die automatische Anlage wird damit zu einer eigenen Anforderung (FA-13). Beide Einschränkungen wurden bewusst in Kauf genommen.
 
 \subsection{Sichtbarkeitsregeln}
 
-Für die Darstellung gelten drei Regeln, die sich aus der Feature-Beschreibung ergeben:
+Für die Darstellung gelten drei Regeln:
 
 \begin{enumerate}
-    \item \textbf{Ordner werden nicht als Einträge angezeigt.} Die Liste zeigt ausschließlich Dokumente; die Ordnerstruktur wird über Typ-Icons und Filter abgebildet, nicht über eine navigierbare Hierarchie. Der Benutzer sieht also eine flache Liste aller seiner Dokumente.
+    \item \textbf{Ordner werden nicht als Einträge angezeigt.} Die Liste zeigt ausschließlich Dokumente; die Ordnerstruktur wird über Typ-Icons und Filter abgebildet. Der Benutzer sieht eine flache Liste aller seiner Dokumente.
-    \item \textbf{Leere Typordner erscheinen nicht.} Ein Kunde, für den noch keine Monitoring-Reports abgelegt wurden, sieht diesen Typ nicht als leere Kategorie.
+    \item \textbf{Leere Typordner erscheinen nicht.}
-    \item \textbf{Ordner ohne gültiges Marker-Metadatum werden ignoriert.} Legt jemand versehentlich einen Ordner auf oberster Ebene an, ohne eine Organisations-ID zu hinterlegen, bleibt dieser für alle Kunden unsichtbar. Der Fall wird protokolliert, führt aber nicht zu einem Fehler und niemals zu einem Zugriff.
+    \item \textbf{Ordner ohne gültiges Marker-Metadatum werden ignoriert.} Fehlt die Organisations-ID, bleibt der Ordner unsichtbar. Der Fall wird protokolliert, führt aber nicht zu einem Fehler.
 \end{enumerate}
 
-Die dritte Regel ist eine Sicherheitsmaßnahme: Sie stellt sicher, dass ein Ordner nur dann für einen Kunden sichtbar wird, wenn seine Zugehörigkeit ausdrücklich hinterlegt ist. Ein fehlendes Metadatum führt zum Ausschluss, nicht zu einer Vermutung.
+Die dritte Regel ist eine Sicherheitsmaßnahme: Ein fehlendes Metadatum führt zum Ausschluss, nicht zu einer Vermutung.

chapters/conception/ui-concept.tex

@@ -3,17 +3,17 @@
 
 \subsection{Zuarbeit über einen Clickdummy}
 
-Das Oberflächenkonzept wurde nicht als Mockup in einem Entwurfswerkzeug erstellt, sondern von \emph{Hanna Ebner} als lauffähiger Clickdummy in einem eigenen Branch des Houston-Repositories umgesetzt und am 22.~Juli 2026 am Feature verlinkt.
+Das Oberflächenkonzept wurde von \emph{Hanna Ebner} als lauffähiger Clickdummy in einem eigenen Branch des Houston-Repositories umgesetzt und am 22.~Juli 2026 am Feature verlinkt.
 
-Diese Form der Zuarbeit hat gegenüber einem Bildentwurf spürbare Vorteile. Der Clickdummy verwendet die bestehenden Komponenten und Stile der Anwendung, wodurch das Ergebnis von vornherein zum übrigen Portal passt. Fragen zu Abständen, Schriftgrößen oder Farben stellen sich gar nicht erst, weil sie durch das vorhandene Stylesheet beantwortet werden. Zudem ist das Ergebnis unmittelbar bedienbar: Interaktionen wie das Ein- und Ausklappen von Filtern lassen sich ausprobieren, statt sie aus einer statischen Abbildung erschließen zu müssen. Für die Umsetzung bedeutete das, dass der Clickdummy als Referenz für das Markup dienen konnte und in mehreren Product Backlog Items ausdrücklich als solche benannt wurde.
+Der Clickdummy verwendet die bestehenden Komponenten und Stile der Anwendung, wodurch Fragen zu Abständen, Schriftgrößen oder Farben durch das vorhandene Stylesheet beantwortet werden. Interaktionen wie das Ein- und Ausklappen von Filtern lassen sich ausprobieren statt aus einer statischen Abbildung erschlossen werden. Der Clickdummy diente als Referenz für das Markup und wurde in mehreren Product Backlog Items als solche benannt.
 
 \subsection{Flache Liste statt navigierbarer Hierarchie}
 
-Die auffälligste Entwurfsentscheidung ist, dass der Dokumentenbereich trotz seiner Bezeichnung als „Document Explorer" keine navigierbare Ordnerhierarchie darstellt. Der Benutzer sieht eine flache Liste aller seiner Dokumente; die Typzugehörigkeit wird über ein Icon und über Filter ausgedrückt, nicht über ein Hineinnavigieren in Ordner.
+Der Dokumentenbereich stellt trotz seiner Bezeichnung als „Document Explorer" keine navigierbare Ordnerhierarchie dar. Der Benutzer sieht eine flache Liste aller Dokumente; die Typzugehörigkeit wird über Icons und Filter ausgedrückt.
 
-Der Grund liegt im erwarteten Nutzungsverhalten. Ein Kunde sucht in aller Regel ein bestimmtes Dokument — den letzten Monitoring-Report oder einen konkreten Vertrag. Bei einer Hierarchie müsste er zunächst wissen, in welcher Kategorie es abgelegt ist, und sich dorthin durchklicken. Die flache Liste erlaubt es dagegen, unmittelbar zu suchen oder zu filtern. Da die Hierarchie ohnehin nur zwei Ebenen tief ist und die zweite Ebene aus sieben festen Kategorien besteht, wäre der Navigationsaufwand in keinem Verhältnis zum Nutzen gestanden.
+Ein Kunde sucht in der Regel ein bestimmtes Dokument. Bei einer Hierarchie müsste er zunächst die Kategorie kennen und sich dorthin durchklicken. Die flache Liste erlaubt unmittelbares Suchen und Filtern. Da die Hierarchie nur zwei Ebenen mit sieben festen Kategorien umfasst, stünde der Navigationsaufwand in keinem Verhältnis zum Nutzen.
 
-Diese Entscheidung schlug sich auch in der Formulierung der Anforderungen nieder: Die ursprüngliche Beschreibung sprach von Dokumenten als Kacheln, wurde im Verlauf jedoch auf eine Zeilendarstellung in einer Liste geändert. Eine Zeile bietet Platz für Icon, Name, Auswahlbox und Aktionsschaltflächen und lässt sich später um weitere Spalten erweitern.
+Die ursprüngliche Beschreibung sah Dokumentkacheln vor, wurde jedoch auf Zeilendarstellung geändert. Eine Zeile bietet Platz für Icon, Name, Auswahlbox und Aktionsschaltflächen und lässt sich um Spalten erweitern.
 
 \subsection{Aufbau der Seite}
 
@@ -23,15 +23,15 @@ Die Seite gliedert sich von oben nach unten in vier Bereiche:
     \item Eine \textbf{Suchleiste} am oberen Rand, über die nach dem Dokumentnamen gesucht wird.
     \item Darunter eine Reihe von \textbf{Filterelementen}, je eines pro Dokumententyp, mit denen sich Typen ein- und ausblenden lassen.
     \item Die \textbf{Dokumentenliste} als Tabelle. Jede Zeile enthält das Typ-Icon, den Dokumentnamen sowie die Aktionen Herunterladen, Teilen und — bei PDF-Dateien — Vorschau. Eine Auswahlbox am Zeilenanfang dient der Mehrfachauswahl für den ZIP-Download.
-    \item Am unteren Rand die \textbf{Blätterelemente} zum Wechsel zwischen den Seiten sowie die Auswahl der Seitengröße.
+    \item Am unteren Rand die \textbf{Blätterelemente} zum Seitenwechsel sowie die Auswahl der Seitengröße.
 \end{enumerate}
 
-Die Tabellenstruktur wurde bewusst erweiterbar angelegt. In der Feature-Beschreibung ist ausdrücklich festgehalten, dass weitere Spalten — etwa für eine Vorschau oder zusätzliche Auswahlmöglichkeiten — ergänzt werden können, ohne den Aufbau zu verändern.
+Die Tabellenstruktur ist erweiterbar: Weitere Spalten können ergänzt werden, ohne den Aufbau zu verändern.
 
 \subsection{Konsistenz zur bestehenden Anwendung}
 
-Eine durchgängige Vorgabe war, dass sich der Dokumentenbereich wie die übrigen Houston-Seiten bedienen lassen soll (NFA-4). Das betrifft insbesondere die Paginierung, die wie an anderer Stelle eine benutzerseitig wählbare Seitengröße anbietet, und die Suche, die dem gewohnten Verhalten folgen soll.
+Eine durchgängige Vorgabe war, dass sich der Dokumentenbereich wie die übrigen Houston-Seiten bedienen lässt (NFA-4).
 
-Wie genau diese Vorgabe zu verstehen ist, zeigte sich erst im Abnahmetest: Die zunächst umgesetzte Suchleiste blendete nach einer Eingabe eine Schaltfläche zum Leeren des Feldes ein — eine für sich genommen sinnvolle Funktion, die es auf den übrigen Seiten jedoch nicht gibt. Der Unterschied wurde als Fehler gemeldet (siehe Abschnitt~\ref{sec:acceptance-testing}). Das Beispiel verdeutlicht, dass eine Konsistenzanforderung sich nicht vollständig aus einer Beschreibung ableiten lässt, sondern letztlich am Vergleich mit dem Bestand geprüft werden muss.
+Wie genau diese Vorgabe zu verstehen ist, zeigte sich erst im Abnahmetest: Die Suchleiste blendete nach einer Eingabe eine Schaltfläche zum Leeren ein — eine sinnvolle Funktion, die es auf den übrigen Seiten nicht gibt. Der Unterschied wurde als Fehler gemeldet (siehe Abschnitt~\ref{sec:acceptance-testing}). Das Beispiel verdeutlicht, dass eine Konsistenzanforderung am Vergleich mit dem Bestand geprüft werden muss.
 
-Ein zweiter Punkt betrifft das Zusammenspiel von Freigabelinks und Paginierung. Ein Link, der auf ein bestimmtes Dokument verweist, muss auch dann funktionieren, wenn dieses Dokument nicht auf der ersten Seite liegt. Das Konzept sieht deshalb vor, dass der Freigabelink nicht nur das Dokument benennt, sondern beim Weiterleiten auch die passenden Abfrageparameter setzt, sodass die richtige Seite geladen und an die entsprechende Stelle gesprungen wird.
+Ein Freigabelink, der auf ein bestimmtes Dokument verweist, muss auch funktionieren, wenn dieses nicht auf der ersten Seite liegt. Der Link setzt daher beim Weiterleiten die passenden Abfrageparameter, sodass die richtige Seite geladen und an die entsprechende Stelle gesprungen wird.

chapters/execution/architecture.tex

@@ -1,12 +1,39 @@
-\section{Architektur des Documents-Moduls}
+\section{Architektur des Dokumentenmoduls}
 \label{sec:architecture}
 
-% TODO: Razor Page DocumentsPage.cshtml → DocumentsService → S3DocumentsClient
+\subsection{Schichtung}
-% Klassendiagramm module-components.pdf
 
-% \begin{figure}[H]
+Das Dokumentenmodul folgt der in Houston etablierten Schichtung. Abbildung~\ref{fig:module-components} zeigt die Komponenten.
-%   \centering
+
-%   \includegraphics[width=0.9\textwidth]{figures/diagrams/module-components.pdf}
+\begin{figure}[H]
-%   \caption{Komponentenstruktur des Documents-Moduls}
+    \centering
-%   \label{fig:module-components}
+    \includegraphics[width=0.95\textwidth]{figures/diagrams/module-components.pdf}
-% \end{figure}
+    \caption{Komponenten des Dokumentenmoduls}
+    \label{fig:module-components}
+\end{figure}
+
+Die oberste Schicht bilden drei Razor Pages: \texttt{Documents} für Liste, Suche, Filter und Blätterelemente, \texttt{Document/Download} für Downloadanforderungen (einzeln und als ZIP) und \texttt{Document/Share} für Freigabelinks. Die Aufteilung folgt daraus, dass Download und Freigabe eigene Routen mit eigenen Antwortformaten benötigen.
+
+Darunter liegt der \texttt{DocumentsService} als fachliche Schicht mit den Regeln des Ablagekonzepts: Auflösung des Kundenordners, Typableitung aus dem Pfad, Ausblendung technischer Einträge. Der \texttt{S3DocumentsClient} kapselt den technischen Speicherzugriff und ist die einzige Stelle, an der \texttt{IAmazonS3} unmittelbar verwendet wird.
+
+\subsection{Eigene Typen statt Zeichenketten}
+
+Eine Entwurfsentscheidung, die sich im Verlauf herausbildete, betrifft den Umgang mit Pfaden. Anfangs wurden Dokumentschlüssel als Zeichenketten durch die Schichten gereicht. Im Review des Downloads führte das zu wiederholten Rückfragen zur Pfadvalidierung, weil einer Zeichenkette nicht anzusehen ist, ob sie bereits geprüft wurde.
+
+Daraufhin wurden eigene Typen eingeführt: Ein \emph{Schlüssel} bezeichnet den vollständigen, validierten Pfad; ein \emph{relativer Pfad} den Anteil unterhalb des Kundenordners. Beide können nur über Konstruktionswege entstehen, die die jeweilige Prüfung durchführen. Eine vergessene Prüfung führt zu einem Übersetzungsfehler statt zu einer Sicherheitslücke.
+
+Der zugehörige Pull Request durchlief 23 Iterationen und bestand zu einem erheblichen Teil aus diesem Refactoring — ein Aufwand, der sich auszahlte, weil ZIP-Download, PDF-Vorschau und Freigabelinks dieselben Typen wiederverwenden konnten. Nach demselben Muster entstanden \texttt{DocumentType}, \texttt{DocumentName} und \texttt{OrgSlug}.
+
+\subsection{Zentrale Autorisierung}
+
+Die erste Fassung des Document Explorers prüfte die Berechtigung im PageModel. Im Review wies \emph{Hanna Ebner} darauf hin, dass die Autorisierung in Houston zentral in der Anwendungskonfiguration erfolgt und eine zusätzliche Prüfung an der Seite überflüssig ist.
+
+Der Einwand betrifft mehr als doppelten Code: Eine seitenspezifische Prüfung ist leicht zu übersehen, wenn weitere Seiten hinzukommen — genau das wäre bei \texttt{Download} und \texttt{Share} passiert. Die zentrale Registrierung stellt sicher, dass alle Routen des Moduls derselben Richtlinie unterliegen.
+
+\subsection{Gestapelte Pull Requests}
+
+Ein Vorgehen, das sich durch die gesamte Umsetzung zieht, ist die Verkettung der Pull Requests. Der erste ging gegen den Hauptbranch; jeder darauf aufbauende gegen den Branch seines Vorgängers.
+
+Der Grund ist die Reviewbarkeit. Da die Arbeiten aufeinander aufbauen, hätte ein direkter Vergleich gegen den Hauptbranch auch sämtliche Vorgängeränderungen enthalten. Durch die Verkettung enthält jeder Pull Request genau die Änderungen seines Backlog Items.
+
+Der Preis zeigte sich beim Zusammenführen: Sobald ein Vorgänger in den Hauptbranch übernommen war, musste der Nachfolger umgestellt werden. Diese Umstellung setzt in Azure DevOps die bereits abgegebenen Freigaben zurück. Für künftige Arbeiten wäre abzuwägen, ob der Gewinn an Reviewbarkeit diesen Abstimmungsaufwand rechtfertigt; bei der vorliegenden Zahl aufeinander aufbauender Items überwog er deutlich.

chapters/execution/document-explorer.tex

@@ -1,5 +1,30 @@
 \section{Document Explorer}
 \label{sec:document-explorer}
 
-% TODO: PBI 9295 — /documents Seite, ListObjectsV2, Empty State, Fehlerbehandlung
+\subsection{Umfang}
-% Abbildung~\ref{fig:documents-page-model}, \ref{fig:document-view-model}, \ref{fig:documents-table-body}
+
+Der Document Explorer war das erste umgesetzte Backlog Item und mit acht Aufwandspunkten das umfangreichste. Er umfasst die Grundstruktur des gesamten Moduls: Seite, Dienst, Speicherclient, Modelle sowie Einbindung in Navigation und Autorisierung.
+
+\subsection{Vom Kachel- zum Listenentwurf}
+
+Die ursprüngliche Fassung sah eine Kacheldarstellung vor. Im Verlauf wurde auf Zeilendarstellung geändert, da Auswahlboxen für den ZIP-Download, Download- und Teilen-Schaltflächen sowie eine Vorschau im Backlog standen. Eine Kachel hätte für diese Elemente keinen natürlichen Platz geboten. Die Tabelle soll flexibel um weitere Spalten erweiterbar sein.
+
+\subsection{Ableitung des Dokumententyps}
+
+Der Typ eines Dokuments ergibt sich aus dem Unterordnernamen und wird gegen eine Aufzählung abgeglichen. Im Review schlug \emph{Timo Walter} vor, die Zeichenketten-Umwandlung mit Nichtbeachtung der Groß- und Kleinschreibung zu verwenden statt einer eigenen Zuordnung. Beim Hinzufügen eines Typs muss so nur die Aufzählung ergänzt werden. Schlägt die Umwandlung fehl, gilt das Dokument als untypisiert.
+
+Eine bewusste Ausnahme betrifft die Übersetzung: Fehlt für einen bekannten Typ der Eintrag in der Ressourcendatei, wird eine Ausnahme ausgelöst. Jeder Wert der Aufzählung ist per Definition gültig; fehlt seine Übersetzung, ist das eine unvollständige Implementierung. Ein stiller Rückfall auf den Ordnernamen würde diesen Fehler verdecken.
+
+\subsection{Leerer Zustand und Fehlerbehandlung}
+
+Zwei Anforderungen betreffen Situationen ohne anzeigbare Dokumente und sind zu unterscheiden.
+
+Der \textbf{leere Zustand} tritt ein, wenn der Kunde berechtigt ist, aber keine Dokumente vorliegen — insbesondere unmittelbar nach der automatischen Ordneranlage. Er wird mit einem Hinweis dargestellt.
+
+Ein \textbf{Fehler} liegt vor, wenn die Dokumente nicht geladen werden konnten. Im Review wurde angemerkt, dass dieser Fall nicht in einer stillschweigend leeren Seite münden darf: Im einen Fall gibt es nichts zu sehen, im anderen funktioniert die Anwendung nicht.
+
+\subsection{Die bekannte Schwäche}
+
+Bereits im Review fragte \emph{Hanna Ebner}, warum für jeden Kunden eine eigene Abfrage nötig sei. Die Antwort war, dass die Schnittstelle dies nicht anders zulässt, verbunden mit dem Verweis auf das eigens angelegte Recherche-Item.
+
+Die Schwäche wurde erkannt und bewusst zurückgestellt — der Explorer sollte nicht daran scheitern, dass eine Optimierung noch nicht gefunden war. Die tatsächliche Lösung beschreibt Abschnitt~\ref{sec:folder-management}.

chapters/execution/downloads.tex

@@ -1,13 +1,29 @@
-\section{Dokumenten-Downloads}
+\section{Downloads}
 \label{sec:downloads}
 
-% TODO: PBI 9299 (Einzeldownload), PBI 9296 (ZIP-Download)
+\subsection{Einzeldownload über zeitlich begrenzte Zugriffs-URLs}
-% Streaming: S3 GetObject → ZipArchive → HTTP Response Stream
-% Abbildung~\ref{fig:zip-download-action}
 
-% \begin{figure}[H]
+Für den Einzeldownload wird eine zeitlich begrenzte Zugriffs-URL erzeugt, mit der der Browser das Dokument unmittelbar vom Speicher abruft \autocite{aws-presigned-urls}. Die Datenübertragung läuft nicht über die Anwendung; ein großes Dokument belegt weder Arbeitsspeicher noch Verbindungen des Webservers. Die URL ist nur wenige Minuten gültig.
-%   \centering
+
-%   \includegraphics[width=0.9\textwidth]{figures/diagrams/zip-stream.pdf}
+Wichtig ist, dass die Berechtigungsprüfung \emph{vor} dem Erzeugen der URL stattfindet. Die URL selbst trägt keine Prüfung — wer sie besitzt, kann zugreifen. Sie darf deshalb nur für einen Schlüssel erzeugt werden, der nachweislich im Kundenordner liegt. Genau hier setzte der überwiegende Teil des Reviews an, und die Rückfragen führten zur in Abschnitt~\ref{sec:architecture} beschriebenen Einführung eigener Pfadtypen.
-%   \caption{ZIP-Download-Ablauf}
+
-%   \label{fig:zip-stream}
+Zusätzlich musste sichergestellt werden, dass das Dokument unter seinem ursprünglichen Namen ankommt, da der Schlüssel den vollständigen Pfad enthält.
-% \end{figure}
+
+\subsection{ZIP-Download}
+
+Jede Zeile erhält eine Auswahlbox für den ZIP-Download. Die Schaltfläche ist deaktiviert, solange nichts ausgewählt ist.
+
+Abbildung~\ref{fig:zip-stream} zeigt den Ablauf.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=0.95\textwidth]{figures/diagrams/zip-stream.pdf}
+    \caption{Ablauf des ZIP-Downloads}
+    \label{fig:zip-stream}
+\end{figure}
+
+Das Archiv wird erst beim Klick erzeugt. Entscheidend ist, dass es nie vollständig im Arbeitsspeicher entsteht: Die Anwendung öffnet die Antwort als Archivstrom, liest die Dokumente nacheinander aus dem Speicher und schreibt sie unmittelbar als Einträge hinein \autocite{dotnet-zip}. Da die Gesamtgröße unbegrenzt ist, würde ein vollständiger Aufbau den Speicherbedarf von der größten Auswahl abhängig machen. Beim Strömen bleibt er konstant.
+
+\subsection{ZIP auch bei einer einzelnen Datei}
+
+Im Review stellte \emph{Sarah Hinzmann} die Frage, ob bei nur einer ausgewählten Datei ein Archiv erzeugt werden solle. Die Entscheidung fiel für das Archiv: Die Schaltfläche ist mit „Als ZIP herunterladen" beschriftet und soll vorhersagbar ein Archiv liefern. Wer eine einzelne Datei unverpackt benötigt, verwendet die Download-Schaltfläche in der Zeile.

chapters/execution/filter-pagination.tex

@@ -1,6 +1,24 @@
 \section{Typfilter und Paginierung}
 \label{sec:filter-pagination}
 
-% TODO: PBI 9749 (Typfilter), PBI 9731 (Pagination)
+\subsection{Filterung nach Dokumententyp}
-% ContinuationToken statt Offset-Pagination
+
-% Abbildung~\ref{fig:pagination-continuation-token}
+Unterhalb der Suchleiste steht je Dokumententyp ein Bedienelement zum Ein- und Ausblenden. Die Auswahl wird als Abfrageparameter übertragen und im PageModel ausgewertet; die Filterung selbst erfolgt anschließend im Dienst.
+
+Die Auswertung des Parameters war Gegenstand des Reviews. Da die Werte aus der Adresszeile stammen, muss die Anwendung mit manipulierten oder veralteten Werten rechnen. \emph{Robin Noack} schlug vor, nicht erkennbare Werte stillschweigend zu verwerfen. Ein unbekannter Filterwert ist kein Angriff, sondern in der Regel ein veralteter Link. Die Mandantentrennung geschieht über das Präfix, nicht über den Filter.
+
+Ein zweiter Reviewhinweis betraf die Benennung: Der Typ für eine Menge von Dokumententypen unterschied sich vom Einzeltyp nur durch ein Zeichen. Da eine Verwechslung leicht möglich ist, wurde die Benennung geschärft.
+
+\subsection{Paginierung mit Fortsetzungsmerkmalen}
+
+Die Paginierung folgt der Arbeitsweise des Speichers, der Ergebnisse blockweise mit Fortsetzungsmerkmalen liefert \autocite{aws-listobjectsv2}. Ein Fortsetzungsmerkmal setzt die Auflistung dort fort, wo sie endete. Ein direkter Sprung auf eine beliebige Seite ist nicht möglich, ohne alle vorhergehenden Blöcke abzurufen. Die Akzeptanzkriterien verlangten dies auch nicht — gefordert waren Vor- und Zurück-Navigation.
+
+\subsection{Übernommene Annahmen}
+
+Ein Zahlenwert für die maximale Seitengröße war aus den bestehenden Houston-Seiten übernommen worden (NFA-4). \emph{Robin Noack} wies darauf hin, dass dieser Wert dort aus einer Beschränkung des ITSM-Systems stammt und für den Speicher keine Bedeutung hat. Was wie eine Konvention aussah, war eine technische Grenze eines anderen Systems. Der Wert wurde angepasst.
+
+Diskutiert wurde auch, ob die vom Benutzer wählbare Seitengröße nach oben begrenzt werden sollte, da ein sehr großer Wert aus der Adresszeile eine entsprechend große Antwort erzwingen könnte.
+
+\subsection{Zusammenspiel mit Freigabelinks}
+
+Die Paginierung wirkt sich auf die Freigabelinks aus: Ein Link auf ein Dokument ist wertlos, wenn er stets auf der ersten Seite landet. Die Weiterleitung setzt deshalb nicht nur die Sprungmarke, sondern auch die Abfrageparameter für die richtige Seite. Diese Abhängigkeit war bei der Formulierung des Items berücksichtigt worden.

chapters/execution/folder-management.tex

@@ -1,8 +1,32 @@
-\section{Ordnerstruktur und Kundenordner-Lookup}
+\section{Ordnerverwaltung und Kundenordner-Lookup}
 \label{sec:folder-management}
 
-% TODO: PBI 9560 (Ordneranlage beim ersten Seitenaufruf), PBI 10018 (O(1)-Lookup)
+\subsection{Gemeinsame Umsetzung zweier Backlog Items}
-% OrgSlug: deterministische, S3-konforme Normalisierung des Efecte-Namens (Umlaute bleiben erhalten)
+
-% IBM-Naming-Constraints: \cite{ibm-s3-naming}
+Die automatische Ordneranlage und der neue Kundenordner-Lookup wurden in einem gemeinsamen Pull Request umgesetzt. Der Lookup benötigt in seiner Rückfallebene den Fall, dass kein Ordner existiert und die Struktur angelegt werden muss. Eine getrennte Implementierung hätte einen Platzhalter erfordert, der im nächsten Pull Request entfernt worden wäre. Die Zusammenlegung wurde begründet und beide Items verknüpft.
-% ResolveCustomerPrefixAsync, Self-Healing-Rename
+
-% Abbildung~\ref{fig:org-slug}, \ref{fig:resolve-customer-prefix}, \ref{fig:rename-customer-folder}
+\subsection{Normalisierung des Firmennamens}
+
+Der erwartete Ordnername entsteht aus dem Firmennamen des Benutzers. Da dieser aus einem Fremdsystem stammt und beliebige Zeichen enthalten kann, wird er normalisiert: umschließende Leerzeichen entfernt, strukturell bedeutsame oder nicht darstellbare Zeichen ersetzt, führende und abschließende Punkte verhindert, die Länge begrenzt.
+
+Zwei Eigenschaften sind entscheidend. Die Normalisierung ist \textbf{deterministisch} — derselbe Eingabename ergibt stets denselben Ordnernamen, Voraussetzung für den Direktzugriff. Sie erhält \textbf{Umlaute}, weil der Ordner in Filestash von Menschen gelesen wird.
+
+Im Review fragte \emph{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 \autocite{ibm-s3-naming, aws-s3-naming}.
+
+\subsection{Umsetzung des Lookups}
+
+Die in Abschnitt~\ref{sec:lookup-decision} beschriebene dreistufige Auflösung wurde in einer Methode zusammengefasst — der einzigen Stelle, an der ein Kundenpräfix entsteht. Der erste Schritt fragt die Metadaten des erwarteten Markers ab. Der zweite wiederholt dies mit dem um die Organisations-ID ergänzten Namen (Kollisionsfall). Erst der dritte greift auf das lineare Verfahren zurück.
+
+Beim Prüfen, ob ein Zielname frei ist, wird nicht nur der Marker betrachtet, sondern auch geprüft, ob bereits Objekte unterhalb des Zielpräfixes liegen. Ein Zielname gilt nur als frei, wenn weder ein fremder Marker noch Inhalte vorhanden sind.
+
+\subsection{Umbenennen als Kopiervorgang}
+
+Der Speicher kennt keine Umbenennung. Ein Objekt lässt sich nur kopieren und anschließend löschen. Eine Umbenennung ist daher nicht unteilbar — sie kann abbrechen, und Objekte liegen teils am alten, teils am neuen Ort.
+
+Umgesetzt wurde dies über zwei Maßnahmen. Erstens wird der \textbf{Marker zuletzt kopiert}: Solange er fehlt, wird das Ziel von einer parallelen Anfrage nicht als Kundenordner erkannt. Zweitens entfernt die Fehlerbehandlung bereits erzeugte Teilkopien, damit der Vorgang wiederholbar ist.
+
+Die zweite Maßnahme gilt nur, solange kein zweiter Vorgang dieselbe Umbenennung ausführt. Dieser Fall ist Gegenstand des folgenden Abschnitts.
+
+\subsection{Stand bei Abgabe}
+
+Der zugehörige Pull Request war zum Zeitpunkt der Erstellung dieser Dokumentation noch offen. Die inhaltlichen Anmerkungen waren geschlossen, die abschließende Freigabe stand aus.

chapters/execution/pdf-preview.tex

@@ -1,6 +1,28 @@
-\section{PDF-Modal-Vorschau und Share-Link-Previews}
+\section{PDF-Vorschau und Freigabelinks}
 \label{sec:pdf-preview}
 
-% TODO: PBI 9300 (PDF-Modal), PBI 9294 (Share-Link-Previews)
+\subsection{PDF-Vorschau im Modal}
-% Pre-Signed URLs, zeitlich begrenzte Gültigkeit
+
-% Abbildung~\ref{fig:presigned-url}
+Die Vorschau öffnet PDF-Dokumente in einem überlagerten Fenster über dieselbe zeitlich begrenzte Zugriffs-URL, die auch dem Download zugrunde liegt. Für Nicht-PDF-Dateien wird keine Vorschau angeboten.
+
+Eine Prüfung der Dateigröße wurde bewusst nicht umgesetzt. Diese Abgrenzung wurde im Approval-Termin festgelegt: Jede Grenze wäre willkürlich, und der Browser stellt PDF-Dokumente ohnehin fortlaufend dar.
+
+\subsection{Aufbau der Freigabelinks}
+
+Ein Freigabelink verweist auf eine eigene Seite, deren Adresse den relativen Pfad des Dokuments kodiert enthält. Kodiert wird nur der Anteil unterhalb des Kundenordners, um Pfadtrennzeichen und Sonderzeichen unbeschadet durch die Adresse zu transportieren.
+
+Dass der Kundenordner nicht Bestandteil des Links ist, hat eine Wirkung: Der Link enthält keinen Hinweis auf die Organisation und ist ohne Anmeldung nicht auflösbar.
+
+Die Seite zeigt keinen Dokumentinhalt an. Sie liefert Metaangaben für die Vorschau und leitet auf die Dokumentenliste weiter, wobei Sprungmarke und passende Seite angesteuert werden.
+
+\subsection{Vorschau in Messengern}
+
+Der Zweck der Freigabeseite ist, dass ein in einem Messenger geteilter Link mit Titel und Symbol dargestellt wird. Dazu werden Metaangaben ausgeliefert: Dokumentname als Titel, Typsymbol als Bild, Adresse der Dokumentenliste als Ziel.
+
+Die Typsymbole liegen als Vektorgrafiken vor, die von Vorschaudiensten gängiger Messenger nicht zuverlässig dargestellt werden. Sie mussten daher zusätzlich als Rastergrafiken bereitgestellt werden. Im Pull Request wurde vermerkt, dass die Rastergrafiken bei einer Gestaltungsänderung nachzuziehen sind.
+
+\subsection{Sichtbarkeit der Vorschaubilder}
+
+Damit ein Messenger eine Vorschau erzeugen kann, muss er das Bild ohne Anmeldung abrufen können. Bei den sieben festen Typsymbolen ist das unbedenklich, da sie keine kundenbezogene Information enthalten. Benutzerdefinierte Symbole aus URL-Dateien werden daher \emph{nicht} für die Vorschau ausgeliefert — andernfalls müsste Dateiinhalt über einen nicht authentifizierten Pfad zugänglich gemacht werden.
+
+Die Entscheidung wurde im Pull Request festgehalten. Sie zeigt, dass eine harmlose Funktion in Verbindung mit einer anderen eine Sicherheitsfrage aufwirft, die keine der beiden für sich genommen aufgeworfen hätte.

chapters/execution/race-conditions.tex

@@ -1,15 +1,54 @@
-\section{Bekannte Grenze: Race Conditions im Lookup}
+\section{Erkannte Grenze: Nebenläufigkeit im Lookup}
 \label{sec:race-conditions}
 
-% TODO: PBI 10070 — Houston läuft in mehreren Instanzen, In-Memory-Lock reicht nicht
+\subsection{Ausgangslage}
-% Szenario A: Datenverlust beim parallelen Rename (Rollback löscht Dokumente des Gewinners)
-% Szenario B: Mandantenvermischung beim gleichzeitigen Anlegen gleicher Efecte-Namen
-% Lösungsansätze: Rollback-Absicherung, Conditional Writes, verteiltes Lock, prozessuale Migration
-% Timebox: 4–6 Stunden (Stephan Janßen)
 
-% \begin{figure}[H]
+Der Lesepfad des Kundenordner-Lookups ist unkritisch. Der in Abschnitt~\ref{sec:folder-management} beschriebene dritte Schritt ist jedoch \emph{verändernd}: Er benennt Ordner um und legt sie an, im Rahmen einer gewöhnlichen Seitenanfrage. Da Houston in mehreren Instanzen betrieben wird, reicht eine Sperre innerhalb einer Instanz nicht aus.
-%   \centering
+
-%   \includegraphics[width=0.9\textwidth]{figures/diagrams/race-condition-a.pdf}
+Bei der Durchsicht des Codes wurden zwei Fehlerszenarien gefunden, die ausdrücklich formulierte Akzeptanzkriterien verletzen.
-%   \caption{Race Condition Szenario A: Datenverlust beim parallelen Rename}
+
-%   \label{fig:race-condition-a}
+\subsection{Szenario A: Datenverlust beim gleichzeitigen Umbenennen}
-% \end{figure}
+
+Das erste Szenario betrifft die Fehlerbehandlung des Umbenennens. Abbildung~\ref{fig:race-condition-a} zeigt den Ablauf.
+
+\begin{figure}[H]
+    \centering
+    \includegraphics[width=\textwidth]{figures/diagrams/race-condition-a.pdf}
+    \caption{Datenverlust bei gleichzeitigem Umbenennen}
+    \label{fig:race-condition-a}
+\end{figure}
+
+Beide Anfragen halten den Zielnamen für frei, weil beide prüfen, bevor eine schreibt. Anfrage~A kopiert alle Objekte und löscht die Quelle. Anfrage~B findet beim nächsten Objekt die Quelle nicht mehr vor. Ihre Fehlerbehandlung entfernt die eigenen Teilkopien — dieselben Objekte, die A soeben geschrieben hat. Da die Quelle gelöscht ist, existiert keine Kopie mehr. Das Ergebnis ist Datenverlust.
+
+\subsection{Szenario B: Vermischung zweier Mandanten}
+
+Der Marker wird ohne Bedingung geschrieben. Haben zwei Organisationen denselben Firmennamen und greifen erstmals gleichzeitig zu, legen beide den Marker an; der zuletzt geschriebene gewinnt. Beide arbeiten anschließend im selben Ordner, obwohl das Metadatum nur einer gehört. Der Folgeaufruf korrigiert sich zwar selbst, doch zwischenzeitlich Abgelegtes verbleibt im fremden Ordner.
+
+Von den beiden Szenarien ist dieses das schwerwiegendere: Datenverlust ist ein Betriebsproblem, die Offenlegung von Kundendokumenten ein Vertraulichkeitsproblem.
+
+\subsection{Abgegrenzte Fälle}
+
+Zur Eingrenzung wurde geprüft, welche nebenläufigen Abläufe \emph{nicht} betroffen sind. Zwei Anfragen derselben Organisation erzeugen identische Schlüssel und sind harmlos. Lesen während einer Verschiebung ist abgedeckt: Da der Marker zuletzt kopiert wird, wird ein halb gefülltes Ziel nicht als Kundenordner erkannt. Das Problem beschränkt sich auf zwei \emph{unterschiedlich weit fortgeschrittene} verändernde Vorgänge.
+
+\subsection{Erwogene Gegenmaßnahmen}
+
+Vier Ansätze wurden formuliert:
+
+\begin{enumerate}
+    \item \textbf{Absicherung der Fehlerbehandlung.} Vor dem Entfernen der Teilkopien wird geprüft, ob der Marker der Quelle noch existiert. Fehlt er, hat ein anderer Vorgang die Umbenennung abgeschlossen, und es darf nichts gelöscht werden. Das beseitigt Szenario~A weitgehend: Es bleiben überzählige Objekte zurück statt Daten verloren zu gehen.
+    \item \textbf{Bedingtes Schreiben.} Wird der Marker nur unter der Bedingung geschrieben, dass er noch nicht existiert, ist das Beanspruchen eines Namens unteilbar und Szenario~B ausgeschlossen \autocite{aws-conditional-writes}. Voraussetzung ist, dass der Speicher diese vergleichsweise junge Erweiterung unterstützt — was ausdrücklich nachzuweisen wäre.
+    \item \textbf{Instanzübergreifende Sperre.} Eine über die Datenbank realisierte Sperre je Organisation würde den verändernden Teil sauber serialisieren, kostet aber einen zusätzlichen Zugriff je Anfrage und erfordert ein Konzept für den Fall, dass eine Sperre nicht freigegeben wird.
+    \item \textbf{Verlagerung aus dem Anfragepfad.} Bestandsordner werden einmalig kontrolliert migriert, und die Anwendung protokolliert lediglich, wenn ein Ordner vom Sollzustand abweicht. Damit verschwindet die Ursache vollständig statt abgesichert zu werden.
+\end{enumerate}
+
+Der erste Ansatz sollte unabhängig von der Serialisierungslösung umgesetzt werden. Der vierte ist bemerkenswert, da er eine organisatorische statt technische Lösung darstellt.
+
+\subsection{Umgang mit dem Befund}
+
+Der Befund wurde als eigenes Backlog Item mit erhöhter Priorität erfasst und vom laufenden Pull Request abgegrenzt. Das Team versah es mit einem Zeitrahmen von vier bis sechs Stunden.
+
+Den Pull Request offenzuhalten, bis die Nebenläufigkeit gelöst ist, hätte den Lookup blockiert: Ob bedingtes Schreiben verfügbar ist, ließ sich ohne Rückfrage beim Betreiber nicht beantworten, und deren Bearbeitungsdauer war zuvor mit mehreren Wochen bemessen worden. Der Lookup verbessert den Zustand gegenüber vorher bereits deutlich.
+
+Hinzu kommt, dass der verändernde Pfad nur beim ersten Zugriff einer Organisation durchlaufen wird. Das Risikofenster besteht pro Kunde genau einmal.
+
+Die Akzeptanzkriterien des Folgeitems halten fest, dass eine reine Sperre innerhalb einer Instanz nicht als Lösung akzeptiert wird und dass beide Szenarien durch Unit-Tests nachzubilden sind.

chapters/execution/s3-client.tex

@@ -1,5 +1,26 @@
 \section{Anbindung des S3-Speichers}
 \label{sec:s3-client}
 
-% TODO: AWS SDK für .NET, IAmazonS3, keyed services in Program.cs, S3Settings (DEV/TEST/PROD Buckets)
+\subsection{Zugriff über das AWS SDK}
-% Abbildung~\ref{fig:s3-settings-registration}, \ref{fig:s3-documents-client}
+
+Der Zugriff auf den Speicher erfolgt über das AWS SDK für .NET. Obwohl der Speicher nicht bei Amazon betrieben wird, ist dies der naheliegende Weg: StorageGRID implementiert die S3-Schnittstelle, und das SDK lässt sich über eine abweichende Dienstadresse auf einen beliebigen kompatiblen Endpunkt richten. Eine eigene Implementierung — insbesondere der Signaturberechnung — wäre aufwendig und fehleranfällig gewesen.
+
+Der \texttt{S3DocumentsClient} kapselt die verwendeten Operationen: Auflisten, Metadatenabruf, Erzeugen zeitlich begrenzter Zugriffs-URLs, Lesen von Objektinhalten sowie Anlegen, Kopieren und Löschen von Objekten. Diese Kapselung hält die SDK-spezifischen Typen aus der fachlichen Schicht und ermöglicht in Tests ein Mock (siehe Abschnitt~\ref{sec:unit-tests}).
+
+\subsection{Konfiguration mehrerer Speicher}
+
+Houston verwendete bereits vor diesem Projekt einen S3-Speicher für das Dokumentationssystem. Mit dem Dokumentenbereich kam ein zweiter, davon unabhängiger Speicher hinzu.
+
+In der ersten Fassung wurden die Einstellungen als eigenständiger Konfigurationssatz geführt. Im Review wurde angeregt, eine gemeinsame Struktur für S3-Einstellungen zu verwenden und die Verwendungen über benannte Registrierungen im Dienstcontainer auseinanderzuhalten \autocite{dotnet-keyed-di}. Ein dritter Speicher erfordert so lediglich einen weiteren Konfigurationsabschnitt und eine Registrierung, nicht aber eine Verdopplung der Einstellungsklassen.
+
+\subsection{Umgebungen und Zugangsdaten}
+
+Für die drei Umgebungen existiert je ein eigener Bucket mit getrennten Zugangsdaten, sodass ein fehlerhaft konfigurierter Entwicklungsstand nicht auf Produktivdaten zugreifen kann. Die Zugangsdaten liegen nicht im Quelltext, sondern werden über die Konfigurationsmechanismen der Anwendung bereitgestellt und im unternehmensweiten Passwortmanager hinterlegt.
+
+\subsection{Auflisten von Objekten}
+
+Die zentrale Leseoperation listet Objekte unterhalb eines Präfixes auf. Sie wird mit dem Kundenpräfix aufgerufen und liefert sämtliche Objekte über alle Typordner hinweg.
+
+Zwei Eigenschaften prägten die Umsetzung. Erstens liefert die Operation Ergebnisse blockweise: Überschreitet die Trefferzahl eine Grenze, wird ein Fortsetzungsmerkmal zurückgegeben \autocite{aws-listobjectsv2}. Diese Eigenschaft wurde für die Paginierung genutzt (siehe Abschnitt~\ref{sec:filter-pagination}). Zweitens liefert sie keine benutzerdefinierten Metadaten — die Ursache des in Abschnitt~\ref{sec:lookup-research} beschriebenen Lookup-Problems.
+
+Beim Auflisten werden Platzhalterobjekte der Typordner und der Marker des Kundenordners herausgefiltert. Beide erkennt der Dienst daran, dass ihr Schlüssel auf das Trennzeichen endet.

chapters/execution/search.tex

@@ -1,6 +1,22 @@
-\section{Serverseitige Suche}
+\section{Suche}
 \label{sec:search}
 
-% TODO: PBI 9298 — Suchleiste, titelbasiert, Teiltreffer, serverseitiges Filtern
+\subsection{Umsetzung}
-% S3-API bietet keine direkte Filterung → Houston-seitiger Filter
+
-% Abbildung~\ref{fig:document-search}
+Die Suche filtert die Dokumentenliste anhand des Namens und berücksichtigt Teiltreffer. Ein geleertes Suchfeld stellt die vollständige Liste wieder her. Im Approval-Termin wurde gefragt, ob auch eine Beschreibung durchsucht werden solle; da Dokumente keine tragen, wurde die Suche auf den Namen begrenzt.
+
+\subsection{Der Begriff „serverseitig"}
+
+Die Anforderung verlangt eine serverseitige Suche. Gemeint ist, dass die Filterung in der Anwendung stattfindet, nicht im Browser — der Browser erhält die bereits gefilterte Menge. Eine Filterung im Browser würde voraussetzen, dass sämtliche Dokumente zuvor übertragen wurden, was mit der Paginierung unvereinbar wäre.
+
+Nicht umgesetzt ist eine Filterung durch den \emph{Speicher}. Houston listet die Objekte auf und filtert die Namen anschließend selbst. Im Review stellte \emph{Hanna Ebner} die Frage, ob sich das nicht direkt über die Schnittstelle lösen lasse, und musste verneint werden.
+
+\subsection{Warum keine Filterung im Speicher möglich war}
+
+Im weiteren Verlauf brachte \emph{Timo Walter} die Abfragefunktion des Speichers ins Spiel. Die Prüfung ergab, dass diese Objektinhalte filtert, nicht Objektnamen — sie wählt aus strukturierten Dateien einzelne Datensätze aus \autocite{aws-s3-select}.
+
+Als zweite Möglichkeit wurde der Suchdienst des Speicherherstellers erwogen \autocite{storagegrid-search-integration}. Dessen Verfügbarkeit stand noch nicht fest; die Anfrage lief bereits (siehe Abschnitt~\ref{sec:infrastructure}). Die spätere Antwort fiel negativ aus. Auf Anregung des Reviewers wurde dieser Umstand in das Recherche-Item aufgenommen.
+
+\subsection{Bewertung}
+
+Die praktische Auswirkung ist derzeit gering. Die Dokumentenzahl je Kunde ist überschaubar; die Suche skaliert nur mit der Dokumentenzahl eines einzelnen Kunden, nicht mit der Kundenzahl. Der Lookup wurde daher im Projektzeitraum gelöst, die Suchoptimierung blieb für den Ausblick.

chapters/execution/type-icons.tex

@@ -1,5 +1,16 @@
-\section{Dokumenttypen und Icons}
+\section{Typ-Icons}
 \label{sec:type-icons}
 
-% TODO: PBI 9549 — Typ-Mapping aus Unterordner, .resx-Lokalisierung
+\subsection{Eigene Symbole statt Symbolschrift}
-% Abbildung~\ref{fig:document-type-mapping}, \ref{fig:document-types-resx}
+
+Houston verwendet für Symbole eine gängige Symbolbibliothek. Für die sieben Dokumententypen enthielt diese keine passenden Motive — Begriffe wie „SLA-Report Ticketbearbeitung" lassen sich mit allgemeinen Symbolen nicht unterscheiden. Es wurden daher eigene Vektorgrafiken erstellt.
+
+Eine Einbindung als gewöhnliche Grafik hätte eine feste Farbe bedeutet. Houston unterstützt jedoch ein helles und ein dunkles Erscheinungsbild, und fest eingefärbte Symbole wären im dunklen kaum sichtbar gewesen.
+
+\subsection{Einfärbung über Masken}
+
+Gelöst wurde dies, indem die Vektorgrafiken als Maske über einer Hintergrundfläche dienen. Die Fläche übernimmt die aktuelle Textfarbe, sodass sich das Symbol automatisch anpasst. Die eigenen Symbole lassen sich über dieselben Gestaltungsklassen ansprechen wie die vorhandenen. Alle Grafiken müssen dieselben Abmessungen haben; im Review fiel auf, dass eine abwich, und die Maße wurden angeglichen.
+
+\subsection{Standardsymbol}
+
+Dokumente ohne erkennbaren Typ erhalten ein neutrales Standardsymbol. Damit trägt jede Zeile ein Symbol, und an der Darstellung ist erkennbar, dass keine Typzuordnung vorliegt, ohne dass dies wie ein Fehler wirkt.

chapters/execution/url-files.tex

@@ -1,6 +1,28 @@
-\section{Support für URL-Dateien}
+\section{Unterstützung von URL-Dateien}
 \label{sec:url-files}
 
-% TODO: PBI 9301 — .url-Dateien parsen, Verlinkung beliebiger URLs (Teams, SharePoint)
+\subsection{Anwendungsfall}
-% Zum Parsen einfach schnell einen eigenen INI Parser selber geschrieben als auf eine 3rd party dependency einzubinden.
+
-% Abbildung~\ref{fig:url-file-parsing}
+Nicht alle Unterlagen lassen sich sinnvoll in den Speicher kopieren. Ein fortlaufend gepflegtes Dokument oder ein Kanal in einem Kollaborationswerkzeug soll verlinkt werden — eine Kopie wäre sofort veraltet. Dafür werden \texttt{.url}-Dateien unterstützt: kleine Textdateien im INI-Format mit Zieladresse und optionalem Symbol. In der Liste erscheinen sie wie gewöhnliche Dokumente, führen beim Anklicken jedoch auf die hinterlegte Adresse.
+
+Der Anwendungsfall wurde in der Feature-Analyse geklärt: Gemeint ist das Einbetten \emph{externer} Ressourcen, nicht das Teilen von Houston-Dokumenten nach außen (siehe Abschnitt~\ref{sec:feature-analysis}).
+
+\subsection{Auswertung des Dateiformats}
+
+Für das INI-Format wurde bewusst keine externe Bibliothek eingebunden. Benötigt wird ein einziger Wert aus einem Abschnitt. Eine Bibliothek brächte eine dauerhaft zu pflegende Abhängigkeit für Funktionalität, die in wenigen Zeilen selbst geschrieben ist. Zudem würde sie bei fehlerhaften Dateien vermutlich einen Fehler melden, während hier ein stiller Rückfall erforderlich ist.
+
+\subsection{Rückfall auf normales Verhalten}
+
+Kann keine gültige Adresse erkannt werden, wird die Datei wie eine gewöhnliche Datei zum Herunterladen angeboten. Eine fehlerhafte Verknüpfungsdatei darf das Dokument nicht unzugänglich machen.
+
+\subsection{Anzeigename}
+
+Die Endung \texttt{.url} wird für die Anzeige entfernt. Im Review wies \emph{Robin Noack} darauf hin, dass die dafür verwendete Zeichenzahl als unmittelbare Zahl im Code stand; stattdessen sollte die Länge der Endung selbst verwendet werden, da Zahl und Endung an verschiedenen Stellen stehen und bei einer Änderung auseinanderlaufen können.
+
+\subsection{Symbole für Verknüpfungen}
+
+Da benutzerdefinierte Symbole aus den in Abschnitt~\ref{sec:pdf-preview} genannten Gründen nicht ausgeliefert werden, stehen stattdessen benannte Voreinstellungen zur Verfügung, die auf Symbole der in Houston vorhandenen Bibliothek verweisen. Für die häufigsten Ziele — Dateiablage, Dokumentenverwaltungssystem und Kollaborationswerkzeug — wurden eigene Symbole ergänzt. Die verfügbaren Namen wurden im internen Wiki dokumentiert und im Pull Request darauf verwiesen.
+
+\subsection{Ausschluss vom ZIP-Download}
+
+Verknüpfungsdateien erhalten keine Auswahlbox und können nicht Teil eines Archivs werden. Ein Archiv enthielte sonst eine Datei, die beim Öffnen eine möglicherweise nur intern auflösbare Verknüpfung liefert. Da eine Verknüpfung fachlich kein Dokument ist, wäre ihre Aufnahme irreführend.

chapters/overview/initial-situation.tex

@@ -1,9 +1,9 @@
 \section{Ausgangssituation}
 \label{sec:initial-situation}
 
-Die Idee, Kunden über Houston Zugang zu ihren Dokumenten zu ermöglichen, besteht seit November 2023: \emph{Nicole Kimmel} legte damals das Feature~484 „Dokumente" mit zwei Stichpunkten an — „Vertrag, Betriebshandbuch, Feinkonzepte an zentraler Stelle abgelegt" und „Rechnungen einsehbar". Diese Notiz blieb über zweieinhalb Jahre nahezu unverändert im Backlog und spiegelt die damaligen Bedürfnisse wider, ohne einen konkreten Lösungsansatz zu beschreiben.
+Die Idee besteht seit November 2023: \emph{Nicole Kimmel} legte damals das Feature~484 „Dokumente" mit zwei Stichpunkten an — „Vertrag, Betriebshandbuch, Feinkonzepte an zentraler Stelle abgelegt" und „Rechnungen einsehbar". Diese Notiz blieb über zweieinhalb Jahre unverändert im Backlog, ohne einen konkreten Lösungsansatz zu beschreiben.
 
-Zum Zeitpunkt des Projektbeginns im Sommer 2026 gab es keinen strukturierten Prozess, über den Kunden selbstständig auf ihre Dokumente zugreifen konnten. Verträge, Berichte und ähnliche Unterlagen wurden punktuell per E-Mail oder über Dateiablagen bereitgestellt. Daraus ergaben sich mehrere Probleme:
+Zum Projektbeginn im Sommer 2026 wurden Verträge, Berichte und ähnliche Unterlagen punktuell per E-Mail oder Dateiablage bereitgestellt. Daraus ergaben sich mehrere Probleme:
 
 \begin{itemize}
     \item \textbf{Fehlende Zentralisierung:} Dokumente lagen verteilt in E-Mails, Dateiablagen und lokalen Verzeichnissen ohne einheitlichen Zugangspunkt.
@@ -12,4 +12,4 @@ Zum Zeitpunkt des Projektbeginns im Sommer 2026 gab es keinen strukturierten Pro
     \item \textbf{Kein sicherer, mandantengetrennter Zugriff:} Es existierte kein technischer Mechanismus, der sicherstellte, dass ein Kunde ausschließlich seine eigenen Dokumente einsehen konnte.
 \end{itemize}
 
-Auf technischer Seite war kein geeigneter S3-Speicher provisioniert und die Houston-Anwendung kannte keine Verbindung zu einem externen Objektspeicher. Die Bereitstellung der notwendigen Infrastruktur — drei S3-Buckets (DEV, TEST, PROD) bei Advanced Unibyte auf Basis von NetApp StorageGRID — musste erst im Laufe des Projekts beantragt und eingerichtet werden.
+Auf technischer Seite war kein S3-Speicher provisioniert. Die Bereitstellung der notwendigen Infrastruktur — drei S3-Buckets (DEV, TEST, PROD) bei Advanced Unibyte auf Basis von NetApp StorageGRID — musste erst im Projektverlauf beantragt werden.

chapters/overview/participants.tex

@@ -1,19 +1,13 @@
 \section{Projektbeteiligte}
 \label{sec:participants}
 
-Das Projekt wurde durch eine strukturierte Zusammenarbeit verschiedener Beteiligter mit klar definierten Rollen umgesetzt.
+Als \textbf{Praktikant und Entwickler} (\emph{Linus Nagel}) war ich für Anforderungsklärung, Konzeption, Implementierung aller Product Backlog Items, Akzeptanzkriterien und Dokumentation verantwortlich.
 
-In meiner Rolle als \textbf{Praktikant und Entwickler} (\emph{Linus Nagel}) war ich für die gesamte technische Umsetzung verantwortlich: Anforderungsklärung, Konzeption, Implementierung aller Product Backlog Items, das Verfassen der Akzeptanzkriterien und die Erstellung dieser Dokumentation.
+\emph{Sarah Hinzmann} übernahm die \textbf{betriebliche Betreuung}, koordinierte Abstimmungen und war an Code-Reviews der Abschlussphase beteiligt. \emph{Thomas Drewermann} fungierte als \textbf{Product Owner}: Er arbeitete das Feature~484 im Juni 2026 aus, definierte den Umfang und beantwortete Rückfragen.
 
-Die \textbf{betriebliche Betreuung} übernahm \emph{Sarah Hinzmann}. Sie koordinierte die Abstimmungen, begleitete das Projekt von der Themenvergabe bis zur Abgabe und war an Code-Reviews der Abschlussphase beteiligt.
+Die \textbf{technische Qualitätssicherung} lag beim Team der Unicorn Development: \emph{Timo Walter} (Code-Reviews der frühen PRs, Architektur-Rückfragen), \emph{Robin Noack} (Reviews der Schlussphase), \emph{Hanna Ebner} (UI-Konzept und Clickdummy). \emph{Maria-Lena Andersz} führte die \textbf{Abnahmetests} durch.
 
-Als \textbf{Product Owner und fachlicher Ansprechpartner} fungierte \emph{Thomas Drewermann}. Er arbeitete das Feature~484 im Juni 2026 vollständig aus, definierte den Umfang, beantwortete Rückfragen während der Feature-Analyse und begleitete den Projektverlauf fachlich.
+Weitere Beteiligte: \emph{Stephan Janßen} (Schätzung, Backlog-Pflege), \emph{Christiana Sobik} (Backlog-Pflege), \emph{Bianco Veigel} (Sprint-Planung), \emph{Nicole Kimmel} (ursprüngliche Anforderung, 2023).
-
-Die \textbf{technische Qualitätssicherung} übernahm das Entwicklerteam der Unicorn Development: \emph{Timo Walter} führte die Code-Reviews der frühen Pull Requests durch und stellte Rückfragen zu Architekturentscheidungen; \emph{Robin Noack} übernahm die Reviews in der Schlussphase. \emph{Hanna Ebner} erarbeitete das UI-Konzept und den Clickdummy. Das gesamte Team war an der Aufwandsschätzung der Product Backlog Items beteiligt.
-
-Die \textbf{Abnahmetests} wurden durch \emph{Maria-Lena Andersz} durchgeführt.
-
-Weitere Beteiligte in unterstützenden Rollen: \emph{Stephan Janßen} (Schätzung und Backlog-Pflege), \emph{Christiana Sobik} (Backlog-Pflege), \emph{Bianco Veigel} (Sprint-Planung), \emph{Nicole Kimmel} (ursprüngliche Anforderung, 2023).
 
 \begin{table}[H]
 \centering

chapters/overview/project-description.tex

@@ -1,10 +1,8 @@
 \section{Projektbeschreibung}
 \label{sec:project-description}
 
-Das Projekt \emph{Houston Dokumente} hat zum Ziel, Kunden im Kundenportal Houston einen zentralen Bereich bereitzustellen, in dem sie ihre Dokumente einsehen und herunterladen können. Die Dokumente werden in einem S3-Speichersystem abgelegt und gepflegt; den Kunden werden sie über eine neue Houston-Seite zugänglich gemacht.
+Das Projekt \emph{Houston Dokumente} stellt Kunden im Kundenportal Houston einen zentralen Bereich bereit, in dem sie ihre Dokumente einsehen und herunterladen können. Die Dokumente werden in einem S3-Speicher abgelegt; Mitarbeiter pflegen sie über das interne Dateiverwaltungswerkzeug Filestash, Kunden rufen sie über eine neue Houston-Seite strukturiert ab.
 
-Bisher existierte kein einheitlicher, zentraler Zugangspunkt für kundenbezogene Dokumente wie Verträge, Berichte oder Protokolle. Diese wurden punktuell per E-Mail oder Dateiablage bereitgestellt und waren für Kunden nicht selbstständig abrufbar. Die neue Dokumentenseite in Houston löst diese Situation ab: Mitarbeiter pflegen die Dokumente über ein internes Dateiverwaltungswerkzeug direkt im S3-Speicher, Kunden können sie anschließend strukturiert abrufen.
+Der Dokumentenbereich unterscheidet sieben fachlich definierte Dokumententypen — darunter Service-Protokolle, SLA-Reports, Monitoring Reports und Vertragsunterlagen. Weitere Funktionen sind Suche, Typfilter, Paginierung, PDF-Viewer, Einzel- und ZIP-Download sowie URL-Dateien, mit denen beliebige Webadressen in der Dokumentenliste verknüpft werden können.
 
-Der Dokumentenbereich unterscheidet sieben fachlich definierte Dokumententypen — darunter Service-Protokolle, SLA-Reports, Monitoring Reports und Vertragsunterlagen — und gliedert die Anzeige anhand dieser Typen. Darüber hinaus umfasst das Projekt eine Suchfunktion, Filter nach Dokumententyp, Paginierung, einen PDF-Viewer, den Download einzelner Dateien sowie das Herunterladen mehrerer Dokumente als ZIP-Archiv. Zusätzlich werden sogenannte URL-Dateien unterstützt, mit denen beliebige Webadressen — etwa Links zu Teams-Kanälen oder SharePoint-Seiten — in der Dokumentenliste verknüpft werden können.
+Technisch umfasst das Projekt die Anbindung an den S3-Speicher über das AWS SDK für .NET, ein rollenbasiertes Berechtigungskonzept über Microsoft Entra~ID sowie die automatische Anlage der Ordnerstruktur beim ersten Seitenaufruf. Schreibzugriffe durch Kunden sind nicht vorgesehen; dies bleibt Aufgabe der internen Mitarbeiter.
-
-Das Projekt umfasst die vollständige Integration des Dokumentenbereichs in die bestehende Houston-Webanwendung. Dazu zählen die Anbindung an den S3-Speicher über das AWS SDK für .NET, ein rollenbasiertes Berechtigungskonzept über Microsoft Entra~ID sowie die automatische Anlage der Ordnerstruktur für neue Kunden beim ersten Seitenaufruf. Nicht Bestandteil des Projekts sind Schreibzugriffe durch Kunden sowie die Anlage oder Bearbeitung von Dokumenten durch den Kunden selbst; dies bleibt Aufgabe der internen Mitarbeiter über das Dateiverwaltungswerkzeug.

chapters/overview/project-scope.tex

@@ -4,8 +4,8 @@
 Folgende Punkte sind explizit \emph{nicht} Bestandteil des Projekts:
 
 \begin{itemize}
-    \item \textbf{Kein Schreibzugriff für Kunden:} Kunden können Dokumente ausschließlich einsehen und herunterladen. Das Hochladen, Bearbeiten oder Löschen von Dokumenten durch den Kunden ist nicht vorgesehen.
+    \item \textbf{Kein Schreibzugriff für Kunden:} Kunden können Dokumente ausschließlich einsehen und herunterladen.
-    \item \textbf{Kein internes Upload-UI in Houston:} Das Hochladen und Verwalten von Dokumenten durch WorkSimple-Mitarbeiter erfolgt ausschließlich über Filestash, einen externen S3-Browser. Eine eigene Upload-Oberfläche in Houston wurde nicht entwickelt.
+    \item \textbf{Kein internes Upload-UI in Houston:} Die Dokumentenverwaltung durch Mitarbeiter erfolgt ausschließlich über Filestash.
-    \item \textbf{Keine freie Ordnerstruktur intern:} Interne Mitarbeiter können über Filestash keine beliebigen Ordner anlegen, die dem Kunden angezeigt werden. Nur die sieben definierten Typordner sind für Kunden sichtbar; weitere Ordner werden ignoriert.
+    \item \textbf{Keine freie Ordnerstruktur intern:} Nur die sieben definierten Typordner sind für Kunden sichtbar; weitere Ordner werden ignoriert.
     \item \textbf{Keine Dashboard-Kacheln im PidI-Umfang:} Geplante Erweiterungen wie Dashboard-Kacheln für Tenant-Härtung aus Security-Assessment-Metadaten oder eine Anzeige zuletzt hinzugefügter Dokumente sind als Feature-Creep im Backlog erfasst, aber nicht Teil des PidI-Projekts.
 \end{itemize}

chapters/overview/system-landscape.tex

@@ -1,7 +1,7 @@
 \section{Systemlandschaft}
 \label{sec:system-landscape}
 
-Der Dokumentenbereich ist in die bestehende Systemlandschaft von WorkSimple eingebettet. Abbildung~\ref{fig:system-context} zeigt den Systemkontext und das Zusammenspiel der beteiligten Systeme.
+Abbildung~\ref{fig:system-context} zeigt den Systemkontext des Dokumentenbereichs.
 
 \begin{figure}[H]
     \centering
@@ -10,12 +10,12 @@ Der Dokumentenbereich ist in die bestehende Systemlandschaft von WorkSimple eing
     \label{fig:system-context}
 \end{figure}
 
-\textbf{Houston} ist das Kundenportal von WorkSimple. Es ist als ASP.NET-Core-Webanwendung mit Razor Pages implementiert und aggregiert Informationen aus mehreren internen Systemen zu einer einheitlichen Oberfläche für Kunden. Im Rahmen dieses Projekts wurde Houston um den Dokumentenbereich erweitert.
+\textbf{Houston} ist das Kundenportal von WorkSimple, implementiert als ASP.NET-Core-Webanwendung mit Razor Pages. Es wurde im Rahmen dieses Projekts um den Dokumentenbereich erweitert.
 
-\textbf{Efecte} ist das unternehmenseigene ITSM-Tool (IT Service Management). Es dient als zentrale Datenbasis für Kundeninformationen, darunter die eindeutige Organisations-ID jedes Kunden (\texttt{efecte-org-id}), die im Rahmen des Projekts als Autorisierungsmerkmal für den Zugriff auf den richtigen S3-Kundenordner verwendet wird.
+\textbf{Efecte} ist das ITSM-Tool des Unternehmens und liefert die eindeutige Organisations-ID jedes Kunden (\texttt{efecte-org-id}), die als Autorisierungsmerkmal für den S3-Kundenordner dient.
 
-\textbf{Microsoft Entra~ID} (ehemals Azure~AD) übernimmt die Authentifizierung und Autorisierung der Benutzer. Nach erfolgreicher Anmeldung erhält Houston ein Token, das unter anderem die Efecte-Organisations-ID und die zugewiesenen Anwendungsrollen des Benutzers enthält. Die neu eingeführte Rolle \texttt{Documents.Read} steuert den Zugriff auf den Dokumentenbereich.
+\textbf{Microsoft Entra~ID} (ehemals Azure~AD) übernimmt Authentifizierung und Autorisierung. Das Token enthält die Efecte-Organisations-ID und die Anwendungsrollen; die Rolle \texttt{Documents.Read} steuert den Zugriff auf den Dokumentenbereich.
 
-\textbf{S3-Speicher (NetApp StorageGRID)} ist die Ablage für alle Kundendokumente. Er wird von Advanced Unibyte betrieben und ist S3-kompatibel. Houston greift über das AWS SDK für .NET auf den Speicher zu. Jeder Kunde erhält einen eigenen Ordner im Bucket, der über ein S3-Objekt-Metadatum (\texttt{efecte-org-id}) identifiziert wird.
+\textbf{S3-Speicher (NetApp StorageGRID)} ist die von Advanced Unibyte betriebene, S3-kompatible Ablage für Kundendokumente. Houston greift über das AWS SDK für .NET darauf zu. Jeder Kunde erhält einen eigenen Ordner, identifiziert über ein S3-Metadatum (\texttt{efecte-org-id}).
 
-\textbf{Filestash} ist ein webbasierter S3-Browser, der intern von WorkSimple-Mitarbeitern genutzt wird, um Dokumente in den S3-Speicher hochzuladen und zu verwalten. Filestash ist eine externe Anwendung und kein Bestandteil der Houston-Entwicklung.
+\textbf{Filestash} ist ein webbasierter S3-Browser, den WorkSimple-Mitarbeiter intern zum Hochladen und Verwalten von Dokumenten nutzen.

chapters/overview/target-situation.tex

@@ -1,20 +1,18 @@
 \section{Zielsituation}
 \label{sec:target-situation}
 
-Mit der Fertigstellung des Dokumentenbereichs erhalten Kunden im Kundenportal Houston erstmals einen strukturierten, selbstständig nutzbaren Zugang zu ihren Dokumenten. Die Zielsituation zeichnet sich durch eine zentrale Ablage im S3-Speicher und eine mandantengetrennte Darstellung in Houston aus.
+Der Dokumentenbereich bietet folgende Funktionen:
-
-Der Dokumentenbereich bietet folgende zentrale Funktionen:
 
 \begin{itemize}
-    \item \textbf{Document Explorer:} Auf der Seite \texttt{/documents} werden alle Dokumente des Kunden als Liste dargestellt, gegliedert nach sieben fachlich definierten Dokumententypen (Service-Protokoll, Abnahme-Dokumente, SLA-Reports Ticketbearbeitung, Monitoring Reports, Security Assessments, Abrechnungsdaten, Vertragsunterlagen). Leere Ordner werden nicht angezeigt.
+    \item \textbf{Document Explorer:} Auf \texttt{/documents} werden alle Dokumente des Kunden als Liste dargestellt, gegliedert nach sieben Dokumententypen. Leere Ordner werden nicht angezeigt.
-    \item \textbf{Typfilter und Suche:} Dokumente können nach Typ gefiltert und titelbasiert serverseitig durchsucht werden.
+    \item \textbf{Typfilter und Suche:} Filterung nach Typ und titelbasierte serverseitige Suche.
-    \item \textbf{Paginierung:} Große Dokumentenmengen werden seitenweise dargestellt.
+    \item \textbf{Paginierung:} Seitenweise Darstellung großer Dokumentenmengen.
-    \item \textbf{Downloads:} Einzelne Dokumente lassen sich direkt herunterladen; mehrere Dokumente können als ZIP-Archiv gebündelt heruntergeladen werden.
+    \item \textbf{Downloads:} Einzeldownload sowie ZIP-Download mehrerer ausgewählter Dokumente.
-    \item \textbf{PDF-Vorschau:} PDF-Dokumente können in einem modalen Viewer direkt im Browser angezeigt werden.
+    \item \textbf{PDF-Vorschau:} Anzeige von PDF-Dokumenten in einem modalen Viewer.
-    \item \textbf{Share-Link-Previews:} Für einzelne Dokumente können zeitlich begrenzte Freigabelinks erzeugt werden.
+    \item \textbf{Share-Link-Previews:} Erzeugung zeitlich begrenzter Freigabelinks.
     \item \textbf{URL-Dateien:} Spezielle \texttt{.url}-Dateien ermöglichen die Verlinkung beliebiger Webadressen — z.\,B. Teams-Kanäle oder SharePoint-Seiten — in der Dokumentenliste.
     \item \textbf{Mandantentrennung:} Jeder Kunde sieht ausschließlich die Dokumente in seinem eigenen S3-Ordner, der über die \texttt{efecte-org-id} aus dem Authentifizierungstoken identifiziert wird.
     \item \textbf{Automatische Ordneranlage:} Beim ersten Aufruf der Dokumentenseite wird die vollständige Ordnerstruktur für den Kunden im S3 angelegt, sofern sie noch nicht existiert.
 \end{itemize}
 
-Die Pflege der Dokumente erfolgt weiterhin durch WorkSimple-Mitarbeiter über Filestash, den internen S3-Browser. Kunden haben ausschließlich lesenden Zugriff.
+Kunden haben ausschließlich lesenden Zugriff; die Pflege erfolgt durch Mitarbeiter über Filestash.

chapters/planning/backlog.tex

@@ -3,7 +3,7 @@
 
 \subsection{Entwicklungsprozess}
 
-Die Softwareentwicklung bei der Unicorn Development erfolgt nach einem agilen Prozess mit zweiwöchigen Sprints, verwaltet in Azure DevOps. Jedes Work Item durchläuft dabei einen definierten Zustandsautomaten, der in Abbildung~\ref{fig:ado-workflow} dargestellt ist.
+Die Unicorn Development arbeitet agil mit zweiwöchigen Sprints in Azure DevOps. Jedes Work Item durchläuft den in Abbildung~\ref{fig:ado-workflow} dargestellten Zustandsautomaten.
 
 \begin{figure}[H]
     \centering
@@ -12,16 +12,16 @@ Die Softwareentwicklung bei der Unicorn Development erfolgt nach einem agilen Pr
     \label{fig:ado-workflow}
 \end{figure}
 
-Ein neu angelegtes Item befindet sich zunächst im Zustand \texttt{New}. Sobald Beschreibung und Akzeptanzkriterien vollständig sind, wird es zur Freigabe eingereicht (\texttt{To Approve}). Im Approval-Termin prüft das Team, ob das Item der \emph{Definition of Ready} genügt, stellt Rückfragen und schätzt den Aufwand in Story Points. Erst danach gilt es als \texttt{Approved} und kann in einen Sprint gezogen werden (\texttt{Committed}). Nach erfolgreichem Merge des zugehörigen Pull Requests wechselt das Item nach \texttt{Dev Completed}; die fachliche Abnahme überführt es schließlich nach \texttt{Test Completed}.
+Ein neues Item steht auf \texttt{New} und wird nach vollständiger Beschreibung zur Freigabe eingereicht (\texttt{To Approve}). Im Approval-Termin prüft das Team die \emph{Definition of Ready}, stellt Rückfragen und schätzt Story Points; danach gilt es als \texttt{Approved} und kann in einen Sprint gezogen werden (\texttt{Committed}). Nach dem Merge wechselt es zu \texttt{Dev Completed}; die Abnahme überführt es nach \texttt{Test Completed}.
 
-Dieser Prozess erwies sich im Projektverlauf als wirksam: Die Rückfragen im Approval-Termin — insbesondere durch \emph{Timo Walter} — deckten mehrfach Lücken in den Akzeptanzkriterien auf, etwa zur Frage, wann und wie oft die Ordnerstruktur geprüft wird, oder ob Namensbeschränkungen für Kundenordner zu berücksichtigen sind.
+Rückfragen im Approval-Termin — insbesondere durch \emph{Timo Walter} — deckten mehrfach Lücken in den Akzeptanzkriterien auf, etwa zur Häufigkeit der Ordnerstrukturprüfung oder zu Namensbeschränkungen.
 
 \subsection{Schnitt der Product Backlog Items}
 
-Der Backlog-Schnitt erfolgte in zwei Phasen. Am 18.~Juni 2026 — unmittelbar nach der Feature-Analyse — wurden die acht Items der Kernfunktionalität angelegt. Sie orientieren sich direkt an der Gliederung der Feature-Beschreibung: Der Document Explorer bildet die Basis, die im Abschnitt \emph{Feature-Creep} genannten Punkte (Suche, Einzeldownload, ZIP-Download, PDF-Modal, URL-Dateien) wurden jeweils zu eigenen Items. Am 7.~Juli 2026 kam das Item zur Typisierung über Icons hinzu, am 8.~Juli das Item zur automatischen Ordneranlage.
+Der Backlog-Schnitt erfolgte in zwei Phasen. Am 18.~Juni 2026 wurden acht Kern-Items angelegt, orientiert an der Feature-Beschreibung: Document Explorer als Basis, die \emph{Feature-Creep}-Punkte (Suche, Einzeldownload, ZIP-Download, PDF-Modal, URL-Dateien) als eigene Items. Am 7.~Juli kam die Typisierung über Icons hinzu, am 8.~Juli die automatische Ordneranlage.
 
-Eine zweite Gruppe von Items entstand erst während der Umsetzung. Am 22.~Juli ergänzte die UI-Zuarbeit die Anforderungen um Paginierung und Typfilter. Am 28.~Juli wurde die Recherche zur Optimierung der S3-Abfrage angelegt, deren Ergebnis am 12.~August in das Item zum Kundenordner-Lookup mündete. Am 17.~August kam schließlich das Item zu den Race Conditions hinzu (siehe Abschnitt~\ref{sec:race-conditions}).
+Eine zweite Gruppe entstand während der Umsetzung: Am 22.~Juli ergänzte die UI-Zuarbeit Paginierung und Typfilter. Am 28.~Juli wurde die Recherche zur Optimierung der S3-Abfrage angelegt, deren Ergebnis am 12.~August in das Kundenordner-Lookup-Item mündete. Am 17.~August kam das Item zu Race Conditions hinzu (siehe Abschnitt~\ref{sec:race-conditions}).
 
-Insgesamt hängen 14 Product Backlog Items und ein Bug am Feature. Die vollständige Übersicht mit Aufwandsschätzung, Sprint und Status findet sich in Tabelle~\ref{tab:backlog} im Anhang. Die geschätzten Aufwände summieren sich auf 46 Story Points, verteilt auf 35 Punkte in Sprint~15.2026 und 11 Punkte in Sprint~16.2026.
+Insgesamt hängen 14 Product Backlog Items und ein Bug am Feature (Tabelle~\ref{tab:backlog} im Anhang). Die geschätzten Aufwände summieren sich auf 46 Story Points: 35 in Sprint~15.2026, 11 in Sprint~16.2026.
 
-Bemerkenswert ist die Aufteilung: Die im Voraus geschnittenen Items betreffen ausschließlich fachliche Funktionen. Sämtliche nachgeschobenen Items der zweiten Gruppe entstanden aus technischen Problemen, die erst bei der Implementierung sichtbar wurden — ein Muster, das in Abschnitt~\ref{sec:reflection} aufgegriffen wird.
+Die vorgeschnittenen Items betreffen ausschließlich fachliche Funktionen; alle nachgeschobenen entstanden aus technischen Problemen bei der Implementierung — ein Muster, das in Abschnitt~\ref{sec:reflection} aufgegriffen wird.

chapters/planning/feature-analysis.tex

@@ -1,15 +1,15 @@
 \section{Feature-Analyse}
 \label{sec:feature-analysis}
 
-Das Feature~484 „Dokumente" existierte seit November 2023 als zweizeilige Bedarfsnotiz im Backlog. Am 10.~Juni 2026 arbeitete \emph{Thomas Drewermann} es in mehreren aufeinanderfolgenden Bearbeitungen zu einer vollständigen Feature-Beschreibung aus. Dabei entstanden die Entscheidung für einen S3-Speicher als Ablage, die Festlegung auf Filestash als internes Verwaltungswerkzeug, der Katalog der sieben Dokumententypen sowie die Abschnitte \emph{Feature-Creep} und \emph{Out of Scope}.
+Das Feature~484 „Dokumente" existierte seit November 2023 als zweizeilige Bedarfsnotiz. Am 10.~Juni 2026 arbeitete \emph{Thomas Drewermann} es zu einer vollständigen Feature-Beschreibung aus — einschließlich S3, Filestash als Verwaltungswerkzeug, den sieben Dokumententypen sowie den Abschnitten \emph{Feature-Creep} und \emph{Out of Scope}.
 
-Am 18.~Juni 2026 führte ich eine Feature-Analyse durch, um die verbliebenen Unklarheiten vor dem Backlog-Schnitt zu beseitigen. Vier Rückfragen wurden als Kommentare am Work Item gestellt und noch am selben Tag beantwortet. Drei davon entschieden Architekturfragen:
+Am 18.~Juni 2026 führte ich die Feature-Analyse durch. Vier Rückfragen wurden als Kommentare gestellt und am selben Tag beantwortet; drei entschieden Architekturfragen:
 
 \begin{enumerate}
-    \item \textbf{Autorisierung über Metadaten:} Auf die Frage, ob die Efecte-Organisations-ID als Metadatum am Kundenordner gespeichert und die Berechtigung darüber aufgelöst werden könne, lautete die Antwort \emph{ja}. Damit war das Autorisierungskonzept festgelegt (siehe Abschnitt~\ref{sec:authorization}).
+    \item \textbf{Autorisierung über Metadaten:} Die Efecte-Organisations-ID wird als Metadatum am Kundenordner gespeichert; die Berechtigung wird darüber aufgelöst (siehe Abschnitt~\ref{sec:authorization}).
-    \item \textbf{Filestash als externes Werkzeug:} Es wurde bestätigt, dass Filestash unverändert als Verwaltungsoberfläche genutzt wird und \emph{nicht} als Referenz für einen Nachbau in Houston dient. Damit beschränkte sich der Implementierungsaufwand auf die Kundensicht.
+    \item \textbf{Filestash als externes Werkzeug:} Filestash dient unverändert als Verwaltungsoberfläche, \emph{nicht} als Referenz für einen Nachbau in Houston.
-    \item \textbf{Typisierung über Ordner statt Metadaten:} Auf die Frage, ob der Dokumententyp als Metafeld an der Datei vermerkt werden solle, lautete die Antwort \emph{nein, Ordner}. Der Typ wird also über den Unterordner bestimmt, in dem das Dokument liegt.
+    \item \textbf{Typisierung über Ordner statt Metadaten:} Der Dokumententyp wird über den Unterordner bestimmt, nicht als Metafeld an der Datei.
-    \item \textbf{Bedeutung der URL-Dateien:} Die vierte Frage klärte, dass mit der Verlinkung zu Teams oder SharePoint gemeint ist, \emph{externe} Ressourcen in den Dokumentenbereich einzubetten — und nicht umgekehrt Houston-Dokumente nach außen zu teilen. Daraus entstand das Product Backlog Item zur Unterstützung von \texttt{.url}-Dateien.
+    \item \textbf{Bedeutung der URL-Dateien:} Gemeint ist das Einbetten \emph{externer} Ressourcen in den Dokumentenbereich, nicht das Teilen von Houston-Dokumenten nach außen.
 \end{enumerate}
 
-Die dritte Entscheidung erwies sich im weiteren Verlauf als die folgenreichste. Die Abbildung des Typs über die Ordnerstruktur macht die Filterung nach Typ günstig, da sie sich auf ein Präfix-Listing reduziert. Sie erzwingt jedoch, dass die Ordnerstruktur für jeden Kunden vorhanden ist, und macht damit die automatische Anlage der Ordner zu einer eigenen Anforderung. Zugleich erschwert sie die typübergreifende Suche, da hierfür mehrere Präfixe durchlaufen werden müssen.
+Die dritte Entscheidung erwies sich als die folgenreichste: Die Typabbildung über Ordner macht die Filterung günstig (Präfix-Listing), erzwingt aber die automatische Anlage der Ordnerstruktur und erschwert die typübergreifende Suche.

chapters/planning/infrastructure.tex

@@ -1,7 +1,7 @@
 \section{Beschaffung der S3-Infrastruktur}
 \label{sec:infrastructure}
 
-Der für das Projekt benötigte S3-Speicher stand zu Projektbeginn nicht zur Verfügung und musste über den internen Service-Desk-Prozess beantragt werden. Da der Speicher nicht von WorkSimple selbst, sondern von Advanced Unibyte betrieben wird, war die Beschaffung mit einem mehrstufigen Abstimmungsweg verbunden. Abbildung~\ref{fig:timeline-infra} zeigt den zeitlichen Verlauf.
+Der S3-Speicher stand zu Projektbeginn nicht bereit und musste über den Service-Desk beantragt werden. Da Advanced Unibyte ihn betreibt, war ein mehrstufiger Abstimmungsweg nötig. Abbildung~\ref{fig:timeline-infra} zeigt den Verlauf.
 
 \begin{figure}[H]
     \centering
@@ -12,23 +12,23 @@ Der für das Projekt benötigte S3-Speicher stand zu Projektbeginn nicht zur Ver
 
 \subsection{Bereitstellung der Buckets}
 
-Am 22.~Juli 2026 stellte ich den Service Request „Houston DEV S3 Documents Speicher" an das interne Infrastruktur-Team. Der Request wurde am 23.~Juli \emph{Alexander Wagner} zugewiesen und am 27.~Juli abgeschlossen: Advanced Unibyte hatte die Buckets angelegt, die Zugangsdaten wurden im Passwortmanager Passbolt hinterlegt. Insgesamt wurden drei Buckets bereitgestellt — je einer für die Entwicklungs-, Test- und Produktivumgebung.
+Am 22.~Juli 2026 stellte ich den Service Request. Er wurde am 23.~Juli \emph{Alexander Wagner} zugewiesen und am 27.~Juli abgeschlossen: drei Buckets (DEV, TEST, PROD) waren angelegt, die Zugangsdaten in Passbolt hinterlegt.
 
-Vom Antrag bis zur Verfügbarkeit vergingen fünf Arbeitstage. Da der Document Explorer als erstes Item ohnehin erst am 27.~Juli in die Umsetzung ging, entstand hieraus keine Verzögerung.
+Da der Document Explorer ohnehin erst am 27.~Juli in die Umsetzung ging, entstand keine Verzögerung.
 
 \subsection{Freischaltung zusätzlicher Funktionen}
 
-Deutlich aufwendiger gestaltete sich die Klärung, welche S3-Funktionen die StorageGRID-Installation tatsächlich unterstützt. Im Rahmen der Recherche zur Optimierung des Kundenordner-Lookups (siehe Abschnitt~\ref{sec:lookup-research}) kamen zwei Funktionen als mögliche Lösungen in Betracht:
+Aufwendiger war die Klärung der verfügbaren S3-Funktionen. Im Rahmen der Lookup-Recherche (siehe Abschnitt~\ref{sec:lookup-research}) kamen zwei in Betracht:
 
 \begin{itemize}
     \item \textbf{S3 Select} (\texttt{SelectObjectContent}) erlaubt es, Inhalte einzelner Objekte serverseitig per SQL-ähnlicher Abfrage zu filtern \autocite{aws-s3-select, storagegrid-s3-select}.
     \item Der \textbf{Search Integration Service} von StorageGRID spiegelt Objektmetadaten in einen Elasticsearch-Index und ermöglicht dadurch eine echte Suche über Metadaten \autocite{storagegrid-search-integration}.
 \end{itemize}
 
-Am 30.~Juli beantragte ich die Freischaltung beider Funktionen. Da hierfür der Betreiber einbezogen werden musste, kontaktierte \emph{Lennart Meinert} am 4.~August Advanced Unibyte. Am 6.~August benannte er die drei betroffenen Buckets, am 7.~August bestätigte Advanced Unibyte die Aktivierung von S3 Select für alle drei Umgebungen.
+Am 30.~Juli beantragte ich die Freischaltung beider Funktionen. \emph{Lennart Meinert} kontaktierte am 4.~August Advanced Unibyte; am 7.~August wurde S3 Select für alle drei Umgebungen aktiviert.
 
-Für den Search Integration Service fiel die Antwort anders aus: Am 17.~August teilte Advanced Unibyte mit, dass diese Funktion derzeit nicht angeboten werde; das Thema wurde intern an den dortigen Product Owner eskaliert. Am 21.~August schlug Advanced Unibyte ein Folgegespräch vor. Da zu diesem Zeitpunkt bereits eine Lösung ohne serverseitige Suche gefunden und umgesetzt war (siehe Abschnitt~\ref{sec:lookup-decision}), wurde der Service Request geschlossen und das Thema in den Ausblick verschoben.
+Für den Search Integration Service teilte Advanced Unibyte am 17.~August mit, dass die Funktion derzeit nicht angeboten werde, und schlug am 21.~August ein Folgegespräch vor. Da bereits eine Lösung ohne serverseitige Suche umgesetzt war (siehe Abschnitt~\ref{sec:lookup-decision}), wurde der Request geschlossen.
 
 \subsection{Bewertung}
 
-Zwischen dem ersten Antrag und der abschließenden Klärung lagen vier Wochen. Diese Vorlaufzeit war zu Projektbeginn nicht eingeplant und beeinflusste die Architekturentscheidung unmittelbar: Ein Lösungsansatz, der auf einer erst noch zu beschaffenden Fremdleistung beruht, ist innerhalb eines Projektzeitraums von wenigen Wochen nicht belastbar. Die schließlich gewählte Lösung kommt daher ohne Erweiterung der Speicherfunktionen aus.
+Zwischen erstem Antrag und abschließender Klärung lagen vier Wochen — zu Projektbeginn nicht eingeplant. Ein Lösungsansatz, der auf einer noch zu beschaffenden Fremdleistung beruht, ist innerhalb eines Projektzeitraums von wenigen Wochen nicht belastbar. Die gewählte Lösung kommt daher ohne Erweiterung der Speicherfunktionen aus.

chapters/planning/onboarding.tex

@@ -1,18 +1,18 @@
 \section{Einarbeitung}
 \label{sec:onboarding}
 
-Vor Beginn der Implementierung war eine Einarbeitung in die für das Projekt relevanten Technologien erforderlich. Im Zentrum stand dabei der S3-Objektspeicher, mit dem im bisherigen Verlauf des Praktikums noch nicht gearbeitet worden war.
+Vor der Implementierung war eine Einarbeitung in die projektrelevanten Technologien erforderlich, insbesondere S3.
 
 \subsection{S3 als Objektspeicher}
 
-S3 (\emph{Simple Storage Service}) ist kein klassisches Dateisystem, sondern ein Objektspeicher. Objekte werden über einen flachen Schlüsselraum adressiert; eine Ordnerhierarchie existiert technisch nicht. Was in Werkzeugen wie Filestash als Ordner dargestellt wird, ist lediglich ein Präfix im Objektschlüssel, das in Verbindung mit einem Trennzeichen (\texttt{Delimiter}) beim Auflisten hierarchisch interpretiert wird \autocite{aws-listobjectsv2}. Diese Eigenschaft prägt das gesamte Ablagekonzept (siehe Abschnitt~\ref{sec:s3-layout}) und war für mehrere spätere Architekturentscheidungen ausschlaggebend.
+S3 (\emph{Simple Storage Service}) ist ein Objektspeicher, kein Dateisystem. Objekte werden über einen flachen Schlüsselraum adressiert; was als Ordner erscheint, ist ein Präfix im Objektschlüssel, das per \texttt{Delimiter} hierarchisch interpretiert wird \autocite{aws-listobjectsv2}. Diese Eigenschaft prägt das Ablagekonzept (siehe Abschnitt~\ref{sec:s3-layout}) und war für mehrere Architekturentscheidungen ausschlaggebend.
 
-Eine zweite wesentliche Erkenntnis betrifft die Abfragemöglichkeiten: An Objekten können zwar benutzerdefinierte Metadaten hinterlegt werden, S3 bietet jedoch \emph{keine} Möglichkeit, Objekte anhand dieser Metadaten zu suchen. Ein Lookup nach einem Metadatenwert erfordert daher das Auflisten aller in Frage kommenden Objekte und eine anschließende clientseitige Filterung. Dieses Detail wurde erst im Verlauf der Implementierung zum zentralen technischen Problem des Projekts (siehe Abschnitt~\ref{sec:lookup-research}).
+S3 bietet zudem \emph{keine} Suche über benutzerdefinierte Metadaten. Ein Lookup erfordert das Auflisten aller Objekte mit clientseitiger Filterung — das zentrale technische Problem des Projekts (siehe Abschnitt~\ref{sec:lookup-research}).
 
 \subsection{AWS SDK für .NET}
 
-Der Zugriff auf den S3-Speicher erfolgt aus Houston heraus über das AWS SDK für .NET. Zentrale Schnittstelle ist \texttt{IAmazonS3}, über die sämtliche Operationen (\texttt{ListObjectsV2}, \texttt{GetObject}, \texttt{PutObject}, \texttt{CopyObject}, \texttt{DeleteObjects}) ausgeführt werden. Da \texttt{IAmazonS3} eine Schnittstelle ist, lässt sie sich in Unit-Tests durch ein Mock ersetzen, was für die spätere Testabdeckung des Kundenordner-Lookups entscheidend war (siehe Abschnitt~\ref{sec:unit-tests}).
+Der Zugriff erfolgt über \texttt{IAmazonS3} aus dem AWS SDK für .NET (\texttt{ListObjectsV2}, \texttt{GetObject}, \texttt{PutObject}, \texttt{CopyObject}, \texttt{DeleteObjects}). Da \texttt{IAmazonS3} eine Schnittstelle ist, lässt sie sich in Unit-Tests durch ein Mock ersetzen (siehe Abschnitt~\ref{sec:unit-tests}).
 
 \subsection{NetApp StorageGRID}
 
-Der eingesetzte Speicher wird nicht bei Amazon betrieben, sondern von Advanced Unibyte auf Basis von NetApp StorageGRID bereitgestellt. StorageGRID ist S3-kompatibel, implementiert die S3-API jedoch nicht vollständig. Welche Funktionen tatsächlich verfügbar sind, hängt von der Konfiguration der Installation ab und musste im Einzelfall geklärt werden. Diese Einschränkung betraf im Projektverlauf sowohl \texttt{SelectObjectContent} \autocite{storagegrid-s3-select} als auch den \emph{Search Integration Service} \autocite{storagegrid-search-integration} und führte zu den in Abschnitt~\ref{sec:infrastructure} beschriebenen Abstimmungen.
+Der Speicher wird von Advanced Unibyte auf Basis von NetApp StorageGRID betrieben. StorageGRID ist S3-kompatibel, implementiert die API jedoch nicht vollständig. Dies betraf im Projektverlauf \texttt{SelectObjectContent} \autocite{storagegrid-s3-select} und den \emph{Search Integration Service} \autocite{storagegrid-search-integration} und führte zu den in Abschnitt~\ref{sec:infrastructure} beschriebenen Abstimmungen.

chapters/planning/requirements.tex

@@ -1,33 +1,33 @@
 \section{Anforderungen}
 \label{sec:requirements}
 
-Aus der Feature-Beschreibung und der Analyse ergaben sich die folgenden Anforderungen. Die funktionalen Anforderungen wurden anschließend in Product Backlog Items überführt; die vollständige Zuordnung findet sich in Tabelle~\ref{tab:requirements} im Anhang.
+Aus Feature-Beschreibung und Analyse ergaben sich die folgenden Anforderungen (Zuordnung zu Backlog Items in Tabelle~\ref{tab:requirements} im Anhang).
 
 \subsection{Funktionale Anforderungen}
 
 \begin{itemize}
-    \item \textbf{FA-1 — Dokumentenliste:} Auf der Seite \texttt{/documents} werden alle Dokumente der Organisation des angemeldeten Benutzers als Liste dargestellt. Ordner selbst werden nicht als Einträge angezeigt; leere Typordner erscheinen nicht.
+    \item \textbf{FA-1 — Dokumentenliste:} Auf \texttt{/documents} werden alle Dokumente der Organisation aufgelistet; leere Typordner erscheinen nicht.
-    \item \textbf{FA-2 — Mandantentrennung:} Ein Benutzer sieht ausschließlich Dokumente, die im Ordner seiner Organisation liegen. Die Zuordnung erfolgt über die \texttt{efecte-org-id} am Kundenordner.
+    \item \textbf{FA-2 — Mandantentrennung:} Ein Benutzer sieht ausschließlich Dokumente seiner Organisation, zugeordnet über die \texttt{efecte-org-id}.
-    \item \textbf{FA-3 — Rollenbasierter Zugriff:} Der Navigationspunkt ist nur bei vorhandener Rollenberechtigung sichtbar. Ein direkter Aufruf ohne Berechtigung führt zu einer 403-Antwort.
+    \item \textbf{FA-3 — Rollenbasierter Zugriff:} Der Navigationspunkt ist nur bei vorhandener Berechtigung sichtbar; Aufruf ohne Berechtigung ergibt 403.
-    \item \textbf{FA-4 — Typisierung und Icons:} Jedes Dokument wird mit einem Icon dargestellt, das aus dem Unterordner abgeleitet wird. Unbekannte Typen erhalten ein Standard-Icon.
+    \item \textbf{FA-4 — Typisierung und Icons:} Jedes Dokument wird mit einem aus dem Unterordner abgeleiteten Icon dargestellt.
-    \item \textbf{FA-5 — Suche:} Dokumente können serverseitig nach ihrem Titel durchsucht werden, inklusive Teiltreffern. Ein leeres Suchfeld zeigt wieder die vollständige Liste.
+    \item \textbf{FA-5 — Suche:} Serverseitige Titelsuche mit Teiltreffern.
-    \item \textbf{FA-6 — Typfilter:} Unterhalb der Suchleiste kann je Dokumententyp ein Element zum Ein- und Ausblenden ausgewählt werden.
+    \item \textbf{FA-6 — Typfilter:} Filterelemente je Dokumententyp zum Ein- und Ausblenden.
-    \item \textbf{FA-7 — Paginierung:} Die Liste wird seitenweise dargestellt; die Seitengröße ist durch den Benutzer festlegbar, analog zu den übrigen Houston-Seiten.
+    \item \textbf{FA-7 — Paginierung:} Seitenweise Darstellung mit benutzerdefinierter Seitengröße, analog zu den übrigen Houston-Seiten.
-    \item \textbf{FA-8 — Einzeldownload:} Jeder Eintrag besitzt einen Download-Button. Der Download erfolgt über eine zeitlich begrenzte Pre-Signed URL \autocite{aws-presigned-urls} unter Beibehaltung des ursprünglichen Dateinamens.
+    \item \textbf{FA-8 — Einzeldownload:} Download über eine zeitlich begrenzte Pre-Signed URL \autocite{aws-presigned-urls} unter Beibehaltung des Dateinamens.
-    \item \textbf{FA-9 — ZIP-Download:} Mehrere Dokumente können über Auswahlboxen markiert und gemeinsam als ZIP-Archiv heruntergeladen werden. Die Ordnerstruktur des Archivs entspricht der S3-Struktur; das Archiv wird erst beim Klick erzeugt.
+    \item \textbf{FA-9 — ZIP-Download:} Ausgewählte Dokumente werden als ZIP-Archiv heruntergeladen; die Ordnerstruktur entspricht der S3-Struktur.
-    \item \textbf{FA-10 — PDF-Vorschau:} PDF-Dokumente können in einem Modal angezeigt werden, ohne zuvor heruntergeladen zu werden. Für Nicht-PDF-Dateien wird keine Vorschau geöffnet.
+    \item \textbf{FA-10 — PDF-Vorschau:} PDF-Anzeige im Modal ohne vorherigen Download.
-    \item \textbf{FA-11 — Share-Links:} Für jedes Dokument kann ein Freigabelink erzeugt werden, dessen Zielseite OpenGraph-Meta-Tags für eine Linkvorschau bereitstellt und anschließend auf den Document Explorer weiterleitet.
+    \item \textbf{FA-11 — Share-Links:} Freigabelink mit OpenGraph-Meta-Tags für Linkvorschau und Weiterleitung auf den Document Explorer.
-    \item \textbf{FA-12 — URL-Dateien:} Im Speicher abgelegte \texttt{.url}-Dateien werden nach dem INI-Format ausgewertet und leiten beim Anklicken auf die hinterlegte Adresse weiter. Ist keine gültige URL erkennbar, wird die Datei wie eine normale Datei behandelt.
+    \item \textbf{FA-12 — URL-Dateien:} \texttt{.url}-Dateien werden nach INI-Format ausgewertet und leiten auf die hinterlegte Adresse weiter; fehlt eine gültige URL, wird die Datei normal behandelt.
-    \item \textbf{FA-13 — Automatische Ordneranlage:} Beim Aufruf der Dokumentenseite wird die vollständige Typordnerstruktur für die Organisation angelegt, sofern sie noch nicht existiert.
+    \item \textbf{FA-13 — Automatische Ordneranlage:} Beim Aufruf wird die Typordnerstruktur für die Organisation angelegt, sofern sie fehlt.
 \end{itemize}
 
 \subsection{Nichtfunktionale Anforderungen}
 
 \begin{itemize}
-    \item \textbf{NFA-1 — Skalierbarkeit des Lookups:} Die Auflösung des Kundenordners darf nicht linear mit der Anzahl der Kunden wachsen. Im Normalfall soll ein einzelner Aufruf genügen.
+    \item \textbf{NFA-1 — Skalierbarkeit des Lookups:} Die Auflösung des Kundenordners darf nicht linear mit der Kundenanzahl wachsen.
-    \item \textbf{NFA-2 — Fehlerbehandlung:} Können Dokumente nicht geladen werden, wird eine verständliche Fehlermeldung angezeigt. Eine stillschweigend leere Seite ist nicht zulässig.
+    \item \textbf{NFA-2 — Fehlerbehandlung:} Bei Ladefehlern wird eine verständliche Meldung angezeigt; eine stillschweigend leere Seite ist unzulässig.
-    \item \textbf{NFA-3 — Leerer Zustand:} Existieren für einen berechtigten Benutzer keine Dokumente, wird ein entsprechender Hinweis angezeigt.
+    \item \textbf{NFA-3 — Leerer Zustand:} Existieren keine Dokumente, wird ein Hinweis angezeigt.
-    \item \textbf{NFA-4 — Konsistenz zur bestehenden Oberfläche:} Suche, Paginierung und Bedienelemente orientieren sich an den übrigen Houston-Seiten.
+    \item \textbf{NFA-4 — Konsistenz:} Bedienelemente orientieren sich an den übrigen Houston-Seiten.
-    \item \textbf{NFA-5 — Testbarkeit:} Die Logik zur Auflösung des Kundenordners ist durch Unit-Tests mit einem gemockten \texttt{IAmazonS3} abgedeckt.
+    \item \textbf{NFA-5 — Testbarkeit:} Der Kundenordner-Lookup ist durch Unit-Tests mit gemocktem \texttt{IAmazonS3} abgedeckt.
-    \item \textbf{NFA-6 — Pfadsicherheit:} Beim Download wird geprüft, dass der angeforderte Schlüssel innerhalb des Kundenordners liegt; Pfadanteile zum Verlassen des Ordners werden abgewiesen.
+    \item \textbf{NFA-6 — Pfadsicherheit:} Beim Download wird geprüft, dass der Schlüssel innerhalb des Kundenordners liegt.
 \end{itemize}

chapters/planning/schedule.tex

@@ -1,7 +1,7 @@
 \section{Zeit- und Aufwandsplanung}
 \label{sec:schedule}
 
-Für das Praktikum sind 24 Manntage beziehungsweise 192 Arbeitsstunden vorgesehen. Der Projektzeitraum erstreckt sich von der Themenfindung Ende Mai 2026 bis zur Abgabe der Dokumentation. Die Umsetzung verteilt sich auf die Sprints 15.2026 bis 17.2026. Abbildung~\ref{fig:gantt} zeigt die geplante zeitliche Verteilung.
+Für das Praktikum sind 24 Manntage (192 Stunden) vorgesehen. Der Projektzeitraum reicht von Ende Mai 2026 bis zur Abgabe; die Umsetzung verteilt sich auf die Sprints 15–17.2026. Abbildung~\ref{fig:gantt} zeigt die Zeitplanung.
 
 \begin{figure}[H]
     \centering
@@ -10,8 +10,8 @@ Für das Praktikum sind 24 Manntage beziehungsweise 192 Arbeitsstunden vorgesehe
     \label{fig:gantt}
 \end{figure}
 
-Die Planung gliedert sich in vier Phasen. Die \textbf{Analyse- und Konzeptionsphase} (Ende Mai bis Anfang Juli) umfasste die Themenfindung mit \emph{Sarah Hinzmann} und \emph{Thomas Drewermann}, die Feature-Analyse sowie den Schnitt und die Freigabe der Product Backlog Items. Die \textbf{Implementierungsphase} begann am 27.~Juli mit dem ersten Pull Request und erstreckte sich über die Sprints 15 und 16. Parallel dazu lief die \textbf{Qualitätssicherung} in Form fortlaufender Code-Reviews; der Abnahmetest begann am 13.~August. Die \textbf{Abschlussphase} umfasst Release, Dokumentation und Präsentation.
+Vier Phasen gliedern die Planung: Die \textbf{Analyse- und Konzeptionsphase} (Ende Mai bis Anfang Juli) umfasste Themenfindung, Feature-Analyse und Backlog-Schnitt. Die \textbf{Implementierungsphase} begann am 27.~Juli über die Sprints 15 und 16. Parallel lief die \textbf{Qualitätssicherung} (Code-Reviews, Abnahmetest ab 13.~August). Die \textbf{Abschlussphase} umfasst Release, Dokumentation und Präsentation.
 
-Eine Besonderheit der Planung ist die Abhängigkeit von der Infrastrukturbereitstellung: Der Document Explorer konnte erst umgesetzt werden, nachdem der S3-Speicher zur Verfügung stand. Diese Abhängigkeit wurde bereits im Approval-Termin am 8.~Juli durch \emph{Stephan Janßen} als Voraussetzung am Item vermerkt. Der tatsächliche Vorlauf für die Beschaffung wird im folgenden Abschnitt beschrieben.
+Die Planung hing von der Infrastrukturbereitstellung ab: Der Document Explorer konnte erst nach Verfügbarkeit des S3-Speichers umgesetzt werden. \emph{Stephan Janßen} vermerkte diese Abhängigkeit am 8.~Juli als Voraussetzung am Item.
 
 Der Soll-Ist-Vergleich der Zeitplanung findet sich in Abschnitt~\ref{sec:target-comparison}.

chapters/qa/acceptance-testing.tex

@@ -1,5 +1,38 @@
 \section{Abnahmetest}
 \label{sec:acceptance-testing}
 
-% TODO: Maria-Lena Andersz — Sichtbarkeitsproblem des Menüpunkts (2026-08-13)
+\subsection{Ablauf}
-% Rollenzuweisung klären, Bug 10134 (Suchfunktion), finale Abnahme 2026-08-24/25
+
+Die fachliche Abnahme übernahm \emph{Maria-Lena Andersz}. Sie begann am 13.~August 2026 und zog sich mit Unterbrechungen bis zum 25.~August; geprüft wurde gegen die Akzeptanzkriterien der Backlog Items auf der Testumgebung.
+
+Die Abnahme zerfiel in zwei Abschnitte: zunächst Zugriffs- und Konfigurationsprobleme, erst danach die funktionale Prüfung.
+
+\subsection{Der Menüpunkt war nicht sichtbar}
+
+Der Menüpunkt „Dokumente" erschien nicht. Die Ursache lag nicht im Code, sondern in der Berechtigungsvergabe — der Testerin war die Anwendungsrolle nicht zugewiesen. Das Verhalten entsprach der Spezifikation: Ohne Rolle ist der Menüpunkt unsichtbar (siehe Abschnitt~\ref{sec:authorization}).
+
+Der Vorgang legt eine Lücke offen: Die Rolle war Ende Juli für die Entwicklungsumgebung beantragt worden; dass ihre Vergabe an Testende ein eigener Schritt ist, war weder in Akzeptanzkriterien noch Übergabe festgehalten. Eine rollenbasierte Funktion bringt Anforderungen mit, die über den Code hinausgehen.
+
+Hier bewährte sich die 403-Antwort (Abschnitt~\ref{sec:authorization}): Bei 404 wäre für die Testerin nicht unterscheidbar gewesen, ob die Seite fehlt oder die Berechtigung.
+
+\subsection{Konfiguration und Testdaten}
+
+Nach Klärung der Berechtigung wurden keine Dokumente angezeigt. Auch hier lag die Ursache in der Umgebung: Es fehlten Testdateien im Speicher, und die Zuordnung zwischen Testkonto und Organisation war nicht korrekt konfiguriert.
+
+Das ist charakteristisch für das Ablagekonzept: Ob ein Benutzer Dokumente sieht, hängt von einer Kette ab — Anmeldetoken, Organisationszuordnung, Metadatum am Kundenordner. Ist ein Glied falsch, zeigt die Seite keine Dokumente, aber auch keinen Fehler. Nach Bereinigung funktionierte die Anzeige.
+
+Eine Prüfliste für die Inbetriebnahme — Speicher erreichbar, Testdaten vorhanden, Rolle vergeben, Organisationszuordnung gesetzt — hätte diesen Abschnitt verkürzt.
+
+\subsection{Funktionale Prüfung}
+
+Am 24.~August fand die funktionale Abnahme statt: Paginierung, Suchverhalten, Sprungmarken der Freigabelinks, Fehlerverhalten, Verknüpfungsdateien und Download.
+
+Die Prüfung verlief überwiegend erfolgreich; einzelne Bestandteile waren nicht verfügbar, da der letzte Pull Request offen war (siehe Abschnitt~\ref{sec:folder-management}). Abweichungen wurden als Fehlerberichte erfasst.
+
+\subsection{Der gefundene Fehler}
+
+Ein Fehlerbericht: Das Suchfeld blendet nach Eingabe eine Schaltfläche zum Leeren ein, die auf den übrigen Houston-Seiten nicht existiert — eine Abweichung in Darstellung und Verhalten.
+
+Die Schaltfläche ist eine sinnvolle Erleichterung; der Fehler liegt darin, dass sie nur an dieser Stelle existiert, was NFA-4 (Konsistenz) verletzt.
+
+Weder Unit-Test noch Code-Review hätten ihn finden können; sichtbar wird die Abweichung erst beim Vergleich mit den bestehenden Seiten — das leistet nur ein Abnahmetest durch eine Person, die die Anwendung kennt. Der Fehler wurde für den folgenden Sprint eingeplant.

chapters/qa/code-reviews.tex

@@ -1,7 +1,42 @@
 \section{Code-Reviews}
 \label{sec:code-reviews}
 
-% TODO: 11 PRs (2154–2196), Reviewer: Timo Walter, Sarah Hinzmann, Robin Noack
+\subsection{Umfang}
-% Reviewfunde: zentrale Auth über Program.cs, keyed Settings, 403 statt 404,
+
-% Slug-Naming-Constraints (IBM-Doku), Fehlerbehandlung statt stiller leerer Seite
+Die Umsetzung verteilte sich auf elf Pull Requests mit 113 Diskussionssträngen (Tabelle~\ref{tab:pull-requests} im Anhang). Kein Pull Request wurde abgelehnt; sämtliche erhielten eine Freigabe. Die inhaltliche Auseinandersetzung fand durchgängig in den Diskussionssträngen statt.
-% Tabelle~\ref{tab:pull-requests} im Anhang
+
+Dass kein Pull Request verworfen wurde, ist kein Zufall: Die vorgelagerte Klärung — Feature-Analyse im Juni, Backlog-Durchsicht im Juli — hatte die fachlichen Fragen so weit beantwortet, dass keine Implementierung auf einer falschen Annahme beruhte.
+
+\subsection{Prüftiefe und Risiko}
+
+Die Verteilung der Diskussionsstränge folgt dem Risiko: Die intensivste Prüfung erfuhren Einzeldownload (30 Stränge) und Freigabelinks (23) — die Arbeiten, bei denen ein Fehler Kundendokumente offengelegt hätte. Der Document Explorer folgt mit 21 Strängen, die PDF-Vorschau mit zwei: eine Darstellungsfunktion ohne eigene Sicherheitsentscheidung.
+
+Die Verteilung entstand ohne Vorgabe — die Reviewer lenkten ihre Aufmerksamkeit intuitiv dorthin, wo ein Fehler teuer gewesen wäre.
+
+\subsection{Wiederkehrende Themen}
+
+Über alle Diskussionsstränge hinweg lassen sich fünf Muster erkennen.
+
+\textbf{Sicherheit und Eingabeprüfung.} Der größte Anteil entfiel auf die Prüfung externer Angaben: Pfadprüfung beim Download, zeitlich begrenzte Zugriffs-URLs statt Dateiströme, Ausschluss benutzerdefinierter Symbole aus der Vorschau und der Grundsatz, keine Inhalte über nicht authentifizierte Pfade auszuliefern.
+
+\textbf{Kompatibilität vor Ideallösung.} Mehrfach wurde eine technisch sauberere Lösung zugunsten einer verlässlicheren verworfen — etwa die Bereitstellung der Vorschaubilder als Rastergrafik, weil die Vektorvariante von verbreiteten Messengern nicht zuverlässig dargestellt wird (siehe Abschnitt~\ref{sec:pdf-preview}).
+
+\textbf{Abgrenzung statt Ausweitung.} Erkannte Probleme wurden als neue Backlog Items erfasst statt im laufenden Pull Request miterledigt — etwa Speicherabfrage, Typsuche und Nebenläufigkeit. Das hielt die Pull Requests begrenzt und machte die Probleme sichtbar.
+
+\textbf{Struktur und Wartbarkeit.} Wiederkehrend: auszulagernde Skripte, fehlertolerantes Auswerten von Aufzählungswerten, überflüssige Kommentare, uneinheitliche Benennungen.
+
+\textbf{Fachliche Klärung im Review.} In mehreren Fällen änderte die Diskussion nicht den Code, sondern das Backlog Item — etwa den Statuscode bei fehlender Berechtigung (403 statt 404) und die Festlegung, dass auch einzelne Dokumente als Archiv ausgeliefert werden. Das Review leistete damit Anforderungsarbeit.
+
+\subsection{Wechsel der Reviewer}
+
+Über die Projektlaufzeit wechselte der Hauptreviewer zweimal: \emph{Timo Walter} prüfte die fünf Pull Requests der Anfangsphase, \emph{Sarah Hinzmann} übernahm Anfang August, \emph{Robin Noack} die Schlussphase. Zusätzlich beteiligte sich \emph{Hanna Ebner} an den frühen Diskussionen.
+
+Der Wechsel war organisatorisch bedingt, hatte aber einen fachlichen Effekt: Frühe Reviews befassten sich mit Architektur, Sicherheit und Speicherabfrage; mittlere mit Bedienung und Wartbarkeit; späte mit Benennung, Fehlertoleranz und Codestil. Ein gleicher Reviewer hätte diese Bandbreite vermutlich nicht abgedeckt; zugleich verteilte der Wechsel das Wissen über das Modul im Team.
+
+\subsection{Kritische Betrachtung des Vorgehens}
+
+Am 27.~Juli wurden vier Pull Requests am selben Tag eröffnet, ein fünfter folgte am Tag darauf. Da sie inhaltlich aufeinander aufbauten, ließ sich nur der erste zeitnah abschließen; die übrigen blieben zwei bis drei Wochen offen.
+
+Die in Abschnitt~\ref{sec:architecture} beschriebene Verkettung machte die Änderungen gut prüfbar, verlagerte den Aufwand aber ans Ende: Der überwiegende Teil der Zusammenführungen fällt in die Woche vom 18. bis 21.~August — unmittelbar vor Abnahme und Produktivsetzung.
+
+Rückblickend wäre sequenzielles Vorgehen vorzuziehen gewesen, da die inhaltliche Abhängigkeit echtes paralleles Vorankommen ohnehin verhinderte.

chapters/qa/releases.tex

@@ -1,5 +1,26 @@
-\section{Releases}
+\section{Auslieferung}
 \label{sec:releases}
 
-% TODO: DEV / TEST / PROD je eigener Bucket, Rollenvergabe vor Release
+\subsection{Umgebungen}
-% PR 2196 noch aktiv bei Dokumentationsabgabe
+
+Die Auslieferung folgt dem in Houston etablierten dreistufigen Weg über Entwicklungs-, Test- und Produktivumgebung. Jede Stufe besitzt einen eigenen Speicher (siehe Abschnitt~\ref{sec:s3-client}); eine Auslieferung setzt voraus, dass dieser eingerichtet, erreichbar und korrekt hinterlegt ist.
+
+Deshalb wurde die Infrastrukturbereitstellung (Abschnitt~\ref{sec:infrastructure}) bereits im Approval-Termin als Voraussetzung vermerkt.
+
+\subsection{Rollen als Teil der Auslieferung}
+
+Die Anwendungsrolle muss je Umgebung vorhanden sein und den betreffenden Personen zugewiesen werden — kein Bestandteil des Anwendungsstands, sondern eine begleitende Maßnahme.
+
+Dieser Punkt führte im Abnahmetest zu Verzögerungen (Abschnitt~\ref{sec:acceptance-testing}). Vor der Produktivsetzung wurde daher am 20.~August geprüft, ob sämtliche Funktionen des Moduls hinter der Rolle liegen.
+
+Die Prüfung ist nötig, weil das Modul mehrere Einstiegspunkte besitzt: Wäre eine Route nicht von der zentralen Richtlinie erfasst, bliebe sie ohne Anmeldung erreichbar, ohne dass dies sichtbar wäre. Die zentrale Registrierung (Abschnitt~\ref{sec:architecture}) macht diesen Fehler unwahrscheinlich; die Prüfung bestätigt dies.
+
+\subsection{Stand bei Abgabe}
+
+Bei Abgabe waren zehn der elf Pull Requests zusammengeführt, überwiegend in der Woche vom 18.~bis 21.~August. Der Dokumentenbereich war damit in seinen Kernfunktionen — Liste, Typisierung, Suche, Filter, Paginierung, Downloads, Vorschau, Freigabelinks und Verknüpfungsdateien — ausgeliefert.
+
+Nicht abgeschlossen war die Ordnerverwaltung mit dem neuen Kundenordner-Lookup. Der Pull Request war fachlich fertig, aber nicht freigegeben; bis dahin bleibt das in Abschnitt~\ref{sec:document-explorer} beschriebene lineare Verfahren — funktional korrekt, aber mit bekannter Skalierungsschwäche.
+
+Ebenfalls offen sind das Backlog Item zur Nebenläufigkeit sowie der Fehlerbericht aus der Abnahme, der für den folgenden Sprint eingeplant ist.
+
+Der Dokumentenbereich ist in Betrieb, aber nicht vollständig abgeschlossen (Abschnitt~\ref{sec:target-comparison}).

chapters/qa/test-strategy.tex

@@ -1,4 +1,14 @@
 \section{Teststrategie}
 \label{sec:test-strategy}
 
-% TODO: Unit-Tests mit gemocktem IAmazonS3, Abnahmetests durch Maria-Lena Andersz
+Die Qualitätssicherung stützte sich auf drei Stufen.
+
+\textbf{Unit-Tests} sichern isoliert prüfbare Logik ab — hier vor allem Kundenordner-Auflösung und Pfadbehandlung. Sie laufen bei jedem Übersetzungsvorgang.
+
+\textbf{Code-Reviews} prüfen Entwurf, Lesbarkeit und Sicherheitseigenschaften — Fehlerarten, für die kein automatisierter Test formulierbar ist, etwa ob eine Information auf einem nicht authentifizierten Pfad ausgeliefert werden darf.
+
+\textbf{Abnahmetests} prüfen gegen die Akzeptanzkriterien in der tatsächlichen Umgebung. Sie erfassen Fehler aus dem Zusammenspiel von Konfiguration, Berechtigungen und realen Daten — eine Klasse, die in Unit-Tests und Reviews unsichtbar bleibt.
+
+Die automatisierten Tests folgten dem Risiko, nicht einer Abdeckungsvorgabe. Für den Kundenordner-Lookup war Testabdeckung ausdrücklich als Akzeptanzkriterium aufgenommen; für die PDF-Vorschau nicht. Ein Fehler im Lookup führt zur Anzeige fremder Dokumente oder Datenverlust und ist im Betrieb schwer zu bemerken; ein Fehler in der Vorschau ist beim ersten Aufruf offensichtlich.
+
+Diese Priorisierung hat eine Kehrseite: Fehler in Bereichen ohne automatisierte Abdeckung wurden erst im Abnahmetest gefunden (Abschnitt~\ref{sec:acceptance-testing}).

chapters/qa/unit-tests.tex

@@ -1,6 +1,28 @@
 \section{Unit-Tests}
 \label{sec:unit-tests}
 
-% TODO: DocumentsServiceTests — gemocktes IAmazonS3
+\subsection{Testbarkeit durch Kapselung}
-% Pfade: Fast-Path, Fallback, Rename, Create, Kollision, Fehlerfall
+
-% Abbildung~\ref{fig:documents-service-tests}
+Da der Speicherzugriff über die SDK-Schnittstelle erfolgt, lässt sich diese in Tests durch eine Attrappe ersetzen. Die Tests laufen damit ohne Netzwerkverbindung, ohne Zugangsdaten und ohne einen realen Speicher.
+
+Die Attrappe erlaubt Zustände, die sich real kaum erzeugen ließen — etwa einen Kundenordner mit falschem Namen, aber korrektem Metadatum, oder einen Ordner ohne Metadatum. Gerade diese Randfälle könnten ohne Test unbemerkt fehlerhaft bleiben.
+
+\subsection{Abgedeckte Pfade}
+
+Die Tests bilden die in Abschnitt~\ref{sec:lookup-decision} beschriebenen Wege einzeln ab: Direktzugriff, Kollisionsfall, Rückfallebene mit Umbenennung, Anlegen eines fehlenden Kundenordners und Ignorieren eines Ordners ohne gültiges Metadatum. Geprüft wird nicht nur das Ergebnis, sondern auch die Speicherzugriffe — beim Direktzugriff etwa, dass genau eine Metadatenabfrage und keine Auflistung stattfand.
+
+Die Anforderung an den Lookup war keine funktionale, sondern eine über den Aufwand. Ein Test, der nur das richtige Präfix prüft, bestünde auch, wenn die Implementierung weiterhin alle Ordner durchliefe. Die eigentliche Eigenschaft — dass der Regelfall mit einem einzigen Zugriff auskommt — lässt sich nur über die beobachteten Aufrufe prüfen.
+
+\subsection{Testdaten}
+
+\emph{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.
+
+\subsection{Ein Test, der das Falsche prüfte}
+
+\emph{Timo Walter} bemerkte beim Lesen, dass ein Test bestand, aber aus dem falschen Grund: Der Prüfling brach in der ersten Zeile ab, weil die Pfadauswertung einen unbekannten Typbezeichner vorfand — die eigentlich zu prüfende Logik wurde nie erreicht.
+
+Er leitete einen vermuteten Fehler ab: Ein Dokument ohne Typ dürfe die Auswertung nicht scheitern lassen. Die Klärung ergab, dass der Code korrekt, der Test aber missverständlich benannt war. Geprüft wurde eine Sicherheitseigenschaft: dass ein Benutzer, der den Kundennamen als Pfadbestandteil in die Adresse schreibt, kein Ergebnis erhält und keine Anfrage an den Speicher ausgelöst wird.
+
+Der Vorgang zeigt zweierlei: Ein Test, der aus dem falschen Grund grün ist, ist wertlos, weil er Sicherheit suggeriert. Der Fund war nicht durch Ausführen zu erzielen, sondern nur durch Lesen — er belegt den Wert des Reviews für Testcode.
+
+Als Konsequenz wurde die Absicht des Tests explizit gemacht. Diese Anforderung — dass ein Test ohne den Fix fehlschlagen muss — wurde in die Akzeptanzkriterien des Folgeitems zur Nebenläufigkeit aufgenommen (siehe Abschnitt~\ref{sec:race-conditions}).

figures/code/auth-policy.cs

@@ -0,0 +1,25 @@
+// Houston/Auth/HoustonRoles.cs
+public static readonly string DocumentsView = "Documents.View";
+
+// Houston/Program.cs
+var viewDocumentsPolicy = "CanViewDocuments";
+
+builder.Services.AddAuthorization(o =>
+{
+    o.FallbackPolicy = new AuthorizationPolicyBuilder().RequireAuthenticatedUser().Build();
+    // ...
+    o.AddPolicy(viewDocumentsPolicy, policy => policy.RequireRole(HoustonRoles.DocumentsView));
+});
+
+builder.Services.AddRazorPages(o =>
+{
+    // ...
+    o.Conventions.AllowAnonymousToPage("/Document/Share");
+    o.Conventions.AuthorizeFolder("/Document", viewDocumentsPolicy);
+    o.Conventions.AuthorizePage("/Documents", viewDocumentsPolicy);
+});
+
+// Houston/Services registrations
+builder.Services.AddOptions<DocumentsSettings>().BindConfiguration("Documents");
+builder.Services.AddDocumentsClient();
+builder.Services.AddScoped<DocumentsService>();

figures/code/document-id.cs

@@ -0,0 +1,42 @@
+using System.Diagnostics.CodeAnalysis;
+using System.Text;
+using Microsoft.AspNetCore.WebUtilities;
+
+namespace Houston.Model.Documents;
+
+/// <summary>
+/// Public URL id of a customer document.
+/// </summary>
+/// <remarks>
+/// The identifier used in URLs (e.g. <c>/document/{id}/download</c> or <c>/document/{id}/share</c>)
+/// is the URL base64 encoding of the document path <em>without</em> the customer/organization
+/// folder. For an object stored at <c>OrgX/TypeY/FileZ.pdf</c> the id therefore encodes
+/// <c>TypeY/FileZ.pdf</c>. The organization part is never part of the id, so it can only ever be
+/// derived server side from the authenticated user.
+/// </remarks>
+public readonly record struct DocumentId(string Value)
+{
+    public static DocumentId Encode(DocumentRelativePath relativePath)
+        => new(WebEncoders.Base64UrlEncode(Encoding.UTF8.GetBytes(relativePath.ToString())));
+
+    public bool TryDecode([NotNullWhen(true)] out DocumentRelativePath? relativePath)
+    {
+        relativePath = null;
+
+        if (String.IsNullOrEmpty(Value))
+            return false;
+
+        try
+        {
+            var decoded = Encoding.UTF8.GetString(WebEncoders.Base64UrlDecode(Value));
+            return DocumentRelativePath.TryFromS3Key(decoded, out relativePath);
+        }
+        catch (FormatException)
+        {
+            relativePath = null;
+            return false;
+        }
+    }
+
+    public override string ToString() => Value;
+}

figures/code/document-key.cs

@@ -0,0 +1,41 @@
+using System.Diagnostics.CodeAnalysis;
+using System.Text;
+
+namespace Houston.Model.Documents;
+
+/// <summary>
+/// Full S3 object key of a customer document, including the customer/organization prefix.
+/// </summary>
+public readonly record struct DocumentKey(OrgSlug Org, DocumentType? Type, DocumentName Name)
+{
+    public static bool TryFromS3Key(string key, [NotNullWhen(true)] out DocumentKey? result)
+    {
+        result = null;
+
+        if (key.EndsWith('/')) return false;
+
+        var parts = key.Split('/', StringSplitOptions.RemoveEmptyEntries);
+
+        if (parts.Contains("..")) return false;
+
+        result = parts switch
+        {
+            [var org, var name] when OrgSlug.TryFromFolderName(org, out var slug)
+                => new(slug.Value, null, new(name)),
+            [var org, var type, var name] when OrgSlug.TryFromFolderName(org, out var slug)
+                => new(slug.Value, DocumentTypeExtensions.ParseStorageFolderName(type), new(name)),
+            _ => null,
+        };
+
+        return result is not null;
+    }
+
+    public override string ToString()
+    {
+        StringBuilder result = new();
+        result.Append(Org.ToString());
+        if (Type is { } type) result.Append(type.StorageFolderName).Append('/');
+        result.Append(Name);
+        return result.ToString();
+    }
+}

figures/code/document-name.cs

@@ -0,0 +1,27 @@
+namespace Houston.Model.Documents;
+
+public readonly record struct DocumentName(string Value)
+{
+    public bool Matches(string pattern)
+    {
+        return Value.Contains(pattern, StringComparison.CurrentCultureIgnoreCase);
+    }
+
+    /// <summary>
+    /// Whether this document is a PDF and therefore eligible for the inline modal preview.
+    /// </summary>
+    public bool IsPdf => Value.EndsWith(".pdf", StringComparison.OrdinalIgnoreCase);
+
+    /// <summary>
+    /// Whether this is an external document link (a .URL file).
+    /// </summary>
+    public bool IsLink => Value.EndsWith(".url", StringComparison.OrdinalIgnoreCase);
+
+    /// <summary>
+    /// File display name.
+    /// </summary>
+    public string DisplayName => IsLink ? Value[..^".url".Length] : Value;
+
+    /// <inheritdoc />
+    public override string ToString() => Value;
+}

figures/code/document-search.cs

@@ -0,0 +1,39 @@
+private async IAsyncEnumerable<DocumentKey> SearchDocumentsAsync(
+    OrgSlug org,
+    string? searchTerm,
+    DocumentTypeSet documentTypes,
+    bool includeUntypedDocuments,
+    DocumentRelativePath? startAfter,
+    [EnumeratorCancellation] CancellationToken cancellationToken)
+{
+    var query = searchTerm?.Trim();
+
+    await foreach (var doc in ListDocumentsAsync(org, startAfter, cancellationToken))
+    {
+        if (!doc.Type.MatchesFilter(documentTypes, includeUntypedDocuments))
+            continue;
+
+        if (!String.IsNullOrEmpty(query) && !doc.Name.Matches(query))
+            continue;
+
+        yield return doc;
+    }
+}
+
+// Houston/Model/Documents/DocumentName.cs
+public bool Matches(string pattern)
+{
+    return Value.Contains(pattern, StringComparison.CurrentCultureIgnoreCase);
+}
+
+// Houston/Model/Documents/DocumentType.cs
+public bool MatchesFilter(DocumentTypeSet documentTypes, bool includeUntypedDocuments)
+{
+    if (documentTypes.IsEmpty && !includeUntypedDocuments)
+        return true;
+
+    if (documentType is null)
+        return includeUntypedDocuments;
+
+    return documentTypes.Types.Contains(documentType.Value);
+}

figures/code/document-type.cs

@@ -0,0 +1,42 @@
+using System.Globalization;
+using Houston.Resources;
+
+namespace Houston.Model.Documents;
+
+public enum DocumentType
+{
+    ServiceProtocol,
+    AcceptanceDocuments,
+    SlaReportsTicketProcessing,
+    MonitoringReports,
+    SecurityAssessments,
+    BillingData,
+    ContractDocuments,
+}
+
+public static class DocumentTypeExtensions
+{
+    public const string OtherDocumentsDisplayName = "Sonstige Dokumente";
+    public const string OtherDocumentsValue = "OtherDocuments";
+
+    public static string? FromStorageFolderName(string storageFolderName) =>
+        APITranslation.ResourceManager.GetString(storageFolderName, CultureInfo.InvariantCulture);
+
+    public static DocumentType? ParseStorageFolderName(string storageFolderName)
+    {
+        var type = FromStorageFolderName(storageFolderName);
+        if (!Enum.TryParse<DocumentType>(type, ignoreCase: true, out var variant))
+            return null;
+
+        return variant;
+    }
+
+    extension(DocumentType documentType)
+    {
+        /// <summary>
+        /// The name of the S3 subfolder that holds documents of this type, i.e. the German translation.
+        /// </summary>
+        public string StorageFolderName =>
+            APITranslation.ResourceManager.GetString(documentType.ToString(), CultureInfo.InvariantCulture)
+            ?? throw new NotImplementedException($"Missing translation for DocumentType '{documentType}'.");
+    }

figures/code/documents-table-body.cshtml

@@ -0,0 +1,65 @@
+<tbody>
+@foreach (var file in Model.Files)
+{
+    <tr class="document-row" id="@Documents.DocumentViewId(file.Id)">
+        <td>
+            @if (Documents.IsDownloadable(file.Name))
+            {
+                <div class="form-check mb-0">
+                    <input type="checkbox" name="selected" value="@file.Id"
+                           class="form-check-input js-document-select"
+                           aria-label="@file.Name.DisplayName auswählen"/>
+                </div>
+            }
+        </td>
+        <td>
+            <i class="doc-type-icon bx-sm @file.IconClass" title="@file.Type.DisplayName"></i>
+        </td>
+        <td>@file.Name.DisplayName</td>
+        <td class="text-end">
+            <div class="d-flex">
+                @if (file.Name.IsPdf)
+                {
+                    <button type="button"
+                            class="btn btn-icon btn-text-secondary rounded-pill js-document-preview"
+                            data-preview-url="@Model.DocumentPreviewUrl(file.Id)"
+                            data-document-name="@file.Name.DisplayName"
+                            title="@file.Name.DisplayName als Vorschau öffnen"
+                            aria-label="@file.Name.DisplayName als Vorschau öffnen">
+                        <i class="bx bx-show-alt"></i>
+                    </button>
+                }
+                else
+                {
+                    <span class="btn btn-icon rounded-pill invisible" aria-hidden="true">
+                        <i class="bx bx-show-alt"></i>
+                    </span>
+                }
+                <button type="button"
+                        class="btn btn-icon btn-text-secondary rounded-pill js-document-share"
+                        data-share-url="@Model.DocumentShareUrl(file.Id)"
+                        title="Link zu @file.Name.DisplayName kopieren"
+                        aria-label="Link zu @file.Name.DisplayName kopieren">
+                    <i class="bx bx-share-alt"></i>
+                </button>
+                @if (file.Name.IsLink)
+                {
+                    <a class="btn btn-icon btn-text-secondary rounded-pill"
+                       asp-page="/Document/Download" asp-route-id="@file.Id"
+                       target="_blank" rel="noopener noreferrer"
+                       title="@file.Name.DisplayName in neuem Tab öffnen" aria-label="@file.Name.DisplayName in neuem Tab öffnen">
+                        <i class="bx bx-download"></i>
+                    </a>
+                }
+                else
+                {
+                    <a class="btn btn-icon btn-text-secondary rounded-pill"
+                       asp-page="/Document/Download" asp-route-id="@file.Id"
+                       title="@file.Name.DisplayName herunterladen" aria-label="@file.Name.DisplayName herunterladen">
+                        <i class="bx bx-download"></i>
+                    </a>
+                }
+            </div>
+        </td>
+    </tr>
+}

figures/code/ini-parser.cs

@@ -0,0 +1,49 @@
+namespace Houston.Services;
+
+public class IniParser
+{
+    public async Task<IniDocument> ParseAsync(TextReader reader, CancellationToken cancellationToken)
+    {
+        var sections = new Dictionary<string, Dictionary<string, string>>(StringComparer.OrdinalIgnoreCase);
+        var current = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
+        sections[String.Empty] = current;
+
+        while (await reader.ReadLineAsync(cancellationToken) is { } line)
+        {
+            var trimmed = line.Trim();
+
+            // Skip blank lines and comments
+            if (trimmed.Length == 0 || trimmed[0] is ';' or '#')
+                continue;
+
+            if (trimmed.StartsWith('[') && trimmed.EndsWith(']'))
+            {
+                var name = trimmed[1..^1].Trim();
+                if (!sections.TryGetValue(name, out current!))
+                    sections[name] = current = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
+                continue;
+            }
+
+            var separator = trimmed.IndexOf('=');
+            if (separator < 0)
+                continue;
+
+            var key = trimmed[..separator].Trim();
+            if (key.Length == 0)
+                continue;
+
+            // Last value wins for duplicate keys within a section.
+            current[key] = trimmed[(separator + 1)..].Trim();
+        }
+
+        return new(sections);
+    }
+
+    /// <summary>
+    /// Parses INI content from a string.
+    /// </summary>
+    public Task<IniDocument> ParseAsync(string content, CancellationToken cancellationToken)
+    {
+        using var reader = new StringReader(content);
+        return ParseAsync(reader, cancellationToken);
+    }

figures/code/list-documents.cs

@@ -0,0 +1,25 @@
+private async IAsyncEnumerable<DocumentKey> ListDocumentsAsync(
+    OrgSlug org,
+    DocumentRelativePath? startAfter,
+    [EnumeratorCancellation] CancellationToken cancellationToken)
+{
+    var isFirstRequest = true;
+    var requestBuilder = () =>
+    {
+        var r = new ListObjectsV2Request
+        {
+            Prefix = org.ToString(),
+            StartAfter = isFirstRequest && startAfter is { } doc
+                ? new DocumentKey(org, doc.Type, doc.Name).ToString()
+                : null,
+        };
+
+        isFirstRequest = false;
+
+        return r;
+    };
+
+   await foreach (var obj in EnumerateObjectsAsync(requestBuilder, cancellationToken))
+       if (DocumentKey.TryFromS3Key(obj.Key, out var key))
+           yield return key.Value;
+}

figures/code/org-slug.cs

@@ -0,0 +1,112 @@
+using System.Diagnostics.CodeAnalysis;
+using System.Text;
+
+namespace Houston.Model.Documents;
+
+public readonly record struct OrgSlug
+{
+    public const int MaxLength = 128;
+
+    private const string CharactersToReplace = @"/\{}^%`][""><~#|";
+
+    private const char ReplacementCharacter = '-';
+
+    /// <summary>
+    /// Characters that must not start or end a folder name, because they are either invisible or
+    /// break path semantics on the client side.
+    /// </summary>
+    private static readonly char[] UntrimmableEdgeCharacters = [' ', '.', ReplacementCharacter];
+
+    public string Value { get; }
+
+    private OrgSlug(string value) => Value = value;
+
+    public static bool TryFromS3Key(string key, [NotNullWhen(true)] out OrgSlug? result)
+    {
+        result = null;
+
+        if (!key.EndsWith('/')) return false;
+
+        var parts = key.Split('/', StringSplitOptions.RemoveEmptyEntries);
+
+        return parts is [var name] && TryFromFolderName(name, out result);
+    }
+
+    public static bool TryFromFolderName(string name, [NotNullWhen(true)] out OrgSlug? result)
+    {
+        result = null;
+
+        if (String.IsNullOrWhiteSpace(name)) return false;
+        if (name.Contains('/')) return false;
+        if (name == "..") return false;
+
+        result = new OrgSlug(name);
+        return true;
+    }
+
+    /// <summary>
+    /// Builds the canonical folder name for an organization.
+    /// </summary>
+    /// <returns>
+    /// <c>false</c> if the name contains nothing that survives the normalization, in which case
+    /// there is no folder name Houston could safely claim.
+    /// </returns>
+    public static bool TryFrom(OrgName name, [NotNullWhen(true)] out OrgSlug? result)
+    {
+        result = null;
+
+        var slug = Normalize(name.Value, MaxLength);
+        if (slug.Length == 0)
+            return false;
+
+        result = new OrgSlug(slug);
+        return true;
+    }
+
+    public static bool TryFrom(OrgName name, OrgId id, [NotNullWhen(true)] out OrgSlug? result)
+    {
+        result = null;
+
+        var normalizedId = Normalize(id.Value, MaxLength);
+        if (normalizedId.Length == 0)
+            return false;
+
+        // The id is what makes the folder name unique, so the name is what gets truncated.
+        var suffix = $" ({normalizedId})";
+        if (suffix.Length >= MaxLength)
+            return false;
+
+        var slug = Normalize(name.Value, MaxLength - suffix.Length);
+
+        result = new OrgSlug(slug.Length == 0 ? normalizedId : slug + suffix);
+        return true;
+    }
+
+    private static string Normalize(string value, int maxLength)
+    {
+        var builder = new StringBuilder(Math.Min(value.Length, maxLength));
+
+        foreach (var character in value.Trim().TakeWhile(c => builder.Length != maxLength))
+        {
+            builder.Append(Char.IsControl(character) || CharactersToReplace.Contains(character)
+                ? ReplacementCharacter
+                : character);
+        }
+
+        // Truncating can uncover a trailing space or dot, so trimming happens afterwards.
+        return builder.ToString().Trim().Trim(UntrimmableEdgeCharacters).Trim();
+    }
+
+    /// <summary>
+    /// S3 prefix of the folder, including the trailing slash.
+    /// </summary>
+    public override string ToString()
+    {
+        // A default(OrgSlug) would resolve to the bucket root and expose every customer's
+        // documents, so it must never be used as a prefix.
+        if (String.IsNullOrEmpty(Value))
+            throw new InvalidOperationException("An uninitialized OrgSlug cannot be used as an S3 prefix.");
+
+        return Value + '/';
+    }
+}

figures/code/pagination-continuation-token.cs

@@ -0,0 +1,28 @@
+private async IAsyncEnumerable<ListObjectsV2Response> EnumerateResponsesAsync(
+    Func<ListObjectsV2Request> requestBuilder,
+    [EnumeratorCancellation] CancellationToken cancellationToken)
+{
+    string? continuationToken = null;
+    do
+    {
+        var request = requestBuilder();
+        request.ContinuationToken = continuationToken;
+        request.BucketName = _settings.S3.Bucket;
+
+        var response = await s3.ListObjectsV2Async(request, cancellationToken);
+        yield return response;
+
+        continuationToken = response.IsTruncated == true ? response.NextContinuationToken : null;
+    } while (continuationToken is not null);
+}
+
+private async IAsyncEnumerable<S3Object> EnumerateObjectsAsync(
+    Func<ListObjectsV2Request> requestBuilder,
+    [EnumeratorCancellation] CancellationToken cancellationToken)
+{
+    await foreach (var response in EnumerateResponsesAsync(requestBuilder, cancellationToken))
+    {
+        foreach (var obj in response.S3Objects ?? [])
+            yield return obj;
+    }
+}

figures/code/presigned-url.cs

@@ -0,0 +1,39 @@
+private async Task<string?> GetPreSignedUrlAsync(DocumentKey key, bool inline, CancellationToken cancellationToken)
+{
+    if (!await ObjectExistsAsync(key, cancellationToken))
+        return null;
+
+    var request = new GetPreSignedUrlRequest
+    {
+        BucketName = _settings.S3.Bucket,
+        Key = key.ToString(),
+        Verb = HttpVerb.GET,
+        Expires = DateTime.UtcNow.Add(DownloadUrlLifetime),
+        ResponseHeaderOverrides =
+        {
+            ContentDisposition = inline
+                ? InlineContentDisposition(key.Name.ToString())
+                : AttachmentContentDisposition(key.Name.ToString()),
+        },
+    };
+
+    return await s3.GetPreSignedURLAsync(request);
+}
+
+private static string AttachmentContentDisposition(string fileName)
+{
+    var header = new ContentDispositionHeaderValue("attachment");
+    header.SetHttpFileName(fileName);
+    return header.ToString();
+}
+
+/// <summary>
+/// Builds a <c>Content-Disposition</c> header that lets the browser render the document inline
+/// while preserving the file name, using RFC 5987 encoding so non ASCII file names survive.
+/// </summary>
+private static string InlineContentDisposition(string fileName)
+{
+    var asciiFallback = new string(fileName.Select(c => c is >= ' ' and < (char)127 and not '"' ? c : '_').ToArray());
+    var encoded = Uri.EscapeDataString(fileName);
+    return $"inline; filename=\"{asciiFallback}\"; filename*=UTF-8''{encoded}";
+}

figures/code/rename-customer-folder.cs

@@ -0,0 +1,54 @@
+/// <summary>
+/// todo: this function can currently cause dataloss. see #10070
+/// </summary>
+/// <returns>success</returns>
+private async Task<bool> RenameCustomerFolderAsync(
+    OrgSlug source, OrgSlug destination, OrgId owner, CancellationToken cancellationToken)
+{
+    if (source == destination)
+        return true;
+
+    if (!await CanClaimCustomerFolderAsync(destination, owner, cancellationToken))
+        return false;
+
+    var sourcePrefix = source.ToString();
+    var destinationPrefix = destination.ToString();
+
+    var sourceKeys = await ListKeysAsync(sourcePrefix, cancellationToken);
+
+    // The marker of the customer folder carries the efecte-org-id, so it is copied last and
+    // deleted first: the destination only becomes resolvable once it is complete. Everything
+    // below the customer folder keeps its relative key, including subfolders Houston does not
+    // know, so no document ever ends up somewhere else.
+    var documentKeys = sourceKeys.Where(key => key != sourcePrefix).ToList();
+    var markerKeys = sourceKeys.Where(key => key == sourcePrefix).ToList();
+    var copiedKeys = new List<string>(sourceKeys.Count);
+
+    try
+    {
+        foreach (var key in documentKeys.Concat(markerKeys))
+        {
+            var destinationKey = destinationPrefix + key[sourcePrefix.Length..];
+            await CopyObjectAsync(key, destinationKey, cancellationToken);
+            copiedKeys.Add(destinationKey);
+        }
+    }
+    catch (AmazonS3Exception exception)
+    {
+        ExceptionlessClient.Default.SubmitLog(
+        $"Could not move customer folder '{source}' to '{destination}': {exception.Message}. "
+        + "The folder stays where it is.", LogLevel.Error);
+
+        // Leftover copies would block every later attempt, because the destination is only
+        // claimed while it is empty. Cleaning them up keeps the move retryable.
+        await TryDeleteObjectsAsync(copiedKeys, cancellationToken);
+        return false;
+    }
+
+    // From here on the destination is authoritative. A failure while deleting only leaves
+    // garbage behind, the customer already sees all of his documents under the new name.
+    await TryDeleteObjectsAsync(documentKeys, cancellationToken);
+    await TryDeleteObjectsAsync(markerKeys, cancellationToken);
+
+    return true;
+}

figures/code/resolve-customer-prefix.cs

@@ -0,0 +1,64 @@
+private async Task<OrgSlug?> GetCustomerFolderAsync(OrgName name, OrgId id, CancellationToken cancellationToken)
+{
+    if (!OrgSlug.TryFrom(name, out var canonicalSlug) || !OrgSlug.TryFrom(name, id, out var collisionSlug))
+    {
+        ExceptionlessClient.Default.SubmitLog($"Efecte name '{name}' of organization {id} does not yield a usable folder name.", LogLevel.Warn);
+        return null;
+    }
+
+    var (prettySlug, uniqueSlug) = (canonicalSlug.Value, collisionSlug.Value);
+
+    // Fast path: pretty slug exists & meta-id matches => return slug(name)
+    var prettyState = await InspectCustomerFolderAsync(prettySlug, id, cancellationToken);
+    if (prettyState is CustomerFolderState.Owned)
+        return prettySlug;
+
+    // Conflict resolution: pretty slug exists & meta-id does not match => return slug(name,id)
+    var uniqueState = await InspectCustomerFolderAsync(uniqueSlug, id, cancellationToken);
+    if (uniqueState is CustomerFolderState.Owned)
+        return uniqueSlug;
+
+    // State cleanup:
+    // Either the folder does not have the name it should have or doesn't exist, so the bucket has to be scanned. And
+    // if necessary and possible, renamed such that the next lookup hits one of the expected slugs.
+
+    OrgSlug? availableSlug =
+          prettyState is CustomerFolderState.Missing ? prettySlug
+        : uniqueState is CustomerFolderState.Missing ? uniqueSlug
+        : null;
+
+    var currentSlug = await SearchCustomerPrefixAsync(id, cancellationToken);
+
+    if (currentSlug is null)
+    {
+        if (availableSlug is not { } available)
+        {
+            ExceptionlessClient.Default.SubmitLog(
+                $"Organization {id} has no customer folder and neither "
+                + $"'{prettySlug}' nor '{uniqueSlug}' is available.", LogLevel.Error);
+            return null;
+        }
+
+        if (!await CreateCustomerFolderAsync(available, id, cancellationToken))
+            return null;
+
+        if (await InspectCustomerFolderAsync(available, id, cancellationToken) is not CustomerFolderState.Owned)
+        {
+            ExceptionlessClient.Default.SubmitLog(
+                $"Organization {id} has no customer folder and "
+                + $"'{available}' could not be created.", LogLevel.Error);
+            return null;
+        }
+
+        return available;
+    }
+
+    if (availableSlug is null || availableSlug.Value == currentSlug.Value)
+        return currentSlug;
+
+    // A failed move leaves every document under the name it already had, so that name is what
+    // gets handed back. The next lookup simply tries the move again.
+    return await RenameCustomerFolderAsync(currentSlug.Value, availableSlug.Value, id, cancellationToken)
+        ? availableSlug
+        : currentSlug;
+}

figures/code/s3-client-registration.cs

@@ -0,0 +1,38 @@
+using Amazon.Runtime;
+using Amazon.S3;
+using Houston.Settings;
+using Microsoft.Extensions.Options;
+
+namespace Houston.Extensions;
+
+public static class DocumentsExtensions
+{
+    extension(IServiceCollection services)
+    {
+        public IServiceCollection AddDocumentsClient()
+        {
+            return services.AddKeyedScoped<IAmazonS3>("Documents", (services, _) =>
+            {
+                var settings = services.GetRequiredService<IOptions<DocumentsSettings>>();
+                var client = new AmazonS3Client(
+                    new BasicAWSCredentials(settings.Value.S3.Key, settings.Value.S3.Secret),
+                    new AmazonS3Config { ServiceURL = settings.Value.S3.Endpoint });
+
+                // The SDK percent-encodes the separators in x-amz-copy-source ("bucket%2Fkey%2Fdoc.pdf").
+                // AWS decodes that again, our S3 splits bucket and key on the first literal slash and ends up
+                // without a key ("Invalid copy source object key"), so the separators are restored here. The
+                // event runs before the signer, hence the corrected value is the one that gets signed.
+                client.BeforeRequestEvent += (_, args) =>
+                {
+                    if (args is WebServiceRequestEventArgs { Headers: { } headers }
+                        && headers.TryGetValue("x-amz-copy-source", out var copySource)
+                        && copySource.Contains("%2F", StringComparison.Ordinal))
+                    {
+                        headers["x-amz-copy-source"] = copySource.Replace("%2F", "/", StringComparison.Ordinal);
+                    }
+                };
+
+                return client;
+            });
+        }
+    }

figures/code/s3-settings.cs

@@ -0,0 +1,16 @@
+namespace Houston.Settings;
+
+public class DocumentsSettings
+{
+    public required S3Settings S3 { get; set; }
+}
+
+namespace Houston.Settings;
+
+public class S3Settings
+{
+    public required string Endpoint { get; set; }
+    public required string Key { get; set; }
+    public required string Secret { get; set; }
+    public required string Bucket { get; set; }
+}

figures/code/share-page.cs

@@ -0,0 +1,61 @@
+using Houston.Model.Documents;
+using Microsoft.AspNetCore.Authorization;
+using Microsoft.AspNetCore.Http.Extensions;
+using Microsoft.AspNetCore.Mvc;
+using Microsoft.AspNetCore.Mvc.RazorPages;
+
+namespace Houston.Pages.Document;
+
+/// <summary>
+/// Anonymous landing page for shared document links. It exposes only metadata derived from the
+/// document id and never fetches or renders file contents.
+/// </summary>
+public class Share : PageModel
+{
+    [BindProperty(SupportsGet = true)]
+    public string Id { get; set; } = String.Empty;
+
+    public string Title { get; private set; } = "Dokument";
+
+    public string ImageUrl { get; private set; } = String.Empty;
+
+    public string ExplorerUrl { get; private set; } = String.Empty;
+
+    public IActionResult OnGet()
+    {
+        var docId = new DocumentId(Id);
+
+        if (!docId.TryDecode(out var relativePath))
+            return NotFound();
+
+        var type = relativePath.Value.Type;
+        var name = relativePath.Value.Name;
+        var iconPath = type.PreviewPath;
+
+        Title = name.DisplayName;
+        ImageUrl = AbsoluteUrl(iconPath);
+        ExplorerUrl = AbsoluteUrl("/documents", BuildExplorerQuery(type, name), $"#{Documents.DocumentViewId(docId)}");
+
+        return Page();
+    }
+
+    private static QueryString BuildExplorerQuery(DocumentType? type, DocumentName name)
+    {
+        return new QueryBuilder {
+            { "q", name.DisplayName },
+            { "types", type.Name }
+        }.ToQueryString();
+    }
+
+    private string AbsoluteUrl(string path, QueryString query = default, string? fragment = null)
+    {
+        return UriHelper.BuildAbsolute(
+            Request.Scheme,
+            Request.Host,
+            Request.PathBase,
+            path,
+            query,
+            fragment: fragment is null ? default : new FragmentString(fragment)
+        );
+    }
+}

figures/code/test-path-traversal.cs

@@ -0,0 +1,12 @@
+[Theory]
+[InlineData("../Kunde2/secret.pdf")]
+[InlineData("sub/../../Kunde2/secret.pdf")]
+public void DocumentIdTryParseRejectsPathTraversal(string relativePath)
+{
+    Assert.False(new DocumentId(UnsafeDocumentIdValue(relativePath)).TryDecode(out _));
+}
+
+
+// Test-Hilfsfunktion: erzeugt bewusst eine ID, die die Validierung umgeht.
+private static string UnsafeDocumentIdValue(string relativePath)
+    => WebEncoders.Base64UrlEncode(Encoding.UTF8.GetBytes(relativePath));

figures/code/tests-empty-bucket.cs

@@ -0,0 +1,44 @@
+
+/// <summary>
+/// A bucket without a single object: every lookup answers with a 404 and every listing is empty
+/// until a test puts something in via <see cref="GiveFolder"/>, <see cref="GiveTopLevelFolders"/>
+/// or <see cref="GiveObjects"/>.
+/// </summary>
+private static IAmazonS3 EmptyBucket()
+{
+    var s3 = Substitute.For<IAmazonS3>();
+
+    // Objects written during the test become visible to later lookups, just like in a real bucket.
+    var writtenObjects = new Dictionary<string, string?>(StringComparer.Ordinal);
+
+    s3.GetObjectMetadataAsync(Arg.Any<GetObjectMetadataRequest>(), Arg.Any<CancellationToken>())
+        .Returns(call =>
+        {
+            var key = call.Arg<GetObjectMetadataRequest>().Key;
+
+            if (!writtenObjects.TryGetValue(key, out var owner))
+                throw new AmazonS3Exception("not found") { StatusCode = System.Net.HttpStatusCode.NotFound };
+
+            return owner is null ? new GetObjectMetadataResponse() : MetadataResponse(owner);
+        });
+
+    s3.ListObjectsV2Async(Arg.Any<ListObjectsV2Request>(), Arg.Any<CancellationToken>())
+        .Returns(_ => new ListObjectsV2Response { IsTruncated = false });
+
+    s3.CopyObjectAsync(Arg.Any<CopyObjectRequest>(), Arg.Any<CancellationToken>())
+        .Returns(_ => new CopyObjectResponse());
+
+    s3.PutObjectAsync(Arg.Any<PutObjectRequest>(), Arg.Any<CancellationToken>())
+        .Returns(call =>
+        {
+            var request = call.Arg<PutObjectRequest>();
+            writtenObjects[request.Key] = request.Metadata["efecte-org-id"];
+            return new PutObjectResponse();
+        });
+
+    s3.DeleteObjectsAsync(Arg.Any<DeleteObjectsRequest>(), Arg.Any<CancellationToken>())
+        .Returns(_ => new DeleteObjectsResponse());
+
+    return s3;
+}
+

figures/code/type-icon-mask.scss

@@ -0,0 +1,28 @@
+.doc-type-icon {
+    display: inline-flex;
+    width: 1.25em;
+    height: 1.25em;
+    vertical-align: middle;
+    align-items: center;
+    justify-content: center;
+}
+
+@each $name in (
+    'service-protokoll',
+    'abnahme-dokumente',
+    'sla-reports',
+    'monitoring-reports',
+    'security-assessments',
+    'abrechnungsdaten',
+    'vertragsunterlagen',
+    'default',
+    'ms-sharepoint',
+    'ms-onedrive',
+    'ms-teams',
+) {
+    .doc-type-icon-#{$name} {
+        background-color: currentColor;
+        mask-repeat: no-repeat;
+        mask-position: center;
+        mask-size: contain;
+        mask-image: url('/img/document-types/icons/#{$name}.svg');

figures/code/url-file-parsing.cs

@@ -0,0 +1,43 @@
+public async Task<string?> TryGetUrlFileIconClassAsync(DocumentKey doc, CancellationToken cancellationToken)
+{
+    var ini = await TryReadUrlFileAsync(doc, cancellationToken);
+    var iconFile = ini?.GetValue("InternetShortcut", "IconFile");
+
+    return String.IsNullOrEmpty(iconFile) ? null : iconFile;
+}
+
+private async Task<string?> TryGetUrlFileTargetAsync(DocumentKey doc, CancellationToken cancellationToken)
+{
+    var ini = await TryReadUrlFileAsync(doc, cancellationToken);
+    var target = ini?.GetValue("InternetShortcut", "URL");
+
+    if (String.IsNullOrWhiteSpace(target))
+        return null;
+
+    if (!Uri.TryCreate(target, UriKind.Absolute, out var uri))
+        return null;
+
+    if (!(uri.Scheme == Uri.UriSchemeHttp || uri.Scheme == Uri.UriSchemeHttps))
+        return null;
+
+    return uri.ToString();
+}
+
+private async Task<IniDocument?> TryReadUrlFileAsync(DocumentKey doc, CancellationToken cancellationToken)
+{
+    try
+    {
+        using var response = await s3.GetObjectAsync(new GetObjectRequest
+        {
+            BucketName = _settings.S3.Bucket,
+            Key = doc.ToString(),
+        }, cancellationToken);
+
+        using var reader = new StreamReader(response.ResponseStream);
+        return await iniParser.ParseAsync(reader, cancellationToken);
+    }
+    catch (AmazonS3Exception exception) when (exception.StatusCode == HttpStatusCode.NotFound)
+    {
+        return null;
+    }
+}

figures/code/zip-archive.cs

@@ -0,0 +1,41 @@
+/// <summary>
+/// Streams the prepared documents into a ZIP archive written directly onto <paramref name="destination"/>
+/// </summary>
+public async Task WriteZipArchiveAsync(
+    OrgSlug orgSlug, IEnumerable<DocumentRelativePath> documents,
+    Stream destination, CancellationToken cancellationToken)
+{
+    await using var zip = await ZipArchive.CreateAsync(
+        destination, ZipArchiveMode.Create, leaveOpen: true,
+        entryNameEncoding: null, cancellationToken);
+
+    foreach (var path in documents)
+    {
+        var key = new DocumentKey(orgSlug, path.Type, path.Name);
+
+        using var response = await TryGetObjectAsync(new GetObjectRequest
+        {
+            BucketName = _settings.S3.Bucket,
+            Key = key.ToString(),
+        }, cancellationToken);
+
+        if (response is null)
+            continue;
+
+        var entry = zip.CreateEntry(path.ToString(), CompressionLevel.Optimal);
+        await using var entryStream = await entry.OpenAsync(cancellationToken);
+        await response.ResponseStream.CopyToAsync(entryStream, cancellationToken);
+    }
+}
+
+private async Task<GetObjectResponse?> TryGetObjectAsync(GetObjectRequest request, CancellationToken cancellationToken)
+{
+    try
+    {
+        return await s3.GetObjectAsync(request, cancellationToken);
+    }
+    catch (AmazonS3Exception exception) when (exception.StatusCode == HttpStatusCode.NotFound)
+    {
+        return null;
+    }
+}

figures/code/zip-download-handler.cs

@@ -0,0 +1,42 @@
+public async Task<IActionResult> OnPostDownloadZipAsync(CancellationToken cancellationToken)
+{
+    if (!OrgName.TryCreate(User.GetCompanyName(), out var orgName))
+        return NotFound();
+
+    var fallback = RedirectToPage(new
+    {
+        q = Search,
+        types = TypeFilterSelection,
+        pageSize = PageSize,
+        pageToken = PageToken,
+    });
+
+    if (SelectedDocuments is null || SelectedDocuments.Count == 0)
+        return fallback;
+
+    var relativePaths = SelectedDocuments
+        .SelectWhere<string, DocumentRelativePath>(x => new DocumentId(x).TryDecode(out var y) ? y.Value : null)
+        .Where(x => IsDownloadable(x.Name))
+        .ToList();
+
+    if (relativePaths.Count == 0)
+        return fallback;
+
+    var orgSlug = await documents.ResolveCustomerPrefixAsync(OrgId, orgName.Value, cancellationToken);
+    if (orgSlug is null)
+        return fallback;
+
+    // Zipping compresses each entry with a DeflateStream, which flushes its buffers synchronously
+    // when the entry is closed. Kestrel forbids synchronous response writes by default, so we opt
+    // in for this streamed response only. Nothing large is written synchronously - the document
+    // payloads are still copied with async IO.
+    var bodyControl = HttpContext.Features.Get<IHttpBodyControlFeature>();
+    bodyControl?.AllowSynchronousIO = true;
+
+    Response.ContentType = "application/zip";
+    Response.Headers.ContentDisposition = $"attachment; filename=\"{DocumentsService.ZipDownloadFileName}\"";
+
+    await documents.WriteZipArchiveAsync(orgSlug.Value, relativePaths, Response.Body, cancellationToken);
+
+    return new EmptyResult();
+}

figures/diagrams/module-components.mmd

@@ -1,29 +1,39 @@
-classDiagram
+flowchart TB
-    class DocumentsPage {
+    subgraph Pages["Pages"]
-        +OnGetAsync()
+        P1["Documents.cshtml<br/>+ .cshtml.cs<br/><i>Liste, Suche, Filter, Seiten</i>"]
-        +OnGetDownloadAsync()
+        P2["Document/Download.cshtml.cs<br/><i>Einzel- und ZIP-Download</i>"]
-        +OnGetZipAsync()
+        P3["Document/Share.cshtml.cs<br/><i>OpenGraph-Vorschau</i>"]
-    }
+    end
-    class DocumentsService {
+
-        +ListDocumentsAsync(orgId, search, type, token)
+    subgraph Services["Services"]
-        +GetDownloadUrlAsync(orgId, key)
+        S["DocumentsService<br/><i>Auflisten, Filtern, Aufloesen<br/>des Kundenordners</i>"]
-        +GetZipStreamAsync(orgId, keys)
+        C["S3DocumentsClient<br/><i>Kapselung von IAmazonS3</i>"]
-        +ResolveCustomerPrefixAsync(orgId, orgName)
+    end
-    }
+
-    class S3DocumentsClient {
+    subgraph Model["Model/Documents"]
-        -IAmazonS3 _s3
+        M1["DocumentType<br/><i>Enum + Ableitung<br/>aus Ordnername</i>"]
-        +ListObjectsAsync(prefix, delimiter, token)
+        M2["DocumentName<br/><i>Anzeigename,<br/>.url-Erkennung</i>"]
-        +GetObjectMetadataAsync(key)
+        M3["DocumentKey /<br/>RelativePath<br/><i>validierte Pfade</i>"]
-        +GetPresignedUrlAsync(key)
+        M4["OrgSlug<br/><i>Normalisierung des<br/>Firmennamens</i>"]
-    }
+        M5["DocumentViewModel"]
-    class OrgSlug {
+    end
-        +Slugify(name) string
+
-    }
+    EXT["IAmazonS3<br/>(AWS SDK)"]
-    class S3Settings {
+    CFG["S3Settings<br/><i>keyed service</i>"]
-        +BucketName string
+
-        +ServiceUrl string
+    P1 --> S
-    }
+    P2 --> S
-    DocumentsPage --> DocumentsService
+    P3 --> S
-    DocumentsService --> S3DocumentsClient
+    S --> C
-    DocumentsService --> OrgSlug
+    S --> M1
-    S3DocumentsClient --> S3Settings
+    S --> M2
+    S --> M4
+    S --> M5
+    P2 --> M3
+    C --> EXT
+    C --> CFG
+
+    style S fill:#dae8fc,stroke:#6c8ebf
+    style C fill:#dae8fc,stroke:#6c8ebf
+    style EXT fill:#f5f5f5,stroke:#999
+    style CFG fill:#f5f5f5,stroke:#999

figures/diagrams/race-condition-a.mmd

@@ -1,15 +1,21 @@
 sequenceDiagram
-    participant A as Request A
+    autonumber
+    participant A as Anfrage A
     participant S3 as S3-Speicher
-    participant B as Request B
+    participant B as Anfrage B
 
-    Note over A,B: Ordner AltName/ mit 200 Objekten, Zielname: Kunde GmbH/
+    Note over A,B: Ausgangslage: Ordner "AltName/" mit 200 Objekten,<br/>Zielname "Kunde GmbH/". Beide Anfragen gehoeren derselben Org.
-    A->>S3: CanClaim(Kunde GmbH) → Missing → true
+
-    B->>S3: CanClaim(Kunde GmbH) → Missing → true
+    A->>S3: CanClaim("Kunde GmbH") → frei
-    A->>S3: Kopiere 200 Objekte nach Kunde GmbH/
+    B->>S3: CanClaim("Kunde GmbH") → frei
-    B->>S3: Kopiere Objekte #1–60 nach Kunde GmbH/
+    Note over A,B: Beide halten den Zielnamen fuer beanspruchbar
-    A->>S3: DeleteObjects(AltName/*) ✓
+
-    B->>S3: Kopie #61 → NoSuchKey ✗
+    A->>S3: kopiert alle 200 Objekte
-    B->>S3: catch: DeleteObjects(copiedKeys #1–60)
+    B->>S3: kopiert Objekte 1 bis 60
-    Note over S3: 60 Objekte aus Kunde GmbH/ gelöscht!
+    A->>S3: DeleteObjects("AltName/*")
-    Note over S3: AltName/ existiert nicht mehr → Datenverlust
+    Note over S3: Quelle ist jetzt geloescht
+
+    B->>S3: kopiert Objekt 61 → NoSuchKey
+    B->>S3: catch: DeleteObjects(eigene 60 Kopien)
+
+    Note over S3: Die 60 geloeschten Objekte sind genau die,<br/>die A erfolgreich geschrieben hatte.<br/>Die Quelle existiert nicht mehr — Datenverlust.

figures/diagrams/zip-stream.mmd

@@ -1,15 +1,21 @@
 sequenceDiagram
-    participant B as Browser
+    autonumber
-    participant P as PageModel
+    actor U as Benutzer
+    participant P as Download-PageModel
     participant S as DocumentsService
+    participant Z as ZipArchive
     participant S3 as S3-Speicher
 
-    B->>P: POST /documents?handler=Zip&keys=[...]
+    U->>P: Auswahl + Klick auf<br/>"Als ZIP herunterladen"
-    P->>S: GetZipStreamAsync(orgId, keys)
+    P->>S: Schluessel gegen Kundenpraefix pruefen
-    loop je Dokument
+    S-->>P: validierte Schluessel
-        S->>S3: GetObjectAsync(key)
+    P->>U: Antwort-Header:<br/>application/zip
-        S3-->>S: Stream
+    loop je ausgewaehltes Dokument
-        S->>S: ZipArchive.CreateEntry + CopyToAsync
+        S->>S3: GetObject(key)
+        S3-->>S: Inhalts-Stream
+        S->>Z: Eintrag mit relativem Pfad anlegen
+        Z->>U: komprimierte Bytes<br/>direkt in die Antwort
     end
-    S-->>P: ZipStream
+    Z->>U: Archiv abschliessen
-    P-->>B: application/zip (streaming)
+
+    Note over Z,U: Kein Zwischenspeichern im<br/>Arbeitsspeicher oder auf Platte

main.tex

@@ -20,8 +20,8 @@
   {Sarah Hinzmann}
 
 \setdates
-{07.07.2026 -- <WIP>}
+{07.07.2026 -- 25.08.2026}
-{<WIP>}
+{25.08.2026}
 
 \begin{document}
 

shell.nix

@@ -1,17 +1,19 @@
-with import <nixpkgs> {}; let
+let
+  # Pinned to the same nixpkgs revision as itc.componentware, where the minted
+  # toolchain is known to work. The channel version ships a latexminted that
+  # crashes on Python 3.14, which makes every code listing fail.
+  pkgs = import (builtins.fetchTarball {
+    url = "https://github.com/NixOS/nixpkgs/archive/cc3f2ee0b3909e42334f34720ccac109a7e67068.tar.gz";
+    sha256 = "sha256:0lz0yl9fmh5wfqp7j7rmcs8qjqr3bf1h5cy4rfdasbnbzh4k9j6x";
+  }) {};
+
   fonts = [
-    times-newer-roman
+    pkgs.times-newer-roman
   ];
-  # This is not reccocgnised by latexmk, so we will have to put our
-  # font files in ~/.local/share/fonts
-  # fontsConf = makeFontsConf {
-  #   fontDirectories = fonts;
-  # };
-  # export FONTCONFIG_FILE="${fontsConf}"
 in
-  mkShell {
+  pkgs.mkShell {
     nativeBuildInputs = fonts;
-    packages = [
+    packages = with pkgs; [
       latexrun
       mermaid-cli
       times-newer-roman
@@ -42,6 +44,6 @@ in
       # install fonts
       DEST=~/.local/share/fonts/TimesNewerRoman
       mkdir -p $DEST
-      cp -r ${toString times-newer-roman}/share/fonts/opentype "$DEST"
+      cp -rn ${toString pkgs.times-newer-roman}/share/fonts/opentype "$DEST" 2>/dev/null || true
     '';
   }