-
Notifications
You must be signed in to change notification settings - Fork 1
Architecture
VTOC Agent is one product with four cooperating parts. The goal is familiar: the device has its own firmware, while an optional desktop companion gives an owner a clear way to inspect, configure, update, and operate that device. The companion is inspired by the useful shape of a desktop device manager, not by a requirement to copy any other product's implementation or interface.
flowchart TB
F[Device firmware\nboard-specific and recovery-aware]
D[Desktop VTOC Client\ncontainerized companion]
W[Browser flasher\nreviewed release install]
B[Typed VTOC bridge\nrequests, state, and results]
R[Ragnar\nremote observation consumer]
T[VTOC TAC Plugin\ncanonical TAK gateway]
S[TAK server]
W -->|owner-authorized serial flash| F
D <-->|declared local transport| F
D <-->|typed state and commands| B
F -->|device-native observations| B
B --> R
B --> T
T --> S
The firmware runs on a supported board profile, beginning with the Heltec WiFi LoRa 32 V3. It owns board-native work: safe startup, hardware health, supported sensors and radios, declared modes, local status, and recovery behavior. A firmware image is always tied to an exact board profile and release manifest.
The flasher is a public, static GitHub Pages application. It presents only reviewed release artifacts and their evidence. The owner chooses the serial port; the page must never silently discover, select, configure, or flash a device. See Browser Flasher and Release Process.
The VTOC Client is the optional companion application that runs as a containerized service on an authorized computer. It is the practical place for a desktop-style control experience: device inventory, health and logs, configuration, release preparation, mode controls, and connection state. A future graphical interface can sit on top of the same client API instead of embedding device-management logic into the browser flasher or remote services.
The client is deliberately separate from firmware. This lets a user update the desktop-side tooling without changing the board image, and lets the board remain useful when no desktop companion is running. See Desktop Client for the intended user experience and implementation boundary.
The bridge carries explicit requests, declared capabilities, job state, and results between the device, desktop client, and remote integrations. Ragnar remains remote and consumes supported device observations. The VTOC TAC Plugin remains the separate canonical TAK gateway. Neither is granted arbitrary shell access, raw network interception, or generic adapter control.
sequenceDiagram
participant O as Owner
participant C as Desktop VTOC Client
participant D as Device Firmware
participant B as Typed Bridge
participant X as Remote Integration
O->>C: View device state or request a supported action
C->>D: Use an explicitly declared local transport
D-->>C: Return health, capability, or job state
C->>B: Publish typed, auditable result when enabled
B-->>X: Deliver only the supported result
Every action remains capability-bound. Detecting a cable, nearby device, or network endpoint does not itself grant access. The client must display the target, requested action, and result clearly enough for an owner to understand what occurred.