@sellable/mcp 0.1.367 → 0.1.369

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 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' and 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. 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, and notAdHoc:true. 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.",
+        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. Each lane packet includes workerDispatch with acceptedRuntimes, rejectedRuntimes, requiresVisibleThreadOrDurableReceipt, and receiptArtifactHint; `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. 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' and 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. 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 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: {
@@ -75,7 +75,7 @@ export const setupEvergreenCampaignsToolDefinitions = [
                     type: "array",
                     maxItems: 20,
                     items: { type: "object" },
-                    description: "Required for verify. Structured lane worker receipts from create-campaign/source/message/sequence execution. Customer-visible lanes must use status:'succeeded' or status:'completed' and include createCampaignStepReceipt with setupPlanCall, createCampaignWorkflowReceipt, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall nested inside createCampaignStepReceipt. createCampaignWorkflowReceipt proves the lane worker loaded `$sellable:create-campaign`, `create-campaign-v2`, and `create-campaign-v2/core/flow.v2.json`; top-level-only proof copies are not enough.",
+                    description: "Required for verify. Structured lane worker receipts from create-campaign/source/message/sequence execution. Customer-visible lanes must use status:'succeeded' or status:'completed' and include createCampaignStepReceipt with setupPlanCall, createCampaignWorkflowReceipt, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall nested inside createCampaignStepReceipt. createCampaignWorkflowReceipt proves the lane worker loaded `$sellable:create-campaign`, `create-campaign-v2`, and `create-campaign-v2/core/flow.v2.json`; it must also include a visible workerThreadId or durable receiptArtifactPath with durableReceiptWritten:true. top-level-only proof copies are not enough.",
                 },
             },
             required: [],

package/package.json

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

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

@@ -138,10 +138,38 @@ After bounded delegated approval or safe `--yolo`, fan out lane worker tasks
 only from the current plan. Each worker receives the complete lane packet:
 workspace id, sender ids, lane key/type, existing campaign/table binding or
 create intent, source hints, caps, planRevision, actionId, allowed side effects,
-and postconditions. Workers must explicitly load and use the installed visible
-`$sellable:create-campaign` wrapper as the nested workflow entrypoint, then load
-`create-campaign-v2` and `create-campaign-v2/core/flow.v2.json` through the
-packaged MCP prompt/asset loaders before campaign creation or repair. The
+postconditions, and the packet's `workerDispatch` policy. Treat
+`workerDispatch.requiresVisibleThreadOrDurableReceipt:true` as a hard
+execution boundary, not guidance. Read and preserve `workerDispatch.acceptedRuntimes`,
+`workerDispatch.rejectedRuntimes`, and `workerDispatch.receiptArtifactHint`
+before dispatch.
+
+Worker fan-out must use visible or durable execution. Preferred in local Codex
+is a visible Codex thread created with `codex_app.create_thread`; the parent
+must record the returned thread id, pass exactly one lane packet into that
+thread, and require the worker to write the lane receipt at the artifact path
+named by `workerDispatch.receiptArtifactHint`. A streaming worker or branch
+worker is acceptable only when it writes a durable per-lane receipt artifact as
+it works. `multi_agent_v1.spawn_agent`, raw `spawn_agent`, or any opaque
+Task/subagent runtime that cannot expose a visible thread id or durable receipt
+artifact is not accepted as command-level UAT proof and must not be used for
+mutating evergreen setup.
+
+Run this preflight before the first irreversible product mutation in any lane:
+the parent must have recorded either a visible Codex thread id or a durable
+`receiptArtifactPath` for that lane. If the runtime cannot provide this, stop
+with `blocked: missing_visible_or_durable_lane_worker_runtime` before calling
+`create_campaign`, `update_campaign`, `import_leads`, `confirm_lead_list`, or
+any source/message/sequence mutation. Do not downgrade this to
+`missing_parallel_lane_worker_runtime` when an opaque runtime exists: an
+opaque runtime is still missing visible/durable proof. If a worker creates
+partial product state without receipts, the run is blocked; created objects exist
+is not equivalent to command completion.
+
+Workers must explicitly load and use the installed visible
+`$sellable:create-campaign` wrapper as the nested workflow entrypoint, then
+load `create-campaign-v2` and `create-campaign-v2/core/flow.v2.json` through
+the packaged MCP prompt/asset loaders before campaign creation or repair. The
 worker then uses that create-campaign workflow/subskills for campaign
 creation/setup, source/import, filter choice, Message Drafting, packaged
 `generate-messages`, sequence attachment, and send-review readiness. Do not
@@ -149,20 +177,23 @@ rebuild those steps ad hoc in the parent thread or from a copied receipt
 checklist. The parent thread is only the planner, dispatcher, verifier, and
 receipt collector: it must not call `create_campaign`, `import_leads`,
 `start_campaign_message_preparation`, `update_cell`, or sequence-attach tools
-for a lane that was assigned to a worker. When the host supports branch
-execution, Task/subagent, or separate Codex threads, assign one lane packet per
-worker and run the lane workers in parallel. If the host cannot run parallel
-workers, report `blocked: missing_parallel_lane_worker_runtime` instead of
-silently doing all lane creation sequentially in the parent thread.
+for a lane that was assigned to a worker. When the host supports visible Codex
+threads, branch execution with durable receipts, or a streaming durable worker,
+assign one lane packet per worker and run the lane workers in parallel. If the
+host cannot run parallel workers with visible/durable receipts, report
+`blocked: missing_visible_or_durable_lane_worker_runtime` instead of silently
+doing all lane creation sequentially in the parent thread.
 Short form: the parent thread is the planner, dispatcher, verifier, and receipt collector.
 Before the first mutating lane action, complete an execution-runtime preflight:
-name the callable worker surface/tool that will run lane packets (for example
-Task/subagent, branch worker, separate Codex thread, or an equivalent explicit
-worker runtime). If you cannot name a real callable worker runtime, stop with
-`blocked: missing_parallel_lane_worker_runtime` before calling
+name the callable worker surface/tool that will run lane packets and the proof
+it gives (`thread id`, `receiptArtifactPath`, or both). If you cannot name a
+real callable visible/durable worker runtime, stop with
+`blocked: missing_visible_or_durable_lane_worker_runtime` before calling
 `create_campaign`, `update_campaign`, `import_leads`, `confirm_lead_list`, or
 any source/message/sequence mutation. Creating campaign shells first and then
 discovering the worker runtime is missing is a failed run.
+Legacy reports may mention `blocked: missing_parallel_lane_worker_runtime`;
+for new command runs, use the visible/durable blocker above.
 
 For any lane with `intent:"create"`, the worker must satisfy the normal
 net-new create-campaign preflight before shell creation: load
@@ -187,7 +218,9 @@ not a parent-thread summary. The receipt must include:
   `workflowPromptName:"create-campaign-v2"`,
   `workflowPromptLoadedToHasMoreFalse:true`,
   `workflowAssetPath:"create-campaign-v2/core/flow.v2.json"`,
-  `workflowAssetLoaded:true`, the real `workerRuntime`, and `notAdHoc:true`.
+  `workflowAssetLoaded:true`, the real `workerRuntime`, a visible
+  `workerThreadId` or durable `receiptArtifactPath`, `durableReceiptWritten:true`
+  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.
@@ -258,6 +291,9 @@ verification unless the same object also appears inside
       "workflowAssetPath": "create-campaign-v2/core/flow.v2.json",
       "workflowAssetLoaded": true,
       "workerRuntime": "separate-codex-thread",
+      "workerThreadId": "<visible local Codex thread id>",
+      "receiptArtifactPath": ".planning/artifacts/uat/69/lane-receipts/<planRevision>/<actionId>-<laneKey>.json",
+      "durableReceiptWritten": true,
       "notAdHoc": true
     },
     "campaignBriefReceipt": {
@@ -335,6 +371,12 @@ succeeds should the parent perform the idempotency rerun.
 If any required field is missing, report
 `blocked: missing_create_campaign_step_receipt` for that lane and do not call it
 complete.
+If `createCampaignWorkflowReceipt.workerRuntime` is
+`multi_agent_v1.spawn_agent`, `spawn_agent`, or another opaque worker runtime,
+or if it lacks both `workerThreadId` and a durable receipt artifact proof, treat
+the lane as `blocked: missing_create_campaign_step_receipt` with detail
+`createCampaignWorkflowReceipt.workerRuntime.visible_or_durable`; do not call
+verify and do not repair by summarizing product readback in the parent.
 
 Message Drafting runtime rule: the preferred proof source is the normal
 create-campaign branch handoff (`watchNarration.workerDetails.messageDraftBuilder`