@sellable/mcp 0.1.344 → 0.1.346

package/dist/tools/setup-evergreen-campaigns.d.ts

@@ -4,6 +4,8 @@ type SetupEvergreenCampaignsInput = {
     yolo?: boolean;
     allConnectedSenders?: boolean;
     selectedSenderIds?: string[];
+    postEngagerSenderIds?: string[];
+    sharedSenderIds?: string[];
     bindings?: Array<{
         laneKey: string;
         campaignId: string;
@@ -45,6 +47,22 @@ export declare const setupEvergreenCampaignsToolDefinitions: {
                 maxItems: number;
                 description: string;
             };
+            postEngagerSenderIds: {
+                type: string;
+                items: {
+                    type: string;
+                };
+                maxItems: number;
+                description: string;
+            };
+            sharedSenderIds: {
+                type: string;
+                items: {
+                    type: string;
+                };
+                maxItems: number;
+                description: string;
+            };
             bindings: {
                 type: string;
                 maxItems: number;

package/dist/tools/setup-evergreen-campaigns.js

@@ -6,7 +6,7 @@ async function postSetupEvergreenCampaigns(body) {
 export const setupEvergreenCampaignsToolDefinitions = [
     {
         name: "setup_evergreen_campaigns",
-        description: "Evergreen campaign setup plan/verify command. Use plan mode first to inspect exact workspace/sender/campaign/table/source state and receive immutable lane packets for one Post Engagers lane per selected sender plus shared Signal Discovery and Shared Cold Fallback lanes. yolo is only a parent-skill auto-execution hint for safe lane packets; this backend command remains read-only in plan mode and verifies receipts in verify mode. When safe-yolo needs normal setup work, the parent skill may ask for bounded delegated approval: one approval over the current planRevision, selected action ids, caps, allowed side-effect classes, and stop conditions lets lane workers execute without per-substep approval while staying inside that packet. Lane workers must execute creation, source import, create-campaign workflow steps, generate-messages, sequence attachment, and review readiness through existing create-campaign workflow/subskills, then return receipts here for verification. This command does not launch campaigns, does not schedule sends, does not assign scheduler-owned send fields, does not archive/delete cleanup targets, and does not spend paid credits.",
+        description: "Evergreen campaign setup plan/verify command. Use plan mode first to inspect exact workspace/sender/campaign/table/source state and receive immutable lane packets. `selectedSenderIds` is a legacy shorthand for both scopes; prefer `postEngagerSenderIds` for the Post Engagers sender scope and `sharedSenderIds` for the shared lane sender scope when they differ. The command plans one Post Engagers lane per post-engager sender plus shared Signal Discovery and Shared Cold Fallback lanes for the shared sender set. yolo is only a parent-skill auto-execution hint for safe lane packets; this backend command remains read-only in plan mode and verifies receipts in verify mode. When safe-yolo needs normal setup work, the parent skill may ask for bounded delegated approval: one approval over the current planRevision, selected action ids, caps, allowed side-effect classes, and stop conditions lets lane workers execute without per-substep approval while staying inside that packet. Lane workers must execute creation, source import, create-campaign workflow steps, generate-messages, sequence attachment, and review readiness through existing create-campaign workflow/subskills, then return receipts here for verification. This command does not launch campaigns, does not schedule sends, does not assign scheduler-owned send fields, does not archive/delete cleanup targets, and does not spend paid credits.",
         inputSchema: {
             type: "object",
             properties: {
@@ -32,7 +32,19 @@ export const setupEvergreenCampaignsToolDefinitions = [
                     type: "array",
                     items: { type: "string" },
                     maxItems: 25,
-                    description: "Exact OutboundSenderIdentity ids for sender-owned Post Engagers lanes and shared-lane sender set.",
+                    description: "Legacy shorthand: exact OutboundSenderIdentity ids for both sender-owned Post Engagers lanes and shared-lane sender set. Prefer scoped fields when those differ.",
+                },
+                postEngagerSenderIds: {
+                    type: "array",
+                    items: { type: "string" },
+                    maxItems: 25,
+                    description: "Exact OutboundSenderIdentity ids that should receive sender-owned Post Engagers lanes.",
+                },
+                sharedSenderIds: {
+                    type: "array",
+                    items: { type: "string" },
+                    maxItems: 25,
+                    description: "Exact OutboundSenderIdentity ids attached to shared Signal Discovery and Shared Cold Fallback lanes.",
                 },
                 bindings: {
                     type: "array",
@@ -78,6 +90,8 @@ export function setupEvergreenCampaigns(input) {
         depth: input.depth,
         allConnectedSenders: input.allConnectedSenders,
         selectedSenderIds: input.selectedSenderIds,
+        postEngagerSenderIds: input.postEngagerSenderIds,
+        sharedSenderIds: input.sharedSenderIds,
         bindings: input.bindings,
         planRevision: input.planRevision,
         selectedActionIds: input.selectedActionIds,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.344",
+  "version": "0.1.346",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign-v2/references/final-handoff-contract.md

@@ -63,6 +63,15 @@ currentStep: "sequence" })` to attach the sender via the v3 senders route and
    and Paid InMail Campaign is only an explicit paid-InMail opt-in because it
    can spend InMail credits. If that response does not persist `currentStep:
 "send"`, call `update_campaign({ campaignId, currentStep: "send" })`.
+   Then reread `get_campaign({ campaignId })` and `list_tables()` and verify the
+   current `workflowTableId` has `hasSequence:true`. A campaign-level
+   `SEQUENCE_EXISTS` response is not enough when `confirm_lead_list` or another
+   copy step has moved the campaign to a new current campaign table while an old
+   stale shell table still owns the sequence columns. In that stale-shell case,
+   either repair only the current workflowTableId with `attach_sequence` using
+   the same non-paid product template the recommended selector would have chosen,
+   or stop and report the stale-shell sequence blocker if replacement was not
+   explicitly approved. Never choose a paid-InMail template for this repair.
 9. Surface the `handoff.orientation` string from `auto-execute.yaml` and
    summarize the visible Settings/Sequence/Send state without repeating the
    watch URL.
@@ -141,7 +150,11 @@ order, atomically:
 2. **Validate sender + sequence state.** If no sender is attached, refuse start
    and return the Settings link. If no sequence is attached but a sender is
    attached, call `attach_recommended_sequence({ campaignId, currentStep:
-"send" })` before approving messages.
+"send" })` before approving messages, then rerun the precondition check against
+   the current workflowTableId rather than an older shell table. If
+   `SEQUENCE_EXISTS` only proves an old shell while the current table lacks
+   `hasSequence:true`, stop or perform the explicitly approved stale-shell
+   current-table repair before any launch.
 3. **Approve generated messages** through the bounded or broad path:
    - If the user asked for an exact send count, such as "schedule 250 sends",
      verify the preparation job approved only the bounded prepared cohort for

package/skills/create-campaign-v2-tail/SKILL.md

@@ -68,6 +68,7 @@ Step 16 — awaiting-user-greenlight
   ask the user which connected sender to attach; in explicit UAT safe mode only, use the safe mock sender
   update_campaign(senderIds=[selectedSenderId], currentStep=sequence)
   attach_recommended_sequence({ campaignId, currentStep: "send" })  # tier-aware: premium/SN -> If Open Profile->INMAIL_OPEN, else INVITE->accepted->DM
+  reread get_campaign + list_tables; verify hasSequence:true on the current workflowTableId, not an older shell table
   if the attach response did not move the UI: update_campaign(currentStep=send)
   surface campaign setup orientation + final launch choices without repeating the watch URL
   STOP. DO NOT call start_campaign. DO NOT move to running without explicit launch greenlight.
@@ -81,7 +82,13 @@ hand-author a `version: 2` template with nodes, branches, and
 entryNodeId — that's error-prone mid-long-context (galley-off UAT
 `20260420T195732Z` failed because Claude hit "Invalid node type" and
 tried to debug via forbidden Bash/Glob calls). Use `attach_sequence`
-only when the caller explicitly needs a custom non-recommended cadence.
+only when the caller explicitly needs a custom non-recommended cadence, or when
+you have just reread the campaign after `confirm_lead_list` and proved the
+current campaign table has no sequence while an older stale shell table is
+causing campaign-level `SEQUENCE_EXISTS`. In that stale-shell repair case, use
+`attach_sequence` on the current workflowTableId with the same non-paid product
+template the backend would select; never choose a paid-InMail template and never
+repair a table other than the current workflowTableId.
 
 Hard gates — if you find yourself about to violate any of these, stop
 first:
@@ -532,6 +539,14 @@ Shape:
    opt-in because it can spend InMail credits. If the tool response
    does not persist `currentStep: "send"`, call
    `update_campaign({ campaignId, currentStep: "send" })`.
+   Then reread `get_campaign({ campaignId })` and `list_tables()` and verify the
+   returned current workflowTableId has `hasSequence:true`. If
+   `attach_recommended_sequence` returned `SEQUENCE_EXISTS` but the current table
+   still has `hasSequence:false`, do not continue to launch handoff from that
+   stale shell proof. Repair only the current workflowTableId with
+   `attach_sequence` using the same non-paid product template the recommended
+   selector would have chosen, or stop and report the stale-shell sequence
+   blocker if replacement was not explicitly approved.
 9. Surface the `handoff.orientation` string from `auto-execute.yaml` without
    repeating the watch URL.
 10. Ask the final launch greenlight with the structured question function:

package/skills/create-evergreen-campaigns/SKILL.md

@@ -60,17 +60,34 @@ plan returns lane packets.
 
 Plan shape:
 
-- one Post Engagers lane per selected sender;
-- one shared Signal Discovery lane;
-- one shared Cold Fallback lane;
+- one Post Engagers lane per sender in the **Post Engagers sender scope**;
+- one shared Signal Discovery lane for the **shared lane sender scope**;
+- one shared Cold Fallback lane for the **shared lane sender scope**;
 - explicit existing campaign/table bindings when the user points at a canonical
   lane. Pass those exact ids to the plan and reuse/verify them instead of
   creating duplicates.
 - If a user supplies canonical ids, reuse/verify them instead of creating duplicates.
 
-When senders are ambiguous, ask which sender ids need Post Engagers lanes before
-planning. If the operator says all connected senders, pass `allConnectedSenders`
-and let the command return exact selected sender ids or blockers.
+Use `selectedSenderIds` only as a legacy shorthand when the same senders should
+get sender-owned Post Engagers lanes and attach to shared lanes. When the scopes
+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.
+
+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
+campaign and Jell/Hulan should only participate in the two shared campaigns,
+call `setup_evergreen_campaigns` with `postEngagerSenderIds:["<justin id>"]`
+and `sharedSenderIds:["<justin id>","<jell or hulan id>"]`.
+
+When senders are ambiguous, ask which sender ids belong in the Post Engagers
+sender scope and which belong in the shared lane sender scope before planning.
+If the operator says all connected senders for both scopes, pass
+`allConnectedSenders` and let the command return exact selected sender ids or
+blockers.
 
 `--yolo` is supported, but it is a safety-scoped execution mode, not a cleanup
 or launch permission. With `--yolo`, pass `yolo:true` to
@@ -166,22 +183,51 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
    - The first review batch exists and at least 3 review rows have generated
      messages from the approved brief. If fewer than 3 usable rows exist, report
      the actual count and why.
+     If a bounded preparation job requested more than the minimum but already
+     met the minimum generated-message floor, do not stall on a single bad review row once a fresh status/readiness check shows no queued, processing, or active cells; record the shortfall, name the failed/empty-row reason when
+     available, and continue with route-proof review rather than expanding source
+     or waiting forever.
    - At least one generated row is approved as a route-proof gate. If zero rows
      are approved and the prompt explicitly asked for full/customer-ready
      completion, approve exactly one quality-valid generated row. If one or more
      rows are already approved, do not add more approvals during evergreen
      completion. Never broad approve all rows.
-   - The recommended non-paid sequence is attached, and the watched campaign is
-     on Send. Use `attach_recommended_sequence({ campaignId, currentStep:"send" })`
-     when a safe attach is needed. Existing sequence proof may come from
-     `SEQUENCE_EXISTS`; do not replace it without explicit user confirmation.
+   - The recommended non-paid sequence is attached to the current campaign
+     table, and the watched campaign is on Send. Use
+     `attach_recommended_sequence({ campaignId, currentStep:"send" })` when a
+     safe attach is needed. After `confirm_lead_list` or any source-list copy,
+     immediately reread `get_campaign({ campaignId })`; the returned
+     `workflowTableId` is the current campaign table. Cross-check that exact
+     current workflowTableId with `list_tables` and require `hasSequence:true`
+     before reporting completion. If a stale shell table has sequence columns but
+     the current campaign table does not, `SEQUENCE_EXISTS` is not enough:
+     record the stale shell table id, then repair the current workflowTableId
+     with `attach_sequence` using the same non-paid product template
+     `attach_recommended_sequence` would have selected. Never use a paid-InMail
+     template and never attach/replace sequence outside the current table unless
+     the current lane packet explicitly allowed sequence repair.
    - No scheduled, queued outbound, sent outbound, campaign launch, or paid
      InMail spend is created by this skill.
 4. **Verify each slot** after create/reuse/repair:
    - `get_campaign` shows the campaign exists, remains unlaunched, and has the expected workflow table.
    - Builder truth must match dashboard truth. `currentStep:"running"` is valid only when the linked table has `campaignStatus:"ACTIVE"`. For a `PAUSED` or `ARCHIVED` campaign/table, repair or flag stale `currentStep:"running"` back to launch review (`send` / review-ready) before reporting the slot done. Never call `start_campaign` just to make a stale `running` step true.
-   - Send/action lanes such as Post Engagers have a sequence attached. Use `list_tables({ hasSequence: true })` as a quick cross-check, but do not treat that filter as the only proof. If the canonical campaign/table is missing from the sequence-filtered table list but a safe `attach_recommended_sequence({ campaignId })` repair/precheck returns `SEQUENCE_EXISTS`, record `sequence attached (verified by SEQUENCE_EXISTS precheck; list_tables.hasSequence mismatch)` and do not retry.
-   - Only use `attach_recommended_sequence({ campaignId })` for a send-lane sequence repair/precheck when the target is a canonical prod slot and the invoking prompt allows sequence repair. Call it at most once without `confirmed`; a successful response is `repaired`, and `SEQUENCE_EXISTS` is non-mutating proof that a sequence already exists. Never call `attach_recommended_sequence` or `attach_sequence` with `confirmed:true` in evergreen automation unless the user explicitly asks to replace an existing sequence.
+   - Send/action lanes such as Post Engagers have a sequence attached on the
+     exact current campaign table. Use `list_tables({ hasSequence: true })` as a
+     quick cross-check, but do not treat that filter as the only proof. If the
+     canonical current campaign table is missing from the sequence-filtered
+     table list and `attach_recommended_sequence({ campaignId })` returns
+     `SEQUENCE_EXISTS`, inspect whether a stale shell table owns the sequence.
+     For a customer-visible completion run, stale shell proof is not completion:
+     rerun the current-table repair above or report `blocked: stale_shell_sequence`.
+   - Only use `attach_recommended_sequence({ campaignId })` for a send-lane
+     sequence repair/precheck when the target is a canonical prod slot and the
+     invoking prompt allows sequence repair. Call it at most once without
+     `confirmed`; a successful response is `repaired`. Treat `SEQUENCE_EXISTS` as
+     non-mutating proof only when the current table also has `hasSequence:true`.
+     Never call `attach_recommended_sequence` or `attach_sequence` with
+     `confirmed:true` in evergreen automation unless the user explicitly asks to
+     replace an existing sequence or the approved lane packet allows current
+     table stale-shell repair.
    - Do not report `source-only/no sequence expected` for any named evergreen
      campaign that appears in Campaigns, has a CampaignOffer ID, or is backed by
      a campaign dashboard table. Shared Signal Discovery and Shared Cold