@sellable/install 0.1.243 → 0.1.245

package/package.json

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

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

@@ -58,6 +58,22 @@ Default evergreen plan per workspace (override only if the prompt specifies diff
 1. **`<Sender Name> - Post Engagers`** — one per sender (warm lane, highest priority)
 2. **`<Workspace/Team> - Shared Signal Discovery`** — one shared warm-signal campaign lane across senders
 3. **`<Workspace/Team> - Shared Cold Fallback`** — one shared cold/fallback campaign lane across senders
+
+Sender scope resolution is safety-critical. Do not pass
+`allConnectedSenders:true` unless the invoking prompt explicitly says "all
+connected senders", "every connected sender", "all seats", or names an
+equivalent all-sender scope. If the user says "all 4 campaigns", "the four
+evergreen campaigns", or names specific senders, resolve those exact senders
+and pass explicit `postEngagerSenderIds` plus `sharedSenderIds`; do not broaden
+the plan to every connected sender. In non-interactive or `--yolo` mode, when
+more than two connected senders exist and the prompt does not explicitly
+authorize all connected senders, stop before mutation with
+`blocked: ambiguous_post_engager_sender_scope` and report the sender ids/names
+needed for approval. Never let "workspace default" silently create Post
+Engagers lanes for extra senders.
+Short form: Do not pass `allConnectedSenders:true` unless the prompt explicitly says all/every connected sender.
+Short form: "all 4 campaigns" means explicit sender scope plus two shared lanes, not all connected senders.
+Short form: In `--yolo`, ambiguous multi-sender scope blocks before mutation.
 </inputs>
 
 <command_backed_workflow>
@@ -281,11 +297,24 @@ zsh treats it as read-only; use `exit_code` or `rc` instead. Receipt polling
 must use `find <receipt-dir> -maxdepth 1 -name 'evg_*.json' -print` or an
 explicit nullglob-safe equivalent. Do not use naked `*.json` globs under zsh,
 and keep zero-receipt polls quiet with no `no matches found` diagnostics.
+Do not embed `<<'WORKER_PROMPT'` heredocs inside a single quoted or double
+quoted `/bin/bash -lc '...'` command string; nested quoting is brittle and can
+truncate the first worker before mutation. For multi-worker launchers, write one
+plain prompt file per lane under the current run directory, then start each
+worker with `codex -a never -s danger-full-access exec -C "$REPO" -o
+"$worker_final_file" - < "$worker_prompt_file"`. Keep launcher shell variables
+double-quoted and keep the prompt heredoc only in a standalone script/prompt-file
+write step, not inside an already quoted shell argument. If the first launcher
+attempt exits with a shell parse error or before starting the first worker,
+stop with `blocked: worker_launcher_quoting_failed` and do not retry by
+loosening sender scope or mutating in the parent.
 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: 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.
+Short form: Multi-worker launchers write prompt files and run `codex ... - < "$worker_prompt_file"`.
 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, parent postEngagerSenderIds, parent sharedSenderIds,
@@ -299,8 +328,11 @@ current lane packet for receipt paths.
 Do not hardcode machine-specific paths, workspace ids, campaign ids, sender ids, or UAT/phase artifact paths in this MCP prompt or any worker prompt.
 After the receipt-directory `mkdir`, the next shell/tool call must launch the first lane worker.
 Do not run `find`, `ls`, extra inventory, or another preflight between directory setup and the first worker launch.
-For the local Codex CLI fallback, use this literal durable CLI worker launch template
-and fill only the lane-specific placeholders:
+For the local Codex CLI fallback, use this literal durable CLI worker launch
+template and fill only the lane-specific placeholders. For one-off direct worker
+launches you may pipe a heredoc directly to `codex`; for multi-worker shell
+launchers, write the same prompt body to `<worker-prompt-file>` and launch the
+worker with stdin redirected from that file:
 
 ```
 codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
@@ -324,6 +356,9 @@ Use mcp__sellable only. Do not use admin tools, direct DB, Prisma, SQL, web sear
 Do not launch, start, schedule, send, or use paid InMail.
 Complete only this lane, write the required durable receipt JSON, and stop.
 WORKER_PROMPT
+
+# Multi-worker launcher equivalent:
+codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> - < <worker-prompt-file>
 ```
 
 If any placeholder cannot be filled from the current lane packet, do not inspect
@@ -455,8 +490,19 @@ not a parent-thread summary. The receipt must include:
   evidence field such as `rowCount`, `rowIdsHash`, or `rowEvidence`; do not
   leave those only in `searchSignalsProof`, `importProof`, `coldFallbackProof`,
   or narrative text for the parent/verifier to infer.
-- `filterDecisionReceipt`: saved/applied filter ids or explicit skip-filter
-  decision with current campaign/table basis.
+- `filterDecisionReceipt`: saved/applied ICP filter proof for the current
+  campaign/table basis. Customer-visible evergreen lanes must enable ICP
+  filtering with `enableICPFilters:true`, call `save_rubrics`, and save at
+  least three rubric/filter criteria before Message Drafting. Do not skip
+  filtering for evergreen setup. Missing or skipped filter proof is
+  `blocked: missing_filter_setup`.
+  Before the worker exits, the durable JSON must contain
+  `filterDecisionReceipt.status:"applied"`,
+  `filterDecisionReceipt.enableICPFilters:true`, the current
+  `workflowTableId`, and concrete saved-filter proof such as
+  `filterDecisionReceipt.filterIds`, `filterDecisionReceipt.rubricIds`,
+  `filterDecisionReceipt.savedRubricCount`, or
+  `filterDecisionReceipt.headlineICPCriteria`.
 - `messageDraftingReceipt`: the Message Drafting proof described below,
   including packaged `generate-messages` prompt/assets and validation. Raw
   fields like `generateMessagesPromptLoadedToHasMoreFalse`,
@@ -592,7 +638,12 @@ verification unless the same object also appears inside
       "sourceLadderReason": "<why the current source is valid before colder sources>"
     },
     "filterDecisionReceipt": {
-      "status": "skipped",
+      "status": "applied",
+      "enableICPFilters": true,
+      "filterIds": ["<saved filter/rubric id>"],
+      "rubricIds": ["<saved rubric id>"],
+      "headlineICPCriteria": ["<saved ICP criterion>", "<saved ICP criterion>", "<saved ICP criterion>"],
+      "savedRubricCount": 3,
       "workflowTableId": "<workflow table id>"
     },
     "messageDraftingReceipt": {
@@ -884,10 +935,34 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      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
-     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
+    - Customer-visible evergreen lanes must enable ICP filtering before Message
+      Drafting. This applies to Post Engagers, Shared Signal Discovery, and
+      Shared Cold Fallback. Do not skip filtering for evergreen setup, even when
+      the source is warm. Use the normal `$sellable:create-campaign` filter
+      workflow: set or save 3-5 headline ICP criteria, call `save_rubrics`, and
+      persist `enableICPFilters:true` on the campaign before generating
+      messages. Good evergreen filters should be light but real: role/budget
+      relevance, company/market fit, and obvious non-buyer exclusion. For
+      Post Engagers, keep filters permissive enough that warm source rows are not
+      over-pruned, but still save the filter rules. For shared lanes, filter for
+      buyers/operators relevant to the workspace offer and exclude students,
+      job seekers, vendors, and off-topic commenters. The receipt must show
+      `filterDecisionReceipt.status:"applied"`,
+      `filterDecisionReceipt.enableICPFilters:true`, current `workflowTableId`,
+      and saved filter/rubric proof with at least three saved rubric/filter
+      criteria (`filterIds`, `rubricIds`, `headlineICPCriteria`, or
+      `savedRubricCount`). Missing or skipped filter proof is
+      `blocked: missing_filter_setup`.
+      Short form: Customer-visible evergreen lanes must enable ICP filtering.
+      Short form: `enableICPFilters:true`.
+      Short form: Do not skip filtering for evergreen setup.
+      Short form: at least three saved rubric/filter criteria.
+      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
@@ -917,10 +992,13 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
    - A source/list decision has been resolved and campaign rows are loaded. If
      there is no approved source or no rows can be copied, report `blocked` with
      the missing source detail; do not call the campaign complete.
-   - The filter step is resolved: either saved/applied filters are present, or
-     the campaign explicitly skipped filters. Do not leave customer-visible
-     campaigns at `filter-choice`, `filter-rules`, or `apply-icp-rubric` and
-     report success.
+    - The filter step is resolved with saved/applied filters. Customer-visible
+      evergreen lanes must have `enableICPFilters:true`, at least three saved
+      ICP filter/rubric criteria, and a receipt with
+      `filterDecisionReceipt.status:"applied"`. Do not skip filters for
+      evergreen setup. Do not leave customer-visible campaigns at
+      `filter-choice`, `filter-rules`, or `apply-icp-rubric` and report success.
+      Do not proceed to Message Drafting until saved filters are applied.
    - Message Drafting has run from the current campaign/table basis, using the
      create-campaign message prompt/assets and validation gate. Updating
      `currentStep:"messages"` is not proof. Parent-thread handwritten copy is