nodmix 2026.5.25

package/docs/nodes/troubleshooting.md

@@ -0,0 +1,123 @@
+---
+summary: "Troubleshoot node pairing, foreground requirements, permissions, and tool failures"
+read_when:
+  - Node is connected but camera/canvas/screen/exec tools fail
+  - You need the node pairing versus approvals mental model
+title: "Node troubleshooting"
+---
+
+Use this page when a node is visible in status but node tools fail.
+
+## Command ladder
+
+```bash
+nodmix status
+nodmix gateway status
+nodmix logs --follow
+nodmix doctor
+nodmix channels status --probe
+```
+
+Then run node specific checks:
+
+```bash
+nodmix nodes status
+nodmix nodes describe --node <idOrNameOrIp>
+nodmix approvals get --node <idOrNameOrIp>
+```
+
+Healthy signals:
+
+- Node is connected and paired for role `node`.
+- `nodes describe` includes the capability you are calling.
+- Exec approvals show expected mode/allowlist.
+
+## Foreground requirements
+
+`canvas.*`, `camera.*`, and `screen.*` are foreground only on iOS/Android nodes.
+
+Quick check and fix:
+
+```bash
+nodmix nodes describe --node <idOrNameOrIp>
+nodmix nodes canvas snapshot --node <idOrNameOrIp>
+nodmix logs --follow
+```
+
+If you see `NODE_BACKGROUND_UNAVAILABLE`, bring the node app to the foreground and retry.
+
+## Permissions matrix
+
+| Capability                   | iOS                                     | Android                                      | macOS node app                | Typical failure code           |
+| ---------------------------- | --------------------------------------- | -------------------------------------------- | ----------------------------- | ------------------------------ |
+| `camera.snap`, `camera.clip` | Camera (+ mic for clip audio)           | Camera (+ mic for clip audio)                | Camera (+ mic for clip audio) | `*_PERMISSION_REQUIRED`        |
+| `screen.record`              | Screen Recording (+ mic optional)       | Screen capture prompt (+ mic optional)       | Screen Recording              | `*_PERMISSION_REQUIRED`        |
+| `location.get`               | While Using or Always (depends on mode) | Foreground/Background location based on mode | Location permission           | `LOCATION_PERMISSION_REQUIRED` |
+| `system.run`                 | n/a (node host path)                    | n/a (node host path)                         | Exec approvals required       | `SYSTEM_RUN_DENIED`            |
+
+## Pairing versus approvals
+
+These are different gates:
+
+1. **Device pairing**: can this node connect to the gateway?
+2. **Gateway node command policy**: is the RPC command ID allowed by `gateway.nodes.allowCommands` / `denyCommands` and platform defaults?
+3. **Exec approvals**: can this node run a specific shell command locally?
+
+Quick checks:
+
+```bash
+nodmix devices list
+nodmix nodes status
+nodmix approvals get --node <idOrNameOrIp>
+nodmix approvals allowlist add --node <idOrNameOrIp> "/usr/bin/uname"
+```
+
+If pairing is missing, approve the node device first.
+If `nodes describe` is missing a command, check the gateway node command policy and whether the node actually declared that command on connect.
+If pairing is fine but `system.run` fails, fix exec approvals/allowlist on that node.
+
+Node pairing is an identity/trust gate, not a per-command approval surface. For `system.run`, the per-node policy lives in that node's exec approvals file (`nodmix approvals get --node ...`), not in the gateway pairing record.
+
+For approval-backed `host=node` runs, the gateway also binds execution to the
+prepared canonical `systemRunPlan`. If a later caller mutates command/cwd or
+session metadata before the approved run is forwarded, the gateway rejects the
+run as an approval mismatch instead of trusting the edited payload.
+
+## Common node error codes
+
+- `NODE_BACKGROUND_UNAVAILABLE` → app is backgrounded; bring it foreground.
+- `CAMERA_DISABLED` → camera toggle disabled in node settings.
+- `*_PERMISSION_REQUIRED` → OS permission missing/denied.
+- `LOCATION_DISABLED` → location mode is off.
+- `LOCATION_PERMISSION_REQUIRED` → requested location mode not granted.
+- `LOCATION_BACKGROUND_UNAVAILABLE` → app is backgrounded but only While Using permission exists.
+- `SYSTEM_RUN_DENIED: approval required` → exec request needs explicit approval.
+- `SYSTEM_RUN_DENIED: allowlist miss` → command blocked by allowlist mode.
+  On Windows node hosts, shell-wrapper forms like `cmd.exe /c ...` are treated as allowlist misses in
+  allowlist mode unless approved via ask flow.
+
+## Fast recovery loop
+
+```bash
+nodmix nodes status
+nodmix nodes describe --node <idOrNameOrIp>
+nodmix approvals get --node <idOrNameOrIp>
+nodmix logs --follow
+```
+
+If still stuck:
+
+- Re-approve device pairing.
+- Re-open node app (foreground).
+- Re-grant OS permissions.
+- Recreate/adjust exec approval policy.
+
+## Related
+
+- [Nodes overview](/nodes)
+- [Camera nodes](/nodes/camera)
+- [Location command](/nodes/location-command)
+- [Exec approvals](/tools/exec-approvals)
+- [Gateway pairing](/gateway/pairing)
+- [Gateway troubleshooting](/gateway/troubleshooting)
+- [Channel troubleshooting](/channels/troubleshooting)

package/docs/nodes/voicewake.md

@@ -0,0 +1,93 @@
+---
+summary: "Global voice wake words (Gateway-owned) and how they sync across nodes"
+read_when:
+  - Changing voice wake words behavior or defaults
+  - Adding new node platforms that need wake word sync
+title: "Voice wake"
+---
+
+Nodmix treats **wake words as a single global list** owned by the **Gateway**.
+
+- There are **no per-node custom wake words**.
+- **Any node/app UI may edit** the list; changes are persisted by the Gateway and broadcast to everyone.
+- macOS and iOS keep local **Voice Wake enabled/disabled** toggles (local UX + permissions differ).
+- Android currently keeps Voice Wake off and uses a manual mic flow in the Voice tab.
+
+## Storage (Gateway host)
+
+Wake words are stored on the gateway machine at:
+
+- `~/.nodmix/settings/voicewake.json`
+
+Shape:
+
+```json
+{ "triggers": ["nodmix", "claude", "computer"], "updatedAtMs": 1730000000000 }
+```
+
+## Protocol
+
+### Methods
+
+- `voicewake.get` → `{ triggers: string[] }`
+- `voicewake.set` with params `{ triggers: string[] }` → `{ triggers: string[] }`
+
+Notes:
+
+- Triggers are normalized (trimmed, empties dropped). Empty lists fall back to defaults.
+- Limits are enforced for safety (count/length caps).
+
+### Routing methods (trigger → target)
+
+- `voicewake.routing.get` → `{ config: VoiceWakeRoutingConfig }`
+- `voicewake.routing.set` with params `{ config: VoiceWakeRoutingConfig }` → `{ config: VoiceWakeRoutingConfig }`
+
+`VoiceWakeRoutingConfig` shape:
+
+```json
+{
+  "version": 1,
+  "defaultTarget": { "mode": "current" },
+  "routes": [{ "trigger": "robot wake", "target": { "sessionKey": "agent:main:main" } }],
+  "updatedAtMs": 1730000000000
+}
+```
+
+Route targets support exactly one of:
+
+- `{ "mode": "current" }`
+- `{ "agentId": "main" }`
+- `{ "sessionKey": "agent:main:main" }`
+
+### Events
+
+- `voicewake.changed` payload `{ triggers: string[] }`
+- `voicewake.routing.changed` payload `{ config: VoiceWakeRoutingConfig }`
+
+Who receives it:
+
+- All WebSocket clients (macOS app, WebChat, etc.)
+- All connected nodes (iOS/Android), and also on node connect as an initial "current state" push.
+
+## Client behavior
+
+### macOS app
+
+- Uses the global list to gate `VoiceWakeRuntime` triggers.
+- Editing "Trigger words" in Voice Wake settings calls `voicewake.set` and then relies on the broadcast to keep other clients in sync.
+
+### iOS node
+
+- Uses the global list for `VoiceWakeManager` trigger detection.
+- Editing Wake Words in Settings calls `voicewake.set` (over the Gateway WS) and also keeps local wake-word detection responsive.
+
+### Android node
+
+- Voice Wake is currently disabled in Android runtime/Settings.
+- Android voice uses manual mic capture in the Voice tab instead of wake-word triggers.
+
+## Related
+
+- [Talk mode](/nodes/talk)
+- [Audio and voice notes](/nodes/audio)
+- [Media understanding](/nodes/media-understanding)

package/docs/perplexity.md

@@ -0,0 +1,11 @@
+---
+summary: "Redirect to /tools/perplexity-search"
+title: "Perplexity search"
+redirect: /tools/perplexity-search
+---
+
+This page has moved to [Perplexity search](/tools/perplexity-search).
+
+## Related
+
+- [Web tools](/tools/web)

package/docs/pi-dev.md

@@ -0,0 +1,82 @@
+---
+summary: "Developer workflow for Pi integration: build, test, and live validation"
+title: "Pi development workflow"
+read_when:
+  - Working on Pi integration code or tests
+  - Running Pi-specific lint, typecheck, and live test flows
+---
+
+A sane workflow for working on the Pi integration in Nodmix.
+
+## Type checking and linting
+
+- Default local gate: `pnpm check`
+- Build gate: `pnpm build` when the change can affect build output, packaging, or lazy-loading/module boundaries
+- Full landing gate for Pi-heavy changes: `pnpm check && pnpm test`
+
+## Running Pi tests
+
+Run the Pi-focused test set directly with Vitest:
+
+```bash
+pnpm test \
+  "src/agents/pi-*.test.ts" \
+  "src/agents/pi-embedded-*.test.ts" \
+  "src/agents/pi-tools*.test.ts" \
+  "src/agents/pi-settings.test.ts" \
+  "src/agents/pi-tool-definition-adapter*.test.ts" \
+  "src/agents/pi-hooks/**/*.test.ts"
+```
+
+To include the live provider exercise:
+
+```bash
+NODMIX_LIVE_TEST=1 pnpm test src/agents/pi-embedded-runner-extraparams.live.test.ts
+```
+
+This covers the main Pi unit suites:
+
+- `src/agents/pi-*.test.ts`
+- `src/agents/pi-embedded-*.test.ts`
+- `src/agents/pi-tools*.test.ts`
+- `src/agents/pi-settings.test.ts`
+- `src/agents/pi-tool-definition-adapter.test.ts`
+- `src/agents/pi-hooks/*.test.ts`
+
+## Manual testing
+
+Recommended flow:
+
+- Run the gateway in dev mode:
+  - `pnpm gateway:dev`
+- Trigger the agent directly:
+  - `pnpm nodmix agent --message "Hello" --thinking low`
+- Use the TUI for interactive debugging:
+  - `pnpm tui`
+
+For tool call behavior, prompt for a `read` or `exec` action so you can see tool streaming and payload handling.
+
+## Clean slate reset
+
+State lives under the Nodmix state directory. Default is `~/.nodmix`. If `NODMIX_STATE_DIR` is set, use that directory instead.
+
+To reset everything:
+
+- `nodmix.json` for config
+- `agents/<agentId>/agent/auth-profiles.json` for model auth profiles (API keys + OAuth)
+- `credentials/` for provider/channel state that still lives outside the auth profile store
+- `agents/<agentId>/sessions/` for agent session history
+- `agents/<agentId>/sessions/sessions.json` for the session index
+- `sessions/` if legacy paths exist
+- `workspace/` if you want a blank workspace
+
+If you only want to reset sessions, delete `agents/<agentId>/sessions/` for that agent. If you want to keep auth, leave `agents/<agentId>/agent/auth-profiles.json` and any provider state under `credentials/` in place.
+
+## References
+
+- [Testing](/help/testing)
+- [Getting Started](/start/getting-started)
+
+## Related
+
+- [Pi integration architecture](/pi)