# 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.