@sellable/install 0.1.291 → 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.291",
+  "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

@@ -5,6 +5,7 @@ visibility: public
 allowed-tools:
   - mcp__sellable__refill_sends
   - mcp__sellable__get_refill_target_plan
+  - mcp__sellable__refresh_paid_inmail_credits
   - mcp__sellable__get_auth_status
   - mcp__sellable__start_cli_login
   - mcp__sellable__wait_for_cli_login
@@ -96,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
@@ -116,16 +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.
-If paid InMail is below threshold, stale, or missing credit facts, report the
-exact campaign/table/column threshold action or connection fallback; `--yolo`
-does not lower paid-InMail thresholds or create campaigns.
+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.
 
 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
@@ -135,23 +161,21 @@ campaigns are start-eligible refill candidates; read refill state before decidin
 whether to prep, approve, start, or skip. Do not treat them as archived inventory.
 
 For interactive Codex or Claude Code sessions, that approval must use the
-host-native structured question gate, but the full approval packet must render
-in normal chat first:
+host-native structured question gate, not plain chat:
 
 - Codex: use `request_user_input`.
 - Claude Code: use `AskUserQuestion`.
 
-Render the operator output packet in normal chat immediately before opening the
-structured question. Use Markdown so the packet is readable: workspace, sender
+The approval question must present the final refill step with exactly two
+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. Then open the
-structured approval question with exactly two choices: `Accept` and `Decline`.
-Keep that question compact, for example "Approve the refill packet rendered
-above?" Do not paste the full packet into the structured question panel. Treat
-`Accept` as permission for only the exact packet rendered immediately above,
-including target, caps, mode, and side effects. Treat `Decline` as a hard stop
-with no mutation.
+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
@@ -169,7 +193,8 @@ approved eligible sequence actions, so include that expected side effect in the
 packet. It does not authorize starting unrelated, archived, completed, draft, or
 direct campaigns, separate launch/send actions, archive or delete cleanup,
 	direct scheduler writes, sender reassignment, paid-InMail threshold changes,
-	connection campaign creation, or campaigns outside those
+	connection campaign creation, paid-InMail credit refreshes outside the exact
+	rendered sender packet, or campaigns outside those
 selected for the eligible sender set. Stop and re-plan if the route, sender set,
 ids, caps, blockers, paid-InMail feasibility, action class, or side-effect class
 drift before mutation. Sent/scheduled counts increasing toward the approved
@@ -194,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