@sellable/install 0.1.341 → 0.1.342

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.341",
+  "version": "0.1.342",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code, Codex, and Hermes",
   "bin": {

package/skill-templates/refill-sends.md

@@ -223,13 +223,17 @@ Structured planner packet:
   campaign/sender/lane summary, skipped rungs, existing-row frontier proof, and
   any absolute `wait.deadlineAt`.
 - Preserve these coverage labels exactly: `Need to prepare`, `Goal`,
-  `Already sent`, `Scheduled`, `Ready and waiting to be scheduled`, and
-  `Still need`.
+  `Already sent`, `Scheduled`, `Ready and waiting to be scheduled`,
+  `Still need to schedule`, and `Still need to prepare`. Never render an
+  unlabeled `Still need` value.
 - `target.globalActionQueue` is the only cross-sender yolo execution queue.
   Execute exactly one globally ranked primitive from
   `target.globalActionQueue[0]`, then rerun `get_refill_target_plan` with the
   same `workspaceId` before
   choosing another action.
+- When that primitive is `run_scheduler_sweep`, show `workspaceWide:true` and
+  its reason in the approval/yolo packet so the operator sees that the sweep
+  may schedule other eligible workspace cells on the approved date.
 - `manualAlternates` are not yolo actions. Threshold lowering and campaign
   creation are manual continuations only.
 
@@ -324,12 +328,16 @@ If the target plan is complete by projected coverage, report that the selected
 target is already filled and no-op without asking for approval. If the ready
 buffer covers the projected gap, paid InMail credit facts are fresh for every
 selected paid-InMail lane, but scheduled coverage is still short, keep the run
-open in a persistent read-only scheduler wait loop. Poll
-`get_refill_target_plan` every 60-120 seconds, or on the host's next continuation
-interval, until projected coverage fills the target, a concrete non-scheduler
-blocker appears, or Christian explicitly asks to stop or only receive a status
-report. Treat `awaiting_scheduler_after_ready_buffer` as an in-progress wait
-state, not a close-out condition.
+open in a persistent read-only scheduler wait loop. Honor the emitted wait
+metadata: reread `get_refill_target_plan` after about 30 seconds by default (or
+the action's explicit `rereadAfterMs`), never use a blind hard-coded sleep, and
+stop at the named bound using `receipt_deadline > unchanged_poll_bound >
+run_budget` precedence. A matching active/uncertain request key is never
+redispatched. Continue until projected coverage fills the target, a concrete
+non-scheduler blocker appears, a named bound stops the run, or Christian
+explicitly asks to stop or only receive a status report. Treat
+`awaiting_scheduler_after_ready_buffer` as an in-progress wait state, not a
+close-out condition.
 Wait actions are gates, not competing goals. When `wait_for_active_work` or
 `wait_for_scheduler` includes receipt `wait.deadlineAt`, honor that absolute
 deadline; if it is expired on this call, escalate to diagnostics with the