@sellable/install 0.1.153 → 0.1.154

package/README.md

@@ -56,16 +56,13 @@ Auth is stored once at:
 ```
 
 Claude Code and Codex are configured to launch the same packaged MCP server. The
-installer also writes Sellable source-scout agents for both hosts from the
-packaged `agents/` registry: Claude Code gets `source-scout-*` subagents, and
-Codex gets `source-scout-linkedin-engagement`, `source-scout-sales-nav`, and
-`source-scout-prospeo-contact`. After Find Buyers Plan approval, runtime prompts
-use the named scout for the approved source lane as the normal path when the
-current session exposes it. If a named scout is unavailable, they use a generic
-background agent when possible; parent-thread provider probes are the explicit
-fallback, not the default path. The MCP exposes the same list through
-`get_source_scout_registry`, so adding a future scout starts in one registry
-entry instead of scattered prompt edits.
+installer also writes Sellable agent definitions from the packaged `agents/`
+registry, but normal create-campaign runs use only the Message Drafting
+background agent. Source discovery and filter/rubric setup stay in the parent
+thread with product-native MCP tools unless the user explicitly asks for a
+source-comparison/debug run. `get_post_find_leads_scout_registry` returns the
+Message Drafting worker for the normal path; `get_source_scout_registry` is
+metadata for explicit debug/comparison use.
 
 ## Names
 

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,21 +123,23 @@ 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
+## User Revision Feedback And QA
 
-If the parent sends user feedback about the template before `approve-message`,
-treat it as a Message Drafting revision, not a campaign write. Use the current
-`messageDraftRecommendation`, basis token/hash, campaign/table basis, and the
-latest user feedback as inputs. Load or reuse the full
-`generate-messages` contract, then return a revised recommendation with:
+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
 

package/bin/sellable-install.mjs

@@ -918,26 +918,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
@@ -1132,11 +1125,12 @@ updates.
 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
-   load prospect-setup registries/prompts before asking add filters vs skip filters.
-   Once the user answers, launch Message Drafting from the same campaign/table
-   basis. If filters are approved, also launch Prospect Filters. 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.

package/package.json

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

package/skill-templates/create-campaign.md

@@ -248,34 +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, source discovery is agent-first after the Find Buyers Plan approval. For
-the approved single source lane, explicitly spawn that returned named custom
-scout; for example, choosing LinkedIn posts should spawn
-`source-scout-linkedin-engagement` even when no comparison is needed. When
-multiple source angles are credible, 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 wording.
-YOLO/autonomous mode counts as campaign-scoped permission to use Sellable source
-background agents. In Claude Code, invoke the generated `source-scout-*`
-Task/Agent subagent for the approved lane, or all credible lanes in one
-assistant message when comparison/fallback is needed, 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 named source scout is unavailable, use a generic `gpt-5.5` high
-background agent when the host can spawn generic agents. Continue source
-discovery in the parent thread only when agent launch is impossible or the user
-explicitly says to continue inline. 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 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
@@ -288,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
@@ -432,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
@@ -773,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
@@ -783,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.