Software auf Co-Browsing prüfen

Bevor du Relyo einbaust, kann dein Coding-Agent deine bestehende Software untersuchen: Welche Oberflächen gibt es, welches Verfahren passt (DOM-Mirroring oder Frame-Capture), was muss maskiert werden, wie viel Aufwand ist es? Der Agent liest nur den Code und ändert nichts. Am Ende steht ein Bericht mit Empfehlung, Maskierungsliste, Aufwandsplan und offenen Fragen.

So nutzt du den Prompt

Öffne deinen Coding-Agent (Claude Code, Cursor, Copilot …) im Repository deiner Software und gib ihm diesen Auftrag:

Untersuche diese Software nach dem Auftrag unter https://relyo.de/docs/analyse.md
(Abschnitt „Untersuchungsauftrag“) und liefere den Bericht im dort beschriebenen Format.
Ändere keinen Code.

Oder kopiere den vollständigen Auftrag unten. Bei großen Systemen mit mehreren Repositories gibst du dem Agent alle Repositories, die zu Oberflächen gehören, die Endnutzer bedienen.

Heute gibt es SDKs für Websites und Flutter-Apps. Findet der Agent andere Technologien (zum Beispiel WinForms, WPF oder Java), bewertet er sie als „Head fehlt“ und schätzt den Aufwand dafür getrennt.

Untersuchungsauftrag

# Untersuchungsauftrag: Co-Browsing-Integration (Relyo) für eine bestehende Software

Du bist ein Untersuchungsagent mit Lesezugriff auf den vollständigen Quellcode einer bestehenden Software. Deine Aufgabe: Ermittle, welche Optionen es gibt, Relyo-Co-Browsing (Support-Mitarbeiter sieht den Bildschirm des Nutzers nach dessen Zustimmung, kann annotieren und nach zweiter Zustimmung fernsteuern) in diese Software zu integrieren, und empfiehl die beste Option mit Aufwand und Risiken. Du änderst keinen Code. Du beantwortest Fragen aus dem Code, nicht aus Annahmen; was du nicht belegen kannst, kennzeichnest du als offen.

## Hintergrund: die zwei Verfahren

Relyo kennt genau zwei Übertragungsarten, alles andere ist Adapter:

1. **DOM-Mirroring (`stream: dom`)** für alles, was in einem Browser oder WebView als HTML rendert. Ein JavaScript-SDK (rrweb) serialisiert den DOM einmal vollständig und danach nur Mutationen; Fernsteuerung dispatcht DOM-Events. Geht mit: klassischen Web-Seiten, SPAs (React/Vue/Angular), ASP.NET WebForms, Blazor (Server, WASM, Hybrid), Electron-Renderer, WebView2/WKWebView-Inhalt. Geht nicht mit: `<canvas>`-gerenderten Oberflächen (Flutter Web, Avalonia Browser, WebGL-Apps), Cross-Origin-iframes.
2. **Frame-Capture (`stream: frame`)** für alles ohne DOM. Das SDK rendert das eigene Anwendungsfenster in einen RGBA-Puffer, maskiert sensible Bereiche auf dem Gerät, teilt in 64-px-Kacheln und sendet nur geänderte Kacheln. Capture pro Plattform: Windows `PrintWindow(PW_RENDERFULLCONTENT)` auf das eigene HWND; Android `PixelCopy` auf das Window; iOS `UIWindow.drawHierarchy`; Flutter `RepaintBoundary.toImage`; Avalonia `RenderTargetBitmap`. Keine Betriebssystem-Berechtigung, kein Desktop-Capture. Fernsteuerung durch Event-Injektion in die eigene App (Windows PostMessage/UI Automation, Android `dispatchTouchEvent`, iOS nur eingeschränkt, Flutter `GestureBinding`).

**Stand der SDKs (prüfe die aktuelle Doku):** Verfügbar sind das Web-SDK (`dom`, https://relyo.de/docs/web.md) und das Flutter-SDK `relyo_flutter` (`frame`, iOS ab 15, Android ab 8, Flutter Web, https://relyo.de/docs/flutter.md). Für .NET (WinForms, WPF, MAUI, Avalonia) und Java sind SDKs geplant, aber noch nicht verfügbar; native iOS-/Android-Apps ohne Flutter haben ebenfalls noch keinen Head. Die Capture-Verfahren oben beschreiben für diese Plattformen die vorgesehene Technik: Bewerte solche Oberflächen als „Head fehlt“ und schätze den Aufwand separat. Projekt-Keys für relyo.de: https://relyo.de/docs/projekt.md.

Pflichtbestandteile jeder Integration: Consent-Dialog vor der ersten Übertragung, nicht überdeckbare Statusanzeige während der Session, Maskierung von Passwortfeldern automatisch und von markierten Bereichen manuell, sofortiger Widerruf der Fernsteuerung bei echter Nutzereingabe, Beenden jederzeit durch den Nutzer.

## Vorgehen

Arbeite die Schritte in dieser Reihenfolge ab und notiere pro Schritt die Belege (Dateipfade, Zeilen, Build-Dateien).

### 1. Inventar der Oberflächen

Finde jede eigenständige Oberfläche, die ein Endnutzer bedient. Pro Oberfläche:

- Name, Zweck, wer sie nutzt (Endkunde, Innendienst, Admin)
- Technologie und Version: Web (Framework, Build-Tool), ASP.NET WebForms/MVC/Razor Pages/Blazor (welches Hosting-Modell, Render-Modes), WinForms, WPF, MAUI, Avalonia, Xamarin, Electron, Flutter, nativ iOS/Android, Java Swing/JavaFX, Qt, Delphi, anderes
- Runtime: .NET Framework 4.x / .NET 6–10, Node, Flutter-Version, JDK, Betriebssysteme, Mindest-OS, Mobile-Targets
- Einstiegspunkt (`Program.Main`, `App.xaml`, `MauiProgram`, `main.dart`, `index.html`, Master Page, `_Host.cshtml`/`App.razor`)
- Verteilung: Installer, Store, ClickOnce, Intranet-URL, Citrix/RDP-Betrieb (wichtig: bei Terminal-Server-Betrieb läuft Capture auf dem Server – prüfen, ob das Fenster dort existiert)

Belege: Projektdateien (`*.csproj`, `pubspec.yaml`, `package.json`, `build.gradle`, `*.xcodeproj`), Zielframeworks, Referenzen.

### 2. Eingebettete Fremd-Rendering-Flächen

Für jede Oberfläche aus Schritt 1: Welche Teile rendern nicht über die Haupttechnologie?

- WebViews (WebView2, `WebBrowser`, WKWebView, Android WebView, `BlazorWebView`, `webview_flutter`), eingebettete Browser-Komponenten, PDF-Viewer, Karten, Charts auf `<canvas>`/DirectX/OpenGL, Video, ActiveX, `WindowsFormsHost` in WPF, Platform Views in Flutter, `NativeControlHost` in Avalonia
- Drittanbieter-UI-Suiten (Telerik, DevExpress, Infragistics, Syncfusion, ComponentOne) und deren Rendering-Art (GDI, DirectX, HTML)
- Mehrfenster-Betrieb: MDI, Floating-Dialoge, Popups, Tray-Fenster, zweite Monitore

Pro Fläche: Wird sie vom jeweiligen Capture-Verfahren erfasst (siehe Hintergrund), muss sie markiert („nicht übertragen“) oder gesondert erfasst werden?

### 3. Sensible Daten und Maskierung

- Alle Passwort-/PIN-/Token-Eingaben: Control-Typen und ob sie automatisch erkennbar sind (`PasswordChar`, `PasswordBox`, `isSecureTextEntry`, `type=password`, `Entry.IsPassword`, `obscureText`)
- Bereiche mit personenbezogenen oder vertraulichen Daten, die ein Supporter nicht sehen soll (Gehälter, Gesundheitsdaten, Zahlungsdaten, Kundenlisten anderer Mandanten). Wie sind sie im Code identifizierbar (Control-Namen, Komponenten, Routen, Datenbindungen)? Wie viele Stellen müssten manuell markiert werden?
- Multi-Mandanten-Logik: Gibt es Rollen/Rechte, die auch für die Freigabe einer Session gelten müssen?
- Vorhandene Datenschutz-/Logging-/Audit-Mechanismen, an die Relyo-Ereignisse (Session gestartet, Steuerung erteilt) angedockt werden sollten

### 4. Eingabe- und Event-Modell

- Wie entstehen Nutzer-Events (Standard-Framework-Events, eigener Input-Layer, globale Hooks, Gamepad/Scanner/Barcode-Leser, Touch)?
- Gibt es bereits eine Message-Filter-/Input-Pipeline-Stelle, an der synthetische von echten Eingaben unterschieden werden könnten?
- Besonderheiten: Modale Dialoge, Drag-&-Drop, Kontextmenüs, Tastenkürzel, die eine Fernsteuerung nicht auslösen darf (z. B. Buchen, Löschen, Zahlungsfreigabe) – Kandidaten für eine Tasten-/Aktions-Blockliste

### 5. Netzwerk und Betrieb

- Ausgehende Verbindungen: Ist WebSocket (`wss://`) zu einem Relay möglich? Proxy-Konfiguration, Zertifikats-Pinning, Firewall-Regeln im Zielumfeld, Offline-Betrieb
- CSP, Hosting, CDN bei Web-Oberflächen; Script-Einbindung in Master Pages/Layouts
- Identität: Gibt es eine Nutzer-ID/einen Anzeigenamen, die beim Verbinden mitgegeben werden können (für Suche nach Gerät statt Code-Eingabe)?
- Bestehende Support-Werkzeuge im Code (TeamViewer-Links, Remote-Desktop-Aufrufe, Fehlerbericht-Funktionen, Hilfe-Menü) als natürlicher Einhängepunkt für „Support-Code anzeigen“

### 6. Lebenszyklus und Navigation

- Reloads/Postbacks/Neustarts, die eine Session unterbrechen (Full-Postbacks, Vollseiten-Navigation, App-Neustart nach Login, Mandantenwechsel)
- Hintergrund/Vordergrund, Minimieren, Sperrbildschirm, Multi-Window
- Wo lässt sich der aktuelle Kontext („welche Maske/Route ist offen“) abgreifen, damit der Supporter ihn sieht?

### 7. Build, Test, Verteilung

- Build-Pipeline, Paketformat, Signierung, Release-Zyklus: Wie kommt ein SDK-Update zum Nutzer?
- Vorhandene UI-Tests (Playwright, FlaUI, Appium, integration_test), auf denen Relyo-Abnahmetests aufsetzen könnten
- Lizenz- und Abhängigkeitsregeln (z. B. keine nativen Libs, keine GPL), die Encoder- oder SDK-Wahl einschränken

## Optionen ableiten

Bilde pro Oberfläche die möglichen Integrationswege und bewerte sie. Mindestens prüfen:

- **A. DOM-Mirroring direkt** (Web-SDK einbinden)
- **B. DOM-Mirroring im eingebetteten WebView** (für Hybrid-Apps: Web-SDK im WebView, Host-Fenster nicht gespiegelt)
- **C. Frame-Capture des eigenen Fensters** über den passenden Head (WinForms, WPF, MAUI, Avalonia, Flutter, nativ)
- **D. Kombination** (Host-Frame + WebView-DOM als zwei Streams)
- **E. Nicht sinnvoll integrierbar** – mit Begründung (z. B. Terminal-Server ohne Fensterzugriff, Delphi/Qt ohne verfügbaren Head → Aufwand für neuen Head schätzen)

Bewertungskriterien je Option: Abdeckung des Bildschirms (was fehlt), Fernsteuerbarkeit (full/limited/none), Maskierungsaufwand (Anzahl manueller Stellen), Eingriffstiefe in den Code (Zeilen, betroffene Projekte), Risiken (Performance, DPI, Fremdkomponenten, Betriebsumgebung), Aufwand in Personentagen für Integration, Maskierung, Tests und Rollout.

## Ergebnisformat

Liefere einen Bericht in Markdown mit genau dieser Struktur:

1. **Zusammenfassung** (max. 10 Sätze): empfohlene Option(en), Gesamtaufwand, die zwei größten Risiken.
2. **Inventar** als Tabelle: Oberfläche | Technologie/Version | Runtime | Nutzergruppe | Verteilung | Verfahren (dom/frame) | Belegpfad.
3. **Pro Oberfläche** ein Abschnitt: Optionen A–E mit Bewertung nach den Kriterien oben, Empfehlung, konkreter Einhängepunkt (Datei/Methode) für `Init`, `ShowCode`, Maskierungsmarkierungen, Interrupt-Hook, Navigation.
4. **Maskierungsliste**: jede Stelle mit sensiblen Daten (Pfad, Control, Grund), unterteilt in „automatisch erkannt“ und „manuell zu markieren“.
5. **Blockliste** für Fernsteuerung: Aktionen/Tasten, die nie per Remote ausgelöst werden dürfen, mit Begründung.
6. **Betriebsvoraussetzungen**: Firewall/Proxy/CSP/Zertifikate, Mindest-OS, DPI-Manifest, Terminal-Server-Befund.
7. **Aufwandsplan**: Tabelle Teilaufgabe | PT | Abhängigkeit, getrennt nach Integration, Maskierung, Tests, Rollout.
8. **Offene Fragen**: alles, was aus dem Code nicht entscheidbar war, mit der Person oder dem Artefakt, das es klären kann.
9. **Belege**: Liste aller herangezogenen Dateien.

Regeln: Keine Schätzung ohne Begründung. Keine Aussage über Fremdkomponenten ohne Blick in deren Referenz/Version im Projekt. Wenn eine Oberfläche mehrere Technologien mischt, behandle jede Teilfläche getrennt. Wenn du eine Technologie findest, für die Relyo keinen Head hat, beschreibe, welches Capture- und Injektionsverfahren dort möglich wäre, und schätze den Head separat.

Software prüfen lassen

So nutzt du den Prompt

Untersuchungsauftrag