@sellable/mcp 0.1.418 → 0.1.420

package/README.md

@@ -66,8 +66,9 @@ reader value, validates proof/AI tells, and saves content artifacts under
 
 The refill-sends public command wrapper plans and executes approval-gated send
 refills. It supports `--yolo` and optional sender selectors such as
-`--sender "Christian Reyes"` or typed MCP calls to `refill_sends({ yolo,
-senders })` from:
+`--sender "Christian Reyes"`, optional through-date selectors such as
+`--until 2026-06-30`, or typed MCP calls to `refill_sends({ yolo, senders,
+untilDate })` from:
 
 - `mcp/sellable/skills/refill-sends/SKILL.md`
 
@@ -296,6 +297,7 @@ Use the refill command for sender send refills:
 
 ```
 /sellable:refill-sends --yolo
+/sellable:refill-sends --yolo --until 2026-06-30
 /sellable:refill-sends --sender "Christian Reyes" --sender "Thomas Nobbs"
 ```
 
@@ -323,6 +325,7 @@ Use the Codex refill command with the same flags:
 
 ```
 $sellable:refill-sends --yolo
+$sellable:refill-sends --yolo --until 2026-06-30
 $sellable:refill-sends --sender "Christian Reyes" --sender "Thomas Nobbs"
 ```
 

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

@@ -6,6 +6,7 @@ type RefillSendsCommandInput = {
     senderIds?: string[];
     senderNames?: string[];
     horizonSendDays?: number;
+    untilDate?: string;
     campaignId?: string;
     tableId?: string;
     intent?: RefillSendsIntent;
@@ -48,6 +49,11 @@ export declare const refillSendsToolDefinitions: {
                 maximum: number;
                 description: string;
             };
+            untilDate: {
+                type: string;
+                pattern: string;
+                description: string;
+            };
             campaignId: {
                 type: string;
                 description: string;
@@ -78,7 +84,19 @@ export declare function refillSendsCommand(input?: RefillSendsCommandInput): {
     workflowPromptName: string;
     yolo: boolean;
     intent: RefillSendsIntent;
-    horizonSendDays: number;
+    untilDate: string | null;
+    horizonSendDays: number | null;
+    fillWindow: {
+        mode: string;
+        untilDate: string;
+        description: string;
+        horizonSendDays?: undefined;
+    } | {
+        mode: string;
+        horizonSendDays: number | null;
+        description: string;
+        untilDate?: undefined;
+    };
     approvalMode: RefillSendsApprovalMode;
     campaignId: string | null;
     tableId: string | null;
@@ -101,7 +119,8 @@ export declare function refillSendsCommand(input?: RefillSendsCommandInput): {
                 senders: string[];
                 senderIds: string[];
                 senderNames: string[];
-                horizonSendDays: number;
+                untilDate: string | null;
+                horizonSendDays: number | null;
                 campaignId: string | undefined;
                 tableId: string | undefined;
                 intent: RefillSendsIntent;

package/dist/tools/refill-sends.js

@@ -14,6 +14,25 @@ function normalizeHorizonSendDays(value) {
     }
     return Math.max(1, Math.min(7, Math.floor(value)));
 }
+function normalizeUntilDate(value) {
+    if (value === undefined || value === null || value === "")
+        return null;
+    if (typeof value !== "string") {
+        throw new Error("untilDate must be a string in YYYY-MM-DD format.");
+    }
+    const trimmed = value.trim();
+    if (!/^\d{4}-\d{2}-\d{2}$/.test(trimmed)) {
+        throw new Error("untilDate must use YYYY-MM-DD format.");
+    }
+    const [year, month, day] = trimmed.split("-").map((part) => Number(part));
+    const parsed = new Date(Date.UTC(year, month - 1, day));
+    if (parsed.getUTCFullYear() !== year ||
+        parsed.getUTCMonth() !== month - 1 ||
+        parsed.getUTCDate() !== day) {
+        throw new Error("untilDate must be a valid calendar date.");
+    }
+    return trimmed;
+}
 export const refillSendsToolDefinitions = [
     {
         name: "refill_sends",
@@ -44,7 +63,12 @@ export const refillSendsToolDefinitions = [
                     type: "number",
                     minimum: 1,
                     maximum: 7,
-                    description: "Number of sender-local send days to fill. Defaults to 2.",
+                    description: "Number of sender-local send days to fill. Defaults to 2 when untilDate is not provided.",
+                },
+                untilDate: {
+                    type: "string",
+                    pattern: "^\\d{4}-\\d{2}-\\d{2}$",
+                    description: "Optional sender-local YYYY-MM-DD date to fill through, inclusive. Overrides the default two send-day horizon.",
                 },
                 campaignId: {
                     type: "string",
@@ -76,7 +100,10 @@ export function refillSendsCommand(input = {}) {
     const senderNames = normalizeStrings(input.senderNames);
     const hasSenderSelectors = senders.length > 0 || senderIds.length > 0 || senderNames.length > 0;
     const yolo = input.yolo === true;
-    const horizonSendDays = normalizeHorizonSendDays(input.horizonSendDays);
+    const untilDate = normalizeUntilDate(input.untilDate);
+    const horizonSendDays = untilDate
+        ? null
+        : normalizeHorizonSendDays(input.horizonSendDays);
     const intent = input.intent ?? "plain";
     const approvalMode = input.approvalMode ?? (yolo ? "approve" : "mark_ready");
     const senderScope = hasSenderSelectors
@@ -91,7 +118,19 @@ export function refillSendsCommand(input = {}) {
         workflowPromptName: "refill-sends-workflow",
         yolo,
         intent,
+        untilDate,
         horizonSendDays,
+        fillWindow: untilDate
+            ? {
+                mode: "until_date",
+                untilDate,
+                description: "Fill through this sender-local date inclusive, skipping no-send days and never extending beyond the date without a new packet.",
+            }
+            : {
+                mode: "horizon_send_days",
+                horizonSendDays,
+                description: "Fill the default bounded horizon by sender-local send days.",
+            },
         approvalMode,
         campaignId: input.campaignId ?? null,
         tableId: input.tableId ?? null,
@@ -105,6 +144,9 @@ export function refillSendsCommand(input = {}) {
             'Load get_subskill_prompt({ subskillName: "refill-sends-workflow" }) before any product operation.',
             `Resolve route with resolve_campaign_fill_route({ intent: "${intent}"${input.campaignId ? `, campaignId: "${input.campaignId}"` : ""}${input.tableId ? `, tableId: "${input.tableId}"` : ""} }).`,
             "Call list_senders and get_sender_routing, then resolve sender selectors against active enrolled campaign-backed sequence senders.",
+            untilDate
+                ? `Use fill window untilDate="${untilDate}" as the inclusive sender-local through date; do not extend beyond that date without a new approval packet.`
+                : `Use the default fill window of ${horizonSendDays} sender-local send days.`,
             "Read get_campaign_refill_state for enough exact candidate campaigns to pick the best per-sender target by recent/future scheduler-owned sends, then recent result evidence, then source health.",
             "Fresh reread get_campaign_refill_state immediately before any import, prep, approval, or horizon-fill mutation.",
         ],
@@ -125,10 +167,12 @@ export function refillSendsCommand(input = {}) {
         hostExamples: {
             claude: [
                 "/sellable:refill-sends --yolo",
+                "/sellable:refill-sends --yolo --until 2026-06-30",
                 '/sellable:refill-sends --sender "Christian Reyes" --sender "Thomas Nobbs"',
             ],
             codex: [
                 "$sellable:refill-sends --yolo",
+                "$sellable:refill-sends --yolo --until 2026-06-30",
                 '$sellable:refill-sends --sender "Christian Reyes" --sender "Thomas Nobbs"',
             ],
             mcpTool: {
@@ -138,6 +182,7 @@ export function refillSendsCommand(input = {}) {
                     senders,
                     senderIds,
                     senderNames,
+                    untilDate,
                     horizonSendDays,
                     campaignId: input.campaignId,
                     tableId: input.tableId,

package/dist/tools/setup-evergreen-campaigns.js

@@ -6,7 +6,7 @@ async function postSetupEvergreenCampaigns(body) {
 export const setupEvergreenCampaignsToolDefinitions = [
     {
         name: "setup_evergreen_campaigns",
-        description: "Evergreen campaign setup plan/verify command. Use plan mode first to inspect exact workspace/sender/campaign/table/source state and receive immutable lane packets. `selectedSenderIds` is a legacy shorthand for both scopes; prefer `postEngagerSenderIds` for the Post Engagers sender scope and `sharedSenderIds` for the shared lane sender scope when they differ. If a protected existing Post Engagers campaign must stay unchanged and the operator requested only shared lane execution, pass postEngagerSenderIds:[] and sharedSenderIds; do not include the protected active Post Engagers lane as a reuse packet because it can make the yolo plan non-autoExecutable. The command plans one Post Engagers lane per post-engager sender plus shared Signal Discovery and Shared Cold Fallback lanes for the shared sender set. yolo is only a parent-skill auto-execution hint for safe lane packets; pass yolo only in plan mode and never include yolo on mode:\"verify\" calls. This backend command remains read-only in plan mode and verifies receipts in verify mode. Package-backed prompt authority: the installed public wrapper can be the local Codex skill entrypoint, but lane workers must use get_subskill_prompt and get_subskill_asset for nested `$sellable:create-campaign`, create-campaign-v2, generate-messages, validation, and assets; nested filesystem prompt fallback is a failed UAT. Use mcp__sellable only for workspace selection and product mutations/readbacks. Do not use mcp__sellable_admin, direct DB, Prisma, SQL, built-in web search, browser search, web.run, or any external browsing/search tool as execution or research proof; if Sellable MCP research tools are insufficient, write a blocked receipt instead of browsing externally. Worker-local replans are read-only drift checks and must preserve the exact parent sender scopes, including postEngagerSenderIds:[] when intentionally empty and the exact sharedSenderIds array; if scope, planRevision, actionId, or laneKey drifts, stop with blocked:worker_plan_scope_drift before mutation. Each lane packet includes workerDispatch with acceptedRuntimes, rejectedRuntimes, requiresVisibleThreadOrDurableReceipt, receiptArtifactHint, receiptRunId, and receiptMustBeWrittenAfter; pre-existing receipts at old deterministic paths are stale and must not be used, so stop with blocked:stale_receipt_artifact if the receipt was not freshly written for the current receiptRunId. `multi_agent_v1.spawn_agent`/opaque spawn_agent is not accepted for mutating command proof unless the parent has visible thread or durable receipt proof. In local Codex, prefer `codex_app.list_projects` then `codex_app.create_thread` with a local project target; do not create a worktree for lane execution. If Codex app thread tools are unavailable but local Codex CLI is available, use durable streaming workers with `codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> -`; approval and sandbox flags must appear before `exec`, and current customer CLI installs reject `codex exec --ask-for-approval never` and `codex exec -a never`. When safe-yolo needs normal setup work, the parent skill may ask for bounded delegated approval: one approval over the current planRevision, selected action ids, caps, allowed side-effect classes, and stop conditions lets lane workers execute without per-substep approval while staying inside that packet. In exec/automation mode, do not call request_user_input; if yolo plan autoExecutable:false and no interactive approval can be received, stop with blocked:bounded_approval_unavailable_in_exec_mode before any mutation. Lane workers must explicitly load and use the installed `$sellable:create-campaign` wrapper as the nested workflow entrypoint, then load `create-campaign-v2` and `create-campaign-v2/core/flow.v2.json`; they must execute creation, source import, create-campaign workflow steps, generate-messages, sequence attachment, pause_campaign review-state transition when the current table is still DRAFT, and review readiness through that existing create-campaign workflow/subskills, then return receipts here for verification. Customer-visible verify receipts must set status:'succeeded' or status:'completed'; status:'passed', status:'pass', and status:'passed_with_warnings' are rejected as primary success statuses. Receipts must include createCampaignStepReceipt with setupPlanCall, createCampaignWorkflowReceipt, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall nested inside createCampaignStepReceipt; top-level-only copies of those objects are not enough and are not promoted by verify. setupPlanCall must use canonical keys: planRevision, actionId, laneKey, workspaceId, senderIds, campaignId, tableId, createIntent. Do not use laneActionId, lanePacketActionId, delegatedPlanRevision, delegatedActionId, or requestedCall text as a substitute for those canonical fields. createCampaignWorkflowReceipt must include skillCommand:'$sellable:create-campaign', skillName:'create-campaign', wrapperSkillLoaded:true, workflowPromptName:'create-campaign-v2', workflowPromptLoadedToHasMoreFalse:true, workflowAssetPath:'create-campaign-v2/core/flow.v2.json', workflowAssetLoaded:true, workerRuntime, workerThreadId or receiptArtifactPath, durableReceiptWritten when using a receipt file, and notAdHoc:true. messageDraftingReceipt must use exactly statusSource:'branch' or statusSource:'packaged-generate-messages-worker'; descriptive aliases such as statusSource:'package-readback-local-thread' are rejected. It must include proof that generate-messages was loaded, start_campaign_message_preparation/get_campaign_message_preparation_status ran when the packaged worker path is used, validationResult:'passed', a passed qualityReview, and at least 3 concrete sampleMessages with rowId, generatedMessageText, verdict, and issues; Do not substitute `message` for `generatedMessageText`; Do not substitute `passVerdict` for `verdict`. Before writing durable receipts, run a receipt self-check: top-level `planRevision`, `actionId`, `laneKey`, `laneType`, `workspaceId`, and `senderIds` must exist; if the self-check fails, fix the receipt before ending. Use start_campaign_message_preparation with approvalMode:\"mark_ready\" only for evergreen setup. Never call `start_campaign_message_preparation` with `approvalMode:\"approve\"`; approve exactly one semantic Approved cell through select_campaign_cells/update_cell and final proof must show approvedGeneratedMessageCount exactly 1. Shared Cold Fallback samples with a standalone name followed by 'Hey there' are rejected. This command does not launch campaigns, does not schedule sends, does not assign scheduler-owned send fields, does not raw-write campaign status, does not archive/delete cleanup targets, and does not spend paid credits.",
+        description: "Evergreen campaign setup plan/verify command. Use plan mode first to inspect exact workspace/sender/campaign/table/source state and receive immutable lane packets. `selectedSenderIds` is a legacy shorthand for both scopes; prefer `postEngagerSenderIds` for the Post Engagers sender scope and `sharedSenderIds` for the shared lane sender scope when they differ. If a protected existing Post Engagers campaign must stay unchanged and the operator requested only shared lane execution, pass postEngagerSenderIds:[] and sharedSenderIds; do not include the protected active Post Engagers lane as a reuse packet because it can make the yolo plan non-autoExecutable. The command plans one Post Engagers lane per post-engager sender plus shared Signal Discovery and Shared Cold Fallback lanes for the shared sender set. yolo is only a parent-skill auto-execution hint for safe lane packets; pass yolo only in plan mode and never include yolo on mode:\"verify\" calls. This backend command remains read-only in plan mode and verifies receipts in verify mode. Package-backed prompt authority: the installed public wrapper can be the local Codex skill entrypoint, but lane workers must use get_subskill_prompt and get_subskill_asset for nested `$sellable:create-campaign`, create-campaign-v2, generate-messages, validation, and assets; nested filesystem prompt fallback is a failed UAT. Use mcp__sellable only for workspace selection and product mutations/readbacks. Do not use mcp__sellable_admin, direct DB, Prisma, SQL, built-in web search, browser search, web.run, or any external browsing/search tool as execution or research proof; if Sellable MCP research tools are insufficient, write a blocked receipt instead of browsing externally. Worker-local replans are read-only drift checks and must preserve the exact parent sender scopes, including postEngagerSenderIds:[] when intentionally empty and the exact sharedSenderIds array; if scope, planRevision, actionId, or laneKey drifts, stop with blocked:worker_plan_scope_drift before mutation. Each lane packet includes workerDispatch with acceptedRuntimes, rejectedRuntimes, requiresVisibleThreadOrDurableReceipt, receiptArtifactHint, receiptRunId, and receiptMustBeWrittenAfter; pre-existing receipts at old deterministic paths are stale and must not be used, so stop with blocked:stale_receipt_artifact if the receipt was not freshly written for the current receiptRunId. `multi_agent_v1.spawn_agent`/opaque spawn_agent is not accepted for mutating command proof unless the parent has visible thread or durable receipt proof. In local Codex, prefer `codex_app.list_projects` then `codex_app.create_thread` with a local project target; do not create a worktree for lane execution. If Codex app thread tools are unavailable but local Codex CLI is available, use durable streaming workers with `codex -a never -s danger-full-access exec -C <repo> -o <worker-final-file> -`; approval and sandbox flags must appear before `exec`, and current customer CLI installs reject `codex exec --ask-for-approval never` and `codex exec -a never`. Plan responses include approvalSummary; render approvalSummary when asking for bounded delegated approval because it explicitly lists campaignsToCreate, campaignsToUpdate, campaignsToVerifyOnly, campaignsLeftUntouched, attachedSenders, selectedActionIds, allowedSideEffects, forbiddenSideEffects, blockers, and approvalQuestion. When safe-yolo needs normal setup work, the parent skill may ask for bounded delegated approval: one approval over the current planRevision, selected action ids, caps, allowed side-effect classes, and stop conditions lets lane workers execute without per-substep approval while staying inside that packet. In exec/automation mode, do not call request_user_input; if yolo plan autoExecutable:false and no interactive approval can be received, stop with blocked:bounded_approval_unavailable_in_exec_mode before any mutation. Lane workers must explicitly load and use the installed `$sellable:create-campaign` wrapper as the nested workflow entrypoint, then load `create-campaign-v2` and `create-campaign-v2/core/flow.v2.json`; they must execute creation, source import, create-campaign workflow steps, generate-messages, sequence attachment, pause_campaign review-state transition when the current table is still DRAFT, and review readiness through that existing create-campaign workflow/subskills, then return receipts here for verification. Customer-visible verify receipts must set status:'succeeded' or status:'completed'; status:'passed', status:'pass', and status:'passed_with_warnings' are rejected as primary success statuses. Receipts must include createCampaignStepReceipt with setupPlanCall, createCampaignWorkflowReceipt, campaignBriefReceipt, sourceDecisionReceipt, filterDecisionReceipt, messageDraftingReceipt, reviewBatchReceipt, sequenceReceipt, and verifyCall nested inside createCampaignStepReceipt; top-level-only copies of those objects are not enough and are not promoted by verify. setupPlanCall must use canonical keys: planRevision, actionId, laneKey, workspaceId, senderIds, campaignId, tableId, createIntent. Do not use laneActionId, lanePacketActionId, delegatedPlanRevision, delegatedActionId, or requestedCall text as a substitute for those canonical fields. createCampaignWorkflowReceipt must include skillCommand:'$sellable:create-campaign', skillName:'create-campaign', wrapperSkillLoaded:true, workflowPromptName:'create-campaign-v2', workflowPromptLoadedToHasMoreFalse:true, workflowAssetPath:'create-campaign-v2/core/flow.v2.json', workflowAssetLoaded:true, workerRuntime, workerThreadId or receiptArtifactPath, durableReceiptWritten when using a receipt file, and notAdHoc:true. messageDraftingReceipt must use exactly statusSource:'branch' or statusSource:'packaged-generate-messages-worker'; descriptive aliases such as statusSource:'package-readback-local-thread' are rejected. It must include proof that generate-messages was loaded, start_campaign_message_preparation/get_campaign_message_preparation_status ran when the packaged worker path is used, validationResult:'passed', a passed qualityReview, and at least 3 concrete sampleMessages with rowId, generatedMessageText, verdict, and issues; Do not substitute `message` for `generatedMessageText`; Do not substitute `passVerdict` for `verdict`. Before writing durable receipts, run a receipt self-check: top-level `planRevision`, `actionId`, `laneKey`, `laneType`, `workspaceId`, and `senderIds` must exist; if the self-check fails, fix the receipt before ending. Use start_campaign_message_preparation with approvalMode:\"mark_ready\" only for evergreen setup. Never call `start_campaign_message_preparation` with `approvalMode:\"approve\"`; approve exactly one semantic Approved cell through select_campaign_cells/update_cell and final proof must show approvedGeneratedMessageCount exactly 1. Shared Cold Fallback samples with a standalone name followed by 'Hey there' are rejected. This command does not launch campaigns, does not schedule sends, does not assign scheduler-owned send fields, does not raw-write campaign status, does not archive/delete cleanup targets, and does not spend paid credits.",
         inputSchema: {
             type: "object",
             properties: {

package/package.json

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

package/skills/create-evergreen-campaigns/SKILL.md

@@ -234,7 +234,15 @@ blocker and would make the whole yolo plan non-autoExecutable even though the
 operator asked to leave it untouched. Inventory and waterfall proof may mention
 the protected lane, but selectedActionIds and lane workers must cover only the
 shared lane packets.
+If the operator says to preserve existing active/live campaigns, preserve an
+ACTIVE Post Engagers lane the same way: treat it as protected inventory, exclude
+it from `postEngagerSenderIds` for the execution plan, and select only the
+remaining missing/reusable shared-lane actionIds. Do not let a protected active
+Post Engagers reuse packet block shared-lane verification or repair. Report the
+protected active lane in inventory/final notes, but do not dispatch a worker for
+it and do not include it in `selectedActionIds`.
 Short form: Do not include the protected active Post Engagers lane as a reuse packet when the operator requested only shared lane execution.
+Short form: "preserve existing active/live campaigns" means exclude ACTIVE Post Engagers from yolo execution, not block all shared-lane work.
 
 When senders are ambiguous, ask which sender ids belong in the Post Engagers
 sender scope and which belong in the shared lane sender scope before planning.
@@ -261,11 +269,23 @@ sender scopes, explicit bindings, or an interactive session.
 
 When safe-yolo is blocked only because the plan needs normal setup work, ask
 for a **bounded delegated approval** over the rendered current plan instead of
-asking for each substep. The approval packet must name the workspace id, sender
-ids, lane keys, campaign/table ids or create intents, source/import caps,
-generate-message caps, route-proof approval policy, selectedActionIds,
-planRevision, allowed side-effect classes, and stop conditions. After that one
-approval covers the current planRevision, the parent may act on behalf of the
+asking for each substep. The approval request must be rendered from the plan's
+`approvalSummary`, not handwritten from raw lane packets alone. Show:
+
+- `workspaceId`, `planRevision`, and `selectedActionIds`.
+- Sender scopes with display names and ids: Post Engagers senders and shared-lane senders.
+- `campaignsToCreate`: each campaign/lane name, action id, create intent, attached senders, and allowed side effects.
+- `campaignsToUpdate`: each existing campaign/table id, current status/step, attached senders, and exact repairs or setup side effects.
+- `campaignsToVerifyOnly`: existing campaigns that will only be verified/read.
+- `campaignsLeftUntouched`: existing campaigns attached to selected senders but excluded from the current selected lane scope, with the reason.
+- Source/import caps, generate-message caps, route-proof approval policy, allowed side-effect classes, forbidden side effects, blockers, and stop conditions.
+
+If `approvalSummary.approvalQuestion` is present, use it as the short approval
+question and put the detailed buckets underneath. Do not ask a vague yes/no
+question that only says "run evergreen setup" or "approve this plan" without
+naming the campaigns to create, existing campaigns to update/verify, campaigns
+left untouched, and attached senders. After that one approval covers the current
+planRevision and selectedActionIds, the parent may act on behalf of the
 operator and execute the selectedActionIds end to end. Do not ask again for
 substep approvals for source import, create-campaign choices, Message Drafting,
 sequence attach/precheck, or exactly one route-proof approval when those actions
@@ -275,6 +295,7 @@ workspace id, sender ids, source/list id, campaign/table id, new campaign/table
 id, planRevision, actionId, selectedActionIds, allowed side effects, caps,
 status, or blocker set outside the approved packet.
 The short rule: one approval covers the current planRevision and selectedActionIds.
+The approval clarity rule: the operator approves named campaign create/update/verify/untouched buckets and attached senders, not a generic evergreen run.
 The execution rule: act on behalf of the operator; do not ask again for substep approvals while work stays within the lane packet, approved caps, approved side-effect classes, and route-proof approval policy.
 The drift rule: stop and re-plan when ids, caps, blockers, side-effect classes, or any new campaign/table id leave the approved packet.
 
@@ -346,6 +367,14 @@ When launching durable Codex CLI workers from an automation parent, pass an
 explicit supported worker model instead of relying on the Codex CLI default
 model. Use the parent runtime model when known, for example:
 `codex -a never -s danger-full-access exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
+In Codex CLI, the parent runtime model is visible in the run header as
+`model: <model-name>`. Copy that exact model string into child worker launches
+first. If the parent header says `model: gpt-5.5`, launch workers with
+`-m gpt-5.5`; do not invent or probe nearby aliases such as `gpt-5.3-codex`,
+`gpt-5.2`, `gpt-5-codex`, `codex-latest`, or `codex-mini-latest` before trying
+the exact parent model. A one-line probe must count as supported only when it
+exits 0 and returns the requested output; a session header followed by a
+`not supported` error is rejected, not accepted.
 Do not rely on the Codex CLI default model; some customer and VPS installs
 default to unavailable model aliases. If the parent cannot identify a supported
 worker model and a test `codex exec -m <worker-model>` launch is rejected, stop

package/skills/refill-sends/SKILL.md

@@ -66,14 +66,18 @@ Accepted invocation flags in the same user request:
   fresh state reread.
 - `--sender <name-or-id>`: scope to a specific sender; repeat for multiple
   senders.
+- `--until <YYYY-MM-DD>`: fill through that sender-local date, inclusive,
+  instead of the default two send-day horizon.
 - `senderIds: <id>, <id>` or `senderNames: <name>, <name>`: explicit selector
   alternatives when the host preserves natural-language arguments better than
   shell-style flags.
+- `untilDate: YYYY-MM-DD`: explicit date selector alternative when the host
+  preserves natural-language arguments better than shell-style flags.
 
 When the host can call typed MCP tools, start with:
 
 ```text
-refill_sends({ yolo?: boolean, senders?: string[], senderIds?: string[], senderNames?: string[], horizonSendDays?: number })
+refill_sends({ yolo?: boolean, senders?: string[], senderIds?: string[], senderNames?: string[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD" })
 ```
 
 That command helper only normalizes arguments and returns the execution
@@ -132,13 +136,16 @@ reassignment, or campaigns outside those selected for the eligible sender set.
 Stop and re-plan if the route, sender set, ids, caps, blockers, or side-effect
 class drift before mutation.
 
-In `--yolo`, the default two-day fill horizon is two send days. For each target
-sender, compute the bounded gap from that sender's healthy daily capacity,
-existing future scheduler-owned scheduled sends, and rows already ready to
-schedule across active campaigns enrolled with that sender. Then pick the best
-same-sender campaign to fill the gap: prefer recent/future scheduler-owned sends
-for that sender, then strongest recent result evidence, then source health. Do
-not stop after filling only one sender when the request was sender-scoped. If a
+In `--yolo`, the default two-day fill horizon is two send days unless
+`--until`/`untilDate` is provided. If an until date is provided, compute bounded
+gaps through that sender-local date inclusive, skipping no-send days and never
+extending beyond that date without a new packet. For each target sender, compute
+the bounded gap from that sender's healthy daily capacity, existing future
+scheduler-owned scheduled sends, and rows already ready to schedule across
+active campaigns enrolled with that sender. Then pick the best same-sender
+campaign to fill the gap: prefer recent/future scheduler-owned sends for that
+sender, then strongest recent result evidence, then source health. Do not stop
+after filling only one sender when the request was sender-scoped. If a
 same-source copy hits the campaign-table row cap, split the current source into
 a bounded LinkedIn profile source list, confirm only that smaller list into the
 same campaign, and operate on the copied review batch. Do not fall back to