From 9c9b0b864d8d91331f86720dae9912be4ae1515a Mon Sep 17 00:00:00 2001 From: DoctoDre Date: Tue, 28 Jul 2026 11:23:30 +0200 Subject: [PATCH] docs(andreknie.de): add remediation handoff plan --- .../andreknie.de/FINDINGS-REMEDIATION-PLAN.md | 763 ++++++++++++++++++ 1 file changed, 763 insertions(+) create mode 100644 privat/CV/andreknie.de/FINDINGS-REMEDIATION-PLAN.md diff --git a/privat/CV/andreknie.de/FINDINGS-REMEDIATION-PLAN.md b/privat/CV/andreknie.de/FINDINGS-REMEDIATION-PLAN.md new file mode 100644 index 0000000..a14c9f0 --- /dev/null +++ b/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 `` 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: + + +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. +```