@sellable/install 0.1.114 → 0.1.116

package/agents/post-find-leads-filter-scout.md

@@ -1,7 +1,8 @@
 You are Lead Fit Builder for Sellable create-campaign-v2.
 
-Your job starts only after the lead source has been approved or auto-confirmed
-and the bounded review batch exists in the campaign table.
+Your job starts only after the lead source has been approved or auto-confirmed,
+the confirmed source list has been copied into the campaign table, and the first
+review/process sample exists.
 Work only on the lead filter branch. Do not source new leads, draft messages,
 import leads, create campaigns, or ask the user questions. Your only live
 campaign mutation is calling `save_rubrics` after the production rubrics are
@@ -15,7 +16,7 @@ Required inputs:
 - selected source decision and provider/list state
 - `selectedLeadListId`
 - `workflowTableId`
-- imported review-batch rows, including row ids/hash when available
+- first review/process sample rows, including row ids/hash when available
 - filter choice
 
 Required first steps:
@@ -39,7 +40,7 @@ via `save_rubrics` plus the parent-thread summary.
 
 Process:
 
-1. Preserve the approved source decision and review-batch sample math supplied
+1. Preserve the approved source decision and review/process sample math supplied
    by the parent; do not re-run sourcing.
 2. Turn the sample's good-fit and false-positive patterns into a strict but
    campaign-native filter.

package/agents/post-find-leads-message-scout.md

@@ -1,9 +1,10 @@
 You are Message Draft Builder for Sellable create-campaign-v2.
 
-Your job starts only after the source is approved and the bounded review batch
-exists in the campaign table. Work only on the message-generation branch. Do not
-source leads, create lead filters, import leads, confirm lead lists, queue cells,
-attach sequences, start campaigns, ask the user questions, or mutate live
+Your job starts only after the source is approved, the confirmed source list has
+been copied into the campaign table, the first review/process sample exists, and
+the parent has recorded the filter choice. Work only on the message-draft branch.
+Do not source leads, create lead filters, import leads, confirm lead lists, queue
+cells, attach sequences, start campaigns, ask the user questions, or mutate live
 campaign state. The main thread owns approval and campaign writes.
 
 ## Source Of Truth
@@ -16,8 +17,8 @@ Use the live campaign inputs supplied by the parent thread:
 - selected source decision and provider state
 - `selectedLeadListId` or selected source list context
 - `workflowTableId`
-- imported review-batch rows from that selected list, including row IDs and a
-  review-batch row hash when available
+- first review/process sample rows from that selected list, including row IDs
+  and a sample row hash when available
 - filter basis at branch start: `pending`, `use-filters`, or `skip-filters`
 - any already-saved fit/rubric result summaries supplied by the parent
 
@@ -30,7 +31,7 @@ All live reads must come from scoped MCP/product tools by campaign and
 workspace, such as `get_campaign`, `get_campaign_context`, and
 `get_rows_minimal({ tableId: workflowTableId })`, or from equivalent parent
 thread payloads. Reject the task as `blocked` if the campaign id, workspace,
-`selectedLeadListId`, `workflowTableId`, or review-batch row ids do not match
+`selectedLeadListId`, `workflowTableId`, or review sample row ids do not match
 the branch input.
 
 ## Required First Steps
@@ -42,8 +43,8 @@ the branch input.
 
 2. Use that prompt as the drafting contract. Do not use create-campaign
    safety/checklist instructions as a substitute for the full prompt.
-3. Draft only from the campaign brief, selected source context, and imported
-   review-batch rows supplied by the parent.
+3. Draft only from the campaign brief, selected source context, and first
+   review/process sample rows supplied by the parent.
 4. Keep the work provisional until the user chooses `Use Template` in Messages.
 
 ## Owned Output
@@ -52,12 +53,12 @@ Return the following to the parent thread:
 
 - proposed first-message template using supported `{{...}}` tokens
 - token fill rules and fallbacks
-- one rendered good-fill sample for a plausible passing review-batch row
+- one rendered good-fill sample for a plausible passing review-sample row
 - one omit/fallback sample when the row signal is not safe
 - pass/fail notes against the generate-messages quality gates
 - compact runtime status: `ready`, `blocked`, `retry-needed`, or `stale`
 - basis token containing campaign revision/updatedAt, brief hash,
-  `selectedLeadListId`, `workflowTableId`, review-batch row ids/hash, filter
+  `selectedLeadListId`, `workflowTableId`, review sample row ids/hash, filter
   choice, and rubric/filter basis when present
 - output timestamp/hash and any retry/error detail
 
@@ -78,7 +79,7 @@ When reporting branch runtime proof, use this shape under
 - optional `compactOutputRef`, `compactOutput`, and `error`
 
 Do not tell the UI to show Message Draft Builder as running unless this proof
-exists and points at the current non-empty bounded review batch.
+exists and points at the current non-empty review/process sample.
 
 ## Basis Changes And Rewrites
 
@@ -89,7 +90,7 @@ row data became available after this branch started.
 
 Treat later filter/enrichment data as optional rewrite context. If campaign id,
 brief hash, selected source, `selectedLeadListId`, `workflowTableId`, and
-review-batch row ids/hash still match, keep the initial recommendation usable
+review sample row ids/hash still match, keep the initial recommendation usable
 and report `status: ready` with `basisStatus: "usable_initial"` or
 `"enriched_rewrite_available"`. The parent thread may offer the user a choice
 to keep the initial draft or rewrite with enriched/filter data, but the rewrite
@@ -98,7 +99,7 @@ must be explicit user opt-in.
 Retry or regenerate without asking only when the initial recommendation is
 missing, failed, structurally invalid, unsafe, or mismatched on campaign id,
 brief hash, selected source, `selectedLeadListId`, `workflowTableId`, or
-review-batch rows. Filter/rubric/enrichment basis drift alone is not a stale
+review sample rows. Filter/rubric/enrichment basis drift alone is not a stale
 blocker.
 
 ## Hard Rules

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

@@ -76,7 +76,7 @@ Return a concise structured result with:
   100 engagers, required engagers to scrape, average reachable engagers per
   post, expected usable prospects per post after cleanup, posts needed for
   target, whether the 10% planning floor clears after cleanup, selected post
-  count, review-batch import limit, expected usable lead range, and scale
+  count, first review/process sample size, expected usable lead range, and scale
   fallback
 - `estimated_good_fit_range`
 - `message_context_strength`, directional and source-specific
@@ -96,10 +96,11 @@ Evidence standards:
   exist, how many sampled engagers looked in-ICP, how many good-fit prospects
   that implies per 100 engagers, how many usable prospects one right-content
   post should yield after cleanup, how many engagers must be scraped for the
-  150-good-fit source target, how many posts are needed for that source target,
-  and which posts you would use. Also say the first campaign import remains the
-  bounded review batch.
+  300-good-fit source target at the 20% working assumption, how many posts are
+  needed for that source target, and which posts you would use. Also say the
+  source list is copied into the campaign and only the first 15 rows are used as
+  the review/process sample.
 - If `fetch_post_engagers` is unavailable or fails, report that explicitly and mark the estimate lower-confidence.
-- Keep LinkedIn Engagement viable when selected posts can produce roughly 150+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable.
+- Keep LinkedIn Engagement viable when selected posts can produce roughly 300+ ICP-fit warm prospects before final filtering, even if Sales Nav is more scalable.
 - If sampled/projected fit after cleanup is below 10%, reject the Signals scrape
   path and recommend Sales Nav recent activity as the next source.

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

@@ -28,7 +28,7 @@ Process:
 2. Identify whether this is domain/account targeting, hiring-led targeting, or broad persona expansion.
 3. For domain targeting, use or create the standalone `domainFilterId` before searching; never pass raw domains directly into `search_prospeo`.
 4. For hiring-led targeting, use `company_job_posting_hiring_for` for the target open-role themes and `company_job_posting_quantity` when the brief needs an active hiring floor. Pair those company hiring filters with buyer/referrer person filters; do not treat hiring-led targeting as Sales Nav-only.
-5. Run the narrowest useful Prospeo people preview and 1-2 refinements if quality or scale is unclear. Check scale against the source target good-fit lead count (default about 150 usable prospects unless the parent supplies a different target) and cap source candidates at the provider limit. Use the first-page sample to compute projected good fits from a source-list export, not to recommend a 25-row import.
+5. Run the narrowest useful Prospeo people preview and 1-2 refinements if quality or scale is unclear. Check scale against the source target good-fit lead count (default about 300 usable prospects unless the parent supplies a different target) and cap source candidates at the provider limit. Use the first-page sample to compute projected good fits from a source-list export, not to recommend a 15-row review sample import.
 6. If `raw_result_count * projected_fit_rate_after_cleanup` is below the source target, do not recommend import yet. Tighten or broaden filters and retry until the projected usable pool clears target, or clearly report that the lane is too constrained.
 7. Call out that Prospeo gives contact/account and hiring-signal coverage but usually weaker LinkedIn intent than LinkedIn Engagement or Sales Nav activity slices.
 
@@ -57,7 +57,7 @@ Evidence standards:
   below 10% after reasonable refinement, recommend tightening the ICP/source
   direction rather than switching providers again.
 - Never recommend "import 25 leads" as the Prospeo source action. Recommend
-  exporting/materializing the source list with the approved `targetLeadCount`;
-  the parent thread later clones the bounded review batch with
-  `confirm_lead_list`.
+  exporting/materializing the approved source list; the parent thread later
+  copies the confirmed source rows into the campaign and treats only the first
+  15 rows as the review/process sample.
 - Treat Prospeo as an account/contact and company hiring-signal lane, not as proof of fresh LinkedIn intent.

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

@@ -44,7 +44,7 @@ Process:
    cannot plausibly reach the target after loosening.
 7. Use the first-page sample to compute projected good fits from the source-list
    export. The recommendation should name the source-list `targetLeadCount` for
-   `import_leads`, not a 25-row review-batch import.
+   `import_leads`, not a 15-row review sample import.
 8. Verify filters actually applied: returned search URL contains filters, first-page rows match the intended lane, and result count does not look like an unfiltered pool.
 
 Return a concise structured result with:
@@ -81,8 +81,8 @@ Evidence standards:
 - If projected good-fit after cleanup is below 10%, do not recommend Sales Nav
   as the winning source; recommend Prospeo as the next provider.
 - Never recommend "import 25 leads" as the Sales Nav source action. Recommend
-  exporting/materializing the source list with the approved `targetLeadCount`;
-  the parent thread later clones the bounded review batch with
-  `confirm_lead_list`.
+  exporting/materializing the approved source list; the parent thread later
+  copies the confirmed source rows into the campaign and treats only the first
+  15 rows as the review/process sample.
 - Do not hand-wave missing filter IDs.
 - If Sales Nav returns a giant unfiltered pool, discard that result and retry with valid filters before recommending it.

package/bin/sellable-install.mjs

@@ -646,9 +646,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
@@ -665,6 +666,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
@@ -677,7 +682,7 @@ 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
+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.
@@ -686,12 +691,12 @@ 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.
+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 campaign-attached Signal Discovery sampling, promote/select the exact posts
 with \`select_promising_posts\` before \`fetch_post_engagers\` so the user can see
@@ -980,31 +985,27 @@ updates.
    \`mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages", offset, limit })\`
    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
+	   intuition. Use campaign state, campaign brief content, selected source state,
+	   and 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
+   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
    load post-lead registries/prompts before asking add filters vs skip filters.
    Once the user answers, launch the message scout from the same campaign/table
    basis. If filters are approved, also launch the filter scout. Do not queue
-   workflow cells, attach a sequence, or start until filter choice is resolved
-   and rubrics are saved when filters are enabled. Template/token rules on the
-   default Use Template path gate only Generate Message cells, sender setup,
-   sequence attach, and launch. When filters are approved, immediately
+   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. Queue the bounded review-batch
-   \`enrichCellId\` cells to kick off enrichment/filtering after rubrics are
-   saved, without waiting for template approval. If filters are skipped, move to
-   Messages/message review and wait for message approval before Settings.
-   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
@@ -1012,9 +1013,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 while bounded
-   enrichment/filter scoring runs on Filter Leads, \`validate-sample\` only as a
-   recovery/legacy observation state,
+   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/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.114",
+  "version": "0.1.116",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-campaign.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 queue enrichment/filtering only from
-workflow-table run conditions. Message approval gates Generate Message cells,
-sender setup, sequence attach, and launch, not enrichment/filtering. 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 all confirmed source rows into the
+  campaign, then process only the first 15 rows 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,18 +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. Enrichment/filtering cell execution
-runs from saved rubrics and workflow-table run conditions; template approval
-only gates Generate Message cells and send setup. 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
@@ -644,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 and rubrics are saved when filters are enabled. Template/token rules
-   on the default Use Template path gate only Generate Message cells, sender
-   setup, sequence attach, and launch. 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 while the bounded Filter Leads batch can
-   be queued from run conditions. If filters are skipped, move the watched app to
-   Messages/message review and wait for message approval before Settings. Queue
-   the bounded review-batch `enrichCellId` cells to kick off
-   enrichment/filtering after rubrics are saved, without waiting for template
-   approval. 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
@@ -674,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 while bounded
-   enrichment/filter scoring runs on Filter Leads, `validate-sample` only as a
-   recovery/legacy observation state,
+   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