@sellable/install 0.1.287 → 0.1.288

package/bin/sellable-install.mjs

@@ -1005,6 +1005,7 @@ const CREATE_CAMPAIGN_ALLOWED_TOOLS = [
   "mcp__sellable__wait_for_campaign_processing",
   "mcp__sellable__resolve_campaign_fill_route",
   "mcp__sellable__get_campaign_refill_state",
+  "mcp__sellable__get_refill_target_plan",
   "mcp__sellable__fill_campaign_horizon",
   "mcp__sellable__start_campaign_message_preparation",
   "mcp__sellable__get_campaign_message_preparation_status",
@@ -1064,6 +1065,7 @@ const REFILL_SENDS_ALLOWED_TOOLS = [
   "mcp__sellable__get_campaign_waterfall",
   "mcp__sellable__resolve_campaign_fill_route",
   "mcp__sellable__get_campaign_refill_state",
+  "mcp__sellable__get_refill_target_plan",
   "mcp__sellable__fill_campaign_horizon",
   "mcp__sellable__get_campaign",
   "mcp__sellable__get_campaign_context",
@@ -1989,10 +1991,11 @@ 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. Load the canonical prompt via
+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.
+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" })\`.
-4. Follow the canonical prompt exactly. Do not launch, start, archive, delete,
+5. Follow the canonical prompt exactly. Do not launch, start, archive, delete,
    or write scheduler rows as part of refill sends.
 
 ## MCP Prompt Fallback

package/lib/runtime-verify.mjs

@@ -30,6 +30,7 @@ export const REQUIRED_SELLABLE_MCP_TOOLS = [
   "attach_recommended_sequence",
   "resolve_campaign_fill_route",
   "get_campaign_refill_state",
+  "get_refill_target_plan",
   "refill_sends",
   "setup_evergreen_campaigns",
   "start_campaign_message_preparation",

package/package.json

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

package/skill-templates/create-campaign.md

@@ -49,6 +49,7 @@ allowed-tools:
   - mcp__sellable__wait_for_campaign_processing
   - mcp__sellable__resolve_campaign_fill_route
   - mcp__sellable__get_campaign_refill_state
+  - mcp__sellable__get_refill_target_plan
   - mcp__sellable__fill_campaign_horizon
   - mcp__sellable__start_campaign_message_preparation
   - mcp__sellable__get_campaign_message_preparation_status

package/skill-templates/create-evergreen-campaigns.md

@@ -1330,21 +1330,35 @@ Message, and verify current-revision sample messages before final completion.
      Short form: Shared lanes must reject internal workflow vocabulary.
      Short form: revise or rerun the packaged create-campaign/generate-messages path.
    - **Post Engagers** first-message style: short, casual, references the
-     sender-authored post they engaged with, and stops after the thank-you
-     line. Use **no internal vocabulary, no pitch, no meeting ask, no product
-     line, and no relevance question** in message one:
+     sender-authored post they engaged with, includes the post URL as a concrete
+     reminder, uses an easy buyer-function/category line, and ends with one
+     row-custom closed question. Use **no internal vocabulary, no meeting ask,
+     no proof block, no feature-stack category, and no generic static question**
+     in message one:
 
      ```
      {{first_name}}
 
      Hey there
 
-     Thank you for the support on my post about {{post_topic_line}}
+     Saw you pop up on my post about {{post_topic_line}}
+
+     This one
+     {{post_url}}
+
+     Looks like you lead {{plain_buyer_function}} at {{company_name}}, right?
+
+     {{custom_closed_question}}
      ```
 
-     Do not add any paragraph after the thank-you line. In particular, do not
-     append `curious, are you trying...`, `open to...`, `worth seeing...`, or
-     Sellable/product copy to a Post Engagers first message.
+     `{{custom_closed_question}}` must be specific to the post topic, buyer
+     function, company context, and current offer category. The category should
+     be easy to understand, for example `LinkedIn outbound`, `customer success`,
+     `CX operations`, `support`, `sales`, or `growth`; do not use feature-heavy
+     phrasing like `manual research + follow-up process`, `lead filters`, or
+     `sequence setup`. Do not add any paragraph after the custom closed question.
+     In particular, do not append `open to...`, `worth seeing...`, a meeting ask,
+     proof block, or Sellable/product copy to a Post Engagers first message.
 
    - **Shared Signal Discovery** first-message style: short, casual, starts
      from the real public business theme or buyer problem supported by the row.

package/skill-templates/refill-sends.md

@@ -4,6 +4,7 @@ description: Plan regular campaign and evergreen campaign send refill work throu
 visibility: public
 allowed-tools:
   - mcp__sellable__refill_sends
+  - mcp__sellable__get_refill_target_plan
   - mcp__sellable__get_auth_status
   - mcp__sellable__start_cli_login
   - mcp__sellable__wait_for_cli_login
@@ -102,11 +103,23 @@ get_subskill_prompt({ subskillName: "refill-sends-workflow" })
 ```
 
 Then follow that workflow exactly. The default path is read-only research:
-resolve the route, identify the sender-relevant campaign that most recently had
-scheduler-owned sends, read refill state for that target, report the next safe
-step using campaign names first, and stop before mutation unless the user has
-explicitly approved the exact workspace, campaign/table/source ids, caps/dates,
-approval mode, expected side effects, and stop/rollback condition.
+compute the refill target plan first, resolve the route, identify the
+sender-relevant campaign that most recently had scheduler-owned sends, read
+refill state for that target, report the next safe step using campaign names
+first, and stop before mutation unless the user has explicitly approved the
+exact workspace, campaign/table/source ids, caps/dates, approval mode, expected
+side effects, and stop/rollback condition.
+
+Immediately after loading the internal workflow, call
+`get_refill_target_plan`. The target plan is the canonical first fact receipt:
+selected sender-local days, gross scheduled-send target, scheduler-owned
+scheduled coverage across active enrolled campaigns, ready buffer, remaining
+scheduled gap, remaining ready-or-scheduled gap, `targetShapeRevision`, and
+`stateRevision`. If the target plan is complete, report that the selected target
+is already filled and no-op without asking for approval. If the ready buffer
+covers the target 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 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,7 +160,10 @@ 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, or campaigns outside those
 selected for the eligible sender set. Stop and re-plan if the route, sender set,
-ids, caps, blockers, or side-effect class drift before mutation.
+ids, caps, blockers, action class, or side-effect class drift before mutation.
+Scheduled counts increasing toward the approved target are expected progress:
+they change `stateRevision`, not `targetShapeRevision`, and do not require a
+second approval.
 
 In `--yolo`, continue as far as the rendered packet safely allows. After each
 apply/prep/start result, reread state, settle processing when needed, and move to
@@ -162,7 +178,8 @@ saturation, not merely prepared/approved/ready rows. Maintain a horizon
 saturation ledger per selected sender: selected send days, gross capacity,
 future scheduler-owned scheduled cells with non-null `scheduledFor`,
 ready-to-schedule buffer, remaining scheduled gap, remaining ready-or-scheduled
-gap, and the next MCP primitive that can reduce the gap. After every
+gap, `targetShapeRevision`, `stateRevision`, and the next MCP primitive that can
+reduce the gap. After every
 apply/prep/start result, wait for processing, reread refill state, recompute the
 ledger, then keep applying safe bounded actions until the scheduled count fills
 the horizon or a concrete blocker/timeout is proven. If ready rows cover the