@sellable/install 0.1.299 → 0.1.301

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",
@@ -2002,10 +2005,17 @@ Desktop, then start a new thread.
 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
+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" })\`.
+   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.
 

package/package.json

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

package/skill-templates/refill-sends-evergreen.md

@@ -0,0 +1,84 @@
+---
+name: refill-sends-evergreen
+description: Plan evergreen waterfall send refill work through the Phase 85 dry-run workflow.
+visibility: public
+allowed-tools:
+  - mcp__sellable__refill_sends_evergreen
+  - mcp__sellable__get_evergreen_refill_plan
+  - mcp__sellable__get_subskill_prompt
+  - mcp__sellable__get_subskill_asset
+  - mcp__sellable__get_auth_status
+  - mcp__sellable__get_active_workspace
+  - mcp__sellable__list_workspaces
+  - mcp__sellable__get_workspace
+---
+
+# Refill Sends Evergreen
+
+Use this public command wrapper for evergreen waterfall refill requests such as
+"refill evergreen", "fill evergreen senders", "load evergreen lanes", or
+"plan evergreen refill".
+
+Host command names:
+
+- Claude Code: `/sellable:refill-sends-evergreen`
+- Codex: `$sellable:refill-sends-evergreen`
+
+Phase 85 is read-only, dry-run, zero mutations. It plans the deterministic
+waterfall-ladder refill packet and writes a local dry-run journal, but it does
+not prepare messages, approve messages, start campaigns, schedule sends, send
+messages, refresh paid InMail credit facts, create campaigns, or change source
+configuration. Execution ships in the follow-up phase.
+
+## Entry
+
+Resolve the explicit `workspaceId` from the request, automation config, or
+active workspace readback. Scheduled or autonomous usage must carry
+`workspaceId` on every tool call. If the workspace is missing or ambiguous, stop
+with `WORKSPACE_REQUIRED`; do not switch the shared active workspace.
+
+Start with the command contract:
+
+```text
+refill_sends_evergreen({ workspaceId })
+```
+
+Then load the internal workflow prompt and flow asset:
+
+```text
+get_subskill_prompt({ subskillName: "refill-sends-evergreen-workflow" })
+get_subskill_asset({ subskillName: "refill-sends-evergreen-workflow", assetPath: "core/flow.v1.json" })
+```
+
+Continue both loads until `hasMore:false`; parse the flow JSON and verify
+`workflow:"refill-sends-evergreen-workflow"` with a `v1` version before the
+planner call.
+
+Call the dry-run planner with the explicit workspace id:
+
+```text
+get_evergreen_refill_plan({ workspaceId, senderIds?, runState?, journal?, journalNote? })
+```
+
+Use `senderIds` only when the user scoped the request to exact senders. Use
+`runState` only for an explicit what-if dry run; otherwise let the MCP read
+local lane memory hints. Leave `journal` enabled unless the user specifically
+asked for no local journal.
+
+## Report
+
+Review the returned packet before giving a recommendation:
+
+- `planRevision` starts with `pr1:`.
+- `stateRevision` identifies the current readback.
+- `packet` is the operator-facing facts receipt.
+- `plans[]` contains per-sender lane decisions and itinerary details.
+- `globalActionQueue[]` is a dry-run sequence only in Phase 85.
+- `evergreen.enumeratedRungs` and each action's `evergreenRung` map to the
+  locked ladder from the workflow asset.
+- `journalPath` points to the dry-run markdown journal written by the MCP.
+- `sideEffects` must be all false.
+
+Report campaign names and sender names first, ids second. Include the chosen
+rung, the itinerary, the plan revision, the journal path, and any blockers or
+warnings. Stop after the report; do not execute the action queue in Phase 85.

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
@@ -92,10 +93,16 @@ When the host can call typed MCP tools, start with:
 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.
 
 ## Workspace Contract
 
@@ -145,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:
@@ -199,16 +210,38 @@ Structured planner packet:
 - `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, 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
@@ -225,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
@@ -293,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
@@ -307,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.