@sellable/mcp 0.1.402 → 0.1.404

package/dist/tools/prompts.js

@@ -373,7 +373,7 @@ export function getPostFindLeadsScoutRegistry() {
             codex: 'After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not spawn anything before that question. After the answer, launch only Message Drafting. The filter-choice answer is the post-import user gate for this single worker; do not ask another question about starting it in step-wise or YOLO mode. The registry lookup is not a launch: after get_post_find_leads_scout_registry, immediately invoke Task/spawn_agent or the host background-agent mechanism before loading filter-leads.md, before saving rubrics, and before treating skip-filters as ready for message review. Both choices route through this kickoff; do not let filters_skipped jump straight from filter-choice to message-generation. If filters are chosen, the parent stays on Filter Rules and drafts/saves rubrics with MCP tools while Message Drafting runs in the background. If filters are skipped, move to Messages/message review only after Message Drafting has started or is ready; update_campaign(currentStep=messages) is not proof of launch. If the named Message Drafting custom agent is unavailable, spawn a generic gpt-5.5 xhigh Message Drafting background agent with the same lean campaign/table basis. When the background worker starts, persist workerDetails.messageDraftBuilder with statusSource "branch", status "branch-running", runId, startedAt, updatedAt, basisToken when known, and basis containing campaignId, selectedLeadListId, workflowTableId, filterChoice, and reviewBatchRowHash or reviewBatchRowIds; workerStatuses.messageDraftBuilder may be "running" as a simple badge only. Never put rich proof under workerStatuses and never use workerStatuses.messageDrafting. If no background-agent tool is callable, start the same full message branch inline before filter drafting or before skip-filter message review, record workerDetails.messageDraftBuilder with statusSource "parent-thread-fallback" and status "fallback-active", and require the same live context, prompt, assets, and validation gate before message review; do not wait until filters are saved and then call the registry.',
             claude: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not invoke any Task/Agent before that question. After the answer, invoke only Message Drafting. If filters are chosen, parent drafts/saves rubrics with MCP tools while Message Drafting runs, asks filter approval, then joins Message Drafting. If filters are skipped, invoke only Message Drafting and move to Messages/message review.",
             parentThreadRule: 'Named agents are optional acceleration, but message drafting is not optional. The only normal background worker is Message Drafting. The filter-choice answer is the campaign-scoped go-ahead for this single post-import worker; do not ask another question to start it in step-wise or YOLO mode. If a named agent is unavailable, use a generic gpt-5.5 xhigh Message Drafting background agent. source work and filter work stay in the parent thread with MCP tools. If post-find-leads-message-scout is available, run it as the background Message Draft Builder after the filter-choice answer. The registry lookup is not a launch: get_post_find_leads_scout_registry only identifies the worker, and Message Drafting counts as started only after Task/spawn_agent or the host background-agent tool is invoked, or after the parent begins the same full message branch inline because no background-agent tool is callable. This launch must happen before loading filter-leads.md, save_rubrics, filter approval, or skip-filter message review; currentStep=messages is not proof of launch. If post-find-leads-message-scout is absent, do not customer-surface install status. Do not silently treat message drafting as started; the main thread must either launch the background worker or execute the same message branch from CampaignOffer state, selected source state, workflowTableId, and initial campaign-table execution slice rows. For a spawned worker, record workerDetails.messageDraftBuilder with statusSource branch / status branch-running, runId, startedAt, updatedAt, and basis containing campaignId, selectedLeadListId, workflowTableId, filterChoice, and reviewBatchRowHash or reviewBatchRowIds. workerStatuses.messageDraftBuilder is optional simple badge text only ("running", "ready", "blocked", "idle"); never put runId/statusSource/basis under workerStatuses and never use workerStatuses.messageDrafting. If no background-agent tool is callable, start that same full message branch inline before filter drafting or before skip-filter message review, record workerDetails.messageDraftBuilder with statusSource parent-thread-fallback / status fallback-active then ready, and require the same live context, prompt, assets, and validation gate before message review; do not report that as a background worker failure. If neither branch nor inline fallback can run, return blocked/retry-needed; do not wait until filters are saved and then call the registry. The Message Drafting handoff must be lean. Do not paste copied row counts, brief hashes, review-batch hashes, full reviewBatchRowIds, broad row data, or local debug artifacts into the spawn prompt. Local markdown/json files are not normal-path inputs. The filter-choice question is the first post-import user gate; do not load post-lead registries or filter references before it. Message drafting starts after the filter-choice answer, must load get_subskill_prompt({ subskillName: "generate-messages" }), and must load every required message asset named by generate-messages Mode 0 through get_subskill_asset before drafting. Reference Asset Loading means loading the required pre-draft reference pack before drafting; return blocked/retry-needed if required assets cannot be loaded; load ai-tells.md because it is never optional. The branch or parent-thread fallback loads the full generate-messages prompt and every referenced asset through get_subskill_asset. After generating/revising the candidate and before returning ready, must load get_subskill_prompt({ subskillName: "create-campaign-v2-validation" }) as the final internal validation gate, must read live campaign table state through scoped MCP/product tools, and must reject mismatched selectedLeadListId/workflowTableId/campaign/workspace input. Do not block when filters were chosen but leadScoringRubrics are not yet visible in the branch read; the parent owns save_rubrics and filter approval in parallel, so Message Drafting should return status ready with basisStatus usable_initial when campaign/list/table identity and the non-empty execution slice match. Do not use any alternate, local-artifact, or examples-only message prompt. User copy feedback, message QA, or rewrite requests before approve-message must be routed back to Message Drafting with the current recommendation, lean campaign/table basis, and latest user text; the parent must not rewrite or QA the template from memory and must not call update_campaign_brief before approve-message. The worker validates internally and returns only templateRecommendation, tokenFillRules, renderedGoodSample, status, approveOrReviseRecommendation, validationStatus, outputAt, outputHash, and blocked/retry detail. Do not render renderedFallbackSample, risk notes, or a qaReceipt on the normal happy path. On the filter path, save_rubrics keeps the browser on Filter Rules after save_rubrics so the user can approve the saved criteria; after saved-filter approval, move to Filter Leads with currentStep=apply-icp-rubric whether Message Drafting is ready or still running. Wait there for message approval. Enrichment, filtering, Generate Message cells, sender setup, sequence attach, and launch wait for template approval on the Use Template path. On the skip path, move to Messages/message review after Message Drafting has started or is ready and wait for message approval before enrichment or Settings. Do not render message review from checklist or shortcut instructions; message review requires a messageDraftRecommendation whose basis proves the generate-messages prompt, required message assets, and validation gate ran for the current campaign/table execution slice. Do not automatically rerun Message Drafting after filters/enrichment finish; show the initial draft by default and offer an enriched rewrite only with explicit user opt-in. Handoff and recommendation output are Markdown with labeled fields, not raw JSON.',
-            prepareMessagesRule: `Default create-campaign stays on the existing reviewBatchLimit:15 first campaign-table execution slice. For plain post-mint fill/load/refill requests, load get_subskill_prompt({ subskillName: "refill-sends-workflow" }), then call resolve_campaign_fill_route({ intent:"plain" }) and get_campaign_refill_state before any mutation. Route outcomes are route:"evergreen_horizon", route:"active_campaigns", and route:"ask_create"; stay in the same campaignOfferId/campaignId context after minting. Plain fill is not an alias for fill_campaign_horizon or campaign creation. fill_campaign_horizon is evergreen-only and is not the generic regular-campaign fill path. Campaign creation is allowed only after route:"ask_create" and explicit user selection; it is never the default response to plain fill. Treat "fill up/load sends" as capacity-fill preparation: calculate the bounded target from sender capacity when needed, then use the refill workflow to decide same-campaign source replenishment, enrichment/prep, approval/ready state, scheduler reread, and sender-health blockers. Do not create warm-post-engager side campaigns. For already-running regular campaigns that need Signal Discovery source replenishment, use the guarded currentStep clear with clearCurrentStepIfMatches:"running", campaign-scoped provider prompt/search/select, and import_leads with the existing sourceLeadListId when a newly approved selected-post scrape would otherwise return reusedExistingSourceList. After confirm_lead_list copies rows into an existing table, avoid fixed maxRowsToCheck:100; inspect reviewBatch/table selectors or use adaptive/wider bounded prep so appended rows are included. Do not interpret checkedRows as enriched rows; it is only the table cursor. Prepared, approved, and ready_to_schedule rows are intermediate states; never call them scheduled unless a re-read proves scheduler-owned scheduled cells with non-null scheduledFor. Before source import, prep, or approval, require exact visible approval and a fresh get_campaign_refill_state reread; stop if freshness.stateHash or exact ids changed. For "approve X messages", use approvalMode:approve only when explicitly requested, but still do not launch. For "schedule X sends" or "fill sender sends", approve only when explicitly requested, then re-read campaign/table scheduled counts; if scheduler-owned scheduledFor cells are not present, report prepared/approved/ready - awaiting scheduler instead of success. Do not call start_campaign as part of fill/schedule horizon. Do not call start_campaign as part of refill sends. Launch/start is a separate explicit human action after the operator intentionally wants sends to go out, and it must still verify that the bounded cohort is the only approved cohort and must not broad approve-all. campaignId is CampaignOffer.id. If the user asks to stop preparation, the target is wrong, or status shows the wrong campaign/table, use cancel_campaign_message_preparation only for the exact active job. Low-level selectors are diagnostics and recovery only for this lane. start_campaign remains forbidden until explicit launch/start approval outside refill sends.`,
+            prepareMessagesRule: `Default create-campaign stays on the existing reviewBatchLimit:15 first campaign-table execution slice. For plain post-mint fill/load/refill requests, load get_subskill_prompt({ subskillName: "refill-sends-workflow" }), then call resolve_campaign_fill_route({ intent:"plain" }), list_senders, and get_campaign_refill_state for enough candidate campaigns to identify the campaign that most recently had scheduler-owned sends for the relevant sender set before any mutation. Route outcomes are route:"evergreen_horizon", route:"active_campaigns", and route:"ask_create"; stay in the same campaignOfferId/campaignId context after minting. Plain fill is not an alias for fill_campaign_horizon or campaign creation. fill_campaign_horizon is evergreen-only and is not the generic regular-campaign fill path. Campaign creation is allowed only after route:"ask_create" and explicit user selection; it is never the default response to plain fill. Treat "fill up/load sends" as capacity-fill preparation. In --yolo fill/refill mode, default to one best recent-send campaign and a two-send-day horizon: calculate the bounded gap from healthy sender daily capacity minus future scheduler-owned scheduled sends and ready-to-schedule rows, then prepare only that gap. Use the refill workflow to decide whether to enrich/prep more rows in that same recent-send campaign, add/import more rows to that same campaign/source path, use a different existing campaign only when the recent-send lane is blocked/exhausted, or ask what to create. Do not create warm-post-engager side campaigns. Surface sender-health blockers separately from prepared/approved/scheduled counts. User-facing refill decisions must be campaign-name-first and sender-name-first, with ids as proof/execution targets only. For already-running regular campaigns that need Signal Discovery source replenishment, use the guarded currentStep clear with clearCurrentStepIfMatches:"running", campaign-scoped provider prompt/search/select, and import_leads with the existing sourceLeadListId when a newly approved selected-post scrape would otherwise return reusedExistingSourceList. After confirm_lead_list copies rows into an existing table, avoid fixed maxRowsToCheck:100; if confirm_lead_list returns USER_ADDED_ROWS_LIMIT_EXCEEDED, create a bounded same-source split from selectedLeadListId with get_rows_minimal/load_csv_linkedin_leads, confirm that smaller source list into the same campaign, and operate on the reviewBatch first; inspect reviewBatch/table selectors or use adaptive/wider bounded prep so appended rows are included. Do not interpret checkedRows as enriched rows; it is only the table cursor. Prepared, approved, and ready_to_schedule rows are intermediate states; never call them scheduled unless a re-read proves scheduler-owned scheduled cells with non-null scheduledFor. Before source import, prep, or approval, require exact visible approval and a fresh get_campaign_refill_state reread; stop if freshness.stateHash or exact ids changed. For "approve X messages", use approvalMode:approve only when explicitly requested, but still do not launch. For "schedule X sends" or "fill sender sends", approve only when explicitly requested, then re-read campaign/table scheduled counts; if scheduler-owned scheduledFor cells are not present, report prepared/approved/ready - awaiting scheduler instead of success. Do not call start_campaign as part of fill/schedule horizon. Do not call start_campaign as part of refill sends. Launch/start is a separate explicit human action after the operator intentionally wants sends to go out, and it must still verify that the bounded cohort is the only approved cohort and must not broad approve-all. campaignId is CampaignOffer.id. If the user asks to stop preparation, the target is wrong, or status shows the wrong campaign/table, use cancel_campaign_message_preparation only for the exact active job. Low-level selectors are diagnostics and recovery only for this lane. start_campaign remains forbidden until explicit launch/start approval outside refill sends.`,
         },
     };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.402",
+  "version": "0.1.404",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign/SKILL.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/skills/create-campaign-v2/references/ai-tells.md

@@ -55,12 +55,6 @@ raise your hand for X (creepy to reach out based on that, i know) - but
 this felt too on the nose to ignore"` shapes only when the source was an
 explicit lead-magnet comment, reply, or opt-in.
 
-Shared evergreen exception: for Shared Signal Discovery and other shared
-evergreen lanes, the weak-signal permissioned bridge above is still a tell.
-Reject `hope this is relevant`, `might be interested`, and `saw you in a few
-conversations` as openers; require a concrete signal/problem bridge or omit the
-source line.
-
 **Severity:** REJECT
 
 ## Tell #3 — Explicit date or duration references about the recipient

package/skills/create-campaign-v2/references/gold-standard-message-examples.md

@@ -203,32 +203,6 @@ Why it works:
 **Proof ranks used:** rank 1 (mechanism - 1,000+ conditions from one blood
 draw), rank 3 (risk before claims).
 
-Do not use the Superpower weak-signal hedge pattern for Shared Evergreen Signal Discovery. Shared evergreen lanes are reused across multiple senders and must not open with `hope this is relevant`, `might be interested`, or `saw you in a few conversations`. Use the safe pattern below instead.
-
-### Shared Evergreen Signal Discovery Safe Pattern
-
-Use when the campaign is a shared evergreen signal lane and the source signal is
-real but not sender-owned.
-
-```text
-Hey {{first_name}},
-
-The AI-assisted GTM conversations keep coming back to one problem: turning good LinkedIn signal into review-ready pipeline without another outbound dashboard.
-
-Sellable helps teams find signal-matched prospects, filter for fit, and generate reviewed LinkedIn copy from one workflow.
-
-Curious if LinkedIn outbound is a channel you're trying to make more reliable this quarter?
-```
-
-Why it works:
-
-- no low-confidence relevance hedge
-- no `I'm building` or founder-only first person
-- no internal workflow vocabulary such as Codex, MCP, agent workflows, workflow
-  table, lead source, or signal discovery
-- the signal becomes a buyer problem instead of an activity-log opener
-- safe for multiple senders attached to the same shared lane
-
 ## Conditional Examples
 
 Use these only when the campaign motion matches.

package/skills/create-campaign-v2/references/gold-standard-message-patterns.md

@@ -199,21 +199,11 @@ Shape:
 Prefer:
 
 - lowercase or casual casing when the motion supports it
-- an honest line like "hope this is relevant" or "so may be off, but this seemed relevant" only for non-evergreen weak-signal campaigns
+- an honest line like "hope this is relevant" or "so may be off, but this seemed relevant"
 - a concrete CTA that names the useful conversation or asset
 - binary options only when the brief explicitly supports two real next steps
 - direct wording over polished marketing language
 
-Shared Evergreen Signal Discovery override:
-
-- Do not use `hope this is relevant`, `might be interested`, or `saw you in a
-  few conversations` as the opener.
-- Do not use `I'm building`, `I've mapped`, `my company`, or `my team`.
-- Turn the source topic into a buyer problem bridge, then write the product line
-  in team/company voice.
-- If the source topic cannot support a concrete bridge, omit the source line and
-  start from a role/company/problem observation.
-
 Avoid:
 
 - copying a gimmick like "from a claude code terminal" unless the brief

package/skills/create-campaign-v2/references/sellable-cleanup-rules.md

@@ -74,7 +74,7 @@ Revise or reject the sample when any of these happen.
 - **actions are implied, not stated** — e.g. "runs that chain as AI agents" when a clearer version would name the specific actions (verb + object, one per line)
 - **category-level opener used when a per-lead signal exists** — if `lead-sample.json` carries any per-lead signal (post, hire, visible tool, topic engagement), the opener must reference it. Category-level openers of shape `"Most [category] teams still do X by hand"` are only acceptable when zero per-lead signal is in the sample. When a category-level opener is used as fallback, Findings must flag it explicitly
 - **mind-reading from engagement signals** — a topic engagement, post, public activity, role, company, or hiring trigger does not prove buyer intent. Reject phrases like `"AI-GTM stack is clearly on your mind"`, `"you're clearly focused on..."`, `"obviously relevant"`, or `"already thinking about..."` unless that exact priority is explicitly present in `lead-sample.json`. Translate to low-certainty buyer context or omit the signal from copy.
-- **source-y signal narration** — reject `"saw you on..."`, `"saw you engaging with..."`, `"you commented on..."`, `"your LinkedIn activity..."`, `"you might not remember the thread..."`, `"found you through [source] and your role looked close..."`, or any line that makes the recipient feel watched unless the chosen archived motion is intentionally self-aware about the signal. For sender-owned LinkedIn post sources, a light first-person acknowledgment is allowed when row data proves a reaction/comment: `"appreciate you showing some love on my post about [topic]"` or `"thanks for showing support on my [topic] post"`. Do not name a comment unless comment text is present. Follow the acknowledgment with a soft relevance bridge before broad pain/product copy, e.g. `"figured this might be relevant if LinkedIn is becoming more of a GTM channel for [company]"`. For third-party LinkedIn-post-sourced campaigns, a topic-level bridge is allowed when it explains why the note exists and stays apologetically uncertain: `"saw you in a few conversations about [topic], so may be off, but this seemed relevant."`, `"saw you in a few conversations around [topic], so hope this is relevant."`, or `"found you in a thread about [topic], so may be off, but this seemed relevant."` Shared evergreen signal exception: these hedges are blocked for Shared Signal Discovery and other shared evergreen lanes; use a concrete signal/problem bridge or omit the source line. Reserve `"raise your hand"` language for explicit lead-magnet comments, replies, or opt-ins. Translate the signal into natural buyer context or omit it.
+- **source-y signal narration** — reject `"saw you on..."`, `"saw you engaging with..."`, `"you commented on..."`, `"your LinkedIn activity..."`, `"you might not remember the thread..."`, `"found you through [source] and your role looked close..."`, or any line that makes the recipient feel watched unless the chosen archived motion is intentionally self-aware about the signal. For sender-owned LinkedIn post sources, a light first-person acknowledgment is allowed when row data proves a reaction/comment: `"appreciate you showing some love on my post about [topic]"` or `"thanks for showing support on my [topic] post"`. Do not name a comment unless comment text is present. Follow the acknowledgment with a soft relevance bridge before broad pain/product copy, e.g. `"figured this might be relevant if LinkedIn is becoming more of a GTM channel for [company]"`. For third-party LinkedIn-post-sourced campaigns, a topic-level bridge is allowed when it explains why the note exists and stays apologetically uncertain: `"saw you in a few conversations about [topic], so may be off, but this seemed relevant."`, `"saw you in a few conversations around [topic], so hope this is relevant."`, or `"found you in a thread about [topic], so may be off, but this seemed relevant."` Reserve `"raise your hand"` language for explicit lead-magnet comments, replies, or opt-ins. Translate the signal into natural buyer context or omit it.
 - **sender-owned source rendered as third-party** — hard fail when the source post is sender-owned and the draft says `"found you in a thread"`, `"saw you in a thread"`, `"saw you in conversations"`, or `"saw you in a few conversations"` as if the post were third-party. For sender-owned sources, the copy must either use a light first-person acknowledgment plus a soft relevance bridge, or omit the source line. If multiple senders may send the campaign, or the final sender/source-owner match is ambiguous, do not assume a specific `my post` voice or name a specific sender; omit the sender-owned source line until row-level sender ownership is proven. Neutral low-certainty thread/source language is only for truly third-party sources.
 - **fake line-to-line continuity** — reject line stacks where the source acknowledgment, relevance bridge, product line, and CTA do not actually build on each other. Each line must make the next line feel earned. If two adjacent lines could be swapped, deleted, or joined with `"anyway"` without changing the meaning, the transition is fake. In sender-owned post campaigns, the chain should be: support on my post -> why this topic may matter for the company -> what the product/problem does about that same topic -> low-friction next step.
 - **assumptive title-fit opener** — reject `"Your [role] role at [company] looked close to this problem"` or `"looked close to this outbound campaign problem"`. This asserts fit from title/company. Keep the apologetic uncertainty instead: `"may be off, but if [workflow] is relevant to what you're working on..."`.

package/skills/create-evergreen-campaigns/SKILL.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,73 +264,20 @@ 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 the auto-executable plan returns, take at most one short planning pass to
-choose the visible/durable worker runtime and build the worker launch packet.
-Do not keep reasoning, re-reading prompts, or restating the workflow instead of
-dispatching. If the parent cannot name the callable worker runtime and prepare
-the first worker launch command/tool call immediately after that pass, stop with
-`blocked: worker_dispatch_deadline_exceeded` before directory setup or mutation.
 After creating receipt directories, dispatch workers immediately; do not perform extended parent reasoning, extra inventory, or prompt rewriting loops.
-Before any campaign shell creation, the parent must dispatch every selected lane
-worker from the current plan and record the visible thread id or
-`receiptArtifactPath` for each selected actionId. The parent must not call
-`create_campaign`, `import_leads`, `confirm_lead_list`, sequence tools, message
-preparation tools, or `setup_evergreen_campaigns` with `mode:"apply"` or any
-other mutating setup mode. In this wrapper, `setup_evergreen_campaigns` is
-plan/verify authority only; customer-visible creation belongs inside lane
-workers through `$sellable:create-campaign`. If a campaign/table id appears for
-a create lane before that lane has a recorded worker runtime and fresh receipt
-path/thread id, stop with `blocked: parent_mutated_before_worker_receipt` and
-do not continue setup in the parent.
-Short form: dispatch every selected lane worker before shell creation.
-Short form: do not call `setup_evergreen_campaigns` with `mode:"apply"` from the parent.
 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.
-After launching workers, poll only the expected current-run receipt paths from
-`workerDispatch.receiptArtifactHint`. If no worker receipt file appears within a
-bounded wait, for example 10 minutes in automation, stop with
-`blocked: worker_receipt_timeout`, include the worker ids/final-file paths/stderr
-if available, and do not create or repair campaign shells in the parent.
 Use only the repo-local `workerDispatch.receiptArtifactHint` returned by the
 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'
@@ -365,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>
@@ -380,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
@@ -452,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"`,
@@ -514,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`,
@@ -668,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": {
@@ -754,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
@@ -793,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
@@ -851,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
@@ -878,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.
@@ -932,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
@@ -944,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
@@ -960,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
@@ -990,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
@@ -1065,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
@@ -1090,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.
@@ -1174,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}
@@ -1185,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/skills/generate-messages/SKILL.md

@@ -252,35 +252,6 @@ must read like final create-campaign/generate-messages output.
   samples. If two samples would still read the same after replacing names and
   companies, revise or rerun.
 
-### Shared Evergreen Signal Discovery hard gate
-
-For Shared Signal Discovery and other shared evergreen lanes, signal-led copy
-must be safer than the legacy weak-signal examples. These lanes are reused by
-multiple senders, so the first line cannot sound like a scraped-activity excuse
-or a founder self-intro.
-
-- `hope this is relevant`, `might be interested`, and `saw you in a few conversations` are blocked openers for shared evergreen lanes.
-- do not write first-person singular founder language such as `I'm building`,
-  `I've mapped`, `my company`, or `my team` unless exactly one sender can
-  credibly say it and the lane is not shared.
-- Do not put internal workflow vocabulary in buyer-facing copy: `Codex`, `MCP`,
-  `Claude-style agent workflows`, `agent workflows`, `workflow table`, `lead
-  source`, or `signal discovery`.
-- Write a concrete signal/problem bridge instead of a relevance hedge. Good
-  shapes are `the AI-assisted GTM conversations keep coming back to [buyer
-  problem]`, `teams trying to turn LinkedIn signal into pipeline usually hit
-  [problem]`, or `when [observable business moment] is live, [buyer workflow]
-  gets harder to run consistently`.
-- If the row evidence is too weak to write a concrete bridge, omit the source
-  line and start from a buyer problem, event, role, or company observation.
-- Shared evergreen lanes must pass this gate before `confirmed`, before saving a
-  reusable template, and before any route-proof approval.
-
-Short form: shared evergreen copy cannot use `hope this is relevant`.
-Short form: shared evergreen copy cannot use `might be interested`.
-Short form: shared evergreen copy cannot use `I'm building`.
-Short form: write a concrete signal/problem bridge instead of a relevance hedge.
-
 ### Rich Personalization Contract
 
 The `create-campaign` asset `references/ai-native-tokens.md` is the canonical
@@ -298,15 +269,12 @@ conditional good/bad fill reference.
 - Use this shape for any hook, bridge, or row-specific relevance line:
   `[PERSONALIZATION_LINE — Intent: write one short sentence that anchors the
 note to why this might matter now. DO: connect one observable role/company/
-activity signal to the buyer problem or offer with a permissioned bridge. For
-shared evergreen lanes, do not use `hope this is relevant`, `might be
-interested`, or `saw you in a few conversations`; use a concrete
-signal/problem bridge instead. For non-evergreen weak-signal campaigns only,
-legacy low-certainty language like "hope this is relevant if..." or "so may be
-off, but this seemed relevant" can be considered when the source is otherwise
-awkward. DON'T: recap their resume, list companies, compliment their
-background, name a product their company sells, use source-citation phrasing, or
-use generic nouns like "your work".
+activity signal to the buyer problem or offer with low-certainty language like
+"hope this is relevant if...", "saw you might be interested in...", "saw you in
+a few conversations around...", or "figured this might matter if...". DON'T: recap
+their resume, list companies, compliment their background, name a product their
+company sells, use source-citation phrasing, or use generic nouns like "your
+work".
 FALLBACK: if unsupported, omit the entire line.]`
 - The rendered personalization line should usually be 6-14 words. If it needs
   two clauses, multiple companies, or abstract tags like `GTM`, `international
@@ -465,9 +433,9 @@ artifact.**
 
    Safer shapes:
 
-   - `hope this is relevant if {{signal_topic}} is part of the plan` for non-evergreen weak-signal campaigns only
-   - `saw you might be interested in {{signal_topic}}, so hope this is relevant` for non-evergreen weak-signal campaigns only
-   - `saw you in a few conversations around {{signal_topic}}, so hope this is relevant` for non-evergreen weak-signal campaigns only
+   - `hope this is relevant if {{signal_topic}} is part of the plan`
+   - `saw you might be interested in {{signal_topic}}, so hope this is relevant`
+   - `saw you in a few conversations around {{signal_topic}}, so hope this is relevant`
    - `saw you in a few conversations about {{signal_topic}}, so may be off, but this seemed relevant`
    - `appreciate you showing some love on my post about {{signal_topic}}` only when the sender/client authored the source post and the row proves a reaction or comment
    - `thanks for showing support on my {{signal_topic}} post` only when the sender/client authored the source post and the row proves a reaction or comment
@@ -531,22 +499,20 @@ artifact.**
    magnet replies, or scraped conversations), it is acceptable to reference the
    conversation when it explains why the note exists. Keep it topic-level, not
    activity-log-level: `saw you in a few conversations around
-   {{signal_topic}}, so hope this is relevant` is acceptable only for
-   non-evergreen weak-signal campaigns; it is blocked for Shared Evergreen
-   Signal Discovery. `saw you commented on {{post_context}}` and `your LinkedIn
-   activity around...` are not acceptable. Reserve `raise your hand` phrasing
-   for explicit lead-magnet comments, replies, or opt-ins. For ordinary shared
-   evergreen thread discovery, either translate the topic into a concrete
-   buyer/problem bridge or omit the source line.
+   {{signal_topic}}, so hope this is relevant` is acceptable; `saw you
+   commented on {{post_context}}` and `your LinkedIn activity around...` are
+   not. Reserve `raise your hand` phrasing for explicit lead-magnet comments,
+   replies, or opt-ins. For ordinary thread discovery, use `saw you in a few
+   conversations around {{signal_topic}}...` or `found you in a thread about
+   {{signal_topic}}...`.
 
    Keep the apologetic nature, but aim it at uncertainty, not surveillance.
-   Good for non-evergreen weak-signal campaigns: `saw you in a few
-   conversations about outbound, so may be off, but this seemed relevant`, `may
-   be off, but if outbound is relevant to what you're working on...`, or `hope
-   this is relevant if...`. For shared evergreen lanes, these hedges are not
-   enough; use a concrete signal/problem bridge or omit the source line. Bad:
-   `your role at {{company}} looked close...`, because it asserts fit from a
-   title and tells the buyer about themselves.
+   Good: `saw you in a few conversations about outbound, so may be off, but
+   this seemed relevant`, `may be off, but if outbound is relevant to what
+   you're working on...`, `if this is not relevant to your outbound workflow,
+   ignore me`, `hope
+   this is relevant if...`. Bad: `your role at {{company}} looked close...`,
+   because it asserts fit from a title and tells the buyer about themselves.
 
    Block wordier source narration such as `you might not remember the thread,
    but I found you through a {{signal_topic}} discussion and your
@@ -1543,10 +1509,7 @@ Before `confirmed`, run the selected winner against these gates:
   the lead sample. If desire is inferred, use tentative framing like
   `hope this is relevant if...`, `saw you might be interested in...`,
   `saw you in a few conversations around...`, `figured this might matter if...`,
-  or `if you've ever wanted...`. Exception: for Shared Signal Discovery and
-  other shared evergreen lanes, `hope this is relevant`, `might be interested`,
-  and `saw you in a few conversations` are blocked; use a concrete
-  signal/problem bridge or omit the source line.
+  or `if you've ever wanted...`.
 - **Buyer-first opener:** after the greeting, the first substantive line
   should usually enter the buyer's world: a real signal, current-state
   pain, buyer-owned priority, or useful artifact. Sender-origin can come
@@ -1847,11 +1810,8 @@ about`, or `clearly relevant` are BLOCKED. Source-y phrases such as
   `saw you might be interested in [topic], so hope this is relevant`, `saw you
   in a few conversations around [topic], so hope this is relevant`, `found you
   in a few conversations about [topic], so may be off, but this seemed
-  relevant`, `figured this might matter if [workflow] is live at [company]`, or
-  a similarly natural line. For shared evergreen lanes, skip the `hope this is
-  relevant` / `might be interested` / `saw you in a few conversations` versions
-  and use the concrete bridge version. Longer source-recap forms such as `you
-  might not remember the thread,
+  relevant`, `figured this might matter if [workflow] is live at [company]`, or a similarly natural
+  line. Longer source-recap forms such as `you might not remember the thread,
   but I found you through a [topic] discussion...` are BLOCKED; they narrate
   the scrape path instead of creating buyer relevance.
 - **Engagement reference is opt-in, not the default opener:** do not
@@ -1996,9 +1956,9 @@ matters to the buyer, why this might be relevant, or the operator-reality that
 led to it. Acceptable openers:
 
 - `Hey {{first_name}}, [one plain sentence about what we built].`
-- `Hey {{first_name}}, hope this is relevant if [buyer context] is still on your plate.` Not for shared evergreen lanes.
-- `Hey {{first_name}}, saw you might be interested in [topic], so hope this is relevant.` Not for shared evergreen lanes.
-- `Hey {{first_name}}, saw you in a few conversations around [topic], so hope this is relevant.` Not for shared evergreen lanes.
+- `Hey {{first_name}}, hope this is relevant if [buyer context] is still on your plate.`
+- `Hey {{first_name}}, saw you might be interested in [topic], so hope this is relevant.`
+- `Hey {{first_name}}, saw you in a few conversations around [topic], so hope this is relevant.`
 - `Hey {{first_name}}, found you in a thread about [topic], so may be off, but this seemed relevant.`
 - `Hey {{first_name}}, saw you raise your hand for [topic], so figured this was (hopefully) worth sending.` Only use this for explicit lead-magnet comments, replies, or opt-ins.
 - `Hey {{first_name}}, saw you raise your hand for [topic] (creepy to reach out based on that, i know) - but this felt too on the nose to ignore.` Only use this for explicit lead-magnet comments, replies, or opt-ins.
@@ -2259,9 +2219,9 @@ Rules:
 - if `lead-sample.json` carries **any** per-lead signal for this lead — a recent post, a recent hire, a visible tool in the headline, a topic engagement, a public initiative — the **message must reference it specifically**. Category-level copy is rejected.
 - default placement is **Block 3**, not Block 1. Keep Block 1 substance-first unless the archived motion clearly earns a signal-led opener without falling into source-citation / talk-at phrasing.
 - acceptable signal use by default:
-  - `"Hope this is relevant if [topic] is part of the plan."` Non-evergreen weak-signal only; blocked for shared evergreen lanes.
-  - `"Saw you might be interested in [topic], so hope this is relevant."` Non-evergreen weak-signal only; blocked for shared evergreen lanes.
-  - `"Saw you in a few conversations around [topic], so hope this is relevant."` Non-evergreen weak-signal only; blocked for shared evergreen lanes.
+  - `"Hope this is relevant if [topic] is part of the plan."`
+  - `"Saw you might be interested in [topic], so hope this is relevant."`
+  - `"Saw you in a few conversations around [topic], so hope this is relevant."`
   - `"Saw you in a few conversations about [topic], so may be off, but this seemed relevant."`
   - `"Found you in a thread about [topic], so may be off, but this seemed relevant."`
   - `"Thought of {{company}} because [observable signal] points at [problem]."`
@@ -2279,11 +2239,6 @@ Rules:
   - `"Saw you raise your hand for [topic], so figured this was worth sending."`
   - `"Figured this was worth sending."`
 - signal-led opener shape is a **special case**, not the default. Use it only when the archived motion truly depends on it and the line can stay natural. For LinkedIn-post-sourced campaigns, prefer `"saw you in a few conversations around [topic], so hope this is relevant"` or `"found you in a thread about [topic], so may be off, but this seemed relevant"` when referencing the source makes the outreach feel less random. Avoid activity-log phrasing such as `"you commented on..."`, `"you reacted to..."`, or `"your LinkedIn activity..."` unless the approved motion is the deliberately self-aware raise-hand line for an explicit lead-magnet comment, reply, or opt-in.
-- For Shared Evergreen Signal Discovery, do not use the weak signal-led opener
-  shapes above. Translate the source into a concrete problem bridge, e.g.
-  `"The AI-assisted GTM conversations keep coming back to one problem: turning
-  good LinkedIn signal into review-ready pipeline without another dashboard."`
-  Then connect the product in buyer language.
 - tokenized engagement-source opener shape is BLOCKED by default:
   `{{first_name}}, saw you {{engagement_context}} on {{post_context}}` reads
   like surveillance unless the filled line is explicitly self-aware and
@@ -2292,9 +2247,7 @@ Rules:
 this is relevant`, `saw you in a few conversations around [topic], so hope this
 is relevant`, `saw you in a few conversations about [topic], so may be off,
 but this seemed relevant`, or `found you in a thread about [topic], so may be
-off, but this seemed relevant`. For shared evergreen lanes, those weak signal
-bridges are blocked; use a concrete signal/problem bridge instead. Use the
-self-aware raise-hand shapes only when
+off, but this seemed relevant`. Use the self-aware raise-hand shapes only when
 the source was an explicit lead-magnet comment, reply, or opt-in: `saw you raise
 your hand for [topic], so figured this was (hopefully) worth sending` or `saw you
 raise your hand for [topic] (creepy to reach out based on that, i know) - but

package/skills/refill-sends/SKILL.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

package/skills/refill-sends-workflow/SKILL.md

@@ -3,6 +3,9 @@ name: refill-sends-workflow
 description: Internal skill-led refill sends workflow for regular campaigns and evergreen campaigns.
 visibility: internal
 allowed-tools:
+  - 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
@@ -33,6 +36,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
 ---
@@ -52,11 +56,27 @@ Plain phrases that enter here include "fill", "refill sends", "max out sends",
    fill/load language, `intent:"active"` only when the user explicitly narrowed
    to active regular campaigns, and `intent:"evergreen"` only when the user
    explicitly asked for evergreen or horizon work.
-2. Pick exact ids from the resolver result. Do not use campaign names or table
-   names as target identifiers.
-3. Call `get_campaign_refill_state` for the selected `campaignId` or `tableId`.
-   This must be the next target-specific research primitive.
-4. Classify the target from refill state:
+2. Resolve sender context before choosing a target. Call `list_senders`; when a
+   managed program is involved, also call `get_campaign_waterfall`, and call
+   `get_sender_routing` when territory rules may constrain sender eligibility.
+   If the user named senders, map those names to exact sender ids. If the user
+   did not name senders, infer the relevant senders from the most recent
+   scheduler-owned sends in refill-state readbacks and report that inference.
+   Short form: infer from the most recent scheduler-owned sends when the sender set is not explicit.
+3. Read `get_campaign_refill_state` for candidate campaigns from the resolver
+   result. For a broad `active_campaigns` route, inspect enough candidates to
+   identify the campaign or small campaign set that most recently had
+   scheduler-owned sends for the relevant sender set. Do not stop after the
+   first resolver target unless it is also the most recent sender-relevant send
+   lane.
+   Short form: Do not stop after the first resolver target unless recent-send evidence supports it.
+   In `--yolo` mode, selecting every active campaign is a scope error. Pick the
+   single highest-ranked recent-send campaign unless the refill-state evidence
+   proves multiple distinct sender lanes need separate two-day fills.
+   Short form: `--yolo` selects the best recent-send campaign first, not all active campaigns.
+4. Pick exact ids from the selected refill-state response. Do not use campaign
+   names or table names as target identifiers for tool calls.
+5. Classify the target from refill state:
    - regular campaign: campaign-backed workflow table with normal source,
      sequence, senders, and send/refill stages.
    - evergreen campaign: managed always-on lane with current source evidence.
@@ -77,7 +97,10 @@ Use the refill-state response as the current facts receipt:
   approved, ready to schedule, scheduled;
 - active message prep job;
 - scheduler-owned scheduled counts by date/action from cells with non-null
-  `scheduledFor`;
+  `scheduledFor`; treat these as the last sends/continuation signal;
+- latest scheduled send date, latest scheduled-cell update when present,
+  sender overlap with the requested or inferred sender set, and whether future
+  scheduled sends already exist;
 - `freshness.stateHash` and exact campaign/table/workspace ids.
 
 Empty or unsafe states stop with the blocker: no fillable target, missing or deleted campaign,
@@ -89,9 +112,61 @@ scheduler, or unsupported direct campaign type.
 
 For regular campaign workspaces, rank regular campaigns from route and
 `get_campaign_refill_state` evidence. Choose the best existing refill target.
+The default refill interpretation is "continue the campaign that was actually
+sending most recently for the relevant available senders", not "touch every
+active campaign".
+
+Default `--yolo` horizon is two send days when the user asks to fill, refill,
+load, or max sends without naming a different horizon. Compute the target from
+the selected campaign's healthy sender daily capacity for the next two send
+days, minus already scheduler-owned future scheduled sends for those days and
+minus rows already ready to schedule. If `readyToSchedule` already covers the
+two-day gap, do not add rows or prep; report that the selected campaign is loaded
+and awaiting the scheduler. If the gap is positive, prepare only the gap and keep
+all source-copy/prep caps tied to that two-day packet.
+Short form: default `--yolo` refill target is the selected campaign's two-day send gap.
+
+Rank candidates in this order:
+
+1. **Sender match**: campaigns whose healthy sender ids match the user-named
+   senders, or the inferred sender set when the user said only "fill sends" or
+   "load senders". Do not include campaigns merely because they are active when
+   their sender set is unrelated.
+2. **Recent sends**: campaigns with the newest scheduler-owned scheduled counts
+   and non-null `scheduledFor` cells for those senders. Future scheduled sends
+   are stronger continuation evidence than old historical sends; otherwise use
+   the latest scheduled send date / newest scheduled-cell update from refill
+   state.
+3. **Continuation capacity**: campaigns with healthy senders, remaining daily
+   capacity, and a gap between current ready-to-schedule rows and the desired
+   sender capacity.
+4. **Same-campaign source health**: prefer campaigns whose current source has
+   enough `sourceAvailable` inventory to prepare the gap. If source inventory
+   is low or exhausted, choose same-campaign row replenishment before switching
+   campaigns.
+5. **Campaign scope**: keep the selected set small. Normally choose one
+   campaign; choose multiple only when the recent-send evidence shows multiple
+   distinct sender lanes are actively being filled.
+
 Do not create side campaigns, warm-post-engager side campaigns, on-demand campaigns,
 or unrelated campaigns as the default answer to a fill request.
 
+For each selected campaign, decide the next action by the smallest sufficient
+step:
+
+- **Enrich/prep more rows in the same campaign** when sender health is good,
+  recent sends point to this campaign, and `sourceAvailable` can cover the
+  ready-to-schedule gap.
+- **Add/import more rows to the same campaign/source path** when the campaign is
+  the right recent-send lane but source inventory or viable rows cannot cover
+  the gap.
+- **Use a different existing campaign** only when the recent-send campaign is
+  blocked, archived, missing sequence/source/senders, disconnected, exhausted
+  with no viable same-campaign replenishment path, or the user explicitly asks
+  to move to another campaign.
+- **Ask what to create** only after resolver/state evidence shows there is no
+  suitable existing campaign for the requested sender set.
+
 When the best regular campaign is source-exhausted, recommend same-campaign source-ladder replenishment.
 Keep `selectedLeadListId` source identity distinct
 from the campaign `workflowTableId`.
@@ -109,6 +184,30 @@ Source replenishment choices:
   source prospects into the same campaign/source-list path, then confirm
   readiness.
 
+When reusing an existing source list on an already-large campaign, handle the
+campaign-table row cap automatically in `--yolo` mode. If `confirm_lead_list`
+fails with `USER_ADDED_ROWS_LIMIT_EXCEEDED`, parse `remainingRows`,
+`currentRows`, `requestedRows`, and `maxRows`; do not stop just because the full
+source list is too large. Instead, create a bounded same-source split:
+
+1. choose a split size no larger than `remainingRows`, the two-day refill row
+   budget, and the first-pass processing cap unless the packet named a higher
+   cap;
+2. read compact rows from the current `selectedLeadListId` with
+   `get_rows_minimal`;
+3. create a temporary bounded LinkedIn profile source list with
+   `load_csv_linkedin_leads`, preserving useful source columns such as post URL,
+   post author, engagement type/text, keyword, confidence, and why;
+4. call `confirm_lead_list` with that bounded source-list id, the same campaign
+   id, and `currentStep:"running"` for ACTIVE campaigns;
+5. verify the campaign table row count and review batch with
+   `get_campaign_table_schema` before any prep/approval.
+
+Do not use `add_on_demand_leads` or create an on-demand table as the automatic
+regular-campaign fallback. The fallback must stay same-campaign and
+source-list-backed.
+Short form: row-cap fallback means bounded same-source split, not stop or on-demand.
+
 ### Running Campaign Signal Discovery Recovery
 
 For an already-running regular campaign that needs same-campaign Signal
@@ -146,10 +245,10 @@ returns to Running after same-campaign source rows are copied. Do not call
 post-copy state transition.
 
 Before any source mutation, show exact approval evidence: workspace id,
-campaign id, workflow table id, source/provider id, source-list id when known,
-import caps, target dates/caps, dedupe/DNC/provider exclusion expectations, and
-expected row side effects. Then reread `get_campaign_refill_state`; if
-`freshness.stateHash` or exact ids changed, stop and ask for a fresh approval.
+campaign name, campaign id, workflow table id, source/provider id, source-list
+id when known, import caps, target dates/caps, dedupe/DNC/provider exclusion expectations, and expected row side effects. Present the campaign name and plain-English reason first; include ids only as proof and execution targets.
+Then reread `get_campaign_refill_state`; if `freshness.stateHash` or exact ids
+changed, stop and ask for a fresh approval.
 
 After source import, call `wait_for_lead_list_ready` and `confirm_lead_list`
 with the source-list id and campaign id. Imports append to the existing
@@ -179,18 +278,71 @@ Before prep or approval mutation, reread `get_campaign_refill_state` and compare
 If they changed, stop. A second concurrent refill run must see the first run's
 import/prep state on reread and avoid duplicate work.
 
+After the final reread and before the first mutating refill primitive, render
+one final approval packet in campaign-name-first language, then ask a
+host-native structured question with exactly two choices: `Accept` and
+`Decline`. The question is the execution boundary.
+Short form: exactly two choices: `Accept` and `Decline`.
+
+- In Codex interactive sessions, use `request_user_input`.
+- In Claude Code interactive sessions, use `AskUserQuestion`.
+- The `Accept` choice must name the exact campaign, workspace id, campaign id,
+  workflow table id, source/action ids when relevant, caps/dates, approval mode,
+  expected side effects, and stop/rollback condition.
+- The `Decline` choice must stop with no mutation.
+- Do not proceed from a plain chat "ok", "yes", "go", or "do it" when the
+  structured question tool is available. If the structured question tool is not
+  available in an interactive session, stop and tell the user the quick question
+  panel is required for refill approvals. In non-interactive exec/automation,
+  print the approval packet and stop before mutation.
+
+`--yolo` mode is explicit auto-accept. If Christian includes `--yolo` in the
+same refill request, do not ask the `Accept` / `Decline` question. Instead:
+
+1. render the same final approval packet;
+2. reread `get_campaign_refill_state`;
+3. verify the route, workspace id, campaign id, table id, source/action ids,
+   caps/dates, approval mode, blockers, and side-effect class still match the
+   packet;
+4. execute only the exact packet.
+
+`--yolo` never authorizes launch/start, sending, archive/delete cleanup, raw
+scheduler writes, sender reassignment, unrelated campaigns, expanded campaign
+sets, or higher caps than the packet named. If any state or scope drifts, stop
+and re-plan instead of auto-accepting the changed action.
+Short form: expanded campaign sets are not covered by `--yolo`.
+Short form: direct scheduler writes are not covered by `--yolo`.
+Short form: stop and re-plan instead of auto-accepting the changed action.
+
 After same-campaign source copy, inspect the actual campaign-table position of
 the copied rows before starting prep. Newly copied rows often land after the first 100 table rows. Use `get_campaign_table_schema` to read the `reviewBatch`,
 then use `select_campaign_cells` diagnostics against
 `rowSelector:{ type:"reviewBatch" }` for `enrich`, `generateMessage`, and
 `approved` roles when needed.
 
+For bounded split refills, operate on the review batch first. Queue
+`queue_campaign_cells` for `columnRole:"enrich"` on
+`rowSelector:{ type:"reviewBatch" }`, wait for campaign processing, then queue
+`columnRole:"generateMessage"` for the same review batch or
+`needsGeneratedMessage` rows. If the bounded packet explicitly uses
+`approvalMode:"approve"` because the user asked to fill/schedule sends or
+provided `--yolo` for a two-day send fill, approve only the bounded review-batch
+cohort after current generated messages exist. Do not broad approve existing
+table rows.
+
 If review-batch enrich cells are pending or Generate Message cells are
 dependency-blocked, omit `maxRowsToCheck` so the adaptive prep job can cover the
 bounded table scan, or set a bounded cap high enough to include appended rows
 when row count evidence requires it. Do not run a fixed `maxRowsToCheck:100` prep pass after appending rows to a larger existing campaign table; it can spend
 the whole budget on older rows and miss the refill batch.
 
+Bound `targetPreparedMessages` to the actual ready-to-schedule gap for the
+selected campaign and sender set. If `readyToSchedule` already covers the gap,
+do not start prep; report that the campaign is already loaded and awaiting the
+scheduler. If source inventory is available and the gap is small, prepare only
+the gap instead of filling every active campaign.
+Short form: prepare only the gap instead of filling every active campaign.
+
 Scheduled success requires a post-action reread proving scheduler-owned cells
 with non-null `scheduledFor`. Prepared, approved, and ready-to-schedule rows are
 intermediate states; report them as awaiting scheduler unless scheduled cells
@@ -225,9 +377,24 @@ the current source or ask for more research instead of walking the ladder.
 - No mutation in production unless Christian explicitly approves exact
   workspace, campaign/table ids, source/action ids, caps/dates, approval mode,
   expected side effects, and rollback/stop condition.
+- In interactive Codex or Claude Code, that explicit approval must be collected
+  through the host-native `Accept` / `Decline` question gate.
+- `--yolo` in the current refill request is explicit auto-accept for the
+  rendered bounded refill packet only; it does not loosen the launch/send,
+  scheduler-write, archive/delete, or drift rules above.
 
 ## Report
 
-Report the selected target, target type, source state, blockers, exact next
-primitive, approval required, and the freshness hash used. Say explicitly that
-nothing was launched and nothing was sent.
+Report in campaign-name-first language:
+
+- selected campaign name(s), target type, and sender names;
+- why they were selected, including last scheduled send date/future scheduled
+  send evidence and sender overlap;
+- whether the smallest next step is enrich/prep more in that campaign, add rows
+  to that campaign/source, use a different existing campaign, or ask what to
+  create;
+- source state, blockers, exact next primitive, approval required, and the
+  freshness hash used.
+
+Keep ids visible but secondary: show them under "Exact target" or "Proof", not
+as the main decision text. Say explicitly: nothing was launched and nothing was sent.