@sellable/mcp 0.1.414 → 0.1.415

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.414",
+  "version": "0.1.415",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign-v2/references/ai-tells.md

@@ -55,6 +55,12 @@ raise your hand for X (creepy to reach out based on that, i know) - but
 this felt too on the nose to ignore"` shapes only when the source was an
 explicit lead-magnet comment, reply, or opt-in.
 
+Shared evergreen exception: for Shared Signal Discovery and other shared
+evergreen lanes, the weak-signal permissioned bridge above is still a tell.
+Reject `hope this is relevant`, `might be interested`, and `saw you in a few
+conversations` as openers; require a concrete signal/problem bridge or omit the
+source line.
+
 **Severity:** REJECT
 
 ## Tell #3 — Explicit date or duration references about the recipient

package/skills/create-campaign-v2/references/gold-standard-message-examples.md

@@ -203,6 +203,32 @@ Why it works:
 **Proof ranks used:** rank 1 (mechanism - 1,000+ conditions from one blood
 draw), rank 3 (risk before claims).
 
+Do not use the Superpower weak-signal hedge pattern for Shared Evergreen Signal Discovery. Shared evergreen lanes are reused across multiple senders and must not open with `hope this is relevant`, `might be interested`, or `saw you in a few conversations`. Use the safe pattern below instead.
+
+### Shared Evergreen Signal Discovery Safe Pattern
+
+Use when the campaign is a shared evergreen signal lane and the source signal is
+real but not sender-owned.
+
+```text
+Hey {{first_name}},
+
+The AI-assisted GTM conversations keep coming back to one problem: turning good LinkedIn signal into review-ready pipeline without another outbound dashboard.
+
+Sellable helps teams find signal-matched prospects, filter for fit, and generate reviewed LinkedIn copy from one workflow.
+
+Curious if LinkedIn outbound is a channel you're trying to make more reliable this quarter?
+```
+
+Why it works:
+
+- no low-confidence relevance hedge
+- no `I'm building` or founder-only first person
+- no internal workflow vocabulary such as Codex, MCP, agent workflows, workflow
+  table, lead source, or signal discovery
+- the signal becomes a buyer problem instead of an activity-log opener
+- safe for multiple senders attached to the same shared lane
+
 ## Conditional Examples
 
 Use these only when the campaign motion matches.
@@ -419,24 +445,25 @@ Tokenized shape:
 Hey there
 
 Thanks for the support on my post about {{post_topic_line}}
-
-Curious, is this something you're dealing with right now?
 ```
 
 Transfer rules:
 
 - Do not hardcode a post topic. Fill `{{post_topic_line}}` from the actual
   selected sender-authored post or use a safer source-specific phrase.
+- Do not add a relevance question, CTA, product line, or extra paragraph after
+  the thank-you line. The reply-rate lesson is the casual warm acknowledgment,
+  not a cold pitch appended to it.
 - Do not use "showing some love"; it reads too casual for executive/VP/director
   contacts.
 - Keep the thank-you line. The point of this motion is acknowledging real
-  sender-owned support before asking a light relevance question. Do not flatten
-  it back to "saw you pop up" unless the sender specifically asks for that
-  wording.
+  sender-owned support without appending a cold relevance question. Do not
+  flatten it back to "saw you pop up" unless the sender specifically asks for
+  that wording.
 - Do not copy this shape into shared lanes, third-party thread sources, or cold
   fallback campaigns.
-- Keep the question closed and problem-oriented; do not pitch, ask for a
-  meeting, or mention internal product vocabulary in message one.
+- Do not pitch, ask for a meeting, or mention internal product vocabulary in
+  message one.
 
 ## Useful CTA Shapes
 

package/skills/create-campaign-v2/references/gold-standard-message-patterns.md

@@ -199,11 +199,21 @@ Shape:
 Prefer:
 
 - lowercase or casual casing when the motion supports it
-- an honest line like "hope this is relevant" or "so may be off, but this seemed relevant"
+- an honest line like "hope this is relevant" or "so may be off, but this seemed relevant" only for non-evergreen weak-signal campaigns
 - a concrete CTA that names the useful conversation or asset
 - binary options only when the brief explicitly supports two real next steps
 - direct wording over polished marketing language
 
+Shared Evergreen Signal Discovery override:
+
+- Do not use `hope this is relevant`, `might be interested`, or `saw you in a
+  few conversations` as the opener.
+- Do not use `I'm building`, `I've mapped`, `my company`, or `my team`.
+- Turn the source topic into a buyer problem bridge, then write the product line
+  in team/company voice.
+- If the source topic cannot support a concrete bridge, omit the source line and
+  start from a role/company/problem observation.
+
 Avoid:
 
 - copying a gimmick like "from a claude code terminal" unless the brief

package/skills/create-campaign-v2/references/sellable-cleanup-rules.md

@@ -74,7 +74,7 @@ Revise or reject the sample when any of these happen.
 - **actions are implied, not stated** — e.g. "runs that chain as AI agents" when a clearer version would name the specific actions (verb + object, one per line)
 - **category-level opener used when a per-lead signal exists** — if `lead-sample.json` carries any per-lead signal (post, hire, visible tool, topic engagement), the opener must reference it. Category-level openers of shape `"Most [category] teams still do X by hand"` are only acceptable when zero per-lead signal is in the sample. When a category-level opener is used as fallback, Findings must flag it explicitly
 - **mind-reading from engagement signals** — a topic engagement, post, public activity, role, company, or hiring trigger does not prove buyer intent. Reject phrases like `"AI-GTM stack is clearly on your mind"`, `"you're clearly focused on..."`, `"obviously relevant"`, or `"already thinking about..."` unless that exact priority is explicitly present in `lead-sample.json`. Translate to low-certainty buyer context or omit the signal from copy.
-- **source-y signal narration** — reject `"saw you on..."`, `"saw you engaging with..."`, `"you commented on..."`, `"your LinkedIn activity..."`, `"you might not remember the thread..."`, `"found you through [source] and your role looked close..."`, or any line that makes the recipient feel watched unless the chosen archived motion is intentionally self-aware about the signal. For sender-owned LinkedIn post sources, a light first-person acknowledgment is allowed when row data proves a reaction/comment: `"appreciate you showing some love on my post about [topic]"` or `"thanks for showing support on my [topic] post"`. Do not name a comment unless comment text is present. Follow the acknowledgment with a soft relevance bridge before broad pain/product copy, e.g. `"figured this might be relevant if LinkedIn is becoming more of a GTM channel for [company]"`. For third-party LinkedIn-post-sourced campaigns, a topic-level bridge is allowed when it explains why the note exists and stays apologetically uncertain: `"saw you in a few conversations about [topic], so may be off, but this seemed relevant."`, `"saw you in a few conversations around [topic], so hope this is relevant."`, or `"found you in a thread about [topic], so may be off, but this seemed relevant."` Reserve `"raise your hand"` language for explicit lead-magnet comments, replies, or opt-ins. Translate the signal into natural buyer context or omit it.
+- **source-y signal narration** — reject `"saw you on..."`, `"saw you engaging with..."`, `"you commented on..."`, `"your LinkedIn activity..."`, `"you might not remember the thread..."`, `"found you through [source] and your role looked close..."`, or any line that makes the recipient feel watched unless the chosen archived motion is intentionally self-aware about the signal. For sender-owned LinkedIn post sources, a light first-person acknowledgment is allowed when row data proves a reaction/comment: `"appreciate you showing some love on my post about [topic]"` or `"thanks for showing support on my [topic] post"`. Do not name a comment unless comment text is present. Follow the acknowledgment with a soft relevance bridge before broad pain/product copy, e.g. `"figured this might be relevant if LinkedIn is becoming more of a GTM channel for [company]"`. For third-party LinkedIn-post-sourced campaigns, a topic-level bridge is allowed when it explains why the note exists and stays apologetically uncertain: `"saw you in a few conversations about [topic], so may be off, but this seemed relevant."`, `"saw you in a few conversations around [topic], so hope this is relevant."`, or `"found you in a thread about [topic], so may be off, but this seemed relevant."` Shared evergreen signal exception: these hedges are blocked for Shared Signal Discovery and other shared evergreen lanes; use a concrete signal/problem bridge or omit the source line. Reserve `"raise your hand"` language for explicit lead-magnet comments, replies, or opt-ins. Translate the signal into natural buyer context or omit it.
 - **sender-owned source rendered as third-party** — hard fail when the source post is sender-owned and the draft says `"found you in a thread"`, `"saw you in a thread"`, `"saw you in conversations"`, or `"saw you in a few conversations"` as if the post were third-party. For sender-owned sources, the copy must either use a light first-person acknowledgment plus a soft relevance bridge, or omit the source line. If multiple senders may send the campaign, or the final sender/source-owner match is ambiguous, do not assume a specific `my post` voice or name a specific sender; omit the sender-owned source line until row-level sender ownership is proven. Neutral low-certainty thread/source language is only for truly third-party sources.
 - **fake line-to-line continuity** — reject line stacks where the source acknowledgment, relevance bridge, product line, and CTA do not actually build on each other. Each line must make the next line feel earned. If two adjacent lines could be swapped, deleted, or joined with `"anyway"` without changing the meaning, the transition is fake. In sender-owned post campaigns, the chain should be: support on my post -> why this topic may matter for the company -> what the product/problem does about that same topic -> low-friction next step.
 - **assumptive title-fit opener** — reject `"Your [role] role at [company] looked close to this problem"` or `"looked close to this outbound campaign problem"`. This asserts fit from title/company. Keep the apologetic uncertainty instead: `"may be off, but if [workflow] is relevant to what you're working on..."`.

package/skills/create-evergreen-campaigns/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: create-evergreen-campaigns
 description: Reconcile a sender team's evergreen campaigns — create-or-reuse the standing campaigns (per-sender post engagers + shared signal/cold lanes) idempotently, and when asked for customer-ready/full setup, complete each customer-visible campaign to paused send review with brief, rows, generated review messages, one approval gate row, and sequence. Never duplicates, never launches.
-visibility: internal
+visibility: public
 ---
 
 # Create Evergreen Campaigns
@@ -14,6 +14,40 @@ producing duplicates. This skill never launches campaigns; customer-visible
 completion stops at paused send review.
 </role>
 
+## Operational Fast Path
+
+In automation or `--yolo` customer-visible setup, use this path before the
+long-form contract below:
+
+1. Resolve the active workspace and explicit sender scopes, then call
+   `setup_evergreen_campaigns({ mode:"plan", yolo:true, postEngagerSenderIds,
+   sharedSenderIds })`. If the user did not name senders but
+   `get_campaign_waterfall` returns an active managed evergreen/prod waterfall
+   for the workspace, derive exact sender scopes from the waterfall `senderRefs`
+   and canonical Post Engagers/shared slots before the first setup plan. Match
+   `senderRefs` to `list_senders` by LinkedIn public identifier, display name,
+   or obvious handle/name alias; record the mapping in the plan notes. Do not
+   call setup with empty sender arrays when product-visible waterfall evidence
+   identifies the evergreen sender scope.
+2. If the plan is not current, lacks lane packets, or has
+   `autoExecutable:false`, return the exact blocker before mutation.
+3. Choose the worker runtime immediately. When running under Codex CLI or on VPS,
+   the local Codex CLI fallback is the default accepted runtime. Use visible
+   Codex app threads only when the callable thread tools are actually available.
+   If shell execution is unavailable and no visible/durable thread surface is
+   callable, return `blocked: missing_visible_or_durable_lane_worker_runtime`
+   before mutation.
+4. Write one compact prompt file per selected lane packet, create the receipt
+   directory, and launch all lane workers in parallel with the literal Codex CLI
+   worker command shape below. The parent does not create campaign shells.
+5. Collect fresh durable receipts, verify with the original planRevision and
+   selectedActionIds, then run the idempotency plan and show sample messages.
+
+Do not keep reasoning, re-reading prompts, or restating this workflow instead of
+dispatching workers. If the first worker cannot be launched after at most one
+short planning pass, return `blocked: worker_dispatch_deadline_exceeded` before
+directory setup or product mutation.
+
 <inputs>
 The invoking prompt names the senders ("create evergreen campaigns for csreyes92 and thomas"). Resolve each via `list_senders`.
 
@@ -58,6 +92,32 @@ 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. If the prompt does not name senders but the
+active workspace has a product-visible managed evergreen/prod waterfall, derive
+the exact scope from that waterfall instead of using all connected senders:
+Post Engagers sender scope is the senderRefs that own person-specific
+Post Engagers slots; shared sender scope is the union of senderRefs on the
+shared Signal Discovery and Shared Cold Fallback waterfall slots. If the
+waterfall has one clear production evergreen program for the workspace, this is
+not ambiguous even when `list_senders` returns additional connected senders.
+In non-interactive or `--yolo` mode, when more than two connected senders exist
+and neither the prompt nor product-visible waterfall evidence identifies exact
+evergreen sender scope, 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: Product-visible managed evergreen/prod waterfall senderRefs are exact sender scope.
+Short form: Do not report `no_senders` while waterfall senderRefs can be mapped to list_senders.
+Short form: In `--yolo`, ambiguous multi-sender scope blocks before mutation.
 </inputs>
 
 <command_backed_workflow>
@@ -71,6 +131,13 @@ error, or does not return a current `planRevision` with lane packets, stop
 immediately with `blocked: setup_evergreen_campaigns_unavailable`. Do not fall
 back to ad hoc create-campaign calls, inventory-only guesses, or direct shell
 creation when the command-backed plan is missing.
+Exception: if an initial unscoped plan returns only `blocked:no_senders`, and
+the parent has already read `list_senders` plus a product-visible managed
+evergreen/prod waterfall with mappable `senderRefs`, immediately re-run the
+plan once with explicit derived `postEngagerSenderIds` and `sharedSenderIds`.
+Do not report `no_senders` to the user until that scoped plan has also failed.
+If senderRef mapping is partial, stop with
+`blocked: ambiguous_post_engager_sender_scope` and include the unmapped refs.
 
 MCP/product-visible proof only: every success claim must be observable through
 the installed Sellable MCP tools and product-visible readbacks a normal user or
@@ -215,7 +282,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 +302,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:
@@ -257,35 +334,128 @@ acceptable only when it writes a fresh durable per-lane receipt artifact as it
 works.
 When visible Codex app thread tools are unavailable but local Codex CLI is
 available, the accepted durable streaming-worker command shape is:
-`codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> -`.
+`codex -a never -s danger-full-access exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
 The approval and sandbox flags must come before the `exec` subcommand for Codex
-CLI builds that expose `-a`/`-s` only at top level. Do not use
+CLI builds that expose `-a`/`-s` only at top level. `--skip-git-repo-check` belongs after `exec` because current customer and VPS Codex CLI builds expose it
+as an `exec` subcommand flag, not a top-level flag. Do not use
 `codex exec --ask-for-approval never ...` or `codex exec -a never ...`; those
 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 launching durable Codex CLI workers from an automation parent, pass an
+explicit supported worker model instead of relying on the Codex CLI default
+model. Use the parent runtime model when known, for example:
+`codex -a never -s danger-full-access exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
+Do not rely on the Codex CLI default model; some customer and VPS installs
+default to unavailable model aliases. If the parent cannot identify a supported
+worker model and a test `codex exec -m <worker-model>` launch is rejected, stop
+with `blocked: worker_model_unavailable` before mutation.
+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 --skip-git-repo-check -m "$WORKER_MODEL" -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.
+Do not use `nohup`, detached background workers, or any launcher that returns
+before the workers finish and before receipts/final files exist. A durable
+worker must run in a foreground command session, visible Codex thread, or a shell
+that stays alive until every worker has finished. If using background jobs inside
+one shell, the same shell must stay alive, wait for every worker PID, poll only
+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.
+Short form: Multi-worker launchers write prompt files and run `codex ... - < "$worker_prompt_file"`.
+Short form: Do not use `nohup`; keep the worker process attached until receipt or blocker.
+After the auto-executable plan returns, take at most one short planning pass to
+choose the visible/durable worker runtime and build the worker launch packet.
+Do not keep reasoning, re-reading prompts, or restating the workflow instead of
+dispatching. If the parent cannot name the callable worker runtime and prepare
+the first worker launch command/tool call immediately after that pass, stop with
+`blocked: worker_dispatch_deadline_exceeded` before directory setup or mutation.
 After creating receipt directories, dispatch workers immediately; do not perform extended parent reasoning, extra inventory, or prompt rewriting loops.
+Before any campaign shell creation, the parent must dispatch every selected lane
+worker from the current plan and record the visible thread id or
+`receiptArtifactPath` for each selected actionId. The parent must not call
+`create_campaign`, `import_leads`, `confirm_lead_list`, sequence tools, message
+preparation tools, or `setup_evergreen_campaigns` with `mode:"apply"` or any
+other mutating setup mode. In this wrapper, `setup_evergreen_campaigns` is
+plan/verify authority only; customer-visible creation belongs inside lane
+workers through `$sellable:create-campaign`. If a campaign/table id appears for
+a create lane before that lane has a recorded worker runtime and fresh receipt
+path/thread id, stop with `blocked: parent_mutated_before_worker_receipt` and
+do not continue setup in the parent.
+Short form: dispatch every selected lane worker before shell creation.
+Short form: do not call `setup_evergreen_campaigns` with `mode:"apply"` from the parent.
 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.
+The worker prompt must include the exact filter status rule:
+`filterDecisionReceipt.status:"applied"` only; never `completed`, `confirmed`,
+`done`, or any other alias.
+The worker prompt must include the generated-message write rule: `update_cell`
+is allowed only for the semantic Approved checkbox, never for generated message
+text/body/sample copy. Bad copy requires `revise_message_template_and_rerun` or
+brief/template revision plus Generate Message rerun; any generated-message cell
+override is `blocked: generated_message_cell_override`.
 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.
+After launching workers, poll only the expected current-run receipt paths from
+`workerDispatch.receiptArtifactHint`. If no worker receipt file appears within a
+bounded wait, for example 10 minutes in automation, stop with
+`blocked: worker_receipt_timeout`, include the worker ids/final-file paths/stderr
+if available, and do not create or repair campaign shells in the parent.
 Use only the repo-local `workerDispatch.receiptArtifactHint` returned by the
 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'
+codex -a never -s danger-full-access exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
 Use $sellable:create-evergreen-campaigns as the governing skill for this one lane worker.
 
 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>
@@ -297,8 +467,13 @@ Worker lane packet JSON:
 Load `$sellable:create-campaign` and nested prompts/assets through Sellable MCP loaders.
 Use mcp__sellable only. Do not use admin tools, direct DB, Prisma, SQL, web search, or browser search.
 Do not launch, start, schedule, send, or use paid InMail.
+For filter proof, durable receipt status must be `filterDecisionReceipt.status:"applied"` only; never `completed`, `confirmed`, `done`, or aliases.
+For generated messages, `update_cell` is allowed only for the semantic Approved checkbox. Never use `update_cell` for generated message text/body/sample copy. Bad copy requires `revise_message_template_and_rerun` or brief/template revision plus Generate Message rerun. Any generated-message cell override is `blocked: generated_message_cell_override`.
 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 --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - < <worker-prompt-file>
 ```
 
 If any placeholder cannot be filled from the current lane packet, do not inspect
@@ -368,7 +543,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"`,
@@ -423,8 +605,26 @@ 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`.
+  The exact status string is contractual: use `status:"applied"` only.
+  Do not write `status:"completed"`, `status:"confirmed"`, `status:"saved"`,
+  `status:"done"`, or any other alias after saving filters; the parent verifier
+  rejects those aliases even when saved rubric proof exists.
+  Short form: Filter receipt status must be exactly `applied`.
+  Short form: Do not write `filterDecisionReceipt.status:"completed"`.
+  Short form: Do not write `filterDecisionReceipt.status:"confirmed"`.
 - `messageDraftingReceipt`: the Message Drafting proof described below,
   including packaged `generate-messages` prompt/assets and validation. Raw
   fields like `generateMessagesPromptLoadedToHasMoreFalse`,
@@ -460,7 +660,10 @@ not a parent-thread summary. The receipt must include:
 Before writing the durable receipt, run a receipt self-check. The top-level
 receipt must include top-level `planRevision`, `actionId`, `laneKey`,
 `laneType`, `workspaceId`, and `senderIds`, plus campaign/table/source ids and
-row/message/approval counts. Inside
+row/message/approval counts. It must also include top-level `receiptArtifactPath`,
+top-level `durableReceiptWritten:true`, top-level `receiptRunId`, and top-level
+`receiptWrittenAt`; do not leave `receiptArtifactPath` only under
+`createCampaignWorkflowReceipt` for the parent to patch during verify. Inside
 `createCampaignStepReceipt.messageDraftingReceipt`, `sampleMessages[]` must
 include `rowId`, `generatedMessageText`, `verdict`, and `issues`. Do not
 substitute `message` for `generatedMessageText`. Do not substitute
@@ -472,6 +675,8 @@ before writing JSON; do not leave only raw objects like
 `get_campaign_message_preparation_status`, `attachRecommendedSequenceResult`,
 `finalCampaignRead`, or `finalTableRead`.
 Self-check shorthand: top-level `planRevision`, `actionId`, `laneKey`, `laneType`, `workspaceId`, and `senderIds` must exist before worker completion.
+Self-check shorthand: top-level `receiptArtifactPath`, `durableReceiptWritten:true`, `receiptRunId`, and `receiptWrittenAt` must exist before worker completion.
+Self-check shorthand: top-level `receiptWrittenAt` must exist before worker completion.
 Self-check shorthand: `campaignBriefReceipt.briefHash`,
 `campaignBriefReceipt.deliveryFormat`, `campaignBriefReceipt.tokenRules`,
 `campaignBriefReceipt.hardAvoids`, and `campaignBriefReceipt.sourceUseRules`
@@ -560,7 +765,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": {
@@ -641,6 +851,25 @@ 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.
+   Do not repair by overwriting bad generated message cells and then calling the
+   overwritten cells `sampleMessages`.
+   `messageDraftingReceipt.qualityReview.repairNote`,
+   `messageDraftingReceipt.toolsUsed`, or any proof mentioning generated
+   message cell repair through `update_cell` is self-incriminating and must be
+   `blocked: generated_message_cell_override`.
+   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
@@ -667,6 +896,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
@@ -705,9 +954,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
@@ -727,10 +981,85 @@ duplicate-lane blockers before you call the command finished. If verify blocks,
 report the blocker and repair only the missing postconditions from the same
 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`, `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.
+
+Parent repair dispatch uses the same compact discipline. If the parent sample
+quality gate fails after a worker receipt, do not launch a repair worker by
+embedding the full existing receipt JSON, raw row arrays, raw provider output,
+or the full wrapper skill in the repair prompt. Build a compact repair packet
+with only: workspace id, original planRevision, selectedActionIds, lane
+actionId, laneKey, campaignId, tableId, parent sender scope arrays, receipt
+artifact path, allowed repair side effects, failed sample snippets, failed
+quality codes, and the banned phrase list. The repair prompt must say
+`Do not include existing receipt JSON; load current product state through
+Sellable MCP readbacks and rewrite the durable receipt from fresh readbacks`.
+After the repair worker completes the final product readbacks
+(`get_campaign_messages_preview`, `get_campaign`, navigation/table readback),
+it must rewrite the durable receipt immediately before any extended narration,
+analysis, or final answer. If the repair worker cannot rewrite the durable
+receipt in one bounded pass, it must exit with
+`blocked: repair_receipt_write_timeout`. The parent must treat an unchanged
+receipt mtime, missing repair final file, or missing updated
+`messageDraftingReceipt.sampleMessages` after repair as blocked, never success.
+Short form: repair prompts use compact repair packets, not full receipt JSON.
+Short form: Do not include existing receipt JSON in repair prompts.
+Short form: repair workers write the durable receipt immediately after final readbacks.
+Short form: missing repair receipt rewrite is `blocked: repair_receipt_write_timeout`.
+
 Message proof for every customer-visible lane must come from the current
 campaign/table basis and include at least 3 generated review rows from the
 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 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>
@@ -765,19 +1094,26 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      Short form: Do not pass the warm template into Shared Signal Discovery or Shared Cold Fallback.
      Short form: Shared lanes must reject generic product-summary samples.
      Short form: Shared lanes must reject three nearly identical samples.
+     Short form: Shared lanes must reject low-confidence relevance hedges.
+     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}}
 
      Hey there
 
-     Thanks for the support on my post about {{post_topic_line}}
+     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
@@ -791,6 +1127,28 @@ 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.
+     Before Message Drafting runs, the campaign brief must already include
+     these shared-lane hard avoids and source-use rules. Do not rely on a
+     failed first generation batch to discover that self-intros, generic
+     product summaries, or repeated structure are bad. If the first generated
+     batch violates these rules, rerun, but record that as a repaired UAT path
+     rather than the desired zero-shot path.
+     Do not use low-confidence relevance hedges such as "hope this is
+     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",
+     "Claude Code", or "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",
+     "reviewed pipeline", "leads, filters, messages", "review-ready LinkedIn
+     sequence", "plain-language campaign idea into leads/filters/messages",
+     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".
+     Short form: no low-confidence relevance hedge such as "hope this is relevant".
+     Short form: no internal workflow vocabulary such as "Codex-style workflow", "MCP", "agent workflows", "Claude Code", or "Claude-style agent workflows".
    - **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
@@ -805,14 +1163,57 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
      Sellable/Codex/Claude-Code feature summary
      across prospects. This is a single-message cold path unless the approved
      create-campaign message workflow proves a better delivery format.
+     Do not open with "hope this is relevant" or a similar low-confidence
+     relevance hedge. Do not use a repeated product-definition paragraph such
+     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
+     batch use "I'm building", "We're building", "I've put together", or
+     similar language and then rely on a cleanup rerun as the normal path.
      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
-     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
+     Short form: no low-confidence relevance hedge such as "hope this is relevant".
+     Short form: no repeated product-definition paragraph such as "Sellable is a GTM system".
+    - 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
@@ -842,10 +1243,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
@@ -864,13 +1268,17 @@ 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, low-confidence relevance hedges such as "hope this
+      is relevant", internal workflow vocabulary, 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 +1352,9 @@ 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. Never approve or final-report sample text produced by manual `update_cell` body edits. 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:
 
 ```
 Evergreen Reconcile — {date}
@@ -953,6 +1363,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>
 

package/skills/generate-messages/SKILL.md

@@ -228,12 +228,16 @@ must choose a signal-led, event-led, job-post-led, or proof-led motion from the
 current brief and row evidence instead of inheriting a preset first-message
 template.
 Post-engager first messages should thank the prospect for the support on the
-sender-owned post before asking the light relevance question. Prefer the gold
-shape `Thanks for the support on my post about {{post_topic_line}}` over
+sender-owned post and then stop. Do not add a relevance question, CTA, product
+line, meeting ask, or extra paragraph after the thank-you opener unless the
+operator explicitly asks for a longer first message. Prefer the gold shape
+`Thanks for the support on my post about {{post_topic_line}}` over
 surveillance-flavored wording like `saw you pop up`, unless the sender explicitly
 asks for that older wording.
 Short form: use the CXConnect Post-Engager Warm Reply-Rate Pattern only when the source is sender-owned Post Engagers.
 Short form: Never use that warm post-engager pattern for Shared Signal Discovery or Shared Cold Fallback.
+Short form: Post-engager warm first messages stop after the thank-you line.
+Short form: Do not add `curious`, `open to`, `trying to`, product copy, or a CTA after the post-engager thank-you line.
 
 ### Shared Cold Fallback quality bar
 
@@ -245,6 +249,12 @@ must read like final create-campaign/generate-messages output.
 - Ask one clear buyer problem question.
 - Keep the product line minimal and buyer-readable; do not turn the note into a
   product-stack dump.
+- Do not describe Sellable as a process checklist such as "campaign idea into
+  prospects, filters, messages, and sequence setup"; that reads like internal
+  product plumbing, not a buyer reason to reply.
+- Do not use awkward product-process nouns in reviewed cold samples:
+  `sequence-prospects`, `dashboard overhead`, `campaign map`, `send-ready copy`,
+  `reviewed prospect lists`, or "one campaign would look like" as a default CTA.
 - Use no self-intro such as "We're building" or "We're working on a way" in the
   reviewed samples.
 - Use no opt-out shrug such as "If this isn't relevant, ignore me."
@@ -252,6 +262,39 @@ must read like final create-campaign/generate-messages output.
   samples. If two samples would still read the same after replacing names and
   companies, revise or rerun.
 
+### Shared Evergreen Signal Discovery hard gate
+
+For Shared Signal Discovery and other shared evergreen lanes, signal-led copy
+must be safer than the legacy weak-signal examples. These lanes are reused by
+multiple senders, so the first line cannot sound like a scraped-activity excuse
+or a founder self-intro.
+
+- `hope this is relevant`, `might be interested`, and `saw you in a few conversations` are blocked openers for shared evergreen lanes.
+- do not write first-person singular founder language such as `I'm building`,
+  `I've mapped`, `my company`, or `my team` unless exactly one sender can
+  credibly say it and the lane is not shared.
+- Do not put internal workflow vocabulary in buyer-facing copy: `Codex`, `MCP`,
+  `Claude-style agent workflows`, `agent workflows`, `workflow table`, `lead
+  source`, or `signal discovery`.
+- Do not use `Claude`, `Codex`, `MCP`, `agent`, `dashboard`, `workflow`,
+  `source`, `sequence`, `send-ready copy`, or `reviewed prospect list` as
+  buyer-facing explanation in shared evergreen samples unless the buyer's own
+  company/product category uses that exact word and the line still sounds human.
+- Write a concrete signal/problem bridge instead of a relevance hedge. Good
+  shapes are `the AI-assisted GTM conversations keep coming back to [buyer
+  problem]`, `teams trying to turn LinkedIn signal into pipeline usually hit
+  [problem]`, or `when [observable business moment] is live, [buyer workflow]
+  gets harder to run consistently`.
+- If the row evidence is too weak to write a concrete bridge, omit the source
+  line and start from a buyer problem, event, role, or company observation.
+- Shared evergreen lanes must pass this gate before `confirmed`, before saving a
+  reusable template, and before any route-proof approval.
+
+Short form: shared evergreen copy cannot use `hope this is relevant`.
+Short form: shared evergreen copy cannot use `might be interested`.
+Short form: shared evergreen copy cannot use `I'm building`.
+Short form: write a concrete signal/problem bridge instead of a relevance hedge.
+
 ### Rich Personalization Contract
 
 The `create-campaign` asset `references/ai-native-tokens.md` is the canonical
@@ -269,12 +312,15 @@ conditional good/bad fill reference.
 - Use this shape for any hook, bridge, or row-specific relevance line:
   `[PERSONALIZATION_LINE — Intent: write one short sentence that anchors the
 note to why this might matter now. DO: connect one observable role/company/
-activity signal to the buyer problem or offer with low-certainty language like
-"hope this is relevant if...", "saw you might be interested in...", "saw you in
-a few conversations around...", or "figured this might matter if...". DON'T: recap
-their resume, list companies, compliment their background, name a product their
-company sells, use source-citation phrasing, or use generic nouns like "your
-work".
+activity signal to the buyer problem or offer with a permissioned bridge. For
+shared evergreen lanes, do not use `hope this is relevant`, `might be
+interested`, or `saw you in a few conversations`; use a concrete
+signal/problem bridge instead. For non-evergreen weak-signal campaigns only,
+legacy low-certainty language like "hope this is relevant if..." or "so may be
+off, but this seemed relevant" can be considered when the source is otherwise
+awkward. DON'T: recap their resume, list companies, compliment their
+background, name a product their company sells, use source-citation phrasing, or
+use generic nouns like "your work".
 FALLBACK: if unsupported, omit the entire line.]`
 - The rendered personalization line should usually be 6-14 words. If it needs
   two clauses, multiple companies, or abstract tags like `GTM`, `international
@@ -433,9 +479,9 @@ artifact.**
 
    Safer shapes:
 
-   - `hope this is relevant if {{signal_topic}} is part of the plan`
-   - `saw you might be interested in {{signal_topic}}, so hope this is relevant`
-   - `saw you in a few conversations around {{signal_topic}}, so hope this is relevant`
+   - `hope this is relevant if {{signal_topic}} is part of the plan` for non-evergreen weak-signal campaigns only
+   - `saw you might be interested in {{signal_topic}}, so hope this is relevant` for non-evergreen weak-signal campaigns only
+   - `saw you in a few conversations around {{signal_topic}}, so hope this is relevant` for non-evergreen weak-signal campaigns only
    - `saw you in a few conversations about {{signal_topic}}, so may be off, but this seemed relevant`
    - `appreciate you showing some love on my post about {{signal_topic}}` only when the sender/client authored the source post and the row proves a reaction or comment
    - `thanks for showing support on my {{signal_topic}} post` only when the sender/client authored the source post and the row proves a reaction or comment
@@ -499,20 +545,22 @@ artifact.**
    magnet replies, or scraped conversations), it is acceptable to reference the
    conversation when it explains why the note exists. Keep it topic-level, not
    activity-log-level: `saw you in a few conversations around
-   {{signal_topic}}, so hope this is relevant` is acceptable; `saw you
-   commented on {{post_context}}` and `your LinkedIn activity around...` are
-   not. Reserve `raise your hand` phrasing for explicit lead-magnet comments,
-   replies, or opt-ins. For ordinary thread discovery, use `saw you in a few
-   conversations around {{signal_topic}}...` or `found you in a thread about
-   {{signal_topic}}...`.
+   {{signal_topic}}, so hope this is relevant` is acceptable only for
+   non-evergreen weak-signal campaigns; it is blocked for Shared Evergreen
+   Signal Discovery. `saw you commented on {{post_context}}` and `your LinkedIn
+   activity around...` are not acceptable. Reserve `raise your hand` phrasing
+   for explicit lead-magnet comments, replies, or opt-ins. For ordinary shared
+   evergreen thread discovery, either translate the topic into a concrete
+   buyer/problem bridge or omit the source line.
 
    Keep the apologetic nature, but aim it at uncertainty, not surveillance.
-   Good: `saw you in a few conversations about outbound, so may be off, but
-   this seemed relevant`, `may be off, but if outbound is relevant to what
-   you're working on...`, `if this is not relevant to your outbound workflow,
-   ignore me`, `hope
-   this is relevant if...`. Bad: `your role at {{company}} looked close...`,
-   because it asserts fit from a title and tells the buyer about themselves.
+   Good for non-evergreen weak-signal campaigns: `saw you in a few
+   conversations about outbound, so may be off, but this seemed relevant`, `may
+   be off, but if outbound is relevant to what you're working on...`, or `hope
+   this is relevant if...`. For shared evergreen lanes, these hedges are not
+   enough; use a concrete signal/problem bridge or omit the source line. Bad:
+   `your role at {{company}} looked close...`, because it asserts fit from a
+   title and tells the buyer about themselves.
 
    Block wordier source narration such as `you might not remember the thread,
    but I found you through a {{signal_topic}} discussion and your
@@ -1509,7 +1557,10 @@ Before `confirmed`, run the selected winner against these gates:
   the lead sample. If desire is inferred, use tentative framing like
   `hope this is relevant if...`, `saw you might be interested in...`,
   `saw you in a few conversations around...`, `figured this might matter if...`,
-  or `if you've ever wanted...`.
+  or `if you've ever wanted...`. Exception: for Shared Signal Discovery and
+  other shared evergreen lanes, `hope this is relevant`, `might be interested`,
+  and `saw you in a few conversations` are blocked; use a concrete
+  signal/problem bridge or omit the source line.
 - **Buyer-first opener:** after the greeting, the first substantive line
   should usually enter the buyer's world: a real signal, current-state
   pain, buyer-owned priority, or useful artifact. Sender-origin can come
@@ -1810,8 +1861,11 @@ about`, or `clearly relevant` are BLOCKED. Source-y phrases such as
   `saw you might be interested in [topic], so hope this is relevant`, `saw you
   in a few conversations around [topic], so hope this is relevant`, `found you
   in a few conversations about [topic], so may be off, but this seemed
-  relevant`, `figured this might matter if [workflow] is live at [company]`, or a similarly natural
-  line. Longer source-recap forms such as `you might not remember the thread,
+  relevant`, `figured this might matter if [workflow] is live at [company]`, or
+  a similarly natural line. For shared evergreen lanes, skip the `hope this is
+  relevant` / `might be interested` / `saw you in a few conversations` versions
+  and use the concrete bridge version. Longer source-recap forms such as `you
+  might not remember the thread,
   but I found you through a [topic] discussion...` are BLOCKED; they narrate
   the scrape path instead of creating buyer relevance.
 - **Engagement reference is opt-in, not the default opener:** do not
@@ -1956,9 +2010,9 @@ matters to the buyer, why this might be relevant, or the operator-reality that
 led to it. Acceptable openers:
 
 - `Hey {{first_name}}, [one plain sentence about what we built].`
-- `Hey {{first_name}}, hope this is relevant if [buyer context] is still on your plate.`
-- `Hey {{first_name}}, saw you might be interested in [topic], so hope this is relevant.`
-- `Hey {{first_name}}, saw you in a few conversations around [topic], so hope this is relevant.`
+- `Hey {{first_name}}, hope this is relevant if [buyer context] is still on your plate.` Not for shared evergreen lanes.
+- `Hey {{first_name}}, saw you might be interested in [topic], so hope this is relevant.` Not for shared evergreen lanes.
+- `Hey {{first_name}}, saw you in a few conversations around [topic], so hope this is relevant.` Not for shared evergreen lanes.
 - `Hey {{first_name}}, found you in a thread about [topic], so may be off, but this seemed relevant.`
 - `Hey {{first_name}}, saw you raise your hand for [topic], so figured this was (hopefully) worth sending.` Only use this for explicit lead-magnet comments, replies, or opt-ins.
 - `Hey {{first_name}}, saw you raise your hand for [topic] (creepy to reach out based on that, i know) - but this felt too on the nose to ignore.` Only use this for explicit lead-magnet comments, replies, or opt-ins.
@@ -2219,9 +2273,9 @@ Rules:
 - if `lead-sample.json` carries **any** per-lead signal for this lead — a recent post, a recent hire, a visible tool in the headline, a topic engagement, a public initiative — the **message must reference it specifically**. Category-level copy is rejected.
 - default placement is **Block 3**, not Block 1. Keep Block 1 substance-first unless the archived motion clearly earns a signal-led opener without falling into source-citation / talk-at phrasing.
 - acceptable signal use by default:
-  - `"Hope this is relevant if [topic] is part of the plan."`
-  - `"Saw you might be interested in [topic], so hope this is relevant."`
-  - `"Saw you in a few conversations around [topic], so hope this is relevant."`
+  - `"Hope this is relevant if [topic] is part of the plan."` Non-evergreen weak-signal only; blocked for shared evergreen lanes.
+  - `"Saw you might be interested in [topic], so hope this is relevant."` Non-evergreen weak-signal only; blocked for shared evergreen lanes.
+  - `"Saw you in a few conversations around [topic], so hope this is relevant."` Non-evergreen weak-signal only; blocked for shared evergreen lanes.
   - `"Saw you in a few conversations about [topic], so may be off, but this seemed relevant."`
   - `"Found you in a thread about [topic], so may be off, but this seemed relevant."`
   - `"Thought of {{company}} because [observable signal] points at [problem]."`
@@ -2239,6 +2293,11 @@ Rules:
   - `"Saw you raise your hand for [topic], so figured this was worth sending."`
   - `"Figured this was worth sending."`
 - signal-led opener shape is a **special case**, not the default. Use it only when the archived motion truly depends on it and the line can stay natural. For LinkedIn-post-sourced campaigns, prefer `"saw you in a few conversations around [topic], so hope this is relevant"` or `"found you in a thread about [topic], so may be off, but this seemed relevant"` when referencing the source makes the outreach feel less random. Avoid activity-log phrasing such as `"you commented on..."`, `"you reacted to..."`, or `"your LinkedIn activity..."` unless the approved motion is the deliberately self-aware raise-hand line for an explicit lead-magnet comment, reply, or opt-in.
+- For Shared Evergreen Signal Discovery, do not use the weak signal-led opener
+  shapes above. Translate the source into a concrete problem bridge, e.g.
+  `"The AI-assisted GTM conversations keep coming back to one problem: turning
+  good LinkedIn signal into review-ready pipeline without another dashboard."`
+  Then connect the product in buyer language.
 - tokenized engagement-source opener shape is BLOCKED by default:
   `{{first_name}}, saw you {{engagement_context}} on {{post_context}}` reads
   like surveillance unless the filled line is explicitly self-aware and
@@ -2247,7 +2306,9 @@ Rules:
 this is relevant`, `saw you in a few conversations around [topic], so hope this
 is relevant`, `saw you in a few conversations about [topic], so may be off,
 but this seemed relevant`, or `found you in a thread about [topic], so may be
-off, but this seemed relevant`. Use the self-aware raise-hand shapes only when
+off, but this seemed relevant`. For shared evergreen lanes, those weak signal
+bridges are blocked; use a concrete signal/problem bridge instead. Use the
+self-aware raise-hand shapes only when
 the source was an explicit lead-magnet comment, reply, or opt-in: `saw you raise
 your hand for [topic], so figured this was (hopefully) worth sending` or `saw you
 raise your hand for [topic] (creepy to reach out based on that, i know) - but