@sellable/mcp 0.1.151 → 0.1.153

package/skills/create-campaign-v2/SOUL.md

@@ -51,9 +51,11 @@ turn anchored to that:
 3. Turn that into a campaign brief and create the watchable campaign shell.
 4. Ask for brief approval before any lead import or sending-adjacent work.
 5. Find likely responders and approve the source.
-6. Import only the bounded review batch.
+6. Copy the confirmed source list into the campaign and use the first 15 rows as
+   the review/process sample.
 7. Filter for fit and draft the reusable message template from the same sample.
-8. Ask for message approval before queueing the review-batch cascade.
+8. Queue the bounded fit cascade from saved rubrics/run conditions only after the
+   message template is approved.
 9. Use Settings for sender selection, sequence attach, and final launch handoff.
 
 Approvals only feel safe when the user can see what they are approving. Before
@@ -81,12 +83,13 @@ example, like `omit the noticed... line` or `use "operators"`. Missing data
 should never produce robotic or creepy copy.
 
 Approved token guidance is part of the campaign, not just the review. After the
-bounded review batch exists and message generation has a selected template, the
-campaign brief should carry forward the token fill rules and examples before any
+first review/process sample exists and message generation has a selected
+template, the campaign brief should carry forward the token fill rules and examples before any
 workflow-table cascade is queued: good fills, good omits, bad fills, fallback
 rules, and why the bad fills are blocked.
 The campaign brief must carry forward the token fill rules from review into the
-live campaign state before enrichment, filtering, or Generate Message cells run.
+live campaign state before enrichment, filtering, Generate Message cells, sender
+setup, sequence attach, or launch.
 
 ## Progress Updates
 
@@ -275,17 +278,17 @@ surface install status to the customer.
 
 For post-lead work, call `get_post_find_leads_scout_registry` after
 the user chooses filters, not before the filter-choice question. After
-`confirm_lead_list` imports a non-empty bounded review batch and
-`get_rows_minimal` proves rows exist, ask add-filters vs skip-filters
+`confirm_lead_list` copies source rows and `get_rows_minimal` proves the first
+review/process sample exists, ask add-filters vs skip-filters
 immediately. Once the user answers, start `post-find-leads-message-scout` /
 message generation from the same campaign/table basis. If the user chooses
 filters, also start `post-find-leads-filter-scout`, move the browser to Filter
-Rules, save rubrics, then keep the browser on Filter Leads while the message
-recommendation is reviewed. If the user skips filters, move the browser to
-Messages/message review. The join gate is live branch readiness: saved rubrics
-or a resolved skip-filter choice, plus a message recommendation grounded in the
-same campaign/table basis. Enrichment, filtering, and product Generate Message
-cells still wait for template approval.
+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 the browser to Messages/message review. The join gate is
+saved-filter approval or a resolved skip-filter choice, plus a message
+recommendation grounded in the same campaign/table basis. Enrichment, filtering,
+and Generate Message cells wait for template approval on the Use Template path.
 
 Only promise parallel post-lead work when parallel work actually started. If the
 host cannot or should not launch background branches, say the real sequence:

package/skills/create-campaign-v2/core/auto-execute.README.md

@@ -11,19 +11,19 @@ autonomous tail (Step 13, `auto-execute-leads`). All subsequent steps (14
 validate-sample, 15 auto-execute-messaging, 16 awaiting-user-greenlight)
 read the already-parsed config; they do not re-load the YAML mid-run.
 
-Config values are NOT written to DB. They live on the skill side and
-influence tool arguments (e.g. `importLimit` flows into `import_leads`
-`targetLeadCount` arg, `sampleSize` flows into the first N rows pulled from
-the imported review batch for validation).
+Config values are NOT written to DB. They live on the skill side and influence
+tool arguments (e.g. `importLimit` / `sampleSize` controls the first N
+review/process rows after `confirm_lead_list` copies the confirmed source rows
+into the campaign).
 
 ## Sections
 
 ### `import`
 
-- **`importLimit`** — Review-batch size imported in Step 13. The tail MUST
-  NOT exceed this cap before the user reviews the first batch and explicitly
-  approves expansion. If the user wants 250 leads, run a later expansion step;
-  do not spend credits on all 250 during the default approval tail.
+- **`importLimit`** — Review/process sample size used after Step 13 copies the
+  confirmed source rows into the campaign. The tail MUST NOT exceed this cap
+  before the message template is approved and at least one generated passing
+  message is reviewed.
 - **`provider`** — Inherited from the Phase 84 commit decision (saved in
   the committed brief / campaign metadata). Present here so the tail can
   narrate which provider it's running against; it does NOT override the
@@ -31,19 +31,18 @@ the imported review batch for validation).
 
 ### `sample`
 
-- **`sampleSize`** — How many rows the validation loop pulls from the
-  imported review batch. In v2 this matches the review-batch cap
-  (default 25), so the user sees enough real rows to judge the campaign
-  without spending credits on hundreds more.
+- **`sampleSize`** — How many rows the validation loop pulls from the first
+  review/process sample. In v2 this matches the process cap (default 15), so the
+  user sees enough real rows to judge the campaign without spending credits on
+  hundreds more.
 - **`minProjectedPass`** — Passing-message floor required before handoff.
-  The default requires 5 passing examples from the 25-row review batch.
+  The default requires one passing example from the 15-row review sample.
   Math:
   ```text
   projectedPass = round(passInSample / sampleSize * importLimit)
   ```
-  With defaults (sampleSize=25, importLimit=25), `projectedPass` equals
-  the actual review-batch pass count. 5 passing rows is exactly at the
-  floor.
+  With defaults (sampleSize=15, importLimit=15), `projectedPass` equals the
+  actual review sample pass count. One passing row is exactly at the floor.
 - **`maxRevisionRounds`** — Hard cap before escalating to the user. A
   revision round is one full sample pass that triggered brief revision
   and retried. On stale resume the counter does NOT reset.
@@ -128,7 +127,7 @@ logs and adjust:
 
 - `importLimit` higher only if users consistently ask for larger review
   batches and credit spend is acceptable.
-- `sampleSize` higher if a 25-row review batch is not enough to judge
+- `sampleSize` higher if a 15-row review sample is not enough to judge
   quality for a specific market.
 - `minProjectedPass` lower only if fewer than 3 passing examples is still
   enough for a confident user decision.

package/skills/create-campaign-v2/core/auto-execute.yaml

@@ -14,10 +14,11 @@
 version: 1
 
 import:
-  # Initial review batch imported in Step 13 before the sample validation
-  # loop. Import + enrichment must never exceed this cap before the user
-  # reviews the sample and explicitly asks to expand.
-  importLimit: 25
+  # Initial review/process sample used after the confirmed source list is copied
+  # into the campaign. Enrichment must never exceed this cap before the message
+  # template is approved and the sample proves at least one passing generated
+  # message.
+  importLimit: 15
   # Provider is inherited from the campaign-attached source association created
   # during find-leads. Step 13 may re-run provider preflight in memory, but it
   # does not choose a new source.
@@ -27,11 +28,11 @@ sample:
   # Rows pulled from the imported cohort for the validation loop. In v2 this
   # equals the review-batch cap so the user sees a focused first test batch
   # without spending credits on hundreds of rows.
-  sampleSize: 25
+  sampleSize: 15
   # Projected first-batch passing count required to proceed to sample
   # messaging. This is not approval to scale the full source list.
   # projectedPass = round(passInSample / sampleSize * importLimit).
-  minProjectedPass: 5
+  minProjectedPass: 1
   # Hard cap on revision loops before escalating to the user. On a stale
   # resume the counter does NOT reset — the 3-round cap holds across
   # sessions.
@@ -106,7 +107,7 @@ handoff:
   # Orientation surfaced in Step 16 ("awaiting-user-greenlight") along with
   # the watch link. Keep this short and user-facing.
   orientation: >-
-    Review the first 25 enriched leads and messages. If they look good,
+    Review the first generated passing message. If it looks good,
     attach a sender in Settings, accept the recommended sequence, and start
     the campaign without spending credits on more leads first.