@sellable/mcp 0.1.736 → 0.1.738

package/dist/refill-run-loop.d.ts

@@ -166,6 +166,11 @@ declare function dominantSchedulerRefusalReason(receipt: Record<string, unknown>
     reason: string;
     count: number;
 } | null;
+type SchedulerRefusalDisposition = {
+    retryable: boolean | null;
+    blockerClass: "transient_or_refreshable" | "time_bound_capacity" | "operator_action_required" | "unknown";
+};
+declare function classifySchedulerRefusal(reason: string | null): SchedulerRefusalDisposition;
 declare function schedulerSweepNoOpBlocker(ctx: LoopContext, reportInput: Record<string, unknown>): Record<string, unknown> | null;
 export declare function packetCoherenceFailure(plan: Record<string, unknown>): string | null;
 export declare function terminalProjection(value: {
@@ -184,5 +189,6 @@ export declare function runRefillV2Loop(input: RefillV2LoopInput, deps: RefillV2
 export declare const refillRunLoopInternals: {
     schedulerSweepNoOpBlocker: typeof schedulerSweepNoOpBlocker;
     dominantSchedulerRefusalReason: typeof dominantSchedulerRefusalReason;
+    classifySchedulerRefusal: typeof classifySchedulerRefusal;
 };
 export {};

package/dist/refill-run-loop.js

@@ -432,6 +432,24 @@ function dominantSchedulerRefusalReason(receipt) {
     }
     return null;
 }
+function classifySchedulerRefusal(reason) {
+    if (!reason)
+        return { retryable: null, blockerClass: "unknown" };
+    // Infrastructure or freshness failures: the underlying facts can be re-read
+    // and the same sweep can then succeed without anyone changing configuration.
+    if (/(pool|timeout|timed[_ -]?out|connection|transient|unavailable|receipt[_ -]?invalid|stale|refresh)/i.test(reason)) {
+        return { retryable: true, blockerClass: "transient_or_refreshable" };
+    }
+    // Time-bound capacity: nothing is broken, the slot simply is not open yet.
+    if (/(window|capacity|daily[_ -]?limit|cooldown|rate[_ -]?limit)/i.test(reason)) {
+        return { retryable: true, blockerClass: "time_bound_capacity" };
+    }
+    // Standing gates: re-running cannot clear these; a human must act.
+    if (/(billing|credit[_ -]?threshold|disconnected|sender[_ -]?mismatch|not[_ -]?scheduler[_ -]?eligible|suspended|unauthor)/i.test(reason)) {
+        return { retryable: false, blockerClass: "operator_action_required" };
+    }
+    return { retryable: null, blockerClass: "unknown" };
+}
 // fix(112al): a sweep whose own receipt proves it placed zero while ready
 // inventory existed. Gated on the executed action actually being a scheduler
 // sweep and on a FRESH terminal receipt (ran / window_closed_noop), so an
@@ -461,8 +479,9 @@ function schedulerSweepNoOpBlocker(ctx, reportInput) {
                 dominantReason: dominant.reason,
                 dominantReasonSource: dominant.source,
                 dominantReasonCount: dominant.count,
+                ...classifySchedulerRefusal(dominant.reason),
             }
-            : {}),
+            : classifySchedulerRefusal(null)),
         ...(stringValue(receipt?.nextAction)
             ? { recommendedAction: stringValue(receipt?.nextAction) }
             : {}),
@@ -4806,4 +4825,5 @@ export async function runRefillV2Loop(input, deps) {
 export const refillRunLoopInternals = {
     schedulerSweepNoOpBlocker,
     dominantSchedulerRefusalReason,
+    classifySchedulerRefusal,
 };

package/dist/tools/refresh-sender-engagement.js

@@ -22,7 +22,7 @@ export const refreshSenderEngagementToolDefinitions = [
                 },
                 campaignId: {
                     type: "string",
-                    description: "Optional exact sender-owned Post Engagers campaign id. Enables the same safe refresh path for a campaign-derived waterfall without requiring managed evergreen configuration.",
+                    description: "Optional exact sender-owned Post Engagers campaign id. Omit it and the command discovers the sender's Post Engagers campaign itself, so managed evergreen configuration is not required; pass it only to pin one exact campaign. When the sender owns several lanes, the response reports the rest under discovery.additionalCandidates — refresh each by repeating the call with that campaignId.",
                 },
                 tableId: {
                     type: "string",

package/package.json

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

package/skills/refresh-sender-engagement/SKILL.md

@@ -33,7 +33,9 @@ You are a pipeline supply agent. People who engage with a sender's LinkedIn post
 <inputs>
 The invoking prompt names the senders ("refresh sender engagement for csreyes92 and thomas"). Resolve each via `list_senders` (match name/handle/LinkedIn URL). With no names given, inspect the active workspace and refresh every connected sender that has an active/paused sender-owned Post Engagers campaign backed by Signal Discovery.
 
-Optional: target sender names/ids, `tableId` when the user wants to force a specific campaign table, maximum posts per sender (default 5, hard cap 5 unless the user explicitly asks for more), and maximum engager pages per tracked post.
+Optional: target sender names/ids, `campaignId` when the user wants to force a specific Post Engagers campaign, `tableId` when the user wants to force a specific campaign table, maximum posts per sender (default 5, hard cap 5 unless the user explicitly asks for more), and maximum engager pages per tracked post.
+
+`campaignId` is optional. When it is omitted the command discovers the sender's Post Engagers campaign itself — it searches the workspace for campaigns the sender solely owns that are backed by a post-engager provider and named as a Post Engagers lane. A workspace can hold one such lane per sender, so discovery is always scoped to the sender you are refreshing; another sender's lane and shared multi-sender lanes are never selected. Do not pass a `campaignId` you guessed.
 </inputs>
 
 <entrypoint>
@@ -58,9 +60,12 @@ For each target sender/campaign:
    - Resolve each target sender with `list_senders`/`get_sender`. Use the sender id returned by the product, not a guessed handle.
 2. **Use the typed product command first**:
    - Call `refresh_sender_engagement` in `mode:"dry_run"` for each sender.
-   - Always pass `workspaceId`, `senderId`, and any user-specified `tableId`, `maxPosts`, or `maxEngagerPages`.
+   - Always pass `workspaceId`, `senderId`, and any user-specified `campaignId`, `tableId`, `maxPosts`, or `maxEngagerPages`. Omitting `campaignId` is correct and normal — the command resolves the campaign itself.
+   - Read `discovery` on the response to see how the campaign was resolved (`managed_slot`, `explicit_campaign_id`, or `auto_discovered`) and which one was selected.
+   - If `discovery.additionalCandidates` is non-empty, that sender owns more than one Post Engagers lane. Refresh each one by repeating the dry-run/apply cycle with that candidate's `campaignId`. Every lane gets its own dry run and its own `dryRunFingerprint`; never reuse a fingerprint across campaigns.
    - Treat the dry-run response as the campaign/source boundary authority. It should identify the sender-owned Post Engagers slot, campaign, workflow table, source provider `campaign-tracked-post`, source table type `tracked_post_engager_source_list`, expected tracked posts, expected engager refresh/import work, and a `dryRunFingerprint`.
    - If the typed command reports no eligible sender-owned Post Engagers campaign, no tracked posts, no recent posts, or a workspace/sender mismatch, report that exact blocker and stop for that sender. Do not silently create campaigns or fall back to shared lanes.
+   - `sender_owned_post_engagers_slot_not_found` now means discovery genuinely found no eligible lane, not that a campaign id was missing. Report `discovery.campaignsInspected` alongside it, and describe it as missing campaign setup — never as "the sender has no posts", since no LinkedIn fetch happens before this point.
 3. **Gate writes with dry-run proof**:
    - Never call `refresh_sender_engagement` in `mode:"apply"` before a successful dry run from this same run.
    - For manual runs, show the target workspace, sender, campaign/table, source lead list, expected tracked posts, expected row/import impact, and `dryRunFingerprint`, then wait for explicit user approval before apply.

package/skills/research/config.json

@@ -0,0 +1,9 @@
+{
+  "parallelMode": "wide",
+  "agentCount": 6,
+  "maxToolCallsPerAgent": 2,
+  "senderMaxAgents": 2,
+  "senderMaxToolCallsPerAgent": 3,
+  "progressMode": true,
+  "debugMode": true
+}