@sellable/install 0.1.248 → 0.1.249

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.248",
+  "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

@@ -123,6 +123,7 @@ such as "fill campaigns", "fill up", "refill sends", "max out sends", or
 ```text
 get_subskill_prompt({ subskillName: "refill-sends-workflow" })
 resolve_campaign_fill_route({ intent:"plain" })
+list_senders
 get_campaign_refill_state
 ```
 
@@ -133,15 +134,27 @@ campaign refill. Route outcomes are `route:"evergreen_horizon"`,
 returns `route:"ask_create"`, ask whether to create a normal campaign or
 evergreen campaigns. Campaign creation is allowed only after this route and
 explicit user selection; it is never the default response to plain fill. When
-more leads are needed, the refill workflow must recommend same-campaign
-source-ladder replenishment; do not create warm-post-engager side campaigns,
-on-demand campaigns, or unrelated campaigns. Surface sender-health blockers
-separately from prepared/approved/scheduled counts.
+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. 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
 from sender capacity when needed, then use the refill workflow to decide source
-replenishment, enrichment/prep, approval policy, and scheduler proof. Mutation
-requires exact visible approval and a fresh `get_campaign_refill_state` reread.
+replenishment, enrichment/prep, approval policy, and scheduler proof. Present
+operator decisions by campaign name and sender name first, with campaign/table
+ids as proof only. Mutation requires exact visible approval and a fresh
+`get_campaign_refill_state` reread.
 For already-running regular campaigns that need Signal Discovery source
 replenishment, the refill workflow owns the guarded recovery: clear
 `currentStep` only with `clearCurrentStepIfMatches:"running"`, load the

package/skill-templates/create-evergreen-campaigns.md

@@ -58,22 +58,6 @@ Default evergreen plan per workspace (override only if the prompt specifies diff
 1. **`<Sender Name> - Post Engagers`** — one per sender (warm lane, highest priority)
 2. **`<Workspace/Team> - Shared Signal Discovery`** — one shared warm-signal campaign lane across senders
 3. **`<Workspace/Team> - Shared Cold Fallback`** — one shared cold/fallback campaign lane across senders
-
-Sender scope resolution is safety-critical. Do not pass
-`allConnectedSenders:true` unless the invoking prompt explicitly says "all
-connected senders", "every connected sender", "all seats", or names an
-equivalent all-sender scope. If the user says "all 4 campaigns", "the four
-evergreen campaigns", or names specific senders, resolve those exact senders
-and pass explicit `postEngagerSenderIds` plus `sharedSenderIds`; do not broaden
-the plan to every connected sender. In non-interactive or `--yolo` mode, when
-more than two connected senders exist and the prompt does not explicitly
-authorize all connected senders, stop before mutation with
-`blocked: ambiguous_post_engager_sender_scope` and report the sender ids/names
-needed for approval. Never let "workspace default" silently create Post
-Engagers lanes for extra senders.
-Short form: Do not pass `allConnectedSenders:true` unless the prompt explicitly says all/every connected sender.
-Short form: "all 4 campaigns" means explicit sender scope plus two shared lanes, not all connected senders.
-Short form: In `--yolo`, ambiguous multi-sender scope blocks before mutation.
 </inputs>
 
 <command_backed_workflow>
@@ -231,8 +215,7 @@ After bounded delegated approval or safe `--yolo`, fan out lane worker tasks
 only from the current plan. Each worker receives the complete lane packet:
 workspace id, sender ids, lane key/type, existing campaign/table binding or
 create intent, source hints, caps, planRevision, actionId, allowed side effects,
-postconditions, the parent `postEngagerSenderIds`, the parent
-`sharedSenderIds`, and the packet's `workerDispatch` policy. Treat
+postconditions, and the packet's `workerDispatch` policy. Treat
 `workerDispatch.requiresVisibleThreadOrDurableReceipt:true` as a hard
 execution boundary, not guidance. Read and preserve `workerDispatch.acceptedRuntimes`,
 `workerDispatch.rejectedRuntimes`, and `workerDispatch.receiptArtifactHint`
@@ -251,15 +234,6 @@ parent packet, do not mutate and do not use it as `setupPlanCall` proof; stop
 with `blocked: worker_plan_scope_drift` and ask the parent to re-plan.
 Short form: If a worker-local plan omits `postEngagerSenderIds:[]`, do not use it as `setupPlanCall` proof.
 Short form: stop with `blocked: worker_plan_scope_drift`.
-Every worker prompt must include both parent scope arrays as explicit fields:
-`Parent postEngagerSenderIds:` and `Parent sharedSenderIds:`. Workers must
-preserve parent postEngagerSenderIds even for shared lanes. Never run a
-shared-lane worker-local plan with `postEngagerSenderIds:[]` unless the parent
-`postEngagerSenderIds` is exactly `[]`. Every durable receipt must copy these
-arrays to top-level `parentPostEngagerSenderIds` and `parentSharedSenderIds`
-before completion.
-Short form: Workers must preserve parent postEngagerSenderIds even for shared lanes.
-Short form: Never run a shared-lane worker-local plan with `postEngagerSenderIds:[]` unless the parent `postEngagerSenderIds` is exactly `[]`.
 
 Worker fan-out must use visible or durable execution. Preferred in local Codex
 is a visible Codex thread created with the actual Codex app thread tools:
@@ -290,36 +264,10 @@ CLI builds that expose `-a`/`-s` only at top level. Do not use
 forms fail on current customer CLI installs. Pipe the lane packet prompt on
 stdin, require the worker to write `workerDispatch.receiptArtifactHint`, and
 pass exactly one lane packet per worker.
-When wrapping multiple local Codex CLI workers in a shell launcher, run the
-wrapper with `/bin/bash -lc` or another explicitly chosen portable shell. Do not
-rely on zsh-specific behavior. Do not use `status` as a shell variable because
-zsh treats it as read-only; use `exit_code` or `rc` instead. Receipt polling
-must use `find <receipt-dir> -maxdepth 1 -name 'evg_*.json' -print` or an
-explicit nullglob-safe equivalent. Do not use naked `*.json` globs under zsh,
-and keep zero-receipt polls quiet with no `no matches found` diagnostics.
-Do not embed `<<'WORKER_PROMPT'` heredocs inside a single quoted or double
-quoted `/bin/bash -lc '...'` command string; nested quoting is brittle and can
-truncate the first worker before mutation. For multi-worker launchers, write one
-plain prompt file per lane under the current run directory, then start each
-worker with `codex -a never -s danger-full-access exec -C "$REPO" -o
-"$worker_final_file" - < "$worker_prompt_file"`. Keep launcher shell variables
-double-quoted and keep the prompt heredoc only in a standalone script/prompt-file
-write step, not inside an already quoted shell argument. If the first launcher
-attempt exits with a shell parse error or before starting the first worker,
-stop with `blocked: worker_launcher_quoting_failed` and do not retry by
-loosening sender scope or mutating in the parent.
-Short form: run the wrapper with `/bin/bash -lc`.
-Short form: Do not rely on zsh-specific behavior.
-Short form: Do not use `status` as a shell variable; use `exit_code` or `rc`.
-Short form: Receipt polling uses `find <receipt-dir> -maxdepth 1 -name 'evg_*.json' -print`.
-Short form: Do not use naked `*.json` globs under zsh; no `no matches found` diagnostics.
-Short form: Do not embed `<<'WORKER_PROMPT'` heredocs inside a quoted `/bin/bash -lc` command string.
-Short form: Multi-worker launchers write prompt files and run `codex ... - < "$worker_prompt_file"`.
 After creating receipt directories, dispatch workers immediately; do not perform extended parent reasoning, extra inventory, or prompt rewriting loops.
 Use a compact worker prompt: include lane packet JSON, original selectedActionIds,
-original planRevision, parent postEngagerSenderIds, parent sharedSenderIds,
-receiptArtifactPath, workspace id, sender ids, side-effect caps, and the
-instruction to load packaged prompts through MCP.
+original planRevision, receiptArtifactPath, workspace id, sender ids,
+side-effect caps, and the instruction to load packaged prompts through MCP.
 Do not paste the entire wrapper skill into worker prompts. If the parent cannot
 launch at least one visible/durable worker immediately after directory setup,
 stop with `blocked: worker_dispatch_stalled` before any mutation.
@@ -328,11 +276,8 @@ current lane packet for receipt paths.
 Do not hardcode machine-specific paths, workspace ids, campaign ids, sender ids, or UAT/phase artifact paths in this MCP prompt or any worker prompt.
 After the receipt-directory `mkdir`, the next shell/tool call must launch the first lane worker.
 Do not run `find`, `ls`, extra inventory, or another preflight between directory setup and the first worker launch.
-For the local Codex CLI fallback, use this literal durable CLI worker launch
-template and fill only the lane-specific placeholders. For one-off direct worker
-launches you may pipe a heredoc directly to `codex`; for multi-worker shell
-launchers, write the same prompt body to `<worker-prompt-file>` and launch the
-worker with stdin redirected from that file:
+For the local Codex CLI fallback, use this literal durable CLI worker launch template
+and fill only the lane-specific placeholders:
 
 ```
 codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
@@ -341,8 +286,6 @@ Use $sellable:create-evergreen-campaigns as the governing skill for this one lan
 Workspace id: <workspaceId>
 Parent planRevision: <planRevision>
 Parent selectedActionIds: <selectedActionIds JSON>
-Parent postEngagerSenderIds: <postEngagerSenderIds JSON>
-Parent sharedSenderIds: <sharedSenderIds JSON>
 Action id: <actionId>
 Lane key: <laneKey>
 Allowed side effects: <allowedSideEffects JSON>
@@ -356,9 +299,6 @@ Use mcp__sellable only. Do not use admin tools, direct DB, Prisma, SQL, web sear
 Do not launch, start, schedule, send, or use paid InMail.
 Complete only this lane, write the required durable receipt JSON, and stop.
 WORKER_PROMPT
-
-# Multi-worker launcher equivalent:
-codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> - < <worker-prompt-file>
 ```
 
 If any placeholder cannot be filled from the current lane packet, do not inspect
@@ -428,14 +368,7 @@ not a parent-thread summary. The receipt must include:
   `senderIds`, `campaignId`, `tableId`, and `createIntent`. Do not use
   `laneActionId`, `lanePacketActionId`, `delegatedPlanRevision`,
   `delegatedActionId`, or freeform `requestedCall` text as a substitute for
-  these fields. For create lanes, `setupPlanCall.campaignId` and
-  `setupPlanCall.tableId` must be the actual created campaign/table ids after
-  creation and readback. If the parent lane packet carried null ids before
-  creation, preserve that original packet only in a separate `parentLanePacket`
-  object; do not leave `setupPlanCall.campaignId:null` or
-  `setupPlanCall.tableId:null`.
-  Short form: For create lanes, `setupPlanCall.campaignId` and `setupPlanCall.tableId` must be the actual created campaign/table ids.
-  Short form: Do not leave `setupPlanCall.campaignId:null` or `setupPlanCall.tableId:null`.
+  these fields.
 - `createCampaignWorkflowReceipt`: proof the worker loaded the actual installed
   `$sellable:create-campaign` wrapper instead of doing ad hoc MCP calls. It must
   include `skillCommand:"$sellable:create-campaign"`,
@@ -490,25 +423,8 @@ not a parent-thread summary. The receipt must include:
   evidence field such as `rowCount`, `rowIdsHash`, or `rowEvidence`; do not
   leave those only in `searchSignalsProof`, `importProof`, `coldFallbackProof`,
   or narrative text for the parent/verifier to infer.
-- `filterDecisionReceipt`: saved/applied ICP filter proof for the current
-  campaign/table basis. Customer-visible evergreen lanes must enable ICP
-  filtering with `enableICPFilters:true`, call `save_rubrics`, and save at
-  least three rubric/filter criteria before Message Drafting. Do not skip
-  filtering for evergreen setup. Missing or skipped filter proof is
-  `blocked: missing_filter_setup`.
-  Before the worker exits, the durable JSON must contain
-  `filterDecisionReceipt.status:"applied"`,
-  `filterDecisionReceipt.enableICPFilters:true`, the current
-  `workflowTableId`, and concrete saved-filter proof such as
-  `filterDecisionReceipt.filterIds`, `filterDecisionReceipt.rubricIds`,
-  `filterDecisionReceipt.savedRubricCount`, or
-  `filterDecisionReceipt.headlineICPCriteria`.
-  The exact status string is contractual: use `status:"applied"` only.
-  Do not write `status:"confirmed"`, `status:"saved"`, `status:"done"`, or
-  any other alias after saving filters; the parent verifier rejects those
-  aliases even when saved rubric proof exists.
-  Short form: Filter receipt status must be exactly `applied`.
-  Short form: Do not write `filterDecisionReceipt.status:"confirmed"`.
+- `filterDecisionReceipt`: saved/applied filter ids or explicit skip-filter
+  decision with current campaign/table basis.
 - `messageDraftingReceipt`: the Message Drafting proof described below,
   including packaged `generate-messages` prompt/assets and validation. Raw
   fields like `generateMessagesPromptLoadedToHasMoreFalse`,
@@ -644,12 +560,7 @@ verification unless the same object also appears inside
       "sourceLadderReason": "<why the current source is valid before colder sources>"
     },
     "filterDecisionReceipt": {
-      "status": "applied",
-      "enableICPFilters": true,
-      "filterIds": ["<saved filter/rubric id>"],
-      "rubricIds": ["<saved rubric id>"],
-      "headlineICPCriteria": ["<saved ICP criterion>", "<saved ICP criterion>", "<saved ICP criterion>"],
-      "savedRubricCount": 3,
+      "status": "skipped",
       "workflowTableId": "<workflow table id>"
     },
     "messageDraftingReceipt": {
@@ -730,19 +641,6 @@ path itself in the worker thread:
    exactly one semantic Approved cell through `select_campaign_cells` and
    `update_cell`.
    Approval shorthand: approve exactly one semantic Approved cell.
-   In this message-drafting path, `update_cell` is allowed only for the semantic
-   Approved checkbox. Do not use `update_cell` or any row/cell write to edit
-   generated message text, sample copy, or final message bodies in automation.
-   If generated copy fails review, update the campaign brief/message template
-   with `update_campaign_brief` or `revise_message_template_and_rerun`, then
-   rerun Generate Message and review current-revision generated output. Receipt
-   `sampleMessages` must come from generated current-revision cells after the
-   brief/template rerun, not from hand-edited message cell overrides. If a lane
-   used a generated-message body override, report
-   `blocked: generated_message_cell_override` instead of success.
-   Short form: `update_cell` is allowed only for the semantic Approved checkbox.
-   Short form: Do not use `update_cell` to edit generated message text.
-   Short form: Bad copy requires brief/template revision plus Generate Message rerun.
 4. Poll `get_campaign_message_preparation_status` until no queued/active cells
    remain or a bounded stop reason is returned.
 5. Use `get_campaign_messages_preview` or `select_campaign_cells` to inspect
@@ -769,26 +667,6 @@ The only accepted statusSource values are exactly `branch` and
 `packaged-generate-messages-worker`; descriptive aliases such as
 `package-readback-local-thread` are rejected.
 
-Before any provider-specific source mutation for a newly created campaign,
-reread `get_campaign_navigation_state({ campaignId })` and use that product
-navigation state as the source-step authority. Do not jump from a shell directly
-into `contact-search`, and do not jump from a shell directly into
-`signal-discovery`. Advance through the product-visible source-selection step
-first, then load the provider prompt and write only the provider/source fields
-accepted for that current step. Never include sender reassignment fields in
-source-step updates, never include custom narration fields in source-step
-updates, and do not use guessed `currentStep` or watched narration payloads to
-force the flow forward. If `update_campaign` rejects the source transition
-twice, reread navigation/campaign state once; if the campaign is not already on
-the intended source step, stop the lane with
-`blocked: watched_source_transition_blocked` and include the rejected tool
-result plus the readback. Do not loop on rejected `update_campaign` transitions.
-Short form: do not jump from a shell directly into `contact-search`.
-Short form: do not jump from a shell directly into `signal-discovery`.
-Short form: never include sender reassignment fields in source-step updates.
-Short form: never include custom narration fields in source-step updates.
-Short form: do not loop on rejected `update_campaign` transitions.
-
 One lane may produce exactly one CampaignOffer/campaign id and one current
 workflow table id. For `intent:"create"`, the first successful
 `create_campaign` result establishes the lane's only allowed campaign/table
@@ -827,14 +705,9 @@ the prospect's engagement unless the selected source evidence proves that exact
 sender authored the post.
 Shared lanes must reject generic product-summary samples that explain the
 product in the same broad words for every row. Shared lanes must reject three
-nearly identical samples after stripping the leading name. Shared lanes must
-fail quality review when any reviewed sample has non-empty `issues`; do not
-approve or final-report samples with `verdict:"passed"` and non-empty `issues`.
-If any of these failures appears, revise or rerun the packaged
-create-campaign/generate-messages path from the lane worker before writing a
-success receipt.
-Short form: Shared lanes must fail quality review when any reviewed sample has non-empty `issues`.
-Short form: Do not approve or final-report samples with `verdict:"passed"` and non-empty `issues`.
+nearly identical samples after stripping the leading name. If either failure
+appears, revise or rerun the packaged create-campaign/generate-messages path
+from the lane worker before writing a success receipt.
 The generated-message cells are not prompt proof: `currentRevisionGeneratedMessages`,
 Generate Message column counts, `messagesCount`, or rendered row previews prove
 only that table cells exist from the current brief/template, not that the
@@ -854,22 +727,6 @@ duplicate-lane blockers before you call the command finished. If verify blocks,
 report the blocker and repair only the missing postconditions from the same
 current plan.
 
-Before calling verify, the parent should build compact receipt objects from the
-durable receipt files and pass those compact objects to MCP. The compact receipt
-must preserve every verifier-owned field named above, including top-level ids,
-`createCampaignStepReceipt`, canonical filter/message/review/sequence/final
-proof, and at least three concrete sample messages. It should omit large raw
-search outputs, long post lists, full row arrays, raw provider responses, and
-debug-only narration fields. Do not pass multi-hundred-kilobyte raw receipt
-objects when a compact canonical receipt has the same proof; large raw verify
-payloads can stall local MCP bridges and make UAT ambiguous.
-Do not print or `jq .` full receipt JSON into the terminal. For local checks,
-print only compact summaries such as file, actionId, laneKey, campaignId,
-filter status, sample count, approved count, and final status.
-Short form: Parent verify uses compact canonical receipt objects, not raw giant receipts.
-Short form: Do not dump full receipt JSON with `jq .`.
-Short form: Never change planRevision/actionId/laneKey while compacting receipts.
-
 Message proof for every customer-visible lane must come from the current
 campaign/table basis and include at least 3 generated review rows from the
 packaged `generate-messages` path before completion is reported.
@@ -908,8 +765,6 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      Short form: Do not pass the warm template into Shared Signal Discovery or Shared Cold Fallback.
      Short form: Shared lanes must reject generic product-summary samples.
      Short form: Shared lanes must reject three nearly identical samples.
-     Short form: Shared lanes must reject low-confidence relevance hedges.
-     Short form: Shared lanes must reject internal workflow vocabulary.
      Short form: revise or rerun the packaged create-campaign/generate-messages path.
    - **Post Engagers** first-message style: short, casual, references the
      sender-authored post they engaged with, closed question, **no internal
@@ -920,7 +775,7 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
 
      Hey there
 
-     Thank you for the support on my post about {{post_topic_line}}
+     Thanks for the support on my post about {{post_topic_line}}
      ```
 
    - **Shared Signal Discovery** first-message style: short, casual, references
@@ -936,22 +791,6 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      say it. Prefer sender-agnostic company/team language such as "we're
      helping CX teams..." or "at cxconnect.ai, we help..." and one clear
      problem question.
-     Before Message Drafting runs, the campaign brief must already include
-     these shared-lane hard avoids and source-use rules. Do not rely on a
-     failed first generation batch to discover that self-intros, generic
-     product summaries, or repeated structure are bad. If the first generated
-     batch violates these rules, rerun, but record that as a repaired UAT path
-     rather than the desired zero-shot path.
-     Do not use low-confidence relevance hedges such as "hope this is
-     relevant" in Shared Signal Discovery samples. Translate source/tool terms
-     into prospect-facing business language; do not put internal workflow
-     vocabulary such as "Codex-style workflow", "MCP", "agent workflows", or
-     "Claude-style agent workflows" in customer-facing message one.
-     Short form: Shared Signal Discovery uses no self-intro such as "I'm building Sellable".
-     Short form: Shared Signal Discovery uses no self-intro such as "We're building Sellable".
-     Short form: Shared Signal Discovery uses no "I've put together".
-     Short form: no low-confidence relevance hedge such as "hope this is relevant".
-     Short form: no internal workflow vocabulary such as "Codex-style workflow", "MCP", "agent workflows", or "Claude-style agent workflows".
    - **Shared Cold Fallback** first-message style: cold, direct, and cohesive.
      It must not pretend there was engagement, must not say "saw you pop up",
      and must not use a standalone name line followed by "Hey there" or other
@@ -966,52 +805,14 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      Sellable/Codex/Claude-Code feature summary
      across prospects. This is a single-message cold path unless the approved
      create-campaign message workflow proves a better delivery format.
-     Do not open with "hope this is relevant" or a similar low-confidence
-     relevance hedge. Do not use a repeated product-definition paragraph such
-     as "Sellable is a GTM system" across samples; every reviewed cold sample
-     should be specific enough to the role, company, or problem that the three
-     sample messages do not share the same body skeleton.
-     Before Message Drafting runs, the campaign brief must already forbid
-     self-intros, generic product summaries, opt-out shrugs, product-stack
-     dumps, and repeated template structure. Do not let the first generation
-     batch use "I'm building", "We're building", "I've put together", or
-     similar language and then rely on a cleanup rerun as the normal path.
      Short form: Shared Cold Fallback must not pass just because the receipt says `generate-messages` loaded.
      Short form: Shared Cold Fallback uses no self-intro such as "We're building".
-     Short form: Shared Cold Fallback uses no self-intro such as "I'm building Sellable".
-     Short form: Shared Cold Fallback uses no "I've put together".
      Short form: Shared Cold Fallback uses no opt-out shrug such as "If this isn't relevant, ignore me".
      Short form: Shared Cold Fallback uses no product-stack dump.
-     Short form: no low-confidence relevance hedge such as "hope this is relevant".
-     Short form: no repeated product-definition paragraph such as "Sellable is a GTM system".
-    - Customer-visible evergreen lanes must enable ICP filtering before Message
-      Drafting. This applies to Post Engagers, Shared Signal Discovery, and
-      Shared Cold Fallback. Do not skip filtering for evergreen setup, even when
-      the source is warm. Use the normal `$sellable:create-campaign` filter
-      workflow: set or save 3-5 headline ICP criteria, call `save_rubrics`, and
-      persist `enableICPFilters:true` on the campaign before generating
-      messages. Good evergreen filters should be light but real: role/budget
-      relevance, company/market fit, and obvious non-buyer exclusion. For
-      Post Engagers, keep filters permissive enough that warm source rows are not
-      over-pruned, but still save the filter rules. For shared lanes, filter for
-      buyers/operators relevant to the workspace offer and exclude students,
-      job seekers, vendors, and off-topic commenters. The receipt must show
-      `filterDecisionReceipt.status:"applied"`,
-      `filterDecisionReceipt.enableICPFilters:true`, current `workflowTableId`,
-      and saved filter/rubric proof with at least three saved rubric/filter
-      criteria (`filterIds`, `rubricIds`, `headlineICPCriteria`, or
-      `savedRubricCount`). Missing or skipped filter proof is
-      `blocked: missing_filter_setup`.
-      Short form: Customer-visible evergreen lanes must enable ICP filtering.
-      Short form: `enableICPFilters:true`.
-      Short form: Do not skip filtering for evergreen setup.
-      Short form: at least three saved rubric/filter criteria.
-      Short form: missing or skipped filter proof is `blocked: missing_filter_setup`.
-      Short form: run Message Drafting only after saved filters are applied.
-    - Every customer-visible lane must run Message Drafting from the current
-      campaign/table basis after source rows exist. The worker must load the full
-      packaged `generate-messages` prompt, every required asset, and
-      `create-campaign-v2-validation`; if the internal branch handoff is not
+   - Every customer-visible lane must run Message Drafting from the current
+     campaign/table basis after source rows exist. The worker must load the full
+     packaged `generate-messages` prompt, every required asset, and
+     `create-campaign-v2-validation`; if the internal branch handoff is not
      callable in the packaged runtime, the worker must call
      `start_campaign_message_preparation` and poll
      `get_campaign_message_preparation_status` from the lane worker. The
@@ -1041,13 +842,10 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
    - A source/list decision has been resolved and campaign rows are loaded. If
      there is no approved source or no rows can be copied, report `blocked` with
      the missing source detail; do not call the campaign complete.
-    - The filter step is resolved with saved/applied filters. Customer-visible
-      evergreen lanes must have `enableICPFilters:true`, at least three saved
-      ICP filter/rubric criteria, and a receipt with
-      `filterDecisionReceipt.status:"applied"`. Do not skip filters for
-      evergreen setup. Do not leave customer-visible campaigns at
-      `filter-choice`, `filter-rules`, or `apply-icp-rubric` and report success.
-      Do not proceed to Message Drafting until saved filters are applied.
+   - The filter step is resolved: either saved/applied filters are present, or
+     the campaign explicitly skipped filters. Do not leave customer-visible
+     campaigns at `filter-choice`, `filter-rules`, or `apply-icp-rubric` and
+     report success.
    - Message Drafting has run from the current campaign/table basis, using the
      create-campaign message prompt/assets and validation gate. Updating
      `currentStep:"messages"` is not proof. Parent-thread handwritten copy is
@@ -1066,17 +864,13 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
       reviewed sample messages. For Shared Cold Fallback, reject samples that
       open with a standalone name followed by "Hey there" or a similarly generic
       greeting. For Shared Cold Fallback, also reject samples with a self-intro
-      such as "We're building", "I'm building Sellable", or "I've put
-      together", an opt-out shrug such as "If this isn't relevant, ignore me",
-      or a product-stack dump that repeats the same
+      such as "We're building", an opt-out shrug such as "If this isn't
+      relevant, ignore me", or a product-stack dump that repeats the same
       Sellable/Codex/Claude-Code feature summary across prospects. For all
       shared lanes, reject generic product-summary samples, repeated
-      near-identical samples, low-confidence relevance hedges such as "hope this
-      is relevant", internal workflow vocabulary, any sample with non-empty
-      `issues`, and any preserved Post Engagers opener; revise or rerun the packaged
-      create-campaign/generate-messages path before reporting completion. Do not
-      approve or final-report samples with `verdict:"passed"` and non-empty
-      `issues`.
+      near-identical samples, and any preserved Post Engagers opener; revise or
+      rerun the packaged create-campaign/generate-messages path before reporting
+      completion.
    - The first review batch exists and at least 3 review rows have generated
      messages from the approved brief. If fewer than 3 usable rows exist, report
      the actual count and why.
@@ -1150,9 +944,7 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
    **Also confirm the delivery format and keep config in sync.** Ask the user whether DM lanes should send multiline (paragraph-per-message) or as a single message. Record the answer as the brief's `Delivery format:` line, and when multiline is chosen, set `actionConfig.sendEachParagraphAsMessage: true` on that campaign's `send_dm` column via `update_column` (config edits run no cells and nothing sends from unlaunched campaigns). Never set the paragraph-split flag on InMail columns — the option does not apply to InMail.
 6. **Interactive polish mode only: prove the template on one real row.** For ONE campaign that has at least one lead row (add one via `add_on_demand_leads` if every lane is empty and the user provides/approves a test lead), generate a message for exactly one row (`queue_campaign_cells` with `columnRole: "generateMessage"`, `rowSelector: { type: "reviewBatch", limit: 1 }` or the single row's ID), wait for it, then show the user the generated message next to the template — AND show how it would split if paragraph-per-message sending is enabled (list each paragraph as `msg 1:`, `msg 2:`, …) so the user confirms each one reads like a real typed message. Check alignment: tone, structure, no internal vocabulary, correct token substitution, no letter punctuation. Do NOT approve the row or generate for more rows — one sample only.
 7. **Automation mode template/config audit**: inspect existing send-lane briefs for a `Delivery format:` line and chat-native warm template. If a send lane is missing the line and the prompt allows cleanup, update only the campaign brief metadata with the safest default for that lane (`Delivery format: single message (LinkedIn DM; line breaks remain inside one generated message; no follow-up until reply)`). If cleanup is not allowed, flag it. Do not generate a sample row in automation mode unless the invocation explicitly asks for sample proof. In structure-only automation, do not generate a sample row unless the invocation explicitly asks for sample proof. In customer-visible completion, follow the Customer-Visible Completion Contract instead.
-8. **Final customer-facing completion must include sample messaging**: after customer-visible verify and the idempotency rerun pass, add a `Sample Messaging Review` section to the final answer. For every completed lane, show at least one full generated first message for every completed lane with campaign name, campaign id, row id, and verdict. Extract samples from nested `createCampaignStepReceipt.messageDraftingReceipt.sampleMessages`, not from top-level summaries; extract samples from nested `createCampaignStepReceipt.messageDraftingReceipt.sampleMessages` when building the final answer. Prefer the approved route-proof row when it is quality-valid; otherwise use the best reviewed generated row from the verified receipt. A final `passed` sample must have `issues:[]`; if every reviewed sample has issues, report the lane as needing message revision instead of presenting a passed sample. Do not summarize the sample into a copy theme. Show the actual message text so the user can inspect tone and specificity. If any sample is not quite right, tell the user they can ask the AI to update the campaign brief/message template and rerun Generate Message before launch. Never suggest launching, scheduling, or sending as the next step from this command.
-   If the `Sample Messaging Review` section is omitted, the command is incomplete even when the structural campaign setup succeeded.
-9. **Report the reconcile plan and result** — every slot tagged `reused`, `created`, `repaired`, `flagged`, or `blocked`, plus template/sample details only when that mode ran:
+8. **Report the reconcile plan and result** — every slot tagged `reused`, `created`, `repaired`, `flagged`, or `blocked`, plus template/sample details only when that mode ran:
 
 ```
 Evergreen Reconcile — {date}
@@ -1161,17 +953,6 @@ Evergreen Reconcile — {date}
 • Sellable.dev - Shared Signal Discovery: repaired (send review ready; 50 rows, 3 generated, 1 approved gate row, sequence attached, paused)
 • Sellable.dev - Shared Cold Fallback: created (send review ready; 50 rows, 3 generated, 1 approved gate row, sequence attached, paused)
 All campaigns remain unlaunched. Next: enrich/approve more rows when you want more items ready to schedule.
-
-Sample Messaging Review
-• Christian Reyes - Post Engagers (`cmp_...`, row `row_...`, verdict: passed)
-  ```
-  {{full generated first message}}
-  ```
-• Sellable.dev - Shared Cold Fallback (`cmp_...`, row `row_...`, verdict: passed)
-  ```
-  {{full generated first message}}
-  ```
-If any sample is not quite right, ask the AI to update the campaign brief/message template and rerun Generate Message before launch.
 ```
 </objective>
 

package/skill-templates/refill-sends.md

@@ -5,6 +5,9 @@ visibility: public
 allowed-tools:
   - mcp__sellable__get_subskill_prompt
   - mcp__sellable__search_subskill_prompts
+  - mcp__sellable__list_senders
+  - mcp__sellable__get_sender_routing
+  - mcp__sellable__get_campaign_waterfall
   - mcp__sellable__resolve_campaign_fill_route
   - mcp__sellable__get_campaign_refill_state
   - mcp__sellable__fill_campaign_horizon
@@ -35,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
 ---
@@ -51,10 +55,39 @@ get_subskill_prompt({ subskillName: "refill-sends-workflow" })
 ```
 
 Then follow that workflow exactly. The default path is read-only research:
-resolve the route, read target refill state, report the next safe step, 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.
+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.
+
+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