@sellable/mcp 0.1.375 → 0.1.376

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -16,10 +16,11 @@ Each message gets 5+ minutes of Claude attention with deep research - no other t
16
16
 
17
17
  ### Prompt Source Of Truth
18
18
 
19
- There are five public Sellable entrypoints shared across hosts:
19
+ There are six public Sellable entrypoints shared across hosts:
20
20
 
21
21
  - `sellable:create-campaign`
22
22
  - `sellable:create-ab-test`
23
+ - `sellable:create-evergreen-campaigns`
23
24
  - `sellable:foundation`
24
25
  - `sellable:content`
25
26
  - `sellable:create-post`
@@ -35,6 +36,11 @@ review-copy campaigns from:
35
36
 
36
37
  - `mcp/sellable/skills/create-ab-test/SKILL.md`
37
38
 
39
+ The create-evergreen-campaigns public wrapper reconciles standing evergreen
40
+ campaign lanes and loads the command-backed setup workflow from:
41
+
42
+ - `mcp/sellable/skills/create-evergreen-campaigns/SKILL.md`
43
+
38
44
  The foundation public wrapper loads the core identity/company memory workflow
39
45
  from:
40
46
 
@@ -179,9 +185,11 @@ The installer does the full local setup:
179
185
 
180
186
  After the installer passes, fully quit and reopen Codex Desktop. Start a new
181
187
  thread and select `Sellable Create Campaign`, `Sellable Create A/B Test`,
182
- `Sellable Foundation`, `Sellable Content`, or `Sellable Create Post`; or invoke
188
+ `Sellable Create Evergreen Campaigns`, `Sellable Foundation`,
189
+ `Sellable Content`, or `Sellable Create Post`; or invoke
183
190
  `$sellable:create-campaign`, `$sellable:create-ab-test`,
184
- `$sellable:foundation`, `$sellable:content`, or `$sellable:create-post`. If the app still says
191
+ `$sellable:create-evergreen-campaigns`, `$sellable:foundation`,
192
+ `$sellable:content`, or `$sellable:create-post`. If the app still says
185
193
  `mcp__sellable__*` tools are missing after the installer passes, check that
186
194
  `~/.codex/config.toml` contains both `[marketplaces.sellable]` and
187
195
  `[plugins."sellable@sellable"]`.
@@ -194,22 +202,26 @@ Use these names consistently:
194
202
 
195
203
  - Claude Code command: `/sellable:create-campaign`
196
204
  - Claude Code command: `/sellable:create-ab-test`
205
+ - Claude Code command: `/sellable:create-evergreen-campaigns`
197
206
  - Claude Code command: `/sellable:foundation`
198
207
  - Claude Code command: `/sellable:content`
199
208
  - Claude Code command: `/sellable:create-post`
200
209
  - Codex command: `$sellable:create-campaign`
201
210
  - Codex command: `$sellable:create-ab-test`
211
+ - Codex command: `$sellable:create-evergreen-campaigns`
202
212
  - Codex command: `$sellable:foundation`
203
213
  - Codex command: `$sellable:content`
204
214
  - Codex command: `$sellable:create-post`
205
215
  - Codex Desktop plugin: `sellable@sellable`
206
216
  - Codex visible skill: `Sellable Create Campaign`
207
217
  - Codex visible skill: `Sellable Create A/B Test`
218
+ - Codex visible skill: `Sellable Create Evergreen Campaigns`
208
219
  - Codex visible skill: `Sellable Foundation`
209
220
  - Codex visible skill: `Sellable Content`
210
221
  - Codex visible skill: `Sellable Create Post`
211
222
  - Codex skill frontmatter name: `create-campaign`
212
223
  - Codex skill frontmatter name: `create-ab-test`
224
+ - Codex skill frontmatter name: `create-evergreen-campaigns`
213
225
  - Codex skill frontmatter name: `foundation`
214
226
  - Codex skill frontmatter name: `content`
215
227
  - Codex skill frontmatter name: `create-post`
@@ -6,7 +6,7 @@ async function postSetupEvergreenCampaigns(body) {
6
6
  export const setupEvergreenCampaignsToolDefinitions = [
7
7
  {
8
8
  name: "setup_evergreen_campaigns",
9
- 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: lane workers must use get_subskill_prompt and get_subskill_asset for `$sellable:create-campaign`, create-campaign-v2, generate-messages, and assets; 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, 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. In local Codex, call `codex_app.list_projects` first, then `codex_app.create_thread` with a local project target; do not create a worktree for lane execution. 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.",
9
+ 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: lane workers must use get_subskill_prompt and get_subskill_asset for `$sellable:create-campaign`, create-campaign-v2, generate-messages, and assets; 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, call `codex_app.list_projects` first, then `codex_app.create_thread` with a local project target; do not create a worktree for lane execution. 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.",
10
10
  inputSchema: {
11
11
  type: "object",
12
12
  properties: {
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@sellable/mcp",
3
- "version": "0.1.375",
3
+ "version": "0.1.376",
4
4
  "type": "module",
5
5
  "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
6
6
  "main": "dist/index.js",
@@ -199,8 +199,18 @@ environment:{type:"local"}}`. Do not create a worktree target for evergreen
199
199
  UAT or lane execution. The parent must record the returned thread id, pass
200
200
  exactly one lane packet into that thread, and require the worker to write the
201
201
  lane receipt at the artifact path named by
202
- `workerDispatch.receiptArtifactHint`. A streaming worker or branch worker is
203
- acceptable only when it writes a durable per-lane receipt artifact as it works.
202
+ `workerDispatch.receiptArtifactHint`. That path is run-specific and must include
203
+ the packet's `workerDispatch.receiptRunId`. Before dispatch, if a file already
204
+ exists at the hinted path, do not trust or verify it; move it aside or choose the
205
+ fresh hinted path from a new plan. A valid receipt must be written after
206
+ `workerDispatch.receiptMustBeWrittenAfter`, reread by the parent after the
207
+ worker exits, and contain the current `planRevision`, `actionId`, `laneKey`,
208
+ `receiptArtifactPath`, and `durableReceiptWritten:true`. If a receipt predates
209
+ the current run, uses an old path without `receiptRunId`, or was not freshly
210
+ written by the current worker, stop with `blocked: stale_receipt_artifact`
211
+ before parent verify or completion. A streaming worker or branch worker is
212
+ acceptable only when it writes a fresh durable per-lane receipt artifact as it
213
+ works.
204
214
  `multi_agent_v1.spawn_agent`, raw `spawn_agent`, or any opaque Task/subagent
205
215
  runtime that cannot expose a visible thread id or durable receipt artifact is
206
216
  not accepted as command-level UAT proof and must not be used for mutating
@@ -366,7 +376,7 @@ verification unless the same object also appears inside
366
376
  "workflowAssetLoaded": true,
367
377
  "workerRuntime": "separate-codex-thread",
368
378
  "workerThreadId": "<visible local Codex thread id>",
369
- "receiptArtifactPath": ".planning/artifacts/uat/69/lane-receipts/<planRevision>/<actionId>-<laneKey>.json",
379
+ "receiptArtifactPath": ".planning/artifacts/uat/69/lane-receipts/<planRevision>/<receiptRunId>/<actionId>-<laneKey>.json",
370
380
  "durableReceiptWritten": true,
371
381
  "notAdHoc": true
372
382
  },