@sellable/install 0.1.287 → 0.1.289

package/bin/sellable-install.mjs

@@ -1005,6 +1005,7 @@ const CREATE_CAMPAIGN_ALLOWED_TOOLS = [
   "mcp__sellable__wait_for_campaign_processing",
   "mcp__sellable__resolve_campaign_fill_route",
   "mcp__sellable__get_campaign_refill_state",
+  "mcp__sellable__get_refill_target_plan",
   "mcp__sellable__fill_campaign_horizon",
   "mcp__sellable__start_campaign_message_preparation",
   "mcp__sellable__get_campaign_message_preparation_status",
@@ -1064,6 +1065,7 @@ const REFILL_SENDS_ALLOWED_TOOLS = [
   "mcp__sellable__get_campaign_waterfall",
   "mcp__sellable__resolve_campaign_fill_route",
   "mcp__sellable__get_campaign_refill_state",
+  "mcp__sellable__get_refill_target_plan",
   "mcp__sellable__fill_campaign_horizon",
   "mcp__sellable__get_campaign",
   "mcp__sellable__get_campaign_context",
@@ -1989,10 +1991,11 @@ Desktop, then start a new thread.
 
 1. Call \`mcp__sellable__get_auth_status({})\`.
 2. Normalize invocation arguments with \`mcp__sellable__refill_sends({ yolo, senders, senderIds, senderNames, untilDate })\` when the host exposes typed MCP tools.
-3. Load the canonical prompt via
+3. Call \`mcp__sellable__get_refill_target_plan({ senders, senderIds, senderNames, untilDate })\` before any mutation. If the returned target is already complete, stop with the no-op receipt. If ready rows cover the target but scheduled rows do not, run only the read-only scheduler settle/re-read loop.
+4. Load the canonical prompt via
    \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends" })\`,
    then load \`mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends-workflow" })\`.
-4. Follow the canonical prompt exactly. Do not launch, start, archive, delete,
+5. Follow the canonical prompt exactly. Do not launch, start, archive, delete,
    or write scheduler rows as part of refill sends.
 
 ## MCP Prompt Fallback

package/lib/runtime-verify.mjs

@@ -30,6 +30,7 @@ export const REQUIRED_SELLABLE_MCP_TOOLS = [
   "attach_recommended_sequence",
   "resolve_campaign_fill_route",
   "get_campaign_refill_state",
+  "get_refill_target_plan",
   "refill_sends",
   "setup_evergreen_campaigns",
   "start_campaign_message_preparation",

package/package.json

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

package/skill-templates/create-campaign.md

@@ -49,6 +49,7 @@ allowed-tools:
   - mcp__sellable__wait_for_campaign_processing
   - mcp__sellable__resolve_campaign_fill_route
   - mcp__sellable__get_campaign_refill_state
+  - mcp__sellable__get_refill_target_plan
   - mcp__sellable__fill_campaign_horizon
   - mcp__sellable__start_campaign_message_preparation
   - mcp__sellable__get_campaign_message_preparation_status

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

@@ -159,6 +159,14 @@ Post Engagers slots; shared sender scope is the union of senderRefs on the
 shared Signal Discovery and Shared Cold Fallback waterfall slots. If the
 waterfall has one clear production evergreen program for the workspace, this is
 not ambiguous even when `list_senders` returns additional connected senders.
+If non-archived existing shared evergreen campaigns/tables are already attached
+to additional senders, count those attached sender ids as current shared-lane
+membership and include them in the shared-lane report. Do not collapse the
+shared scope down to the one person named for a Post Engagers lane unless the
+operator explicitly asked to limit shared lanes to that person or remove other
+senders. Archived campaigns, archived tables, and archived waterfall bindings
+are stale inventory for scope/counting unless the operator supplied those exact
+ids and explicitly asked for archived dashboard visibility repair.
 In non-interactive or `--yolo` mode, when more than two connected senders exist
 and neither the prompt nor product-visible waterfall evidence identifies exact
 evergreen sender scope, stop before mutation with
@@ -168,6 +176,8 @@ Engagers lanes for extra senders.
 Short form: Do not pass `allConnectedSenders:true` unless the prompt explicitly says all/every connected sender.
 Short form: "all 4 campaigns" means explicit sender scope plus two shared lanes, not all connected senders.
 Short form: Product-visible managed evergreen/prod waterfall senderRefs are exact sender scope.
+Short form: Non-archived shared campaign attachments count as current shared-lane sender scope.
+Short form: A named Post Engagers sender is not automatically the whole shared-lane scope.
 Short form: Do not report `no_senders` while waterfall senderRefs can be mapped to list_senders.
 Short form: In `--yolo`, ambiguous multi-sender scope blocks before mutation.
 </inputs>
@@ -270,7 +280,8 @@ differ, pass both explicit arrays:
 - `postEngagerSenderIds`: only senders that should have sender-owned Post
   Engagers campaigns.
 - `sharedSenderIds`: senders attached to the shared Signal Discovery and Shared
-  Cold Fallback campaigns.
+  Cold Fallback campaigns. This must be the full intended shared sender set,
+  not merely the sender named for a Post Engagers lane.
 
 If the operator says a sender is shared-only, do not create a Post Engagers lane
 for that shared-only sender. Example: if Justin already has a Post Engagers
@@ -387,10 +398,13 @@ before completion.
 Short form: Workers must preserve parent postEngagerSenderIds even for shared lanes.
 Short form: Never run a shared-lane worker-local plan with `postEngagerSenderIds:[]` unless the parent `postEngagerSenderIds` is exactly `[]`.
 
-Worker fan-out must use visible or durable execution. Preferred in local Codex
-is a visible Codex thread created with the actual Codex app thread tools:
-first call `codex_app.list_projects`, select the current repo project, then
-call `codex_app.create_thread` with `target:{type:"project", projectId,
+Worker fan-out must use visible or durable execution. In local Codex, the
+default and preferred runtime is `workerDispatch.preferredRuntime:
+"visible-codex-app-thread"`. The parent must attempt a visible Codex app thread
+first with the actual Codex app thread tools: if `codex_app.create_thread` is
+not already visible, use tool discovery for the Codex app thread tools; then
+call `codex_app.list_projects`, select the current repo project, and call
+`codex_app.create_thread` with `target:{type:"project", projectId,
 environment:{type:"local"}}`. Do not create a worktree target for evergreen
 UAT or lane execution. The parent must record the returned thread id, pass
 exactly one lane packet into that thread, and require the worker to write the
@@ -404,9 +418,10 @@ worker exits, and contain the current `planRevision`, `actionId`, `laneKey`,
 `receiptArtifactPath`, and `durableReceiptWritten:true`. If a receipt predates
 the current run, uses an old path without `receiptRunId`, or was not freshly
 written by the current worker, stop with `blocked: stale_receipt_artifact`
-before parent verify or completion. A streaming worker or branch worker is
-acceptable only when it writes a fresh durable per-lane receipt artifact as it
-works.
+before parent verify or completion. A streaming worker or branch worker is a
+fallback only when app thread tools are unavailable; the receipt must include
+`preferredRuntimeAttempt` for `visible-codex-app-thread` and a non-empty
+`fallbackReason`, or backend verify rejects it.
 When visible Codex app thread tools are unavailable but local Codex CLI is
 available, the accepted durable streaming-worker command shape is:
 `codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
@@ -716,7 +731,11 @@ not a parent-thread summary. The receipt must include:
   `workflowAssetPath:"create-campaign-v2/core/flow.v2.json"`,
   `workflowAssetLoaded:true`, the real `workerRuntime`, a visible
   `workerThreadId` or durable `receiptArtifactPath`, `durableReceiptWritten:true`
-  when using a receipt file, and `notAdHoc:true`.
+  when using a receipt file, and `notAdHoc:true`. If `workerRuntime` is
+  `streaming-worker-with-durable-receipt` or
+  `branch-worker-with-durable-receipt`, also include
+  `preferredRuntimeAttempt` proving the parent attempted
+  `visible-codex-app-thread` first and a non-empty `fallbackReason`.
 - `researchSenderReceipt`: `research-sender` prompt load proof,
   `complete_sender_research` result, sender LinkedIn identity basis, and the
   notes/proof counts used before the net-new `create_campaign` call. It must
@@ -911,7 +930,7 @@ verification unless the same object also appears inside
       "workflowPromptLoadedToHasMoreFalse": true,
       "workflowAssetPath": "create-campaign-v2/core/flow.v2.json",
       "workflowAssetLoaded": true,
-      "workerRuntime": "separate-codex-thread",
+      "workerRuntime": "visible-codex-app-thread",
       "workerThreadId": "<visible local Codex thread id>",
       "receiptArtifactPath": "<receiptArtifactPath from workerDispatch.receiptArtifactHint>",
       "durableReceiptWritten": true,
@@ -1330,21 +1349,35 @@ Message, and verify current-revision sample messages before final completion.
      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
-     sender-authored post they engaged with, and stops after the thank-you
-     line. Use **no internal vocabulary, no pitch, no meeting ask, no product
-     line, and no relevance question** in message one:
+     sender-authored post they engaged with, includes the post URL as a concrete
+     reminder, uses an easy buyer-function/category line, and ends with one
+     row-custom closed question. Use **no internal vocabulary, no meeting ask,
+     no proof block, no feature-stack category, and no generic static question**
+     in message one:
 
      ```
      {{first_name}}
 
      Hey there
 
-     Thank you for the support on my post about {{post_topic_line}}
+     Saw you pop up on my post about {{post_topic_line}}
+
+     This one
+     {{post_url}}
+
+     Looks like you lead {{plain_buyer_function}} at {{company_name}}, right?
+
+     {{custom_closed_question}}
      ```
 
-     Do not add any paragraph after the thank-you line. In particular, do not
-     append `curious, are you trying...`, `open to...`, `worth seeing...`, or
-     Sellable/product copy to a Post Engagers first message.
+     `{{custom_closed_question}}` must be specific to the post topic, buyer
+     function, company context, and current offer category. The category should
+     be easy to understand, for example `LinkedIn outbound`, `customer success`,
+     `CX operations`, `support`, `sales`, or `growth`; do not use feature-heavy
+     phrasing like `manual research + follow-up process`, `lead filters`, or
+     `sequence setup`. Do not add any paragraph after the custom closed question.
+     In particular, do not append `open to...`, `worth seeing...`, a meeting ask,
+     proof block, or Sellable/product copy to a Post Engagers first message.
 
    - **Shared Signal Discovery** first-message style: short, casual, starts
      from the real public business theme or buyer problem supported by the row.

package/skill-templates/refill-sends.md

@@ -4,6 +4,7 @@ description: Plan regular campaign and evergreen campaign send refill work throu
 visibility: public
 allowed-tools:
   - mcp__sellable__refill_sends
+  - mcp__sellable__get_refill_target_plan
   - mcp__sellable__get_auth_status
   - mcp__sellable__start_cli_login
   - mcp__sellable__wait_for_cli_login
@@ -102,11 +103,29 @@ get_subskill_prompt({ subskillName: "refill-sends-workflow" })
 ```
 
 Then follow that workflow exactly. The default path is read-only research:
-resolve the route, identify the sender-relevant campaign that most recently had
-scheduler-owned sends, read refill state for that target, report the next safe
-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.
+compute the refill target plan first, resolve the route, identify the
+sender-relevant campaign that most recently had scheduler-owned sends, read
+refill state for that target, report the next safe 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.
+
+Immediately after loading the internal workflow, call
+`get_refill_target_plan`. The target plan is the canonical first fact receipt:
+eligible senders, selected sender-local days, gross target, actual sent
+coverage, scheduler-owned scheduled coverage across active enrolled campaigns,
+projected coverage (`sent + scheduled`), inferred per-sender send lane/action
+selections, ready buffer, remaining projected gap, paid-InMail credit/threshold
+feasibility, `targetShapeRevision`, and `stateRevision`. When `actionTypes` are
+omitted, trust the target plan's inferred lane rather than asking whether to
+fill connections, DMs, or InMails. If the target plan is complete by projected
+coverage, report that the selected target is already filled and no-op without
+asking for approval. If the ready buffer covers the projected gap but scheduled
+coverage is still short, run only a bounded read-only scheduler settle/reread
+loop and report `awaiting_scheduler_after_ready_buffer` if it does not settle.
+If paid InMail is below threshold, stale, or missing credit facts, report the
+exact campaign/table/column threshold action or connection fallback; `--yolo`
+does not lower paid-InMail thresholds or create campaigns.
 
 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
@@ -145,9 +164,14 @@ 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
+	direct scheduler writes, sender reassignment, paid-InMail threshold changes,
+	connection campaign creation, 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.
+ids, caps, blockers, paid-InMail feasibility, action class, or side-effect class
+drift before mutation. Sent/scheduled counts increasing toward the approved
+target are expected progress:
+they change `stateRevision`, not `targetShapeRevision`, and do not require a
+second approval.
 
 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
@@ -157,18 +181,20 @@ 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.
+For `--yolo` fill/schedule requests, completion means projected horizon
+saturation (`sent + scheduled`), not merely prepared/approved/ready rows.
+Maintain a horizon saturation ledger per selected sender: selected send days,
+gross capacity, actual sent cells, future scheduler-owned scheduled cells with
+non-null `scheduledFor`, projected count, ready-to-schedule buffer, remaining
+projected gap, paid-InMail feasibility, `targetShapeRevision`,
+`stateRevision`, and the next MCP primitive that can reduce the gap. After every
+apply/prep/start result, wait for processing, reread the target plan/refill
+state, recompute the ledger, then keep applying safe bounded actions until
+projected coverage fills the horizon or a concrete blocker/timeout is proven.
+If ready rows cover the projected gap 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