KantSites/docs/QUALITY.md

Qualitätsbericht – erster ausführbarer Prototyp

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 Kant-CMS-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.