@sellable/mcp 0.1.475 → 0.1.476

package/dist/tools/leads.d.ts

@@ -4617,7 +4617,7 @@ export declare function importLeads(input: ImportLeadsInput): Promise<{
     validSelectedPostCount: number;
     recommendedValidPostCount: number;
     estimatedValidEngagers: number;
-    targetEngagerCount: number;
+    targetEngagerCount: number | null;
     suggestedToolCalls: never[];
     leadListId?: undefined;
     existingLeadListId?: undefined;
@@ -4651,7 +4651,7 @@ export declare function importLeads(input: ImportLeadsInput): Promise<{
     validSelectedPostCount: number;
     recommendedValidPostCount: number;
     estimatedValidEngagers: number;
-    targetEngagerCount: number;
+    targetEngagerCount: number | null;
     message: string;
     suggestedToolCalls: {
         tool: string;
@@ -4698,7 +4698,7 @@ export declare function importLeads(input: ImportLeadsInput): Promise<{
     estimatedEngagers: number;
     selectedPostCount: number;
     availableSelectedPostCount: number;
-    targetEngagerCount: number;
+    targetEngagerCount: number | null;
     maxPostsToScrape: number | null;
     limitedSelectedPosts: boolean;
     invalidSelectedPostCount: number;

package/dist/tools/leads.js

@@ -1127,15 +1127,15 @@ function normalizeEngagementCount(value) {
         : 0;
 }
 function buildSignalDiscoverySourceRecommendation({ selectedPosts, targetEngagerCount, maxPostsToScrape, }) {
-    const { targetGoodFitLeads, defaultFitRate, minPlanningFitRate, sourceCandidateTarget, reviewBatchSize, } = getSignalDiscoverySourcePlanDefaults();
-    const effectiveTargetEngagerCount = normalizePositiveInteger(targetEngagerCount) ?? sourceCandidateTarget;
+    const { targetGoodFitLeads, defaultFitRate, minPlanningFitRate, reviewBatchSize, } = getSignalDiscoverySourcePlanDefaults();
+    const explicitTargetEngagerCount = normalizePositiveInteger(targetEngagerCount);
     const normalizedSelectedPosts = selectedPosts.map((post) => ({
         ...post,
         likes: normalizeEngagementCount(post.likes),
         comments: normalizeEngagementCount(post.comments),
     }));
     const scrapePlan = selectSignalPostsForImport(normalizedSelectedPosts, {
-        targetEngagerCount: effectiveTargetEngagerCount,
+        targetEngagerCount: explicitTargetEngagerCount,
         maxPostsToScrape: maxPostsToScrape ?? undefined,
     });
     const recommendedPosts = scrapePlan.posts;
@@ -1143,8 +1143,8 @@ function buildSignalDiscoverySourceRecommendation({ selectedPosts, targetEngager
     const recommendedCount = recommendedPosts.length;
     const totalVisibleEngagement = normalizedSelectedPosts.reduce((sum, post) => sum + post.likes + post.comments, 0);
     const recommendedVisibleEngagement = recommendedPosts.reduce((sum, post) => sum + post.likes + post.comments, 0);
-    const fitRateForEstimate = targetEngagerCount && effectiveTargetEngagerCount > 0
-        ? Math.min(1, targetGoodFitLeads / effectiveTargetEngagerCount)
+    const fitRateForEstimate = explicitTargetEngagerCount && explicitTargetEngagerCount > 0
+        ? Math.min(1, targetGoodFitLeads / explicitTargetEngagerCount)
         : defaultFitRate;
     const estimatedGoodFit = scrapePlan.estimatedEngagers * fitRateForEstimate;
     const tableRows = recommendedPosts
@@ -1154,9 +1154,12 @@ function buildSignalDiscoverySourceRecommendation({ selectedPosts, targetEngager
         return `| ${escapeMarkdownTableCell(post.authorName)} | ${escapeMarkdownTableCell(post.reason)} | ${formatApproxInteger(engagement)} | ${formatApproxInteger(estimatedPostGoodFit)} |`;
     })
         .join("\n");
-    const fitRateLabel = targetEngagerCount && effectiveTargetEngagerCount > 0
+    const fitRateLabel = explicitTargetEngagerCount && explicitTargetEngagerCount > 0
         ? "the approved buyer-search target"
         : `the ${Math.round(defaultFitRate * 100)}% starting estimate`;
+    const peopleToCheckCopy = explicitTargetEngagerCount && explicitTargetEngagerCount > 0
+        ? `about ${explicitTargetEngagerCount.toLocaleString("en-US")} people who reacted or commented`
+        : `up to ${formatApproxInteger(scrapePlan.estimatedEngagers)} people from the selected posts`;
     const selectedPoolCopy = recommendedCount < selectedCount
         ? `**Posts considered:** ${selectedCount.toLocaleString("en-US")} selected posts with ${formatApproxInteger(totalVisibleEngagement)} public reactions/comments<br>\n**Recommended first set:** ${recommendedCount.toLocaleString("en-US")} post${recommendedCount === 1 ? "" : "s"} with ${formatApproxInteger(recommendedVisibleEngagement)} public reactions/comments and up to ${formatApproxInteger(scrapePlan.estimatedEngagers)} people to check<br>`
         : `**Public activity in the selected posts:** ${formatApproxInteger(totalVisibleEngagement)} reactions/comments<br>\n**People we can check from this set:** up to ${formatApproxInteger(scrapePlan.estimatedEngagers)}<br>`;
@@ -1167,7 +1170,7 @@ Start with LinkedIn posts.
 I found ${recommendedCount.toLocaleString("en-US")} recommended LinkedIn post${recommendedCount === 1 ? "" : "s"} to check first. People there are already reacting or commenting around this problem.
 
 **Goal:** find about ${targetGoodFitLeads.toLocaleString("en-US")} likely prospects<br>
-**People to check:** about ${effectiveTargetEngagerCount.toLocaleString("en-US")} people who reacted or commented<br>
+**People to check:** ${peopleToCheckCopy}<br>
 **Good sign:** at least ${Math.round(minPlanningFitRate * 100)}% of the first sample should look like real prospects; below that, switch to active LinkedIn profiles with the right titles<br>
 **First review:** after the list is built, review the first ${reviewBatchSize.toLocaleString("en-US")} leads before we scale
 
@@ -1195,7 +1198,7 @@ Approval card should say:
         message,
         recommendedPostCount: recommendedCount,
         estimatedEngagers: scrapePlan.estimatedEngagers,
-        targetEngagerCount: effectiveTargetEngagerCount,
+        targetEngagerCount: explicitTargetEngagerCount ?? null,
     };
 }
 function hasUsableSignalValidationPost(post) {
@@ -2114,7 +2117,7 @@ export const leadToolDefinitions = [
                 },
                 targetEngagerCount: {
                     type: "number",
-                    description: "Signal Discovery: target number of people from selected posts to check. Default planning target is about 300 likely prospects at a 20% starting pass assumption, or about 1500 people to check. Use real sample math when available: target likely prospects divided by sampled pass rate. If the sampled/projected fit rate is below the 10% planning floor, switch to the next provider instead of scaling noisy post reactions. Limits selected posts before starting scrape, with a backend hard cap of 10 posts.",
+                    description: "Signal Discovery: optional explicit target number of people from selected posts to check. If omitted, import all selected posts up to backend Signal Discovery caps. Use only when the approved source plan has real sample math: target likely prospects divided by sampled pass rate. If the sampled/projected fit rate is below the 10% planning floor, switch to the next provider instead of scaling noisy post reactions. When provided, this can limit selected posts before starting scrape, with a backend hard cap of 10 posts.",
                 },
                 maxPostsToScrape: {
                     type: "number",
@@ -2263,7 +2266,7 @@ export const leadToolDefinitions = [
                 },
                 targetEngagerCount: {
                     type: "number",
-                    description: "Optional source-candidate target from sample math. When provided, the recommendation ranks selected posts by scrapable engagement and asks approval for only enough posts to cover this target. If omitted, uses the default Signal Discovery source target.",
+                    description: "Optional source-candidate target from sample math. When provided, the recommendation ranks selected posts by scrapable engagement and asks approval for only enough posts to cover this target. If omitted, all selected posts are recommended up to backend Signal Discovery caps.",
                 },
                 maxPostsToScrape: {
                     type: "number",
@@ -3793,9 +3796,7 @@ export async function importLeads(input) {
         : undefined;
     // === SIGNAL DISCOVERY FLOW ===
     if (provider === "signal-discovery") {
-        const defaultSignalTargetEngagers = getSignalDiscoverySourcePlanDefaults().sourceCandidateTarget;
-        const effectiveTargetEngagerCount = normalizePositiveInteger(targetEngagerCount) ??
-            defaultSignalTargetEngagers;
+        const effectiveTargetEngagerCount = normalizePositiveInteger(targetEngagerCount) ?? null;
         // Get selected posts from the campaign's signal search tabs
         // Note: API returns flat fields (postUrl, postContent, authorName, etc.)
         const tabsResponse = await api.get(`/api/v3/campaigns/${campaignOfferId}/signal-discovery/tabs`);
@@ -3843,7 +3844,7 @@ export async function importLeads(input) {
             throw new Error(`Maximum ${MAX_SIGNAL_DISCOVERY_POSTS} Signal Discovery posts can be imported for scraping. ${uniqueSelectedPosts.length} unique posts are currently selected; reduce the selected posts to the strongest ${MAX_SIGNAL_DISCOVERY_POSTS} before calling import_leads.`);
         }
         let importSelection = selectSignalPostsForImport(uniqueSelectedPosts, {
-            targetEngagerCount: effectiveTargetEngagerCount,
+            targetEngagerCount: effectiveTargetEngagerCount ?? undefined,
             maxPostsToScrape,
         });
         let postsToScrape = importSelection.posts;
@@ -3876,7 +3877,7 @@ export async function importLeads(input) {
         }
         if (invalidPlannedPosts.length > 0 && !allowInvalidSignalPosts) {
             const validImportSelection = selectSignalPostsForImport(postValidation.validPosts, {
-                targetEngagerCount: effectiveTargetEngagerCount,
+                targetEngagerCount: effectiveTargetEngagerCount ?? undefined,
                 maxPostsToScrape,
             });
             const validRecommendedCount = validImportSelection.posts.length;
@@ -3915,7 +3916,7 @@ export async function importLeads(input) {
         }
         if (allowInvalidSignalPosts && postValidation.invalidPosts.length > 0) {
             importSelection = selectSignalPostsForImport(postValidation.validPosts, {
-                targetEngagerCount: effectiveTargetEngagerCount,
+                targetEngagerCount: effectiveTargetEngagerCount ?? undefined,
                 maxPostsToScrape,
             });
             postsToScrape = importSelection.posts;

package/dist/tools/refill-sends.js

@@ -197,7 +197,7 @@ export function refillSendsCommand(input = {}) {
             "Render target.eligibleSenderLedger and target.senderRefillPlans before mutation. Preserve the coverage labels Need to prepare, Goal, Already sent, Scheduled, Ready and waiting to be scheduled, and Still need.",
             "Use target.globalActionQueue as the only cross-sender yolo queue: execute only target.globalActionQueue[0], one globally ranked primitive, then rerun get_refill_target_plan before choosing another action.",
             "If get_refill_target_plan returns status complete, report eligible sender ledger, target.senderRefillPlans, gross target, selected days, sent count, scheduled count, projected count, campaign ids, targetShapeRevision, and no-op proof without asking for approval.",
-            "Refill target lanes are only connection invites (send_invite) or paid InMails (send_inmail_closed). Do not count send_dm or send_inmail_open as horizon target capacity; they may exist in sequences, but the planner must pick the refill lane from the most recent active campaign-backed send evidence for each sender.",
+            "Refill target lanes are connection invites (send_invite), standalone paid InMails (send_inmail_closed), or unified Sales Nav cascades represented publicly as send_inmail_closed with campaign classification sales_nav_cascade. For a Sales Nav cascade, refill the selected campaign first; its sequence can route prospects to Open InMail, paid InMail while fresh credits are >= 5, or same-campaign connection fallback without asking for separate open/paid/connection campaigns. Do not count send_dm as horizon target capacity.",
             "If remainingReadyOrProjectedGap is 0 but remainingProjectedGap is positive, run only a persistent read-only scheduler wait/reread loop; do not ask for prep/import/approval and do not close out while scheduler pickup is the only remaining state.",
             `Resolve route with resolve_campaign_fill_route({ intent: "${intent}"${input.campaignId ? `, campaignId: "${input.campaignId}"` : ""}${input.tableId ? `, tableId: "${input.tableId}"` : ""} }).`,
             'If the plain route shows stale managed waterfall evidence, archived/completed shared slots, or targets that do not cover the selected sender set, immediately call resolve_campaign_fill_route({ intent: "active" }) and inspect current dashboard-active ACTIVE/PAUSED campaign-backed sequence campaigns before declaring a sender blocked.',
@@ -215,7 +215,7 @@ export function refillSendsCommand(input = {}) {
             "Maintain a target-window saturation ledger per selected sender from get_refill_target_plan: selected days, gross capacity, actual sent counts, future scheduler-owned scheduled counts, projected counts, ready-to-schedule buffer, remaining projected gap, paid InMail threshold feasibility, targetShapeRevision, stateRevision, and next MCP primitive.",
             "In --yolo, this tool automatically maintains a run-local refreshedPaidInmailSenderIds set: when the first target plan returns refresh_paid_inmail_credits candidates for selected paid-InMail lanes, it refreshes each exact sender at most once, reruns get_refill_target_plan, and returns the post-refresh targetPlan before any prep/import/approval/start action is chosen.",
             "Do not present paid-credit refresh as the next operator action after refill_sends returns autoPaidInmailRefresh and the post-refresh targetPlan.",
-            "If paid InMail feasibility remains below threshold after that automatic refresh, report the exact sender/campaign/table/column threshold action or connection fallback; --yolo must not lower paid InMail thresholds or create campaigns.",
+            "If paid InMail feasibility remains below threshold after that automatic refresh, report the exact sender/campaign/table/column threshold action or same-campaign connection fallback; --yolo must not lower paid InMail thresholds or create campaigns.",
             "In --yolo or after one Accept, continue through every safe selected sender/campaign action covered by the rendered target packet; sent/scheduled-count progress changes stateRevision and should continue while targetShapeRevision is stable.",
             "Do not complete a fill/schedule request until a final get_refill_target_plan or refill-state reread proves projected coverage (sent + scheduled) fills the scheduler-forward target window. Treat awaiting_scheduler_after_ready_buffer as loaded, awaiting scheduler when ready buffer covers the gap; do not import/prep more rows in that state, and keep polling unless Christian stops/statuses the run or a concrete non-scheduler blocker such as paid_inmail_below_threshold appears.",
         ],

package/dist/tools/refill-target-plan.js

@@ -57,6 +57,9 @@ function stringValue(value) {
 function booleanValue(value) {
     return typeof value === "boolean" ? value : undefined;
 }
+function campaignClassificationValue(value) {
+    return value === "sales_nav_cascade" ? "sales_nav_cascade" : undefined;
+}
 function stringArray(value) {
     if (!Array.isArray(value))
         return [];
@@ -307,6 +310,7 @@ function sanitizeCampaignRanking(value) {
             tableId: stringValue(option.tableId) ?? "",
             tableName: stringValue(option.tableName) ?? null,
             campaignStatus: stringValue(option.campaignStatus) ?? null,
+            classification: campaignClassificationValue(option.classification),
             supportsSelectedLane: option.supportsSelectedLane === true,
             rankSignals: stringArray(option.rankSignals),
             rankReason: stringValue(option.rankReason) ?? "",
@@ -351,6 +355,11 @@ function sanitizePaidInmail(value) {
         tableId: stringValue(value.tableId) ?? null,
         tableName: stringValue(value.tableName) ?? null,
         columnId: stringValue(value.columnId) ?? null,
+        maxStalenessSeconds: numberValue(value.maxStalenessSeconds),
+        campaignClassification: campaignClassificationValue(value.campaignClassification) ?? null,
+        connectionFallbackAvailable: booleanValue(value.connectionFallbackAvailable) ?? false,
+        connectionFallbackCampaignId: stringValue(value.connectionFallbackCampaignId) ?? null,
+        connectionFallbackCampaignName: stringValue(value.connectionFallbackCampaignName) ?? null,
         suggestedThreshold: typeof value.suggestedThreshold === "number"
             ? value.suggestedThreshold
             : null,
@@ -622,7 +631,7 @@ function sanitizeRefillTargetPlanResult(result) {
 export const refillTargetPlanToolDefinitions = [
     {
         name: "get_refill_target_plan",
-        description: "read-only refill target planner to call before any refill mutation. It identifies eligible senders and infers one implicit refill lane per sender: connection invites or paid InMails, chosen from future scheduled, recent scheduled, and ready-to-schedule evidence in active campaign-backed sequence campaigns before falling back to campaign sequences. DMs and open-profile InMails are follow-up sequence actions, not refill target lanes. By default the planner computes the scheduler-forward 48-hour target window, selected sender-local days whose sending windows overlap that window, gross target, actual sent coverage, scheduler-owned scheduled coverage, projected coverage (sent + scheduled), ready buffer, remaining projected gap, paid InMail credit/threshold feasibility, bounded action candidates, and targetRevision drift proof. This tool does not create rows, import leads, prepare messages, approve messages, does not schedule sends, start campaigns, lower paid InMail thresholds, create campaigns, launch, spend InMail credits, or write scheduler fields. Complete projected targets no-op without approval; loaded, awaiting scheduler targets use read-only wait/reread until projected coverage fills.",
+        description: "read-only refill target planner to call before any refill mutation. It identifies eligible senders and infers one implicit refill lane per sender. For unified Sales Nav cascade campaigns, the public refill lane is the paid-InMail cascade target (send_inmail_closed) with campaign classification sales_nav_cascade; the same campaign can still route prospects to Open InMail or connection-request fallback based on row eligibility and fresh paid credits >= 5. Non-cascade lanes remain connection invites or paid InMails, chosen from future scheduled, recent scheduled, and ready-to-schedule evidence in active campaign-backed sequence campaigns before falling back to campaign sequences. DMs remain follow-up sequence actions, not refill target lanes. By default the planner computes the scheduler-forward 48-hour target window, selected sender-local days whose sending windows overlap that window, gross target, actual sent coverage, scheduler-owned scheduled coverage, projected coverage (sent + scheduled), ready buffer, remaining projected gap, paid InMail credit/threshold/freshness feasibility, same-campaign connection fallback availability, bounded action candidates, and targetRevision drift proof. This tool does not create rows, import leads, prepare messages, approve messages, does not schedule sends, start campaigns, lower paid InMail thresholds, create campaigns, launch, spend InMail credits, or write scheduler fields. Complete projected targets no-op without approval; loaded, awaiting scheduler targets use read-only wait/reread until projected coverage fills.",
         inputSchema: {
             type: "object",
             properties: {
@@ -676,7 +685,7 @@ export const refillTargetPlanToolDefinitions = [
                         type: "string",
                         enum: ["send_invite", "send_inmail_closed"],
                     },
-                    description: "Optional refill target lane override. Supported refill lanes are connection invites (send_invite) and paid InMails (send_inmail_closed) only. If omitted, the planner infers one per-sender lane from active campaign future scheduled, recent scheduled, and ready-to-schedule evidence before falling back to selected active campaign sequences.",
+                    description: "Optional refill target lane override. Supported public refill lanes are connection invites (send_invite) and paid InMails / unified Sales Nav cascades (send_inmail_closed) only. If omitted, the planner infers one per-sender lane from active campaign future scheduled, recent scheduled, and ready-to-schedule evidence before falling back to selected active campaign sequences.",
                 },
                 approvalMode: {
                     type: "string",

package/dist/tools/sequencer.js

@@ -65,13 +65,12 @@ export const sequencerToolDefinitions = [
         name: "attach_recommended_sequence",
         description: "Attach the tier-recommended sequence template to a campaign. " +
             "Delegates template selection to the backend's existing tier-aware selector " +
-            "(selectTemplateForTiers), which picks `If Open Profile -> INMAIL_OPEN, else INVITE` " +
-            "for Sales Nav/Recruiter senders and `INVITE -> accepted -> DM` for Basic, Premium, or mixed sender sets. " +
-            "Paid InMail Campaign is not auto-selected because it can spend InMail credits; " +
-            "use attach_sequence with an explicit paid-InMail template only after the user opts in. " +
+            "(selectTemplateForTiers), which picks the unified Sales Nav cascade for Sales Nav/Recruiter senders: " +
+            "Open Profile check -> Open InMail, otherwise fresh paid credits >= 5 -> paid InMail, otherwise same-campaign connection request -> accepted wait -> DM. " +
+            "Basic, Premium, or mixed sender sets still get `INVITE -> accepted -> DM`. " +
+            "This is the default Sales Nav product path; use attach_sequence directly only when the caller needs a custom non-recommended cadence. " +
             "Prefer this over attach_sequence during the create-campaign-v2 autonomous tail — " +
-            "it removes the risk of hand-authoring an invalid template mid-long-context. " +
-            "Use attach_sequence directly only when the caller needs a custom non-recommended cadence.",
+            "it removes the risk of hand-authoring an invalid template mid-long-context.",
         inputSchema: {
             type: "object",
             properties: {

package/package.json

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

package/skills/create-campaign-v2/references/final-handoff-contract.md

@@ -58,10 +58,12 @@ currentStep: "sequence" })` to attach the sender via the v3 senders route and
    move the watched app to Sequence.
 8. Call `attach_recommended_sequence({ campaignId, currentStep: "send" })` to
    bind the tier-aware recommended sequence. Explain the sequence choice in the
-   handoff: Sales Nav/Recruiter senders get the Sales Nav Open Profile
-   strategy, Basic/Premium/mixed senders get the Premium invite-to-DM strategy,
-   and Paid InMail Campaign is only an explicit paid-InMail opt-in because it
-   can spend InMail credits. If that response does not persist `currentStep:
+   handoff: Sales Nav/Recruiter senders get the unified Sales Nav cascade
+   (Open Profile -> Open InMail, otherwise fresh paid credits >= 5 -> paid
+   InMail, otherwise connection request -> accepted wait -> DM), while
+   Basic/Premium/mixed senders get the Premium invite-to-DM strategy. The manual
+   Paid InMail Campaign remains an explicit custom template, not the normal
+   recommended path. If that response does not persist `currentStep:
 "send"`, call `update_campaign({ campaignId, currentStep: "send" })`.
    Then reread `get_campaign({ campaignId })` and `list_tables()` and verify the
    current `workflowTableId` has `hasSequence:true`. A campaign-level
@@ -69,9 +71,9 @@ currentStep: "sequence" })` to attach the sender via the v3 senders route and
    copy step has moved the campaign to a new current campaign table while an old
    stale shell table still owns the sequence columns. In that stale-shell case,
    either repair only the current workflowTableId with `attach_sequence` using
-   the same non-paid product template the recommended selector would have chosen,
-   or stop and report the stale-shell sequence blocker if replacement was not
-   explicitly approved. Never choose a paid-InMail template for this repair.
+   the same product template the recommended selector would have chosen, or stop
+   and report the stale-shell sequence blocker if replacement was not explicitly
+   approved. Do not substitute the manual Paid InMail Campaign for this repair.
 9. Surface the `handoff.orientation` string from `auto-execute.yaml` and
    summarize the visible Settings/Sequence/Send state without repeating the
    watch URL.

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

@@ -86,9 +86,9 @@ only when the caller explicitly needs a custom non-recommended cadence, or when
 you have just reread the campaign after `confirm_lead_list` and proved the
 current campaign table has no sequence while an older stale shell table is
 causing campaign-level `SEQUENCE_EXISTS`. In that stale-shell repair case, use
-`attach_sequence` on the current workflowTableId with the same non-paid product
-template the backend would select; never choose a paid-InMail template and never
-repair a table other than the current workflowTableId.
+`attach_sequence` on the current workflowTableId with the same product template
+the backend would select; do not substitute the manual Paid InMail Campaign and
+never repair a table other than the current workflowTableId.
 
 Hard gates — if you find yourself about to violate any of these, stop
 first:
@@ -533,10 +533,12 @@ Shape:
    route and describe the Sequence view.
 8. Call `attach_recommended_sequence({ campaignId, currentStep: "send" })`
    (bind the tier-recommended sequence to the campaign). Explain the sequence
-   choice plainly: Sales Nav/Recruiter senders get the Sales Nav Open Profile
-   strategy, Basic/Premium/mixed senders get the Premium invite-to-DM strategy,
-   and Paid InMail Campaign is available only as an explicit paid-InMail
-   opt-in because it can spend InMail credits. If the tool response
+   choice plainly: Sales Nav/Recruiter senders get the unified Sales Nav
+   cascade (Open Profile -> Open InMail, otherwise fresh paid credits >= 5 ->
+   paid InMail, otherwise connection request -> accepted wait -> DM), while
+   Basic/Premium/mixed senders get the Premium invite-to-DM strategy. The manual
+   Paid InMail Campaign remains an explicit custom template, not the normal
+   recommended path. If the tool response
    does not persist `currentStep: "send"`, call
    `update_campaign({ campaignId, currentStep: "send" })`.
    Then reread `get_campaign({ campaignId })` and `list_tables()` and verify the
@@ -544,9 +546,10 @@ Shape:
    `attach_recommended_sequence` returned `SEQUENCE_EXISTS` but the current table
    still has `hasSequence:false`, do not continue to launch handoff from that
    stale shell proof. Repair only the current workflowTableId with
-   `attach_sequence` using the same non-paid product template the recommended
-   selector would have chosen, or stop and report the stale-shell sequence
-   blocker if replacement was not explicitly approved.
+   `attach_sequence` using the same product template the recommended selector
+   would have chosen, or stop and report the stale-shell sequence blocker if
+   replacement was not explicitly approved. Do not substitute the manual Paid
+   InMail Campaign for this repair.
 9. Surface the `handoff.orientation` string from `auto-execute.yaml` without
    repeating the watch URL.
 10. Ask the final launch greenlight with the structured question function:

package/skills/create-evergreen-campaigns/SKILL.md

@@ -1515,7 +1515,11 @@ Message, and verify current-revision sample messages before final completion.
      - DM lanes: add a `Delivery format:` line — either `multiline (each paragraph sends as its own DM message)` or `single message`. When multiline, the template's blank-line paragraphs ARE the message boundaries — write each one as a standalone typed message.
      - **InMail lanes can never be multiline**: an InMail is one message and the recipient must reply before anything else can be sent. InMail-bound templates must read as one cohesive message — declare `Delivery format: single message (InMail — no follow-up until reply)` and never structure the copy to depend on multi-message pacing.
 
-   - The sequence is auto-selected by sender tier; do not hand-author sequence templates here. Never select a paid-InMail template.
+   - The sequence is auto-selected by sender tier; do not hand-author sequence
+     templates here. Sales Nav/Recruiter senders may receive the unified Sales
+     Nav cascade through `attach_recommended_sequence`; attaching it does not
+     spend paid InMail credits by itself. Do not substitute the manual Paid
+     InMail Campaign template.
 3. **Customer-Visible Completion Contract**: a named evergreen lane that appears
    as a campaign card or campaign-backed table is not done when the shell exists.
    It is done only when the customer can open the campaign and land on final
@@ -1592,7 +1596,7 @@ Message, and verify current-revision sample messages before final completion.
      completion, approve exactly one quality-valid generated row. If one or more
      rows are already approved, do not add more approvals during evergreen
      completion. Never broad approve all rows.
-    - The recommended non-paid sequence is attached to the current campaign
+    - The recommended tier-aware sequence is attached to the current campaign
       table, and the watched campaign is on Send. Use
       `attach_recommended_sequence({ campaignId, currentStep:"send" })` when a
       safe attach is needed. After `confirm_lead_list` or any source-list copy,
@@ -1602,10 +1606,11 @@ Message, and verify current-revision sample messages before final completion.
      before reporting completion. If a stale shell table has sequence columns but
      the current campaign table does not, `SEQUENCE_EXISTS` is not enough:
      record the stale shell table id, then repair the current workflowTableId
-     with `attach_sequence` using the same non-paid product template
-      `attach_recommended_sequence` would have selected. Never use a paid-InMail
-      template and never attach/replace sequence outside the current table unless
-      the current lane packet explicitly allowed sequence repair.
+     with `attach_sequence` using the same product template
+      `attach_recommended_sequence` would have selected. Do not substitute the
+      manual Paid InMail Campaign, and never attach/replace sequence outside the
+      current table unless the current lane packet explicitly allowed sequence
+      repair.
     - If the current campaign table is still `DRAFT` after sequence/readiness
       proof, call `pause_campaign({ campaignId })` and reread. `pause_campaign`
       is the product-native review-state transition; it is not a launch and does

package/skills/refill-sends/SKILL.md

@@ -131,18 +131,21 @@ eligible senders, selected sender-local days, gross target, actual sent
 coverage, scheduler-owned scheduled coverage across active enrolled campaigns,
 projected coverage (`sent + scheduled`), inferred per-sender send lane/action
 selections, ready buffer, remaining projected gap, paid-InMail credit/threshold
-feasibility, `targetShapeRevision`, and `stateRevision`. Refill target lanes
-are only connection invites (`send_invite`) or paid InMails
-(`send_inmail_closed`), chosen per sender from the most recent current
-dashboard-active campaign-backed send evidence. DMs (`send_dm`) and
-open-profile InMails (`send_inmail_open`) may exist in sequences, but they are
-not refill horizon target capacity and must not be counted as refill sent,
-scheduled, or ready coverage. When `actionTypes` are omitted, trust the target
-plan's inferred connection-or-paid-InMail lane rather than asking which of those
-two lanes to fill. If a stale target plan selects `send_dm` or
-`send_inmail_open`, stop and re-plan with the current planner before mutation.
-Short form: trust the target plan's inferred lane only when it is a
-connection-invite or paid-InMail refill lane.
+feasibility, `targetShapeRevision`, and `stateRevision`. Refill target lanes are
+connection invites (`send_invite`), standalone paid InMails
+(`send_inmail_closed`), or unified Sales Nav cascades represented publicly as
+`send_inmail_closed` with `campaignClassification:"sales_nav_cascade"`. For a
+Sales Nav cascade, refill the selected campaign first; its sequence can route
+prospects to Open InMail, paid InMail while fresh credits are >= 5, or
+same-campaign connection fallback without asking for separate open/paid/
+connection campaigns. DMs (`send_dm`) are follow-up actions, not refill horizon
+target capacity, and must not be counted as refill sent, scheduled, or ready
+coverage. When `actionTypes` are omitted, trust the target plan's inferred lane
+rather than asking which campaign class to fill. If a stale target plan selects
+`send_dm` or `send_inmail_open` as the lane, stop and re-plan with the current
+planner before mutation.
+Short form: trust the target plan's inferred lane when it is a connection invite,
+paid-InMail refill lane, or unified Sales Nav cascade.
 
 Structured planner packet:
 
@@ -168,7 +171,8 @@ facts, it refreshes each selected sender at most once, reruns
 `get_refill_target_plan`, and returns the post-refresh `targetPlan` before
 choosing the next prep/approval/start action. If fresh facts are still below
 threshold, below-threshold paid-InMail facts fall back to an existing connection
-lane or a manual continuation.
+lane, the same Sales Nav cascade campaign's connection branch, or a manual
+continuation.
 
 Compact refill lessons: sender-level target plan is final truth; trust
 `schedulerGate.sendable` and scheduler gate blockers, not raw
@@ -201,8 +205,8 @@ post-refresh `targetPlan`. Trust `refill_sends.autoPaidInmailRefresh`: it should
 show the exact sender ids refreshed once, sender-credit-cache write receipts,
 and a returned post-refresh `targetPlan`. Continue from that post-refresh packet.
 If paid InMail is below threshold after the fresh credit read, report the exact
-campaign/table/column threshold action or connection fallback; `--yolo` does not
-lower paid-InMail thresholds or create campaigns.
+campaign/table/column threshold action or same-campaign connection fallback;
+`--yolo` does not lower paid-InMail thresholds or create campaigns.
 
 If the plain route's managed waterfall targets are stale, for example skipped
 targets show archived/completed shared slots or the returned targets do not cover

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

@@ -75,20 +75,23 @@ in-progress wait state, not a reason to mark the goal complete or blocked.
    campaigns, projected coverage (`sent + scheduled`), ready buffer, remaining
    projected gap, paid-InMail credit/threshold feasibility, bounded action
    candidates, `targetShapeRevision`, and `stateRevision`.
-   Refill target lanes are binary per sender: connection invites
-   (`send_invite`) or paid InMails (`send_inmail_closed`). DMs
-   (`send_dm`) and open-profile InMails (`send_inmail_open`) can remain in the
-   sequence, but they are follow-up actions, not refill horizon capacity. Do not
-   count their sent, scheduled, or ready cells when deciding whether a sender
-   needs refill. When `actionTypes` are omitted, trust the target plan's
-   inferred connection-or-paid-InMail lane; do not ask the operator which of
-   those two lanes to fill after the plan has inferred that from active
-   campaign future scheduled, recent scheduled, and ready evidence. If a stale
-   planner/tool response selects `send_dm` or `send_inmail_open`, treat that as
-   unsupported stale refill state and re-plan with a current planner before any
-   mutation.
-   Short form: trust the target plan's inferred lane only when it is a
-   connection-invite or paid-InMail refill lane.
+   Refill target lanes are connection invites (`send_invite`), standalone paid
+   InMails (`send_inmail_closed`), or unified Sales Nav cascades represented
+   publicly as `send_inmail_closed` with
+   `campaignClassification:"sales_nav_cascade"`. For a Sales Nav cascade, fill
+   the selected campaign first; its sequence can route prospects to Open InMail,
+   paid InMail while fresh credits are >= 5, or same-campaign connection
+   fallback without asking for separate open/paid/connection campaigns. DMs
+   (`send_dm`) are follow-up actions, not refill horizon capacity. Do not count
+   their sent, scheduled, or ready cells when deciding whether a sender needs
+   refill. When `actionTypes` are omitted, trust the target plan's inferred lane;
+   do not ask the operator which campaign class to fill after the plan has
+   inferred that from active campaign future scheduled, recent scheduled, and
+   ready evidence. If a stale planner/tool response selects `send_dm` or
+   `send_inmail_open`, treat that as unsupported stale refill state and re-plan
+   with a current planner before any mutation.
+   Short form: trust the target plan's inferred lane when it is a connection
+   invite, paid-InMail refill lane, or unified Sales Nav cascade.
    Structured planner packet:
    - `target.eligibleSenderLedger` is the public sender eligibility ledger.
    - `target.senderRefillPlans[]` is the canonical sender-level packet; read and
@@ -112,7 +115,8 @@ in-progress wait state, not a reason to mark the goal complete or blocked.
    `get_refill_target_plan`, and returns the post-refresh `targetPlan` before
    choosing the next prep/approval/start action. If fresh facts are still below
    threshold, below-threshold paid-InMail facts fall back to an existing
-   connection lane or a manual continuation.
+   connection lane, the same Sales Nav cascade campaign's connection branch, or
+   a manual continuation.
    Compact refill lessons: sender-level target plan is final truth; trust
    `schedulerGate.sendable` and scheduler gate blockers, not raw
    `unipileAccountStatus` labels alone; use compact prep status checks for
@@ -147,7 +151,7 @@ in-progress wait state, not a reason to mark the goal complete or blocked.
    should show the exact sender ids refreshed once, sender-credit-cache write
    receipts, and a returned post-refresh `targetPlan`. Continue from that
    post-refresh packet. If paid InMail is below threshold after the fresh credit read, report
-   the exact campaign/table/column threshold action or
+   the exact campaign/table/column threshold action or same-campaign
    connection fallback; `--yolo` does not lower paid-InMail thresholds or create campaigns.
 2. Call `resolve_campaign_fill_route`. Use `intent:"plain"` for generic
    fill/load language, `intent:"active"` only when the user explicitly narrowed
@@ -282,10 +286,13 @@ dashboard-active campaign-backed sequence evidence:
 
 1. Prefer the sender's most recent future scheduled refill action, then the most
    recent recent scheduled refill action, then ready refill rows.
-2. Refill actions are only `send_invite` and `send_inmail_closed`.
-3. If the most recent active campaign evidence is DM or open InMail, ignore it
-   for refill lane selection and use the nearest connection-invite or paid-InMail
-   evidence instead.
+2. Refill actions are `send_invite` or `send_inmail_closed`; unified Sales Nav
+   cascades also appear as `send_inmail_closed` with
+   `campaignClassification:"sales_nav_cascade"`.
+3. If the most recent active campaign evidence is DM, ignore it for refill lane
+   selection. If open InMail evidence belongs to a unified Sales Nav cascade,
+   keep the cascade campaign as the selected `send_inmail_closed` target; do not
+   create side open/paid/connection campaigns.
 4. If no connection/paid-InMail evidence exists, fall back to the selected
    active campaign sequence, still choosing only one of `send_invite` or
    `send_inmail_closed` for that sender.
@@ -418,8 +425,15 @@ search_signals({ campaignOfferId, currentStep:"signal-discovery", confirmed:true
 ```
 
 Use `select_promising_posts` before importing. For a fresh source refill, prefer
-`selectionMode:"replace"` and `scrapePlanMode:"capacity-target"` with the
-approved `targetEngagerCount` and `maxPostsToScrape`. If the approved post set cannot cover the target, do not knowingly run an under-capacity scrape; ask for approval to expand the selected post set or switch source.
+`selectionMode:"replace"` and `scrapePlanMode:"all-selected"`, then call
+`import_leads` without `targetEngagerCount` or `maxPostsToScrape` so the scrape
+uses the selected posts' max available engagers within backend provider caps.
+Do not invent, lower, or pass a people-to-check target for refill imports unless
+Christian explicitly supplied that target or post cap in the current request or
+approval packet. If Christian did supply an explicit `targetEngagerCount` or
+`maxPostsToScrape`, use `scrapePlanMode:"capacity-target"` and respect the
+under-capacity refusal: ask for approval to expand the selected post set or
+switch source instead of scraping a target-mismatched set.
 
 If `import_leads` returns `reusedExistingSourceList` but the user explicitly
 approved a different selected-post scrape, retry `import_leads` with the existing `sourceLeadListId` from that response or from refill state. For Signal

package/skills/workflow-sequences/SKILL.md

@@ -77,7 +77,7 @@ This is the canonical MCP workflow for creating sequencer tables. Prefer this ov
   - `INVITE` only
   - `INVITE -> accepted -> DM`
   - `COMMENT` only
-  - `If Open Profile -> INMAIL_OPEN, else INVITE`
+  - Sales Nav unified cascade: Open Profile -> Open InMail, otherwise paid-credit check -> Paid InMail or connection fallback
 
 ## Output