nodmix 2026.5.25

package/docs/concepts/agent.md

@@ -0,0 +1,136 @@
+---
+summary: "Agent runtime, workspace contract, and session bootstrap"
+read_when:
+  - Changing agent runtime, workspace bootstrap, or session behavior
+title: "Agent runtime"
+---
+
+Nodmix runs a **single embedded agent runtime** - one agent process per
+Gateway, with its own workspace, bootstrap files, and session store. This page
+covers that runtime contract: what the workspace must contain, which files get
+injected, and how sessions bootstrap against it.
+
+## Workspace (required)
+
+Nodmix uses a single agent workspace directory (`agents.defaults.workspace`) as the agent's **only** working directory (`cwd`) for tools and context.
+
+Recommended: use `nodmix setup` to create `~/.nodmix/nodmix.json` if missing and initialize the workspace files.
+
+Full workspace layout + backup guide: [Agent workspace](/concepts/agent-workspace)
+
+If `agents.defaults.sandbox` is enabled, non-main sessions can override this with
+per-session workspaces under `agents.defaults.sandbox.workspaceRoot` (see
+[Gateway configuration](/gateway/configuration)).
+
+## Bootstrap files (injected)
+
+Inside `agents.defaults.workspace`, Nodmix expects these user-editable files:
+
+- `AGENTS.md` - operating instructions + "memory"
+- `SOUL.md` - persona, boundaries, tone
+- `TOOLS.md` - user-maintained tool notes (e.g. `imsg`, `sag`, conventions)
+- `BOOTSTRAP.md` - one-time first-run ritual (deleted after completion)
+- `IDENTITY.md` - agent name/vibe/emoji
+- `USER.md` - user profile + preferred address
+
+On the first turn of a new session, Nodmix injects the contents of these files into the system prompt's Project Context.
+
+Blank files are skipped. Large files are trimmed and truncated with a marker so prompts stay lean (read the file for full content).
+
+If a file is missing, Nodmix injects a single "missing file" marker line (and `nodmix setup` will create a safe default template).
+
+`BOOTSTRAP.md` is only created for a **brand new workspace** (no other bootstrap files present). While it is pending, Nodmix keeps it in Project Context and adds system-prompt bootstrap guidance for the initial ritual instead of copying it into the user message. If you delete it after completing the ritual, it should not be recreated on later restarts.
+
+To disable bootstrap file creation entirely (for pre-seeded workspaces), set:
+
+```json5
+{ agents: { defaults: { skipBootstrap: true } } }
+```
+
+## Built-in tools
+
+Core tools (read/exec/edit/write and related system tools) are always available,
+subject to tool policy. `apply_patch` is optional and gated by
+`tools.exec.applyPatch`. `TOOLS.md` does **not** control which tools exist; it's
+guidance for how _you_ want them used.
+
+## Skills
+
+Nodmix loads skills from these locations (highest precedence first):
+
+- Workspace: `<workspace>/skills`
+- Project agent skills: `<workspace>/.agents/skills`
+- Personal agent skills: `~/.agents/skills`
+- Managed/local: `~/.nodmix/skills`
+- Bundled (shipped with the install)
+- Extra skill folders: `skills.load.extraDirs`
+
+Skills can be gated by config/env (see `skills` in [Gateway configuration](/gateway/configuration)).
+
+## Runtime boundaries
+
+The embedded agent runtime is built on the Pi agent core (models, tools, and
+prompt pipeline). Session management, discovery, tool wiring, and channel
+delivery are Nodmix-owned layers on top of that core.
+
+## Sessions
+
+Session transcripts are stored as JSONL at:
+
+- `~/.nodmix/agents/<agentId>/sessions/<SessionId>.jsonl`
+
+The session ID is stable and chosen by Nodmix.
+Legacy session folders from other tools are not read.
+
+## Steering while streaming
+
+Inbound prompts that arrive mid-run are steered into the current run by default.
+Steering is delivered **after the current assistant turn finishes executing its
+tool calls**, before the next LLM call, and no longer skips remaining tool calls
+from the current assistant message.
+
+`/queue steer` is the default active-run behavior. `/queue followup` and
+`/queue collect` make messages wait for a later turn instead of steering.
+`/queue interrupt` aborts the active run instead. See [Queue](/concepts/queue)
+and [Steering queue](/concepts/queue-steering) for queue and boundary behavior.
+
+Block streaming sends completed assistant blocks as soon as they finish; it is
+**off by default** (`agents.defaults.blockStreamingDefault: "off"`).
+Tune the boundary via `agents.defaults.blockStreamingBreak` (`text_end` vs `message_end`; defaults to text_end).
+Control soft block chunking with `agents.defaults.blockStreamingChunk` (defaults to
+800-1200 chars; prefers paragraph breaks, then newlines; sentences last).
+Coalesce streamed chunks with `agents.defaults.blockStreamingCoalesce` to reduce
+single-line spam (idle-based merging before send). Non-Telegram channels require
+explicit `*.blockStreaming: true` to enable block replies.
+Verbose tool summaries are emitted at tool start (no debounce); Control UI
+streams tool output via agent events when available.
+More details: [Streaming + chunking](/concepts/streaming).
+
+## Model refs
+
+Model refs in config (for example `agents.defaults.model` and `agents.defaults.models`) are parsed by splitting on the **first** `/`.
+
+- Use `provider/model` when configuring models.
+- If the model ID itself contains `/` (OpenRouter-style), include the provider prefix (example: `openrouter/moonshotai/kimi-k2`).
+- If you omit the provider, Nodmix tries an alias first, then a unique
+  configured-provider match for that exact model id, and only then falls back
+  to the configured default provider. If that provider no longer exposes the
+  configured default model, Nodmix falls back to the first configured
+  provider/model instead of surfacing a stale removed-provider default.
+
+## Configuration (minimal)
+
+At minimum, set:
+
+- `agents.defaults.workspace`
+- `channels.whatsapp.allowFrom` (strongly recommended)
+
+---
+
+_Next: [Group Chats](/channels/group-messages)_ 🦞
+
+## Related
+
+- [Agent workspace](/concepts/agent-workspace)
+- [Multi-agent routing](/concepts/multi-agent)
+- [Session management](/concepts/session)

package/docs/concepts/architecture.md

@@ -0,0 +1,154 @@
+---
+summary: "WebSocket gateway architecture, components, and client flows"
+read_when:
+  - Working on gateway protocol, clients, or transports
+title: "Gateway architecture"
+---
+
+## Overview
+
+- A single long-lived **Gateway** owns all messaging surfaces (WhatsApp via
+  Baileys, Telegram via grammY, Slack, Discord, Signal, iMessage, WebChat).
+- Control-plane clients (macOS app, CLI, web UI, automations) connect to the
+  Gateway over **WebSocket** on the configured bind host (default
+  `127.0.0.1:18789`).
+- **Nodes** (macOS/iOS/Android/headless) also connect over **WebSocket**, but
+  declare `role: node` with explicit caps/commands.
+- One Gateway per host; it is the only place that opens a WhatsApp session.
+- The **canvas host** is served by the Gateway HTTP server under:
+  - `/__nodmix__/canvas/` (agent-editable HTML/CSS/JS)
+  - `/__nodmix__/a2ui/` (A2UI host)
+    It uses the same port as the Gateway (default `18789`).
+
+## Components and flows
+
+### Gateway (daemon)
+
+- Maintains provider connections.
+- Exposes a typed WS API (requests, responses, server-push events).
+- Validates inbound frames against JSON Schema.
+- Emits events like `agent`, `chat`, `presence`, `health`, `heartbeat`, `cron`.
+
+### Clients (mac app / CLI / web admin)
+
+- One WS connection per client.
+- Send requests (`health`, `status`, `send`, `agent`, `system-presence`).
+- Subscribe to events (`tick`, `agent`, `presence`, `shutdown`).
+
+### Nodes (macOS / iOS / Android / headless)
+
+- Connect to the **same WS server** with `role: node`.
+- Provide a device identity in `connect`; pairing is **device-based** (role `node`) and
+  approval lives in the device pairing store.
+- Expose commands like `canvas.*`, `camera.*`, `screen.record`, `location.get`.
+
+Protocol details:
+
+- [Gateway protocol](/gateway/protocol)
+
+### WebChat
+
+- Static UI that uses the Gateway WS API for chat history and sends.
+- In remote setups, connects through the same SSH/Tailscale tunnel as other
+  clients.
+
+## Connection lifecycle (single client)
+
+```mermaid
+sequenceDiagram
+    participant Client
+    participant Gateway
+
+    Client->>Gateway: req:connect
+    Gateway-->>Client: res (ok)
+    Note right of Gateway: or res error + close
+    Note left of Client: payload=hello-ok<br>snapshot: presence + health
+
+    Gateway-->>Client: event:presence
+    Gateway-->>Client: event:tick
+
+    Client->>Gateway: req:agent
+    Gateway-->>Client: res:agent<br>ack {runId, status:"accepted"}
+    Gateway-->>Client: event:agent<br>(streaming)
+    Gateway-->>Client: res:agent<br>final {runId, status, summary}
+```
+
+## Wire protocol (summary)
+
+- Transport: WebSocket, text frames with JSON payloads.
+- First frame **must** be `connect`.
+- After handshake:
+  - Requests: `{type:"req", id, method, params}` → `{type:"res", id, ok, payload|error}`
+  - Events: `{type:"event", event, payload, seq?, stateVersion?}`
+- `hello-ok.features.methods` / `events` are discovery metadata, not a
+  generated dump of every callable helper route.
+- Shared-secret auth uses `connect.params.auth.token` or
+  `connect.params.auth.password`, depending on the configured gateway auth mode.
+- Identity-bearing modes such as Tailscale Serve
+  (`gateway.auth.allowTailscale: true`) or non-loopback
+  `gateway.auth.mode: "trusted-proxy"` satisfy auth from request headers
+  instead of `connect.params.auth.*`.
+- Private-ingress `gateway.auth.mode: "none"` disables shared-secret auth
+  entirely; keep that mode off public/untrusted ingress.
+- Idempotency keys are required for side-effecting methods (`send`, `agent`) to
+  safely retry; the server keeps a short-lived dedupe cache.
+- Nodes must include `role: "node"` plus caps/commands/permissions in `connect`.
+
+## Pairing + local trust
+
+- All WS clients (operators + nodes) include a **device identity** on `connect`.
+- New device IDs require pairing approval; the Gateway issues a **device token**
+  for subsequent connects.
+- Direct local loopback connects can be auto-approved to keep same-host UX
+  smooth.
+- Nodmix also has a narrow backend/container-local self-connect path for
+  trusted shared-secret helper flows.
+- Tailnet and LAN connects, including same-host tailnet binds, still require
+  explicit pairing approval.
+- All connects must sign the `connect.challenge` nonce.
+- Signature payload `v3` also binds `platform` + `deviceFamily`; the gateway
+  pins paired metadata on reconnect and requires repair pairing for metadata
+  changes.
+- **Non-local** connects still require explicit approval.
+- Gateway auth (`gateway.auth.*`) still applies to **all** connections, local or
+  remote.
+
+Details: [Gateway protocol](/gateway/protocol), [Pairing](/channels/pairing),
+[Security](/gateway/security).
+
+## Protocol typing and codegen
+
+- TypeBox schemas define the protocol.
+- JSON Schema is generated from those schemas.
+- Swift models are generated from the JSON Schema.
+
+## Remote access
+
+- Preferred: Tailscale or VPN.
+- Alternative: SSH tunnel
+
+  ```bash
+  ssh -N -L 18789:127.0.0.1:18789 user@host
+  ```
+
+- The same handshake + auth token apply over the tunnel.
+- TLS + optional pinning can be enabled for WS in remote setups.
+
+## Operations snapshot
+
+- Start: `nodmix gateway` (foreground, logs to stdout).
+- Health: `health` over WS (also included in `hello-ok`).
+- Supervision: launchd/systemd for auto-restart.
+
+## Invariants
+
+- Exactly one Gateway controls a single Baileys session per host.
+- Handshake is mandatory; any non-JSON or non-connect first frame is a hard close.
+- Events are not replayed; clients must refresh on gaps.
+
+## Related
+
+- [Agent Loop](/concepts/agent-loop) — detailed agent execution cycle
+- [Gateway Protocol](/gateway/protocol) — WebSocket protocol contract
+- [Queue](/concepts/queue) — command queue and concurrency
+- [Security](/gateway/security) — trust model and hardening

package/docs/concepts/channel-docking.md

@@ -0,0 +1,145 @@
+---
+summary: "Move one Nodmix session's reply route between linked chat channels"
+title: "Channel docking"
+read_when:
+  - You want replies for one active session to move from Telegram to Discord, Slack, Mattermost, or another linked channel
+  - You are configuring session.identityLinks for cross-channel direct messages
+  - A /dock command says the sender is not linked or no active session exists
+---
+
+Channel docking is call forwarding for one Nodmix session.
+
+It keeps the same conversation context, but changes where future replies for
+that session are delivered.
+
+## Example
+
+Alice can message Nodmix on Telegram and Discord:
+
+```json5
+{
+  session: {
+    identityLinks: {
+      alice: ["telegram:123", "discord:456"],
+    },
+  },
+}
+```
+
+If Alice sends this from Telegram:
+
+```text
+/dock_discord
+```
+
+Nodmix keeps the current session context and changes the reply route:
+
+| Before docking               | After `/dock_discord`       |
+| ---------------------------- | --------------------------- |
+| Replies go to Telegram `123` | Replies go to Discord `456` |
+
+The session is not recreated. The transcript history stays attached to the
+same session.
+
+## Why use it
+
+Use docking when a task starts in one chat app but the next replies should land
+somewhere else.
+
+Common flow:
+
+1. Start an agent task from Telegram.
+2. Move to Discord where you are coordinating work.
+3. Send `/dock_discord` from the Telegram session.
+4. Keep the same Nodmix session, but receive future replies in Discord.
+
+## Required config
+
+Docking requires `session.identityLinks`. The source sender and target peer
+must be in the same identity group:
+
+```json5
+{
+  session: {
+    identityLinks: {
+      alice: ["telegram:123", "discord:456", "slack:U123"],
+    },
+  },
+}
+```
+
+The values are channel-prefixed peer ids:
+
+| Value          | Meaning                      |
+| -------------- | ---------------------------- |
+| `telegram:123` | Telegram sender id `123`     |
+| `discord:456`  | Discord direct peer id `456` |
+| `slack:U123`   | Slack user id `U123`         |
+
+The canonical key (`alice` above) is only the shared identity group name. Dock
+commands use the channel-prefixed values to prove that the source sender and
+target peer are the same person.
+
+## Commands
+
+Dock commands are generated from loaded channel plugins that support native
+commands. Current bundled commands:
+
+| Target channel | Command            | Alias              |
+| -------------- | ------------------ | ------------------ |
+| Discord        | `/dock-discord`    | `/dock_discord`    |
+| Mattermost     | `/dock-mattermost` | `/dock_mattermost` |
+| Slack          | `/dock-slack`      | `/dock_slack`      |
+| Telegram       | `/dock-telegram`   | `/dock_telegram`   |
+
+The underscore aliases are useful on native command surfaces such as Telegram.
+
+## What changes
+
+Docking updates the active session delivery fields:
+
+| Session field   | Example after `/dock_discord`            |
+| --------------- | ---------------------------------------- |
+| `lastChannel`   | `discord`                                |
+| `lastTo`        | `456`                                    |
+| `lastAccountId` | the target channel account, or `default` |
+
+Those fields are persisted in the session store and used by later reply
+delivery for that session.
+
+## What does not change
+
+Docking does not:
+
+- create channel accounts
+- connect a new Discord, Telegram, Slack, or Mattermost bot
+- grant access to a user
+- bypass channel allowlists or DM policies
+- move transcript history to another session
+- make unrelated users share a session
+
+It only changes the delivery route for the current session.
+
+## Troubleshooting
+
+**The command says the sender is not linked.**
+
+Add both the current sender and the target peer to the same
+`session.identityLinks` group. For example, if Telegram sender `123` should dock
+to Discord peer `456`, include both `telegram:123` and `discord:456`.
+
+**The command says no active session exists.**
+
+Dock from an existing direct-chat session. The command needs an active session
+entry so it can persist the new route.
+
+**Replies still go to the old channel.**
+
+Check that the command replied with a success message, and confirm the target
+peer id matches the id used by that channel. Docking only changes the active
+session route; another session may still route elsewhere.
+
+**I need to switch back.**
+
+Send the matching command for the original channel, such as `/dock_telegram` or
+`/dock-telegram`, from a linked sender.

package/docs/concepts/commitments.md

@@ -0,0 +1,150 @@
+---
+summary: "Inferred follow-up memory for check-ins that are not exact reminders"
+title: "Inferred commitments"
+sidebarTitle: "Commitments"
+read_when:
+  - You want Nodmix to remember natural follow-ups
+  - You want to understand how inferred check-ins differ from reminders
+  - You want to review or dismiss follow-up commitments
+---
+
+Commitments are short-lived follow-up memories. When enabled, Nodmix can
+notice that a conversation created a future check-in opportunity and remember
+to bring it back later.
+
+Examples:
+
+- You mention an interview tomorrow. Nodmix may check in afterward.
+- You say you are exhausted. Nodmix may ask later whether you slept.
+- The agent says it will follow up after something changes. Nodmix may track
+  that open loop.
+
+Commitments are not durable facts like `MEMORY.md`, and they are not exact
+reminders. They sit between memory and automation: Nodmix remembers a
+conversation-bound obligation, then heartbeat delivers it when it is due.
+
+## Enable commitments
+
+Commitments are off by default. Enable them in config:
+
+```bash
+nodmix config set commitments.enabled true
+nodmix config set commitments.maxPerDay 3
+```
+
+Equivalent `nodmix.json`:
+
+```json
+{
+  "commitments": {
+    "enabled": true,
+    "maxPerDay": 3
+  }
+}
+```
+
+`commitments.maxPerDay` limits how many inferred follow-ups can be delivered
+per agent session in a rolling day. The default is `3`.
+
+## How it works
+
+After an agent reply, Nodmix may run a hidden background extraction pass in a
+separate context. That pass looks only for inferred follow-up commitments. It
+does not write into the visible conversation and it does not ask the main agent
+to reason about the extraction.
+
+When it finds a high-confidence candidate, Nodmix stores a commitment with:
+
+- the agent id
+- the session key
+- the original channel and delivery target
+- a due window
+- a short suggested check-in
+- non-instructional metadata for heartbeat to decide whether to send it
+
+Delivery happens through heartbeat. When a commitment becomes due, heartbeat
+adds the commitment to the heartbeat turn for the same agent and channel scope.
+The model can send one natural check-in or reply `HEARTBEAT_OK` to dismiss it.
+If heartbeat is configured with `target: "none"`, due commitments remain
+internal and do not send external check-ins. Commitment delivery prompts do not
+replay the original conversation text, and due commitment heartbeat turns run
+without Nodmix tools.
+
+Nodmix never delivers an inferred commitment immediately after writing it.
+The due time is clamped to at least one heartbeat interval after the commitment
+is created, so the follow-up cannot echo back in the same moment it was
+inferred.
+
+## Scope
+
+Commitments are scoped to the exact agent and channel context where they were
+created. A follow-up inferred while talking to one agent in Discord is not
+delivered by another agent, another channel, or an unrelated session.
+
+This scope is part of the feature. Natural check-ins should feel like the same
+conversation continuing, not like a global reminder system.
+
+## Commitments vs reminders
+
+| Need                                            | Use                                      |
+| ----------------------------------------------- | ---------------------------------------- |
+| "Remind me at 3 PM"                             | [Scheduled tasks](/automation/cron-jobs) |
+| "Ping me in 20 minutes"                         | [Scheduled tasks](/automation/cron-jobs) |
+| "Run this report every weekday"                 | [Scheduled tasks](/automation/cron-jobs) |
+| "I have an interview tomorrow"                  | Commitments                              |
+| "I was up all night"                            | Commitments                              |
+| "Follow up if I do not answer this open thread" | Commitments                              |
+
+Exact user requests already belong to the scheduler path. Commitments are only
+for inferred follow-ups: the moments where the user did not ask for a reminder,
+but the conversation clearly created a useful future check-in.
+
+## Manage commitments
+
+Use the CLI to inspect and clear stored commitments:
+
+```bash
+nodmix commitments
+nodmix commitments --all
+nodmix commitments --agent main
+nodmix commitments --status snoozed
+nodmix commitments dismiss cm_abc123
+```
+
+See [`nodmix commitments`](/cli/commitments) for the command reference.
+
+## Privacy and cost
+
+Commitment extraction uses an LLM pass, so enabling it adds background model
+usage after eligible turns. The pass is hidden from the user-visible
+conversation, but it can read the recent exchange needed to decide whether a
+follow-up exists.
+
+Stored commitments are local Nodmix state. They are operational memory, not
+long-term memory. Disable the feature with:
+
+```bash
+nodmix config set commitments.enabled false
+```
+
+## Troubleshooting
+
+If expected follow-ups are not appearing:
+
+- Confirm `commitments.enabled` is `true`.
+- Check `nodmix commitments --all` for pending, dismissed, snoozed, or expired
+  records.
+- Make sure heartbeat is running for the agent.
+- Check whether `commitments.maxPerDay` has already been reached for that
+  agent session.
+- Remember that exact reminders are skipped by commitment extraction and should
+  appear under [scheduled tasks](/automation/cron-jobs) instead.
+
+## Related
+
+- [Memory overview](/concepts/memory)
+- [Active memory](/concepts/active-memory)
+- [Heartbeat](/gateway/heartbeat)
+- [Scheduled tasks](/automation/cron-jobs)
+- [`nodmix commitments`](/cli/commitments)
+- [Configuration reference](/gateway/configuration-reference#commitments)