@sellable/install 0.1.152 → 0.1.153

package/README.md

@@ -59,11 +59,13 @@ 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`. Runtime prompts use those named agents only
-when the current session exposes them; otherwise they fall back to the same MCP
-provider probes without customer-facing install-status copy. 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.
+`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.
 
 ## Names
 

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

@@ -110,6 +110,27 @@ brief hash, selected source, `selectedLeadListId`, `workflowTableId`, or
 execution-slice rows. Filter/rubric/enrichment basis drift alone is not a stale
 blocker.
 
+## User Revision Feedback
+
+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:
+
+- revised proposed template
+- what changed and why
+- token fill rule/fallback changes, if any
+- one rendered good-fill sample
+- 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/package.json

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

package/skill-templates/create-campaign.md

@@ -253,20 +253,29 @@ 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
+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 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.
+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 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.
+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.
 
 For campaign-attached Signal Discovery sampling, promote/select the exact posts
 with `select_promising_posts` before `fetch_post_engagers` so the user can see