@sellable/install 0.1.282 → 0.1.283

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.282",
+  "version": "0.1.283",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-evergreen-campaigns.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,8 @@ 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 lanes must reject unsupported low-confidence relevance hedges.
+     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
@@ -1317,21 +1348,12 @@ Message, and verify current-revision sample messages before final completion.
      product summaries, or repeated structure are bad. If the first generated
      batch violates these rules, rerun, but record that as a repaired UAT path
      rather than the desired zero-shot path.
-     Use the Dotwork gold-standard shape for Shared Signal Discovery samples
-     when the row supports a topic-level weak signal: "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 "saw you in a
-     few conversations around [topic], so hope this is relevant". These bridges
-     are allowed only when source evidence supports the topic and the line does
-     not claim a reaction, comment, sender-authored post, or other engagement
-     that is not proven. Do not use "found you in a thread" or other raw
-     source/discovery mechanics.
-     Shared Signal Discovery InMail subjects should follow the Dotwork plus-sign
-     A + B + C pattern: concrete topic + buyer outcome + useful artifact/picture,
-     for example "initiatives + business outcomes + one live picture".
-     Translate source/tool terms into prospect-facing business language; do not
-     put internal workflow
-     vocabulary such as "Codex-style workflow", "MCP", "agent workflows",
+     Shared Signal Discovery samples may use a supported topic bridge such as
+     "saw you around conversations about [high-level topic], so hope this is
+     relevant" when the topic is grounded in source evidence and not
+     activity-log phrasing. Translate source/tool terms into prospect-facing
+     business language; do not put internal workflow vocabulary such as
+     "Codex-style workflow", "MCP", "agent workflows",
      "Claude Code", or "Claude-style agent workflows" in customer-facing
      message one. Also avoid generic product-process nouns such as "dashboard",
      "workflow", "source", "send-ready copy", "reviewed prospect lists",
@@ -1342,7 +1364,8 @@ 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: Shared Signal Discovery may use "saw you around conversations about [topic], so hope this is relevant" when source-supported.
+     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",
@@ -1358,14 +1381,15 @@ Message, and verify current-revision sample messages before final completion.
      Sellable/Codex/Claude-Code feature summary
      across prospects. This is a single-message cold path unless the approved
      create-campaign message workflow proves a better delivery format.
-     Do not use source-thread hedges such as "hope this is relevant", "might be
-     interested", or "saw you in a few conversations" in Shared Cold Fallback.
-     Start from a concrete role, company, or buyer-problem observation instead.
-     Do not use a repeated
-     product-definition paragraph such as "Sellable is a GTM system" across
-     samples; every reviewed cold sample should be specific enough to the role,
-     company, or problem that the three sample messages do not share the same
-     body skeleton.
+     Do not open with "hope this is relevant" or a similar low-confidence
+     relevance hedge in Shared Cold Fallback. Do not use a repeated product-definition paragraph such
+     as "Sellable is a GTM system" across samples; every reviewed cold sample
+     should be specific enough to the role, company, or problem that the three
+     sample messages do not share the same body skeleton.
+     Do not use source-thread hedges such as "might be interested", "saw you
+     around conversations about...", or "saw you in a few conversations" in
+     Shared Cold Fallback. Start from a concrete role, company, or buyer-problem
+     observation instead.
      Do not use mechanical Sellable process language such as "campaign idea into
      prospects, filters, messages, and sequence setup", "sequence-prospects",
      "dashboard overhead", "campaign map", "send-ready copy", or "reviewed
@@ -1382,7 +1406,8 @@ Message, and verify current-revision sample messages before final completion.
      Short form: Shared Cold Fallback uses no "I've put together".
      Short form: Shared Cold Fallback uses no opt-out shrug such as "If this isn't relevant, ignore me".
      Short form: Shared Cold Fallback uses no product-stack dump.
-     Short form: no "hope this is relevant", "might be interested", or "saw you in a few conversations" in Shared Cold Fallback; Shared Signal Discovery has the topic-level conversation-bridge exception above.
+     Short form: Shared Cold Fallback uses no low-confidence relevance hedge such as "hope this is relevant".
+     Short form: no "hope this is relevant", "might be interested", "saw you around conversations about", or "saw you in a few conversations" in Shared Cold Fallback; Shared Signal Discovery has the topic-level conversation-bridge exception above.
      Short form: no repeated product-definition paragraph such as "Sellable is a GTM system".
     - Customer-visible evergreen lanes must enable ICP filtering before Message
       Drafting. This applies to Post Engagers, Shared Signal Discovery, and
@@ -1483,13 +1508,18 @@ Message, and verify current-revision sample messages before final completion.
       or a product-stack dump that repeats the same
       Sellable/Codex/Claude-Code feature summary across prospects. For all
       shared lanes, reject generic product-summary samples, repeated
-      near-identical samples, intent-assumptive hedges such as "might be
-      interested", source-context mismatches such as "saw you in a few
-      conversations" in Shared Cold Fallback, internal workflow vocabulary, any
-      sample with non-empty `issues`, and any preserved Post Engagers opener;
-      revise or rerun the packaged create-campaign/generate-messages path before
-      reporting completion. Do not approve or final-report samples
-      with `verdict:"passed"` and non-empty `issues`.
+      near-identical samples, unsupported low-confidence relevance hedges, internal
+      workflow vocabulary, any sample with non-empty `issues`, and any preserved
+      Post Engagers opener; revise or rerun the packaged
+      create-campaign/generate-messages path before reporting completion. Do not
+      approve or final-report samples with `verdict:"passed"` and non-empty
+      `issues`.
+      Shared Signal Discovery samples may use `"saw you around conversations
+      about [high-level topic], so hope this is relevant"` when the topic is
+      supported by source evidence and not activity-log phrasing. Shared Cold
+      Fallback samples must still reject source/conversation hedges such as
+      `"hope this is relevant"`, `"might be interested"`, or `"saw you in a few
+      conversations"`.
    - The first review batch exists and at least 3 review rows have generated
      messages from the approved brief. If fewer than 3 usable rows exist, report
      the actual count and why.