@sellable/install 0.1.288 → 0.1.290

package/package.json

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

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,

package/skill-templates/refill-sends.md

@@ -112,14 +112,20 @@ 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:
-selected sender-local days, gross scheduled-send target, scheduler-owned
-scheduled coverage across active enrolled campaigns, ready buffer, remaining
-scheduled gap, remaining ready-or-scheduled gap, `targetShapeRevision`, and
-`stateRevision`. If the target plan is complete, report that the selected target
-is already filled and no-op without asking for approval. If the ready buffer
-covers the target 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.
+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
@@ -158,10 +164,12 @@ 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, action class, or side-effect class drift before mutation.
-Scheduled counts increasing toward the approved target are expected progress:
+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.
 
@@ -173,19 +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, `targetShapeRevision`, `stateRevision`, 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