@sellable/mcp 0.1.134 → 0.1.136

package/dist/tools/sequencer.js

@@ -85,7 +85,7 @@ export const sequencerToolDefinitions = [
                 },
                 currentStep: {
                     type: "string",
-                    description: "Optional CampaignOffer currentStep to persist with the sequence attach, usually 'send' after the recommended sequence is bound.",
+                    description: "Optional CampaignOffer currentStep to persist atomically with the sequence attach, usually 'send' after the recommended sequence is bound. The backend writes the matching watch narration; do not follow with a separate step-only update_campaign fixup.",
                 },
             },
             required: ["campaignId"],

package/package.json

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

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

@@ -431,8 +431,10 @@ brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
   brief approval question once `create_campaign` has returned `watchUrl`. This
   is a hard gate for `AskUserQuestion` / `request_user_input`: do not ask
   `Approve this brief before I start finding leads?` until the user has already
-  seen the watch link for the live campaign shell. If the question panel would
-  appear without a preceding `Watch link:` line, stop and send the link first.
+  seen both (1) the full brief content being approved and (2) the watch link for
+  the live campaign shell. A summary like `the brief is visible there` is not a
+  valid approval surface. If the question panel would appear without the full
+  brief and a preceding `Watch link:` line, stop and render those first.
   The visible brief must come before any optional debug persistence. After the
   brief is synthesized, render the approval-ready brief in chat and
   create/update the campaign shell before any visible `mkdir`, `Write`,
@@ -563,7 +565,11 @@ until the filter choice is resolved and the template is ready for approval.`
   `get_rows_minimal` proves rows exist, the Message Draft Builder must start
   from the live campaign brief, source decision, lead sample, and imported
   campaign table sample. Do not show `Message Draft Builder: In Progress` unless
-  the worker or parent-thread fallback has actually started. It can prepare
+  the worker or parent-thread fallback has actually started and runtime proof is
+  stored or returned as `watchNarration.workerDetails.messageDraftBuilder` with
+  `runId` or `fallbackId`, `statusSource`, `status`, `startedAt`, `updatedAt`,
+  `basisToken`, and the current `selectedLeadListId`/`workflowTableId`/
+  review-batch row basis. It can prepare
   proof inventory, token strategy, and candidate angles while filter-leads
   tightens keep/exclude rules. Template review cannot start
   until filter choice is answered and rubrics are saved. If filters are enabled,
@@ -614,6 +620,15 @@ until the filter choice is resolved and the template is ready for approval.`
   launch both branches together, this is still the two Task/Agent subagents
   path; otherwise message-generation starts first and filter-leads joins after
   the filter choice.
+- Runtime proof is part of the branch contract, not optional UI decoration.
+  `watchNarration.workerDetails.messageDraftBuilder.status` may be
+  `branch-running`, `fallback-active`, `spawn-failed`,
+  `fallback-superseded`, `branch-superseded`, `ready`, `blocked`,
+  `retry-needed`, or `stale`. Running copy requires `branch-running` with
+  `runId` or `fallback-active` with `fallbackId`; ready copy requires compact
+  output from the current basis. Spawn failures, stale output, or retry-needed
+  states show blocked/retry copy. Late fallback/branch outputs that are
+  superseded by a newer basis must not override the current worker status.
 - Never run a downstream stage until the active `flow.v2.json` step's required
   campaign state and required normal inputs exist. In normal customer runs, do
   not create optional debug artifacts just to satisfy a file gate.
@@ -633,13 +648,21 @@ until the filter choice is resolved and the template is ready for approval.`
 batch`, and a no-launch safety note. Do not leave the guide saying
   `source approved` or `I'll show the review-batch outcome` once import is
   starting.
-- After the bounded review batch is present, update the watched browser to
-  `currentStep: "filter-choice"` with `watchNarration.stage: "fit-message"` and
-  ask the user to Choose filters or skip. If import succeeds but row readback
-  returns zero rows, do not move to filter choice; keep the user in source/import
-  recovery and ask whether to retry import, import more from the approved
-  source, or revise source. Active filtering starts only after rubrics are
-  saved; do not say filtering the batch before rubrics are saved.
+- After `import_leads` starts a provider/source import and the watched browser
+  moves to `confirm-lead-list`, the guide must describe the visible import
+  progress, not source approval. Use copy like `Scraping source leads from
+posts` for Signal Discovery or `Importing source leads` for Sales Nav/Prospeo.
+  Do not leave `Review the source in Codex` while the Signals/Sales Nav/Prospeo
+  import progress page is visible.
+- After the bounded review batch is present, the watched browser must move to
+  `currentStep: "filter-choice"` with `watchNarration.stage: "fit-message"` in
+  the same visible beat. Use copy like `I recommend adding filters`: say the
+  visible sample is in the campaign table, recommend adding filters when the
+  imported rows look mixed/noisy, and ask the user to choose filters or skip. If import
+  succeeds but row readback returns zero rows, do not move to filter choice; keep
+  the user in source/import recovery and ask whether to retry import, import more
+  from the approved source, or revise source. Active filtering starts only after
+  rubrics are saved; do not say filtering the batch before rubrics are saved.
 - When the user chooses filters, immediately persist `enableICPFilters: true`
   and `currentStep: "create-icp-rubric"` so the watched app leaves the filter
   choice screen and shows that Codex is defining the rules in chat. After Lead
@@ -1311,6 +1334,14 @@ normal live campaign path; those files are optional debug context only. If the
 long prompt plus safety gate cannot safely approve the draft, stop at
 `revise-messaging` with the exact failure.
 
+Return compact output to the parent: template recommendation, token fill rules,
+one rendered sample, concerns, status, basis token, output timestamp/hash, and
+error or retry detail. The basis must include campaign revision/updatedAt, brief
+hash, `selectedLeadListId`, `workflowTableId`, bounded review-batch row
+ids/hash, filter choice, and filter/rubric basis when present. Do not write
+message cells, enrich rows, attach sequence, or imply send readiness from this
+background branch.
+
 Do NOT proceed to Step 4 (message review gate) unless the user has answered
 filter choice, the watched app is still on Filter Leads while approval is
 pending, and `message-validation.md` contains the safety-gate required