@sellable/mcp 0.1.737 → 0.1.739

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/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.737",
+  "version": "0.1.739",
   "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.