@sellable/install 0.1.220 → 0.1.222

package/bin/sellable-install.mjs

@@ -991,8 +991,8 @@ const CREATE_CAMPAIGN_ALLOWED_TOOLS = [
   "mcp__sellable__record_campaign_review_batch",
   "mcp__sellable__queue_campaign_cells",
   "mcp__sellable__wait_for_campaign_processing",
-  "mcp__sellable__refill_campaign_sends",
   "mcp__sellable__resolve_campaign_fill_route",
+  "mcp__sellable__get_campaign_refill_state",
   "mcp__sellable__fill_campaign_horizon",
   "mcp__sellable__start_campaign_message_preparation",
   "mcp__sellable__get_campaign_message_preparation_status",

package/lib/runtime-verify.mjs

@@ -28,14 +28,16 @@ export const REQUIRED_SELLABLE_MCP_TOOLS = [
   "get_campaign_messages_preview",
   "attach_sequence",
   "attach_recommended_sequence",
-  "refill_campaign_sends",
   "resolve_campaign_fill_route",
+  "get_campaign_refill_state",
   "start_campaign_message_preparation",
   "get_campaign_message_preparation_status",
   "cancel_campaign_message_preparation",
   "start_campaign",
 ];
 
+export const FORBIDDEN_SELLABLE_MCP_TOOLS = ["refill_campaign_sends"];
+
 export const CREATE_CAMPAIGN_SMOKE_CALLS = [
   {
     name: "get_auth_status",
@@ -59,6 +61,14 @@ export const CREATE_CAMPAIGN_SMOKE_CALLS = [
       limit: 1200,
     },
   },
+  {
+    name: "get_subskill_prompt",
+    arguments: {
+      subskillName: "refill-sends-workflow",
+      offset: 0,
+      limit: 1200,
+    },
+  },
   {
     name: "get_subskill_asset",
     arguments: {
@@ -310,6 +320,7 @@ function summarizeAttempt(result, attempt) {
     ok: result.ok === true,
     availableToolCount: result.availableTools?.length || 0,
     missingToolCount: result.missingTools?.length || 0,
+    forbiddenToolCount: result.forbiddenTools?.length || 0,
     error: result.error || null,
     createCampaignSmoke: result.createCampaignSmoke
       ? {
@@ -379,6 +390,7 @@ async function verifySellableMcpRuntimeOnce({
 
   let availableTools = [];
   let missingTools = [...requiredTools];
+  let forbiddenTools = [];
   let createCampaignSmoke = null;
   let error = null;
 
@@ -390,7 +402,19 @@ async function verifySellableMcpRuntimeOnce({
     });
     availableTools = toolList.tools.map((tool) => tool.name).sort();
     missingTools = missingRequiredTools(toolList.tools, requiredTools);
-    if (missingTools.length === 0) {
+    forbiddenTools = availableTools.filter((tool) =>
+      FORBIDDEN_SELLABLE_MCP_TOOLS.includes(tool)
+    );
+    if (forbiddenTools.length > 0) {
+      createCampaignSmoke = {
+        ok: false,
+        missingTools: [],
+        calls: [],
+        error: `Forbidden MCP tool(s) exposed: ${forbiddenTools.join(", ")}`,
+        startedAt: new Date().toISOString(),
+        completedAt: new Date().toISOString(),
+      };
+    } else if (missingTools.length === 0) {
       createCampaignSmoke = await verifyCreateCampaignSmoke({
         client,
         availableTools,
@@ -420,13 +444,18 @@ async function verifySellableMcpRuntimeOnce({
   }
 
   return {
-    ok: !error && missingTools.length === 0 && createCampaignSmoke?.ok === true,
+    ok:
+      !error &&
+      missingTools.length === 0 &&
+      forbiddenTools.length === 0 &&
+      createCampaignSmoke?.ok === true,
     skipped: false,
     command,
     args,
     requiredTools,
     availableTools,
     missingTools,
+    forbiddenTools,
     createCampaignSmoke,
     stderrTail: stderrLines,
     error: error ? redact(error) : null,

package/package.json

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

package/skill-templates/create-campaign.md

@@ -47,8 +47,8 @@ allowed-tools:
   - mcp__sellable__record_campaign_review_batch
   - mcp__sellable__queue_campaign_cells
   - mcp__sellable__wait_for_campaign_processing
-  - mcp__sellable__refill_campaign_sends
   - mcp__sellable__resolve_campaign_fill_route
+  - mcp__sellable__get_campaign_refill_state
   - mcp__sellable__fill_campaign_horizon
   - mcp__sellable__start_campaign_message_preparation
   - mcp__sellable__get_campaign_message_preparation_status
@@ -118,44 +118,38 @@ The default path stays the existing first campaign-table execution slice:
 review the normal `reviewBatchLimit:15`, approve reviewed draft rows, then move
 to Settings/sequence/final greenlight. For any plain post-mint fill request
 such as "fill campaigns", "fill up", "refill sends", "max out sends", or
-"load sends", first call `refill_campaign_sends({ mode:"plan", intent:"plain" })`.
-If the user did not include `--yolo`, report the plan and stop. If the user did
-include `--yolo`, call plan first, inspect blockers, then call
-`refill_campaign_sends({ mode:"apply", yolo:true, planRevision, actionIds })`
-using only the selected immutable action IDs from the fresh plan. Plain fill is
-not an alias for `fill_campaign_horizon` or campaign creation. Keep
-`resolve_campaign_fill_route`, `fill_campaign_horizon`, and
-`start_campaign_message_preparation` as fallback/lower-level diagnostics only
-when `refill_campaign_sends` is unavailable or when the refill command itself
-returns an evergreen subplan. `fill_campaign_horizon` is evergreen-only and
-must not be used for regular campaign refill. When more leads are needed, the
-plan must recommend same-campaign source-ladder replenishment; do not create
-warm-post-engager side campaigns, on-demand campaigns, or unrelated campaigns.
-If fallback `resolve_campaign_fill_route` returns `route:"ask_create"`, ask
-whether to create a normal campaign or evergreen campaigns; campaign creation is
-never the default response to plain fill.
+"load sends", hand off to the skill-led refill workflow:
+
+```text
+get_subskill_prompt({ subskillName: "refill-sends-workflow" })
+resolve_campaign_fill_route({ intent:"plain" })
+get_campaign_refill_state
+```
+
+Plain fill is not an alias for `fill_campaign_horizon` or campaign creation.
+`fill_campaign_horizon` is evergreen-only and must not be used for regular
+campaign refill. Route outcomes are `route:"evergreen_horizon"`,
+`route:"active_campaigns"`, and `route:"ask_create"`; stay in the same `campaignOfferId`/`campaignId` context after minting. If route resolution
+returns `route:"ask_create"`, ask whether to create a normal campaign or
+evergreen campaigns. Campaign creation is allowed only after this route and
+explicit user selection; it is never the default response to plain fill. When
+more leads are needed, the refill workflow must recommend same-campaign
+source-ladder replenishment; do not create warm-post-engager side campaigns,
+on-demand campaigns, or unrelated campaigns. Surface sender-health blockers
+separately from prepared/approved/scheduled counts.
+
 Treat active fills as capacity-fill preparation: calculate the bounded target
-from sender capacity when needed, then let the preparation job queue pending
-`Enrich Prospect` cells, wait for ICP/rubric and Generate Message cells to
-cascade, and mark ready or approve only the target cohort. Do not count
-`checkedRows` as enriched rows; it is only the table cursor. Use
-`progress.enrichedRows`, `progress.needsEnrichRows`, `activeCellCount`,
-`preparedMessages`, `approvedRows`, active preparation jobs, sender-health
-blockers, target, estimated row budget remaining, and `stopReason` to explain
-progress. If the user says "prepare/generate X messages", set
-`targetPreparedMessages:X`, omit `maxRowsToCheck`, and keep
-`approvalMode:"mark_ready"`. The backend calibrates on at least 100 actually
-enriched rows, estimates the row budget from observed rubric/pass yield, caps
-`maxRowsToCheck` at 300, then continues in batches capped at 100 newly checked
-rows. It will not pull another row batch while the current checked batch still
-has queueable or active cells. If the user says "approve X messages", use
-`approvalMode:"approve"` but still do not launch. If the user says "schedule X
-sends" or asks to fill sender sends, use `approvalMode:"approve"` only when
-the user explicitly asked for approval, approve exactly the bounded X-message
-cohort during preparation, then re-read scheduled counts; if scheduler-owned
-cells are not present, report prepared/approved/ready awaiting scheduler
-instead of success. Final launch remains a separate explicit user greenlight
-and must verify that bounded cohort and must not broad approve-all.
+from sender capacity when needed, then use the refill workflow to decide source
+replenishment, enrichment/prep, approval policy, and scheduler proof. Mutation
+requires exact visible approval and a fresh `get_campaign_refill_state` reread.
+If the user says "prepare/generate X messages", use message-prep primitives with
+`targetPreparedMessages:X` and default `approvalMode:"mark_ready"`. If the user
+says "approve X messages", use `approvalMode:"approve"` only for the bounded
+cohort and still do not launch. If the user says "schedule X sends", approve
+only when explicitly requested, then reread scheduled counts; if
+scheduler-owned cells are not present, report prepared/approved/ready awaiting
+scheduler instead of success. Final launch remains a separate explicit user
+greenlight and must not broad approve-all.
 When approving reviewed draft rows in the campaign table, resolve the actual
 visible `Approved` cells with `select_campaign_cells({ columnRole: "approved",
 rowSelector: { type: "rowIds", rowIds } })` and `update_cell` those returned

package/skill-templates/refill-sends.md

@@ -0,0 +1,54 @@
+---
+name: refill-sends
+description: Plan regular campaign and evergreen campaign send refill work through the skill-led refill workflow.
+visibility: public
+allowed-tools:
+  - mcp__sellable__get_subskill_prompt
+  - mcp__sellable__search_subskill_prompts
+  - mcp__sellable__resolve_campaign_fill_route
+  - mcp__sellable__get_campaign_refill_state
+  - mcp__sellable__fill_campaign_horizon
+  - mcp__sellable__get_campaign
+  - mcp__sellable__get_campaign_message_preparation_status
+  - mcp__sellable__start_campaign_message_preparation
+  - mcp__sellable__cancel_campaign_message_preparation
+  - mcp__sellable__import_leads
+  - mcp__sellable__wait_for_lead_list_ready
+  - mcp__sellable__confirm_lead_list
+  - mcp__sellable__search_signals
+  - mcp__sellable__fetch_post_engagers
+  - mcp__sellable__search_sales_nav
+  - mcp__sellable__lookup_sales_nav_filter
+  - mcp__sellable__search_prospeo
+  - mcp__sellable__search_prospeo_companies
+  - mcp__sellable__confirm_prospeo_company_accounts
+  - mcp__sellable__load_csv_linkedin_leads
+  - mcp__sellable__load_csv_domains
+  - mcp__sellable__list_dnc_entries
+  - mcp__sellable__load_csv_dnc_entries
+  - mcp__sellable__get_rows
+  - mcp__sellable__get_rows_minimal
+  - mcp__sellable__get_table_rows
+---
+
+# Refill Sends
+
+Use this public wrapper for plain operator requests such as "fill", "refill sends",
+"max out sends", "load everyone up", or "fill horizon sends".
+
+Load the internal workflow prompt before taking any operational step:
+
+```text
+get_subskill_prompt({ subskillName: "refill-sends-workflow" })
+```
+
+Then follow that workflow exactly. The default path is read-only research:
+resolve the route, read target refill state, report the next safe step, 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.
+
+Public concepts are regular campaign and evergreen campaign. Internal direct
+campaign types are unsupported refill targets. `fill_campaign_horizon` is only a
+legacy evergreen-only lower-level primitive after route and refill-state
+evidence proves an evergreen target.