kami
5fe8f228c1
Add a read-only /ecosystem page that consumes the sibling services' JSON APIs (Nexus entities, Praxis attention, Hexis capabilities), fetched concurrently with honest per-panel error states. Siblings stay headless — mavweb is their human surface (arch §16). Wired via mavweb -nexus/-praxis/-hexis flags; mavweb joins the ecosystem compose network. Fix mobile horizontal overflow across all pages: .content is a flex child with default min-width:auto, so it refused to shrink below the tables' intrinsic width. min-width:0 lets wide tables pan inside .scroll instead of dragging the page sideways. Verified via CDP geometry check (scrollWidth === clientWidth at 430px). Also includes in-progress Ethos UI redesign, ecosystem deploy compose, and planning docs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
28 lines
2.4 KiB
Markdown
28 lines
2.4 KiB
Markdown
# Plan: Bluetooth Control & Network Scanning
|
|
|
|
**Goal:** Maven can scan Bluetooth devices (discover, connect, read characteristics) and scan the local network (discover hosts, open ports, service fingerprints) — exposed as tools in her allowlist for query and automation.
|
|
|
|
**Done when:**
|
|
- `internal/bluetooth/` package wraps `bluez` D-Bus API or `hcitool`/`bluetoothctl` CLI for device discovery, pairing, and RSSI reading
|
|
- `internal/netscan/` package performs ARP scan, TCP port scan, service detection
|
|
- Both are wired as tools (same `ProposeTool`/`EnableTool` flow, status/proposed files in `deploy/mavend.json` or generated at runtime)
|
|
- Results are writable as facts/key-value observations for loop predicates
|
|
- Voice commands: "maven, просканируй bluetooth", "какие устройства в сети?" route through `IntentAct` or `IntentQuery`
|
|
|
|
**Scope:**
|
|
- New `internal/bluetooth/` — BlueZ D-Bus client (`github.com/godbus/dbus/v5` or exec wrappers)
|
|
- New `internal/netscan/` — ARP scanner (`net/http` + arp table read), TCP connect scanner (`net.DialTimeout`), service probe
|
|
- Config: `tools` block extended with auto-generated scan tool entries
|
|
- Reuses `internal/tool.Executor` for running scan commands
|
|
- Reuses `internal/store.WriteFact` for scan results as facts
|
|
|
|
**Steps:**
|
|
1. Create `internal/bluetooth/scanner.go` — `Scan(duration) ([]Device, error)`: calls `bluetoothctl --timeout N scan on`, parses output; or uses D-Bus `org.bluez` API
|
|
2. Create `internal/bluetooth/presence.go` — RSSI-based presence probe: scan for known MAC, write `presence_bt:<name>` fact with RSSI value for the presence pipeline (`internal/store/presence.go`)
|
|
3. Create `internal/netscan/scanner.go` — `ScanLAN() ([]Host, error)`: reads ARP table (`/proc/net/arp`), TCP scans common ports (22, 80, 443, 8080, 9090, 9100) with `net.DialTimeout`
|
|
4. Create `internal/netscan/service.go` — service probes: HTTP GET on port 80/8080, SSH banner grab on 22, ping
|
|
5. Wire scan tools into `ProposeTool` at startup — `bluetooth_scan`, `wifi_scan`, `port_scan`, `network_map`
|
|
6. Presence integration: periodic BT scan writes `presence_bt:<device>` facts; `internal/store/presence.go:PresenceSignals` reads them alongside WiFi probes
|
|
7. Add `bluetooth` and `netscan` config blocks to `config.Config` — `{scan_interval, known_devices, scan_timeout}`
|
|
8. Test with local network — verify host discovery matches `nmap` output; verify BT scan discovers known devices
|