PmWiki für KI-Agenten
PmWiki ist selbst kein KI-System. Gerade das ist eine Stärke: Es stellt eine kleine, nachvollziehbare und erweiterbare Arbeitsumgebung bereit, in der Menschen und KI-Agenten dieselben Seiten bearbeiten können. Inhalte bleiben lesbar, Änderungen bleiben prüfbar und die menschliche Freigabe kann technisch von der Bearbeitung getrennt werden.
Diese Seite beschreibt keine fertige Universalautomatik. Sie zeigt ein belastbares Grundmuster, das sich an die Anforderungen eines eigenen Projekts anpassen lässt.
Warum PmWiki gut zu KI-Agenten passt
1. Ein überschaubares, dateibasiertes System
PmWiki benötigt für den normalen Betrieb keine Datenbank. Seiten, Konfiguration und Anhänge lassen sich deshalb vergleichsweise leicht sichern, untersuchen und auf einen anderen Server übertragen. Für einen Agenten ist ein überschaubares System mit klaren Dateigrenzen leichter zu verstehen als eine Anwendung, deren Zustand über viele Dienste verteilt ist.
Das bedeutet jedoch nicht, dass ein Agent die Dateien im Verzeichnis `wiki.d` wie gewöhnliche Text- oder Markdown-Dateien bearbeiten sollte. Dort liegen neben dem sichtbaren Text auch Metadaten und Versionsinformationen. Normale Inhaltsänderungen sollten über PmWiki selbst erfolgen.
2. Stabile und verständliche Seitennamen
Jede Seite besitzt einen eindeutigen Namen nach dem Muster `Gruppe.Seite`, zum Beispiel Projekt.WieWirArbeiten`. Diese Namen sind für Menschen lesbar, für Skripte stabil und eignen sich gut als Ziel in Aufgaben, Protokollen und Verknüpfungen.
Gruppen können außerdem eigene Navigation, Zugriffsrechte, Kopf- und Fußbereiche sowie Konfigurationen erhalten. Dadurch lassen sich öffentliche Inhalte, technische Bereiche und eine geschützte Werkstatt sauber trennen.
3. Strukturierte Daten direkt in einer lesbaren Seite
Mit PageTextVariables können Seiten maschinenlesbare Metadaten enthalten. Ein mögliches Schema verwendet etwa die Felder PageType`, `Status`, `Responsible` und SourceUrl` mit Werten wie `article`, `review`, einem Namen und einer Quellenadresse.
Der restliche Inhalt bleibt normal lesbarer Seitentext. Ein Agent kann damit Status, Zuständigkeit, Quellen oder stabile Kennzeichen auswerten, ohne den eigentlichen Beitrag in eine Datenbankmaske zu zwingen.
4. Versionsgeschichte und nachvollziehbare Änderungen
PmWiki führt eine Versionsgeschichte mit Autor, Zeit und Änderungszusammenfassung. Wenn Agenten über die reguläre Bearbeitung schreiben, bleiben diese Informationen erhalten. Menschen können Änderungen vergleichen, zurückverfolgen und bei Bedarf wiederherstellen.
Das ist eine wichtige Voraussetzung für verantwortliche KI-Nutzung: Ein Agent sollte nicht nur ein Ergebnis liefern, sondern auch eine überprüfbare Änderung hinterlassen.
5. Rechte lassen sich klein zuschneiden
PmWiki kann Lesen, Bearbeiten, Hochladen und administrative Aktionen getrennt schützen. Das eingebaute AuthUser-System ermöglicht persönliche Konten und Gruppen.
Ein KI-Agent braucht normalerweise kein Administratorkonto. Ein eigenes Konto mit Bearbeitungsrecht reicht aus. Veröffentlichung, Rechteverwaltung und endgültige Freigabe können bei einem Menschen bleiben. Dieses Prinzip der geringsten Berechtigung begrenzt sowohl Bedienfehler als auch die Folgen kompromittierter Zugangsdaten.
6. Erweiterbar, ohne den Kern umzubauen
PmWiki trennt den Programmkern von lokalen Anpassungen. Konfiguration gehört nach `local/`, wiederverwendbare Erweiterungen nach `cookbook/`, Darstellung nach `pub/skins/` oder `pub/css/`. Eigene Markups und Aktionen können ergänzt werden, ohne `pmwiki.php` zu verändern.
Dadurch kann ein Agent kleine, klar begrenzte Änderungen vornehmen. Der PmWiki-Kern bleibt austauschbar und Updates werden nicht durch unüberschaubare Core-Patches blockiert.
7. Die normale Weboberfläche kann als sichere Schreibschnittstelle dienen
Für viele Projekte ist keine umfangreiche neue API erforderlich. Ein Agent kann sich mit einem eigenen Konto anmelden, das Bearbeitungsformular abrufen, die vorhandenen Schutzfelder übernehmen und die Seite mit Autor sowie Änderungszusammenfassung speichern. Danach liest er die Seite erneut und vergleicht das gespeicherte Ergebnis.
Wichtig sind Konflikterkennung, CSRF-Schutz, eine eindeutige Agentenidentität und die Prüfung nach jedem Schreibvorgang. Für häufige oder externe Automatisierungen kann später eine schmale, projektspezifische Schnittstelle hinzukommen.
Was eine gute Agentenintegration benötigt
Technische Grundlage
- eine aktuelle stabile PmWiki-Version auf einer noch unterstützten PHP-Version,
- HTTPS und sichere Sitzungscookies,
- eine eigene lokale Konfiguration statt Änderungen am PmWiki-Kern,
- regelmäßige, getestete Backups von Seiten, Konfiguration und Uploads,
- ein Uploadverzeichnis, in dem keine Skripte ausgeführt werden können,
- eine Positivliste erlaubter Dateitypen und begrenzte Dateigrößen,
- Protokollierung und Überwachung für fehlgeschlagene oder ungewöhnliche Zugriffe.
Die jeweils aktuellen Voraussetzungen beschreibt die offizielle Seite PmWiki Requirements. Sicherheitsfragen werden unter PmWiki Security zusammengeführt.
Ein klar begrenzter Agentenzugang
- ein eigenes Benutzerkonto je Agent oder Agentenrolle,
- nur die tatsächlich benötigten Rechte,
- Zugangsdaten ausschließlich in einer lokalen Geheimnisdatei oder einem Secret Store,
- keine Zugangsdaten in Prompts, Wikiseiten, öffentlichen Protokollen oder Uploads,
- SFTP nur für Konfiguration, Erweiterungen und Dateien, nicht als normaler Weg für Seitenänderungen,
- keine direkte Bearbeitung von `wiki.d`, außer bei kontrollierter Migration oder Wiederherstellung.
Ein redaktionelles Modell
Ein Agent braucht eindeutige Regeln dafür, was er selbst entscheiden darf. Bewährt hat sich ein einfacher Lebenszyklus:
Entwurf -> menschliche Prüfung -> freigegeben -> bei neuer Bearbeitung wieder in Prüfung
Zusätzlich braucht es:
- klar benannte Verantwortliche,
- maschinenlesbare Statuswerte,
- eine geschützte Arbeits- und Aufgabenübersicht,
- Quellenregeln für sachliche Aussagen,
- eine menschliche Endfreigabe für öffentliche Inhalte,
- sichtbare Hinweise, wenn eine Seite noch nicht freigegeben ist.
Eine Agentenanweisung für PmWiki
PmWiki verwendet eigenes Markup und ist nicht mit Markdown identisch. Ein Agent muss unter anderem wissen:
- wie Gruppen, Seiten und Anhänge aufgelöst werden,
- wie PmWiki-Markup statt Markdown geschrieben wird,
- welche Dateien zum Core gehören und nicht verändert werden sollen,
- wie `local/config.php`, Skins und Cookbook-Erweiterungen getrennt werden,
- wie Seiten über die reguläre Bearbeitung geändert werden,
- welche Prüfungen nach Inhalts-, PHP-, CSS- oder Serveränderungen nötig sind.
Eine solche Anweisung vermindert typische Fehler erheblich und macht die Arbeitsweise zwischen verschiedenen Agenten wiederholbar.
Ein möglicher Aufbau
Mensch / Herausgeber
| Aufgaben, Korrekturen, Freigabe
v
geschützte Werkstatt und Auftragsliste
| eindeutige Seite + Ziel + gewünschte Änderung
v
KI-Agent mit begrenztem Bearbeitungskonto
| lesen -> sichern -> ändern -> erneut lesen -> prüfen
v
PmWiki-Seite mit Status und Versionsgeschichte
| Review
v
menschliche Freigabe oder neuer Korrekturauftrag
Konfigurations- und Mediendateien können getrennt über einen kontrollierten Dateiweg übertragen werden. Der Agent sollte immer wissen, welcher Weg für Inhalt und welcher für Technik vorgesehen ist.
Minimaler Integrationsweg
- PmWiki aktuell installieren und HTTPS aktivieren.
- Einen eigenen Skin beziehungsweise lokale CSS-Anpassungen verwenden; den Core unverändert lassen.
- Persönliche Konten für Mensch und Agent einrichten und die Agentenrechte begrenzen.
- Öffentliche Inhalte und geschützte Werkstatt in getrennte Gruppen legen.
- Ein kleines Metadatenschema für Seitentyp, Status, Verantwortung und Quellen festlegen.
- Einen getesteten Schreibablauf über die PmWiki-Bearbeitung einrichten.
- Vor jeder Änderung lesen, bei größeren Eingriffen sichern und nach dem Speichern erneut vergleichen.
- Einen Review- und Freigabeprozess mit menschlicher Letztentscheidung einrichten.
- Uploads härten und nur notwendige Dateitypen zulassen.
- Zuerst eine Seite vollständig durch den Prozess führen; erst danach automatisieren oder auf viele Seiten ausweiten.
Häufige Fehler
- Markdown ungeprüft übernehmen: Überschriften, Links, Listen und Codeblöcke besitzen in PmWiki eine andere Syntax.
- `wiki.d` direkt verändern: Das kann Historie, Kodierung oder Seiteneigenschaften beschädigen.
- Dem Agenten Administratorrechte geben: Für normale Inhaltsarbeit ist das unnötig.
- Den PmWiki-Kern patchen: Änderungen werden bei Updates überschrieben und erschweren die Wartung.
- Massenänderungen ohne Pilot: Erst eine Seite, dann wenige Seiten, anschließend erst den Gesamtbestand bearbeiten.
- Ungeprüfte Cookbook-Rezepte installieren: Erweiterungen sind ausführbarer Fremdcode und müssen auf Aktualität sowie Sicherheit geprüft werden.
- Speichern mit Fertigsein verwechseln: Nach jedem Schreibvorgang müssen Inhalt, Status, Links und öffentliche Darstellung kontrolliert werden.
- Freigabe automatisieren: Bei redaktionellen und ethischen Inhalten sollte die Letztentscheidung sichtbar bei einem verantwortlichen Menschen liegen.
Wie KI-Ethos PmWiki verwendet
KI-Ethos setzt dieses Grundmuster bereits praktisch ein:
- `ki-agent` darf Seiten bearbeiten und zur Prüfung einreichen, aber nicht freigeben.
- Hans Hufnagel prüft, erteilt Korrekturaufträge und setzt den Status `approved`.
- Öffentliche Seiten tragen einen maschinenlesbaren Status.
- Die Gruppe `Werkstatt` ist nur für angemeldete Bearbeitende sichtbar.
- Seitenänderungen erfolgen über PmWiki und behalten dadurch Historie und Autorenzuordnung.
- Konfiguration, Skin, eigene Markups und Dateien werden getrennt vom Inhalt gepflegt.
- Vor technischen Umbauten werden gezielte Rücksetzpunkte angelegt.
Das System bleibt bewusst einfach. Zusätzliche Automatisierung wird erst eingebaut, wenn ein kleiner Ablauf zuverlässig funktioniert.
PmWiki.md für KI-Agenten
Die folgende Markdown-Datei ist eine ausführliche, allgemein wiederverwendbare Arbeitsanweisung für KI-Agenten. Sie behandelt PmWiki-Markup, Seitenstruktur, Konfiguration, CSS, Skins, Cookbook-Rezepte, eigene Markups, Uploads, Sicherheit, Fehlersuche und einen vorsichtigen Änderungsworkflow.
PmWiki.md – Arbeitsanweisung öffnen oder herunterladen
Die Datei ist keine offizielle PmWiki-Dokumentation. Sie sollte zusammen mit einer zweiten, nicht öffentlichen Projektdatei verwendet werden, die Domain, Rollen, Verzeichnisse, eigene Erweiterungen, Backupverfahren und Namenskonventionen der konkreten Installation beschreibt. Zugangsdaten gehören in keine dieser Dateien.