Was der MZP sich Verruecktes leisten koennte

MCP Apps — der Viewer zieht in den Chat

github.com/modelcontextprotocol/ext-apps (~2,9k Sterne, Spec 2026-01-26, aktiv) · github.com/MCP-UI-Org/mcp-ui (~5,2k, Apache-2.0) · Hosts laut Support-Matrix: Claude Web/Desktop, ChatGPT, VS Code Copilot, M365 Copilot, Cursor, Goose, MCPJam

Die Idee: Ein Tool verweist in seinen Metadaten auf eine ui://-Ressource (HTML), und der Host rendert sie als Iframe in einer Sandbox direkt in der Unterhaltung, mit einem Nachrichtenkanal zurueck zum Server.

Heute endet publishDiagram mit einer URL, und der Mensch wechselt in den Browser. Mit MCP Apps stuende der interaktive Viewer mit Radar, Linse, Steckbrief und Drill-down direkt unter der Antwort. Die Voraussetzungen sind ungewoehnlich gut: viewer.js und radar.js sind Vanilla-IIFEs, die nur aus dem SVG-DOM lesen. Sie brauchen keinen Server-Zustand und kein Framework, also genau das, was in einer Sandbox ohne Netz funktioniert.

beruehrt: DiagramMcpTools, DiagramViewerAssets, mzone-mcp-common · Werkbank zum Testen: MCPJam/inspector · Stufe: Spike, dann Story

Pretext — echte Textmasse statt 8 Pixel pro Zeichen

github.com/chenglou/pretext (~50,6k Sterne, MIT, aktiv) · Mehrzeilige Textmessung und Umbruch ohne DOM-Reflow, ueber Canvas-Metriken, laeuft auch serverseitig

Die Idee: Text einmal vorbereiten (prepare), danach Hoehe, Zeilen und Breite rein arithmetisch berechnen (layout). Das ermoeglicht Shrink-Wrap, ausbalancierte Zeilen und Text, der um Hindernisse fliesst.

NodeContentMetrics rechnet Knotenbreiten mit NAME_CHAR_W = 8 und SUB_CHAR_W = 5.5. Ein „WWW“ wird damit zu schmal geschaetzt, ein „iii“ zu breit. Das eine erzeugt Ueberlaeufe, das andere verschenkt Platz, und beides wirkt ueber die Knotengroesse bis ins Layout und in LAYOUT_QUALITY hinein. Die Schriften liegen bereits im Haus (fonts-maierzone@1.0.0).

beruehrt: NodeContentMetrics, LayoutConstants, ratchet/layout-quality.txt · Stufe: sofort

libavoid und HOLA — orthogonales Routing mit Nudging

github.com/mjwybrow/adaptagrams (~320 Sterne, C++, Monash University; letzter Push 2025-10) · github.com/Aksem/libavoid-js (WASM-Port, LGPL-2.1) · Wybrow/Marriott: „Orthogonal Connector Routing“, HOLA „Human-like Orthogonal Layout“

Die Idee: Kanten werden als kuerzeste orthogonale Wege um Hindernisse gesucht. Danach schiebt ein eigener Schritt (Nudging) parallel verlaufende Segmente auf Abstand, damit sie sich nicht ueberdecken. Dazu minimiert das Verfahren Kreuzungen und Knicke als eigene Kosten.

EdgeRouter baut Elbow-Routen und weicht auf die andere Achse aus, wenn die Primaerroute eine fremde Box kreuzt. Das ist eine gute Heuristik, aber eben keine Suche. Die Beschwerde in MZP-95 (Knaeuel bei wachsender Knotenzahl) ist genau der Fall, fuer den Nudging erfunden wurde: Parallelfuehrung auf derselben Rasterlinie.

beruehrt: EdgeRouter, DiagramValidator#checkAttachSpacing · Stufe: mittelfristig

Umgesetzt als MZP-129 (EdgeNudger, am Ende von EdgeRouter.routeAll): Schrittweite 8 px statt 4, kreuzungsbewusst, dazu eine Glaettung von Kehrtwenden auf derselben Linie, die den Grossteil der Knick-Verbesserung bringt.

Penrose und Bluefish — Beziehungen statt Koordinaten

github.com/penrose/penrose (~8,0k Sterne, MIT, CMU, aktiv) · github.com/bluefishjs/bluefish (~160, MIT, MIT CSAIL)

Die Idee: Penrose trennt Substance (was existiert), Style (wie es aussieht) und Domain (was es geben darf) und loest das Layout als Optimierung ueber Randbedingungen. Bluefish macht Beziehungen wie Align, Stack und Distribute zu eigenstaendigen Elementen des Diagramms.

MZP hat die Trennung schon zur Haelfte: DiagramSpec entspricht Substance, DiagramVariant und DiagramSkinCss entsprechen Style, DiagramTypeSchemas entspricht Domain. Was fehlt, ist die Zwischenstufe zwischen „alles pinnen“ und „alles der Engine ueberlassen“. Heute muss ein Agent, der „Cache steht rechts neben API“ will, Koordinaten setzen, und die Engine laesst das Diagramm dann komplett in Ruhe (LayoutEngine.apply-Fruehausstieg).

Umgesetzt am 2026-10-01 zusammen mit N7 als MZP-146 (Spec docs/superpowers/specs/2026-10-01-layout-constraints-design.md). Anders als hier skizziert: kein Bildschirmvokabular wie rightOf und kein align, sondern flussbezogene Arten sameRank, before und order — die Engine garantiert nur, was Rang und Reihenfolge hergeben. Bausteine: ConstraintGraph, ConstraintRanks, ConstraintOrder, ConstraintValidator. Eine Golden-Baseline fuer das Auto-Layout sichert ab, dass Diagramme ohne Vorgaben unveraendert bleiben. Mit Mermaid traegt das Overlay die Vorgaben.

beruehrt: DiagramSpec, layout/RankAssignment, layout/OrderingPass, DiagramValidator · Stufe: spaeter

LikeC4 — der naechste Paritaets-Massstab nach Archify

github.com/likec4/likec4 (~5,7k Sterne, MIT, Push 2026-09-25) · Architecture-as-Code mit Live-Diagrammen aus dem Code, VS-Code-Erweiterung, eigenem MCP-Server

Die Idee: Ein Modell, viele Sichten. Dynamic Views erzaehlen einen Ablauf Schritt fuer Schritt ueber dieselben Elemente, man navigiert zwischen den Ebenen, und die Diagramme bleiben aktuell, weil sie aus dem Modell generiert werden.

Archify war ein Viewer-Vergleich, und der ist abgearbeitet. LikeC4 misst eine andere Achse: Wie viel Modell steckt hinter dem Bild? Bei MZP sind Drill-down (MZP-111), Views/Kapitel (MZP-54), Simulation (MZP-85) und der Code-Mapper (MZP-88) einzelne Bausteine. Bei LikeC4 sind es Sichten auf ein Modell. Eine Paritaetsliste nach dem Muster von Archify zeigt, welche Luecken echt sind und welche MZP bewusst anders loest.

beruehrt: nichts (Spike) · Folgekandidaten: MZP-85, MZP-111 · Stufe: sofort

FossFLOW / isoflow — Architektur in Isometrie

github.com/markmanx/isoflow (~1,7k Sterne, MIT, Push 2025-09) · github.com/Abrar74774/FossFLOW (Fortfuehrung von stan-smith/FossFLOW, MIT, Push 2026-08)

Die Idee: Infrastruktur-Diagramme als isometrische Szene mit Kacheln auf einer Rautenebene, Knoten als extrudierte Bloecke und Kanten als Pfade am Boden.

Das Layout bleibt, wie es ist. Isometrie ist eine affine Abbildung (matrix(0.866, 0.5, -0.866, 0.5, 0, 0)) ueber die fertigen Koordinaten, dazu zwei Seitenflaechen je Knoten fuer die Tiefe. Fuer deployment und architecture waere das eine neue DiagramVariant, die in einem Pitch-Deck verlaesslich die meisten Blicke bekommt.

beruehrt: DiagramVariant, DiagramSkinCss, SvgRenderer, viewer.js · Stufe: spaeter

Motion Canvas / Revideo — und warum Playwright reicht

github.com/motion-canvas/motion-canvas (~19k Sterne, MIT) · github.com/midrender/revideo (vormals redotvideo/revideo, ~4k, MIT, headless Rendering-API)

Die Idee: Animation als Code mit exakten Frames, gerendert zu Video, bei Revideo sogar headless per API.

MZP-56 hat WebM an Bewegung gekoppelt. Die gibt es seit MZP-54 (trace), und mit MZP-85 kommt der skriptgesteuerte Playback dazu. mzone-render faehrt schon Playwright 1.50, und Playwright nimmt nativ Video auf (recordVideo). Die Seite spielt den Playback ab, der Dienst filmt mit, und heraus kommt ein WebM ohne neue Abhaengigkeit. Revideo lohnt sich erst, wenn Frame-Genauigkeit gebraucht wird, etwa fuer Schnittfassungen.

beruehrt: mzone-render/server.js, DiagramPageRenderer · abhaengig: MZP-85 · Stufe: nach MZP-85

GEPA — Tool-Beschreibungen gegen die eigenen Evals optimieren

github.com/gepa-ai/gepa (~6,8k Sterne, MIT, aktiv) mit MCP-Adapter fuer stdio- und HTTP-Server · arXiv 2602.14878 „MCP Tool Descriptions Are Smelly!“ (2026)

Die Idee: Reflektive Optimierung. GEPA liest Ausfuehrungsspuren (Fehler, falsche Toolwahl), diagnostiziert, woran es lag, und schlaegt gezielt bessere Tool-Beschreibungen und System-Prompts vor. Es braucht dafuer einen Datensatz, eine Metrik und einen Startstand.

Der Datensatz sind die Aufgaben unter evals/tasks/, die Metrik ist das Gate von /mzp-eval (gruen/gelb/rot), der Startstand sind die heutigen @McpTool-Texte. Die Studie misst im Mittel +5,85 Prozentpunkte Erfolgsquote durch bessere Beschreibungen, aber auch Rueckschritte in 16,7 % der Faelle. Genau deshalb passt es: Das Eval-Gate faengt diese Rueckschritte ab.

beruehrt: application/mcp/*McpTools, docs/agent-workflows/evals · Stufe: Spike

VFLM / IntroSVG — das Befund-Overlay

github.com/FolSpark/VFLM („Seeing is Improving“, CVPR 2026, Apache-2.0) · IntroSVG (CVPR 2026, Generator-Kritiker-Schleife) · „See it. Say it. Sorted.“ (arXiv 2508.15222)

Die Idee: generieren, rendern, das Bild ansehen, gezielt verbessern. Die Arbeiten zeigen, dass Layouts in mehreren Runden besser werden, wenn das Modell das gerenderte Ergebnis sieht, statt nur Zahlen zu lesen.

validateDiagram meldet LAYOUT_QUALITY mit edgeCrossings, connectorOverlaps und weiteren Zahlen, dazu visualProof (sichtbare Formen). Mit „3 Kreuzungen“ weiss ein Agent aber nicht, welche Kanten sich kreuzen, und muss raten. Die Geometrie dafuer rechnet LayoutQuality bereits, sie wird nur zu einer Zahl verdichtet.

beruehrt: LayoutQuality, DiagramMcpTools#validateDiagram, DiagramRasterizer · Stufe: (1) sofort, (2) mittelfristig

Annotorious + text-annotator — Review-Links, die zurueckreden

github.com/annotorious/annotorious (~870 Sterne, BSD-3, Push 2026-09-25) · github.com/recogito/text-annotator-js (BSD-3, aktiv) · beide speichern im Format W3C Web Annotation

Die Idee: Rechtecke, Polygone und Textmarkierungen direkt auf Bild und Seite zeichnen und als standardisiertes JSON ablegen.

Review-Links (R13, reviewTtlSeconds bis 7 Tage) bringen ein Artefakt zu Menschen ohne Zugang. Deren Antwort kommt heute per Mail oder Chat, also formlos und ohne Ortsbezug. Mit einer Anmerkungsschicht auf der Preview markiert der Reviewer „diese Kante ist falsch“ direkt am SVG, und der Agent liest die Anmerkungen strukturiert zurueck, mit Koordinate und getroffener data-node-id.

beruehrt: ReviewPreviewStore, neue Flyway-Migration, neues MCP-Tool · Stufe: mittelfristig

visual-explainer — Seitengattungen, die MZP hosten sollte

github.com/nicobailon/visual-explainer (~9,9k Sterne, MIT, Push 2026-08) · Agent-Skill fuer Claude Code, Cursor, Pi u.a.

Die Idee: feste Seitengattungen fuer Agentenarbeit wie /diff-review, /plan-review, /project-recap und /fact-check, jede mit einem eigenen Aufbau statt einer ASCII-Tabelle im Terminal.

Fast 10k Sterne zeigen die Nachfrage. Das Projekt endet aber auf der lokalen Platte. MZP hat alles, was danach kommt: validateArtifact mit Browser-Blick, Versionen, Review-Links und Live-Daten. Interessant sind die Gattungen selbst, vor allem fact-check (ein Dokument gegen den Code pruefen) und project-recap (Wiedereinstieg nach einer Pause).

beruehrt: docs/agent-workflows · Stufe: sofort

GitNexus — ein Code-Wissensgraph vor dem Architecture-Mapper

github.com/abhigyanpatwari/GitNexus (~47,6k Sterne, Push 2026-09-27, Lizenz „Other“, vor jeder Nutzung pruefen) · Code-Graph ohne Server, laeuft im Browser, mit MCP-Anbindung

Die Idee: ein Repo in einen Wissensgraphen aus Symbolen, Aufrufen und erkannten Clustern bzw. Communities verwandeln, abfragbar durch Agenten.

Der code-to-architecture-mapper (MZP-88) muss ein Repo auf 9 Knoten und 12 Kanten verdichten, und diese Aggregation ist der schwierigste Schritt im Workflow. Eine Community-Erkennung auf dem Aufrufgraphen liefert Kandidaten fuer die 9 Knoten mit Begruendung (Kohaesion) statt nach Gefuehl.

beruehrt: docs/agent-workflows/code-to-architecture-mapper.md · Stufe: sofort (nur Dokument)

vtracer — pruefen, ob die Reinzeichnung zur Skizze passt

github.com/visioncortex/vtracer (~7,1k Sterne, MIT, Push 2026-09-26) · Raster zu Vektor, Rust, CLI und WASM

Die Idee: ein Pixelbild in saubere SVG-Pfade zerlegen, farbig oder binaer, mit einstellbarer Glaettung.

Der Workflow verspricht „Skizze treu“. Geprueft wird heute aber nur die innere Passung (.frame-Konvention, Toleranz 0), nicht die Treue zum Foto. Vektorisiert man das Skizzenfoto, erhaelt man Kasten- und Linienkandidaten mit Koordinaten. Legt man diese ueber die Rahmen der Reinzeichnung, faellt ein vergessener Kasten oder ein vertauschter Pfeil auf, bevor ein Mensch hinschaut.

Erledigt ohne vtracer (MZP-139, aus Band 5): Seit das Modell Rahmen in absoluten Pixelkoordinaten liefert, wird das Inventar zur Begleitdatei inventar.json, und die Deckungspruefung laeuft gegen dieses Inventar statt gegen eine Vektor-Trace.

beruehrt: docs/agent-workflows/sketch-to-figure.md, ggf. publishAsset · Stufe: mittelfristig

perfect-freehand + rough-notation — Tuschestrich und Handmarkierung

github.com/steveruizok/perfect-freehand (~5,7k Sterne, MIT, Push 2026-04) · github.com/rough-stuff/rough-notation (~9,7k, MIT; seit 2024 still, aber abgeschlossen und klein)

Die Idee: perfect-freehand macht aus einer Punktfolge eine Kontur mit simuliertem Druck, also an- und abschwellende Linien wie mit Feder. rough-notation zeichnet animierte Handmarkierungen (Kreis, Unterstreichung, Klammer, Highlight) um beliebige Elemente.

analog-v1 zeichnet heute mit gleichmaessigem stroke-width. Echte Kartografie lebt vom Schwellstrich. perfect-freehand erzeugt ihn deterministisch, also mit gleicher Eingabe und gleichem Pfad, und bleibt damit versionierbar. rough-notation ist das fehlende Hover-Vokabular: Beim Ueberfahren wird der Knoten von Hand eingekreist, statt nur einen Tooltip zu zeigen.

Umgesetzt am 2026-10-02 als MZP-147 (Spec docs/superpowers/specs/2026-10-02-analog-tusche-design.md), anders als hier skizziert: keine der beiden Bibliotheken unter /lib/. Der Server rechnet die Schwellstrich-Kontur nach dem perfect-freehand-Muster selbst (TuscheWriter, TuscheBundle), fest ins SVG geschrieben. Damit sehen Seite, figure.svg und figure.png gleich aus. Drei Stricharten (schwell, filter, beide), Opt-in allein ueber die Version: Blaetter auf analog@1.0.0 bleiben unberuehrt. Der Handkreis (rough-notation-Muster) ist ein CSS-Baustein. Die Passungspruefung misst die Kontur und nicht die Mittellinie, Eval art-analog-tusche. Folgebug MZP-145: Bei einer viewBox, die nicht bei 0 begann, schnitt die Filterregion Knoten in translate()-Gruppen weg. Behoben und am 02.10. live nachgeprueft (Region jetzt -Breite … Breite).

beruehrt: static/lib/, sketch-to-figure.md, analog-musterkarte · Stufe: sofort

svgbob — ASCII-Kritzel als vierte Eingabeform

github.com/ivanceras/svgbob (~4,2k Sterne, Apache-2.0, Push 2026-04) · „Convert your ascii diagram scribbles into happy little SVG“

Die Idee: ein Parser, der Box-Zeichnungen aus +--+, | und Pfeilen als Grafik versteht.

MZP-110 hat mit Mermaid gezeigt, wie eine fremde Eingabeform als Uebersetzer in eine DiagramSpec ohne Koordinaten funktioniert. ASCII ist die Form, in der Agenten ohnehin denken, und gleichzeitig eine abgetippte Handskizze. Aus einer ASCII-Zeichnung lassen sich Boxen mit Text, Verbindungen und sogar die relative Lage gewinnen. Die Lage liefert A4 gratis Constraints.

Umgesetzt am 2026-10-01/02 als MZP-148 (Spec docs/superpowers/specs/2026-10-01-ascii-input-design.md) als eigener Raster-Scanner in Java, ohne svgbob-Code, WASM oder Sidecar. Eingang ist ein eigener Tool-Parameter ascii und kein Feld im JSON, damit Backslashes und Zeilenumbrueche nicht maskiert werden muessen. diagramJson wirkt als Overlay (Titel, nodeType, Icons). Die Lage wird wie geplant zu Vorgaben: Laufrichtung aus den Pfeilen, Kaesten auf derselben Fluss-Ebene als order. Mermaid und ASCII teilen sich jetzt importer/ (Overlay, Ids). Die Fehlermeldungen zeigen den Weg (ASCII_EDGE_DANGLING mit Zeile und Spalte: „Zwischen Linie und Kastenrand darf kein Leerzeichen stehen“). In der Live-Probe ist genau daran der erste Versuch gescheitert. Eval dia-ascii-architecture.

beruehrt: neues Paket application/support/diagram/ascii, DiagramMcpTools · Stufe: spaeter

StarVector / OmniSVG / SkeTikZ — der Datensatz ist das Geschenk, nicht das Modell

github.com/joanrod/star-vector (~4,6k Sterne, Apache-2.0) · github.com/OmniSVG/OmniSVG (~2,6k, Apache-2.0, NeurIPS 2025) · Sketch2Diagram / SkeTikZ (ICLR 2025, 3.231 Paare aus Handskizze und TikZ)

Die Idee: Bild-zu-SVG als Codegenerierung. Die Modelle sind gross, brauchen eine GPU und scheiden damit fuer den Betrieb aus.

Interessant ist SkeTikZ: echte Handskizzen mit Referenzdiagramm. Das ist genau die Eingabe von Sketch-to-Figure. Zwanzig ausgewaehlte Paare als evals/tasks/eval-sketch-* machen messbar, wie gut ein Agent mit dem MZP-Werkzeug eine Skizze umsetzt, gemessen gegen die Referenz, etwa ueber Knotenzahl, Kantenzahl und Deckung (siehe D1).

beruehrt: docs/agent-workflows/evals · abhaengig: D1 · Stufe: spaeter

Tone.js — eine Klangspur fuer den Simulationsmodus

github.com/Tonejs/Tone.js (~14,7k Sterne, MIT, Push 2026-09-16) · Web-Audio-Framework

Die Idee: Musik und Klang im Browser programmieren, mit Takt, Synthesizern und Effekten.

MZP-85 bringt Schritt-Arten (active | reject | commit | review | pass). Hoerbar gemacht bekommt jede Art einen Klang: commit einen aufloesenden Akkord, reject eine Dissonanz, die Tonhoehe folgt dem Rang des Knotens. Wer den Ablauf abspielt, hoert eine Schleife, bevor er sie sieht. Der ernste Kern ist Sonifikation als Barrierefreiheit: Ein Ablaufdiagramm, das man hoeren kann, ist fuer blinde Nutzer mehr als ein Alt-Text.

beruehrt: viewer.js (Playback aus MZP-85) · abhaengig: MZP-85 · Stufe: spaeter

CodeCharta — die Ratschen als begehbare Stadt

github.com/MaibornWolff/codecharta (~540 Sterne, BSD-3, Push 2026-09-26) · Code-Metriken als 3D-Stadt: Grundflaeche = LOC, Hoehe und Farbe = weitere Metriken

Die Idee: Ein Repo wird zur Stadtkarte, Pakete sind Viertel, Dateien Gebaeude. Wo es brennt, sieht man aus der Vogelperspektive.

Die Ratschen-Register tragen genau solche Zahlen: filesize.txt (LOC je Datei mit Begruendung), coverage.txt (Abdeckung je Paket), boundaries.txt (Kanten). three@0.170.0 liegt bereits unter /lib/, und E11 kann Zahlen live liefern. Eine Stadt, in der jede Registerausnahme als rot gluehendes Hochhaus steht, ist die ehrlichste Darstellung von „die Ratschen halten den Bestand, statt ihn zu verbessern“.

Umgesetzt anders als geplant (MZP-144): keine Live-Datenquelle ratchets, sondern ein Schnappschuss city.json in priv-ratschen-stadt, gezeigt als Admin-Rubrik ix. Der Grund: Klassennamen und Registerbegruendungen gehoeren nicht auf eine oeffentliche Seite. Nach jedem Deploy neu bauen mit mvn test && python scripts/ratchet-city.py --publish.

beruehrt: application/support/livedata, src/test/resources/ratchet · Stufe: spaeter

pixelmatch / odiff — die Pixel-Baseline fuer den Layout-Korpus

github.com/mapbox/pixelmatch (~7k Sterne, ISC, ~150 Zeilen, keine Abhaengigkeiten) · github.com/dmtrKovalenko/odiff (~3,2k, MIT, SIMD) · github.com/lost-pixel/lost-pixel (~1,7k, MIT, als Vergleichsprojekt)

Die Idee: zwei Renderings pixelgenau vergleichen und ein Differenzbild erzeugen, als Alternative zu Percy oder Chromatic.

LayoutQualityRatchetTest zaehlt Kreuzungen, Ueberlappungen und Knicke ueber einen festen Korpus. Eine Aenderung, die die Zahlen haelt, das Bild aber verschiebt (Farbe, Abstand, Schrift), rutscht durch. Zwei Anwendungen: (1) Pixel-Baseline fuer den Korpus in mzone-render, (2) diffVersions bekommt ein visuelles Diff zwischen zwei Versionen einer Seite als PNG mit markierten Aenderungsflaechen.

beruehrt: mzone-render, PublisherMcpTools#diffVersions · Stufe: mittelfristig

greadability — Lesbarkeit von Graph-Layouts als Zahl

github.com/rpgove/greadability (~80 Sterne, BSD-3; seit 2018 still, verletzt damit die Aktivitaetsregel und wird bewusst nur als Definitionsquelle genommen) · Gove 2018, „It Pays to Be Lazy“

Die Idee: vier Metriken fuer die Lesbarkeit von Layouts, jeweils normiert auf 0 bis 1. Kreuzungsanteil, Kreuzungswinkel (90° ist gut), Winkelaufloesung am Knoten und Kantenlaengen-Varianz.

LayoutQuality zaehlt Kreuzungen, misst aber nicht ihren Winkel. Eine rechtwinklige Kreuzung liest sich fast so gut wie keine, eine spitze ist ein Knaeuel. Bei orthogonalem Routing ist der Winkel zwar meist 90°, wichtig wird er bei Kurven und schraegen Kanten (Radial- und Mindmap-Layout).

beruehrt: LayoutQuality, LayoutQualityRatchetTest · Stufe: sofort

Abnahme-Runde, bevor Neues dazukommt

Im Backlog stehen aus dieser Recherche allein acht Tickets auf REVIEW (MZP-119, 120, 121, 122, 123, 124, 126 und 129). Solange sie dort liegen, weiss niemand, ob „umgesetzt“ auch „abgenommen“ heisst. Dazu kommt Buchhaltung: Das Spike-Ticket MZP-118 steht noch auf IDEA, obwohl MZP-126 es inhaltlich erledigt hat. MZP-128 („Tool behauptet ein Chat-Widget, das es nicht gibt“) ist am selben Tag entstanden wie MZP-126 und muss gegen einen MCP-Apps-faehigen Host neu bewertet werden: Dort stimmt der Hinweis inzwischen. Relevant bleibt er nur fuer Hosts ohne MCP Apps.

beruehrt: Backlog · Stufe: sofort

MZP-127 zu Ende messen und das Muster ausrollen

Variante B ist live, die Beschreibung von validateDiagram ist von 7.160 auf 3.780 Zeichen gefallen. Die Messung A gegen B steht aber aus, und das Ticket selbst verlangt sie, bevor etwas als gut gilt. Dabei ist ein Haken zu beachten: Der Plan sah A vor dem Deploy vor. Da B jetzt schon live ist, muss A gegen einen lokalen Stand vor a22e331 laufen, sonst werden zweimal dieselben Texte verglichen.

beruehrt: evals/, application/mcp/*McpTools, DiagramInputGuide · Stufe: sofort

Hotspots im Chat-Viewer statt eines markierten PNG

C2 Teil 2 wollte ein PNG mit roten Markern ueber DiagramRasterizer zurueckgeben. Seit MZP-126 gibt es dafuer einen billigeren Weg: Der Chat-Viewer rendert das Diagramm ohnehin, und hotspots[] liefert Art, Koordinate und IDs. Die Live-Probe vom 2026-09-28 zeigt das Format: {"kind":"connectorOverlap","x":272,"y":164,"ids":["e1","e2"]}. Die Marker kommen als Overlay-Schicht in den Viewer, und die betroffenen Kanten werden mit dem vorhandenen markActive hervorgehoben.

beruehrt: chat-bridge.js, viewer.js, DiagramMcpTools#getDiagramChatView · ersetzt: C2 Teil 2 · Stufe: sofort

queryDiagram: den publizierten Graphen befragen

Das ist Luecke 2 aus MZP-124. Der LikeC4-MCP bietet query-incomers-graph, query-outgoers-graph und find-relationship-paths. MZP hat Reach-Trace und Routen-Sonde, aber nur im Browser. Ein Agent kann einen publizierten Graphen deshalb nicht fragen, was von db abhaengt, ohne das ganze JSON in den Kontext zu laden.

beruehrt: DiagramMcpTools (neues Tool), getArtifactSource-Lesepfad · Stufe: sofort

DRILLDOWN_EDGE_MISSING: Ebenen gegeneinander pruefen

Das ist die billige Form von Luecke 1 aus MZP-124. LikeC4 hebt Kanten automatisch in die hoeheren Ebenen, weil alles ein Modell ist. MZP verbindet zwei unabhaengige Specs ueber drillDown, deshalb koennen die Kanten auseinanderlaufen. Statt ein gemeinsames Modell zu bauen, reicht eine Pruefung: Kanten, die im Unterdiagramm nach aussen fuehren, brauchen eine Entsprechung am Elternknoten.

beruehrt: DiagramValidator, MZP-111-Pfad · Stufe: sofort

Kehrtwenden an der Quelle vermeiden

MZP-129 hat einen Router-Befund zutage gefoerdert: Der Router erzeugt Routen wie (x,112) → (x,104) → (x,248). EdgeNudger.ohneZacken glaettet sie nachtraeglich, das bringt den Grossteil der Verbesserung (Knicke −52). Die Ursache sitzt aber im Router. Solange nachtraeglich geglaettet wird, rechnen Validator-Pfade vor dem Nudger auf verzackten Routen.

beruehrt: EdgeRouter, EdgeNudger, ratchet/layout-quality.txt · Stufe: mittelfristig

MZP-85 ziehen, weil drei Funde daran haengen

Der Simulationsmodus steht seit dem 2026-09-07 auf READY, und der Spike MZP-87 hat Schema und DOM-Vertrag bestaetigt. An ihm haengen A7 (WebM ueber Playwright recordVideo), D5 (Klangspur) und die LikeC4-Beobachtung zu Dynamic Views: Schritt-Labels unabhaengig vom Kantenlabel mitdenken, also text pro Schritt statt Kantenbeschriftung. Die Vorbedingung aus dem Ticket (MZP-91/92 landen lassen) ist erfuellt, beide stehen auf DONE.

beruehrt: viewer.js, viewer.css, DiagramPageRenderer, neuer SimulationValidator · Stufe: Entscheidung

Auswahl im Chat wird zur Layout-Vorgabe

A4 (Constraints statt Koordinaten) scheiterte an der Frage, wie ein Agent „Cache rechts neben API“ ausdrueckt. Mit dem Rueckkanal aus MZP-126 kann der Mensch es zeigen: Er zieht im Chat-Viewer zwei Knoten nebeneinander, die Bruecke meldet {"rightOf":["cache","api"]} als Modellkontext, und der Agent schickt es als constraints[] an validateDiagram. Die Engine behaelt das Auto-Layout und nimmt den Wunsch nur als Vorgabe fuer Rang und Reihenfolge.

Umgesetzt am 2026-10-01 als MZP-146 (chat-wuensche.js): Der Mensch formuliert Wuensche per Geste oder Tastatur im Chat-Viewer, die Bruecke meldet sie zusammen mit Auswahl und Hotspot als einen Kontext-Bericht an den Agenten, und der Agent schickt sie als constraints[] an validateDiagram. Der Viewer layoutet bewusst nicht selbst neu.

beruehrt: chat-bridge.js, DiagramSpec, layout/ · abhaengig: A4 · Stufe: spaeter

Visuelles Diff als dritte Spalte im diff-review

Der Workflow diff-review.md (MZP-122) zeigt das Architektur-Delta ueber diffDiagram und die bewegten Ratschen-Zeilen. Was fehlt, ist das Bild: Wie sieht der Korpus nach der Aenderung aus? E1 (pixelmatch) wollte das als Ratsche. Als Review-Beilage ist es kleiner und sofort nuetzlich: fuer die fuenf Korpusgraphen mit der groessten Aenderung in layout-quality ein Vorher/Nachher-PNG und ein Differenzbild.

beruehrt: mzone-render, docs/agent-workflows/diff-review.md · abhaengig: E1 (Bibliothek) · Stufe: mittelfristig

Mermaid-Fehler, die den Weg zeigen

Aus dem B-Lauf zu MZP-127: Beide Haiku-Fehlschlaege und ein teurer Umweg hingen nicht am Beschreibungstext, sondern an der Fehlermeldung. Haiku erfindet Dialekte (architecture, quadrant-diagram) und schreibt Subgraph-Ids mit Umlaut (prüfkette → „Zeile 12 nicht lesbar“). Das kostet jeweils 1–4 Aufrufe.

beruehrt: application/support/diagram/mermaid · Stufe: sofort

analog-v1 vom Server erklaeren

Der D4-Spike (MZP-130) hat einen Blocker gefunden, der schwerer wiegt als die Lizenzfrage: Snippet, Bausteinkatalog und .frame-Konvention leben nur in docs/agent-workflows/sketch-to-figure.md. Ein Agent ohne Repo-Zugriff kann den Stil nicht kennen, und jede Sketch-Eval wuerde vor allem das messen.

beruehrt: CapabilitiesAssembler, sketch-to-figure.md · Stufe: vor jeder Sketch-Eval