@sellable/install 0.1.291 → 0.1.292

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.291",
+  "version": "0.1.292",
   "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
@@ -123,9 +124,14 @@ 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.
+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 +141,19 @@ 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
-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.
+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.
 
 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 +171,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