@sellable/install 0.1.296 → 0.1.297

package/bin/sellable-install.mjs

@@ -2000,7 +2000,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, targetDate, untilDate })\` when the host exposes typed MCP tools.
-3. Call \`mcp__sellable__get_refill_target_plan({ senders, senderIds, senderNames, targetDate, untilDate })\` before any mutation. Render \`target.eligibleSenderLedger\`, \`target.senderRefillPlans[]\`, and \`target.globalActionQueue\` as the structured packet. Preserve the labels \`Need to prepare\`, \`Goal\`, \`Already sent\`, \`Scheduled\`, \`Ready and waiting to be scheduled\`, and \`Still need\`. In \`--yolo\`, execute only one globally ranked primitive from \`target.globalActionQueue[0]\`, then rerun \`get_refill_target_plan\`. Maintain a run-local \`refreshedPaidInmailSenderIds\` set and refresh each selected paid-InMail sender at most once before falling back to an existing connection lane or manual continuation. For exact-date proof, \`mcp__sellable__get_scheduler_fill_capacity\` is read-only and tells how many cells the scheduler will try to place for a sender/action/date. 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.
+3. Call \`mcp__sellable__get_refill_target_plan({ senders, senderIds, senderNames, targetDate, untilDate })\` before any mutation. Render \`target.eligibleSenderLedger\`, \`target.senderRefillPlans[]\`, and \`target.globalActionQueue\` as the structured packet. Preserve the labels \`Need to prepare\`, \`Goal\`, \`Already sent\`, \`Scheduled\`, \`Ready and waiting to be scheduled\`, and \`Still need\`. In \`--yolo\`, \`mcp__sellable__refill_sends\` maintains a run-local \`refreshedPaidInmailSenderIds\` set, refreshes stale/missing paid InMail facts for each selected paid-InMail sender at most once, reruns \`get_refill_target_plan\`, and returns \`autoPaidInmailRefresh\` plus the post-refresh \`targetPlan\` before choosing the next prep/approval/start action. Do not present paid-credit refresh as the next operator action after \`refill_sends\` returns that post-refresh plan. For exact-date proof, \`mcp__sellable__get_scheduler_fill_capacity\` is read-only and tells how many cells the scheduler will try to place for a sender/action/date. 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.296",
+  "version": "0.1.297",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/refill-sends.md

@@ -161,11 +161,14 @@ Structured planner packet:
 - `manualAlternates` are not yolo actions. Threshold lowering and campaign
   creation are manual continuations only.
 
-Run-local paid-credit guard: maintain a `refreshedPaidInmailSenderIds` set for
-the current command call. Refresh each selected sender at most once per refill
-command call, then rerun `get_refill_target_plan`. If fresh facts are still
-below threshold, below-threshold paid-InMail facts fall back to an existing
-connection lane or a manual continuation.
+Run-local paid-credit guard: in `--yolo`, the `refill_sends` MCP command
+automatically maintains a `refreshedPaidInmailSenderIds` set for the current
+command call. If its first target plan has stale/missing paid-InMail credit
+facts, it refreshes each selected sender at most once, reruns
+`get_refill_target_plan`, and returns the post-refresh `targetPlan` before
+choosing the next prep/approval/start action. If fresh facts are still below
+threshold, below-threshold paid-InMail facts fall back to an existing connection
+lane or a manual continuation.
 
 Compact refill lessons: sender-level target plan is final truth; trust
 `schedulerGate.sendable` and scheduler gate blockers, not raw
@@ -190,14 +193,14 @@ 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. In `--yolo`, refresh each exact selected sender at
-most once for the current refill run, then 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 paid InMail credit facts are stale or missing and the first target plan
+contains `refresh_paid_inmail_credits`, do not present that as the operator's
+next action in `--yolo`. Trust `refill_sends.autoPaidInmailRefresh`: it should
+show the exact sender ids refreshed once, sender-credit-cache write receipts,
+and a returned post-refresh `targetPlan`. Continue from that post-refresh packet.
+If paid InMail is below threshold after the 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