@sellable/mcp 0.1.738 → 0.1.740

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

@@ -172,6 +172,21 @@ type SchedulerRefusalDisposition = {
 };
 declare function classifySchedulerRefusal(reason: string | null): SchedulerRefusalDisposition;
 declare function schedulerSweepNoOpBlocker(ctx: LoopContext, reportInput: Record<string, unknown>): Record<string, unknown> | null;
+declare function coverageOnlySignature(plan: Record<string, unknown>): {
+    sent: number;
+    scheduled: number;
+    ready: number;
+    goal: number;
+};
+declare function nextCoverageStallState(ctx: LoopContext, plan: Record<string, unknown>): {
+    signature: {
+        sent: number;
+        scheduled: number;
+        ready: number;
+        goal: number;
+    };
+    repeatCount: number;
+};
 export declare function packetCoherenceFailure(plan: Record<string, unknown>): string | null;
 export declare function terminalProjection(value: {
     targetConfig?: unknown;
@@ -190,5 +205,8 @@ export declare const refillRunLoopInternals: {
     schedulerSweepNoOpBlocker: typeof schedulerSweepNoOpBlocker;
     dominantSchedulerRefusalReason: typeof dominantSchedulerRefusalReason;
     classifySchedulerRefusal: typeof classifySchedulerRefusal;
+    coverageOnlySignature: typeof coverageOnlySignature;
+    nextCoverageStallState: typeof nextCoverageStallState;
+    COVERAGE_STALL_LIMIT: number;
 };
 export {};

package/dist/refill-run-loop.js

@@ -1864,6 +1864,46 @@ function nextNoProgressState(ctx, plan, action) {
         repeatCount,
     };
 }
+// fix(112an, UNIVERSAL progress-or-settle): 112aj's bound keys on
+// noProgressSignature, which includes actionFingerprint (type:campaign:table:
+// sender:actionKey:effectId). A loop that re-plans a DIFFERENT action each
+// iteration therefore resets the counter and never trips it, no matter how many
+// iterations produce zero coverage movement. Both expensive livelocks we hit
+// had exactly that shape:
+//   - Dotwork s3: 136 refill_sends calls, 21 exact_action_complete, coverage
+//     frozen at {sent:0, scheduled:0, ready:20, goal:50} throughout.
+//   - sellable FINAL: 6 of 7 exact runs returned byte-identical coverage
+//     {goal:180, ready:5, scheduled:9, sent:0}, each under a distinct
+//     next_exact_target, so 112aj saw six "different" actions.
+// This is the coverage-only companion: it ignores WHICH action ran and asks
+// only whether the world moved. A command that cannot move sent/scheduled/ready
+// across COVERAGE_STALL_LIMIT consecutive iterations is burning wall-clock and
+// credits for nothing and must settle with an honest terminal naming the frozen
+// counters and the last action it attempted.
+//
+// Threshold is deliberately looser than 112aj's 3: distinct actions legitimately
+// run in sequence before coverage moves (prepare -> approve -> sweep), so a tight
+// cap would cut off real ladders. Six is above the longest legitimate
+// zero-movement prefix observed across the 8-workspace matrix (the healthy rows
+// settle in 0-20 calls; only true stalls exceed it).
+const COVERAGE_STALL_LIMIT = 6;
+function coverageOnlySignature(plan) {
+    const coverage = coverageSnapshot(plan);
+    return {
+        sent: coverage.sent,
+        scheduled: coverage.scheduled,
+        ready: coverage.ready,
+        goal: coverage.goal,
+    };
+}
+function nextCoverageStallState(ctx, plan) {
+    const next = coverageOnlySignature(plan);
+    const prior = recordValue(runStateProgress(ctx).coverageStall) ?? {};
+    const priorSignature = recordValue(prior.signature);
+    const same = priorSignature !== undefined && safeJson(priorSignature) === safeJson(next);
+    const repeatCount = same ? (numberValue(prior.repeatCount) ?? 1) + 1 : 1;
+    return { signature: next, repeatCount };
+}
 function sourceHandoffText(action) {
     const campaignId = actionCampaignId(action) ?? "campaign";
     const toolInput = actionToolInput(action);
@@ -2601,6 +2641,11 @@ async function gatePlan(input, deps, ctx) {
         fallbackSummary: line.fallbackSummary,
     }));
     const fingerprint = fingerprintFromPlan(plan);
+    // fix(112an): universal coverage-only bound. Evaluated BEFORE 112aj's
+    // action-scoped bound only for its counter update, but enforced AFTER it so
+    // the more specific typed terminals (broaden keyword handoff, etc.) keep
+    // precedence when they apply. See COVERAGE_STALL_LIMIT.
+    const coverageStall = nextCoverageStallState(ctx, plan);
     const noProgress = nextNoProgressState(ctx, plan, action);
     if (noProgress.repeatCount >= 3) {
         // fix(111y, CloverL): when the stuck rung is a broaden whose derived tier
@@ -2665,14 +2710,33 @@ async function gatePlan(input, deps, ctx) {
             blocker: "no_forward_progress",
             stuckRung: stringValue(action.evergreenRung) ?? stringValue(action.type),
             repeatedHeadAction: action,
-            progress: { noProgress },
+            progress: { noProgress, coverageStall },
             guidance: "The same refill rung repeated three times with no coverage, frontier, or lane movement.",
         });
     }
+    // fix(112an): universal bound — the world did not move for
+    // COVERAGE_STALL_LIMIT consecutive iterations, regardless of which action ran
+    // each time. Settle with an honest terminal naming the frozen counters rather
+    // than burning further wall-clock and credits on a command that cannot advance.
+    if (coverageStall.repeatCount >= COVERAGE_STALL_LIMIT) {
+        const frozen = coverageStall.signature;
+        return completeTerminal(input, deps, ctx, "blocked", {
+            blocker: "no_coverage_movement",
+            stuckRung: stringValue(action.evergreenRung) ?? stringValue(action.type),
+            repeatedHeadAction: action,
+            progress: { coverageStall },
+            coverage: frozen,
+            guidance: `Coverage did not move across ${COVERAGE_STALL_LIMIT} consecutive refill iterations ` +
+                `(sent ${frozen.sent}, scheduled ${frozen.scheduled}, ready ${frozen.ready}, ` +
+                `goal ${frozen.goal}); the actions differed each time, so this is a workspace-level ` +
+                "stall rather than one repeated rung. Settling instead of continuing to spend. " +
+                "Re-run after the underlying blocker changes; the last attempted action is reported above.",
+        });
+    }
     const nextRunState = mergeRunState(ctx.runState, {
         lastPlan: fingerprint,
         headAction: action,
-        progress: mergeProgress(ctx, { noProgress }),
+        progress: mergeProgress(ctx, { noProgress, coverageStall }),
     });
     const advanced = await deps.runClient.advanceRefillRunGateRemote({
         workspaceId: input.workspaceId,
@@ -4826,4 +4890,7 @@ export const refillRunLoopInternals = {
     schedulerSweepNoOpBlocker,
     dominantSchedulerRefusalReason,
     classifySchedulerRefusal,
+    coverageOnlySignature,
+    nextCoverageStallState,
+    COVERAGE_STALL_LIMIT,
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.738",
+  "version": "0.1.740",
   "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, `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.
+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, `maxPosts` to refresh a specific number of posts, and maximum engager pages per tracked post.
+
+Leave `maxPosts` unset unless the user asked for a specific number. By default the command refreshes every tracked post published inside the 30-day lookback window, which is what keeps recent posts checked often enough to catch new engagers. A post whose engagement counts have not moved costs a single cheap count probe and is skipped before any engager fetch, so a wider sweep is not a proportionally more expensive one. Passing `maxPosts` narrows that sweep.
 
 `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>
@@ -84,7 +86,7 @@ For each target sender/campaign:
 - LinkedIn operations here are read-only fetches plus a typed product import into a campaign table. **No messages are generated, approved, scheduled, or sent by this skill.**
 - Respect workspace boundaries: only add leads to campaigns in the active workspace, and only for senders that belong to it.
 - Respect campaign boundaries: only add engagers to the matched sender-owned Post Engagers campaign/table. Do not mix shared-lane engagers into sender-owned campaigns or sender-owned engagers into shared lanes.
-- Cap provider usage per run: at most 5 posts × `fetch_post_engagers` per sender. If the invoking automation wants more, it must say so explicitly.
+- Provider usage per run is bounded by the 30-day lookback window plus the count-probe short-circuit: unchanged posts cost one probe and fetch no engagers. Do not widen `maxEngagerPages` beyond what the user asked for.
 - Never call `start_campaign`, `attach_sequence`, `queue_campaign_cells`, `start_campaign_message_preparation`, approval tools, send/schedule tools, or shared-lane mutation tools.
 - Never create campaigns, change campaign status, change sender ownership, approve campaign cells, or start message prep as part of this refresh.
 </safety>