Annotix-MCP-Bridge auf Stage

stage.webdevmedia.de führt Annotix 1.0.7 und die separate Bridge mcp-annotix-bridge-plugin 0.1.0. Die Bridge macht visuelles Annotix-Feedback für ChatGPT/Codex auffindbar, lesbar und sicher aktualisierbar, ohne Annotix-Core zu verändern. Active und Fallback gehören nicht zu diesem Rollout.

Architektur und Tool-Vertrag

Annotix 1.0.7 besitzt Speicherschema 6, die dynamisch präfixierten Tabellen antx_feedback und antx_feedback_replies sowie native REST-Callbacks unter antx/v1. Seine Lese-API listet nur eine bereits bekannte Seiten-URL und bietet keine globale Detailoperation. Deshalb verwendet die Bridge für List/Get einen gekapselten, ausschließlich lesenden Datenbankadapter mit Versions-, Tabellen- und Spaltenprüfung. Sichere Screenshot- und Attachment-URLs kommen weiterhin aus Annotix' nativer Normalisierung. Sämtliche Mutationen laufen über die nativen Annotix-Permissions und -Callbacks; direkte SQL-Schreibzugriffe gibt es nicht.

Der MCP-OAuth-Transport besitzt unabhängig von WordPress-Cookies einen Principal. Für Annotix wird dieser fail-closed per exakt gleichem WordPress-Login aufgelöst. Nur während des nativen Annotix-Callbacks setzt die Bridge diesen Benutzer als current_user; ein finally stellt den vorherigen Zustand sofort wieder her. Ohne exakten Match gibt es keinen Ersatzbenutzer und keine Operation.

Die drei Werkzeuge sind bewusst kleiner als der ursprüngliche Fünf-Tool-Entwurf: Resolve und Reopen sind Werte derselben nativen Statusmutation; Reply und optionale Statusänderung teilen Berechtigungs- und Sessiongrenze. Dadurch sinken Katalog-, Schema- und Auswahlkontext, ohne Funktionsumfang zu verlieren. Create, Edit und Delete werden nicht beworben.

Annotix speichert in dieser Version keinen DOM-/CSS-Selector, XPath, Elementtext, HTML-Ausschnitt, Seitentitel oder Kategorien. Die Bridge erfindet diese Daten nicht. Sie gibt auch keine Binärscreenshots aus; der Agent erhält eine sichere Medien-URL und die gespeicherten Geometriedaten.

Sicherheit und Berechtigungen

• Die wirksame MCP-Rolle muss mindestens customer sein; zusätzlich entscheidet Annotix' eigene Nutzerkonfiguration über Lesen, Reply und Status.
• Der OAuth-Principal muss exakt einem WordPress-Login entsprechen. Die kurzlebige Identitätsbindung erweitert weder Betriebssystem- noch MCP-Rechte.
• Bei Aktivierung setzt die Bridge ausschließlich den aktivierenden WordPress-Administrator auf den nativen Annotix-Typ dev, sofern er nicht bereits client oder dev ist. Läuft die servicegesteuerte Aktivierung ohne WordPress-Current-User, führt der erste authentifizierte MCP-Aufruf jedes MCP-Admins dieselbe Freigabe genau einmal aus und merkt dessen ID in der Bridge-eigenen Option mcp_annotix_bridge_bootstrapped_users. Eine spätere manuelle Rücksetzung auf none bleibt deshalb wirksam. Andere Nutzer bleiben unverändert. dev ist hier Least Privilege: Lesen, Reply und Status sind erlaubt, Create, Edit, Move und Delete nicht.
• Schreibzugriffe verlangen eine offene Work Session im Scope annotix. Fehlt sie, bootstrapped der vorhandene MCP-Vertrag automatisch collaboration__session_open und wiederholt den Aufruf.
• Gasttoken, Nonces, Cookies, Screenshot-Dateipfade und Binärdaten verlassen den Server nicht. Anhänge werden auf ID, Name, MIME, Größe und sichere URL reduziert.
• Die Bridge besitzt keinen Delete-Pfad. Replies sind über die Bridge append-only.
• reply_and_set_status schreibt zuerst die Antwort und setzt danach den Status. Bei einem seltenen zweiten Fehler meldet die strukturierte Antwort, dass die Antwort bereits gespeichert wurde; die Operation täuscht keine Transaktion vor.

Installation, Update und Smoke-Test

1. Den vollständigen Pluginbaum aus dem versionierten Commit nach wp-content/plugins/mcp-annotix-bridge-plugin auf Stage vorbereiten; weder Active noch Fallback berühren.
2. PHP-Syntax und tests/static-smoke.php vor dem Tausch prüfen. Vorherigen Stage-Baum als owner-only Rollbackpartner erhalten.
3. Plugin aktivieren und tests/wp-smoke.php im WordPress-Kontext ausführen.
4. Im Funktionskatalog nach annotix suchen und exakt die drei Werkzeuge samt read/write-, destructive- und Work-Session-Metadaten prüfen.
5. List/Get mit leerer sowie paginierter Ergebnismenge prüfen. Für Schreibproben ausschließlich einen eindeutig mit [MCP TEST] markierten isolierten Punkt verwenden.
6. Reply, in_progress, resolved und open über MCP setzen, jeweils erneut lesen und in Annotix' UI kontrollieren.
7. Einen nicht berechtigten Principal negativ prüfen. Annotix kontrolliert deaktivieren, strukturierten annotix_not_available-Fehler und weiterhin gesundes WordPress prüfen, danach Annotix wieder aktivieren.
8. Frontend, Admin, Screenshot-URL und Browseransicht prüfen; Testdaten anschließend entfernen oder den begründeten Restzustand protokollieren.

Rollback

Ein Plugin-Rollback deaktiviert die Bridge oder tauscht ausschließlich ihren vollständigen Stage-Pluginbaum gegen den geprüften Vorgänger. Annotix und seine Tabellen bleiben unverändert. Der Rückweg wird mit WordPress-Aktivierung, HTTP, Katalog und Annotix-UI geprüft. Einen Status setzt annotix__feedback_update mit dem vorherigen Wert zurück; automatisch erzeugte Replies werden nicht gelöscht.

Grenze: Abhängigkeit von Annotix 1.x Speicherschema 6

Bei fehlendem Annotix, Version 2.x, anderem Schemastring, fehlenden Tabellen/Spalten oder fehlenden nativen Methoden bricht der Adapter fail-closed mit einem strukturierten Fehler ab. Nach einem Annotix-Update sind Feature-Erkennung, Testpunkt und UI-Smoke vor Freigabe erneut auszuführen.