@sellable/install 0.1.253 → 0.1.255

package/package.json

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

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

@@ -353,9 +353,20 @@ the expected receipt paths, and record a per-worker exit code plus final-file
 paths and stderr/log paths before returning. If workers exit with empty logs and
 no final files because the subprocess detached or was reaped, stop with
 `blocked: worker_subprocess_detached_without_output` before parent verify.
+When launching multiple local Codex CLI workers from one shell, start each
+background job in the same shell that will call `wait`. Do not capture worker
+PIDs through command substitution, a subshell, a pipeline, or a helper function
+invoked as `worker_pid=$(launch_worker ...)`; those patterns make the captured
+PID non-waitable by the parent shell. Use the same-shell PID array pattern:
+`pids=(); codex ... > "$log_file" 2>&1 & pids+=("$!")`, then
+`for pid in "${pids[@]}"; do wait "$pid" || rc=1; done`. If `wait` reports
+`pid is not a child of this shell`, stop with
+`blocked: worker_subprocess_detached_without_output`.
 Short form: run the wrapper with `/bin/bash -lc`.
 Short form: Do not rely on zsh-specific behavior.
 Short form: Do not use `status` as a shell variable; use `exit_code` or `rc`.
+Short form: Do not capture worker PIDs through command substitution or a subshell.
+Short form: Use same-shell `pids+=("$!")` before waiting on every PID.
 Short form: Receipt polling uses `find <receipt-dir> -maxdepth 1 -name 'evg_*.json' -print`.
 Short form: Do not use naked `*.json` globs under zsh; no `no matches found` diagnostics.
 Short form: Do not embed `<<'WORKER_PROMPT'` heredocs inside a quoted `/bin/bash -lc` command string.
@@ -932,17 +943,34 @@ current plan.
 Before calling verify, the parent should build compact receipt objects from the
 durable receipt files and pass those compact objects to MCP. The compact receipt
 must preserve every verifier-owned field named above, including top-level ids,
-`createCampaignStepReceipt`, canonical filter/message/review/sequence/final
-proof, and at least three concrete sample messages. It should omit large raw
+`createCampaignStepReceipt`, `researchSenderReceipt`, canonical
+filter/message/review/sequence/final proof, and at least three concrete sample
+messages. It should omit large raw
 search outputs, long post lists, full row arrays, raw provider responses, and
 debug-only narration fields. Do not pass multi-hundred-kilobyte raw receipt
 objects when a compact canonical receipt has the same proof; large raw verify
 payloads can stall local MCP bridges and make UAT ambiguous.
+Use a small Node JSON compactor for non-trivial compaction. Do not build complex
+inline `jq` filters inside nested quoted shell strings; quote failures are a
+UAT blocker and waste the verification run. The Node compactor must preserve
+every canonical verifier object under `createCampaignStepReceipt`, including
+`setupPlanCall`, `createCampaignWorkflowReceipt`, `researchSenderReceipt`,
+`campaignBriefReceipt`, `sourceDecisionReceipt`, `filterDecisionReceipt`,
+`messageDraftingReceipt`, `reviewBatchReceipt`, `sequenceReceipt`,
+`finalPausedSendProof`, and `verifyCall`.
+When compacting, normalize `finalPausedSendProof.currentStep` and
+`finalPausedSendProof.campaignStatus` from nested pause/navigation readbacks if
+the worker receipt stored those values under `pauseCampaignResult`,
+`navigationReadback`, or `navigationProof`; do not pass an empty
+`finalPausedSendProof` object to verify.
 Do not print or `jq .` full receipt JSON into the terminal. For local checks,
 print only compact summaries such as file, actionId, laneKey, campaignId,
 filter status, sample count, approved count, and final status.
 Short form: Parent verify uses compact canonical receipt objects, not raw giant receipts.
 Short form: Do not dump full receipt JSON with `jq .`.
+Short form: Do not use complex inline `jq` for receipt compaction; use Node.
+Short form: Compact receipts must preserve `researchSenderReceipt`.
+Short form: Compact receipts must preserve direct `finalPausedSendProof.currentStep` and `campaignStatus`.
 Short form: Never change planRevision/actionId/laneKey while compacting receipts.
 
 Message proof for every customer-visible lane must come from the current
@@ -951,15 +979,23 @@ packaged `generate-messages` path before completion is reported.
 Parent-thread handwritten copy or setting `currentStep` is not proof.
 
 The parent must run its own sample-quality gate before final reporting, even
-when worker receipts say `verdict:"passed"`. For each shared lane, normalize the
-reviewed sample messages by removing leading greeting/name lines, first names,
-and whitespace-only differences; reject shared-lane samples when the message body is identical after removing first names or when all samples share the same
-paragraph skeleton. Also reject final shared-lane samples with `Hey <name>,`
-letter punctuation, weak relevance hedges, internal workflow vocabulary,
-self-intros, or any non-empty `issues`. If the parent finds repeated shared-lane
-sample copy, report `blocked: repeated_shared_lane_sample_copy`, revise the
-campaign brief/template through the packaged workflow, rerun Generate Message,
-and verify current-revision sample messages before final completion.
+when worker receipts say `verdict:"passed"`. For Post Engagers lanes, reject
+any sample that adds a relevance question, CTA, product line, or extra paragraph
+after `Thank you for the support on my post about ...`; blocked phrases include
+`curious`, `open to`, `trying to`, `worth seeing`, `want to see`, and any
+Sellable/product explanation. For each shared lane, normalize the reviewed
+sample messages by removing leading greeting/name lines, first names, and
+whitespace-only differences; reject shared-lane samples when the message body is
+identical after removing first names or when all samples share the same paragraph
+skeleton. Also reject final shared-lane samples with `Hey <name>,` letter
+punctuation, weak relevance hedges, internal workflow vocabulary, self-intros,
+or any non-empty `issues`. Shared lanes must also reject mechanical
+product-process wording such as `sequence-prospects`, `dashboard overhead`,
+`campaign map`, `campaign idea into prospects`, `prospects, filters, messages`,
+`send-ready copy`, or `reviewed prospect lists`. If the parent finds repeated
+shared-lane sample copy, report `blocked: repeated_shared_lane_sample_copy`,
+revise the campaign brief/template through the packaged workflow, rerun Generate
+Message, and verify current-revision sample messages before final completion.
 </command_backed_workflow>
 
 <objective>
@@ -998,8 +1034,9 @@ and verify current-revision sample messages before final completion.
      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
-     sender-authored post they engaged with, closed question, **no internal
-     vocabulary, no pitch, no meeting ask** in message one:
+     sender-authored post they engaged with, and stops after the thank-you
+     line. Use **no internal vocabulary, no pitch, no meeting ask, no product
+     line, and no relevance question** in message one:
 
      ```
      {{first_name}}
@@ -1009,6 +1046,10 @@ and verify current-revision sample messages before final completion.
      Thank you for the support on my post about {{post_topic_line}}
      ```
 
+     Do not add any paragraph after the thank-you line. In particular, do not
+     append `curious, are you trying...`, `open to...`, `worth seeing...`, or
+     Sellable/product copy to a Post Engagers first message.
+
    - **Shared Signal Discovery** first-message style: short, casual, references
      the real observed signal/theme or public conversation. It may mention the
      engagement source only when the source evidence supports it. Do not say
@@ -1032,7 +1073,10 @@ and verify current-revision sample messages before final completion.
      relevant" in Shared Signal Discovery samples. Translate source/tool terms
      into prospect-facing business language; do not put internal workflow
      vocabulary such as "Codex-style workflow", "MCP", "agent workflows", or
-     "Claude-style agent workflows" in customer-facing message one.
+     "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", and "sequence" unless the
+     recipient's own product/category makes that exact word buyer-native.
      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".
@@ -1057,6 +1101,11 @@ and verify current-revision sample messages before final completion.
      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 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
+     prospect lists" in final cold samples. Say the buyer problem and one plain
+     outcome instead.
      Before Message Drafting runs, the campaign brief must already forbid
      self-intros, generic product summaries, opt-out shrugs, product-stack
      dumps, and repeated template structure. Do not let the first generation