Translation-Keys – die App prüft ihre eigenen Texte
Datum: 2026-04-01
i18n bricht leise – bis der Nutzer es merkt
Ein Key fehlt in EN. Ein Twig-Template nutzt `translations.Foo.bar` statt `translations.FooBar.bar`. Ein Setter im Model heißt `footer_imprint`, die Vendor-Translation erwartet `footer_impressum`. Auf Deutsch sieht alles gut aus – der erste englische Besucher oder der Translation-Validator im CI sieht 500 oder leere Strings.
Agentic Engineering behandelt i18n als Quality-Gate – nicht als Freitags-Nacharbeit.
Das Problem
| Fehler | Wann sichtbar |
|---|---|
| Fehlender Key in einer Sprache | Sprachwechsel / Validator |
| Falscher ScreenKey in Twig | Runtime / 500 |
| Host-Model vs. Vendor-Keys | Translation-Validierung |
| Hardcodierter String im Template | SEO, Konsistenz, Review |
Manuelles Nachziehen nach jedem Feature skaliert nicht – vor allem nicht mit KI-generierten Screens.
Das Pattern: die Kette
Routing (routes-project-config.php + Vendor)
→ Screen-Script
→ Twig: translations.{ScreenKey}.{property}
→ translation/{lang}/screen-*/ oder projektspezifisch
→ UITemplateModel-Properties
Ein Subagent traversiert alle Screens aus dem gemergten Routing und vergleicht:
001. Keys in Translation-Dateien
002. Properties im Model (App oder fabian)
003. Referenzen in Twig
004. Parität DE/EN (und weitere Sprachen)
So sieht es bei uns aus
php start-vendor-subagent-ralph-loop.php subagent-check-translations
`subagent-check-translations`:
001. Lädt Routing wie `VendorRouteConfigLoaderService`.
002. Prüft jeden Screen (öffentlich + secure mit Autologin-Regeln).
003. Meldet fehlende Keys als FAILED – nicht „TODO“.
004. Läuft im Development-Workflow und nach größeren UI-Änderungen.
Naming-Konventionen
| Element | Konvention |
|---|---|
| Translation-Ordner | `screen-{name}` für Vendor-Screens |
| Twig-Zugriff | `translations.{ScreenKey}.seo_title` |
| Model | Properties in snake_case |
| Blog-Screen | `translation/{lang}/blog/{YYYYMMDD}-{slug}-{lang}.php` |
Vendor-Screens erwarten oft `ScreenUserLogin` als Key – Host-Templates mit `UserLogin` ohne Anpassung → Fehler.
Validator vs. menschliches Auge
Der `VendorTranslationValidationService` prüft, ob jeder Key in der Translation-Datei eine öffentliche Property im Model hat. Host-Models mit abweichenden Namen (z. B. nur `footer_imprint` statt `footer_impressum`) lösen 500 aus – bevor ein Nutzer klickt.
Lösung: Model an Vendor angleichen, Host-Translation entfernen (Vendor-Fallback), oder korrekte `screen-*` Pfade mit fabian-Models.
Anti-Patterns
001. Strings direkt in Twig – „nur ein Wort“ – wird zu 200 hardcodierten Texten.
002. Translation nur DE – EN vergisst man bis Production.
003. Alter Ordner `user-login` bei Vendor-Route `screen-user-login` – Falscher Pfad, falsches Model.
004. Dynamische Keys ohne Model-Property – Validator schlägt fehl.
005. i18n manuell „am Freitag“ – Wird nie grün im Ralph-Loop.
Integration im Workflow
| Trigger | Aktion |
|---|---|
| Neuer Screen | Translations DE+EN anlegen, dann `check-translations` |
| Template-Änderung | Keys in Briefing/Model nachziehen |
| Vendor-Update | `check-vendor-duplicates` + `check-translations` |
| Vor Push | Development-Workflow |
curl mit `?autologin=1` für secure Routes laut Projektregel – gleiche URLs wie der Subagent.
Häufige Fragen
Warum nicht nur Twig-Fehler abwarten?
Manche Fehler erst bei Validierung beim Request-Start – alle Screens zu curlen ist teuer; Routing-Traversal ist systematischer.
Muss jedes Wort übersetzt sein?
Ja für UI und SEO pro Screen – Base-Navigation in `base-{lang}.php`.
Blogposts?
Inhalt oft nur DE; SEO-Titel/-Description in `translation/.../blog/`.
Verwandte Beiträge
| Beitrag | Thema |
|---|---|
| Rules, Skills, Subagents | `@skill-translations` |
| Self-Testing | UI-Tests pro Screen |
| Briefing-First | Keys in Spec |
| check-screens | Twig + PHP zusammen |
Takeaway
i18n ist ein Quality-Gate im Workflow – kein Nachziehen am Freitag. Translation-Keys systematisch prüfen heißt: Routing → Twig → Model → alle Sprachen. Wer das dem Subagent überlässt, merkt Fehler vor dem Nutzer – und vor dem Commit.
Vertiefung: Translation-Keys – die App prüft ihre eigenen Texte im Projektalltag
In unserem Repository ist agentic translation keys kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic translation keys 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 translation keys 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-translation-keys` 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-04-01-agentic-translation-keys/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-04-01-agentic-translation-keys/` vorhanden.
003. Route `/blog/agentic-translation-keys` 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-translation-keys` 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 translation keys |
|---|---|
| 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 translation keys 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-translation-keys` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.
Vertiefung (Teil 5): Translation-Keys – die App prüft ihre eigenen Texte im Projektalltag
In unserem Repository ist agentic translation keys kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic translation keys 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 translation keys 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-translation-keys` 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-04-01-agentic-translation-keys/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-04-01-agentic-translation-keys/` vorhanden.
003. Route `/blog/agentic-translation-keys` 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-translation-keys` 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 translation keys |
|---|---|
| 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 translation keys 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-translation-keys` ist Teil dieser Serie – vertiefend, referenzierbar und auf Hardcore-Developer-Niveau formuliert.
Vertiefung: Translation-Keys – die App prüft ihre eigenen Texte im Projektalltag
In unserem Repository ist agentic translation keys kein abstraktes Konzept, sondern Teil der täglichen Agent-Arbeit unter `briefing/`, `cursor-rules/` und den `start-vendor-*`-Workflows. Wer agentic translation keys 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 translation keys 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-translation-keys` 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-04-01-agentic-translation-keys/` vollständig und mit mindestens einer Tabelle gepflegt.
002. Hero-SVG und Content-SVG im Post-Ordner und unter `htdocs/images/blog/2026-04-01-agentic-translation-keys/` vorhanden.
003. Route `/blog/agentic-translation-keys` 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-translation-keys` 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 translation keys |
|---|---|
| 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 translation keys 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-translation-keys` 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 translation keys bedeutet das: nicht nur Inhalt erweitern, sondern sicherstellen, dass der gerenderte Screen stabil bleibt.
001. Routing: Public-Route `/blog/agentic-translation-keys` 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.