feat(uno-q): ship the arduino-uno-q expert skill on every node by default

Vendors the comprehensive UNO Q skill (SKILL.md + 7 references/*.md) and installs it into EVERY agent's workspace on each board, so agents know this board's specifics (dual-brain arch, Bridge/RPC, pin tables, LED matrix + the ArduinoGraphics-not-installed gotcha) instead of guessing generic Arduino. Why per-agent workspace: ZeroClaw's read_skill returns only SKILL.md; the agent reads references/*.md via the workspace-sandboxed file_read tool, so references are only reachable under ~/.zeroclaw/agents/<alias>/workspace/skills/. A shared/skills bundle surfaces the skill but its references get sandbox-blocked. - push-skill.sh installs a SKILL.md+references skill into every agent workspace (discovers aliases from the board); provision-fleet runs it per board. - config.template risk profile now allows + auto-approves read_skill + file_read so agents load skills without a human approver (webhook path is non-interactive). - Flattened the folded 'description: >-' to single-line (ZeroClaw's frontmatter parser is a flat scanner, not full YAML). Verified on board 65301572 with cloud/Sonnet-5: discovered arduino-uno-q → read_skill(SKILL.md) → file_read references/04-bridge-rpc.md → correct board-specific answer citing the file. Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-07-16 09:14:00 -07:00
parent 7233a4b1c0
commit d2135a1938
12 changed files with 877 additions and 2 deletions
@@ -0,0 +1,89 @@
+# UNO Q — Wireless (Wi-Fi & Bluetooth)
+
+The **WCBN3536A** module gives dual-band **Wi-Fi 5 (2.4/5 GHz)** and **Bluetooth 5.1**, with onboard antennas. The radio is owned by the **Linux/MPU side**, so networking is configured in Debian (via `nmcli` or the desktop). The MCU reaches the network **through the Bridge**, not directly.
+
+## Wi-Fi from Linux (the normal way)
+Use the network icon in the top-right of the desktop, or NetworkManager on the CLI (great over SSH):
+```bash
+sudo nmcli d wifi connect <SSID> password <YOUR_PASSWORD>   # connect
+sudo nmcli d disconnect wlan0                               # disconnect
+sudo nmcli connection delete <SSID>                         # forget a network
+nmcli d wifi list                                           # scan (handy)
+```
+
+## WPA2-Enterprise (university / corporate, e.g. eduroam)
+NetworkManager handles 802.1X. **eduroam (PEAP/MSCHAPv2):**
+```bash
+nmcli con add \
+  type wifi \
+  connection.id Eduroam \
+  wifi.ssid eduroam \
+  wifi.mode infrastructure \
+  wifi-sec.key-mgmt wpa-eap \
+  802-1x.eap peap \
+  802-1x.phase2-auth mschapv2 \
+  802-1x.identity <your identity>
+```
+**TTLS + PAP variant:**
+```bash
+nmcli con add \
+  type wifi \
+  connection.id ExampleNetwork \
+  wifi.ssid <your Wi-Fi SSID> \
+  wifi.mode infrastructure \
+  wifi-sec.key-mgmt wpa-eap \
+  802-1x.eap ttls \
+  802-1x.phase2-auth pap \
+  802-1x.domain-suffix-match example.com \
+  802-1x.identity <your identity>
+```
+Bring a connection up and be prompted for the password interactively:
+```bash
+nmcli --ask con up <your network name>
+```
+This matters for workshops on campus/enterprise networks where a plain SSID+password won't work.
+
+## Reaching the network from the MCU (via the Bridge)
+The sketch doesn't have its own IP stack for Wi-Fi; it borrows the Linux side's connectivity through the Bridge. App Lab provides bridged network client classes, e.g. a TCP client:
+```cpp
+BridgeTCPClient<> client(Bridge);
+
+void setup() {
+  if (!Bridge.begin()) { while (true) {} }
+  Serial.begin(9600);
+}
+
+void loop() {
+  if (client.connect("time.nist.gov", 13) < 0) {  // Daytime protocol
+    Serial.println("Connection failed!");
+    delay(5000); return;
+  }
+  String line;
+  while (client.connected() || client.available()) {
+    if (client.available()) {
+      char c = client.read();
+      if (c == '\n') break;
+      if (c != '\r') line += c;
+    }
+  }
+  Serial.print("Server says: "); Serial.println(line);
+  client.stop();
+  delay(10000);
+}
+```
+Takeaway: get the board online **on the Linux side first**, then the MCU can make network calls over the Bridge.
+
+## Bluetooth (Linux side)
+Manage from the top-right Bluetooth icon in SBC mode, or via CLI:
+```bash
+bluetoothctl power on
+bluetoothctl power off
+```
+Inside the `bluetoothctl` prompt:
+```
+power on
+scan on                 # discover devices
+scan off
+connect <MAC_ADDRESS>   # pair/connect
+```
+Use it to link phones, computers, or BT sensors to the board.