@sellable/install 0.1.281 → 0.1.283

package/bin/sellable-install.mjs

@@ -37,7 +37,7 @@ function getInstallVersion() {
   }
 }
 
-const CODEX_PLUGIN_VERSION = "0.1.52";
+const CODEX_PLUGIN_VERSION = "0.1.53";
 const CODEX_PLUGIN_COMPAT_VERSIONS = [
   "0.1.8",
   "0.1.9",
@@ -74,6 +74,7 @@ const CODEX_PLUGIN_COMPAT_VERSIONS = [
   "0.1.40",
   "0.1.41",
   "0.1.51",
+  "0.1.52",
 ];
 const RAW_INSTALL_PACKAGE_SPEC =
   process.env.SELLABLE_INSTALL_PACKAGE_SPEC || "@sellable/install@latest";

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.281",
+  "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>
 
@@ -572,16 +601,24 @@ response, run a local file-existence and JSON self-check for
 receipt there; if any postcondition, quality gate, verifier schema, or file
 write blocks, write a canonical blocked receipt there with `status:"blocked"`,
 `blocker`, `campaignId`, `tableId`, `actionId`, `laneKey`, `planRevision`, and
-the latest product readback. The terminal condition is filesystem proof that
-<receiptArtifactPath> exists.
+the latest product readback. For Post Engagers lanes, no sender-authored posts
+or no sender-owned post-engager source is an acceptable terminal blocked/no-op
+receipt, not a worker crash: use one of
+`post_engagers_no_sender_posts`, `post_engagers_no_recent_sender_posts`,
+`post_engagers_no_sender_owned_posts`, or
+`post_engagers_source_author_mismatch`, include the source/readback evidence,
+and stop without scraping third-party authors or generating misleading warm
+copy. The terminal condition is filesystem proof that <receiptArtifactPath>
+exists.
 WORKER_PROMPT
 
 # Multi-worker launcher equivalent:
 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
@@ -816,6 +853,17 @@ the lane is complete. Do not use `status:"passed"` or
 in a separate `warnings` array, but the completion status stays canonical.
 The backend verifier rejects `status:"passed"`, `status:"pass"`, and
 `status:"passed_with_warnings"` as primary completion statuses.
+Exception: a Post Engagers lane may write `status:"blocked"` when Sellable MCP
+sender-post/source readback proves there are no recent sender-authored posts to
+scrape, no sender-owned post-engager source, or the current source is authored
+by someone else. Use the explicit blocker codes
+`post_engagers_no_sender_posts`, `post_engagers_no_recent_sender_posts`,
+`post_engagers_no_sender_owned_posts`, or
+`post_engagers_source_author_mismatch`. Parent verify treats these as
+`acceptedLaneBlockers`, so the parent can report the truthful no-op instead of
+retrying invalid source repair. This exception does not apply to shared lanes,
+bad generated copy, stale plans, target mismatch, missing receipt files, launch
+or schedule side effects, or arbitrary worker failures.
 
 All step proof objects must live under `createCampaignStepReceipt`. Do not put
 `createCampaignWorkflowReceipt`, `campaignBriefReceipt`,
@@ -1097,8 +1145,13 @@ 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. 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
+and reports only verified completion. If verify returns `verified:true` with
+`acceptedLaneBlockers`, report those lanes as accepted blocked/no-op lanes, not
+completed campaigns. 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
@@ -1253,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
@@ -1294,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",
@@ -1319,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",
@@ -1335,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
@@ -1359,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
@@ -1460,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.
@@ -1530,7 +1583,7 @@ Message, and verify current-revision sample messages before final completion.
      internal-only objects, verify the active waterfall linkage, table ID,
      source type, and priority, and label them `internal source pool` rather
      than treating them as completed campaigns.
-   - Post Engagers lanes are sender-owned source lanes. The selected/source LinkedIn posts must be authored by that exact sender (for example, Thomas post-engager source posts must visibly be Thomas-authored posts). If selected/source posts include another person or company author, mark the slot `blocked`/`flagged` for source repair; do not scrape/import engagers or report completion until the source is sender-owned. Shared Signal Discovery lanes are the only evergreen lanes allowed to mix authors.
+   - Post Engagers lanes are sender-owned source lanes. The selected/source LinkedIn posts must be authored by that exact sender (for example, Thomas post-engager source posts must visibly be Thomas-authored posts). If Sellable MCP readback proves the sender has no recent posts to scrape, no sender-authored posts with usable engagers, no sender-owned post-engager source, or the selected/source posts include another person or company author, write a blocked receipt with the matching accepted blocker code and report that back to the parent as an accepted no-op. Do not scrape/import engagers from third-party authors and do not report completion until the source is sender-owned. Shared Signal Discovery lanes are the only evergreen lanes allowed to mix authors.
 5. **Interactive polish mode only: confirm the message template with the user — and check it reads chat-native.** Show the exact first-message template each created campaign's brief carries and ask the user to confirm or adjust it before moving on. Because DM copy may send paragraph-by-paragraph (each blank-line block becomes its own message), every paragraph must read like something a human literally typed as a separate chat message:
    - **No letter punctuation.** `Hey {{first_name}}` — never `Hey {{first_name}},` (nobody types a trailing comma and hits send). No `Dear`, no sign-offs, no `Best,`.
    - Each paragraph stands alone as a message — short, lowercase-casual is fine, sentence fragments are fine.