@sellable/install 0.1.280 → 0.1.282

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.280",
+  "version": "0.1.282",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-evergreen-campaigns.md

@@ -572,8 +572,15 @@ 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:
@@ -816,6 +823,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`,
@@ -938,32 +956,48 @@ 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`
 or equivalent) with `statusSource:"branch"`. If that internal branch handoff is
-not callable or not exposed in the packaged MCP runtime, do **not** stop after
-creating/importing rows. The lane worker must run the packaged message-drafting
-path itself in the worker thread:
-
-1. Load `get_subskill_prompt({ subskillName:"generate-messages" })` until
-   `hasMore:false`.
-2. Load the required message assets and `create-campaign-v2-validation`.
-3. Call `start_campaign_message_preparation({ campaignId, tableId,
+not callable or not exposed in the packaged MCP runtime, do **not** substitute
+plain row generation. The lane worker must inline the same
+`post-find-leads-message-scout` contract in the worker thread before any
+`start_campaign_message_preparation` call:
+
+1. Run the `post-find-leads-message-scout` branch, or inline its packaged
+   contract when branch launch is unavailable, from the current campaign/table,
+   selected lead list, saved filters, review batch row ids/hash, brief hash,
+   `mode:"create-campaign-v2"`, and lane type.
+2. Load `get_subskill_prompt({ subskillName:"generate-messages" })` until
+   `hasMore:false`, all required message assets, and
+   `create-campaign-v2-validation`.
+3. Produce a concrete `messageDraftRecommendation` before row generation. It
+   must include the selected message approach/template recommendation,
+   token/fill rules, source-use rules, hard avoids, at least one rendered good
+   sample, current campaign/table/source basis, and validation status. Shared
+   lanes still use `firstMessageTemplateState:"not preset; generate-messages
+   branch selected the final message approach"`; do not set
+   `firstMessageTemplate` for shared lanes.
+4. Persist the recommendation into the campaign brief/message generation basis
+   with the packaged create-campaign tools before generating rows. If the
+   generated copy fails review, update the campaign brief/message template with
+   `update_campaign_brief` or `revise_message_template_and_rerun`, then rerun
+   Generate Message and review current-revision generated output.
+5. Only after the scout recommendation and persisted basis exist, call
+   `start_campaign_message_preparation({ campaignId, tableId,
    targetPreparedMessages, maxRowsToCheck, approvalMode:"mark_ready",
    autoContinue:true })` inside the same lane worker, with bounded caps from the
-   lane packet.
-   Never call `start_campaign_message_preparation` with `approvalMode:"approve"`
-   for evergreen setup. Generate/readiness and approval are separate safety
-   steps: first mark rows ready, then inspect generated copy, then approve
-   exactly one semantic Approved cell through `select_campaign_cells` and
-   `update_cell`.
+   lane packet. `start_campaign_message_preparation` is row execution proof
+   only; it is not Message Drafting proof and cannot satisfy this step by
+   itself. Never call `start_campaign_message_preparation` with
+   `approvalMode:"approve"` for evergreen setup.
+   Generate/readiness and approval are separate safety steps: first mark rows
+   ready, then inspect generated copy, then approve exactly one semantic
+   Approved cell through `select_campaign_cells` and `update_cell`.
    Approval shorthand: approve exactly one semantic Approved cell.
    In this message-drafting path, `update_cell` is allowed only for the semantic
    Approved checkbox. Do not use `update_cell` or any row/cell write to edit
    generated message text, sample copy, or final message bodies in automation.
-   If generated copy fails review, update the campaign brief/message template
-   with `update_campaign_brief` or `revise_message_template_and_rerun`, then
-   rerun Generate Message and review current-revision generated output. Receipt
-   `sampleMessages` must come from generated current-revision cells after the
-   brief/template rerun, not from hand-edited message cell overrides. If a lane
-   used a generated-message body override, report
+   Receipt `sampleMessages` must come from generated current-revision cells
+   after the brief/template rerun, not from hand-edited message cell overrides.
+   If a lane used a generated-message body override, report
    `blocked: generated_message_cell_override` instead of success.
    Do not repair by overwriting bad generated message cells and then calling the
    overwritten cells `sampleMessages`.
@@ -974,9 +1008,9 @@ path itself in the worker thread:
    Short form: `update_cell` is allowed only for the semantic Approved checkbox.
    Short form: Do not use `update_cell` to edit generated message text.
    Short form: Bad copy requires brief/template revision plus Generate Message rerun.
-4. Poll `get_campaign_message_preparation_status` until no queued/active cells
+6. Poll `get_campaign_message_preparation_status` until no queued/active cells
    remain or a bounded stop reason is returned.
-5. Use `get_campaign_messages_preview` or `select_campaign_cells` to inspect
+7. Use `get_campaign_messages_preview` or `select_campaign_cells` to inspect
    generated rows, quality-review at least 3 samples, approve exactly one
    quality-valid route-proof row when none is already approved, and prove no
    broad approve-all happened.
@@ -986,16 +1020,21 @@ path itself in the worker thread:
    approvedGeneratedMessageCount exactly 1. Do not report completion with 2+
    approved rows.
    Approval shorthand: Do not report completion with 2+ approved rows.
-6. Continue to `attach_recommended_sequence({ campaignId, currentStep:"send" })`
+8. Continue to `attach_recommended_sequence({ campaignId, currentStep:"send" })`
    and, if the campaign is still `DRAFT`, `pause_campaign({ campaignId })`.
    Reread the campaign/table before claiming completion.
 
 That packaged worker path must return `messageDraftingReceipt.statusSource:
 "packaged-generate-messages-worker"`. It is accepted only when the receipt
-includes the same prompt/assets/validation proof, current campaign/table/source
-basis, generated review rows, sample messages, quality review, route-proof
-approval evidence, sequence proof, and final paused-send proof required of the
-branch handoff. `statusSource:"parent-thread-fallback"` is still invalid.
+includes branch-equivalent `post-find-leads-message-scout` proof, the
+`messageDraftRecommendation`, proof the recommendation was persisted into the
+brief/message basis before row generation, the prompt/assets/validation proof,
+current campaign/table/source basis, generated review rows, sample messages,
+quality review, route-proof approval evidence, sequence proof, and final
+paused-send proof required of the branch handoff. `statusSource:
+"parent-thread-fallback"` is still invalid. If neither branch handoff nor
+inline scout proof can run, stop with `blocked:
+missing_message_drafting_branch`; do not shortcut through row prep.
 The only accepted statusSource values are exactly `branch` and
 `packaged-generate-messages-worker`; descriptive aliases such as
 `package-readback-local-thread` are rejected.
@@ -1076,8 +1115,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
@@ -1365,16 +1409,25 @@ Message, and verify current-revision sample messages before final completion.
       Short form: missing or skipped filter proof is `blocked: missing_filter_setup`.
       Short form: run Message Drafting only after saved filters are applied.
     - Every customer-visible lane must run Message Drafting from the current
-      campaign/table basis after source rows exist. The worker must load the full
-      packaged `generate-messages` prompt, every required asset, and
-      `create-campaign-v2-validation`; if the internal branch handoff is not
-     callable in the packaged runtime, the worker must call
-     `start_campaign_message_preparation` and poll
-     `get_campaign_message_preparation_status` from the lane worker. The
-     returned receipt must include `statusSource:"branch"` or
-     `statusSource:"packaged-generate-messages-worker"`, at least 3 concrete
-     reviewed sample messages, a passed validation result, and a passed quality
-     review. Row/message counts alone are not enough.
+      campaign/table basis after source rows exist and saved filters are
+      applied. The worker must use the normal
+      `post-find-leads-message-scout` branch handoff or inline that same scout
+      contract when branch launch is unavailable. Plain
+      `start_campaign_message_preparation` is row execution proof only; it is
+      not a fallback substitute for Message Drafting. The worker must load the
+      full packaged `generate-messages` prompt, every required asset, and
+      `create-campaign-v2-validation`; before row generation, the receipt must
+      show branch-equivalent scout proof, a concrete
+      `messageDraftRecommendation`, and proof that recommendation was persisted
+      into the campaign brief/message generation basis. Only then may the
+      worker call `start_campaign_message_preparation` and poll
+      `get_campaign_message_preparation_status` from the lane worker. The
+      returned receipt must include `statusSource:"branch"` or
+      `statusSource:"packaged-generate-messages-worker"`, at least 3 concrete
+      reviewed sample messages, a passed validation result, and a passed quality
+      review. Row/message counts alone are not enough. If the branch handoff and
+      inline scout contract are both unavailable, report
+      `blocked: missing_message_drafting_branch`.
 
    - **The brief must declare the delivery format** so Generate Message writes copy suited to how it actually sends:
      - DM lanes: add a `Delivery format:` line — either `multiline (each paragraph sends as its own DM message)` or `single message`. When multiline, the template's blank-line paragraphs ARE the message boundaries — write each one as a standalone typed message.
@@ -1412,12 +1465,15 @@ Message, and verify current-revision sample messages before final completion.
      `hasMore:false`, required message assets were loaded, and
      `create-campaign-v2-validation` ran through
      `workerDetails.messageDraftBuilder` with `statusSource:"branch"` or
-     through the lane worker's packaged message-prep path with
-     `statusSource:"packaged-generate-messages-worker"`,
-     `start_campaign_message_preparation`, and
+     through the lane worker's inline `post-find-leads-message-scout` contract
+     with `statusSource:"packaged-generate-messages-worker"`. For the packaged
+     worker path, proof must include branch-equivalent scout proof, a concrete
+     `messageDraftRecommendation`, template/basis persistence proof before row
+     generation, `start_campaign_message_preparation`, and
      `get_campaign_message_preparation_status`. The generated-message cells are
      not prompt proof; `currentRevisionGeneratedMessages` and row previews are
-     only downstream cell evidence. The proof must include
+     only downstream cell evidence. Row prep alone is not prompt proof. The
+     proof must include
       `validationResult:"passed"`, a passed quality review, and at least 3
       reviewed sample messages. For Shared Cold Fallback, reject samples that
       open with a standalone name followed by "Hey there" or a similarly generic
@@ -1497,7 +1553,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.