@sellable/install 0.1.279 → 0.1.281

package/package.json

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

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

@@ -938,32 +938,48 @@ verify and do not repair by summarizing product readback in the parent.
 Message Drafting runtime rule: the preferred proof source is the normal
 create-campaign branch handoff (`watchNarration.workerDetails.messageDraftBuilder`
 or equivalent) with `statusSource:"branch"`. If that internal branch handoff is
-not callable or not exposed in the packaged MCP runtime, do **not** stop after
-creating/importing rows. The lane worker must run the packaged message-drafting
-path itself in the worker thread:
-
-1. Load `get_subskill_prompt({ subskillName:"generate-messages" })` until
-   `hasMore:false`.
-2. Load the required message assets and `create-campaign-v2-validation`.
-3. Call `start_campaign_message_preparation({ campaignId, tableId,
+not callable or not exposed in the packaged MCP runtime, do **not** substitute
+plain row generation. The lane worker must inline the same
+`post-find-leads-message-scout` contract in the worker thread before any
+`start_campaign_message_preparation` call:
+
+1. Run the `post-find-leads-message-scout` branch, or inline its packaged
+   contract when branch launch is unavailable, from the current campaign/table,
+   selected lead list, saved filters, review batch row ids/hash, brief hash,
+   `mode:"create-campaign-v2"`, and lane type.
+2. Load `get_subskill_prompt({ subskillName:"generate-messages" })` until
+   `hasMore:false`, all required message assets, and
+   `create-campaign-v2-validation`.
+3. Produce a concrete `messageDraftRecommendation` before row generation. It
+   must include the selected message approach/template recommendation,
+   token/fill rules, source-use rules, hard avoids, at least one rendered good
+   sample, current campaign/table/source basis, and validation status. Shared
+   lanes still use `firstMessageTemplateState:"not preset; generate-messages
+   branch selected the final message approach"`; do not set
+   `firstMessageTemplate` for shared lanes.
+4. Persist the recommendation into the campaign brief/message generation basis
+   with the packaged create-campaign tools before generating rows. If the
+   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.
+5. Only after the scout recommendation and persisted basis exist, call
+   `start_campaign_message_preparation({ campaignId, tableId,
    targetPreparedMessages, maxRowsToCheck, approvalMode:"mark_ready",
    autoContinue:true })` inside the same lane worker, with bounded caps from the
-   lane packet.
-   Never call `start_campaign_message_preparation` with `approvalMode:"approve"`
-   for evergreen setup. Generate/readiness and approval are separate safety
-   steps: first mark rows ready, then inspect generated copy, then approve
-   exactly one semantic Approved cell through `select_campaign_cells` and
-   `update_cell`.
+   lane packet. `start_campaign_message_preparation` is row execution proof
+   only; it is not Message Drafting proof and cannot satisfy this step by
+   itself. Never call `start_campaign_message_preparation` with
+   `approvalMode:"approve"` for evergreen setup.
+   Generate/readiness and approval are separate safety steps: first mark rows
+   ready, then inspect generated copy, then approve 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
+   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`.
@@ -974,9 +990,9 @@ path itself in the worker thread:
    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
+6. 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
+7. Use `get_campaign_messages_preview` or `select_campaign_cells` to inspect
    generated rows, quality-review at least 3 samples, approve exactly one
    quality-valid route-proof row when none is already approved, and prove no
    broad approve-all happened.
@@ -986,16 +1002,21 @@ path itself in the worker thread:
    approvedGeneratedMessageCount exactly 1. Do not report completion with 2+
    approved rows.
    Approval shorthand: Do not report completion with 2+ approved rows.
-6. Continue to `attach_recommended_sequence({ campaignId, currentStep:"send" })`
+8. Continue to `attach_recommended_sequence({ campaignId, currentStep:"send" })`
    and, if the campaign is still `DRAFT`, `pause_campaign({ campaignId })`.
    Reread the campaign/table before claiming completion.
 
 That packaged worker path must return `messageDraftingReceipt.statusSource:
 "packaged-generate-messages-worker"`. It is accepted only when the receipt
-includes the same prompt/assets/validation proof, current campaign/table/source
-basis, generated review rows, sample messages, quality review, route-proof
-approval evidence, sequence proof, and final paused-send proof required of the
-branch handoff. `statusSource:"parent-thread-fallback"` is still invalid.
+includes branch-equivalent `post-find-leads-message-scout` proof, the
+`messageDraftRecommendation`, proof the recommendation was persisted into the
+brief/message basis before row generation, the prompt/assets/validation proof,
+current campaign/table/source basis, generated review rows, sample messages,
+quality review, route-proof approval evidence, sequence proof, and final
+paused-send proof required of the branch handoff. `statusSource:
+"parent-thread-fallback"` is still invalid. If neither branch handoff nor
+inline scout proof can run, stop with `blocked:
+missing_message_drafting_branch`; do not shortcut through row prep.
 The only accepted statusSource values are exactly `branch` and
 `packaged-generate-messages-worker`; descriptive aliases such as
 `package-readback-local-thread` are rejected.
@@ -1232,7 +1253,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 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 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
@@ -1298,7 +1319,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: 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: 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",
@@ -1365,16 +1386,25 @@ Message, and verify current-revision sample messages before final completion.
       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
-     returned receipt must include `statusSource:"branch"` or
-     `statusSource:"packaged-generate-messages-worker"`, at least 3 concrete
-     reviewed sample messages, a passed validation result, and a passed quality
-     review. Row/message counts alone are not enough.
+      campaign/table basis after source rows exist and saved filters are
+      applied. The worker must use the normal
+      `post-find-leads-message-scout` branch handoff or inline that same scout
+      contract when branch launch is unavailable. Plain
+      `start_campaign_message_preparation` is row execution proof only; it is
+      not a fallback substitute for Message Drafting. The worker must load the
+      full packaged `generate-messages` prompt, every required asset, and
+      `create-campaign-v2-validation`; before row generation, the receipt must
+      show branch-equivalent scout proof, a concrete
+      `messageDraftRecommendation`, and proof that recommendation was persisted
+      into the campaign brief/message generation basis. Only then may the
+      worker call `start_campaign_message_preparation` and poll
+      `get_campaign_message_preparation_status` from the lane worker. The
+      returned receipt must include `statusSource:"branch"` or
+      `statusSource:"packaged-generate-messages-worker"`, at least 3 concrete
+      reviewed sample messages, a passed validation result, and a passed quality
+      review. Row/message counts alone are not enough. If the branch handoff and
+      inline scout contract are both unavailable, report
+      `blocked: missing_message_drafting_branch`.
 
    - **The brief must declare the delivery format** so Generate Message writes copy suited to how it actually sends:
      - DM lanes: add a `Delivery format:` line — either `multiline (each paragraph sends as its own DM message)` or `single message`. When multiline, the template's blank-line paragraphs ARE the message boundaries — write each one as a standalone typed message.
@@ -1412,12 +1442,15 @@ Message, and verify current-revision sample messages before final completion.
      `hasMore:false`, required message assets were loaded, and
      `create-campaign-v2-validation` ran through
      `workerDetails.messageDraftBuilder` with `statusSource:"branch"` or
-     through the lane worker's packaged message-prep path with
-     `statusSource:"packaged-generate-messages-worker"`,
-     `start_campaign_message_preparation`, and
+     through the lane worker's inline `post-find-leads-message-scout` contract
+     with `statusSource:"packaged-generate-messages-worker"`. For the packaged
+     worker path, proof must include branch-equivalent scout proof, a concrete
+     `messageDraftRecommendation`, template/basis persistence proof before row
+     generation, `start_campaign_message_preparation`, and
      `get_campaign_message_preparation_status`. The generated-message cells are
      not prompt proof; `currentRevisionGeneratedMessages` and row previews are
-     only downstream cell evidence. The proof must include
+     only downstream cell evidence. Row prep alone is not prompt proof. The
+     proof must include
       `validationResult:"passed"`, a passed quality review, and at least 3
       reviewed sample messages. For Shared Cold Fallback, reject samples that
       open with a standalone name followed by "Hey there" or a similarly generic

package/skill-templates/refill-sends.md

@@ -157,6 +157,19 @@ return concrete continuation options with campaign names, exact ids, which optio
 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