@sellable/install 0.1.298 → 0.1.300

package/bin/sellable-install.mjs

@@ -1059,7 +1059,10 @@ const REFILL_SENDS_ALLOWED_TOOLS = [
   "mcp__sellable__list_workspaces",
   "mcp__sellable__set_active_workspace",
   "mcp__sellable__get_subskill_prompt",
+  "mcp__sellable__get_subskill_asset",
   "mcp__sellable__search_subskill_prompts",
+  "mcp__sellable__get_scheduler_fill_capacity",
+  "mcp__sellable__refresh_paid_inmail_credits",
   "mcp__sellable__list_senders",
   "mcp__sellable__get_sender_routing",
   "mcp__sellable__get_campaign_waterfall",
@@ -1999,12 +2002,21 @@ Desktop, then start a new thread.
 ## Execute Workflow
 
 1. Call \`mcp__sellable__get_auth_status({})\`.
-2. Normalize invocation arguments with \`mcp__sellable__refill_sends({ yolo, senders, senderIds, senderNames, targetDate, untilDate })\` when the host exposes typed MCP tools.
-3. Call \`mcp__sellable__get_refill_target_plan({ senders, senderIds, senderNames, targetDate, untilDate })\` before any mutation. Render \`target.eligibleSenderLedger\`, \`target.senderRefillPlans[]\`, and \`target.globalActionQueue\` as the structured packet. Preserve the labels \`Need to prepare\`, \`Goal\`, \`Already sent\`, \`Scheduled\`, \`Ready and waiting to be scheduled\`, and \`Still need\`. In \`--yolo\`, \`mcp__sellable__refill_sends\` maintains a run-local \`refreshedPaidInmailSenderIds\` set, refreshes stale/missing paid InMail facts for each selected paid-InMail sender at most once, reruns \`get_refill_target_plan\`, and returns \`autoPaidInmailRefresh\` plus the post-refresh \`targetPlan\` before choosing the next prep/approval/start action. Do not present paid-credit refresh as the next operator action after \`refill_sends\` returns that post-refresh plan. For exact-date proof, \`mcp__sellable__get_scheduler_fill_capacity\` is read-only and tells how many cells the scheduler will try to place for a sender/action/date. If the returned target is already complete, stop with the no-op receipt. If ready rows cover the target but scheduled rows do not, keep the run open in the read-only scheduler wait/re-read loop until projected coverage fills, a concrete non-scheduler blocker appears, or Christian explicitly stops/statuses the run.
-4. Load the canonical prompt via
+2. Resolve the target workspace id from the user request, automation config, or install-time workspace mapping. Pass \`workspaceId\` on every scheduled or \`--yolo\` refill tool call. Missing \`workspaceId\` in scheduled or \`--yolo\` mode is a blocker; return \`WORKSPACE_REQUIRED\` instead of running against shared config state. Do not solve automation workspace uncertainty by changing the shared active workspace.
+3. Normalize invocation arguments with \`mcp__sellable__refill_sends({ yolo, executionMode, requireWorkspace, workspaceId, senders, senderIds, senderNames, targetDate, untilDate })\` when the host exposes typed MCP tools. Type shape: \`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" })\`.
+4. Clover scheduled automation example: \`mcp__sellable__refill_sends({ yolo:false, executionMode:"scheduled", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })\`, then \`mcp__sellable__get_refill_target_plan({ intent:"plain", approvalMode:"mark_ready", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })\`.
+5. Call \`mcp__sellable__get_refill_target_plan({ workspaceId, senders, senderIds, senderNames, targetDate, untilDate })\` before any mutation. Render \`target.eligibleSenderLedger\`, \`target.senderRefillPlans[]\`, and \`target.globalActionQueue\` as the structured packet. Preserve the labels \`Need to prepare\`, \`Goal\`, \`Already sent\`, \`Scheduled\`, \`Ready and waiting to be scheduled\`, and \`Still need\`. In \`--yolo\`, \`mcp__sellable__refill_sends\` maintains a run-local \`refreshedPaidInmailSenderIds\` set, refreshes stale/missing paid InMail facts for each selected paid-InMail sender at most once, reruns \`get_refill_target_plan\`, and returns \`autoPaidInmailRefresh\` plus the post-refresh \`targetPlan\` before choosing the next prep/source-copy/bounded-approval/read-only wait action. Refill ladder: approve generated rows only through the explicit bounded approval gate, process existing same-campaign unenriched/unprepared rows before source work, then same-source copy, then provider-aligned source-more. New source/provider switches change reply-rate baseline and are manual alternates, not \`--yolo\` side effects. Do not present paid-credit refresh as the next operator action after \`refill_sends\` returns that post-refresh plan. For exact-date proof, \`mcp__sellable__get_scheduler_fill_capacity\` is read-only and tells how many cells the scheduler will try to place for a sender/action/date. If the returned target is already complete, stop with the no-op receipt. If ready rows cover the target but scheduled rows do not, keep the run open in the read-only scheduler wait/re-read loop until projected coverage fills, a concrete non-scheduler blocker appears, or Christian explicitly stops/statuses the run.
+6. Load the canonical prompt and deterministic flow asset via
    \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends" })\`,
-   then load \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends-workflow" })\`.
-5. Follow the canonical prompt exactly. Do not launch, start, archive, delete,
+   then load \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends-workflow" })\`,
+   then load \`mcp__sellable__get_subskill_asset({ subskillName: "refill-sends-workflow", assetPath: "core/flow.v1.json" })\`.
+   Continue prompt and asset loads until \`hasMore:false\`; parse the flow JSON
+   and verify \`workflow:"refill-sends-workflow"\` with a \`v1\` version.
+   Freshness gate precedes scheduler wait: when stale or missing paid-credit
+   facts are present, refresh exact selected sender facts once, rerun
+   \`get_refill_target_plan\`, and only then enter \`wait_for_scheduler\` if
+   freshness is clean.
+7. Follow the canonical prompt exactly. Do not launch, start, archive, delete,
    or write scheduler rows as part of refill sends.
 
 ## MCP Prompt Fallback

package/package.json

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

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

@@ -1515,7 +1515,11 @@ Message, and verify current-revision sample messages before final completion.
      - DM lanes: add a `Delivery format:` line — either `multiline (each paragraph sends as its own DM message)` or `single message`. When multiline, the template's blank-line paragraphs ARE the message boundaries — write each one as a standalone typed message.
      - **InMail lanes can never be multiline**: an InMail is one message and the recipient must reply before anything else can be sent. InMail-bound templates must read as one cohesive message — declare `Delivery format: single message (InMail — no follow-up until reply)` and never structure the copy to depend on multi-message pacing.
 
-   - The sequence is auto-selected by sender tier; do not hand-author sequence templates here. Never select a paid-InMail template.
+   - The sequence is auto-selected by sender tier; do not hand-author sequence
+     templates here. Sales Nav/Recruiter senders may receive the unified Sales
+     Nav cascade through `attach_recommended_sequence`; attaching it does not
+     spend paid InMail credits by itself. Do not substitute the manual Paid
+     InMail Campaign template.
 3. **Customer-Visible Completion Contract**: a named evergreen lane that appears
    as a campaign card or campaign-backed table is not done when the shell exists.
    It is done only when the customer can open the campaign and land on final
@@ -1592,7 +1596,7 @@ Message, and verify current-revision sample messages before final completion.
      completion, approve exactly one quality-valid generated row. If one or more
      rows are already approved, do not add more approvals during evergreen
      completion. Never broad approve all rows.
-    - The recommended non-paid sequence is attached to the current campaign
+    - The recommended tier-aware sequence is attached to the current campaign
       table, and the watched campaign is on Send. Use
       `attach_recommended_sequence({ campaignId, currentStep:"send" })` when a
       safe attach is needed. After `confirm_lead_list` or any source-list copy,
@@ -1602,10 +1606,11 @@ Message, and verify current-revision sample messages before final completion.
      before reporting completion. If a stale shell table has sequence columns but
      the current campaign table does not, `SEQUENCE_EXISTS` is not enough:
      record the stale shell table id, then repair the current workflowTableId
-     with `attach_sequence` using the same non-paid product template
-      `attach_recommended_sequence` would have selected. Never use a paid-InMail
-      template and never attach/replace sequence outside the current table unless
-      the current lane packet explicitly allowed sequence repair.
+     with `attach_sequence` using the same product template
+      `attach_recommended_sequence` would have selected. Do not substitute the
+      manual Paid InMail Campaign, and never attach/replace sequence outside the
+      current table unless the current lane packet explicitly allowed sequence
+      repair.
     - If the current campaign table is still `DRAFT` after sequence/readiness
       proof, call `pause_campaign({ campaignId })` and reread. `pause_campaign`
       is the product-native review-state transition; it is not a launch and does

package/skill-templates/refill-sends.md

@@ -7,6 +7,7 @@ allowed-tools:
   - mcp__sellable__get_refill_target_plan
   - mcp__sellable__get_scheduler_fill_capacity
   - mcp__sellable__refresh_paid_inmail_credits
+  - mcp__sellable__get_subskill_asset
   - mcp__sellable__get_auth_status
   - mcp__sellable__start_cli_login
   - mcp__sellable__wait_for_cli_login
@@ -68,6 +69,9 @@ 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,
@@ -86,17 +90,54 @@ Accepted invocation flags in the same user request:
 When the host can call typed MCP tools, start with:
 
 ```text
-refill_sends({ yolo?: boolean, senders?: string[], senderIds?: string[], senderNames?: string[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD" })
+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 only normalizes arguments and returns the execution
-contract. It does not mutate. Continue with the workflow below for route
-selection, state rereads, approval gating, source import, preparation, and
-bounded approval.
+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, same-source row copy, and read-only wait
+rereads. 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.
 
-First call `get_auth_status({})`. If auth or active workspace is not OK, follow
-the returned login/workspace guidance before route resolution. Do not run refill
-research against an implicit or guessed workspace.
+## 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`, 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
+refill_sends({ yolo:false, executionMode:"scheduled", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+get_refill_target_plan({ intent:"plain", approvalMode:"mark_ready", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+```
+
+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
@@ -111,19 +152,23 @@ 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 before taking any operational step:
+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" })
 ```
 
-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.
+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:
@@ -131,18 +176,21 @@ 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 only connection invites (`send_invite`) or paid InMails
-(`send_inmail_closed`), chosen per sender from the most recent current
-dashboard-active campaign-backed send evidence. DMs (`send_dm`) and
-open-profile InMails (`send_inmail_open`) may exist in sequences, but they are
-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 connection-or-paid-InMail lane rather than asking which of those
-two lanes to fill. If a stale target plan selects `send_dm` or
-`send_inmail_open`, stop and re-plan with the current planner before mutation.
-Short form: trust the target plan's inferred lane only when it is a
-connection-invite or paid-InMail refill lane.
+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.
 
 Structured planner packet:
 
@@ -156,19 +204,43 @@ Structured planner packet:
   `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` before
+  `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.
+
 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/approval/start action. If fresh facts are still below
+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 or a manual continuation.
+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
@@ -186,8 +258,9 @@ will try to place and does not import, approve, schedule, refresh credits, or
 mutate.
 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 but scheduled coverage is still short, keep the
-run open in a persistent read-only scheduler wait loop. Poll
+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
@@ -201,8 +274,8 @@ 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 connection fallback; `--yolo` does not
-lower paid-InMail thresholds or create campaigns.
+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
@@ -232,7 +305,7 @@ 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 active workspace. Without `--yolo`, if Christian did not name senders, ask
+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,
@@ -254,7 +327,7 @@ 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
+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
@@ -268,7 +341,7 @@ 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/start result, wait for processing, reread
+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.