@sellable/mcp 0.1.557 → 0.1.558

package/skills/refill-sends/SKILL.md

@@ -58,359 +58,97 @@ allowed-tools:
 
 # Refill Sends
 
-Use this public command wrapper for plain operator requests such as "fill",
-"refill sends", "max out sends", "load everyone up", or "fill horizon sends".
-
-Host command names:
-
-- Claude Code: `/sellable:refill-sends`
-- Codex: `$sellable:refill-sends`
-
-Accepted invocation flags in the same user request:
-
-- `--yolo`: auto-accept the rendered bounded refill packet after the required
-  fresh state reread.
-- `workspaceId: <id>`: required for scheduled automation and `--yolo`; pass it
-  through on every refill MCP tool call instead of relying on shared config
-  state.
-- `--sender <name-or-id>`: scope to a specific sender; repeat for multiple
-  senders.
-- `--until <YYYY-MM-DD>`: fill through that sender-local date, inclusive,
-  instead of the default scheduler-forward 48-hour target window.
-- `--target-date <YYYY-MM-DD>`: fill only that sender-local date. This means
-  prepare rows for scheduler-fillable slots on that date, not every remaining
-  daily-limit slot and not an inclusive through-date.
-- `senderIds: <id>, <id>` or `senderNames: <name>, <name>`: explicit selector
-  alternatives when the host preserves natural-language arguments better than
-  shell-style flags.
-- `untilDate: YYYY-MM-DD`: explicit date selector alternative when the host
-  preserves natural-language arguments better than shell-style flags.
-- `targetDate: YYYY-MM-DD`: exact-date selector alternative when the host
-  preserves natural-language arguments better than shell-style flags.
-
-When the host can call typed MCP tools, start with:
-
-```text
-refill_sends({ yolo?: boolean, executionMode?: "manual" | "scheduled" | "yolo", requireWorkspace?: boolean, workspaceId?: string, senders?: string[], senderIds?: string[], senderNames?: string[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD" })
-```
-
-That command helper normalizes arguments and returns the execution contract. In
-non-yolo mode it does not mutate. In `--yolo`, it may execute exactly one safe
-bounded primitive from the fresh `target.globalActionQueue[0]`, then reread and
-return the new target plan; currently safe primitives are paid-credit refresh,
-existing-row message preparation, generated-message approval, receipt-proven
-same-source row copy, and read-only wait rereads. Same-source copy/source
-fallback is safe only after receipt-proven exhaustion:
-`hasMoreFrontierRows:false`, zero `approvalCandidates`, no `stuckActiveCells`,
-and no non-terminal `approvedNotDispatched` work. It does not run unbounded approval, lower
-paid-InMail thresholds, switch source families, create campaigns, launch, send,
-or write scheduler rows. Continue with the workflow below for route selection,
-state rereads, approval gating, source import, preparation, and bounded
-approval.
-
-## Workspace Contract
-
-First resolve the target workspace id from the user's request, automation config,
-or install-time workspace mapping. Pass `workspaceId` on every scheduled or
-`--yolo` refill tool call, including setup/read calls such as
-`refill_sends`, `get_refill_target_plan`, `list_senders`,
-`get_sender_routing`, `resolve_campaign_fill_route`,
-`get_campaign_refill_state`, `get_scheduler_fill_capacity`,
-`run_scheduler_sweep`, and any later refill mutation covered by the packet.
-Missing `workspaceId` in scheduled or `--yolo` mode is a blocker; stop with
-`WORKSPACE_REQUIRED` instead of running against an implicit or guessed
-workspace.
-
-Do not solve scheduled or `--yolo` workspace uncertainty by changing the shared
-active workspace. Manual interactive workspace switching remains a separate
-diagnostic/setup flow, outside automation.
-
-Examples:
-
-```text
-refill_sends({ yolo:true, executionMode:"yolo", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
-get_refill_target_plan({ intent:"plain", approvalMode:"approve", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
-list_senders({ workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
-```
-
-Clover scheduled automation must name the Clover workspace explicitly:
+This is the concise public adapter for the typed refill contract. The backend
+planner, durable run, flow asset, and contract asset own allocation, retries,
+circuit behavior, scheduler placement, and completion rules.
+
+Compatibility triggers include `fill`, `refill sends`, `max out sends`,
+`load everyone up`, and `fill horizon sends`. Route every one through this same
+typed workflow; none authorizes a broader or legacy execution path.
+
+Measure completion from canonical projected coverage (`sent + scheduled`). The
+workflow does not lower paid-InMail thresholds; a threshold change remains a
+separate operator gate.
+
+Exact zero-shot form:
+
+`$sellable:refill-sends in sellable.dev workspace --target-date YYYY-MM-DD --yolo`
+
+Claude Code uses `/sellable:refill-sends`. Optional selectors are `--sender`,
+`--target-date`, `--until`, and `--yolo`.
+
+## Bootstrap and execute
+
+1. Call `mcp__sellable__get_auth_status({})`. If authentication is incomplete,
+   use the returned login path and stop until verified.
+2. First resolve and echo the explicit workspace and date scope. In scheduled or
+   `--yolo` mode, a missing `workspaceId` is `WORKSPACE_REQUIRED`; never change
+   shared active-workspace state to guess. Echo `workspaceId`, workspace name,
+   `targetDate` or other date selector, sender selectors, action selectors, and
+   approval mode before continuing.
+3. Load
+   `mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends-workflow" })`
+   until `hasMore:false`.
+4. Load
+   `mcp__sellable__get_subskill_asset({ subskillName: "refill-sends-workflow", assetPath: "core/flow.v1.json" })`
+   until `hasMore:false`.
+5. Load
+   `mcp__sellable__get_subskill_asset({ subskillName: "refill-sends-workflow", assetPath: "core/contract.v2.json" })`
+   until `hasMore:false`. Validate `contractVersion`, `cacheVersion`, and
+   `contractHash` against the flow and generated metadata. Stop with
+   `unsupported_refill_contract_major` or `refill_contract_hash_mismatch` on
+   incompatibility; do not emulate missing assets from repo files or memory.
+6. Invoke only the public durable entrypoint:
+   `mcp__sellable__refill_sends({ workspaceId, targetDate, untilDate, horizonSendDays, senderIds, senderNames, actionTypes, yolo, executionMode, requireWorkspace:true })`.
+   Preserve the exact scope and approval echo returned by the tool on resume.
+
+## Operator packet
+
+Always render the normal bounded approval packet, even under `--yolo`. Yolo is
+bounded auto-accept of that packet; it is not broader authority. Use campaign
+and sender names first, with IDs secondary. Preserve these six labels exactly:
+
+- Need to prepare
+- Goal
+- Already sent
+- Scheduled
+- Ready and waiting to be scheduled
+- Still need
+
+Show `targetShapeRevision`, `stateRevision`, action key, exact target date,
+side-effect class, expected targets, placement cap, and approval expiry. The
+public tool runs one packet-named primitive, records its receipt, rereads
+authoritative state, and replans. Keep any existing Codex goal open through
+settling; a skill cannot create `/goal` by itself.
+
+## Safety and terminal truth
+
+The generated contract is authoritative. Never direct-send, raw-write scheduler
+fields, create/archive/delete campaigns, lower thresholds, switch an unselected
+source family, mutate sender configuration, or start an unapproved campaign.
+Paused campaign start and workspace-wide scheduler placement remain separately
+named, product-gated side effects. Sellable MCP receipts are the proof surface;
+never use Prisma, SQL, direct database access, or production scripts as proof.
+
+Render typed terminal truth name-first. Success is `projected_full`. Otherwise
+report the concrete blocker or `deadline_reached`, `iteration_limit`, or
+`operator_stopped` with target-specific evidence. A ready buffer or
+`awaiting_scheduler_after_ready_buffer` is
+`ready_buffer_exists_is_not_complete`, never completion.
+
+<!-- REFILL_CONTRACT_GENERATED:START -->
+## Generated refill contract metadata
+
+contractVersion: 2.0.0
+cacheVersion: refill-contract-v1
+contractHash: e54ba0f80bc534fd70fd8c10c1caab109fe9a91c205cfc423f5f6735cd53fdc1
 
 ```text
-refill_sends({ yolo:false, executionMode:"scheduled", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
-get_refill_target_plan({ intent:"plain", approvalMode:"mark_ready", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+scope: workspace_id, target_date, sender_selectors, campaign_selectors, approval_mode, contract_identity, installed_identity
+gates: approval_packet, one_primitive, fresh_reread, normalized_accounting, prep_circuit
+release identities (independent of semantic hash): mcpPackageVersion, installPackageVersion, codexPluginVersion
+forbidden: direct_send, raw_scheduler_write, campaign_create, campaign_archive_delete, threshold_lowering, unselected_source_mutation, unapproved_campaign_start, sender_config_write
+terminal: projected_full, concrete_blocker, deadline_reached, iteration_limit, operator_stopped, capped_by_scheduler, loaded_awaiting_scheduler, lanes_exhausted, not_an_evergreen_workspace, no_refillable_campaigns
+ready_buffer_exists_is_not_complete
 ```
-
-First call `get_auth_status({})`. If auth is not OK, follow the returned login
-guidance before route resolution. Do not run refill research against an implicit
-or guessed workspace.
-
-Treat "refill senders", "fill senders", "load everyone up", and "max out
-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 filled by projected coverage
-(`sent + scheduled`) for the scheduler-forward target window, 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`; treat it as loaded, awaiting scheduler.
-
-Load the internal workflow prompt and deterministic flow asset before taking
-any operational step:
-
-```text
-get_subskill_prompt({ subskillName: "refill-sends-workflow" })
-get_subskill_asset({ subskillName: "refill-sends-workflow", assetPath: "core/flow.v1.json" })
-```
-
-Continue both loads until `hasMore:false`; parse the flow JSON and verify
-`workflow:"refill-sends-workflow"` with a `v1` version. Then follow that
-workflow exactly. The default path is read-only research: 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:
-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`. Refill target lanes are
-connection invites (`send_invite`), standalone paid InMails
-(`send_inmail_closed`), or unified Sales Nav cascades represented publicly as
-`send_inmail_closed` with `campaignClassification:"sales_nav_cascade"`. For a
-Sales Nav cascade, refill the selected campaign first; its sequence can route
-prospects to Open InMail, paid InMail while fresh credits are >= 5, or
-same-campaign connection fallback without asking for separate open/paid/
-connection campaigns. DMs (`send_dm`) are follow-up actions, 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 lane
-rather than asking which campaign class to fill. If a stale target plan selects
-`send_dm` or `send_inmail_open` as the lane, stop and re-plan with the current
-planner before mutation.
-Short form: trust the target plan's inferred lane when it is a connection invite,
-paid-InMail refill lane, or unified Sales Nav cascade.
-Connection-only evergreen campaigns with exact `["send_invite"]` sequence proof
-are plain invite capacity: treat them as `selectedLane:"send_invite"` only. Do
-not infer DM, InMail, Sales Nav cascade, paid-credit refresh, message
-generation, follow-up, sequence mutation, launch/start, scheduling override, or
-direct-send work from a connection-only lane.
-
-Structured planner packet:
-
-- `target.eligibleSenderLedger` is the public sender eligibility ledger.
-- `target.senderRefillPlans[]` is the canonical sender-level packet; read and
-  display it before mutation.
-- Each sender packet includes `campaignRanking.options`, `sourcePlan`,
-  `refillReceipt`, `nextActions`, and `manualAlternates`.
-- `refillReceipt` is the public ladder receipt. It carries the selected
-  campaign/sender/lane summary, skipped rungs, existing-row frontier proof, and
-  any absolute `wait.deadlineAt`.
-- Preserve these coverage labels exactly: `Need to prepare`, `Goal`,
-  `Already sent`, `Scheduled`, `Ready and waiting to be scheduled`, and
-  `Still need`.
-- `target.globalActionQueue` is the only cross-sender yolo execution queue.
-  Execute exactly one globally ranked primitive from
-  `target.globalActionQueue[0]`, then rerun `get_refill_target_plan` with the
-  same `workspaceId` before
-  choosing another action.
-- `manualAlternates` are not yolo actions. Threshold lowering and campaign
-  creation are manual continuations only.
-
-Refill action ladder: approve generated rows only when an explicit bounded
-approval gate exists, process all existing same-campaign unenriched/unprepared
-rows in bounded batches before any source work, then copy bounded net-new rows
-from the selected source (`selectedLeadListId`, provider, and source
-fingerprint preserved), then use provider-aligned source-more. A new source or
-provider switch changes the reply-rate baseline and is a manual alternate, not a
-`--yolo` side effect.
-Source/copy/fallback requires receipt-proven exhaustion of earlier rungs:
-`existingRowFrontier.hasMoreFrontierRows:false`, zero `approvalCandidates`, no
-fresh active prep, no `stuckActiveCells`, and no non-terminal
-`approvedNotDispatched` rows. Treat anomalies, `stuckActiveCells`, and
-non-terminal `approvedNotDispatched` as diagnose-and-report gates, not
-exhaustion. Terminal `approvedNotDispatched` blockers may be reported, then the
-ladder can proceed.
-
-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/source-copy/bounded-approval/read-only wait action. If fresh facts are still below
-threshold, below-threshold paid-InMail facts fall back to an existing connection
-lane, the same Sales Nav cascade campaign's connection branch, or a manual
-continuation.
-
-Freshness gate precedes scheduler wait: if any selected
-`target.senderRefillPlans[].paidInmail.status` is `missing_credit_facts` or
-`stale_credit_facts`, or the target plan contains a
-`refresh_paid_inmail_credits` candidate, do not enter `wait_for_scheduler` even
-when `remainingReadyOrProjectedGap:0`. Refresh the exact selected sender credit
-facts once, rerun `get_refill_target_plan`, and only then decide whether
-scheduler wait is the next safe action. If facts remain missing/stale after the
-single refresh attempt, stop with a paid-InMail freshness blocker instead of
-waiting on scheduler pickup.
-The standalone MCP refresh surface is the scoped route
-`/api/v3/mcp/senders/:senderId/refresh-inmail-credits` with explicit
-`workspaceId`; do not use active-workspace mutation as the automation control
-path.
-
-Compact refill lessons: sender-level target plan is final truth; trust
-`schedulerGate.sendable` and scheduler gate blockers, not raw
-`unipileAccountStatus` labels alone; use compact prep status checks for
-long-running jobs; reread target plans after prep or cancel; treat ready rows as
-intermediate; avoid huge parallel target-plan reads when output is large. If a
-campaign produces prepared/ready rows but sender-level projected coverage does
-not move after one bounded settle loop, pivot to compact prep status or a
-scheduler-proven lane. Do not keep waiting on campaign-level ready counts.
-
-For exact-date requests, pass `targetDate` to `get_refill_target_plan`. If you
-need raw proof, call the read-only `get_scheduler_fill_capacity` query for the
-same sender/action/date; it tells the MCP how many cells the product scheduler
-will try to place and does not import, approve, schedule, refresh credits, or
-mutate.
-When the refill loop has ready rows and needs scheduler pickup now, use
-`run_scheduler_sweep` with the same explicit `workspaceId`; it can place cells
-within existing scheduler gates and returns the receipt, but it never sends or
-bypasses limits.
-Scheduler-run receipt interpretation: `cellsConsidered is allocation-attempt
-count`, not total ready supply, while `readyCellsFound` is ready inventory found
-before prefilters. Inspect `campaignScopeSummary` before assuming the selected
-refill campaign/table was included; if absent, do not infer that target was
-ready-but-blocked. Interpret `prefiltered` as ready cells removed before
-allocation, `skipped` as considered cells blocked by scheduler gates, and
-`deferred` as considered cells waiting on windows/capacity/cooldown. For ready
-closed-InMail cells with stale paid-credit prefilter/defer reasons, refresh
-paid-InMail credits once through existing tools, then rerun `run_scheduler_sweep`
-or read `action:"status"`; `refresh_paid_inmail_credits_then_rerun` is that
-path. `wait_for_capacity_or_window` means report loaded/capped/waiting and do
-not source or prep more rows; `no_ready_cells_continue_refill_prep` means return
-to the refill/prep ladder. Do not treat `cellsScheduled:0` alone as failure.
-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, paid InMail credit facts are fresh for every
-selected paid-InMail lane, 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.
-Wait actions are gates, not competing goals. When `wait_for_active_work` or
-`wait_for_scheduler` includes receipt `wait.deadlineAt`, honor that absolute
-deadline; if it is expired on this call, escalate to diagnostics with the
-receipt evidence instead of issuing another blind wait.
-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`. Do not present paid-credit refresh as the next operator
-action after `refill_sends` returns `autoPaidInmailRefresh` and the
-post-refresh `targetPlan`. 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 same-campaign 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
-the named sender, immediately run the active route refetch before declaring a
-sender blocked. Current dashboard-active `PAUSED` campaign-backed sequence
-campaigns are start-eligible refill candidates; read refill state before deciding
-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, not plain chat:
-
-- Codex: use `request_user_input`.
-- Claude Code: use `AskUserQuestion`.
-
-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. 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
-reread. For sender-scoped language with no named senders, `--yolo` means all
-eligible healthy senders enrolled in active campaign-backed sequence campaigns in
-the requested `workspaceId`. Without `--yolo`, if Christian did not name senders, ask
-which eligible enrolled senders to refill before choosing campaigns or mutating.
-
-`--yolo` only covers the exact sender set, per-sender target campaigns, caps,
-approval mode, and side effects in the packet. It may authorize `start_campaign`
-only for selected `PAUSED`, dashboard-active, campaign-backed sequence refill
-targets when the rendered packet names the exact campaign ids and start side
-effect. Starting a paused campaign can let the product scheduler schedule/send
-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, 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
-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/source-copy/bounded-approval/read-only wait result, reread state, settle processing when needed, and move to
-the next selected sender or start-eligible same-packet campaign instead of
-stopping after the first partial result. If no in-packet safe action remains,
-return concrete continuation options with campaign names, exact ids, which option
-is still covered by the current packet, and which option needs a new approval
-packet.
-
-For `--yolo` fill/schedule requests, completion means projected saturation
-(`sent + scheduled`) for the scheduler-forward target window, not merely
-prepared/approved/ready rows. Maintain a target-window saturation ledger per
-selected sender: selected send days, gross capacity, actual sent cells, future
-scheduler-owned scheduled cells with non-null `scheduledFor`, projected count,
-ready-to-schedule buffer, remaining projected gap, paid-InMail feasibility,
-`targetShapeRevision`, `stateRevision`, and the next MCP primitive that can
-reduce the gap. After every apply/prep/source-copy/bounded-approval/read-only wait result, wait for processing, reread
-the target plan/refill state, recompute the ledger, then keep applying safe
-bounded actions until projected coverage fills the target window or a concrete
-non-scheduler blocker is proven.
-If ready rows cover the projected gap but the scheduler has not picked them up
-yet, report loaded, awaiting scheduler and 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 fill target is the scheduler-forward 48-hour window
-unless `--target-date`/`targetDate`, `--until`/`untilDate`, or an explicit
-compatibility `horizonSendDays` is provided. If a target date is provided,
-compute bounded gaps for only that sender-local date using scheduler-fillable
-slots. If an until date is provided, compute bounded gaps through that
-sender-local date inclusive, skipping no-send days and never extending beyond
-that date without a new packet. For each target sender, compute the bounded gap
-from that sender's healthy daily capacity, existing future scheduler-owned
-scheduled sends, and rows already ready to schedule across active campaigns
-enrolled with that sender. Then pick the best same-sender campaign to fill the
-gap: prefer recent/future scheduler-owned sends for that sender, then strongest
-recent result evidence, then source health. Do not stop
-after filling only one sender when the request was sender-scoped. If a
-same-source copy hits the campaign-table row cap, split the current source into
-a bounded LinkedIn profile source list, confirm only that smaller list into the
-same campaign, and operate on the copied review batch. Do not fall back to
-on-demand campaigns or unrelated active-campaign fills.
-
-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.
+<!-- REFILL_CONTRACT_GENERATED:END -->

package/skills/refill-sends-v2/SKILL.md

@@ -1,9 +1,9 @@
 ---
 name: refill-sends-v2
 description: Execute refill sends v2 through the fenced evergreen refill loop, with dry-run and resume support.
-visibility: public
+visibility: internal
 allowed-tools:
-  - mcp__sellable__refill_sends_v2
+  - mcp__sellable__refill_sends
   - mcp__sellable__get_refill_plan_v2
   - mcp__sellable__get_subskill_prompt
   - mcp__sellable__get_subskill_asset
@@ -24,7 +24,7 @@ Host command names:
 - Claude Code: `/sellable:refill-sends-v2`
 - Codex: `$sellable:refill-sends-v2`
 
-`refill_sends_v2` is the execution surface. In real-run mode it starts or
+`refill_sends` is the execution surface. In real-run mode it starts or
 resumes a fenced refill run, reads a fresh packet, executes only the packet's
 named bounded work, verifies the result, and returns either a terminal report, a
 blocked report, or an in-progress resume handle. In dry-run mode it stays
@@ -40,19 +40,19 @@ with `WORKSPACE_REQUIRED`; do not switch the shared active workspace.
 For a real refill run:
 
 ```text
-refill_sends_v2({ workspaceId, intent:"auto", senderIds?, approvalMode? })
+refill_sends({ workspaceId, intent:"auto", senderIds?, approvalMode? })
 ```
 
 For read-only inspection:
 
 ```text
-refill_sends_v2({ workspaceId, dryRun:true, intent:"auto", senderIds? })
+refill_sends({ workspaceId, dryRun:true, intent:"auto", senderIds? })
 ```
 
 To resume an in-progress run, pass the handle back exactly:
 
 ```text
-refill_sends_v2({ workspaceId, runId, fence })
+refill_sends({ workspaceId, runId, fence })
 ```
 
 If a stale handle loses the lease, the tool reports the holder status and the

package/skills/refill-sends-v2-workflow/SKILL.md

@@ -3,7 +3,7 @@ name: refill-sends-v2-workflow
 description: Internal execution workflow for refill sends v2 fenced runs.
 visibility: internal
 allowed-tools:
-  - mcp__sellable__refill_sends_v2
+  - mcp__sellable__refill_sends
   - mcp__sellable__get_refill_plan_v2
   - mcp__sellable__get_subskill_prompt
   - mcp__sellable__get_subskill_asset
@@ -16,7 +16,7 @@ allowed-tools:
 # Refill Sends V2 Workflow
 
 This internal workflow mirrors the run-record gates enforced by
-`refill_sends_v2`: bootstrap, plan, execute, verify, and report. Dry runs stay
+`refill_sends`: bootstrap, plan, execute, verify, and report. Dry runs stay
 read-only. Real runs execute only packet-named bounded work under a fenced run
 lease and return terminal, blocked, or in-progress results.
 
@@ -25,7 +25,7 @@ Runtime flow asset: after loading this prompt, load
 through MCP, continue chunks until `hasMore:false`, parse the JSON, and verify
 `workflow:"refill-sends-v2-workflow"` with a `v1` version before driving the
 loop. If the asset cannot load or parse, stop with
-`blocked:refill_sends_v2_workflow_asset_unavailable`; do not emulate it from
+`blocked:refill_sends_workflow_asset_unavailable`; do not emulate it from
 local files or memory.
 
 ## G0 Bootstrap
@@ -36,7 +36,7 @@ Scheduled or autonomous runs must not rely on implicit workspace state.
 Start or resume the execution loop:
 
 ```text
-refill_sends_v2({ workspaceId, intent:"auto", senderIds?, approvalMode?, runId?, fence? })
+refill_sends({ workspaceId, intent:"auto", senderIds?, approvalMode?, runId?, fence? })
 ```
 
 Use `dryRun:true` only when the user asked for read-only inspection. A dry run
@@ -121,7 +121,7 @@ outcome, then verifies before replanning.
 - Capped scheduler capacity is complete.
 
 Scheduler wait is cross-invocation. If the tool returns `in_progress` with
-sweep guidance, re-invoke `refill_sends_v2` with `{runId, fence}`. The scheduler
+sweep guidance, re-invoke `refill_sends` with `{runId, fence}`. The scheduler
 budget is cumulative at the run level. Zero pickup after a confirmed sweep is
 debugged from `pipelineDiagnosis`; it is not waited out forever.
 Scheduler-run receipt interpretation still applies to terminal progress:

package/skills/refill-sends-v2-workflow/core/flow.v1.json

@@ -65,7 +65,7 @@
       "purpose": "Resolve explicit workspace evidence when the request did not provide workspaceId."
     },
     {
-      "tool": "refill_sends_v2",
+      "tool": "refill_sends",
       "requiredValues": {
         "workspaceId": "{workspaceId}"
       },
@@ -133,7 +133,7 @@
         "get_active_workspace",
         "list_workspaces",
         "get_workspace",
-        "refill_sends_v2",
+        "refill_sends",
         "get_subskill_prompt",
         "get_subskill_asset",
         "get_refill_plan_v2"
@@ -143,7 +143,7 @@
           "tool": "get_auth_status"
         },
         {
-          "tool": "refill_sends_v2",
+          "tool": "refill_sends",
           "requiredFields": ["workspaceId"]
         },
         {
@@ -281,9 +281,9 @@
     },
     {
       "id": "execute",
-      "description": "Execute exactly the packet head action through refill_sends_v2 internals. Bounded approvals, message preparation, same-source copies, rerun_errored_cells, saved signal continuations, paid-credit refreshes, and pinned-lane starts are allowed only when named by the packet. Execute only the fingerprint captured at the last plan gate; stale packets refuse and return to plan.",
+      "description": "Execute exactly the packet head action through refill_sends internals. Bounded approvals, message preparation, same-source copies, rerun_errored_cells, saved signal continuations, paid-credit refreshes, and pinned-lane starts are allowed only when named by the packet. Execute only the fingerprint captured at the last plan gate; stale packets refuse and return to plan.",
       "allowedTools": [
-        "refill_sends_v2",
+        "refill_sends",
         "start_campaign_message_preparation",
         "confirm_lead_list",
         "import_leads",
@@ -313,11 +313,11 @@
     },
     {
       "id": "verify",
-      "description": "Verify whole-row outcomes before another plan read. Reattach to an own active prep job by requestSource/requestHash; never re-dispatch prep while a matching job is active. Foreign prep waits until clear or blocks foreign_prep_active. wait_for_active_work and wait_for_source_import reread the plan on bounded cadence. wait_for_scheduler is cross-invocation: each tool call polls briefly under the host guard, heartbeats the lease, and returns in_progress sweep guidance so the agent re-invokes refill_sends_v2 with {runId,fence}. The approximately five minute scheduler budget is cumulative at the run level.",
-      "allowedTools": ["refill_sends_v2", "get_refill_plan_v2"],
+      "description": "Verify whole-row outcomes before another plan read. Reattach to an own active prep job by requestSource/requestHash; never re-dispatch prep while a matching job is active. Foreign prep waits until clear or blocks foreign_prep_active. wait_for_active_work and wait_for_source_import reread the plan on bounded cadence. wait_for_scheduler is cross-invocation: each tool call polls briefly under the host guard, heartbeats the lease, and returns in_progress sweep guidance so the agent re-invokes refill_sends with {runId,fence}. The approximately five minute scheduler budget is cumulative at the run level.",
+      "allowedTools": ["refill_sends", "get_refill_plan_v2"],
       "onEnter": [
         {
-          "tool": "refill_sends_v2",
+          "tool": "refill_sends",
           "requiredFields": ["workspaceId", "runId", "fence"]
         }
       ],