docs(projects): update claude-in-a-box project text and diagram

The box now runs an agent pipeline, assist mode and evals.
The old card and diagram only described rule loading and the commit hook.

src/app/pages/projects/projects.component.ts

@@ -106,18 +106,22 @@ export class ProjectsComponent implements OnInit, OnDestroy {
         'PROJECTS.CLAUDE_BOX.BULLET_2',
         'PROJECTS.CLAUDE_BOX.BULLET_3',
         'PROJECTS.CLAUDE_BOX.BULLET_4',
+        'PROJECTS.CLAUDE_BOX.BULLET_5',
+        'PROJECTS.CLAUDE_BOX.BULLET_6',
       ],
       challenges: [
         'PROJECTS.CLAUDE_BOX.CHALLENGE_1',
         'PROJECTS.CLAUDE_BOX.CHALLENGE_2',
         'PROJECTS.CLAUDE_BOX.CHALLENGE_3',
+        'PROJECTS.CLAUDE_BOX.CHALLENGE_4',
       ],
       learnings: [
         'PROJECTS.CLAUDE_BOX.LEARNING_1',
         'PROJECTS.CLAUDE_BOX.LEARNING_2',
+        'PROJECTS.CLAUDE_BOX.LEARNING_3',
       ],
       isFeatured: false,
-      technologies: ['Claude Code', 'MCP', 'Docker', 'Bash', 'Node.js']
+      technologies: ['Claude Code', 'MCP', 'Docker', 'Bash', 'Node.js', 'Playwright']
     },
     {
       identifier: "playground",

src/assets/i18n/de.json

@@ -197,12 +197,12 @@
       },
       "CLAUDE_BOX": {
         "TITLE": "Claude-in-a-Box",
-        "DESCRIPTION": "Eine Entwicklungsumgebung im Container, in der ein KI-Coding-Agent nach einem festen Regelsatz arbeitet und nicht nach dem, was ich gerade eintippe. 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.",
+        "DESCRIPTION": "Eine Entwicklungsumgebung im Container, in der KI-Agenten Code nach festen Regeln schreiben. Eine Pipeline aus kleinen Agenten klärt, plant, implementiert, vereinfacht und reviewt, und ich sage Ja zum Plan und zu jedem Commit. Hooks außerhalb der Agenten blockieren rote Builds und Zugriffe auf Secrets.",
         "LINK_INTERNAL": "Projektdetails",
         "HIGHLIGHTS": {
-          "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."
+          "P1": "Ein Agent pro Aufgabe, jeder mit frischem Kontext und passendem Modell. Die Übergabe läuft über Dateien, nicht über den Chat.",
+          "P2": "Ein Commit-Hook führt Build, Tests und einen Secret-Scan aus und blockiert den Commit, wenn etwas rot ist.",
+          "P3": "Eine Eval-Suite misst jede Änderung an Regeln oder Agenten an festen Aufgaben mit versteckten Prüfungen."
         }
       },
       "P2": {
@@ -383,17 +383,21 @@
     },
     "CLAUDE_BOX": {
       "TITLE": "Claude-in-a-Box",
-      "SHORT_DESCRIPTION": "Ein Container-Setup, um mit einem KI-Coding-Agenten nach einem festen Regelsatz zu arbeiten.",
-      "INTRODUCTION": "Ein KI-Coding-Agent produziert den ganzen Tag Code, ohne sich zu beschweren. Das Problem ist, dass das Ergebnis meistens vernünftig aussieht, auch wenn es falsch ist, und die ganzen Kosten damit im Review landen. Also habe ich ein Docker-Setup gebaut, das den Agenten denselben Regeln unterwirft wie alle anderen, die am Repository arbeiten. Er liest die Architekturregeln des Projekts, in dem er gerade steckt, und der Build muss durchlaufen, bevor ein Commit möglich ist. Auf den Hook, der genau das durchsetzt, komme ich immer wieder zurück, weil er das Einzige ist, woran der Agent nicht vorbeikommt.",
-      "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 zum Laufen zu bringen. Builds, Browser und Sprach-Runtimes mussten alle in Volumes landen, die dem Entwickler-User gehören.",
+      "SHORT_DESCRIPTION": "Ein Container-Setup für einen KI-Coding-Agenten: eine Pipeline aus kleinen Agenten mit je einer Aufgabe und Hooks, an denen keiner von ihnen vorbeikommt.",
+      "INTRODUCTION": "Ein KI-Coding-Agent produziert den ganzen Tag Code, ohne sich zu beschweren. Das Problem ist, dass das Ergebnis meistens vernünftig aussieht, auch wenn es falsch ist, und die ganzen Kosten damit im Review landen. Also habe ich ein Docker-Setup gebaut, das den Agenten denselben Regeln unterwirft wie alle anderen, die am Repository arbeiten: Er liest die Architekturregeln des Projekts, in dem er gerade steckt, und der Build muss durchlaufen, bevor ein Commit möglich ist. Inzwischen ist aus der Box eine Pipeline geworden. Das Klären passiert im Chat, danach gibt es einen kleinen Agenten pro Aufgabe, jeder mit frischem Kontext: Einer plant, einer implementiert, einer vereinfacht, einer reviewt. Die Übergabe läuft über Dateien, nicht über den Chat, und ich sage an zwei Stellen Ja: zum Plan und zu jedem Commit. Die Hooks um das Ganze herum sind immer noch der Teil, auf den ich am häufigsten zurückkomme, weil sie das Einzige sind, woran sich kein Agent vorbeireden kann.",
+      "BULLET_1": "Agenten-Pipeline: Klären (die Hauptsession stellt gezielte Fragen und schreibt eine Spec), Planen, Implementieren, Vereinfachen, ein Security-Check, wenn die Änderung etwas Sicherheitsrelevantes berührt, Review, Commit-Message. Jeder Schritt nach dem Klären ist ein eigener Agent mit frischem Kontext und einem Modell, das zur Aufgabe passt: Fable für Klären, Planen und Review, Sonnet fürs Implementieren, Opus für Vereinfachen und Security, Haiku für die Commit-Message. Sind weniger als 20 % des wöchentlichen Fable-Budgets übrig, wechseln diese Schritte von selbst auf Opus, und die Statusleiste zeigt es an.",
+      "BULLET_2": "Ich bleibe an zwei Stellen im Spiel: Der Plan braucht mein OK, bevor jemand Code schreibt, und jeder Commit braucht mein Ja. Der Reviewer ist kritisch und kennt den Chat nicht: Er lässt das Gate laufen, schreibt für jeden Fund einen fehlschlagenden Test und prüft, ob das Feature funktioniert, wenn nötig im Browser. Funde gehen zurück an den Implementierer, höchstens zwei Runden. Ein Agent, der denselben Fehler zweimal nicht beheben kann, hört auf und meldet RED, und ich entscheide. Kleine Änderungen überspringen Plan und Review.",
+      "BULLET_3": "Die Regeln werden per Erkennung geladen. Ein Repo mit pom.xml bekommt die Java- und Spring-Regeln, eines mit package.json die TypeScript-Regeln, ein Unity-Projekt die datenorientierten Regeln, und Repos mit eigenen Architekturnotizen bekommen diese zusätzlich. Jeder Agent liest nur die Dokumente, die seine Aufgabe braucht, damit der Kontext klein bleibt.",
+      "BULLET_4": "Hooks außerhalb der Agenten: ein Compile- oder Type-Check am Ende jedes Turns, ein Commit-Gate, das den vollen Build, die Tests und einen Secret-Scan ausführt und einen roten Commit verweigert, ein Guard, der das Lesen von .env-Dateien und Keys blockiert, und ein Work-Mode-Guard. Drumherum ein Container ohne Root mit festen Toolchains und MCP-Servern für Code-Graph-Abfragen, Gitea und lesendes Jira.",
+      "BULLET_5": "Work-Mode assist, pro Chat: Ich schreibe den Kern (Domain, Services, Persistenz), die Agenten schreiben Gerüst, Boilerplate und Tests und reviewen meinen Code. Ein Hook verweigert den Agenten das Schreiben auf die Kernpfade, die Trennung wird also erzwungen und nicht nur erbeten.",
+      "BULLET_6": "Eine Eval-Suite lässt die ganze Pipeline headless gegen feste Aufgaben laufen, Fallen eingeschlossen, jede mit versteckten Prüfungen. Die Ergebnisse werden pro Commit der Box protokolliert, eine Änderung an einer Regel oder einem Agenten wird also gemessen statt geraten.",
+      "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, pro Repo und pro Aufgabe aufgeteilt, und jeder Agent lädt nur die, die für ihn gelten.",
+      "CHALLENGE_2": "Die Gates so zu bauen, dass kein Agent sich daran vorbeireden kann. Jede Prüfung läuft als Hook außerhalb des Agenten: Ein fehlgeschlagener Build blockiert den Commit, ein Lesezugriff auf Secrets wird verweigert, ein Schreibzugriff auf einen Kernpfad im Assist-Modus abgelehnt, unabhängig davon, was der Agent über seine eigene Arbeit denkt.",
+      "CHALLENGE_3": "Ein Reviewer, der zugesehen hat, wie der Code entstanden ist, winkt ihn durch. Also startet jeder Agent mit leerem Kontext und bekommt nur die Dateien, die seine Aufgabe braucht: Der Reviewer sieht Spec, Plan und Diff, nie den Chat. Der Preis ist, dass jeder Agent den Code neu liest, die Pipeline ist also langsamer als ein langer Chat.",
+      "CHALLENGE_4": "Zu wissen, ob eine Änderung an der Box etwas bringt. Jede angepasste Regel fühlte sich wie eine Verbesserung an, also habe ich die Eval-Suite gebaut: feste Aufgaben mit versteckten Prüfungen, vor und nach einer Änderung mit denselben Modellen ausgeführt. Die Suite prüft auch sich selbst: Die unveränderte Vorlage muss an jeder Aufgabe scheitern und die Referenzlösung muss bestehen, sonst sagt ein grüner Lauf nichts aus.",
       "LEARNING_1": "Die Formulierung der Prompts war deutlich weniger wichtig, als ich dachte. Fast der ganze Unterschied kam vom Drumherum.",
-      "LEARNING_2": "Den Output des Agenten genauso zu reviewen und durch dieselben Gates zu schicken wie den Pull Request eines neuen Teammitglieds hat sich als die nützlichste Regel überhaupt herausgestellt."
+      "LEARNING_2": "Den Output des Agenten genauso zu reviewen und durch dieselben Gates zu schicken wie den Pull Request eines neuen Teammitglieds hat sich als die nützlichste Regel überhaupt herausgestellt.",
+      "LEARNING_3": "Kleine Agenten mit jeweils frischem Kontext schlagen einen langen Chat. Nicht weil das Modell klüger wird, sondern weil niemand frühere Fehler mitschleppt und jede Übergabe eine Datei ist, die ich lesen und korrigieren kann."
     },
     "TBP": {
       "TITLE": "To Be Played",

src/assets/i18n/en.json

@@ -197,12 +197,12 @@
       },
       "CLAUDE_BOX": {
         "TITLE": "Claude-in-a-Box",
-        "DESCRIPTION": "A development setup in a container where an AI coding agent works under a fixed set of rules rather than whatever I happen to type that day. It picks up the rules for whatever stack it finds in the repository, and a git hook stops the commit if the build or the tests are red.",
+        "DESCRIPTION": "A development setup in a container where AI agents write code under fixed rules. A pipeline of small agents clarifies, plans, implements, simplifies and reviews, and I say yes to the plan and to every commit. Hooks outside the agents block red builds and reads of secrets.",
         "LINK_INTERNAL": "Project details",
         "HIGHLIGHTS": {
-          "P1": "The agent loads the rules for the stack it finds in the repo, so a Java service and a frontend get different ones.",
-          "P2": "A commit hook runs the build and the tests and blocks the commit when they fail.",
-          "P3": "MCP servers for code search and read-only Jira access, plus separate review agents that go over the diff."
+          "P1": "One agent per job, each with a fresh context and a model that fits the job. Hand-over runs through files, not through the chat.",
+          "P2": "A commit hook runs the build, the tests and a secret scan and blocks the commit when anything is red.",
+          "P3": "An eval suite measures every change to rules or agents against fixed tasks with hidden checks."
         }
       },
       "P2": {
@@ -383,17 +383,21 @@
     },
     "CLAUDE_BOX": {
       "TITLE": "Claude-in-a-Box",
-      "SHORT_DESCRIPTION": "A container setup for working with an AI coding agent under a fixed set of rules.",
-      "INTRODUCTION": "An AI coding agent will produce code all day without complaining. The trouble is that what comes out usually looks reasonable even when it is wrong, so all the cost lands in review. I built a Docker setup that puts the agent under the same constraints as anyone else working on the repo. It reads the architecture rules of whatever project it is in, and the build has to pass before a commit goes through. The hook that enforces that last part is the piece I keep coming back to, because it is the one thing the agent has no way around.",
-      "BULLET_1": "Container with fixed toolchains: JDKs and Maven through SDKMAN, Node, and a home volume that survives a rebuild.",
-      "BULLET_2": "Rules are loaded by detection. A repo with a pom.xml gets the Java and Spring rules, one with a package.json gets the TypeScript rules, and repos with their own architecture notes get those on top.",
-      "BULLET_3": "A commit hook works out the stack, runs the matching build and tests, and refuses the commit if they fail.",
-      "BULLET_4": "MCP servers for code graph queries and read-only Jira lookups, plus review agents that check a finished diff before it counts as done.",
-      "CHALLENGE_1": "Keeping the rules short enough to stay useful. Long general guidelines just get ignored, so they are split into per-stack and per-repo files that only load when they apply.",
-      "CHALLENGE_2": "Making the quality gate something the agent cannot talk its way past. The check runs as a git hook outside the agent, so a failing build blocks the commit no matter what the agent believes about its own work.",
-      "CHALLENGE_3": "Getting the toolchains installed in a container that has no root. Builds, browsers and language runtimes all had to go into volumes owned by the development user.",
+      "SHORT_DESCRIPTION": "A container setup for an AI coding agent: a pipeline of small agents, one job each, and hooks none of them can get past.",
+      "INTRODUCTION": "An AI coding agent will produce code all day without complaining. The trouble is that what comes out usually looks reasonable even when it is wrong, so all the cost lands in review. I built a Docker setup that puts the agent under the same constraints as anyone else working on the repo: it reads the architecture rules of whatever project it is in, and the build has to pass before a commit goes through. Since then the box has grown into a pipeline. The chat clarifies the task; after that it is one small agent per job, each with a fresh context: one plans, one implements, one simplifies, one reviews. They hand over through files, not through chat, and I say yes at two points, to the plan and to every commit. The hooks around all of this are still the part I keep coming back to, because they are the one thing no agent can talk its way past.",
+      "BULLET_1": "Agent pipeline: clarify (the main session asks sharp questions and writes a spec), plan, implement, simplify, a security check when the change touches something security relevant, review, commit message. Every step after clarify is its own agent with a fresh context and a model that fits the job: Fable for clarify, plan and review, Sonnet for implementing, Opus for simplify and security, Haiku for the commit message. When less than 20% of the weekly Fable budget is left, those steps fall back to Opus on their own, and the statusline shows it.",
+      "BULLET_2": "I stay in the loop at two points: the plan needs my OK before anyone writes code, and every commit needs my yes. The reviewer is critical and has never seen the chat: it runs the gate, writes a failing test for each finding and checks that the feature works, in the browser if needed. Findings go back to the implementer, at most two rounds. An agent that fails to fix the same failure twice stops and returns RED, and I decide. Small changes skip plan and review.",
+      "BULLET_3": "Rules are loaded by detection. A repo with a pom.xml gets the Java and Spring rules, one with a package.json gets the TypeScript rules, a Unity project gets the data-oriented rules, and repos with their own architecture notes get those on top. Each agent reads only the documents its job needs, so the context stays small.",
+      "BULLET_4": "Hooks outside the agents: a compile or type check at the end of every turn, a commit gate that runs the full build, the tests and a secret scan and refuses a red commit, a guard that blocks reads of .env files and keys, and a work-mode guard. Around it a rootless container with pinned toolchains and MCP servers for code graph queries, Gitea and read-only Jira.",
+      "BULLET_5": "Work mode assist, per chat: I write the core code (domain, services, persistence), the agents write scaffolding, boilerplate and tests and review my code. A hook denies agent writes to the core paths, so the split is enforced, not just requested.",
+      "BULLET_6": "An eval suite runs the whole pipeline headless against fixed tasks, trap tasks included, each with hidden checks. The results are logged per commit of the box, so a change to a rule or an agent is measured instead of guessed.",
+      "CHALLENGE_1": "Keeping the rules short enough to stay useful. Long general guidelines just get ignored, so they are split into files per stack, per repo and per job, and each agent loads only the ones that apply to it.",
+      "CHALLENGE_2": "Making the gates something an agent cannot talk its way past. Every check runs as a hook outside the agent: a failing build blocks the commit, a read of a secret is refused, a write to a core path in assist mode is denied, no matter what the agent believes about its own work.",
+      "CHALLENGE_3": "A reviewer that has watched the code being written approves it. So every agent starts with an empty context and gets only the files its job needs: the reviewer sees spec, plan and diff, never the chat. The price is that each agent reads the code again, so the pipeline is slower than one long chat.",
+      "CHALLENGE_4": "Knowing whether a change to the box helps. Every edit to a rule felt like an improvement, so I built the eval suite: fixed tasks with hidden checks, run before and after a change with the same models. The suite checks itself too: the untouched fixture must fail every task and the reference solution must pass, otherwise a green run means nothing.",
       "LEARNING_1": "Prompt wording mattered far less than I expected. Almost all of the difference came from the scaffolding.",
-      "LEARNING_2": "Reviewing and gating the agent's output the same way you would a new colleague's pull request turned out to be the most useful rule of the lot."
+      "LEARNING_2": "Reviewing and gating the agent's output the same way you would a new colleague's pull request turned out to be the most useful rule of the lot.",
+      "LEARNING_3": "Small agents with a fresh context each beat one long chat. Not because the model gets smarter, but because nobody carries earlier mistakes forward, and every hand-over is a file I can read and correct."
     },
     "TBP": {
       "TITLE": "To Be Played",

src/assets/projects/claude-in-a-box/1.svg

@@ -1,6 +1,6 @@
 <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1200 630" width="1200" height="630" role="img" aria-labelledby="title desc">
   <title id="title">Claude-in-a-Box</title>
-  <desc id="desc">A containerised agent: repository detection routes stack rules into the box, and a commit gate blocks anything with a failing build.</desc>
+  <desc id="desc">Repository detection loads the rules per stack and per repo into an agent pipeline: clarify, plan, implement, simplify, security when relevant, review and commit message, one agent per step with its model. The human approves the plan and every commit; review findings go back to the implementer for at most two rounds. Hooks outside the agents run a compile check at turn end, a commit gate, a secret guard and a work-mode guard.</desc>
 
   <defs>
     <linearGradient id="bg" x1="0" y1="0" x2="0" y2="1">
@@ -14,8 +14,8 @@
     <marker id="arrow" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse">
       <path d="M 0 0 L 10 5 L 0 10 z" fill="#4a5563"/>
     </marker>
-    <marker id="arrowCyan" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse">
-      <path d="M 0 0 L 10 5 L 0 10 z" fill="#26c6da"/>
+    <marker id="arrowOrange" viewBox="0 0 10 10" refX="9" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse">
+      <path d="M 0 0 L 10 5 L 0 10 z" fill="#ffa726"/>
     </marker>
   </defs>
 
@@ -33,77 +33,115 @@
   <text x="64" y="72" class="mono" fill="#26c6da" font-size="26" font-weight="600">claude-in-a-box</text>
   <text x="64" y="102" class="sans lbl">the harness, not the prompt</text>
 
-  <!-- ── Left: repository detection ─────────────────────────── -->
   <text x="64" y="176" class="sans cap">detect</text>
-
   <g>
-    <rect x="64" y="196" width="228" height="62" rx="10" fill="#212a35" stroke="#2f3a47"/>
-    <text x="86" y="223" class="mono chip">pom.xml</text>
-    <text x="86" y="245" class="sans lbl" font-size="15">→ java / spring rules</text>
+    <rect x="64" y="188" width="228" height="52" rx="10" fill="#212a35" stroke="#2f3a47"/>
+    <text x="86" y="210" class="mono chip">pom.xml</text>
+    <text x="86" y="230" class="sans" fill="#8b97a6" font-size="15">→ java / spring rules</text>
   </g>
   <g>
-    <rect x="64" y="278" width="228" height="62" rx="10" fill="#212a35" stroke="#2f3a47"/>
-    <text x="86" y="305" class="mono chip">package.json</text>
-    <text x="86" y="327" class="sans lbl" font-size="15">→ typescript rules</text>
+    <rect x="64" y="248" width="228" height="52" rx="10" fill="#212a35" stroke="#2f3a47"/>
+    <text x="86" y="270" class="mono chip">package.json</text>
+    <text x="86" y="290" class="sans" fill="#8b97a6" font-size="15">→ typescript rules</text>
   </g>
   <g>
-    <rect x="64" y="360" width="228" height="62" rx="10" fill="#212a35" stroke="#2f3a47"/>
-    <text x="86" y="387" class="mono chip">pyproject.toml</text>
-    <text x="86" y="409" class="sans lbl" font-size="15">→ python rules</text>
+    <rect x="64" y="308" width="228" height="52" rx="10" fill="#212a35" stroke="#2f3a47"/>
+    <text x="86" y="330" class="mono chip">Assets/</text>
+    <text x="86" y="350" class="sans" fill="#8b97a6" font-size="15">→ unity rules</text>
   </g>
   <g>
-    <rect x="64" y="442" width="228" height="62" rx="10" fill="#212a35" stroke="#2f3a47" stroke-dasharray="4 4"/>
-    <text x="86" y="469" class="mono chip">&lt;repo&gt;.md</text>
-    <text x="86" y="491" class="sans lbl" font-size="15">→ architecture profile</text>
+    <rect x="64" y="368" width="228" height="52" rx="10" fill="#212a35" stroke="#2f3a47" stroke-dasharray="4 4"/>
+    <text x="86" y="390" class="mono chip">&lt;repo&gt;.md</text>
+    <text x="86" y="410" class="sans" fill="#8b97a6" font-size="15">→ architecture profile</text>
   </g>
+  <path d="M 300 214 H 340" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
+  <path d="M 300 274 H 340" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
+  <path d="M 300 334 H 340" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
+  <path d="M 300 394 H 340" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
 
-  <path d="M 300 227 H 360" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
-  <path d="M 300 309 H 360" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
-  <path d="M 300 391 H 360" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
-  <path d="M 300 473 H 360" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
-
-  <!-- ── Centre: the container ──────────────────────────────── -->
-  <rect x="376" y="150" width="330" height="380" rx="18" fill="#1a222c" stroke="#26c6da" stroke-width="2"/>
-  <text x="400" y="184" class="sans cap" fill="#26c6da">container</text>
-
-  <rect x="404" y="212" width="274" height="96" rx="12" fill="#243040" stroke="#33475c"/>
-  <circle cx="440" cy="248" r="14" fill="none" stroke="#26c6da" stroke-width="2"/>
-  <circle cx="440" cy="248" r="5" fill="#26c6da"/>
-  <text x="470" y="246" class="sans" fill="#e3e9f0" font-size="21" font-weight="600">agent</text>
-  <text x="470" y="270" class="sans lbl" font-size="15">scoped context only</text>
-  <text x="424" y="296" class="mono" fill="#6c7887" font-size="14">/workspace · no root</text>
-
-  <text x="404" y="348" class="sans cap">pinned toolchain</text>
-  <g class="mono" font-size="16" fill="#9aa7b5">
-    <text x="404" y="380">sdkman · jdk · maven</text>
-    <text x="404" y="408">node · npm</text>
-    <text x="404" y="436">mcp: codegraph, jira (ro)</text>
+  <rect x="356" y="150" width="780" height="290" rx="18" fill="#1a222c" stroke="#26c6da" stroke-width="2"/>
+  <text x="380" y="184" class="sans cap" style="fill:#26c6da">agent pipeline</text>
+  <text x="1112" y="184" class="sans cap" text-anchor="end" style="font-size:13px;letter-spacing:.08em">one job each · fresh context · hand-over by files</text>
+  <g>
+    <rect x="380" y="230" width="90" height="84" rx="12" fill="#243040" stroke="#33475c"/>
+    <text x="425" y="262" class="mono" text-anchor="middle" fill="#e3e9f0" font-size="14" font-weight="600">clarify</text>
+    <text x="425" y="284" class="sans" text-anchor="middle" fill="#8b97a6" font-size="13">Fable</text>
+    <text x="425" y="302" class="sans" text-anchor="middle" fill="#6c7887" font-size="13">main session</text>
   </g>
-  <rect x="404" y="462" width="274" height="44" rx="10" fill="#2a2118" stroke="#5c4326"/>
-  <text x="424" y="490" class="mono" fill="#ffa726" font-size="16">review subagents</text>
-
-  <path d="M 714 340 H 776" stroke="#26c6da" stroke-width="2" marker-end="url(#arrowCyan)"/>
-
-  <!-- ── Right: the gate ────────────────────────────────────── -->
-  <text x="792" y="176" class="sans cap">gate</text>
-
-  <rect x="792" y="196" width="344" height="288" rx="14" fill="#1c242e" stroke="#2f3a47"/>
-
-  <g class="mono" font-size="17">
-    <circle cx="822" cy="243" r="7" fill="#4caf50"/>
-    <text x="844" y="249" fill="#cdd6e0">lint</text>
-    <circle cx="822" cy="291" r="7" fill="#4caf50"/>
-    <text x="844" y="297" fill="#cdd6e0">build</text>
-    <circle cx="822" cy="339" r="7" fill="#ef5350"/>
-    <text x="844" y="345" fill="#cdd6e0">tests</text>
+  <g>
+    <rect x="486" y="230" width="90" height="84" rx="12" fill="#243040" stroke="#33475c"/>
+    <text x="531" y="262" class="mono" text-anchor="middle" fill="#e3e9f0" font-size="14" font-weight="600">plan</text>
+    <text x="531" y="284" class="sans" text-anchor="middle" fill="#8b97a6" font-size="13">Fable</text>
   </g>
+  <g>
+    <rect x="592" y="230" width="90" height="84" rx="12" fill="#243040" stroke="#33475c"/>
+    <text x="637" y="262" class="mono" text-anchor="middle" fill="#e3e9f0" font-size="14" font-weight="600">implement</text>
+    <text x="637" y="284" class="sans" text-anchor="middle" fill="#8b97a6" font-size="13">Sonnet</text>
+  </g>
+  <g>
+    <rect x="698" y="230" width="90" height="84" rx="12" fill="#243040" stroke="#33475c"/>
+    <text x="743" y="262" class="mono" text-anchor="middle" fill="#e3e9f0" font-size="14" font-weight="600">simplify</text>
+    <text x="743" y="284" class="sans" text-anchor="middle" fill="#8b97a6" font-size="13">Opus</text>
+  </g>
+  <g>
+    <rect x="804" y="230" width="90" height="84" rx="12" fill="#243040" stroke="#33475c" stroke-dasharray="4 4"/>
+    <text x="849" y="262" class="mono" text-anchor="middle" fill="#e3e9f0" font-size="14" font-weight="600">security</text>
+    <text x="849" y="284" class="sans" text-anchor="middle" fill="#8b97a6" font-size="13">Opus</text>
+    <text x="849" y="302" class="sans" text-anchor="middle" fill="#6c7887" font-size="13">if relevant</text>
+  </g>
+  <g>
+    <rect x="910" y="230" width="90" height="84" rx="12" fill="#243040" stroke="#33475c"/>
+    <text x="955" y="262" class="mono" text-anchor="middle" fill="#e3e9f0" font-size="14" font-weight="600">review</text>
+    <text x="955" y="284" class="sans" text-anchor="middle" fill="#8b97a6" font-size="13">Fable</text>
+  </g>
+  <g>
+    <rect x="1016" y="230" width="90" height="84" rx="12" fill="#243040" stroke="#33475c"/>
+    <text x="1061" y="262" class="mono" text-anchor="middle" fill="#e3e9f0" font-size="14" font-weight="600">commit</text>
+    <text x="1061" y="284" class="sans" text-anchor="middle" fill="#8b97a6" font-size="13">Haiku</text>
+    <text x="1061" y="302" class="sans" text-anchor="middle" fill="#6c7887" font-size="13">message</text>
+  </g>
+  <path d="M 470 272 H 486" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
+  <path d="M 576 272 H 592" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
+  <path d="M 682 272 H 698" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
+  <path d="M 788 272 H 804" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
+  <path d="M 894 272 H 910" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
+  <path d="M 1000 272 H 1016" stroke="#4a5563" stroke-width="2" marker-end="url(#arrow)"/>
+  <path d="M 955 230 V 214 H 637 V 230" fill="none" stroke="#ffa726" stroke-width="2" marker-end="url(#arrowOrange)"/>
+  <text x="796" y="207" class="sans" text-anchor="middle" fill="#ffa726" font-size="13">findings · max 2 rounds</text>
 
-  <rect x="812" y="378" width="304" height="76" rx="10" fill="#2b1b1c" stroke="#7d3a3c"/>
-  <text x="836" y="408" class="mono" fill="#ef8b8d" font-size="17">git commit — blocked</text>
-  <text x="836" y="434" class="sans lbl" font-size="15">hook runs outside the agent</text>
+  <path d="M 531 314 V 352" stroke="#ffa726" stroke-width="2" marker-end="url(#arrowOrange)"/>
+  <path d="M 1061 314 V 352" stroke="#ffa726" stroke-width="2" marker-end="url(#arrowOrange)"/>
+  <rect x="486" y="352" width="90" height="40" rx="10" fill="#2a2118" stroke="#5c4326"/>
+  <text x="531" y="377" class="mono" text-anchor="middle" fill="#ffa726" font-size="14">you: ok?</text>
+  <rect x="1016" y="352" width="90" height="40" rx="10" fill="#2a2118" stroke="#5c4326"/>
+  <text x="1061" y="377" class="mono" text-anchor="middle" fill="#ffa726" font-size="14">you: yes?</text>
+  <text x="592" y="377" class="sans" fill="#8b97a6" font-size="14">RED after 2 failed fixes → you decide</text>
 
-  <text x="792" y="524" class="sans lbl" font-size="16">a failing build cannot be argued with</text>
+  <text x="380" y="424" class="mono" fill="#6c7887" font-size="13">size S: clarify → implement → commit</text>
+  <text x="1112" y="424" class="mono" text-anchor="end" fill="#6c7887" font-size="13">Fable budget &lt; 20% → Opus, shown in statusline</text>
+
+  <text x="64" y="462" class="sans cap">hooks · outside every agent, no way around</text>
+  <g>
+    <rect x="64" y="474" width="256" height="66" rx="10" fill="#1c242e" stroke="#2f3a47"/>
+    <text x="84" y="501" class="mono" fill="#cdd6e0" font-size="15">turn end</text>
+    <text x="84" y="524" class="sans" fill="#8b97a6" font-size="13">compile or type check</text>
+  </g>
+  <g>
+    <rect x="336" y="474" width="256" height="66" rx="10" fill="#2b1b1c" stroke="#7d3a3c"/>
+    <text x="356" y="501" class="mono" fill="#ef8b8d" font-size="15">git commit → gate</text>
+    <text x="356" y="524" class="sans" fill="#8b97a6" font-size="13">build + tests · red blocks</text>
+  </g>
+  <g>
+    <rect x="608" y="474" width="256" height="66" rx="10" fill="#1c242e" stroke="#2f3a47"/>
+    <text x="628" y="501" class="mono" fill="#cdd6e0" font-size="15">secret guard</text>
+    <text x="628" y="524" class="sans" fill="#8b97a6" font-size="13">no reads of .env, keys, tokens</text>
+  </g>
+  <g>
+    <rect x="880" y="474" width="256" height="66" rx="10" fill="#1c242e" stroke="#2f3a47"/>
+    <text x="900" y="501" class="mono" fill="#cdd6e0" font-size="15">work-mode guard</text>
+    <text x="900" y="524" class="sans" fill="#8b97a6" font-size="13">assist: core code stays yours</text>
+  </g>
 
   <line x1="64" y1="566" x2="1136" y2="566" stroke="#2a333e"/>
-  <text x="64" y="598" class="mono" fill="#5b6673" font-size="15">docker · claude code · mcp · hooks</text>
+  <text x="64" y="598" class="mono" fill="#5b6673" font-size="15">rootless container · pinned toolchains · mcp: codegraph, jira (ro), gitea · evals</text>
 </svg>