@sellable/install 0.1.244 → 0.1.246

package/package.json

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

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

@@ -490,8 +490,25 @@ 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:"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:"confirmed"`.
 - `messageDraftingReceipt`: the Message Drafting proof described below,
   including packaged `generate-messages` prompt/assets and validation. Raw
   fields like `generateMessagesPromptLoadedToHasMoreFalse`,
@@ -627,7 +644,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": {
@@ -832,6 +854,22 @@ 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`, 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.
+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: Never change planRevision/actionId/laneKey while compacting receipts.
+
 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.
@@ -880,7 +918,7 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
 
      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}}
      ```
 
    - **Shared Signal Discovery** first-message style: short, casual, references
@@ -896,6 +934,12 @@ 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.
      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".
@@ -913,16 +957,45 @@ 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.
+     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
+    - 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
@@ -952,10 +1025,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