MZP Knowledge Engine · Report v2 · 2026-08-23

KI-Agenten im Maierzone Publisher — die Gegenprobe

Der Report vom 15.08.2026 beschreibt den MZP aus der Sicht eines Agenten. Acht Tage später steht dieselbe Beschreibung gegen die laufende Instanz: Was stimmt noch, was ist stillschweigend veraltet, und was funktioniert in der Praxis — gemessen, nicht vermutet.

Bilanz

Zwei Achsen je Befund: Drift fragt, ob eine Aussage des 15.08 heute noch trägt. Praxis fragt, ob das Werkzeug im Gebrauch hält, was der Vertrag verspricht. Neu sammelt, was v1 gar nicht kennen konnte.

Befunde im Überblick

Sortierbar über die Spaltenköpfe, filterbar über das Suchfeld. Die vollständige Begründung samt Beleg steht weiter unten bei der jeweiligen Sektion.

01 Architektur — KI-Agent im MZP-Ökosystem

Die Türen ins System — und die eine, die v1 noch nicht kannte.

MODERAT D-01 GUT D-02

1. D-01MODERATDrift
   Architekturbild kennt den Browser im Publish-Pfad nicht

   v1 zeichnet vier Bausteine: Agent, MCP-Server, Freemarker, Postgres, NGINX. Heute haengt hinter jedem Publish zusaetzlich ein Headless-Browser (Render-Self-Check) und ein serverseitiger SVG-Diagramm-Renderer. Die Aussage ist nicht falsch, aber unvollstaendig.

   Beleg: publishArtifact liefert render:{clean:true, durationMs:1684} — ein echter Browser-Roundtrip, den v1 nicht kennt.

2. D-02GUTDrift
   Der MCP-Server bleibt die einzige Tür

   Agent und Postgres treffen sich nie direkt. Die REST-Strecke ist keine Abkuerzung: /api/artifacts verlangt einen OAuth2-Bearer von auth.maierzone.de, den ein MCP-Agent nicht hat.

   Beleg: getCapabilities().conventions.rest — ohne Token antwortet der Server mit HTTP 401 unauthorized.

02 Routing — Wiki-Seite oder Artefakt-Bundle?

Der Entscheidungsbaum von ADR-006 — heute zwei Äste zu kurz.

SCHLECHT D-03 GUT D-04 MODERAT D-05

1. D-03SCHLECHTDrift
   Der Entscheidungsbaum ist binaer — es gibt vier Strecken

   v1 kennt genau zwei Wege: publishPage (Wiki-Template) oder publishArtifact (Bundle). Heute sind es vier: dazu publishAsset (R31, Einzeldatei mit Steckbrief und Trust-Achse) und publishDiagram (ADR-008, serverseitig gerendertes Diagramm). Ein Agent, der v1 folgt, baut Diagramme und Assets von Hand nach.

   Beleg: getCapabilities().tools enthaelt publishAsset und publishDiagram; beide fehlen im Flussdiagramm von v1.

2. D-04GUTDrift
   Nie beide Strecken fuer denselben Slug — bleibt richtig

   Wiki-Text und Artefakt-Bundle sind weiterhin verschiedene Datenmodelle. getPageContext liefert bei einem Bundle ein leeres Context-JSON, getArtifactSource ist der Weg dorthin.

   Beleg: getPageContext auf ki-agenten-mzp-report liefert keinen Wiki-Kontext; getArtifactSource denselben Slug mit 48.459 Bytes index.html.

3. D-05MODERATPraxis
   Der wiki-Praefix-Zwang ist eine LLM-Klassifikation, keine Regel

   getCapabilities kuendigt an, Service-/Infrastruktur-Content ohne wiki-Praefix werde mit HTTP 409 abgelehnt. Eine Probeseite mit klarem MZP-Log-Charakter unter dem Slug probe-mzp-v2-check lief ohne Praefix und ohne Notice durch — klassifiziert wurde sie hinterher als KNOWLEDGE_BASE. Die Durchsetzung haengt am Urteil eines Modells, nicht an einem Slug-Muster.

   Beleg: publishPage(probe-mzp-v2-check, wiki-page) → notices leer; getPageHistory zeigt category KNOWLEDGE_BASE, criticality LOW.

03 Publish-Sequenz — Artefakt-Publish-Sequenz

Drei Aufrufe, ein Schreibvorgang — plus zwei Prüfungen, die es am 2026-08-15 noch nicht gab.

MODERAT D-06 GUT D-07 GUT D-08 MODERAT D-09

1. D-06MODERATDrift
   Die Drei-Schritt-Sequenz ist heute abkuerzbar

   v1 zeichnet getCapabilities → validateArtifact → publishArtifact als feste Kette, bei der das Bundle zweimal ueber die Leitung geht. Heute reicht der previewToken aus validateArtifact als stagingToken an publishArtifact; und einzelne Dateien kommen per fromSlug serverseitig aus dem Bestand.

   Beleg: publishArtifact mit fromSlug auf den eigenen Slug erzeugte Version 2 mit unveraendertem app.js; die Antwort quittiert FILES_REFERENCED mit 52.682 nicht uebertragenen Bytes.

2. D-07GUTNeu
   Post-Publish-Self-Check: HTTP-Rueckpruefung plus echter Browser

   Der groesste Zugewinn seit dem 15.08 und in v1 nicht vorhanden. Nach jedem Publish holt der Server die eigene URL oeffentlich zurueck (Status und Content-Type) und laedt die Seite zusaetzlich in einem echten Browser, um Konsolenfehler, Exceptions und gescheiterte Ressourcen zu melden.

   Beleg: Diese Seite selbst: REACHABLE ueber 9 URLs, alle 200, plus RENDER_CLEAN in 2967 ms.

3. D-08GUTPraxis
   overwrite loescht nichts — nachgemessen

   Die Kernaussage der v1-Sequenz haelt: overwrite legt eine Version an, rollbackArtifact holt sie zurueck, und das Rollback selbst ist wieder eine neue Version. Kein Stand geht verloren.

   Beleg: v1 → overwrite → v2 → rollbackArtifact(1) ergab Version 3 mit Notice ROLLBACK_APPLIED, fromVersion 1, newVersion 3.

4. D-09MODERATDrift
   v1 nennt keine Versions-Obergrenze — es sind fuenf

   maxVersionsPerSlug ist 5. Wer oefter iteriert, verliert die aeltesten Staende stillschweigend aus dem Rollback-Fenster. In der v1-Sequenz steht nur „alte Version bleibt“.

   Beleg: getCapabilities().maxVersionsPerSlug = 5.

04 Lifecycle — Page-Lifecycle

Vier Zustände, unverändert korrekt — und ein Automat, den kaum jemand bedient.

GUT D-10 GUT D-11 MODERAT D-12

1. D-10GUTDrift
   Die vier Zustaende stimmen unveraendert

   CURRENT, DRAFT, SUPERSEDED, ARCHIVED — Zahl, Namen und Uebergaenge des v1-Zustandsdiagramms sind heute noch korrekt. setPageLifecycle prueft Existenz des Nachfolgers und Zyklen.

   Beleg: Tool-Vertrag setPageLifecycle: Fehlercodes SUCCESSOR_NOT_FOUND und LIFECYCLE_CYCLE.

2. D-11GUTPraxis
   deletePage ist erreichbar — der wiki-index behauptet das Gegenteil

   v1 zeichnet deletePage korrekt als harten Endzustand. Der wiki-index dagegen notiert unter Aufraeum-Kandidaten, sechs Testseiten seien nur archiviert worden, weil kein deletePage ueber MCP verfuegbar sei. Das stimmt heute nicht mehr.

   Beleg: deletePage auf beide Probe-Slugs meldete „Seite erfolgreich geloescht“.

3. D-12MODERATPraxis
   Die Lifecycle-Achse wird kaum benutzt

   Der Zustandsautomat existiert, aber im Bestand steht er praktisch still: keine einzige ungeloeste Nachfolge, dafuer 29 von 33 Wiki-Seiten ganz ohne Cross-References. Ein Mechanismus, den niemand bedient, verhindert keine Dubletten.

   Beleg: lintWiki: totalWikiPages 33, unresolvedSuccessions leer, missingCrossRefs mit 29 Eintraegen.

05 Schichten — Knowledge-Engine Schichten

Fünf Schichten, eine falsche Zahl und eine fehlende Achse.

SCHLECHT D-13 GUT D-14 SCHLECHT D-15

1. D-13SCHLECHTDrift
   28 Tools ist falsch — es sind 34

   Die Zahl steht in v1 an zwei Stellen: in der Schicht L2 des Schichtdiagramms und im Wirkungsradius-Diagramm. Acht Tools sind seither dazugekommen: publishDiagram, validateDiagram, diffVersions, extractTemplate, getCapabilityFor, listCapabilities, getDesignMdFor, searchBranding.

   Beleg: getCapabilities().tools listet 34 Namen.

2. D-14GUTDrift
   L2 bleibt die einzige Schicht, die ein Agent anspricht

   Die Kernaussage des Schichtdiagramms haelt: alles unterhalb des MCP-Protokolls ist Implementierungsdetail. Kein neues Tool durchbricht die Schicht.

   Beleg: Alle 34 Tools sind MCP-Aufrufe; die REST-Aequivalente sind auth-pflichtig und fuer Agenten verschlossen.

3. D-15SCHLECHTNeu
   Die komplette Diagramm-Engine fehlt in v1

   Am 15.08 war sie im Bau, heute ist sie eine eigene Faehigkeitsachse: 35 Diagrammtypen mit echtem serverseitigem Renderer, Budget- und 4px-Grid-Validierung, automatischem Connector-Routing, PNG-Export und visualProof-Nachzaehlung im Browser. Ein Agent, der nur v1 liest, baut Diagramme weiterhin von Hand als SVG.

   Beleg: getCapabilityFor(diagramTypes) liefert 35 Typen von architecture bis funnel.

06 Wirkungsradius — Wirkungsradius eines KI-Agent-Calls

Wie klein der Blast-Radius eines Tool-Calls wirklich noch ist.

MODERAT D-16 GUT D-17

1. D-16MODERATDrift
   Genau eine Zeile ist heute mehr als eine Zeile

   v1 sagt: ein Tool-Call aendert genau eine Zeile in published_pages. Inzwischen haengen daran Versions-Snapshots, die Asset-Trust-Achse (asset_trust, used_assets aus Migration V14), ein klassifizierter Audit-Trail und die Hall-of-Fame. Der Blast-Radius ist weiterhin klein, aber breiter als gezeichnet.

   Beleg: getPageStats: versions 72, assets 194; getPageHistory liefert je Aufruf category, criticality und Begruendung.

2. D-17GUTPraxis
   Kein Tool fasst NGINX oder Docker an

   Die Schutzaussage von v1 haelt vollstaendig. Alle Schreibpfade bleiben Postgres-Schreiber; die Auslieferungsschicht wird nur gelesen, nie konfiguriert.

   Beleg: Header-Abruf gegen /published/ zeigt unveraenderte NGINX-Konfiguration ueber alle Probe-Publishes hinweg.

Neu seit v1

Fähigkeiten und Fehler, die der Report vom 15.08 nicht kennen konnte — hier entscheidet sich, ob der MZP in acht Tagen netto gewonnen hat.

1. P-01MODERATPraxis
   listPublishedPages war 51 Minuten tot — waehrend dieser Pruefung behoben

   Um 06:31 UTC scheiterte jeder Aufruf: ohne Parameter, mit limit, mit status, mit kind. Das Tool, das den Bestand aufzaehlt, war unbenutzbar; ausweichen liess sich nur ueber searchPages und fullTextSearch. Die Nachmessung um 07:22 UTC lief in allen drei Varianten sauber durch, samt total und nextCursor. Zwischen beiden Messungen wurde neu deployed oder neu gestartet.

   Was bleibt: Ein Tool, das nach einem Deploy in Produktion sofort und vollstaendig ausfaellt, waehrend die Suite gruen ist, ist kein Zufall — das ist P-03. Der Vorfall ist geschlossen, die Ursachenklasse nicht.

   Beleg: 06:31 UTC — vier Varianten, viermal ERROR: could not determine data type of parameter $6. 07:22 UTC — dieselben Varianten: total 237 / 236 / 7, nextCursor gesetzt, Notice RESULT_PAGED.

2. P-02MODERATPraxis
   Ursache des Ausfalls: untypisiertes NULL in der Keyset-Query

   Die JPQL-Query bindet cursorTs in einer IS-NULL-Position. Ohne Cursor geht ein untypisiertes NULL an Postgres, das den Typ des Bind-Parameters nicht herleiten kann — H2 in der Testschicht toleriert genau das. Der Fehlertext nennt Parameter $6, und $6 ist die erste Bindung von cursorTs.

   Nachtrag: Seit 07:22 UTC laeuft die Abfrage. Ob per CAST, per getrennter Query oder schlicht per Neustart mit anderem Statement-Cache — aus der MCP-Sicht nicht unterscheidbar. Wer den Fix festschreiben will, prueft die Stelle im Repository gegen den deployten Stand.

   Beleg: PublishedPageRepository.java:48-63, Aufrufer PublishService.java:305 uebergibt null, null.

3. P-03SCHLECHTPraxis
   Tests laufen auf H2, Produktion auf Postgres

   Der systemische Grund, warum ein Totalausfall wie P-01 gruen durch die Suite kommt: die Testschicht benutzt H2 mit abgeschaltetem Flyway, die Produktion Postgres mit Flyway-Migrationen. Typ-Inferenz, Enum-Mapping und Migrationsreihenfolge sind genau die Stellen, an denen die beiden auseinanderlaufen — und genau dort schlug es zu.

   Beleg: CLAUDE.md: local-Profil H2 in-memory, Flyway aus. Commit b09e24b (Test-Coverage-Fixes fuer listPublishedPages) ist am selben Tag gruen gemergt worden.

4. P-04GUTPraxis
   Der 5-Minuten-Cache ist weg

   Am 15.08 lieferte /published/ noch cache-control max-age=300 ohne Validator — nach einem overwrite lief bis zu fuenf Minuten alter Begleitcode gegen frisches Markup. Heute liefert dieselbe URL no-store.

   Beleg: curl -D - auf /published/ki-agenten-mzp-report/ → Cache-Control: no-store.

5. P-05GUTPraxis
   Der files-Parameter ist benutzbar geworden

   Am 15.08 war das echte Array ueber MCP nicht aufrufbar, weil das Schema alle vier Quellfelder als Pflicht verlangte; nur filesJson ging. Heute nimmt files ein normales Array, gemischt aus content und fromSlug.

   Beleg: publishArtifact mit gemischtem files-Array lief ohne Schema-Fehler durch.

6. P-06MODERATPraxis
   mergePageContext meldet den Verlust jetzt — richtet ihn aber weiter an

   Der Fix von B4 macht den Schaden sichtbar statt still: eine ARRAY_REPLACED-Notice nennt oldLength und newLength. Das Verhalten selbst ist unveraendert destruktiv — ein Patch mit einem Abschnitt ersetzt weiterhin alle. Wer die Notice nicht liest, verliert Inhalt genauso wie vorher.

   Beleg: Patch mit einer Sektion auf eine Seite mit dreien: Array sections wurde ersetzt statt gemerged, 3 vorher, 1 danach — und der Kontext hatte danach genau eine Sektion.

7. P-07GUTPraxis
   UNKNOWN_STYLE_CLASS greift und nennt den Namen

   Eine erfundene mz-Klasse wird beim Validieren als WARNING mit dem konkreten Klassennamen gemeldet, statt ungestyltes HTML durchzulassen. Der in CLAUDE.md beschriebene Weg — nicht raten, validieren lassen — funktioniert wie dokumentiert.

   Beleg: validateArtifact mit einer erfundenen Klasse → Notice UNKNOWN_STYLE_CLASS mit Namensnennung, ok true, previewUrl trotzdem geliefert.

8. P-08MODERATPraxis
   EXTERNAL_REFERENCE ist bei Diagrammen ein Dauer-Fehlalarm

   Die Warnung nennt eine Google-Fonts-URL, die nicht aus dem eingereichten Diagramm-JSON stammt, sondern aus dem serverseitig gerenderten Template. Sie erscheint bei jedem einzelnen Diagramm-Publish. Eine Warnung, die immer kommt, wird nicht mehr gelesen — und verdeckt die echten. Der Plan H1 (Diagramm-Output self-contained) adressiert genau das.

   Beleg: validateDiagram mit einem Zwei-Knoten-Flowchart ohne jede externe Referenz → WARNING EXTERNAL_REFERENCE auf fonts.googleapis.com.

9. P-09GUTNeu
   FR-001 ist geliefert: transparenter Hintergrund und PNG-Export

   Der am 18.08 eingereichte Feature-Request ist umgesetzt. meta.transparentBackground laesst die Hintergrundflaeche weg, meta.pngScale steuert die Aufloesung, und die publizierte Seite traegt zwei Export-Knoepfe. Der Server warnt sogar mit, wenn heller Text auf transparentem Grund landet.

   Beleg: validateDiagram mit transparentBackground true → ok true plus Notice TRANSPARENT_CONTRAST; diagram.png mit scale 1 bis 4 laut Tool-Vertrag.

10. P-10SCHLECHTPraxis
    Basic-Auth blendet den Self-Check fuer den halben Namespace aus

    Slugs, die mit wiki- beginnen, liegen hinter NGINX Basic-Auth. Der Post-Publish-Self-Check holt die Seite oeffentlich und bekommt 401 — er meldet NOT_REACHABLE als ERROR, obwohl alles korrekt gespeichert ist. Schwerer wiegt: der Render-Check laeuft danach gar nicht mehr. Der gesamte Wiki-Namespace (33 Seiten) wird seit Einfuehrung des Self-Checks ungeprueft publiziert.

    Beleg: wiki-probe-auth-selfcheck → reachability.allOk false, HTTP 401 statt 200, render-Block fehlt komplett. Gegenprobe probe-wiki-auth-check (wiki nicht am Anfang): 200 und RENDER_CLEAN.

11. P-11GUTNeu
    diffVersions liefert echten Unified-Diff

    Zwei Staende desselben Slugs lassen sich zeilenweise vergleichen; unveraenderte Dateien fehlen im Ergebnis, was den Beweis fuer die fromSlug-Wiederverwendung gleich mitliefert.

    Beleg: diffVersions(1,2) zeigte nur index.html als MODIFIED — app.js taucht nicht auf, war also byte-identisch uebernommen.

12. P-12GUTNeu
    Vier Branding-Profile stehen als Server-Wissen bereit

    searchBranding und getDesignMdFor liefern nightline, ledger, monoblock und arcade mit Farbrollen, Typografie, Layout-Prinzipien und Voice — Freitext wie „verspielt“ trifft ebenfalls. Ein Agent muss Gestaltung nicht mehr erfinden.

    Beleg: searchBranding(nightline) → vollstaendiges Profil inkl. colors, typography, layoutPrinciples, voice.

13. P-13SCHLECHTPraxis
    Der wiki-index ist grob veraltet

    Er nennt 69 Seiten (Stand 03.08) und 16 Wiki-Seiten. Tatsaechlich sind es 237 Seiten und 33 Wiki-Seiten. Der Index notiert seine eigene Drift sogar selbst als Aufraeum-Kandidat — und wurde seither trotzdem nicht nachgezogen. lintWiki erkennt genau diese Drift nicht, weil es Freshness an lastVerified misst, nicht an der Wirklichkeit.

    Beleg: getPageStats und listPublishedPages: 237 Seiten, 97 Bundles. lintWiki: 33 Wiki-Seiten. wiki-index metadata: Seiten gesamt 69.

14. P-14MODERATPraxis
    Freshness ist gruen, Verlinkung ist es nicht

    lintWiki meldet 32 von 33 Seiten gruen und genau eine gelbe. Gleichzeitig haben 29 Seiten keinen einzigen Cross-Reference. Die Freshness-Ampel misst das Datum, nicht die Vernetzung — eine taggenaue Sammlung unverbundener Inseln zaehlt als gesund.

    Beleg: lintWiki: freshness green 32, yellow 1, red 0; missingCrossRefs mit 29 Slugs.

15. P-15GUTNeu
    Der Audit-Trail klassifiziert jeden Schreibzugriff

    getPageHistory nennt zu jedem Aufruf Werkzeug, Agent, Zeitpunkt, Kategorie, Kritikalitaet und eine Begruendung in Prosa. Die Einordnung entsteht per structured output, nicht per Regel.

    Beleg: getPageHistory der Probeseite: publishPage als KNOWLEDGE_BASE/LOW mit Begruendung, mergePageContext als OTHER/LOW.

16. P-16MODERATNeu
    extractTemplate ist ohne Rueckwaertsgang

    Seiten lassen sich zu wiederverwendbaren Templates erheben. Es gibt aber kein Gegenstueck: kein deleteTemplate, kein Ueberschreiben — eine Namenskollision endet im Fehler. Ein Fehlgriff bleibt dauerhaft im Katalog stehen. Deshalb in dieser Pruefung bewusst nicht ausgeloest.

    Beleg: Tool-Vertrag extractTemplate: nur Neuanlage, Namenskollision → Fehler statt Ueberschreiben. listTemplates zeigt 9 Templates, keines entfernbar.

17. P-17GUTNeu
    Review-Links mit langer TTL statt 15 Minuten

    validateArtifact nimmt reviewTtlSeconds bis sieben Tage; solche Links liegen in der Datenbank statt im Speicher, ueberstehen einen Neustart und lassen sich per revokePreview sofort zurueckziehen. Damit ist ein Zwischenstand teilbar, ohne ihn zu publizieren.

    Beleg: Tool-Vertrag validateArtifact (R13) inkl. Klemmung auf 604800 s mit Notice REVIEW_TTL_CLAMPED.

18. P-18GUTPraxis
    Die Selbstbeschreibung ist zerlegbar geworden

    getCapabilities laesst sich auf minimal kuerzen, einzelne Themen kommen ueber listCapabilities und getCapabilityFor, und wer die Klassennamen schon kennt, holt die vollen Katalogeintraege im selben Aufruf statt in einem zweiten. Der Einstieg kostet damit einen Bruchteil des Kontexts von v1.

    Beleg: listCapabilities → budgets, diagramRules, diagramTypes, libs, slugRules, styling. getCapabilityFor liefert nur die angefragten.

Was zwischen den beiden Reports passiert ist

Aus der Commit-Historie des Repositories, nicht aus den Wiki-Seiten — der Index war zum Zeitpunkt dieser Prüfung selbst veraltet.

1. 2026-08-15
   Der v1-Report entsteht — und am selben Abend werden vier MCP-Bugs aus dem Design-Test gefixt (B1–B4) sowie die Asset-Trust-Achse R32 eingebaut. v1 beschreibt also bereits einen Stand, der wenige Stunden später überholt war.
2. 2026-08-15 – 08-16
   Diagramm-Engine: JSON-Modell, Parser, Token-Set, Schema-, Grid- und Budget-Validierung, dann Ausbau in vier Etappen.
3. 2026-08-17
   Hall of Fame — eine Bewertungsachse auf publizierten Seiten, in v1 nicht vorhanden.
4. 2026-08-18
   Edge-Router Phase A und B: Konnektoren docken senkrecht an und weichen fremden Boxen aus. Neue Diagrammtypen für das Datengeschäft.
5. 2026-08-19
   FR-001 erledigt: Diagramme als PNG kopier- und speicherbar, transparenter Hintergrund. Vier eigenständige Branding-Profile kommen dazu.
6. 2026-08-23
   Morgens: OG- und Twitter-Meta-Tags, extractTemplate. Mittags: Keyset-Pagination für listPublishedPages — mit einem Ausfallfenster in Produktion, das während dieser Prüfung endete (P-01).

Anhang — Rohbelege

Jeder Befund oben steht auf einer dieser Ausgaben. Alle Schreibproben liefen gegen Wegwerf-Slugs (probe-*, wiki-probe-*) und wurden nach der Messung per deletePage entfernt; keine bestehende Seite wurde angefasst.

06:31 UTC
Error invoking method: listPublishedPages
ERROR: could not determine data type of parameter $6
— identisch ohne Parameter, mit limit=3, mit status=current, mit kind=asset

07:22 UTC — dieselben Varianten
limit=3        -> total 237, nextCursor gesetzt, RESULT_PAGED
status=current -> total 236
kind=asset     -> total 7

PublishedPageRepository.java:48-63
  AND (:cursorTs IS NULL
       OR p.lastModified < :cursorTs
       OR (p.lastModified = :cursorTs AND p.slug > :cursorSlug))

PublishService.java:305
  findWindow(status, assetsOnly,
             position == null ? null : position.lastModified(),
             position == null ? null : position.slug(),
             PageRequest.of(0, wirksam + 1));

{"code":"ARRAY_REPLACED","severity":"WARNING","subject":"sections",
 "message":"Array 'sections' wurde ersetzt statt gemerged: 3 Eintraege vorher, 1 danach.",
 "details":{"oldLength":3,"newLength":1}}

publishArtifact("wiki-probe-auth-selfcheck")
{"code":"NOT_REACHABLE","severity":"ERROR",
 "message":"Publiziert, aber oeffentlich nicht korrekt ausgeliefert: HTTP 401 statt 200",
 "details":{"status":401}}
— und im Ergebnis fehlt der render-Block vollstaendig.

Gegenprobe "probe-wiki-auth-check" (wiki nicht am Slug-Anfang):
REACHABLE 200 + RENDER_CLEAN (1329 ms)

curl -D - https://publisher.maierzone.de/published/ki-agenten-mzp-report/
HTTP/1.1 200
Cache-Control: no-store

— am 2026-08-15 stand hier max-age=300 ohne Validator.

{"code":"REACHABLE","severity":"INFO","message":"Oeffentlich erreichbar geprueft: 9 URL(s), alle 200 mit erwartetem Content-Type"}
{"code":"RENDER_CLEAN","severity":"INFO","message":"Im Browser geladen, keine Konsolenfehler, keine Ausnahmen, keine gescheiterten Ressourcen","details":{"durationMs":2967}}

getPageStats → {"totalTemplates":9,"totalPublishedPages":236,"pagesLastWeek":74,
                "artifacts":{"bundles":97,"assets":194,"assetBytes":4553109,"versions":72}}
lintWiki    → {"totalWikiPages":33,"freshness":{"green":32,"yellow":1,"red":0},
               "missingCrossRefs":[29 Slugs],"unresolvedSuccessions":[]}
wiki-index  → metadata["Seiten gesamt"] = "69 (Stand 2026-08-03)"