# Allgemeiner Weiterarbeitsprompt für große Projektpakete

Ich arbeite mit dem aktuell hochgeladenen Gesamtpaket weiter.

## Verbindliche Arbeitsweise

- Verwende ausschließlich das hochgeladene Gesamtpaket als technische und dokumentarische Quelle.
- Bestehende Inhalte, Funktionen, Verzeichnisse und Nachweise dürfen nicht stillschweigend entfernt, gekürzt oder durch vereinfachte Platzhalter ersetzt werden.
- Prüfe vor Änderungen zuerst Struktur, aktuelle Produktbezeichnung, vorhandene Funktionen, zentrale Navigation, Dokumentation, Prüfberichte und bereits bekannte Einschränkungen.
- Konsolidiere statt zu duplizieren. Keine Dateinamen wie `final_neu`, `fix_v2`, `neu_final` oder parallele Chronikdateien erzeugen.
- Chronologische Dokumente werden pro Dokumenttyp in genau einer fortlaufenden Datei gepflegt. Neue Einträge stehen oben, ältere bleiben darunter erhalten.
- Markdown ist die interne Quelle. Sichtbare HTML-Seiten dürfen interne Markdown-Dateien, Run-Nummern, Bauphasen, Fortschrittszähler oder andere Projektsteuerungsinformationen weder verlinken noch als Inhalt anzeigen.
- Bei größeren Änderungen Inhalte parallel als saubere Markdown-Quellen weiterführen, ohne Zwischenstände unnötig im Chat auszugeben.
- Für Java-/Maven-Projekte verwendete Entwurfsmuster im Code kurz kommentieren und zusätzlich in `docs/design-patterns.md` mit Pattern, Zweck, Einsatzort und Begründung dokumentieren.

## HTML- und UX-Standard

- Alle sichtbaren HTML-Seiten müssen wie eine zusammenhängende Anwendung wirken, nicht wie lose Dokumentseiten.
- Bestehendes zentrales Designsystem wiederverwenden und nur gezielt erweitern.
- Desktop, iPhone, iPad und Safari berücksichtigen.
- Hell-/Dunkelmodus, Tastaturfokus, mobile Navigation, Tabellen, Dialoge, leere Zustände, Fehlerzustände und reduzierte Bewegung konsistent halten.
- Codeblöcke verwenden durchgängig JetBrains Dark, farbiges Syntax-Highlighting, Copy-Funktion und horizontales Scrollen.
- Keine externen CDN-, Font- oder Laufzeitabhängigkeiten einführen, sofern dies nicht ausdrücklich verlangt wird.
- Keine Emojis oder uneinheitlichen Symbolzeichen in der Hauptnavigation; ein lokales SVG-Icon-System verwenden.

## Qualitäts- und Nachweispflichten

Nach jeder größeren Änderung mindestens prüfen:

1. interne Links und lokale Ressourcen,
2. JavaScript-Syntax,
3. JSON-, YAML- und XML/POM-Gültigkeit,
4. Java-Kompilierung beziehungsweise Maven-Build, soweit die Umgebung dies erlaubt,
5. Offline-Fähigkeit,
6. HTML-Struktur, doppelte IDs und Accessibility-Basis,
7. ZIP-Integrität,
8. Dateiinventar und SHA-256-Checksummen.

Nicht ausführbare Prüfungen niemals als bestanden ausweisen. Einschränkungen, fehlende Werkzeuge und offene externe Nachweise transparent dokumentieren.

## Abschlussausgabe

Am Ende immer:

- ein sauberes finales ZIP ohne unnötige Zwischenversionen,
- aktualisierte `README.md`, `lernweg.html`, `WAS_WURDE_GEMACHT.md/html`,
- aktuelle Prüfberichte, Inventar und Checksummen,
- kurze Zusammenfassung der Änderungen,
- ZIP-Größe,
- klare Öffnungsreihenfolge.