@sellable/mcp 0.1.358 → 0.1.360

package/dist/tools/setup-evergreen-campaigns.js

@@ -6,7 +6,7 @@ async function postSetupEvergreenCampaigns(body) {
 export const setupEvergreenCampaignsToolDefinitions = [
     {
         name: "setup_evergreen_campaigns",
-        description: "Evergreen campaign setup plan/verify command. Use plan mode first to inspect exact workspace/sender/campaign/table/source state and receive immutable lane packets. `selectedSenderIds` is a legacy shorthand for both scopes; prefer `postEngagerSenderIds` for the Post Engagers sender scope and `sharedSenderIds` for the shared lane sender scope when they differ. The command plans one Post Engagers lane per post-engager sender plus shared Signal Discovery and Shared Cold Fallback lanes for the shared sender set. yolo is only a parent-skill auto-execution hint for safe lane packets; this backend command remains read-only in plan mode and verifies receipts in verify mode. When safe-yolo needs normal setup work, the parent skill may ask for bounded delegated approval: one approval over the current planRevision, selected action ids, caps, allowed side-effect classes, and stop conditions lets lane workers execute without per-substep approval while staying inside that packet. Lane workers must execute creation, source import, create-campaign workflow steps, generate-messages, sequence attachment, pause_campaign review-state transition when the current table is still DRAFT, and review readiness through existing create-campaign workflow/subskills, then return receipts here for verification. Customer-visible verify receipts must include createCampaignStepReceipt with setupPlanCall, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall. messageDraftingReceipt must include validationResult:'passed', a passed qualityReview, and at least 3 concrete sampleMessages with row ids, generated message text, pass verdicts, and no issues; Shared Cold Fallback samples with a standalone name followed by 'Hey there' are rejected. This command does not launch campaigns, does not schedule sends, does not assign scheduler-owned send fields, does not raw-write campaign status, does not archive/delete cleanup targets, and does not spend paid credits.",
+        description: "Evergreen campaign setup plan/verify command. Use plan mode first to inspect exact workspace/sender/campaign/table/source state and receive immutable lane packets. `selectedSenderIds` is a legacy shorthand for both scopes; prefer `postEngagerSenderIds` for the Post Engagers sender scope and `sharedSenderIds` for the shared lane sender scope when they differ. The command plans one Post Engagers lane per post-engager sender plus shared Signal Discovery and Shared Cold Fallback lanes for the shared sender set. yolo is only a parent-skill auto-execution hint for safe lane packets; this backend command remains read-only in plan mode and verifies receipts in verify mode. When safe-yolo needs normal setup work, the parent skill may ask for bounded delegated approval: one approval over the current planRevision, selected action ids, caps, allowed side-effect classes, and stop conditions lets lane workers execute without per-substep approval while staying inside that packet. Lane workers must execute creation, source import, create-campaign workflow steps, generate-messages, sequence attachment, pause_campaign review-state transition when the current table is still DRAFT, and review readiness through existing create-campaign workflow/subskills, then return receipts here for verification. Customer-visible verify receipts must include createCampaignStepReceipt with setupPlanCall, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall. messageDraftingReceipt must use statusSource:'branch' or statusSource:'packaged-generate-messages-worker' and include proof that generate-messages was loaded, start_campaign_message_preparation/get_campaign_message_preparation_status ran when the packaged worker path is used, validationResult:'passed', a passed qualityReview, and at least 3 concrete sampleMessages with row ids, generated message text, pass verdicts, and no issues; Shared Cold Fallback samples with a standalone name followed by 'Hey there' are rejected. This command does not launch campaigns, does not schedule sends, does not assign scheduler-owned send fields, does not raw-write campaign status, does not archive/delete cleanup targets, and does not spend paid credits.",
         inputSchema: {
             type: "object",
             properties: {

package/package.json

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

package/skills/create-evergreen-campaigns/SKILL.md

@@ -73,6 +73,16 @@ Plan shape:
   creating duplicates.
 - If a user supplies canonical ids, reuse/verify them instead of creating duplicates.
 
+The command-backed unbound plan is authoritative. If
+`setup_evergreen_campaigns({ mode:"plan", ... })` returns a lane packet with
+`intent:"create"`, execute that create packet exactly. Do not convert it into an
+explicit binding because `list_tables`, `get_campaigns`, a waterfall, or old
+inventory shows an `ARCHIVED` campaign/table with a matching name. Archived
+campaigns are not reusable evergreen targets. Only pass an archived
+campaign/table as an explicit binding when the user supplied those exact ids and
+explicitly allowed dashboard visibility repair; otherwise ignore archived
+matches for execution and let the create packet proceed.
+
 Use `selectedSenderIds` only as a legacy shorthand when the same senders should
 get sender-owned Post Engagers lanes and attach to shared lanes. When the scopes
 differ, pass both explicit arrays:
@@ -200,6 +210,37 @@ If any required field is missing, report
 `blocked: missing_create_campaign_step_receipt` for that lane and do not call it
 complete.
 
+Message Drafting runtime rule: the preferred proof source is the normal
+create-campaign branch handoff (`watchNarration.workerDetails.messageDraftBuilder`
+or equivalent) with `statusSource:"branch"`. If that internal branch handoff is
+not callable or not exposed in the packaged MCP runtime, do **not** stop after
+creating/importing rows. The lane worker must run the packaged message-drafting
+path itself in the worker thread:
+
+1. Load `get_subskill_prompt({ subskillName:"generate-messages" })` until
+   `hasMore:false`.
+2. Load the required message assets and `create-campaign-v2-validation`.
+3. Call `start_campaign_message_preparation({ campaignId, tableId,
+   targetPreparedMessages, maxRowsToCheck, approvalMode:"mark_ready",
+   autoContinue:true })` inside the same lane worker, with bounded caps from the
+   lane packet.
+4. Poll `get_campaign_message_preparation_status` until no queued/active cells
+   remain or a bounded stop reason is returned.
+5. Use `get_campaign_messages_preview` or `select_campaign_cells` to inspect
+   generated rows, quality-review at least 3 samples, approve exactly one
+   quality-valid route-proof row when none is already approved, and prove no
+   broad approve-all happened.
+6. Continue to `attach_recommended_sequence({ campaignId, currentStep:"send" })`
+   and, if the campaign is still `DRAFT`, `pause_campaign({ campaignId })`.
+   Reread the campaign/table before claiming completion.
+
+That packaged worker path must return `messageDraftingReceipt.statusSource:
+"packaged-generate-messages-worker"`. It is accepted only when the receipt
+includes the same prompt/assets/validation proof, current campaign/table/source
+basis, generated review rows, sample messages, quality review, route-proof
+approval evidence, sequence proof, and final paused-send proof required of the
+branch handoff. `statusSource:"parent-thread-fallback"` is still invalid.
+
 One lane may produce exactly one CampaignOffer/campaign id and one current
 workflow table id. For `intent:"create"`, the first successful
 `create_campaign` result establishes the lane's only allowed campaign/table
@@ -212,10 +253,12 @@ and do not report completion. Do not hide the earlier shell by reporting only
 the later imported campaign.
 
 Each customer-visible lane receipt must also include message proof from
-`watchNarration.workerDetails.messageDraftBuilder` or the worker's equivalent
-branch handoff record. Valid evergreen message proof names the current campaign
-id, workflowTableId, selected lead-list or source id, filter choice, and
-review-batch row ids/hash, and it must use `statusSource:"branch"`.
+`watchNarration.workerDetails.messageDraftBuilder`, the worker's equivalent
+branch handoff record, or the packaged message-prep worker path above. Valid
+evergreen message proof names the current campaign id, workflowTableId,
+selected lead-list or source id, filter choice, and review-batch row ids/hash,
+and it must use `statusSource:"branch"` or
+`statusSource:"packaged-generate-messages-worker"`.
 `statusSource:"parent-thread-fallback"` is not accepted for evergreen
 customer-visible completion because it can be a parent summary rather than proof
 that the create-campaign Message Drafting branch actually ran. The proof must
@@ -296,9 +339,14 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
    - Every customer-visible lane must run Message Drafting from the current
      campaign/table basis after source rows exist. The worker must load the full
      packaged `generate-messages` prompt, every required asset, and
-     `create-campaign-v2-validation`; the returned receipt must include at
-     least 3 concrete reviewed sample messages, a passed validation result, and
-     a passed quality review. Row/message counts alone are not enough.
+     `create-campaign-v2-validation`; if the internal branch handoff is not
+     callable in the packaged runtime, the worker must call
+     `start_campaign_message_preparation` and poll
+     `get_campaign_message_preparation_status` from the lane worker. The
+     returned receipt must include `statusSource:"branch"` or
+     `statusSource:"packaged-generate-messages-worker"`, at least 3 concrete
+     reviewed sample messages, a passed validation result, and a passed quality
+     review. Row/message counts alone are not enough.
 
    - **The brief must declare the delivery format** so Generate Message writes copy suited to how it actually sends:
      - DM lanes: add a `Delivery format:` line — either `multiline (each paragraph sends as its own DM message)` or `single message`. When multiline, the template's blank-line paragraphs ARE the message boundaries — write each one as a standalone typed message.
@@ -329,9 +377,13 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      `get_subskill_prompt({ subskillName:"generate-messages"` was loaded until
      `hasMore:false`, required message assets were loaded, and
      `create-campaign-v2-validation` ran through
-     `workerDetails.messageDraftBuilder` with `statusSource:"branch"`. The generated-message
-     cells are not prompt proof; `currentRevisionGeneratedMessages` and row
-     previews are only downstream cell evidence. The proof must include
+     `workerDetails.messageDraftBuilder` with `statusSource:"branch"` or
+     through the lane worker's packaged message-prep path with
+     `statusSource:"packaged-generate-messages-worker"`,
+     `start_campaign_message_preparation`, and
+     `get_campaign_message_preparation_status`. The generated-message cells are
+     not prompt proof; `currentRevisionGeneratedMessages` and row previews are
+     only downstream cell evidence. The proof must include
      `validationResult:"passed"`, a passed quality review, and at least 3
      reviewed sample messages. For Shared Cold Fallback, reject samples that
      open with a standalone name followed by "Hey there" or a similarly generic