@sellable/mcp 0.1.363 → 0.1.365

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

@@ -51,11 +51,368 @@ Default evergreen plan per workspace (override only if the prompt specifies diff
 3. **`<Workspace/Team> - Shared Cold Fallback`** — one shared cold/fallback campaign lane across senders
 </inputs>
 
+<command_backed_workflow>
+For full/customer-visible setup, the first operational command is always
+`setup_evergreen_campaigns({ mode:"plan", yolo })`. Inventory can happen first
+for operator understanding, but do not create/reuse/repair campaign shells,
+source rows, messages, sequence, approvals, or cleanup before the command-backed
+plan returns lane packets.
+If `setup_evergreen_campaigns` is unavailable, returns 404, throws an API
+error, or does not return a current `planRevision` with lane packets, stop
+immediately with `blocked: setup_evergreen_campaigns_unavailable`. Do not fall
+back to ad hoc create-campaign calls, inventory-only guesses, or direct shell
+creation when the command-backed plan is missing.
+
+Plan shape:
+
+- 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.
+
+The command-backed unbound plan is authoritative. If
+`setup_evergreen_campaigns({ mode:"plan", ... })` returns a lane packet with
+`intent:"create"`, execute that create packet exactly. Do not convert it into an
+explicit binding because `list_tables`, `get_campaigns`, a waterfall, or old
+inventory shows an `ARCHIVED` campaign/table with a matching name. Archived
+campaigns are not reusable evergreen targets. Only pass an archived
+campaign/table as an explicit binding when the user supplied those exact ids and
+explicitly allowed dashboard visibility repair; otherwise ignore archived
+matches for execution and let the create packet proceed.
+
+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
+`setup_evergreen_campaigns({ mode:"plan", yolo })` and proceed without
+intermediate approval only when every selected lane packet returns
+`autoExecutable:true`. `--yolo` does not authorize archive/delete cleanup,
+launch/start, schedule/send, broad approve-all, wrong workspace work, stale
+plan execution, paid InMail spend, or ambiguous target choice. Stop on wrong
+workspace, cleanup/archive/delete need, stale plan, disconnected sender,
+duplicate candidate, unsafe side effect, missing source proof, or missing
+message proof.
+
+When safe-yolo is blocked only because the plan needs normal setup work, ask
+for a **bounded delegated approval** over the rendered current plan instead of
+asking for each substep. The approval packet must name the workspace id, sender
+ids, lane keys, campaign/table ids or create intents, source/import caps,
+generate-message caps, route-proof approval policy, selectedActionIds,
+planRevision, allowed side-effect classes, and stop conditions. After that one
+approval covers the current planRevision, the parent may act on behalf of the
+operator and execute the selectedActionIds end to end. Do not ask again for
+substep approvals for source import, create-campaign choices, Message Drafting,
+sequence attach/precheck, or exactly one route-proof approval when those actions
+are within the lane packet, approved caps, approved side-effect classes, and
+route-proof approval policy. Stop and re-plan if any fresh reread changes the
+workspace id, sender ids, source/list id, campaign/table id, new campaign/table
+id, planRevision, actionId, selectedActionIds, allowed side effects, caps,
+status, or blocker set outside the approved packet.
+The short rule: one approval covers the current planRevision and selectedActionIds.
+The execution rule: act on behalf of the operator; do not ask again for substep approvals while work stays within the lane packet, approved caps, approved side-effect classes, and route-proof approval policy.
+The drift rule: stop and re-plan when ids, caps, blockers, side-effect classes, or any new campaign/table id leave the approved packet.
+
+After bounded delegated approval or safe `--yolo`, fan out lane worker tasks
+only from the current plan. Each worker receives the complete lane packet:
+workspace id, sender ids, lane key/type, existing campaign/table binding or
+create intent, source hints, caps, planRevision, actionId, allowed side effects,
+and postconditions. Workers must use the create-campaign workflow and
+create-campaign workflow/subskills for campaign creation/setup, source/import,
+filter choice, Message Drafting, packaged `generate-messages`, sequence
+attachment, and send-review readiness. Do not rebuild those steps ad hoc in the
+parent thread. The parent thread is only the planner, dispatcher, verifier, and
+receipt collector: it must not call `create_campaign`, `import_leads`,
+`start_campaign_message_preparation`, `update_cell`, or sequence-attach tools
+for a lane that was assigned to a worker. When the host supports branch
+execution, Task/subagent, or separate Codex threads, assign one lane packet per
+worker and run the lane workers in parallel. If the host cannot run parallel
+workers, report `blocked: missing_parallel_lane_worker_runtime` instead of
+silently doing all lane creation sequentially in the parent thread.
+Short form: the parent thread is the planner, dispatcher, verifier, and receipt collector.
+Before the first mutating lane action, complete an execution-runtime preflight:
+name the callable worker surface/tool that will run lane packets (for example
+Task/subagent, branch worker, separate Codex thread, or an equivalent explicit
+worker runtime). If you cannot name a real callable worker runtime, stop with
+`blocked: missing_parallel_lane_worker_runtime` before calling
+`create_campaign`, `update_campaign`, `import_leads`, `confirm_lead_list`, or
+any source/message/sequence mutation. Creating campaign shells first and then
+discovering the worker runtime is missing is a failed run.
+
+For any lane with `intent:"create"`, the worker must satisfy the normal
+net-new create-campaign preflight before shell creation: load
+`get_subskill_prompt({ subskillName:"research-sender" })`, run the sender/team
+identity research needed for the brief, call `complete_sender_research(...)`,
+then call `create_campaign`. Do not bypass this with a parent-thread brief or
+by directly setting campaign state.
+
+Workers return worker receipts. Each customer-visible lane receipt must include
+one durable `createCampaignStepReceipt` built from actual tool calls or worker receipts,
+not a parent-thread summary. The receipt must include:
+
+- `setupPlanCall`: the exact `setup_evergreen_campaigns({ mode:"plan", ... })`
+  planRevision, selected actionId, lane key, workspace id, sender ids, and
+  campaign/table binding or create intent used before work started. For a
+  create lane, this receipt must explicitly include `createIntent:true`; for a
+  reuse lane, do not report `createIntent:true`.
+- `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.
+- `campaignBriefReceipt`: the CampaignOffer/campaign id, current
+  workflowTableId, brief hash or updated-at marker, delivery format, token
+  rules, hard avoids, source-use rules, and first-message template state.
+- `sourceDecisionReceipt`: selected source/list id, provider, cursor/inventory
+  state, import/copy caps, explicit `dedupeDncProviderExclusions:true` or an
+  equivalent exclusions object, row ids or row-count evidence (`rowCount`,
+  `readyRowCount`, or `rowEvidence`), and the reason no colder source was used
+  before the current source was proven exhausted or insufficient.
+- `filterDecisionReceipt`: saved/applied filter ids or explicit skip-filter
+  decision with current campaign/table basis.
+- `messageDraftingReceipt`: the Message Drafting proof described below,
+  including packaged `generate-messages` prompt/assets and validation.
+- `reviewBatchReceipt`: review-batch row ids/hash, generated row count,
+  quality-valid route-proof row id when approved, and proof that no broad
+  approve-all occurred.
+- `sequenceReceipt`: exact current workflowTableId, recommended non-paid
+  sequence attach/precheck result, and readback showing `hasSequence:true` when
+  completion is claimed.
+- final paused-send proof: if the current campaign table is `DRAFT` after the
+  sequence is attached, call the product `pause_campaign({ campaignId })`
+  endpoint/tool to put the unlaunched campaign into `PAUSED` review state, then
+  reread the campaign/table. Do not raw-write `campaignStatus`, do not start or
+  launch, and do not schedule/send. Completion requires reread proof of
+  `currentStep:"send"` and `campaignStatus:"PAUSED"`.
+- `verifyCall`: the exact `setup_evergreen_campaigns({ mode:"verify",
+  planRevision, selectedActionIds, receipts })` call/result used before the
+  parent reports completion.
+
+Use these canonical receipt leaf names exactly. Do not substitute looser aliases
+like `generateMessagesPromptLoad`, `requiredAssetLoads`,
+`validationPromptLoad`, `reviewBatchBasisHash`, `reviewRowIds`,
+`sequenceActionTypes`, or `pass:true` unless you also include the canonical
+fields below:
+
+The receipt status must be `status:"succeeded"` or `status:"completed"` when
+the lane is complete. Do not use `status:"passed"` or
+`status:"passed_with_warnings"` as the primary success status. Warnings may go
+in a separate `warnings` array, but the completion status stays canonical.
+
+All step proof objects must live under `createCampaignStepReceipt`. Do not put
+`campaignBriefReceipt`, `sourceDecisionReceipt`, `filterDecisionReceipt`,
+`messageDraftingReceipt`, `reviewBatchReceipt`, or `sequenceReceipt` only as
+top-level siblings; top-level copies are useful for humans but are not enough
+for command verification unless the same object also appears inside
+`createCampaignStepReceipt`.
+
+```json
+{
+  "status": "succeeded",
+  "planRevision": "<original planRevision>",
+  "laneKey": "<lane key>",
+  "laneType": "<lane type>",
+  "workspaceId": "<workspace id>",
+  "senderIds": ["<sender id>"],
+  "campaignId": "<campaign id>",
+  "tableId": "<workflow table id>",
+  "createCampaignStepReceipt": {
+    "campaignBriefReceipt": {
+      "campaignId": "<campaign id>",
+      "workflowTableId": "<workflow table id>",
+      "briefHash": "<brief/currentApprovedBriefHash>",
+      "deliveryFormat": "single message",
+      "tokenRules": true,
+      "hardAvoids": true,
+      "sourceUseRules": true,
+      "firstMessageTemplate": "<template or template state>"
+    },
+    "sourceDecisionReceipt": {
+      "sourceId": "<source id>",
+      "sourceListId": "<source/list id>",
+      "cursorOrInventoryState": "<cursor/inventory/import state>",
+      "dedupeDncProviderExclusions": true,
+      "sourceLadderReason": "<why the current source is valid before colder sources>"
+    },
+    "filterDecisionReceipt": {
+      "status": "skipped",
+      "workflowTableId": "<workflow table id>"
+    },
+    "messageDraftingReceipt": {
+      "statusSource": "branch",
+      "promptLoadedToHasMoreFalse": true,
+      "requiredAssetsLoaded": true,
+      "validationLoaded": true,
+      "validationResult": "passed",
+      "qualityReview": {"passed": true, "checkedSampleCount": 3, "issues": []},
+      "campaignId": "<campaign id>",
+      "workflowTableId": "<workflow table id>",
+      "selectedLeadListId": "<source/list id>",
+      "reviewBatchRowHash": "<review row ids hash>",
+      "messageDraftRecommendation": {"basis": "generate-messages"},
+      "sampleMessages[].verdict": "pass",
+      "sampleMessages": [
+        {"rowId": "<row id>", "generatedMessageText": "<message>", "verdict": "pass"}
+      ]
+    },
+    "reviewBatchReceipt": {
+      "rowIdsHash": "<review row ids hash>",
+      "generatedCount": 3
+    },
+    "sequenceReceipt": {
+      "workflowTableId": "<workflow table id>",
+      "hasSequence": true,
+      "sequenceReceipt.actionTypes": ["send_invite"],
+      "sequenceReceipt.nonPaid": true,
+      "actionTypes": ["send_invite"],
+      "nonPaid": true
+    },
+    "finalPausedSendProof": {
+      "currentStep": "send",
+      "campaignStatus": "PAUSED"
+    },
+    "verifyCall": {
+      "mode": "verify",
+      "planRevision": "<original planRevision>",
+      "selectedActionIds": ["<all original selected action ids>"]
+    }
+  }
+}
+```
+
+Verification always uses the original execution planRevision and original
+selectedActionIds from the plan packets that were dispatched before mutation.
+The parent must preserve the original selectedActionIds exactly.
+Do not replace them with a later reuse planRevision/actionIds after the
+campaigns exist. After workers complete, attach or patch `verifyCall` on each
+lane receipt with that original execution planRevision, original
+selectedActionIds, same sender scopes, and the verify result. Only after verify
+succeeds should the parent perform the idempotency rerun.
+
+If any required field is missing, report
+`blocked: missing_create_campaign_step_receipt` for that lane and do not call it
+complete.
+
+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** 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.
+4. Poll `get_campaign_message_preparation_status` until no queued/active cells
+   remain or a bounded stop reason is returned.
+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.
+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 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.
+
+One lane may produce exactly one CampaignOffer/campaign id and one current
+workflow table id. For `intent:"create"`, the first successful
+`create_campaign` result establishes the lane's only allowed campaign/table
+target. Every later source/import/confirm/message/filter/sequence/readback call
+must use that same campaign id and current workflow table id. If any tool
+returns or creates a different CampaignOffer, workflow table, "Campaign from
+Source" campaign, or shell for the same lane, stop immediately with
+`blocked: duplicate_campaign_offer_created`, include both ids in the receipt,
+and do not report completion. Do not hide the earlier shell by reporting only
+the later imported campaign.
+
+Each customer-visible lane receipt must also include message proof from
+`watchNarration.workerDetails.messageDraftBuilder`, the worker's equivalent
+branch handoff record, or the packaged message-prep worker path above. Valid
+evergreen message proof names the current campaign id, workflowTableId,
+selected lead-list or source id, filter choice, and review-batch row ids/hash,
+and it must use `statusSource:"branch"` or
+`statusSource:"packaged-generate-messages-worker"`.
+`statusSource:"parent-thread-fallback"` is not accepted for evergreen
+customer-visible completion because it can be a parent summary rather than proof
+that the create-campaign Message Drafting branch actually ran. The proof must
+show 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 receipt must also include `validationResult:"passed"`, a passed
+quality-review object, and at least 3 concrete reviewed sample messages with
+row ids, generated message text, pass verdicts, and no issues. Shared Cold
+Fallback samples must not open with a standalone name line followed by
+"Hey there" or another generic greeting; that pattern means the lane did not
+finish the create-campaign message workflow to customer quality.
+Shared Signal Discovery samples must not use sender-owned post-engager language
+such as "my post", "thanks for showing support", "saw you pop up", or any copy
+that implies the sending sender authored the source post or personally received
+the prospect's engagement unless the selected source evidence proves that exact
+sender authored the post.
+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", postEngagerSenderIds,
+sharedSenderIds, planRevision, selectedActionIds, receipts })` using the same
+sender scopes as the plan call and the original execution planRevision/actionIds,
+and reports only verified completion. A verify call without the same sender scopes can recompute an empty or different plan and is invalid proof. A verify call that uses a later reuse planRevision instead of the original execution planRevision is also invalid proof. Only after verify succeeds, rerun
+`setup_evergreen_campaigns({ mode:"plan", postEngagerSenderIds,
+sharedSenderIds, yolo:true })` without explicit campaign/table bindings. That
+idempotency rerun must return `intent:"reuse"` for every completed lane and no
+duplicate-lane blockers before you call the command finished. If verify blocks,
+report the blocker and repair only the missing postconditions from the same
+current plan.
+
+Message proof for every customer-visible lane must come from the current
+campaign/table basis and include at least 3 generated review rows from the
+packaged `generate-messages` path before completion is reported.
+Parent-thread handwritten copy or setting `currentStep` is not proof.
+</command_backed_workflow>
+
 <objective>
 1. **Inventory first**: `get_campaigns` + `list_tables` + `get_campaign_waterfall` in the active workspace. Treat `list_tables` and the managed waterfall as authoritative for older managed slots; `get_campaigns` is a recent campaign page and may miss canonical evergreen lanes. Match existing campaigns/tables/waterfall slots to the plan by name (case-insensitive, ignore suffixes like "(Copy)") and stored slot identity. `list_tables.campaignStatus` and `list_tables.dashboardBucket` are part of the identity check: a matching `ARCHIVED` table/campaign is not a plain `REUSE`. If it is the canonical prod slot and the invocation explicitly allows dashboard visibility repair, repair it to `PAUSED`; otherwise mark it `flagged`/`blocked` and do not create a duplicate. A matching non-archived campaign/table/waterfall slot = REUSE; record it and move on. Never create a second campaign for a slot that already has one in any of those inventories.
-2. **Create only the missing slots** with `create_on_demand_campaign({ name, senderIds, campaignBrief })`:
+2. **Create only the missing slots** through the full `$sellable:create-campaign`
+   workflow path for each lane, using the lane packet as the setup basis:
    - Post Engagers lanes: that sender's ID only. Shared lanes: all the senders' IDs.
-   - The brief must include the warm post-engager first-message template style — short, casual, references the post they engaged with, closed question, **no internal vocabulary, no pitch, no meeting ask** in message one:
+   - The brief and message direction are lane-specific. Never reuse the Post
+     Engagers opening for Shared Cold Fallback.
+   - **Post Engagers** first-message style: short, casual, references the
+     sender-authored post they engaged with, closed question, **no internal
+     vocabulary, no pitch, no meeting ask** in message one:
 
      ```
      {{first_name}}
@@ -65,6 +422,33 @@ Default evergreen plan per workspace (override only if the prompt specifies diff
      Saw you pop up on my post about {{post_topic_line}}
      ```
 
+   - **Shared Signal Discovery** first-message style: short, casual, references
+     the real observed signal/theme or public conversation. It may mention the
+     engagement source only when the source evidence supports it. Do not say
+     "my post" unless the selected source post was actually authored by the
+     sending sender. Do not thank the prospect for showing support, reacting,
+     commenting, or popping up unless this is a sender-owned Post Engagers lane
+     with sender-authored source evidence.
+   - **Shared Cold Fallback** first-message style: cold, direct, and cohesive.
+     It must not pretend there was engagement, must not say "saw you pop up",
+     and must not use a standalone name line followed by "Hey there" or other
+     generic greeting. It should open with a light role/company/problem
+     observation, avoid awkward phrases like "looks like a team where", and ask
+     one clear problem question. This is a single-message
+     cold path unless the approved create-campaign message workflow proves a
+     better delivery format.
+   - Every customer-visible lane must run Message Drafting from the current
+     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.
      - **InMail lanes can never be multiline**: an InMail is one message and the recipient must reply before anything else can be sent. InMail-bound templates must read as one cohesive message — declare `Delivery format: single message (InMail — no follow-up until reply)` and never structure the copy to depend on multi-message pacing.
@@ -90,26 +474,73 @@ Default evergreen plan per workspace (override only if the prompt specifies diff
    - 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
+     `workerDetails.messageDraftBuilder` with `statusSource:"branch"` or
+     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. 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
+     greeting.
    - 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.
-   - No scheduled, queued outbound, sent outbound, campaign launch, or paid
-     InMail spend is created by this skill.
+    - 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.
+    - If the current campaign table is still `DRAFT` after sequence/readiness
+      proof, call `pause_campaign({ campaignId })` and reread. `pause_campaign`
+      is the product-native review-state transition; it is not a launch and does
+      not schedule or send. Never raw-write campaign status.
+    - 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

package/skills/refill-sends/SKILL.md

@@ -9,6 +9,9 @@ allowed-tools:
   - mcp__sellable__get_campaign_refill_state
   - mcp__sellable__fill_campaign_horizon
   - mcp__sellable__get_campaign
+  - mcp__sellable__get_campaign_context
+  - mcp__sellable__update_campaign
+  - mcp__sellable__get_provider_prompt
   - mcp__sellable__get_campaign_message_preparation_status
   - mcp__sellable__start_campaign_message_preparation
   - mcp__sellable__cancel_campaign_message_preparation
@@ -16,6 +19,7 @@ allowed-tools:
   - mcp__sellable__wait_for_lead_list_ready
   - mcp__sellable__confirm_lead_list
   - mcp__sellable__search_signals
+  - mcp__sellable__select_promising_posts
   - mcp__sellable__fetch_post_engagers
   - mcp__sellable__search_sales_nav
   - mcp__sellable__lookup_sales_nav_filter
@@ -29,6 +33,10 @@ allowed-tools:
   - mcp__sellable__get_rows
   - mcp__sellable__get_rows_minimal
   - mcp__sellable__get_table_rows
+  - mcp__sellable__get_campaign_table_schema
+  - mcp__sellable__select_campaign_cells
+  - mcp__sellable__wait_for_campaign_processing
+  - mcp__sellable__get_sender
 ---
 
 # Refill Sends

package/skills/refill-sends-workflow/SKILL.md

@@ -7,6 +7,9 @@ allowed-tools:
   - mcp__sellable__get_campaign_refill_state
   - mcp__sellable__fill_campaign_horizon
   - mcp__sellable__get_campaign
+  - mcp__sellable__get_campaign_context
+  - mcp__sellable__update_campaign
+  - mcp__sellable__get_provider_prompt
   - mcp__sellable__get_campaign_message_preparation_status
   - mcp__sellable__start_campaign_message_preparation
   - mcp__sellable__cancel_campaign_message_preparation
@@ -14,6 +17,7 @@ allowed-tools:
   - mcp__sellable__wait_for_lead_list_ready
   - mcp__sellable__confirm_lead_list
   - mcp__sellable__search_signals
+  - mcp__sellable__select_promising_posts
   - mcp__sellable__fetch_post_engagers
   - mcp__sellable__search_sales_nav
   - mcp__sellable__lookup_sales_nav_filter
@@ -27,6 +31,10 @@ allowed-tools:
   - mcp__sellable__get_rows
   - mcp__sellable__get_rows_minimal
   - mcp__sellable__get_table_rows
+  - mcp__sellable__get_campaign_table_schema
+  - mcp__sellable__select_campaign_cells
+  - mcp__sellable__wait_for_campaign_processing
+  - mcp__sellable__get_sender
 ---
 
 # Refill Sends Workflow
@@ -101,6 +109,42 @@ Source replenishment choices:
   source prospects into the same campaign/source-list path, then confirm
   readiness.
 
+### Running Campaign Signal Discovery Recovery
+
+For an already-running regular campaign that needs same-campaign Signal
+Discovery replenishment, treat the watch/current-step transition as a guarded
+repair, not as normal create-campaign navigation.
+
+Do not call `search_signals` with `currentStep:"signal-discovery"` directly from `currentStep:"running"`. The campaign step guard intentionally rejects that
+backwards transition. After exact approval and a fresh refill-state reread, clear `currentStep` only if it still exactly matches `running`:
+
+```text
+update_campaign({ campaignId, currentStep:null, clearCurrentStepIfMatches:"running" })
+```
+
+Then register provider preflight and run a campaign-scoped `search_signals` so
+post rows exist in the campaign's Signal Discovery state:
+
+```text
+get_provider_prompt({ provider:"signal-discovery", campaignOfferId, confirmed:true })
+search_signals({ campaignOfferId, currentStep:"signal-discovery", confirmed:true, ... })
+```
+
+Use `select_promising_posts` before importing. For a fresh source refill, prefer
+`selectionMode:"replace"` and `scrapePlanMode:"capacity-target"` with the
+approved `targetEngagerCount` and `maxPostsToScrape`. If the approved post set cannot cover the target, do not knowingly run an under-capacity scrape; ask for approval to expand the selected post set or switch source.
+
+If `import_leads` returns `reusedExistingSourceList` but the user explicitly
+approved a different selected-post scrape, retry `import_leads` with the existing `sourceLeadListId` from that response or from refill state. For Signal
+Discovery this bypasses the stale reuse guard and materializes the newly
+selected campaign-scoped posts into a fresh source list.
+
+After `wait_for_lead_list_ready`, call `confirm_lead_list` with the new
+source-list id and same campaign id. Pass `currentStep:"running"` to `confirm_lead_list` for an ACTIVE already-running campaign so the watched state
+returns to Running after same-campaign source rows are copied. Do not call
+`update_campaign` to fake this after the copy; `confirm_lead_list` owns the
+post-copy state transition.
+
 Before any source mutation, show exact approval evidence: workspace id,
 campaign id, workflow table id, source/provider id, source-list id when known,
 import caps, target dates/caps, dedupe/DNC/provider exclusion expectations, and
@@ -135,11 +179,28 @@ Before prep or approval mutation, reread `get_campaign_refill_state` and compare
 If they changed, stop. A second concurrent refill run must see the first run's
 import/prep state on reread and avoid duplicate work.
 
+After same-campaign source copy, inspect the actual campaign-table position of
+the copied rows before starting prep. Newly copied rows often land after the first 100 table rows. Use `get_campaign_table_schema` to read the `reviewBatch`,
+then use `select_campaign_cells` diagnostics against
+`rowSelector:{ type:"reviewBatch" }` for `enrich`, `generateMessage`, and
+`approved` roles when needed.
+
+If review-batch enrich cells are pending or Generate Message cells are
+dependency-blocked, omit `maxRowsToCheck` so the adaptive prep job can cover the
+bounded table scan, or set a bounded cap high enough to include appended rows
+when row count evidence requires it. Do not run a fixed `maxRowsToCheck:100` prep pass after appending rows to a larger existing campaign table; it can spend
+the whole budget on older rows and miss the refill batch.
+
 Scheduled success requires a post-action reread proving scheduler-owned cells
 with non-null `scheduledFor`. Prepared, approved, and ready-to-schedule rows are
 intermediate states; report them as awaiting scheduler unless scheduled cells
 are present.
 
+preparedMessages can remain 0 while scheduler-ready state changes downstream.
+After a prep job reaches a terminal state, run `wait_for_campaign_processing`
+when generated/pass counts are still settling, then poll `get_campaign_refill_state` until `readyToSchedule` drops, scheduled counts increase, or the state clearly
+remains awaiting scheduler. Do not force scheduler fields directly.
+
 ## Evergreen Campaign Discipline
 
 `fill_campaign_horizon` is a legacy evergreen-only lower-level primitive. Call it