@sellable/mcp 0.1.144 → 0.1.146

package/dist/tools/registry.js

@@ -0,0 +1,59 @@
+import { authToolDefinitions } from "./auth.js";
+import { blueprintCommitToolDefinitions } from "./blueprint-commit.js";
+import { bootstrapToolDefinitions } from "./bootstrap.js";
+import { campaignToolDefinitions } from "./campaigns.js";
+import { cellToolDefinitions } from "./cells.js";
+import { startCliLoginToolDef, waitForCliLoginToolDef } from "./cli-login.js";
+import { contextToolDefinitions } from "./context.js";
+import { directCampaignToolDefinitions } from "./direct-campaigns.js";
+import { engageBootstrapToolDefinitions } from "./engage-bootstrap.js";
+import { engageDiscoveryToolDefinitions } from "./engage-discovery.js";
+import { engageMemoryToolDefinitions } from "./engage-memory.js";
+import { engageStateToolDefinitions } from "./engage-state.js";
+import { enrichmentToolDefinitions } from "./enrichment.js";
+import { frameworkToolDefinitions } from "./framework.js";
+import { leadToolDefinitions } from "./leads.js";
+import { linkedinToolDefinitions } from "./linkedin.js";
+import { navigationToolDefinitions } from "./navigation.js";
+import { onDemandToolDefinitions } from "./one-off.js";
+import { processingToolDefinitions } from "./processing.js";
+import { promptToolDefinitions } from "./prompts.js";
+import { readinessToolDefinitions } from "./readiness.js";
+import { rowToolDefinitions } from "./rows.js";
+import { rubricToolDefinitions } from "./rubrics.js";
+import { senderToolDefinitions } from "./senders.js";
+import { sequencerToolDefinitions } from "./sequencer.js";
+import { tableToolDefinitions } from "./tables.js";
+import { verifyRowToolDefinitions } from "./verify-row.js";
+import { workspaceToolDefinitions } from "./workspaces.js";
+export const allTools = [
+    ...campaignToolDefinitions,
+    ...authToolDefinitions,
+    startCliLoginToolDef,
+    waitForCliLoginToolDef,
+    ...bootstrapToolDefinitions,
+    ...engageBootstrapToolDefinitions,
+    ...engageDiscoveryToolDefinitions,
+    ...workspaceToolDefinitions,
+    ...frameworkToolDefinitions,
+    ...contextToolDefinitions,
+    ...navigationToolDefinitions,
+    ...leadToolDefinitions,
+    ...enrichmentToolDefinitions,
+    ...processingToolDefinitions,
+    ...rubricToolDefinitions,
+    ...readinessToolDefinitions,
+    ...rowToolDefinitions,
+    ...cellToolDefinitions,
+    ...promptToolDefinitions,
+    ...linkedinToolDefinitions,
+    ...onDemandToolDefinitions,
+    ...directCampaignToolDefinitions,
+    ...senderToolDefinitions,
+    ...engageStateToolDefinitions,
+    ...engageMemoryToolDefinitions,
+    ...sequencerToolDefinitions,
+    ...tableToolDefinitions,
+    ...blueprintCommitToolDefinitions,
+    ...verifyRowToolDefinitions,
+];

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -152,13 +152,14 @@ For Signal Discovery, the customer-facing approval card must use the exact
 action shape "Approve scraping N Signal Discovery posts?" and the chat summary
 should be a compact `## Source Recommendation` block with:
 
-- goal: about 300 good-fit prospects after cleanup, enrichment, and filters
-- working assumption: about 15% of raw post engagers become good-fit prospects
-- engagers needed: about 2,000 raw engagers
+- 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
+- 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 15 leads into the review
+- 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
@@ -251,7 +252,7 @@ After every `update_campaign({ campaignId, currentStep })`, use
 `get_campaign_navigation_state` when available as a compact orientation check:
 match the saved campaign state to the expected watch-link step, explain the
 current state in one sentence, and only then continue. Sender selection belongs
-at Settings after message approval and 15-row validation. After message
+at Settings after message approval and review-batch validation. After message
 validation, use Settings to help the user connect or select a LinkedIn sender.
 Explain Slack reply review before launch. After sender selection, attach the
 recommended sequence and move the watched UI to Send. Do not start the campaign
@@ -614,9 +615,9 @@ updates.
    until `hasMore=false`. The create-campaign message-review safety gate is a
    supplemental approval checklist, not a replacement for the long prompt. Use
    campaign state, campaign brief content, selected source state, and imported
-   review-batch rows as the source of truth; do not read stale local markdown,
-   inspect the database directly, or synthesize local validation artifacts from
-   general knowledge.
+   review-batch rows as the source of truth; do not read stale local markdown
+   such as `message-validation.md`, inspect the database directly, or synthesize
+   local validation artifacts from general knowledge.
 5. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Import only the first
    bounded review batch after the source is attached to the campaign; do not
@@ -640,7 +641,7 @@ updates.
    `mcp__sellable__update_campaign({ campaignId, currentStep })` before major
    visible work so the user can watch progress in the app: `create-offer` for
    the brief, `pick-provider` or the selected provider step while sourcing,
-   `filter-choice` after the 15-row review batch, `create-icp-rubric` as soon
+   `filter-choice` after the review batch, `create-icp-rubric` as soon
    as filters are approved, `apply-icp-rubric` after rubrics save and while
    waiting for message-template approval, `validate-sample` while the approved
    template unlocks bounded enrichment/filter scoring on Filter Leads,

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

@@ -158,6 +158,12 @@ approval label must describe the action with the count, such as "Approve
 scraping 3 Signal Discovery posts?" For Sales Nav or Prospeo, the label should
 name the specific search/import lane. Do not call `import_leads` or
 `confirm_lead_list` until this second source-action approval is granted.
+After the user approves this concrete source-action gate, do not show the
+Source Recommendation again and do not ask another source approval question.
+Acknowledge once, then call `import_leads` immediately with the approved source
+math. For Signal Discovery, pass `provider: "signal-discovery"`,
+`targetEngagerCount`, `maxPostsToScrape`, and `confirmed: true`; the tool owns
+moving the watch UI to source-list progress after a lead-list/job id exists.
 
 For Signal Discovery, use this compact source-action approval shape after
 selected posts exist:
@@ -167,9 +173,9 @@ selected posts exist:
 
 Use Signal Discovery first.
 
-**Goal:** ~300 good-fit prospects after cleanup, enrichment, and filters<br>
-**Working assumption:** ~15% of raw post engagers become good-fit prospects<br>
-**Engagers needed:** ~2,000 raw engagers
+**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>
+**Review checkpoint:** import the first 25 leads into the campaign for fit and message review before scaling<br>
 
 ### Selected posts
 
@@ -186,12 +192,12 @@ Use Signal Discovery first.
 
 Approve scraping these 3 posts.
 
-This gives enough volume to target ~300 good-fit prospects after cleanup, while
+This gives enough volume to work toward ~150 good-fit prospects, while
 keeping the source tied to people already engaging with Claude Code outbound /
 AI-native sales workflows.
 
-**First pass:** build the source list, then import only 15 leads into the
-review batch so we can inspect quality before scaling.
+**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.

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

@@ -238,11 +238,15 @@ 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 ~300 good-fit prospect goal, 15% raw-engager assumption, selected-post
-table, total visible pool, estimated good-fit pool, first-pass 15-row review
+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?"
 
+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
+one sentence and call `import_leads` for the approved source immediately.
+
 ## Parallelism + Naming
 
 Source selection is sequential by default. Start with the first recommended

package/skills/create-campaign-v2/core/auto-execute.README.md

@@ -33,16 +33,16 @@ the imported review batch for validation).
 
 - **`sampleSize`** — How many rows the validation loop pulls from the
   imported review batch. In v2 this matches the review-batch cap
-  (default 15), so the user sees enough real rows to judge the campaign
+  (default 25), so the user sees enough real rows to judge the campaign
   without spending credits on hundreds more.
 - **`minProjectedPass`** — Passing-message floor required before handoff.
-  The default requires 3 passing examples from the 15-row review batch.
+  The default requires 5 passing examples from the 25-row review batch.
   Math:
   ```text
   projectedPass = round(passInSample / sampleSize * importLimit)
   ```
-  With defaults (sampleSize=15, importLimit=15), `projectedPass` equals
-  the actual review-batch pass count. 3 passing rows is exactly at the
+  With defaults (sampleSize=25, importLimit=25), `projectedPass` equals
+  the actual review-batch pass count. 5 passing rows is exactly at the
   floor.
 - **`maxRevisionRounds`** — Hard cap before escalating to the user. A
   revision round is one full sample pass that triggered brief revision

package/skills/create-campaign-v2/core/auto-execute.yaml

@@ -17,7 +17,7 @@ import:
   # Initial review batch imported in Step 13 before the sample validation
   # loop. Import + enrichment must never exceed this cap before the user
   # reviews the sample and explicitly asks to expand.
-  importLimit: 15
+  importLimit: 25
   # Provider is inherited from the campaign-attached source association created
   # during find-leads. Step 13 may re-run provider preflight in memory, but it
   # does not choose a new source.
@@ -27,11 +27,11 @@ sample:
   # Rows pulled from the imported cohort for the validation loop. In v2 this
   # equals the review-batch cap so the user sees a focused first test batch
   # without spending credits on hundreds of rows.
-  sampleSize: 15
+  sampleSize: 25
   # Projected first-batch passing count required to proceed to sample
   # messaging. This is not approval to scale the full source list.
   # projectedPass = round(passInSample / sampleSize * importLimit).
-  minProjectedPass: 3
+  minProjectedPass: 5
   # Hard cap on revision loops before escalating to the user. On a stale
   # resume the counter does NOT reset — the 3-round cap holds across
   # sessions.
@@ -106,7 +106,7 @@ handoff:
   # Orientation surfaced in Step 16 ("awaiting-user-greenlight") along with
   # the watch link. Keep this short and user-facing.
   orientation: >-
-    Review the first 15 enriched leads and messages. If they look good,
+    Review the first 25 enriched leads and messages. If they look good,
     attach a sender in Settings, accept the recommended sequence, and start
     the campaign without spending credits on more leads first.
 

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

@@ -460,7 +460,7 @@
           "requiredInlineFields": [
             "primary source and exact filters/recipe",
             "specific source action awaiting approval",
-            "for Signal Discovery: Source Recommendation markdown with goal ~300 good-fit prospects, ~15% raw-engager fit assumption, ~2,000 raw engagers needed, selected-post table, total visible pool, estimated good-fit pool, first pass, and fallback",
+            "for Signal Discovery: Source Recommendation markdown with ~150 good-fit prospects as the target, source-candidate plan ~1,000 raw engagers at a conservative ~15% fit assumption, review checkpoint size, selected-post table, total visible pool, estimated good-fit pool, first pass, and fallback",
             "for Signal Discovery: selected post count and target engager/source-candidate volume",
             "bounded review batch size",
             "runner-up and why it lost",
@@ -485,6 +485,16 @@
             "signal-discovery": "Approve scraping {selectedPostCount} Signal Discovery posts?",
             "sales-nav": "Import the approved Sales Nav review batch",
             "prospeo": "Import the approved Prospeo review batch"
+          },
+          "postApprovalContract": {
+            "singleUseApproval": true,
+            "doNotRepeatAfterApproval": [
+              "Source Recommendation",
+              "show_source_decision_card",
+              "ask_source_review_choice"
+            ],
+            "requiredNextActionAfterApproval": "acknowledge in one sentence, then call import_leads immediately",
+            "signalDiscoveryNextTool": "import_leads({ campaignOfferId, provider: \"signal-discovery\", targetEngagerCount, maxPostsToScrape, confirmed: true })"
           }
         }
       ],
@@ -541,7 +551,7 @@
             "importLimit"
           ],
           "requiredValues": {
-            "importLimit": 15
+            "importLimit": 25
           },
           "modeAddHandshake": {
             "firstCallReturns": "needsModeSelection when adding to an existing campaign-attached list",
@@ -925,12 +935,24 @@
             "messageDraftRecommendation"
           ],
           "requiredVisibleLabels": [
-            "Subject:",
-            "Sample prospect fill:",
+            "## Message Template",
+            "## Rendered Example",
+            "Good token fill:",
             "My take:",
-            "Concern:",
             "Question: approve-message or revise-messaging?",
             "Recommendation:"
+          ],
+          "doNotShowByDefault": [
+            "Token Notes",
+            "Good omit / fallback",
+            "Bad fill to avoid",
+            "Token Adherence Table"
+          ],
+          "internalPersistenceOnly": [
+            "Token Fill Rules",
+            "Token Fill Examples",
+            "fallback guidance",
+            "bad-fill avoidance notes"
           ]
         },
         {

package/skills/create-campaign-v2/references/approval-gate-framing.md

@@ -15,7 +15,7 @@ packet.
 
 The approval gate used to be the place where the user authorized
 spend/send-adjacent mutation. It is now compatibility-only. New runs import the
-bounded 15-row review batch after source approval, save rubrics and the approved
+bounded review batch after source approval, save rubrics and the approved
 message template after post-import review, and only then queue the cascade.
 
 If `campaign-shell.json` exists, a draft `CampaignOffer` row already exists but

package/skills/create-campaign-v2/references/filter-leads.md

@@ -174,6 +174,14 @@ If more than roughly 20% of the review batch appears to be the forbidden side,
 classify it as a list/source problem and return `revise-find-leads`; do not
 hide that problem behind narrow rubrics.
 
+## Suppression And Relationship Safety
+
+Do not put DNC or one-off relationship-safety notes into production rubrics
+unless the review batch shows that the pattern will leak at meaningful volume
+and normal DNC/domain suppression will not catch it. Former employers, existing
+customers, investors, partner lists, and one-off do-not-contact domains usually
+belong in the recommendation as DNC/suppression instructions outside the rubric JSON.
+
 ## Production Rubric Shape
 
 Confirmed rubrics must use the production `LeadScoringRubric` fields exactly:
@@ -265,6 +273,40 @@ Interpretation:
 - Density dramatically below the band: likely source contamination, ICP drift,
   or provider-side weakness; investigate before launch.
 
+## Post-Filter Signal Enrichment Pass (Sales Nav lane)
+
+Run this only for Sales Nav FIT rows when the downstream message step does not
+already have row-level post evidence. In normal campaign-backed runs, use live
+campaign-table row state as the source of truth. In explicit debug/UAT artifact
+flows, append the diagnostic copy back to `lead-sample.json`.
+
+This pass exists to protect the Earned-right and Read-as-1:1 substance filters.
+Without row-level posts, message generation is likely to fall back to generic
+category openers or presumed intent instead of evidence the recipient can
+recognize.
+
+Contract:
+
+- scope: Sales Nav FIT rows only; do not enrich MAYBE or REJECT rows for this
+  pass
+- budget cap: top 10 FIT rows by filter score
+- tool: `mcp__sellable__fetch_linkedin_posts`, called per row
+- fetch: most recent 3-5 public posts when available
+- target surface: store each result as `recent_posts[]` entries with
+  `{ url, posted_at, excerpt }`; keep `recent_posts: []` for quiet profiles
+- order of operations: run AFTER `lead-filter.md` is written, BEFORE
+  `message-validation.md` starts drafting
+
+Record enrichment outcome in the filter summary: rows attempted, rows with
+posts, rows with zero public posts, and tool failures. If more than half of the
+attempted rows have zero posts, flag low signal density and tell message
+generation to prefer trigger, peer-observation, or non-post proof instead of a
+post-quote opener.
+
+Do not convert "recently posted" or post availability into an ICP fit rubric.
+The posts are message evidence only; buyer qualification still comes from role,
+authority, account fit, capacity, geography, and exclusions.
+
 ## Decision Rules
 
 - Use `confirmed` when the source lane is viable and the rubrics are enough to

package/skills/create-campaign-v2/references/message-review-safety-gate.md

@@ -31,8 +31,11 @@ instead of pulling the long prompt into the main thread.
    local markdown/json artifacts in normal customer runs; emit debug artifacts
    only when the parent explicitly asks for debug/UAT output.
 5. Render the customer-facing message review in chat before asking for approval.
-   After approval, the parent persists template and token rules into campaign
-   state with `update_campaign_brief`.
+   Keep chat lightweight: show the tokenized template and one strong rendered
+   good-fill example only. Do not print the token notes table, omit/fallback
+   example, or bad-fill analysis in chat unless the user explicitly asks.
+   After approval, the parent persists template, token rules, fallback guidance,
+   and bad-fill avoidance notes into campaign state with `update_campaign_brief`.
 6. Ask exactly `approve-message` or `revise-messaging`. Do not import, queue,
    attach sequence, or start before `approve-message`.
 
@@ -89,10 +92,17 @@ but the [topic] thread felt close enough to send`. Otherwise omit the
 - If the message is plausible but not ready to send, set
   `Recommendation: revise-messaging`.
 
+## Internal Message Recommendation
+
+The message scout or parent safety gate should still produce complete internal
+review data: token-fill rules, one rendered omit/fallback example, and bad-fill
+avoidance notes. This data is for campaign-brief persistence and safety checks,
+not for the default chat approval packet.
+
 ## Customer-Facing Message Review
 
 Render this in chat before asking. Use Markdown structure so the approval target
-is visually scannable:
+is visually scannable and low-overhead:
 
 ````markdown
 Status: message-review
@@ -111,33 +121,11 @@ Status: message-review
 {{tokenized_message_body}}
 ```
 
-## Rendered Examples
-
-### Good token fill
-
-Use when the row has a clean, supported fill.
-
-```text
-Subject: ...
-
-Hey First,
-
-...
-```
-
-### Good omit / fallback
-
-Use when a row signal or company context is missing, weak, or awkward.
-
-```text
-Subject: ...
-
-Hey First,
+## Rendered Example
 
-...
-```
+### Example
 
-### Bad fill to avoid
+Good token fill:
 
 ```text
 Subject: ...
@@ -147,14 +135,6 @@ Hey First,
 ...
 ```
 
-**Why this is wrong:** one sentence naming the exact token-fill failure.
-
-## Token Notes
-
-| Token            | Use when                 | Fallback |
-| ---------------- | ------------------------ | -------- |
-| `{{first_name}}` | Clean first name exists. | `there`  |
-
 ## Recommendation
 
 **My take:** ...
@@ -168,15 +148,13 @@ Hey First,
 
 Formatting requirements:
 
-- Put the tokenized template and every rendered example in fenced `text` blocks
+- Put the tokenized template and rendered example in fenced `text` blocks
   so chat gives them a distinct background.
-- `Good token fill` and `Good omit / fallback` must each contain a complete
-  rendered subject + body, not a bullet list of token names or a single
-  bridge-line fragment.
-- Include `Bad fill to avoid` when the row sample has a tempting but unsafe
-  source-mechanics or raw-headline fill; otherwise include `Bad fill to avoid:
-none found`.
-- Use a token notes table, not paragraph-only token notes.
+- The chat example must contain a complete rendered subject + body, not a
+  bullet list of token names or a single bridge-line fragment.
+- Do not show `Good omit / fallback`, `Bad fill to avoid`, or `Token Notes` in
+  the default chat approval packet. Keep those in the internal recommendation
+  and persist them to the campaign brief after approval.
 - Keep reasoning outside the code blocks so the blocks are easy to inspect and
   approve.
 

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

@@ -6,7 +6,7 @@ on every revision round.
 
 ## Principle
 
-We spend a bounded review batch (default 15 rows) to prove fit before the
+We spend a bounded review batch (default 25 rows) to prove fit before the
 user spends credits on hundreds more leads. The sample loop has one job:
 answer the question "do we have enough real passing examples for the user to
 judge this campaign?" Message generation starts earlier: the first row that
@@ -23,7 +23,7 @@ auto-revise leads.
 - `CampaignOffer.currentStep === "apply-icp-rubric"` (the watched app is
   already on Filter Leads after `save_rubrics`; `validate-sample` is the
   logical loop name, not a visible route)
-- Imported review batch from Step 13 (size: `importLimit`, default 15)
+- Imported review batch from Step 13 (size: `importLimit`, default 25)
 - Config from `auto-execute.yaml`: `sample.sampleSize`,
   `sample.minProjectedPass`, `sample.maxRevisionRounds`
 - Persisted counter `revisionRound` (starts at 0 on first entry; persists
@@ -56,7 +56,7 @@ auto-revise leads.
 6. wait_for_rubric_results(sample, targetCount = <cohortSize>, minPassedCount = 1)
    - cohortSize = stats.totalRows of the enrichment batch, or the
      imported batch count
-   - default targetCount=15 matches the default review batch, but pass the
+   - default targetCount=25 matches the default review batch, but pass the
      explicit batch count anyway so future larger expansion batches do not
      accidentally stop early
      (see §Known Tool Behaviors #3)
@@ -172,8 +172,8 @@ company, enrichCellId, enrichStatus) over the default shape.
 
 ### 5. `wait_for_rubric_results` can timeout with enough signal to decide
 
-Observed: a 15-row review batch may return `ready=false`, `reason="timeout"`,
-and partial stats such as 13/15 scored, 2 passing, 2 messages generated. That is
+Observed: a 25-row review batch may return `ready=false`, `reason="timeout"`,
+and partial stats such as 20/25 scored, 4 passing, 4 messages generated. That is
 enough to diagnose an underperforming sample. Waiting again without active
 processing makes the experience feel frozen.
 
@@ -190,16 +190,16 @@ once only if active processing is still visible.
 projectedPass = round(passInSample / sampleSize * importLimit)
 ```
 
-Worked examples with defaults (sampleSize=15, importLimit=15):
+Worked examples with defaults (sampleSize=25, importLimit=25):
 
-| passInSample | projectedPass | Handoff? (minProjectedPass=3) |
+| passInSample | projectedPass | Handoff? (minProjectedPass=5) |
 | ------------ | ------------- | ----------------------------- |
 | 0            | 0             | No — escalate or revise       |
-| 2            | 2             | No — escalate or revise       |
-| 3            | 3             | Yes — exactly at floor        |
-| 4            | 4             | Yes                           |
+| 3            | 3             | No — escalate or revise       |
+| 5            | 5             | Yes — exactly at floor        |
+| 8            | 8             | Yes                           |
 | 10           | 10            | Yes                           |
-| 15           | 15            | Yes                           |
+| 25           | 25            | Yes                           |
 
 When non-default importLimit/sampleSize are configured, the math scales
 the same way. In the default review-batch mode, the sample size equals the
@@ -263,8 +263,8 @@ rate is zero with no pattern that brief editing could fix.
 
 Signal examples:
 
-- 15/15 rows are wrong function / wrong seniority / wrong geo.
-- 12/15 rows enrich to empty strings for the tokens the brief needs.
+- 25/25 rows are wrong function / wrong seniority / wrong geo.
+- 20/25 rows enrich to empty strings for the tokens the brief needs.
 - Rubric passes 0 rows and the failure reasons are all "not ICP."
 - **Marketplace supply-side contamination:** >20% of sample rows match
   the brief §14 forbidden side (e.g. Skillsync sample contains

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

@@ -55,9 +55,9 @@ Supported branches:
   `import_leads({ campaignOfferId })` for Signal Discovery unless selected posts
   already exist on the campaign. Provider import materializes the source lead
   list from the approved source-capacity plan; it is not the same target as the
-  15-row campaign review batch.
+  default 25-row campaign review batch.
 - **Supplied LinkedIn profile CSV** — confirm `load_csv_linkedin_leads` only
-  after rubrics and the approved message set are ready. Batch/materialize the
+  after the user approves that supplied-list source. Batch/materialize the
   uploaded CSV into a Sellable lead-list table. Persist the returned
   `leadListId`, then import the bounded review batch into the campaign table
   with
@@ -106,9 +106,9 @@ fills the source lead list; it does **not** clone rows into the campaign table:
 ```text
 import_leads({
   campaignOfferId,
-  targetLeadCount: <sourceTargetGoodFitLeads; default 300>,
+  targetLeadCount: <sourceCandidateTarget; provider default>,
   // Signal Discovery only:
-  targetEngagerCount: <ceil(sourceTargetGoodFitLeads / sampledFitRateAfterCleanup)>,
+  targetEngagerCount: <ceil(targetGoodFitLeads / sampledFitRateAfterCleanup)>,
   maxPostsToScrape: <postsNeeded from approved math>
 })
 ```
@@ -120,9 +120,12 @@ so dedup ratios are visible.
 
 For Signal Discovery, do not scrape every currently selected/promoted sample
 post by default. Before `import_leads`, reconcile selected posts with the
-approved source math. If the math says 20 good fits per 100 engagers and the
-source target is 300 good-fit leads, pass `targetEngagerCount` around 1,500 and
-only enough posts to reach that engager count. The subsequent
+approved source math. The default good-fit target is 150 and the conservative
+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
 `confirm_lead_list` call still uses `targetLeadCount: <importLimit>` so only the
 bounded review batch enters the campaign table.
 
@@ -216,8 +219,10 @@ cannot scale further without a new source lane.
 - Zero-imported + zero-skipped ⇒ hard-fail escalate.
 - Zero-imported + high-skipped ⇒ lane-exhausted operator notice (NOT a
   silent proceed).
-- `import_leads` is NOT called before rubrics are saved and the approved message
-  set is synced into the campaign brief.
+- `import_leads` is allowed immediately after the concrete source-action
+  approval. It materializes the source list and then `confirm_lead_list` imports
+  only the bounded review batch. Enrichment, fit scoring, and message cells wait
+  for saved rubrics plus the approved message set.
 - Step 13 MUST reuse an approved source already attached with `campaignOfferId`
   before `import_leads`; it does not replay provider searches.
 - `import_leads` is NOT called again in Step 14 (validate-sample). Full

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

@@ -178,8 +178,8 @@ Source approved and import starting:
 {
   "stage": "review-batch",
   "headline": "Importing the review batch",
-  "visibleState": "The browser is still showing the approved LinkedIn Engagement source leads.",
-  "agentIntent": "Codex is importing only the bounded 15-row review batch into the campaign now.",
+  "visibleState": "The browser is still showing the approved LinkedIn Engagement source candidates.",
+  "agentIntent": "Codex is importing only the bounded review batch into the campaign now.",
   "nextAction": "Review batch ready"
 }
 ```