@sellable/install 0.1.293 → 0.1.295

package/bin/sellable-install.mjs

@@ -1973,15 +1973,17 @@ ${allowedToolsYaml(REFILL_SENDS_ALLOWED_TOOLS)}
 
 Use this as the customer-facing entrypoint for the Sellable \`refill-sends\`
 workflow. It supports \`--yolo\` and optional repeated \`--sender <name-or-id>\`
-selectors. It also supports \`--until YYYY-MM-DD\` to fill through a specific
-sender-local date instead of the default two send-day horizon.
+selectors. It also supports \`--target-date YYYY-MM-DD\` to fill one exact
+sender-local date and \`--until YYYY-MM-DD\` to fill through a specific
+sender-local date instead of the default scheduler-forward 48-hour target window.
 
 Goal-mode continuation: a skill cannot create or invoke \`/goal\` by itself. If
 this command is already running inside an active Codex goal, keep that goal open
-until every selected sender lane is horizon-filled by projected coverage
-(\`sent + scheduled\`), Christian 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\`.
+until every selected sender lane is filled by projected coverage
+(\`sent + scheduled\`) for the scheduler-forward target window, Christian
+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.
 
 ## Bootstrap
 
@@ -1997,8 +1999,8 @@ 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, untilDate })\` when the host exposes typed MCP tools.
-3. Call \`mcp__sellable__get_refill_target_plan({ senders, senderIds, senderNames, untilDate })\` before any mutation. 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.
+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. 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
    \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends" })\`,
    then load \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends-workflow" })\`.

package/lib/runtime-verify.mjs

@@ -31,6 +31,7 @@ export const REQUIRED_SELLABLE_MCP_TOOLS = [
   "resolve_campaign_fill_route",
   "get_campaign_refill_state",
   "get_refill_target_plan",
+  "get_scheduler_fill_capacity",
   "refill_sends",
   "setup_evergreen_campaigns",
   "start_campaign_message_preparation",

package/package.json

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

package/skill-templates/create-campaign.md

@@ -138,10 +138,10 @@ explicit user selection; it is never the default response to plain fill. When
 choosing among active targets, use refill-state scheduled-count evidence to
 continue the campaign that most recently had scheduler-owned sends for the
 relevant sender set; do not treat every active campaign as a refill candidate.
-In `--yolo` fill/refill mode, default to one best recent-send campaign and a
-two-send-day horizon: subtract future scheduler-owned scheduled sends and
-ready-to-schedule rows from healthy sender daily capacity, then prepare only
-that bounded gap.
+In `--yolo` fill/refill mode, default to one best recent-send campaign and the
+scheduler-forward 48-hour target window: subtract future scheduler-owned
+scheduled sends and ready-to-schedule rows from healthy sender daily capacity,
+then prepare only that bounded gap.
 When more leads are needed, the refill workflow must recommend same-campaign
 source-ladder replenishment first; do not create warm-post-engager side
 campaigns, on-demand campaigns, or unrelated campaigns. If same-source copy hits

package/skill-templates/refill-sends.md

@@ -5,6 +5,7 @@ visibility: public
 allowed-tools:
   - mcp__sellable__refill_sends
   - mcp__sellable__get_refill_target_plan
+  - mcp__sellable__get_scheduler_fill_capacity
   - mcp__sellable__refresh_paid_inmail_credits
   - mcp__sellable__get_auth_status
   - mcp__sellable__start_cli_login
@@ -70,17 +71,22 @@ Accepted invocation flags in the same user request:
 - `--sender <name-or-id>`: scope to a specific sender; repeat for multiple
   senders.
 - `--until <YYYY-MM-DD>`: fill through that sender-local date, inclusive,
-  instead of the default two send-day horizon.
+  instead of the default scheduler-forward 48-hour target window.
+- `--target-date <YYYY-MM-DD>`: fill only that sender-local date. This means
+  prepare rows for scheduler-fillable slots on that date, not every remaining
+  daily-limit slot and not an inclusive through-date.
 - `senderIds: <id>, <id>` or `senderNames: <name>, <name>`: explicit selector
   alternatives when the host preserves natural-language arguments better than
   shell-style flags.
 - `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
+  preserves natural-language arguments better than shell-style flags.
 
 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" })
+refill_sends({ yolo?: boolean, 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
@@ -99,10 +105,11 @@ resolver.
 
 Goal-mode continuation: a skill cannot create or invoke `/goal` by itself. When
 this command is already running inside an active Codex goal, keep that goal open
-until every selected sender lane is horizon-filled by projected coverage
-(`sent + scheduled`), Christian 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`.
+until every selected sender lane is filled by projected coverage
+(`sent + scheduled`) for the scheduler-forward target window, Christian
+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:
 
@@ -136,6 +143,11 @@ 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.
+For exact-date requests, pass `targetDate` to `get_refill_target_plan`. If you
+need raw proof, call the read-only `get_scheduler_fill_capacity` query for the
+same sender/action/date; it tells the MCP how many cells the product scheduler
+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
@@ -210,32 +222,35 @@ return concrete continuation options with campaign names, exact ids, which optio
 is already covered by the current packet, and which option needs a new approval
 packet.
 
-For `--yolo` fill/schedule requests, completion means projected horizon
-saturation (`sent + scheduled`), not merely prepared/approved/ready rows.
-Maintain a horizon saturation ledger per 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 the target plan/refill
-state, recompute the ledger, then keep applying safe bounded actions until
-projected coverage fills the horizon or a concrete non-scheduler blocker is
-proven.
+For `--yolo` fill/schedule requests, completion means projected saturation
+(`sent + scheduled`) for the scheduler-forward target window, not merely
+prepared/approved/ready rows. Maintain a target-window saturation ledger per
+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
+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.
 If ready rows cover the projected gap but the scheduler has not picked them up
-yet, run the persistent read-only 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.
-
-In `--yolo`, the default two-day fill horizon is two send days unless
-`--until`/`untilDate` is provided. If an until date is provided, compute bounded
-gaps through that sender-local date inclusive, skipping no-send days and never
-extending beyond that date without a new packet. For each target sender, compute
-the bounded gap from that sender's healthy daily capacity, existing future
-scheduler-owned scheduled sends, and rows already ready to schedule across
-active campaigns enrolled with that sender. Then pick the best same-sender
-campaign to fill the gap: prefer recent/future scheduler-owned sends for that
-sender, then strongest recent result evidence, then source health. Do not stop
+yet, report loaded, awaiting scheduler and run the persistent read-only
+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.
+
+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,
+compute bounded gaps for only that sender-local date using scheduler-fillable
+slots. If an until date is provided, compute bounded gaps through that
+sender-local date inclusive, skipping no-send days and never extending beyond
+that date without a new packet. For each target sender, compute the bounded gap
+from that sender's healthy daily capacity, existing future scheduler-owned
+scheduled sends, and rows already ready to schedule across active campaigns
+enrolled with that sender. Then pick the best same-sender campaign to fill the
+gap: prefer recent/future scheduler-owned sends for that sender, then strongest
+recent result evidence, then source health. Do not stop
 after filling only one sender when the request was sender-scoped. If a
 same-source copy hits the campaign-table row cap, split the current source into
 a bounded LinkedIn profile source list, confirm only that smaller list into the