@sellable/mcp 0.1.378 → 0.1.380

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. Package-backed prompt authority: the installed public wrapper can be the local Codex skill entrypoint, but lane workers must use get_subskill_prompt and get_subskill_asset for nested `$sellable:create-campaign`, create-campaign-v2, generate-messages, validation, and assets; nested filesystem prompt fallback is a failed UAT. Use mcp__sellable only for workspace selection and product mutations/readbacks. Do not use mcp__sellable_admin, direct DB, Prisma, or SQL as execution proof. Worker-local replans are read-only drift checks and must preserve the exact parent sender scopes, including postEngagerSenderIds:[] when intentionally empty and the exact sharedSenderIds array; if scope, planRevision, actionId, or laneKey drifts, stop with blocked:worker_plan_scope_drift before mutation. Each lane packet includes workerDispatch with acceptedRuntimes, rejectedRuntimes, requiresVisibleThreadOrDurableReceipt, receiptArtifactHint, receiptRunId, and receiptMustBeWrittenAfter; pre-existing receipts at old deterministic paths are stale and must not be used, so stop with blocked:stale_receipt_artifact if the receipt was not freshly written for the current receiptRunId. `multi_agent_v1.spawn_agent`/opaque spawn_agent is not accepted for mutating command proof unless the parent has visible thread or durable receipt proof. In local Codex, prefer `codex_app.list_projects` then `codex_app.create_thread` with a local project target; do not create a worktree for lane execution. If Codex app thread tools are unavailable but local Codex CLI is available, use durable streaming workers with `codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> -`; approval and sandbox flags must appear before `exec`, and current customer CLI installs reject `codex exec --ask-for-approval never` and `codex exec -a never`. 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 explicitly load and use the installed `$sellable:create-campaign` wrapper as the nested workflow entrypoint, then load `create-campaign-v2` and `create-campaign-v2/core/flow.v2.json`; they 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 that existing create-campaign workflow/subskills, then return receipts here for verification. Customer-visible verify receipts must set status:'succeeded' or status:'completed'; status:'passed', status:'pass', and status:'passed_with_warnings' are rejected as primary success statuses. Receipts must include createCampaignStepReceipt with setupPlanCall, createCampaignWorkflowReceipt, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall nested inside createCampaignStepReceipt; top-level-only copies of those objects are not enough and are not promoted by verify. setupPlanCall must use canonical keys: planRevision, actionId, laneKey, workspaceId, senderIds, campaignId, tableId, createIntent. Do not use laneActionId, lanePacketActionId, delegatedPlanRevision, delegatedActionId, or requestedCall text as a substitute for those canonical fields. createCampaignWorkflowReceipt must include skillCommand:'$sellable:create-campaign', skillName:'create-campaign', wrapperSkillLoaded:true, workflowPromptName:'create-campaign-v2', workflowPromptLoadedToHasMoreFalse:true, workflowAssetPath:'create-campaign-v2/core/flow.v2.json', workflowAssetLoaded:true, workerRuntime, workerThreadId or receiptArtifactPath, durableReceiptWritten when using a receipt file, and notAdHoc:true. messageDraftingReceipt must use exactly statusSource:'branch' or statusSource:'packaged-generate-messages-worker'; descriptive aliases such as statusSource:'package-readback-local-thread' are rejected. It must 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 rowId, generatedMessageText, verdict, and issues; Do not substitute `message` for `generatedMessageText`; Do not substitute `passVerdict` for `verdict`. Before writing durable receipts, run a receipt self-check: top-level `planRevision`, `actionId`, `laneKey`, `laneType`, `workspaceId`, and `senderIds` must exist; if the self-check fails, fix the receipt before ending. Use start_campaign_message_preparation with approvalMode:\"mark_ready\" only for evergreen setup. Never call `start_campaign_message_preparation` with `approvalMode:\"approve\"`; approve exactly one semantic Approved cell through select_campaign_cells/update_cell and final proof must show approvedGeneratedMessageCount exactly 1. 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. If a protected existing Post Engagers campaign must stay unchanged and the operator requested only shared lane execution, pass postEngagerSenderIds:[] and sharedSenderIds; do not include the protected active Post Engagers lane as a reuse packet because it can make the yolo plan non-autoExecutable. 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; pass yolo only in plan mode and never include yolo on mode:\"verify\" calls. This backend command remains read-only in plan mode and verifies receipts in verify mode. Package-backed prompt authority: the installed public wrapper can be the local Codex skill entrypoint, but lane workers must use get_subskill_prompt and get_subskill_asset for nested `$sellable:create-campaign`, create-campaign-v2, generate-messages, validation, and assets; nested filesystem prompt fallback is a failed UAT. Use mcp__sellable only for workspace selection and product mutations/readbacks. Do not use mcp__sellable_admin, direct DB, Prisma, or SQL as execution proof. Worker-local replans are read-only drift checks and must preserve the exact parent sender scopes, including postEngagerSenderIds:[] when intentionally empty and the exact sharedSenderIds array; if scope, planRevision, actionId, or laneKey drifts, stop with blocked:worker_plan_scope_drift before mutation. Each lane packet includes workerDispatch with acceptedRuntimes, rejectedRuntimes, requiresVisibleThreadOrDurableReceipt, receiptArtifactHint, receiptRunId, and receiptMustBeWrittenAfter; pre-existing receipts at old deterministic paths are stale and must not be used, so stop with blocked:stale_receipt_artifact if the receipt was not freshly written for the current receiptRunId. `multi_agent_v1.spawn_agent`/opaque spawn_agent is not accepted for mutating command proof unless the parent has visible thread or durable receipt proof. In local Codex, prefer `codex_app.list_projects` then `codex_app.create_thread` with a local project target; do not create a worktree for lane execution. If Codex app thread tools are unavailable but local Codex CLI is available, use durable streaming workers with `codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> -`; approval and sandbox flags must appear before `exec`, and current customer CLI installs reject `codex exec --ask-for-approval never` and `codex exec -a never`. 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. In exec/automation mode, do not call request_user_input; if yolo plan autoExecutable:false and no interactive approval can be received, stop with blocked:bounded_approval_unavailable_in_exec_mode before any mutation. Lane workers must explicitly load and use the installed `$sellable:create-campaign` wrapper as the nested workflow entrypoint, then load `create-campaign-v2` and `create-campaign-v2/core/flow.v2.json`; they 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 that existing create-campaign workflow/subskills, then return receipts here for verification. Customer-visible verify receipts must set status:'succeeded' or status:'completed'; status:'passed', status:'pass', and status:'passed_with_warnings' are rejected as primary success statuses. Receipts must include createCampaignStepReceipt with setupPlanCall, createCampaignWorkflowReceipt, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall nested inside createCampaignStepReceipt; top-level-only copies of those objects are not enough and are not promoted by verify. setupPlanCall must use canonical keys: planRevision, actionId, laneKey, workspaceId, senderIds, campaignId, tableId, createIntent. Do not use laneActionId, lanePacketActionId, delegatedPlanRevision, delegatedActionId, or requestedCall text as a substitute for those canonical fields. createCampaignWorkflowReceipt must include skillCommand:'$sellable:create-campaign', skillName:'create-campaign', wrapperSkillLoaded:true, workflowPromptName:'create-campaign-v2', workflowPromptLoadedToHasMoreFalse:true, workflowAssetPath:'create-campaign-v2/core/flow.v2.json', workflowAssetLoaded:true, workerRuntime, workerThreadId or receiptArtifactPath, durableReceiptWritten when using a receipt file, and notAdHoc:true. messageDraftingReceipt must use exactly statusSource:'branch' or statusSource:'packaged-generate-messages-worker'; descriptive aliases such as statusSource:'package-readback-local-thread' are rejected. It must 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 rowId, generatedMessageText, verdict, and issues; Do not substitute `message` for `generatedMessageText`; Do not substitute `passVerdict` for `verdict`. Before writing durable receipts, run a receipt self-check: top-level `planRevision`, `actionId`, `laneKey`, `laneType`, `workspaceId`, and `senderIds` must exist; if the self-check fails, fix the receipt before ending. Use start_campaign_message_preparation with approvalMode:\"mark_ready\" only for evergreen setup. Never call `start_campaign_message_preparation` with `approvalMode:\"approve\"`; approve exactly one semantic Approved cell through select_campaign_cells/update_cell and final proof must show approvedGeneratedMessageCount exactly 1. 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: {
@@ -86,7 +86,7 @@ export const setupEvergreenCampaignsToolDefinitions = [
 export function setupEvergreenCampaigns(input) {
     return postSetupEvergreenCampaigns({
         mode: input.mode,
-        yolo: input.yolo,
+        yolo: input.mode === "verify" ? undefined : input.yolo,
         depth: input.depth,
         allConnectedSenders: input.allConnectedSenders,
         selectedSenderIds: input.selectedSenderIds,

package/package.json

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

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

@@ -24,10 +24,19 @@ run without user input, or similar, run in **automation mode**:
 - Reconcile structure and record any template/config polish as `created`,
   `reused`, `repaired`, `flagged`, or `blocked`.
 - Choose the automation depth from the invoking prompt:
+  - Sparse `--yolo` create/repair invocations default to customer-visible completion:
+    when the user says run/create/repair/setup `$sellable:create-evergreen-campaigns`,
+    create evergreen campaigns, or similar without saying heartbeat/structure-only,
+    set `depth:"customer_visible"`. Customers usually expect usable campaigns,
+    not empty shells.
   - **Structure-only reconcile** is for heartbeat prompts that only say to
-    ensure slots exist. It may create/reuse shells and apply metadata repairs,
-    but it does not create rows, generate messages, approve rows, or attach new
-    send work.
+    ensure slots exist. Only choose `depth:"structure_only"` for
+    heartbeat/ensure-slots-only automation where the prompt explicitly says it
+    does not need source rows, generated messages, approvals, or sequence. It may
+    create/reuse shells and apply metadata repairs, but it does not create rows,
+    generate messages, approve rows, or attach new send work.
+    Short form: only choose `depth:"structure_only"` for
+    heartbeat/ensure-slots-only runs.
   - **Customer-visible completion** is required when the prompt says full
     campaign, customer-ready, send-review-ready, went through
     `$sellable:create-campaign`, fill out, approve one, only needs enrich and
@@ -138,6 +147,16 @@ for that shared-only sender. Example: if Justin already has a Post Engagers
 campaign and Jell/Hulan should only participate in the two shared campaigns,
 call `setup_evergreen_campaigns` with `postEngagerSenderIds:["<justin id>"]`
 and `sharedSenderIds:["<justin id>","<jell or hulan id>"]`.
+If the operator says to keep a protected existing Post Engagers campaign unchanged
+and create/repair only the shared lanes, pass `postEngagerSenderIds:[]` and the
+full shared sender set in `sharedSenderIds`. Do not include the protected active
+Post Engagers lane as a reuse packet in that shared-only execution scope: an
+ACTIVE protected lane can correctly produce a backend `launched_campaign`
+blocker and would make the whole yolo plan non-autoExecutable even though the
+operator asked to leave it untouched. Inventory and waterfall proof may mention
+the protected lane, but selectedActionIds and lane workers must cover only the
+shared lane packets.
+Short form: Do not include the protected active Post Engagers lane as a reuse packet when the operator requested only shared lane execution.
 
 When senders are ambiguous, ask which sender ids belong in the Post Engagers
 sender scope and which belong in the shared lane sender scope before planning.
@@ -155,6 +174,12 @@ plan execution, paid InMail spend, or ambiguous target choice. Stop on wrong
 workspace, cleanup/archive/delete need, stale plan, disconnected sender,
 duplicate candidate, unsafe side effect, missing source proof, or missing
 message proof.
+In exec/automation mode, do not call `request_user_input`. If a plan under
+`--yolo` returns `autoExecutable:false` and the run cannot receive interactive
+bounded delegated approval, stop with
+`blocked: bounded_approval_unavailable_in_exec_mode` before any mutation and
+state whether the operator should rerun with a safe autoExecutable plan, narrower
+sender scopes, explicit bindings, or an interactive session.
 
 When safe-yolo is blocked only because the plan needs normal setup work, ask
 for a **bounded delegated approval** over the rendered current plan instead of
@@ -306,31 +331,56 @@ not a parent-thread summary. The receipt must include:
   when using a receipt file, and `notAdHoc:true`.
 - `researchSenderReceipt`: `research-sender` prompt load proof,
   `complete_sender_research` result, sender LinkedIn identity basis, and the
-  notes/proof counts used before the net-new `create_campaign` call.
+  notes/proof counts used before the net-new `create_campaign` call. It must
+  include canonical `promptLoadedToHasMoreFalse:true`,
+  `completeSenderResearch`, and either `senderLinkedinUrl`, non-empty
+  `senderIds`, or non-empty `senderIdentityBasis`, plus `identityBasis`.
 - `campaignBriefReceipt`: the CampaignOffer/campaign id, current
   workflowTableId, brief hash or updated-at marker, delivery format, token
-  rules, hard avoids, source-use rules, and first-message template state.
+  rules, hard avoids, source-use rules, and first-message template state. If
+  the tool output uses `approvedFirstMessageTemplate`, copy it to canonical
+  `firstMessageTemplate`; if it uses `deliveryFormatIncluded`,
+  `tokenRulesIncluded`, `hardAvoidsIncluded`, or `sourceUseRulesIncluded`, copy
+  those to canonical `deliveryFormat`, `tokenRules`, `hardAvoids`, and
+  `sourceUseRules`.
 - `sourceDecisionReceipt`: selected source/list id, provider, cursor/inventory
   state, import/copy caps, explicit `dedupeDncProviderExclusions:true` or an
   equivalent exclusions object, row ids or row-count evidence (`rowCount`,
   `readyRowCount`, or `rowEvidence`), and the reason no colder source was used
-  before the current source was proven exhausted or insufficient.
+  before the current source was proven exhausted or insufficient. If the raw
+  provider output uses `sourceProvider`, `sourceListId`, `reviewBatchRowIds`, or
+  `rationale`, copy them to canonical `provider`, `sourceId`/`sourceListId`,
+  `rowIdsHash`/`rowCount`, and `sourceLadderReason`.
 - `filterDecisionReceipt`: saved/applied filter ids or explicit skip-filter
   decision with current campaign/table basis.
 - `messageDraftingReceipt`: the Message Drafting proof described below,
-  including packaged `generate-messages` prompt/assets and validation.
+  including packaged `generate-messages` prompt/assets and validation. Raw
+  fields like `generateMessagesPromptLoadedToHasMoreFalse`,
+  `requiredAssetsLoadedToHasMoreFalse`,
+  `validationPromptLoadedToHasMoreFalse`,
+  `get_campaign_message_preparation_status`, and
+  `waitForCampaignProcessingProof` are useful, but the receipt must also copy
+  them into canonical `promptLoadedToHasMoreFalse`, `requiredAssetsLoaded`,
+  `validationLoaded`, `reviewBatchRowHash`, and
+  `messageDraftRecommendation`.
 - `reviewBatchReceipt`: review-batch row ids/hash, generated row count,
   quality-valid route-proof row id when approved, and proof that no broad
   approve-all occurred.
 - `sequenceReceipt`: exact current workflowTableId, recommended non-paid
   sequence attach/precheck result, and readback showing `hasSequence:true` when
-  completion is claimed.
+  completion is claimed. If the tool output uses
+  `attachRecommendedSequenceResult.actionTypes` or
+  `nonPaidRecommendedSequence`, copy them to canonical `actionTypes` and
+  `nonPaid`.
 - final paused-send proof: if the current campaign table is `DRAFT` after the
   sequence is attached, call the product `pause_campaign({ campaignId })`
   endpoint/tool to put the unlaunched campaign into `PAUSED` review state, then
   reread the campaign/table. Do not raw-write `campaignStatus`, do not start or
   launch, and do not schedule/send. Completion requires reread proof of
-  `currentStep:"send"` and `campaignStatus:"PAUSED"`.
+  `currentStep:"send"` and `campaignStatus:"PAUSED"`. If the raw output nests
+  this in `finalCampaignRead` or `finalTableRead`, copy it to canonical
+  `finalPausedSendProof.currentStep` and
+  `finalPausedSendProof.campaignStatus`.
 - `verifyCall`: the exact `setup_evergreen_campaigns({ mode:"verify",
   planRevision, selectedActionIds, receipts })` call/result used before the
   parent reports completion.
@@ -345,7 +395,18 @@ substitute `message` for `generatedMessageText`. Do not substitute
 `passVerdict` for `verdict`. If the self-check fails, fix the receipt before
 ending; do not leave the parent to infer canonical fields from top-level
 aliases or narrative text.
+Self-check shorthand: copy raw tool-output aliases into canonical receipt keys
+before writing JSON; do not leave only raw objects like
+`get_campaign_message_preparation_status`, `attachRecommendedSequenceResult`,
+`finalCampaignRead`, or `finalTableRead`.
 Self-check shorthand: top-level `planRevision`, `actionId`, `laneKey`, `laneType`, `workspaceId`, and `senderIds` must exist before worker completion.
+Self-check shorthand: `messageDraftingReceipt.promptLoadedToHasMoreFalse`,
+`requiredAssetsLoaded`, `validationLoaded`, `reviewBatchRowHash`, and
+`messageDraftRecommendation` must exist before worker completion.
+Self-check shorthand: `reviewBatchReceipt.rowIdsHash`,
+`reviewBatchReceipt.generatedCount`, `sequenceReceipt.actionTypes`,
+`sequenceReceipt.nonPaid`, `finalPausedSendProof.currentStep`, and
+`finalPausedSendProof.campaignStatus` must exist before worker completion.
 Self-check shorthand: `sampleMessages[]` must include `rowId`, `generatedMessageText`, `verdict`, and `issues`.
 Self-check shorthand: Do not substitute `message` for `generatedMessageText`.
 Self-check shorthand: Do not substitute `passVerdict` for `verdict`.
@@ -430,9 +491,8 @@ verification unless the same object also appears inside
       "selectedLeadListId": "<source/list id>",
       "reviewBatchRowHash": "<review row ids hash>",
       "messageDraftRecommendation": {"basis": "generate-messages"},
-      "sampleMessages[].verdict": "pass",
       "sampleMessages": [
-        {"rowId": "<row id>", "generatedMessageText": "<message>", "verdict": "pass"}
+        {"rowId": "<row id>", "generatedMessageText": "<message>", "verdict": "passed", "issues": []}
       ]
     },
     "reviewBatchReceipt": {
@@ -442,8 +502,6 @@ verification unless the same object also appears inside
     "sequenceReceipt": {
       "workflowTableId": "<workflow table id>",
       "hasSequence": true,
-      "sequenceReceipt.actionTypes": ["send_invite"],
-      "sequenceReceipt.nonPaid": true,
       "actionTypes": ["send_invite"],
       "nonPaid": true
     },
@@ -571,7 +629,8 @@ The parent then calls
 `setup_evergreen_campaigns({ mode:"verify", postEngagerSenderIds,
 sharedSenderIds, planRevision, selectedActionIds, receipts })` using the same
 sender scopes as the plan call and the original execution planRevision/actionIds,
-and reports only verified completion. A verify call without the same sender scopes can recompute an empty or different plan and is invalid proof. A verify call that uses a later reuse planRevision instead of the original execution planRevision is also invalid proof. Only after verify succeeds, rerun
+and reports only verified completion. Do not include `yolo` in the verify call;
+`yolo` is plan-mode only. A verify call without the same sender scopes can recompute an empty or different plan and is invalid proof. A verify call that uses a later reuse planRevision instead of the original execution planRevision is also invalid proof. Only after verify succeeds, rerun
 `setup_evergreen_campaigns({ mode:"plan", postEngagerSenderIds,
 sharedSenderIds, yolo:true })` without explicit campaign/table bindings. That
 idempotency rerun must return `intent:"reuse"` for every completed lane and no