Frontend-Readiness

Frontend-Readiness (Frontend-Bereitschaft)

Aufruf als $frontend-readiness diff, $frontend-readiness pr <URL>, $frontend-readiness release oder $frontend-readiness full.

Verwende die Regeln für Modus, Nachweis, Urteil und Bearbeitung aus check-readiness. Bei direktem Aufruf wähle dort einen Modus aus. Wenn von check-readiness aufgerufen, behalte dessen ausgewähltes Ziel bei. Bewerte nur Frontend-Oberflächen.

Bewerte die Prüfungen, die für das gewählte Ziel zutreffen. Markiere eine nicht zutreffende Ausnahme mit N/A und einer Begründung. Ein Abschnitt, der nicht zutrifft (z.B. nicht-öffentliche App bei Suche und Teilen, kein Framework bei Framework-Konventionen), wird mit einer einzigen N/A-Zeile markiert, nicht mit einer pro Prüfung.

Blockierende Bereiche: Unterbrochener kritischer Ablauf oder Route, Auth- und Berechtigungs-UI, unsicheres Rendern von Benutzerinhalten, durchgesickerte Geheimnisse, Barrierefreiheitsfehler bei kritischen Abläufen, fehlende Fehler- oder Leerzustände auf datengesteuerten Oberflächen, fehlgeschlagener Build oder Tests. Andere Fehler sind als Empfehlung zu werten.

Korrektheit

• Jede relevante Route wird durch direkte Navigation, Neuladen, In-App-Navigation, Zurück und Vorwärts gerendert.
• Jeder kritische Ablauf durchläuft den Happy Path und bewahrt nützliche Eingaben bei behebbaren Fehlern.
• Formulare validieren Eingaben, verhindern doppelte Übermittlungen, zeigen umsetzbare Fehler an und machen Fehler für assistive Technologien zugänglich.
• Client-, Server-, URL- und persistierter Zustand bleiben konsistent bei Neuladen, Abbrüchen, veralteten Antworten und wiederholten Aktionen.
• Die Konsole enthält keine neuen Fehler oder Warnungen; fehlgeschlagene Netzwerkanfragen werden erklärt.
• Auth- und Berechtigungsgrenzen zeigen korrekte UI, bewahren die beabsichtigten Rückkehr-Routen und behandeln abgelaufene Sitzungen, verbotene Antworten und Rollenwechsel.

Jede datengesteuerte Oberfläche hat eine explizite Zustandsmatrix. Markiere einen Zustand nur dann mit N/A, wenn er nicht auftreten kann oder keinen nutzerrelevanten Wert bietet.

• Leer: Erfolgreiches Null-Ergebnis erklärt, was passiert ist, und bietet eine nützliche nächste Aktion.
• Laden: Der Fortschritt ist klar, nützliche vorhandene Inhalte bleiben stabil und wiederholte Aktionen bleiben kontrolliert.
• Skelett: Wo das endgültige Layout vorhersagbar und die Verzögerung wahrnehmbar ist, entsprechen Platzhalter diesem Layout und vermeiden Layout-Verschiebungen; andernfalls N/A eintragen.
• Teilweise: Verfügbare Inhalte bleiben nutzbar, während unabhängige Abschnitte laden oder fehlschlagen.
• Fehler: Die Nachricht ist umsetzbar, nützliche Eingaben bleiben erhalten und Wiederholung oder Wiederherstellung funktioniert.

Framework-Konventionen

Überspringe Punkte für Frameworks, die das Projekt nicht verwendet; nenne das erkannte Framework und die Version.

• Framework-, Router- und Datenlade-APIs entsprechen der installierten Version und den bestehenden Projektkonventionen; notiere die Version und die Quelle der Wahrheit.
• Interne Navigation verwendet die erkannte Framework-Komponente für Links, wie Link von next/link oder @tanstack/react-router; natives <a> behandelt externe, Download-, E-Mail- und Telefonlinks.
• Routenparameter, Suchparameter, Weiterleitungen und Navigation verwenden die Framework-Router-APIs und Hooks.
• Statische und dynamische Styles folgen dem bestehenden, vom Framework unterstützten Styling-System; dynamische Werte verwenden CSS-Custom-Properties, es sei denn, bibliotheksbedingte Positionierung erfordert Inline-Styles.

Schnittstelle und Barrierefreiheit

• Layout funktioniert bei jedem aufgezeichneten Viewport ohne unbeabsichtigten Überlauf. Lange Texte, fehlende Medien, langsame Daten und große Sammlungen bleiben nutzbar.
• Hierarchie, Abstände, Typografie, Farben und interaktives Feedback sind konsistent; Steuerelemente decken die Zustände Hover, Fokus, Aktiv, Deaktiviert, Laden und Fehler ab.
• Zerstörerische Aktionen erfordern eine klare Absicht und bieten, wo praktikabel, Wiederherstellungsmöglichkeiten.
• Semantische Landmarken, Überschriften, Steuerelemente, Labels und zugängliche Namen entsprechen dem Zweck.
• Die reine Tastaturbedienung erreicht und bedient jedes interaktive Element in logischer Reihenfolge; der Fokus bleibt sichtbar und bewegt sich korrekt durch Dialoge, Menüs, Fehler und Routenwechsel.
• Text und essentielle UI erfüllen das aufgezeichnete Barrierefreiheitsziel (WCAG 2.2 AA, sofern keine strengere Anforderung gilt); die Bedeutung hängt nicht nur von der Farbe ab.
• Bilder haben geeignete Alternativen; dekorative Medien bleiben stumm. Zoom, Textvergrößerung, reduzierte Bewegung und erforderliche Screenreader-Ansagen bewahren den Ablauf.

Resilienz, Datenschutz und Sicherheit

• Benutzergesteuerte Inhalte werden sicher gerendert; Geheimnisse und privilegierte Entscheidungen bleiben serverseitig.
• Externe Links, Weiterleitungen, Uploads, Speicher und Browser-APIs validieren nicht vertrauenswürdige Eingaben. Externe Tabs verwenden sicheres Opener-Verhalten, wo zutreffend.
• Offline- und Timeout-Verhalten vermeidet Datenverlust.
• Fehler-UI verbirgt sensible Interna, während Logs genügend diagnostischen Kontext behalten.
• Authentifizierungs- oder personenbezogene Datenprodukte machen öffentliche AGB- und Datenschutzseiten über Auth und persistente Navigation zugänglich; der Inhalt entspricht dem tatsächlichen Verhalten.
• Cookies, CSRF-Abwehr, Antwort-Sicherheitsheader, Weiterleitungen und Cache-Richtlinien werden überprüft, wenn die Anwendung sie kontrolliert.
• Analysen, Fehlerverfolgung und Zustimmung respektieren die Datenschutzanforderungen und geben keine persönlichen oder geheimen Daten preis.
• Feature-Flags haben einen verifizierten Wert für die Zielumgebung und, bei riskanten Änderungen, einen dokumentierten Rollback- oder Deaktivierungspfad.

Performance und Assets

• Repräsentative Routen werden aus einem Production-Build in der aufgezeichneten Umgebung gemessen, unter Verwendung von TTFB, LCP, INP, CLS, erstem nützlichem Inhalt und primärem Interaktions-Timing.
• Jede relevante Route zeigt nützlichen Inhalt oder einen umsetzbaren Fallback und akzeptiert ihre primäre Interaktion innerhalb des aufgezeichneten Budgets; fünf Sekunden sind der Standard nur, wenn kein strengeres Produktbudget existiert.
• Production-Build-Ausgabe, Route-Chunks und Netzwerk-Wasserfall enthalten keine unerklärten hohen Kosten.
• Geänderte Performance-Optimierungen haben einen gemessenen Nutzen und bewahren, wo zutreffend, Tastatur-, Fokus-, Screenreader- und Offline-Verhalten.
• Effekte geben Listener, Abonnements, Observer, ausstehende Requests, Worker, Timer, Animationsframes und debounced oder throttled Arbeit frei, wenn sich Abhängigkeiten ändern oder Komponenten unmounten.
• Bilder nutzen verfügbare Framework-Optimierung, responsive Abmessungen und sizes, moderne Formate, Komprimierung, stabile Seitenverhältnisse und korrekte eager/lazy-Priorität. Video und Schriftarten haben eine durchdachte Auslieferung, Fallbacks und Preload-Verhalten.
• Drittanbieter-, Inline- und blockierende Skripte haben einen expliziten Zweck und eine explizite Lade-Priorität.

Suche und Teilen

Gilt nur für öffentliche oder teilbare Routen; rein authentifizierte Apps benötigen nur die Nicht-Indexierungs-Prüfung.

• Jede Route definiert geeignete Titel- und Beschreibungs-Metadaten. Öffentlich indexierbare Routen setzen kanonische und Robots-Intention über Framework-APIs; Nicht-Produktions- und geschützte Umgebungen werden nicht versehentlich indexiert.
• Teilbare Routen lösen Open-Graph- und Social-Media-Metadaten in absolute, crawlable Werte auf. OG-Bilder geben den korrekten Inhaltstyp, die Abmessungen und den Alternativtext zurück; gerenderte Tags und eine echte Teilen-Vorschau werden verifiziert.
• Für ein Release-Gate führt Lighthouse gegen deployed Production-Routen auf aufgezeichneten mobilen und Desktop-Profilen durch; Performance, Accessibility, Best Practices und SEO-Ergebnisse und Regressionen werden aufgezeichnet.

Entwicklung und Deployment

• Formatierer, Lint, Typecheck, Tests und Production-Build bestehen oder haben eine explizite Baseline für Fehlschläge.
• Geänderte Logik hat den kleinsten nützlichen automatisierten Regressionstest.
• Umgebungsvariablen, Feature-Flags, API-URLs, Browser-Support und Testkonten entsprechen der Zielumgebung.
• Fehlerverfolgung, Favicons und Installationssymbole funktionieren, wo das Produkt sie erfordert.
• Für ein Release-Gate oder eine deployment-relevante Änderung werden deployed Assets, Routen, APIs, Auth, Header, Weiterleitungen und Cache-Verhalten in der Zielumgebung verifiziert.