sensorium-mcp 2.16.121 → 2.16.122

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sensorium-mcp",
-  "version": "2.16.121",
+  "version": "2.16.122",
   "description": "MCP server for remote control of AI assistants via Telegram",
   "main": "dist/index.js",
   "bin": {

package/templates/delegate-and-wait.default.md

@@ -0,0 +1,77 @@
+---
+name: Delegate and Wait
+triggers:
+  - delegate to thread
+  - delegate and wait
+  - orchestrator worker
+  - spawn thread and wait
+  - use multi-thread
+replaces_orchestrator: true
+---
+
+## Delegate and Wait — Orchestrator-Worker Pattern
+
+### Overview
+This skill describes the **orchestrator-worker** pattern: you spawn a ghost thread, send it a task, and **wait** for the result. The orchestrator does NOT do the work — it delegates, waits, and processes the response.
+
+### When to Use
+- Code reviews (you need the findings to act on)
+- Any task where the output determines your next action
+- Work that requires specialist domain context (dashboard, testing, refactoring)
+- Tasks with acceptance criteria you need to verify
+
+### Core Pattern
+
+#### Step 1 — Spawn the worker thread
+```
+start_thread(
+  name: "Dashboard Worker",
+  task: "You are a dashboard specialist. You build and maintain the Vue dashboard.",
+  memorySourceThreadId: <ORCHESTRATOR_THREAD_ID>  // share memory context
+)
+→ returns { threadId: <WORKER_THREAD_ID> }
+```
+
+#### Step 2 — Send a detailed task with EXPLICIT report-back instruction
+```
+send_message_to_thread(
+  threadId: <WORKER_THREAD_ID>,
+  message: "Task: Rewrite the dashboard settings page using React.
+  Acceptance criteria:
+  - Settings load from /api/settings
+  - Form validates input
+  - Save button persists changes
+  
+  ⚠️ IMPORTANT: When complete, report your results back to thread <ORCHESTRATOR_THREAD_ID> using:
+  send_message_to_thread(threadId=<ORCHESTRATOR_THREAD_ID>, message='...')"
+)
+```
+
+**CRITICAL**: The task message MUST include the orchestrator's thread ID so the worker knows where to send results.
+
+#### Step 3 — Wait for results (do NOT duplicate the work)
+```
+remote_copilot_wait_for_instructions(threadId: <ORCHESTRATOR_THREAD_ID>)
+```
+The orchestrator parks here. It does NOT start doing the work itself. The worker will execute the task and send results back via `send_message_to_thread`.
+
+#### Step 4 — Process results when they arrive
+Results arrive as a message in `wait_for_instructions`. Review, approve, or request changes by sending another message to the worker.
+
+### Rules
+
+- **NEVER** duplicate work after delegating. If you sent it to a worker, wait for the response.
+- **ALWAYS** include the orchestrator thread ID in the task message so the worker can report back.
+- **ALWAYS** include clear acceptance criteria in the task message.
+- **ALWAYS** use `wait_for_instructions` after sending the task — this is what makes you an orchestrator, not a doer.
+- Worker threads build domain-specific memory over time — reuse the same thread for the same domain.
+- The orchestrator stays clean for high-level decisions and operator interaction.
+
+### Anti-Patterns
+
+- ❌ Sending a task then immediately doing the work yourself
+- ❌ Creating a worker thread AND running a subagent for the same task
+- ❌ Forgetting to include the orchestrator thread ID in the task message
+- ❌ Sending tasks without acceptance criteria
+- ❌ Creating a new thread for every task instead of reusing domain threads
+- ❌ Reading worker results and re-doing the work instead of applying them

package/templates/fire-and-forget.default.md

@@ -0,0 +1,76 @@
+---
+name: Fire and Forget
+triggers:
+  - fire and forget
+  - background task
+  - spawn autonomous thread
+  - thread delegation no wait
+replaces_orchestrator: true
+---
+
+## Fire and Forget — Autonomous Worker Pattern
+
+### Overview
+This skill describes the **fire-and-forget** pattern: you spawn a ghost thread, send it a task, and **continue working immediately**. The worker executes autonomously and reports progress directly to the **operator** (not back to you).
+
+### When to Use
+- Background cleanup tasks (log rotation, stale file removal)
+- Scheduled improvements that don't affect current work
+- Logging, monitoring, metrics collection
+- Any task where the result does NOT gate your next step
+- Long-running tasks you don't need to wait on
+
+### When NOT to Use
+- Code reviews (you need the findings)
+- Any task where the output determines your next action
+- Tasks that modify files you're also editing (conflict risk)
+- Work with acceptance criteria you need to verify → use **Delegate and Wait** instead
+
+### Core Pattern
+
+#### Step 1 — Spawn the worker thread
+```
+start_thread(
+  name: "Background Cleanup",
+  task: "You handle background maintenance tasks autonomously."
+)
+→ returns { threadId: <WORKER_THREAD_ID> }
+```
+
+#### Step 2 — Send the task (NO report-back needed)
+```
+send_message_to_thread(
+  threadId: <WORKER_THREAD_ID>,
+  message: "Task: Clean up stale log files older than 30 days in ~/.remote-copilot-mcp/logs/.
+  This is a one-shot task. Report progress to the operator via report_progress or send_voice.
+  Do NOT message the sender back."
+)
+```
+
+**KEY**: The task explicitly tells the worker NOT to send results back to the orchestrator. The worker reports to the **operator** directly using `report_progress` or `send_voice`.
+
+#### Step 3 — Continue working immediately
+Do NOT call `wait_for_instructions` for this worker. Continue with your own work. The worker runs independently.
+
+### Worker Behavior
+The autonomous worker should:
+- Execute the task independently
+- Report progress to the **operator** via `report_progress` or `send_voice`
+- NOT send messages back to the orchestrator thread
+- Handle errors gracefully and notify the operator if something fails
+
+### Rules
+
+- **NEVER** call `wait_for_instructions` after a fire-and-forget delegation.
+- **ALWAYS** tell the worker to report to the operator, not back to the orchestrator.
+- **ALWAYS** include explicit instructions like "Do NOT message the sender back."
+- Use this pattern only when the result doesn't affect your immediate work.
+- If you later realize you need the result, spawn a new **Delegate and Wait** task instead.
+
+### Anti-Patterns
+
+- ❌ Waiting on a fire-and-forget worker (defeats the purpose)
+- ❌ Worker sending results back to the orchestrator instead of the operator
+- ❌ Using fire-and-forget for tasks that gate your next step
+- ❌ Spawning fire-and-forget workers that modify files you're actively editing
+- ❌ Forgetting to tell the worker how to report progress (operator gets no visibility)

package/templates/multi-thread-delegation.default.md

@@ -1,100 +0,0 @@
----
-name: Multi-Thread Delegation
-triggers:
-  - delegate to thread
-  - use multi-thread
-  - thread delegation
-  - spawn thread
-replaces_orchestrator: true
----
-
-## Multi-Thread Agent Orchestration
-
-### Overview
-This skill describes how to use sensorium-mcp's inter-thread messaging for orchestrating work across multiple persistent threads. Each thread represents a specialist worker with its own memory context.
-
-### Thread Topology
-- **Manager Thread** (main): Design decisions, operator interaction, constraints, routing
-- **Worker Threads** (persistent): Specialized domains — dashboard, code-review, testing, refactoring, etc.
-
-### Core Pattern: Delegate and Wait
-
-When you have work that should be delegated to a worker thread:
-
-1. **Create or identify the worker thread**
-   ```
-   start_thread(name: "Dashboard Worker")
-   → returns { threadId: <WORKER_THREAD_ID> }
-   ```
-
-2. **Send a detailed task with clear acceptance criteria**
-   ```
-   send_message_to_thread(
-     threadId: <WORKER_THREAD_ID>,
-     message: "Task: Rewrite the dashboard settings page using React.
-     Acceptance criteria:
-     - Settings load from /api/settings
-     - Form validates input
-     - Save button persists changes
-     When complete, send results back to thread <MANAGER_THREAD_ID>."
-   )
-   ```
-
-3. **Wait for results — do NOT duplicate the work**
-   ```
-   remote_copilot_wait_for_instructions(threadId: <MANAGER_THREAD_ID>)
-   ```
-   The worker will execute the task and send results back via send_message_to_thread.
-
-4. **Process results when they arrive**
-   Results arrive as an operator message in wait_for_instructions. Review, approve, or request changes.
-
-### Pattern 2: Fire and Forget
-
-For tasks that don't need a response back — the worker executes autonomously and the manager moves on.
-
-1. **Create or identify the worker thread**
-   ```
-   start_thread(name: "Background Cleanup")
-   → returns { threadId: <WORKER_THREAD_ID> }
-   ```
-
-2. **Send the task — no report-back needed**
-   ```
-   send_message_to_thread(
-     threadId: <WORKER_THREAD_ID>,
-     message: "Task: Clean up stale log files older than 30 days in ~/.remote-copilot-mcp/logs/.
-     This is a one-shot task. Report progress to the operator via report_progress or send_voice.
-     Do NOT message the sender back."
-   )
-   ```
-
-3. **Continue working immediately**
-   Don't call wait_for_instructions for this task. Continue with your own work.
-
-#### When to use Fire and Forget:
-- Background cleanup tasks
-- Scheduled improvements that don't affect current work
-- Logging, monitoring, metrics tasks
-- Any task where the result doesn't gate your next step
-
-#### When NOT to use Fire and Forget:
-- Code reviews (you need the findings to act on)
-- Any task where the output determines your next action
-- Tasks that modify files you're also editing (conflict risk)
-
-### Rules
-
-- **NEVER** duplicate work with a subagent after delegating to a thread. Trust the delegation.
-- **ALWAYS** include clear acceptance criteria in the task message.
-- **ALWAYS** specify which thread to report back to.
-- Worker threads build domain-specific memory over time — reuse the same thread for the same domain.
-- The manager thread stays clean for high-level decisions and operator interaction.
-
-### Anti-Patterns
-
-- ❌ Creating a worker thread AND running a subagent for the same task
-- ❌ Sending a task then immediately doing the work yourself
-- ❌ Creating a new thread for every task instead of reusing domain threads
-- ❌ Sending tasks without acceptance criteria or report-back instructions
-- ❌ Reading worker results and re-doing the work instead of applying them