@sellable/mcp 0.1.151 → 0.1.152

package/dist/tools/rubrics.js

@@ -95,16 +95,16 @@ async function fetchCampaignOffer(campaignOfferId) {
         leadScoringRubrics: v3.rubrics,
     };
 }
-const filterLeadsReadyWatchNarration = {
+const filterRulesSavedForReviewWatchNarration = {
     stage: "fit-message",
-    headline: "Filter rules saved",
-    visibleState: "The browser is staying on Filter Leads with the fit rules saved.",
-    agentIntent: "Codex is preparing the message template for approval before enrichment, filtering, or message cells run.",
-    nextAction: "Review the message template in chat",
+    headline: "Filter rules saved for review",
+    visibleState: "The browser is showing Filter Rules with the saved criteria.",
+    agentIntent: "Codex is waiting for filter approval before the review batch is enriched or scored.",
+    nextAction: "Approve or revise the filters",
     progressLabel: "Fit + message",
-    safety: "Template approval comes before row execution.",
+    safety: "Saved rules are ready to review; downstream row processing remains gated.",
 };
-function shouldMoveToFilterLeads(campaign) {
+function shouldKeepFilterRulesVisible(campaign) {
     const currentStep = campaign.currentStep;
     if (!currentStep)
         return true;
@@ -116,16 +116,15 @@ function shouldMoveToFilterLeads(campaign) {
         "filter-choice",
         "create-icp-rubric",
         "filter-rules",
-        "apply-icp-rubric",
     ].includes(currentStep);
 }
 function buildEnableIcpFiltersPayload(campaign) {
     const payload = {
         enableICPFilters: true,
     };
-    if (shouldMoveToFilterLeads(campaign)) {
-        payload.currentStep = "apply-icp-rubric";
-        payload.watchNarration = filterLeadsReadyWatchNarration;
+    if (shouldKeepFilterRulesVisible(campaign)) {
+        payload.currentStep = "create-icp-rubric";
+        payload.watchNarration = filterRulesSavedForReviewWatchNarration;
     }
     return payload;
 }
@@ -245,7 +244,7 @@ export const rubricToolDefinitions = [
     },
     {
         name: "save_rubrics",
-        description: "Persist rubric criteria to the campaign. Pass leadScoringRubrics directly to save without drafting. Saving active rubrics enables ICP filtering and moves the watched client to Filter Leads; it does not run filtering by itself.",
+        description: "Persist rubric criteria to the campaign. Pass leadScoringRubrics directly to save without drafting. Saving active rubrics enables ICP filtering and keeps the watched client on Filter Rules for user approval; it does not move to Filter Leads or run filtering by itself.",
         inputSchema: {
             type: "object",
             properties: {
@@ -580,12 +579,16 @@ export async function saveRubrics(input) {
     // cascade blocked.
     let enableICPFiltersSet = false;
     let currentStepSet = false;
+    let savedCurrentStep = null;
     try {
         const api = getApi();
         const payload = buildEnableIcpFiltersPayload(campaign);
         await api.put(`/api/v2/campaign-offers/${input.campaignOfferId}`, payload);
         enableICPFiltersSet = true;
-        currentStepSet = payload.currentStep === "apply-icp-rubric";
+        if (typeof payload.currentStep === "string") {
+            savedCurrentStep = payload.currentStep;
+            currentStepSet = true;
+        }
     }
     catch (error) {
         // Non-fatal: the rubric save already succeeded. Retry the minimum
@@ -604,17 +607,17 @@ export async function saveRubrics(input) {
     }
     return {
         success: true,
-        message: currentStepSet
-            ? `Saved ${normalizedDraft.length} rubric criteria, ICP filtering is ON, and the campaign is on Filter Leads.`
-            : enableICPFiltersSet || campaign.enableICPFilters === true
+        message: savedCurrentStep === "create-icp-rubric"
+            ? `Saved ${normalizedDraft.length} rubric criteria, ICP filtering is ON, and the campaign is waiting for filter approval.`
+            : currentStepSet
                 ? `Saved ${normalizedDraft.length} rubric criteria and ICP filtering is ON.`
-                : `Saved ${normalizedDraft.length} rubric criteria to the campaign. WARNING: could not auto-enable ICP filtering — call update_campaign({ campaignId, enableICPFilters: true }) to activate rubric-based filtering.`,
+                : enableICPFiltersSet || campaign.enableICPFilters === true
+                    ? `Saved ${normalizedDraft.length} rubric criteria and ICP filtering is ON.`
+                    : `Saved ${normalizedDraft.length} rubric criteria to the campaign. WARNING: could not auto-enable ICP filtering — call update_campaign({ campaignId, enableICPFilters: true }) to activate rubric-based filtering.`,
         criteriaCount: normalizedDraft.length,
         deletedCount: deletedRubricIds.length,
         enableICPFiltersSet,
-        currentStep: currentStepSet
-            ? "apply-icp-rubric"
-            : (campaign.currentStep ?? null),
+        currentStep: savedCurrentStep ?? campaign.currentStep ?? null,
         currentStepSet,
         rubrics: result?.rubrics ?? normalizedDraft,
         activeRubrics: result?.rubrics ?? normalizedDraft,

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -72,10 +72,10 @@ not create, link, or surface local draft files unless the user explicitly asks
 for them. Resume, gating, and handoff read campaign state first. The
 watchable campaign exists after the short brief; lead import is bounded to the
 first review batch. After that, the user chooses whether to use filters or skip.
-When filters are chosen, save rubrics, then pause before queueing enrichment or
-filtering: tell the user the fit rules are saved, the message template needs
-approval next, and enrichment/filtering will start after that approval. Use
-Template is the default message path; AI Generated is only an explicit opt-out.
+When filters are chosen, save rubrics, get filter approval, then wait for
+message-template approval before enrichment/filtering or Generate Message cells.
+Use Template is the default message path; AI Generated is only an explicit
+opt-out.
 
 ## Opening Turn Contract
 
@@ -124,9 +124,10 @@ data, compare sources by source volume, sampled ICP fit, activity/warmth
 signals, cleanup risk, and confidence basis. If a user asks for a forecast,
 label it explicitly as not estimated from this run.
 
-Before any provider prompt, search, source scout, or signal-discovery call,
-show a short source-plan gate and ask for approval. This first approval
-authorizes scouting/search only. The gate should say:
+Before any provider prompt, search, source scout, or signal-discovery call, show
+one source-plan gate and ask for approval. The plan must be visible before the
+question, and this first approval authorizes scouting/search only. The gate
+should say:
 
 - given this campaign, the viable source options
 - the recommended first lane
@@ -143,6 +144,10 @@ why. Do not call `search_signals`, `search_sales_nav`, `search_prospeo`,
 `fetch_post_engagers`, or provider-scoped subagents until the user approves this
 source plan or explicitly chooses a different source.
 
+If the user already answered a provider approval such as "Approve Prospeo plan",
+that answer satisfies the source-plan gate. Persist the approved provider and
+run the scouting/search next; do not ask a second source-plan approval question.
+
 For hiring-led campaigns, do not default to Sales Nav just because the target is
 a role search. Prospeo is the primary lane when the brief asks for companies
 actively hiring specific roles, open-role signals, account/contact coverage, or
@@ -153,41 +158,42 @@ are likely. Sales Nav is useful for recent LinkedIn activity, role/title
 precision, and referral paths, but it does not provide hiring-by-role filters;
 say that distinction plainly in the source-plan gate.
 
-After scouting, ask for a second approval on the concrete source action. For
-Signal Discovery, name how many selected posts will be scraped, the target
-engager/source-candidate volume, and the bounded review-batch size. For Sales
-Nav or Prospeo, name the specific approved import lane and source lead count.
+    After scouting, ask for a second approval on the concrete source action. For
+    Signal Discovery, name how many selected posts will be scraped, the target
+    engager/source-candidate volume, and the 15-row review/process sample size. For Sales
+    Nav or Prospeo, name the specific approved import lane and source lead count.
+
 Do not call `import_leads` or `confirm_lead_list` until this second approval is
 granted.
 
-For Sales Nav and Prospeo, the second gate approves materializing the source
-lead list, not importing only the review batch. Use the first-page/sample review
-to calculate projected good fits: sampled fit rate after conservative cleanup,
-raw pool size, source target, and expected good-fit count. If the projected
-good-fit pool is below the campaign target (normally about 150+ usable
-prospects unless source defaults say otherwise), keep refining/broadening
-filters before asking for import approval. Once it clears target, approve
-`import_leads` with the source-list `targetLeadCount` (up to the raw count or
-provider max). Only after the source list is ready should `confirm_lead_list`
-clone the bounded review batch into the campaign table.
+    For Sales Nav and Prospeo, the second gate approves materializing the source
+    lead list, not importing only the review batch. Use the first-page/sample review
+    to calculate projected good fits: sampled fit rate after conservative cleanup,
+    raw pool size, source target, and expected good-fit count. If the projected
+    good-fit pool is below the campaign target, keep refining/broadening filters
+    before asking for import approval. Once it clears target, approve `import_leads`
+    with a source-list `targetLeadCount` around 1,000 by default (provider cap is
+    internal when the raw pool is larger). Only after the source list is ready
+    should `confirm_lead_list({ reviewBatchLimit: 15 })` copy confirmed rows into
+    the campaign table and return the first 15 review/process rows.
 
 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:
 
-- 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
+- goal: about 300 good-fit prospects after cleanup, enrichment, and filters
+- source-candidate plan: about 1,500 raw engagers using a 20% working fit-rate
+  assumption unless sampled data supports a different number
 - planning floor: continue with Signal Discovery only when sampled/projected
   fit is at least 10% after cleanup; below that, move to Sales Nav recent
   activity instead of scraping noisy engagers
-- review checkpoint: after the source list exists, clone only the bounded
-  review batch into the campaign for fit and message review
+- review checkpoint: after the source list exists, copy confirmed source rows
+  into the campaign and process only the first 15 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 at the approved source-candidate target,
-  then clone only the bounded review batch into the campaign
+- first pass: build the source list, copy it into the campaign, then process
+  only the first 15 leads before scaling
 - fallback: switch to Sales Nav recent activity if sampled/projected fit falls
   below 10%, or if the review batch is vendor-heavy, agency-heavy, or off-ICP
 
@@ -217,17 +223,19 @@ which posts are being sampled in the watched app. The watch guide should say
 that we are pulling sample engagers from these posts to confirm the ICP is
 actually engaging and the source is viable.
 
-After the bounded review batch exists, use the same registry pattern for
+    After confirmed source rows exist in the campaign table, use the same registry pattern for
+
 post-lead work, but do not load that registry or any deep filter/message prompt
 before the filter-choice question. After `confirm_lead_list`, ask add filters
 vs skip filters immediately. Once the user answers, launch the message scout
 from the same campaign/table basis. If the user chooses filters, also launch the
-filter-leads scout, move to Filter Rules, save rubrics, then keep the browser on
-Filter Leads while the message recommendation is reviewed. If the user skips
-filters, move to Messages/message review. Workflow cell execution still waits
-for filter and template approval. AI Generated is an explicit opt-out from the
-template path. If the post-lead agents are absent, the main thread still
-orchestrates the same branches from the compact context with MCP tools/assets.
+filter-leads scout, move to Filter Rules, save rubrics, then ask for filter
+approval. After approval, keep the browser on Filter Leads while the message
+recommendation is reviewed. If the user skips filters, move to Messages/message
+review. Enrichment/filtering and Generate Message cells wait for message
+approval. AI Generated is an explicit opt-out from the template path. If the
+post-lead agents are absent, the main thread still orchestrates the same
+branches from compact MCP context.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
@@ -643,29 +651,23 @@ updates.
    until `hasMore=false`. Message review requires Message Draft Builder output:
    do not draft from a checklist, local markdown artifact, or parent-thread
    intuition. Use campaign state, campaign brief content, selected source state, and
-   imported review-batch rows as the source of truth; do not read stale local
+   first review/process sample 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
-   queue workflow cells, attach a sequence, or start until the filter choice is
-   resolved, rubrics are saved when filters are enabled, template/token rules
-   are approved on the default Use Template path, and the approved message set
-   is synced into the campaign brief. When filters are approved, immediately
+   watch link and see useful setup state immediately. Materialize the approved
+   source list, copy confirmed rows into the campaign, and process only the
+   first 15 review rows after the source is attached to the campaign; do not
+   queue workflow cells, attach a sequence, or start until saved filters and the
+   message template/token rules are approved. When filters are chosen, immediately
    call `mcp__sellable__update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
    so the watched app moves to Filter Rules while rubrics are drafted/saved.
-   After rubrics save, move the watched app to `apply-icp-rubric` / Filter
-   Leads and say the fit rules are saved; the background message scout is
-   preparing the message recommendation and approval comes next while the
-   browser stays on Filter Leads. If filters are skipped, move the watched app to
-   Messages/message review and wait for message approval there. After approval,
-   save the template to the campaign brief, then queue the bounded review-batch
-   `enrichCellId` cells to kick off enrichment/filtering. Move to Messages only
-   after at least one review row passes and Generate Message cells are running or
-   ready.
-   Product Generate Message cells must not run before that template/token
-   approval.
+   After rubrics save, keep Filter Rules visible for approval; after approval,
+   move to Filter Leads and wait there for the background message recommendation.
+   If filters are skipped, move to Messages/message review. Queue the bounded
+   review-batch `enrichCellId` cells only after message approval. Move to
+   Messages only after at least one review row passes and one generated message
+   is ready.
    Do not ask the user to approve the brief before shell creation unless they
    explicitly requested a no-write draft; the shell itself is the review surface.
 6. The main thread owns watch navigation. Call
@@ -673,9 +675,10 @@ updates.
    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 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,
+   as filters are chosen and while saved filters await approval,
+   `apply-icp-rubric` after filter approval and message approval while bounded
+   enrichment/filter scoring runs, `validate-sample` only as a recovery/legacy
+   observation state,
    `auto-execute-messaging` after at least one row passes and review-batch
    messages are being generated or reviewed, `awaiting-user-greenlight` only
    after generated review-batch messages are approved, `settings` for sender

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

@@ -1,6 +1,6 @@
 ---
 name: create-campaign-v2
-description: Execute the compact JSON-gated shell-first campaign flow: resolve campaign identity, create a watchable CampaignOffer shell with the brief, attach and approve the source, import the bounded review batch, persist rubrics and approved message template, validate the review batch, then hand off to Settings, sequence, and start.
+description: Execute the compact JSON-gated shell-first campaign flow: resolve campaign identity, create a watchable CampaignOffer shell with the brief, attach and approve the source, copy the confirmed source list into the campaign, process the first 15 review rows, persist rubrics and approved message template, validate the first passing generated message, then hand off to Settings, sequence, and start.
 visibility: internal
 ---
 
@@ -40,19 +40,17 @@ for debug output.
 4. Create the watchable campaign shell with `create_campaign` and the v1 brief.
 5. Surface the direct watch link.
 6. Choose and approve the lead source.
-7. Import and confirm only the bounded first review batch.
+7. Materialize the approved source list, confirm/copy it into the campaign, and
+   use only the first 15 rows as the initial review/process sample.
 8. Ask whether to use filters or skip them.
-9. Persist lead rubrics when filters are enabled.
-10. Generate a first-message template recommendation from the imported review
-    rows.
-11. Review and approve/revise the message.
-12. Sync the approved template into the campaign brief.
-13. After message approval, keep the watched app on Filter Leads while the
-    bounded enrichment/filter cascade starts.
-14. Move to Messages only after at least one review row passes and one generated
-    message is ready for review. Do not wait for a stronger sample once that
-    first passing message exists; review it, then hand off to Settings, sender,
-    sequence, and explicit launch greenlight.
+9. Persist lead rubrics when filters are enabled, then ask approval while the
+   app remains on Filter Rules.
+10. Move to Filter Leads only after saved filters are approved.
+11. Review and approve/revise the message template.
+12. Sync the approved template into the brief, then queue bounded
+    enrichment/filtering.
+13. Move to Messages after one row passes and one generated message is ready;
+    review it, then hand off to Settings, sender, sequence, and launch.
 
 There is no normal approval-packet, commit-gate, atomic-mint, or local
 artifact-validation step. Those belong only to legacy validation/rehearsal
@@ -136,9 +134,9 @@ can be a conversation-signal check if relevant hiring posts are likely, and
 Sales Nav is a LinkedIn activity/referral fallback rather than the main hiring
 filter.
 
-Before any provider prompt, search, source scout, or signal-discovery call,
-show a short source-plan gate and ask for approval. This first approval
-authorizes source scouting/search only. The gate must say, in plain language:
+Before any provider prompt, search, source scout, or signal-discovery call, show
+one source-plan gate and ask for approval. The gate must include the plan before
+the question, and this first approval authorizes source scouting/search only:
 
 - given this campaign, the viable source options
 - the recommended first lane
@@ -151,7 +149,9 @@ Do not surface blanket source heuristics as product copy. Make the recommendatio
 specific to the campaign. If Signal Discovery is recommended, name the exact
 post themes you will search. If the campaign looks unlikely to have relevant
 public conversations, recommend the specific Sales Nav or Prospeo lane instead
-and say why. Do not call `search_signals`, `search_sales_nav`, `search_prospeo`,
+and say why. An approval like "Approve Prospeo plan" satisfies this gate; persist
+the provider and search next. Do not ask a second source-plan question. Do not
+call `search_signals`, `search_sales_nav`, `search_prospeo`,
 `fetch_post_engagers`, or provider-scoped subagents until the user approves this
 source plan or explicitly chooses a different source.
 
@@ -176,17 +176,17 @@ name the specific search/import lane and source lead count. Do not call
 `import_leads` or `confirm_lead_list` until this second source-action approval
 is granted.
 
-For Sales Nav and Prospeo, do not ask to import only the 25-row review batch at
+For Sales Nav and Prospeo, do not ask to import only the 15-row review sample at
 the source-action gate. First-page samples are for source math: compute sampled
 fit after conservative cleanup, project how many good-fit prospects the raw
 pool can yield, and keep refining filters while the projected good-fit pool is
-below the campaign target (normally about 150+ usable prospects unless the
-campaign/source defaults say otherwise). Once the lane clears the target, ask
+below the campaign target. Once the lane clears the target, ask
 approval to materialize the source list with
-`targetLeadCount = min(rawResultCount, providerMax, ceil(targetGoodFitLeads /
-projectedFitRateAfterCleanup))`. After that source list is ready,
-`confirm_lead_list` imports only the bounded review batch into the campaign
-table for fit and message review.
+`targetLeadCount` around 1,000 source contacts by default (use the provider cap
+internally when the raw pool is larger). After that source list is ready,
+`confirm_lead_list({ reviewBatchLimit: 15 })` copies confirmed source rows into
+the campaign table and returns the first 15 review/process row ids for fit and
+message review.
 
 After the user approves this concrete source-action gate, do not show the
 Source Recommendation again and do not ask another source approval question.
@@ -205,10 +205,11 @@ selected posts exist:
 
 Use Signal Discovery first.
 
-**Good-fit target:** ~150 prospects after cleanup, enrichment, and filters<br>
-**Source-candidate plan:** scrape ~1,000 raw engagers using a conservative 15% fit-rate assumption<br>
+**Goal:** ~300 good-fit prospects after cleanup, enrichment, and filters<br>
+**Working assumption:** ~20% of raw post engagers become good-fit prospects<br>
+**Engagers needed:** ~1,500 raw engagers<br>
 **Planning floor:** continue only when sampled/projected fit is at least 10% after cleanup; below that, switch to Sales Nav recent activity<br>
-**Review checkpoint:** after the source list exists, clone only the bounded review batch into the campaign for fit and message review<br>
+**Review checkpoint:** after the source list exists, copy the confirmed source list into the campaign and process only the first 15 leads for fit and message review<br>
 
 ### Selected posts
 
@@ -219,19 +220,18 @@ Use Signal Discovery first.
 | Divyanshi Sharma | LinkedIn lead-gen system built with Claude Code |               ~508 |
 
 **Total visible pool:** ~2,813 engagers<br>
-**Estimated good-fit pool at 15%:** ~420 prospects before dedupe/risk cleanup
+**Estimated good-fit pool at 20%:** ~560 prospects before dedupe/risk cleanup
 
 ### Recommendation
 
 Approve scraping these 3 posts.
 
-This gives enough volume to work toward ~150 good-fit prospects, while
+This gives enough volume to target ~300 good-fit prospects after cleanup, while
 keeping the source tied to people already engaging with Claude Code outbound /
 AI-native sales workflows.
 
-**First pass:** build the source list at the approved source-candidate target,
-then clone only the bounded review batch into the campaign so we can inspect
-fit and messages before sending.
+**First pass:** build the source list, copy it into the campaign, then process
+only the first 15 leads so we can inspect quality before scaling.
 
 **Fallback:** if sampled/projected fit falls below 10%, or if the review batch
 is too vendor-heavy, agency-heavy, or off-ICP, switch to Sales Nav recent
@@ -245,7 +245,7 @@ authorizes. For Sales Nav/Prospeo it must also show source export math:
 `rawResultCount`, `sampledFitRate`, conservative projected fit rate,
 `targetLeadCount` for the source list, and projected good-fit count from that
 export. If projected good-fit count is below target, the recommendation is to
-refine or broaden filters, not to import a 25-row batch.
+refine or broaden filters, not to run a 15-row review sample.
 
 Supplied profile CSVs, company/domain CSVs, pasted domains, and existing
 Sellable lead lists are supported, but keep provider mechanics out of the first
@@ -253,7 +253,7 @@ customer-facing source-choice labels.
 
 ## Post-Lead Workstreams
 
-After `confirm_lead_list` imports a non-empty bounded review batch and
+After `confirm_lead_list` copies a non-empty confirmed source into the campaign and
 `get_rows_minimal({ tableId: workflowTableId })` proves rows exist, ask the
 filter-choice question immediately. Do not call
 `get_post_find_leads_scout_registry`, load filter/message subskill prompts, or
@@ -271,11 +271,12 @@ are optional only.
 When the user chooses filters, immediately call
 `update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
 before rubric thinking or branch work. The watched app should move to Filter
-Rules quickly. After `save_rubrics`, the watched app should move to
-`apply-icp-rubric` / Filter Leads so the user can see the saved filters are
-ready and wait there for the background message agent. Tell the user explicitly
-that a message agent is drafting the first-message template while enrichment,
-filtering, and Generate Message cells remain blocked.
+Rules quickly. After `save_rubrics`, keep the app on Filter Rules so the user
+can read and approve the saved criteria. Only after that approval should
+`update_campaign` move to `apply-icp-rubric` / Filter Leads, where the run waits
+for the message template approval before enrichment, filtering, or Generate
+Message cells are queued. Tell the user the Message Draft Builder is preparing
+the template in the background.
 
 Lead Fit Builder persists production rubrics with `save_rubrics` when filters
 are enabled. It must not require `brief.md`, `lead-review.md`, or
@@ -311,11 +312,11 @@ state before drafting. Do not render message review until
 
 Load references only when needed:
 
-- `references/watch-link-handoff.md` for watch-link recovery and handoff copy.
-- `references/watch-guide-narration.md` for watched-step narration.
+- `references/watch-link-handoff.md` for watch-link handoff.
+- `references/watch-guide-narration.md` for watch narration.
 - `references/lead-validation-preview.md` for legacy/debug preview shapes.
 - `references/filter-leads.md` for rubric design and `save_rubrics` rules.
-- `references/step-13-import-leads.md` before review-batch import.
+- `references/step-13-import-leads.md` before source copy.
 - `references/sample-validation-loop.md` before review-batch validation.
 - `references/final-handoff-contract.md` for Settings, sender, sequence, and
   start.

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

@@ -51,9 +51,11 @@ turn anchored to that:
 3. Turn that into a campaign brief and create the watchable campaign shell.
 4. Ask for brief approval before any lead import or sending-adjacent work.
 5. Find likely responders and approve the source.
-6. Import only the bounded review batch.
+6. Copy the confirmed source list into the campaign and use the first 15 rows as
+   the review/process sample.
 7. Filter for fit and draft the reusable message template from the same sample.
-8. Ask for message approval before queueing the review-batch cascade.
+8. Queue the bounded fit cascade from saved rubrics/run conditions only after the
+   message template is approved.
 9. Use Settings for sender selection, sequence attach, and final launch handoff.
 
 Approvals only feel safe when the user can see what they are approving. Before
@@ -81,12 +83,13 @@ example, like `omit the noticed... line` or `use "operators"`. Missing data
 should never produce robotic or creepy copy.
 
 Approved token guidance is part of the campaign, not just the review. After the
-bounded review batch exists and message generation has a selected template, the
-campaign brief should carry forward the token fill rules and examples before any
+first review/process sample exists and message generation has a selected
+template, the campaign brief should carry forward the token fill rules and examples before any
 workflow-table cascade is queued: good fills, good omits, bad fills, fallback
 rules, and why the bad fills are blocked.
 The campaign brief must carry forward the token fill rules from review into the
-live campaign state before enrichment, filtering, or Generate Message cells run.
+live campaign state before enrichment, filtering, Generate Message cells, sender
+setup, sequence attach, or launch.
 
 ## Progress Updates
 
@@ -275,17 +278,17 @@ surface install status to the customer.
 
 For post-lead work, call `get_post_find_leads_scout_registry` after
 the user chooses filters, not before the filter-choice question. After
-`confirm_lead_list` imports a non-empty bounded review batch and
-`get_rows_minimal` proves rows exist, ask add-filters vs skip-filters
+`confirm_lead_list` copies source rows and `get_rows_minimal` proves the first
+review/process sample exists, ask add-filters vs skip-filters
 immediately. Once the user answers, start `post-find-leads-message-scout` /
 message generation from the same campaign/table basis. If the user chooses
 filters, also start `post-find-leads-filter-scout`, move the browser to Filter
-Rules, save rubrics, then keep the browser on Filter Leads while the message
-recommendation is reviewed. If the user skips filters, move the browser to
-Messages/message review. The join gate is live branch readiness: saved rubrics
-or a resolved skip-filter choice, plus a message recommendation grounded in the
-same campaign/table basis. Enrichment, filtering, and product Generate Message
-cells still wait for template approval.
+Rules, save rubrics, then ask for filter approval. After approval, keep the
+browser on Filter Leads while the message recommendation is reviewed. If the user
+skips filters, move the browser to Messages/message review. The join gate is
+saved-filter approval or a resolved skip-filter choice, plus a message
+recommendation grounded in the same campaign/table basis. Enrichment, filtering,
+and Generate Message cells wait for template approval on the Use Template path.
 
 Only promise parallel post-lead work when parallel work actually started. If the
 host cannot or should not launch background branches, say the real sequence:

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

@@ -11,19 +11,19 @@ autonomous tail (Step 13, `auto-execute-leads`). All subsequent steps (14
 validate-sample, 15 auto-execute-messaging, 16 awaiting-user-greenlight)
 read the already-parsed config; they do not re-load the YAML mid-run.
 
-Config values are NOT written to DB. They live on the skill side and
-influence tool arguments (e.g. `importLimit` flows into `import_leads`
-`targetLeadCount` arg, `sampleSize` flows into the first N rows pulled from
-the imported review batch for validation).
+Config values are NOT written to DB. They live on the skill side and influence
+tool arguments (e.g. `importLimit` / `sampleSize` controls the first N
+review/process rows after `confirm_lead_list` copies the confirmed source rows
+into the campaign).
 
 ## Sections
 
 ### `import`
 
-- **`importLimit`** — Review-batch size imported in Step 13. The tail MUST
-  NOT exceed this cap before the user reviews the first batch and explicitly
-  approves expansion. If the user wants 250 leads, run a later expansion step;
-  do not spend credits on all 250 during the default approval tail.
+- **`importLimit`** — Review/process sample size used after Step 13 copies the
+  confirmed source rows into the campaign. The tail MUST NOT exceed this cap
+  before the message template is approved and at least one generated passing
+  message is reviewed.
 - **`provider`** — Inherited from the Phase 84 commit decision (saved in
   the committed brief / campaign metadata). Present here so the tail can
   narrate which provider it's running against; it does NOT override the
@@ -31,19 +31,18 @@ the imported review batch for validation).
 
 ### `sample`
 
-- **`sampleSize`** — How many rows the validation loop pulls from the
-  imported review batch. In v2 this matches the review-batch cap
-  (default 25), so the user sees enough real rows to judge the campaign
-  without spending credits on hundreds more.
+- **`sampleSize`** — How many rows the validation loop pulls from the first
+  review/process sample. In v2 this matches the process cap (default 15), 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 5 passing examples from the 25-row review batch.
+  The default requires one passing example from the 15-row review sample.
   Math:
   ```text
   projectedPass = round(passInSample / sampleSize * importLimit)
   ```
-  With defaults (sampleSize=25, importLimit=25), `projectedPass` equals
-  the actual review-batch pass count. 5 passing rows is exactly at the
-  floor.
+  With defaults (sampleSize=15, importLimit=15), `projectedPass` equals the
+  actual review sample pass count. One passing row 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
   and retried. On stale resume the counter does NOT reset.
@@ -128,7 +127,7 @@ logs and adjust:
 
 - `importLimit` higher only if users consistently ask for larger review
   batches and credit spend is acceptable.
-- `sampleSize` higher if a 25-row review batch is not enough to judge
+- `sampleSize` higher if a 15-row review sample is not enough to judge
   quality for a specific market.
 - `minProjectedPass` lower only if fewer than 3 passing examples is still
   enough for a confident user decision.