alvin-bot 5.6.0 → 5.6.1

package/CHANGELOG.md

@@ -2,6 +2,20 @@
 
 All notable changes to Alvin Bot are documented here.
 
+## [5.6.1] — 2026-05-18
+
+### Background-task results stay in the chat
+
+Results from scheduled and background tasks now appear directly in
+the chat as before. Only an output long enough to span more than two
+messages comes as a single attached file instead — keeping your chat
+tidy without ever splitting a result across a wall of messages. No
+"shortened" notices on normal-sized results; you stay in control of
+when something gets saved as a file.
+
+As always, verified with a fresh-install + stress test on a clean
+separate machine.
+
 ## [5.6.0] — 2026-05-18
 
 ### Background-task reports are now clean and to the point

package/dist/paths.js

@@ -19,8 +19,13 @@ export const DATA_DIR = resolve(process.env.ALVIN_DATA_DIR || resolve(os.homedir
 export const PUBLIC_DIR = resolve(BOT_ROOT, "web", "public");
 /** plugins/ — Plugin directory */
 export const PLUGINS_DIR = resolve(BOT_ROOT, "plugins");
-/** skills/ — Skill definitions */
-export const SKILLS_DIR = resolve(BOT_ROOT, "skills");
+/** skills/ — Skill definitions.
+ *  Defaults to BOT_ROOT/skills (repo). Override with ALVIN_SKILLS_DIR so
+ *  tests can redirect skill writes into a throwaway sandbox instead of
+ *  polluting the real repo. Default (no env) is byte-identical to before. */
+export const SKILLS_DIR = process.env.ALVIN_SKILLS_DIR
+    ? resolve(process.env.ALVIN_SKILLS_DIR)
+    : resolve(BOT_ROOT, "skills");
 /** User skills directory (custom, outside repo) */
 export const USER_SKILLS_DIR = resolve(DATA_DIR, "skills");
 /** Example/template files (always in repo) */

package/dist/services/subagent-delivery.js

@@ -56,52 +56,39 @@ async function sendWithMarkdownFallback(api, chatId, text) {
     }
 }
 const MAX_TG_CHUNK = 3800; // below Telegram's 4096 limit with headroom
-// V56-T2 honesty fix — the .md file attachment is no longer gated on a
-// separate 20k threshold. It now triggers whenever the cap actually
-// truncates (isTruncated → body.length > BODY_CAP), so every truncated
-// delivery carries the full output as a file and the marker is honest.
-// (The prior 20k-only behavior is fully subsumed by isTruncated.)
 /**
- * V56-T2 (Layer-2) — honest hard cap on the INLINE delivered body.
+ * Post-v5.6.0 delivery routing — by message count, NOT by a truncating
+ * cap.
  *
- * V56-T1 made delivery carry the SDK final result instead of the whole
- * transcript, but a final result can itself occasionally be very long.
- * This bounds the inline-message body so a single agent answer can't
- * flood the chat, while staying HONEST.
+ * v5.6.0 introduced an inline body cap (1800 chars + a
+ * "…(truncated for chat — full output attached)" marker) that ALWAYS
+ * attached the full body as a `.md` file whenever it truncated. The
+ * effect was that even a small ~4 KB result got truncated + filed,
+ * which the user disliked. That cap is removed entirely.
  *
- * Honesty contract (fixed after a review found a self-defeating
- * regression): whenever `capBody` actually truncates — i.e. the body is
- * non-empty AND longer than BODY_CAP — the delivery ALSO attaches the
- * COMPLETE uncapped output as a `.md` file via the same upload
- * mechanism the old >20000-char path already used. The marker
- * therefore truthfully says the full output is *attached*, instead of
- * the previous wording that pointed at a `~/.alvin-bot/logs/` file the
- * cap path never actually wrote. Net effect: any truncated delivery =
- * bounded inline message + full `.md` attachment; no lossy inline-only
- * range remains. The old >20000 path is unchanged (it already attached
- * the full body); this just extends "attach the full file" down to
- * "whenever the cap truncated".
+ * V56-T1 ("deliver the final result, not the transcript") is kept — a
+ * normal final result is usually short and now simply appears inline
+ * like it did before v5.6.0.
  *
- * This is a pure bounded slice + a fixed marker — NOT a structure-
- * guessing heuristic. It no-ops on empty/whitespace so the
- * `(empty output)` truncated-run signal keeps working (and no spurious
- * file is attached for it).
- */
-const BODY_CAP = 1800;
-const TRUNCATION_MARKER = "…(truncated for chat — full output attached)";
-/**
- * True when `capBody` would actually truncate this body — the single
- * source of truth for "did we drop content, so the full output must be
- * attached as a file". Mirrors the `length > BODY_CAP` test in capBody.
+ * The body is routed by how many Telegram messages it would need
+ * (MAX_TG_CHUNK = 3800):
+ *   - body ≤ 1×MAX_TG_CHUNK            → ONE inline message
+ *   - 1×MAX_TG_CHUNK < body ≤ 2×       → inline across exactly 2
+ *                                         messages (no marker, no file)
+ *   - body > 2×MAX_TG_CHUNK (≥3 chunks)→ do NOT spam 3+ messages: send
+ *                                         the compact header + ONE
+ *                                         short neutral note + the FULL
+ *                                         (uncapped, complete) body as a
+ *                                         `.md` file attachment
+ *
+ * The `(empty output)` truncated-run signal (~14 chars) is tier-1, so
+ * it stays a single inline message with no note and no file.
+ *
+ * The file in the ≥3-chunk case is the COMPLETE body — nothing is cut,
+ * so the note must NOT say "truncated". It is a minimal neutral line.
  */
-function isTruncated(body) {
-    return body.length > BODY_CAP;
-}
-function capBody(body) {
-    if (body.length <= BODY_CAP)
-        return body;
-    return `${body.slice(0, BODY_CAP)}\n\n${TRUNCATION_MARKER}`;
-}
+const FILE_THRESHOLD = MAX_TG_CHUNK * 2; // > this ⇒ would need ≥3 messages
+const FULL_RESULT_NOTE = "📎 Full result attached (too long for chat).";
 let injectedApi = null;
 let runtimeApi = null;
 /** Test-only hook for injecting a fake bot API. Production code must NEVER call this. */
@@ -346,56 +333,40 @@ export async function deliverSubAgentResult(info, result, opts = {}) {
     }
     const banner = buildBanner(info, result);
     const body = result.output?.trim() || `(empty output)`;
-    // V56-T2 — bounded variant for the INLINE message path. Whenever this
-    // actually truncates (isTruncated), the FULL uncapped `body` is also
-    // attached as a .md file below, so the cap never costs the user
-    // access to the complete result and the marker stays truthful.
-    const inlineBody = capBody(body);
     try {
-        // Truncated → honest delivery: short banner + bounded inline body
-        // (with the truthful "full output attached" marker) + the COMPLETE
-        // uncapped body as a .md file. This single branch covers the whole
-        // truncated range (mid-size AND the old > 20000-char range): there
-        // is no lossy inline-only range anymore. (The old >20000 behavior
-        // is unchanged — it already attached the full body; the change is
-        // that mid-size now also attaches it and the marker no longer
-        // points at a logs file that was never written.)
-        if (isTruncated(body)) {
+        // Tier 3: body would need ≥3 Telegram messages → don't spam the
+        // chat. Send the compact header + ONE short neutral note + the FULL
+        // (uncapped, COMPLETE) body as a single `.md` file. Nothing is cut,
+        // so the note says nothing about truncation.
+        if (body.length > FILE_THRESHOLD) {
             await sendWithMarkdownFallback(api, tgChatId, banner);
-            // The bounded inline body fits in one message (BODY_CAP=1800 plus
-            // the short marker is well under MAX_TG_CHUNK); send it as plain
-            // text so an unbalanced markdown slice can't crash the send.
-            await api.sendMessage(tgChatId, inlineBody.slice(0, MAX_TG_CHUNK));
+            await api.sendMessage(tgChatId, FULL_RESULT_NOTE);
             try {
                 const { InputFile } = await import("grammy");
                 const buf = Buffer.from(body, "utf-8");
                 await api.sendDocument(tgChatId, new InputFile(buf, `${info.name}.md`));
             }
             catch (err) {
-                // Upload failed → the bounded inline body was already delivered
-                // above, so the user still has something honest (banner + capped
-                // text + marker). The marker slightly over-promises here (file
-                // didn't attach) but this is the rare failure path, not the
-                // normal one, and there is no silent data loss.
+                // Upload failed → the user still has the banner + the note, so
+                // they know a result exists and is large. Rare failure path,
+                // no silent data loss (nothing was promised inline).
                 console.error(`[subagent-delivery] file upload failed:`, err);
             }
             return OK;
         }
-        // Not truncated (body ≤ BODY_CAP) → unchanged passthrough.
-        // inlineBody === body here (capBody is a no-op), no marker, no file.
-        // Case A: fits in a single message → banner + body joined
-        if (inlineBody.length + banner.length + 2 <= MAX_TG_CHUNK) {
-            await sendWithMarkdownFallback(api, tgChatId, `${banner}\n\n${inlineBody}`);
+        // Tier 1: body fits with the banner in a single message → join.
+        if (body.length + banner.length + 2 <= MAX_TG_CHUNK) {
+            await sendWithMarkdownFallback(api, tgChatId, `${banner}\n\n${body}`);
             return OK;
         }
-        // Case B: defensive — a ≤1800-char body still under-runs MAX_TG_CHUNK
-        // with the banner, but keep the banner-then-chunk fallback for
-        // safety against an unusually long banner.
+        // Tier 1/2: body alone needs 1 or 2 messages (≤ 2×MAX_TG_CHUNK).
+        // Send the banner, then the body chunked across at most 2 messages.
+        // No marker, no file — this is the pre-v5.6.0 inline behavior.
         await sendWithMarkdownFallback(api, tgChatId, banner);
-        for (let i = 0; i < inlineBody.length; i += MAX_TG_CHUNK) {
+        for (let i = 0; i < body.length; i += MAX_TG_CHUNK) {
             // Body chunks are always sent as plain text — markdown across
             // arbitrary chunk boundaries would be inconsistent anyway.
-            await api.sendMessage(tgChatId, inlineBody.slice(i, i + MAX_TG_CHUNK));
+            await api.sendMessage(tgChatId, body.slice(i, i + MAX_TG_CHUNK));
         }
         return OK;
     }
@@ -428,25 +399,16 @@ async function deliverViaRegistry(platform, info, result) {
     const chatId = info.parentChatId;
     const banner = buildBannerPlain(info, result);
     const body = result.output?.trim() || `(empty output)`;
-    // V56-T2 — same honest contract as the Telegram path. Whenever the
-    // cap truncates, the FULL uncapped `body` is attached as a .md file
-    // (if the adapter supports uploads) so the marker stays truthful and
-    // the complete output remains accessible.
-    const inlineBody = capBody(body);
-    const NON_TG_CHUNK = 3800;
+    const NON_TG_CHUNK = MAX_TG_CHUNK; // same conservative 3800 cap
     try {
-        // Truncated → honest delivery: banner + bounded inline body (with
-        // the truthful "full output attached" marker) + the COMPLETE
-        // uncapped body as a .md file. Covers the whole truncated range
-        // (mid-size AND > the old 20k threshold) — no lossy inline-only
-        // range remains. If the adapter has no sendDocument or the upload
-        // fails, the bounded inline body still went out (honest, just no
-        // file) — no silent data loss.
-        if (isTruncated(body)) {
+        // Tier 3: body would need ≥3 messages → don't spam the channel.
+        // Send the banner + ONE short neutral note + the FULL (uncapped,
+        // COMPLETE) body as a `.md` file (if the adapter supports uploads).
+        // Mirrors the Telegram path exactly. No truncation — the file is
+        // the complete result.
+        if (body.length > FILE_THRESHOLD) {
             await adapter.sendText(chatId, banner);
-            for (let i = 0; i < inlineBody.length; i += NON_TG_CHUNK) {
-                await adapter.sendText(chatId, inlineBody.slice(i, i + NON_TG_CHUNK));
-            }
+            await adapter.sendText(chatId, FULL_RESULT_NOTE);
             if (adapter.sendDocument) {
                 try {
                     await adapter.sendDocument(chatId, Buffer.from(body, "utf-8"), `${info.name}.md`);
@@ -457,16 +419,16 @@ async function deliverViaRegistry(platform, info, result) {
             }
             return;
         }
-        // Not truncated (body ≤ BODY_CAP) → unchanged passthrough.
-        // inlineBody === body here, no marker, no file.
-        if (inlineBody.length + banner.length + 2 <= NON_TG_CHUNK) {
-            await adapter.sendText(chatId, `${banner}\n\n${inlineBody}`);
+        // Tier 1: body + banner fit in one message → join.
+        if (body.length + banner.length + 2 <= NON_TG_CHUNK) {
+            await adapter.sendText(chatId, `${banner}\n\n${body}`);
             return;
         }
-        // Defensive banner-then-chunk fallback (e.g. unusually long banner).
+        // Tier 1/2: banner, then body chunked across at most 2 messages.
+        // No marker, no file.
         await adapter.sendText(chatId, banner);
-        for (let i = 0; i < inlineBody.length; i += NON_TG_CHUNK) {
-            await adapter.sendText(chatId, inlineBody.slice(i, i + NON_TG_CHUNK));
+        for (let i = 0; i < body.length; i += NON_TG_CHUNK) {
+            await adapter.sendText(chatId, body.slice(i, i + NON_TG_CHUNK));
         }
     }
     catch (err) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "alvin-bot",
-  "version": "5.6.0",
+  "version": "5.6.1",
   "description": "Alvin Bot — Your personal AI agent on Telegram, WhatsApp, Discord, Signal, and Web.",
   "type": "module",
   "main": "dist/index.js",