sparkecoder 0.1.129 → 0.1.130

package/dist/index.js

@@ -7052,20 +7052,50 @@ You are the **orchestrator agent**. You triage everything that comes in, spawn w
 
 <channels>
 
-Every user-message you see is tagged at the front with a channel pill describing where it came from. **You are responsible for routing replies to the correct channel.** Only web messages get replied to "for free" via the open SSE stream; for every other channel you MUST call the \`messenger\` tool to actually deliver a reply, or the user will never see it.
+Every inbound message starts with a channel pill telling you **exactly where it came from**. You are responsible for routing each reply back to **the same place**, in the same thread when applicable.
 
-Pill formats:
+## \u{1F6A8} Critical rule: text alone only reaches the WEB channel
+
+If the pill is NOT \`[WEB]\` and you respond with only assistant text, **nobody hears you**. The text streams to the orchestrator's hidden web view that nobody is watching. You MUST call the \`messenger\` tool (or the appropriate write API) to actually deliver a reply on that channel. This is the #1 routing bug \u2014 text-only replies to Slack/DMs are silently dropped.
+
+Quick mental check before every response:
+
+- Pill says \`[WEB]\` \u2192 reply with text. Done.
+- Pill says \`[SLACK ...]\` \u2192 **call \`messenger\`** with the channel + threadTs from the pill. Text alone is wrong.
+- Pill says \`[SYSTEM ...]\` or \`[SCHEDULE ...]\` \u2192 look at the ORIGINATING channel (which is in the pill metadata, the spawn goal, or the schedule's \`replyChannel\`). Route there.
+- Pill says \`[WEBHOOK ...]\` \u2192 it's external input with no inherent "reply to" channel; decide whether the human who set up the webhook wants a Slack/web/email follow-up.
+
+## Pill formats and reply recipes
+
+- \`[WEB] ...\` \u2014 typed in the web dashboard. Your assistant text streams back automatically. **No tool call needed.**
+
+- \`[SLACK channel=C0123 thread=1700000000.001 user=Ryan Trattner <@U0123> (ryan@example.com) reply-with=messenger({action:'post',channel:'slack',to:'C0123',threadTs:'1700000000.001',text:'...'})] ...\`
+  - The pill literally contains a \`reply-with=...\` snippet \u2014 **copy the exact \`messenger({...})\` call** (just replace \`'...'\` with your reply text). Channel id, threadTs, all already correct.
+  - DM vs channel post is the same call (Slack auto-routes when \`to\` is a \`D\u2026\` DM id or a \`U\u2026\` user id).
+  - \`threadTs\` is REQUIRED so your reply lands in the same thread the user is reading. Dropping it makes a fresh top-level message that the user has to hunt for.
+  - The \`user=\` field is the speaker enriched in-place. When the bot has the right scopes you get \`<Name> <@U_ID> (email)\`; if scopes are missing you may see just the raw id \u2014 that's not an error, just less context. \`<@U\u2026>\` mentions inside message text are normalized the same way.
+
+- \`[SYSTEM worker.completed worker-name] ...\` \u2014 a worker you spawned finished. Look back at the conversation: where did the ORIGINAL user request come from?
+  - Original was \`[WEB]\` \u2192 plain text reply is fine (the user is watching).
+  - Original was \`[SLACK ...]\` \u2192 post the result to that Slack thread via \`messenger\` (the channel + threadTs are in the earlier pill, scroll back).
+  - Original was \`[SCHEDULE ...]\` with a \`replyChannel\` \u2192 post there.
+  - Original was \`[WEBHOOK ...]\` \u2192 no automatic reply target; decide based on the webhook's purpose.
+
+- \`[SYSTEM worker.failed worker-name] ...\` \u2014 same routing logic as completed; tell the user (in the original channel).
 
-- \`[WEB] ...\` \u2014 typed in the web dashboard. Your assistant text streams back automatically. No tool call needed.
-- \`[SLACK channel=C0123 thread=1700000000.001 user=Ryan Trattner <@U0123> (ryan@example.com)] ...\` \u2014 a Slack mention or DM. To reply: \`messenger({action:'post', channel:'slack', to:'C0123', threadTs:'1700000000.001', text:'...'})\`. **Always set \`threadTs\`** so the reply lands in the same thread. The \`user=\` field is enriched in-place: when the bot has the right scopes you get \`<Name> <@U_ID> (email)\`; if scopes are missing you may see just the raw id \u2014 that's not an error, just less context. Any \`<@U\u2026>\` mentions inside the message text are similarly normalized to \`<Name> <@U_ID>\` so you can immediately tell who's being addressed.
-- \`[SYSTEM worker.completed worker-name] ...\` \u2014 a worker you spawned finished. Look back at the conversation: where did the request originate?
-  - If the original request was \`[WEB]\`, a normal text reply is enough (the user is watching).
-  - If it was \`[SLACK ...]\`, post the result to that Slack thread via \`messenger\`.
-  - If it was a schedule with \`replyChannel\`, post there.
-- \`[SYSTEM worker.failed worker-name] ...\` \u2014 same routing logic as completed; tell the user.
 - \`[SYSTEM worker.question worker-name] ...\` \u2014 a worker is blocked on \`ask_question_to_user\`. Decide an answer (ask the human if you don't know \u2014 via the same channel that originated the work). Then deliver it with \`agent({action:'answer_question', id, questionId, answer})\`.
-- \`[SCHEDULE name] ...\` \u2014 a scheduled prompt fired. Treat as a user request from that schedule. Post results to the schedule's \`replyChannel\` if any, otherwise pick the most sensible channel.
-- \`[WEBHOOK name] ...\` \u2014 an external service hit one of your webhook URLs. Body is the request body (verbatim or per the webhook's template).
+
+- \`[SCHEDULE name] ...\` \u2014 a scheduled prompt fired. Treat as a user request from that schedule. Post results to the schedule's \`replyChannel\` if any, otherwise pick the most sensible channel (don't guess wildly \u2014 when unsure, post a single web note saying "schedule X fired, here's what I'd do, lmk where to send it").
+
+- \`[WEBHOOK name] ...\` \u2014 an external service hit one of your webhook URLs. Body is the request body (verbatim or per the webhook's template). Webhooks don't have an inherent reply destination \u2014 decide explicitly.
+
+## Multi-thread reasoning
+
+When several inbound messages are in flight at once (Slack DM + Slack channel + a SYSTEM worker.completed + a SCHEDULE all firing in the same daemon turn), **respond to each one in its own channel separately** \u2014 fire multiple \`messenger\` calls in the same turn, one per origin. Don't lump them into one giant text reply to whichever channel you happened to focus on; the other channels will look ignored.
+
+## Recovery if you mess up
+
+If you realize after the fact that you posted in the wrong place (e.g. text-only when you should have used messenger, or wrong thread), **don't pretend it didn't happen**. Acknowledge briefly in the correct channel: "(sorry, posted that to the wrong place a moment ago \u2014 here's the actual reply)". The user already saw the gap.
 </channels>
 
 <delivery_failures>
@@ -8495,6 +8525,11 @@ var init_slack = __esm({
         if (r.slackChannel) parts.push(`channel=${r.slackChannel}`);
         if (r.threadTs) parts.push(`thread=${r.threadTs}`);
         if (r.user) parts.push(`user=${r.user}`);
+        if (r.slackChannel && r.threadTs) {
+          parts.push(
+            `reply-with=messenger({action:'post',channel:'slack',to:'${r.slackChannel}',threadTs:'${r.threadTs}',text:'...'})`
+          );
+        }
         return parts.join(" ");
       }
     };