@sellable/install 0.1.200 → 0.1.202

package/bin/sellable-install.mjs

@@ -1147,7 +1147,15 @@ updates.
    copies of this file; packaged Claude Code and Codex runs must use the MCP
    asset loader so they share the same config.
 3. Follow that prompt and workflow config exactly.
-4. For message generation, use the \`post-find-leads-message-scout\` agent when
+4. For filter and message setup, keep the parent thread as a lean orchestrator.
+   The only normal background agent is \`post-find-leads-message-scout\` for
+   Message Drafting. Both post-import choices must launch Message Drafting.
+   When filters are chosen, launch Message Drafting, then keep filters in the
+   parent thread: load \`references/filter-leads.md\`, draft production rubrics,
+   call \`save_rubrics\`, ask filter approval, and then join Message Drafting for
+   template review. When filters are skipped, launch only Message Drafting
+   before treating the campaign as in Messages/message review.
+5. For message generation, use the \`post-find-leads-message-scout\` agent when
    available. The worker and parent-thread fallback must load
    \`mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })\`,
    then every required message asset named by \`generate-messages\` Mode 0 before
@@ -1163,7 +1171,7 @@ updates.
    local markdown such as \`message-validation.md\`, inspect the database
    directly, or synthesize local validation artifacts from general knowledge.
    The message recommendation handoff is labeled Markdown, not raw JSON.
-5. Create the campaign shell early with the v1 brief so the user can open the
+6. 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
@@ -1178,13 +1186,15 @@ updates.
    After rubrics save, keep Filter Rules visible for approval; after approval,
    move to Filter Leads and show \`Filters saved + waiting for message approval\`
    until the template is approved.
-   If filters are skipped, move to Messages/message review. Queue the bounded
-   campaign-table execution-slice \`enrichCellId\` cells only after message approval. Move to
-   Messages only after at least one review row passes and one generated message
-   is ready.
+   If filters are skipped, launch Message Drafting before moving to
+   Messages/message review; updating \`currentStep\` to \`messages\` is not proof
+   that the background worker started. Queue the bounded campaign-table
+   execution-slice \`enrichCellId\` cells only after message approval. Move to the
+   generated-row Messages review 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
+7. The main thread owns watch navigation. Call
    \`mcp__sellable__update_campaign({ campaignId, currentStep })\` before major
    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,

package/package.json

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

package/skill-templates/create-campaign.md

@@ -90,6 +90,9 @@ execution slice configures filters and messages. After that, the user chooses
 whether to use filters or skip.
 When filters are chosen, save rubrics, get filter approval, then wait for
 message-template approval before enrichment/filtering or Generate Message cells.
+Filter work stays in the parent thread and must inspect visible campaign rows
+with `get_rows_minimal` / `get_rows` before drafting and saving rubrics; use at
+most one direct `enrich_with_prospeo` sample when row evidence is too thin.
 After filter approval, Filter Leads should show `Filters saved + waiting for
 message approval` until the template is approved.
 The default path stays the existing first campaign-table execution slice:
@@ -97,17 +100,19 @@ review the normal `reviewBatchLimit:15`, approve reviewed draft rows, then move
 to Settings/sequence/final greenlight. Only call
 `start_campaign_message_preparation` when the user explicitly asks for more
 prepared messages or a send count. If the user says "prepare/generate X
-messages", set `targetPreparedMessages:X`, let the backend derive
-`maxRowsToCheck:min(2500,max(300,X*5))`, and keep
-`approvalMode:"mark_ready"`. The backend samples up to 100 rows first, then
-adapts later batches up to 250 rows while recalculating yield. Poll
+messages", set `targetPreparedMessages:X`, omit `maxRowsToCheck`, and keep
+`approvalMode:"mark_ready"`. The backend calibrates on at least 100 rows,
+estimates the row budget from observed rubric/pass yield, caps
+`maxRowsToCheck` at 2500, then adapts later batches up to 250 rows while
+recalculating yield. Poll
 `get_campaign_message_preparation_status` for preparation-job status: checked
-rows, prepared/approved count, target, row budget remaining, and stop reason. If
-the user says "approve X messages", use `approvalMode:"approve"` but still do
-not launch. If the user says "schedule X sends", use `approvalMode:"approve"`
-to approve exactly the bounded X-message cohort during preparation, then
-continue through sender, sequence, and final launch greenlight; the launch path
-must verify that bounded cohort and must not broad approve-all.
+rows, passed/prepared/approved count, target, estimated row budget remaining,
+and stop reason. If the user says "approve X messages", use
+`approvalMode:"approve"` but still do not launch. If the user says "schedule X
+sends", use `approvalMode:"approve"` to approve exactly the bounded X-message
+cohort during preparation, then continue through sender, sequence, and final
+launch greenlight; the launch path must verify that bounded cohort and must not
+broad approve-all.
 Treat `campaignId` as `CampaignOffer.id`. Low level selector/queue tools are
 diagnostics and recovery only for this lane. If the user asks to stop
 preparation, the target is wrong, or status shows the wrong campaign/table, call
@@ -422,12 +427,15 @@ 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 only Message Drafting
-from the same campaign/table basis. If the user chooses filters, the parent
+from the same campaign/table basis. This kickoff is required for both answers:
+`Use filters` and `Skip filters`. 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
+message recommendation is reviewed. If the user skips filters, start Message
+Drafting first, then move to Messages/message review after it has started or
+returned a ready recommendation. `update_campaign({ currentStep: "messages" })`
+is not proof of kickoff. Enrichment/filtering and Generate Message cells wait
 for message approval. AI Generated is an explicit opt-out from the template
 path.
 
@@ -480,14 +488,14 @@ automation just because a watch link exists. If `create_campaign` returns
 `watchHandoff.markdown`, print that exact value once, directly before the brief
 approval question. It will use the URL mode to say Codex or Claude Code:
 
-````markdown
+```markdown
 > **WATCH CODEX BUILD THE CAMPAIGN LIVE**
 >
 > [Open live campaign builder]({watchUrl})
 >
 > Keep this chat open. I'll ask approval questions here before making decisions
 > that need your judgment.
-````
+```
 
 The rendered callout is intentional: rendered chat clients highlight the
 headline, link, and note without treating it as a code block, and plain terminals
@@ -910,11 +918,12 @@ updates.
 3. Follow that prompt and workflow config exactly.
 4. For filter and message setup, keep the parent thread as a lean orchestrator.
    The only normal background agent is `post-find-leads-message-scout` for
-   Message Drafting. When filters are chosen, launch Message Drafting, then keep
-   filters in the parent thread: load `references/filter-leads.md`, draft
-   production rubrics, call `save_rubrics`, ask filter approval, and then join
-   Message Drafting for template review. When filters are skipped, launch only
-   Message Drafting.
+   Message Drafting. Both post-import choices must launch Message Drafting.
+   When filters are chosen, launch Message Drafting, then keep filters in the
+   parent thread: load `references/filter-leads.md`, draft production rubrics,
+   call `save_rubrics`, ask filter approval, and then join Message Drafting for
+   template review. When filters are skipped, launch only Message Drafting
+   before treating the campaign as in Messages/message review.
 5. For message generation, keep the parent thread as a lean orchestrator and
    use the `post-find-leads-message-scout` compatibility agent for Message
    Drafting whenever the host exposes it
@@ -963,13 +972,15 @@ updates.
    After rubrics save, keep Filter Rules visible for approval; after approval,
    move to Filter Leads and show `Filters saved + waiting for message approval`
    until the template is approved.
-   If filters are skipped, move to Messages/message review. Queue the bounded
-   campaign-table execution-slice `enrichCellId` cells only after message approval. Move to
-   Messages only after at least one review row passes and one generated message
-   is ready.
+   If filters are skipped, launch Message Drafting before moving to
+   Messages/message review; updating `currentStep` to `messages` is not proof
+   that the background worker started. Queue the bounded campaign-table
+   execution-slice `enrichCellId` cells only after message approval. Move to the
+   generated-row Messages review 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
+7. The main thread owns watch navigation. Call
    `mcp__sellable__update_campaign({ campaignId, currentStep })` before major
    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,
@@ -984,9 +995,9 @@ updates.
    job has reported compact checked/prepared/stop status, `settings` for sender
    selection, `sequence` after sender attach, and `send` once the recommended
    sequence is attached. Do not advance the step backward.
-7. Keep `selectedLeadListId` as the source list and `workflowTableId` as the
+8. Keep `selectedLeadListId` as the source list and `workflowTableId` as the
    campaign table. Do not use disk files as the post-mint source of truth.
-8. Do not ask the user to run another command.
+9. Do not ask the user to run another command.
 
 ## Fallback