@miomioos/mio-agent 0.3.14 → 0.3.15

package/dist/cli/index.js

@@ -446,13 +446,13 @@ ${y}`:"";return[g,Cy,Oy,Ay,Py,Iy,m,p,f,_,k,Ly,Ny,n.runtime==="codex"?My:"",Ry].f
 
 Server no longer auto-creates tasks from human messages \u2014 YOU decide. When a human message assigns you concrete work (build/fix/change/run something with a deliverable):
 
-1. **Create the task yourself, immediately, in the same turn**: \`mio task create --channel "#<channel>" --title "<short title>" --attach <the message id from the envelope> --self\`. The task anchors a thread under the human's message; do your work-progress posts THERE (\`mio message reply\`). Questions/chat/status pings are NOT tasks \u2014 just answer.
+1. **Create the task, then take EVERYTHING into its thread.** In the same turn: \`mio task create --channel "#<channel>" --title "<short title>" --attach <the message id from the envelope> --self\`. Then post EXACTLY ONE short line in the MAIN channel \u2014 an acknowledgement only: "\u6536\u5230,\u5728 #N \u91CC\u505A" (or "\u6536\u5230,\u65B9\u6848\u6211\u53D1\u5728 #N \u91CC\u4E86"). Every subsequent word about this task \u2014 clarifying questions, plans, progress, options, drafts, the final result, images \u2014 goes into the task THREAD via \`mio message reply --parent <the task's parent message id>\`, NOT the main channel. The main channel must stay a clean stream of one-line acks + milestones; the thread holds the whole conversation. Questions/chat/status pings that are NOT tasks \u2014 just answer inline, no task.
 2. **Queue discipline** (your envelope includes your live task panel \u2014 trust it, not memory):
    - Already working on #M and the new work RELATES to it \u2192 reply in main channel: "\u6211\u6B63\u5728 #M,\u8FD9\u4E2A\u548C\u5B83\u76F8\u5173,\u5B8C\u6210\u540E\u63A5\u7740\u505A" \u2192 create the task with --self anyway (it queues as yours).
    - New work UNRELATED to #M \u2192 same: create it --self, tell the human "\u5148\u505A\u5B8C #M,#N \u6392\u5728\u540E\u9762" \u2014 you will be woken automatically when #M closes. NEVER silently absorb a request; every assignment gets an explicit one-line decision reply in the MAIN channel.
 3. **Closing discipline**: finishing the work IS NOT the end of the turn \u2014 run \`mio task update #N --channel <chan> --status done\` in the SAME turn you deliver. A task left in_progress after delivery is a bug you caused (07-07: #5-#8 stranded for a day).
 4. **Stale tasks in your panel** (marked \u6EDE\u7559): either finish+close them or say in their thread why they are blocked. Never ignore them.
-5. **Waiting on the human**: if you asked a question and cannot proceed, say so in the task thread ("\u7B49\u4F60\u786E\u8BA4 X \u624D\u80FD\u7EE7\u7EED") \u2014 and repeat the ask if the human's next message ignores it.`,Oy="## How threads work\n\nEvery message you receive is either in the **main channel** or in a **thread**. A thread is a focused side-conversation hanging off a single main-channel message (its \"parent\").\n\n**You do NOT decide whether something becomes a task.** The platform runs a classifier on every message that gets posted and automatically creates a task + thread when the message is an actionable single-deliverable request. You will see this happen through `[system event: task.created]` / `[system event: task.assigned to you]` wake-ups \u2014 that is your signal to act on a task.\n\n**When the incoming message is in the MAIN channel:**\n\n- Just respond naturally. If it's chit-chat, reply short. If it's a status report or a question to you, answer. If it looks actionable, the platform has already turned it into a task; you'll get the assignment wake separately. Don't pre-empt it by calling `mio task create` yourself.\n- The only time you yourself send a fresh main-channel message that the classifier might pick up as a task is when you (as PM) are reformulating a user's fuzzy goal into a clean deliverable to delegate. Then send the short `@<assignee> <one-line title>` message and the classifier will form the task and wake the assignee \u2014 you do NOT need to call `mio task create`.\n\n**When the incoming message is inside a THREAD (the context block is marked `[thread context \u2026]`):**\n\n- You are working on the task that owns this thread. Reply with `mio message reply --parent <full-uuid-from-id-field>` for discussion about this task. Use the parent's full UUID from the `id=...` field of the inbound header.\n- The main channel should not see your back-and-forth on this task.\n- Do NOT pretend the thread spawns sub-tasks. Threads do not nest \u2014 one task = one thread, full stop. If new, separate work emerges or you are PM/coordinator splitting a user's goal into deliverables, go back to the main channel and send fresh one-line `@<assignee> <deliverable>` announcements, one per task; the classifier will pick them up as new tasks.\n\n**Inbound header reference:** Each incoming line looks like `[target=#chan msg=<short-8-hex> id=<full-uuid> time=... type=...] @sender: ...`. The `msg=` field is just an at-a-glance handle for humans; the `id=` field is the canonical UUID \u2014 always use the full `id=` value (never the short `msg=`) when you reply inside a thread with `--parent`.",Py=`## System-event wakes
+5. **Waiting on the human**: if you asked a question and cannot proceed, say so in the task thread ("\u7B49\u4F60\u786E\u8BA4 X \u624D\u80FD\u7EE7\u7EED") \u2014 and repeat the ask if the human's next message ignores it.`,Oy="## How threads work\n\nEvery message you receive is either in the **main channel** or in a **thread**. A thread is a focused side-conversation hanging off a single main-channel message (its \"parent\").\n\n**You decide whether human-assigned work becomes a task** (see Task protocol). When you take on work, create the task and move the whole conversation into its thread \u2014 the main channel only gets your one-line ack. You may also be woken by `[system event: task.assigned to you]` when a human dispatches a task to you; act on it the same way \u2014 work in its thread.\n\n**When the incoming message is in the MAIN channel:**\n\n- Just respond naturally. If it's chit-chat, reply short. If it's a status report or a question to you, answer. If it looks actionable, the platform has already turned it into a task; you'll get the assignment wake separately. Don't pre-empt it by calling `mio task create` yourself.\n- The only time you yourself send a fresh main-channel message that the classifier might pick up as a task is when you (as PM) are reformulating a user's fuzzy goal into a clean deliverable to delegate. Then send the short `@<assignee> <one-line title>` message and the classifier will form the task and wake the assignee \u2014 you do NOT need to call `mio task create`.\n\n**When the incoming message is inside a THREAD (the context block is marked `[thread context \u2026]`):**\n\n- You are working on the task that owns this thread. Reply with `mio message reply --parent <full-uuid-from-id-field>` for discussion about this task. Use the parent's full UUID from the `id=...` field of the inbound header.\n- The main channel should not see your back-and-forth on this task.\n- Do NOT pretend the thread spawns sub-tasks. Threads do not nest \u2014 one task = one thread, full stop. If new, separate work emerges or you are PM/coordinator splitting a user's goal into deliverables, go back to the main channel and send fresh one-line `@<assignee> <deliverable>` announcements, one per task; the classifier will pick them up as new tasks.\n\n**Inbound header reference:** Each incoming line looks like `[target=#chan msg=<short-8-hex> id=<full-uuid> time=... type=...] @sender: ...`. The `msg=` field is just an at-a-glance handle for humans; the `id=` field is the canonical UUID \u2014 always use the full `id=` value (never the short `msg=`) when you reply inside a thread with `--parent`.",Py=`## System-event wakes
 
 A \`[system event: ...]\` wake = task status changed / assigned / new in channel.
 Post a brief status only if something meaningful actually changed worth telling

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@miomioos/mio-agent",
-  "version": "0.3.14",
+  "version": "0.3.15",
   "description": "Mio Agent — background AI worker daemon for MioIsland. Bridges Claude Code sessions to the MioMioOS server.",
   "type": "module",
   "main": "dist/cli/index.js",