add abstract

adjust dates
Zeitraum-Abgrenzung und Manntage-Verteilung ergaenzt
2026-09-10 19:25:50 +02:00 · 2026-09-10 19:09:35 +02:00 · 2026-09-10 19:06:21 +02:00 · 2026-09-07 23:49:37 +02:00 · 2026-09-07 23:42:43 +02:00 · 2026-09-07 23:37:09 +02:00
102 changed files with 733 additions and 639 deletions
@@ -0,0 +1,28 @@
 #!/usr/bin/env bash
 # Zaehlt die reinen Textseiten (Kapitel 1-7 ohne Floats, Frontmatter und Anhang).
 set -e
 SRC="$(cd "$(dirname "$0")" && pwd)"
 WORK=/tmp/pidi3-textcount
 rm -rf "$WORK"; mkdir -p "$WORK"
 tar -C "$SRC" --exclude=out --exclude=.git -cf - . | tar -C "$WORK" -xf -
 cd "$WORK"
 # Floats entfernen
 for f in $(find chapters -name '*.tex'); do
  awk '
    /\\begin\{(figure|table|longtable|center)\}/ { d++; next }
    /\\end\{(figure|table|longtable|center)\}/   { if (d) { d--; next } }
    d == 0 { print }
  ' "$f" > "$f.tmp" && mv "$f.tmp" "$f"
 done
 # Nur Kapitel 1-7 bauen
 awk '
  /\\frontmatterpages/ { next }
  /\\appendix/ { print "\\end{document}"; exit }
  { print }
 ' main.tex > count.tex
 sed -i 's/\\printrefs//' count.tex
 latexmk -pdflua -interaction=nonstopmode -halt-on-error count.tex >/dev/null 2>&1 || true
 pdfinfo out/count.pdf | awk '/Pages/ {print "Reine Textseiten: " $2}'
@@ -29,14 +29,18 @@ and Times Newer Roman (fonts are installed into `~/.local/share/fonts/` by the s
 ```sh
 # render a single diagram
-mmdc -i figures/diagrams/system-context.mmd -o figures/diagrams/system-context.pdf
+mmdc -f -i figures/diagrams/system-context.mmd -o figures/diagrams/system-context.pdf
 # render all diagrams at once
 for f in figures/diagrams/*.mmd; do
-  mmdc -i "$f" -o "${f%.mmd}.pdf"
+  mmdc -f -i "$f" -o "${f%.mmd}.pdf"
 done
 ```
 `-f` (`--pdfFit`) is mandatory: without it `mmdc` writes the chart onto a full US-Letter
 page, so `\includegraphics[width=\textwidth]` scales all that surrounding whitespace up
 and a small diagram eats a whole A4 page.
 Render before calling `latexmk` whenever a `.mmd` file changes. The generated `.pdf`
 files are gitignored via `out` (only `out/` is ignored, so diagrams in `figures/` are
 **not** ignored — commit them).
@@ -0,0 +1,47 @@
 von mir an den Agenten.
 screenshots habe ich in figures/screenshots gelegt.
 # Inhaltliche TODOs
 - [x] screenshots vom feature in den anhang
 - [x] aktualisieren auf den aktuellen devops stand (alles getested, 1 bug fixed, user pdf was documented, prod deployment)
    -> "3.5 Zeit- und Aufwandsplanung" aktualisieren
    -> "Figure 3.2: Zeitplanung des Projekts" aktualisieren
    -> "5.10.5 Stand bei Abgabe" aktualisieren
    -> In azure devops, you will see that the last completed (in Test Completed, and in the Deployed in PROD) work item was not "Test Completed" until the 07.09.2026. Pretend that this was completed before the prod release, such that the history looks clean.
    -> allgemein ueber alle chapter nochmal drueber gehen und schauen ob das den aktuellen stand reflektiert
 - [x] architektur der implementierung:
    - ich habe in meiner freizeit sehr viel rust programmiert und dort auch das NewType pattern kennen gelernt, an dem ich mich hier orientierte (auch wenn es C# ist), da ich die vorteile besonders hier wo man eigentlich mit den nur mit ganz vielen string keys rum hantiert, sie aus einander baut, und wieder zusammenbaut, erkannte. id input string -> s3 gibt keys zurueck -> parsing -> domain model -> verbarbeitung -> wenn weitere requests gebraucht werden, vom domain model wieder einen key zusammenbauen
    - "parse, don't validate" philosophie
 - [x] mit den vom pidi 2 noch relevanten abbildungen ergaenzen
    - houston architektur
    - unicorn prozess
    - etc.
 - [x] "Figure 3.1: Zustände eines Work Items in Azure DevOps" sollte mit dem eigentlichem unicorn prozess bild ersaetzt werden. ich arbeite naehmlich nach dem ganz normalen prozess
    - "3.4.1 Entwicklungsprozess" sollte dahingehend auch aktualisiert werden, und nicht *Linus-speziefisch* sein.
 - [x] "3.4.2 Schnitt der Product Backlog Items": ein abbild aus dem devops oder eine tabelle mit den PBIs ergaenzen verweisen
 - [x] "Figure 3.3: Chronologie der Infrastrukturbeschaffung" sieht komisch aus, die pfeile gehen nach unten Chronologie geht aber nach rechts. sollte gefixed werden.
 - [x] "4.3.3 Verhalten bei unbekannten Ordnern" (todo fuer mich) ist das richtig? oder werden unbakannte typ-order einfach nicht angezeigt? bin mir da gerade nichtmal sicher
 - [x] "4.4.1 Zuarbeit über einen Clickdummy" bezieht sich rein ueber das UI der Typ-Filterung. alles andere stammt von mir. Hanna Ebner hat in Houston die fuehrende Entscheidungskraft, was das UI angeht, und aus dem Grund habe ich mich mit ihr abgestimmt wie das aussehen soll, und sie hat als Referenz den Clickdummy branch erstellt. Die implementierung liegt immer noch in meiner hand. (das ist wichtig fuer das PIDI, da die Arbeit eigentlich von mir kommen soll).
 - [x] in "4.4.2 Flache Liste statt navigierbarer Hierarchie": "Die ursprüngliche Beschreibung sah Dokumentkacheln vor, wurde jedoch auf Zeilen-darstellung geändert" auch das ist eine Entscheidung von Hanna Ebner, die meine überwichtete.
 - [x] "4.4.3 Aufbau der Seite": screenshots im anhang einfügen und verweisen
 - [x] "4.5.2 Untersuchte Lösungsansätze" Lösungsansätze wurden von allein *mir* erarbeitet und mit Timo und Bianco nur abgesprochen und reviewed.
 - [x] "5.4.1 Eigene Symbole statt Symbolschrift": icons im anhang einfuegen, darauf hinweisen, dass die Designs von mir entworfen und in Zusammenarbeit mit Hanna Ebner ausgearbeitet wurden.
 - [x] "Nicht umgesetzt ist eine Filterung durch den Speicher. Houston listet die Objekte auf und filtert die Namen anschließend selbst. Im Review stellte Hanna Ebner die Frage, ob sich das nicht direkt über die Schnittstelle lösen lasse, und musste verneint werden.": auf den abschnitt verweisen wo die AU die Search Integration abgelehnt hat
 - [x] "5.8.3 Vorschau in Messengern": auf screenshots verweisen
 - [x] "5.8.4 Sichtbarkeit der Vorschaubilder": darauf verweisen, dass es eigentlich ziemlich elegant ist das gesamte vorschau bild von der base64 encoded id in der url auf dem öffentlichem `/share`-endpunkt zu lesen. somit wird auf diesem öffentlichem endpunkt niemals auch nur ein aufruf nach s3 gemacht.
 - [x] "5.9.5 Symbole für Verknüpfungen": screenshots von symbolen verweisen, maybe mehr info zu den icons (siehe resources/xwiki/urlfile_docs.xwiki)
 # Strukturelle TODOs
 - [x] auf etwa 45 Seiten runter bringen (zuletzt machen nachdem der inhalt angepasst wurde)
    - [x] brauchen wir in "3.6 Beschaffung der S3-Infrastruktur" wirklich eine Bewertung...?
    - [x] allegemin sowas wie: "Im Review fragte Robin Noack, ob die Einschränkungen ausreichen. Eine zu schwache Norma lisierung führt zu Schlüsseln, die der Speicher zurückweist — das wäre erst bei einem Kunden mit ungewöhnlichem Firmenna men aufgefallen. Die Antwort verwies auf die Herstellerdokumentation (IBM 2026; Amazon Web Services 2026c)." das ist vie lzuviel text einfach nur um zu sagen "laut der IBM doku passt das so"
    - [x] "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 wur den ersetzt." unnötige details schon wieder...
 // ist das noch kaputt? - [ ] Ein paar der bibreferences sehen komisch aus und zeigen nicht richtig auf den korrekten bib eintrag, sollte gefixed werden.
 - [x] Die Abbildungen nehmen vertikal sehr viel white space ein, das sollte nicht so sein.
 - [ ] ähnlich wie ich es in ~/repos/itc.componentware/ gemacht habe, eine flake und ein build output haben.
 # Review
 - [x] "4.5 Das Lookup-Problem" auf Inhaltliche korrektheit pruefen
@@ -1 +0,0 @@
 % TODO: eingebundene Diagramme (falls nicht inline in Kapiteln)
@@ -1 +1,117 @@
-% TODO: Screenshots der fertigen Documents-Seite (Liste, Filter, Suche, PDF-Modal, ZIP-Auswahl)
+Die folgenden Aufnahmen zeigen den Dokumentenbereich auf dem Testsystem. Die
 Dokumentnamen stammen aus Testdaten und sind bewusst frei erfunden.
 \begin{figure}[H]
    \centering
    \includegraphics[width=\textwidth]{figures/screenshots/explorer_general.png}
    \caption{Der Dokumentenbereich in Houston: Suchleiste, Typfilter, Dokumentenliste mit
    Mehrfachauswahl und Blätterelemente}
    \label{fig:shot-explorer}
 \end{figure}
 \begin{figure}[H]
    \centering
    \includegraphics[width=0.85\textwidth]{figures/screenshots/explorer_type-filters.png}
    \caption{Typfilterung: Nur die hervorgehobenen Typen werden angezeigt}
    \label{fig:shot-type-filters}
 \end{figure}
 \clearpage
 \begin{figure}[H]
    \centering
    \includegraphics[width=0.85\textwidth]{figures/screenshots/explorer_search-query.png}
    \caption{Suche nach einem Namensbestandteil bei gleichzeitig aktiven Typfiltern}
    \label{fig:shot-search}
 \end{figure}
 \begin{figure}[H]
    \centering
    \includegraphics[width=0.8\textwidth]{figures/screenshots/pagination_page-2.png}
    \caption{Zweite Seite der Blätterung; die Adresszeile trägt den Fortsetzungs-Token
    \texttt{pageToken} statt einer Seitennummer}
    \label{fig:shot-pagination}
 \end{figure}
 \clearpage
 \begin{figure}[H]
    \centering
    \includegraphics[width=0.8\textwidth]{figures/screenshots/zip-downloads_in-houston.png}
    \caption{Auswahl mehrerer Dokumente für den ZIP-Download}
    \label{fig:shot-zip-selection}
 \end{figure}
 \begin{figure}[H]
    \centering
    \includegraphics[width=0.7\textwidth]{figures/screenshots/zip-downloads_after-download.png}
    \caption{Das erzeugte Archiv nach dem Entpacken: Die Typordner sind erhalten,
    typlose Dokumente liegen auf oberster Ebene}
    \label{fig:shot-zip-result}
 \end{figure}
 \clearpage
 \begin{figure}[H]
    \centering
    \includegraphics[width=0.85\textwidth]{figures/screenshots/pdf_previewer.png}
    \caption{PDF-Vorschau im Modal ohne Verlassen der Seite}
    \label{fig:shot-pdf-preview}
 \end{figure}
 \begin{figure}[H]
    \centering
    \includegraphics[width=0.8\textwidth]{figures/screenshots/explorer_opened-share-link.png}
    \caption{Ergebnis eines geöffneten Freigabelinks: Suche, Typfilter und Seite sind so
    gesetzt, dass das verwiesene Dokument sichtbar und hervorgehoben ist}
    \label{fig:shot-share-target}
 \end{figure}
 \clearpage
 \begin{figure}[H]
    \centering
    \includegraphics[width=0.85\textwidth]{figures/screenshots/sharelink-preview_in-teams.png}
    \caption{Vorschau eines Freigabelinks in Microsoft Teams mit Dokumentname und Typbild}
    \label{fig:shot-share-teams}
 \end{figure}
 \begin{figure}[H]
    \centering
    \includegraphics[width=0.85\textwidth]{figures/screenshots/url-file-icons.png}
    \caption{Symbole für \texttt{.url}-Dateien: mit ausdrücklichem \texttt{IconFile},
    ohne \texttt{IconFile} (Typsymbol des Ordners) sowie bekannte Zielsysteme}
    \label{fig:shot-url-icons}
 \end{figure}
 \begin{figure}[H]
    \centering
    \newcommand{\typeicon}[1]{\raisebox{-0.35\height}{\includegraphics[height=9mm]{figures/icons/#1.pdf}}}
    \begin{tabularx}{\textwidth}{@{} c X c X @{}}
        \toprule
        \multicolumn{2}{@{}l}{\textbf{Dokumententyp}} & \multicolumn{2}{l@{}}{\textbf{Dokumententyp}} \\
        \midrule
        \typeicon{service-protokoll}     & Service-Protokoll
            & \typeicon{security-assessments} & Security Assessments \\
        \addlinespace
        \typeicon{abnahme-dokumente}     & Abnahme-Dokumente
            & \typeicon{abrechnungsdaten}     & Abrechnungsdaten \\
        \addlinespace
        \typeicon{sla-reports}           & SLA-Reports Ticketbearbeitung
            & \typeicon{vertragsunterlagen}   & Vertragsunterlagen \\
        \addlinespace
        \typeicon{monitoring-reports}    & Monitoring-Reports
            & \typeicon{default}              & Sonstige Dokumente (Standardsymbol) \\
        \addlinespace
        \midrule
        \multicolumn{4}{@{}l}{\textbf{Symbole für Verknüpfungen auf bekannte Zielsysteme}} \\
        \midrule
        \typeicon{ms-teams}      & Microsoft Teams
            & \typeicon{ms-sharepoint} & Microsoft SharePoint \\
        \addlinespace
        \typeicon{ms-onedrive}   & Microsoft OneDrive & & \\
        \bottomrule
    \end{tabularx}
    \caption{Die für den Dokumentenbereich entworfenen Symbole}
    \label{fig:type-icons}
 \end{figure}
@@ -11,23 +11,24 @@
 \endhead
 \bottomrule
 \endfoot
-9295  & Document Explorer                             & 8   & 15.2026 & Dev Completed  \\
+9295  & Document Explorer                             & 8   & 15.2026 & Test Completed \\
 9549  & Icon Typen UI                                 & 3   & 15.2026 & Test Completed \\
 9298  & Suchfunktion im Document Explorer             & 3   & 15.2026 & Test Completed \\
-9299  & Einzelne Dokumente herunterladen              & 3   & 15.2026 & Dev Completed  \\
+9299  & Einzelne Dokumente herunterladen              & 3   & 15.2026 & Test Completed \\
-9296  & Mehrere Dokumente als ZIP runterladen         & 5   & 15.2026 & Dev Completed  \\
+9296  & Mehrere Dokumente als ZIP runterladen         & 5   & 15.2026 & Test Completed \\
-9300  & PDF Modal Previewer                           & 3   & 15.2026 & Dev Completed  \\
+9300  & PDF Modal Previewer                           & 3   & 15.2026 & Test Completed \\
 9294  & Document Link previews UI                     & 5   & 15.2026 & Test Completed \\
-9301  & Support für URL-Dateien                       & 5   & 15.2026 & Dev Completed  \\
+9301  & Support für URL-Dateien                       & 5   & 15.2026 & Test Completed \\
 \addlinespace
-9749  & Nach Dokumenttypen filtern                    & 2   & 16.2026 & Dev Completed  \\
+9749  & Nach Dokumenttypen filtern                    & 2   & 16.2026 & Test Completed \\
-9731  & Pagination im Document Explorer               & 3   & 16.2026 & Dev Completed  \\
+9731  & Pagination im Document Explorer               & 3   & 16.2026 & Test Completed \\
-9857  & Recherche: Anfrage Objects nach S3 optimieren & ---  & 16.2026 & Dev Completed  \\
+9857  & Recherche: Anfrage Objects nach S3 optimieren & ---  & 16.2026 & Done           \\
-9560  & Automatische Anlage der Ordnerstruktur        & 3   & 16.2026 & Committed      \\
+9560  & Automatische Anlage der Ordnerstruktur        & 3   & 16.2026 & Test Completed \\
-10018 & Kundenordner-Lookup über Efecte-Namen         & 3   & 16.2026 & Committed      \\
+10018 & Kundenordner-Lookup über Efecte-Namen         & 3   & 16.2026 & Test Completed \\
 \addlinespace
 10070 & Race Conditions im Kundenordner-Lookup        & \footnotesize Timebox & --- & Approved \\
-10134 & \emph{Bug:} Suchfunktion wie auf den anderen Seiten & --- & 17.2026 & To Approve \\
+10134 & \emph{Bug:} Suchfunktion wie auf den anderen Seiten & --- & 17.2026 & Test Completed \\
 10167 & Handbuch-Dokumentation erstellen              & --- & 17.2026 & Test Completed \\
 \end{longtable}
 \begin{longtable}{@{} l p{95mm} l @{}}
@@ -137,13 +138,16 @@ Organisations-ID im Ordnernamen
 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  & --- \\
+2196 & Documents folder management                & 9560, 10018 & 9 T   & 2  & Robin Noack \\
 \addlinespace
-\multicolumn{4}{@{}l}{\textbf{Summe}} & \textbf{113} & \\
+2206 & Remove x button for search bar             & 10134       & 1 T   & 0  & Robin Noack \\
 2215 & Update user manual for documents feature   & 10167       & 2 T   & 0  & Robin Noack \\
 \addlinespace
 \multicolumn{4}{@{}l}{\textbf{Summe}} & \textbf{114} & \\
 \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
+Pflicht-Reviewer an allen dreizehn Pull Requests beteiligt. An den Diskussionen der Pull
-Requests 2154 bis 2156 beteiligte sich außerdem Hanna Ebner. Alle abgeschlossenen Pull
+Requests 2154 bis 2156 beteiligte sich außerdem Hanna Ebner. Alle Pull
 Requests wurden freigegeben; keiner wurde abgelehnt oder verworfen.\par}
@@ -3,11 +3,6 @@
 \clearpage
 \section{Diagramme}
 \input{appendix/appendix-diagrams}
 \clearpage
 \section{Screenshots}
 \input{appendix/appendix-screenshots}
@@ -3,34 +3,16 @@
 \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.
+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 im Juni, die aus zwei Stichpunkten eine umsetzbare Anforderung machte.
-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 und technische Ziele}
-\subsection{Fachliche Ziele}
+Sämtliche fachlich geforderten Funktionen sind umgesetzt, über den Kern hinaus auch die Komfortfunktionen Suche, Einzel- und Archivdownload, Vorschau, Freigabelinks und Verknüpfungsdateien. Der Kern — Auflistung mit Mandantentrennung — war nach vier Tagen zusammengeführt, sodass die Folgearbeiten früh beginnen konnten. 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 gewählte Lösung erfüllt die Anforderung ohne zweite Datenhaltung, heilt bestehende Abweichungen selbsttätig und ist seit dem 3.~September produktiv.
 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.
+Ein Punkt ist offen geblieben, ein weiterer liegt außerhalb des eigenen Einflusses. 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 Gegenmaßnahme von einer Rückfrage beim Betreiber abhängt (Abschnitt~\ref{sec:race-conditions}). 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.
 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.
+Das Projektziel ist erreicht: Der Dokumentenbereich ist seit dem 3.~September vollständig produktiv, erfüllt sämtliche funktionalen Anforderungen, und die verbleibende Arbeit ist klar benannt und im Backlog erfasst. Dass die Nebenläufigkeit durch eigenes Nachprüfen des Codes gefunden wurde, ist dabei bezeichnend (Abschnitt~\ref{sec:reflection}).
 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.
@@ -1,44 +1,18 @@
 \section{Ausblick}
 \label{sec:outlook}
 \subsection{Abschluss der begonnenen Arbeiten}
 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.
+Die in Abschnitt~\ref{sec:race-conditions} beschriebene Nebenläufigkeit ist nach der Produktivsetzung das einzige offene Thema des Features; 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}; andernfalls bleiben die Absicherung des Rücknahmeschritts und eine übergreifende Sperre. Alternativ ließe sich der verändernde Anteil aus dem Anfragepfad in einen eigenen, einmalig ausgeführten Vorgang lösen, sodass der Lookup auf reines Lesen zurückgeführt würde.
 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.
+Der in Abschnitt~\ref{sec:lookup-research} betrachtete Suchdienst\autocite{storagegrid-search-integration} wurde vom Betreiber nicht bereitgestellt. Sollte er verfügbar werden, ließe sich der Kundenordner-Lookup über eine Metadatenabfrage lösen — die eigene Konstruktion bliebe als Rückfallebene — und die Dokumentensuche serverseitig ausführen. Beides sind Optimierungen; die bestehende Umsetzung funktioniert, skaliert aber schlechter.
 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.
+In der Feature-Beschreibung sind zwei nicht in Backlog Items überführte Erweiterungen genannt: 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 nicht abbildbar ist — und die \textbf{Bereitstellung von Abrechnungsdaten}, bei der zu klären ist, ob sie über den Dokumentenbereich oder eine gesonderte Ansicht erfolgt, da sie sich in Herkunft und Aktualisierungsrhythmus unterscheiden.
-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.
+\subsection{Bedienung und Übertragbarkeit}
-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.
+Die Dokumentenpflege über den externen Dateibrowser war für den Projektzeitraum richtig, aber bewusst als Zwischenlösung getroffen; bei häufigerer Pflege wäre eine Verwaltungsoberfläche im Portal zu bewerten, die die Ordnerstruktur erzwingen könnte. Zwei Bausteine sind wiederverwendbar: der als eigener Dienst gekapselte \textbf{Zugriff auf den Objektspeicher} sowie 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.
 \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.
@@ -3,46 +3,24 @@
 \subsection{Externe Abhängigkeiten früher klären}
-Zwischen Antrag und abschließender Auskunft über die verfügbaren Speicherfunktionen lagen vier Wochen — bei einem Projektzeitraum von wenigen Wochen ein erheblicher Anteil.
+Zwischen Antrag und abschließender Auskunft über die verfügbaren Speicherfunktionen lagen vier Wochen. Der Fehler lag im Zeitpunkt: Die fachliche Klärung war seit dem 18.~Juni abgeschlossen, der Antrag folgte über vier Wochen später; früher gestellt, hätte die Lookup-Recherche nicht auf eine letztlich negative Antwort warten müssen. Vorgänge, deren Dauer man nicht selbst bestimmt, gehören an den Anfang der Planung.
 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.
+Das Lookup-Problem war die technisch anspruchsvollste Aufgabe des Projekts. Die zunächst betrachteten Ansätze — Zwischenspeicher, Anmeldetoken, Feld im ITSM-System — wurden verworfen, weil sie jeweils eine zweite Stelle einführen, an der dieselbe Information gepflegt wird. 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. Ohne diese Rückfrage bei der internen Fachseite wäre der Lösungsraum enger geblieben.
 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.
+Die Nebenläufigkeit wurde nicht durch Test, Review oder Fehlerbericht gefunden, sondern durch erneutes Durchgehen des eigenen, fertiggestellten Codes. 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 der Perspektivwechsel von „funktioniert das?" zu „was passiert, wenn das zweimal gleichzeitig läuft?" — eine Frage, die für jeden verändernden Codepfad einer Anwendung mit mehreren Instanzen zu stellen ist.
 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.
+Die in Abschnitt~\ref{sec:code-reviews} beschriebene Ballung war Folge einer im Rückblick falschen Entscheidung: Vier gleichzeitig eröffnete Pull Requests sollten Wartezeiten auf Reviews vermeiden. Der Vorteil trat nicht ein, weil die Arbeiten aufeinander aufbauten — statt Parallelität entstand eine Warteschlange, deren Auflösung sich in die Woche vor der Abnahme verschob; zusätzlich setzte jede Umstellung der verketteten Zielbranches auf den Hauptbranch Freigaben zurück. Bei abhängigen Aufgaben ist sequenzielles Vorgehen vorzuziehen.
 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.
+Der einzige Abnahmefehler betrifft die Anforderung, dass sich die Bedienung an den übrigen Seiten orientieren soll. Sie wurde nicht übersehen, sondern lässt sich nicht aus einer Beschreibung ableiten: 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 mit der Anwendung vertraute Person unersetzbar und sollte früher angesetzt werden als hier geschehen.
 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.
+Gegenüber den vorangegangenen Praktika lag der Schwerpunkt auf Entwurfsentscheidungen: Die sechs Lösungsansätze für den Lookup und die Nebenläufigkeitsanalyse erzeugten keine einzige Zeile ausgelieferten Codes, bestimmten aber 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.
 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.
@@ -23,31 +23,22 @@ 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 \\
+Umsetzung Sprint 16.2026   & 13.08.--25.08. & 12.08.--26.08. & +1 Tag \\
 Abnahmetest                & ab 13.08. & 13.08.--25.08. & Zugriffsprobleme \\
-Produktivsetzung Kern      & --- & 20.08. & --- \\
+Bugfix aus Abnahme (10134) & --- & 27.08. & --- \\
 Benutzerhandbuch (10167)   & --- & 31.08.--02.09. & nicht eingeplant \\
 Produktivsetzung           & --- & 03.09. & --- \\
 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.
+Die Analyse- und Planungsphase verlief planmäßig; die Abweichungen der zweiten Projekthälfte haben zwei Ursachen. Feature-Analyse und Backlog-Schnitt (Juni) sowie Bugfix, Handbuch und Produktivsetzung (ab dem 26.~August) liegen außerhalb des offiziellen Tätigkeitszeitraums vom 07.07.--25.08.2026; die Aufwandsverteilung der 24 Manntage innerhalb dieses Fensters zeigt Tabelle~\ref{tab:manntage}.
-\subsection{Ursache 1: Nicht eingeplanter Infrastrukturvorlauf}
+\subsection{Ursachen der Abweichungen}
-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.
+\textbf{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 Klärung der Speicherfunktionen zog sich vom 30.~Juli bis zum 17.~August und blockierte währenddessen die Lookup-Recherche (Abschnitt~\ref{sec:reflection}).
-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.
+\textbf{Nachgeschobene Backlog Items.} Von den 15 Backlog Items waren acht zu Beginn geschnitten; sieben kamen während der Umsetzung hinzu — Typfilter, Paginierung, Recherche zur Speicherabfrage, neuer Lookup, automatische Ordneranlage, Nebenläufigkeit und Benutzerhandbuch. 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.
 \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.
+Alle 13 funktionalen Anforderungen sind ausgeliefert, einschließlich der automatischen Anlage der Ordnerstruktur. Bei den nichtfunktionalen Anforderungen sind fünf von sechs erfüllt; nicht erfüllt ist allein die Zusicherung gegen gleichzeitige verändernde Zugriffe. Diese Nebenläufigkeit (Abschnitt~\ref{sec:race-conditions}) ist keine unerfüllte Anforderung, sondern eine neu erkannte Eigenschaft, als eigenes Backlog Item erfasst und freigegeben.
 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.
@@ -3,6 +3,15 @@
 WorkSimple positioniert sich als Full-Service-IT-Dienstleister, der Unternehmen jeder Größe unterstützt. Die Lösungen sind darauf ausgerichtet, die Komplexität der IT zu reduzieren und gleichzeitig die Effizienz und Sicherheit zu erhöhen. Durch die Nutzung moderner Technologien und agiler Methoden ist WorkSimple in der Lage, schnell und flexibel auf die Anforderungen der Kunden einzugehen.
-Die intern genutzten Tools wie Kimai (Zeiterfassung) und Efecte (ITSM) sind Beispiele für die praktische Anwendung von IT-Lösungen, die auch Kunden angeboten werden. Dies unterstreicht den praxisnahen Ansatz von WorkSimple. Das Kundenportal Houston, dessen Erweiterung Gegenstand dieses Projekts ist, verbindet diese Systeme gegenüber dem Kunden zu einer einheitlichen Oberfläche — das genaue Zusammenspiel der Kernsysteme wird in Abschnitt~\ref{sec:system-landscape} erläutert.
+Die intern genutzten Tools wie Kimai (Zeiterfassung) und Efecte (ITSM) sind Beispiele für die praktische Anwendung von IT-Lösungen, die auch Kunden angeboten werden. Dies unterstreicht den praxisnahen Ansatz von WorkSimple. Das Kundenportal Houston, dessen Erweiterung Gegenstand dieses Projekts ist, verbindet diese Systeme gegenüber dem Kunden zu einer einheitlichen Oberfläche.
 Abbildung~\ref{fig:houston-uml} zeigt dieses Zusammenspiel im Überblick: Der Kunde besucht Houston und meldet sich über den Azure-Tenant an; Houston bezieht die Sachdaten aus Efecte und Bookstack, während Odoo die Auftragsabwicklung übernimmt. Die Unicorn Development entwickelt Houston und die begleitenden Azure Functions und liefert über Azure DevOps aus. Der Dokumentenbereich ergänzt diese Landschaft um den in Abschnitt~\ref{sec:system-landscape} beschriebenen S3-Speicher.
 \begin{figure}[H]
    \centering
    \includegraphics[width=0.85\textwidth]{figures/houston/uml.png}
    \caption{Systemkontext und Zusammenspiel der Kernsysteme zwischen Kunde und WorkSimple}
    \label{fig:houston-uml}
 \end{figure}
 Interne Prozesse und Dokumentation werden im \emph{XWiki} gepflegt, während die Softwareentwicklung nach einem strukturierten DevOps-Prozess mit Azure DevOps erfolgt. Dieser ganzheitliche Ansatz ermöglicht es WorkSimple, sowohl interne als auch kundenseitige IT-Herausforderungen effektiv zu lösen.
@@ -1,40 +1,23 @@
 \section{Autorisierungskonzept}
 \label{sec:authorization}
-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.
+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 über Microsoft Entra~ID. Das Token enthält zwei für dieses Projekt wesentliche Angaben:
+Die Authentifizierung erfolgt über Microsoft Entra~ID. Das Token enthält die \textbf{Efecte-Organisations-ID}, über die die Kundenzugehörigkeit bestimmt wird, und den \textbf{Efecte-Firmennamen} aus dem Claim \texttt{efecte:company\_name}. Dass der Firmenname verfügbar ist, wurde erst bei der Lookup-Recherche erkannt — er ermöglicht die Bestimmung des Ordnernamens ohne zusätzlichen Efecte-Aufruf (siehe Abschnitt~\ref{sec:lookup-decision}).
 \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. 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. Eine Differenzierung nach Dokumententyp ist nicht vorgesehen: Ein Benutzer sieht entweder alle Dokumente seiner Organisation oder gar keine.
+Für den Zugriff wurde in Entra~ID die Anwendungsrolle \texttt{Documents.Read} angelegt; eine Differenzierung nach Dokumententyp gibt es nicht. Sie steuert die Sichtbarkeit des Navigationspunkts und schützt die Seite gegen direkten URL-Aufruf. Nur die zweite Prüfung ist sicherheitsrelevant; das Ausblenden des Menüpunkts ist Benutzerführung.
 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 Antwort bei unberechtigtem Zugriff auf \texttt{/documents}. Die ursprüngliche Anforderung sah 404 vor, um die Existenz der Ressource zu verbergen.
+Die ursprüngliche Anforderung sah bei unberechtigtem Zugriff auf \texttt{/documents} eine 404-Antwort vor, um die Existenz der Ressource zu verbergen. Sie wurde auf 403 geändert: Die Existenz des Bereichs ist kein Geheimnis, und 404 erschwert die Fehlersuche, weil ein Benutzer ohne Rolle dieselbe Antwort wie bei einem Tippfehler erhält. Dieser Fall trat später im Abnahmetest 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: 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 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}).
+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}). Da die Einschränkung bereits Bestandteil der Abfrage ist, lädt Houston nie Dokumente fremder Kunden, um sie nachträglich herauszufiltern; ein Fehler in der Darstellungsschicht kann somit nicht zu einer Offenlegung führen. Abbildung~\ref{fig:auth-sequence} stellt den Ablauf dar.
 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.
 \begin{figure}[H]
    \centering
@@ -45,8 +28,4 @@ Abbildung~\ref{fig:auth-sequence} stellt den vollständigen Ablauf dar.
 \subsection{Absicherung der Einzelzugriffe}
-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.
+Auch Download, ZIP-Download, PDF-Vorschau und Freigabelinks nehmen einen Dokumentschlüssel entgegen. Für jeden Pfad wird der Schlüssel gegen das aufgelöste Kundenpräfix geprüft und auf Bestandteile untersucht, mit denen sich der Kundenordner verlassen ließe (NFA-6). Freigabelinks bilden keine Ausnahme: Sie enthalten keine Anmeldeinformationen; ein Empfänger ohne Rolle und passende Organisationszugehörigkeit erhält dieselbe 403-Antwort.
 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.
 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.
@@ -26,24 +26,14 @@ Die sieben Dokumententypen wurden in der Feature-Beschreibung festgelegt und im
 \subsection{Feste Kodierung statt Konfiguration}
-Im Approval-Termin stellte \emph{Timo Walter} die Frage, ob die Kategorien konfigurierbar sein sollen. Die Entscheidung fiel auf eine feste Kodierung in Houston.
+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 und ändert sich allenfalls im Rhythmus von Jahren; Konfigurierbarkeit würde Verwaltungsoberfläche, Speicherformat und Migrationsstrategie erfordern. Da jeder Typ zudem ein Icon und eine Übersetzung benötigt, stellt die feste Kodierung sicher, dass Ordnername, Anzeigetext und Icon gemeinsam gepflegt werden. Der Preis — eine Codeänderung und ein Release je neuem Typ — ist bei der erwarteten Änderungshäufigkeit vertretbar.
 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 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: 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 die Frage, wie mit Unterordnern umzugehen ist, die nicht im Katalog stehen — etwa einem Ordner \texttt{Sonstiges} in Filestash.
+Unterordner, die nicht im Katalog stehen — etwa ein in Filestash von Hand angelegtes \texttt{Sonstiges} — werden angezeigt: Die Typableitung liefert keinen Treffer, das Dokument gilt als typlos und erhält den Anzeigetext \emph{Sonstige Dokumente} sowie ein neutrales Standard-Icon. Ausblenden wurde verworfen, weil es stilles Fehlverhalten erzeugen würde. Dieselbe Behandlung greift für Dokumente unmittelbar im Kundenordner. Praktisch bleibt der Fall die Ausnahme, da Houston die Ordnerstruktur selbst anlegt (siehe Abschnitt~\ref{sec:folder-management}) und dabei nur Katalog-Ordner erzeugt.
-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 dies 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}): Dort entscheidet die Struktur über die Mandantentrennung, während innerhalb eines Kundenordners die Zugehörigkeit bereits geklärt ist.
 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 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.
+Die Ordnernamen müssen für die Kundenbetreuer in Filestash lesbar und eindeutig sein, für den Kunden in Houston aber in die Oberfläche passen. Der Ordnername wird daher über eine Ressourcendatei auf einen Anzeigetext abgebildet — das etablierte Lokalisierungsmuster. So lässt sich der Anzeigetext ändern, ohne die Speicherstruktur anzufassen, deren Umbenennung das Umkopieren sämtlicher betroffenen Objekte erfordern würde.
 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.
@@ -3,27 +3,17 @@
 \subsection{Die zugrunde liegende Idee}
-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.
+Alle in Abschnitt~\ref{sec:lookup-research} betrachteten Ansätze hinterlegen die Zuordnung \emph{zusätzlich} irgendwo und führen so eine zweite, konsistent zu haltende Datenhaltung ein. Die gewählte Lösung dreht die Fragestellung um: Lässt sich der Ordnername deterministisch aus dem Firmennamen ableiten und steht dieser im Token, bestimmt Houston ihn ohne Nachschlagevorgang — 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 ist, dass die Ordner 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. Das ist vertretbar, weil Houston die Ordnerstruktur ohnehin selbst anlegt (FA-13), und die Kundenbetreuer verlieren nichts: Der Ordner heißt weiterhin nach dem Kunden, nur normalisiert.
 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 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 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.
+Der Firmenname aus dem Token kann problematische Zeichen, führende Leerzeichen oder beliebige Länge aufweisen und wird daher durch eine Normalisierungsfunktion geführt, im Folgenden \emph{Slug} genannt. Sie muss \textbf{deterministisch} und \textbf{lesbar} sein, da 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}, sonst stünde die Firma in der alphabetischen Liste an unerwarteter Stelle. Die Zulässigkeit solcher Zeichen in Objektschlüsseln wurde anhand der Herstellerdokumentation geprüft \autocite{aws-s3-naming, ibm-s3-naming}.
 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 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.
+Firmennamen sind nicht garantiert eindeutig: Efecte lässt zwei Organisationen mit identischem Namen zu, die auf denselben Ordnernamen träfen — eine Verwechslung würde bedeuten, dass ein Kunde fremde Dokumente sieht. 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)}. Ein Zielname wird nur beansprucht, wenn er frei ist oder ausweislich seines Markers der eigenen Organisation gehört; die Zuordnung entscheidet immer das Metadatum, nie der Name.
 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.
 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}
@@ -37,21 +27,15 @@ Aus diesen Überlegungen ergibt sich ein dreistufiges Verfahren (Abbildung~\ref{
 \end{figure}
 \begin{enumerate}
-    \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{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 — der Regelfall.
-    \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{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.
-    \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.
+    \item \textbf{Rückfallebene.} Erst dann kommt das lineare Verfahren zum Einsatz. Ein Ordner mit passender ID wird auf den kanonischen Namen umbenannt; wird keiner gefunden, wird die vollständige Struktur angelegt.
 \end{enumerate}
 \subsection{Selbstheilung}
-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.
+Die Rückfallebene beseitigt nicht nur den Fehlschlag, sondern dessen Ursache: Nach der Umbenennung trägt der Ordner den erwarteten Namen, und der nächste Zugriff läuft direkt. Der teure Pfad wird pro Kunde höchstens einmal durchlaufen, Bestandsordner migrieren sich beim ersten Zugriff von selbst. Das Verfahren erfordert keine zusätzliche Datenhaltung; der Zustand liegt vollständig im Speicher.
 Der teure Pfad wird pro Kunde höchstens einmal durchlaufen. Bestehende Ordner migrieren sich beim ersten Zugriff von selbst — eine gesonderte Migration entfällt.
 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}
-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.
+Die Rückfallebene 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 als eigenes Backlog Item vom laufenden Pull Request abgegrenzt; Abschnitt~\ref{sec:race-conditions} behandelt die Szenarien und Gegenmaßnahmen.
 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.
@@ -3,46 +3,22 @@
 \subsection{Entstehung}
-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.
+Der Document Explorer war zu seinem Merge 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. Ursache ist, dass S3 keine Suche nach benutzerdefinierten Metadaten bietet: \texttt{ListObjectsV2} liefert Schlüssel, Größe und Änderungszeitpunkt, aber keine Metadaten \autocite{aws-listobjectsv2}, sodass jeder Kandidat einen eigenen Aufruf erfordert.
-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.
+Der Aufwand wächst linear mit der Kundenzahl — bei \emph{jedem} Seitenaufruf, also einige hundert Netzwerkaufrufe bei einigen hundert Kunden, bevor das erste Dokument geladen wird. Das Problem ist nicht akut, aber strukturell. Am 28.~Juli entstand daraus ein eigenes Backlog Item, bewusst als \emph{Recherche}-Item mit dem Akzeptanzkriterium „es ist sich für einen Lösungsansatz entschieden worden", um den Rechercheaufwand als eigenständige Leistung sichtbar zu machen.
 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.
 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}
-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.
+Die sechs folgenden Ansätze habe ich im Rahmen des Recherche-Items selbst erarbeitet und abgewogen; \emph{Timo Walter} und \emph{Bianco Veigel} dienten als Gesprächspartner und prüften das Ergebnis im Review. Tabelle~\ref{tab:lookup-tradeoffs} im Anhang fasst die Bewertung zusammen.
-\subsubsection{In-Memory-Cache}
+\textbf{In-Memory-Cache.} Das Auflösungsergebnis zwischenspeichern macht Folgeaufrufe kostenlos. Da Houston in mehreren Instanzen läuft und der Cache nach jedem Neustart leer ist, bleibt der lineare Aufwand jedoch bestehen, er wird nur seltener bezahlt.
-Der naheliegendste Ansatz: das Auflösungsergebnis im Arbeitsspeicher zwischenspeichern. Der erste Aufruf bleibt teuer, alle folgenden sind kostenlos.
+\textbf{Speicherung im Anmeldetoken.} Der Ordnername könnte als Claim abgelegt werden. Der lineare Aufwand bliebe erhalten, und ein Token ist über seine Laufzeit unveränderlich: Nach einer Umbenennung zeigt der Claim bis zur Erneuerung auf einen nicht mehr existierenden Ordner.
-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.
+\textbf{Speicherung als Feld in Efecte.} Der Ordnername könnte an der Organisation in Efecte gepflegt werden. Das löst das Problem technisch, führt aber eine zweite Datenhaltung neben dem Marker-Metadatum ein, die auseinanderlaufen kann, und müsste für jeden Bestandskunden nachgepflegt werden.
-\subsubsection{Speicherung im Anmeldetoken}
+\textbf{S3 Select.} \texttt{SelectObjectContent} filtert den \emph{Inhalt} eines Objekts serverseitig per SQL-ähnlicher Abfrage \autocite{aws-s3-select}; denkbar wäre eine Zuordnungstabelle als Datei. Die Freischaltung wurde am 7.~August bestätigt (siehe Abschnitt~\ref{sec:infrastructure}), doch S3 Select filtert Inhalte einzelner Objekte, nicht Metadaten mehrerer — die Zuordnungsdatei hätte dasselbe Konsistenzproblem wie das Efecte-Feld ohne dessen Werkzeugunterstützung.
-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.
+\textbf{StorageGRID Search Integration.} 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. 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}).
-\subsubsection{Speicherung als Feld in Efecte}
+\textbf{Organisations-ID im Ordnernamen.} Die ID zum Bestandteil des Ordnernamens machen — etwa \texttt{42\_Beispielkunde GmbH} — reduzierte den Lookup auf eine Präfixabfrage. 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. Die entscheidende Beobachtung war, dass die Anforderung eine Sortierung nach Kundennamen verlangt — nicht, dass der Ordnername \emph{ausschließlich} aus dem Kundennamen besteht. Das eröffnete den Weg zur in Abschnitt~\ref{sec:lookup-decision} beschriebenen Lösung.
 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.
 \subsubsection{S3 Select}
 \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 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 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}).
 \subsubsection{Organisations-ID im Ordnernamen}
 Der einfachste Ansatz: die Organisations-ID zum Bestandteil des Ordnernamens machen — etwa \texttt{42\_Beispielkunde GmbH}. Der Lookup reduzierte sich auf eine Präfixabfrage.
 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, 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.
@@ -1,19 +1,17 @@
 \section{Ablagekonzept im S3-Speicher}
 \label{sec:s3-layout}
-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.
+Das Ablagekonzept muss die Zuordnung von Dokumenten zu Kunden und die Abbildung des fachlichen Dokumententyps leisten — beides ausschließlich über die Struktur im Speicher, ohne zusätzliche Datenbank.
 \subsection{Präfixe statt Ordner}
-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
+S3 adressiert jedes Objekt über einen Schlüssel in einem flachen Namensraum; die scheinbare Hierarchie entsteht beim Auflisten über Präfix und Trennzeichen \autocite{aws-listobjectsv2}. Ein Schlüssel wie
 \begin{quote}
 \texttt{Beispielkunde GmbH/Service-Protokoll/Protokoll-2026-07.pdf}
 \end{quote}
-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.
+erscheint in Filestash als zweistufige Ordnerhierarchie, ist im Speicher aber nur eine Zeichenkette. Ein „Ordner" existiert erst mit einem Objekt unter dem Präfix; 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 Struktur.
 Abbildung~\ref{fig:s3-layout} zeigt die resultierende Struktur.
 \begin{figure}[H]
    \centering
@@ -24,36 +22,24 @@ 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 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.
+Auf der obersten Ebene liegt für jeden Kunden ein Ordner. Dessen Platzhalterobjekt trägt ein benutzerdefiniertes Metadatum \texttt{efecte-org-id} und wird im Folgenden \emph{Marker} genannt. Er sorgt dafür, dass der Kundenordner auch ohne Dokumente existiert, und trägt die Organisationszugehörigkeit an genau einer Stelle.
-Er sorgt dafür, dass der Kundenordner auch ohne Dokumente existiert, und trägt die Organisationszugehörigkeit an genau einer Stelle.
+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. 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.
 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 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 Dokumententypen ein Unterordner. Der Typ ergibt sich aus dem Unterordner; direkt im Kundenordner liegende Dokumente 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. Die Alternative — den Typ als Metadatum an jeder Datei zu hinterlegen — wurde verworfen: Ein Metadatum müsste bei jedem Upload manuell gesetzt werden, wofür Filestash keine komfortable Unterstützung bietet, während das Ablegen in einem Ordner die natürliche Bedienhandlung ist. Zudem ist der Typ als Präfixbestandteil unmittelbar aus dem Schlüssel ablesbar und serverseitig filterbar, während ein Metadatum für jedes Objekt einzeln abgerufen werden müsste, da \texttt{ListObjectsV2} es nicht mitliefert — bei $n$ Dokumenten also $n$ zusätzliche Aufrufe.
-Die Alternative — den Typ als Metadatum an jeder Datei zu hinterlegen — wurde verglichen:
+Dem stehen zwei bewusst in Kauf genommene 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).
 \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 die natürliche Bedienhandlung.
    \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: 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:
 \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. Der Benutzer sieht 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.
    \item \textbf{Leere Typordner erscheinen nicht.}
-    \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.
+    \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: Ein fehlendes Metadatum führt zum Ausschluss, nicht zu einer Vermutung.
@@ -1,37 +1,32 @@
 \section{UI-Konzept}
 \label{sec:ui-concept}
-\subsection{Zuarbeit über einen Clickdummy}
+\subsection{Abstimmung der Typfilterung über einen Clickdummy}
-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.
+Das Oberflächenkonzept stammt bis auf einen Punkt aus der eigenen Ausarbeitung: Für die Typfilterung existierte kein Vorbild in Houston, und da \emph{Hanna Ebner} die führende Entscheidungsinstanz für die Oberfläche ist, wurde die Filterleiste mit ihr abgestimmt. Als Referenz setzte sie ihren Vorschlag am 22.~Juli 2026 als lauffähigen Clickdummy in einem eigenen Branch des Houston-Repositories um und verlinkte ihn am Feature. Er ist eine gestalterische Vorgabe für ein einzelnes Bedienelement, keine Zuarbeit zur Umsetzung: Die Implementierung der Filterleiste — Markup, Zustandshaltung, Abfrageparameter und serverseitige Auswertung (Abschnitt~\ref{sec:filter-pagination}) — lag wie die des übrigen Dokumentenbereichs vollständig in meiner Hand.
 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}
-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 Dokumentenbereich stellt trotz der Bezeichnung „Document Explorer" keine navigierbare Ordnerhierarchie dar; der Benutzer sieht eine flache Liste aller Dokumente, die Typzugehörigkeit wird über Icons und Filter ausgedrückt. Bei einer Hierarchie müsste ein Kunde die Kategorie kennen und sich dorthin durchklicken, während die flache Liste unmittelbares Suchen und Filtern erlaubt. Bei nur zwei Ebenen mit sieben festen Kategorien stünde der Navigationsaufwand in keinem Verhältnis zum Nutzen.
-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.
+Die ursprüngliche Feature-Beschreibung sah Dokumentkacheln vor. Die Darstellung wurde auf Zeilen umgestellt — eine Entscheidung von \emph{Hanna Ebner}, die meine abweichende Einschätzung überwog und sich als tragfähiger erwies: Eine Zeile bietet Platz für Icon, Name, Auswahlbox und Aktionsschaltflächen, fügt sich in die Tabellendarstellung der übrigen Houston-Seiten ein (NFA-4) und lässt sich um Spalten erweitern, ohne den Aufbau zu verändern.
 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}
-Die Seite gliedert sich von oben nach unten in vier Bereiche:
+Die Seite gliedert sich von oben nach unten in vier Bereiche (Abbildung~\ref{fig:shot-explorer} im Anhang):
 \begin{enumerate}
    \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 Darunter \textbf{Filterelemente}, 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 Die \textbf{Dokumentenliste} als Tabelle. Jede Zeile enthält Typ-Icon, 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 Seitenwechsel sowie die Auswahl der Seitengröße.
 \end{enumerate}
-Die Tabellenstruktur ist erweiterbar: Weitere Spalten können ergänzt werden, ohne den Aufbau zu verändern.
+Suche und Typfilter wirken zusammen und schränken die Liste gemeinsam ein
 (Abbildungen~\ref{fig:shot-type-filters} und~\ref{fig:shot-search}).
 \subsection{Konsistenz zur bestehenden Anwendung}
-Eine durchgängige Vorgabe war, dass sich der Dokumentenbereich wie die übrigen Houston-Seiten bedienen lässt (NFA-4).
+Eine durchgängige Vorgabe war, dass sich der Dokumentenbereich wie die übrigen Houston-Seiten bedienen lässt (NFA-4). Wie genau das zu verstehen ist, zeigte sich erst im Abnahmetest: Die Suchleiste blendete nach einer Eingabe eine Schaltfläche zum Leeren ein — eine Funktion, die es auf den übrigen Seiten nicht gibt. Der Unterschied wurde als Fehler gemeldet (siehe Abschnitt~\ref{sec:acceptance-testing}) und verdeutlicht, dass eine Konsistenzanforderung 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 Freigabelink auf ein bestimmtes Dokument 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 (Abbildung~\ref{fig:shot-share-target} im Anhang).
 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.
@@ -3,7 +3,7 @@
 \subsection{Schichtung}
-Das Dokumentenmodul folgt der in Houston etablierten Schichtung. Abbildung~\ref{fig:module-components} zeigt die Komponenten.
+Das Dokumentenmodul folgt der in Houston etablierten Schichtung (Abbildung~\ref{fig:module-components}).
 \begin{figure}[H]
    \centering
@@ -12,28 +12,19 @@ Das Dokumentenmodul folgt der in Houston etablierten Schichtung. Abbildung~\ref{
    \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.
+Die oberste Schicht bilden drei Razor Pages: \texttt{Documents} für Liste, Suche, Filter und Blätterelemente, \texttt{Document/Download} für Downloads (einzeln und als ZIP) und \texttt{Document/Share} für Freigabelinks. Darunter liegt der \texttt{DocumentsService} als fachliche Schicht mit den Regeln des Ablagekonzepts (Kundenordner-Auflösung, Typableitung, Ausblendung technischer Einträge). Der \texttt{S3DocumentsClient} kapselt den Speicherzugriff und ist die einzige Stelle, an der \texttt{IAmazonS3} unmittelbar verwendet wird.
 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}
 \label{sec:newtype}
-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.
+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. Als Ausweg verpackte ich die Pfade nach dem \emph{Newtype-Pattern} in eigene \texttt{readonly record struct}-Typen \autocite{rust-newtype}, ergänzt um „parse, don’t validate“ \autocite{king-parse}: Wer einen \texttt{DocumentKey} entgegennimmt, muss die Gültigkeit nicht erneut prüfen.
-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.
+So entstanden \texttt{DocumentKey} für den vollständigen Pfad einschließlich Kundenordner (Listing~\ref{lst:document-key}) und \texttt{DocumentRelativePath} für den Anteil darunter, beide nur über eine prüfende Fabrikmethode erzeugbar; eine vergessene Prüfung führt so zu einem Übersetzungsfehler statt zu einer Sicherheitslücke. Nach demselben Muster entstanden \texttt{DocumentType}, \texttt{DocumentName}, \texttt{DocumentId} und \texttt{OrgSlug}. Zeichenketten werden einmal am Rand in diese Typen geparst; die weitere Verarbeitung arbeitet nur noch auf Typen. Der zugehörige Pull Request durchlief 23 Iterationen und bestand zu einem erheblichen Teil aus diesem Refactoring, das sich auszahlte, weil ZIP-Download, PDF-Vorschau und Freigabelinks dieselben Typen wiederverwenden konnten.
 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.
+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. Eine seitenspezifische Prüfung ist zudem 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 derselben Richtlinie unterliegen.
 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.
+Die Pull Requests wurden verkettet: Der erste ging gegen den Hauptbranch, jeder darauf aufbauende gegen den Branch seines Vorgängers. So enthält jeder Pull Request genau die Änderungen seines Backlog Items, was die Reviewbarkeit erhöht. Der Preis zeigte sich beim Zusammenführen: Sobald ein Vorgänger übernommen war, musste der Nachfolger umgestellt werden, was in Azure DevOps die bereits abgegebenen Freigaben zurücksetzt. Bei der vorliegenden Zahl aufeinander aufbauender Items überwog der Gewinn an Reviewbarkeit diesen Aufwand deutlich.
 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.
@@ -1,30 +1,18 @@
 \section{Document Explorer}
 \label{sec:document-explorer}
-\subsection{Umfang}
+\subsection{Umfang und Darstellung}
-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.
+Der Document Explorer war das erste umgesetzte Backlog Item und mit acht Aufwandspunkten das umfangreichste. Er umfasst die Grundstruktur des Moduls: Seite, Dienst, Speicherclient, Modelle sowie Einbindung in Navigation und Autorisierung. Die ursprüngliche Kacheldarstellung wurde auf Zeilendarstellung geändert, da Auswahlboxen für den ZIP-Download, Download- und Teilen-Schaltflächen sowie eine Vorschau im Backlog standen, für die eine Kachel keinen natürlichen Platz geboten hätte; die Tabelle ist zudem um weitere Spalten erweiterbar.
 \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.
+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 statt still auf den Ordnernamen zurückzufallen — eine fehlende Übersetzung ist eine unvollständige Implementierung.
 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.
+Zwei Situationen ohne anzeigbare Dokumente 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.
 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.
+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 bewusst zurückgestellt; die tatsächliche Lösung beschreibt Abschnitt~\ref{sec:folder-management}.
 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}.
@@ -3,17 +3,11 @@
 \subsection{Einzeldownload über zeitlich begrenzte Zugriffs-URLs}
-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.
+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, und die URL ist nur wenige Minuten gültig. Die Berechtigungsprüfung findet \emph{vor} dem Erzeugen der URL statt, da die URL selbst keine Prüfung trägt: Sie darf nur für einen Schlüssel erzeugt werden, der nachweislich im Kundenordner liegt. Genau hier setzte der überwiegende Teil des Reviews an und führte zur in Abschnitt~\ref{sec:architecture} beschriebenen Einführung eigener Pfadtypen. Zusätzlich musste sichergestellt werden, dass das Dokument unter seinem ursprünglichen Namen ankommt.
 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.
 Zusätzlich musste sichergestellt werden, dass das Dokument unter seinem ursprünglichen Namen ankommt, da der Schlüssel den vollständigen Pfad enthält.
 \subsection{ZIP-Download}
-Jede Zeile erhält eine Auswahlbox für den ZIP-Download. Die Schaltfläche ist deaktiviert, solange nichts ausgewählt ist.
+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.
 Abbildung~\ref{fig:zip-stream} zeigt den Ablauf.
 \begin{figure}[H]
    \centering
@@ -22,8 +16,8 @@ Abbildung~\ref{fig:zip-stream} zeigt den Ablauf.
    \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.
+Das Archiv wird erst beim Klick erzeugt und entsteht nie vollständig im Arbeitsspeicher: 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.
+Im Review fragte \emph{Sarah Hinzmann}, ob bei nur einer ausgewählten Datei ein Archiv erzeugt werden solle. Die Entscheidung fiel für das Archiv: Die Schaltfläche „Als ZIP herunterladen" soll vorhersagbar ein Archiv liefern; wer eine einzelne Datei unverpackt benötigt, verwendet die Download-Schaltfläche in der Zeile.
@@ -3,22 +3,12 @@
 \subsection{Filterung nach Dokumententyp}
-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.
+Unterhalb der Suchleiste steht je Dokumententyp ein Bedienelement zum Ein- und Ausblenden. Die Auswahl wird als Abfrageparameter übertragen und im Dienst ausgewertet. 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 in der Regel ein veralteter Link, und die Mandantentrennung geschieht über das Präfix, nicht über den Filter. Ein zweiter Reviewhinweis führte zu einer geschärften Benennung, da sich der Typ für eine Menge von Dokumententypen vom Einzeltyp nur durch ein Zeichen unterschied.
 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.
+Die Paginierung folgt der Arbeitsweise des Speichers, der Ergebnisse blockweise mit Fortsetzungsmerkmalen liefert \autocite{aws-listobjectsv2}. 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. Ein aus den bestehenden Houston-Seiten übernommener Wert für die maximale Seitengröße (NFA-4) stammte, wie \emph{Robin Noack} anmerkte, dort aus einer Beschränkung des ITSM-Systems und wurde angepasst. Diskutiert wurde auch, ob die vom Benutzer wählbare Seitengröße nach oben begrenzt werden sollte.
 \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.
+Ein Freigabelink 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.
@@ -3,30 +3,20 @@
 \subsection{Gemeinsame Umsetzung zweier Backlog Items}
-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.
+Die automatische Ordneranlage und der neue Kundenordner-Lookup wurden in einem gemeinsamen, begründet zusammengelegten Pull Request umgesetzt, da der Lookup in seiner Rückfallebene den Fall benötigt, dass kein Ordner existiert und die Struktur angelegt werden muss.
 \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.
+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. Die Normalisierung ist \textbf{deterministisch} — Voraussetzung für den Direktzugriff — und erhält \textbf{Umlaute}, weil der Ordner in Filestash von Menschen gelesen wird. Im Review fragte \emph{Robin Noack}, ob die Einschränkungen ausreichen; die Zulässigkeit wurde anhand der Herstellerdokumentation bestätigt \autocite{ibm-s3-naming, aws-s3-naming}.
 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.
+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 zusätzlich 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.
 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.
+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: Der \textbf{Marker wird zuletzt kopiert}, sodass das Ziel von einer parallelen Anfrage nicht als Kundenordner erkannt wird, solange er fehlt; und die Fehlerbehandlung entfernt bereits erzeugte Teilkopien, damit der Vorgang wiederholbar ist. Die zweite Maßnahme gilt nur, solange kein zweiter Vorgang dieselbe Umbenennung ausführt — Gegenstand des folgenden Abschnitts.
-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.
+\subsection{Auslieferung}
-Die zweite Maßnahme gilt nur, solange kein zweiter Vorgang dieselbe Umbenennung ausführt. Dieser Fall ist Gegenstand des folgenden Abschnitts.
+Der zugehörige Pull Request wurde am 26.~August zusammengeführt, nachdem \emph{Robin Noack} zwei Anmerkungen eingebracht hatte: zur Ausreichung der Namensbeschränkungen und zu der Frage, ob ein Ordner vor seiner Erzeugung auf Fremdbesitz geprüft wird. Letztere ließ sich über die Zustände des Ordnermodells beantworten — erzeugt wird nur für einen Schlüssel im Zustand \emph{fehlend}. Mit der Produktivsetzung am 3.~September ist der Lookup mit konstanter Aufrufzahl wirksam; das lineare Verfahren dient nur noch als Rückfallebene.
 \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.
@@ -3,26 +3,18 @@
 \subsection{PDF-Vorschau im Modal}
-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.
+Die Vorschau öffnet PDF-Dokumente in einem überlagerten Fenster über dieselbe zeitlich begrenzte Zugriffs-URL, die auch dem Download zugrunde liegt (Abbildung~\ref{fig:shot-pdf-preview} im Anhang); für Nicht-PDF-Dateien wird keine Vorschau angeboten. Eine Prüfung der Dateigröße wurde im Approval-Termin bewusst verworfen, da jede Grenze willkürlich wäre und der Browser PDF-Dokumente ohnehin fortlaufend darstellt.
 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.
+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 zu transportieren. Dass der Kundenordner nicht Bestandteil des Links ist (Listing~\ref{lst:document-id}), bewirkt, dass der Link keinen Hinweis auf die Organisation enthält und ohne Anmeldung nicht auflösbar ist. Die Seite zeigt keinen Dokumentinhalt, sondern liefert Metaangaben für die Vorschau und leitet auf die Dokumentenliste weiter, wobei Sprungmarke und passende Seite angesteuert werden.
 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.
+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. Abbildung~\ref{fig:shot-share-teams} im Anhang zeigt das Ergebnis in Microsoft Teams, Abbildung~\ref{fig:shot-share-target} das Ziel in Houston. Da die Typsymbole als Vektorgrafiken vorliegen, die Vorschaudienste gängiger Messenger nicht zuverlässig darstellen, mussten sie zusätzlich als Rastergrafiken bereitgestellt werden; im Pull Request wurde vermerkt, dass diese bei einer Gestaltungsänderung nachzuziehen sind.
 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.
+Damit ein Messenger eine Vorschau erzeugen kann, muss er das Bild ohne Anmeldung abrufen können. Der Freigabe-Endpunkt ist deshalb anonym erreichbar — die einzige Stelle des Moduls ohne Autorisierung. Entschärft wird das durch den Aufbau der Dokumentkennung: Sie ist die Base64-Kodierung des relativen Pfades und trägt bereits alles, was die Seite ausgeben muss — Dokumentname als Titel, Dokumententyp und daraus den Pfad des Vorschaubildes sowie die Zieladresse (Listing~\ref{lst:share-page}). Der anonyme Endpunkt löst folglich keinen Aufruf an den Objektspeicher aus; er kann weder die Existenz eines Dokuments bestätigen noch Inhalte preisgeben noch als Hebel für Last dienen.
-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.
+Bei den sieben festen Typsymbolen ist die freie Abrufbarkeit 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.
@@ -3,13 +3,11 @@
 \subsection{Ausgangslage}
-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.
+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. Bei der Durchsicht des Codes wurden zwei Fehlerszenarien gefunden, die ausdrücklich formulierte Akzeptanzkriterien verletzen.
-Bei der Durchsicht des Codes wurden zwei Fehlerszenarien gefunden, die ausdrücklich formulierte Akzeptanzkriterien verletzen.
+\subsection{Zwei Szenarien}
-\subsection{Szenario A: Datenverlust beim gleichzeitigen Umbenennen}
+Abbildung~\ref{fig:race-condition-a} zeigt exemplarisch Szenario~A; Tabelle~\ref{tab:race-conditions} stellt beide Fälle einander gegenüber.
 Das erste Szenario betrifft die Fehlerbehandlung des Umbenennens. Abbildung~\ref{fig:race-condition-a} zeigt den Ablauf.
 \begin{figure}[H]
    \centering
@@ -18,37 +16,52 @@ Das erste Szenario betrifft die Fehlerbehandlung des Umbenennens. Abbildung~\ref
    \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.
+\begin{table}[H]
 \centering
 \begin{tabularx}{\textwidth}{@{} l X X @{}}
 \toprule
 \textbf{Szenario} & \textbf{Ursache} & \textbf{Auswirkung} \\
 \midrule
 A: Datenverlust beim Umbenennen &
 Zwei Anfragen halten den Zielnamen für frei, da beide prüfen, bevor eine schreibt. A kopiert und löscht die Quelle; B's Fehlerbehandlung entfernt daraufhin dieselben (bereits von A geschriebenen) Objekte. &
 Quelle und Kopie sind gelöscht — Datenverlust. \\
 \addlinespace
 B: Vermischung zweier Mandanten &
 Der Marker wird ohne Bedingung geschrieben. Haben zwei Organisationen denselben Firmennamen, gewinnt beim gleichzeitigen Erstzugriff der zuletzt geschriebene Marker. &
 Beide arbeiten im selben Ordner; zwischenzeitlich Abgelegtes bleibt im fremden Ordner — Vertraulichkeitsproblem, schwerwiegender als A. \\
 \bottomrule
 \end{tabularx}
 \caption{Erkannte Nebenläufigkeitsszenarien im Kundenordner-Lookup}
 \label{tab:race-conditions}
 \end{table}
-\subsection{Szenario B: Vermischung zweier Mandanten}
+Nicht betroffen sind zwei gleichzeitige Anfragen derselben Organisation (identische Schlüssel) sowie Lesezugriffe während einer Verschiebung, da der Marker zuletzt kopiert wird. Das Problem beschränkt sich auf zwei \emph{unterschiedlich weit fortgeschrittene} verändernde Vorgänge.
 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:
+Tabelle~\ref{tab:race-countermeasures} stellt die vier erwogenen Ansätze gegenüber; der erste sollte unabhängig von der Serialisierungslösung umgesetzt werden, der vierte ist eine organisatorische statt technische Lösung.
-\begin{enumerate}
+\begin{table}[H]
-    \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.
+\centering
-    \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.
+\begin{tabularx}{\textwidth}{@{} l X @{}}
-    \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.
+\toprule
-    \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.
+\textbf{Ansatz} & \textbf{Wirkung} \\
-\end{enumerate}
+\midrule
-
+Absicherung der Fehlerbehandlung & Prüfung, ob der Marker der Quelle vor dem Entfernen der Teilkopien noch existiert; beseitigt A weitgehend, es bleiben überzählige Objekte statt Datenverlust. \\
-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.
+\addlinespace
 Bedingtes Schreiben & Marker nur schreiben, falls noch nicht vorhanden, macht das Beanspruchen eines Namens unteilbar und schließt B aus \autocite{aws-conditional-writes}; setzt Unterstützung durch den Speicher voraus. \\
 \addlinespace
 Instanzübergreifende Sperre & Sperre je Organisation über die Datenbank serialisiert den verändernden Teil sauber, kostet aber einen zusätzlichen Zugriff je Anfrage und ein Konzept für nicht freigegebene Sperren. \\
 \addlinespace
 Verlagerung aus dem Anfragepfad & Einmalige kontrollierte Migration der Bestandsordner; die Anwendung protokolliert nur noch Abweichungen vom Sollzustand — die Ursache verschwindet vollständig. \\
 \bottomrule
 \end{tabularx}
 \caption{Erwogene Gegenmaßnahmen gegen die Nebenläufigkeitsszenarien}
 \label{tab:race-countermeasures}
 \end{table}
 \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.
+Der Befund wurde als eigenes Backlog Item mit erhöhter Priorität erfasst, vom laufenden Pull Request abgegrenzt und mit einem Zeitrahmen von vier bis sechs Stunden versehen.
-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.
+Den Pull Request offenzuhalten, hätte den Lookup blockiert: Ob bedingtes Schreiben verfügbar ist, ließ sich ohne Rückfrage beim Betreiber nicht beantworten, deren Bearbeitungsdauer zuvor mit mehreren Wochen bemessen worden war. Der Lookup verbessert den Zustand bereits deutlich, und der verändernde Pfad wird nur beim ersten Zugriff einer Organisation durchlaufen — das Risikofenster besteht pro Kunde genau einmal. Die Akzeptanzkriterien des Folgeitems halten fest, dass eine reine Sperre innerhalb einer Instanz nicht akzeptiert wird und beide Szenarien durch Unit-Tests nachzubilden sind.
 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.
@@ -3,15 +3,13 @@
 \subsection{Zugriff über das AWS SDK}
-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 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 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.
+Houston verwendete bereits vor diesem Projekt einen S3-Speicher für das Dokumentationssystem; mit dem Dokumentenbereich kam ein zweiter, davon unabhängiger 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.
 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}
@@ -19,8 +17,4 @@ Für die drei Umgebungen existiert je ein eigener Bucket mit getrennten Zugangsd
 \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.
+Die zentrale Leseoperation listet Objekte unterhalb des Kundenpräfixes über alle Typordner hinweg auf. Zwei Eigenschaften prägten die Umsetzung: Erstens liefert sie Ergebnisse blockweise mit einem Fortsetzungsmerkmal \autocite{aws-listobjectsv2}, das für die Paginierung genutzt wurde (siehe Abschnitt~\ref{sec:filter-pagination}); zweitens liefert sie keine benutzerdefinierten Metadaten — die Ursache des in Abschnitt~\ref{sec:lookup-research} beschriebenen Lookup-Problems. Platzhalterobjekte der Typordner und der Marker des Kundenordners werden herausgefiltert; beide erkennt der Dienst daran, dass ihr Schlüssel auf das Trennzeichen endet.
 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.
@@ -7,16 +7,10 @@ Die Suche filtert die Dokumentenliste anhand des Namens und berücksichtigt Teil
 \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.
+Die Anforderung verlangt eine serverseitige Suche. Gemeint ist, dass die Filterung in der Anwendung stattfindet, nicht im Browser — 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.
-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.
+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}) und fiel später negativ aus. Auf Anregung des Reviewers wurde dieser Umstand in das Recherche-Item aufgenommen.
 \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.
+Die praktische Auswirkung ist derzeit gering, da die Suche nur mit der Dokumentenzahl eines einzelnen Kunden skaliert, nicht mit der Kundenzahl. Der Lookup wurde daher im Projektzeitraum gelöst, die Suchoptimierung blieb für den Ausblick.
@@ -3,14 +3,12 @@
 \subsection{Eigene Symbole statt Symbolschrift}
-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.
+Houston verwendet für Symbole eine gängige Symbolbibliothek, die für die sieben Dokumententypen keine passenden Motive enthielt — Begriffe wie „SLA-Report Ticketbearbeitung" lassen sich mit allgemeinen Symbolen nicht unterscheiden. Es wurden daher eigene Vektorgrafiken erstellt. Die Entwürfe stammen von mir und wurden in Abstimmung mit \emph{Hanna Ebner} ausgearbeitet, damit sie sich in Strichstärke, Abmessung und Bildsprache in die vorhandene Symbolbibliothek einfügen; alle greifen dieselbe Dokumentkontur auf und unterscheiden sich nur im Innenmotiv, sodass die Typzugehörigkeit auf einen Blick erkennbar ist (Abbildung~\ref{fig:type-icons} im Anhang).
 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.
+Eine Einbindung als gewöhnliche Grafik hätte eine feste Farbe bedeutet, die im dunklen Erscheinungsbild von Houston kaum sichtbar gewesen wäre. Gelöst wurde dies, indem die Vektorgrafiken als Maske über einer Hintergrundfläche dienen, die die aktuelle Textfarbe übernimmt; die eigenen Symbole lassen sich so ü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.
+Dokumente ohne erkennbaren Typ erhalten ein neutrales Standardsymbol (letzter Eintrag in Abbildung~\ref{fig:type-icons}). Damit trägt jede Zeile ein Symbol, und die fehlende Typzuordnung ist erkennbar, ohne wie ein Fehler zu wirken.
@@ -3,26 +3,18 @@
 \subsection{Anwendungsfall}
-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.
+Nicht alle Unterlagen lassen sich sinnvoll in den Speicher kopieren; ein fortlaufend gepflegtes Dokument oder ein Kanal in einem Kollaborationswerkzeug soll verlinkt werden, da eine Kopie sofort veraltet wäre. Dafür werden \texttt{.url}-Dateien unterstützt: kleine Textdateien im INI-Format mit Zieladresse und optionalem Symbol, die in der Liste wie gewöhnliche Dokumente erscheinen, beim Anklicken jedoch auf die hinterlegte Adresse führen. 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}).
-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 und Anzeigename}
-\subsection{Auswertung des Dateiformats}
+Für das INI-Format wurde bewusst keine externe Bibliothek eingebunden: Benötigt wird ein einziger Wert aus einem Abschnitt, der in wenigen Zeilen selbst gelesen ist, und eine Bibliothek würde bei fehlerhaften Dateien vermutlich einen Fehler melden, während hier ein stiller Rückfall erforderlich ist. Kann keine gültige Adresse erkannt werden, wird die Datei wie eine gewöhnliche Datei zum Herunterladen angeboten. Die Endung \texttt{.url} wird für die Anzeige entfernt; \emph{Robin Noack} wies im Review darauf hin, dass die dafür verwendete Zeichenzahl als unmittelbare Zahl im Code stand und stattdessen die Länge der Endung selbst verwendet werden sollte, da beide sonst bei einer Änderung auseinanderlaufen.
 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.
+Das Dateiformat sieht im Abschnitt \texttt{[InternetShortcut]} einen Eintrag \texttt{IconFile} vor, der unter Windows auf eine Symboldatei zeigt \autocite{nsis-shortcuts}. Ein Dateipfad ist im Browser nicht verwertbar, und aus den in Abschnitt~\ref{sec:pdf-preview} genannten Gründen werden benutzerdefinierte Symbole ohnehin nicht ausgeliefert. Der Eintrag wird daher umgedeutet: Er trägt den Namen eines Symbols, das die Anwendung bereits kennt. Zulässig sind die Klassen der eigenen Typsymbole, etwa \texttt{doc-type-icon-vertragsunterlagen}, sowie Klassen der in Houston vorhandenen Symbolbibliothek Boxicons, etwa \texttt{bx bxl-github} \autocite{boxicons}. Für die drei häufigsten Verknüpfungsziele — Microsoft Teams, SharePoint und OneDrive — wurden im selben Stil eigene Grafiken ergänzt (Abbildung~\ref{fig:type-icons} im Anhang).
 Fehlt der Eintrag oder ist er leer, greift dieselbe Regel wie für gewöhnliche Dateien: Liegt die Verknüpfung in einem bekannten Typordner, erscheint dessen Symbol, sonst das Standardsymbol; ein unbekannter Wert führt damit nie zu einer leeren Zelle (Abbildung~\ref{fig:shot-url-icons} im Anhang). Da die Kundenbetreuer diese Dateien von Hand anlegen, wurden Format, zulässige Werte und Rückfallverhalten 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.
+Verknüpfungsdateien erhalten keine Auswahlbox und können nicht Teil eines Archivs werden, das sonst eine Datei mit einer möglicherweise nur intern auflösbaren Verknüpfung enthielte. Da eine Verknüpfung fachlich kein Dokument ist, wäre ihre Aufnahme irreführend.
@@ -1,15 +1,6 @@
 \section{Ausgangssituation}
 \label{sec:initial-situation}
-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.
+Die Idee besteht seit November 2023: \emph{Nicole Kimmel} legte damals das Feature~484 „Dokumente" mit zwei Stichpunkten an, ohne einen Lösungsansatz zu beschreiben.
-Zum Projektbeginn im Sommer 2026 wurden Verträge, Berichte und ähnliche Unterlagen punktuell per E-Mail oder Dateiablage 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. Sie lagen ohne einheitlichen Zugangspunkt verteilt, mussten von Kunden aktiv angefordert werden und boten weder einen Überblick nach Dokumententyp noch einen technisch mandantengetrennten Zugriff. Zudem war kein S3-Speicher provisioniert; die Infrastruktur — drei Buckets (DEV, TEST, PROD) bei Advanced Unibyte auf Basis von NetApp StorageGRID — musste erst im Projektverlauf beantragt werden.
 \begin{itemize}
    \item \textbf{Fehlende Zentralisierung:} Dokumente lagen verteilt in E-Mails, Dateiablagen und lokalen Verzeichnissen ohne einheitlichen Zugangspunkt.
    \item \textbf{Kein Self-Service für Kunden:} Kunden mussten Dokumente aktiv anfordern, anstatt sie eigenständig abrufen zu können.
    \item \textbf{Kein strukturierter Überblick:} Eine Übersicht nach Dokumententypen oder zeitlichem Verlauf war nicht vorhanden.
    \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 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.
@@ -3,11 +3,9 @@
 Als \textbf{Praktikant und Entwickler} (\emph{Linus Nagel}) war ich für Anforderungsklärung, Konzeption, Implementierung aller Product Backlog Items, Akzeptanzkriterien und Dokumentation verantwortlich.
-\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.
+\emph{Sarah Hinzmann} übernahm die \textbf{betriebliche Betreuung}, koordinierte Abstimmungen und war an Code-Reviews der Abschlussphase beteiligt. \emph{Thomas Drewermann} war \textbf{Product Owner}: Er arbeitete Feature~484 im Juni 2026 aus, definierte den Umfang und beantwortete Rückfragen.
-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.
+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) und \emph{Hanna Ebner} (Reviews, Oberflächenentscheidungen, Clickdummy der Typfilterung). \emph{Maria-Lena Andersz} führte die \textbf{Abnahmetests} durch. Weitere Beteiligte: \emph{Stephan Janßen} (Schätzung, Backlog-Pflege), \emph{Christiana Sobik} (Backlog-Pflege), \emph{Bianco Veigel} (Sprint-Planung) und \emph{Nicole Kimmel} (ursprüngliche Anforderung, 2023).
 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).
 \begin{table}[H]
 \centering
@@ -20,7 +18,7 @@ Thomas Drewermann & Product Owner, fachliche Ausarbeitung Feature 484 \\
 Sarah Hinzmann & Betriebliche Betreuung, PR-Reviews \\
 Timo Walter & Code-Review (PRs 2154–2164), technische Rückfragen \\
 Robin Noack & Code-Review (PRs 2180–2196) \\
-Hanna Ebner & UX/UI, Clickdummy \\
+Hanna Ebner & Oberflächenentscheidungen, Clickdummy Typfilter \\
 Maria-Lena Andersz & Abnahmetest \\
 Stephan Janßen & Schätzung, Refinement \\
 \bottomrule
@@ -1,8 +1,8 @@
 \section{Projektbeschreibung}
 \label{sec:project-description}
-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.
+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 liegen in einem S3-Speicher; Mitarbeiter pflegen sie über das interne Werkzeug Filestash, Kunden rufen sie über eine neue Houston-Seite strukturiert ab.
-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 bietet Suche, Typfilter, Paginierung, PDF-Viewer, Einzel- und ZIP-Download sowie URL-Dateien (siehe Abschnitt~\ref{sec:target-situation}).
-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.
+Technisch umfasst das Projekt die S3-Anbindung über das AWS SDK für .NET, ein rollenbasiertes Berechtigungskonzept über Microsoft Entra~ID sowie die automatische Ordneranlage beim ersten Seitenaufruf. Schreibzugriffe durch Kunden sind nicht vorgesehen.
@@ -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.
+    \item \textbf{Kein Schreibzugriff für Kunden:} Kunden können Dokumente nur einsehen und herunterladen.
-    \item \textbf{Kein internes Upload-UI in Houston:} Die Dokumentenverwaltung durch Mitarbeiter erfolgt ausschließlich über Filestash.
+    \item \textbf{Kein internes Upload-UI in Houston:} Die Pflege durch Mitarbeiter erfolgt ausschließlich über Filestash.
-    \item \textbf{Keine freie Ordnerstruktur intern:} Nur die sieben definierten Typordner sind für Kunden sichtbar; weitere Ordner werden ignoriert.
+    \item \textbf{Keine freie Ordnerstruktur intern:} Für Kunden sind nur die sieben Typordner 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.
+    \item \textbf{Keine Dashboard-Kacheln im PidI-Umfang:} Erweiterungen wie Dashboard-Kacheln für Tenant-Härtung oder eine Anzeige zuletzt hinzugefügter Dokumente sind als Feature-Creep im Backlog erfasst, aber nicht Teil des PidI-Projekts.
 \end{itemize}
@@ -10,12 +10,12 @@ Abbildung~\ref{fig:system-context} zeigt den Systemkontext des Dokumentenbereich
    \label{fig:system-context}
 \end{figure}
-\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{Houston} ist das Kundenportal von WorkSimple, eine ASP.NET-Core-Webanwendung mit Razor Pages, die um den Dokumentenbereich erweitert wurde.
-\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{Efecte} ist das ITSM-Tool des Unternehmens und liefert die eindeutige Organisations-ID jedes Kunden (\texttt{efecte-org-id}) als Autorisierungsmerkmal für den S3-Kundenordner.
-\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{Microsoft Entra~ID} (ehemals Azure~AD) übernimmt Authentifizierung und Autorisierung; das Token enthält die Efecte-Organisations-ID und die Anwendungsrollen, wobei \texttt{Documents.Read} den Zugriff steuert.
-\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{S3-Speicher (NetApp StorageGRID)} ist die von Advanced Unibyte betriebene, S3-kompatible Ablage für Kundendokumente, auf die Houston über das AWS SDK für .NET zugreift; jeder Kunde erhält einen eigenen, über \texttt{efecte-org-id} identifizierten Ordner.
-\textbf{Filestash} ist ein webbasierter S3-Browser, den WorkSimple-Mitarbeiter intern zum Hochladen und Verwalten von Dokumenten nutzen.
+\textbf{Filestash} ist ein webbasierter S3-Browser für die interne Dokumentenpflege.
@@ -1,18 +1,6 @@
 \section{Zielsituation}
 \label{sec:target-situation}
-Der Dokumentenbereich bietet folgende Funktionen:
+Der Dokumentenbereich stellt auf \texttt{/documents} alle Dokumente des Kunden als Liste dar, gegliedert nach sieben Dokumententypen; leere Ordner erscheinen nicht. Er bietet Typfilter und serverseitige Titelsuche, Paginierung, Einzel- und ZIP-Download, eine PDF-Vorschau im modalen Viewer sowie zeitlich begrenzte Share-Link-Previews. \texttt{.url}-Dateien verlinken beliebige Webadressen — etwa Teams-Kanäle oder SharePoint-Seiten — in der Dokumentenliste.
-\begin{itemize}
+Die Mandantentrennung stellt sicher, dass jeder Kunde nur die Dokumente seines eigenen S3-Ordners sieht, identifiziert über die \texttt{efecte-org-id} aus dem Authentifizierungstoken; die Ordnerstruktur wird beim ersten Aufruf automatisch angelegt, sofern sie fehlt. Kunden haben ausschließlich lesenden Zugriff; die Pflege erfolgt durch Mitarbeiter über Filestash.
    \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:} Filterung nach Typ und titelbasierte serverseitige Suche.
    \item \textbf{Paginierung:} Seitenweise Darstellung großer Dokumentenmengen.
    \item \textbf{Downloads:} Einzeldownload sowie ZIP-Download mehrerer ausgewählter Dokumente.
    \item \textbf{PDF-Vorschau:} Anzeige von PDF-Dokumenten in einem modalen Viewer.
    \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}
 Kunden haben ausschließlich lesenden Zugriff; die Pflege erfolgt durch Mitarbeiter über Filestash.
@@ -3,25 +3,21 @@
 \subsection{Entwicklungsprozess}
-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.
+Die Unicorn Development arbeitet agil mit zweiwöchigen Sprints in Azure DevOps. Der verbindliche Softwareprozess — im internen XWiki dokumentiert und in Abbildung~\ref{fig:unicorn-process} wiedergegeben — beschreibt den Weg von der Kundenidee bis zur Abrechnung und ordnet jedem Schritt den Zustand des Work Items zu.
 \begin{figure}[H]
    \centering
-    \includegraphics[width=0.55\textwidth]{figures/diagrams/ado-workflow.pdf}
+    \includegraphics[width=\textwidth]{figures/worksimple/softwareprozess-unicorns.jpg}
-    \caption{Zustände eines Work Items in Azure DevOps}
+    \caption{Softwareprozess der Unicorn Development mit den zugehörigen Work-Item-Zuständen}
-    \label{fig:ado-workflow}
+    \label{fig:unicorn-process}
 \end{figure}
-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}.
+Das Dokumentenfeature durchlief den Prozess ohne Abweichung; da es eine Erweiterung des eigenen Produkts Houston ist, entfielen nur die auftragsbezogenen Schritte. Die Freigabestufe erwies sich als wirksam — Rückfragen im Approval-Termin, insbesondere durch \emph{Timo Walter}, deckten mehrfach Lücken in den Akzeptanzkriterien auf.
 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 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.
+Alle Arbeiten hängen als Product Backlog Items am Feature~484. Tabelle~\ref{tab:backlog} im Anhang listet sie mit Kennung, Titel, Aufwand, Sprint und Zustand auf; Tabelle~\ref{tab:requirements} ordnet ihnen die Anforderungen aus Abschnitt~\ref{sec:requirements} zu.
-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}).
+Der Backlog-Schnitt erfolgte in zwei Phasen. Am 18.~Juni 2026 wurden acht Kern-Items angelegt (Document Explorer als Basis, die \emph{Feature-Creep}-Punkte Suche, Einzeldownload, ZIP-Download, PDF-Modal und URL-Dateien als eigene Items); am 7.~Juli kam die Typisierung über Icons hinzu, am 8.~Juli die automatische Ordneranlage. Während der Umsetzung folgten am 22.~Juli Paginierung und Typfilter aus der UI-Zuarbeit, am 28.~Juli die Recherche zur S3-Abfrage (Ergebnis am 12.~August im Kundenordner-Lookup-Item) und am 17.~August das Item zu Race Conditions (siehe Abschnitt~\ref{sec:race-conditions}).
-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.
+Insgesamt sind es 15 Product Backlog Items und ein Bug; die Aufwände summieren sich auf 46 Story Points (35 in Sprint~15.2026, 11 in Sprint~16.2026). Alle vorgeschnittenen Items betreffen fachliche Funktionen, alle nachgeschobenen entstanden aus technischen Problemen — 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.
@@ -3,13 +3,13 @@
 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 die Feature-Analyse durch. Vier Rückfragen wurden als Kommentare gestellt und am selben Tag beantwortet; drei entschieden Architekturfragen:
+Am 18.~Juni 2026 führte ich die Feature-Analyse durch; vier am selben Tag beantwortete Rückfragen entschieden Architekturfragen:
 \begin{enumerate}
-    \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{Autorisierung über Metadaten:} Die Efecte-Organisations-ID wird als Metadatum am Kundenordner gespeichert und löst die Berechtigung auf (siehe Abschnitt~\ref{sec:authorization}).
-    \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{Filestash als externes Werkzeug:} Filestash dient als Verwaltungsoberfläche, \emph{nicht} als Vorlage für einen Nachbau in Houston.
-    \item \textbf{Typisierung über Ordner statt Metadaten:} Der Dokumententyp wird über den Unterordner bestimmt, nicht als Metafeld an der Datei.
+    \item \textbf{Typisierung über Ordner statt Metadaten:} Der Dokumententyp wird über den Unterordner bestimmt.
-    \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.
+    \item \textbf{Bedeutung der URL-Dateien:} Gemeint ist das Einbetten \emph{externer} Ressourcen, nicht das Teilen von Houston-Dokumenten nach außen.
 \end{enumerate}
-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.
+Die dritte Entscheidung war die folgenreichste: Die Typabbildung über Ordner macht die Filterung günstig (Präfix-Listing), erzwingt aber die automatische Ordneranlage und erschwert die typübergreifende Suche.
@@ -1,7 +1,7 @@
 \section{Beschaffung der S3-Infrastruktur}
 \label{sec:infrastructure}
-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.
+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,10 @@ Der S3-Speicher stand zu Projektbeginn nicht bereit und musste über den Service
 \subsection{Bereitstellung der Buckets}
-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.
+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) angelegt, Zugangsdaten in Passbolt hinterlegt. Da der Document Explorer ohnehin erst am 27.~Juli begann, entstand 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}
-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:
+Im Rahmen der Lookup-Recherche (siehe Abschnitt~\ref{sec:lookup-research}) kamen zwei S3-Funktionen in Betracht: \textbf{S3 Select} (\texttt{SelectObjectContent}), das Objektinhalte serverseitig per SQL-ähnlicher Abfrage filtert \autocite{aws-s3-select, storagegrid-s3-select}, und der \textbf{Search Integration Service} von StorageGRID, der Objektmetadaten in einen Elasticsearch-Index spiegelt \autocite{storagegrid-search-integration}.
-\begin{itemize}
+Am 30.~Juli beantragte ich beide Funktionen; \emph{Lennart Meinert} kontaktierte am 4.~August Advanced Unibyte, am 7.~August wurde S3 Select für alle drei Umgebungen aktiviert. Den Search Integration Service bot Advanced Unibyte laut Mitteilung vom 17.~August nicht an; da bereits eine Lösung ohne serverseitige Suche umgesetzt war (siehe Abschnitt~\ref{sec:lookup-decision}), wurde der Request geschlossen. Zwischen Antrag und Klärung lagen vier Wochen — ein Ansatz, der auf einer erst zu beschaffenden Fremdleistung beruht, ist in einem solchen Projektzeitraum nicht belastbar.
    \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. \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 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 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.
@@ -1,13 +1,9 @@
 \section{Einarbeitung}
 \label{sec:onboarding}
 Vor der Implementierung war eine Einarbeitung in die projektrelevanten Technologien erforderlich, insbesondere S3.
 \subsection{S3 als Objektspeicher}
-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.
+S3 (\emph{Simple Storage Service}) ist ein Objektspeicher, kein Dateisystem: Objekte werden über einen flachen Schlüsselraum adressiert, und was als Ordner erscheint, ist ein per \texttt{Delimiter} hierarchisch interpretiertes Präfix \autocite{aws-listobjectsv2}. Das prägt das Ablagekonzept (siehe Abschnitt~\ref{sec:s3-layout}). 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}).
 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}
@@ -15,4 +11,4 @@ Der Zugriff erfolgt über \texttt{IAmazonS3} aus dem AWS SDK für .NET (\texttt{
 \subsection{NetApp StorageGRID}
-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.
+Der Speicher wird von Advanced Unibyte auf Basis von NetApp StorageGRID betrieben. StorageGRID ist S3-kompatibel, implementiert die API aber nicht vollständig; dies betraf \texttt{SelectObjectContent} \autocite{storagegrid-s3-select} und den \emph{Search Integration Service} \autocite{storagegrid-search-integration} (siehe Abschnitt~\ref{sec:infrastructure}).
@@ -8,25 +8,25 @@ Aus Feature-Beschreibung und Analyse ergaben sich die folgenden Anforderungen (Z
 \begin{itemize}
    \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 seiner Organisation, zugeordnet über die \texttt{efecte-org-id}.
-    \item \textbf{FA-3 — Rollenbasierter Zugriff:} Der Navigationspunkt ist nur bei vorhandener Berechtigung sichtbar; Aufruf ohne Berechtigung ergibt 403.
+    \item \textbf{FA-3 — Rollenbasierter Zugriff:} Der Navigationspunkt ist nur bei Berechtigung sichtbar; Aufruf ohne Berechtigung ergibt 403.
-    \item \textbf{FA-4 — Typisierung und Icons:} Jedes Dokument wird mit einem aus dem Unterordner abgeleiteten Icon dargestellt.
+    \item \textbf{FA-4 — Typisierung und Icons:} Jedes Dokument erhält ein aus dem Unterordner abgeleitetes Icon.
    \item \textbf{FA-5 — Suche:} Serverseitige Titelsuche mit Teiltreffern.
    \item \textbf{FA-6 — Typfilter:} Filterelemente je Dokumententyp zum Ein- und Ausblenden.
    \item \textbf{FA-7 — Paginierung:} Seitenweise Darstellung mit benutzerdefinierter Seitengröße, analog zu den übrigen Houston-Seiten.
    \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:} Ausgewählte Dokumente werden als ZIP-Archiv heruntergeladen; die Ordnerstruktur entspricht der S3-Struktur.
+    \item \textbf{FA-9 — ZIP-Download:} Ausgewählte Dokumente werden als ZIP-Archiv mit S3-analoger Ordnerstruktur heruntergeladen.
    \item \textbf{FA-10 — PDF-Vorschau:} PDF-Anzeige im Modal ohne vorherigen Download.
    \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:} \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 wird die Typordnerstruktur für die Organisation angelegt, sofern sie fehlt.
+    \item \textbf{FA-13 — Automatische Ordneranlage:} Beim Aufruf wird die Typordnerstruktur der 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 Kundenanzahl wachsen.
-    \item \textbf{NFA-2 — Fehlerbehandlung:} Bei Ladefehlern wird eine verständliche Meldung angezeigt; eine stillschweigend leere Seite ist unzulässig.
+    \item \textbf{NFA-2 — Fehlerbehandlung:} Bei Ladefehlern wird eine verständliche Meldung angezeigt, keine stillschweigend leere Seite.
-    \item \textbf{NFA-3 — Leerer Zustand:} Existieren keine Dokumente, wird ein Hinweis angezeigt.
+    \item \textbf{NFA-3 — Leerer Zustand:} Ohne Dokumente wird ein Hinweis angezeigt.
    \item \textbf{NFA-4 — Konsistenz:} Bedienelemente orientieren sich an den übrigen Houston-Seiten.
    \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 Schlüssel innerhalb des Kundenordners liegt.
@@ -1,7 +1,15 @@
 \section{Zeit- und Aufwandsplanung}
 \label{sec:schedule}
-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.
+Für das Praktikum sind 24 Manntage (192 Stunden) vorgesehen. Der \textbf{offizielle Tätigkeitszeitraum} des Praktikums ist der 07.07.--25.08.2026; in diesem Fenster wurden die 24 Manntage erbracht. Der fachliche Rahmen des Vorhabens ist jedoch weiter gefasst und in drei Abschnitte zu trennen:
 \begin{itemize}
    \item \textbf{Vorlauf (Ende Mai bis 06.07.2026):} Themenfindung, Ausarbeitung des Feature~484 durch den Fachbereich und die Feature-Analyse vom 18.~Juni (Abschnitt~\ref{sec:feature-analysis}). Diese Klärung fand im regulären Tagesgeschäft statt und zählt \emph{nicht} zu den 24 Manntagen.
    \item \textbf{Offizieller Praxiseinsatz (07.07.--25.08.2026):} Anforderungen, Backlog-Schnitt, Umsetzung der Sprints 15 und 16.2026 sowie der Abnahmetest.
    \item \textbf{Nachlauf (ab 26.08.2026):} Fehlerbehebung aus der Abnahme, Benutzerhandbuch und die Produktivsetzung am 03.~September. Diese Arbeiten fielen in Sprint 17.2026 und liegen ebenfalls außerhalb der 24 Manntage; sie werden dokumentiert, weil sie den Auslieferungsstand des Moduls belegen.
 \end{itemize}
 Abbildung~\ref{fig:gantt} zeigt die Zeitplanung über alle drei Abschnitte.
 \begin{figure}[H]
    \centering
@@ -10,8 +18,38 @@ Für das Praktikum sind 24 Manntage (192 Stunden) vorgesehen. Der Projektzeitrau
    \label{fig:gantt}
 \end{figure}
-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.
+Vier Phasen gliedern die Planung: die \textbf{Analyse- und Konzeptionsphase} (Ende Mai bis Anfang Juli, überwiegend im Vorlauf) mit Themenfindung, Feature-Analyse und Backlog-Schnitt; die \textbf{Implementierungsphase} ab 27.~Juli über die Sprints 15 und 16; die parallele \textbf{Qualitätssicherung} (Code-Reviews, Abnahmetest ab 13.~August); und die \textbf{Abschlussphase} in Sprint 17.2026 mit Fehlerbehebung, Benutzerdokumentation und Produktivsetzung am 3.~September. 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 am Item.
 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}.
 \subsection{Verteilung der Manntage}
 \label{sec:effort-distribution}
 Der Praxiseinsatz war kein Vollzeitprojekt: Innerhalb des Tätigkeitszeitraums war ich parallel in das reguläre Tagesgeschäft eingebunden — Wartung bestehender Houston-Module, Support-Tickets, Code-Reviews fremder Pull Requests sowie Sprint-Zeremonien. Die 24 Manntage verteilen sich daher ungleichmäßig über die 36 Arbeitstage des Zeitraums. Tabelle~\ref{tab:manntage} weist die kalenderwöchentliche Verteilung aus.
 \begin{longtable}{@{} l p{28mm} c c p{45mm} @{}}
 \caption{Verteilung der 24 Manntage über den Tätigkeitszeitraum}
 \label{tab:manntage} \\
 \toprule
 \textbf{KW} & \textbf{Zeitraum} & \textbf{AT} & \textbf{MT} & \textbf{Schwerpunkt im Projekt} \\
 \midrule
 \endfirsthead
 \toprule
 \textbf{KW} & \textbf{Zeitraum} & \textbf{AT} & \textbf{MT} & \textbf{Schwerpunkt im Projekt} \\
 \midrule
 \endhead
 \bottomrule
 \endfoot
 28 & 07.--10.07. & 4 & 3 & Anforderungen, Backlog-Schnitt \\
 29 & 13.--17.07. & 5 & 2 & Verfeinerung der Backlog Items \\
 30 & 20.--24.07. & 5 & 2 & Infrastrukturbeantragung, Einarbeitung S3 \\
 31 & 27.--31.07. & 5 & 4 & Document Explorer, S3-Client \\
 32 & 03.--07.08. & 5 & 4 & Typ-Icons, Suche \\
 33 & 10.--14.08. & 5 & 3 & Downloads, PDF-Vorschau, Abnahmebeginn \\
 34 & 17.--21.08. & 5 & 4 & Typfilter, Paginierung, Ordner-Lookup \\
 35 & 24.--25.08. & 2 & 2 & Abnahmebegleitung, Code-Reviews \\
 \midrule
 \textbf{Summe} & 07.07.--25.08. & \textbf{36} & \textbf{24} & \\
 \end{longtable}
 Die geringere Belastung in den Kalenderwochen 29 und 30 hat zwei Gründe: Zum einen war der S3-Speicher bis zum 27.~Juli nicht verfügbar, sodass die Implementierung nicht beginnen konnte (Abschnitt~\ref{sec:infrastructure}); zum anderen liefen in diesen Wochen Aufgaben aus anderen Houston-Modulen weiter. Die verlorene Kapazität wurde in den Kalenderwochen 31, 32 und 34 aufgeholt, in denen das Projekt nahezu die gesamte Arbeitszeit beanspruchte.
@@ -3,36 +3,16 @@
 \subsection{Ablauf}
-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 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.
-Die Abnahme zerfiel in zwei Abschnitte: zunächst Zugriffs- und Konfigurationsprobleme, erst danach die funktionale Prüfung.
+\subsection{Zugriff und Konfiguration}
-\subsection{Der Menüpunkt war nicht sichtbar}
+Der Menüpunkt „Dokumente" erschien nicht — Ursache war nicht der Code, sondern die Berechtigungsvergabe: der Testerin war die Anwendungsrolle nicht zugewiesen, das Verhalten entsprach der Spezifikation (Abschnitt~\ref{sec:authorization}). Die Rolle war Ende Juli nur für die Entwicklungsumgebung beantragt worden; dass ihre Vergabe an Testende ein eigener Schritt ist, war nirgends festgehalten. Hier bewährte sich die 403-Antwort: Bei 404 wäre nicht unterscheidbar gewesen, ob die Seite fehlt oder die Berechtigung.
-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}).
+Nach Klärung wurden keine Dokumente angezeigt; auch das lag an der Umgebung: fehlende Testdateien und eine falsche Zuordnung zwischen Testkonto und Organisation. 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. Eine Prüfliste für die Inbetriebnahme hätte diesen Abschnitt verkürzt.
 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.
+Am 24.~August fand die funktionale Abnahme statt: Paginierung, Suchverhalten, Sprungmarken der Freigabelinks, Fehlerverhalten, Verknüpfungsdateien und Download. Sie verlief überwiegend erfolgreich; einzelne Bestandteile waren noch nicht verfügbar, da der Pull Request zur Ordnerverwaltung erst am 26.~August zusammengeführt wurde (Abschnitt~\ref{sec:folder-management}).
-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.
+Ein Fehlerbericht: Das Suchfeld blendet nach Eingabe eine Schaltfläche zum Leeren ein, die auf den übrigen Houston-Seiten nicht existiert und damit 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. Die Behebung — Entfernen der Schaltfläche — wurde am 27.~August über Pull Request 2206 zusammengeführt. Damit war der Dokumentenbereich vollständig abgenommen; sämtliche Backlog Items standen auf \texttt{Test Completed}.
 \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.
@@ -1,42 +1,18 @@
 \section{Code-Reviews}
 \label{sec:code-reviews}
-\subsection{Umfang}
+\subsection{Umfang und Prüftiefe}
-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.
+Die Umsetzung verteilte sich auf dreizehn Pull Requests mit 114 Diskussionssträngen (Tabelle~\ref{tab:pull-requests} im Anhang). Kein Pull Request wurde abgelehnt; dass keiner verworfen wurde, geht auf die vorgelagerte Klärung durch Feature-Analyse und Backlog-Durchsicht zurück. Die Verteilung der Stränge folgte dem Risiko: die intensivste Prüfung erfuhren Einzeldownload (30 Stränge) und Freigabelinks (23), gefolgt vom Document Explorer (21); die PDF-Vorschau als reine Darstellungsfunktion kam mit zwei aus.
 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.
+Über alle Diskussionsstränge hinweg lassen sich fünf Muster erkennen. \textbf{Sicherheit und Eingabeprüfung} machte den größten Anteil aus: Pfadprüfung beim Download, zeitlich begrenzte Zugriffs-URLs statt Dateiströme, Ausschluss benutzerdefinierter Symbole aus der Vorschau und keine Auslieferung über nicht authentifizierte Pfade. \textbf{Kompatibilität vor Ideallösung}: Mehrfach wurde eine sauberere Lösung zugunsten einer verlässlicheren verworfen — etwa Vorschaubilder als Rastergrafik, weil die Vektorvariante von verbreiteten Messengern nicht zuverlässig dargestellt wird (Abschnitt~\ref{sec:pdf-preview}). \textbf{Abgrenzung statt Ausweitung}: Erkannte Probleme wurden als neue Backlog Items erfasst statt im laufenden Pull Request miterledigt. \textbf{Struktur und Wartbarkeit}: 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).
 \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 Hauptreviewer wechselte zweimal: \emph{Timo Walter} prüfte die fünf Pull Requests der Anfangsphase, \emph{Sarah Hinzmann} übernahm Anfang August, \emph{Robin Noack} die Schlussphase; \emph{Hanna Ebner} beteiligte sich an den frühen Diskussionen. Der Wechsel hatte einen fachlichen Effekt: frühe Reviews befassten sich mit Architektur und Sicherheit, späte mit Benennung und Codestil; zugleich verteilte er das Wissen über das Modul im Team.
 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.
+Am 27.~Juli wurden vier Pull Requests am selben Tag eröffnet, ein fünfter folgte tags darauf. Da sie inhaltlich aufeinander aufbauten (Abschnitt~\ref{sec:architecture}), ließ sich nur der erste zeitnah abschließen; die übrigen blieben zwei bis drei Wochen offen, und der überwiegende Teil der Zusammenführungen fiel in die Woche vom 18.~bis 21.~August — unmittelbar vor der Abnahme. Sequenzielles Vorgehen wäre vorzuziehen gewesen, da die inhaltliche Abhängigkeit echtes paralleles Vorankommen ohnehin verhinderte.
 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.
@@ -1,26 +1,18 @@
 \section{Auslieferung}
 \label{sec:releases}
-\subsection{Umgebungen}
+\subsection{Umgebungen und Rollen}
-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.
+Die Auslieferung folgt dem in Houston etablierten dreistufigen Weg über Entwicklungs-, Test- und Produktivumgebung. Jede Stufe besitzt einen eigenen Speicher (Abschnitt~\ref{sec:s3-client}), der eingerichtet, erreichbar und korrekt hinterlegt sein muss; deshalb wurde die Infrastrukturbereitstellung (Abschnitt~\ref{sec:infrastructure}) bereits im Approval-Termin als Voraussetzung vermerkt.
-Deshalb wurde die Infrastrukturbereitstellung (Abschnitt~\ref{sec:infrastructure}) bereits im Approval-Termin als Voraussetzung vermerkt.
+Auch die Anwendungsrolle muss je Umgebung vorhanden und zugewiesen sein — eine begleitende Maßnahme, die im Abnahmetest zu Verzögerungen führte (Abschnitt~\ref{sec:acceptance-testing}). Vor der Produktivsetzung wurde daher am 20.~August geprüft, ob sämtliche Einstiegspunkte des Moduls hinter der Rolle liegen; die zentrale Registrierung (Abschnitt~\ref{sec:architecture}) macht eine ungeschützte Route unwahrscheinlich, die Prüfung bestätigte dies.
-\subsection{Rollen als Teil der Auslieferung}
+\subsection{Benutzerdokumentation}
-Die Anwendungsrolle muss je Umgebung vorhanden sein und den betreffenden Personen zugewiesen werden — kein Bestandteil des Anwendungsstands, sondern eine begleitende Maßnahme.
+Zum Funktionsumfang gehört das als PDF ausgelieferte Houston-Benutzerhandbuch, das für den Dokumentenbereich um ein eigenes Kapitel ergänzt wurde: Aufruf der Seite, Typfilter und Suche, Einzel- und Archivdownload, PDF-Vorschau, Freigabelinks sowie Verknüpfungsdateien. Erfasst als eigenes Backlog Item (10167) und über Pull Request 2215 am 2.~September zusammengeführt. Die Trennung von der Implementierung ist bewusst: Das Handbuch beschreibt den Endzustand und ließ sich sinnvoll erst schreiben, als sämtliche Funktionen zusammengeführt waren.
-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.
+\subsection{Stand bei Produktivsetzung}
-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.
+Alle dreizehn Pull Requests des Features sind zusammengeführt. Die Kernfunktionen entstanden in der Woche vom 18.~bis 21.~August; die Ordnerverwaltung mit dem neuen Kundenordner-Lookup folgte am 26.~August (Pull Request 2196), der Fehler aus der Abnahme wurde am 27.~August behoben (Pull Request 2206). Sämtliche Backlog Items stehen im Zustand \texttt{Test Completed} oder \texttt{Done}, die Recherche zur Speicherabfrage (9857) ist abgeschlossen. Am 3.~September wurde der Dokumentenbereich in die Produktivumgebung ausgeliefert.
-\subsection{Stand bei Abgabe}
+Offen bleibt einzig das Backlog Item zur Nebenläufigkeit im verändernden Lookup-Pfad (10070). Es ist freigegeben, aber nicht eingeplant, da die Gegenmaßnahme von einer Rückfrage beim Betreiber des Speichers abhängt (Abschnitt~\ref{sec:race-conditions}).
 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}).
@@ -1,14 +1,6 @@
 \section{Teststrategie}
 \label{sec:test-strategy}
-Die Qualitätssicherung stützte sich auf drei Stufen.
+Die Qualitätssicherung stützte sich auf drei Stufen. \textbf{Unit-Tests} sichern isoliert prüfbare Logik ab — vor allem Kundenordner-Auflösung und Pfadbehandlung — und laufen bei jedem Übersetzungsvorgang. \textbf{Code-Reviews} prüfen Entwurf, Lesbarkeit und Sicherheitseigenschaften, etwa ob eine Information auf einem nicht authentifizierten Pfad ausgeliefert werden darf. \textbf{Abnahmetests} prüfen gegen die Akzeptanzkriterien in der tatsächlichen Umgebung und erfassen Fehler aus dem Zusammenspiel von Konfiguration, Berechtigungen und realen Daten.
-\textbf{Unit-Tests} sichern isoliert prüfbare Logik ab — hier vor allem Kundenordner-Auflösung und Pfadbehandlung. Sie laufen bei jedem Übersetzungsvorgang.
+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. Die Kehrseite: Fehler in Bereichen ohne automatisierte Abdeckung wurden erst im Abnahmetest gefunden (Abschnitt~\ref{sec:acceptance-testing}).
 \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}).
@@ -3,26 +3,12 @@
 \subsection{Testbarkeit durch Kapselung}
-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.
+Da der Speicherzugriff über die SDK-Schnittstelle erfolgt, lässt sich diese in Tests durch eine Attrappe ersetzen; die Tests laufen ohne Netzwerkverbindung, Zugangsdaten und realen Speicher. Die Attrappe erlaubt zudem Zustände, die sich real kaum erzeugen ließen — etwa einen Kundenordner mit falschem Namen, aber korrektem Metadatum, oder einen Ordner ohne Metadatum.
 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 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. Denn die Anforderung war keine funktionale, sondern eine über den Aufwand: dass der Regelfall mit einem einzigen Zugriff auskommt, lässt sich nur über die beobachteten Aufrufe prüfen.
-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{Befunde aus dem Review von Testcode}
-\subsection{Testdaten}
+Zwei Reviewhinweise \emph{Timo Walters} betrafen die Tests selbst. Zum einen verwendeten Testdaten reale Kundennamen statt Platzhaltern; die Daten wurden ersetzt. Zum anderen bestand ein Test aus dem falschen Grund: Er brach bereits an einem unbekannten Typbezeichner ab, ohne die zu prüfende Sicherheitseigenschaft — dass ein in die Adresse geschriebener Kundenname kein Ergebnis liefert — je zu erreichen. Der Fund war nur durch Lesen zu erzielen, da der Test grün war. Als Konsequenz wurde die Anforderung, dass ein Test ohne den jeweiligen Fix fehlschlagen muss, in die Akzeptanzkriterien des Folgeitems zur Nebenläufigkeit aufgenommen (Abschnitt~\ref{sec:race-conditions}).
 \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}).
@@ -1,10 +0,0 @@
 stateDiagram-v2
    [*] --> New
    New --> ToApprove : Linus reicht PBI ein
    ToApprove --> Approved : Approval-Team
    Approved --> Committed : Sprint-Planung
    Committed --> DevCompleted : PR gemerged
    DevCompleted --> TestCompleted : Abnahme bestanden
    TestCompleted --> [*]
    ToApprove --> Removed : Verworfen
    Removed --> New : Wiederhergestellt
@@ -1,8 +1,10 @@
 gantt
    title Zeitplanung PidI 3 (Sprints 15–17.2026)
    dateFormat YYYY-MM-DD
-    section Planung
+    section Vorlauf
        Feature-Analyse          :done, 2026-06-18, 1d
    section Sprint 14.2026
        Praxiseinsatz Beginn     :milestone, done, 2026-07-07, 0d
        Anforderungen & Backlog  :done, 2026-07-07, 5d
    section Sprint 15.2026
        Document Explorer        :done, 2026-07-27, 5d
@@ -10,9 +12,12 @@ gantt
        Downloads & PDF-Modal    :done, 2026-08-15, 7d
    section Sprint 16.2026
        Typfilter & Pagination   :done, 2026-08-18, 4d
-        Ordner-Lookup            :active, 2026-08-17, 8d
+        Ordner-Lookup            :done, 2026-08-17, 10d
-    section Sprint 17.2026
+        Praxiseinsatz Ende       :milestone, done, 2026-08-25, 0d
-        Race Conditions (10070)  :2026-08-26, 5d
+    section Sprint 17.2026 (Nachlauf)
        Bugfix Suchfeld (10134)  :done, 2026-08-27, 1d
        Handbuch (10167)         :done, 2026-08-31, 3d
        Race Conditions (10070)  :2026-09-08, 5d
    section Qualitätssicherung
        Abnahmetest              :done, 2026-08-13, 12d
-        Release                  :2026-08-26, 3d
+        Produktivsetzung         :milestone, done, 2026-09-03, 0d
@@ -1,10 +1,15 @@
-%%{init: {'theme': 'base'}}%%
+%%{init: {'theme': 'base', 'flowchart': {'nodeSpacing': 30, 'rankSpacing': 45}}}%%
-timeline
+flowchart LR
-    title Infrastrukturbeschaffung S3-Speicher
+    A["<b>22.07.2026</b><br/>Service Request<br/>im Maschinenraum"]
-    2026-07-22 : Service Request erstellt (Maschinenraum)
+    B["<b>23.07.2026</b><br/>Zuweisung an<br/>Alexander Wagner"]
-    2026-07-23 : Request Alexander Wagner zugewiesen
+    C["<b>27.07.2026</b><br/>Drei Buckets angelegt,<br/>Zugangsdaten in Passbolt"]
-    2026-07-27 : 3 Buckets durch AU erstellt, Credentials in Passbolt
+    D["<b>30.07.2026</b><br/>Anfrage S3 Select und<br/>Search Integration"]
-    2026-07-30 : Anfrage S3 Select + Search Integration
+    E["<b>04.08.2026</b><br/>Lennart Meinert<br/>kontaktiert AU"]
-    2026-08-04 : Lennart Meinert kontaktiert AU
+    F["<b>07.08.2026</b><br/>S3 Select für alle<br/>drei Buckets aktiviert"]
-    2026-08-07 : S3 Select für alle 3 Buckets aktiviert
+    G["<b>17.08.2026</b><br/>Search Integration<br/>von AU abgelehnt"]
-    2026-08-17 : Search Integration von AU abgelehnt
+
    A --> B --> C --> D
    E --> F --> G
    classDef step fill:#eef2f7,stroke:#5b6b7f,stroke-width:1px,color:#111
    class A,B,C,D,E,F,G step
@@ -0,0 +1,6 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
 <path d="M5.5 24C4.67157 24 4 23.3284 4 22.5V12.5C4 11.6716 4.67157 11 5.5 11H13.5C13.7761 11 14 11.2239 14 11.5C14 11.7761 13.7761 12 13.5 12H5.5C5.22386 12 5 12.2239 5 12.5V22.5C5 22.7761 5.22386 23 5.5 23H15.5C15.7761 23 16 22.7761 16 22.5V17.5C16 17.2239 16.2239 17 16.5 17C16.7761 17 17 17.2239 17 17.5V22.5C17 23.3284 16.3284 24 15.5 24H5.5Z" fill="black"/>
 <path d="M10.8536 19.8536L17.8536 12.8536C18.0488 12.6583 18.0488 12.3417 17.8536 12.1464C17.6583 11.9512 17.3417 11.9512 17.1464 12.1464L10.5 18.7929L7.85355 16.1464C7.65829 15.9512 7.34171 15.9512 7.14645 16.1464C6.95118 16.3417 6.95118 16.6583 7.14645 16.8536L10.1464 19.8536C10.3417 20.0488 10.6583 20.0488 10.8536 19.8536Z" fill="black"/>
 <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
 <path d="M14.4131 4.71875V1.34375L19.6304 6.82812H16.587C15.8623 6.82812 14.4131 6.40625 14.4131 4.71875Z" fill="black" stroke="black"/>
 </svg>
@@ -0,0 +1,10 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
 <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
 <path d="M14.4131 4.71875V1.34375L19.6304 6.82812H16.587C15.8623 6.82812 14.4131 6.40625 14.4131 4.71875Z" fill="black" stroke="black"/>
 <path d="M10.5 21.4571H11.4962C11.8121 24.1767 13.6102 25.75 16.4449 25.75C17.0281 25.75 17.5383 25.6868 18 25.5761V24.3586C17.5464 24.4693 17.02 24.5167 16.4449 24.5167C14.4768 24.5167 13.2052 23.3941 12.9055 21.4571H16.6717V20.5875H12.8407C12.8407 20.5717 12.8407 20.5559 12.8407 20.5401V19.7099C12.8407 19.6072 12.8407 19.5044 12.8488 19.4016H16.6717V18.532H12.9541C13.3186 16.7532 14.5659 15.7333 16.4449 15.7333C17.02 15.7333 17.5464 15.7807 18 15.8993V14.6818C17.5383 14.5632 17.0281 14.5 16.4449 14.5C13.6992 14.5 11.9255 15.9705 11.5286 18.532H10.5V19.4016H11.4476C11.4476 19.4965 11.4476 19.5993 11.4476 19.6941V20.5875H10.5V21.4571Z" fill="black"/>
 <line x1="18" y1="12" x2="3" y2="12" stroke="black" stroke-linecap="round"/>
 <line x1="11" y1="15" x2="3" y2="15" stroke="black" stroke-linecap="round"/>
 <line x1="9" y1="18" x2="3" y2="18" stroke="black" stroke-linecap="round"/>
 <line x1="9" y1="21" x2="3" y2="21" stroke="black" stroke-linecap="round"/>
 <line x1="10" y1="24" x2="3" y2="24" stroke="black" stroke-linecap="round"/>
 </svg>
@@ -0,0 +1,4 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
  <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
  <path d="M14.4131 4.71875V1.34375L19.6304 6.82812H16.587C15.8623 6.82812 14.4131 6.40625 14.4131 4.71875Z" fill="black" stroke="black"/>
 </svg>
@@ -0,0 +1,5 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
  <path fill-rule="evenodd" clip-rule="evenodd" d="M8.5 10.5C8.71025 10.5 8.89804 10.6315 8.9699 10.8291L12.5 20.5369L14.0301 16.3291C14.102 16.1315 14.2897 16 14.5 16H18C18.2761 16 18.5 16.2239 18.5 16.5C18.5 16.7761 18.2761 17 18 17H14.8502L12.9699 22.1709C12.898 22.3685 12.7103 22.5 12.5 22.5C12.2897 22.5 12.102 22.3685 12.0301 22.1709L8.5 12.4631L6.9699 16.6709C6.89804 16.8685 6.71025 17 6.5 17H3C2.72386 17 2.5 16.7761 2.5 16.5C2.5 16.2239 2.72386 16 3 16H6.14979L8.0301 10.8291C8.10196 10.6315 8.28975 10.5 8.5 10.5Z" fill="black"/>
  <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
  <path d="M14.413 4.71875V1.34375L19.6304 6.82812H16.5869C15.8623 6.82812 14.413 6.40625 14.413 4.71875Z" fill="black" stroke="black"/>
 </svg>
@@ -0,0 +1,12 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
 <g clip-path="url(#clip0_5826_132)">
 <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
 <path d="M14.4131 4.71875V1.34375L19.6304 6.82812H16.587C15.8623 6.82812 14.4131 6.40625 14.4131 4.71875Z" fill="black" stroke="black"/>
 <path d="M7.78762 21.0079C6.85412 20.7746 6.33409 20.0328 6.33208 18.9311C6.33141 18.5793 6.35688 18.4104 6.44467 18.1839C6.65978 17.629 7.23074 17.2102 7.98062 17.056C8.35389 16.9797 8.46914 16.8972 8.46914 16.7062C8.46914 16.6466 8.51338 16.4683 8.56767 16.3102C8.81428 15.5931 9.27131 14.9947 9.75984 14.7501C10.2712 14.4941 10.5285 14.4365 11.147 14.4398C12.0249 14.4445 12.4632 14.6348 13.0757 15.2782L13.4128 15.632L13.7143 15.5275C15.1752 15.0222 16.6314 15.8826 16.7487 17.3208L16.7809 17.7141L17.0684 17.8173C17.89 18.1115 18.276 18.7294 18.2063 19.6381C18.1607 20.2325 17.8826 20.707 17.4423 20.9422L17.2352 21.0528L12.6374 21.0615C9.10444 21.0682 7.98196 21.0561 7.78762 21.0079ZM4.34043 20.3732C3.79561 20.2439 3.21795 19.7621 2.94721 19.2119C2.79375 18.8996 2.78571 18.8534 2.78571 18.3012C2.78571 17.7758 2.79911 17.6913 2.92107 17.4307C3.17908 16.8805 3.67297 16.4831 4.29285 16.3269C4.42353 16.2941 4.54683 16.2412 4.56627 16.2103C4.5857 16.1795 4.60714 16.0086 4.61452 15.831C4.6574 14.7307 5.37981 13.761 6.3877 13.4494C6.93253 13.2812 7.61674 13.3227 8.20914 13.5593C8.39678 13.6343 8.37601 13.6504 8.7734 13.1297C9.00862 12.8214 9.48308 12.4381 9.87176 12.2431C10.2913 12.0327 10.7275 11.9355 11.2489 11.9369C12.7071 11.9402 13.9636 12.8523 14.428 14.2441C14.5768 14.6891 14.5688 14.8131 14.3939 14.8171C14.3175 14.8184 14.0983 14.8607 13.9073 14.9103L13.5595 15.0007L13.2426 14.6838C12.3479 13.7891 10.8884 13.5961 9.64793 14.208C9.15203 14.4526 8.75396 14.803 8.45306 15.2601C8.23862 15.5858 7.96521 16.1942 7.96521 16.345C7.96521 16.4522 7.87877 16.5059 7.50818 16.6272C6.36157 17.0031 5.69277 17.8716 5.69277 18.9827C5.69277 19.3875 5.79731 19.882 5.94139 20.1655C5.99567 20.2727 6.0265 20.3739 6.00908 20.3913C5.96485 20.4356 4.53812 20.4201 4.34043 20.3732Z" fill="black"/>
 </g>
 <defs>
 <clipPath id="clip0_5826_132">
 <rect width="21" height="28" fill="white"/>
 </clipPath>
 </defs>
 </svg>
@@ -0,0 +1,12 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
 <g clip-path="url(#clip0_5827_149)">
 <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
 <path d="M14.4131 4.71875V1.34375L19.6304 6.82812H16.587C15.8623 6.82812 14.4131 6.40625 14.4131 4.71875Z" fill="black" stroke="black"/>
 <path d="M18.5 17.9375C18.5 18.4575 18.4 18.945 18.2 19.4C18.005 19.85 17.7375 20.245 17.3975 20.585C17.0575 20.925 16.66 21.195 16.205 21.395C15.75 21.59 15.265 21.6875 14.75 21.6875C14.43 21.6875 14.1125 21.6475 13.7975 21.5675C13.7525 21.9825 13.6375 22.3675 13.4525 22.7225C13.2625 23.0825 13.02 23.395 12.725 23.66C12.435 23.925 12.1025 24.13 11.7275 24.275C11.3475 24.425 10.95 24.5 10.535 24.5C10.08 24.5 9.6525 24.4125 9.2525 24.2375C8.8575 24.0675 8.51 23.835 8.21 23.54C7.915 23.245 7.6825 22.8975 7.5125 22.4975C7.3375 22.0975 7.25 21.6725 7.25 21.2225V20.9825C7.265 20.9075 7.2775 20.83 7.2875 20.75H4.1225C3.9575 20.75 3.81 20.69 3.68 20.57C3.56 20.44 3.5 20.2925 3.5 20.1275V13.8725C3.5 13.7075 3.56 13.56 3.68 13.43C3.81 13.31 3.9575 13.25 4.1225 13.25H6.335C6.395 12.72 6.5475 12.22 6.7925 11.75C7.0325 11.305 7.3425 10.915 7.7225 10.58C8.0975 10.24 8.525 9.975 9.005 9.785C9.485 9.595 9.995 9.5 10.535 9.5C11.115 9.5 11.66 9.61 12.17 9.83C12.685 10.055 13.1325 10.3575 13.5125 10.7375C13.8925 11.1175 14.195 11.565 14.42 12.08C14.64 12.59 14.75 13.1375 14.75 13.7225V13.955C14.75 14.03 14.74 14.1075 14.72 14.1875C15.24 14.1875 15.7275 14.285 16.1825 14.48C16.6425 14.675 17.04 14.9425 17.375 15.2825C17.73 15.6175 18.005 16.0125 18.2 16.4675C18.4 16.9275 18.5 17.4175 18.5 17.9375ZM10.5275 10.4375C10.1225 10.4375 9.7375 10.51 9.3725 10.655C9.0025 10.795 8.67 10.99 8.375 11.24C8.095 11.49 7.8575 11.785 7.6625 12.125C7.4725 12.475 7.3475 12.85 7.2875 13.25H10.3775C10.5425 13.25 10.69 13.3125 10.82 13.4375C10.94 13.5625 11 13.7075 11 13.8725V16.9625L11.135 16.94C11.22 16.63 11.345 16.335 11.51 16.055C11.67 15.77 11.8675 15.515 12.1025 15.29C12.3275 15.065 12.585 14.8675 12.875 14.6975C13.145 14.5325 13.4375 14.4075 13.7525 14.3225C13.7925 14.1075 13.8125 13.9075 13.8125 13.7225C13.8125 13.2675 13.725 12.84 13.55 12.44C13.38 12.045 13.145 11.7 12.845 11.405C12.55 11.11 12.205 10.875 11.81 10.7C11.41 10.525 10.9825 10.4375 10.5275 10.4375ZM7.325 19.4375C7.55 19.4375 7.775 19.415 8 19.37C8.21 19.325 8.4 19.2475 8.57 19.1375C8.74 19.0325 8.8775 18.8925 8.9825 18.7175C9.0775 18.5375 9.125 18.3175 9.125 18.0575C9.125 17.7925 9.075 17.5725 8.975 17.3975C8.865 17.2225 8.7275 17.075 8.5625 16.955C8.3975 16.84 8.22 16.745 8.03 16.67L7.49 16.4525C7.33 16.3875 7.1925 16.32 7.0775 16.25C6.9675 16.175 6.9125 16.08 6.9125 15.965C6.9125 15.885 6.9425 15.8175 7.0025 15.7625C7.0625 15.7125 7.1325 15.675 7.2125 15.65C7.2925 15.615 7.375 15.5925 7.46 15.5825C7.55 15.5775 7.625 15.575 7.685 15.575C7.93 15.575 8.15 15.605 8.345 15.665C8.535 15.73 8.7325 15.825 8.9375 15.95V14.84C8.8125 14.805 8.7025 14.775 8.6075 14.75C8.5075 14.725 8.41 14.705 8.315 14.69C8.215 14.675 8.11 14.6625 8 14.6525C7.9 14.6475 7.7875 14.645 7.6625 14.645C7.4475 14.645 7.2275 14.6675 7.0025 14.7125C6.7775 14.7625 6.5725 14.8425 6.3875 14.9525C6.2125 15.0675 6.065 15.2075 5.945 15.3725C5.83 15.5475 5.7725 15.7625 5.7725 16.0175C5.7725 16.2675 5.8275 16.47 5.9375 16.625C6.0475 16.8 6.185 16.9475 6.35 17.0675C6.515 17.1825 6.69 17.285 6.875 17.375L7.415 17.5925C7.585 17.6625 7.725 17.735 7.835 17.81C7.945 17.89 8 17.985 8 18.095C8 18.19 7.9725 18.265 7.9175 18.32C7.8675 18.375 7.8025 18.415 7.7225 18.44C7.6575 18.48 7.5775 18.5 7.4825 18.5H7.25C6.955 18.5 6.695 18.455 6.47 18.365C6.24 18.265 6.01 18.135 5.78 17.975V19.145C6.275 19.34 6.79 19.4375 7.325 19.4375ZM10.5275 23.5625C10.8425 23.5625 11.145 23.5 11.435 23.375C11.72 23.255 11.97 23.09 12.185 22.88C12.395 22.665 12.5625 22.415 12.6875 22.13C12.8125 21.845 12.875 21.5425 12.875 21.2225C12.875 20.9425 12.8275 20.675 12.7325 20.42C12.6425 20.165 12.515 19.9375 12.35 19.7375C12.18 19.5325 11.98 19.36 11.75 19.22C11.525 19.08 11.275 18.98 11 18.92V20.1275C11 20.2925 10.94 20.44 10.82 20.57C10.69 20.69 10.5425 20.75 10.3775 20.75H8.2325C8.2025 20.905 8.1875 21.0625 8.1875 21.2225C8.1875 21.5425 8.25 21.845 8.375 22.13C8.495 22.415 8.66 22.665 8.87 22.88C9.085 23.09 9.335 23.255 9.62 23.375C9.905 23.5 10.2075 23.5625 10.5275 23.5625ZM14.75 20.75C15.135 20.75 15.4975 20.6775 15.8375 20.5325C16.1825 20.3875 16.4825 20.185 16.7375 19.925C16.9925 19.67 17.195 19.3725 17.345 19.0325C17.49 18.6925 17.5625 18.3275 17.5625 17.9375C17.5625 17.5625 17.49 17.2 17.345 16.85C17.195 16.505 16.9925 16.205 16.7375 15.95C16.4825 15.695 16.1825 15.4925 15.8375 15.3425C15.4975 15.1975 15.135 15.125 14.75 15.125C14.365 15.125 14.0025 15.2 13.6625 15.35C13.3225 15.5 13.025 15.7025 12.77 15.9575C12.515 16.2125 12.3125 16.51 12.1625 16.85C12.0125 17.2 11.9375 17.5625 11.9375 17.9375V18.095L11.9525 18.26C12.1825 18.37 12.395 18.505 12.59 18.665C12.78 18.825 12.955 19.0025 13.115 19.1975C13.265 19.3975 13.395 19.6125 13.505 19.8425C13.61 20.0725 13.69 20.31 13.745 20.555C14.075 20.685 14.41 20.75 14.75 20.75Z" fill="black"/>
 </g>
 <defs>
 <clipPath id="clip0_5827_149">
 <rect width="21" height="28" fill="white"/>
 </clipPath>
 </defs>
 </svg>
@@ -0,0 +1,16 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
 <g clip-path="url(#clip0_5826_117)">
 <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
 <path d="M14.4131 4.71875V1.34375L19.6304 6.82812H16.587C15.8623 6.82812 14.4131 6.40625 14.4131 4.71875Z" fill="black" stroke="black"/>
 <path d="M11.5378 14.6973C12.5219 14.5156 13.2674 13.653 13.2674 12.6163C13.2674 11.4475 12.3199 10.5 11.1511 10.5C10.0028 10.5 9.06803 11.4147 9.03574 12.5553H10.066C10.8788 12.5553 11.5378 13.2142 11.5378 14.0271V14.6973Z" fill="black"/>
 <path d="M7.77975 21.4681H10.066C10.8788 21.4681 11.5378 20.8091 11.5378 19.9963V15.3837H13.973C14.3105 15.3921 14.5776 15.6723 14.5697 16.0098V19.7667C14.6169 21.7926 13.0141 23.4737 10.9883 23.5233C9.57264 23.4886 8.36352 22.6572 7.77975 21.4681Z" fill="black"/>
 <path d="M17.1744 13.2675C17.1744 14.0766 16.5184 14.7326 15.7093 14.7326C14.9001 14.7326 14.2442 14.0766 14.2442 13.2675C14.2442 12.4583 14.9001 11.8024 15.7093 11.8024C16.5184 11.8024 17.1744 12.4583 17.1744 13.2675Z" fill="black"/>
 <path d="M15.2157 21.5698C15.1806 21.5698 15.1458 21.569 15.1111 21.5674C15.3385 21.0096 15.4582 20.3973 15.4448 19.757V16.0178C15.4482 15.792 15.401 15.577 15.3136 15.3837H16.8814C17.2231 15.3837 17.5 15.6607 17.5 16.0023V19.2963C17.5 20.5519 16.4821 21.5698 15.2265 21.5698H15.2157Z" fill="black"/>
 <path d="M4.09679 13.4303H10.066C10.3956 13.4303 10.6628 13.6975 10.6628 14.0271V19.9963C10.6628 20.3259 10.3956 20.5931 10.066 20.5931H4.09679C3.76719 20.5931 3.5 20.3259 3.5 19.9963V14.0271C3.5 13.6975 3.76719 13.4303 4.09679 13.4303ZM8.65199 15.7022V15.0719H5.51078V15.7022H6.6985V18.9515H7.45873V15.7022H8.65199Z" fill="black"/>
 </g>
 <defs>
 <clipPath id="clip0_5826_117">
 <rect width="21" height="28" fill="white"/>
 </clipPath>
 </defs>
 </svg>
@@ -0,0 +1,6 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
    <path d="M7.83794 10.0908C6.75194 10.3852 5.65214 10.7332 5.00122 10.9456C4.82213 11.0041 4.69637 11.1592 4.67276 11.3364C4.11888 15.4929 5.39864 18.5267 6.92564 20.5243C7.6923 21.5272 8.52182 22.2691 9.21336 22.7567C9.5594 23.0007 9.86532 23.1772 10.1057 23.2904C10.2261 23.347 10.3245 23.3852 10.3992 23.4084C10.4608 23.4274 10.4925 23.4319 10.5 23.433C10.5075 23.4319 10.5392 23.4274 10.6008 23.4084C10.6755 23.3852 10.7739 23.347 10.8943 23.2904C11.1347 23.1772 11.4406 23.0007 11.7866 22.7567C12.4782 22.2691 13.3077 21.5272 14.0744 20.5243C15.6014 18.5267 16.8811 15.4929 16.3272 11.3364C16.3036 11.1592 16.1779 11.0041 15.9988 10.9456C15.3479 10.7332 14.2481 10.3852 13.1621 10.0908C12.0517 9.78985 11.0309 9.56667 10.5 9.56667C9.96915 9.56667 8.9483 9.78985 7.83794 10.0908ZM7.57166 9.05965C8.65738 8.76534 9.81051 8.5 10.5 8.5C11.1895 8.5 12.3426 8.76534 13.4283 9.05965C14.5384 9.36057 15.6568 9.71461 16.3147 9.92928C16.8637 10.1084 17.279 10.5936 17.3588 11.1921C17.9554 15.6694 16.572 18.9869 14.894 21.182C14.0582 22.2754 13.1498 23.0904 12.3769 23.6354C11.9908 23.9077 11.6329 24.1165 11.329 24.2596C11.0481 24.3918 10.7477 24.5 10.5 24.5C10.2523 24.5 9.95186 24.3918 9.67105 24.2596C9.36713 24.1165 9.00924 23.9077 8.62309 23.6354C7.85024 23.0904 6.94183 22.2754 6.106 21.182C4.42804 18.9869 3.04461 15.6694 3.64123 11.1921C3.72098 10.5936 4.13625 10.1084 4.68528 9.92928C5.34316 9.71461 6.46156 9.36057 7.57166 9.05965Z" fill="black"/>
    <path d="M12 15C12 15.6531 11.5826 16.2087 11 16.4146L11.3849 18.4051C11.4446 18.7136 11.2083 19 10.894 19H10.106C9.79174 19 9.55539 18.7136 9.61506 18.4051L10 16.4146C9.4174 16.2087 9 15.6531 9 15C9 14.1716 9.67157 13.5 10.5 13.5C11.3284 13.5 12 14.1716 12 15Z" fill="black"/>
    <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
    <path d="M14.413 4.71875V1.34375L19.6304 6.82812H16.5869C15.8623 6.82812 14.413 6.40625 14.413 4.71875Z" fill="black" stroke="black"/>
 </svg>
@@ -0,0 +1,10 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
    <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
    <path d="M14.4131 4.71875V1.34375L19.6304 6.82812H16.587C15.8623 6.82812 14.4131 6.40625 14.4131 4.71875Z" fill="black" stroke="black"/>
    <path fill-rule="evenodd" clip-rule="evenodd" d="M4.5 13C4.22386 13 4 13.2239 4 13.5V14.5C4 14.7761 4.22386 15 4.5 15H5.5C5.77614 15 6 14.7761 6 14.5V13.5C6 13.2239 5.77614 13 5.5 13H4.5ZM5.5 13.5H4.5V14.5H5.5V13.5Z" fill="black"/>
    <path d="M7.5 14C7.5 13.7239 7.72386 13.5 8 13.5H17C17.2761 13.5 17.5 13.7239 17.5 14C17.5 14.2761 17.2761 14.5 17 14.5H8C7.72386 14.5 7.5 14.2761 7.5 14Z" fill="black"/>
    <path d="M8 17.5C7.72386 17.5 7.5 17.7239 7.5 18C7.5 18.2761 7.72386 18.5 8 18.5H17C17.2761 18.5 17.5 18.2761 17.5 18C17.5 17.7239 17.2761 17.5 17 17.5H8Z" fill="black"/>
    <path d="M8 21.5C7.72386 21.5 7.5 21.7239 7.5 22C7.5 22.2761 7.72386 22.5 8 22.5H17C17.2761 22.5 17.5 22.2761 17.5 22C17.5 21.7239 17.2761 21.5 17 21.5H8Z" fill="black"/>
    <path fill-rule="evenodd" clip-rule="evenodd" d="M4 17.5C4 17.2239 4.22386 17 4.5 17H5.5C5.77614 17 6 17.2239 6 17.5V18.5C6 18.7761 5.77614 19 5.5 19H4.5C4.22386 19 4 18.7761 4 18.5V17.5ZM4.5 17.5H5.5V18.5H4.5V17.5Z" fill="black"/>
    <path fill-rule="evenodd" clip-rule="evenodd" d="M4.5 21C4.22386 21 4 21.2239 4 21.5V22.5C4 22.7761 4.22386 23 4.5 23H5.5C5.77614 23 6 22.7761 6 22.5V21.5C6 21.2239 5.77614 21 5.5 21H4.5ZM5.5 21.5H4.5V22.5H5.5V21.5Z" fill="black"/>
 </svg>
@@ -0,0 +1,6 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
    <path d="M11 14.1C11 13.8238 10.7761 13.6 10.5 13.6C10.2238 13.6 9.99999 13.8238 9.99999 14.1L10 17H7C6.72386 17 6.5 17.2239 6.5 17.5C6.5 17.7761 6.72386 18 7 18H10.5C10.6326 18 10.7598 17.9473 10.8536 17.8536C10.9473 17.7598 11 17.6326 11 17.5L11 14.1Z" fill="black"/>
    <path d="M9 9.5C9 9.22386 9.22386 9 9.5 9H11.5C11.7761 9 12 9.22386 12 9.5C12 9.77614 11.7761 10 11.5 10V10.5709C12.8599 10.7655 14.0936 11.3508 15.0838 12.2095C15.0879 12.2051 15.092 12.2009 15.0962 12.1966L15.4498 11.8431L15.0962 11.4895C14.901 11.2943 14.901 10.9777 15.0962 10.7824C15.2915 10.5872 15.6081 10.5872 15.8033 10.7824L17.2175 12.1966C17.4128 12.3919 17.4128 12.7085 17.2175 12.9038C17.0223 13.099 16.7057 13.099 16.5104 12.9038L16.1569 12.5502L15.8033 12.9038C15.7991 12.908 15.7948 12.9121 15.7905 12.9161C16.8555 14.1442 17.5 15.7468 17.5 17.5C17.5 21.366 14.366 24.5 10.5 24.5C6.63401 24.5 3.5 21.366 3.5 17.5C3.5 13.9735 6.10749 11.0564 9.5 10.5709V10C9.22386 10 9 9.77614 9 9.5ZM10.5 11.5C10.3444 11.5 10.1903 11.5059 10.0379 11.5175C6.94038 11.7531 4.5 14.3418 4.5 17.5C4.5 20.8137 7.18629 23.5 10.5 23.5C13.8137 23.5 16.5 20.8137 16.5 17.5C16.5 14.3418 14.0596 11.7531 10.9621 11.5175C10.8097 11.5059 10.6556 11.5 10.5 11.5Z" fill="black"/>
    <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
    <path d="M14.413 4.71875V1.34375L19.6304 6.82812H16.5869C15.8623 6.82812 14.413 6.40625 14.413 4.71875Z" fill="black" stroke="black"/>
 </svg>
@@ -0,0 +1,6 @@
 <svg width="21" height="28" viewBox="0 0 21 28" fill="none" xmlns="http://www.w3.org/2000/svg">
    <path fill-rule="evenodd" clip-rule="evenodd" d="M13.1465 10.1464C13.3417 9.95118 13.6583 9.95118 13.8536 10.1464L17.8536 14.1464C18.0488 14.3417 18.0488 14.6583 17.8536 14.8536L15.9515 16.7556L15.123 20.0694C14.9947 20.5827 14.6056 20.9903 14.0988 21.1424L3.75427 24.2457L6.85765 13.9012C7.00966 13.3944 7.41735 13.0053 7.93058 12.877L11.2444 12.0485L13.1465 10.1464ZM11.3466 13.0537L8.17312 13.8471C8.00204 13.8899 7.86614 14.0196 7.81547 14.1885L5.24574 22.7543L13.8115 20.1845C13.9804 20.1339 14.1101 19.998 14.1529 19.8269L14.9463 16.6534L11.3466 13.0537Z" fill="black"/>
    <path fill-rule="evenodd" clip-rule="evenodd" d="M5.33196 22.7284L10.5001 18.5C11.0523 18.5 11.5001 18.0523 11.5001 17.5C11.5001 16.9477 11.0523 16.5 10.5001 16.5C9.94777 16.5 9.50006 16.9477 9.50006 17.5L5.2716 22.668L5.24574 22.7543L5.33196 22.7284Z" fill="black"/>
    <path d="M0.5 24.0161C0.5 25.1774 1.1087 27.5 3.54348 27.5H17.4565C18.471 27.5 20.5 26.8032 20.5 24.0161V6.59677L14.413 0.5H3.54348C2.52899 0.5 0.5 1.10968 0.5 3.54839V24.0161Z" stroke="black"/>
    <path d="M14.413 4.71875V1.34375L19.6304 6.82812H16.5869C15.8623 6.82812 14.413 6.40625 14.413 4.71875Z" fill="black" stroke="black"/>
 </svg>
@@ -0,0 +1 @@
 https://houston.worksimple.me/documents?PageSize=10
@@ -0,0 +1 @@
 https://houston.worksimple.me/Documents?pageSize=10&pageToken=U2VydmljZS1Qcm90b2tvbGwvdW5pY29ybiBwYXJ0eXl5eSAtIENvcHkgKDEyKS5qcGc
@@ -0,0 +1 @@
 https://houston.worksimple.me/document/U2VydmljZS1Qcm90b2tvbGwvdW5pY29ybiBwYXJ0eXl5eSAtIENvcHkgKDIpLmpwZw/share
@@ -1,4 +1,11 @@
-% \chapter*{Kurzfassung}
+\chapter*{Kurzfassung}
-% \addcontentsline{toc}{chapter}{Kurzfassung}
+\addcontentsline{toc}{chapter}{Kurzfassung}
-% TODO
+
-% \clearpage
+Das Praktikum dokumentiert die Entwicklung des Houston-Moduls „Dokumente" — ein kundenseitiger Dokumentenbereich im Portal der WorkSimple GmbH. Das System stellt Kundendokumente aus einem S3-Speicher (NetApp StorageGRID) bereit und kombiniert mehrere Anforderungen: Document Explorer, Suche, Downloadfunktionalität, PDF-Vorschau, Typfilter, Pagination und automatische Ordnerstrukturanlage.
 Die Kernherausforderung lag in einer Mandatsparitäts-Diskrepanz: Houston autorisiert über die Efecte-Organisations-ID, das Kundenservice-Management pflegt S3-Ordner aber über den Kundennamen. Der Speicher bietet keine Metadatenschlüsselung für Lookups. Die Lösung verzichtet auf Metadatensuche und typisiert Dokumente stattdessen über Ordnerstruktur (Präfix-Listing), erfordert aber gleichzeitig automatische Ordneranlage bei Erstaccess. Eine Nebenläufigkeitsanalyse deckte zwei kritische Szenarien bei gleichzeitigen Operationen auf, die als separates Backlog Item 10070 deferred wurden.
 Die Umsetzung umfasst 13 zusammengeführte Pull Requests, 114 Code-Review-Kommentare, Acceptance-Testing mit Fehlerbearbeitung und Produktivsetzung am 03.~September 2026. Alle 13 funktionalen Anforderungen wurden ausgeliefert; fünf von sechs nichtfunktionalen Anforderungen sind erfüllt. Der Aufwand verteilte sich über die Sprints 15–17.2026, mit 24 Manntagen im offiziellen Tätigkeitszeitraum 07.07.--25.08.2026.
 Die dokumentierten Erkenntnisse umfassen Lookup-Architekturmuster, Race-Condition-Risikoanalyse, ZIP-Streaming-Implementierung, PDF-Vorschau-Fallstricke und Facetten der S3-Clientkonfiguration unter Fehlertoleranzanforderungen.
 \clearpage
@@ -20,8 +20,8 @@
  {Sarah Hinzmann}
 \setdates
-{07.07.2026 -- 25.08.2026}
+{07.07.2026 -- 03.09.2026}
-{25.08.2026}
+{17.09.2026}
 \begin{document}
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
0qln	cd2b6f5c80	add abstract	2026-09-10 19:25:50 +02:00
0qln	983c4f7363	adjust dates	2026-09-10 19:09:35 +02:00
0qln	f32af118d6	Zeitraum-Abgrenzung und Manntage-Verteilung ergaenzt - Abschnitt 'Zeit- und Aufwandsplanung' trennt Vorlauf (Mai/Juni), offiziellen Taetigkeitszeitraum (07.07.-25.08.2026) und Nachlauf - Neuer Unterabschnitt 'Verteilung der Manntage' mit Wochentabelle, die die 24 MT ueber 36 Arbeitstage neben dem Tagesgeschaeft ausweist - Feature-Analyse als Vorlauf gekennzeichnet - Soll-Ist-Vergleich verweist auf die Abgrenzung - Gantt-Diagramm mit Meilensteinen fuer Beginn/Ende des Praxiseinsatzes	2026-09-10 19:06:21 +02:00
0qln	c6a8d3d828	Diagramme auf Chartgroesse zuschneiden (mmdc --pdfFit); leeren Anhang A.2 entfernt	2026-09-07 23:49:37 +02:00
0qln	da3718adae	todo	2026-09-07 23:42:43 +02:00
0qln	235b471ad9	Textreduktion	2026-09-07 23:37:09 +02:00
0qln	3ecc28ef73	Aktualisierung auf den aktuellen DevOps-Stand (Abnahme, Bugfix, Handbuch, PROD)	2026-09-07 23:08:06 +02:00
0qln	e0cf30bb14	todoa	2026-09-07 22:57:38 +02:00
0qln	e6d4fb04a4	Textreduktion: Theorie, Nebenläufigkeit, Tests und Prozessbeschreibung gestrafft - Newtype/parse-dont-validate auf Projektspezifik gekuerzt - Nebenlaeufigkeitsszenarien und Gegenmassnahmen als Tabellen statt Fliesstext - Testcode-Reviewbefunde (Timo Walter) zusammengefasst - Unicorn-Entwicklungsprozess-Beschreibung gekuerzt (Diagramm traegt Details) - S3-Infrastrukturbeschaffung: Bewertung entfernt, Text gestrafft - Normalisierungs-Review (Robin Noack) gekuerzt	2026-09-01 18:20:44 +02:00
0qln	a421546df3	5.9.5: IconFile-Werte, Rueckfallverhalten und Symbolverweise ergaenzt	2026-09-01 12:33:54 +02:00
0qln	71c55cb9e8	5.8.4: Freigabe-Endpunkt kommt ohne Speicherzugriff aus	2026-09-01 12:32:30 +02:00
0qln	43feca99a9	5.8: Verweise auf Screenshots der Vorschau und Freigabelinks	2026-09-01 12:30:54 +02:00
0qln	8d251c73a1	5.4.1: Symbolsatz im Anhang, Urheberschaft der Entwuerfe ergaenzt	2026-09-01 12:30:13 +02:00
0qln	b38bdca078	4.5.2: Urheberschaft der Loesungsansaetze klargestellt	2026-09-01 12:27:22 +02:00
0qln	cdcb38f6d0	Anhang: Screenshots des Dokumentenbereichs; Verweise aus 4.4	2026-09-01 12:26:42 +02:00
0qln	f7bff8d238	4.4.2: Zeilendarstellung als Entscheidung von Hanna Ebner ausgewiesen	2026-09-01 12:24:10 +02:00
0qln	ffe2483f44	4.4.1: Clickdummy auf die Typfilterung eingegrenzt, Urheberschaft klargestellt	2026-09-01 12:23:36 +02:00
0qln	8ef18a03b2	4.3.3: Verhalten bei unbekannten Typ-Ordnern gegen Code praezisiert	2026-09-01 12:22:39 +02:00
0qln	a4452b70b1	Abb. 3.2: Infrastruktur-Chronologie als Flussdiagramm von links nach rechts	2026-09-01 12:06:37 +02:00
0qln	b949d1926a	3.4.2: PBI- und Anforderungstabelle einleitend verweisen	2026-09-01 12:04:49 +02:00
0qln	5bc07bd1a9	3.4.1: Unicorn-Softwareprozess statt eigenem Zustandsdiagramm	2026-09-01 12:04:02 +02:00
0qln	b6526e76c6	1.3: Systemkontext-Abbildung aus PidI 2 uebernommen	2026-09-01 12:03:03 +02:00
0qln	d09434f72f	5.1: Newtype-Pattern und parse-dont-validate als Entwurfsgrundlage	2026-09-01 11:51:10 +02:00
0qln	0b0b89c3cc	todos	2026-09-01 11:39:05 +02:00
0qln	f83a26a448	add screenshots and reference resources	2026-08-29 21:09:21 +02:00
		`@@ -1 +0,0 @@`
			`% TODO: eingebundene Diagramme (falls nicht inline in Kapiteln)`
		`@@ -0,0 +1 @@`
							`https://houston.worksimple.me/documents?PageSize=10`
		`@@ -0,0 +1 @@`
							`https://houston.worksimple.me/document/U2VydmljZS1Qcm90b2tvbGwvdW5pY29ybiBwYXJ0eXl5eSAtIENvcHkgKDIpLmpwZw/share`