@sellable/mcp 0.1.151 → 0.1.153

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

@@ -6,24 +6,27 @@ on every revision round.
 
 ## Principle
 
-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:
+We spend a bounded review/process sample (default 15 rows) to prove fit before
+the user spends credits on the rest of the confirmed source list. 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
 passes filters is enough to begin observing or queueing Generate Message for
 that passing row.
 
-If the answer is yes, proceed to Step 15 messaging for the review batch. If
+If the answer is yes, proceed to Step 15 messaging for the review sample. If
 the answer is no, diagnose whether the brief is wrong or the list is wrong,
 and either revise brief autonomously OR escalate to the user — never
 auto-revise leads.
 
 ## Inputs
 
-- `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 25)
+- `CampaignOffer.currentStep === "apply-icp-rubric"` (Filter Leads is reached
+  only after saved-filter approval; `validate-sample` is the logical loop name,
+  not a visible route)
+- Approved message template/token rules exist in the campaign brief before any
+  enrichment or scoring cells are queued
+- Confirmed campaign rows from Step 13, with first review/process sample from
+  `reviewBatchRowIds` (size: `importLimit`, default 15)
 - Config from `auto-execute.yaml`: `sample.sampleSize`,
   `sample.minProjectedPass`, `sample.maxRevisionRounds`
 - Persisted counter `revisionRound` (starts at 0 on first entry; persists
@@ -32,7 +35,7 @@ auto-revise leads.
 ## Loop Shape
 
 ```text
-1. pick first sampleSize rows from the imported review batch
+1. pick first sampleSize rows from the confirmed campaign rows
 
 2. paginate the campaign table to collect enrichCellIds where
    enrichStatus = "pending" for the sample rows
@@ -41,7 +44,7 @@ auto-revise leads.
    - strip carryData from every row BEFORE retaining in tail context
      (see §Known Tool Behaviors #4)
 
-3. queue_cells(enrichCellIds, batchSize <= 100)
+3. after message-template approval, queue_cells(enrichCellIds, batchSize <= 100)
    - confirm_lead_list does NOT auto-enqueue enrichment on imports
      into an existing workflow table; Step 14 must enqueue manually
      (see §Known Tool Behaviors #1)
@@ -54,9 +57,9 @@ auto-revise leads.
    scoring from the queued Enrich Prospect cells
 
 6. wait_for_rubric_results(sample, targetCount = <cohortSize>, minPassedCount = 1)
-   - cohortSize = stats.totalRows of the enrichment batch, or the
-     imported batch count
-   - default targetCount=25 matches the default review batch, but pass the
+   - cohortSize = stats.totalRows of the enrichment batch, or the review sample
+     count
+   - default targetCount=15 matches the default review sample, but pass the
      explicit batch count anyway so future larger expansion batches do not
      accidentally stop early
      (see §Known Tool Behaviors #3)
@@ -73,6 +76,7 @@ auto-revise leads.
    - partialResult: object when present
    - stats: object
    Never retain the full rows payload in tail context.
+   - 15 rows is the default customer-visible process sample
    - 25 rows ≈ 67KB of payload (full post bodies in carryData)
    - 100 rows ≈ 268KB; 500 rows ≈ 1.3MB — blows context on Opus
      (see §Known Tool Behaviors #2)
@@ -96,7 +100,7 @@ auto-revise leads.
      underfloor partial sample
 
 9. compute metrics:
-   passInSample       = count of review-batch rows where rubric passed
+   passInSample       = count of review/process sample rows where rubric passed
    projectedPass      = round(passInSample / sampleSize * importLimit)
 
 10. branch:
@@ -150,8 +154,8 @@ inspection is required, and strip `carryData` before retention.
 
 ### 3. `wait_for_rubric_results.targetCount` defaults to 25
 
-Observed: default `targetCount=25` returns `ready=true` after the first 25
-rubric completions. This matches the default review batch, but if a future
+Observed: older defaults used `targetCount=25`; the current default process
+sample is 15. If a future
 expansion batch is larger, pass the explicit batch size instead of relying on
 the default. The completion semantic is `passRate.completed`, NOT "table
 fully enriched and scored."
@@ -175,8 +179,8 @@ company, enrichCellId, enrichStatus) over the default shape.
 
 ### 5. `wait_for_rubric_results` can timeout with enough signal to decide
 
-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
+Observed: a 15-row review sample may return `ready=false`, `reason="timeout"`,
+and partial stats such as 12/15 scored, 4 passing, 4 messages generated. That is
 enough to diagnose an underperforming sample. Waiting again without active
 processing makes the experience feel frozen.
 
@@ -194,16 +198,17 @@ once only if active processing is still visible.
 projectedPass = round(passInSample / sampleSize * importLimit)
 ```
 
-Worked examples with defaults (sampleSize=25, importLimit=25):
-
-| passInSample | projectedPass | Handoff? (minProjectedPass=5) |
-| ------------ | ------------- | ----------------------------- |
-| 0            | 0             | No — escalate or revise       |
-| 3            | 3             | No — escalate or revise       |
-| 5            | 5             | Yes — exactly at floor        |
-| 8            | 8             | Yes                           |
-| 10           | 10            | Yes                           |
-| 25           | 25            | Yes                           |
+Worked examples with defaults (sampleSize=15, importLimit=15):
+
+| passInSample | projectedPass | Handoff? (minProjectedPass=1)                     |
+| ------------ | ------------- | ------------------------------------------------- |
+| 0            | 0             | No — escalate or revise                           |
+| 1            | 1             | Yes — one pass is enough for first-message review |
+| 3            | 3             | Yes                                               |
+| 5            | 5             | Yes                                               |
+| 8            | 8             | Yes                                               |
+| 10           | 10            | Yes                                               |
+| 15           | 15            | 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

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

@@ -10,19 +10,19 @@ CampaignOffer state and the watch link are canonical. Disk artifacts are
 optional debug/UAT diagnostics, and normal customer runs should not expose local
 draft files. Resume, gating, and handoff read campaign state first.
 
-Bounded review-batch sourcing + import happens after the existing campaign
+Source-list materialization and first-sample setup happen after the existing campaign
 shell has the selected source attached with `campaignOfferId`. It happens before
 the post-import fit/message scouts, so those scouts can use the actual campaign
 table sample.
 
 Do not queue workflow cells, attach a sequence, or start before the later
-rubric/message prerequisites are true:
+fit prerequisites are true:
 
 1. rubrics saved to the campaign
-2. approved message set synced into `campaignBrief`
 
-Do not enrich, queue workflow cells, attach a sequence, or start before those
-prerequisites are true.
+Do not enrich or queue filter cells before saved rubrics/run conditions are true.
+Do not queue Generate Message cells, attach a sequence, or start before the
+approved message set is synced into `campaignBrief`.
 
 Before `import_leads`, the approved source must already be campaign-attached.
 The find-leads scouts receive `campaignOfferId` up front, so selected Signal
@@ -55,13 +55,12 @@ 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
-  default 25-row campaign review batch.
+  default 15-row campaign review/process sample.
 - **Supplied LinkedIn profile CSV** — confirm `load_csv_linkedin_leads` only
   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
-  `confirm_lead_list({ sourceLeadListId: leadListId, targetLeadCount: importLimit })`.
+  `leadListId`, then copy the confirmed list into the campaign table with
+  `confirm_lead_list({ sourceLeadListId: leadListId, reviewBatchLimit: 15 })`.
   Do not call `import_leads` for this branch; the materialized lead list is the
   source.
   Do **not** call `wait_for_lead_list_ready` for this branch; there is no
@@ -69,13 +68,13 @@ Supported branches:
   in an import-failed state before `confirm_lead_list`.
 - **Existing Sellable lead list** — revalidate the source list in the same
   workspace, then reuse it with
-  `confirm_lead_list({ sourceLeadListId, targetLeadCount: importLimit })`.
+  `confirm_lead_list({ sourceLeadListId, reviewBatchLimit: 15 })`.
   Do **not** call `wait_for_lead_list_ready` for this branch.
 - **Supplied domain/account CSV** — reuse or confirm `load_csv_domains`, keep
   its `domainFilterId`, run a campaign-associated Prospeo people search with
   `campaignOfferId`, provider prompt preflight, and `domainFilterId`, then
-  materialize the source list from that search before importing the bounded
-  review batch into the campaign table.
+  materialize the source list from that search before copying the confirmed
+  list into the campaign table and processing the first 15 rows.
 
 ## Campaign-Attached Source Contract
 
@@ -115,33 +114,43 @@ import_leads({
 
 Provider is inherited from the selected source decision (not re-selected here)
 and should already be saved on the campaign before import. For Sales Nav and
-Prospeo, `<sourceCandidateTarget>` is not the 25-row review batch. It is the
-source-list export/materialization count from the approved source math:
-`min(rawResultCount, providerMax, ceil(targetGoodFitLeads /
-projectedFitRateAfterCleanup))`. If projected good fits remain below the target
-(often about 150+ usable prospects unless the campaign/source defaults specify
-otherwise), return to find-leads and refine filters before import. Response
+Prospeo, `<sourceCandidateTarget>` is not the 15-row review/process sample. It is
+the source-list export/materialization count from the approved source math. Aim
+for about 1,000 source contacts by default and use the provider cap internally
+when the raw pool is larger. If projected good fits remain below the target,
+return to find-leads and refine filters before import. Response
 returns `{ imported, skipped, duplicates }` — surface all three to the
 escalation logic 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. 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
+approved source math. The default good-fit target is 300 and the planning
+fit-rate assumption is 20%, so the default source-candidate plan is about 1,500
 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 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. After the scrape,
-`wait_for_lead_list_ready` must clear the approved source-candidate target; if
-it reports `source_under_capacity`, do not call `confirm_lead_list`. The
-subsequent `confirm_lead_list` call still uses `targetLeadCount: <importLimit>`
-so only the bounded review batch enters the campaign table.
-
-For supplied direct lists, `confirm_lead_list` must receive
-`targetLeadCount: <importLimit>` or explicit `sourceRowIds` so a 100-row source
-imports only the bounded review batch before greenlight.
+Discovery falls below that floor during the pre-scrape sample, revise the source
+plan before importing. After an approved scrape starts, do not discard a nonempty
+completed source list just because it lands below the source-candidate target:
+confirm/copy the completed list for the first review sample, then add more posts
+or switch provider if the sample quality or scale is not enough. The subsequent
+`confirm_lead_list` call uses `reviewBatchLimit: 15`. It copies the confirmed
+source rows into the campaign table and returns only the first 15 rows as the
+review/process sample.
+
+Harvest-specific interpretation: Signal Discovery post comments and reactions
+are paged from Harvest at about 100 records per page, with production caps of
+1,500 reactions and 300 comments per selected post. The source list stores
+headline-passing candidates after that scrape. Therefore `71 source rows` means
+71 candidates passed headline/list filtering and were inserted; it does not
+mean the post scrape stopped after 71 raw engagers. Treat raw visible engagement,
+raw fetched pages, inserted source rows, and the 15-row review/process sample as
+separate numbers.
+
+For supplied direct lists, `confirm_lead_list` should receive
+`reviewBatchLimit: 15` so the campaign table can hold the confirmed list while
+the first 15 rows drive the initial approval flow.
 
 ## `mode=add` Two-Step Handshake
 
@@ -230,9 +239,11 @@ cannot scale further without a new source lane.
 - Zero-imported + high-skipped ⇒ lane-exhausted operator notice (NOT a
   silent proceed).
 - `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.
+  approval. It materializes the source list and then `confirm_lead_list` copies
+  the confirmed source rows into the campaign table while returning only the
+  first 15 rows for the initial review/process sample. Enrichment and fit
+  scoring wait for saved rubrics/run conditions; message cells wait for 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

@@ -38,7 +38,7 @@ states.
   Apollo, or existing list.
 - During search iteration, say what you tried, what you are trying next, what
   sample you are checking, and why that helps this campaign.
-- At filter choice, do not say filtering the batch before rubrics and message approval are saved.
+- At filter choice, do not say the batch is filtering before rubrics are saved.
 - Avoid internal terms: MCP, tool, currentStep, workflow table, scout, debug.
 - Treat `safety` as optional internal context, not a visible disclaimer.
 - Do not repeat long negative lists like "no leads import, no enrichment, no
@@ -114,7 +114,7 @@ Source direction override:
   "stage": "find-leads",
   "headline": "Testing the requested source",
   "visibleState": "The campaign asked for hiring and account signals, so Codex is starting with Prospeo instead of the default LinkedIn engagement path.",
-  "agentIntent": "It is checking whether this source has enough reachable ICP-looking people before importing a review batch.",
+  "agentIntent": "It is checking whether this source has enough reachable ICP-looking people before building the source list.",
   "nextAction": "Review source"
 }
 ```
@@ -138,8 +138,8 @@ Search iteration:
   "stage": "find-leads",
   "headline": "Tightening the search",
   "visibleState": "The first Signal Discovery search was broad, so Codex is trying a narrower Claude Code founder lane.",
-  "agentIntent": "It is sampling a few engagers before importing so the review batch stays on-brief.",
-  "nextAction": "Review batch"
+  "agentIntent": "It is sampling a few engagers before scraping so the first review sample stays on-brief.",
+  "nextAction": "Review source math"
 }
 ```
 
@@ -160,14 +160,14 @@ chat, update the guide to route the user back to Codex/Claude for approval. Do
 not keep future-tense copy such as `I'll show a source recommendation` once the
 decision card is visible.
 
-Review batch:
+Review/process sample:
 
 ```json
 {
   "stage": "review-batch",
-  "headline": "Preparing your review batch",
-  "visibleState": "This page shows the leads Codex selected for review.",
-  "agentIntent": "Codex is preparing the first campaign batch from those leads.",
+  "headline": "Preparing your first sample",
+  "visibleState": "This page shows the confirmed source leads. Codex will process the first 15 for review.",
+  "agentIntent": "Codex is preparing the first campaign sample from those leads.",
   "nextAction": "Fit + message"
 }
 ```
@@ -177,10 +177,10 @@ Source approved and import starting:
 ```json
 {
   "stage": "review-batch",
-  "headline": "Importing the review batch",
+  "headline": "Copying source leads",
   "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"
+  "agentIntent": "Codex is copying the confirmed source into the campaign and will process only the first 15 for review.",
+  "nextAction": "Review sample ready"
 }
 ```
 
@@ -189,13 +189,13 @@ current-tense import copy. Do not leave the guide in source-approved or
 future-tense copy such as `I'll show the review-batch outcome`; that makes the
 browser guide describe a different moment than chat.
 
-After review batch import:
+After confirmed source rows are copied:
 
 ```json
 {
   "stage": "fit-message",
   "headline": "Filtering may not be needed",
-  "visibleState": "25 review leads are in the campaign table from 181 source candidates. Sample read: 23/25 look like senior target-role fits; 2 need cleanup or manual review. The browser is showing the filter-choice screen.",
+  "visibleState": "15 review leads are ready from 181 source candidates. Sample read: 13/15 look like senior target-role fits; 2 need cleanup or manual review. The browser is showing the filter-choice screen.",
   "agentIntent": "Codex is not recommending filters because the sample already looks clean. Fit examples: Dave Kranowitz (Chief Revenue Officer); Marie Didominica (Head of Growth Marketing). Add filters only for a narrow exclusion.",
   "nextAction": "Skip filters or add a narrow cleanup rule",
   "workerStatuses": {
@@ -209,15 +209,15 @@ Use this after the selected review rows are present and before filters are
 saved. The filter recommendation must be row-specific: say why filters are
 recommended from the sample counts and examples, or say filtering may not be
 needed when the visible review rows already look clean. This is a user decision
-gate, not active filtering; do not say filtering the batch before rubrics and
-message approval are saved. The Message Draft Builder should start immediately
-after the bounded review batch exists; mark it running only when that branch
-actually started.
+gate, not active filtering; do not say filtering the batch before rubrics are
+saved. The Message Draft Builder should start after the filter-choice answer;
+mark it running only when that branch actually started.
 When the user chooses filters, immediately persist `enableICPFilters: true` and
 move to `create-icp-rubric` so the watched app shows Filter Rules while Codex
-defines the rules in chat. After `save_rubrics`, move to `apply-icp-rubric`
-so the watched app shows Filter Leads with saved rules before message approval
-unlocks any enrichment or filtering.
+defines the rules in chat. After `save_rubrics`, keep the app on Filter Rules so
+the user can read and approve the saved criteria. Only that approval moves the
+app to `apply-icp-rubric` / Filter Leads, where it waits for message approval
+before enrichment/filtering is queued.
 
 Fit + message:
 
@@ -242,7 +242,7 @@ Review ready:
   "stage": "review-ready",
   "headline": "Review the message template",
   "visibleState": "The browser remains on Filter Leads while the message template is reviewed in chat.",
-  "agentIntent": "Codex is waiting for approval before saving the template to the campaign brief and queueing enrichment/filtering.",
+  "agentIntent": "Codex is waiting for the approved template before row processing starts.",
   "nextAction": "Approve or revise the template"
 }
 ```
@@ -254,17 +254,16 @@ 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 one passing row with one generated message before moving to review.",
+  "agentIntent": "Codex 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 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.
+Do not move to Messages immediately after `approve-message`. Filter Leads is
+reached only after saved-filter approval; approving the message unlocks the
+bounded cascade from that screen. Move to Messages once at least one review row
+passes and one generated message is ready. Do not wait for the rest of the 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

@@ -17,8 +17,8 @@ table.
 ## MANDATORY TOOL ORDER (read this BEFORE any tail step)
 
 Every tail run MUST call these tools in this exact order. The tail is
-**review-batch cascade-driven**: you kick off Enrich Prospect only for
-the imported review batch, and the workflow engine chains DNC Check →
+**first-sample cascade-driven**: you kick off Enrich Prospect only for
+the first review/process sample, and the workflow engine chains DNC Check →
 ICP Score → Passes Rubric → Generate Message automatically. Your job is
 to START the bounded cascade, WAIT until filter results land, OBSERVE message
 generation as soon as one row passes, and stop for review.
@@ -26,27 +26,27 @@ Do NOT manually run rubric-check, enrich, or message-generation
 tools — the cascade already does them.
 
 ```text
-Step 13 — import/confirm review batch only
+Step 13 — materialize source list + confirm first sample
   materialize/reuse approved source with campaignOfferId
-  import_leads(targetLeadCount=importLimit)
+  import_leads(source-list target; SalesNav/Prospeo default ~1000, Signal Discovery default ~1500 engagers)
   wait_for_lead_list_ready
-  confirm_lead_list
+  confirm_lead_list(reviewBatchLimit=15)
   wait_for_campaign_table_ready    # campaign table exists
-  get_rows_minimal                 # read imported review batch
+  get_rows_minimal                 # read first review/process sample
   update_campaign(currentStep=filter-choice)
 
 Post-import main thread
-  launch Message Draft Builder immediately after workflowTableId + review rows exist
+  launch Message Draft Builder after the filter-choice answer
   launch Lead Fit Builder only after user chooses filters
   save_rubrics({ campaignOfferId, leadScoringRubrics }) after the campaign table exists
   keep the watched app on Filter Leads after rubrics are saved
   while on Filter Leads, show the message template recommendation from the background Message Draft Builder
   after approve-message, update_campaign_brief writes `## Approved Message Template` with `{{...}}` tokens
-  only then start the bounded review-batch cascade
+  only then start the first-sample cascade
 
-Step 14 — kick bounded cascade + observe sample
-  queue_cells(cellIds=<review-batch Enrich Prospect cells only>)  <-- starts bounded chain
-  wait_for_campaign_table_ready    # wait until review-batch cascade starts returning filter results
+Step 14 — kick first-sample cascade + observe sample
+  queue_cells(cellIds=<first 15 review/process Enrich Prospect cells only>)  <-- starts bounded chain
+  wait_for_campaign_table_ready    # wait until sample cascade starts returning filter results
   get_rows_minimal                 # read passesRubric + message cell status per row
   wait_for_rubric_results(minPassedCount=1, includeRows=false)
   if at least one row passes: update_campaign(currentStep=auto-execute-messaging)
@@ -210,20 +210,19 @@ import milestone.
      token, confirm `load_csv_linkedin_leads` as source-list materialization to batch the
      supplied CSV into a Sellable lead list, persist the returned `leadListId`,
      then call `confirm_lead_list({ sourceLeadListId: leadListId,
-targetLeadCount: importLimit })`. Do not call `import_leads` for this
-     branch; the lead list is the source, and `confirm_lead_list` imports the
-     bounded review batch into the campaign table.
+reviewBatchLimit: 15 })`. Do not call `import_leads` for this
+     branch; the lead list is the source, and `confirm_lead_list` copies the
+     confirmed source rows into the campaign table.
    - `existing-lead-list`: revalidate that the lead list still exists in the
      same workspace, reuse it as `sourceLeadListId`, then call
-     `confirm_lead_list({ sourceLeadListId, targetLeadCount: importLimit })`.
+     `confirm_lead_list({ sourceLeadListId, reviewBatchLimit: 15 })`.
    - `supplied-domains`: reuse or confirm `load_csv_domains`, preserving
      `domainFilterId`; run a campaign-associated Prospeo people search with
      `campaignOfferId`, provider prompt preflight, and that `domainFilterId`;
-     then import with `targetLeadCount: importLimit`.
-     Never exceed `importLimit`. This is a review batch, not a full
-     campaign-scale import. If a source search/list contains more rows than
-     the cap, import only the first `importLimit` rows and leave the rest for
-     a later expansion step.
+     then import with `targetLeadCount` set to the approved source-list target
+     (default about 1,000). The first 15 copied campaign rows are the
+     review/process sample; the full confirmed source list is copied into the
+     campaign for later expansion.
      Persist or recover materialized IDs on resume: `leadListId`,
      `domainFilterId`, `searchId`, `selectedLeadListId`, `workflowTableId`, and
      imported row IDs. If the source file changed after preview, or an existing lead list
@@ -236,7 +235,7 @@ campaignOfferId, confirmed: true })` -> `search_signals({ campaignOfferId,
 ...approved recipe })` -> `select_promising_posts({ campaignOfferId,
 selectionMode: "replace", selections, headlineICPCriteria })` ->
      `import_leads({ campaignOfferId, provider: "signal-discovery",
-targetLeadCount: importLimit })`.
+	targetEngagerCount: 1500 })`.
      For Signal Discovery, the promotion/select step is load-bearing. Use
      post IDs from the current campaign-scoped `search_signals` response or
      posts the user has visibly promoted in the campaign UI. Never use post IDs
@@ -248,26 +247,26 @@ targetLeadCount: importLimit })`.
      re-run a narrow campaign-scoped `search_signals` call to recover current
      post rows, or ask the user to promote the desired posts in the UI and then
      retry `import_leads`.
-     Source approval is the explicit confirmation for this bounded review
-     batch; do not ask for a second yes/no gate between
+     Source approval is the explicit confirmation for this selected-post
+     scrape; do not ask for a second yes/no gate between
      `select_promising_posts` and `import_leads`.
    - Sales Nav: `get_provider_prompt({ provider: "sales-nav", campaignOfferId,
 confirmed: true })` -> rebuild/verify filter IDs -> `search_sales_nav({
 campaignOfferId, filters, confirmed: true })` -> `import_leads({
 campaignOfferId, provider: "sales-nav", searchId, targetLeadCount:
-importLimit })`.
+1000 })`.
    - Prospeo: `get_provider_prompt({ provider: "prospeo", campaignOfferId,
 confirmed: true })` -> reuse `domainFilterId` when present ->
      `search_prospeo({ campaignOfferId, filters, domainFilterId, confirmed:
 true })` -> `import_leads({ campaignOfferId, provider: "prospeo",
-searchId, targetLeadCount: importLimit })`.
+searchId, targetLeadCount: 1000 })`.
 3. `wait_for_lead_list_ready` when a provider import job exists, then
    `confirm_lead_list`. Persist both identifiers: `selectedLeadListId` remains
    the source list and `workflowTableId` is the campaign table.
-4. `wait_for_campaign_table_ready` until the bounded review-batch rows are
+4. `wait_for_campaign_table_ready` until the first review/process sample rows are
    available in the campaign table.
 5. Call `get_rows_minimal({ tableId: workflowTableId })` and confirm the first
-   review batch is present. Do not queue cells in Step 13.
+   15-row review/process sample is present. Do not queue cells in Step 13.
 6. If the import returns zero usable leads, ESCALATE per
    `references/escalation-ladder.md` (hard fail).
 7. `update_campaign({ campaignId, currentStep: "filter-choice" })`.
@@ -283,16 +282,16 @@ succeeded.
 
 ## Step 14: validate-sample (logical loop on Filter Leads)
 
-Entered after the message template is approved while the watched campaign is
-already on `CampaignOffer.currentStep === "apply-icp-rubric"` / Filter Leads.
+Entered after rubrics are saved while the watched campaign is already on
+`CampaignOffer.currentStep === "apply-icp-rubric"` / Filter Leads.
 Do not route to a visible `validate-sample` step. Full decision tree lives in
 `references/sample-validation-loop.md`.
 
-**Step 14 starts the bounded cascade, then observes it.** Step 13 imported the
-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. Step 15 opens review as soon as one passing generated message
+**Step 14 starts the bounded fit cascade, then observes it.** Step 13 imported
+the review batch only. After `save_rubrics`, 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 and approved-template message
+generation is ready. 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.
@@ -304,7 +303,7 @@ queue_cells({ tableId: workflowTableId, cellIds: reviewBatchEnrichCellIds })
 wait_for_campaign_table_ready({ tableId: workflowTableId })
 get_rows_minimal({ tableId: workflowTableId })
 wait_for_rubric_results({ tableId: workflowTableId, targetCount: cohortSize, minPassedCount: 1, includeRows: false })
-passInSample = count of first sampleSize review-batch rows with passesRubric === true
+passInSample = count of first sampleSize review/process sample rows with passesRubric === true
 projectedPass = round(passInSample / sampleSize * importLimit)
 
 if wait_for_rubric_results.ready === true and passRate.passed >= 1:
@@ -390,7 +389,7 @@ Template`. If it does not, fail before the cascade runs. Do not repair
 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.
+   Remaining review/process sample 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.
@@ -414,7 +413,7 @@ job from messaging. Does NOT generate or write message text. A
 sequence with no `Generate Message` outputs would try to send empty
 strings, which is why Step 16 requires Step 15 to be complete.
 
-1. Observe the review-batch messages on the same sample that passed
+1. Observe the review-sample messages on the same sample that passed
    validation.
 2. If `messaging.critique.enabled` is true (Plan 85-03), run the
    bounded critique pass on the sample output per
@@ -440,9 +439,9 @@ strings, which is why Step 16 requires Step 15 to be complete.
    message that contains unresolved or unsupported tokens (including
    any critique rewrite that tried to introduce one).
 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.
+   critique when enabled), stop at the review handoff. Do NOT wait for the
+   remaining review/process sample 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.
@@ -537,13 +536,14 @@ runs.
 
 ## Tail Hard Rules
 
-- Review-batch sourcing/import happens in Step 13, not during atomic mint.
+- Source-list materialization and first-sample confirmation happen in Step 13,
+  not during atomic mint.
 - Step 13 materializes/reuses the approved source with `campaignOfferId` before
   import. Do not import a legacy campaignless Signal source until selected posts
   exist on the campaign.
-- Full-list expansion is not part of the default tail. It requires user
-  approval after the review batch.
-  Import must never exceed `importLimit`.
+- Full-list expansion happens only after the first review flow proves out. The
+  first enrichment/scoring pass must stay capped to the 15-row review/process
+  sample.
 - The tail NEVER calls `start_campaign` on its own.
 - The tail NEVER auto-revises leads. Brief revision is autonomous; lead
   revision is always operator-gated.