FEATURE REQUEST · MZP-FR-004

Page Lifecycle & Supersession

Ein Statusfeld pro Seite und ein Zeiger auf den Nachfolger. Damit ein Agent, der kalt startet, in einem Call sieht, welche der 115 Seiten noch gilt.

Eingereicht von
Claude (Cowork-Session)
Datum
2026-08-06
Betrifft
mzone-publisher · MCP-Toolflaeche
Status
VORSCHLAG
Aufwandsschaetzung
klein — ein Spaltenpaar, ein Tool, eine Lint-Regel

Das Problem

Der Publisher weiss, wie eine Seite innerhalb ihres Slugs gealtert ist — listVersions und rollbackArtifact decken das ab. Er weiss nichts darueber, wie Seiten untereinander altern. Genau dort entsteht der Schaden.

Seiten gesamt
115
in Nachfolge-Familien
26
exakte Titel-Kollisionen
2
Seiten ohne Titel
9

Ein Agent, der eine Session mit listPublishedPages() beginnt, bekommt 115 gleichrangige Eintraege. Nichts daran sagt ihm, dass vier davon dieselbe Frage viermal beantworten und nur die letzte stimmt. Er muss raten — meist ueber das Aenderungsdatum, was falsch ist, sobald jemand eine alte Seite nachtraeglich korrigiert.

Belege aus dem laufenden Bestand

FamilieSeitenBefund
MZP-Audit / Nachtest 6 wiki-log-2026-08-03-mzp-nachtest, …-08-04-mzp-audit, …-08-05-mzp-audit-nachtest bis -4. Fuenf davon sind ueberholt, keine sagt es.
GitHub-Trend-Reports 10 Von github-radar bis github-trend-radar-august-2026 — dasselbe Genre, ueberlappende Zeitraeume, keine Ordnung.
TypeScript 7 3 typescript-7-go-rewrite-2026 und typescript-7-deep-dive-2026 tragen denselben Titel, Zeichen fuer Zeichen. 13 Minuten Abstand.
mz-dev-toolbox 2 dev-toolbox-report und wiki-svc-dev-toolbox-report — zweite exakte Titel-Kollision, vermutlich eine Umbenennung, die als Kopie endete.
UI-/Canvas-Gap 3 mzp-canvas-ui-gap-report, wiki-svc-mzone-ui-canvas-parity, wiki-svc-mzone-ui-audit.
DAS STAERKSTE ARGUMENT

Auf dieser Instanz liegt bereits eine Seite namens pascal-redundanz-audit — „Redundanz-Audit & Konsolidierungs-Plan". Jemand hat die Arbeit, die dieses Feature automatisieren wuerde, schon einmal von Hand gemacht. Genau einmal, fuer genau eine Familie, im Juli. Handarbeit, die sich nicht wiederholt hat, ist die klarste Anforderung an ein Feature, die es gibt.

Der Vorschlag

Zwei Felder pro Seite, ein Tool, zwei Rueckgabe-Erweiterungen. Kein neues Datenmodell, keine Migration von Inhalten.

  1. F1Kern

    Zwei Spalten: status ∈ draft | current | superseded | archived (Default current) und supersededBy (Slug, nullable). Dazu optional supersedeReason als Freitext.

  2. F2Kern

    Ein Tool: setPageLifecycle(slug, status, supersededBy?, reason?). Setzt der Aufrufer supersededBy, wird status implizit superseded. Der Server prueft, dass der Nachfolger existiert und dass keine Zyklen entstehen.

  3. F3Kern

    Listing wird ehrlich: listPublishedPages, searchPages und fullTextSearch geben status und supersededBy im Summary mit — zwei kurze Felder, kein Token-Problem. listPublishedPages(status?) filtert; ohne Parameter bleibt das Verhalten wie heute, damit nichts bricht.

  4. F4Kuer

    Banner beim Ausliefern: Eine superseded-Seite bekommt beim Serven einen schmalen Hinweisstreifen ueber dem Inhalt, mit Link auf den Nachfolger. Der gespeicherte HTML-Body bleibt unangetastet — die Injektion passiert in der Auslieferung, wie bei einem Server-Side-Include. Menschen, die einen alten Link aus einem Chat aufrufen, sind damit auch bedient.

  5. F5Kuer

    Publish-Notice statt Publish-Block: Wer einen Titel publiziert, den es schon gibt, bekommt in der Antwort TITLE_COLLISION mit dem kollidierenden Slug — im selben Geist wie UNKNOWN_STYLE_CLASS. Kein Fehler, nur ein Wink: „meintest du supersededBy?" Genau an dieser Stelle waeren die zwei bestehenden Kollisionen nie entstanden.

  6. F6Kuer

    lintWiki lernt eine Regel: Slug-Familien mit gemeinsamem Praefix und mehr als drei Mitgliedern, bei denen keine Nachfolge gesetzt ist, werden als UNRESOLVED_SUCCESSION gemeldet. Der bestehende Wildwuchs wird damit einmal sichtbar statt einmal von Hand auditiert.

So sähe der Aufruf aus

setPageLifecycle(
  slug:          "wiki-log-2026-08-05-mzp-audit-nachtest-3",
  status:        "superseded",
  supersededBy:  "wiki-log-2026-08-05-mzp-audit-nachtest-4",
  reason:        "Nachtest IV deckt denselben Umfang mit neuerem Stand ab"
)

listPublishedPages(status: "current")
  → 89 statt 115 Eintraege, alle gueltig

Was das Feature ausdrücklich nicht ist

KEIN ZWEITES VERSIONING

listVersions und rollbackArtifact beschreiben die Geschichte eines Slugs. Dieser Vorschlag beschreibt Beziehungen zwischen Slugs. Die beiden ueberschneiden sich nicht.

KEIN LÖSCHEN

deletePage gibt es. Der Punkt hier ist das Gegenteil: Alte Seiten sollen erreichbar bleiben — alte Links funktionieren weiter —, aber sie sollen ihren Rang verlieren.

KEIN TAXONOMIE-SYSTEM

Tags, Kategorien und Sammlungen waeren ein eigener, groesserer Wunsch. Hier geht es nur um die eine Achse, an der Wissen tatsaechlich verfaellt: die Zeit.

KEIN AUTOMATISCHES URTEIL

Der Server erklaert keine Seite von sich aus fuer veraltet. Er meldet Verdachtsfaelle; entschieden wird von dem, der publiziert.

Warum ich das will

Ich bin der Konsument dieser Liste. Jede Session faengt bei null an — ADR-008 haelt genau das fest: die MCP-Strecke ist zustandslos, ich bringe kein Gedaechtnis mit. Was ich ueber diese Instanz weiss, weiss ich aus listPublishedPages.

Heute kostet mich das dreifach. Ich lese 115 Zeilen, um zu merken, dass sechs davon dieselbe Sache sind. Ich rate anhand des Datums, welche gilt. Und wenn ich falsch rate, schreibe ich eine neue Seite auf Basis einer alten — womit die Familie auf sieben waechst und das Problem sich selbst fuettert. Das ist keine Unbequemlichkeit, das ist eine Rueckkopplung mit positivem Vorzeichen.

Zwei Spalten brechen sie auf. Das ist das ganze Argument.