nodal-agents 0.7.9 → 0.7.95

package/README.md

@@ -2,7 +2,7 @@
 
 > **Your AI agents. Your data. Your machine.**
 
-A self-hosted platform for building and orchestrating a **team of AI agents** on your own hardware — each with its own personality, tools, memory, and model. Talk to them in the dashboard or on Telegram; they research, write files, call your connectors, and delegate to each other to get the job done.
+A self-hosted platform for building and orchestrating a **team of AI agents** on your own hardware — each with its own personality, tools, memory, and model. Talk to them in the dashboard, or on Telegram, Discord, Slack, and WhatsApp; they research, write files, call your connectors, and delegate to each other to get the job done.
 
 **No SaaS lock-in. No per-token markup. No cloud roundtrip.** Two commands to install, runs on any machine with Node 22+ (Mac, Windows, Linux), and works with **any LLM** — frontier or local, paid or free.
 
@@ -70,18 +70,20 @@ Every agent runs on the model **you** choose, with the tools **you** grant, in a
 
 ## Available now
 
-**Models** — Anthropic · OpenAI · Google · Groq · Mistral · OpenRouter · **native DeepSeek** (`api.deepseek.com`) · **native MiniMax** (`api.minimax.io`) · any local model (LM Studio, Ollama). One key per provider; each agent picks its own model.
+**Models** — Anthropic · OpenAI · Google · Groq · Mistral · OpenRouter · **native DeepSeek** (`api.deepseek.com`) · **native MiniMax** (`api.minimax.io`) · **native Moonshot / Kimi** (`api.moonshot.ai`) · any local model (LM Studio, Ollama). One key per provider; each agent picks its own model.
 
 **Connectors** — multi-instance (Gmail perso *and* boulot on one install), managed from the dashboard:
 - *OAuth* — Airtable · Calendar · Docs · Gmail · Google Drive · Notion · Sheets
-- *API key* — Airtable · Apify · Firecrawl · Notion · Tavily
+- *API key* — Airtable · Apify · Firecrawl · Notion · Poyo · Tavily
 
 **MCP servers** — over Streamable HTTP *and* stdio, plus add/edit your own:
 Apify · Blender · Cogni Cortex · Composio · Fetch · Filesystem · Git · GitHub · KeyShot · Linear · n8n · Notion · Perplexity · Photoshop · Playwright · PostgreSQL · Sentry · Stripe · Supabase · Unity · Unreal Engine
 
 **Skills** — built-in: office editing (Excel/Word/PowerPoint), shell execution, Obsidian, Telegram etiquette, task planning, markdown output, citation discipline, research methodology, results delivery, language mirroring, HTML design. Plus **install any community `SKILL.md`** from GitHub / skills.sh / ClawHub — and agents can **write their own**.
 
-**Channels** — Telegram (long-poll, multi-agent routing via `/ask <slug>`, group-chat filters, conversation continuity) and the dashboard chat.
+**Channels** — Telegram (long-poll, multi-agent routing via `/ask <slug>`, group-chat filters, conversation continuity) · Discord (bot gateway) · Slack (Socket Mode) · WhatsApp (QR pairing) — and the dashboard chat. Approvals, images, and files flow over every channel, with graceful fallbacks where a channel lacks buttons.
+
+**Event triggers** — inbound **webhooks** (`POST /webhooks/<slug>/<secret>` starts a job from any external service) and **watchers** (recurring polls with a capped daily budget and overlap protection).
 
 **Other** — shell execution (`run_command`, approval-gated), per-agent sandboxed filesystem folders, cron automations, tool-call audit log, full job transcripts.
 
@@ -172,7 +174,6 @@ Used daily by the maintainer; stable enough for personal production. **Pre-1.0**
 - **MCP OAuth** → unlocks Linear, Notion remote, GitHub remote, Atlassian, Sentry, and the rest of the SaaS-as-MCP ecosystem.
 - **Dry-run + test-workflow meta-tool** → preview what the ROOT would do before it runs.
 - **Bundled pgvector** → semantic memory search out of the box (today: keyword fallback).
-- **More channels** → Discord, Slack, and beyond Telegram.
 
 ---
 

package/cli.js

@@ -12864,6 +12864,17 @@ var init_schedules = __esm({
         // forces the agent to send the user a success confirmation before finishing.
         // Default false → the cron runs silently (the user must opt in per schedule).
         notifyOnSuccess: boolean("notify_on_success").notNull().default(false),
+        // Explicit notify channel choice (B1, notify-channel-choice plan). One of
+        // 'telegram'|'discord'|'slack'|'whatsapp', or NULL = auto (the historical
+        // behavior: first active channel by CHANNEL_PRIORITY — see run-schedules.ts).
+        // Choosing a channel here LINKS chatId resolution to it: the owner
+        // conversation resolved at fire time is the owner's conversation ON THIS
+        // CHANNEL, not whichever channel happened to win priority. 'whatsapp' is
+        // accepted at the DB layer for forward-compat but the UI does not offer it
+        // yet — no outbound send tool exists for whatsapp (TOOL_ONLY_DELIVERY_CHANNELS,
+        // execute.ts), so a whatsapp notify would only ever reach the user through
+        // deliver-results.ts's adapter-direct path, never a mid-run agent send.
+        notifyChannel: text("notify_channel"),
         // Per-schedule daily cost ceiling in USD (Event Triggers, Brique 3). Rolled
         // up against agent_jobs.total_cost_usd for this schedule since the start
         // of its local day — see runScheduleTick (apps/runner/src/cron/run-schedules.ts).
@@ -12879,7 +12890,11 @@ var init_schedules = __esm({
         check("agent_schedules_type_check", sql`${table.type} IN ('cron','heartbeat')`),
         check(
           "agent_schedules_last_status_check",
-          sql`${table.lastStatus} IN ('success','failed','no_action','budget_exhausted') OR ${table.lastStatus} IS NULL`
+          sql`${table.lastStatus} IN ('success','failed','no_action','budget_exhausted','notify_unreachable') OR ${table.lastStatus} IS NULL`
+        ),
+        check(
+          "agent_schedules_notify_channel_check",
+          sql`${table.notifyChannel} IN ('telegram','discord','slack','whatsapp') OR ${table.notifyChannel} IS NULL`
         )
       ]
     );
@@ -13385,6 +13400,7 @@ var init_webhooks = __esm({
   "../../packages/db/src/schema/webhooks.ts"() {
     "use strict";
     init_pg_core();
+    init_drizzle_orm();
     init_entities();
     init_agents();
     webhookTriggers = pgTable(
@@ -13401,10 +13417,30 @@ var init_webhooks = __esm({
         secret: text("secret"),
         lastTriggeredAt: timestamp("last_triggered_at", { withTimezone: true }),
         triggerCount: integer("trigger_count").default(0),
+        // B2 (notify-channel-choice plan): same pair of columns as
+        // agent_schedules (see schedules.ts), same mechanic — the schedules
+        // brique (B1) established the pattern, this just closes the gap the plan
+        // identified: webhooks had no notify at all, not by design, just because
+        // the original webhooks brique scoped delivery to the HTTP caller (202 +
+        // jobId) and never to the owner. Default false → firing stays silent
+        // unless opted in per trigger.
+        notifyOnSuccess: boolean("notify_on_success").notNull().default(false),
+        // Explicit notify channel choice, NULL = auto (first active channel by
+        // CHANNEL_PRIORITY — see routes/webhook.ts). Unlike agent_schedules,
+        // there is no legacy webhook-notify behavior to preserve, so "auto" here
+        // is a plain first-active-channel resolution from the start (no
+        // telegram-only wrapper).
+        notifyChannel: text("notify_channel"),
         createdAt: timestamp("created_at", { withTimezone: true }).defaultNow(),
         updatedAt: timestamp("updated_at", { withTimezone: true }).defaultNow()
       },
-      (table) => [index("idx_webhook_triggers_entity_id").on(table.entityId)]
+      (table) => [
+        index("idx_webhook_triggers_entity_id").on(table.entityId),
+        check(
+          "webhook_triggers_notify_channel_check",
+          sql`${table.notifyChannel} IN ('telegram','discord','slack','whatsapp') OR ${table.notifyChannel} IS NULL`
+        )
+      ]
     );
   }
 });

package/migrations/0066_schedule_notify_channel.sql

@@ -0,0 +1,19 @@
+-- Notify multi-canal pour les automations (B1). Today a schedule's success
+-- confirmation always resolves the OWNER'S TELEGRAM chat (resolveOwnerChatId,
+-- a hardcoded 'telegram' wrapper) and lets delivery-guard/deliver-results pick
+-- whichever channel wins CHANNEL_PRIORITY — an agent bound to telegram+slack
+-- notifies telegram today by priority coincidence, not by design.
+--
+-- notify_channel: explicit choice, NULL = auto (unchanged behavior: first
+-- active channel by priority). Choosing a channel LINKS chatId resolution to
+-- it — see run-schedules.ts's runScheduleTick.
+ALTER TABLE "agent_schedules" ADD COLUMN "notify_channel" text;--> statement-breakpoint
+ALTER TABLE "agent_schedules" ADD CONSTRAINT "agent_schedules_notify_channel_check" CHECK ("notify_channel" IN ('telegram','discord','slack','whatsapp') OR "notify_channel" IS NULL);--> statement-breakpoint
+
+-- 'notify_unreachable' — fail-loud (invariant #4) status for when the chosen
+-- channel has no owner conversation yet (never DMed the bot there): the cron
+-- still fires the job (no silent fallback to another channel), just without
+-- a chatId, and this status surfaces the problem in the UI instead of reading
+-- as an ordinary 'failed'.
+ALTER TABLE "agent_schedules" DROP CONSTRAINT IF EXISTS "agent_schedules_last_status_check";--> statement-breakpoint
+ALTER TABLE "agent_schedules" ADD CONSTRAINT "agent_schedules_last_status_check" CHECK ("last_status" IN ('success','failed','no_action','budget_exhausted','notify_unreachable') OR "last_status" IS NULL);

package/migrations/0067_webhook_notify_channel.sql

@@ -0,0 +1,12 @@
+-- Notify multi-canal pour les webhooks (B2, same plan as 0066's schedule
+-- notify_channel). Webhooks never had a notify option at all — the original
+-- webhooks brique scoped delivery to the HTTP caller (202 + jobId) and never
+-- to the owner. Same pair of columns, same mechanic as agent_schedules.
+--
+-- notify_channel: explicit choice, NULL = auto (first active channel by
+-- priority — no legacy telegram-only behavior to preserve here, unlike
+-- schedules). Choosing a channel LINKS chatId resolution to it — see
+-- routes/webhook.ts.
+ALTER TABLE "webhook_triggers" ADD COLUMN "notify_on_success" boolean NOT NULL DEFAULT false;--> statement-breakpoint
+ALTER TABLE "webhook_triggers" ADD COLUMN "notify_channel" text;--> statement-breakpoint
+ALTER TABLE "webhook_triggers" ADD CONSTRAINT "webhook_triggers_notify_channel_check" CHECK ("notify_channel" IN ('telegram','discord','slack','whatsapp') OR "notify_channel" IS NULL);

package/migrations/meta/_journal.json

@@ -456,6 +456,20 @@
       "when": 1784500000000,
       "tag": "0065_conversations_origin",
       "breakpoints": true
+    },
+    {
+      "idx": 66,
+      "version": "7",
+      "when": 1784600000000,
+      "tag": "0066_schedule_notify_channel",
+      "breakpoints": true
+    },
+    {
+      "idx": 67,
+      "version": "7",
+      "when": 1784700000000,
+      "tag": "0067_webhook_notify_channel",
+      "breakpoints": true
     }
   ]
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nodal-agents",
-  "version": "0.7.9",
+  "version": "0.7.95",
   "description": "Local-first AI agent platform with a web dashboard — install in one command.",
   "license": "MIT",
   "repository": {