@sellable/install 0.1.277 → 0.1.279

package/package.json

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

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

@@ -1232,7 +1232,7 @@ Message, and verify current-revision sample messages before final completion.
      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 except "hope this is relevant".
+     Short form: Shared lanes must reject intent-assumptive hedges such as "might be interested"; Shared Signal Discovery may use topic-level bridges like "saw you in a few conversations about [topic], so hope this is relevant" or "hope this is relevant if [topic] is part of the plan" when the source evidence supports the topic and the line does not claim engagement or expose source mechanics.
      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
@@ -1252,9 +1252,11 @@ Message, and verify current-revision sample messages before final completion.
      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
+   - **Shared Signal Discovery** first-message style: short, casual, starts
+     from the real public business theme or buyer problem supported by the row.
+     Treat Signal Discovery as a lead-source provider only. Do not mention the
+     engagement source, source mechanics, or discovery method in customer-facing
+     copy. Do not say
      "my post" unless the selected source post was actually authored by the
      sending sender. Do not thank the prospect for showing support, reacting,
      commenting, or popping up unless this is a sender-owned Post Engagers lane
@@ -1271,11 +1273,20 @@ Message, and verify current-revision sample messages before final completion.
      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 "might be interested"
-     or "saw you in a few conversations" in Shared Signal Discovery samples.
-     "Hope this is relevant" is allowed when it stays topic-level and does not
-     pretend engagement. Translate source/tool terms into prospect-facing
-     business language; do not put internal workflow
+     Use the Dotwork gold-standard shape for Shared Signal Discovery samples
+     when the row supports a topic-level weak signal: "saw you might be
+     interested in [topic], so hope this is relevant", "saw you in a few
+     conversations about [topic], so hope this is relevant", or "saw you in a
+     few conversations around [topic], so hope this is relevant". These bridges
+     are allowed only when source evidence supports the topic and the line does
+     not claim a reaction, comment, sender-authored post, or other engagement
+     that is not proven. Do not use "found you in a thread" or other raw
+     source/discovery mechanics.
+     Shared Signal Discovery InMail subjects should follow the Dotwork plus-sign
+     A + B + C pattern: concrete topic + buyer outcome + useful artifact/picture,
+     for example "initiatives + business outcomes + one live picture".
+     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",
@@ -1287,7 +1298,7 @@ Message, and verify current-revision sample messages before final completion.
      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 "might be interested" or "saw you in a few conversations"; "hope this is relevant" is allowed.
+     Short form: topic-level bridges, including "saw you in a few conversations about/around [topic], so hope this is relevant" and "hope this is relevant if [topic] is part of the plan", are allowed for Shared Signal Discovery when evidence-backed and not engagement-claiming; "might be interested" is not allowed.
      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",
@@ -1303,9 +1314,10 @@ Message, and verify current-revision sample messages before final completion.
      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.
-     "Hope this is relevant" is allowed when it does not pretend engagement and
-     immediately ties to a concrete buyer problem. Do not open with "might be
-     interested" or "saw you in a few conversations". Do not use a repeated
+     Do not use source-thread hedges such as "hope this is relevant", "might be
+     interested", or "saw you in a few conversations" in Shared Cold Fallback.
+     Start from a concrete role, company, or buyer-problem observation instead.
+     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
@@ -1326,7 +1338,7 @@ Message, and verify current-revision sample messages before final completion.
      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.
-     Short form: "hope this is relevant" is allowed; "might be interested" and "saw you in a few conversations" are not.
+     Short form: no "hope this is relevant", "might be interested", or "saw you in a few conversations" in Shared Cold Fallback; Shared Signal Discovery has the topic-level conversation-bridge exception above.
      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
@@ -1415,11 +1427,12 @@ Message, and verify current-revision sample messages before final completion.
       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, low-confidence relevance hedges such as "might be
-      interested" or "saw you in a few conversations", 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
+      near-identical samples, intent-assumptive hedges such as "might be
+      interested", source-context mismatches such as "saw you in a few
+      conversations" in Shared Cold Fallback, 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

package/skill-templates/refill-sends.md

@@ -108,6 +108,13 @@ step using campaign names first, and stop before mutation unless the user has
 explicitly approved the exact workspace, campaign/table/source ids, caps/dates,
 approval mode, expected side effects, and stop/rollback condition.
 
+If the plain route's managed waterfall targets are stale, for example skipped
+targets show archived/completed shared slots or the returned targets do not cover
+the named sender, immediately run the active route refetch before declaring a
+sender blocked. Current dashboard-active `PAUSED` campaign-backed sequence
+campaigns are start-eligible refill candidates; read refill state before deciding
+whether to prep, approve, start, or skip. Do not treat them as archived inventory.
+
 For interactive Codex or Claude Code sessions, that approval must use the
 host-native structured question gate, not plain chat:
 
@@ -142,6 +149,14 @@ direct scheduler writes, sender reassignment, or campaigns outside those
 selected for the eligible sender set. Stop and re-plan if the route, sender set,
 ids, caps, blockers, or side-effect class drift before mutation.
 
+In `--yolo`, continue as far as the rendered packet safely allows. After each
+apply/prep/start result, reread state, settle processing when needed, and move to
+the next selected sender or start-eligible same-packet campaign instead of
+stopping after the first partial result. If no in-packet safe action remains,
+return concrete continuation options with campaign names, exact ids, which option
+is already covered by the current packet, and which option needs a new approval
+packet.
+
 In `--yolo`, the default two-day fill horizon is two send days unless
 `--until`/`untilDate` is provided. If an until date is provided, compute bounded
 gaps through that sender-local date inclusive, skipping no-send days and never