@sellable/install 0.1.292 → 0.1.293

package/bin/sellable-install.mjs

@@ -1976,6 +1976,13 @@ workflow. It supports \`--yolo\` and optional repeated \`--sender <name-or-id>\`
 selectors. It also supports \`--until YYYY-MM-DD\` to fill through a specific
 sender-local date instead of the default two send-day horizon.
 
+Goal-mode continuation: a skill cannot create or invoke \`/goal\` by itself. If
+this command is already running inside an active Codex goal, keep that goal open
+until every selected sender lane is horizon-filled by projected coverage
+(\`sent + scheduled\`), Christian explicitly stops/statuses the run, or a
+concrete non-scheduler blocker appears. Do not call the goal complete or blocked
+only because the current state is \`awaiting_scheduler_after_ready_buffer\`.
+
 ## Bootstrap
 
 MCP prompt and command access are required. Do not inspect repo files, run shell
@@ -1991,7 +1998,7 @@ Desktop, then start a new thread.
 
 1. Call \`mcp__sellable__get_auth_status({})\`.
 2. Normalize invocation arguments with \`mcp__sellable__refill_sends({ yolo, senders, senderIds, senderNames, untilDate })\` when the host exposes typed MCP tools.
-3. Call \`mcp__sellable__get_refill_target_plan({ senders, senderIds, senderNames, untilDate })\` before any mutation. If the returned target is already complete, stop with the no-op receipt. If ready rows cover the target but scheduled rows do not, run only the read-only scheduler settle/re-read loop.
+3. Call \`mcp__sellable__get_refill_target_plan({ senders, senderIds, senderNames, untilDate })\` before any mutation. If the returned target is already complete, stop with the no-op receipt. If ready rows cover the target but scheduled rows do not, keep the run open in the read-only scheduler wait/re-read loop until projected coverage fills, a concrete non-scheduler blocker appears, or Christian explicitly stops/statuses the run.
 4. Load the canonical prompt via
    \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends" })\`,
    then load \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends-workflow" })\`.

package/package.json

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

package/skill-templates/refill-sends.md

@@ -97,6 +97,13 @@ senders" as sender-scoped requests. The target set is senders enrolled in active
 campaign-backed sequence campaigns, not the first active campaign returned by a
 resolver.
 
+Goal-mode continuation: a skill cannot create or invoke `/goal` by itself. When
+this command is already running inside an active Codex goal, keep that goal open
+until every selected sender lane is horizon-filled by projected coverage
+(`sent + scheduled`), Christian explicitly stops/statuses the run, or a concrete
+non-scheduler blocker appears. Do not call the goal complete or blocked only
+because the current state is `awaiting_scheduler_after_ready_buffer`.
+
 Load the internal workflow prompt before taking any operational step:
 
 ```text
@@ -117,21 +124,34 @@ eligible senders, selected sender-local days, gross target, actual sent
 coverage, scheduler-owned scheduled coverage across active enrolled campaigns,
 projected coverage (`sent + scheduled`), inferred per-sender send lane/action
 selections, ready buffer, remaining projected gap, paid-InMail credit/threshold
-feasibility, `targetShapeRevision`, and `stateRevision`. When `actionTypes` are
-omitted, trust the target plan's inferred lane rather than asking whether to
-fill connections, DMs, or InMails. 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 but scheduled
-coverage is still short, run only a bounded read-only scheduler settle/reread
-loop and report `awaiting_scheduler_after_ready_buffer` if it does not settle.
+feasibility, `targetShapeRevision`, and `stateRevision`. Refill target lanes
+are only connection invites (`send_invite`) or paid InMails
+(`send_inmail_closed`), chosen per sender from the most recent current
+dashboard-active campaign-backed send evidence. DMs (`send_dm`) and
+open-profile InMails (`send_inmail_open`) may exist in sequences, but they are
+not refill horizon target capacity and must not be counted as refill sent,
+scheduled, or ready coverage. When `actionTypes` are omitted, trust the target
+plan's inferred connection-or-paid-InMail lane rather than asking which of those
+two lanes to fill. If a stale target plan selects `send_dm` or
+`send_inmail_open`, stop and re-plan with the current planner before mutation.
+Short form: trust the target plan's inferred lane only when it is a
+connection-invite or paid-InMail refill lane.
+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 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.
 If paid InMail credit facts are stale or missing and the target plan returns a
 `refresh_paid_inmail_credits` action candidate, include the exact sender id,
 campaign/table/column proof, expected sender-credit-cache writes, and rerun plan
 step in the bounded packet. After `refresh_paid_inmail_credits`, rerun
 `get_refill_target_plan` before any prep/import/approval/start action. If paid
 InMail is below threshold after a fresh credit read, report the exact
-campaign/table/column threshold action or connection fallback; `--yolo` does not
-lower paid-InMail thresholds or create campaigns.
+campaign/table/column threshold action or connection fallback; `--yolo` does not lower paid-InMail thresholds or create campaigns.
 
 If the plain route's managed waterfall targets are stale, for example skipped
 targets show archived/completed shared slots or the returned targets do not cover
@@ -147,13 +167,15 @@ host-native structured question gate, not plain chat:
 - Claude Code: use `AskUserQuestion`.
 
 The approval question must present the final refill step with exactly two
-choices: `Accept` and `Decline`. The question body must include the operator
-output packet: workspace, sender scope, a campaign-by-campaign table with
-campaign name, sender names, action, target count/cap, source/list, and
-blocker/skip reason, then exact ids, expected side effects, forbidden actions,
-and the stop condition. Treat `Accept` as permission for only the rendered
-target, caps, mode, and side effects. Treat `Decline` as a hard stop with no
-mutation.
+choices: `Accept` and `Decline`. Render the full operator output packet in
+normal chat immediately before opening the structured approval question so it
+can be displayed as Markdown. The chat packet must include workspace, sender
+scope, a campaign-by-campaign table with campaign name, sender names, action,
+target count/cap, source/list, and blocker/skip reason, then exact ids,
+expected side effects, forbidden actions, and the stop condition. The structured
+question body must be compact and refer back to the posted packet instead of
+duplicating it. Treat `Accept` as permission for only the rendered target, caps,
+mode, and side effects. Treat `Decline` as a hard stop with no mutation.
 
 If Christian includes `--yolo` in the same refill request, treat that flag as
 auto-accept for the rendered bounded refill packet after the required fresh state
@@ -197,11 +219,13 @@ projected gap, paid-InMail feasibility, `targetShapeRevision`,
 `stateRevision`, and the next MCP primitive that can reduce the gap. After every
 apply/prep/start result, wait for processing, reread the target plan/refill
 state, recompute the ledger, then keep applying safe bounded actions until
-projected coverage fills the horizon or a concrete blocker/timeout is proven.
+projected coverage fills the horizon or a concrete non-scheduler blocker is
+proven.
 If ready rows cover the projected gap but the scheduler has not picked them up
-yet, run a bounded scheduler settle loop and report
-`awaiting_scheduler_after_ready_buffer` as not complete when the timeout is
-reached.
+yet, run the persistent read-only scheduler wait loop. Do not finish the refill
+goal, mark it complete, or mark it blocked only because it is still
+`awaiting_scheduler_after_ready_buffer`; keep waiting unless Christian stops the
+run or the host cannot continue.
 
 In `--yolo`, the default two-day fill horizon is two send days unless
 `--until`/`untilDate` is provided. If an until date is provided, compute bounded