@sellable/mcp 0.1.556 → 0.1.557

package/skills/find-leads-v2/SKILL.md

@@ -0,0 +1,70 @@
+---
+name: find-leads-v2
+description: Canonical approval-gated campaignless lead sourcing state machine.
+visibility: internal
+---
+
+# Find Leads V2
+
+This is the canonical campaignless workflow. The durable identity invariant is
+`runId = leadListId`. Resume from product state with `get_find_leads_run`; never
+reconstruct progress from chat memory.
+
+## Prerequisites and recovery
+
+- Call `get_auth_status`. If login is required, use `start_cli_login` and
+  `wait_for_cli_login` before retrying.
+- Require an active workspace. If none is active, use `list_workspaces` and
+  `set_active_workspace`.
+- If lifecycle tools, this prompt, or its flow asset are missing/outdated,
+  update the Sellable MCP/plugin, restart or reload the host, and retry.
+- Sales Nav requires a connected LinkedIn account with an active Sales Navigator search session.
+- Prospeo requires configured access and enough Prospeo credits for the bounded
+  plan.
+- Signal Discovery capacity must be available; otherwise wait or choose one of
+  the other providers.
+- For hiring-led targeting, start with `Prospeo` because its job-posting filters
+  are native. Run source work in the parent thread; do not dispatch custom source-scout subagents.
+
+## Durable flow
+
+1. `bootstrap_find_leads({ bootstrapKey, name })`, then show the returned watch
+   URL. On restart call `get_find_leads_run({ runId })`; if the link expired use
+   `reissue_find_leads_watch_link`. A deleted run/list is terminal: start a new
+   run only after explaining that recovery.
+2. Draft a compact source plan: target, provider, filters/signals, sample size,
+   import cap, fallback, and expected provider cost/capacity. Ask for explicit
+   source-plan approval. Persist it with `update_find_leads_run` action
+   `approve_source_plan`. This source-plan approval permits search only.
+3. Choose exactly one provider. Load `get_provider_prompt` for the selected provider only,
+   then call `preflight_find_leads_provider` with the current
+   run version and prompt/workflow hash. A prompt loaded for another run,
+   provider, or memory wildcard is invalid.
+4. Search/sample through `search_sales_nav`, `search_prospeo`, or
+   `search_signals`, always passing `findLeadsRunId` and current `runVersion`.
+   For Signal, persist the approved post selection with
+   `select_promising_posts` using the same run and tab.
+5. Present the bounded import plan and ask for a distinct import approval.
+   Persist `approve_import`; never treat source-plan approval as import approval.
+6. Call `import_leads` with exactly one target: `findLeadsRunId`. Pass the
+   current run version and provider search/tab receipt. Never pass a campaign
+   target on this path.
+7. Call `wait_for_lead_list_ready({ findLeadsRunId })` until ready, empty,
+   failed, or cancelled. Re-read the snapshot after timeout/retry.
+8. Review rows with `get_rows_minimal({ tableId: runId })`. For terminal empty
+   runs, export remains valid and returns a header-only CSV.
+9. Export with `export_table_csv({ tableId: runId })`. Do not create a second
+   export tool. Export failure must not mutate the run.
+
+An optional Add to Campaign action is only a suggestion after review when the
+user explicitly asks. It is never an automatic MCP step.
+
+## Terminal states
+
+- `failed`: show stable code, retryability, and exact next action. Resume the
+  same run when retryable.
+- `cancelled`: do not search or import again; review/export existing rows.
+- `ready` or `empty`: review and export.
+
+Progress extensions and background task protocols are optional host hints, not
+dependencies. Ordinary registered tools and the durable snapshot are enough.

package/skills/find-leads-v2/core/flow.v1.json

@@ -0,0 +1,31 @@
+{
+  "workflow": "find-leads-v2",
+  "version": 1,
+  "identity": "runId = leadListId",
+  "providers": {
+    "sales-nav": { "prompt": "sales-nav", "searchTool": "search_sales_nav" },
+    "prospeo": { "prompt": "prospeo", "searchTool": "search_prospeo" },
+    "signal-discovery": { "prompt": "signal-discovery", "searchTool": "search_signals" }
+  },
+  "invariants": [
+    "Resume every existing run with get_find_leads_run.",
+    "A current source-plan approval permits search only.",
+    "A distinct current import approval is required before materialization.",
+    "Load and preflight the selected provider only.",
+    "Export the source table with export_table_csv using tableId equal to runId."
+  ],
+  "states": [
+    { "id": "prerequisites", "tools": ["get_auth_status", "get_active_workspace"], "transitions": { "ready": "run_watch" } },
+    { "id": "run_watch", "tools": ["bootstrap_find_leads", "get_find_leads_run", "reissue_find_leads_watch_link"], "transitions": { "new": "source_plan", "resume_search": "search_sample", "resume_import": "materializing", "terminal": "review" } },
+    { "id": "source_plan", "transitions": { "drafted": "source_plan_approval" } },
+    { "id": "source_plan_approval", "tools": ["update_find_leads_run"], "transitions": { "approved": "provider_preflight", "cancel": "cancelled" } },
+    { "id": "provider_preflight", "tools": ["get_provider_prompt", "preflight_find_leads_provider"], "transitions": { "ready": "search_sample", "blocked": "failed" } },
+    { "id": "search_sample", "tools": ["search_sales_nav", "search_prospeo", "search_signals", "select_promising_posts"], "transitions": { "sampled": "import_plan_approval", "retryable_error": "provider_preflight", "cancel": "cancelled" } },
+    { "id": "import_plan_approval", "tools": ["update_find_leads_run"], "transitions": { "approved": "materializing", "revise": "source_plan", "cancel": "cancelled" } },
+    { "id": "materializing", "tools": ["import_leads", "wait_for_lead_list_ready", "get_find_leads_run"], "transitions": { "ready": "review", "empty": "review", "failed": "failed", "cancelled": "cancelled" } },
+    { "id": "review", "tools": ["get_rows_minimal"], "transitions": { "export": "export" } },
+    { "id": "export", "tools": ["export_table_csv"], "transitions": { "done": "review" } },
+    { "id": "failed", "tools": ["get_find_leads_run"], "transitions": { "retry": "provider_preflight", "export_existing": "export" } },
+    { "id": "cancelled", "tools": ["get_find_leads_run"], "transitions": { "review_existing": "review", "export_existing": "export" } }
+  ]
+}

package/skills/refill-sends/SKILL.md

@@ -58,97 +58,359 @@ allowed-tools:
 
 # Refill Sends
 
-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
+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:
 
 ```text
-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
+refill_sends({ yolo:false, executionMode:"scheduled", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+get_refill_target_plan({ intent:"plain", approvalMode:"mark_ready", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
 ```
-<!-- REFILL_CONTRACT_GENERATED:END -->
+
+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.

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: internal
+visibility: public
 allowed-tools:
-  - mcp__sellable__refill_sends
+  - mcp__sellable__refill_sends_v2
   - 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` is the execution surface. In real-run mode it starts or
+`refill_sends_v2` 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({ workspaceId, intent:"auto", senderIds?, approvalMode? })
+refill_sends_v2({ workspaceId, intent:"auto", senderIds?, approvalMode? })
 ```
 
 For read-only inspection:
 
 ```text
-refill_sends({ workspaceId, dryRun:true, intent:"auto", senderIds? })
+refill_sends_v2({ workspaceId, dryRun:true, intent:"auto", senderIds? })
 ```
 
 To resume an in-progress run, pass the handle back exactly:
 
 ```text
-refill_sends({ workspaceId, runId, fence })
+refill_sends_v2({ workspaceId, runId, fence })
 ```
 
 If a stale handle loses the lease, the tool reports the holder status and the