@sellable/mcp 0.1.739 → 0.1.741

package/dist/tools/refill-executors.d.ts

@@ -214,18 +214,21 @@ export type SchedulerChangedCounts = {
     }>;
 };
 export declare function normalizeSchedulerChangedCounts(value: unknown): SchedulerChangedCounts | null;
+export declare function schedulerEnvelopeIsTerminal(schedulerStatus: string): boolean;
 export declare function normalizeSchedulerPrimitiveResult(value: unknown, expected?: {
     expectedTargets: SchedulerExpectedTargetInput[];
     expectedTargetsHash: string;
     maxPlacements: number;
 }): {
+    retryAfterMs: number;
+    changedCounts: null;
+    auditComplete: false;
+    replayedReceipt?: Record<string, unknown> | undefined;
     status: "matching_scheduler_active";
     schedulerStatus: string;
+    terminal: false;
     disposition: "bounded_reread_wait";
     receipt: null;
-    retryAfterMs: number;
-    changedCounts: null;
-    auditComplete: false;
     blocker?: undefined;
 } | {
     status: string;
@@ -236,6 +239,7 @@ export declare function normalizeSchedulerPrimitiveResult(value: unknown, expect
     changedCounts: null;
     auditComplete: false;
     blocker: string;
+    terminal?: undefined;
 } | {
     status: "scheduler_receipt_incomplete";
     schedulerStatus: string;
@@ -245,8 +249,10 @@ export declare function normalizeSchedulerPrimitiveResult(value: unknown, expect
     auditComplete: false;
     blocker: "scheduler_receipt_incomplete";
     disposition?: undefined;
+    terminal?: undefined;
 } | {
     status: string;
+    terminal: boolean;
     receipt: {} | null;
     retryAfterMs: number | null;
     changedCounts: SchedulerChangedCounts;

package/dist/tools/refill-executors.js

@@ -274,18 +274,50 @@ function completeExpectedTargetSummary(value, expectedTargets, maxPlacements) {
             JSON.stringify(accounted) === JSON.stringify(target?.senderIds));
     });
 }
+// fix(112ao-2): the scheduler's in-flight envelope statuses. A response with
+// one of these describes a job that is still running — it never describes an
+// outcome of this dispatch, no matter what it carries alongside.
+const SCHEDULER_IN_FLIGHT_ENVELOPE_STATUSES = new Set(["accepted", "attached"]);
+// The envelope statuses that report a real outcome for this dispatch and are
+// therefore eligible for the receipt audit below.
+const SCHEDULER_TERMINAL_ENVELOPE_STATUSES = new Set([
+    "ran",
+    "window_closed_noop",
+]);
+export function schedulerEnvelopeIsTerminal(schedulerStatus) {
+    return SCHEDULER_TERMINAL_ENVELOPE_STATUSES.has(schedulerStatus);
+}
 export function normalizeSchedulerPrimitiveResult(value, expected) {
     const response = recordValue(value);
     const receipt = recordValue(response?.receipt);
     const schedulerStatus = stringValue(response?.status) ?? stringValue(receipt?.status) ?? "unknown";
     const errorCode = stringValue(recordValue(response?.error)?.code);
-    if (!receipt &&
-        (schedulerStatus === "accepted" || schedulerStatus === "attached")) {
+    // fix(112ao-2): whether this dispatch finished is a total function of the
+    // ENVELOPE status, decided here before any receipt is read. The previous
+    // guard was `!receipt && (accepted || attached)`, which made completion
+    // depend on whether a field happened to be present: the scheduler may attach
+    // an in-flight response to an already-running job and replay THAT job's
+    // receipt, so an `attached` envelope arrived carrying complete, v3-auditable
+    // counters from a prior run. It skipped this branch, passed the audit on
+    // that stale evidence, and returned auditComplete: true — the coordinator
+    // read a finished sweep and redispatched the run it should have awaited
+    // (Dotwork 2026-07-29: 21 exact runs, coverage frozen at sent:0/scheduled:0).
+    //
+    // `accepted`/`attached` are IN-FLIGHT; `ran`/`window_closed_noop` are
+    // TERMINAL and continue to the audit below. `backoff` and `failed` keep their
+    // existing handling — the run loop already unwraps a backoff envelope's
+    // replayed receipt deliberately (schedulerRunReceiptIsFreshZeroScheduled).
+    if (SCHEDULER_IN_FLIGHT_ENVELOPE_STATUSES.has(schedulerStatus)) {
         return {
             status: "matching_scheduler_active",
             schedulerStatus,
+            terminal: false,
             disposition: "bounded_reread_wait",
             receipt: null,
+            // A prior run's counters are never this dispatch's effect. Surfaced
+            // under a distinct name so it can be read for diagnostics but can never
+            // be mistaken for a fresh outcome.
+            ...(receipt ? { replayedReceipt: receipt } : {}),
             retryAfterMs: numberValue(response?.retryAfterMs) ?? 30_000,
             changedCounts: null,
             auditComplete: false,
@@ -329,6 +361,9 @@ export function normalizeSchedulerPrimitiveResult(value, expected) {
     }
     return {
         status: schedulerStatus,
+        // fix(112ao-2): the completion decision, carried explicitly instead of
+        // leaving each consumer to re-infer it from the status string.
+        terminal: schedulerEnvelopeIsTerminal(schedulerStatus),
         receipt: response?.receipt ?? null,
         retryAfterMs: numberValue(response?.retryAfterMs),
         changedCounts,

package/dist/tools/refill-target-plan.js

@@ -1410,7 +1410,8 @@ function sanitizeSchedulerExpectedTargets(value, scope) {
             branchActionTypes.length === 0 ||
             !scope.campaignIds.includes(campaignId) ||
             !scope.tableIds.includes(tableId) ||
-            senderIds.some((senderId) => !scope.senderIds.includes(senderId))) {
+            senderIds.some((senderId) => !scope.senderIds.includes(senderId)) ||
+            senderIds.some((senderId) => !scope.laneSelected(senderId, refillLaneKey))) {
             return null;
         }
         expectedTargets.push({
@@ -1423,6 +1424,28 @@ function sanitizeSchedulerExpectedTargets(value, scope) {
     }
     return expectedTargets;
 }
+// fix(112ao-3): sweep ELIGIBILITY is server-authoritative. This sanitizer
+// validates PROVENANCE and SHAPE — identity, revisions, date format, scope
+// containment, side-effect class, receipt requirements — and no longer
+// re-derives which lanes qualify for a sweep.
+//
+// The old contract required the server's emitted sender/lane set to EQUAL a
+// set this function re-derived from senderPlans, so any disagreement in
+// EITHER direction discarded the entire sweep:
+//   - client stricter than server (112ak-s: `remainingReadyOrProjectedGap === 0`)
+//     silently vetoed valid server sweeps until 112ak-s2 relaxed the copy;
+//   - client looser than server (112ao-3) does exactly the same damage, because
+//     the server excludes lanes for facts senderPlans never carries — an
+//     exhausted per-date capacity probe (`schedulerFillableSlots === 0`), no
+//     `selectedDay` on the target date, a non-structured lane, or a campaign
+//     with no ready-holding ACTIVE source.
+// Keeping two copies of one predicate in sync across a release boundary is the
+// defect; relaxing the copy was only ever a truce. The client cannot see the
+// inputs the decision needs, so it must not make the decision.
+//
+// Scope containment is retained and is NOT eligibility: a sweep may only name
+// senders and lanes belonging to this run's selected cohort, so a drifted or
+// forged packet still fails closed.
 function sanitizeTargetSchedulerSweep(params) {
     if (!Array.isArray(params.value) ||
         !params.expectedWorkspaceId ||
@@ -1432,13 +1455,12 @@ function sanitizeTargetSchedulerSweep(params) {
         !params.expectedStateRevision) {
         return null;
     }
-    const expectedSenderIds = [...params.sweepEligibleBySender.keys()].sort();
-    const expectedActionTypes = [
-        ...new Set([...params.sweepEligibleBySender.values()].flatMap((lanes) => [...lanes])),
-    ].sort();
-    if (expectedSenderIds.length === 0 || expectedActionTypes.length === 0) {
+    const selectedSenderIds = new Set(params.selectedBySender.keys());
+    const selectedActionTypes = new Set([...params.selectedBySender.values()].flatMap((lanes) => [...lanes]));
+    if (selectedSenderIds.size === 0 || selectedActionTypes.size === 0) {
         return null;
     }
+    const laneSelected = (senderId, actionType) => params.selectedBySender.get(senderId)?.has(actionType) === true;
     for (const rawAction of params.value) {
         if (!isRecord(rawAction) || rawAction.type !== "run_scheduler_sweep") {
             continue;
@@ -1451,7 +1473,7 @@ function sanitizeTargetSchedulerSweep(params) {
         const campaignIds = sortedUniqueStrings(input.campaignIds);
         const tableIds = sortedUniqueStrings(input.tableIds);
         const sourceScopes = sanitizeSchedulerSweepSourceScopes(input.sourceScopes);
-        const expectedTargets = sanitizeSchedulerExpectedTargets(input.expectedTargets, { senderIds, campaignIds, tableIds });
+        const expectedTargets = sanitizeSchedulerExpectedTargets(input.expectedTargets, { senderIds, campaignIds, tableIds, laneSelected });
         const expectedTargetsHash = stringValue(input.expectedTargetsHash)?.trim();
         const maxPlacements = numberValue(input.maxPlacements);
         const receiptRequirements = isRecord(rawAction.receiptRequirements)
@@ -1474,10 +1496,18 @@ function sanitizeTargetSchedulerSweep(params) {
             input.stateRevision !== params.expectedStateRevision ||
             !actionKey ||
             requestKey !== actionKey ||
-            !sameStrings(senderIds, expectedSenderIds) ||
-            !sameStrings(actionTypes, expectedActionTypes) ||
-            (expectedActionTypes.length === 1 &&
-                rawActionType !== expectedActionTypes[0]) ||
+            // Provenance, not eligibility: the sweep may only name senders and lanes
+            // this run selected. Containment (not equality) lets the server exclude
+            // a lane on facts the client cannot see without losing the whole sweep.
+            senderIds.length === 0 ||
+            senderIds.some((senderId) => !selectedSenderIds.has(senderId)) ||
+            actionTypes.length === 0 ||
+            actionTypes.some((actionType) => !selectedActionTypes.has(actionType)) ||
+            // The server sets a top-level actionType only for a single-lane sweep,
+            // derived from the packet's own actionTypes — so this stays a check of
+            // the packet's internal consistency, at exactly the prior strictness
+            // (multi-lane sweeps carry no top-level actionType and are not asserted).
+            (actionTypes.length === 1 && rawActionType !== actionTypes[0]) ||
             campaignIds.length === 0 ||
             tableIds.length === 0 ||
             sourceScopes.length === 0 ||
@@ -1876,41 +1906,20 @@ export function sanitizeRefillTargetPlanResult(result) {
     const paidRefreshNeededSenderIdSet = paidRefreshNeededSenderIds(senderRefillPlans);
     const blockers = sanitizeBlockers(result.blockers, selectedKeys, paidRefreshNeededSenderIdSet);
     const request = isRecord(result.request) ? result.request : {};
-    // fix(112ak-s2): this is the CLIENT mirror of the server's dated-sweep gate,
-    // and it silently discarded the server's valid sweep. sanitizeTargetSchedulerSweep
-    // derives its expected senders/actions from this map and returns null when the
-    // map is empty, so a stricter rule here vetoes the server outright: Dotwork
-    // 2026-07-29 (five lanes, remainingProjectedGap 10, readyBuffer 4, rrpg 6) had
-    // the server emit a 20-placement sweep across all five senders, this loop
-    // marked zero lanes eligible, and every served plan came back with
-    // approve_messages at globalActionQueue[0] and no sweep at any rank. Because
-    // the coordinator consumes the sanitized plan, that blocked execution, not just
-    // display. 112ak-s relaxed the same predicate server-side
-    // (refill-target-plan.ts buildExactDateSchedulerSweepAction): a lane earns a
-    // sweep by HOLDING ready rows against an open dated slot, not by its ready
-    // buffer fully covering its gap. No target-date condition is needed to mirror
-    // the server's scoping — sanitizeTargetSchedulerSweep already refuses to run
-    // without an expectedTargetDate matching ^\d{4}-\d{2}-\d{2}$, so this path is
-    // explicit-date-only by construction. Deliberately the ONLY relaxed occurrence:
-    // the wait_for_scheduler append and the status derivation below both keep
-    // `remainingReadyOrProjectedGap === 0`, where full ready coverage is the
-    // correct and intended meaning.
-    const sweepEligibleBySender = new Map();
-    for (const plan of senderPlans) {
-        const senderId = stringValue(plan.senderId);
-        const actionType = allowedActionType(plan.actionType);
-        if (senderId &&
-            actionType &&
-            numberValue(plan.remainingProjectedGap) > 0 &&
-            numberValue(plan.readyBuffer) > 0) {
-            const lanes = sweepEligibleBySender.get(senderId) ?? new Set();
-            lanes.add(actionType);
-            sweepEligibleBySender.set(senderId, lanes);
-        }
-    }
+    // fix(112ao-3): the client no longer re-derives sweep eligibility. It passes
+    // the run's SELECTED cohort so sanitizeTargetSchedulerSweep can check scope
+    // containment (provenance), and leaves the qualify/disqualify decision to
+    // buildExactDateSchedulerSweepAction, which alone holds the per-date capacity
+    // probe, selectedDays, and ready-supply campaign facts the decision needs.
+    // 112ak-s2 relaxed a duplicated `remainingReadyOrProjectedGap === 0` copy
+    // here after it vetoed valid Dotwork sweeps; the duplication itself was the
+    // defect, since a client that is merely LOOSER than the server discards the
+    // sweep just as completely. The two other occurrences below and above are
+    // untouched and mean something different: the wait_for_scheduler append and
+    // the status derivation both use full ready coverage correctly.
     const schedulerSweepAction = sanitizeTargetSchedulerSweep({
         value: target.globalActionQueue,
-        sweepEligibleBySender,
+        selectedBySender,
         expectedWorkspaceId: stringValue(target.workspaceId),
         expectedTargetDate: stringValue(request.targetDate),
         expectedTargetShapeRevision: stringValue(result.targetShapeRevision),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.739",
+  "version": "0.1.741",
   "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>