@sellable/mcp 0.1.146 → 0.1.148

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

@@ -57,7 +57,8 @@ currentStep: "signal-discovery" })` before sampling so the watched Signal
    leads per 100 engagers before and after a conservative dedupe/cleanup
    factor, required engagers to scrape (`source target / fit rate`), average
    reachable engagers per right-content post, expected usable leads per
-   right-content post after dedupe/cleanup, and posts needed to hit the target.
+   right-content post after dedupe/cleanup, posts needed to hit the target, and
+   whether sampled/projected fit clears the 10% planning floor.
 8. 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.
@@ -74,8 +75,9 @@ Return a concise structured result with:
   engagers, ICP-fit rate as `n/N` plus percentage/range, good-fit prospects per
   100 engagers, required engagers to scrape, average reachable engagers per
   post, expected usable prospects per post after cleanup, posts needed for
-  target, selected post count, review-batch import limit, expected usable lead
-  range, and scale fallback
+  target, whether the 10% planning floor clears after cleanup, selected post
+  count, review-batch import limit, expected usable lead range, and scale
+  fallback
 - `estimated_good_fit_range`
 - `message_context_strength`, directional and source-specific
 - `false_positive_patterns`
@@ -99,3 +101,5 @@ Evidence standards:
   bounded review batch.
 - 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.
+- If sampled/projected fit after cleanup is below 10%, reject the Signals scrape
+  path and recommend Sales Nav recent activity as the next source.

package/agents/source-scout-prospeo-contact.md

@@ -27,7 +27,7 @@ Process:
 1. Read the campaign brief, source intake, kickoff doc, or lane prompt supplied by the parent.
 2. Identify whether this is domain/account targeting or broad persona expansion.
 3. For domain targeting, use or create the standalone `domainFilterId` before searching; never pass raw domains directly into `search_prospeo`.
-4. Run the narrowest useful Prospeo people preview and 1-2 refinements if quality or scale is unclear. Check scale against a default 300+ good-fit target, capped at 2,500 source candidates unless the parent supplies a different target.
+4. Run the narrowest useful Prospeo people preview and 1-2 refinements if quality or scale is unclear. Check scale against a default 300+ good-fit target, capped at 2,500 source candidates unless the parent supplies a different target, and require at least 10% projected good-fit after cleanup.
 5. Call out that Prospeo gives contact/account coverage but usually weaker LinkedIn intent than LinkedIn Engagement or Sales Nav activity slices.
 
 Return a concise structured result with:
@@ -50,4 +50,7 @@ Evidence standards:
 
 - Never pass raw domains, company website arrays, or company-name arrays into `search_prospeo`.
 - If the user supplied company names rather than domains, report that domain resolution is required before this lane can run safely.
+- Prospeo is the terminal fallback. If projected good-fit after cleanup remains
+  below 10% after reasonable refinement, recommend tightening the ICP/source
+  direction rather than switching providers again.
 - Treat Prospeo as an account/contact coverage lane, not as proof of fresh LinkedIn intent.

package/agents/source-scout-sales-nav.md

@@ -35,6 +35,9 @@ Process:
    Loosen nonessential filters in order: remove recent-activity first, widen
    adjacent title variants, widen geography/company-size constraints, and only
    keep hard ICP requirements from the brief.
+   Also check the 10% planning floor after cleanup. If the best reasonable
+   Sales Nav lane remains below 10% projected good-fit, move to Prospeo instead
+   of recommending Sales Nav.
 6. Run the baseline plus 1-2 refinements or loosening passes if the first pass
    is noisy or under-scaled. Label the final pool as constrained if it still
    cannot plausibly reach the target after loosening.
@@ -69,5 +72,7 @@ Evidence standards:
   larger than the warm-post path. If Sales Nav is offered for scale, it should
   either project to the target good-fit count or clearly say it is too tight and
   name the next broadening/Prospeo option.
+- If projected good-fit after cleanup is below 10%, do not recommend Sales Nav
+  as the winning source; recommend Prospeo as the next provider.
 - Do not hand-wave missing filter IDs.
 - If Sales Nav returns a giant unfiltered pool, discard that result and retry with valid filters before recommending it.

package/dist/tools/leads.js

@@ -31,6 +31,9 @@ const defaultCampaignSourceDefaults = {
         defaultSize: 25,
         minProjectedPass: 5,
     },
+    planning: {
+        minFitRate: 0.1,
+    },
     providers: {
         "signal-discovery": {
             targetGoodFitLeads: 150,
@@ -280,6 +283,10 @@ function loadCampaignSourceDefaults() {
                 ...defaultCampaignSourceDefaults.reviewBatch,
                 ...(parsed.reviewBatch ?? {}),
             },
+            planning: {
+                ...defaultCampaignSourceDefaults.planning,
+                ...(parsed.planning ?? {}),
+            },
             providers: {
                 ...defaultCampaignSourceDefaults.providers,
                 ...(parsed.providers ?? {}),
@@ -297,6 +304,7 @@ function getSignalDiscoverySourcePlanDefaults() {
     return {
         targetGoodFitLeads: signalDefaults.targetGoodFitLeads,
         defaultFitRate: signalDefaults.defaultFitRate,
+        minPlanningFitRate: defaults.planning.minFitRate,
         sourceCandidateTarget,
         reviewBatchSize: defaults.reviewBatch.defaultSize,
     };
@@ -602,7 +610,7 @@ function formatApproxInteger(value) {
     return `~${rounded.toLocaleString("en-US")}`;
 }
 function buildSignalDiscoverySourceRecommendation({ selectedPosts, }) {
-    const { targetGoodFitLeads, defaultFitRate, sourceCandidateTarget, reviewBatchSize, } = getSignalDiscoverySourcePlanDefaults();
+    const { targetGoodFitLeads, defaultFitRate, minPlanningFitRate, sourceCandidateTarget, reviewBatchSize, } = getSignalDiscoverySourcePlanDefaults();
     const selectedCount = selectedPosts.length;
     const totalEngagement = selectedPosts.reduce((sum, post) => sum + (post.likes ?? 0) + (post.comments ?? 0), 0);
     const tableRows = selectedPosts
@@ -618,6 +626,7 @@ Use Signal Discovery first.
 
 **Good-fit target:** ~${targetGoodFitLeads.toLocaleString("en-US")} prospects after cleanup, enrichment, and filters<br>
 **Source-candidate plan:** scrape ~${sourceCandidateTarget.toLocaleString("en-US")} raw engagers using a conservative ${Math.round(defaultFitRate * 100)}% fit-rate assumption<br>
+**Planning floor:** continue with Signal Discovery only when sampled/projected fit is at least ${Math.round(minPlanningFitRate * 100)}% after cleanup; below that, switch to Sales Nav recent activity<br>
 **Review checkpoint:** import the first ${reviewBatchSize.toLocaleString("en-US")} leads into the campaign for fit and message review before scaling
 
 ### Selected posts
@@ -637,7 +646,7 @@ This gives enough volume to work toward ~${targetGoodFitLeads.toLocaleString("en
 
 **First pass:** build the source list, then import only the ${reviewBatchSize.toLocaleString("en-US")}-lead review batch so we can inspect fit and messages before scaling.
 
-**Fallback:** if the review batch is too vendor-heavy, agency-heavy, or off-ICP, switch to Sales Nav recent activity.
+**Fallback:** if the sampled/projected fit rate is below ${Math.round(minPlanningFitRate * 100)}%, or if the review batch is too vendor-heavy, agency-heavy, or off-ICP, switch to Sales Nav recent activity.
 
 Approval card should say:
 
@@ -1223,7 +1232,7 @@ export const leadToolDefinitions = [
                 },
                 targetEngagerCount: {
                     type: "number",
-                    description: "Signal Discovery: target number of post engagers/source candidates to scrape. Compute from source target good-fit leads / sampled fit rate; e.g. 150 good fits at 15% fit requires about 1000 engagers. Limits selected posts before starting scrape.",
+                    description: "Signal Discovery: target number of post engagers/source candidates to scrape. Compute from source target good-fit leads / sampled fit rate; e.g. 150 good fits at 15% fit requires about 1000 engagers. If the sampled/projected fit rate is below the 10% planning floor after cleanup, switch to the next provider instead of scaling noisy engagers. Limits selected posts before starting scrape.",
                 },
                 maxPostsToScrape: {
                     type: "number",

package/dist/tools/registry.d.ts

@@ -3702,6 +3702,7 @@ export declare const allTools: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -3735,6 +3736,7 @@ export declare const allTools: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -3793,6 +3795,7 @@ export declare const allTools: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -3851,6 +3854,7 @@ export declare const allTools: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -3911,6 +3915,7 @@ export declare const allTools: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -3941,6 +3946,7 @@ export declare const allTools: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -3971,6 +3977,7 @@ export declare const allTools: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;

package/dist/tools/rubrics.d.ts

@@ -33,6 +33,7 @@ type WaitForRubricResultsInput = {
     tableId?: string;
     targetCount?: number;
     minPassedCount?: number;
+    minMessagesCount?: number;
     timeoutMs?: number;
     intervalMs?: number;
     includeRows?: boolean;
@@ -114,6 +115,7 @@ export declare const rubricToolDefinitions: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -147,6 +149,7 @@ export declare const rubricToolDefinitions: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -205,6 +208,7 @@ export declare const rubricToolDefinitions: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -263,6 +267,7 @@ export declare const rubricToolDefinitions: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -323,6 +328,7 @@ export declare const rubricToolDefinitions: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -353,6 +359,7 @@ export declare const rubricToolDefinitions: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -383,6 +390,7 @@ export declare const rubricToolDefinitions: ({
             tableId?: undefined;
             targetCount?: undefined;
             minPassedCount?: undefined;
+            minMessagesCount?: undefined;
             timeoutMs?: undefined;
             intervalMs?: undefined;
             includeRows?: undefined;
@@ -412,6 +420,10 @@ export declare const rubricToolDefinitions: ({
                 type: string;
                 description: string;
             };
+            minMessagesCount: {
+                type: string;
+                description: string;
+            };
             timeoutMs: {
                 type: string;
                 description: string;
@@ -508,6 +520,12 @@ export declare function checkRubric(input: CheckRubricInput): Promise<{
 export declare function waitForRubricResults(input: WaitForRubricResultsInput): Promise<{
     stats: WorkflowTableStats;
     rows?: import("./rows.js").LightweightRow[] | undefined;
+    messageGeneration?: {
+        completed: number;
+        passingGeneratedMessages: number;
+        minMessagesCount: number;
+        floorMet: boolean;
+    } | undefined;
     ready: boolean;
     attempts: number;
     elapsedMs: number;
@@ -520,28 +538,14 @@ export declare function waitForRubricResults(input: WaitForRubricResultsInput):
         targetCount: number;
         pending?: undefined;
     };
-    reason?: undefined;
-    partialResult?: undefined;
-    diagnostic?: undefined;
-    guidance?: undefined;
 } | {
     stats: WorkflowTableStats;
     rows?: import("./rows.js").LightweightRow[] | undefined;
-    ready: boolean;
-    partial: boolean;
-    reason: string;
-    attempts: number;
-    elapsedMs: number;
-    tableId: string;
-    passRate: {
-        completed: number;
-        passed: number;
-        pending: number;
-        percent: number;
-        targetCount: number;
-        minPassedCount: number;
-    };
     partialResult: {
+        messagesCount?: number | undefined;
+        passingGeneratedMessages?: number | undefined;
+        minMessagesCount?: number | undefined;
+        messageFloorMet?: boolean | undefined;
         completed: number;
         passed: number;
         pending: number;
@@ -551,23 +555,32 @@ export declare function waitForRubricResults(input: WaitForRubricResultsInput):
         enoughToDiagnose: boolean;
         floorMet: boolean;
     };
-    diagnostic?: undefined;
-    guidance?: undefined;
-} | {
+    messageGeneration?: {
+        completed: number;
+        passingGeneratedMessages: number;
+        minMessagesCount: number;
+        floorMet: boolean;
+    } | undefined;
     ready: boolean;
+    partial: boolean;
     reason: string;
     attempts: number;
     elapsedMs: number;
     tableId: string;
     passRate: {
-        minPassedCount?: number | undefined;
         completed: number;
         passed: number;
         pending: number;
         percent: number;
         targetCount: number;
+        minPassedCount: number;
     };
+} | {
     partialResult: {
+        messagesCount?: number | undefined;
+        passingGeneratedMessages?: number | undefined;
+        minMessagesCount?: number | undefined;
+        messageFloorMet?: boolean | undefined;
         enoughToDiagnose: boolean;
         floorMet: boolean;
         minPassedCount?: number | undefined;
@@ -581,12 +594,31 @@ export declare function waitForRubricResults(input: WaitForRubricResultsInput):
         totalRows: number;
         enrichedCount: number | undefined;
         needsEnrichCount: number | undefined;
-        messagesCount: number | undefined;
+        messagesCount: number;
         needsApprovalCount: number | undefined;
         processingCount: number | undefined;
         failedCount: number | undefined;
     };
     guidance: string;
     stats: WorkflowTableStats | null;
+    messageGeneration?: {
+        completed: number;
+        passingGeneratedMessages: number;
+        minMessagesCount: number;
+        floorMet: boolean;
+    } | undefined;
+    ready: boolean;
+    reason: string;
+    attempts: number;
+    elapsedMs: number;
+    tableId: string;
+    passRate: {
+        minPassedCount?: number | undefined;
+        completed: number;
+        passed: number;
+        pending: number;
+        percent: number;
+        targetCount: number;
+    };
 }>;
 export {};

package/dist/tools/rubrics.js

@@ -9,6 +9,11 @@ const DEFAULT_INTERVAL_MS = 2000;
 function sleep(ms) {
     return new Promise((resolve) => setTimeout(resolve, ms));
 }
+function countPassingGeneratedMessages(rowSnapshot) {
+    if (!rowSnapshot?.rows?.length)
+        return 0;
+    return rowSnapshot.rows.filter((row) => row.icpPassed === true && Boolean(row.message?.trim())).length;
+}
 function normalizeRubricItemDefaults(item) {
     return {
         ...item,
@@ -393,6 +398,10 @@ export const rubricToolDefinitions = [
                     type: "number",
                     description: "Optional pass floor for bounded create-campaign samples. When this floor is met, the tool returns ready:true with partial:true instead of waiting for every target row to finish.",
                 },
+                minMessagesCount: {
+                    type: "number",
+                    description: "Optional generated-message floor. When provided with minPassedCount, the tool waits until both floors are met so create-campaign-v2 can review the first passing generated message without waiting for the full batch.",
+                },
                 timeoutMs: {
                     type: "number",
                     description: `Max time to wait in ms (default ${DEFAULT_TIMEOUT_MS}).`,
@@ -688,6 +697,7 @@ export async function waitForRubricResults(input) {
     const intervalMs = Math.max(500, input.intervalMs ?? DEFAULT_INTERVAL_MS);
     const targetCount = resolveMaxProspects(input.targetCount);
     const minPassedCount = resolveMinPassedCount(input.minPassedCount);
+    const minMessagesCount = resolveMinPassedCount(input.minMessagesCount);
     const includeRows = input.includeRows !== false;
     let tableId = input.tableId;
     if (!tableId && input.campaignOfferId) {
@@ -709,19 +719,33 @@ export async function waitForRubricResults(input) {
         const totalRows = stats.totalRows ?? 0;
         const effectiveTarget = totalRows > 0 ? Math.min(targetCount, totalRows) : targetCount;
         const pending = Math.max(effectiveTarget - completed, 0);
+        const messagesCount = stats.messagesCount ?? 0;
         const failedCount = stats.failedCount ?? 0;
         const processingCount = stats.processingCount ?? 0;
         const queuedCount = stats.queuedCount ?? 0;
         const cancellableCount = stats.cancellableCount ?? 0;
         const minPassFloorMet = minPassedCount !== null && passed >= minPassedCount;
+        const rawMessageFloorMet = minMessagesCount === null || messagesCount >= minMessagesCount;
+        let rowSnapshotForMessageCheck = null;
+        let passingGeneratedMessagesCount = null;
+        if (minMessagesCount !== null && minPassFloorMet && rawMessageFloorMet) {
+            rowSnapshotForMessageCheck = await getTableRowsMinimal(tableId, {
+                limit: effectiveTarget,
+            });
+            passingGeneratedMessagesCount = countPassingGeneratedMessages(rowSnapshotForMessageCheck);
+        }
+        const messageFloorMet = minMessagesCount === null ||
+            (passingGeneratedMessagesCount ?? 0) >= minMessagesCount;
+        const earlyFloorMet = minPassFloorMet && messageFloorMet;
         const unresolvedRowsResolvedAsFailures = pending > 0 && completed + failedCount >= effectiveTarget;
         const noActiveProcessing = processingCount === 0 && queuedCount === 0 && cancellableCount === 0;
-        if (completed >= effectiveTarget) {
+        if (completed >= effectiveTarget && messageFloorMet) {
             const percent = completed > 0 ? Math.round((passed / completed) * 100) : 0;
             const rowSnapshot = includeRows
-                ? await getTableRowsMinimal(tableId, {
-                    limit: effectiveTarget,
-                })
+                ? (rowSnapshotForMessageCheck ??
+                    (await getTableRowsMinimal(tableId, {
+                        limit: effectiveTarget,
+                    })))
                 : null;
             return {
                 ready: true,
@@ -735,11 +759,21 @@ export async function waitForRubricResults(input) {
                     targetCount: effectiveTarget,
                     ...(minPassedCount !== null ? { minPassedCount } : {}),
                 },
+                ...(minMessagesCount !== null
+                    ? {
+                        messageGeneration: {
+                            completed: messagesCount,
+                            passingGeneratedMessages: passingGeneratedMessagesCount ?? 0,
+                            minMessagesCount,
+                            floorMet: true,
+                        },
+                    }
+                    : {}),
                 ...(rowSnapshot ? { rows: rowSnapshot.rows } : {}),
                 stats,
             };
         }
-        if (minPassFloorMet) {
+        if (earlyFloorMet) {
             const percent = completed > 0 ? Math.round((passed / completed) * 100) : 0;
             const reason = !noActiveProcessing
                 ? "min_passed_count_met_with_active_processing"
@@ -747,9 +781,10 @@ export async function waitForRubricResults(input) {
                     ? "min_passed_count_met_with_resolved_failures"
                     : "min_passed_count_met_no_active_processing";
             const rowSnapshot = includeRows
-                ? await getTableRowsMinimal(tableId, {
-                    limit: effectiveTarget,
-                })
+                ? (rowSnapshotForMessageCheck ??
+                    (await getTableRowsMinimal(tableId, {
+                        limit: effectiveTarget,
+                    })))
                 : null;
             return {
                 ready: true,
@@ -766,6 +801,16 @@ export async function waitForRubricResults(input) {
                     targetCount: effectiveTarget,
                     minPassedCount,
                 },
+                ...(minMessagesCount !== null
+                    ? {
+                        messageGeneration: {
+                            completed: messagesCount,
+                            passingGeneratedMessages: passingGeneratedMessagesCount ?? 0,
+                            minMessagesCount,
+                            floorMet: true,
+                        },
+                    }
+                    : {}),
                 partialResult: {
                     completed,
                     passed,
@@ -775,6 +820,14 @@ export async function waitForRubricResults(input) {
                     minPassedCount,
                     enoughToDiagnose: true,
                     floorMet: true,
+                    ...(minMessagesCount !== null
+                        ? {
+                            messagesCount,
+                            passingGeneratedMessages: passingGeneratedMessagesCount ?? 0,
+                            minMessagesCount,
+                            messageFloorMet: true,
+                        }
+                        : {}),
                 },
                 ...(rowSnapshot ? { rows: rowSnapshot.rows } : {}),
                 stats,
@@ -785,9 +838,21 @@ export async function waitForRubricResults(input) {
     const completed = lastStats?.passRate?.completed ?? 0;
     const passed = lastStats?.passRate?.passed ?? 0;
     const percent = completed > 0 ? Math.round((passed / completed) * 100) : 0;
+    const messagesCount = lastStats?.messagesCount ?? 0;
     const totalRows = lastStats?.totalRows ?? 0;
     const effectiveTarget = totalRows > 0 ? Math.min(targetCount, totalRows) : targetCount;
     const pending = Math.max(effectiveTarget - completed, 0);
+    let timeoutPassingGeneratedMessagesCount = null;
+    if (minMessagesCount !== null) {
+        try {
+            timeoutPassingGeneratedMessagesCount = countPassingGeneratedMessages(await getTableRowsMinimal(tableId, {
+                limit: effectiveTarget,
+            }));
+        }
+        catch {
+            timeoutPassingGeneratedMessagesCount = null;
+        }
+    }
     return {
         ready: false,
         reason: "timeout",
@@ -802,6 +867,16 @@ export async function waitForRubricResults(input) {
             targetCount: effectiveTarget,
             ...(minPassedCount !== null ? { minPassedCount } : {}),
         },
+        ...(minMessagesCount !== null
+            ? {
+                messageGeneration: {
+                    completed: messagesCount,
+                    passingGeneratedMessages: timeoutPassingGeneratedMessagesCount ?? 0,
+                    minMessagesCount,
+                    floorMet: (timeoutPassingGeneratedMessagesCount ?? 0) >= minMessagesCount,
+                },
+            }
+            : {}),
         partialResult: {
             completed,
             passed,
@@ -811,17 +886,25 @@ export async function waitForRubricResults(input) {
             ...(minPassedCount !== null ? { minPassedCount } : {}),
             enoughToDiagnose: completed > 0,
             floorMet: minPassedCount !== null && passed >= minPassedCount,
+            ...(minMessagesCount !== null
+                ? {
+                    messagesCount,
+                    passingGeneratedMessages: timeoutPassingGeneratedMessagesCount ?? 0,
+                    minMessagesCount,
+                    messageFloorMet: (timeoutPassingGeneratedMessagesCount ?? 0) >= minMessagesCount,
+                }
+                : {}),
         },
         diagnostic: {
             totalRows,
             enrichedCount: lastStats?.enrichedCount,
             needsEnrichCount: lastStats?.needsEnrichCount,
-            messagesCount: lastStats?.messagesCount,
+            messagesCount,
             needsApprovalCount: lastStats?.needsApprovalCount,
             processingCount: lastStats?.processingCount,
             failedCount: lastStats?.failedCount,
         },
-        guidance: "If this is create-campaign-v2 validate-sample, do not repeat waits indefinitely. Use passRate/stats to diagnose and surface sample_revision_required before Settings when the sample is under the pass floor or messages are incomplete.",
+        guidance: "If this is create-campaign-v2 validate-sample, do not repeat waits indefinitely. Use passRate/stats to diagnose and surface sample_revision_required before Settings when the sample is under the pass floor. If minMessagesCount is set, one passing generated message is enough to start review; do not wait for a stronger sample.",
         stats: lastStats,
     };
 }

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -155,14 +155,17 @@ should be a compact `## Source Recommendation` block with:
 - good-fit target: about 150 prospects after cleanup, enrichment, and filters
 - source-candidate plan: about 1,000 raw engagers using a conservative 15%
   fit-rate assumption unless sampled data supports a different number
+- planning floor: continue with Signal Discovery only when sampled/projected
+  fit is at least 10% after cleanup; below that, move to Sales Nav recent
+  activity instead of scraping noisy engagers
 - review checkpoint: import the first 25 leads for fit and message review
 - a selected-post table with post author/topic, why it fits, and visible
   engagement
 - total visible pool and estimated good-fit pool
 - first pass: build the source list, then import only the review
   batch
-- fallback: switch to Sales Nav recent activity if the review batch is
-  vendor-heavy, agency-heavy, or off-ICP
+- fallback: switch to Sales Nav recent activity if sampled/projected fit falls
+  below 10%, or if the review batch is vendor-heavy, agency-heavy, or off-ICP
 
 When the user has not supplied a source and multiple source angles are viable,
 scout those angles as independent branches when the host can actually do it:

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

@@ -49,9 +49,10 @@ for debug output.
 12. Sync the approved template into the campaign brief.
 13. After message approval, keep the watched app on Filter Leads while the
     bounded enrichment/filter cascade starts.
-14. Move to Messages only after at least one review row passes, generate and
-    review bounded messages, then hand off to Settings, sender, sequence, and
-    explicit launch greenlight.
+14. Move to Messages only after at least one review row passes and one generated
+    message is ready for review. Do not wait for a stronger sample once that
+    first passing message exists; review it, then hand off to Settings, sender,
+    sequence, and explicit launch greenlight.
 
 There is no normal approval-packet, commit-gate, atomic-mint, or local
 artifact-validation step. Those belong only to legacy validation/rehearsal
@@ -149,6 +150,11 @@ sequential by default. Run `source-scout-linkedin-engagement`,
 `source-scout-sales-nav`, and `source-scout-prospeo-contact` in parallel only
 when the user explicitly requested source comparison, a prior lane failed, or
 the first viable lane is borderline and a cheap fallback check is needed.
+Use a 10% planning floor after conservative cleanup. If Signal Discovery falls
+below that floor, move to Sales Nav. If Sales Nav falls below that floor after
+reasonable refinement, move to Prospeo. Prospeo is the terminal fallback; if it
+also falls below 10%, tighten the ICP/source direction instead of inventing
+another provider.
 
 After scouting, show a second approval gate for the concrete source action. For
 Signal Discovery, this gate must say how many selected posts will be scraped,
@@ -175,6 +181,7 @@ Use Signal Discovery first.
 
 **Good-fit target:** ~150 prospects after cleanup, enrichment, and filters<br>
 **Source-candidate plan:** scrape ~1,000 raw engagers using a conservative 15% fit-rate assumption<br>
+**Planning floor:** continue only when sampled/projected fit is at least 10% after cleanup; below that, switch to Sales Nav recent activity<br>
 **Review checkpoint:** import the first 25 leads into the campaign for fit and message review before scaling<br>
 
 ### Selected posts
@@ -199,8 +206,9 @@ AI-native sales workflows.
 **First pass:** build the source list, then import only the 25-lead review
 batch so we can inspect fit and messages before scaling.
 
-**Fallback:** if the review batch is too vendor-heavy, agency-heavy, or
-off-ICP, switch to Sales Nav recent activity.
+**Fallback:** if sampled/projected fit falls below 10%, or if the review batch
+is too vendor-heavy, agency-heavy, or off-ICP, switch to Sales Nav recent
+activity.
 ```
 
 A source recommendation must show concrete evidence: source lane, filters or

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

@@ -239,9 +239,9 @@ for source approval before import.
 For Signal Discovery, the second gate is not "approve source" in the abstract.
 It is a concrete scrape approval: show a compact `## Source Recommendation`
 with the ~150 good-fit prospect goal, 15% raw-engager assumption, selected-post
-table, total visible pool, estimated good-fit pool, first-pass review
-batch, and fallback. The approval question should be "Approve scraping N Signal
-Discovery posts?"
+table, total visible pool, estimated good-fit pool, 10% planning floor,
+first-pass review batch, and fallback. The approval question should be "Approve
+scraping N Signal Discovery posts?"
 
 That scrape approval is single-use. Once the user approves it, do not replay
 the source card or ask for the same approval again. Acknowledge the approval in
@@ -257,6 +257,11 @@ borderline and needs a second source to avoid a bad recommendation. The fallback
 order must stay plain: use Sales Nav to find ICP people who are actively posting
 on LinkedIn; if that is not enough, search Sales Nav by titles; if that is still
 not enough, use Prospeo for a broader account/contact path.
+Use a 10% planning floor after conservative cleanup. If Signal Discovery falls
+below that floor, move to Sales Nav. If Sales Nav falls below that floor after
+reasonable refinement, move to Prospeo. Prospeo is the terminal fallback; if it
+also falls below 10%, tighten the ICP/source direction instead of inventing
+another provider.
 
 Source-angle comparison should be real, not implied. Call
 `get_source_scout_registry` before dispatching source scouts and use the

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

@@ -1124,8 +1124,14 @@
           "cellSource": "pending_generate_message_cells_for_passing_rows using approved_campaign_brief_template"
         },
         {
-          "tool": "wait_for_campaign_table_ready",
-          "purpose": "wait_for_generate_message_cells_to_complete"
+          "tool": "wait_for_rubric_results",
+          "purpose": "wait_for_first_passing_generated_message",
+          "requiredValues": {
+            "includeRows": false,
+            "minPassedCount": 1,
+            "minMessagesCount": 1
+          },
+          "readVia": "stats_only_tool_result"
         },
         {
           "action": "observe_generate_message_results",
@@ -1169,25 +1175,24 @@
             "currentStep": "auto-execute-messaging",
             "watchNarration.stage": "review-ready"
           },
-          "watchNarrationRule": "Say what just happened, that review-batch messages are ready in Messages, and that the next action is reviewing or approving generated messages before Settings."
+          "watchNarrationRule": "Say the first passing generated message is ready in Messages; next is review before Settings."
         },
         {
           "action": "ask_generated_message_review_choice",
           "uses": "request_user_input",
           "choices": [
-            "Approve generated messages",
+            "Approve generated message and continue to Settings",
             "Revise filters",
             "Revise message template",
             "Pause here"
-          ],
-          "rule": "Do not advance to Settings until the generated review-batch messages have been reviewed and approved."
+          ]
         }
       ],
       "allowedTools": [
         "get_subskill_asset",
         "get_rows_minimal",
         "queue_cells",
-        "wait_for_campaign_table_ready",
+        "wait_for_rubric_results",
         "update_campaign",
         "AskUserQuestion",
         "request_user_input"
@@ -1201,6 +1206,7 @@
       "hardRules": [
         "critique_failure_never_escalates",
         "critique_sample_size_bounded_by_config",
+        "first_passing_generated_message_unblocks_review",
         "critics_fixed_at_targeting_copy_voice",
         "synthesis_enforces_phase_84_token_contract",
         "opus_reserved_for_highest_value_subset",

package/skills/create-campaign-v2/references/sample-validation-loop.md

@@ -60,9 +60,10 @@ auto-revise leads.
      explicit batch count anyway so future larger expansion batches do not
      accidentally stop early
      (see §Known Tool Behaviors #3)
-   - minPassedCount=1 means one passing filtered row unblocks Step 15
-     Generate Message observation. Do not wait for all sample rows to finish
-     before messages start.
+   - minPassedCount=1 means one passing filtered row unblocks Step 15 Generate
+     Message observation. Step 15 then waits only for one generated message
+     (`minMessagesCount=1`) before review. Do not wait for all sample rows to
+     finish before messages start.
 
 7. call `wait_for_rubric_results` with `includeRows=false`; extract ONLY:
    - ready: boolean
@@ -101,7 +102,9 @@ auto-revise leads.
 10. branch:
    if passInSample >= 1:
        proceed to Step 15 (auto-execute-messaging) with currently passing rows
-       so Generate Message can start without waiting for the full sample
+       so Generate Message can start without waiting for the full sample. Once
+       one passing generated message is ready, stop for user review instead of
+       waiting for a stronger sample.
    else:
        diagnose (see Brief-vs-List Diagnosis below)
        revisionRound += 1
@@ -179,7 +182,8 @@ processing makes the experience feel frozen.
 
 Workaround: treat timeout stats as a partial sample. If at least one row has
 passed, move to Step 15 and observe or queue Generate Message for the passing
-rows. If zero rows have passed and no active processing is visible, stop at
+rows; Step 15 stops when one generated message is ready. If zero rows have
+passed and no active processing is visible, stop at
 `Status: sample-needs-revision` before Settings. Show the completed / passed /
 pending counts and ask whether to revise source, revise filter/rubric, or wait
 once only if active processing is still visible.

package/skills/create-campaign-v2/references/step-13-import-leads.md

@@ -125,7 +125,9 @@ fallback fit rate is 15%, so the default source-candidate plan is about 1,000
 raw engagers. If the sampled fit rate is stronger or weaker, use the sampled
 rate with a conservative cleanup factor, cap the source candidates at the
 approved provider limit, and select only enough posts to reach that engager
-count. The subsequent
+count. The planning floor is 10% projected fit after cleanup; if Signal
+Discovery falls below that floor, do not import the source list. Route back to
+find-leads and move to Sales Nav recent activity instead. The subsequent
 `confirm_lead_list` call still uses `targetLeadCount: <importLimit>` so only the
 bounded review batch enters the campaign table.
 

package/skills/create-campaign-v2/references/step-15-re-cascade.md

@@ -4,15 +4,16 @@ This reference governs Step 15 (`auto-execute-messaging`) re-cascade
 behavior when Step 14's validate-sample loop graduates additional rows
 from pending → passed after the first Generate Message cells have already run.
 
-Load whenever Step 15 is about to transition to
-`awaiting-user-greenlight`, and on every resume into Step 15.
+Load whenever Step 15 is about to ask for generated-message review or transition
+to `awaiting-user-greenlight`, and on every resume into Step 15.
 
 ## Principle
 
-Generate Message cells are cascade-scoped. If Step 14's rubric flips rows
-from pending → passed AFTER Step 15 first observes messages for the review
-batch, the new rows can sit pending with no message. Step 15 must explicitly
-queue the newly-pending Generate Message cells for the review-batch subset.
+Generate Message cells are cascade-scoped. If Step 14's rubric flips rows from
+pending → passed AFTER Step 15 first observes messages for the review batch, the
+new rows can sit pending with no message. That must not block the first review
+handoff. Step 15 opens review as soon as one passing generated message exists;
+late-passed rows can be re-cascaded after explicit user continuation or resume.
 
 Observed on manual Phase-85 signal-discovery run (2026-04-20): 15 new
 rows graduated pending → passed mid-tail while `messagesCount` stayed
@@ -22,13 +23,17 @@ flat at 257. The new rows never got messages.
 
 Re-cascade runs whenever ALL of the following are true:
 
-1. Step 15 has already observed the initial review-batch message cascade.
+1. The user has already approved the first generated message or explicitly asked
+   to continue processing more review-batch rows.
 2. A subsequent check of rubric state shows rows that were pending at
    first message-generation pass are now passed.
 3. Those newly-passed rows do NOT yet have generated messages
    (`messagesCount` flat relative to pre-cascade).
 4. Step 15 has NOT yet transitioned to `awaiting-user-greenlight`.
 
+Before that first generated-message approval, do not run this loop just to wait
+for a bigger sample. One passing generated message is enough for review.
+
 If condition 4 already fired (i.e. we're in Step 16), the re-cascade
 runs on resume into Step 15 if validate-sample was re-entered and new
 rows graduated.

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

@@ -252,16 +252,17 @@ Template approved, bounded filter test running:
   "stage": "fit-message",
   "headline": "Template saved",
   "visibleState": "The browser stays on Filter Leads while the bounded enrichment and filter test runs.",
-  "agentIntent": "Codex saved the approved message template, queued the review-batch Enrich Prospect cells, and is waiting for at least one row to pass before moving to Messages.",
-  "nextAction": "Move to Messages after a passing row"
+  "agentIntent": "Codex saved the approved message template, queued the review-batch Enrich Prospect cells, and is waiting for one passing row with one generated message before moving to review.",
+  "nextAction": "Review the first passing generated message"
 }
 ```
 
 Do not move to Messages immediately after `approve-message`. The visible route
 is already Filter Leads after `save_rubrics`; approving the message only unlocks
 the bounded cascade from that screen. Move to Messages only once at least one
-review-batch row passes and Generate Message cells are ready/running for the
-passing rows.
+review-batch row passes and one generated message is ready for review. Do not
+wait for the rest of the review batch or a stronger sample before asking the
+user to approve the generated message.
 
 Messages waiting for template:
 

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

@@ -58,11 +58,12 @@ Step 14 — kick bounded cascade + observe sample
    passing filtered row exists.)
 
 Step 15 — observe messaging
-  get_rows_minimal                 # confirm passing rows have completed Generate Message cells
+  wait_for_rubric_results({ minPassedCount: 1, minMessagesCount: 1, includeRows: false })
+  get_rows_minimal                 # confirm the first passing generated message exists
   (rare) queue_cells on any pending Generate Message cells
   token-contract spot check via get_rows
   update_campaign(currentStep=auto-execute-messaging) with review-ready narration
-  ask the user to approve generated review-batch messages before Settings
+  ask the user to approve the generated message before Settings
   only after approval: update_campaign(currentStep=awaiting-user-greenlight)
   (generate_messages is NOT an MCP tool; messages come from the cascade)
 
@@ -291,8 +292,10 @@ Do not route to a visible `validate-sample` step. Full decision tree lives in
 review batch only. After `save_rubrics` and the approved message template are
 persisted, Step 14 queues the review-batch Enrich Prospect cells, waits until
 filter results start landing, then moves to message observation as soon as one
-row passes. It does NOT call `check_rubric`, `bulk_enrich_with_prospeo`, or any
-other direct enrichment/scoring tool.
+row passes. Step 15 opens review as soon as one passing generated message
+exists. Do not wait for a larger or stronger sample once that first passing
+message is ready. It does NOT call `check_rubric`,
+`bulk_enrich_with_prospeo`, or any other direct enrichment/scoring tool.
 
 Shape:
 
@@ -307,6 +310,7 @@ projectedPass = round(passInSample / sampleSize * importLimit)
 if wait_for_rubric_results.ready === true and passRate.passed >= 1:
     advance to Step 15 to observe or queue Generate Message for currently passing rows
     do not wait for every sample row to finish before message generation starts
+    stop for review as soon as one passing generated message is ready
 else if wait_for_rubric_results.ready === false and reason === "timeout":
     use the partial passRate/stats as the sample diagnostic
     if passRate.passed >= 1:
@@ -382,17 +386,20 @@ Template`. If it does not, fail before the cascade runs. Do not repair
      already (cascade auto-fired it). If it is still `pending`, queue
      it explicitly: `queue_cells({ tableId, cellIds:
 <generateMessageCellIds> })`.
-3. `wait_for_campaign_table_ready` (or poll) until every passing
-   row's Generate Message cell is `completed`.
-4. Read the results back via `get_rows` (full) and sanity-check a
-   sample against the Phase 84 token contract: no unresolved
+3. `wait_for_rubric_results({ tableId, targetCount: reviewBatchSize,
+minPassedCount: 1, minMessagesCount: 1, includeRows: false })` until the
+   first passing generated message is ready. Do not wait for every passing row's
+   Generate Message cell, and do not add "one more wait" for a stronger sample.
+   Remaining review-batch rows can continue processing in the background.
+4. Read the first ready generated message back via `get_rows` (full) and
+   sanity-check that sample against the Phase 84 token contract: no unresolved
    `{{tokens}}`, no invented proof, one sentence per line, etc.
 5. If the sample fails the token contract, diagnose brief-vs-list
    (same revision loop as Step 14) and escalate if over
    `maxRevisionRounds`.
-6. On success, keep `currentStep: "auto-execute-messaging"` and ask the user
-   to approve the generated review-batch messages. Only that approval may move
-   the campaign to Settings / `awaiting-user-greenlight`.
+6. On success, keep `currentStep: "auto-execute-messaging"` and ask the user to
+   approve the generated message before continuing to Settings. Only that
+   approval may move the campaign to Settings / `awaiting-user-greenlight`.
 
 **Do NOT hand-write message bodies via `update_cell`.** `update_cell`
 is reachable for legitimate operator overrides AFTER the tail hands
@@ -432,15 +439,16 @@ strings, which is why Step 16 requires Step 15 to be complete.
 4. Check `messaging.tokenContract`. When `strict`, reject any sample
    message that contains unresolved or unsupported tokens (including
    any critique rewrite that tried to introduce one).
-5. If the sample passes the token contract (and critique when enabled),
-   stop at the review-batch handoff. Do NOT scale to the full source list
-   before explicit user expansion approval.
+5. If the first passing generated message passes the token contract (and
+   critique when enabled), stop at the review-batch handoff. Do NOT wait for the
+   remaining review-batch rows and do NOT scale to the full source list before
+   explicit user expansion approval.
 6. If the sample fails the token contract or critique, diagnose +
    loop the same way Step 14 does (brief-vs-list), subject to the same
    `maxRevisionRounds` cap.
 7. On success, keep `currentStep: "auto-execute-messaging"`, show that the
-   review-batch messages are ready in Messages, and ask for approval before
-   Settings. Only after the user approves those generated messages should
+   first passing generated message is ready in Messages, and ask for approval
+   before Settings. Only after the user approves the generated message should
    `update_campaign({ campaignId, currentStep: "awaiting-user-greenlight" })`
    run.
 

package/skills/find-leads/SKILL.md

@@ -321,6 +321,9 @@ Use first when the value is in conversation opportunity, competitor engagers, co
 - Sample a representative first page only, scoring the first 25-40 engagers across the chosen posts against a rough yes/no headline rubric or `headlineICPCriteria`.
 - Use headline and display-name cues only for the spot-check sample; do not enrich people during this phase.
 - Base `estimatedReachableLeads` on the sampled engager pass rate, not only on a guessed discount from post themes.
+- Use a 10% planning floor after conservative cleanup. If the sampled/projected
+  fit rate is below 10%, do not scale Signals; move to Sales Nav recent activity
+  instead.
 - A Signals lane with ~150+ estimated ICP-fit reachable engagers from selected
   posts is viable for a focused warm campaign, even if Sales Nav is more
   scalable. Do not discard that lane solely for being smaller. If post-level
@@ -384,6 +387,9 @@ Use first when LinkedIn activity plus tighter role / company filters matter.
   mark Sales Nav as a provider/tool issue and do not include it as a winning
   source.
 - If quality is good but scale is too small, widen the lane by adding/removing roles, expanding industries, widening headcount bands, or relaxing activity constraints.
+- Use the same 10% planning floor after cleanup. If the final Sales Nav lane is
+  projected below 10% good-fit after reasonable refinement, move to Prospeo
+  rather than importing a noisy Sales Nav list.
 - Use as many smart refinement steps as needed within the remaining probe budget instead of returning the first under-scaled recipe.
 - If the lane is meant to support scalable outbound, do not stop at a merely borderline workable result when obvious expansion steps remain.
 - If you can name a specific next Sales Nav refinement that is still allowed by the probe budget, execute it before returning instead of listing it only as a recommendation.
@@ -404,6 +410,9 @@ Use first for broad persona expansion, ABM/domain targeting, hiring-led targetin
 - If you widen with seniority labels such as `Head` or `Director`, keep a matching department/function constraint and inspect the sample for off-function leakage such as `Head of Social Media`, `Head of IT`, or `Director of Finance`.
 - If quality is poor, tighten titles, company shape, seniority, geography, or hiring filters.
 - If quality is good but scale is too small, widen titles, industries, company-size bands, or account scope.
+- Prospeo is the terminal fallback for this chain. If projected fit is still
+  below the 10% planning floor after reasonable Prospeo refinement, stop and ask
+  for a tighter ICP/source direction instead of inventing another provider.
 - When ABM/domain targeting exists, prefer refining around the account set before broadening away from it.
 - Use as many smart refinement steps as needed within the remaining probe budget instead of returning the first under-scaled recipe.
 - If the lane is meant to support scalable outbound, do not stop at a merely borderline workable result when obvious expansion steps remain.

package/skills/providers/prospeo.md

@@ -63,6 +63,10 @@ search_prospeo({
 - Use `import_leads` with `provider: \"prospeo\"` and the `searchId` to create a lead list and start import.
 - **IMPORTANT:** If `import_leads` returns `needsModeSelection: true`, use `AskUserQuestion` to ask "add to existing leads or replace?" Do NOT assume.
 - Default source target is 300+ good-fit leads, capped at 2,500 source candidates for now.
+- Apply the campaign source planning floor: the sampled/projected good-fit rate
+  after cleanup should be at least 10%. Prospeo is the terminal fallback; if the
+  best reasonable Prospeo lane is still below 10%, tighten the ICP/source
+  direction instead of switching to another provider.
 - After the list finishes and the user confirms it looks good, call `confirm_lead_list` with the `jobId` and the review-batch `targetLeadCount` from the active campaign defaults to import only the review batch into the campaign table.
 - `import_leads` owns the watched move to `confirm-lead-list` after a lead list/job exists.
 - `confirm_lead_list` owns the watched move to `filter-choice` after the bounded review batch exists.

package/skills/providers/sales-nav.md

@@ -96,6 +96,11 @@ Example search name: "Active CXOs at 201-500 companies"
    - < 1,000 = remove a filter or widen criteria
    - > 10,000 = add more filters
 
+   Also apply the campaign source planning floor: the sampled/projected good-fit
+   rate after cleanup should be at least 10%. If the best reasonable Sales Nav
+   lane remains below 10%, do not present it as the winning source; move to
+   Prospeo for broader account/contact coverage.
+
 4. FINAL SEARCH + CONFIRM - Execute winning strategy, ask before saving
 
    - Run the final search with the best filter combination

package/skills/providers/signal-discovery.md

@@ -24,7 +24,7 @@ When the user asks to find posts or start searching, **IMMEDIATELY begin Round 1
 
 <lead_target>
 
-- **Default: provider max import count** (use this unless user specifies otherwise; see `lead-import-limits.json`, currently 250)
+- **Default: provider max import count** (use this unless user specifies otherwise; see `lead-import-limits.json`, currently 2,500)
 - **Maximum: provider max import count**
 - Quality > Quantity: a few hundred active users > 1000 potentially inactive profiles
 - Focus on ACTIVE platform users who will actually see and respond to outreach
@@ -104,6 +104,9 @@ You must estimate:
   - `ceil(targetGoodFitLeads / sampledFitRate)`; for example 15 good-fit
     prospects per 100 engagers means a 150-good-fit source target needs about
     1,000 engagers scraped
+- `planningFloor`
+  - minimum acceptable sampled/projected fit rate after conservative cleanup;
+    default 10%. Below this, do not scale Signal Discovery.
 - `projectedRange`
   - the conservative range implied by the observed sample
 
@@ -130,7 +133,10 @@ Use conservative logic:
    - preferred: "`sampledCount`: 40, `passCount`: 9, `passRate`: ~22%, `goodFitPer100Engagers`: ~22 before cleanup / ~13-16 after cleanup, `requiredEngagersToScrape`: ~940-1,150 for a 150-good-fit target after cleanup, `avgReachableEngagersPerPost`: 240, `goodFitProspectsPerPost`: ~31-38, `postsNeededForTarget`: ~4-5, `recentStrongPostCount`: 15-25, `freshEnoughPostCount`: 8-12, `projectedRange`: 150-190 from selected posts"
    - fallback: "I could not fetch engagers, so this is inferred from post and author quality only"
 5. If the evidence is too weak, say so and return a low-confidence estimate instead of pretending precision.
-6. Do not manually enumerate dozens of engagers in the final answer. Summarize the sample by `sampledCount`, `passCount`, `passRate`, `projectedRange`, and 3-6 representative examples.
+6. If sampled/projected fit after cleanup is below the 10% planning floor,
+   reject the Signal Discovery scrape path and recommend Sales Nav recent
+   activity as the next source.
+7. Do not manually enumerate dozens of engagers in the final answer. Summarize the sample by `sampledCount`, `passCount`, `passRate`, `projectedRange`, and 3-6 representative examples.
 
 </yield_estimation>
 
@@ -389,12 +395,15 @@ recommendation, estimate source capacity from real sample math:
 - average reachable engagers per right-content post
 - expected good-fit leads per selected post after dedupe/cleanup
 - posts needed to reach the target
+- whether sampled/projected fit clears the 10% planning floor
 
 Then select the smallest right-content post set that plausibly hits the source
 target. Do not scrape every promoted sample post by default; promoted sampling
 state and final scrape plan are separate. 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.
+scale fallback rather than padding the selection with noisy posts. If the
+sampled/projected fit rate is below 10% after cleanup, do not call
+`import_leads`; move to Sales Nav recent activity.
 
 ```json
 select_promising_posts({