# Qualitätsbericht – erster ausführbarer Prototyp

## Ergänzung: Breite, Menüs, Seiten ohne Kopfbereich, 12.09.2026

- **336 PHP-Tests / 1354 Assertions** unter PHP 8.2.12 und 8.4.22, 17 JavaScript-Modelltests, Playwright-Editortest, öffentliche Browserprüfung.
- **Ein bestehender Test ist absichtlich umgeschrieben worden**, und das ist erwähnenswert: er sicherte zu, dass ein zweiter Kopfbereich abgewiesen wird. Diese Regel war richtig, solange keine Seite wählen konnte, und wurde falsch, sobald sie es kann. Der Test prüft jetzt die neue Regel – mehrere Bereiche mit eigener Adresse, doppelte Adresse weiter abgewiesen, Standardbereich nicht löschbar.
- **Der dritte Fehler des Tages aus derselben Familie:** die globale Seitenbreite ließ sich im Designbereich einstellen, aber `site.css` deckelte bei 1180 px. Schmaler wirkte, breiter nicht. Wie bei der Rahmenstärke und der Bildrundung: eine Einstellung, die sich speichern lässt und nichts tut, ohne jede Fehlermeldung. Ein Test liest jetzt die Regel aus `site.css` und prüft, dass sie den Theme-Wert nimmt.
- Seitenbereiche sind über echte Auslieferung geprüft: mit „keiner“ steht weder `site-header` noch `site-footer` im HTML, der Seiteninhalt aber schon; ein Verweis auf einen gelöschten Bereich fällt auf den Standard zurück.
- **Nicht geprüft:** der Burger ist nicht auf einem Touchgerät bedient worden, und kein Screenreader war beteiligt. Die vier Menüplätze sind im Test benutzt, aber nicht alle vier von Hand in der Menüverwaltung durchgeklickt.

## Ergänzung: Designer ausgebaut, 12.09.2026

- **315 PHP-Tests / 1309 Assertions** unter PHP 8.2.12 und 8.4.22, 16 JavaScript-Modelltests, Playwright-Editortest (axe auf dreizehn Bildschirmen, null Verstöße), öffentliche Browserprüfung.
- Die Gestaltungseigenschaften sind nicht „vorhanden“, sondern einzeln nachgerechnet: 16 Datensätze vergleichen die erzeugte Deklaration Zeichen für Zeichen mit der erwarteten. Das ist die Prüfung, die die beiden Fehler unten gefunden hätte, wenn es sie vorher gegeben hätte.
- **Zwei Fehler, die vorher niemand gesehen hat.** Erstens: eine Rahmenstärke je Seite wurde zu `border-width-top`. Das ist kein CSS, der Browser verwirft die Zeile stillschweigend – Rahmenstärken je Seite hatten **nie** eine Wirkung, und es gab keine Fehlermeldung, die darauf hingewiesen hätte. Zweitens: eine Rundung auf einem Bildblock landete auf dem `figure`, das Bild darin blieb eckig. Beides ist genau das, wonach Umut gefragt hat – er hat zwei echte Defekte gefunden, indem er die Funktion benutzen wollte.
- Ein Test hält das Schema und das Editorpanel zusammen: jede Gruppe im Schema muss im Panel einen Namen haben, sonst landen ihre Eigenschaften in einem unbenannten Aufklappfeld.
- Die drei neuen Bausteine sind über echte Seitenauslieferung geprüft, nicht nur über den Validator: Markup, Rollen, Klassen – und dass die Seite weiterhin `script-src 'none'` sendet, denn keiner von ihnen braucht ein Skript.
- **Nicht geprüft:** kein Screenreader. Der Slider ist nicht mit Touch auf einem echten Gerät bedient worden, nur mit Tastatur und Mausrad im Browser. Und der Vergleich mit Flatsome ist Wissen, keine Messung – die Erweiterung war nicht installierbar, das steht so im Vergleichsdokument.

## Ergänzung: Updater, 12.09.2026

- **285 PHP-Tests / 1244 Assertions** unter PHP 8.2.12 und 8.4.22, Playwright-Editortest (axe auf dreizehn Bildschirmen, null Verstöße), öffentliche Browserprüfung.
- Sechs Tests fahren den Updater gegen **echte Git-Repositorys** in einem Temp-Verzeichnis: ein bares Repository als Herkunft, ein Autorenklon, ein Installationsklon. Die zwei Befehle, die der Updater aufruft, sind dort Platzhalterskripte – so wird die Reihenfolge und der Rückweg mit echtem Git und echten Dateikopien geprüft, ohne zwei Minuten Composer.
- Der wichtigste davon ist der Fehlschlag: die neue Fassung bringt ein Migrationsskript, das mit Exitcode 1 endet. Geprüft wird danach, dass der Code auf dem alten Commit steht, die Datenbank den Inhalt von vor dem Update enthält, der Wartungszustand aufgehoben ist (weil der alte Stand antwortet) und im Protokoll `FEHLER` steht.
- Die Reihenfolge der Schritte ist als Liste festgehalten, nicht nur ihr Ergebnis: Vorprüfung, Ziel, Sicherung, Wartung, Checkout, Fassung prüfen, Abhängigkeiten, Migration, Cache, Rauchtest, Fertig. Wer sie umstellt, bricht den Test.
- Geprüft ist außerdem, dass die Sicherung vor dem Checkout entsteht, dass sie die Datenbank enthält und den Medienordner **nicht**, und dass Datenbank und Medienordner der Installation unverändert bleiben.
- **Am echten Repository durchgespielt**, nicht nur im Test: `git.kant-it.de/kantarci/KantSites`, Tag `v1.0.0` gesetzt, die Entwicklungsinstallation darauf gestellt (`git checkout v1.0.0`), `v1.0.1` veröffentlicht und `php bin/console cms:update` ausgeführt. Ergebnis: elf Schritte, alle ok, in dieser Reihenfolge – Vorprüfung, Ziel (v1.0.1 von 52f0ab38, Fassung 1.0.0), Sicherung (220 KB nach `var/backups/update-20260912-181159`, darin `cms.db`, `.env`, `.env.local`, kein Medienordner), Wartungszustand, Checkout, Fassung geprüft, Abhängigkeiten (Composer fehlt, vendor/ bleibt liegen), Migration („Already at the latest version“), Cache, Rauchtest („Datenbank erreichbar, Migration 20260912001200, Startseite /home lesbar, Fassung 1.0.1“), fertig. Danach: `VERSION` 1.0.1, `git describe` v1.0.1, kein Wartungszustand, `/` antwortet 200, `var/updates.log` enthält `OK v1.0.1 (11 Schritte)`.
- Der Wartungszustand ist danach einzeln geprüft: eingeschaltet antwortet `/` mit **503 und `Retry-After: 600`** und der Wartungsseite, `/admin/login` mit 200; ausgeschaltet wieder 200.
- **Nicht geprüft:** MySQL (dafür fehlt die Installation, siehe `docs/UPDATE.md`, „Was anders wurde“), ein Hosting ohne `proc_open` (die Vorprüfung meldet es, der Fall selbst ist nicht durchgespielt), und ein Update über die Weboberfläche unter einem knappen Zeitlimit.

## Ergänzung: Statistik, 12.09.2026

- **279 PHP-Tests / 1119 Assertions** unter PHP 8.2.12 und PHP 8.4.22, Playwright-Editortest (axe auf jetzt zwölf Bildschirmen, null Verstöße), öffentliche Browserprüfung.
- Der wichtigste Test ist der langweiligste: er liest die Spaltenliste von `stat_hit` und vergleicht sie mit der Zusage. Es gibt keine Spalte für IP-Adresse, Kennung, Sitzung, Cookie oder Hash – und wenn jemand später eine hinzufügt, bricht dieser Test, nicht erst eine Datenschutzprüfung.
- 14 Anfragearten sind abgedeckt: Verwaltung, Bild, Stylesheet, Feed, Einwilligungsseite, Weiterleitung, Formularabsendung, Googlebot, Überwachungsdienst, Headless-Chrome und curl werden nicht gezählt; eine Seite und ein 404 werden gezählt, auch ohne Kennung.
- Durch echte Anfragen über den Kernel geprüft: fünf Aufrufe derselben Seite in derselben Stunde werden **ein** Zähler mit dem Wert 5. Dafür musste der Testaufruf `kernel.terminate` auslösen – ohne das hätte der Test eine andere Anwendung geprüft als die, die läuft.
- Der Bildschirm ist im Browser mit echten Zahlen angesehen worden (sechs Aufrufe, ein Verweis von Google, ein 404), und der CSV-Export ist im Test abgeholt und auf seinen Inhalt geprüft.
- **PHP 8.4 hat dabei eine Verwarnung ausgesprochen**, die der Testlauf sichtbar machte: `fputcsv()` ohne ausdrücklichen Escape-Parameter. Jetzt ausdrücklich leer, was ein CSV-Leser erwartet.
- **Nicht geprüft:** kein Screenreader. Die Aufbewahrung ist mit gestellten Daten geprüft, nicht über echte 425 Tage. Ob die Maschinenerkennung in der Praxis trifft, lässt sich erst am Piloten sehen – deshalb heißt die Zahl auf dem Bildschirm nicht „Besucher“.

## Ergänzung: Einwilligung, Pflichtseiten und ein Layoutfehler im Kopfbereich, 12.09.2026

- **245 PHP-Tests / 976 Assertions** unter PHP 8.2.12 und PHP 8.4.22, Playwright-Editortest, öffentliche Browserprüfung.
- Sieben Cookiezustände und zehn abgewiesene Einbettungsadressen sind abgedeckt. Der Kern der Prüfung ist nicht das Banner, sondern die Aussage „ohne Einwilligung entsteht keine Anfrage“: geprüft wird, dass weder ein iframe noch die Adresse des Anbieters im Markup steht und dass `frame-src 'none'` bleibt.
- Im Browsertest wird der Hinweis über den echten Einstellungsbildschirm eingeschaltet, dann aus einem zweiten Browserkontext ohne Verwaltungscookies geprüft: Banner da, kein iframe, Einwilligen über den Knopf des Platzhalters lädt den Inhalt, „Nur notwendige“ auf der Einwilligungsseite hält ihn wieder zurück. axe ohne Verstöße auf Banner und Einwilligungsseite.
- **Der Browsertest hat zwei echte Fehler gefunden, die ich selbst eingebaut hatte.** Erstens: meine Regel für die Textfarbe im Fußbereich schlug `.tone-ink` und setzte grauen Text auf dunklen Grund – 2,24:1. Farbe gehört in die Tonregeln, nicht in eine Chromregel. Zweitens: das fixierte Banner verdeckte den Einwilligungsknopf des Platzhalters am Seitenende, sodass Playwright ihn nicht anklicken konnte – jetzt endet die Seite oberhalb des Banners, solange die Frage offen ist. Beides wäre einem Menschen erst beim Benutzen aufgefallen.
- **Umut hat einen Fehler gefunden, den keine Prüfung gemeldet hatte:** im Kopfbereich stand die Wortmarke als Buchstabenkolonne in einem schmalen Kasten. `.site-header` war noch ein Flexcontainer aus der Zeit des handgeschriebenen Markups, und `design.css` band jede Designklasse an `#main`, wo Kopf- und Fußbereich nicht liegen. Kein Test hat es gesehen, weil kein Test das Aussehen des Kopfbereichs prüft – axe beanstandet keine 60 Pixel breite Spalte. Behoben; die Prüfung dafür bleibt das Hinsehen.
- **Nicht geprüft:** kein Screenreader. Ob eine echte Einbettung (Karte, Video, Bewertungen) nach der Einwilligung tatsächlich lädt, ist mit einer erfundenen Adresse geprüft, nicht mit einem echten Anbieter – dafür braucht es die Pilotwebsite.

## Ergänzung: Benutzerverwaltung und Mediathek, 12.09.2026

- **217 PHP-Tests / 845 Assertions** unter PHP 8.2.12 und PHP 8.4.22, davon 16 neue für die Benutzerverwaltung; Playwright-Editortest und öffentliche Browserprüfung grün.
- **axe deckt jetzt elf Bildschirme ab statt drei**: Anmeldung, Seitenübersicht, Benutzer, eigenes Konto, Mediathek, Menüs, Formulare, Bereiche, Design, Einstellungen und der Editor in Desktop und Mobil. Null Verstöße. Das war der offene Punkt aus der Umgestaltung.
- Zwei gleichzeitige Sitzungen im Test zeigen die Sperrwirkung: nach einem zurückgesetzten Passwort und nach einer geänderten Rolle ist die Sitzung des betroffenen Kontos bei der nächsten Anfrage abgemeldet, die des handelnden Administrators nicht. Beim eigenen Passwortwechsel bleibt die wechselnde Sitzung angemeldet, die zweite nicht.
- Acht abgewiesene Kontoanlagen erreichen die Datenbank nicht, darunter ein Passwort mit Nullbyte und eines mit 73 Bytes – letzteres, weil bcrypt alles über 72 Bytes stillschweigend ignoriert und ein längeres Passwort damit kürzer wäre, als es aussieht.
- Die Migration lief mit Sicherung (`var/backups/before-users-*.db`) und erst als Probelauf gegen die Entwicklungsdatenbank: drei `ALTER TABLE ... ADD COLUMN`, kein Tabellenneubau.
- **Dabei aufgefallen:** der lokale Vorschauserver lieferte 500 für die neuen Bildschirme, weil sein Prozess einen älteren kompilierten Container hielt – `cache:clear` ohne `--env=prod` räumt den nicht ab. Kein Codefehler, aber der Grund, warum eine Änderung im Browser gegen einen frisch gestarteten Server anzusehen ist.
- Mediathek über das Formular geprüft: zwei Dateien in einem Absenden, Upload ohne Token wird abgewiesen und legt nichts an, Bildangaben mit Versionskonflikt (zweites Speichern mit derselben Version ändert nichts und meldet es), Archivfilter, und Blättern mit 26 eingesetzten Bildern – 24 auf Seite eins, neueste zuerst, `?seite=99` wird auf die letzte Seite begrenzt, und Speichern von Seite zwei kommt auf Seite zwei zurück.
- Die Ablagefläche ist zweimal geprüft: im Browsertest über das echte Dateifeld (die Auswahl erscheint im Feld und wird benannt) und von Hand mit einem echten Drop aus zwei Dateien, von denen die Nicht-Bilddatei übersprungen und gemeldet wurde. Ohne JavaScript bleibt ein gewöhnliches Dateifeld mit Beschriftung übrig; abgeschickt wird nie automatisch.
- **Nicht geprüft:** kein Screenreader; die Mediathek ist mit 2 und mit 26 Einträgen geprüft, nicht mit einer wirklich großen Bibliothek. Vom Updateverfahren ist nichts geprüft, weil nichts gebaut ist – `docs/UPDATE.md` ist ein Plan.

## Ergänzung: Verwaltung neu gestaltet, 12.09.2026

- **201 PHP-Tests / 716 Assertions** grün, Playwright-Editortest mit axe ohne Verstöße auf **Anmeldung, Seitenübersicht und Editor** (Desktop und Mobil), öffentliche Browserprüfung unverändert grün.
- Zwei Testselektoren zeigten auf Klassen, die die Umgestaltung umbenannt hat; sie prüfen jetzt dieselbe Sache über den neuen Namen. Die Klasse, an der die Rechteprüfung für das endgültige Löschen hängt, ist absichtlich geblieben.
- **Der Browsertest hat einen Fehler gefunden, den ich selbst eingebaut hatte.** Beim Zerlegen des Stylesheets schnitt mein Skript am Ende jedes `@media`-Blocks alle schließenden Klammern ab statt nur einer. Damit war `editor.css` ab dem ersten Medienblock ungültig: der Browser behielt 29 von 202 Regeln. Aufgefallen ist es an einer Vorschaubreite von 1236 statt 1240 Pixeln, weil der Standardrahmen des iframe nicht mehr entfernt wurde – vier Pixel als einziges Symptom dafür, dass dreiviertel des Editor-Stylesheets fehlte. Behoben, und die Datei wird jetzt auf ausgeglichene Klammern geprüft.
- **Nicht geprüft:** kein Screenreader. Die Bildschirme Menüs, Formulare, Bereiche, Design, Einstellungen und Fassungen habe ich im Browser angesehen und ihre Tabellen und Formulare bedient, aber die automatische Barrierefreiheitsprüfung deckt sie nicht ab – sie prüft Anmeldung, Seitenübersicht und Editor.
- Der Editor selbst behält seinen Aufbau. Er übernimmt die neuen Farben, Schaltflächen und die Systemschrift, ist aber nicht neu gestaltet worden.

## Ergänzung: Verwaltung neu gestaltet, 12.09.2026

- **201 PHP-Tests / 716 Assertions** grün, Playwright-Editortest mit axe ohne Verstöße auf **Anmeldung, Seitenübersicht und Editor** (Desktop und Mobil), öffentliche Browserprüfung unverändert grün.
- Zwei Testselektoren zeigten auf Klassen, welche die Umgestaltung umbenannt hat; sie prüfen jetzt dieselbe Sache über den neuen Namen. Die Klasse, an der die Rechteprüfung für das endgültige Löschen hängt, ist absichtlich geblieben.
- **Der Browsertest hat einen Fehler gefunden, den ich selbst eingebaut hatte.** Beim Zerlegen des Stylesheets schnitt mein Skript am Ende jedes `@media`-Blocks alle schließenden Klammern ab statt nur einer. Damit war `editor.css` ab dem ersten Medienblock ungültig: der Browser behielt 29 von 202 Regeln. Aufgefallen ist es an einer Vorschaubreite von 1236 statt 1240 Pixeln, weil der Standardrahmen des iframe nicht mehr entfernt wurde – vier Pixel als einziges Anzeichen dafür, dass dreiviertel des Editor-Stylesheets fehlte. Behoben und mit ausgeglichenen Klammern nachgerechnet.
- Von Hand bedient: Seitenübersicht mit Aufklappfeld, Menüs, Formulare, Bereiche, Design, Einstellungen, Mediathek und der Editor in allen drei Vorschaugrößen.
- **Nicht geprüft:** kein Screenreader. Die automatische Barrierefreiheitsprüfung deckt Anmeldung, Seitenübersicht und Editor ab, nicht die übrigen Verwaltungsbildschirme.

## Ergänzung: eigenes CSS und eigenes Skript, 12.09.2026

- **201 PHP-Tests / 716 Assertions** unter PHP 8.2.12 und PHP 8.4.22, **15 JavaScript-Modelltests**, der vollständige Playwright-Editortest mit axe (null Verstöße) und die öffentliche Browserprüfung.
- **Zehn abgewiesene CSS-Eingaben** erreichen kein Dokument, darunter die Ausbruchsversuche: `color:red} body{display:none`, ein fremder Selektor `body { … }`, `@import`, `@media`, `url(javascript:alert(1))`, `url(//fremd.example/x.png)`, ein Backslash-Escape und `expression()`.
- Fünf erlaubte CSS-Formen werden korrekt auf das Element bezogen, einschließlich `& > p` und `& .block-text`.
- **Zwei echte Löcher kamen dabei heraus.** `& .block-text` wurde zu `#id.block-text`, weil das führende Leerzeichen wegtrimmt wurde – aus dem Nachfahren wurde derselbe Knoten, die Regel traf das falsche Element. Und `url(//fremd.example/x.png)` kam durch, weil jede Adresse mit `/` erlaubt war: eine protokollrelative Adresse hätte über das Schema der Seite von Dritten geladen. Beides behoben, beides durch einen Test abgedeckt.
- Skriptauslieferung geprüft: eigenes Skript erscheint **nie** im HTML, sondern nur unter `/assets/seite/{id}.js` mit `text/javascript`, in einer eigenen Closure mit gesuchtem `element`. Die Seite mit Skript sendet `script-src 'self'`, eine Seite ohne behält `script-src 'none'` und liefert für ihre Adresse 404. **Ein Skript aus einem gespeicherten, aber unveröffentlichten Entwurf wird nicht ausgeliefert.**
- Rollenprüfung geprüft: der Vergleich mit dem gespeicherten Stand weist Ändern, Entfernen und Hinzufügen eines Skripts ab und lässt ein unverändertes Skript durch – ein Editor kann eine Seite mit Skript also weiter bearbeiten, ohne das Skript anfassen zu können.
- **Nicht geprüft:** der Reiter „Erweitert“ ist nicht von Hand bedient und nicht mit einem Screenreader getestet. Ob ein eingesetztes Skript im Browser tatsächlich läuft, ist ebenfalls nicht ausgeführt worden – geprüft ist, dass die Datei mit dem erwarteten Inhalt ausgeliefert wird und dass die Richtlinie sie zulässt.

## Ergänzung: formatierter Text, 12.09.2026

- **182 PHP-Tests / 685 Assertions** unter PHP 8.2.12 und PHP 8.4.22, **15 JavaScript-Modelltests**, der vollständige Playwright-Editortest mit axe (null Verstöße) und die öffentliche Browserprüfung.
- **Dreizehn Fälle durch den Filter**, davon acht Angriffe: `<script>alert(1)</script>Text danach` behält nur den Text, ein `onclick`-Attribut verschwindet, `class` und `style` verschwinden mitsamt dem Element (der Text bleibt), ein `javascript:`-Link wird zu Text, ein `<img src=x onerror=…>` verschwindet vollständig, ein `<iframe>` verschwindet, unausgeglichene Auszeichnung wird geschlossen, und Klartext mit `<` wird maskiert.
- Geprüft, **wo** gefiltert wird: nach dem Speichern liegt in der Datenbank bereits die gefilterte Fassung. Damit kann kein Renderer das Filtern vergessen, und eine manipulierte Anfrage speichert nichts, was der Editor nicht anbietet.
- Geprüft, dass ältere Dokumente unberührt bleiben: dieselbe Auszeichnung wird in einem v3-Dokument maskiert ausgegeben und in einem v12-Dokument als Auszeichnung. Der bestehende XSS-Test für v1 gilt unverändert.
- Geprüft, dass derselbe Filter in einem geteilten Bereich greift, und dass ein nach dem Filtern leerer Textblock abgewiesen wird, ohne zu schreiben.
- **Eine Inkonsistenz wurde dabei behoben:** ein Text, der zufällig ein `<` enthielt, behielt echte Zeilenumbrüche, während alles andere `<br>` benutzte – zwei Darstellungen desselben Umbruchs. Beide Zweige erzeugen jetzt `<br>`; innerhalb von `code` bleiben Umbrüche erhalten.
- **Die Werkzeugleiste selbst ist nicht bedient worden** und nicht mit einem Screenreader geprüft. Geprüft ist der Filter, der Speicherweg und die Ausgabe.

## Ergänzung: Kopf, Fuß und verknüpfte Sektionen, 12.09.2026

- **165 PHP-Tests / 660 Assertions** unter PHP 8.2.12 und PHP 8.4.22, **15 JavaScript-Modelltests**, der vollständige Playwright-Editortest mit axe (null Verstöße) und die öffentliche Browserprüfung.
- Bereiche geprüft: Kopf- und Fußbereich erscheinen als gewöhnliche Blöcke, der Navigationsblock zeigt das Menü, eine Änderung am Kopfbereich erreicht beide geprüften Seiten gleichzeitig, und ein geleerter Bereich rendert nichts statt einer kaputten Hülle.
- Verknüpfte Sektion geprüft: auf zwei Seiten sichtbar, die Seitendokumente enthalten **nur die Adresse**, eine Änderung wirkt an beiden Stellen, `usedBy` nennt beide Seiten, und nach dem Entfernen bleiben beide Seiten mit HTTP 200 heil, mit erhaltenem Verweis.
- Abgewiesen werden: eine Hauptüberschrift in einem geteilten Bereich, eine Sektion mit Selbstbezug (ohne zu schreiben), ein zweiter Kopfbereich und das Löschen von Kopf- oder Fußbereich.
- **Ein echter Fehler, den der axe-Lauf gefunden hat, und zwar nicht nur im eingesetzten Fußbereich:** die Token-CSS war für die flache Struktur Sektion → Text geschrieben. `.block-column>.block-text:first-child` setzt eine Farbe für helle Hintergründe und gewinnt auf Spezifität gegen `.tone-ink .block-text`; Text in einer Spalte auf dunklem Grund war damit unlesbar, gemessen **1,87:1**. Das betraf jede dunkle Sektion mit Spalten, nicht nur die neuen Bereiche. Zwei gezielte Selektoren gleicher Spezifität stellen es richtig, helle Farbwelten bleiben unberührt.

## Ergänzung: Startseite, erreichbare Standarddateien, getrennte Befunde, 12.09.2026

- **162 PHP-Tests / 636 Assertions** unter PHP 8.2.12 und PHP 8.4.22, **15 JavaScript-Modelltests**, der vollständige Playwright-Editortest und die **wieder grüne öffentliche Browserprüfung**.
- **Lighthouse 13.4.1: je drei Läufe mobil und Desktop, alle fünf Kategorien 100.**
- Startseite geprüft: eine andere veröffentlichte Seite wird zur Wurzel und antwortet unter `/`, ihre eigene Adresse leitet mit 301 dorthin, die bisherige Wurzel wird eine gewöhnliche Seite und ist wieder verschiebbar. Sitemap, strukturierte Daten und Menüauflösung folgen. Umbenennen und Papierkorb sind für die Wurzel gesperrt. Drei ungültige Angaben ändern nichts.
- **Ein weiterer echter Fehler, den nur ein HTTP-Aufruf zeigt:** `/sitemap.xml`, `/robots.txt`, `/llms.txt` und `/feed.xml` waren lokal **nie erreichbar**. Der eingebaute PHP-Server antwortet für fehlende Pfade mit Dateiendung selbst mit 404, ohne den Frontcontroller zu fragen – alle Kernel-Tests bestanden trotzdem, weil sie die Anwendung direkt aufrufen. `bin/dev-router.php` bildet die Rewrite-Regel nach, Start- und CI-Befehl nutzen es, und die Browserprüfung ruft die vier Adressen jetzt über HTTP auf und prüft den Inhaltstyp. Der Grund, warum es so lange unbemerkt blieb, war genau diese fehlende Prüfung.
- **Barrierefreiheitsbefunde werden nach Ursache getrennt.** Ein Kontrastfehler aus Theme oder Stylesheet bleibt ein Defekt und bricht den Lauf ab – so wurde die Linkfarbe gefunden, die jeden dunklen Abschnitt überschrieb. Ein Kontrastfehler an einem Element, das eine eigene Regel im erzeugten Seiten-Stylesheet hat, ist eine redaktionelle Feststellung: sie wird bei **jedem** Lauf mit Seite, Farbe und Verhältnis ausgegeben und in `reports/browser.json` geschrieben, macht aber einen Codewechsel nicht rot. Stillschweigend durchgelassen wird nichts.
- Aktuell offen und bei jedem Lauf gemeldet: `/grundlagen`, Textblock `#d08080` auf hellem Grund, 2,75:1 statt 4,5:1. Nicht verändert, weil es eine Nutzerentscheidung ist.

## Ergänzung: Seiten verwalten, 12.09.2026

- **160 PHP-Tests / 622 Assertions** unter PHP 8.2.12 und PHP 8.4.22, **15 JavaScript-Modelltests** und der vollständige Playwright-Editortest mit axe (null Verstöße).
- Verschieben geprüft: eine Seite mit Kind und Enkel wird umbenannt, alle drei Adressen ändern sich, jede neue antwortet mit 200, jede alte mit 301 auf genau ihr neues Ziel, und Slug sowie Elternbeziehung der Nachkommen bleiben unverändert.
- Vier abgewiesene Verschiebungen bewegen nichts und erzeugen keine Weiterleitung: unter die eigene Unterseite, in sich selbst, auf eine vergebene Adresse und mit einem unbrauchbaren Slug. Die Startseite wird ebenfalls abgewiesen.
- Papierkorb geprüft: der Teilbaum geht mit, die Seiten antworten öffentlich mit 404 und verschwinden aus Navigation, Sitemap, Beitragsarchiv, Feed und Editorliste. Ein Kind lässt sich nicht vor seinem Elternteil wiederherstellen, und das Wiederherstellen einer Seite holt keine andere zurück.
- Fassungen geprüft: Reihenfolge neueste zuerst, Wiederherstellen erzeugt eine zusätzliche Fassung statt zu überschreiben, eine Fassung einer anderen Seite wird abgewiesen.
- Zeitplan geprüft: ein künftiger Zeitpunkt veröffentlicht nichts, ein vergangener genau einmal, danach ist der Zeitpunkt verbraucht, ein ungültiges Format wird abgewiesen, und eine Seite im Papierkorb wird nie durch den Zeitplan veröffentlicht.
- **Ein echter Fehler kam dabei heraus:** die Reihenfolge des Fassungsverlaufs war nicht eindeutig. `created_at` hat Sekundengenauigkeit, mehrere Speichervorgänge fallen in dieselbe Sekunde, und die Liste richtete sich dann nach der zufälligen Revisions-ID – „vorherige Fassung wiederherstellen“ hätte die falsche treffen können. Jede Fassung trägt jetzt einen je Seite streng aufsteigenden Zähler; die Migration füllt ihn aus den vorhandenen Zeitstempeln und wurde vorher gegen eine Kopie der Datenbank geprüft.
- Migration `20260912000900` erst gegen eine Kopie ausgeführt und der Backfill kontrolliert (drei Fassungen von `/grundlagen` erhielten seq 1 bis 3 in der richtigen Reihenfolge), danach nach Backup angewendet. `cms:publish-due` ausgeführt.

## Ergänzung: Browsertests wiederhergestellt, 12.09.2026

- **155 PHP-Tests / 579 Assertions** unter PHP 8.2.12 und PHP 8.4.22, **15 JavaScript-Modelltests** und erstmals seit dem Editorumbau wieder der **vollständige Playwright-Editortest**.
- Der Editortest war durch den Umbau kaputt: er steuerte die abgeschafften Auswahllisten. Er wurde auf die freien Bedienelemente umgeschrieben und prüft jetzt Einheitenfelder, Vererbung über drei Geräte, einzelnes Zurücksetzen, Palettenfarbe, Abstand je Seite, die Hover-Regel, freie Rasterspalten und die Bewegungseffekte.
- **axe-core: null Verstöße** auf Login, Seitenliste, Editor in Desktop- und Mobilbreite, Medienauswahl und der bearbeiteten veröffentlichten Seite.
- **Lighthouse 13.4.1: je drei Läufe mobil und Desktop auf der Startseite, alle fünf Kategorien 100** – mit Theme-System, gehashtem Stylesheet und den neuen Blöcken.

**Drei echte Fehler, die nur der Browserlauf gezeigt hat:**

1. **Die frei gestalteten Werte wirkten in der Editorvorschau überhaupt nicht.** Ein `srcdoc`-Iframe erbt die Richtlinie des einbettenden Dokuments; die Verwaltung verbietet Inline-Styles, also wurde das erzeugte `<style>` stillschweigend verworfen. Ausgeliefert wurde es korrekt – die Vorschau log. Behoben über ein inertes `<template>` plus `adoptedStyleSheets`.
2. **Die Einrückung der Unterseiten in der Seitenliste hat nie funktioniert**, weil sie über ein `style`-Attribut lief, das dieselbe Richtlinie verwirft. Die Hierarchie sah immer flach aus. Jetzt über Klassen.
3. **Das Theme setzte alle Links auf die Akzentfarbe** und überschrieb die kontextabhängigen Farben: 3,08:1 auf dunklem Grund, 4,36:1 im Fußbereich. Die Regel gilt jetzt nur für Links in Textblöcken, und die voreingestellte Linkfarbe liegt auf allen hellen Tönen über 4,5:1.

**Eine offene Feststellung im Inhalt:** `npm run test:browser` schlägt fehl, weil `/grundlagen` einen im Editor gesetzten Textblock in `#d08080` auf hellem Grund trägt – 2,75:1, unter der AA-Schwelle. Die Revisionen stammen aus dieser Sitzung und nicht aus einem Testlauf (die Tests arbeiten auf eigenen Datenbanken). Die Farbe wurde **nicht** verändert, weil sie eine Nutzerentscheidung ist. Die Kontrastwarnung im Editor meldet genau diesen Fall.

## Ergänzung: Direktbearbeitung, Kontrastwarnung, Vorlagen, 12.09.2026

- **155 PHP-Tests / 579 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **15 JavaScript-Modelltests**.
- **Erstmals wurde der neue Editor im laufenden Betrieb bedient**, nicht nur sein Aufbau abgefragt. Geprüft: ein Doppelklick auf die Hauptüberschrift setzt das Element auf `contenteditable="plaintext-only"`, eine Texteingabe erreicht das Modell (der Speicherstatus wechselt auf „Ungespeicherte Änderungen“ und der Strukturbaum zeigt den neuen Text), und das Verlassen entfernt den Bearbeitungszustand wieder. Die Änderungen wurden anschließend verworfen; es wurde nichts gespeichert und keine echte Seite verändert.
- Die Kontrastwarnung wurde mit echten Werten ausgelöst: `#cccccc` auf `#ffffff` ergibt „Kontrast 1.6:1 – zu wenig“ in der roten Stufe. Die Berechnung folgt der relativen Leuchtdichte aus WCAG 2.1 und löst Palettenverweise vorher auf.
- Gestaltungsvorlagen über HTTP geprüft: anonymer Zugriff führt zur Anmeldung, das CSRF-Token ist Pflicht, ein Stil mit eingeschleuster Deklaration (`32px;position:fixed`) und ein leerer Name werden mit HTTP 422 abgewiesen, ohne etwas zu schreiben; Speichern und Entfernen funktionieren. Damit kann über den Umweg Vorlage kein Wert in ein Dokument gelangen, für den ein Block abgewiesen würde.
- **Weiterhin keine axe- und keine Lighthouse-Messung** und keine Erprobung mit einem Screenreader. Bei der Direktbearbeitung ist das ein besonderer Vorbehalt: ob der Fokus sinnvoll wandert und der Wechsel in den Bearbeitungszustand angekündigt wird, ist nicht nachgewiesen – geprüft ist nur, dass die Mechanik funktioniert.

## Ergänzung: freie Gestaltung, 12.09.2026

- **154 PHP-Tests / 563 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **15 JavaScript-Modelltests**.
- Ein v10-Dokument mit Palettenfarbe, eigenem Farbwert, Abständen je Seite, Ecken je Ecke, Schatten, Buchstabenabstand, Hover-Zustand und eigenem Mobilwert wird Byte für Byte gespeichert und zu blockgenauem CSS: Regel für den Block, eigene Regel für `:hover,:focus-within` und eine Media Query für die schmale Breite.
- **Vierzehn abgewiesene Eingaben schreiben nichts.** Darunter gezielt die Ausbruchsversuche: eine Farbe als Funktion (`rgb(1,2,3)`), eine Länge als Ausdruck (`calc(1px + 2px)`), eine angehängte Deklaration (`18px;position:fixed`), ein Schriftschlüssel mit Anführungszeichen und ein Hintergrundbild als Dateipfad. Jeder dieser Werte scheitert am verankerten Muster seines Typs, bevor er gespeichert wird.
- **Die Sicherheitsrichtlinie wurde eigens geprüft:** das erzeugte Stylesheet ist über seinen eigenen SHA-256-Hash erlaubt, `unsafe-inline` kommt im Kopf nicht vor, und Skripte bleiben auf Seiten ohne Tabs abgeschaltet. Ohne eingestellte Google-Schrift wird kein fremder Host erlaubt und keiner kontaktiert.
- **Acht ungültige Themes** werden abgewiesen, ohne das gespeicherte Theme zu verändern; danach liefert das Theme weiterhin die Voreinstellungen.
- Im Editormodell geprüft: Vererbung, einzelnes Zurücksetzen, Entfernen leerer Reste, Kopieren ohne geteilte Objekte und vollständiges Undo.
- **Im Browser geprüft wurde nur der Aufbau, nicht die Bedienung.** Im laufenden Editor wurde über das DOM bestätigt, dass das Designpanel aus dem Serverschema entsteht: sieben Gruppen, 58 Felder, 11 Farbwähler, 12 Schieberegler, 34 Einheitenauswahlen. **Es wurde kein Gestaltungsvorgang von Hand ausgeführt**, keine Tastaturbedienung erprobt und keine axe- oder Lighthouse-Messung gemacht. Für ein Werkzeug dieser Größe ist das ein erheblicher Vorbehalt.
- Die Bildschirmfotos des Vorschaufensters blieben bei der Editoransicht unbrauchbar (zu schmale Fläche, zeitweise leere Bilder). Die Beurteilung stützt sich deshalb auf DOM-Abfragen und die erzeugte Ausgabe, nicht auf Augenschein.

## Ergänzung: SEO und maschinelle Zugänglichkeit, 12.09.2026

- **128 PHP-Tests / 507 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **14 JavaScript-Modelltests**.
- Sitemap geprüft: wohlgeformtes XML, enthält weder eine `noindex`-Seite noch einen unveröffentlichten Entwurf, dafür Startseite, indexierbare Seiten, Beitragsübersicht und Begriffsarchiv. `robots.txt` verweist auf die Sitemap und sperrt `/admin`. Dieselbe `noindex`-Seite trägt zusätzlich ein `noindex`-Meta, eine indexierbare Seite keines.
- Weiterleitungen geprüft: 301 mit Zielangabe und 410 ohne, beide **vor** dem 404; eine vorhandene Seite gewinnt gegen eine gleichnamige Weiterleitung; Selbstbezug, Weiterleitungskette, Großbuchstaben im Pfad und ein anderer Statuscode als 301 oder 410 werden abgewiesen, ohne etwas zu schreiben.
- Strukturierte Daten geprüft: ohne gepflegte Unternehmensdaten wird **kein** Block ausgegeben. Danach `LocalBusiness` mit Anschrift und Ländercode, doppelte Profile entdoppelt, und kein Feld ohne gepflegten Wert. Ein Beitrag trägt `Article` mit Überschrift und Autor aus seinen Metadaten, eine Unterseite `BreadcrumbList` mit absoluten Adressen. Die Brotkrumen erscheinen erst ab zwei Ebenen.
- `llms.txt` antwortet ausgeschaltet mit HTTP 404 und listet eingeschaltet weder eine `noindex`-Seite noch einen Entwurf.
- Fünf ungültige Unternehmensangaben (E-Mail, Telefon, Ländercode, unsicheres Profil, lokales Unternehmen ohne Anschrift) schreiben nichts. In `robots.txt` überleben weder Markup noch eine zweite `Sitemap:`-Zeile aus dem Freitextfeld.
- Ein bestehender Flattermacher im Testabbau wurde behoben: unter Windows gab ein Kernel den Dateizeiger auf die Testdatenbank manchmal erst kurz nach dem Herunterfahren frei, wodurch das Aufräumen mit einer Warnung fehlschlug und den ganzen Lauf rot färbte. Der Abbau wartet jetzt kurz und lässt die temporäre Datei notfalls dem Betriebssystem.
- **Erstmals seit Paket A wieder im Browser angesehen** – auf ausdrücklichen Wunsch, und ausdrücklich **keine** Messung: eine lokale Demoseite mit allen neuen Bausteinen wurde im Produktionsmodus aufgerufen und die Ausgabe geprüft. Kennzahlen, Symbolkarten mit Inline-SVG, Kundenstimme, Akkordeon, Kontaktdaten, Formular und Aufruf-Band erscheinen wie vorgesehen, die Tabs zeigen mit aktivem JavaScript nur den gewählten Abschnitt. **Das ist eine Sichtprüfung, kein Audit:** es liegen weiterhin keine axe- und keine Lighthouse-Ergebnisse für die Pakete B bis E vor, und die Bildschirmfotos des Vorschaufensters waren auf langen Seiten unzuverlässig, sodass Teile nur über die Auszeichnung und die gemessenen Elementhöhen beurteilt wurden.
- Kosmetisch aufgefallen: eine Symbolkarte innerhalb einer Spalte zeigt zwei ineinanderliegende Rahmen, weil Spalte und Karte je einen eigenen Rahmen haben. Nicht behoben, weil es eine Gestaltungsentscheidung ist und keine Fehlfunktion.

## Ergänzung: Formulare, 12.09.2026

- **117 PHP-Tests / 450 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **14 JavaScript-Modelltests**. `composer audit` meldet keine bekannten Advisories, auch nach Aufnahme von `symfony/mailer`.
- Vollständiger Ablauf geprüft: Ausgabe ohne Skript, gültige Absendung wird gespeichert und mit HTTP 303 zurückgeleitet, damit ein Neuladen nichts doppelt sendet, und die Erfolgsmeldung erscheint auf der Zielseite.
- **Datenschutz gezielt geprüft:** in der gespeicherten Zeile steht keine Absenderadresse, sondern ein 64-stelliger Hash; der Zeitpunkt der Einwilligung wird getrennt festgehalten.
- Fehlerhafte Absendung: HTTP 422, **nichts gespeichert und nichts gesendet**, vier Meldungen an den richtigen Feldern, verbunden über `aria-describedby` und `aria-invalid`, genau eine Zusammenfassung mit `role=alert`, und sämtliche Eingaben bleiben erhalten.
- Vier Spamfälle werden still verworfen, ohne zu speichern, und wie ein Erfolg beantwortet: gefüllter Honeypot, Absendung innerhalb der Mindestzeit, gefälschte Zeitstempelsignatur und ein zu alter Zeitstempel. Das Limit stoppt die sechste Absendung innerhalb einer Stunde.
- Die Formularverwaltung verlangt Anmeldung, Editorrolle und CSRF-Token; eine ungültige Empfängeradresse wird mit einer Meldung abgewiesen statt gespeichert.
- **Ein echter Fehler wurde dabei gefunden und behoben:** das Stundenfenster des Limits entstand aus der lokalen Uhrzeit, die Zeitstempel der Einsendungen aber aus UTC. Auf einer Uhr vor UTC – etwa in Deutschland – hätte das Limit nie gegriffen und der Spamschutz wäre an dieser Stelle wirkungslos gewesen. Beide Seiten rechnen jetzt in UTC; der Test deckt genau diesen Fall ab.
- **Der E-Mail-Versand wurde nie wirklich ausgeführt.** Die Tests nutzen einen Transport, der nichts sendet. Ob `sendmail` auf dem Zielhosting funktioniert, ob Nachrichten zugestellt werden und ob sie im Spamordner landen, ist damit vollständig offen und gehört zu Arbeitspaket J.
- **Auch für diesen Schritt wurden auf Wunsch des Nutzers keine Browser-, axe- und Lighthouse-Läufe ausgeführt.** Formularausgabe und Verwaltung sind nicht visuell und nicht mit einem Screenreader geprüft. Gerade bei Formularen ist das ein erheblicher Vorbehalt: die Fehlerauszeichnung ist im Markup korrekt gesetzt, aber nicht in einer echten Hilfstechnik gehört worden.

## Ergänzung: Tabs, 12.09.2026

- **109 PHP-Tests / 395 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **14 JavaScript-Modelltests**.
- Geprüft, dass die Seite ohne JavaScript vollständig bleibt: beide Panels stehen mit Inhalt und Überschrift im HTML, keines ist serverseitig versteckt, und die Ankerliste verweist auf sie. Verstecken ist ausschließlich Aufgabe des Skripts.
- **Die Sicherheitsrichtlinie wurde gezielt geprüft:** `script-src 'self'` erscheint nur auf der Seite, die tatsächlich einen Tab-Block enthält. Eine Seite ohne Tabs und die 404-Seite senden weiterhin `script-src 'none'` und laden kein Skript. Das Skript wird als externe Datei eingebunden; Inline-Skript kommt nicht vor.
- Abgewiesen werden ein Tab außerhalb einer Tabgruppe (auch auf oberster Dokumentebene), eine Tabgruppe mit einem Textkind und Tabs in einem v6-Dokument.
- Im Editormodell geprüft: eine neue Tabgruppe bringt zwei Tabs mit eigenen IDs mit, nimmt ausschließlich Tabs auf, und ein Tab lässt sich weder in eine Sektion noch in ein Akkordeon einfügen; ein Tab selbst nimmt gewöhnlichen Inhalt auf.
- **Das Skript selbst wurde nicht ausgeführt.** Pfeiltastenbedienung, `aria-selected`, das Umschalten der Panels und die Auswahl über ein Sprungziel sind im Code umgesetzt, aber ohne Browserlauf weder funktional noch auf Barrierefreiheit geprüft. Für ein Tab-Widget ist das ein erheblicher Vorbehalt: gerade die Tastaturbedienung und die ARIA-Rollen sind der Grund, warum diese Umsetzung überhaupt gewählt wurde. Ein Browserlauf steht dafür aus.

## Ergänzung: Blöcke für die Pilotseite, 12.09.2026

- **107 PHP-Tests / 380 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **13 JavaScript-Modelltests**.
- Eine Testseite aus allen zehn neuen Abschnittsarten wird Byte für Byte gespeichert, veröffentlicht und ausgegeben. Geprüft sind die erzeugten `tel:`- und `mailto:`-Verweise samt bereinigter Telefonnummer, das Akkordeon als echtes `details`-Element mit `summary`, Symbole als Inline-SVG, die für Screenreader ausgeschriebene Bewertung und die Abwesenheit von `script` in der Ausgabe.
- Vierzehn abgewiesene Eingaben schreiben nichts: unbekanntes Symbol, fehlender Titel, `javascript:`-Linkziel, Bewertung außerhalb 0–5 sowie als Zeichenkette statt Zahl, leerer Kontaktblock, ungültige Telefonnummer, ungültige E-Mail-Adresse, unbekannte Abstandsgröße, unerlaubtes Linkschema am Aufruf-Band, Text in einer Logoleiste, Text direkt in einem Akkordeon, Akkordeon-Eintrag ohne Akkordeon und Kinder an einer Trennlinie. Zusätzlich abgesichert, dass die neuen Blöcke in Schema v5 weiterhin abgewiesen werden.
- **Zwei echte Fehler wurden durch diese Tests gefunden und behoben.** Im Validator griff die Regel „ein Akkordeon-Eintrag gehört in ein Akkordeon“ nicht auf oberster Dokumentebene, weil sie nur beim Durchlaufen der Kinder lief; sie sitzt jetzt an der Typprüfung selbst. Im JavaScript-Test wurde `history.document.blocks` vor `history.change()` ausgewertet und damit im vorherigen Dokumentstand gesucht – ein Fehler im Test, nicht im Modell, aber einer, der bei umgekehrtem Ausgang eine falsche Bestätigung erzeugt hätte.
- Im Editormodell geprüft: ein neues Akkordeon bringt einen Eintrag mit, damit es nie leer ausgegeben wird; ein Eintrag lässt sich nur in ein Akkordeon einfügen und nirgendwo sonst; eine Logoleiste nimmt nur Bilder; Blattblöcke bleiben Blätter und behalten ihre Vorgabewerte; das vollständige Rückgängigmachen stellt den Ausgangszustand her.
- `composer lint`, `lint:twig`, `lint:yaml`, `lint:container` und die Syntaxprüfung der Editormodule sind erfolgreich. Die erzeugte `design.css` bleibt unverändert, obwohl das Tokenmanifest neue Typen führt, und der bestehende Abgleich zwischen Manifest und Stylesheet greift weiterhin.
- **Auch für diesen Schritt wurden auf Wunsch des Nutzers keine Browser-, axe- und Lighthouse-Läufe ausgeführt.** Für die zehn neuen Blöcke liegt damit **keine visuelle Kontrolle, keine Barrierefreiheitsprüfung und keine Messung** vor. Das wiegt hier schwerer als in den Schritten davor, weil es sich um sichtbare Gestaltungsbausteine mit eigenem CSS handelt; die Aussagen oben betreffen ausschließlich die erzeugte Auszeichnung.

## Ergänzung: Beiträge, 12.09.2026

- **91 PHP-Tests / 347 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **12 JavaScript-Modelltests**.
- Archiv geprüft: Sortierung nach Datum über mehrere Seiten, Begrenzung zu großer und negativer Seitenzahlen auf den gültigen Bereich statt einer leeren Ausgabe, gewöhnliche Seiten und unveröffentlichte Beiträge erscheinen nicht, Canonical und Datumsausgabe stimmen.
- Kategorien und Schlagwörter geprüft: eigene Archive, getrennte Namensräume (ein Schlagwort-Slug ist keine Kategorie), unbekannter Begriff ergibt HTTP 404, erneutes Speichern ersetzt die Zuordnung statt sie zu ergänzen, und ein dadurch leer gewordenes Archiv antwortet weiter mit HTTP 200 und leerer Liste. Beim Löschen einer Seite verschwinden ihre Zuordnungen, die Begriffe selbst bleiben erhalten.
- **Der Block `postlist` wurde gezielt darauf geprüft, dass er keine Beitragsdaten speichert.** Das gespeicherte Dokument enthält nach dem Veröffentlichen ausschließlich Anzahl und Filter; die angezeigten Beiträge stellt der Controller zusammen. Ein Beitrag aus einer anderen Kategorie erscheint nicht. Damit kann ein gespeichertes Dokument keinen unveröffentlichten Beitrag zeigen.
- Feed geprüft: wohlgeformtes XML (`simplexml_load_string`), absolute Adressen, Kategorien als `category`-Elemente, kein unveröffentlichter Beitrag.
- Sechs abgewiesene Metadateneingaben (zu langer Auszug, zu langer Autorname, falsches Datumsformat, unbekanntes und fehlerhaftes Beitragsbild, unbrauchbarer Begriffsname) schreiben nichts und erhöhen die Seitenversion nicht.
- Veröffentlichen stempelt ein fehlendes Beitragsdatum, lässt ein gepflegtes unangetastet und rührt gewöhnliche Seiten nicht an.
- Migration `20260912000600` zuerst gegen eine Kopie der lokalen Datenbank ausgeführt und kontrolliert, danach nach Backup (`var/backups/before-posts-*.db`) angewendet. `composer lint`, `lint:twig`, `lint:yaml`, `lint:container` und wiederholtes Seeding sind erfolgreich.
- **Auch für diesen Schritt wurden auf Wunsch des Nutzers keine Browser-, axe- und Lighthouse-Läufe ausgeführt.** Archivseiten, Beitragsliste, Paginierung und das Formular für Beitragsdaten sind nicht visuell, nicht auf Barrierefreiheit und nicht auf Leistung geprüft. Insbesondere liegt für die Archivseiten keine Messung vor.

## Ergänzung: Menüs, 12.09.2026

- **79 PHP-Tests / 285 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **11 JavaScript-Modelltests**.
- Geprüft, dass die Navigation nicht mehr aus dem Template stammt: die ausgegebenen Links der Hauptnavigation entsprechen genau den gespeicherten Menüeinträgen. Seiten-, Anker- und externe Ziele einschließlich `tel:` werden korrekt gebildet, `aria-current` erscheint nur auf der tatsächlich aktuellen Seite und nicht auf einem Ankereintrag derselben Seite.
- Geprüft, dass eine gelöschte und eine noch unveröffentlichte Seite aus der Navigation fallen, ohne die übrigen Einträge zu verlieren, dass die Kinder eines übersprungenen Eintrags nachrücken und dass der gespeicherte Baum unangetastet bleibt: nach dem Veröffentlichen erscheint der Eintrag wieder. Ein Entwurf wird über das Menü nicht öffentlich.
- Zehn abgewiesene Eingaben schreiben nichts in die Datenbank: leere und überlange Beschriftung, unbekannte Zielart, fehlende Seite, Sprungziel mit Rautezeichen, Sprungziel mit führender Ziffer, `javascript:`, `http:`, protokollrelative Adresse und eine dritte Ebene. Dazu unbekannter Platz, Überschreitung der Eintragsgrenze und ein veralteter Schreibstand.
- Über HTTP geprüft: anonymer Schreibversuch führt zur Anmeldung, CSRF-Token ist Pflicht, ein veralteter Versionsstand überschreibt kein neueres Menü, und der Baum entsteht korrekt aus flachen Formularzeilen über Position und Ebene, einschließlich normalisiertem Sprungziel und ignorierter Leerzeile.
- Migration `20260912000500` zuerst gegen eine Kopie der lokalen Datenbank ausgeführt, dann nach Backup (`var/backups/before-menus-*.db`) angewendet. Wiederholtes Seeding legt fehlende Menüs an und lässt vorhandene unverändert. `composer lint`, `lint:twig`, `lint:yaml` und `lint:container` sind erfolgreich.
- **Ein Fehler in der Testumgebung wurde dabei sichtbar und behoben.** Das Testkernel läuft ohne Debug; Symfony prüft dann weder den kompilierten Container noch die Vorlagen auf Aktualität. Ein geänderter Konstruktor schlug mit einem `TypeError` aus einem veralteten Container fehl, zuvor war bereits eine Vorlagenänderung übergangen worden. `tests/bootstrap.php` verwirft `var/cache/test` jetzt einmal pro Lauf. **Damit gilt für frühere Berichte: Ergebnisse, die vor dieser Behebung entstanden sind, wurden unter einer Bedingung gemessen, die einen veralteten Cache nicht ausschloss.** Die hier berichteten Läufe entstanden nach der Behebung.
- **Auch für diesen Schritt wurden auf Wunsch des Nutzers keine Browser-, axe- und Lighthouse-Läufe ausgeführt.** Die Menüverwaltung und die Aufklappmenüs in der Ausgabe sind nicht visuell, nicht auf Barrierefreiheit und nicht auf Leistung geprüft.

## Ergänzung: Erhalt unbekannter Blöcke, 12.09.2026

- **64 PHP-Tests / 229 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **11 JavaScript-Modelltests**.
- Geprüft, dass ein v4-Dokument mit einem Baustein `acme.slider` samt verschachteltem Text unverändert gespeichert, veröffentlicht und wieder geladen wird, und dass aus diesem Block **nichts** in die öffentliche Ausgabe gelangt: weder seine ungeprüften Props noch seine Kindinhalte noch eine darin abgelegte `javascript:`-URL. Die übrige Seite rendert normal. Sechs fehlerhafte Namensraumformen sowie Plugin-Blöcke in den Schemaversionen v1 bis v3 werden weiterhin vor jedem Schreibzugriff abgewiesen.
- Im JavaScript-Modell geprüft: Erkennung des Namensraums, Beschriftung und Symbol ohne Wörterbucheintrag, kein Einfügen in den Baustein, keine Erzeugung über die Elementbibliothek, Verschieben und Duplizieren mit neuen IDs bei unveränderten Props sowie ein vollständiges Undo auf den Ausgangszustand.
- Beim Schreiben dieser Tests wurde ein Fehler in der Testumgebung sichtbar: das Testkernel läuft ohne Debug, wodurch eine im Cache liegende kompilierte Twig-Vorlage den Ausgang des Laufs bestimmen konnte. Twig lädt in der Testumgebung jetzt automatisch neu; die Wirkung wurde gegengeprüft, indem die Vorlage bewusst verändert wurde und der Test daraufhin fehlschlug.
- `composer lint`, `lint:twig`, `lint:yaml`, `lint:container` und die Syntaxprüfung der Editormodule sind erfolgreich.
- **Auch für diesen Schritt wurden auf Wunsch des Nutzers keine Browser-, axe- und Lighthouse-Läufe ausgeführt.** Der Platzhalter in der Editorvorschau und der Hinweis im Eigenschaftenpanel sind nicht visuell geprüft.

## Ergänzung: Seitenerstellung und Adresshierarchie, 12.09.2026

- **56 PHP-Tests / 212 Assertions** unter PHP 8.2.12 und PHP 8.4.22 erfolgreich, dazu **10 JavaScript-Modelltests**. Neu gegenüber dem vorigen Stand sind 15 Tests zu Seitenerstellung, Adresshierarchie, Löschen und Zugriffsrechten; die Liste steht in STATUS.
- Migration `20260912000400` **zuerst gegen eine Kopie** der lokalen Datenbank ausgeführt und die erzeugten Anweisungen geprüft: vier reine `ALTER TABLE … ADD COLUMN`, kein Tabellenneuaufbau und damit kein Konflikt mit dem Fremdschlüssel `revision.page_id`. Backfill, Wegfall des alten eindeutigen Slug-Index und Anlage von `uniq_page_path` und `idx_page_parent` kontrolliert. Anschließend nach konsistentem Backup (`var/backups/before-hierarchy-20260912-102402.db`) auf die lokale Datenbank angewendet; die drei vorhandenen Seiten und ihre Dokumente sind unverändert.
- `composer lint` (PHP-CS-Fixer), `lint:twig`, `lint:yaml`, `lint:container`, wiederholtes `cms:seed-demo` und der Produktionscacheaufbau sind erfolgreich.
- **Für diesen Schritt wurden auf Wunsch des Nutzers keine Browser-, axe- und Lighthouse-Läufe ausgeführt.** Die neuen Formulare für Anlegen und Löschen sind über Funktionstests geprüft (Formulare werden dort tatsächlich abgeschickt), aber nicht visuell, nicht auf Barrierefreiheit und nicht auf Leistung. Die zuletzt gemessenen Lighthouse- und axe-Ergebnisse gelten für den vorigen Stand und schließen die Verwaltungsoberfläche dieses Schritts nicht ein.
- Beim Testen wurde ein bestehender Fehler in der Testumgebung behoben: die Zähler des Login-Throttlings lagen im dauerhaften Cache und sperrten nach mehreren Testläufen die Anmeldung aus. In der Testumgebung nutzt der Rate-Limiter jetzt einen Array-Cache; die Drosselung selbst bleibt aktiv und wird weiterhin getestet. Zwei aufeinanderfolgende Läufe ohne Cachelöschung waren erfolgreich.
- Weiterhin offen: MySQL/MariaDB, tatsächliches Hosting, Felddaten, vollständige manuelle Barrierefreiheitsprüfung und repräsentative Kundeninhalte.

## Ergänzung: Medienverwaltung, Galerie und Effekte, 12.09.2026

- **41 PHP-Tests / 155 Assertions** unter PHP 8.2.12 und 8.4.22 sowie **10 JavaScript-Modelltests** bestanden. Neu: geschützte Medien-API/CSRF, als JPEG getarnte SVG-Abweisung, tatsächliche Bilddecodierung/Neuencodierung, entfernte angehängte Nutzdaten, drei WebP-Varianten, Metadata-CAS/409, Archivieren/Wiederherstellen und weiter erreichbare Bilddateien. Zusätzlich ungültige Effekt-/Schemaschlüssel, Galerie-Kindtypen und `srcset`-Quellen sowie v3-Undo und Galerie-Verschieberegeln geprüft.
- Isolierter Browserablauf mit eigenen Datenbanken/Medienordnern bestanden: Upload von zwei lokal erzeugten Testillustrationen, Titel und Alt-Texte speichern, Mehrfachauswahl per Tastatur mit Fokus-Erhalt, Galerieeinfügen, Bildbeschriftung, Sortieren/Undo, responsive Spalten, Schatten/Hover/Einblendung und Bewegungsreduktion. Archivieren erhält URLs, Wiederherstellen erlaubt erneute Auswahl. Bilder und Bildquellen bleiben nach Speichern/Neuladen/Publizieren funktionsfähig. Bestehende Rechte-, Netzwerk-/Konflikt- und Editorprüfungen weiterhin erfolgreich.
- Keine axe-Verstöße in Medienauswahl und mobiler Mediathek sowie den bisherigen Login-/Seiten-/Editor- und öffentlichen Prüfungen. Desktop- und Mobil-Mediathek und öffentliche Galerieseite anhand der Screenshots geprüft. Alle drei bestehenden öffentlichen Seiten erneut mit/ohne JavaScript und bei 1440/390 px geprüft. Sandbox-Prüfgrenze weiterhin wie unten beschrieben; keine vollständige manuelle Screenreader-Abnahme.
- **Lighthouse 13.4.1: drei mobile und drei echte Desktopläufe auf der veröffentlichten v3-Galerieseite; alle fünf Kategoriescores in jedem Lauf 100.** LCP-Median mobil **937 ms**, Desktop **279 ms**, CLS **0**, TBT **0 ms**. PHP 8.2.12, SQLite, lokaler Produktionsmodus, GD-generierte Landschaftsillustrationen mit WebP-Varianten statt realer Kundenfotos. Rohdaten `reports/lighthouse-editor`, Metadaten `docs/quality/editor-media-lighthouse.json`, Browserbericht `docs/quality/editor-media-browser.json`. Reproduktion über `npm run test:editor -- --audit`.
- Migration 003 zuerst in Tests, anschließend lokal nach konsistentem SQLite-Backup angewendet. Keine Umschreibung echter Seitendokumente, keine Testuploads in den echten Medienordner, kein Browser-Neuladen des Nutzerentwurfs. Lokaler PHP-Prozess anschließend mit 8M Upload-/10M POST-/256M Speicherlimit gestartet. PHP-Format-, Twig-/YAML-/Container-, Composer- und Produktionsbuild-Prüfungen bestanden; Composer meldet keine bekannten Advisories.

Die öffentlichen Medien-URLs waren im ersten Browserlauf wegen des lokalen PHP-Servers mit `.webp`-Suffix nicht an den Frontcontroller weitergegeben worden. Erweiterungslose Routen beheben dies; tatsächliches Laden der Bilddateien wird jetzt ausdrücklich im Browser geprüft. Keine Hosting-/MySQL-/Restore-Abnahme, keine Felddaten und keine Aussage über beliebige hochgeladene Bilder oder Effekte auf Kundenwebsites.

## Ergänzung: responsive Editorgestaltung, 12.09.2026

- **34 PHP-Tests / 120 Assertions** unter PHP 8.2.12 und 8.4.22 erfolgreich. Zusätzlich zu den Sicherheits-/Revisionsprüfungen: v1/v2 lesen und speichern, originale Veröffentlichung erhalten, v1 wiederherstellen, validierte Gestaltungsklassen ohne Inline-CSS/JavaScript sowie Zurückweisung falscher Geräte, ungeeigneter Blockeigenschaften, unbekannter Tokens und zukünftiger Versionen.
- **9 JavaScript-Modelltests** erfolgreich: ergänzt um idempotente, inhaltserhaltende Migration; Gerätevererbung/Reset/Undo; atomare Vorlagen mit neuen IDs und genau einer H1; Abgleich des generierten CSS mit dem zentralen Tokenmanifest.
- Erweiterter Playwright-Ablauf auf eigener Datenbank erfolgreich: einklappbare Struktur/Werkzeugkasten, Suche und Auswahl per Tastatur, Schriftgröße/Ausrichtung/Abstände auf Desktop/Tablet/Mobil, echte Iframebreiten, Vererbung und Zurücksetzen samt Undo, Zweispaltenvorlage mit mobilem Umbruch. Danach Speichern, Neuladen und Veröffentlichen; berechnete öffentliche Styles auf 1600/768/390 px gegen die Vorschauwerte geprüft. Bestehende Fehler-/Konflikt-/Drag-and-drop-Prüfungen bleiben Bestandteil des Ablaufs.
- Keine axe-Verstöße in Login, Seitenliste, Desktop-/Mobil-Editor und gestalteter öffentlicher Mobilseite. Screenshotkontrolle von Desktop-Editor, Mobil-Editor und veröffentlichter Mobilseite erfolgreich; kein horizontaler Überlauf. Die unten beschriebene Einschränkung der scriptgesperrten Frameprüfung gilt weiterhin. Kompaktbericht: `docs/quality/editor-design-browser.json`.
- Alle drei bestehenden öffentlichen v1-Beispielseiten erneut bei 1440/390 px geprüft; sechs erfolgreiche Accessibility-Prüfungen plus Tastatur- und Navigation ohne JavaScript.
- **Lighthouse 13.4.1 auf der isolierten, veröffentlichten v2-Seite**, einschließlich Design-CSS und eingefügter responsiver Abschnittsvorlage: drei mobile und drei echte Desktopläufe, alle fünf Kategoriescores in jedem Lauf **100**. LCP-Median mobil **901 ms**, Desktop **240 ms**, CLS **0**, TBT **0 ms**. Produktionsmodus, PHP 8.2.12, SQLite und lokaler PHP-Server; Chromium/Profilparameter im Bericht `docs/quality/editor-design-lighthouse.json`, Rohdaten unter `reports/lighthouse-editor`. Der Test läuft reproduzierbar mit `npm run test:editor -- --audit` und ist in CI vorgesehen; externe CI weiterhin nicht ausgeführt.
- PHP-Format-, Twig-/YAML-/Containerprüfungen, JavaScript-Syntaxprüfung, Diff-Prüfung und Produktionscacheaufbau erfolgreich. Die zusätzlichen Designressourcen werden nur für v2-Dokumente geladen. Auf dem PHP-Hosting ist kein Node-Prozess nötig.

Weiterhin kleine lokale Testinhalte: keine Pilotkundenabnahme, keine Felddaten/INP-Aussage, keine umfassende Screenreaderprüfung und kein Nachweis für beliebige Gestaltungsentscheidungen. PHP-Webhosting und MySQL/MariaDB bleiben ungeprüft. Der echte Seitenbestand und der bereits geöffnete Browserentwurf wurden nicht für Tests geändert.

Die folgenden Abschnitte dokumentieren die früheren Entwicklungsstände und deren damalige Messungen.

## Ergänzung: erster visueller Editor, 12.09.2026

Die folgenden Ergebnisse betreffen den neuen Editor; die ursprüngliche Phase-0-Messung bleibt darunter als Ausgangsstand erhalten.

- **27 PHP-Tests, 105 Assertions**, erfolgreich unter PHP 8.2.12 und 8.4.22. Ergänzt: geschützte Admin-/API-Routen, Login-CSRF und falsches Passwort, CSRF für alle Schreib-/Vorschauaktionen, Editor ohne Veröffentlichungsrecht, HTTP-422/409-Behandlung, konkrete Revisionsprüfung, privater Entwurf und anschließende Veröffentlichung, Logout-CSRF, Passwort-Rehash und Sessioninvalidierung bei Rollenänderung.
- **5 JavaScript-Modelltests** für Undo/Redo samt Speicherpunkt, Zusammenfassung von Texteingaben, unveränderte History-Snapshots, neue IDs beim Duplizieren, Zyklenschutz beim Verschieben und identischen JSON-Roundtrip.
- **End-to-End-Editorprüfung** mit Playwright: echte Formularanmeldung, Klickauswahl im Iframe, Eigenschaftenänderung und Live-Vorschau, Undo/Redo, Einfügen/Duplizieren/Verschieben einschließlich Drag-and-drop/Löschen, Speichern und identisches Neuladen, Entwurfsprivatheit, separate Veröffentlichung, Escape/Fokusrückkehr im Dialog, abgefangener Netzwerkabbruch mit erneutem Speichern, 409-Konflikt ohne Verlust lokaler Änderungen, JSON-Download und bestätigtes Laden des Serverstands. Eigene Testdatenbank und Zufallszugänge unter `var/browser-tests`; echte Seiten und Benutzer bleiben durch diese Tests unverändert.
- axe-core: keine gefundenen Verstöße in Login, Seitenübersicht, Desktop- und Mobil-Editor sowie separat in der bearbeiteten öffentlichen Ausgabe. Die scriptgesperrte Vorschau kann den axe-Frameworker nicht ausführen. Der Frameinhalt wird deshalb in der Editor-axe-Prüfung ausgeschlossen und seine identische öffentliche Ausgabe separat geprüft; die Frameauswahl und Bearbeitung sind weiterhin funktional im realen Sandbox-Iframe getestet. Diese Einschränkung ist keine vollständige Barrierefreiheitsabnahme.
- Visuell geprüft: Editor-Desktop bei 1600 × 1100 und Mobil bei 390 × 844, Screenshots unter `reports/editor`. Scrollbereich ist per Tastatur fokussierbar. Keine horizontalen Überläufe in der Mobilprüfung.
- Öffentliche Browser-Regr​ession: alle drei unveränderten Beispielseiten bei 1440 und 390 px erfolgreich, kein Editor-JavaScript und kein zusätzliches Session-Cookie auf der öffentlichen Route.
- Erneute **Lighthouse-13.4.1-Messung** mit drei echten Mobil-/Desktop-Läufen im Produktionsmodus: jeweils 100 in allen fünf Kategorien. LCP-Mediane jetzt mobil 803 ms, Desktop 252 ms, CLS 0 und TBT 0 ms. Gleiches kleines lokales Testszenario und dieselben Grenzen wie unten; keine reale Kundenabnahme oder Felddaten. Metadaten: `docs/quality/editor-public-lighthouse.json`.
- Composer Audit ohne bekannte Advisories; Composer-Validierung, PHP-Formatierung, Twig-/YAML-/Containerprüfung, JavaScript-Syntaxprüfung erfolgreich. CI wurde um Modell- und Editorprüfungen ergänzt, aber nicht extern ausgeführt. MySQL/MariaDB/Hosting bleiben ungetestet.

Der lokale Benutzer `umut` wurde getrennt von den Tests auf ausdrücklichen Nutzerwunsch angelegt und im In-App-Browser angemeldet. Keine Zugangsdaten in Quellen oder Dokumentation abgelegt.

---

Datum: 12.09.2026. Ziel: `http://127.0.0.1:8080/`. Diese Messung betrifft ausschließlich die lokale KantSites-Demoseite, keine bestehende Kundenwebsite und nicht `kant-it.de`.

## Tatsächlich ausgeführte Prüfungen

- PHPUnit 11.5.56: 19 Tests, 35 Assertions erfolgreich unter PHP 8.2.12 und PHP 8.4.22. Dokument-Roundtrip, Entwurfsprivatheit, abgewiesene veraltete Schreibzugriffe, Transaktionsrollback, fremde Revisionen, Wiederherstellung, XSS-Maskierung, ungültige URLs/Designwerte/Block-IDs, Canonical, 404 und verweigerte HTTP-Schreibmethoden.
- Composer-Validierung, PHP-Formatprüfung, Twig-/YAML-/Containerprüfung und produktiver Cacheaufbau erfolgreich. Composer Audit und npm install meldeten keine bekannten Paketlücken zum Prüfzeitpunkt.
- Frische Kopie der für Git vorgesehenen Quellen unter `var/fresh-check`: `composer install --no-dev`, Setup, erste Migration, Seeding zweimal, Produktionscache und Symfony-Request erfolgreich. Gespeicherter Inhalt erscheint mit HTTP 200; zweites Seeding verändert vorhandene Seiten nicht.
- Playwright 1.63.0 / Chromium 153.0.8010.12 und axe-core 4.13.0: `/`, `/grundlagen`, `/projektstand`, jeweils mit 1440 und 390 px Breite; keine axe-Verstöße in den ausgewählten WCAG-2-A/AA-, WCAG-2.1-AA- und Best-Practice-Regeln. Je Kombination 29 bestandene axe-Prüfungen. Kein horizontaler Überlauf oder JavaScript-Seitenfehler.
- Automatisierte Tastaturprüfung des Sprunglinks und Navigation, zusätzlich Navigation mit deaktiviertem JavaScript erfolgreich. Desktop- und Mobil-Screenshots der Startseite visuell durchgesehen.

## Lighthouse

Lighthouse 13.4.1, Chromium Headless 153.0.8010.12 unter Windows; PHP 8.4.22 mit `APP_ENV=prod`, `APP_DEBUG=0`, vorgewärmtem Symfony-Cache, SQLite, lokalem PHP-Entwicklungsserver. Vollständige gespeicherte HTML-Inhalte, keine externen Dienste, keine Editor-Ressourcen. Netzwerk-/CPU-Drosselung simuliert. Drei Läufe je Profil, Median:

| Profil | Leistung | Barrierefreiheit | Best Practices | SEO | Agentisches Browsing | LCP | CLS | TBT |
| --- | ---: | ---: | ---: | ---: | ---: | ---: | ---: | ---: |
| Mobil | 100 | 100 | 100 | 100 | 100 | 797 ms | 0 | 0 ms |
| Desktop | 100 | 100 | 100 | 100 | 100 | 261 ms | 0 | 0 ms |

Alle sechs endgültigen Läufe hatten diese Kategoriescores. Mobil: 412 × 823 px, DPR 1,75, RTT 150 ms, 1.638,4 Kbit/s Durchsatz, CPU-Faktor 4. Desktop: 1350 × 940 px, DPR 1, RTT 40 ms, 10.240 Kbit/s Durchsatz, CPU-Faktor 1. Detailparameter und Umgebungsmetadaten stehen in `docs/quality/lighthouse-summary.json`. Das Skript prüft die tatsächliche `formFactor`-Einstellung und lehnt indexierungsgesperrte Antworten vor dem Audit ab.

Agentisches Browsing: Die anwendbaren Prüfungen `agent-accessibility-tree` und `cumulative-layout-shift` bestanden. `webmcp-form-coverage`, `webmcp-registered-tools`, `webmcp-schema-validity` und `llms-txt` waren **nicht anwendbar**, nicht als implementierte Funktionen bestanden. Es gibt noch keine Formulare, WebMCP-Tools oder llms.txt.

## Grenzen und noch ausstehende Abnahme

- Die kleine Demoseite hat bewusst keine echten Kundenbilder, Blogbeiträge oder Formulare. Deshalb ist sie nur eine technische Regressionsbasis und erfüllt noch nicht die im Plan geforderte repräsentative Referenzsuite. Die Werte nicht als Leistungsnachweis für Kundenwebsites verwenden.
- INP und die Core-Web-Vitals-Feldwerte am 75. Perzentil sind unbekannt. Der gemessene TBT ist kein INP. Es gibt keine realen Nutzungsdaten.
- Manuelle Screenreader-Prüfung, vollständige manuelle Tastatur-/Kontrast-/Zoomprüfung, Dialoge, Formulare und responsive Editorabläufe fehlen. Visuelle Screenshotkontrolle und automatisierte axe-Prüfungen ersetzen sie nicht.
- MySQL-/MariaDB-Betrieb, Apache-Rewrites, tatsächliches PHP-Webhosting, HTTPS-Konfiguration, Restore und externe CI-Ausführung wurden nicht getestet. Ein MySQL-Smokejob ist vorbereitet.
- GEO, Auffindbarkeit und Zitierung in KI-Antworten wurden nicht geprüft. Keine Ranking- oder Zitiergarantie.
- Die rohe Auditserie und Browser-Screenshots liegen lokal in `reports/` und sind nicht für Git vorgesehen. Die kompakte Zusammenfassung und dieser Bericht werden mit den Quellen abgelegt.

## Im Verlauf behoben

Mobiler Textüberlauf bei langen deutschen Wörtern; fehlende Übernahme realer Prozessvariablen bei PHP-Konfiguration ohne `E` in `variables_order` (dadurch blieb Debug/noindex aktiv); anfänglich falsch übergebener Desktop-Preset an die Lighthouse-Programmierschnittstelle; unter Windows gesperrte temporäre Testdatenbank sowie Cleanup des anfänglichen Chrome-Launchers. Die endgültigen oben dokumentierten Prüfungen liefen nach diesen Korrekturen erfolgreich.