@sellable/install 0.1.319 → 0.1.320

package/bin/sellable-install.mjs

@@ -2099,9 +2099,9 @@ Desktop, then start a new thread.
 
 1. Call \`mcp__sellable__get_auth_status({})\`.
 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" })\`.
+3. Normalize invocation arguments with \`mcp__sellable__refill_sends({ yolo, executionMode, requireWorkspace, workspaceId, senders, senderIds, senderNames, actionTypes, 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[], actionTypes?: ("send_invite" | "send_inmail_closed")[], 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. When ready rows cover the target but scheduled rows do not, \`mcp__sellable__run_scheduler_sweep({ workspaceId, action:"run" })\` may request immediate placement within existing gates and returns a receipt, but it never sends or bypasses limits. 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.
+5. Call \`mcp__sellable__get_refill_target_plan({ workspaceId, senders, senderIds, senderNames, actionTypes, 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 or exact-date sweep 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. When the planner returns a request-scoped exact-date scheduler sweep, execute \`mcp__sellable__run_scheduler_sweep({ workspaceId, action:"run", targetDate, requestKey, targetShapeRevision })\` once, capture its receipt, and fully reread before another action. It may schedule eligible workspace cells through existing gates, but it never sends directly or bypasses limits. If the returned target is already complete, stop with the no-op receipt. Only non-exact or no-sweep waits use 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" })\`,
@@ -2112,8 +2112,7 @@ Desktop, then start a new thread.
    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.
+7. Follow the canonical prompt exactly. Do not directly send, bypass scheduler gates, or raw-write scheduler fields. Only the exact rendered paused-campaign start and request-scoped scheduler sweep may use their existing product-gated paths; do not launch, archive, or delete unrelated work.
 
 ## MCP Prompt Fallback
 

package/package.json

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

package/skill-templates/refill-sends.md

@@ -83,6 +83,8 @@ Accepted invocation flags in the same user request:
 - `senderIds: <id>, <id>` or `senderNames: <name>, <name>`: explicit selector
   alternatives when the host preserves natural-language arguments better than
   shell-style flags.
+- `actionTypes: send_invite, send_inmail_closed`: optional lane selector. Omit
+  `actionTypes` to preserve the target planner's lane inference.
 - `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
@@ -91,7 +93,7 @@ Accepted invocation flags in the same user request:
 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" })
+refill_sends({ yolo?: boolean, executionMode?: "manual" | "scheduled" | "yolo", requireWorkspace?: boolean, workspaceId?: string, senders?: string[], senderIds?: string[], senderNames?: string[], actionTypes?: ("send_invite" | "send_inmail_closed")[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD" })
 ```
 
 That command helper normalizes arguments and returns the execution contract. In
@@ -99,14 +101,22 @@ 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
+same-source row copy, a request-scoped exact-date product scheduler sweep, 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.
+and no non-terminal `approvedNotDispatched` work. It does not run unbounded
+approval, lower paid-InMail thresholds, switch source families, create
+campaigns, launch, or send directly; it never raw-writes scheduler fields.
+Continue with the workflow below for route selection, state rereads, approval
+gating, source import, preparation, and bounded approval.
+
+The approval scope is the exact `workspaceId`, `targetDate`, sender ids, action
+types, campaign/table/source ids, `targetShapeRevision`, and `actionKey` in the
+rendered packet. `stateRevision` and sent/scheduled/ready counts are mutable
+progress, not approval-scope drift. Execute only
+`target.globalActionQueue[0]`, then perform a full authoritative reread before
+deciding any next action.
 
 ## Workspace Contract
 
@@ -284,6 +294,19 @@ 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.
+A scheduler sweep is a visible workspace-wide scheduling side effect. The
+request packet limits the expected target changes to its exact date, senders,
+action types, campaigns, tables, and stable sources, but the product scheduler
+may also place unrelated eligible workspace work; disclose that possibility in
+the approval packet and receipt. For an exact-date sweep action, execute it
+once, then reread the full target plan before taking or presenting another
+action.
+The exact-date `run_scheduler_sweep` may schedule eligible workspace cells
+through existing product gates; it never sends directly or raw-writes scheduler
+fields. Only non-exact or no-sweep scheduler waits are read-only.
+On resume, reconcile the current target plan and matching sweep status/receipt
+before retrying. A matching same-key terminal receipt replays; an
+`uncertain_outcome` stops for reconciliation and must not schedule again.
 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
@@ -396,6 +419,14 @@ 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.
 
+Future scheduled coverage and already sent actions are distinct; only
+scheduler-owned future scheduled actions count as scheduled coverage. For
+multiple target dates, finish D1 execution and the full D1 reread before
+planning D2. Completion proof is product-native Sellable MCP evidence only:
+target plan, campaign refill state, scheduler capacity, sweep/status, and
+bounded receipts. Never use individual cell ids, Prisma, SQL, direct database
+access, or production-environment scripts as completion proof.
+
 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,