Assess your software for co-browsing

Before you add Relyo, your coding agent can assess your existing software: which user interfaces are there, which method fits (DOM mirroring or frame capture), what has to be masked, how much effort is it? The agent only reads the code and changes nothing. The result is a report with a recommendation, a masking list, an effort plan and open questions.

How to use the prompt

Open your coding agent (Claude Code, Cursor, Copilot …) in your software’s repository and give it this task:

Assess this software following the brief at https://relyo.de/en/docs/assessment.md
(section "Assessment brief") and deliver the report in the format described there.
Do not change any code.

Or copy the full brief below. For larger systems with several repositories, give the agent every repository that contains a user interface end users work with.

Today there are SDKs for websites and Flutter apps. If the agent finds other technologies (for example WinForms, WPF or Java), it rates them as “no head yet” and estimates that effort separately.

Assessment brief

# Assessment brief: co-browsing integration (Relyo) for an existing software product

You are an assessment agent with read access to the complete source code of an existing software product. Your task: find out which options exist to integrate Relyo co-browsing (a support agent sees the user's screen after the user consents, can annotate, and can take control after a second consent) into this software, and recommend the best option with effort and risks. You do not change any code. You answer questions from the code, not from assumptions; anything you cannot back with evidence you mark as open.

## Background: the two methods

Relyo has exactly two transfer methods; everything else is an adapter:

1. **DOM mirroring (`stream: dom`)** for everything that renders as HTML in a browser or WebView. A JavaScript SDK (rrweb) serialises the DOM once in full and then only mutations; remote control dispatches DOM events. Works with: classic websites, SPAs (React/Vue/Angular), ASP.NET WebForms, Blazor (Server, WASM, Hybrid), Electron renderers, WebView2/WKWebView content. Does not work with: UIs rendered on `<canvas>` (Flutter Web, Avalonia Browser, WebGL apps), cross-origin iframes.
2. **Frame capture (`stream: frame`)** for everything without a DOM. The SDK renders the app's own window into an RGBA buffer, masks sensitive areas on the device, splits it into 64 px tiles and sends only changed tiles. Capture per platform: Windows `PrintWindow(PW_RENDERFULLCONTENT)` on the app's own HWND; Android `PixelCopy` on the window; iOS `UIWindow.drawHierarchy`; Flutter `RepaintBoundary.toImage`; Avalonia `RenderTargetBitmap`. No operating system permission, no desktop capture. Remote control by injecting events into the app itself (Windows PostMessage/UI Automation, Android `dispatchTouchEvent`, iOS only limited, Flutter `GestureBinding`).

**State of the SDKs (check the current docs):** Available are the web SDK (`dom`, https://relyo.de/en/docs/web.md) and the Flutter SDK `relyo_flutter` (`frame`, iOS 15+, Android 8+, Flutter Web, https://relyo.de/en/docs/flutter.md). SDKs for .NET (WinForms, WPF, MAUI, Avalonia) and Java are planned but not yet available; native iOS/Android apps without Flutter have no head yet either. For these platforms the capture methods above describe the intended technique: rate such interfaces as "no head yet" and estimate that effort separately. Project keys for relyo.de: https://relyo.de/en/docs/project.md.

Mandatory parts of every integration: consent dialog before the first transfer, a status indicator that cannot be covered during the session, masking of password fields automatically and of marked areas manually, immediate revocation of remote control on real user input, the user can end the session at any time.

## Procedure

Work through the steps in this order and record the evidence for each step (file paths, lines, build files).

### 1. Inventory of user interfaces

Find every independent user interface an end user works with. Per interface:

- Name, purpose, who uses it (customers, back office, admins)
- Technology and version: web (framework, build tool), ASP.NET WebForms/MVC/Razor Pages/Blazor (which hosting model, render modes), WinForms, WPF, MAUI, Avalonia, Xamarin, Electron, Flutter, native iOS/Android, Java Swing/JavaFX, Qt, Delphi, other
- Runtime: .NET Framework 4.x / .NET 6–10, Node, Flutter version, JDK, operating systems, minimum OS, mobile targets
- Entry point (`Program.Main`, `App.xaml`, `MauiProgram`, `main.dart`, `index.html`, master page, `_Host.cshtml`/`App.razor`)
- Distribution: installer, store, ClickOnce, intranet URL, Citrix/RDP operation (important: with terminal server operation, capture runs on the server – check whether the window exists there)

Evidence: project files (`*.csproj`, `pubspec.yaml`, `package.json`, `build.gradle`, `*.xcodeproj`), target frameworks, references.

### 2. Embedded foreign rendering surfaces

For each interface from step 1: which parts do not render through the main technology?

- WebViews (WebView2, `WebBrowser`, WKWebView, Android WebView, `BlazorWebView`, `webview_flutter`), embedded browser components, PDF viewers, maps, charts on `<canvas>`/DirectX/OpenGL, video, ActiveX, `WindowsFormsHost` in WPF, platform views in Flutter, `NativeControlHost` in Avalonia
- Third-party UI suites (Telerik, DevExpress, Infragistics, Syncfusion, ComponentOne) and how they render (GDI, DirectX, HTML)
- Multi-window operation: MDI, floating dialogs, popups, tray windows, second monitors

Per surface: is it captured by the respective method (see background), does it have to be marked ("do not transfer") or captured separately?

### 3. Sensitive data and masking

- All password/PIN/token inputs: control types and whether they can be detected automatically (`PasswordChar`, `PasswordBox`, `isSecureTextEntry`, `type=password`, `Entry.IsPassword`, `obscureText`)
- Areas with personal or confidential data a supporter must not see (salaries, health data, payment data, customer lists of other tenants). How can they be identified in the code (control names, components, routes, data bindings)? How many places would have to be marked manually?
- Multi-tenant logic: are there roles/permissions that must also apply to sharing a session?
- Existing privacy/logging/audit mechanisms that Relyo events (session started, control granted) should be connected to

### 4. Input and event model

- How do user events arise (standard framework events, own input layer, global hooks, gamepad/scanner/barcode reader, touch)?
- Is there already a message filter / input pipeline where synthetic and real input could be told apart?
- Special cases: modal dialogs, drag and drop, context menus, keyboard shortcuts that remote control must not trigger (e.g. booking, deleting, payment approval) – candidates for a key/action block list

### 5. Network and operations

- Outgoing connections: is a WebSocket (`wss://`) to a relay possible? Proxy configuration, certificate pinning, firewall rules in the target environment, offline operation
- CSP, hosting, CDN for web interfaces; script inclusion in master pages/layouts
- Identity: is there a user ID / display name that can be passed when connecting (to search for a device instead of entering a code)?
- Existing support tools in the code (TeamViewer links, remote desktop calls, error report functions, help menu) as a natural hook for "show support code"

### 6. Lifecycle and navigation

- Reloads/postbacks/restarts that interrupt a session (full postbacks, full-page navigation, app restart after login, tenant switch)
- Background/foreground, minimise, lock screen, multi-window
- Where can the current context ("which screen/route is open") be read so the supporter sees it?

### 7. Build, test, distribution

- Build pipeline, package format, signing, release cycle: how does an SDK update reach users?
- Existing UI tests (Playwright, FlaUI, Appium, integration_test) that Relyo acceptance tests could build on
- Licence and dependency rules (e.g. no native libs, no GPL) that restrict the choice of encoder or SDK

## Deriving options

For each interface, work out the possible integration paths and rate them. Check at least:

- **A. DOM mirroring directly** (add the web SDK)
- **B. DOM mirroring in the embedded WebView** (for hybrid apps: web SDK in the WebView, host window not mirrored)
- **C. Frame capture of the app's own window** via the matching head (WinForms, WPF, MAUI, Avalonia, Flutter, native)
- **D. Combination** (host frame + WebView DOM as two streams)
- **E. Not sensibly integrable** – with reasons (e.g. terminal server without window access, Delphi/Qt without an available head → estimate the effort for a new head)

Rating criteria per option: screen coverage (what is missing), remote control (full/limited/none), masking effort (number of manual places), depth of code changes (lines, affected projects), risks (performance, DPI, third-party components, operating environment), effort in person-days for integration, masking, tests and rollout.

## Report format

Deliver a Markdown report with exactly this structure:

1. **Summary** (max. 10 sentences): recommended option(s), total effort, the two biggest risks.
2. **Inventory** as a table: interface | technology/version | runtime | user group | distribution | method (dom/frame) | evidence path.
3. **Per interface** one section: options A–E rated against the criteria above, recommendation, concrete hook (file/method) for `Init`, `ShowCode`, masking markers, interrupt hook, navigation.
4. **Masking list**: every place with sensitive data (path, control, reason), split into "detected automatically" and "to be marked manually".
5. **Block list** for remote control: actions/keys that must never be triggered remotely, with reasons.
6. **Operating requirements**: firewall/proxy/CSP/certificates, minimum OS, DPI manifest, terminal server findings.
7. **Effort plan**: table sub-task | PD | dependency, split into integration, masking, tests, rollout.
8. **Open questions**: everything that could not be decided from the code, with the person or artefact that can clarify it.
9. **Evidence**: list of all files consulted.

Rules: no estimate without reasons. No statement about third-party components without looking at their reference/version in the project. If an interface mixes several technologies, treat each part separately. If you find a technology Relyo has no head for, describe which capture and injection method would be possible there and estimate the head separately.