privat/CV/andreknie.de/FINDINGS-REMEDIATION-PLAN.md

@@ -0,0 +1,763 @@
+# andreknie.de Findings Remediation Plan
+
+Status: Umsetzungsanleitung, noch nicht abgearbeitet
+
+Zielgruppe: Nachfolgendes Codex-Modell, insbesondere Luna
+
+Letzter Review: 2026-07-28
+
+## 1. Auftrag und Arbeitsgrenzen
+
+Dieser Plan beschreibt die schrittweise Behebung der Findings aus dem vollstaendigen
+Review aller Seiten, Komponenten und relevanten Backend-Flows von andreknie.de.
+
+Wichtig:
+
+- Nicht alle Arbeitspakete auf einmal umsetzen.
+- Zu Beginn eines neuen Tasks genau ein vom Benutzer ausgewaehltes Arbeitspaket
+  bearbeiten.
+- Vor der Implementierung den aktuellen Stand erneut lesen und die Findings
+  verifizieren.
+- Keine unaufgeforderten Refactorings ausserhalb des ausgewaehlten Pakets.
+- Bestehende Benutzer-Aenderungen im Worktree nicht zuruecksetzen.
+- Keine echten Kontakt-, Newsletter- oder Speaker-CV-Anfragen in Produktion
+  absenden.
+- Personenbezogene Produktionsdaten niemals in Logs, Antworten, Screenshots,
+  Commits oder Test-Fixtures uebernehmen.
+
+## 2. Verbindlicher Repository-Kontext
+
+### 2.1 Source of Truth
+
+Arbeitsverzeichnis:
+
+```text
+C:\Coding\Orchestrator
+```
+
+Component:
+
+```text
+C:\Coding\Orchestrator\privat\CV\andreknie.de
+```
+
+Hub:
+
+```text
+https://git.d-hive.de/ankn/Orchestrator.git
+```
+
+Foederiertes Spoke-Repository:
+
+```text
+https://git.d-hive.de/dHive/andreknie.de.git
+```
+
+Nicht verwenden:
+
+- Das alte GitHub-Repository. Es ist veraltet.
+- Eine separate lokale Clone-Kopie von andreknie.de.
+- Direkte Aenderungen ausserhalb des Orchestrator-Monorepos.
+
+### 2.2 Vor jeder Arbeit lesen
+
+Vom Orchestrator-Root:
+
+```text
+AGENTS.md
+.agents/AGENTS.md
+.kiro/steering/*.md
+privat/CV/andreknie.de/README.md
+privat/CV/andreknie.de/DEPLOYMENT-PLAN.md
+privat/CV/andreknie.de/.gitea/workflows/deploy.yml
+privat/CV/andreknie.de/FINDINGS-REMEDIATION-PLAN.md
+```
+
+Dabei haben die aktuellen System- und Benutzeranweisungen Vorrang. Fuer
+versionierte Aenderungen gilt der in den Repository-Regeln beschriebene
+Feature-Branch-, Commit-, Push- und Pull-/Merge-Request-Ablauf. Nicht direkt auf
+`master` oder `main` pushen.
+
+### 2.3 Gitea und Foederation
+
+- Gitea wird ueber `tea` mit Browser-Authentifizierung verwendet.
+- Lokales Tool:
+
+```text
+C:\Coding\tools\tea\tea.exe
+```
+
+- Gitea-Login: `dhive`
+- Der Runner arbeitet im foederierten Spoke.
+- Deployment erst nach erfolgreichem Review und Merge.
+- Vor einem Deployment die aktuellen Orchestrator-/Federationsanleitungen
+  erneut lesen. Keine eigene Synchronisationsvariante erfinden.
+- Workflow-Status nach dem Merge im Spoke mit `tea actions runs` pruefen.
+- Live-Deployment erst als erfolgreich melden, wenn der Gitea-Run erfolgreich
+  ist und die konkrete Aenderung auf `https://andreknie.de` verifiziert wurde.
+
+## 3. Technischer Ausgangspunkt
+
+Stack:
+
+- React 19
+- React Router 7
+- Vite 8
+- Express 5
+- Caddy
+- Datei-basiertes CMS aus Markdown und YAML
+- Gitea Actions Deployment
+
+Relevante Befehle im Component-Verzeichnis:
+
+```powershell
+& 'C:\Users\knie\.cache\codex-runtimes\codex-primary-runtime\dependencies\bin\fallback\pnpm.cmd' run build
+& 'C:\Users\knie\.cache\codex-runtimes\codex-primary-runtime\dependencies\bin\fallback\pnpm.cmd' run test
+.\node_modules\.bin\eslint.CMD src server plugins vite.config.js
+```
+
+Hinweise:
+
+- Der volle Lint ueber das gesamte Repository erfasst alte generierte Dateien
+  unter `site/assets` und ist deshalb fuer gezielte Source-Pruefungen nicht
+  aussagekraeftig.
+- Fuer UI-Tests den lokalen Vite-Server starten und Desktop sowie Mobil mit
+  Browser-Automation pruefen.
+- Relevante Viewports:
+  - Desktop: 1440 x 900
+  - Mobile: 375 x 844
+  - Mobile: 390 x 844
+  - Mobile: 430 x 932
+- Nach Tests alle selbst gestarteten lokalen Server beenden.
+
+## 4. Allgemeiner Ablauf fuer jedes Arbeitspaket
+
+1. Repository-Regeln und diesen Plan lesen.
+2. `git status --short --branch` im Orchestrator pruefen.
+3. Bei fremden Aenderungen nicht zuruecksetzen; Ueberschneidungen sorgfaeltig
+   analysieren.
+4. Aktuellen Hub-Stand per Fast-Forward aktualisieren.
+5. Einen aussagekraeftigen Feature-Branch erstellen.
+6. Nur die Dateien des ausgewaehlten Arbeitspakets bearbeiten.
+7. Relevante Unit-, Integrations- und Browser-Tests ausfuehren.
+8. Build und gezielten Source-Lint ausfuehren.
+9. Diff auf Scope, Secrets, generierte Artefakte und unbeabsichtigte
+   Content-Aenderungen pruefen.
+10. Conventional Commit erstellen.
+11. Branch zum Gitea-Hub pushen und Pull-/Merge-Request erstellen.
+12. PR/MR pruefen; nicht ohne erfolgreiche Quality Gates mergen.
+13. Nach Freigabe mergen und den dokumentierten Hub-and-Spoke-
+    Federationsablauf ausfuehren.
+14. Gitea-Deployment beobachten.
+15. Live nur die betroffenen Funktionen read-only pruefen. Keine echten
+    Formulare absenden.
+
+## 5. Prioritaet 1: Datenschutz und Ausfallsicherheit
+
+Branch-Vorschlag:
+
+```text
+fix/andreknie-data-lifecycle
+```
+
+### 5.1 Token-Lebenszyklus korrigieren
+
+Betroffene Dateien:
+
+```text
+server/services/confirmationToken.js
+server/routes/contact.js
+server/routes/talk-request.js
+server/routes/newsletter.js
+src/pages/Datenschutz.jsx
+```
+
+Aktuelles Problem:
+
+- Bestaetigte Tokens bleiben durch die Cleanup-Bedingung dauerhaft erhalten.
+- Die Token-Datei enthaelt personenbezogene Formulardaten.
+- Bestaetigte Tokens werden vor erfolgreichem Abschluss des Folgeprozesses
+  verbraucht.
+
+Umsetzung:
+
+1. Token-Zustaende explizit modellieren, mindestens `pending` und `processing`.
+2. Eine atomare Funktion einfuehren, die einen gueltigen Token fuer die
+   Verarbeitung reserviert, ihn aber noch nicht endgueltig entfernt.
+3. Nach erfolgreichem Folgeprozess den Token vollstaendig aus der Datei
+   entfernen.
+4. Bei einem Folgefehler den Token wieder auf `pending` setzen oder eine
+   kontrollierte Wiederholung erlauben.
+5. Abgelaufene Tokens unabhaengig vom bisherigen Status entfernen.
+6. Bestaetigte personenbezogene Payloads nicht als Historie behalten.
+7. Gleichzeitige Aufrufe weiterhin durch den vorhandenen Mutex schuetzen.
+8. Keine Tokenwerte oder Payloads loggen.
+9. Vor einer Bereinigung bestehender Produktionsdaten eine Sicherung nach dem
+   vorhandenen Betriebs-/Backup-Verfahren vorsehen. Keine Produktionsdateien
+   aus dem lokalen Task heraus manipulieren.
+
+Vorgesehene Tests:
+
+- Unit: Ein neuer Token ist vor Ablauf gueltig.
+- Unit: Ein abgelaufener Token wird abgelehnt und entfernt.
+- Unit: Ein erfolgreich verarbeiteter Token wird entfernt.
+- Unit: Ein fehlgeschlagener Folgeprozess laesst einen kontrollierten Retry zu.
+- Unit: Zwei parallele Bestaetigungen erzeugen genau einen Folgeprozess.
+- Unit: Cleanup entfernt abgelaufene pending/processing-Datensaetze.
+- Unit: Cleanup behaelt keine erfolgreich verarbeiteten personenbezogenen
+  Payloads.
+- Integration Kontakt: Erfolgreicher Mailversand fuehrt zu Success-Redirect.
+- Integration Kontakt: Mailfehler fuehrt nicht zum endgueltigen Tokenverlust.
+- Integration Newsletter: Wiederholte Bestaetigung erzeugt keinen doppelten
+  Subscriber.
+- Integration Talk Request: Gleiches Verhalten wie beim Kontaktformular.
+
+Akzeptanzkriterien:
+
+- Kein erfolgreich verarbeiteter Token verbleibt in `pending-tokens.json`.
+- Ein temporaerer Mailfehler vernichtet keine Anfrage.
+- Ein Token kann nicht zwei Stakeholder-Mails oder zwei Newsletter-Eintraege
+  erzeugen.
+- Tests enthalten nur synthetische Daten.
+
+### 5.2 SMTP-Konfiguration und Fehlerverhalten haerten
+
+Betroffene Dateien:
+
+```text
+server/services/mailer.js
+server/index.js
+server/routes/contact.js
+server/routes/talk-request.js
+server/routes/newsletter.js
+server/routes/speaker-cv.js
+```
+
+Umsetzung:
+
+1. Produktionsbetrieb ohne notwendige SMTP-Konfiguration nicht stillschweigend
+   als erfolgreichen Versand behandeln.
+2. Konfigurationspruefung beim Serverstart oder einen eindeutigen
+   `mailerReady`-Status einfuehren.
+3. Healthcheck so erweitern, dass die Mail-Konfiguration ohne Ausgabe von
+   Secrets als bereit/nicht bereit erkennbar ist.
+4. Nutzerfreundliche Fehlerantwort liefern, wenn kein Versand moeglich ist.
+5. Serverlogs auf technische IDs und Fehlertypen begrenzen.
+6. Speaker-CV-Lead nur gemaess klarer Reihenfolge speichern und versenden;
+   Wiederholungen duerfen keine unkontrollierten Duplikate erzeugen.
+
+Vorgesehene Tests:
+
+- Unit: Mailer meldet fehlende Konfiguration als nicht bereit.
+- Unit: Keine SMTP-Zugangsdaten erscheinen in Fehlern oder Logs.
+- Integration: Route liefert bei fehlendem Mailer keinen falschen Erfolg.
+- Integration: SMTP-Fehler wird mit passendem HTTP-Status behandelt.
+- Integration: Erfolgsfall bleibt unveraendert.
+- Integration Speaker CV: Fehlendes PDF und Mailfehler werden getrennt
+  behandelt.
+
+Akzeptanzkriterien:
+
+- Keine UI-Erfolgsmeldung, wenn nachweislich keine Mail ausgeloest werden konnte.
+- Healthcheck offenbart keine Secrets.
+- Bestehender erfolgreicher Produktionsflow bleibt kompatibel.
+
+### 5.3 Datenschutztext mit Implementierung synchronisieren
+
+Betroffene Datei:
+
+```text
+src/pages/Datenschutz.jsx
+```
+
+Umsetzung:
+
+1. Erst nach Festlegung und Implementierung der Speicherfristen anpassen.
+2. Kontakt, Vortragsanfrage, Newsletter, Ressourcen und Speaker CV getrennt
+   beschreiben.
+3. Aufbewahrungsdauer beziehungsweise Loeschkriterium konkret benennen.
+4. Widerrufs- oder Abmeldeweg fuer Newsletter eindeutig nennen.
+5. Keine rechtlichen Behauptungen erfinden; bei fachlicher Unsicherheit Text
+   als pruefbeduerftig kennzeichnen und den Benutzer um Freigabe bitten.
+
+Vorgesehene Tests:
+
+- Browser: Datenschutzseite bei Desktop und Mobile ohne Layoutfehler.
+- Content-Review: Jede Aussage entspricht dem implementierten Datenfluss.
+- Linktest: Alle genannten Mailadressen und internen Links sind korrekt.
+
+## 6. Prioritaet 2: Mobile Nutzbarkeit und Ressourcen
+
+Branch-Vorschlag:
+
+```text
+fix/andreknie-mobile-navigation
+```
+
+### 6.1 Bottom-Dock mobil korrigieren
+
+Betroffene Dateien:
+
+```text
+src/components/BottomDock.jsx
+src/components/BottomDock.css
+src/index.css
+src/pages/Home.css
+```
+
+Umsetzung:
+
+1. Mobile Informationsarchitektur festlegen:
+   - bevorzugt weniger primaere Dock-Eintraege plus Menue, oder
+   - ein horizontal scrollbares Dock mit klarer Bedienbarkeit.
+2. Dock-Hoehe als CSS-Variable definieren.
+3. Global ausreichend unteren Inhaltsabstand reservieren.
+4. `env(safe-area-inset-bottom)` beruecksichtigen.
+5. Touch-Ziele mindestens 44 x 44 CSS-Pixel gross halten.
+6. Primaere Hero-CTAs duerfen zu keinem Zeitpunkt vom Dock verdeckt werden.
+7. Footer, Kontaktformular, About-Profil und lange Detailseiten pruefen.
+8. Desktop-Dock nicht unbeabsichtigt veraendern.
+
+Vorgesehene Tests:
+
+- Browser 375 x 844: Hero-Buttons vollstaendig sichtbar und klickbar.
+- Browser 390 x 844: Kein Text oder Formularfeld durch Dock verdeckt.
+- Browser 430 x 932: Safe-Area und Footer funktionieren.
+- Browser 1440 x 900: Desktop-Dock unveraendert.
+- DOM-Messung: Dock liegt innerhalb des Viewports.
+- DOM-Messung: Dokument besitzt keinen horizontalen Overflow.
+- Tastatur: Jeder sichtbare Dock-Eintrag ist erreichbar.
+- Screenshot-Vergleich fuer Home, About, Contact und Article Detail.
+
+Akzeptanzkriterien:
+
+- Kein Dock-Overlay auf CTAs, Formularen oder Footer-Inhalten.
+- Kein horizontaler Seitenoverflow.
+- Mobile Touch-Ziele bleiben ergonomisch.
+
+### 6.2 Ressourcen-Flow entscheiden und umsetzen
+
+Betroffene Dateien:
+
+```text
+src/pages/Resources.jsx
+src/hooks/useFormSubmit.js
+src/utils/validation.js
+server/routes/resource-download.js
+content/resources/*
+src/pages/Datenschutz.jsx
+```
+
+Vor Implementierung Benutzerentscheidung einholen:
+
+- Variante A: Freier direkter Download ohne Lead-Erfassung.
+- Variante B: Download nach erfolgreicher Lead-Erfassung.
+- Variante C: Ressourcen-Seite bis zur Befuellung ausblenden.
+
+Fuer Variante B:
+
+1. Formular mit Name, E-Mail, Unternehmen, Resource-ID und Honeypot erstellen.
+2. Vorhandene Validierung verwenden statt duplizieren.
+3. API-Antwort auswerten und nur die serverseitig gelieferte Download-URL
+   verwenden.
+4. Lade-, Validierungs-, Fehler- und Erfolgszustand implementieren.
+5. Resource-ID serverseitig gegen eine Allowlist vorhandener Ressourcen
+   validieren, nicht nur gegen ein Zeichenmuster.
+6. Datenschutztext und Speicherfristen anpassen.
+
+Vorgesehene Tests:
+
+- Unit: Client- und Servervalidierung fuer alle Pflichtfelder.
+- Unit: Unbekannte Resource-ID wird abgelehnt.
+- Integration: Gueltige Anfrage liefert erwartete lokale Download-URL.
+- Integration: Honeypot erzeugt keine Lead-Datei.
+- Integration: Fehler beim Speichern liefert keinen Download-Erfolg.
+- Browser: Download-Button besitzt eine echte Funktion.
+- Browser: Fehler- und Ladezustand sind sichtbar und zugaenglich.
+- Security: Keine Pfadmanipulation ueber Resource-ID.
+
+Akzeptanzkriterien:
+
+- Kein sichtbarer Button ohne Funktion.
+- Download und Datenschutzerklaerung entsprechen derselben gewaehlten Variante.
+
+## 7. Prioritaet 3: SEO und Dokumentstruktur
+
+Branch-Vorschlag:
+
+```text
+fix/andreknie-seo
+```
+
+### 7.1 SEOHead normalisieren
+
+Betroffene Dateien:
+
+```text
+index.html
+src/components/SEOHead.jsx
+src/pages/*.jsx
+public/images/*
+```
+
+Umsetzung:
+
+1. API von `SEOHead` eindeutig machen: `title` ist immer ohne Brand-Suffix.
+2. Brand-Suffix zentral genau einmal hinzufuegen.
+3. Statische Metadaten in `index.html` als kompatiblen Fallback gestalten,
+   sodass React Helmet keine konkurrierenden doppelten Tags erzeugt.
+4. Canonical-Link ergaenzen.
+5. Open-Graph- und Twitter-Metadaten vervollstaendigen.
+6. Ein tatsaechlich vorhandenes OG-Bild bereitstellen.
+7. Jede Route mit individuellem Titel, Description und Canonical versehen.
+8. Artikel und Kniepunkte aus ihren Content-Metadaten versorgen.
+9. 404-Seite mit `noindex,follow` auszeichnen.
+
+Vorgesehene Tests:
+
+- Unit fuer `SEOHead`: Brand erscheint genau einmal.
+- Unit: Relative und absolute Bild-URLs werden korrekt behandelt.
+- Browser je Route: genau ein aktiver Titel.
+- Browser je Route: genau eine Description.
+- Browser je Route: genau ein Canonical-Link.
+- Browser Artikel: Titel und Description stammen aus dem Artikel.
+- Browser Kniepunkt: Titel, Description, URL und Bild stimmen mit der Ausgabe
+  ueberein.
+- Asset-Test: OG-Bild liefert lokal und live HTTP 200.
+- Build: Keine Helmet- oder React-Warnungen.
+
+Akzeptanzkriterien:
+
+- Kein Titel enthaelt `Dr. Andre Knie` doppelt.
+- Keine konkurrierenden Description-Tags.
+- Alle 15 Routen haben passende Metadaten.
+
+### 7.2 Ueberschriften und Landmarks korrigieren
+
+Betroffene Dateien:
+
+```text
+src/pages/Articles.jsx
+src/pages/ArticleSingle.jsx
+src/pages/KniepunktIssue.jsx
+plugins/vite-plugin-content.js
+content/kniepunkt/*
+```
+
+Umsetzung:
+
+1. Artikeluebersicht und Artikeldetail mit einem `main`-Landmark versehen.
+2. Kniepunkt-Titel nur einmal als `h1` rendern.
+3. Bevorzugt Markdown-Content beim Build normalisieren oder den ersten
+   redundanten H1 kontrolliert entfernen.
+4. Keine pauschale Regex-Manipulation verwenden, wenn ein Markdown-AST oder
+   `marked`-Hook die Struktur sicherer bearbeiten kann.
+5. Ueberschriftenhierarchie in allen Detailseiten pruefen.
+
+Vorgesehene Tests:
+
+- Browser: Jede Route besitzt genau ein `main`.
+- Browser: Jede normale Seite besitzt genau ein `h1`.
+- Unit Content-Plugin: Markdown mit und ohne initiales H1 wird korrekt gerendert.
+- Regression: Bestehende Artikelkoerper verlieren keine Inhalte.
+
+## 8. Prioritaet 4: Barrierefreiheit
+
+Branch-Vorschlag:
+
+```text
+fix/andreknie-accessibility
+```
+
+### 8.1 Navigation und Formulare
+
+Betroffene Dateien:
+
+```text
+src/components/Navigation.jsx
+src/components/BottomDock.jsx
+src/pages/Contact.jsx
+src/components/NewsletterSignup.jsx
+src/components/SpeakerCvRequest.jsx
+```
+
+Umsetzung:
+
+1. Jedem Dock-Link einen zugreifbaren Namen geben.
+2. Aktive Route mit `aria-current="page"` markieren, auch auf Detailrouten.
+3. Hamburger um `aria-expanded` und `aria-controls` ergaenzen.
+4. Label zwischen `Menue oeffnen` und `Menue schliessen` wechseln.
+5. Menue per Escape schliessbar machen.
+6. Formularlabels mit eindeutigen `id`/`htmlFor` verbinden.
+7. Fehlertexte mit `aria-describedby` verknuepfen.
+8. Serverfehler und Erfolgsmeldungen ueber `aria-live` bekanntgeben.
+9. Honeypots mit `hidden` oder einer gleichwertigen robusten Loesung vollstaendig
+   aus Accessibility- und Tab-Reihenfolge entfernen.
+10. Sichtbare Fokusdarstellung fuer Suchfelder und Buttons sicherstellen.
+
+Vorgesehene Tests:
+
+- Component-Test Navigation: `aria-expanded` folgt dem Menuezustand.
+- Component-Test Navigation: Escape schliesst das Menue.
+- Component-Test BottomDock: Jeder Link hat einen Namen.
+- Component-Test Forms: Labels sind programmatisch zugeordnet.
+- Component-Test Forms: Fehler referenzieren das richtige Feld.
+- Tastaturtest: Komplette Navigation ohne Maus.
+- Browser-Snapshot: Honeypot erscheint nicht im Accessibility-Baum.
+- Browser-Snapshot: Dock-Links besitzen eindeutige Namen.
+
+### 8.2 Testimonials und Logos
+
+Betroffene Dateien:
+
+```text
+src/components/TestimonialSlider.jsx
+src/components/TestimonialSlider.css
+src/components/LogoMarquee.jsx
+src/components/LogoMarquee.css
+```
+
+Umsetzung:
+
+1. Nur einen logischen Satz Testimonials fuer Assistenztechnologien exponieren.
+2. Technische Loop-Kopien mit `aria-hidden="true"` ausblenden.
+3. Sichtbaren aktiven Eintrag beziehungsweise Carousel-Position semantisch
+   bekanntgeben.
+4. Pfeile und Scrollbereich per Tastatur bedienbar machen.
+5. Logo-Duplikate fuer Screenreader ausblenden.
+6. Animationen bei Fokus/Hover pausierbar machen.
+7. Bestehendes visuelles Endlosverhalten und Zentrierung erhalten.
+
+Vorgesehene Tests:
+
+- Component-Test: Bei drei Testimonials werden fuer Screenreader nur drei
+  logische Inhalte exponiert.
+- Browser-Snapshot: Keine 27 vorgelesenen Testimonials.
+- Browser-Snapshot: Keine dreifach vorgelesenen Logos.
+- Desktop: zehnmal rechts und zehnmal links ohne sichtbaren Sprung.
+- Mobile: Swipe bleibt funktionsfaehig.
+- Tastatur: Vor/zurueck funktioniert und Fokus bleibt sichtbar.
+
+### 8.3 Reduced Motion und Canvas-Lebenszyklus
+
+Betroffene Dateien:
+
+```text
+src/index.css
+src/pages/Home.css
+src/components/BottomDock.css
+src/components/LogoMarquee.css
+src/components/StatsCube.css
+src/components/BackgroundPattern.jsx
+src/components/DotCloudIcon.jsx
+```
+
+Umsetzung:
+
+1. Zentrale `prefers-reduced-motion: reduce`-Regeln ergaenzen.
+2. Endlos-CSS-Animationen stoppen oder auf einen statischen Zustand setzen.
+3. Canvas-Animationen bei Reduce Motion nicht starten.
+4. Canvas-Animationen pausieren, wenn der Tab verborgen ist.
+5. Optional Intersection Observer verwenden, damit nicht sichtbare Canvas-
+   Komponenten keine Frames berechnen.
+6. `getComputedStyle` nicht in jedem Animationsframe erneut lesen.
+7. Debug-Logs aus `DotCloudIcon` entfernen.
+
+Vorgesehene Tests:
+
+- Browser mit Reduce Motion: keine Endlosanimationen.
+- Browser normal: Design und Interaktion bleiben erhalten.
+- Component-Test: `requestAnimationFrame` wird beim Unmount abgebrochen.
+- Component-Test: Reduce Motion startet keinen Animationsloop.
+- Console-Test: Keine DotCloud-Debugausgaben.
+
+## 9. Prioritaet 5: Performance, Dependencies und Deployment
+
+Branch-Vorschlag:
+
+```text
+perf/andreknie-initial-load
+```
+
+### 9.1 Initialen Bundle verkleinern
+
+Betroffene Dateien:
+
+```text
+src/App.jsx
+src/hooks/useContent.js
+plugins/vite-plugin-content.js
+vite.config.js
+```
+
+Umsetzung in zwei getrennten Schritten:
+
+1. Routen mit `React.lazy` und `Suspense` code-splitten.
+2. Danach Content-Auslieferung umbauen:
+   - Listenmetadaten von vollstaendigen HTML-Bodies trennen.
+   - Detailinhalte nur fuer die aufgerufene Detailseite laden.
+   - Build-Zeit-Generierung beibehalten; kein unnoetiges neues CMS einfuehren.
+3. Einen stabilen Ladezustand ohne Layoutsprung bereitstellen.
+4. Chunk-Grenzwert als CI-Pruefung dokumentieren.
+
+Vorgesehene Tests:
+
+- Build: mehrere Route-Chunks statt eines einzigen App-Chunks.
+- Bundle-Messung vor/nachher dokumentieren.
+- Zielwert initiales JS: deutlich unter dem aktuellen Build von ca. 805 KB
+  unkomprimiert.
+- Browser: Direktaufruf jeder Route funktioniert.
+- Browser: Reload einer Detailroute funktioniert hinter Caddy-Fallback.
+- Browser: Keine leeren Seiten waehrend Lazy Loading.
+- Regression: Alle 62 Artikel, 48 Kniepunkte und 19 Podcast-Eintraege bleiben
+  erreichbar.
+
+### 9.2 Dependency-Findings bearbeiten
+
+Betroffene Dateien:
+
+```text
+package.json
+package-lock.json
+```
+
+Umsetzung:
+
+1. `npm audit --omit=dev` erneut ausfuehren.
+2. React-Router-Advisory auf Anwendbarkeit pruefen.
+3. Keine automatische Downgrade-Empfehlung ungeprueft anwenden.
+4. Auf eine nachweislich gefixte kompatible Version aktualisieren.
+5. Router-Verhalten aller Routen testen.
+6. Audit als CI-Schritt einbauen, wenn das Repository dies ohne instabile
+   Netzwerkfehler erlaubt.
+
+Vorgesehene Tests:
+
+- `npm audit --omit=dev`
+- Build und Source-Lint.
+- Direktnavigation und Client-Navigation aller Routen.
+- Browser Back/Forward.
+- 404 und Detailrouten.
+
+### 9.3 Deployment-Artefakte bereinigen
+
+Betroffene Datei:
+
+```text
+.gitea/workflows/deploy.yml
+```
+
+Aktuelles Problem:
+
+- Neue `dist/assets` werden nach `site/assets` kopiert.
+- Alte gehashte Dateien werden nicht entfernt.
+- Aktueller Bestand beim Review: 29 Dateien, ca. 28.5 MB.
+
+Umsetzung:
+
+1. Neues Build zuerst in ein separates Release-Verzeichnis kopieren.
+2. Vollstaendigkeit des Releases pruefen.
+3. `site` atomar oder kontrolliert auf den neuen Stand umschalten.
+4. Rollback ueber ein klar begrenztes vorheriges Release ermoeglichen.
+5. Nicht mit einer ungesicherten rekursiven Loeschung auf einem berechneten
+   Pfad arbeiten.
+6. Caddy-Konfiguration und Umami-Dateien nicht versehentlich entfernen.
+7. Alte Releases nach einer definierten Anzahl kontrolliert bereinigen.
+
+Vorgesehene Tests:
+
+- Workflow-Test auf Feature-Branch ohne Produktionsumschaltung, falls
+  Infrastruktur dies unterstuetzt.
+- Build-Artefakt enthaelt `index.html`, aktuelle JS-/CSS-Dateien und Assets.
+- Keine Referenz in `index.html` zeigt auf eine geloeschte Datei.
+- Rollback-Test auf das unmittelbar vorherige Release.
+- Nach Deployment: Startseite und eine Detailroute liefern HTTP 200.
+- Live: HTML referenziert genau den neuen Bundle-Hash.
+- Live: Umami-Script und CSP bleiben erhalten.
+
+## 10. Abschluss-Quality-Gates je Paket
+
+Pflicht:
+
+```powershell
+& 'C:\Users\knie\.cache\codex-runtimes\codex-primary-runtime\dependencies\bin\fallback\pnpm.cmd' run build
+& 'C:\Users\knie\.cache\codex-runtimes\codex-primary-runtime\dependencies\bin\fallback\pnpm.cmd' run test
+.\node_modules\.bin\eslint.CMD src server plugins vite.config.js
+git diff --check
+git status --short
+```
+
+Zusaetzlich je nach Paket:
+
+- Backend: Integrations-Tests der betroffenen Routes.
+- UI: Desktop- und Mobile-Browserpruefung.
+- Accessibility: DOM-/Accessibility-Snapshot und Tastaturpruefung.
+- SEO: Anzahl und Inhalt aller Head-Tags kontrollieren.
+- Performance: Buildgroessen vor/nachher festhalten.
+- Deployment: Gitea-Run und Live-Bundle verifizieren.
+
+Ein Paket ist erst fertig, wenn:
+
+- alle vorgesehenen Tests gruen sind,
+- keine unerklaerten Warnungen neu hinzugekommen sind,
+- der Diff auf das Paket begrenzt ist,
+- PR/MR erstellt und geprueft wurde,
+- bei beauftragtem Deployment der Gitea-Run erfolgreich ist,
+- die konkrete Aenderung live verifiziert wurde.
+
+## 11. Empfohlene Paket-Reihenfolge
+
+1. Datenschutz und Ausfallsicherheit
+2. Mobiles Bottom-Dock
+3. SEO und Dokumentstruktur
+4. Barrierefreiheit
+5. Ressourcen-Flow nach Benutzerentscheidung
+6. Performance und Dependencies
+7. Deployment-Artefakte
+
+Die Pakete 1 und 2 haben den groessten unmittelbaren Nutzen. SEO und
+Barrierefreiheit koennen danach unabhaengig bearbeitet werden. Die
+Content-/Bundle-Architektur sollte erst angefasst werden, wenn die funktionalen
+Flows stabil und ausreichend getestet sind.
+
+## 12. Startprompt fuer einen neuen Codex-Chat
+
+Der Benutzer ersetzt `<ARBEITSPAKET>` durch genau eines der oben beschriebenen
+Pakete.
+
+```text
+Arbeite im Orchestrator-Monorepo unter C:\Coding\Orchestrator an andreknie.de.
+Die Source of Truth ist ausschliesslich
+C:\Coding\Orchestrator\privat\CV\andreknie.de. Verwende nicht das alte
+GitHub-Repository und keine separate Clone-Kopie.
+
+Lies zuerst vollstaendig:
+- C:\Coding\Orchestrator\AGENTS.md
+- C:\Coding\Orchestrator\.agents\AGENTS.md
+- die relevanten Dateien unter C:\Coding\Orchestrator\.kiro\steering\
+- C:\Coding\Orchestrator\privat\CV\andreknie.de\README.md
+- C:\Coding\Orchestrator\privat\CV\andreknie.de\DEPLOYMENT-PLAN.md
+- C:\Coding\Orchestrator\privat\CV\andreknie.de\.gitea\workflows\deploy.yml
+- C:\Coding\Orchestrator\privat\CV\andreknie.de\FINDINGS-REMEDIATION-PLAN.md
+
+Setze ausschliesslich dieses Arbeitspaket aus dem Plan um:
+<ARBEITSPAKET>
+
+Vorgehen:
+1. Verifiziere den aktuellen Stand und das Finding.
+2. Erstelle einen Feature-Branch nach den Repository-Regeln.
+3. Implementiere nur den Scope des ausgewaehlten Pakets.
+4. Fuehre alle im Plan vorgesehenen Tests sowie Build, Tests und gezielten
+   Source-Lint aus.
+5. Pruefe Desktop und Mobile, sofern UI betroffen ist.
+6. Zeige mir danach Findings, Aenderungen, Testergebnisse und verbleibende
+   Risiken.
+7. Nutze Gitea und die dokumentierte Hub-and-Spoke-Foederation. Nicht direkt
+   auf master/main pushen.
+8. Erstelle einen PR/MR, aber merge und deploye erst, wenn ich das in diesem
+   Chat ausdruecklich freigebe.
+
+Schuetze personenbezogene Daten und Secrets. Sende keine echten Formulare in
+der Live-Umgebung ab. Erfinde keine Deployment- oder Federationsschritte,
+sondern halte dich an die vorhandenen Anleitungen.
+```