@sellable/mcp 0.1.550 → 0.1.552

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

@@ -1,12 +1,12 @@
 import { getApi } from "../api.js";
-async function postSetupEvergreenCampaigns(body) {
+async function postSetupEvergreenCampaigns(body, workspaceId) {
     const api = getApi();
-    return api.post("/api/v3/mcp/setup-evergreen-campaigns", body);
+    return api.post("/api/v3/mcp/setup-evergreen-campaigns", body, workspaceId ? { workspaceId } : undefined);
 }
 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. `sharedSenderIds` must include every intended shared-lane sender, not only the named Post Engagers sender; when adding other senders to existing shared evergreen campaigns, resolve those sender ids with list_senders and pass the full shared set. 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. Non-archived PAUSED/ACTIVE/DRAFT shared campaigns/tables are the reusable targets; archived campaigns, archived tables, and archived waterfall bindings are stale inventory and must not be counted as valid evergreen slots. If an existing non-archived shared campaign is already attached to additional senders, plan reporting should count those attached senders as existing shared-lane membership rather than treating them as missing or duplicate slots. 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 preferredRuntime, runtimeFallbackOrder, 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, default to `workerDispatch.preferredRuntime` (`visible-codex-app-thread`): discover Codex app thread tools if needed, then call `codex_app.list_projects` and `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 -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -` and include preferredRuntimeAttempt plus fallbackReason in createCampaignWorkflowReceipt; approval, sandbox, and reasoning-effort config flags must appear before `exec`, and current customer CLI installs reject `codex exec --ask-for-approval never` and `codex exec -a never`. Do not rely on default model or default reasoning effort: copy the parent model such as `gpt-5.5` into `-m` and always pass `-c model_reasoning_effort=xhigh`; a child worker that reports GPT 5.5 with high reasoning is a launcher bug to relaunch before mutation, not a user-continue path. 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. Exception: a Post Engagers lane may write status:'blocked' with blocker:'post_engagers_no_sender_posts', 'post_engagers_no_recent_sender_posts', 'post_engagers_no_sender_owned_posts', or 'post_engagers_source_author_mismatch' when Sellable MCP readback proves no usable sender-authored posts/source exists; verify returns these as acceptedLaneBlockers so the parent can report the no-op instead of retrying invalid source repair. Any other blocked receipt, including model-quality/preflight or worker model availability blockers, is not a goal-complete success condition and must not let the parent report evergreen completion. 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; CLI durable fallback runtimes must also include preferredRuntimeAttempt for visible-codex-app-thread and fallbackReason. 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. `sharedSenderIds` must include every intended shared-lane sender, not only the named Post Engagers sender; when adding other senders to existing shared evergreen campaigns, resolve those sender ids with list_senders and pass the full shared set. 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. Non-archived PAUSED/ACTIVE/DRAFT shared campaigns/tables are the reusable targets; archived campaigns, archived tables, and archived waterfall bindings are stale inventory and must not be counted as valid evergreen slots. If an existing non-archived shared campaign is already attached to additional senders, plan reporting should count those attached senders as existing shared-lane membership rather than treating them as missing or duplicate slots. 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 preferredRuntime, runtimeFallbackOrder, 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, default to `workerDispatch.preferredRuntime` (`visible-codex-app-thread`): discover Codex app thread tools if needed, then call `codex_app.list_projects` and `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 -c model_reasoning_effort=high exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -` and include preferredRuntimeAttempt plus fallbackReason in createCampaignWorkflowReceipt; approval, sandbox, and reasoning-effort config flags must appear before `exec`, and current customer CLI installs reject `codex exec --ask-for-approval never` and `codex exec -a never`. Do not rely on default model or default reasoning effort: copy the parent model such as `gpt-5.6-sol` into `-m` and always pass `-c model_reasoning_effort=high`; a child worker that reports GPT 5.6-Sol with reasoning below high is a launcher bug to relaunch before mutation, not a user-continue path. 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. Exception: a Post Engagers lane may write status:'blocked' with blocker:'post_engagers_no_sender_posts', 'post_engagers_no_recent_sender_posts', 'post_engagers_no_sender_owned_posts', or 'post_engagers_source_author_mismatch' when Sellable MCP readback proves no usable sender-authored posts/source exists; verify returns these as acceptedLaneBlockers so the parent can report the no-op instead of retrying invalid source repair. Any other blocked receipt, including model-quality/preflight or worker model availability blockers, is not a goal-complete success condition and must not let the parent report evergreen completion. 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; CLI durable fallback runtimes must also include preferredRuntimeAttempt for visible-codex-app-thread and fallbackReason. 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: {
@@ -15,6 +15,23 @@ export const setupEvergreenCampaignsToolDefinitions = [
                     enum: ["plan", "verify"],
                     description: 'Defaults to "plan". Verify only validates worker receipts.',
                 },
+                workspaceId: {
+                    type: "string",
+                    description: "Optional explicit workspace id. Required for connection-only evergreen setup; it is also sent as the request workspace so concurrent threads cannot drift to another active workspace.",
+                },
+                campaignSequenceOptions: {
+                    type: "object",
+                    properties: {
+                        mode: {
+                            type: "string",
+                            enum: ["connection_only"],
+                            description: "Optional non-default sequence policy. connection_only means attach the canonical invite-only template and verify exactly send_invite, with no DM, InMail, View Profile, follow-up, launch, or send side effects.",
+                        },
+                    },
+                    required: ["mode"],
+                    additionalProperties: false,
+                    description: "Optional non-default evergreen sequence policy. Omit to keep the standard tier-recommended Premium/Sales Nav behavior.",
+                },
                 depth: {
                     type: "string",
                     enum: ["structure_only", "customer_visible"],
@@ -90,10 +107,12 @@ export const setupEvergreenCampaignsToolDefinitions = [
 ];
 export function setupEvergreenCampaigns(input) {
     return postSetupEvergreenCampaigns({
+        workspaceId: input.workspaceId,
         mode: input.mode,
         yolo: input.mode === "verify" ? undefined : input.yolo,
         depth: input.depth,
         handoffMode: input.mode === "verify" ? undefined : input.handoffMode,
+        campaignSequenceOptions: input.campaignSequenceOptions,
         allConnectedSenders: input.allConnectedSenders,
         selectedSenderIds: input.selectedSenderIds,
         postEngagerSenderIds: input.postEngagerSenderIds,
@@ -102,5 +121,5 @@ export function setupEvergreenCampaigns(input) {
         planRevision: input.planRevision,
         selectedActionIds: input.selectedActionIds,
         receipts: input.receipts,
-    });
+    }, input.workspaceId);
 }

package/package.json

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

package/skills/create-campaign/SKILL.md

@@ -721,7 +721,7 @@ Treat host capabilities as concrete functions, not prose conventions:
   import and before dispatching Message Drafting only.
 - `launch_message_drafting`: Claude Code uses `Task` with `subagent_type`
   `post-find-leads-message-scout` when listed; Codex uses the returned
-  compatibility agent or a generic `gpt-5.5` / `xhigh` Message Drafting agent.
+  compatibility agent or a generic `gpt-5.6-sol` / `high` Message Drafting agent.
 
 If a required interactive question function or MCP loader is missing, stop and
 explain the Sellable install/reload problem. Source work uses product-native MCP
@@ -1082,8 +1082,8 @@ updates.
    In Codex, the filter-choice answer is the campaign-scoped go-ahead to use
    this single Message Drafting background agent in step-wise and YOLO modes.
    Do not ask a separate question to start it. If the named custom agent is not
-   available, spawn a generic background agent with `model: "gpt-5.5"` and
-   `reasoning_effort: "xhigh"` using the same lean campaign/table basis. If no
+   available, spawn a generic background agent with `model: "gpt-5.6-sol"` and
+   `reasoning_effort: "high"` using the same lean campaign/table basis. If no
    background-agent tool is callable, start the same full message branch inline
    before filter drafting or skip-filter message review and record it as
    `statusSource: "parent-thread-fallback"`.

package/skills/create-campaign-v2/SKILL.md

@@ -291,7 +291,7 @@ in the branch read means "filters still owned by parent," not `blocked`.
 
 Keep the handoff lean: `campaignId`, `workflowTableId`, concise brief/source summary, source-use rule, and 3-5 sample rows (`rowId`, name, title, company, signal). Do not paste copied row counts, hashes, full row IDs, broad row data, or local debug artifacts.
 
-Route user copy feedback before `approve-message` back to Message Drafting; parent does not rewrite. The branch loads the full `generate-messages` prompt, every required asset, then `get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`; do not render `renderedFallbackSample`, concerns, or `qaReceipt` in the happy path. Generic fallback is `gpt-5.5` / `xhigh` Message Drafting. Handoff is labeled Markdown, not raw JSON.
+Route user copy feedback before `approve-message` back to Message Drafting; parent does not rewrite. The branch loads the full `generate-messages` prompt, every required asset, then `get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`; do not render `renderedFallbackSample`, concerns, or `qaReceipt` in the happy path. Generic fallback is `gpt-5.6-sol` / `high` Message Drafting. Handoff is labeled Markdown, not raw JSON.
 
 ## Hard Gates
 

package/skills/create-campaign-v2/references/tier-routing-matrix.md

@@ -59,6 +59,11 @@ The tail MUST verify:
 
 - `attach_recommended_sequence` is the only way to pick a template in
   the autonomous tail. Do NOT hand-wire a sequence at Step 16.
+- Exception: when the parent `$sellable:create-evergreen-campaigns` plan
+  explicitly carries `campaignSequenceOptions:{ mode:"connection_only" }`,
+  do not call `attach_recommended_sequence`. Use the backend-owned
+  `attach_sequence({ tableId, templateRef:"connection_only", currentStep:"send" })` path and prove
+  `sequenceReceipt.actionTypes:["send_invite"]`.
 - Tier mismatch at attach time is an escalation, NOT a silent fallback.
 - A Standard sender MUST NOT be attached to an INMAIL_OPEN template.
   This would produce sends that fail at Unipile with `not_authorized`.

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

@@ -134,6 +134,19 @@ run without user input, or similar, run in **automation mode**:
     exactly one quality-valid route-proof row when needed, and attach the
     recommended sequence, but it still must not launch campaigns, schedule
     sends, send messages, or spend paid InMail.
+  - **Connection-only evergreen completion is optional and non-default.** Use it
+    only when the prompt explicitly says connection-only, invite-only,
+    connection request only, no DMs, or no follow-ups. Pass the typed option
+    `campaignSequenceOptions:{ mode:"connection_only" }` plus an explicit
+    `workspaceId` to `setup_evergreen_campaigns`. Omit
+    `campaignSequenceOptions` for the standard tier-recommended Premium,
+    Sales Nav, Recruiter, and paid InMail behavior.
+    Connection-only completion still creates/reuses the same evergreen lanes,
+    source rows, and paused/unlaunched review state, but it attaches only the
+    canonical invite template and persists `currentStep:"send"` as the paused
+    review step. It does not require Message Drafting, generated messages,
+    route-proof approval, first DM, InMail, View Profile fallback, follow-up
+    branch, launch, scheduling, or sends.
 
 If the invoking prompt explicitly asks for interactive message polish or sample
 proof, run in **interactive polish mode** and use the confirmation/sample steps
@@ -424,7 +437,7 @@ fallback only when app thread tools are unavailable; the receipt must include
 `fallbackReason`, or backend verify rejects it.
 When visible Codex app thread tools are unavailable but local Codex CLI is
 available, the accepted durable streaming-worker command shape is:
-`codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
+`codex -a never -s danger-full-access -c model_reasoning_effort=high exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
 The approval, sandbox, and reasoning-effort config flags must come before the
 `exec` subcommand for Codex CLI builds that expose `-a`/`-s`/`-c` only at top
 level. `--skip-git-repo-check` belongs after `exec` because current customer and VPS Codex CLI builds expose it
@@ -434,26 +447,26 @@ forms fail on current customer CLI installs. Pipe the lane packet prompt on
 stdin, require the worker to write `workerDispatch.receiptArtifactHint`, and
 pass exactly one lane packet per worker.
 When launching durable Codex CLI workers from an automation parent, pass an
-explicit supported worker model and explicit `xhigh` reasoning effort instead
+explicit supported worker model and explicit `high` reasoning effort instead
 of relying on the Codex CLI defaults. Use the parent runtime model when known,
 for example:
-`codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> -`.
+`codex -a never -s danger-full-access -c model_reasoning_effort=high 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` plus `-c model_reasoning_effort=xhigh`; do not invent or probe
+first. If the parent header says `model: gpt-5.6-sol`, launch workers with
+`-m gpt-5.6-sol` plus `-c model_reasoning_effort=high`; 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 include the same `-c model_reasoning_effort=xhigh` override
+one-line probe must include the same `-c model_reasoning_effort=high` override
 and 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 or default reasoning effort; some
-customer and VPS installs default to unavailable model aliases or to `high`
-reasoning. `-m gpt-5.5` alone is not enough. If a child worker reports GPT 5.5
-with `high` reasoning, treat that as a launcher bug, relaunch with the explicit
-`xhigh` config before mutation, and do not ask the user to continue through the
+customer and VPS installs default to unavailable model aliases or to reasoning
+below `high`. `-m gpt-5.6-sol` alone is not enough. If a child worker reports GPT 5.6-Sol
+with reasoning below `high`, treat that as a launcher bug, relaunch with the explicit
+`high` config before mutation, and do not ask the user to continue through the
 model-quality warning. If the parent cannot identify a supported worker model
-and launch it with `xhigh` reasoning, stop with
+and launch it with `high` reasoning, stop with
 `blocked: worker_model_unavailable` before mutation.
 When wrapping multiple local Codex CLI workers in a shell launcher, run the
 wrapper with `/bin/bash -lc` or another explicitly chosen portable shell. Do not
@@ -466,7 +479,7 @@ Do not embed `<<'WORKER_PROMPT'` heredocs inside a single quoted or double
 quoted `/bin/bash -lc '...'` command string; nested quoting is brittle and can
 truncate the first worker before mutation. For multi-worker launchers, write one
 plain prompt file per lane under the current run directory, then start each
-worker with `codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m "$WORKER_MODEL" -C "$REPO" -o
+worker with `codex -a never -s danger-full-access -c model_reasoning_effort=high exec --skip-git-repo-check -m "$WORKER_MODEL" -C "$REPO" -o
 "$worker_final_file" - < "$worker_prompt_file"`. Keep launcher shell variables
 double-quoted and keep the prompt heredoc only in a standalone script/prompt-file
 write step, not inside an already quoted shell argument. If the first launcher
@@ -572,7 +585,7 @@ launchers, write the same prompt body to `<worker-prompt-file>` and launch the
 worker with stdin redirected from that file:
 
 ```
-codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
+codex -a never -s danger-full-access -c model_reasoning_effort=high exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - <<'WORKER_PROMPT'
 Use $sellable:create-campaign as the governing campaign workflow for this one lane worker.
 Use the evergreen plan/packet below only for lane scope, source metadata,
 postconditions, side-effect caps, and durable receipt proof.
@@ -619,10 +632,10 @@ Do not launch, start, schedule, send, or use paid InMail.
 For filter proof, durable receipt status must be `filterDecisionReceipt.status:"applied"` only; never `completed`, `confirmed`, `done`, or aliases.
 For generated messages, `update_cell` is allowed only for the semantic Approved checkbox. Never use `update_cell` for generated message text/body/sample copy. Bad copy requires `revise_message_template_and_rerun` or brief/template revision plus Generate Message rerun. Any generated-message cell override is `blocked: generated_message_cell_override`.
 If `bootstrap_create_campaign.modelQuality.status === "warn"` because the child
-worker reports GPT 5.5 with `high` reasoning, that is a parent launcher
+worker reports GPT 5.6-Sol with reasoning below `high`, that is a parent launcher
 configuration bug, not an operator approval path inside the worker. Stop before
 mutation, tell the parent to relaunch this lane with
-`-c model_reasoning_effort=xhigh`, and do not mark the worker goal complete.
+`-c model_reasoning_effort=high`, and do not mark the worker goal complete.
 Complete only this lane. Do not end with narration only. Before your final
 response, run a local file-existence and JSON self-check for
 <receiptArtifactPath>. If the lane succeeded, write the canonical success
@@ -643,7 +656,7 @@ receipt, or an accepted Post Engagers no-source blocked/no-op receipt.
 WORKER_PROMPT
 
 # Multi-worker launcher equivalent:
-codex -a never -s danger-full-access -c model_reasoning_effort=xhigh exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - < <worker-prompt-file>
+codex -a never -s danger-full-access -c model_reasoning_effort=high exec --skip-git-repo-check -m <worker-model> -C <repo> -o <worker-final-file> - < <worker-prompt-file>
 ```
 
 If any placeholder cannot be filled from the current plan, matching
@@ -720,6 +733,9 @@ not a parent-thread summary. The receipt must include:
   creation, preserve that original packet only in a separate `parentLanePacket`
   object; do not leave `setupPlanCall.campaignId:null` or
   `setupPlanCall.tableId:null`.
+  If the parent plan used connection-only, the receipt must also include
+  `setupPlanCall.campaignSequenceOptions:{ "mode":"connection_only" }` or
+  `setupPlanCall.sequencePolicy.mode:"connection_only"`.
   Short form: For create lanes, `setupPlanCall.campaignId` and `setupPlanCall.tableId` must be the actual created campaign/table ids.
   Short form: Do not leave `setupPlanCall.campaignId:null` or `setupPlanCall.tableId:null`.
 - `createCampaignWorkflowReceipt`: proof the worker loaded the actual installed
@@ -810,22 +826,40 @@ not a parent-thread summary. The receipt must include:
   them into canonical `promptLoadedToHasMoreFalse`, `requiredAssetsLoaded`,
   `validationLoaded`, `reviewBatchRowHash`, and
   `messageDraftRecommendation`.
+  Connection-only lanes are the exception: do not include
+  `messageDraftingReceipt` or run generated-message prep unless the operator
+  separately asked for message copy. The parent verifier expects no message
+  proof for connection-only lanes.
 - `reviewBatchReceipt`: review-batch row ids/hash, generated row count,
   quality-valid route-proof row id when approved, and proof that no broad
   approve-all occurred.
+  Connection-only lanes are the exception: do not approve a route-proof row and
+  do not include a required review-batch receipt.
 - `sequenceReceipt`: exact current workflowTableId, recommended non-paid
   sequence attach/precheck result, and readback showing `hasSequence:true` when
   completion is claimed. If the tool output uses
   `attachRecommendedSequenceResult.actionTypes` or
   `nonPaidRecommendedSequence`, copy them to canonical `actionTypes` and
   `nonPaid`.
+  For connection-only lanes, do not call `attach_recommended_sequence`. Attach
+  with `attach_sequence({ tableId, templateRef:"connection_only", currentStep:"send" })`, then
+  include exact current-template proof:
+  `sequenceReceipt.hasSequence:true`,
+  `sequenceReceipt.actionTypes:["send_invite"]`, and
+  `sequenceReceipt.nonPaid:true`. Receipts that only say
+  `tool:"attach_recommended_sequence"` or include `send_dm`,
+  `send_inmail_open`, `send_inmail_closed`, or `view_profile` are failing
+  connection-only receipts.
 - final paused-send proof: if the current campaign table is `DRAFT` after the
   sequence is attached, call the product `pause_campaign({ campaignId })`
   endpoint/tool to put the unlaunched campaign into `PAUSED` review state, then
   reread the campaign/table. Do not raw-write `campaignStatus`, do not start or
   launch, and do not schedule/send. Completion requires reread proof of
-  `currentStep:"send"` and `campaignStatus:"PAUSED"`. If the raw output nests
-  this in `finalCampaignRead` or `finalTableRead`, copy it to canonical
+  `currentStep:"send"` and `campaignStatus:"PAUSED"` for standard and
+  connection-only customer-visible lanes. `send` is the product's paused
+  review step; do not use unsupported aliases such as `review` as final proof.
+  If the raw output nests this in `finalCampaignRead` or `finalTableRead`, copy
+  it to canonical
   `finalPausedSendProof.currentStep` and
   `finalPausedSendProof.campaignStatus`.
 - `verifyCall`: the exact `setup_evergreen_campaigns({ mode:"verify",
@@ -1088,9 +1122,14 @@ plain row generation. The lane worker must inline the same
    approvedGeneratedMessageCount exactly 1. Do not report completion with 2+
    approved rows.
    Approval shorthand: Do not report completion with 2+ approved rows.
-8. Continue to `attach_recommended_sequence({ campaignId, currentStep:"send" })`
-   and, if the campaign is still `DRAFT`, `pause_campaign({ campaignId })`.
-   Reread the campaign/table before claiming completion.
+8. Standard mode: continue to
+   `attach_recommended_sequence({ campaignId, currentStep:"send" })` and, if
+   the campaign is still `DRAFT`, `pause_campaign({ campaignId })`. Reread the
+   campaign/table before claiming completion.
+   Connection-only mode: skip Message Drafting and route-proof approval, call
+   `attach_sequence({ tableId, templateRef:"connection_only", currentStep:"send" })`, prove
+   `sequenceReceipt.actionTypes:["send_invite"]`, and pause/reread without
+   launching or sending.
 
 That packaged worker path must return `messageDraftingReceipt.statusSource:
 "packaged-generate-messages-worker"`. It is accepted only when the receipt
@@ -1515,11 +1554,14 @@ Message, and verify current-revision sample messages before final completion.
      - DM lanes: add a `Delivery format:` line — either `multiline (each paragraph sends as its own DM message)` or `single message`. When multiline, the template's blank-line paragraphs ARE the message boundaries — write each one as a standalone typed message.
      - **InMail lanes can never be multiline**: an InMail is one message and the recipient must reply before anything else can be sent. InMail-bound templates must read as one cohesive message — declare `Delivery format: single message (InMail — no follow-up until reply)` and never structure the copy to depend on multi-message pacing.
 
-   - The sequence is auto-selected by sender tier; do not hand-author sequence
+   - In standard mode, the sequence is auto-selected by sender tier; do not hand-author sequence
      templates here. Sales Nav/Recruiter senders may receive the unified Sales
      Nav cascade through `attach_recommended_sequence`; attaching it does not
      spend paid InMail credits by itself. Do not substitute the manual Paid
      InMail Campaign template.
+     For explicit connection-only evergreen lanes only, use the backend-owned
+     `attach_sequence({ tableId, templateRef:"connection_only", currentStep:"send" })` path and do
+     not call `attach_recommended_sequence`.
 3. **Customer-Visible Completion Contract**: a named evergreen lane that appears
    as a campaign card or campaign-backed table is not done when the shell exists.
    It is done only when the customer can open the campaign and land on final
@@ -1543,7 +1585,7 @@ Message, and verify current-revision sample messages before final completion.
       evergreen setup. Do not leave customer-visible campaigns at
       `filter-choice`, `filter-rules`, or `apply-icp-rubric` and report success.
       Do not proceed to Message Drafting until saved filters are applied.
-   - Message Drafting has run from the current campaign/table basis, using the
+   - In standard mode, Message Drafting has run from the current campaign/table basis, using the
      create-campaign message prompt/assets and validation gate. Updating
      `currentStep:"messages"` is not proof. Parent-thread handwritten copy is
      not a substitute. The proof receipt must show
@@ -1584,6 +1626,9 @@ Message, and verify current-revision sample messages before final completion.
       Fallback samples must still reject source/conversation hedges such as
       `"hope this is relevant"`, `"might be interested"`, or `"saw you in a few
       conversations"`.
+     For explicit connection-only lanes, this whole Message Drafting and sample
+     proof block is not required and must not be faked with parent-written
+     messages.
    - The first review batch exists and at least 3 review rows have generated
      messages from the approved brief. If fewer than 3 usable rows exist, report
      the actual count and why.
@@ -1596,7 +1641,7 @@ Message, and verify current-revision sample messages before final completion.
      completion, approve exactly one quality-valid generated row. If one or more
      rows are already approved, do not add more approvals during evergreen
      completion. Never broad approve all rows.
-    - The recommended tier-aware sequence is attached to the current campaign
+    - In standard mode, the recommended tier-aware sequence is attached to the current campaign
       table, and the watched campaign is on Send. Use
       `attach_recommended_sequence({ campaignId, currentStep:"send" })` when a
       safe attach is needed. After `confirm_lead_list` or any source-list copy,
@@ -1611,6 +1656,10 @@ Message, and verify current-revision sample messages before final completion.
       manual Paid InMail Campaign, and never attach/replace sequence outside the
       current table unless the current lane packet explicitly allowed sequence
       repair.
+      For explicit connection-only lanes, the current campaign table must have
+      exactly the canonical invite-only sequence:
+      `sequenceReceipt.actionTypes:["send_invite"]`. Any DM, InMail, or View
+      Profile action means the lane is not complete.
     - If the current campaign table is still `DRAFT` after sequence/readiness
       proof, call `pause_campaign({ campaignId })` and reread. `pause_campaign`
       is the product-native review-state transition; it is not a launch and does

package/skills/refill-sends/SKILL.md

@@ -196,6 +196,11 @@ rather than asking which campaign class to fill. If a stale target plan selects
 planner before mutation.
 Short form: trust the target plan's inferred lane when it is a connection invite,
 paid-InMail refill lane, or unified Sales Nav cascade.
+Connection-only evergreen campaigns with exact `["send_invite"]` sequence proof
+are plain invite capacity: treat them as `selectedLane:"send_invite"` only. Do
+not infer DM, InMail, Sales Nav cascade, paid-credit refresh, message
+generation, follow-up, sequence mutation, launch/start, scheduling override, or
+direct-send work from a connection-only lane.
 
 Structured planner packet:
 
@@ -271,6 +276,10 @@ need raw proof, call the read-only `get_scheduler_fill_capacity` query for the
 same sender/action/date; it tells the MCP how many cells the product scheduler
 will try to place and does not import, approve, schedule, refresh credits, or
 mutate.
+Treat `rollingWeeklyInvite.capacityFreedDuringWindow:true` as proof that
+rolling-weekly capacity frees later in the send window and remains schedulable;
+use its timing fields instead of treating the window-start gate as a permanent
+full-day blocker.
 When the refill loop has ready rows and needs scheduler pickup now, use
 `run_scheduler_sweep` with the same explicit `workspaceId`; it can place cells
 within existing scheduler gates and returns the receipt, but it never sends or

package/skills/refill-sends-v2/SKILL.md

@@ -62,6 +62,11 @@ for lease expiry; never guess a fence.
 The default `intent:"auto"` inspects `managed_waterfall`,
 `dashboard_evergreen`, and `active_campaign` lane sources. Report the lane
 source and lane chain as proof for every selected sender.
+Connection-only evergreen lanes are invite-only refill targets. When the packet
+or campaign proof shows exactly `["send_invite"]`, report and execute only
+`selectedLane:"send_invite"` work; do not infer DM, InMail, Sales Nav cascade,
+paid-credit refresh, message generation, follow-up, sequence mutation,
+launch/start beyond packet authority, scheduler writes, or direct sends.
 
 If membership blocks a workspace read, report the structured
 `workspace_access` blocker instead of retrying auth or switching workspaces.

package/skills/refill-sends-v2-workflow/SKILL.md

@@ -61,6 +61,13 @@ the repair rung, such as re-run errored enrichment/message cells
 (`start_campaign`). The loop bounds and refuses repair loops; it never invents
 a fix list.
 
+Connection-only evergreen packets are invite-only. If the selected lane or
+campaign proof is exactly `["send_invite"]`, the workflow may refill only
+`selectedLane:"send_invite"` capacity. Do not treat that lane as a DM, InMail,
+Sales Nav cascade, paid-credit refresh, generated-message requirement,
+follow-up branch, sequence-repair task, scheduler write, launch/send, or
+provider-family continuation.
+
 Use plain-language labels first and tokens second, for example "copy leads
 already found into the campaign table (`reconcile_source_copy`)".
 

package/skills/refill-sends-v2-workflow/core/flow.v1.json

@@ -52,6 +52,7 @@
     "awaiting scheduler is not an end state; window-closed reports name remaining-ready, expected pickup time, and resume handle",
     "honest-rubric-fail means a human updates the rubric or changes lead source",
     "source replenishment beyond same-source-automatic is a scoped create-campaign handoff, never refill-owned provider search",
+    "connection-only evergreen lanes with exact [\"send_invite\"] proof are invite-only refill capacity; never infer DM, InMail, Sales Nav cascade, paid-credit refresh, message generation, follow-up, sequence mutation, scheduler writes, launch, or send work from them",
     "no campaign creation, provider-family switch, threshold lowering, scheduler writes, sends, archives, deletes, or brief/filter/message/sequence/sender mutation without a separate approval packet"
   ],
   "requiredBootstrap": [

package/dist/refill-date-window.d.ts

@@ -1,34 +0,0 @@
-export type RefillDateWindowSource = "default_scheduler_forward" | "horizon_send_days" | "until_date" | "target_date";
-export type NormalizedRefillDateSelector = {
-    source: RefillDateWindowSource;
-    targetDate: string | null;
-    untilDate: string | null;
-    horizonSendDays: number | null;
-};
-export type RefillRunDateWindow = NormalizedRefillDateSelector & {
-    version: 1;
-    selectedDates: string[];
-    senderWindows?: Array<{
-        senderId: string | null;
-        timeZone: string | null;
-        selectedDates: string[];
-    }>;
-};
-type DateSelectorInput = {
-    targetDate?: unknown;
-    untilDate?: unknown;
-    horizonSendDays?: unknown;
-};
-export declare function normalizeRefillDateSelector(input: DateSelectorInput): NormalizedRefillDateSelector;
-export declare function refillDateSelectorBody(selector: NormalizedRefillDateSelector): {
-    targetDate?: string;
-    untilDate?: string;
-    horizonSendDays?: number;
-};
-export declare function dateWindowFromSelector(selector: NormalizedRefillDateSelector): RefillRunDateWindow;
-export declare function dateWindowFromPlan(plan: Record<string, unknown>, selector: NormalizedRefillDateSelector): RefillRunDateWindow;
-export declare function dateWindowFromRunState(runState: unknown): RefillRunDateWindow | null;
-export declare function selectorFromDateWindow(window: RefillRunDateWindow): NormalizedRefillDateSelector;
-export declare function dateSelectorMatchesWindow(selector: NormalizedRefillDateSelector, window: RefillRunDateWindow): boolean;
-export declare function schedulerSweepTargetDates(window: RefillRunDateWindow): string[];
-export {};