@sellable/install 0.1.297 → 0.1.299

package/bin/sellable-install.mjs

@@ -1999,12 +1999,14 @@ 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/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.
+6. Load the canonical prompt 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,
+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.297",
+  "version": "0.1.299",
   "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

@@ -68,6 +68,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,7 +89,7 @@ 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
@@ -94,9 +97,40 @@ contract. It does not mutate. 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
@@ -131,18 +165,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,7 +193,8 @@ 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.
@@ -168,7 +206,8 @@ 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
 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.
 
 Compact refill lessons: sender-level target plan is final truth; trust
 `schedulerGate.sendable` and scheduler gate blockers, not raw
@@ -195,12 +234,14 @@ report. Treat `awaiting_scheduler_after_ready_buffer` as an in-progress wait
 state, not a close-out condition.
 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`. Trust `refill_sends.autoPaidInmailRefresh`: it should
+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 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
@@ -230,7 +271,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,