@sellable/install 0.1.272 → 0.1.274

package/package.json

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

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

@@ -926,48 +926,32 @@ 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** 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,
+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,
    targetPreparedMessages, maxRowsToCheck, approvalMode:"mark_ready",
    autoContinue:true })` inside the same lane worker, with bounded caps from the
-   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`.
+   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`.
    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.
-   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
+   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`.
@@ -978,9 +962,9 @@ plain row generation. The lane worker must inline the same
    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.
-6. Poll `get_campaign_message_preparation_status` until no queued/active cells
+4. Poll `get_campaign_message_preparation_status` until no queued/active cells
    remain or a bounded stop reason is returned.
-7. Use `get_campaign_messages_preview` or `select_campaign_cells` to inspect
+5. 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.
@@ -990,21 +974,16 @@ plain row generation. The lane worker must inline the same
    approvedGeneratedMessageCount exactly 1. Do not report completion with 2+
    approved rows.
    Approval shorthand: Do not report completion with 2+ approved rows.
-8. Continue to `attach_recommended_sequence({ campaignId, currentStep:"send" })`
+6. 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 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.
+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.
 The only accepted statusSource values are exactly `branch` and
 `packaged-generate-messages-worker`; descriptive aliases such as
 `package-readback-local-thread` are rejected.
@@ -1358,25 +1337,16 @@ 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 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`.
+      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.
 
    - **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.
@@ -1414,15 +1384,12 @@ 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 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
+     through the lane worker's packaged message-prep path with
+     `statusSource:"packaged-generate-messages-worker"`,
+     `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. Row prep alone is not prompt proof. The
-     proof must include
+     only downstream cell evidence. 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

@@ -24,6 +24,7 @@ allowed-tools:
   - mcp__sellable__get_provider_prompt
   - mcp__sellable__get_campaign_message_preparation_status
   - mcp__sellable__start_campaign_message_preparation
+  - mcp__sellable__start_campaign
   - mcp__sellable__cancel_campaign_message_preparation
   - mcp__sellable__import_leads
   - mcp__sellable__wait_for_lead_list_ready
@@ -130,11 +131,16 @@ the active workspace. Without `--yolo`, if Christian did not name senders, ask
 which eligible enrolled senders to refill before choosing campaigns or mutating.
 
 `--yolo` only covers the exact sender set, per-sender target campaigns, caps,
-approval mode, and side effects in the packet. It does not authorize
-launch/start, sending, archive or delete cleanup, 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.
+approval mode, and side effects in the packet. It may authorize `start_campaign`
+only for selected `PAUSED`, dashboard-active, campaign-backed sequence refill
+targets when the rendered packet names the exact campaign ids and start side
+effect. Starting a paused campaign can let the product scheduler schedule/send
+approved eligible sequence actions, so include that expected side effect in the
+packet. It does not authorize starting unrelated, archived, completed, draft, or
+direct campaigns, separate launch/send actions, archive or delete cleanup,
+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`, the default two-day fill horizon is two send days unless
 `--until`/`untilDate` is provided. If an until date is provided, compute bounded