@sellable/mcp 0.1.441 → 0.1.442

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

@@ -23,7 +23,7 @@ export const setupEvergreenCampaignsToolDefinitions = [
                 handoffMode: {
                     type: "string",
                     enum: ["create_campaign_goals"],
-                    description: 'plan mode only. When set to "create_campaign_goals", returns concise per-lane `$sellable:create-campaign` goal prompts and required inputs for simplified worker handoffs without changing verification behavior.',
+                    description: 'plan mode only. When set to "create_campaign_goals", returns concise per-lane `$sellable:create-campaign` goal prompts and required inputs for simplified worker handoffs without changing verification behavior. The matching createCampaignGoals[].goalPrompt is the authoritative campaign task for the lane worker; lane packet fields are operational scope and receipt proof context only.',
                 },
                 yolo: {
                     type: "boolean",

package/package.json

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

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

@@ -62,13 +62,15 @@ long-form contract below:
    callable, return `blocked: missing_visible_or_durable_lane_worker_runtime`
    before mutation.
 4. Write one compact prompt file per selected lane using the matching
-   `createCampaignGoals[].goalPrompt`, plus only the receipt path and canonical
-   receipt requirement. Do not paste the full evergreen skill, lane packet,
-   receipt schema, repair history, or verifier checklist into the worker prompt.
-   The worker goal is simple: run `$sellable:create-campaign` normally for that
-   campaign goal, use the evergreen-selected provider/source only as internal
-   sourcing metadata, and write the receipt. The parent does not create campaign
-   shells.
+   `createCampaignGoals[].goalPrompt` as the authoritative campaign task, plus
+   only the lane packet, receipt path, side-effect caps, and canonical receipt
+   requirement. Paste the goal prompt verbatim; do not replace it with a
+   handcrafted `Goal:` paragraph. Do not paste the full evergreen skill, receipt
+   schema, repair history, verifier checklist, or lane-specific copy checklist
+   into the worker prompt. The worker goal is simple: run
+   `$sellable:create-campaign` normally for that campaign goal, use the
+   evergreen-selected provider/source only as internal sourcing metadata, and
+   write the receipt. The parent does not create campaign shells.
 5. Collect fresh durable receipts, verify with the original planRevision and
    selectedActionIds, then run the idempotency plan and show sample messages.
 
@@ -497,10 +499,17 @@ path/thread id, stop with `blocked: parent_mutated_before_worker_receipt` and
 do not continue setup in the parent.
 Short form: dispatch every selected lane worker before shell creation.
 Short form: do not call `setup_evergreen_campaigns` with `mode:"apply"` from the parent.
-Use a compact worker prompt: include lane packet JSON, original selectedActionIds,
-original planRevision, parent postEngagerSenderIds, parent sharedSenderIds,
-receiptArtifactPath, workspace id, sender ids, side-effect caps, and the
-instruction to load packaged prompts through MCP.
+Use a compact worker prompt: include the exact matching
+`createCampaignGoals[].goalPrompt`, lane packet JSON, original
+selectedActionIds, original planRevision, parent postEngagerSenderIds, parent
+sharedSenderIds, receiptArtifactPath, workspace id, sender ids, side-effect
+caps, and the instruction to load packaged prompts through MCP. The worker
+prompt must explicitly state the authority order:
+`createCampaignGoals[].goalPrompt` first, then loaded `$sellable:create-campaign`
+/ `create-campaign-v2` / `generate-messages` prompts and assets, then evergreen
+lane/receipt proof requirements. Evergreen packet fields and receipt rules are
+operational proof context only; they must not become campaign brief copy,
+message-writing instructions, or generated customer-facing text.
 The worker prompt must include the exact filter status rule:
 `filterDecisionReceipt.status:"applied"` only; never `completed`, `confirmed`,
 `done`, or any other alias.
@@ -542,7 +551,9 @@ worker with stdin redirected from that file:
 
 ```
 codex -a never -s danger-full-access exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
-Use $sellable:create-evergreen-campaigns as the governing skill for this one lane worker.
+Use $sellable:create-campaign as the governing campaign workflow for this one lane worker.
+Use the evergreen plan/packet below only for lane scope, source metadata,
+postconditions, side-effect caps, and durable receipt proof.
 
 Workspace id: <workspaceId>
 Parent planRevision: <planRevision>
@@ -558,6 +569,24 @@ If your runtime exposes a goal tool, create or maintain this exact goal:
 complete action <actionId> only when <receiptArtifactPath> exists as valid JSON
 for this lane or when a blocked receipt has been written at that same path.
 
+Create-campaign goal prompt (authoritative; paste verbatim from the matching
+createCampaignGoals[].goalPrompt):
+<createCampaignGoalPrompt>
+
+Authority order:
+1. The create-campaign goal prompt above is the campaign task.
+2. Loaded `$sellable:create-campaign`, `create-campaign-v2`, and
+   `generate-messages` prompts/assets own the campaign brief and message
+   strategy.
+3. The evergreen lane packet and receipt rules below are operational scope and
+   proof requirements only.
+
+Do not paste evergreen lane keys, provider/source names, receipt terms, setup
+plan terminology, verifier fields, or workflow mechanics into the campaign
+brief or generated customer-facing messages. Do not add evergreen-authored
+message-writing rules to the brief; let the loaded create-campaign and
+generate-messages workflow do its job.
+
 Worker lane packet JSON:
 <lane packet JSON>
 
@@ -587,8 +616,9 @@ WORKER_PROMPT
 codex -a never -s danger-full-access exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - < <worker-prompt-file>
 ```
 
-If any placeholder cannot be filled from the current lane packet, do not inspect
-the filesystem or rerun inventory; stop with `blocked: worker_dispatch_stalled`.
+If any placeholder cannot be filled from the current plan, matching
+`createCampaignGoals[]` entry, or lane packet, do not inspect the filesystem or
+rerun inventory; stop with `blocked: worker_dispatch_stalled`.
 `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
@@ -1276,7 +1306,7 @@ Message, and verify current-revision sample messages before final completion.
      Short form: Do not pass the warm template into Shared Signal Discovery or Shared Cold Fallback.
      Short form: Shared lanes must reject generic product-summary samples.
      Short form: Shared lanes must reject three nearly identical samples.
-     Short form: Shared lanes must reject unsupported intent-assumptive hedges; Shared Signal Discovery may use Dotwork-style topic bridges like "saw you might be interested in [topic], so hope this is relevant", "saw you in a few conversations about [topic], so hope this is relevant", or "hope this is relevant if [topic] is part of the plan" when the source evidence supports the topic and the line does not claim engagement or expose source mechanics.
+     Short form: Shared lane message quality is owned by the packaged generate-messages prompt and validation; evergreen does not author source-thread bridge phrasing.
      Short form: Shared lanes must reject internal workflow vocabulary.
      Short form: revise or rerun the packaged create-campaign/generate-messages path.
    - **Post Engagers** first-message style: short, casual, references the
@@ -1342,7 +1372,7 @@ Message, and verify current-revision sample messages before final completion.
      Short form: Shared Signal Discovery uses no self-intro such as "I'm building Sellable".
      Short form: Shared Signal Discovery uses no self-intro such as "We're building Sellable".
      Short form: Shared Signal Discovery uses no "I've put together".
-     Short form: topic-level bridges, including "saw you might be interested in [topic], so hope this is relevant", "saw you in a few conversations about/around [topic], so hope this is relevant", and "hope this is relevant if [topic] is part of the plan", are allowed for Shared Signal Discovery when evidence-backed and not engagement-claiming; do not use bare "might be interested" as a generic intent claim.
+     Short form: topic-level bridge rules are owned by the packaged generate-messages prompt and validation, not by the evergreen wrapper.
      Short form: no internal workflow vocabulary such as "Codex-style workflow", "MCP", "agent workflows", "Claude Code", or "Claude-style agent workflows".
    - **Shared Cold Fallback** first-message style: cold, direct, and cohesive.
      It must not pretend there was engagement, must not say "saw you pop up",