@sellable/install 0.1.240 → 0.1.242

package/package.json

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

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

@@ -215,7 +215,8 @@ After bounded delegated approval or safe `--yolo`, fan out lane worker tasks
 only from the current plan. Each worker receives the complete lane packet:
 workspace id, sender ids, lane key/type, existing campaign/table binding or
 create intent, source hints, caps, planRevision, actionId, allowed side effects,
-postconditions, and the packet's `workerDispatch` policy. Treat
+postconditions, the parent `postEngagerSenderIds`, the parent
+`sharedSenderIds`, and the packet's `workerDispatch` policy. Treat
 `workerDispatch.requiresVisibleThreadOrDurableReceipt:true` as a hard
 execution boundary, not guidance. Read and preserve `workerDispatch.acceptedRuntimes`,
 `workerDispatch.rejectedRuntimes`, and `workerDispatch.receiptArtifactHint`
@@ -234,6 +235,15 @@ parent packet, do not mutate and do not use it as `setupPlanCall` proof; stop
 with `blocked: worker_plan_scope_drift` and ask the parent to re-plan.
 Short form: If a worker-local plan omits `postEngagerSenderIds:[]`, do not use it as `setupPlanCall` proof.
 Short form: stop with `blocked: worker_plan_scope_drift`.
+Every worker prompt must include both parent scope arrays as explicit fields:
+`Parent postEngagerSenderIds:` and `Parent sharedSenderIds:`. Workers must
+preserve parent postEngagerSenderIds even for shared lanes. Never run a
+shared-lane worker-local plan with `postEngagerSenderIds:[]` unless the parent
+`postEngagerSenderIds` is exactly `[]`. Every durable receipt must copy these
+arrays to top-level `parentPostEngagerSenderIds` and `parentSharedSenderIds`
+before completion.
+Short form: Workers must preserve parent postEngagerSenderIds even for shared lanes.
+Short form: Never run a shared-lane worker-local plan with `postEngagerSenderIds:[]` unless the parent `postEngagerSenderIds` is exactly `[]`.
 
 Worker fan-out must use visible or durable execution. Preferred in local Codex
 is a visible Codex thread created with the actual Codex app thread tools:
@@ -266,8 +276,9 @@ stdin, require the worker to write `workerDispatch.receiptArtifactHint`, and
 pass exactly one lane packet per worker.
 After creating receipt directories, dispatch workers immediately; do not perform extended parent reasoning, extra inventory, or prompt rewriting loops.
 Use a compact worker prompt: include lane packet JSON, original selectedActionIds,
-original planRevision, receiptArtifactPath, workspace id, sender ids,
-side-effect caps, and the instruction to load packaged prompts through MCP.
+original planRevision, parent postEngagerSenderIds, parent sharedSenderIds,
+receiptArtifactPath, workspace id, sender ids, side-effect caps, and the
+instruction to load packaged prompts through MCP.
 Do not paste the entire wrapper skill into worker prompts. If the parent cannot
 launch at least one visible/durable worker immediately after directory setup,
 stop with `blocked: worker_dispatch_stalled` before any mutation.
@@ -286,6 +297,8 @@ Use $sellable:create-evergreen-campaigns as the governing skill for this one lan
 Workspace id: <workspaceId>
 Parent planRevision: <planRevision>
 Parent selectedActionIds: <selectedActionIds JSON>
+Parent postEngagerSenderIds: <postEngagerSenderIds JSON>
+Parent sharedSenderIds: <sharedSenderIds JSON>
 Action id: <actionId>
 Lane key: <laneKey>
 Allowed side effects: <allowedSideEffects JSON>
@@ -368,7 +381,14 @@ not a parent-thread summary. The receipt must include:
   `senderIds`, `campaignId`, `tableId`, and `createIntent`. Do not use
   `laneActionId`, `lanePacketActionId`, `delegatedPlanRevision`,
   `delegatedActionId`, or freeform `requestedCall` text as a substitute for
-  these fields.
+  these fields. For create lanes, `setupPlanCall.campaignId` and
+  `setupPlanCall.tableId` must be the actual created campaign/table ids after
+  creation and readback. If the parent lane packet carried null ids before
+  creation, preserve that original packet only in a separate `parentLanePacket`
+  object; do not leave `setupPlanCall.campaignId:null` or
+  `setupPlanCall.tableId:null`.
+  Short form: For create lanes, `setupPlanCall.campaignId` and `setupPlanCall.tableId` must be the actual created campaign/table ids.
+  Short form: Do not leave `setupPlanCall.campaignId:null` or `setupPlanCall.tableId:null`.
 - `createCampaignWorkflowReceipt`: proof the worker loaded the actual installed
   `$sellable:create-campaign` wrapper instead of doing ad hoc MCP calls. It must
   include `skillCommand:"$sellable:create-campaign"`,
@@ -705,9 +725,14 @@ the prospect's engagement unless the selected source evidence proves that exact
 sender authored the post.
 Shared lanes must reject generic product-summary samples that explain the
 product in the same broad words for every row. Shared lanes must reject three
-nearly identical samples after stripping the leading name. If either failure
-appears, revise or rerun the packaged create-campaign/generate-messages path
-from the lane worker before writing a success receipt.
+nearly identical samples after stripping the leading name. Shared lanes must
+fail quality review when any reviewed sample has non-empty `issues`; do not
+approve or final-report samples with `verdict:"passed"` and non-empty `issues`.
+If any of these failures appears, revise or rerun the packaged
+create-campaign/generate-messages path from the lane worker before writing a
+success receipt.
+Short form: Shared lanes must fail quality review when any reviewed sample has non-empty `issues`.
+Short form: Do not approve or final-report samples with `verdict:"passed"` and non-empty `issues`.
 The generated-message cells are not prompt proof: `currentRevisionGeneratedMessages`,
 Generate Message column counts, `messagesCount`, or rendered row previews prove
 only that table cells exist from the current brief/template, not that the
@@ -791,6 +816,9 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      say it. Prefer sender-agnostic company/team language such as "we're
      helping CX teams..." or "at cxconnect.ai, we help..." and one clear
      problem question.
+     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".
    - **Shared Cold Fallback** first-message style: cold, direct, and cohesive.
      It must not pretend there was engagement, must not say "saw you pop up",
      and must not use a standalone name line followed by "Hey there" or other
@@ -807,6 +835,8 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      create-campaign message workflow proves a better delivery format.
      Short form: Shared Cold Fallback must not pass just because the receipt says `generate-messages` loaded.
      Short form: Shared Cold Fallback uses no self-intro such as "We're building".
+     Short form: Shared Cold Fallback uses no self-intro such as "I'm building Sellable".
+     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.
    - Every customer-visible lane must run Message Drafting from the current
@@ -864,13 +894,16 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
       reviewed sample messages. For Shared Cold Fallback, reject samples that
       open with a standalone name followed by "Hey there" or a similarly generic
       greeting. For Shared Cold Fallback, also reject samples with a self-intro
-      such as "We're building", an opt-out shrug such as "If this isn't
-      relevant, ignore me", or a product-stack dump that repeats the same
+      such as "We're building", "I'm building Sellable", or "I've put
+      together", an opt-out shrug such as "If this isn't relevant, ignore me",
+      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, and any preserved Post Engagers opener; revise or
-      rerun the packaged create-campaign/generate-messages path before reporting
-      completion.
+      near-identical samples, 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`.
    - 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.
@@ -944,7 +977,8 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
    **Also confirm the delivery format and keep config in sync.** Ask the user whether DM lanes should send multiline (paragraph-per-message) or as a single message. Record the answer as the brief's `Delivery format:` line, and when multiline is chosen, set `actionConfig.sendEachParagraphAsMessage: true` on that campaign's `send_dm` column via `update_column` (config edits run no cells and nothing sends from unlaunched campaigns). Never set the paragraph-split flag on InMail columns — the option does not apply to InMail.
 6. **Interactive polish mode only: prove the template on one real row.** For ONE campaign that has at least one lead row (add one via `add_on_demand_leads` if every lane is empty and the user provides/approves a test lead), generate a message for exactly one row (`queue_campaign_cells` with `columnRole: "generateMessage"`, `rowSelector: { type: "reviewBatch", limit: 1 }` or the single row's ID), wait for it, then show the user the generated message next to the template — AND show how it would split if paragraph-per-message sending is enabled (list each paragraph as `msg 1:`, `msg 2:`, …) so the user confirms each one reads like a real typed message. Check alignment: tone, structure, no internal vocabulary, correct token substitution, no letter punctuation. Do NOT approve the row or generate for more rows — one sample only.
 7. **Automation mode template/config audit**: inspect existing send-lane briefs for a `Delivery format:` line and chat-native warm template. If a send lane is missing the line and the prompt allows cleanup, update only the campaign brief metadata with the safest default for that lane (`Delivery format: single message (LinkedIn DM; line breaks remain inside one generated message; no follow-up until reply)`). If cleanup is not allowed, flag it. Do not generate a sample row in automation mode unless the invocation explicitly asks for sample proof. In structure-only automation, do not generate a sample row unless the invocation explicitly asks for sample proof. In customer-visible completion, follow the Customer-Visible Completion Contract instead.
-8. **Report the reconcile plan and result** — every slot tagged `reused`, `created`, `repaired`, `flagged`, or `blocked`, plus template/sample details only when that mode ran:
+8. **Final customer-facing completion must include sample messaging**: after customer-visible verify and the idempotency rerun pass, add a `Sample Messaging Review` section to the final answer. For every completed lane, show at least one full generated first message for every completed lane with campaign name, campaign id, row id, and verdict. Extract samples from nested `createCampaignStepReceipt.messageDraftingReceipt.sampleMessages`, not from top-level summaries; extract samples from nested `createCampaignStepReceipt.messageDraftingReceipt.sampleMessages` when building the final answer. Prefer the approved route-proof row when it is quality-valid; otherwise use the best reviewed generated row from the verified receipt. A final `passed` sample must have `issues:[]`; if every reviewed sample has issues, report the lane as needing message revision instead of presenting a passed sample. Do not summarize the sample into a copy theme. Show the actual message text so the user can inspect tone and specificity. If any sample is not quite right, tell the user they can ask the AI to update the campaign brief/message template and rerun Generate Message before launch. Never suggest launching, scheduling, or sending as the next step from this command.
+9. **Report the reconcile plan and result** — every slot tagged `reused`, `created`, `repaired`, `flagged`, or `blocked`, plus template/sample details only when that mode ran:
 
 ```
 Evergreen Reconcile — {date}
@@ -953,6 +987,17 @@ Evergreen Reconcile — {date}
 • Sellable.dev - Shared Signal Discovery: repaired (send review ready; 50 rows, 3 generated, 1 approved gate row, sequence attached, paused)
 • Sellable.dev - Shared Cold Fallback: created (send review ready; 50 rows, 3 generated, 1 approved gate row, sequence attached, paused)
 All campaigns remain unlaunched. Next: enrich/approve more rows when you want more items ready to schedule.
+
+Sample Messaging Review
+• Christian Reyes - Post Engagers (`cmp_...`, row `row_...`, verdict: passed)
+  ```
+  {{full generated first message}}
+  ```
+• Sellable.dev - Shared Cold Fallback (`cmp_...`, row `row_...`, verdict: passed)
+  ```
+  {{full generated first message}}
+  ```
+If any sample is not quite right, ask the AI to update the campaign brief/message template and rerun Generate Message before launch.
 ```
 </objective>