Named for the thread, its messenger, and the script between them:

• A real KVM for the rack. Drop a Duta on a server/switch/PDU console port and reach it remotely over WiFi (mDNS-discovered) or Bluetooth. Out-of-band serial access, no OpenGear/Avocent appliance and no laptop-plus-USB-dongle.
• Turn an MCU into a Wireshark capture board. Port a Duta build to your own radio/bus hardware and it becomes a live, named Wireshark interface (BLE, 802.15.4/Zigbee/Thread, I²C, serial), dissected in real time. No proprietary sniffer app.
• Automate arduous hardware testing. Expect-style macros, a run queue, pcap capture, and an LLM over MCP to run the tedious bring-up and QA loops unattended.
• Replace sketchy manufacturer apps. Describe a board's panel once as a declarative, Lua-scriptable control surface instead of installing a vendor's one-off configurator.
• …or just a modern serial console. Point it at any plain COM port. No Duta required.

• It bridges a host to a target bus in both directions, and adds a separate control channel for I/O: digital lines, analog in, PWM, and addressable RGB. The bridged medium is pluggable, so UART/TTL works today and CAN comes next.
• Reach the device however you want: USB-CDC (two channels, or a single muxed port), BLE GATT, or WebSocket. The same skrit runs on each. The networked transports are password-gated, so the bridge isn't an open shell on your LAN.
• Devices report their own I/O by behavior, so the app renders the right control for each (a toggle, a slider, a color picker) with no per-board UI to maintain. Add a pin to a board's table and it shows up.
• On capable boards you don't even recompile: the device publishes which pins can do what (strapping and shared pins flagged), and a Configure device screen re-pins relays/PWM/names from the app: validated on-device, persisted, applied on reboot.

• Write expect-style scripts (STRING, WAITFOR, IF, SET, $call...). Sutra runs them, queues them, and cancels them mid-flight. In the editor, #RRGGBB tokens get inline color swatches.
• Those macros also run on the device. They compile to skrit-mc bytecode for a tiny on-device VM, and each one carries a tier (replay, interactive, or app-only) that says where it can run, down to a $2 CH552.
• An LLM can work the bus through a built-in MCP server: read the stream, flip outputs, set a color, pulse a reset line, run macros by name. Secret macros stay redacted, so the model never sees them.

• Devices report their transport and capabilities too, so the app configures itself from what each one reports: USB, BLE, or network, relays or RGB.
• Where it's headed: typed streams (I²C, CAN, BLE sniffing, logic capture) that record as pcapng and appear as live interfaces in Wireshark (extcap). Dissect there, then bring the knowledge back as Sutra decoders so macros and replays speak the protocol. Wireshark is where you understand a bus; Sutra is where you interact with it.

flowchart LR
    You([🧑‍💻 You]) -- clicks --> Sutra
    LLM([🤖 LLM]) -- MCP --> Sutra
    Sutra["🧵 Sutra<br/>desktop · MCP"] <== "skrit · CMD: control + macros<br/>USB-CDC · BLE GATT · WebSocket" ==> Duta
    Sutra <-- "DATA: the bridged bus" --> Duta["📡 Duta<br/>firmware · macro VM"]
    Duta -- "UART/TTL · CAN · …" --> Target([target bus])
    Duta -.-> Fleet["CH552 · ESP32-S3<br/>RP2040 · nRF52840"]

    style Fleet fill:none,stroke-dasharray:4
    style Sutra fill:#1e293b,color:#fff,stroke:#475569
    style Duta fill:#1e293b,color:#fff,stroke:#475569

• Use it: install Sutra and connect over USB, BLE, or WebSocket. Any serial adapter works as a plain bridge; a Duta adds the control channel and I/O.
• Build it: flash Duta to a supported MCU.
• Port it: the skrit spec is one header plus PROTOCOL.md. Bring your own transport.

Everything here is GPL-3.0. Contributions are welcome; open an issue or PR on the relevant repo.