Imporved the site

src/assets/i18n/de.json

@@ -29,7 +29,7 @@
       "PROFILE": "Profilfoto von Andreas Dahm"
     },
     "HELLO": "Hallo, ich bin Andreas.",
-    "LEAD": "Senior Softwareentwickler und Architekt mit über 15 Jahren Erfahrung. Meine Arbeit bewegt sich zwischen zwei Bereichen, die selten zusammentreffen: Echtzeit-3D-Simulation — Stoffphysik, Kollisionserkennung, GPU-Shader — und verteilte Cloud-Architektur für Unternehmensplattformen. Unterwegs habe ich ein Entwicklungsteam geleitet, die Migration eines großen Legacy-Monolithen zu Microservices geplant und ein Spiel auf Steam veröffentlicht. In letzter Zeit beschäftigt mich vor allem die Engineering-Seite der KI-gestützten Entwicklung: die Harnesses, Leitplanken und Quality Gates, die generierten Code überprüfbar machen. Privat entwickle ich Spiele und beschäftige mich mit algorithmischen Themen — vieles davon findet sich irgendwo auf dieser Seite wieder.",
+    "LEAD": "Ich arbeite seit 2010 als Softwareentwickler. Die meiste Zeit davon in zwei ziemlich unterschiedlichen Ecken. Die eine ist Echtzeit-3D-Simulation: Stoffphysik, Kollisionserkennung, GPU-Shader. Die andere ist Cloud-Architektur für größere Unternehmensplattformen. Ein paar Jahre habe ich ein kleines Backend-Team geleitet, den Umbau eines großen Legacy-Monolithen Richtung Microservices geplant und zusammen mit meinem Bruder ein Spiel auf Steam veröffentlicht. In letzter Zeit geht viel Zeit in Tooling rund um KI-gestützte Entwicklung, vor allem darum, das Ergebnis überprüfbar zu machen und nicht nur schnell. Privat baue ich Spiele und probiere Sachen mit Algorithmen aus. Das meiste davon landet irgendwann auf dieser Seite.",
     "ROLE": "Senior Software Entwickler / Full-Stack Entwickler / Softwarearchitekt",
     "LOCATION": "München · Remote",
     "VIEW_PROJECTS": "Projekte ansehen",
@@ -187,12 +187,12 @@
     "PROJECT": {
       "CLAUDE_BOX": {
         "TITLE": "Claude-in-a-Box",
-        "DESCRIPTION": "Eine containerisierte Entwicklungsumgebung, die einen KI-Coding-Agenten zu einem überprüfbaren Teil der Toolchain macht. Statt spontaner Prompts führt die Box den Agenten über Regeln pro Stack, Architekturprofile pro Repository und Commit-Hooks, die keinen roten Build durchlassen.",
+        "DESCRIPTION": "Eine Entwicklungsumgebung im Container, in der ein KI-Coding-Agent nach festen Regeln arbeitet statt nach spontanen Prompts. Er zieht sich die Regeln für den Stack, den er im Repository vorfindet, und ein Git-Hook stoppt den Commit, wenn Build oder Tests rot sind.",
         "LINK_INTERNAL": "Projektdetails",
         "HIGHLIGHTS": {
-          "P1": "Deterministisches Context-Routing: Der Agent lädt die Regeln des Stacks, den er im Repository tatsächlich vorfindet.",
-          "P2": "Commit-Gates, die bei fehlgeschlagenem Build oder Test blockieren — generierter Code kann die Qualitätsschwelle nicht umgehen.",
-          "P3": "MCP-Integrationen für Code-Intelligence und lesenden Ticket-Zugriff, dazu Subagenten, die den Diff prüfen."
+          "P1": "Der Agent lädt die Regeln für den Stack, den er im Repo vorfindet. Ein Java-Service bekommt also andere als ein Frontend.",
+          "P2": "Ein Commit-Hook führt Build und Tests aus und blockiert den Commit, wenn sie fehlschlagen.",
+          "P3": "MCP-Server für Codesuche und lesenden Jira-Zugriff, dazu eigene Review-Agenten, die den Diff durchgehen."
         }
       },
       "P2": {
@@ -364,17 +364,17 @@
     },
     "CLAUDE_BOX": {
       "TITLE": "Claude-in-a-Box",
-      "SHORT_DESCRIPTION": "Eine containerisierte, regelgetriebene Umgebung für die Arbeit mit einem KI-Coding-Agenten.",
-      "INTRODUCTION": "Mit einem KI-Coding-Agenten zu arbeiten ist leicht angefangen und schwer ehrlich gehalten. Das Ergebnis sieht plausibel aus, also sind die teuren Fehler genau die, die durch das Review kommen. Claude-in-a-Box ist meine Antwort darauf: eine Docker-basierte Entwicklungsumgebung, in der der Agent unter denselben Bedingungen arbeitet wie eine neue Kollegin oder ein neuer Kollege — nach den Architekturregeln des Repositories, in dem er sich befindet, und mit einem Build, der grün bleiben muss, bevor irgendetwas committet werden kann. Das interessante Engineering steckt nicht in den Prompts, sondern im Harness darum herum.",
-      "BULLET_1": "Containerisierter Workspace mit fixierten Toolchains — über SDKMAN verwaltete JDKs und Maven, Node und ein persistentes Home-Volume, das einen Container-Rebuild überlebt.",
-      "BULLET_2": "Context-Routing per Erkennung: Ein Repository mit pom.xml lädt die Java/Spring-Regeln, eines mit package.json die TypeScript-Regeln, und ein Repository mit eigenem Architekturprofil lädt zusätzlich dieses.",
-      "BULLET_3": "Ein Commit-Hook, der den Stack selbst erkennt, das passende Build- und Test-Gate ausführt und den Commit bei Fehlschlag blockiert.",
-      "BULLET_4": "MCP-Server für Code-Graph-Abfragen und lesenden Ticket-Zugriff, dazu eigens gebaute Review-Subagenten, die einen fertigen Diff prüfen, bevor er als erledigt gemeldet wird.",
-      "CHALLENGE_1": "Das Regelwerk klein genug für den Context zu halten und trotzdem verbindlich zu machen — allgemeine Ratschläge werden ignoriert, also mussten die Regeln in Stack-Skills und Repository-Profile aufgeteilt werden, die nur bei Bedarf laden.",
-      "CHALLENGE_2": "Das Quality Gate unumgehbar machen. Die Prüfung läuft als Hook außerhalb des Agenten, sodass ein fehlgeschlagener Build den Commit blockiert — unabhängig davon, was der Agent über seine eigene Arbeit glaubt.",
-      "CHALLENGE_3": "Toolchain-Isolation in einem Container ohne Root: Builds, Browser und Sprach-Runtimes mussten alle in Volumes installiert werden, die dem Entwickler-User gehören.",
-      "LEARNING_1": "Die Qualität KI-gestützter Arbeit hängt vor allem am Harness, nicht am Prompt. Deterministische Gates schlagen sorgfältige Formulierungen jedes Mal.",
-      "LEARNING_2": "Den Agenten als nicht vertrauenswürdigen Mitwirkenden zu behandeln — reviewed, gegated und nur mit dem nötigen Context versorgt — ist dieselbe Disziplin, die auch menschliches Code-Review funktionieren lässt."
+      "SHORT_DESCRIPTION": "Ein Container-Setup, um mit einem KI-Coding-Agenten nach festen Regeln zu arbeiten.",
+      "INTRODUCTION": "Einen KI-Coding-Agenten dazu zu bringen, irgendetwas zu produzieren, ist einfach. Ihn dazu zu bringen, etwas zu produzieren, das man auch wirklich mergen würde, ist eine andere Sache, weil das Ergebnis auf den ersten Blick meistens ganz vernünftig aussieht. Also habe ich ein Docker-Setup gebaut, in dem der Agent wie jeder andere Mitwirkende arbeitet. Er bekommt die Architekturregeln des Repositories, in dem er gerade ist, und der Build muss grün sein, bevor überhaupt etwas committet werden kann. Die meiste Arbeit steckt im Setup rund um den Agenten und nicht in den Prompts.",
+      "BULLET_1": "Container mit festen Toolchains: JDKs und Maven über SDKMAN, Node und ein Home-Volume, das einen Rebuild übersteht.",
+      "BULLET_2": "Die Regeln werden per Erkennung geladen. Ein Repo mit pom.xml bekommt die Java- und Spring-Regeln, eines mit package.json die TypeScript-Regeln, und Repos mit eigenen Architekturnotizen bekommen diese zusätzlich.",
+      "BULLET_3": "Ein Commit-Hook ermittelt den Stack, führt den passenden Build und die Tests aus und verweigert den Commit, wenn sie fehlschlagen.",
+      "BULLET_4": "MCP-Server für Code-Graph-Abfragen und lesende Jira-Zugriffe, dazu Review-Agenten, die einen fertigen Diff prüfen, bevor er als erledigt gilt.",
+      "CHALLENGE_1": "Die Regeln kurz genug zu halten, dass sie noch etwas bringen. Lange allgemeine Richtlinien werden einfach ignoriert, also sind sie in Dateien pro Stack und pro Repo aufgeteilt, die nur bei Bedarf geladen werden.",
+      "CHALLENGE_2": "Das Quality Gate so zu bauen, dass der Agent sich nicht daran vorbeireden kann. Die Prüfung läuft als Git-Hook außerhalb des Agenten, ein fehlgeschlagener Build blockiert den Commit also unabhängig davon, was der Agent über seine eigene Arbeit denkt.",
+      "CHALLENGE_3": "Die Toolchains in einem Container ohne Root installiert zu bekommen. Builds, Browser und Sprach-Runtimes mussten alle in Volumes, die dem Entwickler-User gehören.",
+      "LEARNING_1": "Wie gut das Ganze funktioniert, hängt viel stärker am Setup rund um den Agenten als an der Formulierung der Prompts.",
+      "LEARNING_2": "Den Output des Agenten genauso zu reviewen und zu gaten wie den Pull Request einer neuen Kollegin hat sich als die nützlichste Regel überhaupt herausgestellt."
     }
   },
   "IMPRINT": {