@sellable/install 0.1.247 → 0.1.249

package/package.json

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

package/skill-templates/create-campaign.md

@@ -137,9 +137,16 @@ 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.
 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. Surface sender-health
+campaigns, on-demand campaigns, or unrelated campaigns. If same-source copy hits
+`USER_ADDED_ROWS_LIMIT_EXCEEDED`, split the current source into a bounded
+same-source LinkedIn profile list, confirm that smaller list into the same
+campaign, and operate on the copied review batch first. Surface sender-health
 blockers separately from prepared/approved/scheduled counts.
 
 Treat active fills as capacity-fill preparation: calculate the bounded target

package/skill-templates/refill-sends.md

@@ -38,6 +38,7 @@ allowed-tools:
   - mcp__sellable__get_table_rows
   - mcp__sellable__get_campaign_table_schema
   - mcp__sellable__select_campaign_cells
+  - mcp__sellable__queue_campaign_cells
   - mcp__sellable__wait_for_campaign_processing
   - mcp__sellable__get_sender
 ---
@@ -60,6 +61,34 @@ 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.
 
+For interactive Codex or Claude Code sessions, that approval must use the
+host-native structured question gate, not plain chat:
+
+- Codex: use `request_user_input`.
+- Claude Code: use `AskUserQuestion`.
+
+The approval question must present the final refill step with exactly two
+choices: `Accept` and `Decline`. Treat `Accept` as permission for only the
+rendered target, caps, mode, and side effects. Treat `Decline` as a hard stop
+with no mutation.
+
+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. `--yolo` only covers the exact target, caps, approval mode, and side
+effects in the packet. It does not authorize launch/start, sending, archive or
+delete cleanup, direct scheduler writes, sender reassignment, or any expanded
+target set. Stop and re-plan if the route, ids, caps, blockers, or side-effect
+class drift before mutation.
+
+In `--yolo`, the default two-day fill horizon is two send days. The workflow must pick
+the best recent-send campaign first, not every active campaign, and compute the
+bounded gap from healthy sender daily capacity, existing future scheduled sends,
+and rows already ready to schedule. 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 same campaign, and operate on the copied
+review batch. Do not fall back to on-demand campaigns or broad active-campaign
+fills.
+
 Public concepts are regular campaign and evergreen campaign. Internal direct
 campaign types are unsupported refill targets. `fill_campaign_horizon` is only a
 legacy evergreen-only lower-level primitive after route and refill-state