@sellable/mcp 0.1.404 → 0.1.406

package/skills/generate-messages/SKILL.md

@@ -252,6 +252,35 @@ 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
@@ -269,12 +298,15 @@ 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 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".
+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".
 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
@@ -433,9 +465,9 @@ artifact.**
 
    Safer shapes:
 
-   - `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`
+   - `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
    - `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
@@ -499,20 +531,22 @@ 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; `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}}...`.
+   {{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.
 
    Keep the apologetic nature, but aim it at uncertainty, not surveillance.
-   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.
+   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.
 
    Block wordier source narration such as `you might not remember the thread,
    but I found you through a {{signal_topic}} discussion and your
@@ -1509,7 +1543,10 @@ 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...`.
+  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.
 - **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
@@ -1810,8 +1847,11 @@ 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. 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. 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,
   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
@@ -1956,9 +1996,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.`
-- `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}}, 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}}, 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.
@@ -2219,9 +2259,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."`
-  - `"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."`
+  - `"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.
   - `"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]."`
@@ -2239,6 +2279,11 @@ 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
@@ -2247,7 +2292,9 @@ 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`. Use the self-aware raise-hand shapes only when
+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
 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,9 +5,6 @@ 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
@@ -38,7 +35,6 @@ 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
 ---
@@ -55,39 +51,10 @@ get_subskill_prompt({ subskillName: "refill-sends-workflow" })
 ```
 
 Then follow that workflow exactly. The default path is read-only research:
-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.
+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.
 
 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,9 +3,6 @@ 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
@@ -36,7 +33,6 @@ 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
 ---
@@ -56,27 +52,11 @@ 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. 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:
+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:
    - 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.
@@ -97,10 +77,7 @@ 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`; 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;
+  `scheduledFor`;
 - `freshness.stateHash` and exact campaign/table/workspace ids.
 
 Empty or unsafe states stop with the blocker: no fillable target, missing or deleted campaign,
@@ -112,61 +89,9 @@ 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`.
@@ -184,30 +109,6 @@ 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
@@ -245,10 +146,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 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.
+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.
 
 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
@@ -278,71 +179,18 @@ 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
@@ -377,24 +225,9 @@ 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 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.
+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.