@wular/coder 0.3.5 → 0.3.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@wular/coder",
-  "version": "0.3.5",
+  "version": "0.3.6",
   "description": "Delegating coding-agent runtime",
   "type": "module",
   "main": "./dist/sdk.js",

package/plugins/agents/skills/coder/SKILL.md

@@ -32,7 +32,7 @@ If `coder` is not on PATH, install it yourself without asking (`npm install -g @
   coder task run --system "<standing instructions>" "<task text>"
   ```
 
-  Fetch the answer with `coder task result <task-id> --wait` - blocks until done, prints only the final result. Run it in a background shell so it does not block you; without one, poll without `--wait`, or put `--wait` on the run itself.
+  Fetch the answer with `coder task result <task-id> --wait` - blocks until done, prints only the final result. Run it in a background shell so it does not block you. For a fan-out, start one such background waiter per dispatched task (see Supervision loop).
 
 - A `--wait` (on `run` or `result`) exits **4** when the task is waiting on a permission approval: relay the approval to the user, apply their decision with `coder approve <task-id> <approval-id> [--deny]`, then re-fetch with `coder task result <task-id> --wait`. (Unanswered approvals auto-deny after 120s and the task moves on.)
 
@@ -63,7 +63,7 @@ When no coder engine can start (missing binaries, auth, quota across the whole c
 
 ## Supervision loop
 
-With coders running in the background, don't fire-and-forget: check in on them recurrently with whatever scheduling facility your harness has (interval by the work's pace, 10m default); without one, check between your other steps. Each tick: `coder task list`, fetch finished results, dispatch newly unblocked coders, steer stuck ones, stop off-track ones, surface pending approvals. Stop when all tasks are done and relayed.
+With coders running in the background, don't fire-and-forget: hold one background `coder task result <task-id> --wait` shell per task - each returns when its task finishes (relay the answer, dispatch newly unblocked coders) or escalates an approval (exit 4, see above; restart the waiter after answering). Only without background shells, fall back to recurring check-ins (whatever scheduling facility your harness has; interval by the work's pace, 10m default; bump `approvals.escalationTimeoutMs` above it so escalations survive between ticks): each tick `coder task list`, fetch finished results, surface pending approvals.
 
 ## Controlling tasks
 

package/plugins/claude/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "coder",
-  "version": "0.3.5",
+  "version": "0.3.6",
   "description": "Delegate coding tasks to supervised Coder subagents running on Codex, Claude, or any OpenAI-compatible model. Your main context stays clean.",
   "author": {
     "name": "muzam1l"

package/plugins/claude/skills/dispatch/SKILL.md

@@ -30,7 +30,7 @@ If `coder` is not on PATH, install it yourself without asking (`npm install -g @
   coder task run --system "<standing instructions>" "<task text>"
   ```
 
-  Fetch the answer with `coder task result <task-id> --wait` - blocks until done, prints only the final result. Run it as a background Bash call (run_in_background: true) so it does not block you and you are re-invoked on completion; without one, poll without `--wait`, or put `--wait` on the run itself.
+  Fetch the answer with `coder task result <task-id> --wait` - blocks until done, prints only the final result. Run it as a background Bash call (run_in_background: true) so it does not block you and you are re-invoked on completion. For a fan-out, start one such background waiter per dispatched task (see Supervision loop).
 
 - A `--wait` (on `run` or `result`) exits **4** when the task is waiting on a permission approval: relay the approval to the user, apply their decision with `coder approve <task-id> <approval-id> [--deny]`, then re-fetch with `coder task result <task-id> --wait`. (Unanswered approvals auto-deny after 120s and the task moves on.)
 
@@ -61,7 +61,7 @@ When no coder engine can start (missing binaries, auth, quota across the whole c
 
 ## Supervision loop
 
-With coders running in the background, don't fire-and-forget: schedule recurring check-ins (the `/loop` skill or ScheduleWakeup; interval by the work's pace, 10m default). Each tick: `coder task list`, fetch finished results, dispatch newly unblocked coders, steer stuck ones, stop off-track ones, surface pending approvals. Stop the loop when all tasks are done and relayed.
+With coders running in the background, don't fire-and-forget: hold one background `coder task result <task-id> --wait` per task - each re-invokes you when its task finishes (relay the answer, dispatch newly unblocked coders) or escalates an approval (exit 4, see above; restart the waiter after answering). Only without background shells, fall back to recurring check-ins (the `/loop` skill or ScheduleWakeup; interval by the work's pace, 10m default; bump `approvals.escalationTimeoutMs` above it so escalations survive between ticks): each tick `coder task list`, fetch finished results, surface pending approvals.
 
 ## Controlling tasks
 

package/plugins/cursor/.cursor-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "coder",
   "displayName": "Coder",
-  "version": "0.3.5",
+  "version": "0.3.6",
   "description": "Delegate coding tasks to supervised Coder subagents running on Codex, Claude, or any OpenAI-compatible model. Your main context stays clean.",
   "author": {
     "name": "muzam1l"

package/plugins/cursor/skills/coder/SKILL.md

@@ -31,7 +31,7 @@ If `coder` is not on PATH, install it yourself without asking (`npm install -g @
   coder task run --system "<standing instructions>" "<task text>"
   ```
 
-  Fetch the answer with `coder task result <task-id> --wait` - blocks until done, prints only the final result. Run it in a background shell so it does not block you; without one, poll without `--wait`, or put `--wait` on the run itself.
+  Fetch the answer with `coder task result <task-id> --wait` - blocks until done, prints only the final result. Run it in a background shell so it does not block you. For a fan-out, start one such background waiter per dispatched task (see Supervision loop).
 
 - A `--wait` (on `run` or `result`) exits **4** when the task is waiting on a permission approval: relay the approval to the user, apply their decision with `coder approve <task-id> <approval-id> [--deny]`, then re-fetch with `coder task result <task-id> --wait`. (Unanswered approvals auto-deny after 120s and the task moves on.)
 
@@ -62,7 +62,7 @@ When no coder engine can start (missing binaries, auth, quota across the whole c
 
 ## Supervision loop
 
-With coders running in the background, don't fire-and-forget: run a recurring monitoring loop in this session (interval by the work's pace, 10m default). Each tick: `coder task list`, fetch finished results, dispatch newly unblocked coders, steer stuck ones, stop off-track ones, surface pending approvals. Stop the loop when all tasks are done and relayed.
+With coders running in the background, don't fire-and-forget: hold one background `coder task result <task-id> --wait` shell per task - each returns when its task finishes (relay the answer, dispatch newly unblocked coders) or escalates an approval (exit 4, see above; restart the waiter after answering). Only without background shells, fall back to a recurring monitoring loop (interval by the work's pace, 10m default; bump `approvals.escalationTimeoutMs` above it so escalations survive between ticks): each tick `coder task list`, fetch finished results, surface pending approvals.
 
 ## Controlling tasks