@sellable/install 0.1.430 → 0.1.432-wip.146.20260728055759

package/bin/sellable-install.mjs

@@ -1194,6 +1194,9 @@ const CREATE_EVERGREEN_CAMPAIGNS_ALLOWED_TOOLS = [
 ];
 
 const REFILL_SENDS_ALLOWED_TOOLS = [
+  "mcp__sellable__refill_v3_sender_date_eligibility",
+  "mcp__sellable__refill_v3_supply_assessment",
+  "mcp__sellable__refill_v3_workspace_inventory",
   "mcp__sellable__refill_sends",
   "mcp__sellable__get_auth_status",
   "mcp__sellable__start_cli_login",

package/package.json

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

package/skill-templates/refill-sends.md

@@ -3,6 +3,9 @@ name: refill-sends
 description: Refill projected sends across a workspace or selected senders through the canonical fenced coordinator.
 visibility: public
 allowed-tools:
+  - mcp__sellable__refill_v3_sender_date_eligibility
+  - mcp__sellable__refill_v3_supply_assessment
+  - mcp__sellable__refill_v3_workspace_inventory
   - mcp__sellable__refill_sends
   - mcp__sellable__get_refill_target_plan
   - mcp__sellable__get_scheduler_fill_capacity
@@ -30,14 +33,71 @@ Host commands:
 - Claude Code: `/sellable:refill-sends`
 - Codex: `$sellable:refill-sends`
 
+## Refill v3 Calls 1–3a — progressive observation gate
+
+Use this gate only when the operator explicitly requests `--observe-v3`,
+explicitly asks to inspect or preview Refill V3 eligibility and supply without
+refilling, or invokes a UAT request that names Calls 1–3a. An ordinary fill or
+refill intent without `--observe-v3` skips this gate and continues at
+`Entry and exact scope` below.
+
+Do not combine `--observe-v3` with `--yolo`, scheduled execution, or legacy
+execution in one invocation. If they are combined, stop with no tool call and
+ask the operator to choose observation or execution.
+
+1. Call `get_auth_status`. If Sellable authentication is not valid, run only
+   the returned login flow and recheck authentication.
+2. Load
+   `get_subskill_asset({ subskillName: "refill-sends", assetPath: "core/flow.v3.json" })`
+   completely. Require `workflow:"refill-sends-v3"` and `version:3`. Follow
+   only the current state's `allowedTools`, `doNotLoad`, and transition.
+3. Resolve the exact workspace by explicit ID, exact name, install mapping, or
+   an unambiguous accessible-workspace match using `get_active_workspace` and
+   `list_workspaces`. Never change the active workspace.
+4. Call
+   `refill_v3_workspace_inventory({ workspaceId, detail: "concise" })` exactly
+   once.
+5. For each globally eligible sender and requested sender-local date, call
+   `refill_v3_sender_date_eligibility` exactly once with the server-issued
+   `runId` and `fence`. Never call it for a globally ineligible sender.
+6. Only for a positively eligible lane, call `refill_v3_supply_assessment`
+   exactly once for each campaign/lane tuple issued by inventory. Pass the
+   backend-applied quota as the assessment bound; never invent or substitute a
+   campaign, lane, sender, date, run identity, or fence.
+7. Render the complete inventory, sender/date eligibility, and supply result,
+   including every typed blocker, then stop at `observed` or `blocked`.
+
+A sender whose LinkedIn account is connected but whose Sales Navigator status
+is disconnected remains eligible for real non-Sales-Nav lanes. For Thomas or
+any equivalent sender, paid InMail must return `sales_nav_disconnected` at
+eligibility and transition directly to terminal `blocked`: do not call supply,
+refresh a provider, invoke Sales Navigator, or schedule or place anything.
+
+While `--observe-v3` is selected, do not load `refill-sends-workflow`, call
+`get_refill_target_plan`, or call `refill_sends`. The host consumes
+`--observe-v3`; never pass it to `refill_sends`. Calls 1–3a are backend-owned
+observation calls; they may append their fenced decision ledger and Call 2 may
+perform its bounded single-flight paid-credit cache refresh. They never approve
+or enrich rows, acquire supply, change campaign state, invoke a Sales Navigator
+provider action, schedule, place, or send. Between calls, retain the
+server-issued `runId` and `fence`; never reconstruct downstream policy in the
+host.
+
+The sections below remain the default path for ordinary fill and refill
+requests. `refill_sends` remains the only mutation execution owner; this
+explicit observation gate does not introduce another mutation owner.
+
 ## Entry and exact scope
 
-Accepted request fields are `--yolo`, `workspaceId`, `--sender`/`senderIds`/
-`senderNames`, `actionTypes`, `--until`/`untilDate`, `--target-date`/
-`targetDate`, and compatibility `horizonSendDays`. Omitted dates mean the
-scheduler-forward 48-hour window. `untilDate` is sender-local and inclusive;
-`targetDate` is one sender-local scheduler-fillable date. Skip no-send days and
-never extend beyond the requested date. Finish the full D1 reread before D2.
+At the skill boundary, optional `--observe-v3` selects the explicit observation
+gate above and is consumed by the host. It is not a `refill_sends` tool
+argument. Existing coordinator request fields remain `--yolo`, `workspaceId`,
+`--sender`/`senderIds`/`senderNames`, `actionTypes`, `--until`/`untilDate`,
+`--target-date`/`targetDate`, and compatibility `horizonSendDays`. Omitted dates
+mean the scheduler-forward 48-hour window. `untilDate` is sender-local and
+inclusive; `targetDate` is one sender-local scheduler-fillable date. Skip
+no-send days and never extend beyond the requested date. Finish the full D1
+reread before D2.
 
 ```text
 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", runHandle?: RefillRunHandleV1, targetConfig?: RefillTargetConfigV1, reportingContext?: RefillReportingContextV2, messageTemplateRevision?: MessageTemplateRevisionV1 })