GitHub-Recherche · Integrations-Analyse

Was der mzone-publisher als Naechstes integrieren koennte

Zwanzig Ideen aus fremden Repos, jede auf den Publisher zugeschnitten statt kopiert

Datum: 2026-09-03
Anlass: Nutzbarkeits- und Integrationsanalyse — welche fremden Werkzeuge tragen eine Idee, die MZP fehlt
Methode: Keine Uebernahme von Code. Pro Quelle: die tragende Idee, dann ein konkreter Zuschnitt auf die vorhandene Architektur — mit Nennung der Klasse/Datei, die es beruehrt
Grundlage: 18 Projekte und Spezifikationen (Quellenliste am Ende), Stand der Codebasis: Branch p1-safety-nets
Kein Thema: Neue Laufzeit-Abhaengigkeiten, ein zweiter Such-/Graph-Stack, Rewrite bestehender Engines. Der Bestand deckt fast alles — die Ideen setzen darauf auf

TL;DR

Der Publisher ist reif: Wiki-Engine mit Kanten-Graph, serverseitiger Diagramm-Renderer mit 27 Typen und Interaktions-Viewer, Artefakt-Pipeline mit Versionen und Render-Check, Backlog-Cockpit. Die Luecken liegen nicht mehr im Kern, sondern an den Raendern: wie ein Agent den Wissensbestand liest (heute lexikalisch, ein Roundtrip pro Seite), wie fremde Formate herein- und herauskommen (heute gar nicht), und welche MCP-Grundtypen der Server anbietet (heute nur Tools).

Die fuenf Zuschnitte mit dem besten Verhaeltnis aus Wirkung und Aufwand:

Hybride Suche in knowledgeQuery — tsvector + Embedding-Spalte + Reciprocal Rank Fusion, alles in Postgres, kein neuer Dienst. Loest das seit MZP-38 offene Ziel „gutes Memory fuer den Agenten“.
llms.txt und /published/{slug}.md — zwei Serialisierer ueber vorhandene Daten. IDE-Agenten holen sich das aktiv; MZP publiziert fuer Agenten zuerst.
MCP-resources und prompts — Seiten als adressierbare Ressourcen statt nur als Tool-Ausgabe; die Publish-Workflows als geladene Prompt-Vorlagen.
Transklusion ![[slug#abschnitt]] im MarkdownRenderer — eine Quelle, an vielen Stellen eingebettet. Genau das Muster, das ADRs und Runbooks brauchen.
GitHub-Alerts > [!WARNING] im Markdown — De-facto-Standard, den Agenten ohnehin schon schreiben, in mz--Optik gerendert.

1 · Diagramm-Engine

MZP hat hier die groesste Eigenleistung: DiagramSpec → Validierung → LayoutEngine → EdgeRouter → SvgRenderer, 27 Typen, Viewer aus MZP-53, gefuehrte Kapitel (MZP-54), Delta-Quittungen (MZP-55). Die folgenden Ideen erweitern die Eingangs- und Ausdrucks-Seite, nicht die Render-Mechanik.

1.1 Structurizr — ein Modell, viele Sichten

structurizr.com · „models as code“ fuer das C4-Modell, Referenzimplementierung des C4-Autors

Der Kerngedanke: Elemente und Beziehungen werden einmal in einem Modell definiert, daraus werden mehrere Sichten auf verschiedenen Ebenen abgeleitet — Namen, Beschreibungen und Styling bleiben ueber alle Diagramme konsistent, weil sie aus einer Quelle stammen.

Zugeschnitten auf MZP MZP-54 hat mit meta.views bereits Kameras ueber einer Topologie — der naechste Schritt derselben Idee ist ein optionaler model-Block im DiagramSpec, in dem Knoten und Kanten leben, und ein views[], dessen Eintraege je eine Teilmenge samt Detailgrad waehlen. Jede Sicht wird als eigenes SVG unter /published/{slug}/{viewId} gerendert — derselbe Bundle-Mechanismus wie heute, nur mehrere index-Seiten. Kein C4-Werkzeugkasten, keine Deployment-Nodes: nur „ein Spec, mehrere abgeleitete Bilder“. Passt zum Wissens-Graphen — eine Sicht kann auf wiki-svc-*-Slugs zeigen.

beruehrt: DiagramSpec, DiagramTypeSchemas, DiagramPageRenderer · reiht sich hinter MZP-54

1.2 D2 — Ports, Layout-Hinweis, Nachbarschafts-Pin

github.com/d2lang/d2 · Text-zu-Diagramm, drei Layout-Engines (dagre / ELK / TALA), MPL-2.0

D2 laesst pro Diagramm die Layout-Engine waehlen, kennt Ports (feste Andockpunkte an der Knotenkante), ein near-Schluesselwort (einen Knoten relativ zu einem anderen oder zu einer Leinwand-Ecke fixieren) und Klassen zum Stylen vieler Knoten auf einmal.

Zugeschnitten auf MZP Der EdgeRouter waehlt heute Seite und Andockpunkt selbst (bewusst, siehe Engine-AGENTS.md). Fuer die Faelle, in denen ein Autor eine Kante deterministisch fuehren will — Legenden, feste Bus-Topologien — traegt ein optionales ports-Array am Knoten benannte Andockpunkte; fehlt es, routet der Server wie bisher. Der near-Gedanke passt auf freie Elemente wie Titel und Legende: anchor: "top-right" statt Pixelkoordinaten. Die Layout-Engine-Wahl bleibt aussen vor — MZP hat genau eine, und das ist gut so.

beruehrt: EdgeRouter, DiagramGeometry, DiagramSpec (nodes[].ports) · Nebenbefund passt zu MZP-57

1.3 Kroki — fremde Diagramm-Sprachen als Eingang

github.com/yuzutech/kroki · ein API-Gateway vor ~30 Text-Diagramm-Sprachen (Mermaid, PlantUML, D2, Graphviz, C4 …)

Kroki vereinheitlicht viele Diagramm-DSLs hinter einer HTTP-Schnittstelle. MZP wird keine 30 Renderer einbauen — die uebernehmbare Idee ist der Adapter, nicht der Zoo.

Zugeschnitten auf MZP Ein schmaler Import-Pfad: validateDiagram/publishDiagram akzeptieren neben DiagramSpec-JSON auch Mermaid- oder Graphviz-Quelltext, parsen die Teilmenge, die sich auf Knoten/Kanten/Label abbildet (Flowchart, Sequence, ER, State), und erzeugen daraus ein natives Spec — das dann die maierzone-Optik, den Viewer und die Delta-Faehigkeit erbt. Nicht abbildbare Konstrukte kommen als NOTICE zurueck, nicht als Fehler. „Bring dein Mermaid, bekomm ein MZP-Diagramm.“ Senkt die Einstiegshuerde fuer Agenten, die Mermaid schon koennen.

beruehrt: neuer DiagramSpecParser-Eingang, DiagramMcpTools · eigenstaendig, kein Ticket

1.4 JSON Canvas — offenes Austauschformat fuer Knoten/Kanten

jsoncanvas.org · Obsidian-Canvas-Format, Spec 1.0, {nodes:[], edges:[]}, unbekannte Felder werden ignoriert

Ein bewusst kleines, erweiterbares Dateiformat fuer „infinite canvas“-Daten. Jeder Knoten hat id, type, x, y, width, height, jede Kante fromNode/toNode.

Zugeschnitten auf MZP Zwei Serialisierer, kein Format-Krieg:

Export einer .canvas-Datei aus (a) einem Diagramm-Spec und (b) einer Nachbarschaft des Wissens-Graphen (knowledgeQuery-Ergebnis) — damit oeffnet ein Mensch den maierzone-Graphen in Obsidian Canvas oder jedem anderen Infinite-Canvas-Werkzeug, lesend.
Import .canvas → DiagramSpec fuer handgelegte Layouts, die dann in der Engine landen.

Der Graph liegt schon als page_link-Tabelle vor; das Diagramm ohnehin als Knoten/Kanten. Der Aufwand ist eine Abbildung, kein Feature.

beruehrt: GraphClusterKey/knowledgeQuery-Ausgabe, DiagramDeltaService-Umfeld · verwandt mit MZP-38

1.5 Mermaid — die fehlenden Diagrammtypen (kuratiert)

github.com/mermaid-js/mermaid · 2026 neu: Wardley, Ishikawa, Cynefin, Requirement, Packet, XY-Chart, Railroad/EBNF

Mermaid ist kein Vorbild fuer Optik, aber ein guter Katalog dafuer, welche Diagrammarten Leute vermissen. MZP hat 27 Typen; die Frage ist nicht „alle nachziehen“, sondern welche drei zum Haus passen.

Zugeschnitten auf MZP Drei Kandidaten mit klarem Nutzen fuer einen Infrastruktur- und Wissens-Betrieb: requirement (Anforderungs-/Nachverfolgbarkeits-Diagramm — bindet an das Backlog: Ticket → erfuellt von → Komponente), wardley-map (Strategie/Reifegrad), user-journey. Jeder Typ ist Arbeit an drei Stellen (Registry, Schema, Budget — steht in der Engine-AGENTS.md); deshalb kuratiert und nicht als Liste.

beruehrt: TypeRendererRegistry, DiagramTypeSchemas, DiagramBudgets · je Typ ein eigenes Ticket

1.6 Excalidraw — Skizzen-Variante und Whiteboard-Export

docs.excalidraw.com · .excalidraw-JSON ist programmatisch erzeugbar, restoreElements fuellt Defaults

Excalidraws Wert ist der informelle, handgezeichnete Look und ein offenes Szenen-JSON, das man generieren und im Browser visuell pruefen kann.

Zugeschnitten auf MZP Zwei kleine Dinge: (1) eine meta.variant: "sketch" neben den vorhandenen minimal | dark | full-editorial — rauhe Striche fuer bewusst unfertige Diagramme (reine SvgRenderer-Filter-Sache, kein neuer Renderer). (2) Ein Export nach .excalidraw, damit ein publiziertes Diagramm in eine Whiteboard-Session gezogen und von Hand weiterbearbeitet werden kann. Beides ergaenzt den geplanten Export-Ausbau in MZP-56.

beruehrt: DiagramTokens/SvgRenderer (Variante), neuer Export neben diagram.svg · passt in MZP-56

2 · Wiki- und Wissens-Engine

Vorhanden: bodyMd als erstklassiges Feld (MZP-38), page_link-Kanten mit Backlinks, knowledgeQuery, d3-Graph mit Clustering (MZP-43), lintWiki fuer Freshness/Orphans/Drift, Postgres-Volltext, Editor unter /admin/wiki (MZP-40).

2.1 pgvector + BM25 — hybride Suche in Postgres

pgvector · ParadeDB / pg_textsearch / VectorChord · Muster: tsvector-Spalte + vector-Spalte + Reciprocal Rank Fusion

Der 2026er Standard fuer Doku-Retrieval: eine tsvector-Spalte fuer lexikalische Treffer, eine vector-Spalte fuer semantische, eine Abfrage, die beide Rangfolgen mit RRF verschmilzt. Ohne dedizierten Suchcluster.

Zugeschnitten auf MZP knowledgeQuery und fullTextSearch sind heute rein lexikalisch. Die Datenbank ist schon Postgres — es fehlt nur die pgvector-Extension, eine Embedding-Spalte auf published_pages, ein Embedding je Seite beim Publish (kleines lokales Modell oder eine Embedding-API) und ein semantic: true in der Filter-Signatur. Das ist der groesste Einzelhebel fuer das in MZP-38 formulierte Ziel — „ein gutes Memory fuer den Agenten“: Suche findet dann auch, was anders benannt wurde als gefragt. Ehrlich zum Aufwand: neue Flyway-Migration, ein Ort fuer die Embedding-Erzeugung, Nachdenken ueber Re-Embedding bei Aenderungen.

beruehrt: V23-Migration, PublishedPageRepository, KnowledgeMcpTools, PublishService · fuer MZP-38-Folge

2.2 Quartz / Obsidian — Transklusion und Block-Einbettung

quartz.jzhao.xyz · Digital-Garden-Generator: Transklusion, Wikilinks, Backlinks, Graph „out of the box“

Quartz rendert ![[note]] und ![[note#heading]] als eingebetteten Ausschnitt der Zielseite — nicht nur als Link.

Zugeschnitten auf MZP MZP kennt [[slug]] als Kante, aber kein ![[slug]]. Der MarkdownRenderer loest die Einbettungs-Form beim Rendern auf und fuegt einen Ausschnitt (ganze Seite oder ein #abschnitt) mit einem „Quelle“-Chip ein. Hoher Wert fuer ein Wiki, in dem ADRs und Runbooks denselben Kontext wiederholen: eine Wahrheit, mehrfach eingebettet. Muss Zyklen erkennen, eine Tiefe begrenzen und priv--Seiten respektieren (nie in eine oeffentliche Seite einbetten).

beruehrt: MarkdownRenderer, PageLinkExtractor, PrivateSlugs · ergaenzt MZP-40

2.3 Vale — Hausstil als Lint-Regelklasse

vale.sh · markup-bewusster Prosa-Linter, YAML-Regeln, Stile (Google/Microsoft/Haus), schliesst Code-Bloecke aus

Vale bringt Linting auf Prosa: Regeln als YAML (verbotene Woerter, Satzlaenge, Gross-/Kleinschreibung), Stile als Regel-Ordner. Es versteht Markdown genug, um an Syntax keine Fehlalarme zu werfen.

Zugeschnitten auf MZP Nicht die Binary uebernehmen, sondern das Regelmodell: lintWiki prueft heute Struktur (Freshness, Orphans, Drift), nicht Redaktion. Ein Haus-Regelsatz — „keine Umlaute in Bezeichnern“ (steht in AGENTS.md), „Javadoc begruendet, es beschreibt nicht“, verbotene Marketing-Woerter, Ueberschriften-Schreibweise, maximale Satzlaenge — laeuft als zusaetzliche Befundklasse ueber bodyMd, mit Zeilennummer. Die Regelformen existence, substitution, occurrence sind in ~50 Zeilen nachgebaut.

beruehrt: FreshnessCalculator-Umfeld, LintWiki-Tool, MarkdownRenderer (Token-Zugriff) · neue Befundklasse in lintWiki

2.4 GitHub-Alerts — Callouts im Markdown

github.com/chrisweb/rehype-github-alerts · > [!NOTE|TIP|IMPORTANT|WARNING|CAUTION], seit Ende 2023 De-facto-Standard

Fuenf Callout-Typen als Erweiterung des Blockquote, case-insensitiv. Praktisch jeder Markdown-Agent schreibt sie inzwischen.

Zugeschnitten auf MZP Eine kleine Block-Erweiterung im commonmark-Parser des MarkdownRenderer, die [!WARNING] & Co. auf mz--Callout-Markup abbildet — das Design-System hat Karten und mz-pill-Severity schon. Billig, hohe Wirkung auf die Lesbarkeit, und es passt zu Text, den Agenten ohnehin liefern.

beruehrt: MarkdownRenderer (commonmark-Extension) · Teil von MZP-40 oder eigenstaendig

2.5 lychee — tote externe Links melden

github.com/lycheeverse/lychee · asynchroner Link-Checker, kennt Rate-Limits und Retries

lintWiki-Drift schaut nur nach innen. Ausgehende http(s)-Links im bodyMd und in crossRefs veralten still.

Zugeschnitten auf MZP Ein geplanter Job im vorhandenen infrastructure/scheduling prueft periodisch die externen Links und meldet 404/Timeout als lintWiki-Befund, gekoppelt an die Freshness-Anzeige. Kein Fremdcode noetig — ein HEAD mit Timeout ueber die schon extrahierten Links (PageLinkExtractor trennt intern/extern bereits).

beruehrt: infrastructure/scheduling, PageLinkExtractor, LintWiki · kleiner eigener Job

2.6 Docusaurus — Herkunft am Seitenfuss zeigen

docusaurus.io/docs/versioning · „Last updated / Edit this page“ aus Git-Metadaten

Docusaurus blendet unter jeder Seite ein „zuletzt geaendert am / von“ und einen Bearbeiten-Link ein — die Herkunft wird fuer den Leser sichtbar, nicht nur fuer ein Lint-Tool.

Zugeschnitten auf MZP MZP hat getPageHistory, PageVersion, lastVerified und freshnessStatus — alle Daten liegen da. Ein schmaler Herkunfts-Fuss auf /published/{slug}: „zuletzt geaendert 2026-09-01 · Version 7 · actor“ plus Link auf diffVersions. Macht Freshness fuer den Menschen sichtbar, der die Seite liest, statt nur im lintWiki-Report.

beruehrt: wiki-page-Template, PublishService (Kontext-Anreicherung) · klein

3 · Artefakt-Pipeline und Auslieferung

Vorhanden: Bundle-Publish mit bis zu 64 Dateien, gepinnte Libs unter /lib/ (immutable), TTL-Previews mit Browser-Blick (MZP-49), Versionen/Rollback, Reachability- und Render-Check, mz-body-Pruefung, brotli/gzip, getArtifactSource als Readback.

3.1 llms.txt & Mintlify — .md-Quelle unter fester URL

llmstxt.org · Spec v2 (Aug 2026), W3C-Vorschlag Juni 2026 · Cursor, Claude Code, Copilot, Cline, Aider holen es aktiv

Zwei Konventionen haben sich durchgesetzt: eine /llms.txt als agentenlesbarer Index der Site, und je Doku-Seite eine .md-Fassung unter vorhersagbarer URL, damit ein Agent Quelltext statt gerendertes HTML zieht. AI-Crawler ignorieren llms.txt weitgehend — IDE-Agenten nutzen es routinemaessig.

Zugeschnitten auf MZP MZP publiziert fuer Agenten zuerst — hier ist der Nutzen unmittelbar, der Aufwand gering:

/published/llms.txt — generierter Index: Titel, Einzeiler, URL je current-Seite, gruppiert nach Slug-Praefix (svc/run/adr/log). Ein Serialisierer ueber listPublishedPages.
/published/{slug}.md — der rohe bodyMd (oder eine Markdown-Reduktion einer Template-Seite) unter fester, auth-freier URL. MZP hat das halb ueber getArtifactSource — das ist die HTTP-, konventionell benannte Fassung davon.

Princetons GEO-Bench (Mai 2026) misst fuer Seiten mit strukturiertem llms.txt 23 % mehr KI-Zitationen — fuer MZP zweitrangig, aber kein Nachteil.

beruehrt: PublishedPageServingController, neue Routen, SearchPageRoutingConfig-Muster

3.2 Repomix / Gitingest — Praefix als ein Buendel

github.com/yamadashy/repomix · packt viele Dateien in eine KI-freundliche Datei, mit Token-Zaehlung und erklaerender Praeambel

Repomix und Gitingest erzeugen aus einem Repo einen einzelnen Text mit Kopfzeile (was ist das, wie ist es strukturiert) und Token-Schaetzung — damit ein Agent den ganzen Kontext in einem Zug laedt.

Zugeschnitten auf MZP /api/wiki/pack?prefix=wiki-adr → ein Markdown-/XML-Digest aller passenden Seiten, mit erklaerendem Kopf und Token-Schaetzung. Das ist „gib dem Agenten den kompletten ADR-Satz in einem Fetch“ — komplementaer zur hybriden Suche (2.1): Suche fuer den Punkt-Treffer, Pack fuer die Bulk-Ladung. Setzt auf MZP-46 (Wiki-API) auf.

beruehrt: neuer /api/wiki-Endpunkt · direkt an MZP-46

3.3 SRI + Import-Maps — Libs haerten und lesbar referenzieren

Subresource-Integrity (W3C) · Import-Maps (WICG) — bare specifier statt harter Pfad

Zwei Browser-Standardmechanismen, die die Lib-Auslieferung sicherer und den Artefakt-Code sauberer machen.

Zugeschnitten auf MZP Die README-Notiz warnt selbst: eine /lib/-Datei, die ohne Versionswechsel getauscht wird, bleibt unsichtbar. Abhilfe:

getCapabilities().libs liefert je Datei einen sha384-Hash — beim Classpath-Scan in LibRegistry berechnet, Nullkosten zur Laufzeit —, damit ein Artefakt integrity="sha384-…" schreiben kann.
Optional injiziert der Server eine <script type="importmap">, die three/d3 auf die gepinnten Pfade abbildet — Artefakt-Code liest sich dann wie normales ESM, ein Versionswechsel ist eine Map-Zeile.

beruehrt: LibRegistry, CapabilitiesAssembler, ArtifactValidator (integrity zulassen)

3.4 Scalar — lebende Referenz der eigenen Schnittstelle

github.com/scalar/scalar · rendert OpenAPI zu einer schnellen, interaktiven Referenz mit API-Client; in ASP.NET Core 9 Standard statt Swagger UI

Scalars Muster: aus einer Maschinenbeschreibung wird eine durchsuchbare, interaktive Referenzseite, die beim Deploy neu entsteht.

Zugeschnitten auf MZP McpToolCatalog baut die Tool-Liste samt Parameter-Schemas schon per Reflection (dieselbe Quelle wie getCapabilities). Daraus eine Seite /published/mzp-api generieren: jedes MCP-Tool, seine Parameter, Typen, Beschreibungen, einmal ordentlich gesetzt — regeneriert bei jedem Start. Nicht Scalar einbauen, sondern das „Schema → Referenz“-Muster auf den Katalog anwenden, den MZP schon hat. Selbstdokumentierend, und der wiederkehrende „welchen Parameternamen will searchPages“-Stolperer (im Katalog-Javadoc benannt) verschwindet.

beruehrt: McpToolCatalog, ein neuer generierter Renderer · klein-mittel

4 · MCP-Oberflaeche

MZP exponiert ~39 Tools, alle als @McpTool. Der Server bietet keine resources und keine prompts an — die beiden anderen Server-Grundtypen des Protokolls. Die Spezifikation vom 28.07.2026 hat ausserdem einen zustandslosen Kern, cachebare Listen und Multi-Round-Trip-Requests fuer Elicitation gebracht.

4.1 Seiten als resources, nicht nur als Tool-Ausgabe

modelcontextprotocol.io · Spec 2026-07-28: resources/list + resources/read tragen jetzt ttlMs/cacheScope

Eine MCP-Ressource ist der idiomatische „hier ist ein lesbares Dokument mit URI“-Grundtyp — auflistbar, lesbar, jetzt cachebar. Ein Tool-Aufruf ist es nicht.

Zugeschnitten auf MZP Ein ResourceProvider neben den Tools, gespeist aus demselben Repository: mzp://wiki/{slug} wird listbar und ueber resources/read abrufbar, mit gesetztem ttlMs. MCP-Clients koennen den Wissensbestand dann nativ durchblaettern und anheften, statt fuer jede Seite getPageContext aufzurufen. Kein Rewrite — eine zusaetzliche Registrierung.

beruehrt: neue ResourceProvider-Bean, PublishedPageRepository · mittel, an mzone-mcp-common gebunden

4.2 Publish-Workflows als prompts

MCP-prompts: server-angebotene, parametrierte Prompt-Vorlagen, die der Nutzer aus einem Menue waehlt

Das Repo vendort schon einen Skill (.kimi-code/skills/diagram-design). MCP-Prompts sind der protokolleigene Weg, so etwas anzubieten.

Zugeschnitten auf MZP publish-adr, publish-runbook, wiki-lint-triage, diagram-from-scratch als MCP-Prompts, die die Konventionen und die passende getCapabilityFor-Ausgabe vorladen — ein frischer Agent startet korrekt, statt einmal ueber den Parameternamen oder die Slug-Konvention zu stolpern (genau der Schmerz, den das McpToolCatalog-Javadoc beschreibt).

beruehrt: neue Prompt-Beans · klein, sobald mzone-mcp-common Prompts durchreicht

4.3 Cachebare Listen und Elicitation

SEP-2549 (Cache-Hinweise auf */list) · SEP-2322 (MRTR: resultType: "input_required")

Zugeschnitten auf MZP

listPublishedPages, listTemplates, listCapabilities sind lese-lastig — ein ttlMs auf der Antwort, und MCP-Clients holen die ~6 KB Capabilities-Landkarte nicht bei jedem Kaltstart neu.
MRTR-Elicitation laesst den Server mitten im Aufruf fragen „Version 7 ueberschreiben?“, statt publishArtifact ohne overwrite=true mit 409 abbrechen zu lassen. Bessere DX fuer den Ueberschreib-Schutz, den MZP ohnehin schaetzt. Haengt daran, dass die SDK-Basis es unterstuetzt.

beruehrt: alle list*-Tools, PublisherMcpTools · Konformitaets-Nachzug, teils blockiert durch mzone-mcp-common

5 · Quer durch, kleiner

5.1 Shiki — Notations-Kommentare in Code-Bloecken

shiki.style/packages/transformers · // [!code ++], [!code focus], [!code highlight]

Shikis Transformer lesen Kommentar-Notation in einer Code-Zeile und setzen daraus Diff-, Fokus- oder Hervorhebungs-Klassen — eine Konvention, die Agenten aus VitePress/Astro schon kennen.

Zugeschnitten auf MZP Ein Nachbearbeiter fuer eingezaeunte Code-Bloecke im MarkdownRenderer, der die [!code …]-Notation in mz--Zeilenoptik uebersetzt. Reine Renderer-Erweiterung; ADRs und Runbooks stecken voller Code, dem genau das fehlt.

beruehrt: MarkdownRenderer (Code-Block-Renderer)

5.2 Pagefind — geschardeter Client-Index (Beobachtungsposten)

pagefind.app · Rust/WASM, Index in Chunks, laedt nur was die Anfrage braucht, kein Backend

Zugeschnitten auf MZP MZP liefert search-index.json als einen Blob plus mz-sitesearch. Bei ~300 Seiten ist das in Ordnung. Pagefinds Idee — Index scharden, Chunks lazy nachladen, WASM-Matcher — ist der Skalierungspfad, kein Jetzt-Schritt. Hier bewusst als Beobachtungsposten notiert: wenn der eine Blob spuerbar wird, ist das der Anlass, nicht vorher.

beruehrt: static/search, search-index.json-Erzeugung · spaeter

Synthese — Reihenfolge

Sortiert nach Wirkung geteilt durch Aufwand. „Sofort“ heisst: eigenstaendig, kein Blocker, wenige Tage. „Mittelfristig“: einen Entwurf wert, beruehrt Schema oder Migration. „Spaeter“: haengt an einem anderen Ticket oder an mzone-mcp-common.

S1sofort

GitHub-Alerts im Markdown (2.4) und Shiki-Code-Notation (5.1) — beides reine MarkdownRenderer-Erweiterungen, hohe Wirkung auf die Lesbarkeit, null Architektur-Risiko.
S2sofort

llms.txt + /published/{slug}.md (3.1) — zwei Serialisierer ueber vorhandene Daten. Direkt auf der Mission „fuer Agenten publizieren“.
S3sofort

Herkunfts-Fuss (2.6), SRI-Hashes in getCapabilities (3.3), toter-Link-Job (2.5) — je ein kleiner, abgeschlossener Zuschnitt auf Bestandscode.
M1mittelfristig

Hybride Suche pgvector + BM25 + RRF (2.1) — groesster Einzelhebel fuer das MZP-38-Ziel. Neue Extension, Migration, Embedding-Erzeugung. Einen Spike wert.
M2mittelfristig

Transklusion ![[slug#abschnitt]] (2.2) und Vale-artige Hausstil-Regeln in lintWiki (2.3) — beide klar umrissen, beruehren nur MarkdownRenderer/lintWiki.
M3mittelfristig

JSON-Canvas-Export (1.4), Mermaid-Import-Pfad (1.3), generierte API-Referenz (3.4), Repo-Pack-Endpunkt (3.2, an MZP-46) — jeweils eine Abbildung, kein neues Subsystem.
L1spaeter

MCP resources + prompts + Cache-Hinweise (4.1–4.3) — idiomatisch richtig, aber an mzone-mcp-common gebunden; erst pruefen, was die Basis durchreicht.
L2spaeter

Structurizr-Modell/Sichten (1.1) hinter MZP-54 · D2-Ports (1.2) und Excalidraw-Variante/-Export (1.6, an MZP-56) · kuratierte Diagrammtypen (1.5) je einzeln.
B1beobachten

Pagefind-Sharding (5.2) — erst wenn der Ein-Blob-Index spuerbar wird.

Quellen

#	Projekt / Spec	Genutzte Idee	Fundort
1.1	Structurizr / C4-Modell	ein Modell, mehrere abgeleitete Sichten	structurizr.com · docs.structurizr.com/dsl
1.2	D2 (Terrastruct)	Ports, Layout-Hinweis, Nachbarschafts-Pin	github.com/d2lang/d2 · d2lang.com
1.3	Kroki	Adapter fuer fremde Diagramm-DSLs	github.com/yuzutech/kroki · docs.kroki.io
1.4	JSON Canvas	offenes Knoten/Kanten-Austauschformat	jsoncanvas.org · github.com/obsidianmd/jsoncanvas
1.5	Mermaid	Katalog fehlender Diagrammarten	github.com/mermaid-js/mermaid
1.6	Excalidraw	Skizzen-Look, generierbares Szenen-JSON	docs.excalidraw.com/docs/codebase/json-schema
2.1	pgvector · ParadeDB · pg_textsearch	hybride Suche BM25 + Vektor + RRF in Postgres	paradedb.com/blog · github.com/pgvector/pgvector
2.2	Quartz 4 · Obsidian	Transklusion / Block-Einbettung	quartz.jzhao.xyz
2.3	Vale	Prosa-Lint als YAML-Regelmodell	vale.sh · github.com/errata-ai/vale
2.4	GitHub Alerts · rehype-github-alerts	> [!WARNING]-Callouts	github.com/chrisweb/rehype-github-alerts
2.5	lychee	asynchroner externer Link-Check	github.com/lycheeverse/lychee
2.6	Docusaurus	Herkunft/Aenderungsdatum am Seitenfuss	docusaurus.io/docs/versioning
3.1	llms.txt (Spec v2) · Mintlify	Agenten-Index + .md-Quelle unter fester URL	llmstxt.org · blog.modelcontextprotocol.io
3.2	Repomix · Gitingest	viele Seiten als ein KI-freundliches Buendel	github.com/yamadashy/repomix · repomix.com
3.3	Subresource Integrity · Import Maps	Lib-Haertung, bare specifier	W3C SRI · WICG import-maps
3.4	Scalar	Schema → interaktive Referenz beim Deploy	github.com/scalar/scalar
4.x	Model Context Protocol (2026-07-28)	resources, prompts, Cache-Hinweise, MRTR-Elicitation	modelcontextprotocol.io · blog.modelcontextprotocol.io/posts/2026-07-28
5.1	Shiki (@shikijs/transformers)	Notations-Kommentare fuer Diff/Fokus/Highlight	shiki.style/packages/transformers
5.2	Pagefind	geschardeter, lazy geladener WASM-Index	pagefind.app