Sichere Aktionen in Chat, MCP und Windows-Integration¶

Web-Chat und MCP verwenden denselben Capability-Katalog und dieselben versionierten Fachservices. Dadurch gelten für Lesen und Schreiben dieselben Projekt-, Rollen-, Objekt- und Versionsprüfungen. Unterstützte Aktionen decken unter anderem Testbibliothek, Anforderungen, Planung, Durchführung, Ergebnisse, Reviews, Beziehungen, Defekte, Anhänge, Release-/Änderungswissen, Administration und Word-Import/-Export ab.

Eine KI-Antwort oder MCP-Vorschau ändert noch keine Projektdaten. Schreibaktionen werden ausdrücklich vorbereitet, geprüft, bestätigt und auditiert.

Vorbereiten, prüfen, bestätigen¶

1. Prepare: Chat oder MCP erstellt aus der gewünschten Fachaktion eine konkrete, berechtigungsgeprüfte Vorbereitung.
2. Preview: Prüfen Sie Zielobjekt, Änderung, Auswirkungen, Warnungen und gegebenenfalls die erwartete Objektversion.
3. Commit: Bestätigen Sie nur eine unveränderte und verstandene Vorschau. Bei Konflikten oder abgelaufener Vorschau beginnen Sie neu.
4. Audit: Prüfen Sie Ergebnis, Deep-Link und Auditspur. Wiederholte technische Aufrufe dürfen durch Idempotenz nicht unbemerkt dieselbe Änderung doppelt ausführen.

Fehlende Berechtigung, veraltete Version, unbekannte Capability oder ungültige Argumente führen zu einem geschlossenen Fehler statt zu einer teilweisen Änderung.

MCP sicher einrichten¶

MCP verwendet JSON-RPC 2.0 über POST /mcp. Persönliche projektbezogene API-Schlüssel arbeiten mit den Rollen und Berechtigungen des zugehörigen aktiven Projektbenutzers. Globale administrative Schlüssel sind getrennt; Projektzugriff für einen globalen Schlüssel muss ausdrücklich erlaubt werden.

• Erstellen Sie Schlüssel in der vorgesehenen MCP-API-Schlüsselverwaltung und kopieren Sie das Geheimnis sofort; es wird später nicht erneut angezeigt.
• Vergeben Sie kurze Laufzeiten, minimale Scopes und einen eindeutigen Zweck.
• Übergeben Sie ein Projekt über dessen eindeutige ID oder den freigegebenen Projektpfad und verlassen Sie sich nicht auf einen globalen Standardkontext.
• Nutzen Sie Werkzeugkatalog und Capability-Explorer, bevor Sie eine Aktion automatisieren.
• Widerrufen Sie nicht mehr benötigte oder möglicherweise offengelegte Schlüssel sofort.

Wiederverwendbare Testschritte über MCP¶

Für Testschrittbausteine liest ztm_project_reusable_test_steps mit der Capability project.reusable-test-step.read:

Schreiben erfolgt ausschließlich über ztm_project_action_prepare und ztm_project_action_commit. Der API-Schlüssel benötigt die konkret gewählte Schreib-Capability; eine allgemeine Schreibfreigabe reicht nicht. arguments enthält:

Ein Bausteinabschnitt enthält BlockID und die ausdrücklich gewählte Revision; ein eigener Abschnitt hat keine BlockID und enthält StepsRaw sowie optional ExpectedRaw. Raw-Texte verwenden den Projektmodus HTML oder Markdown. Beim Speichern der Zusammensetzung jeden unveränderten eigenen Abschnitt beibehalten. Ein absichtlich leerer Erwartungstext bleibt leer.

save legt eine neue feste Revision an; Archived: true archiviert den Baustein. Es gibt keinen Löschbefehl und keine automatische Aktualisierung aller Verwendungen. Einzelne Abschnitte lassen sich durch ihre aufgelösten Raw-Texte in eigenen Text umwandeln. Der Detach-Befehl löst die gesamte gespeicherte Zusammensetzung.

Vor Commit bisherigen und neuen Inhalt prüfen, dieselbe idempotencyKey bei technischen Wiederholungen verwenden und ausschließlich den erhaltenen previewToken bestätigen. Bei verändertem Fingerprint neu lesen und erneut vorbereiten. Quellleserecht und Zielschreibrecht werden im gemeinsamen Runtime-Dienst geprüft; Quick-Tests werden abgewiesen. Bei der vorhandenen Synchronisierung melden Web und MCP ausgelassene historische Inhalte als skippedManagedContent: Verwaltete Schritte/Ergebnisse bestehender Läufe bleiben gespeichert, andere gewählte Felder können synchronisiert werden.

Local Bridge und kontrollierte lokale Aktionen¶

Die Zeta Test Local Bridge verbindet freigegebene Web-Abläufe mit kontrollierten lokalen Windows-Funktionen. Der Webserver startet keine beliebigen lokalen Prozesse. Chrome oder Edge sprechen über die Browsererweiterung mit einem installierten Native-Messaging-Host; eine maschinenweite Richtlinie erlaubt nur benannte, typisierte Aktionen.

1. Ein Administrator stellt Native Host und Browsererweiterung bereit und verbindet ausschließlich die vorgesehene ZTM-Website.
2. Die Kunden-IT hinterlegt freigegebene Prozessaktionen in der Local-Bridge-Richtlinie. Freie Kommandozeilen und älteres Lua bleiben im Web gesperrt.
3. Externe Werkzeuge verwenden eine strukturierte Referenz wie ztm-local-bridge:action-id. Nur eine vorhandene und erlaubte Aktion kann ausgeführt werden.
4. Prüfen Sie in der Administration Status, Version, Prüfsumme, Endpunkte und die vorgeschlagenen Chrome-/Edge-Richtlinienwerte.

Behandeln Sie Browsererweiterung, Native Host, Website-Zuordnung und lokale Richtlinie als gemeinsame Sicherheitsgrenze. Eine verbundene Bridge ersetzt keine Projekt- oder Objektberechtigung.

Testfall-Versionen¶

ztm_project_test_case_versions liest die Testfall-Versionen mit project.test-case-version.read. Liste, Inhalt, Vergleich, historische Dateien und Vorschau stehen unter denselben Objektrechten wie im Web zur Verfügung. Die Wiederherstellung nutzt die vorbereitete und ausdrücklich bestätigte Schreibfähigkeit project.test-case-version.restore; Argumente und Ablauf sind auch im REST-Kapitel beschrieben.