@sellable/mcp 0.1.120 → 0.1.122

package/agents/source-scout-linkedin-engagement.md

@@ -27,14 +27,25 @@ Process:
 
 1. Read the campaign brief, kickoff doc, or lane prompt supplied by the parent.
 2. Search 3-5 keyword/topic lanes, favoring fresh posts from the last 7-14 days.
-3. Select 3-5 promising posts when available. If a `campaignOfferId` was
-   supplied, call `select_promising_posts({ campaignOfferId, selectionMode:
-"replace", selections, headlineICPCriteria, currentStep:
-"signal-discovery" })` before sampling so the watched Signal Discovery table
-   shows the promoted posts.
-4. Fetch or sample engagers for promoted posts and score rough ICP fit from visible headline/display-name cues only. Do not enrich people during viability estimation.
-5. Estimate usable prospects per selected post from sampled pass rate. If the sample is good but volume is low, say how many more similar posts should be added or scraped.
-6. Return false positives and dead ends explicitly.
+3. Inspect finalist posts by content type before final selection. Prefer posts
+   where the topic matches the campaign wedge, not generic high-engagement news.
+4. Promote the first narrow sample set when campaign-attached. If a
+   `campaignOfferId` was supplied, call `select_promising_posts({
+campaignOfferId, selectionMode: "replace", selections, headlineICPCriteria,
+currentStep: "signal-discovery" })` before sampling so the watched Signal
+   Discovery table shows the exact posts being tested.
+5. Fetch or sample engagers for promoted posts and score rough ICP fit from
+   visible headline/display-name cues only. Do not enrich people during
+   viability estimation.
+6. Compute capacity before recommending the source: target good-fit leads
+   (default 500 unless the parent supplies a target), reachable engagers,
+   sampled ICP-fit rate as `n/N` plus an easy percentage/range, expected usable
+   leads per right-content post after dedupe/cleanup, and posts needed to hit
+   the target.
+7. Select/promote enough right-content posts to plausibly hit the target. If the
+   warm Signals pool is useful but too small, return the expected warm range and
+   recommend Sales Nav/Prospeo for scale instead of padding with noisy posts.
+8. Return false positives and dead ends explicitly.
 
 Return a concise structured result with:
 
@@ -43,8 +54,11 @@ Return a concise structured result with:
 - `keyword_lanes` with timeframe, raw posts found, finalist posts reviewed
 - `selected_posts` with URL/title, author/topic, age, engager count, sampled engagers, good fits as n/N, estimated usable prospects per post, use/discard
 - `sample_leads`, if any
+- `approval_math` with eligible posts, target good-fit leads, sampled engagers,
+  ICP-fit rate as `n/N` plus percentage/range, posts needed for target, selected
+  post count, expected usable lead range, and scale fallback
 - `estimated_good_fit_range`
-- `expected_reply_rate_range`, directional if inferred
+- `message_context_strength`, directional and source-specific
 - `false_positive_patterns`
 - `recommendation`
 - `confidence`
@@ -53,5 +67,8 @@ Evidence standards:
 
 - Do not trust raw post volume without inspecting finalist post quality.
 - Prefer sample-based pass rates over intuition.
+- Do not make the user infer capacity. Say, plainly, how many eligible posts
+  exist, what percent of sampled engagers looked in-ICP, how many posts are
+  needed for 500+ good-fit leads, and which posts you would use.
 - If `fetch_post_engagers` is unavailable or fails, report that explicitly and mark the estimate lower-confidence.
 - Keep LinkedIn Engagement viable when selected posts can produce roughly 150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable.

package/dist/update-check.js

@@ -21,6 +21,7 @@ function readEntrypointDir() {
     }
 }
 function readCurrentVersion() {
+    // @ts-ignore - this MCP package is NodeNext ESM, but the app build typechecks MCP tests through its CommonJS tsconfig.
     const moduleDir = path.dirname(fileURLToPath(import.meta.url));
     const entrypointDir = readEntrypointDir();
     const candidates = [

package/package.json

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

package/skills/create-campaign-v2/SKILL.md

@@ -433,7 +433,10 @@ brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
   campaign brief. Do not wait for file-write chrome before asking for approval.
   Before Find Leads, call `update_campaign({ campaignId, campaignBrief,
   currentStep: "pick-provider", watchNarration: { ... } })` after approval so
-  the watch link moves out of Plan while the main thread compares source paths.
+  the watch link moves out of Plan while the main thread explains the source
+  path. This must be a visible Pick Provider checkpoint before the watched
+  browser moves into Signal Discovery, Sales Nav, Prospeo, or another provider
+  lane.
 
 - After the brief is approved, show the next progress line. When the user has
   not given a specific source direction, use the default sequential source
@@ -444,6 +447,11 @@ that gives the strongest message context if enough ICP-looking people are
 engaging. If that does not clear a quick viability check, I'll switch to Sales
 Nav with recent activity, then broader Sales Nav, and use Prospeo only as the
 fallback. No leads import until you approve the source.`
+  The watched campaign should still be on Pick Provider while this source logic
+  is being explained. If the default first lane is Signal Discovery, say clearly
+  that Codex is about to test Signal Discovery as a viability path, not import
+  leads: it will look for relevant posts, sample engagers, estimate ICP fit, and
+  only continue if the source math works.
 - If the user's request already points to a source, do not force the default
   funnel. Start with the matching lane and say why:
   - specific posts, creators, topics, comments, or engagement signals ->
@@ -453,8 +461,9 @@ fallback. No leads import until you approve the source.`
     search, or target accounts -> Prospeo
   - supplied CSV/profile list -> existing/supplied list preview
   - explicit compare request -> compare only the requested sources
-- In watch mode, do not leave the user sitting on only `pick-provider` while
-  source viability is checked. Move the campaign to the first source lane that
+- In watch mode, do not skip the Pick Provider checkpoint. First move the
+  campaign to `pick-provider` and narrate the source-selection reasoning there.
+  After that visible checkpoint, move the campaign to the first source lane that
   will actually be tested (`signal-discovery`, `sales-nav`, `prospeo`, or the
   user-directed lane), then run the campaign-attached provider prompt + provider
   search in the parent thread with `campaignOfferId`, `confirmed: true`, and
@@ -808,9 +817,11 @@ Required behavior:
   1. Start with LinkedIn Engagement / active LinkedIn posts (internal provider:
      Signals / `signal-discovery`) because recent engagement gives the strongest
      message context and expected reply-rate upside. Search relevant keyword
-     lanes, review finalist posts, promote the sampled posts with
+     lanes, review finalist posts, promote a narrow sample set with
      `select_promising_posts` before fetching engagers when a campaign shell
-     exists, fetch top-post engagers, and estimate warm-fit volume.
+     exists, fetch top-post engagers, estimate ICP-fit rate, compute posts
+     needed for the target good-fit lead count, and only then recommend the
+     selected post set or move to the next source.
   2. If Signals does not have enough recent, relevant, ICP-looking engagers,
      switch to Sales Nav with recent activity when the target can be expressed
      as title/persona/company filters. Run preview filters, inspect preview rows,
@@ -867,12 +878,12 @@ Required behavior:
   smaller, higher-reply-upside first batch versus Sales Nav/Prospeo for broader
   scale. Recommend the source you believe should win, often Sales Nav when scale
   matters, but keep the smaller Signals lane available as a real option.
-- user-facing source logic must use numbers, not vibes. Never write percentages
-  in the source review. Use the numerator, denominator, and sample basis instead,
-  e.g. `8 of 11 sampled engagers fit the ICP`. If the sample is small, say it is
-  directional. If an estimate depends on assumptions, show the math without
-  percentage notation: `5 selected posts x ~40-80 reachable engagers/post x
-roughly 1 in 4 to 2 in 5 expected fit = ~50-160 likely usable leads`.
+- user-facing source logic must use sample-backed numbers, not vibes. Show the
+  numerator, denominator, sample basis, and an easy percentage or range, e.g.
+  `18 of 40 sampled engagers fit the ICP (~45%, directional)`. If the sample is
+  small, say it is directional. If an estimate depends on assumptions, show the
+  math plainly: `8 eligible posts x ~140 reachable engagers/post x ~35-45% ICP
+fit x cleanup factor = ~300-500 likely usable warm leads`.
 - source progress updates should expose the confidence-building numbers as soon
   as they exist: keyword lanes searched, timeframe used, post results by lane,
   finalist posts reviewed, engagers fetched, sampled engagers, sampled fits,
@@ -882,10 +893,12 @@ roughly 1 in 4 to 2 in 5 expected fit = ~50-160 likely usable leads`.
   last 30 days, prefer the last 7-14 days when quality is comparable, and call
   out any older post as a deliberate tradeoff. Do not hide post age inside the
   raw search count
-- default source quality target is 300-500+ likely usable leads for scalable
-  outbound; accept ~150+ likely ICP-fit warm prospects as viable for a focused
-  Signals-first campaign or first review batch. Name the volume tradeoff in
-  `lead-review.md` and the message review context rather than forcing a discard.
+- default source quality target is 500+ likely good-fit leads for scalable
+  outbound unless the campaign or user supplies a different target. Accept
+  ~150+ likely ICP-fit warm prospects as viable for a focused Signals-first
+  campaign or first review batch only when the user is choosing warmth over
+  scale. Name the volume tradeoff in `lead-review.md` and the source approval
+  card rather than forcing a discard.
 - if `lead-source-intake.json` is present, read `sourceType`,
   `sourceInputMode`, file path or existing lead-list ID, selected columns,
   confirmation token, normalized counts, and any preview-created
@@ -919,7 +932,8 @@ roughly 1 in 4 to 2 in 5 expected fit = ~50-160 likely usable leads`.
 - row/domain counts, invalid counts, duplicate counts, and sample method for
   supplied sources
 - preview count
-- ICP match rate with numerator/denominator and sample basis; never percent-only
+- ICP match rate with numerator/denominator, sample basis, and a simple
+  percentage/range; never percent-only
 - volume comparison
 - source viability: expected source volume, expected usable leads after
   filtering, source activity/warmth indicators, cleanup risk, and confidence
@@ -977,7 +991,7 @@ table with one row per selected or finalist post:
 - raw results found
 - finalist posts or preview rows reviewed
 - sampled people
-- sampled fits, shown as `n/N` only; do not include a percentage
+- sampled fits, shown as `n/N` plus a simple percentage/range
 - estimated usable people
 - confidence note (`sample-backed`, `directional`, or `needs more sample`)
 
@@ -994,47 +1008,34 @@ workspace/sender.
 When showing `lead-review.md` to the user, render a slim decision summary in
 chat, not the full evidence table. Use rendered Markdown directly with short
 indexed sections and bullet lines; do not use fenced code blocks for the
-user-facing lead review. The visible response must include:
+user-facing lead review. The visible response must be a compact math-first card,
+not a research memo. It must include only:
 
 - `Lead source decision`
-- `Recommendation`
-- `Primary source and filters` with the concrete source recipe the agent would
-  use if approved. For Sales Nav, name the actual role/title, company-size,
-  geography, industry/account, and activity filters. For Signals, name the
-  selected post set. For Prospeo, name the account/domain and title recipe.
-- `Runner-up sources` with the second-best choice and why it lost. Make the
-  tradeoff explicit, e.g. Sales Nav = clearer scale and fit control, Signals =
-  warmer but smaller/noisier, Prospeo = broader account coverage but weaker
-  LinkedIn intent.
-- `Why it won`
-- `Quick numbers` as bullet points, with one provider/source angle per bullet.
-  Each bullet must include raw volume, sampled fit rate as `n/N`, estimated
-  good-fit range after cleanup, source activity/warmth basis, and confidence
-  note.
-- If Signals was searched or considered, `Signal keyword lanes` as a compact
-  table with keyword lane, timeframe, posts found, and finalist posts reviewed.
-- If Signals was searched or considered, `LinkedIn posts sampled` as a compact
-  table with one row per selected or finalist post: post URL/title,
-  author/topic, age, engagers, sampled engagers, good fits as `n/N`, estimated
-  usable prospects per post, and use/discard decision.
-- `Sample leads` with 3-5 representative `Name — Title, Company` rows
-- `Tradeoff`
-- `Watch link: {watchUrl}` when the campaign shell exists
-- `Source math before approval` as the final content block immediately above
-  the lead-source approval question. This is the bottom-line arithmetic that
-  makes the recommendation feel obvious. It must use concrete counts and a
-  simple formula, for example:
-  `Signals: 5 relevant posts -> ~320 reachable engagers; 18 of 40 sampled
-engagers fit the ICP, so the expected usable range is roughly 120-160 warm
-prospects after cleanup. If we want more volume than that, use Sales Nav:
-~1,900 preview rows with 14 of 25 sampled rows looking usable, but the message
-context is colder.`
-  For Signals, include selected/relevant posts, total or per-post engagers,
-  sampled engagers, sampled ICP fits as `n/N`, estimated usable prospects, and
-  the volume tradeoff. For Sales Nav/Prospeo alternatives, include preview/raw
-  volume, sampled usable rows as `n/N`, estimated usable range, and the warmth
-  or context tradeoff. Do not use percent-only fit rates or unsupported reply
-  rate claims.
+- `Source recommendation: {source}` with the concrete recipe. For Sales Nav,
+  name the actual role/title, company-size, geography, industry/account, and
+  activity filters. For Signals, name the selected post set. For Prospeo, name
+  the account/domain and title recipe.
+- `Math:` with these labels and values:
+  `Eligible posts`, `Sample`, `ICP-fit`, `Target`, `Posts needed`, `Selected`,
+  `Expected good-fit leads`, and `Scale option`.
+- `Why this source:` with at most two bullets.
+- `Watch link: {watchUrl}` only when the campaign shell exists and the host
+  needs a handoff link.
+- the concrete source approval question and options.
+
+Do not include keyword-lane tables, LinkedIn-post-sampled tables, sample-lead
+lists, or long tradeoff prose in the default approval packet. Keep those details
+in `lead-review.md` or campaign/source decision state. The math block is the
+bottom-line arithmetic that makes the recommendation obvious. For example:
+`Eligible posts: 8 outbound + Claude posts. Sample: 120 engagers. ICP-fit: 52/120
+(~43%, directional). Target: 500 good-fit leads. Posts needed: about 8-10 at
+this fit rate. Selected: 8 posts. Expected good-fit leads: ~420-560 after
+dedupe/cleanup. Scale option: Sales Nav gives more rows but loses the engaged
+with this content message hook.` For Sales Nav/Prospeo alternatives, include
+preview/raw volume, sampled usable rows as `n/N` plus percentage/range,
+estimated usable range, and the warmth or context tradeoff. Do not use
+percent-only fit rates or unsupported reply-rate claims.
 
 The first sentence of the visible decision must make the actual choice clear:
 `I recommend {primary source} using {exact filter/source recipe}. The runner-up
@@ -1068,7 +1069,8 @@ posts`, `Try Prospeo/account search`, and `Revise source`.
 Immediately above that approval question, render the `Source math before
 approval` block. Do not ask the user to approve from the recommendation alone;
 show the math tying relevant posts, available engagers, sampled fit, expected
-usable lead count, and the scale alternative together first.
+usable lead count, posts needed for the target, and the scale alternative
+together first.
 
 Do not skip or discard Signals based only on raw post count or vibes. If
 Signals was considered, show the post-level math in chat first so the user can
@@ -1077,13 +1079,16 @@ sampled engagers looked like good fits, and roughly how many usable prospects
 each post can produce. If no engagers could be fetched, say that explicitly and
 lower confidence instead of presenting a precise estimate.
 
-For Signals, default to sampling a few promising posts first rather than trying
-to prove the entire source can scale before the user sees evidence. Pick 3-5
-fresh, high-density posts when available. In campaign-attached watch runs,
-promote those posts with `select_promising_posts` before sampling so the user
-sees which posts are being tested. Then sample engagers, show fit rate, and
-state how many additional posts could be added/scraped if that first sample is
-good but volume is low.
+For Signals, default to a quick capacity test before final recommendation. Pick
+a narrow first sample of fresh, high-density posts, and in campaign-attached
+watch runs promote those posts with `select_promising_posts` before sampling so
+the user sees which posts are being tested. Then sample engagers, show ICP-fit
+rate as `n/N` plus percentage/range, calculate how many right-content posts are
+needed to reach the target good-fit lead count, and select/promote enough
+right-content posts if the lane can hit the target. If the first sample is good
+but volume is low, say how many more posts would be needed and offer the Sales
+Nav/Prospeo scale alternative instead of recommending an under-sized source as
+if it can produce 500+ leads.
 
 Keep discarded paths and full sample rows in the campaign/source decision
 context. In explicit debug/UAT runs they may also be copied into

package/skills/create-campaign-v2/core/flow.v2.json

@@ -525,7 +525,7 @@
           "suppliedProfilesOrCsv": "supplied-list",
           "explicitCompare": "compare-requested-sources"
         },
-        "quickViabilityRule": "Run only enough of the current lane to decide whether it can supply relevant, reachable ICP-looking leads. Stop on the first viable source unless the user asked for comparison.",
+        "quickViabilityRule": "Run only enough of the current lane to decide whether it can supply relevant, reachable ICP-looking leads. For Signals, viability requires sampled ICP-fit rate plus posts-needed math against the target good-fit lead count, not raw post count. Stop on the first viable source unless the user asked for comparison.",
         "parallelAllowedOnlyWhen": [
           "user explicitly requested source comparison",
           "resuming already-started parallel scouts",
@@ -546,7 +546,9 @@
             "watchNarration.stage": "find-leads"
           },
           "when": "before_sequential_source_funnel",
-          "chatRenderRule": "Move the campaign watch view to Find Leads before the main thread starts source viability work. If the user did not specify a source, explain the default order: start with warm LinkedIn post engagement because it gives stronger message context and expected reply-rate upside when enough ICP-looking engagers exist; if it is not viable, switch to Sales Nav with recent activity, then broader Sales Nav, and use Prospeo only as the fallback. If the user did specify hiring signals, domains/accounts, supplied lists, posts/comments, or titles/personas, explain that the matching source overrides the default funnel. State that no leads import until a source is approved. The watchNarration headline/body must name the lane being tested, why this lane now, the quick viability gate, and the safety boundary. Do not mention MCP or local artifacts."
+          "requiresVisibleCheckpointBeforeProviderLane": true,
+          "forbidDirectPlanToProviderLane": true,
+          "chatRenderRule": "Move the campaign watch view to the Pick Provider step before the main thread starts source viability work. This must be a distinct visible checkpoint: do not jump directly from Plan to Signal Discovery, Sales Nav, Prospeo, or another provider lane in the same visible beat. While the watched browser is on Pick Provider, explain the source-selection logic. If the user did not specify a source, explain the default order: start with warm LinkedIn post engagement because it gives stronger message context and expected reply-rate upside when enough ICP-looking engagers exist; if it is not viable, switch to Sales Nav with recent activity, then broader Sales Nav, and use Prospeo only as the fallback. If starting with Signal Discovery, explicitly say this is a viability test: Codex will look for relevant posts, sample engagers, estimate ICP fit, and only continue if the source math works. If the user did specify hiring signals, domains/accounts, supplied lists, posts/comments, or titles/personas, explain that the matching source overrides the default funnel. State that no leads import until a source is approved. The watchNarration headline/body must name the first lane being considered, why this lane now, the quick viability gate, and the safety boundary. Do not mention MCP or local artifacts."
         },
         {
           "action": "advance_watch_to_initial_source_lane",
@@ -564,8 +566,9 @@
             "existingList": "saved-lists",
             "uploadedDomains": "prospeo"
           },
-          "when": "before_first_source_attempt",
-          "rule": "Choose the first visible source lane from explicit source direction when present, otherwise default to Signal Discovery. Send watchNarration with stage find-leads that says why this lane is being tried now, what quick sample or filter gate will pass/fail it, and why that helps this campaign. For Signal Discovery sampling, promote/select the posts with select_promising_posts before fetch_post_engagers so the watched table shows the exact posts being sampled; the guide copy should say Codex is pulling sample engagers from these posts to confirm the ICP is actually engaging and the source is viable. If the lane fails, update currentStep and watchNarration before moving to Sales Nav recent activity, normal Sales Nav, or Prospeo."
+          "when": "after_source_selection_checkpoint_before_first_source_attempt",
+          "requiresPriorVisibleStep": "pick-provider",
+          "rule": "Choose the first visible source lane from explicit source direction when present, otherwise default to Signal Discovery. Only run this after the Pick Provider source-selection checkpoint has been made visible and explained in chat/watchNarration. Send watchNarration with stage find-leads that says why this lane is being tried now, what quick sample or filter gate will pass/fail it, and why that helps this campaign. For Signal Discovery sampling, make it clear this is a viability path before lead import: promote/select the first narrow sample posts with select_promising_posts before fetch_post_engagers so the watched table shows the exact posts being sampled; the guide copy should say Codex is pulling sample engagers from these posts to confirm the ICP is actually engaging and estimate whether enough right-content posts exist for the target lead count. Before final source approval, compute eligible posts, sampled ICP-fit rate, target good-fit lead count, posts needed, selected posts, expected good-fit range, and scale fallback. If the lane fails, update currentStep and watchNarration before moving to Sales Nav recent activity, normal Sales Nav, or Prospeo."
         },
         {
           "action": "run_first_campaign_attached_source_search",
@@ -614,7 +617,7 @@
           "action": "run_subskill",
           "target": "find-leads",
           "mode": "campaign-attached-required",
-          "sourceScoutRule": "Shell-first flow requires the CampaignOffer campaignId from durable state. Pass campaignId as campaignOfferId into every provider prompt/search that can persist source state (`get_provider_prompt({ provider, campaignOfferId, confirmed: true })`, `search_signals`, `search_sales_nav`, `search_prospeo`) and include currentStep for tools that accept it so the user can watch the selected source inside the campaign. Use the default sequential source viability funnel when the user did not specify a source: Signal Discovery first, then Sales Nav with recent activity, then general Sales Nav, then Prospeo only as fallback. Stop on the first viable source unless the user explicitly asked to compare. If the user names hiring signals, domains/accounts, supplied lists, posts/comments, or title/persona filters, start with the matching source instead. Parallel source scouts only when the user requested comparison, an existing parallel run is being resumed, or the first viable source is borderline and one cheap fallback check is needed. The later import_leads call must use the same campaignOfferId. Do not import, confirm, enrich, queue, or start leads during source discovery."
+          "sourceScoutRule": "Shell-first flow requires the CampaignOffer campaignId from durable state. Pass campaignId as campaignOfferId into every provider prompt/search that can persist source state (`get_provider_prompt({ provider, campaignOfferId, confirmed: true })`, `search_signals`, `search_sales_nav`, `search_prospeo`) and include currentStep for tools that accept it so the user can watch the selected source inside the campaign. Use the default sequential source viability funnel when the user did not specify a source: Signal Discovery first, then Sales Nav with recent activity, then general Sales Nav, then Prospeo only as fallback. For Signal Discovery, do not recommend from raw post count; sample engagers, calculate ICP-fit rate, target good-fit lead count, posts needed, selected posts, expected good-fit range, and scale fallback. Stop on the first viable source unless the user explicitly asked to compare. If the user names hiring signals, domains/accounts, supplied lists, posts/comments, or title/persona filters, start with the matching source instead. Parallel source scouts only when the user requested comparison, an existing parallel run is being resumed, or the first viable source is borderline and one cheap fallback check is needed. The later import_leads call must use the same campaignOfferId. Do not import, confirm, enrich, queue, or start leads during source discovery."
         },
         {
           "action": "optional_debug_artifacts",
@@ -712,16 +715,17 @@
           "artifact": "lead-review.md",
           "renderInlineSections": [
             "## Lead source decision",
-            "Recommendation",
-            "Primary source and filters",
-            "Runner-up sources",
-            "Why it won",
-            "Quick numbers",
-            "Signal keyword lanes",
-            "LinkedIn posts sampled",
-            "Sample leads",
-            "Tradeoff",
-            "Source math before approval"
+            "Source recommendation",
+            "Math",
+            "Eligible posts",
+            "Sample",
+            "ICP-fit",
+            "Target",
+            "Posts needed",
+            "Selected",
+            "Expected good-fit leads",
+            "Scale option",
+            "Why this source"
           ],
           "signalsFirstRequiredFields": [
             "post URL",
@@ -742,7 +746,7 @@
             "raw results found",
             "finalist posts or preview rows reviewed",
             "sampled people",
-            "sampled fits as n/N only; no percentage",
+            "sampled fits as n/N plus percentage or range",
             "estimated usable people",
             "estimated good-fit range after cleanup",
             "confidence note"
@@ -756,13 +760,17 @@
           ],
           "approvalMathRequiredFields": [
             "selected or relevant posts count",
+            "eligible right-content posts count",
             "reachable engagers count",
             "sampled engagers count",
-            "sampled ICP fits as n/N only; no percentage",
+            "sampled ICP fits as n/N plus percentage or range",
+            "target good-fit lead count",
+            "posts needed for target",
+            "selected posts count",
             "estimated usable prospects range",
             "scale alternative source",
             "scale alternative raw or preview volume",
-            "scale alternative sampled usable rows as n/N only; no percentage",
+            "scale alternative sampled usable rows as n/N plus percentage or range",
             "warmth or message-context tradeoff",
             "what to choose if the user wants more volume"
           ],
@@ -786,7 +794,7 @@
           "doNotCompressToSummaryOnly": false,
           "doNotRenderArtifactLinksOnly": true,
           "sourceRecommendationReadyWatchRule": "When the source recommendation decision card is ready in chat with counts and sample quality, and before asking for source approval, call update_campaign with leadSourceType `new`, leadSourceProvider set to the recommended primary provider, currentStep set to that provider lane (`sales-nav`, `signal-discovery`, or `prospeo`), and find-leads watchNarration. If the recommendation changed from the lane last sampled, switch the watched provider page to the recommended lane first so the user can inspect what they are approving. Use a headline like `Review the source in Codex`, body copy that says the browser is showing the evaluated source/results, and nextAction like `Approve in Codex`. Do not keep future-tense copy like `I'll show a source recommendation` after the decision is visible. Include a safety note that no leads import until the user approves the source.",
-          "chatRenderRule": "Show a slim rendered-Markdown decision summary only, never a fenced code block. The first sentence must make the decision explicit: 'I recommend {primary source} using {exact filter/source recipe}. The runner-up is {source} because {reason}.' Use indexed sections and short bullets: recommendation, Primary source and filters, Runner-up sources, why it won, Quick numbers with one provider/source angle per bullet, raw volume, sampled fit count as n/N only (no percentages), estimated good-fit range after cleanup, activity/warmth basis, confidence note, 3-5 representative sample leads, one tradeoff, and a final Source math before approval block immediately above the source approval question. Do not forecast connection acceptance rates, reply rates, meetings, pipeline, revenue, or ROI unless the user supplied verified benchmark data for this exact workspace/sender. If Signals was searched or considered, include two compact inline Markdown tables before the recommendation is treated as final: Signal keyword lanes with keyword lane, timeframe, posts found, and finalist posts reviewed; and LinkedIn posts sampled with post URL/title, author/topic, age, engagers, sampled engagers, good fits as n/N only, estimated usable prospects per post, and use/discard decision. Default to selecting a few promising Signals posts for the first sample instead of trying to prove full Signals scale up front; if the sample is good but volume is low, say how many more posts to add/scrape next. The Source math before approval block must tie the approval choice to concrete arithmetic: relevant/selected posts, available engagers, sampled engagers, sampled ICP fits as n/N only, estimated usable prospects, and the scale alternative math. If the user wants more volume than the warm post-engagement estimate, explicitly say which Sales Nav or Prospeo alternative provides that volume and what message-context warmth is lost. Do not skip or discard Signals based only on raw post count or vibes; show the post-level math first, or explicitly say no engagers could be fetched and lower confidence. Keep discarded paths, full sample rows, and lead-sample.json details in lead-review.md. Do not show plain filesystem paths unless links cannot be created."
+          "chatRenderRule": "Show a compact rendered-Markdown decision card only, never a fenced code block. The first sentence must make the decision explicit: 'I recommend {primary source} using {exact filter/source recipe}. The runner-up is {source} because {reason}.' Use only these sections: Lead source decision, Source recommendation, Math, Why this source, and the concrete approval question. The Math section must include labeled lines for Eligible posts, Sample, ICP-fit, Target, Posts needed, Selected, Expected good-fit leads, and Scale option. Show fit as n/N plus an easy percentage or range, never percent-only. Do not include keyword-lane tables, LinkedIn-post-sampled tables, sample-lead lists, or long tradeoff prose in the default approval packet; keep those details in lead-review.md or campaign/source decision state. Do not forecast connection acceptance rates, reply rates, meetings, pipeline, revenue, or ROI unless the user supplied verified benchmark data for this exact workspace/sender. For Signals, do not recommend from raw post count. Compute eligible right-content posts, reachable engagers, sampled ICP-fit rate, target good-fit lead count, posts needed, selected posts, expected good-fit range, and scale fallback. If the user wants more volume than the warm post-engagement estimate, explicitly say which Sales Nav or Prospeo alternative provides that volume and what message-context warmth is lost. If no engagers could be fetched, say that explicitly and lower confidence. Do not show plain filesystem paths unless links cannot be created."
         },
         {
           "action": "render_post_lead_parallel_progress",
@@ -808,7 +816,7 @@
         {
           "action": "ask_continue_revise_or_confirm_only_if_needed",
           "approvalQuestionRule": "If asking the user, the question and options must name the concrete decision. Prefer: 'Approve Sales Nav with {filters}, or use warmer Signals instead?' over 'Approve this lead source?' Option labels must name the source choice, such as 'Approve Sales Nav filters', 'Use warmer Signals posts', 'Try Prospeo/account search', and 'Revise source'.",
-          "approvalMathRule": "Immediately above the approval question, render the Source math before approval block: given this many relevant posts, this many reachable engagers, and this sampled ICP fit as n/N, we expect this usable lead range; if the user wants more volume, name the Sales Nav or Prospeo alternative, its preview/sample math, and the colder/weaker-context tradeoff. Do not ask the approval question until this math is visible.",
+          "approvalMathRule": "Immediately above the approval question, render the compact Math block: given this many eligible relevant posts, this many reachable engagers, this sampled ICP fit as n/N plus percentage/range, this target good-fit lead count, and this many posts needed, we expect this usable lead range from the selected posts; if the user wants more volume, name the Sales Nav or Prospeo alternative, its preview/sample math, and the colder/weaker-context tradeoff. Do not ask the approval question until this math is visible.",
           "autoContinueWhen": {
             "status": "confirmed",
             "confidenceIn": [

package/skills/create-campaign-v2/references/watch-guide-narration.md

@@ -79,14 +79,27 @@ Default source funnel:
 ```json
 {
   "stage": "find-leads",
-  "headline": "Testing warm LinkedIn activity",
-  "visibleState": "Codex is starting with recent post engagement because it gives the strongest message context if enough ICP-looking people are active there.",
-  "agentIntent": "If this lane does not clear the quick sample gate, it will switch to Sales Nav with recent activity, then broader Sales Nav, and use Prospeo only as the fallback.",
+  "headline": "Choosing the lead source",
+  "visibleState": "The browser is on Pick Provider while Codex explains the source path before opening a provider lane.",
+  "agentIntent": "Codex will start with Signal Discovery when warm LinkedIn engagement looks plausible, then switch to Sales Nav or Prospeo only if the quick viability math fails.",
   "nextAction": "Review source",
   "safety": "No leads import until you approve the source."
 }
 ```
 
+Signal Discovery viability handoff:
+
+```json
+{
+  "stage": "find-leads",
+  "headline": "Checking Signal Discovery viability",
+  "visibleState": "The browser is moving from Pick Provider into Signal Discovery so the exact posts and sample math are visible.",
+  "agentIntent": "Codex is testing whether relevant posts have enough ICP-looking engagers before recommending this as the source.",
+  "nextAction": "Review source math",
+  "safety": "No leads import until you approve the source."
+}
+```
+
 Source direction override:
 
 ```json

package/skills/providers/signal-discovery.md

@@ -332,6 +332,22 @@ before `fetch_post_engagers` so the user sees the exact posts being sampled in
 the watched Signal Discovery table. Use `selectionMode: "replace"` for the first
 sample set unless the user explicitly wants to add to existing promoted posts.
 
+For `create-campaign-v2` source approval, do not treat the default
+`selectionTarget` of 3 posts as enough by itself. Before the final source
+recommendation, estimate source capacity from real sample math:
+
+- target good-fit leads (default 500 unless the campaign says otherwise)
+- eligible right-content posts by lane/content type
+- reachable engagers from those posts
+- sampled ICP-fit rate as `n/N` plus an easy percentage/range
+- expected good-fit leads per selected post after dedupe/cleanup
+- posts needed to reach the target
+
+Then select enough right-content posts to plausibly hit the target. If the math
+says the warm post lane only supports a smaller first batch, say that and name
+the Sales Nav or Prospeo scale fallback rather than padding the selection with
+noisy posts.
+
 ```json
 select_promising_posts({
   "campaignOfferId": "cmp_xxx",