@sellable/mcp 0.1.206 → 0.1.208

package/README.md

@@ -264,36 +264,25 @@ Parallel execution contract:
 
 - Source scout names come from `agents/registry.json` and are exposed at runtime
   through `get_source_scout_registry`. Add new scouts there first; installer,
-  Codex config, Claude agent files, and prompts should consume the registry.
-- Post-find-leads scout names also come from `agents/registry.json` and are
-  exposed through `get_post_find_leads_scout_registry`. After
-  `confirm_lead_list` imports a non-empty review batch and rows are proven, ask
-  the filter-choice question immediately. Do not load this registry or deep
-  filter/message prompts before that question. Once the user answers, launch the
-  message-generation scout from the same campaign/table basis. If the user
-  chooses filters, also launch the filter-leads scout, show Filter Rules, save
-  rubrics, then ask for filter approval. After approval, move to Filter Leads
-  and show `Filters saved + waiting for message approval` while the message
+  Codex config, Claude agent files, and prompts can consume the registry for
+  explicit source-comparison/debug runs. Normal create-campaign source work
+  stays inline in the parent thread with the active provider MCP tools.
+- `get_post_find_leads_scout_registry` returns only the Message Drafting worker
+  for normal create-campaign runs. After `confirm_lead_list` imports a non-empty
+  review batch and rows are proven, ask the filter-choice question immediately.
+  Do not load this registry or deep filter/message prompts before that question.
+  Once the user answers, launch Message Drafting from the same campaign/table
+  basis. If the user chooses filters, keep filter/rubric work in the parent
+  thread: show Filter Rules, load `references/filter-leads.md`, save rubrics,
+  then ask for filter approval. After approval, move to Filter Leads and show
+  `Filters saved + waiting for message approval` while the message
   recommendation is reviewed. If filters are skipped, move to Messages/message
   review. Enrichment/filtering and Generate Message cells wait for message
   approval.
-- Claude host: use the installed `source-scout-linkedin-engagement`,
-  `source-scout-sales-nav`, and `source-scout-prospeo-contact` Task/Agent
-  subagents for parallel lead-source scouting only when the current session
-  exposes those agent names. Launch all credible lanes in one assistant message
-  so Claude Code can run them concurrently/background.
-- Codex host: use named custom scouts for source-angle work when subagents are
-  available: `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
-  `source-scout-prospeo-contact`. Use `multi_tool_use.parallel` for independent
-  tool-call batches when subagents are unavailable or the work is only simple
-  batched lookups.
-- For prospect setup, Codex/Claude should launch Prospect Filters
-  (`post-find-leads-filter-scout`) and Message Drafting
-  (`post-find-leads-message-scout`) in the same turn/message when those
-  subagents are available in the current session.
-  If not, run them sequentially with MCP tools/assets, do not surface install
-  status to the customer, and do not claim parallel work.
-- If neither backend is available, run sequentially with the same output schema.
+- Source scouts and Prospect Filters are not normal create-campaign background
+  agents. Only Message Drafting may spawn as a background/custom agent on the
+  normal path; if it cannot be launched and the user does not approve inline
+  fallback, stop instead of silently drafting in the parent thread.
 
 Config path resolution (in order):
 

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

@@ -21,12 +21,14 @@ Use the live campaign inputs supplied by the parent thread:
 
 - `campaignId`
 - campaign revision or `campaignUpdatedAt`
-- `campaignBrief` / campaign brief content model
+- campaign brief summary from the parent, then the current `campaignBrief` /
+  campaign brief content loaded through Sellable tools
 - selected source decision and provider state
 - `selectedLeadListId` or selected source list context
 - `workflowTableId`
-- initial campaign-table execution slice rows from that selected list, including row IDs
-  and a sample row hash when available
+- compact initial campaign-table execution-slice basis: copied source row count,
+  review-batch row count, and review-batch basis/hash. Do not require the
+  parent to paste a long review-batch row-id list.
 - filter basis at branch start: `pending`, `use-filters`, or `skip-filters`
 - any already-saved fit/rubric result summaries supplied by the parent
 
@@ -38,22 +40,34 @@ read stale local markdown files to reconstruct campaign state.
 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 execution-slice row ids do not match
-the branch input.
+thread payloads. Load the current campaign brief and the current review-batch
+rows from those tools before drafting. Reject the task as `blocked` if the
+campaign id, workspace, `selectedLeadListId`, `workflowTableId`, review-batch
+row count, or review-batch basis/hash does not match the branch input.
 
 ## Required First Steps
 
-1. Load the full normal-path message prompt:
+1. Load the current campaign brief and compact campaign/table state:
+   campaign name, `campaignId`, `selectedLeadListId`, `workflowTableId`,
+   copied source row count, review-batch row count, review-batch basis/hash,
+   selected source summary, filter choice, and parent-supplied brief summary.
+   Then read the current campaign/table state through scoped Sellable tools.
+   Do not ask the parent to paste row data or a long row-id list.
+2. Load the full normal-path message prompt:
 
    `get_subskill_prompt({ subskillName: "generate-messages" })`
 
-2. Use that prompt as the drafting contract. Do not use any alternate prompt,
-   examples-only shortcut, or create-campaign safety/checklist instructions as a
-   substitute for the full message prompt.
-3. Draft only from the campaign brief, selected source context, and initial
-   campaign-table execution slice rows supplied by the parent.
-4. Keep the work provisional until the user chooses `Use Template` in Messages.
+3. Load the reference assets required by that prompt's Reference Asset Loading
+   pack, including validation/QA criteria. If a required validation asset cannot
+   load, return `blocked` or `retry-needed` instead of drafting from memory.
+4. Use that prompt as the drafting and QA contract. Do not use any alternate
+   prompt, examples-only shortcut, or create-campaign safety/checklist
+   instructions as a substitute for the full message prompt.
+5. Draft only from the current campaign brief, selected source context, and
+   review-batch rows loaded through scoped Sellable tools.
+6. Run the normal message validation/QA rules before final return. The final
+   recommendation must include the QA pass/fail receipt, not just draft copy.
+7. Keep the work provisional until the user chooses `Use Template` in Messages.
 
 ## Owned Output
 
@@ -64,10 +78,12 @@ Return the following to the parent thread:
 - one rendered good-fill sample for a plausible passing campaign-table row
 - one omit/fallback sample when the row signal is not safe
 - pass/fail notes against the generate-messages quality gates
+- `qaReceipt` / validation notes showing token safety, proof safety, fit
+  uncertainty, bad-fill avoidance, and "would I take this call?" judgment
 - message-draft runtime status: `ready`, `blocked`, `retry-needed`, or `stale`
 - basis token containing campaign revision/updatedAt, brief hash,
-  `selectedLeadListId`, `workflowTableId`, execution-slice row ids/hash, filter
-  choice, and rubric/filter basis when present
+  `selectedLeadListId`, `workflowTableId`, compact execution-slice row
+  count/hash, filter choice, and rubric/filter basis when present
 - output timestamp/hash and any retry/error detail
 
 Do not write local markdown/json artifacts in normal live campaign runs. Return
@@ -98,7 +114,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
-execution-slice row ids/hash still match, keep the initial recommendation usable
+execution-slice row count/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
@@ -107,9 +123,32 @@ 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
-execution-slice rows. Filter/rubric/enrichment basis drift alone is not a stale
+execution-slice row count/hash. Filter/rubric/enrichment basis drift alone is not a stale
 blocker.
 
+## User Revision Feedback And QA
+
+If the parent sends user feedback, a QA request, or a rewrite request about the
+template before `approve-message`, treat it as Message Drafting work, not a
+campaign write. Use the current `messageDraftRecommendation`, basis token/hash,
+campaign/table basis, and latest user feedback as inputs. Load or reuse the full
+`generate-messages` contract and validation assets, then return a revised or
+QA-only recommendation with:
+
+- revised proposed template
+- what changed and why
+- token fill rule/fallback changes, if any
+- one rendered good-fill sample
+- `qaReceipt` with pass/fail notes against the loaded validation assets
+- pass/fail notes against the same quality gates
+- updated output timestamp/hash and basis token
+
+Keep the revision grounded in the same source/list/table rows unless the parent
+explicitly supplies a new selected list or review slice. Do not call
+`update_campaign_brief`, do not persist the template, and do not approve your
+own revision. The parent renders the revised template and waits for
+`approve-message`.
+
 ## Hard Rules
 
 - Do not call product Generate Message cells. This worker drafts the template

package/dist/tools/prompts.d.ts

@@ -86,7 +86,7 @@ export interface SourceScoutRegistryResponse {
 }
 export interface PostFindLeadsScoutRegistryResponse {
     version: number;
-    trigger: "find_leads_source_approved";
+    trigger: "message_drafting_after_confirm_lead_list";
     requiredInputs?: string[];
     scouts: Array<{
         id: string;

package/dist/tools/prompts.js

@@ -147,7 +147,7 @@ export const promptToolDefinitions = [
     },
     {
         name: "get_source_scout_registry",
-        description: "Return the canonical Sellable source-scout agent names and host filenames. Use this before the source-finding step so Codex and Claude can launch the same named scouts from one registry when the current host exposes them.",
+        description: "Return the canonical Sellable source-scout agent names and host filenames for explicit source-comparison/debug runs only. Normal create-campaign source work stays inline in the parent thread.",
         inputSchema: {
             type: "object",
             properties: {},
@@ -157,7 +157,7 @@ export const promptToolDefinitions = [
     },
     {
         name: "get_post_find_leads_scout_registry",
-        description: "Return canonical Sellable prospect-setup worker names for Prospect Filters and Message Drafting after Start Import copies confirmed source rows.",
+        description: "Return the canonical Sellable Message Drafting worker name after Start Import copies confirmed source rows. Prospect filters stay inline in the parent thread in normal create-campaign runs.",
         inputSchema: {
             type: "object",
             properties: {},
@@ -257,25 +257,26 @@ export function getSourceScoutRegistry() {
             legacy: agent.legacy,
         })),
         usage: {
-            codex: "Source finding is sequential by default. Launch multiple returned `name` values in one assistant turn only when the user asked for comparison, a prior lane failed, or the active flow marks the first lane borderline.",
-            claude: "Source finding is sequential by default. Invoke multiple Task/Agent subagents with subagent_type equal to returned `name` values only when comparison, fallback, or borderline-source conditions apply.",
-            parentThreadRule: "Named agents are optional acceleration. If they are absent, do not customer-surface install status; run the same provider probes with MCP tools from the parent thread. Default fallback order: Signal Discovery / LinkedIn engagement, then Sales Nav recent activity, then broader Sales Nav title search, then Prospeo account/contact search. Do not preload every provider prompt before spawning agents; each scout loads only the provider prompt for its lane.",
+            codex: "Source finding is parent-thread and sequential by default in create-campaign. Do not launch source scouts in the normal campaign flow. Returned `name` values are for explicit source-comparison/debug runs only.",
+            claude: "Source finding is parent-thread and sequential by default in create-campaign. Do not invoke source-scout Task/Agent workers in the normal campaign flow. Returned `name` values are for explicit source-comparison/debug runs only.",
+            parentThreadRule: "Normal create-campaign source work stays inline in the parent thread with MCP provider tools. Default fallback order: Signal Discovery / LinkedIn engagement, then Sales Nav recent activity, then broader Sales Nav title search, then Prospeo account/contact search. Do not preload every provider prompt; load only the provider prompt for the active sequential source.",
         },
     };
 }
 export function getPostFindLeadsScoutRegistry() {
     const registry = readAgentRegistry();
-    const scouts = registry.agents.filter((agent) => String(agent.kind || "") === "post-find-leads-scout");
+    const scouts = registry.agents.filter((agent) => String(agent.kind || "") === "post-find-leads-scout" &&
+        String(agent.target || agent.id || "") === "generate-messages");
     return {
         version: registry.version,
-        trigger: "find_leads_source_approved",
+        trigger: "message_drafting_after_confirm_lead_list",
         requiredInputs: [
             "campaignId",
             "campaign revision or campaignUpdatedAt",
             "campaignBrief",
             "source decision and selectedLeadList/source state",
             "workflowTableId",
-            "initial campaign-table execution slice rows from selectedLeadList with row ids/hash",
+            "compact review-batch row count and basis/hash; branch reads rows through scoped tools",
             "filter choice and filter/rubric basis when present",
         ],
         scouts: scouts.map((agent) => ({
@@ -305,10 +306,10 @@ export function getPostFindLeadsScoutRegistry() {
         })),
         joinGate: {
             afterAllComplete: true,
-            requiredState: ["leadScoringRubrics", "messageDraftRecommendation"],
+            requiredState: ["messageDraftRecommendation"],
             noFilterRequiredState: ["messageDraftRecommendation"],
             skipFilterRule: "leadScoringRubrics may be absent only when the user explicitly skips filters with enableICPFilters=false; messageDraftRecommendation is still required before template review.",
-            show: ["readable_filters_with_reasons", "sample_message_for_approval"],
+            show: ["sample_message_for_approval", "message_qa_receipt"],
             nextStage: "message-review",
         },
         messageDraftBranchContract: {
@@ -328,15 +329,16 @@ export function getPostFindLeadsScoutRegistry() {
                 "basisToken",
                 "basis.selectedLeadListId",
                 "basis.workflowTableId",
-                "basis.reviewSampleRowHash or basis.reviewSampleRowIds",
+                "basis.reviewSampleRowCount",
+                "basis.reviewSampleRowHash",
             ],
-            promptRequired: 'get_subskill_prompt({ subskillName: "generate-messages" }); the full generate-messages prompt and its Reference Asset Loading pack are required inside the Message Drafting branch for normal message drafting. If required assets cannot be loaded, return blocked/retry-needed instead of drafting from prompt memory.',
+            promptRequired: 'Load current campaign brief/table state through scoped tools, then get_subskill_prompt({ subskillName: "generate-messages" }); the full generate-messages prompt and its Reference Asset Loading pack, including message validation/QA assets requested by that prompt, are required inside the Message Drafting branch for normal drafting, QA, and user-requested rewrites. If required assets cannot be loaded, return blocked/retry-needed instead of drafting from prompt memory.',
             basisFields: [
                 "campaign revision or updatedAt",
                 "brief hash",
                 "selectedLeadListId",
                 "workflowTableId",
-                "initial campaign-table execution slice row ids/hash",
+                "compact initial campaign-table execution slice row count/hash",
                 "filter choice",
                 "filter/rubric basis when present",
             ],
@@ -345,19 +347,21 @@ export function getPostFindLeadsScoutRegistry() {
                 "tokenFillRules",
                 "renderedSample",
                 "concerns",
+                "revisionNotes when user feedback triggered a revision",
                 "status",
                 "basisStatus",
                 "basisToken",
+                "qaReceipt or validationNotes",
                 "outputAt",
                 "outputHash",
                 "error or retry detail",
             ],
-            reusePolicy: "The first completed Message Drafting recommendation remains the default review candidate. Later Prospect Filters, Filter Leads, enrichment, or rubric completion may make an enriched rewrite available, but does not automatically retry or replace the initial draft unless campaign/brief/source/list/table/review-sample identity mismatches or the initial output failed.",
+            reusePolicy: "The first completed Message Drafting recommendation remains the default review candidate. Later Prospect Filters, Filter Leads, enrichment, or rubric completion may make an enriched rewrite available, but does not automatically retry or replace the initial draft unless campaign/brief/source/list/table/review-sample identity mismatches or the initial output failed. User copy feedback before approve-message is an explicit Message Drafting revision and must be routed back through the message branch with the current recommendation and basis.",
         },
         usage: {
-            codex: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not spawn returned prospect-setup worker names before that question. Once the user answers, spawn Message Drafting from the same campaign/table basis whenever Codex agent-launch policy is satisfied. Treat YOLO/autonomous mode as campaign-scoped permission to use Sellable background agents for pre-launch work. If the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once for permission before loading generate-messages in the parent. If permission is granted and the named custom agent is unavailable, spawn a generic gpt-5.5 xhigh background agent with the same campaign/table basis. If the user chooses filters, also spawn Prospect Filters when allowed, move to Filter Rules, save rubrics, ask for filter approval, then keep the browser on Filter Leads and show `Filters saved + waiting for message approval` while the message recommendation is reviewed. If filters are skipped, move to Messages/message review.",
-            claude: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not invoke returned prospect-setup Task/Agent names before that question. Once the user answers, invoke Message Drafting from the same campaign/table basis. If the user chooses filters, also invoke Prospect Filters, move to Filter Rules, save rubrics, ask for filter approval, then keep the browser on Filter Leads and show `Filters saved + waiting for message approval` while the message recommendation is reviewed. If filters are skipped, move to Messages/message review.",
-            parentThreadRule: 'Message drafting is agent-first, not optional acceleration. If post-find-leads-message-scout is available, run that compatibility agent as background Message Drafting after the filter-choice answer. In Codex, YOLO/autonomous mode counts as campaign-scoped permission to use Sellable background agents for pre-launch work; if the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once for that permission before loading generate-messages in the parent. If permission is granted and the named custom agent is unavailable, spawn a generic gpt-5.5 xhigh background agent with the same campaign/table basis. Do not silently fall back to parent-thread message drafting. The parent may run the message branch inline only if the user explicitly says to continue without a background agent; when doing so, state that message generation is running inline. Local markdown/json files are not normal-path inputs. The filter-choice question is the first post-import user gate; do not load prospect-setup registries or filter references before it. Message drafting starts after the filter-choice answer, must load get_subskill_prompt({ subskillName: "generate-messages" }) and its Reference Asset Loading pack inside the branch or explicitly approved inline fallback, must read live campaign table state through scoped MCP/product tools, and must reject mismatched selectedLeadListId/workflowTableId/campaign/workspace input. Do not use any alternate or examples-only message prompt. On the filter path, keep the browser on Filter Rules after save_rubrics so the user can approve the saved criteria; only then move to Filter Leads, show `Filters saved + waiting for message approval`, and wait there for message approval. Enrichment, filtering, Generate Message cells, sender setup, sequence attach, and launch wait for template approval on the Use Template path. On the skip path, move to Messages/message review and wait for message approval before enrichment or Settings. Do not render message review from checklist or shortcut instructions; message review requires a messageDraftRecommendation whose basis proves the generate-messages prompt ran for the current campaign/table execution slice. Do not automatically rerun Message Drafting after filters/enrichment finish; show the initial draft by default and offer an enriched rewrite only with explicit user opt-in.',
+            codex: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not spawn anything before that question. Once the user answers, spawn only Message Drafting from the same campaign/table basis whenever Codex agent-launch policy is satisfied. Treat YOLO/autonomous mode as campaign-scoped permission for this single message background agent. If the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once for permission before loading generate-messages in the parent. If permission is granted and the named custom agent is unavailable, spawn a generic gpt-5.5 xhigh Message Drafting background agent with the same campaign/table basis. If filters are chosen, do filter/rubric work inline in the parent thread while Message Drafting runs, then keep the browser on Filter Leads and show `Filters saved + waiting for message approval` while the message recommendation is reviewed. If filters are skipped, move to Messages/message review.",
+            claude: "After confirm_lead_list copies source rows and the initial campaign-table execution slice exists, ask the filter-choice question immediately. Do not invoke any Task/Agent before that question. Once the user answers, invoke only Message Drafting from the same campaign/table basis. If filters are chosen, do filter/rubric work inline in the parent thread while Message Drafting runs, then keep the browser on Filter Leads and show `Filters saved + waiting for message approval` while the message recommendation is reviewed. If filters are skipped, move to Messages/message review.",
+            parentThreadRule: 'Message Drafting is the only normal create-campaign background agent. If post-find-leads-message-scout is available, run that compatibility agent after the filter-choice answer so it works while the parent thread handles filter/rubric setup inline. In Codex, YOLO/autonomous mode counts as campaign-scoped permission for this single message background agent; if the user has not enabled YOLO and has not explicitly asked for background agents/subagents/parallel agents/delegation/message bg agent in this campaign, ask once for permission before loading generate-messages in the parent. If permission is granted and the named custom agent is unavailable, spawn a generic gpt-5.5 xhigh Message Drafting background agent with the same campaign/table basis. Do not spawn source scouts or Prospect Filters in the normal create-campaign flow. Do not silently fall back to parent-thread message drafting. The Message Drafting handoff must be compact: campaign identity/name, brief summary, source summary, selectedLeadListId, workflowTableId, copied source row count, review-batch row count/hash, and filter choice. Do not paste full reviewBatchRowIds, row data, or local debug artifacts into the spawn prompt; the branch must load the current campaign brief, campaign/table state, review rows, full generate-messages prompt, and validation/QA assets through scoped tools. The parent may run the message branch inline only if the user explicitly says to continue without a background agent; when doing so, state that message generation is running inline. Local markdown/json files are not normal-path inputs. The filter-choice question is the first post-import user gate; do not load this registry or filter references before it. Message drafting starts after the filter-choice answer, must load get_subskill_prompt({ subskillName: "generate-messages" }) and its Reference Asset Loading plus message validation/QA assets inside the branch or explicitly approved inline fallback, must read live campaign table state through scoped MCP/product tools, and must reject mismatched selectedLeadListId/workflowTableId/campaign/workspace input. Do not use any alternate or examples-only message prompt. User copy feedback, message QA, or rewrite requests before approve-message must be routed back to Message Drafting with the current recommendation, basis token, campaign/table basis, and latest user text; the parent must not rewrite or QA the template from memory and must not call update_campaign_brief before approve-message. On the filter path, the parent thread keeps the browser on Filter Rules after save_rubrics so the user can approve the saved criteria; only then move to Filter Leads, show `Filters saved + waiting for message approval`, and wait there for message approval. Enrichment, filtering, Generate Message cells, sender setup, sequence attach, and launch wait for template approval on the Use Template path. On the skip path, move to Messages/message review and wait for message approval before enrichment or Settings. Do not render message review from checklist or shortcut instructions; message review requires a messageDraftRecommendation whose basis proves the generate-messages prompt and QA assets ran for the current campaign/table execution slice. Do not automatically rerun Message Drafting after filters/enrichment finish; show the initial draft by default and offer an enriched rewrite only with explicit user opt-in.',
         },
     };
 }

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -248,25 +248,12 @@ summary should be a compact `## Source Recommendation` block with:
 - fallback: switch to active LinkedIn profiles if the first sample is too noisy
   or has too few prospects
 
-When the user has not supplied a source and multiple source angles are viable,
-scout those angles as independent branches when the host can actually do it:
-LinkedIn posts / people reacting or commenting (internal `signal-discovery`
-provider prompt), Sales Nav / title + company filters, and Prospeo Contact /
-domains, hiring filters, or broad verified-contact expansion when relevant. In
-Codex, explicitly spawn the named custom scouts
-`source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
-`source-scout-prospeo-contact` for the credible lanes only when the current host
-exposes those names; Codex does not infer subagent fan-out from generic source
-comparison wording. In Claude Code, invoke the generated `source-scout-*`
-Task/Agent subagents for all credible lanes in one assistant message only when
-the current session lists those names. The installer writes them from the same
-canonical Sellable agent registry with explicit Sellable MCP tool allowlists.
-The create-campaign-v2 subskill calls `get_source_scout_registry` before
-dispatch so the current registry, not this copy, is the runtime source of truth.
-If the host runs them sequentially or the named agents are unavailable, do not
-claim they ran in parallel and do not surface install status to the customer. In
-chat, call the downstream copy stage `message generation`; message validation is
-only an internal approval proof.
+Source discovery stays inline in the parent thread for normal create-campaign
+runs. Use the approved provider prompt and MCP tools sequentially; do not spawn
+source-scout background agents unless the user explicitly asks for a source
+comparison/debug run. Do not claim a scout ran unless one did, and do not surface
+install status to the customer. In chat, call the downstream copy stage
+`message generation`; message validation/QA is owned by Message Drafting.
 
 For campaign-attached Signal Discovery sampling, promote/select the exact posts
 with `select_promising_posts` before `fetch_post_engagers` so the user can see
@@ -279,20 +266,27 @@ math should import the smallest set that covers a target. The watch guide should
 say that we are checking people from these posts to confirm the right people are
 actually engaging and the source is viable.
 
-    After confirmed source rows exist in the campaign table, use the same registry pattern for
-
-prospect setup work, but do not load that registry or any deep filter/message prompt
+After confirmed source rows exist in the campaign table, do not load the
+message 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 Message Drafting
-from the same campaign/table basis. If the user chooses filters, also launch the
-Prospect Filters worker, move to Filter Rules, save rubrics, then ask for filter
-approval. After approval, move to Filter Leads and show `Filters saved + waiting
-for message approval` 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
-prospect setup agents are absent, the main thread still orchestrates the same
-branches from compact MCP context.
+vs skip filters immediately. Once the user answers, launch only Message Drafting
+from the same campaign/table basis. If the user chooses filters, the parent
+thread moves to Filter Rules, loads the filter reference, saves rubrics, then
+asks for filter approval while Message Drafting runs. After approval, move to
+Filter Leads and show `Filters saved + waiting for message approval` 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.
+
+The Message Drafting handoff must stay compact. Include campaign identity,
+campaign name, `selectedLeadListId`, `workflowTableId`, copied source row count,
+review-batch row count, review-batch basis/hash, filter choice, source summary,
+and a concise campaign brief summary. Do not paste the full review-batch row ID
+list or row data into the spawn prompt. Message Drafting must load the current
+campaign brief, campaign/table state, and review-batch rows through Sellable
+tools, then load the normal message validation/QA rules and run a QA pass before
+returning its concise review-ready recommendation.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
@@ -423,26 +417,19 @@ Treat host capabilities as concrete functions, not prose conventions:
 - `load_subprompt_asset`: call
   `mcp__sellable__get_subskill_asset({ subskillName, assetPath, offset?, limit? })`
   and continue chunks until `hasMore` is false.
-- `load_source_scout_registry`: call
-  `mcp__sellable__get_source_scout_registry({})` before any scout dispatch.
+- `load_source_scout_registry`: explicit source-comparison/debug runs only; do
+  not call it in the normal create-campaign source path.
 - `load_post_find_leads_scout_registry`: call
   `mcp__sellable__get_post_find_leads_scout_registry({})` after source
-  import and before dispatching Prospect Filters/Message Drafting.
-- `launch_source_scout`: Claude Code uses `Task` with `subagent_type` equal to
-  the registry `name` only when the session lists those agents; Codex uses
-  named custom agents such as
-  `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
-  `source-scout-prospeo-contact` when subagents are available.
-- `launch_post_find_leads_scout`: Claude Code uses `Task` with `subagent_type`
-  equal to the returned prospect-setup registry `name` only when the session
-  lists those agents; Codex uses the returned compatibility agents such as
-  `post-find-leads-filter-scout` and `post-find-leads-message-scout` when
-  subagents are available.
+  import and before dispatching Message Drafting only.
+- `launch_message_drafting`: Claude Code uses `Task` with `subagent_type`
+  `post-find-leads-message-scout` when listed; Codex uses the returned
+  compatibility agent or a generic `gpt-5.5` / `xhigh` Message Drafting agent.
 
 If a required interactive question function or MCP loader is missing, stop and
-explain the Sellable install/reload problem. Named scout agents are optional
-acceleration: if they are absent, do not surface install status to the customer;
-fall back to product-native MCP orchestration instead of local scripts.
+explain the Sellable install/reload problem. Source and filter work use
+product-native MCP orchestration in the parent; the only normal background
+branch is Message Drafting.
 
 Never narrate local draft housekeeping to the user. If you create directories,
 save drafts, write artifacts, or persist intermediate state, translate it into
@@ -764,7 +751,7 @@ updates.
    and the current host policy allows agent launch. The worker must load
    `mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })`.
    In Codex, YOLO/autonomous mode counts as campaign-scoped permission to use
-   Sellable background agents for pre-launch work. If the user has not enabled
+   this single Message Drafting background agent. If the user has not enabled
    YOLO and has not explicitly asked for background agents, subagents, parallel
    agents, delegation, or a message/bg agent in this campaign, ask once for
    permission before loading the long message prompt in the parent. If
@@ -774,17 +761,24 @@ updates.
    silently fall back to parent-thread message drafting; parent fallback is
    allowed only when the user explicitly says to continue without a background
    agent.
-   Do not use any alternate or examples-only message prompt. Message review requires Message Drafting output:
+   Do not use any alternate or examples-only message prompt. Message review and
+   message QA require Message Drafting output:
    do not draft from a checklist, local markdown artifact, or parent-thread
    intuition. Use campaign state, campaign brief content, selected source state, and
    initial campaign-table execution slice 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.
+   synthesize local validation artifacts from general knowledge. The handoff to
+   Message Drafting should pass compact basis only, not a long row-id list; the
+   branch loads current brief/table rows and validation assets itself.
 5. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Materialize the approved
    source list, copy confirmed rows into the campaign, and internally process the
-   first campaign-table execution slice after the source is attached to the campaign; do not
-   queue workflow cells, attach a sequence, or start until saved filters and the
+   first campaign-table execution slice after the source is attached to the
+   campaign; do not load prospect-setup registries/prompts before asking add
+   filters vs skip filters. Once the user answers, launch only Message Drafting
+   from the same campaign/table basis. If filters are approved, do filter/rubric
+   work inline in the parent thread. 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.