@sellable/install 0.1.242 → 0.1.244

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.242",
+  "version": "0.1.244",
   "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>
@@ -274,6 +290,31 @@ CLI builds that expose `-a`/`-s` only at top level. Do not use
 forms fail on current customer CLI installs. Pipe the lane packet prompt on
 stdin, require the worker to write `workerDispatch.receiptArtifactHint`, and
 pass exactly one lane packet per worker.
+When wrapping multiple local Codex CLI workers in a shell launcher, run the
+wrapper with `/bin/bash -lc` or another explicitly chosen portable shell. Do not
+rely on zsh-specific behavior. Do not use `status` as a shell variable because
+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,
@@ -287,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'
@@ -312,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
@@ -661,6 +708,19 @@ path itself in the worker thread:
    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
+   `blocked: generated_message_cell_override` instead of success.
+   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
    remain or a bounded stop reason is returned.
 5. Use `get_campaign_messages_preview` or `select_campaign_cells` to inspect
@@ -687,6 +747,26 @@ The only accepted statusSource values are exactly `branch` and
 `packaged-generate-messages-worker`; descriptive aliases such as
 `package-readback-local-thread` are rejected.
 
+Before any provider-specific source mutation for a newly created campaign,
+reread `get_campaign_navigation_state({ campaignId })` and use that product
+navigation state as the source-step authority. Do not jump from a shell directly
+into `contact-search`, and do not jump from a shell directly into
+`signal-discovery`. Advance through the product-visible source-selection step
+first, then load the provider prompt and write only the provider/source fields
+accepted for that current step. Never include sender reassignment fields in
+source-step updates, never include custom narration fields in source-step
+updates, and do not use guessed `currentStep` or watched narration payloads to
+force the flow forward. If `update_campaign` rejects the source transition
+twice, reread navigation/campaign state once; if the campaign is not already on
+the intended source step, stop the lane with
+`blocked: watched_source_transition_blocked` and include the rejected tool
+result plus the readback. Do not loop on rejected `update_campaign` transitions.
+Short form: do not jump from a shell directly into `contact-search`.
+Short form: do not jump from a shell directly into `signal-discovery`.
+Short form: never include sender reassignment fields in source-step updates.
+Short form: never include custom narration fields in source-step updates.
+Short form: do not loop on rejected `update_campaign` transitions.
+
 One lane may produce exactly one CampaignOffer/campaign id and one current
 workflow table id. For `intent:"create"`, the first successful
 `create_campaign` result establishes the lane's only allowed campaign/table
@@ -978,6 +1058,7 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
 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. **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.
+   If the `Sample Messaging Review` section is omitted, the command is incomplete even when the structural campaign setup succeeded.
 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:
 
 ```