Desktop client

Desktop Client

The Desktop VTOC Client is the planned companion application for an authorized computer. Its purpose is to make a connected VTOC Agent understandable and manageable without hiding what happens to the device.

It should feel like a practical device-management application: select a known device, see its condition, review what it supports, make a deliberate change, and retain a clear result. It is not a remote shell, a generic USB scanner, or a way to enable unavailable hardware functions.

Intended experience

flowchart LR
  A[Choose an authorized device connection] --> B[See identity, board profile, and health]
  B --> C[Review available capabilities and current mode]
  C --> D[Request an explicit supported action]
  D --> E[Show progress, result, and recovery guidance]
  E --> F[Optionally publish typed result to enabled integrations]

Loading

The first useful client screens should cover:

Area	What the owner should see or do
Device overview	Board profile, firmware version, connection state, battery or power state when supported, and last health result.
Connection	Explicitly select an approved USB/UART or network transport; explain when no supported transport is available.
Capabilities and modes	Show only functions the attached board and enabled integrations actually support.
Configuration	Review and apply validated configuration with a clear summary of the change.
Updates and recovery	Link to the reviewed browser-flasher release process and present recovery information before risky operations.
Activity	Show clear job state, timestamps, errors, and sanitized audit records.

Containerized service boundary

The graphical interface, if present, talks to a local VTOC Client service. The service can run in a container on an authorized computer and exposes a typed, documented API. The container must receive only the device transport and host permissions it needs; it must not receive blanket host access by default.

flowchart TB
  UI[Desktop UI or local web view] --> API[Local typed client API]
  API --> S[Containerized VTOC Client service]
  S --> T[Explicitly allowed device transport]
  T --> D[VTOC Agent firmware]
  S --> I[Enabled typed integrations]

Loading

What belongs where

Responsibility	Firmware	Desktop Client	Browser Flasher
Board startup and safe hardware control	Yes	No	No
Device health and supported sensor readings	Yes	Presents and records	No
Local device connection selection	No	Yes	Only for an explicit flash action
Day-to-day configuration and mode controls	Executes supported commands	Guides the owner and shows results	No
Firmware artifact selection and install	Receives image	Links to process and shows state	Yes
Recovery instructions and evidence	Implements recovery path	Presents guidance	Presents release-specific guidance

Implementation path

1. Define the shared protocol for device identity, health, capabilities, jobs, configuration, and errors.
2. Implement a minimal local client service that can connect through one declared transport and display real device health.
3. Add a small desktop or local-web interface that consumes that service API.
4. Add configuration and supported mode controls only after their firmware contract and recovery behavior are tested.
5. Add optional Ragnar and TAK views through typed integrations; retain the VTOC TAC Plugin as the separate TAK gateway.

This keeps the product approachable without turning the desktop client into a monolith or granting it authority beyond the attached device's declared capabilities.