@sellable/mcp 0.1.345 → 0.1.347

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.345",
+  "version": "0.1.347",
   "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

@@ -129,7 +129,22 @@ filter choice, Message Drafting, packaged `generate-messages`, sequence
 attachment, and send-review readiness. Do not rebuild those steps ad hoc in the
 parent thread.
 
-Workers return worker receipts. The parent then calls
+Workers return worker receipts. Each customer-visible lane receipt must include
+message proof from `watchNarration.workerDetails.messageDraftBuilder` or the
+worker's equivalent handoff record. Valid message proof names the current
+campaign id, workflowTableId, selected lead-list or source id, filter choice,
+review-batch row ids/hash, and either `statusSource:"branch"` or
+`statusSource:"parent-thread-fallback"`. It must prove the worker loaded the
+full packaged prompt with `get_subskill_prompt({ subskillName:"generate-messages"`
+until `hasMore:false`, loaded the required message assets, and loaded
+`create-campaign-v2-validation` before returning a `messageDraftRecommendation`.
+The generated-message cells are not prompt proof: `currentRevisionGeneratedMessages`,
+Generate Message column counts, `messagesCount`, or rendered row previews prove
+only that table cells exist from the current brief/template, not that the
+create-campaign Message Drafting branch ran. If this receipt is missing, report
+`blocked: missing_message_drafting_receipt` and do not call the lane complete.
+
+The parent then calls
 `setup_evergreen_campaigns({ mode:"verify", planRevision, selectedActionIds,
 receipts })` and report only verified completion. If verify blocks, report the
 blocker and repair only the missing postconditions from the same current plan.
@@ -179,26 +194,62 @@ Parent-thread handwritten copy or setting `currentStep` is not proof.
    - Message Drafting has run from the current campaign/table basis, using the
      create-campaign message prompt/assets and validation gate. Updating
      `currentStep:"messages"` is not proof. Parent-thread handwritten copy is
-     not a substitute.
+     not a substitute. The proof receipt must show
+     `get_subskill_prompt({ subskillName:"generate-messages"` was loaded until
+     `hasMore:false`, required message assets were loaded, and
+     `create-campaign-v2-validation` ran through either
+     `workerDetails.messageDraftBuilder` with `statusSource:"branch"` or an
+     inline `statusSource:"parent-thread-fallback"` receipt. The generated-message
+     cells are not prompt proof; `currentRevisionGeneratedMessages` and row
+     previews are only downstream cell evidence.
    - 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