Files
WP-LIT-MCP/docs/superpowers/notes/2026-09-26-etappe-1b-abnahme.md
T

3.7 KiB
Raw Blame History

Etappe 1b – Manuelle Abnahme (Browser)

Vorbereitet von Task 13 (Doku/Version/E2E). Automatisiert geprüft ist bereits: alle Unit-Tests (composer test), Lint (composer lint) und die drei Integrationsskripte (tests/Integration/mcp-smoke.sh, tests/Integration/wp-basis-smoke.sh, tests/Integration/media-admin-smoke.sh) – Details im Report von Task 13 (.superpowers/sdd/2026-09-25-etappe-1b-medien-admin/task-13-report.md).

Die folgenden Punkte lassen sich nicht automatisiert oder nur mit einem echten claude.ai-Connector prüfen; das führt Jan-Niclas selbst im Browser durch. Aktueller Stand: Version 0.2.0, Branch etappe-1.

1. Einstellungen → LIT MCP: alle Tabs

  • Aufrufen: WordPress-Adminbereich → Einstellungen → LIT MCP.
  • Alle fünf Tabs öffnen: Verbindung, Zugriff, Tools, Protokoll, Limits. Jeder Tab lädt ohne PHP-Fehler/-Warnung (WP_DEBUG ist an) und zeigt sinnvolle Inhalte.
  • Im Tab „Zugriff“: Rolle „Redakteur“ freigeben, speichern; ein Redakteur-Konto kann sich danach verbinden (Access-Capability wirkt sofort, kein Cache). Freigabe wieder entfernen, speichern.
  • Im Tab „Tools“: ein Tool (z. B. lit/content-query, Standard „direkt“) auf „indirekt“ stellen, speichern – der Hinweistext dort weist bereits darauf hin, dass die Serveranweisungen erst ab der nächsten Verbindung gelten. Danach wieder auf „Standard“ zurückstellen, speichern.

2. claude.ai-Connector verbinden und Widerruf

  • Mit claude.ai verbinden (Staging-Domain oder ddev share), OAuth-Flow durchlaufen.
  • Die neue Verbindung erscheint unter Einstellungen → LIT MCP → Zugriff („Aktive Verbindungen“) mit Client-Namen und Zeitpunkt.
  • Dort „Widerrufen“ klicken. Der nächste Tool-Aufruf in claude.ai scheitert (401) und claude.ai verlangt eine neue Anmeldung, bevor Tools wieder nutzbar sind.

3. Medien-Workflow in claude.ai

  • In claude.ai anfragen: „Suche Bilder ohne Alt-Text, zeig mir eins und schlag einen Alt-Text vor.“ Erwartet: lit-media-search mit missing_alt: true liefert Treffer, lit-media-preview zeigt ein sichtbares Bild in der Unterhaltung (nicht nur eine Textbeschreibung).
  • Optional weiterführen: Alt-Text mit lit/media-update speichern lassen und in der WordPress- Mediathek prüfen, dass er übernommen wurde.

4. Werkzeuge → Website-Zustand

  • WordPress-Adminbereich → Werkzeuge → Website-Zustand → Reiter „Info“ bzw. die Testübersicht.
  • Der Test „LIT MCP Endpunkt“ ist grün, wenn der Server erreichbar und /.well-known/ durchgereicht wird – sonst zeigt er verständlich, was fehlt (z. B. nginx-Sperre für Punkt-Pfade). Bei diesem DDEV-Setup hat mcp-smoke.sh bereits eine WARN dazu ausgegeben (/.well-known/ von der nginx-Konfiguration blockiert) – das hier im Site-Health-Test bestätigen und für die Staging-/Produktions-nginx-Konfiguration eine Ausnahme für /.well-known/ einplanen.

5. Protokoll-Tab

  • Einstellungen → LIT MCP → Protokoll: Einträge der eben durchgeführten Tests (Task 13 und die manuellen Schritte hier) sind sichtbar.
  • Filter nach Tool/Ability (z. B. lit/media-update) funktioniert und schränkt die Liste ein.
  • Ein Eintrag mit Revisions-Link öffnet den WordPress-Revisionsvergleich (z. B. nach einer lit-content-update- oder lit/post-replace-with-copy-Änderung).
  • „Protokoll leeren“ leert die Liste (Bestätigungsdialog beachten) und zeigt danach die Erfolgsmeldung „Protokoll geleert.“.

Ergebnis

Kurze Rückmeldung an den Ausführenden (Task 13 / Controller): welche Punkte grün sind und was ggf. als Folgeaufgabe (Bugfix oder Doku-Korrektur) aufgenommen werden muss.