@sellable/install 0.1.278 → 0.1.280

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.278",
+  "version": "0.1.280",
   "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 intent-assumptive/source-thread hedges such as "might be interested", "hope this is relevant", and "saw you in a few conversations"; Shared Signal Discovery is a source provider, not customer-facing message copy.
+     Short form: Shared lanes must reject unsupported intent-assumptive hedges; Shared Signal Discovery may use Dotwork-style topic bridges like "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 "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
@@ -1273,9 +1273,18 @@ 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 intent-assumptive/source-thread hedges such as "might be
-     interested", "hope this is relevant", "found you in a thread", or "saw
-     you in a few conversations" in Shared Signal Discovery samples.
+     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",
@@ -1289,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 "might be interested", "hope this is relevant", "found you in a thread", or "saw you in a few conversations"; translate source evidence into buyer context.
+     Short form: topic-level bridges, including "saw you might be interested in [topic], so hope this is relevant", "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; do not use bare "might be interested" as a generic intent claim.
      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",
@@ -1329,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: no "hope this is relevant", "might be interested", or "saw you in a few conversations" in shared evergreen lanes.
+     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

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,27 @@ 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.
+
+For `--yolo` fill/schedule requests, completion means scheduler-proven horizon
+saturation, not merely prepared/approved/ready rows. Maintain a horizon
+saturation ledger per selected sender: selected send days, gross capacity,
+future scheduler-owned scheduled cells with non-null `scheduledFor`,
+ready-to-schedule buffer, remaining scheduled gap, remaining ready-or-scheduled
+gap, and the next MCP primitive that can reduce the gap. After every
+apply/prep/start result, wait for processing, reread refill state, recompute the
+ledger, then keep applying safe bounded actions until the scheduled count fills
+the horizon or a concrete blocker/timeout is proven. If ready rows cover the
+horizon but the scheduler has not picked them up yet, run a bounded scheduler
+settle loop and report `awaiting_scheduler_after_ready_buffer` as not complete
+when the timeout is reached.
+
 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