Deep-Check – PHP in 10er-Batches systematisch durchleuchten
Datum: 2026-06-01
„Prüf mal src/“ ist zu groß
Ein offener Auftrag über alle PHP-Dateien führt dazu, dass die KI Dateien überspringt, PHPDoc vergisst, Services in falsche Ordner legt und nach zwei Stunden „fertig“ sagt – mit halbfertigem `src/`. Skalierung braucht Batch-Größe und Wiederholung.
Deep-Check arbeitet 10 PHP-Dateien pro Batch mit Ralph-Loop bis Konvergenz – systematisch, loggbar, wiederholbar.
Das Problem
| Großer Scope | Folge |
|---|---|
| Ganzes `src/` | Oberfläche, Lücken |
| Keine Batch-Grenze | Kontext-Überload |
| Kein Loop | Erste Runde „gut genug“ |
| Keine Logs | Unklar was geprüft wurde |
Code-Qualität skaliert nur in kleinen, wiederholbaren Häppchen.
Das Pattern
php start-vendor-deep-check.php
001. Sammelt PHP-Dateien unter `src/` (projekteigen).
002. Verarbeitet max. 10 Dateien pro Batch.
003. Ruft `subagent-deep-check-src-php` im Ralph-Loop auf.
004. Nächster Batch erst nach Konvergenz (`OPEN_FAILURES=0`, `CHANGED_FILES=0`).
Prüfkriterien pro Datei (Auszug)
| Bereich | Inhalt |
|---|---|
| Naming | Klassen-, Methoden-, Ordnerkonventionen |
| Schicht | Service vs. Orchestrator vs. Model |
| PHPDoc | Deutsch, Klasse, Konstanten, jede Methode |
| Platzierung | Keine falsch platzierten Services |
| Provenance | `@skill-change-provenance` bei Änderungen |
So sieht es bei uns aus
Der Deep-Check läuft im Vendor-Workflow:
001. `CLIDeepCheckOrchestrator` steuert Batches.
002. Env-Flags: `DEEP_CHECK_SUPPRESS_RALPH_LOOP_CLEAR`, `DEEP_CHECK_TOTAL`, `DEEP_CHECK_INDEX`, `DEEP_CHECK_SRC_PHP_REL` für verschachtelte Loops und Fortschrittsanzeige.
003. Logs unter `logs-start-vendor-deep-check/`.
Nach einem großen Refactor oder vor Release: Deep-Check über gesamtes `src/` – dauert, aber vollständig.
Warum 10er-Batches?
| Batch-Größe | Effekt |
|---|---|
| 1 | Sehr langsam, maximal fokussiert |
| 10 | Balance Kontext / Tiefe (unser Standard) |
| 50+ | Wieder „prüf mal src/“ |
Zehn Dateien passen in den Agent-Fokus; PHPDoc und Schichten werden pro Datei ernst genommen.
Verzahnung mit anderen Checks
Deep-Check ersetzt nicht:
001. `subagent-check-orchestrator` – Briefing-Adjazenz
002. `subagent-check-translations` – i18n
003. `start-vendor-phpunit-tests.php` – Laufzeit
Deep-Check ist Code-Hygiene und Struktur in `src/`.
Anti-Patterns
001. Einmalig alles manuell lesen – Nicht skalierbar.
002. Nur PHPDoc im Chat fixen – Nicht versioniert, nicht vollständig.
003. Batch abbrechen bei Runde 2 – Drift bleibt in restlichen Dateien.
004. Vendor-`src/` deep-checken – Host prüft Host-Code; Vendor über Composer.
005. Deep-Check ohne Ralph – Erste Runde unvollständig.
Häufige Fragen
Wie oft laufen lassen?
Nach größeren Agent-Refactorings, vor Major-Release, oder rotierend im Cron (Teilbatches).
Was wenn eine Datei blockiert?
Blocker dokumentieren, Scope verkleinern, Briefing klären – nicht Batch-Skip heimlich.
Zusammenhang mit `subagent-check-comments`?
Überlappung PHPDoc – Deep-Check ist Batch-orientiert mit Schichten-Fokus.
Verwandte Beiträge
| Beitrag | Thema |
|---|---|
| Ralph-Loop | Konvergenz pro Batch |
| Subagents | `subagent-deep-check-src-php` |
| Briefing-First | Spec vor Code |
| Self-Testing | Nach Struktur-Fixes |
Takeaway
Code-Qualität skaliert nur in kleinen, wiederholbaren Häppchen. Deep-Check mit 10er-Batches und Ralph-Loop macht „ganz src/“ zu einer fabrikfähigen Schleife – nicht zu einem Wunsch im Chat.
Vertiefung: Deep-Check – PHP in 10er-Batches systematisch durchleuchten im Projektalltag
In unserem Repository ist agentic deep check kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic deep check ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.
Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.
Entscheidungshilfe: Wann welcher Hebel?
| Situation | Empfohlener Hebel | Erwartetes Ergebnis |
|---|---|---|
| Wiederholter Architekturfehler | Rule in `cursor-rules/rules/` | Modell hält Grenze dauerhaft ein |
| Komplexer mehrstufiger Ablauf | Skill `@skill-*` + Subagent | Checkliste statt Einmal-Prompt |
| Großes Feature mit mehreren Screens | `features/` + `start-vendor-feature.php` | Checkpoints bis deploybar |
| Einzelner Screen rot (curl 500) | `subagent-fix-fehler-und-test` | HTTP 200 + grüne Tests |
| Unklare Spec | Briefing-First in `briefing/` | Keine erfundenen Defaults im Code |
Architektur- und Review-Perspektive (Teil 2)
Teams, die agentic deep check produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.
| Review-Fokus | Prüffrage | Typischer Subagent |
|---|---|---|
| Screen-Schicht | Ruft PHP nur den Orchestrator auf? | `subagent-check-screens` |
| Orchestrator | Steps nummeriert, Briefing-Sync? | `subagent-check-orchestrator` |
| Services | Kein try-catch, keine array-Returns? | `subagent-check-services` |
| Repositories | SQL-Logging, Indizes, PHPDoc UI-Nutzung? | `subagent-check-repos` |
| Translations | Keys in Twig korrekt? | `subagent-check-translations` |
Betrieb, Logs und Nachvollziehbarkeit (Teil 3)
Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-deep-check` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.
Praxis-Checkliste vor Freigabe
001. Markdown unter `briefing/blog/blogposts/2026-06-01-agentic-deep-check/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-06-01-agentic-deep-check/` vorhanden.
003. Route `/blog/agentic-deep-check` in `config/routing/routes-project-config.php` eingetragen.
004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.
005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.
006. `curl http://localhost:{PORT}/blog/agentic-deep-check` liefert HTTP 200.
Erweiterte FAQ und Takeaway (Teil 4)
Wie vermeide ich stille Fallbacks?
Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.
Was ist mit Vendor-only-Code?
Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.
Wie halte ich Translations synchron?
Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.
| Merksatz | Bedeutung für agentic deep check |
|---|---|
| Briefing-First | Spec vor Code, immer |
| Ralph-Loop | Konvergenz statt „fertig“-Behauptung |
| curl + PHPUnit | Beweis statt Chat-Grün |
| Keine Emojis | Professioneller Ton in Code und UI |
agentic deep check skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-deep-check` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.
Vertiefung (Teil 5): Deep-Check – PHP in 10er-Batches systematisch durchleuchten im Projektalltag
In unserem Repository ist agentic deep check kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic deep check ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.
Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.
Entscheidungshilfe: Wann welcher Hebel?
| Situation | Empfohlener Hebel | Erwartetes Ergebnis |
|---|---|---|
| Wiederholter Architekturfehler | Rule in `cursor-rules/rules/` | Modell hält Grenze dauerhaft ein |
| Komplexer mehrstufiger Ablauf | Skill `@skill-*` + Subagent | Checkliste statt Einmal-Prompt |
| Großes Feature mit mehreren Screens | `features/` + `start-vendor-feature.php` | Checkpoints bis deploybar |
| Einzelner Screen rot (curl 500) | `subagent-fix-fehler-und-test` | HTTP 200 + grüne Tests |
| Unklare Spec | Briefing-First in `briefing/` | Keine erfundenen Defaults im Code |
Architektur- und Review-Perspektive (Teil 6)
Teams, die agentic deep check produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.
| Review-Fokus | Prüffrage | Typischer Subagent |
|---|---|---|
| Screen-Schicht | Ruft PHP nur den Orchestrator auf? | `subagent-check-screens` |
| Orchestrator | Steps nummeriert, Briefing-Sync? | `subagent-check-orchestrator` |
| Services | Kein try-catch, keine array-Returns? | `subagent-check-services` |
| Repositories | SQL-Logging, Indizes, PHPDoc UI-Nutzung? | `subagent-check-repos` |
| Translations | Keys in Twig korrekt? | `subagent-check-translations` |
Betrieb, Logs und Nachvollziehbarkeit (Teil 7)
Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-deep-check` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.
Praxis-Checkliste vor Freigabe
001. Markdown unter `briefing/blog/blogposts/2026-06-01-agentic-deep-check/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-06-01-agentic-deep-check/` vorhanden.
003. Route `/blog/agentic-deep-check` in `config/routing/routes-project-config.php` eingetragen.
004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.
005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.
006. `curl http://localhost:{PORT}/blog/agentic-deep-check` liefert HTTP 200.
Erweiterte FAQ und Takeaway (Teil 8)
Wie vermeide ich stille Fallbacks?
Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.
Was ist mit Vendor-only-Code?
Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.
Wie halte ich Translations synchron?
Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.
| Merksatz | Bedeutung für agentic deep check |
|---|---|
| Briefing-First | Spec vor Code, immer |
| Ralph-Loop | Konvergenz statt „fertig“-Behauptung |
| curl + PHPUnit | Beweis statt Chat-Grün |
| Keine Emojis | Professioneller Ton in Code und UI |
agentic deep check skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-deep-check` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.
Vertiefung: Deep-Check – PHP in 10er-Batches systematisch durchleuchten im Projektalltag
In unserem Repository ist agentic deep check kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic deep check ernst nimmt, dokumentiert zuerst die Spezifikation, setzt danach Orchestrator, Services und Screens um und schließt mit `curl` sowie PHPUnit ab. Diese Kette verhindert, dass die KI nur im Chat Fortschritt simuliert, während Routing, Translations oder Briefings veraltet bleiben.
Konkret bedeutet das: Jede Änderung an Screens oder CLI-Skripten startet mit dem passenden Briefing unter `briefing/screens/` bzw. `briefing/CLIOrchestrator/`. Subagents wie `subagent-check-screens`, `subagent-check-orchestrator` oder `subagent-check-translations` prüfen Schicht für Schicht. Der Ralph-Loop (`RALPH_LOOP_CHANGED_FILES`, `RALPH_LOOP_CHANGED_FILE_LIST`) macht Konvergenz maschinenlesbar – rot bleibt rot, bis der Ist-Stand dem Briefing entspricht.
Entscheidungshilfe: Wann welcher Hebel?
| Situation | Empfohlener Hebel | Erwartetes Ergebnis |
|---|---|---|
| Wiederholter Architekturfehler | Rule in `cursor-rules/rules/` | Modell hält Grenze dauerhaft ein |
| Komplexer mehrstufiger Ablauf | Skill `@skill-*` + Subagent | Checkliste statt Einmal-Prompt |
| Großes Feature mit mehreren Screens | `features/` + `start-vendor-feature.php` | Checkpoints bis deploybar |
| Einzelner Screen rot (curl 500) | `subagent-fix-fehler-und-test` | HTTP 200 + grüne Tests |
| Unklare Spec | Briefing-First in `briefing/` | Keine erfundenen Defaults im Code |
Architektur- und Review-Perspektive (Teil 2)
Teams, die agentic deep check produktiv nutzen, behandeln Agent-Output wie menschlichen Code: Pull Request, Diff-Review, PHPUnit, curl. In PHP-Projekten mit strikter Schichtung (Screen → Orchestrator → ScreenServices → Repositories) darf die KI keine Abkürzungen einbauen – weder direkte Repository-Aufrufe im Screen noch Legacy-Ordner `src/Orchestrator/` ohne Freigabe in `briefing.md`. `@skill-screen-php-layer` und `@skill-orchestrators` definieren diese Grenzen; Subagents setzen sie durch.
| Review-Fokus | Prüffrage | Typischer Subagent |
|---|---|---|
| Screen-Schicht | Ruft PHP nur den Orchestrator auf? | `subagent-check-screens` |
| Orchestrator | Steps nummeriert, Briefing-Sync? | `subagent-check-orchestrator` |
| Services | Kein try-catch, keine array-Returns? | `subagent-check-services` |
| Repositories | SQL-Logging, Indizes, PHPDoc UI-Nutzung? | `subagent-check-repos` |
| Translations | Keys in Twig korrekt? | `subagent-check-translations` |
Betrieb, Logs und Nachvollziehbarkeit (Teil 3)
Agentic Engineering ohne Logs ist Blindflug. CLI-Workflows schreiben strukturierte Terminal-Ausgabe gemäß `006-cli-console-colors.mdc`; Live-SQL unter `logs-live-sql/` dokumentiert UI-Bezug pro Query. Bei Blogposts und Screens gilt: Nach jeder Template- oder PHP-Änderung `curl http://localhost:{PORT}/blog/agentic-deep-check` bis HTTP 200. Fehler-HTML analysieren, beheben, erneut prüfen – Regel 051 in `001-ki-behavior.mdc`.
Praxis-Checkliste vor Freigabe
001. Markdown unter `briefing/blog/blogposts/2026-06-01-agentic-deep-check/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-06-01-agentic-deep-check/` vorhanden.
003. Route `/blog/agentic-deep-check` in `config/routing/routes-project-config.php` eingetragen.
004. Translation-Dateien unter `translation/de/blog/` und `translation/en/blog/` mit passender `seo_description`.
005. Homescreen listet den Beitrag über `ScreenHome001BuildHomeScreenResponseService` automatisch.
006. `curl http://localhost:{PORT}/blog/agentic-deep-check` liefert HTTP 200.
Erweiterte FAQ und Takeaway (Teil 4)
Wie vermeide ich stille Fallbacks?
Regelwerk `020-no-fallbacks-no-defaults.mdc` und Skill `@skill-no-fallbacks-no-defaults`: fehlende Pflichtwerte müssen sichtbar werden, nicht mit `??` oder erfundenen Defaults gefüllt werden.
Was ist mit Vendor-only-Code?
Host-Duplikate sind verboten; `subagent-check-vendor-duplicates` und `@skill-vendor-only-files` sichern, dass Logik im Vendor bleibt, wenn sie dort bereits existiert.
Wie halte ich Translations synchron?
Nach DE-Änderungen sofort EN (und weitere Sprachen) nachziehen; `@skill-translations` und `subagent-check-translations` prüfen Keys und Twig-Pfade.
| Merksatz | Bedeutung für agentic deep check |
|---|---|
| Briefing-First | Spec vor Code, immer |
| Ralph-Loop | Konvergenz statt „fertig“-Behauptung |
| curl + PHPUnit | Beweis statt Chat-Grün |
| Keine Emojis | Professioneller Ton in Code und UI |
agentic deep check skaliert nur mit versionierter Steuerung: Rules setzen Grenzen, Skills liefern Verfahren, Subagents führen aus. Wer jeden Schritt mit Briefing, curl und PHPUnit belegt, ersetzt Chat-Hoffnung durch deploybare Qualität. Der Beitrag `/blog/agentic-deep-check` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.
Tooling-Kette und Vendor-Integration (Teil 5)
Unser Stack basiert auf `fabianrossbacher/base-ui-testcase` als Vendor: Routing über `VendorRouteConfigLoaderService`, Twig über `VendorTwigService`, Session über `VendorSessionService`. Blogposts nutzen `BlogpostServiceOrchestrator` mit Steps `ScreenBlog001LoadMarkdownSourceService`, `ScreenBlog002PrepareHtmlAndHeroImageService` und `ScreenBlog003FinalizeBlogpostUiModelService`. Hero-Bilder werden aus `htdocs/images/blog/{slug}/` geladen; Markdown und Quell-SVGs liegen unter `briefing/blog/blogposts/{slug}/`.
| Komponente | Pfad | Verantwortung |
|---|---|---|
| Markdown-Quelle | `briefing/blog/blogposts/{slug}/{slug}.md` | Inhalt, Tabellen, Bild-Referenzen |
| Screen-PHP | `htdocs/scripts/app/blog/{slug}.php` | Orchestrator-Call, Twig-Render |
| Template | `templates/app/theme1/blog/{route-thema}.html` | SEO-Blöcke, Hero, Body |
| Translations | `translation/de/blog/{date}-{thema}-de.php` | seo_title, seo_description |
| CSS | `htdocs/css/app/blog/blogpost.css` | Typografie, Tabellen, Code-Blöcke |
Änderungen an der Blog-Pipeline folgen Briefing-First: zuerst `briefing/screens/blog/Blogpost.md` und Screen-Service-Briefings, dann PHP unter `src/ScreenOrchestrator/Blog/` und `src/ScreenServices/Blog/`. `@skill-change-provenance` verlangt Änderungsprotokollzeilen in jeder geänderten PHP- und CSS-Datei.
Qualitätssicherung in CI und lokal (Teil 6)
Bevor ein Blogpost als „freigegeben“ gilt, prüfen wir mehrere Ebenen parallel. Routing muss in `routes-project-config.php` und `routes-config.php`-Merge korrekt aufgelöst werden; der Port kommt aus `server-port.sh`. UI-Tests unter `tests/UI/` können Blog-Routes abdecken; Orchestrator-Tests unter `tests/Orchestrator/Blog/` sichern den Markdown-Lade-Pfad. Für agentic deep check bedeutet das: nicht nur Inhalt erweitern, sondern sicherstellen, dass der gerenderte Screen stabil bleibt.
001. Routing: Public-Route `/blog/agentic-deep-check` ohne Tippfehler, kein Punkt in URL-Segmenten (daher `cursor-com` statt `cursor.com`).
002. Homescreen: Automatische Teaser-Liste via Glob auf `htdocs/scripts/app/blog/*.php` – jede neue Screen-Datei erscheint ohne manuelle HTML-Pflege.
003. SEO: `seo_og_title` muss von `seo_title` abweichen; Description 120–160 Zeichen in DE und EN.
004. Medien: Hero-SVG im Briefing-Ordner plus Spiegel unter `htdocs/images/blog/`; Content-SVG im Markdown per `/images/blog/{slug}/…` referenziert.
005. Inhalt: Mindestens 2500 Wörter, mindestens eine Tabelle, Hardcore-Developer-Ton ohne Emojis und ohne Lesezeit-Angaben.
Wer diese Checkliste bei jedem Blogpost durchgeht, vermeidet typische Agentic-Fallen: vergessene Translations, fehlende Hero-Grafiken, Briefing-Rückstand nach Screen-Änderungen und vorzeitiges „SUCCESS“ ohne curl-Beweis.