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

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:

C:\Coding\Orchestrator

Component:

C:\Coding\Orchestrator\privat\CV\andreknie.de

Hub:

https://git.d-hive.de/ankn/Orchestrator.git

Foederiertes Spoke-Repository:

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:

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:

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:

& '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:

fix/andreknie-data-lifecycle

5.1 Token-Lebenszyklus korrigieren

Betroffene Dateien:

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:

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:

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:

fix/andreknie-mobile-navigation

6.1 Bottom-Dock mobil korrigieren

Betroffene Dateien:

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:

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:

fix/andreknie-seo

7.1 SEOHead normalisieren

Betroffene Dateien:

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:

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:

fix/andreknie-accessibility

8.1 Navigation und Formulare

Betroffene Dateien:

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:

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:

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:

perf/andreknie-initial-load

9.1 Initialen Bundle verkleinern

Betroffene Dateien:

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:

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:

.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:

& '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.

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.