Jeder Check aus dem PR-Report im Detail — was geprüft wird, wie ein Finding aussieht und was du dann tust. Die Check-Namen im Report verlinken direkt hierher.
Sucht in den neuen Zeilen des Diffs nach Klartext-Zugangsdaten: Passwörter, API-Keys, Tokens (inkl. bekannter Präfixe wie ghp_, sk-). Einmal gepusht = kompromittiert — auch wenn der Commit später entfernt wird.
Secret aus dem Code nehmen (z. B. !secret/ENV/Secret-Store), und das Secret rotieren — es war öffentlich. Fehlalarm auf Beispiel-Werten? Pfad per ignore: ausnehmen.
Findet übrig gebliebene Git-Konflikt-Marker (<<<<<<<, =======, >>>>>>>) in neuen Zeilen — die klassische Folge eines hastig gelösten Merge-Konflikts, die Configs/Code sofort bricht.
Konflikt an der Stelle sauber auflösen, Marker-Zeilen entfernen, erneut pushen.
Warnt, wenn sensible Dateien in den PR geraten: .env, private Keys/Zertifikate, Datenbanken, HA-.storage-Dateien. Solche Dateien gehören fast nie ins Repo.
Datei aus dem PR entfernen + in .gitignore aufnehmen. Enthielt sie echte Secrets: rotieren.
Ein LLM (aktuell Claude) liest den kompletten Diff gegen die echten Projekt-Konventionen und findet Logik-Fehler, die kein Linter sieht — Race-Conditions, Restart-Fallen, falsche Modi, vergessene Randfälle. Findings kommen als zeilengenaue Inline-Kommentare mit Begründung + Fix-Vorschlag.
Antworte direkt auf das Finding — der Bot begründet oder zieht zurück (und resolved dann den Thread). Steuerbar per ai-review.focus / ai-review.severity in der .codemole.yml.
Misst den Umfang des PRs (Zeilen/Dateien). Warnt ab +1000 Zeilen oder >30 Dateien — XXL-PRs sind schwer reviewbar und fehleranfällig.
Wenn möglich in kleinere, thematisch getrennte PRs aufteilen.
yamllint mit HA-tauglichen Regeln — und nur auf den Zeilen, die der PR ändert. Kosmetik-Regeln (line-length, on/off-truthy, Kommentar-Stil) sind aus; echte Fehler (Parse-Fehler, doppelte Keys, Trailing Spaces) sind an. Bestands-Altlasten der Datei zählen nicht.
Die gemeldete Zeile fixen — die Meldung enthält Datei:Zeile:Regel.
Validiert die komplette HA-Konfiguration mit einem aktuellen HA-Core (2026.x) — Schema-Fehler, unbekannte Optionen, kaputte Automationen. Zwei-Pass: Base und Branch werden geprüft, gemeldet werden nur neue Fehler; Umgebungs-Bestandsfehler (z. B. „Unknown device", fehlende Systemlibs) zählen nicht.
Der Fehlertext steht im Report — genau die gemeldete Stelle korrigieren.
Prüft geänderte !include/!include_dir_*-Referenzen: zeigt eine neue Referenz auf eine Datei, die es nicht gibt, startet HA mit kaputter Config.
Datei anlegen oder die Referenz korrigieren.
Prüft neue !secret name-Referenzen gegen secrets.yaml — eine Referenz auf ein nicht definiertes Secret bricht den HA-Start.
Secret in secrets.yaml (auf der Instanz) ergänzen oder den Namen korrigieren.
Findet doppelte Automation-ids und -aliase. Duplikate überschreiben sich still gegenseitig — eine der Automationen ist dann einfach weg, ohne Fehlermeldung.
Eine der beiden umbenennen (id UND alias eindeutig halten).
Fängt zwei klassische HA-Fallen in geänderten Zeilen: (1) State-Trigger mit to: aber ohne from: — feuert beim HA-Neustart, weil Entities von unavailable auf ihren Zustand springen (real passierter Bug: Schlafmodus ging nachts im ganzen Haus aus). (2) device_id: statt entity_id: — überlebt keinen Geräte-Austausch.
from: "off" (bzw. den echten Vorzustand) ergänzen; device_id durch die entity_id ersetzen.
Prüft jede in neuen Zeilen referenzierte entity_id live gegen deine HA-Instanz (/api/states) — fängt Tippfehler, die häufigste Fehlerklasse überhaupt. Templates und !secret-Zeilen werden übersprungen.
ha_url + verschlüsselter ha_token in der .codemole.yml — Token mit dem Secrets-Tool im Browser verschlüsseln, kein Server-Zugriff nötig.
Kompiliert jede geänderte .py-Datei (py_compile) — Syntaxfehler fliegen sofort auf, bevor HA die Integration lädt.
Datei lokal ausführen/kompilieren, Fehler fixen.
Ruff-Lint auf den geänderten Python-Dateien — Style, ungenutzte Importe, häufige Bugs (z. B. Blocking-Calls, die in HA in den async-Loop gehören).
ruff check --fix lokal laufen lassen, Rest manuell.
Prüft die manifest.json jeder Komponente auf die HA-Pflichtfelder (domain, name, version, documentation, issue_tracker, codeowners, requirements, iot_class) + gültiges JSON.
Fehlende Felder ergänzen — ohne version lädt HA Custom-Components gar nicht.
Prüft die hacs.json fürs HACS-Listing (mind. name-Feld). Ohne sie ist die Integration über HACS schlecht/nicht installierbar.
hacs.json mit {"name": "…"} ins Repo-Root.
Stellt sicher, dass translations/en.json existiert (Pflicht-Sprache) und alle anderen Sprachdateien dieselben Keys haben — fehlende Keys erscheinen im UI als rohe Platzhalter.
Fehlende Keys in der gemeldeten Sprache nachziehen (en.json ist die Referenz).
Jede geänderte .json muss parsen — ein Komma zu viel in strings.json bricht sonst die ganze Integration.
JSON an der gemeldeten Stelle reparieren.
Schlägt an, wenn Dateien gelöscht, geleert oder auffällig geschrumpft werden (>80 % weniger Zeilen) — schützt vor versehentlichem Wegwerfen von Code beim Rebase/Merge.
Prüfen, ob das Absicht war; sonst Datei wiederherstellen. Bewusste Löschungen per PR-Label/Beschreibung kenntlich machen.
Die PR-Beschreibung braucht die Pflicht-Abschnitte: Problem, Fix, Before-/After-URL — sonst ist der PR fürs (Kunden-)Review nicht nachvollziehbar.
Beschreibung vervollständigen (Template nutzen); der Check läuft beim nächsten Push erneut.
ESLint + Stylelint auf den geänderten Dateien mit dem EDS-Regelwerk (z. B. Imports mit .js-Endung, keine ungenutzten Variablen).
Lokal npx eslint <datei> / npx stylelint laufen lassen und fixen.
Neue i18n-Platzhalter im Code müssen in den Placeholder-Sheets (jumo.json …) existieren — sonst rendert die Seite rohe Keys.
Keys im Sheet ergänzen (oder projektweite Ausnahme in testing-rules.json).
Führt die Jest-Unit-Tests der geänderten Blocks aus (tests/unit/…). Kein Test für einen geänderten Block → Skip-Hinweis.
Fehlschläge fixen; für neue Logik-Blöcke Tests anlegen.
Visuelle Regression pro Block: Playwright-Screenshots gegen committete Baseline-Bilder. Atoms (button, text, image, link) triggern über block-deps.json automatisch die Tests aller Organisms, die sie einbetten.
Diff prüfen: gewollte Änderung → Baseline aktualisieren (npm run test:visual:update + committen); ungewollt → CSS fixen. Neuen Spec anlegen: Anleitung.
Misst, wie weit der Branch hinter seiner Base hängt. >10 Commits = Warnung, >30 = Fehler — je älter der Stand, desto größer das Konflikt-/Regressionsrisiko beim Merge.
git rebase origin/<base> (oder Base mergen) und pushen.
Statische EDS-Regeln: keine Framework-Imports (React/Vue/jQuery), kein outline: none (WCAG), JS-Bundle-Zuwachs-Warnung (>10 KB) und Token-Compliance — hardcodierte Hex-/rgba-Farben statt var(--…) in neuen CSS-Zeilen (Design-Token-Pflicht).
Farbe durch das passende Design-Token ersetzen (Token-Definitionen selbst, --x: #abc;, sind erlaubt). Opt-out projektweit: hardcoded-colors-Ausnahme in testing-rules.json.
Prüft jede geänderte .php-Datei mit php -l auf Syntaxfehler — fällt sofort auf, bevor WordPress den fatalen Parse-Error wirft. Zeigt Datei & Zeile, auch als Inline-Kommentar.
Fehler an der genannten Zeile beheben (fehlendes ;, Klammer etc.).
Prüft die geänderten .php-Dateien mit phpcs auf sicherheitsrelevante WPCS-Regeln — Output-Escaping, Nonce-Prüfung, Input-Sanitization/-Unslashing, Prepared-SQL. Zwei-Pass: nur neue/geänderte Zeilen — kein Stil-Rauschen, kein Legacy-Ballast. Funde als Inline-Kommentar (gedeckelt auf 20).
Sicherheitslücke schließen: Ausgaben escapen (esc_html()/esc_attr()), Eingaben sanitizen + wp_unslash(), Nonce prüfen, SQL via $wpdb->prepare(). Sniff-Umfang anpassen: env PHPCS_SNIFFS (leer = voller WPCS).
Rendert die konfigurierten Seiten auf Base- und Branch-Preview und prüft mit axe-core (WCAG 2.1 A/AA + Best Practice): Kontrast, Button-/Formular-Labels, Landmarks, Heading-Struktur, Alt-Texte. Gemeldet werden nur neue Findings; Timing (DCL/Load/KB) läuft informativ mit.
page-audit.base_url (mit {branch}-Platzhalter) + pages in der .codemole.yml — Beispiel.
Voller Lighthouse-Vergleich (Performance/A11y/Best-Practices/SEO + LCP/CLS) zwischen Base- und Branch-Preview. Läuft nie automatisch — nur wenn du das Label lighthouse an den PR hängst (Re-Run: Label entfernen + neu setzen). Self-hosted, keine Google-API.
Einmal vor Review/Merge bei performance-relevanten PRs (CSS/JS/Bilder/Fonts). Scores schwanken CDN-bedingt ±2–3 Punkte. Details.