@sellable/mcp 0.1.475 → 0.1.477

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

@@ -86,9 +86,9 @@ 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.
+`attach_sequence` on the current workflowTableId with the same product template
+the backend would select; do not substitute the manual Paid InMail Campaign and
+never repair a table other than the current workflowTableId.
 
 Hard gates — if you find yourself about to violate any of these, stop
 first:
@@ -533,10 +533,12 @@ Shape:
    route and describe the Sequence view.
 8. Call `attach_recommended_sequence({ campaignId, currentStep: "send" })`
    (bind the tier-recommended sequence to the campaign). Explain the sequence
-   choice plainly: Sales Nav/Recruiter senders get the Sales Nav Open Profile
-   strategy, Basic/Premium/mixed senders get the Premium invite-to-DM strategy,
-   and Paid InMail Campaign is available only as an explicit paid-InMail
-   opt-in because it can spend InMail credits. If the tool response
+   choice plainly: Sales Nav/Recruiter senders get the unified Sales Nav
+   cascade (Open Profile -> Open InMail, otherwise fresh paid credits >= 5 ->
+   paid InMail, otherwise connection request -> accepted wait -> DM), while
+   Basic/Premium/mixed senders get the Premium invite-to-DM strategy. The manual
+   Paid InMail Campaign remains an explicit custom template, not the normal
+   recommended path. 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
@@ -544,9 +546,10 @@ Shape:
    `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.
+   `attach_sequence` using the same product template the recommended selector
+   would have chosen, or stop and report the stale-shell sequence blocker if
+   replacement was not explicitly approved. Do not substitute the manual Paid
+   InMail Campaign for this repair.
 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

@@ -1515,7 +1515,11 @@ Message, and verify current-revision sample messages before final completion.
      - 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.
 
-   - The sequence is auto-selected by sender tier; do not hand-author sequence templates here. Never select a paid-InMail template.
+   - The sequence is auto-selected by sender tier; do not hand-author sequence
+     templates here. Sales Nav/Recruiter senders may receive the unified Sales
+     Nav cascade through `attach_recommended_sequence`; attaching it does not
+     spend paid InMail credits by itself. Do not substitute the manual Paid
+     InMail Campaign template.
 3. **Customer-Visible Completion Contract**: a named evergreen lane that appears
    as a campaign card or campaign-backed table is not done when the shell exists.
    It is done only when the customer can open the campaign and land on final
@@ -1592,7 +1596,7 @@ Message, and verify current-revision sample messages before final completion.
      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 to the current campaign
+    - The recommended tier-aware 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,
@@ -1602,10 +1606,11 @@ Message, and verify current-revision sample messages before final completion.
      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.
+     with `attach_sequence` using the same product template
+      `attach_recommended_sequence` would have selected. Do not substitute the
+      manual Paid InMail Campaign, 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

package/skills/refill-sends/SKILL.md

@@ -89,10 +89,16 @@ When the host can call typed MCP tools, start with:
 refill_sends({ yolo?: boolean, senders?: string[], senderIds?: string[], senderNames?: string[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD" })
 ```
 
-That command helper only normalizes arguments and returns the execution
-contract. It does not mutate. Continue with the workflow below for route
-selection, state rereads, approval gating, source import, preparation, and
-bounded approval.
+That command helper normalizes arguments and returns the execution contract. In
+non-yolo mode it does not mutate. In `--yolo`, it may execute exactly one safe
+bounded primitive from the fresh `target.globalActionQueue[0]`, then reread and
+return the new target plan; currently safe primitives are paid-credit refresh,
+existing-row message preparation, same-source row copy, and read-only wait
+rereads. It does not approve messages without the bounded approval gate, lower
+paid-InMail thresholds, switch source families, create campaigns, launch, send,
+or write scheduler rows. Continue with the workflow below for route selection,
+state rereads, approval gating, source import, preparation, and bounded
+approval.
 
 First call `get_auth_status({})`. If auth or active workspace is not OK, follow
 the returned login/workspace guidance before route resolution. Do not run refill
@@ -131,18 +137,21 @@ 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`. Refill target lanes
-are only connection invites (`send_invite`) or paid InMails
-(`send_inmail_closed`), chosen per sender from the most recent current
-dashboard-active campaign-backed send evidence. DMs (`send_dm`) and
-open-profile InMails (`send_inmail_open`) may exist in sequences, but they are
-not refill horizon target capacity and must not be counted as refill sent,
-scheduled, or ready coverage. When `actionTypes` are omitted, trust the target
-plan's inferred connection-or-paid-InMail lane rather than asking which of those
-two lanes to fill. If a stale target plan selects `send_dm` or
-`send_inmail_open`, stop and re-plan with the current planner before mutation.
-Short form: trust the target plan's inferred lane only when it is a
-connection-invite or paid-InMail refill lane.
+feasibility, `targetShapeRevision`, and `stateRevision`. Refill target lanes are
+connection invites (`send_invite`), standalone paid InMails
+(`send_inmail_closed`), or unified Sales Nav cascades represented publicly as
+`send_inmail_closed` with `campaignClassification:"sales_nav_cascade"`. For a
+Sales Nav cascade, refill the selected campaign first; its sequence can route
+prospects to Open InMail, paid InMail while fresh credits are >= 5, or
+same-campaign connection fallback without asking for separate open/paid/
+connection campaigns. DMs (`send_dm`) are follow-up actions, not refill horizon
+target capacity, and must not be counted as refill sent, scheduled, or ready
+coverage. When `actionTypes` are omitted, trust the target plan's inferred lane
+rather than asking which campaign class to fill. If a stale target plan selects
+`send_dm` or `send_inmail_open` as the lane, stop and re-plan with the current
+planner before mutation.
+Short form: trust the target plan's inferred lane when it is a connection invite,
+paid-InMail refill lane, or unified Sales Nav cascade.
 
 Structured planner packet:
 
@@ -161,14 +170,23 @@ Structured planner packet:
 - `manualAlternates` are not yolo actions. Threshold lowering and campaign
   creation are manual continuations only.
 
+Refill action ladder: approve generated rows only when an explicit bounded
+approval gate exists, process all existing same-campaign unenriched/unprepared
+rows in bounded batches before any source work, then copy bounded net-new rows
+from the selected source (`selectedLeadListId`, provider, and source
+fingerprint preserved), then use provider-aligned source-more. A new source or
+provider switch changes the reply-rate baseline and is a manual alternate, not a
+`--yolo` side effect.
+
 Run-local paid-credit guard: in `--yolo`, the `refill_sends` MCP command
 automatically maintains a `refreshedPaidInmailSenderIds` set for the current
 command call. If its first target plan has stale/missing paid-InMail credit
 facts, it refreshes each selected sender at most once, reruns
 `get_refill_target_plan`, and returns the post-refresh `targetPlan` before
-choosing the next prep/approval/start action. If fresh facts are still below
+choosing the next prep/source-copy/read-only wait action. If fresh facts are still below
 threshold, below-threshold paid-InMail facts fall back to an existing connection
-lane or a manual continuation.
+lane, the same Sales Nav cascade campaign's connection branch, or a manual
+continuation.
 
 Compact refill lessons: sender-level target plan is final truth; trust
 `schedulerGate.sendable` and scheduler gate blockers, not raw
@@ -201,8 +219,8 @@ post-refresh `targetPlan`. Trust `refill_sends.autoPaidInmailRefresh`: it should
 show the exact sender ids refreshed once, sender-credit-cache write receipts,
 and a returned post-refresh `targetPlan`. Continue from that post-refresh packet.
 If paid InMail is below threshold after the fresh credit read, report the exact
-campaign/table/column threshold action or connection fallback; `--yolo` does not
-lower paid-InMail thresholds or create campaigns.
+campaign/table/column threshold action or same-campaign 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
@@ -254,7 +272,7 @@ 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
+apply/prep/source-copy/read-only wait result, reread state, settle processing when needed, and move to
 the next selected sender or start-eligible same-packet campaign instead of
 stopping after the first partial result. If no in-packet safe action remains,
 return concrete continuation options with campaign names, exact ids, which option
@@ -268,7 +286,7 @@ 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
+reduce the gap. After every apply/prep/source-copy/read-only wait result, wait for processing, reread
 the target plan/refill state, recompute the ledger, then keep applying safe
 bounded actions until projected coverage fills the target window or a concrete
 non-scheduler blocker is proven.

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

@@ -75,20 +75,23 @@ in-progress wait state, not a reason to mark the goal complete or blocked.
    campaigns, projected coverage (`sent + scheduled`), ready buffer, remaining
    projected gap, paid-InMail credit/threshold feasibility, bounded action
    candidates, `targetShapeRevision`, and `stateRevision`.
-   Refill target lanes are binary per sender: connection invites
-   (`send_invite`) or paid InMails (`send_inmail_closed`). DMs
-   (`send_dm`) and open-profile InMails (`send_inmail_open`) can remain in the
-   sequence, but they are follow-up actions, not refill horizon capacity. Do not
-   count their sent, scheduled, or ready cells when deciding whether a sender
-   needs refill. When `actionTypes` are omitted, trust the target plan's
-   inferred connection-or-paid-InMail lane; do not ask the operator which of
-   those two lanes to fill after the plan has inferred that from active
-   campaign future scheduled, recent scheduled, and ready evidence. If a stale
-   planner/tool response selects `send_dm` or `send_inmail_open`, treat that as
-   unsupported stale refill state and re-plan with a current planner before any
-   mutation.
-   Short form: trust the target plan's inferred lane only when it is a
-   connection-invite or paid-InMail refill lane.
+   Refill target lanes are connection invites (`send_invite`), standalone paid
+   InMails (`send_inmail_closed`), or unified Sales Nav cascades represented
+   publicly as `send_inmail_closed` with
+   `campaignClassification:"sales_nav_cascade"`. For a Sales Nav cascade, fill
+   the selected campaign first; its sequence can route prospects to Open InMail,
+   paid InMail while fresh credits are >= 5, or same-campaign connection
+   fallback without asking for separate open/paid/connection campaigns. DMs
+   (`send_dm`) are follow-up actions, not refill horizon capacity. Do not count
+   their sent, scheduled, or ready cells when deciding whether a sender needs
+   refill. When `actionTypes` are omitted, trust the target plan's inferred lane;
+   do not ask the operator which campaign class to fill after the plan has
+   inferred that from active campaign future scheduled, recent scheduled, and
+   ready evidence. If a stale planner/tool response selects `send_dm` or
+   `send_inmail_open`, treat that as unsupported stale refill state and re-plan
+   with a current planner before any mutation.
+   Short form: trust the target plan's inferred lane when it is a connection
+   invite, paid-InMail refill lane, or unified Sales Nav cascade.
    Structured planner packet:
    - `target.eligibleSenderLedger` is the public sender eligibility ledger.
    - `target.senderRefillPlans[]` is the canonical sender-level packet; read and
@@ -105,14 +108,22 @@ in-progress wait state, not a reason to mark the goal complete or blocked.
    - `nextActions[0]` is the current sender's smallest safe primitive.
    - `manualAlternates` are not yolo actions. Threshold lowering and campaign
      creation are manual continuations only.
+   Refill action ladder: approve generated rows only when an explicit bounded
+   approval gate exists, process all existing same-campaign
+   unenriched/unprepared rows in bounded batches before any source work, then
+   copy bounded net-new rows from the selected source (`selectedLeadListId`,
+   provider, and source fingerprint preserved), then use provider-aligned
+   source-more. A new source or provider switch changes the reply-rate baseline
+   and is a manual alternate, not a `--yolo` side effect.
    Run-local paid-credit guard: in `--yolo`, the `refill_sends` MCP command
    automatically maintains a `refreshedPaidInmailSenderIds` set for the current
    command call. If its first target plan has stale/missing paid-InMail credit
    facts, it refreshes each selected sender at most once, reruns
    `get_refill_target_plan`, and returns the post-refresh `targetPlan` before
-   choosing the next prep/approval/start action. If fresh facts are still below
+   choosing the next prep/source-copy/read-only wait action. If fresh facts are still below
    threshold, below-threshold paid-InMail facts fall back to an existing
-   connection lane or a manual continuation.
+   connection lane, the same Sales Nav cascade campaign's connection branch, or
+   a manual continuation.
    Compact refill lessons: sender-level target plan is final truth; trust
    `schedulerGate.sendable` and scheduler gate blockers, not raw
    `unipileAccountStatus` labels alone; use compact prep status checks for
@@ -147,7 +158,7 @@ in-progress wait state, not a reason to mark the goal complete or blocked.
    should show the exact sender ids refreshed once, sender-credit-cache write
    receipts, and a returned post-refresh `targetPlan`. Continue from that
    post-refresh packet. If paid InMail is below threshold after the fresh credit read, report
-   the exact campaign/table/column threshold action or
+   the exact campaign/table/column threshold action or same-campaign
    connection fallback; `--yolo` does not lower paid-InMail thresholds or create campaigns.
 2. Call `resolve_campaign_fill_route`. Use `intent:"plain"` for generic
    fill/load language, `intent:"active"` only when the user explicitly narrowed
@@ -282,10 +293,13 @@ dashboard-active campaign-backed sequence evidence:
 
 1. Prefer the sender's most recent future scheduled refill action, then the most
    recent recent scheduled refill action, then ready refill rows.
-2. Refill actions are only `send_invite` and `send_inmail_closed`.
-3. If the most recent active campaign evidence is DM or open InMail, ignore it
-   for refill lane selection and use the nearest connection-invite or paid-InMail
-   evidence instead.
+2. Refill actions are `send_invite` or `send_inmail_closed`; unified Sales Nav
+   cascades also appear as `send_inmail_closed` with
+   `campaignClassification:"sales_nav_cascade"`.
+3. If the most recent active campaign evidence is DM, ignore it for refill lane
+   selection. If open InMail evidence belongs to a unified Sales Nav cascade,
+   keep the cascade campaign as the selected `send_inmail_closed` target; do not
+   create side open/paid/connection campaigns.
 4. If no connection/paid-InMail evidence exists, fall back to the selected
    active campaign sequence, still choosing only one of `send_invite` or
    `send_inmail_closed` for that sender.
@@ -418,8 +432,15 @@ 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.
+`selectionMode:"replace"` and `scrapePlanMode:"all-selected"`, then call
+`import_leads` without `targetEngagerCount` or `maxPostsToScrape` so the scrape
+uses the selected posts' max available engagers within backend provider caps.
+Do not invent, lower, or pass a people-to-check target for refill imports unless
+Christian explicitly supplied that target or post cap in the current request or
+approval packet. If Christian did supply an explicit `targetEngagerCount` or
+`maxPostsToScrape`, use `scrapePlanMode:"capacity-target"` and respect the
+under-capacity refusal: ask for approval to expand the selected post set or
+switch source instead of scraping a target-mismatched set.
 
 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
@@ -538,7 +559,7 @@ same refill request, do not ask the `Accept` / `Decline` question. Instead:
    caps/dates, approval mode, blockers, and side-effect class still match the
    packet;
 4. execute only the exact packet;
-5. after each terminal credit-refresh/apply/prep/start result, rerun
+5. after each terminal credit-refresh/apply/prep/source-copy/read-only wait result, rerun
    `get_refill_target_plan`, reread state, settle processing when needed,
    recompute the target-window saturation ledger, and continue with the next smallest
    safe action inside the same bounded packet until every selected sender is

package/skills/workflow-sequences/SKILL.md

@@ -77,7 +77,7 @@ This is the canonical MCP workflow for creating sequencer tables. Prefer this ov
   - `INVITE` only
   - `INVITE -> accepted -> DM`
   - `COMMENT` only
-  - `If Open Profile -> INMAIL_OPEN, else INVITE`
+  - Sales Nav unified cascade: Open Profile -> Open InMail, otherwise paid-credit check -> Paid InMail or connection fallback
 
 ## Output