@sellable/install 0.1.225 → 0.1.226

package/README.md

@@ -96,17 +96,20 @@ Use the same public entrypoints in both hosts:
 
 - Claude Code: `/sellable:create-campaign`
 - Claude Code: `/sellable:create-ab-test`
+- Claude Code: `/sellable:create-evergreen-campaigns`
 - Claude Code: `/sellable:foundation`
 - Claude Code: `/sellable:content`
 - Claude Code: `/sellable:create-post`
 - Codex: `$sellable:create-campaign`
 - Codex: `$sellable:create-ab-test`
+- Codex: `$sellable:create-evergreen-campaigns`
 - Codex: `$sellable:foundation`
 - Codex: `$sellable:content`
 - Codex: `$sellable:create-post`
 - Codex Desktop plugin: `sellable@sellable`
 - Codex visible skill: `Sellable Create Campaign`
 - Codex visible skill: `Sellable Create A/B Test`
+- Codex visible skill: `Sellable Create Evergreen Campaigns`
 - Codex visible skill: `Sellable Foundation`
 - Codex visible skill: `Sellable Content`
 - Codex visible skill: `Sellable Create Post`

package/bin/sellable-install.mjs

@@ -37,7 +37,7 @@ function getInstallVersion() {
   }
 }
 
-const CODEX_PLUGIN_VERSION = "0.1.42";
+const CODEX_PLUGIN_VERSION = "0.1.43";
 const CODEX_PLUGIN_COMPAT_VERSIONS = [
   "0.1.8",
   "0.1.9",
@@ -186,7 +186,8 @@ Options:
 
 Auth:
   Install is auth-free by default. Sign in happens on the first run of
-  /sellable:create-campaign, /sellable:foundation, /sellable:content, or /sellable:create-post in Claude Code or Codex,
+  /sellable:create-campaign, /sellable:create-evergreen-campaigns,
+  /sellable:foundation, /sellable:content, or /sellable:create-post in Claude Code or Codex,
   where the agent walks you through signup or sign-in and stores credentials
   in ~/.sellable/config.json.
 
@@ -212,6 +213,7 @@ function printCreateCommandHint() {
   printAgentBox("Using Claude Code?", "claude", [
     { label: "Campaign", command: "/sellable:create-campaign" },
     { label: "A/B Test", command: "/sellable:create-ab-test" },
+    { label: "Evergreen", command: "/sellable:create-evergreen-campaigns" },
     { label: "Foundation", command: "/sellable:foundation" },
     { label: "Content", command: "/sellable:content" },
     { label: "Post", command: "/sellable:create-post" },
@@ -221,6 +223,7 @@ function printCreateCommandHint() {
   printAgentBox("Using Codex?", "codex", [
     { label: "Campaign", command: "$sellable:create-campaign" },
     { label: "A/B Test", command: "$sellable:create-ab-test" },
+    { label: "Evergreen", command: "$sellable:create-evergreen-campaigns" },
     { label: "Foundation", command: "$sellable:foundation" },
     { label: "Content", command: "$sellable:content" },
     { label: "Post", command: "$sellable:create-post" },
@@ -1021,8 +1024,24 @@ const CREATE_CAMPAIGN_ALLOWED_TOOLS = [
   "mcp__sellable__start_campaign",
 ];
 
+const CREATE_EVERGREEN_CAMPAIGNS_ALLOWED_TOOLS = [
+  ...CREATE_CAMPAIGN_ALLOWED_TOOLS,
+  "mcp__sellable__setup_evergreen_campaigns",
+  "mcp__sellable__get_campaigns",
+  "mcp__sellable__list_tables",
+  "mcp__sellable__get_campaign_waterfall",
+  "mcp__sellable__select_promising_posts",
+  "mcp__sellable__update_cell",
+  "mcp__sellable__pause_campaign",
+  "mcp__sellable__pause_on_demand_campaign",
+  "codex_app.list_projects",
+  "codex_app.create_thread",
+  "codex_app.read_thread",
+  "codex_app.send_message_to_thread",
+];
+
 function allowedToolsYaml(tools) {
-  return tools.map((tool) => `  - ${tool}`).join("\n");
+  return [...new Set(tools)].map((tool) => `  - ${tool}`).join("\n");
 }
 
 function yamlString(value) {
@@ -1760,6 +1779,84 @@ Use \`prepare_campaign_ab_test\` to create clean A/B split lead lists and review
 `, host, "create-ab-test");
 }
 
+function addOrReplaceAllowedTools(markdown, tools) {
+  const allowedToolsBlock = `allowed-tools:\n${allowedToolsYaml(tools)}\n`;
+  if (/^allowed-tools:\n(?:  - .+\n)+/m.test(markdown)) {
+    return markdown.replace(/^allowed-tools:\n(?:  - .+\n)+/m, allowedToolsBlock);
+  }
+  return markdown.replace(/^---\n/m, `---\n${allowedToolsBlock}`);
+}
+
+function createEvergreenCampaignsSkillMd(host = "shared") {
+  try {
+    const here = dirname(fileURLToPath(import.meta.url));
+    const templatePath = join(
+      here,
+      "..",
+      "skill-templates",
+      "create-evergreen-campaigns.md"
+    );
+    if (existsSync(templatePath)) {
+      const publicMarkdown = readFileSync(templatePath, "utf8").replace(
+        /^visibility:\s*internal\s*$/m,
+        "visibility: public"
+      );
+      return stampInstalledHost(
+        addOrReplaceAllowedTools(
+          publicMarkdown,
+          CREATE_EVERGREEN_CAMPAIGNS_ALLOWED_TOOLS
+        ),
+        host,
+        "create-evergreen-campaigns"
+      );
+    }
+  } catch {
+    // fall through to hardcoded fallback below
+  }
+  return stampInstalledHost(`---
+name: create-evergreen-campaigns
+description: Reconcile a sender team's evergreen campaigns idempotently, creating missing standing lanes and completing customer-visible setup without launching or scheduling sends.
+visibility: public
+allowed-tools:
+${allowedToolsYaml(CREATE_EVERGREEN_CAMPAIGNS_ALLOWED_TOOLS)}
+---
+
+# Sellable Create Evergreen Campaigns
+
+Use this as the customer-facing entrypoint for the Sellable
+\`create-evergreen-campaigns\` workflow.
+
+## Bootstrap
+
+MCP prompt access is required. Do not inspect repo files, run shell commands,
+use \`npm\`, \`node\`, local harness scripts, or read local prompt files to
+emulate this workflow.
+
+If the Sellable MCP prompt tools are unavailable, stop and say this is a Codex
+install/reload problem. Tell the user to run
+\`curl -fsSL "https://app.sellable.dev/api/v2/cli/install" | sh\`, fully quit and reopen Codex
+Desktop, then start a new thread.
+
+## Execute Workflow
+
+1. Call \`mcp__sellable__get_auth_status({})\`.
+2. Load the canonical prompt via
+   \`mcp__sellable__get_subskill_prompt({ subskillName: "create-evergreen-campaigns" })\`.
+   If the response has \`hasMore=true\`, continue with \`nextOffset\` until
+   \`hasMore=false\`.
+3. Follow the canonical prompt exactly. The command-backed plan comes from
+   \`mcp__sellable__setup_evergreen_campaigns({ mode: "plan" })\`; mutating
+   setup must return to \`setup_evergreen_campaigns({ mode: "verify" })\` with
+   customer-visible receipts.
+
+## MCP Prompt Fallback
+
+If exact subskill lookup fails, use
+\`mcp__sellable__search_subskill_prompts({ query: "create-evergreen-campaigns", includePublic: true, includeInternal: true })\`,
+then retry \`get_subskill_prompt\`.
+`, host, "create-evergreen-campaigns");
+}
+
 function genericSellableSkillMd({ name, title, description, host = "shared" }) {
   return stampInstalledHost(`---
 name: ${name}
@@ -2209,6 +2306,12 @@ function codexPluginSkills() {
       description: "Create clean A/B campaign review copies",
       skillMd: createAbTestSkillMd(),
     },
+    {
+      dir: "sellable-create-evergreen-campaigns",
+      displayName: "Sellable Create Evergreen Campaigns",
+      description: "Create or repair evergreen campaign lanes without launching sends",
+      skillMd: createEvergreenCampaignsSkillMd(),
+    },
     {
       dir: "sellable-content",
       displayName: "Sellable Content",
@@ -2452,6 +2555,21 @@ function claudeCommands() {
       argumentHint: "[post idea or source material]",
       skillMd: createPostSkillMd(),
     },
+    {
+      name: "create-evergreen-campaigns",
+      title: "Create Evergreen Campaigns",
+      filename: join("sellable", "create-evergreen-campaigns.md"),
+      description: "Create or repair evergreen campaign lanes without launching sends.",
+      argumentHint: "[senders, workspace, and yolo/automation instructions]",
+      skillMd: createEvergreenCampaignsSkillMd("claude"),
+      allowedTools: [
+        "AskUserQuestion",
+        "Task",
+        ...CREATE_EVERGREEN_CAMPAIGNS_ALLOWED_TOOLS.filter(
+          (tool) => !tool.startsWith("codex_app.")
+        ),
+      ],
+    },
   ].map((command) => ({
     ...command,
     content: claudeCommandMd(command),
@@ -3730,6 +3848,7 @@ function printNextSteps(installedHosts, authReused) {
   if (hasClaude) {
     printAgentBox("Using Claude Code?", "claude", [
       { label: "Campaign", command: "/sellable:create-campaign" },
+      { label: "Evergreen", command: "/sellable:create-evergreen-campaigns" },
       { label: "Foundation", command: "/sellable:foundation" },
       { label: "Content", command: "/sellable:content" },
       { label: "Post", command: "/sellable:create-post" },
@@ -3740,6 +3859,7 @@ function printNextSteps(installedHosts, authReused) {
   if (hasCodex) {
     printAgentBox("Using Codex?", "codex", [
       { label: "Campaign", command: "$sellable:create-campaign" },
+      { label: "Evergreen", command: "$sellable:create-evergreen-campaigns" },
       { label: "Foundation", command: "$sellable:foundation" },
       { label: "Content", command: "$sellable:content" },
       { label: "Post", command: "$sellable:create-post" },
@@ -4029,10 +4149,12 @@ async function main() {
       }
       console.log(`  Continue in your agent:`);
       console.log(`    Claude Code: /sellable:create-campaign`);
+      console.log(`    Claude Code: /sellable:create-evergreen-campaigns`);
       console.log(`    Claude Code: /sellable:foundation`);
       console.log(`    Claude Code: /sellable:content`);
       console.log(`    Claude Code: /sellable:create-post`);
       console.log(`    Codex: $sellable:create-campaign`);
+      console.log(`    Codex: $sellable:create-evergreen-campaigns`);
       console.log(`    Codex: $sellable:foundation`);
       console.log(`    Codex: $sellable:content`);
       console.log(`    Codex: $sellable:create-post`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.225",
+  "version": "0.1.226",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-evergreen-campaigns.md

@@ -0,0 +1,737 @@
+---
+name: create-evergreen-campaigns
+description: Reconcile a sender team's evergreen campaigns — create-or-reuse the standing campaigns (per-sender post engagers + shared signal/cold lanes) idempotently, and when asked for customer-ready/full setup, complete each customer-visible campaign to paused send review with brief, rows, generated review messages, one approval gate row, and sequence. Never duplicates, never launches.
+visibility: internal
+---
+
+# Create Evergreen Campaigns
+
+<role>
+You are a campaign structure reconciler. Evergreen campaigns are the standing
+always-on lanes every sender should have. Your job is to make reality match the
+plan — creating only what is missing, reusing everything that exists, and never
+producing duplicates. This skill never launches campaigns; customer-visible
+completion stops at paused send review.
+</role>
+
+<inputs>
+The invoking prompt names the senders ("create evergreen campaigns for csreyes92 and thomas"). Resolve each via `list_senders`.
+
+If the invoking prompt says scheduled, automation, cron, heartbeat, fresh-thread,
+run without user input, or similar, run in **automation mode**:
+
+- Do not ask the user to confirm templates, delivery format, or sample output.
+- Reconcile structure and record any template/config polish as `created`,
+  `reused`, `repaired`, `flagged`, or `blocked`.
+- Choose the automation depth from the invoking prompt:
+  - **Structure-only reconcile** is for heartbeat prompts that only say to
+    ensure slots exist. It may create/reuse shells and apply metadata repairs,
+    but it does not create rows, generate messages, approve rows, or attach new
+    send work.
+  - **Customer-visible completion** is required when the prompt says full
+    campaign, customer-ready, send-review-ready, went through
+    `$sellable:create-campaign`, fill out, approve one, only needs enrich and
+    approve more, or similar. For every dashboard campaign card in that mode,
+    mirror the create-campaign completion path: brief -> source rows -> filter
+    decision -> Message Drafting -> first review batch -> generated messages ->
+    sender/settings validation -> recommended sequence -> `currentStep:"send"`.
+    This mode may create/copy bounded rows, generate review messages, approve
+    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.
+
+If the invoking prompt explicitly asks for interactive message polish or sample
+proof, run in **interactive polish mode** and use the confirmation/sample steps
+below.
+
+Default evergreen plan per workspace (override only if the prompt specifies different lanes):
+
+1. **`<Sender Name> - Post Engagers`** — one per sender (warm lane, highest priority)
+2. **`<Workspace/Team> - Shared Signal Discovery`** — one shared warm-signal campaign lane across senders
+3. **`<Workspace/Team> - Shared Cold Fallback`** — one shared cold/fallback campaign lane across senders
+</inputs>
+
+<command_backed_workflow>
+For full/customer-visible setup, the first operational command is always
+`setup_evergreen_campaigns({ mode:"plan", yolo })`. Inventory can happen first
+for operator understanding, but do not create/reuse/repair campaign shells,
+source rows, messages, sequence, approvals, or cleanup before the command-backed
+plan returns lane packets.
+If `setup_evergreen_campaigns` is unavailable, returns 404, throws an API
+error, or does not return a current `planRevision` with lane packets, stop
+immediately with `blocked: setup_evergreen_campaigns_unavailable`. Do not fall
+back to ad hoc create-campaign calls, inventory-only guesses, or direct shell
+creation when the command-backed plan is missing.
+
+MCP/product-visible proof only: every success claim must be observable through
+the installed Sellable MCP tools and product-visible readbacks a normal user or
+agent can access. Do not inspect the product database directly to prove success.
+Direct SQL, Prisma, or DB snapshots are diagnostic only; they are not success proof for command completion. Receipts must cite MCP tool calls, command
+responses, prompt/asset loads, and product-visible readbacks such as campaign
+context, campaign message preview, table rows, cell selectors, sequence
+readback, and setup plan/verify results. If MCP surfaces disagree on counts or
+state, record the discrepancy and resolve or explain the canonical gate before
+reporting the command complete.
+
+Package-backed prompt authority: when this command or any lane worker says to
+load `$sellable:create-campaign`, `create-campaign-v2`, `generate-messages`, or
+any referenced workflow asset, the package-backed MCP loaders are the source of
+truth. Use `get_subskill_prompt` and `get_subskill_asset` until `hasMore:false`.
+Do not locate, open, read, or summarize local skill files from repo paths,
+installed plugin cache paths, or any filesystem shortcut. Do not use repo-local,
+plugin-cache, or filesystem `SKILL.md` files as workflow authority, even when a
+session header shows a path. If package-backed prompt or asset loaders are not
+callable, stop with `blocked: package_prompt_loader_unavailable`; filesystem
+prompt fallback is a failed UAT and is not proof that the packaged command works.
+Short form: Do not use repo-local, plugin-cache, or filesystem `SKILL.md`.
+Short form: filesystem prompt fallback is a failed UAT.
+
+Package-backed tool surface: use `mcp__sellable` only for workspace selection,
+campaign/table/source/message mutations, and product-visible readbacks. Do not
+use `mcp__sellable_admin`, admin workspace setters, direct DB tools, Prisma, or
+SQL as part of command execution proof. Before any worker mutation, record
+normal-surface workspace proof with
+`set_active_workspace({ workspaceId, userConfirmed:true })` or the equivalent
+`mcp__sellable` call, then reread the active workspace.
+Short form: mcp__sellable only.
+Short form: Do not use `mcp__sellable_admin`.
+
+Plan shape:
+
+- one Post Engagers lane per sender in the **Post Engagers sender scope**;
+- one shared Signal Discovery lane for the **shared lane sender scope**;
+- one shared Cold Fallback lane for the **shared lane sender scope**;
+- explicit existing campaign/table bindings when the user points at a canonical
+  lane. Pass those exact ids to the plan and reuse/verify them instead of
+  creating duplicates.
+- If a user supplies canonical ids, reuse/verify them instead of creating duplicates.
+
+The command-backed unbound plan is authoritative. If
+`setup_evergreen_campaigns({ mode:"plan", ... })` returns a lane packet with
+`intent:"create"`, execute that create packet exactly. Do not convert it into an
+explicit binding because `list_tables`, `get_campaigns`, a waterfall, or old
+inventory shows an `ARCHIVED` campaign/table with a matching name. Archived
+campaigns are not reusable evergreen targets. Only pass an archived
+campaign/table as an explicit binding when the user supplied those exact ids and
+explicitly allowed dashboard visibility repair; otherwise ignore archived
+matches for execution and let the create packet proceed.
+
+Use `selectedSenderIds` only as a legacy shorthand when the same senders should
+get sender-owned Post Engagers lanes and attach to shared lanes. When the scopes
+differ, pass both explicit arrays:
+
+- `postEngagerSenderIds`: only senders that should have sender-owned Post
+  Engagers campaigns.
+- `sharedSenderIds`: senders attached to the shared Signal Discovery and Shared
+  Cold Fallback campaigns.
+
+If the operator says a sender is shared-only, do not create a Post Engagers lane
+for that shared-only sender. Example: if Justin already has a Post Engagers
+campaign and Jell/Hulan should only participate in the two shared campaigns,
+call `setup_evergreen_campaigns` with `postEngagerSenderIds:["<justin id>"]`
+and `sharedSenderIds:["<justin id>","<jell or hulan id>"]`.
+
+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.
+If the operator says all connected senders for both scopes, pass
+`allConnectedSenders` and let the command return exact selected sender ids or
+blockers.
+
+`--yolo` is supported, but it is a safety-scoped execution mode, not a cleanup
+or launch permission. With `--yolo`, pass `yolo:true` to
+`setup_evergreen_campaigns({ mode:"plan", yolo })` and proceed without
+intermediate approval only when every selected lane packet returns
+`autoExecutable:true`. `--yolo` does not authorize archive/delete cleanup,
+launch/start, schedule/send, broad approve-all, wrong workspace work, stale
+plan execution, paid InMail spend, or ambiguous target choice. Stop on wrong
+workspace, cleanup/archive/delete need, stale plan, disconnected sender,
+duplicate candidate, unsafe side effect, missing source proof, or missing
+message proof.
+
+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
+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
+are within the lane packet, approved caps, approved side-effect classes, and
+route-proof approval policy. Stop and re-plan if any fresh reread changes the
+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 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.
+
+After bounded delegated approval or safe `--yolo`, fan out lane worker tasks
+only from the current plan. Each worker receives the complete lane packet:
+workspace id, sender ids, lane key/type, existing campaign/table binding or
+create intent, source hints, caps, planRevision, actionId, allowed side effects,
+postconditions, and the packet's `workerDispatch` policy. Treat
+`workerDispatch.requiresVisibleThreadOrDurableReceipt:true` as a hard
+execution boundary, not guidance. Read and preserve `workerDispatch.acceptedRuntimes`,
+`workerDispatch.rejectedRuntimes`, and `workerDispatch.receiptArtifactHint`
+before dispatch.
+
+Worker-local replans are read-only drift checks, never a replacement execution
+basis. The parent planRevision, selectedActionIds, actionId, laneKey, workspace
+id, and sender scopes remain authoritative for the worker receipt. If a worker
+calls `setup_evergreen_campaigns({ mode:"plan", ... })` before mutation, that
+call must include the exact original sender scopes from the parent plan,
+including `postEngagerSenderIds:[]` when the Post Engagers scope is intentionally
+empty, and the exact `sharedSenderIds` array. If a worker-local plan omits
+`postEngagerSenderIds:[]`, changes `sharedSenderIds`, returns a different
+planRevision/actionId/laneKey, or introduces any Post Engagers lane outside the
+parent packet, do not mutate and do not use it as `setupPlanCall` proof; stop
+with `blocked: worker_plan_scope_drift` and ask the parent to re-plan.
+Short form: If a worker-local plan omits `postEngagerSenderIds:[]`, do not use it as `setupPlanCall` proof.
+Short form: stop with `blocked: worker_plan_scope_drift`.
+
+Worker fan-out must use visible or durable execution. Preferred in local Codex
+is a visible Codex thread created with the actual Codex app thread tools:
+first call `codex_app.list_projects`, select the current repo project, then
+call `codex_app.create_thread` with `target:{type:"project", projectId,
+environment:{type:"local"}}`. Do not create a worktree target for evergreen
+UAT or lane execution. The parent must record the returned thread id, pass
+exactly one lane packet into that thread, and require the worker to write the
+lane receipt at the artifact path named by
+`workerDispatch.receiptArtifactHint`. A streaming worker or branch worker is
+acceptable only when it writes a durable per-lane receipt artifact as it works.
+`multi_agent_v1.spawn_agent`, raw `spawn_agent`, or any opaque Task/subagent
+runtime that cannot expose a visible thread id or durable receipt artifact is
+not accepted as command-level UAT proof and must not be used for mutating
+evergreen setup.
+
+Run this preflight before the first irreversible product mutation in any lane:
+the parent must have recorded either a visible Codex thread id or a durable
+`receiptArtifactPath` for that lane. If the runtime cannot provide this, stop
+with `blocked: missing_visible_or_durable_lane_worker_runtime` before calling
+`create_campaign`, `update_campaign`, `import_leads`, `confirm_lead_list`, or
+any source/message/sequence mutation. Do not downgrade this to
+`missing_parallel_lane_worker_runtime` when an opaque runtime exists: an
+opaque runtime is still missing visible/durable proof. If a worker creates
+partial product state without receipts, the run is blocked; created objects exist
+is not equivalent to command completion.
+
+Workers must explicitly load and use the installed visible
+`$sellable:create-campaign` wrapper as the nested workflow entrypoint, then
+load `create-campaign-v2` and `create-campaign-v2/core/flow.v2.json` through
+the packaged MCP prompt/asset loaders before campaign creation or repair. The
+worker then uses that create-campaign workflow/subskills for campaign
+creation/setup, source/import, filter choice, Message Drafting, packaged
+`generate-messages`, sequence attachment, and send-review readiness. Do not
+rebuild those steps ad hoc in the parent thread or from a copied receipt
+checklist. The parent thread is only the planner, dispatcher, verifier, and
+receipt collector: it must not call `create_campaign`, `import_leads`,
+`start_campaign_message_preparation`, `update_cell`, or sequence-attach tools
+for a lane that was assigned to a worker. When the host supports visible Codex
+threads, branch execution with durable receipts, or a streaming durable worker,
+assign one lane packet per worker and run the lane workers in parallel. If the
+host cannot run parallel workers with visible/durable receipts, report
+`blocked: missing_visible_or_durable_lane_worker_runtime` instead of silently
+doing all lane creation sequentially in the parent thread.
+Short form: the parent thread is the planner, dispatcher, verifier, and receipt collector.
+Before the first mutating lane action, complete an execution-runtime preflight:
+name the callable worker surface/tool that will run lane packets and the proof
+it gives (`thread id`, `receiptArtifactPath`, or both). If you cannot name a
+real callable visible/durable worker runtime, stop with
+`blocked: missing_visible_or_durable_lane_worker_runtime` before calling
+`create_campaign`, `update_campaign`, `import_leads`, `confirm_lead_list`, or
+any source/message/sequence mutation. Creating campaign shells first and then
+discovering the worker runtime is missing is a failed run.
+Legacy reports may mention `blocked: missing_parallel_lane_worker_runtime`;
+for new command runs, use the visible/durable blocker above.
+
+For any lane with `intent:"create"`, the worker must satisfy the normal
+net-new create-campaign preflight before shell creation: load
+`get_subskill_prompt({ subskillName:"research-sender" })`, run the sender/team
+identity research needed for the brief, call `complete_sender_research(...)`,
+then call `create_campaign`. Do not bypass this with a parent-thread brief or
+by directly setting campaign state.
+
+Workers return worker receipts. Each customer-visible lane receipt must include
+one durable `createCampaignStepReceipt` built from actual tool calls or worker receipts,
+not a parent-thread summary. The receipt must include:
+
+- `setupPlanCall`: the exact `setup_evergreen_campaigns({ mode:"plan", ... })`
+  planRevision, selected actionId, lane key, workspace id, sender ids, and
+  campaign/table binding or create intent used before work started. For a
+  create lane, this receipt must explicitly include `createIntent:true`; for a
+  reuse lane, do not report `createIntent:true`. The object must use the
+  canonical keys `planRevision`, `actionId`, `laneKey`, `workspaceId`,
+  `senderIds`, `campaignId`, `tableId`, and `createIntent`. Do not use
+  `laneActionId`, `lanePacketActionId`, `delegatedPlanRevision`,
+  `delegatedActionId`, or freeform `requestedCall` text as a substitute for
+  these fields.
+- `createCampaignWorkflowReceipt`: proof the worker loaded the actual installed
+  `$sellable:create-campaign` wrapper instead of doing ad hoc MCP calls. It 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`, the real `workerRuntime`, a visible
+  `workerThreadId` or durable `receiptArtifactPath`, `durableReceiptWritten:true`
+  when using a receipt file, and `notAdHoc:true`.
+- `researchSenderReceipt`: `research-sender` prompt load proof,
+  `complete_sender_research` result, sender LinkedIn identity basis, and the
+  notes/proof counts used before the net-new `create_campaign` call.
+- `campaignBriefReceipt`: the CampaignOffer/campaign id, current
+  workflowTableId, brief hash or updated-at marker, delivery format, token
+  rules, hard avoids, source-use rules, and first-message template state.
+- `sourceDecisionReceipt`: selected source/list id, provider, cursor/inventory
+  state, import/copy caps, explicit `dedupeDncProviderExclusions:true` or an
+  equivalent exclusions object, row ids or row-count evidence (`rowCount`,
+  `readyRowCount`, or `rowEvidence`), and the reason no colder source was used
+  before the current source was proven exhausted or insufficient.
+- `filterDecisionReceipt`: saved/applied filter ids or explicit skip-filter
+  decision with current campaign/table basis.
+- `messageDraftingReceipt`: the Message Drafting proof described below,
+  including packaged `generate-messages` prompt/assets and validation.
+- `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.
+- `sequenceReceipt`: exact current workflowTableId, recommended non-paid
+  sequence attach/precheck result, and readback showing `hasSequence:true` when
+  completion is claimed.
+- 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"`.
+- `verifyCall`: the exact `setup_evergreen_campaigns({ mode:"verify",
+  planRevision, selectedActionIds, receipts })` call/result used before the
+  parent reports completion.
+
+Before writing the durable receipt, run a receipt self-check. The top-level
+receipt must include top-level `planRevision`, `actionId`, `laneKey`,
+`laneType`, `workspaceId`, and `senderIds`, plus campaign/table/source ids and
+row/message/approval counts. Inside
+`createCampaignStepReceipt.messageDraftingReceipt`, `sampleMessages[]` must
+include `rowId`, `generatedMessageText`, `verdict`, and `issues`. Do not
+substitute `message` for `generatedMessageText`. Do not substitute
+`passVerdict` for `verdict`. If the self-check fails, fix the receipt before
+ending; do not leave the parent to infer canonical fields from top-level
+aliases or narrative text.
+Self-check shorthand: top-level `planRevision`, `actionId`, `laneKey`, `laneType`, `workspaceId`, and `senderIds` must exist before worker completion.
+Self-check shorthand: `sampleMessages[]` must include `rowId`, `generatedMessageText`, `verdict`, and `issues`.
+Self-check shorthand: Do not substitute `message` for `generatedMessageText`.
+Self-check shorthand: Do not substitute `passVerdict` for `verdict`.
+Self-check shorthand: If the self-check fails, fix the receipt before ending.
+
+Use these canonical receipt leaf names exactly. Do not substitute looser aliases
+like `generateMessagesPromptLoad`, `requiredAssetLoads`,
+`validationPromptLoad`, `reviewBatchBasisHash`, `reviewRowIds`,
+`sequenceActionTypes`, or `pass:true` unless you also include the canonical
+fields below:
+
+The receipt status must be `status:"succeeded"` or `status:"completed"` when
+the lane is complete. Do not use `status:"passed"` or
+`status:"passed_with_warnings"` as the primary success status. Warnings may go
+in a separate `warnings` array, but the completion status stays canonical.
+The backend verifier rejects `status:"passed"`, `status:"pass"`, and
+`status:"passed_with_warnings"` as primary completion statuses.
+
+All step proof objects must live under `createCampaignStepReceipt`. Do not put
+`createCampaignWorkflowReceipt`, `campaignBriefReceipt`,
+`sourceDecisionReceipt`, `filterDecisionReceipt`, `messageDraftingReceipt`,
+`reviewBatchReceipt`, or `sequenceReceipt` only as top-level siblings;
+top-level copies are useful for humans but are not enough for command
+verification unless the same object also appears inside
+`createCampaignStepReceipt`.
+
+```json
+{
+  "status": "succeeded",
+  "planRevision": "<original planRevision>",
+  "laneKey": "<lane key>",
+  "laneType": "<lane type>",
+  "workspaceId": "<workspace id>",
+  "senderIds": ["<sender id>"],
+  "campaignId": "<campaign id>",
+  "tableId": "<workflow table id>",
+  "createCampaignStepReceipt": {
+    "createCampaignWorkflowReceipt": {
+      "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": "separate-codex-thread",
+      "workerThreadId": "<visible local Codex thread id>",
+      "receiptArtifactPath": ".planning/artifacts/uat/69/lane-receipts/<planRevision>/<actionId>-<laneKey>.json",
+      "durableReceiptWritten": true,
+      "notAdHoc": true
+    },
+    "campaignBriefReceipt": {
+      "campaignId": "<campaign id>",
+      "workflowTableId": "<workflow table id>",
+      "briefHash": "<brief/currentApprovedBriefHash>",
+      "deliveryFormat": "single message",
+      "tokenRules": true,
+      "hardAvoids": true,
+      "sourceUseRules": true,
+      "firstMessageTemplate": "<template or template state>"
+    },
+    "sourceDecisionReceipt": {
+      "sourceId": "<source id>",
+      "sourceListId": "<source/list id>",
+      "cursorOrInventoryState": "<cursor/inventory/import state>",
+      "dedupeDncProviderExclusions": true,
+      "sourceLadderReason": "<why the current source is valid before colder sources>"
+    },
+    "filterDecisionReceipt": {
+      "status": "skipped",
+      "workflowTableId": "<workflow table id>"
+    },
+    "messageDraftingReceipt": {
+      "statusSource": "branch",
+      "promptLoadedToHasMoreFalse": true,
+      "requiredAssetsLoaded": true,
+      "validationLoaded": true,
+      "validationResult": "passed",
+      "qualityReview": {"passed": true, "checkedSampleCount": 3, "issues": []},
+      "campaignId": "<campaign id>",
+      "workflowTableId": "<workflow table id>",
+      "selectedLeadListId": "<source/list id>",
+      "reviewBatchRowHash": "<review row ids hash>",
+      "messageDraftRecommendation": {"basis": "generate-messages"},
+      "sampleMessages[].verdict": "pass",
+      "sampleMessages": [
+        {"rowId": "<row id>", "generatedMessageText": "<message>", "verdict": "pass"}
+      ]
+    },
+    "reviewBatchReceipt": {
+      "rowIdsHash": "<review row ids hash>",
+      "generatedCount": 3
+    },
+    "sequenceReceipt": {
+      "workflowTableId": "<workflow table id>",
+      "hasSequence": true,
+      "sequenceReceipt.actionTypes": ["send_invite"],
+      "sequenceReceipt.nonPaid": true,
+      "actionTypes": ["send_invite"],
+      "nonPaid": true
+    },
+    "finalPausedSendProof": {
+      "currentStep": "send",
+      "campaignStatus": "PAUSED"
+    },
+    "verifyCall": {
+      "mode": "verify",
+      "planRevision": "<original planRevision>",
+      "selectedActionIds": ["<all original selected action ids>"]
+    }
+  }
+}
+```
+
+Verification always uses the original execution planRevision and original
+selectedActionIds from the plan packets that were dispatched before mutation.
+The parent must preserve the original selectedActionIds exactly.
+Do not replace them with a later reuse planRevision/actionIds after the
+campaigns exist. After workers complete, attach or patch `verifyCall` on each
+lane receipt with that original execution planRevision, original
+selectedActionIds, same sender scopes, and the verify result. Only after verify
+succeeds should the parent perform the idempotency rerun.
+
+If any required field is missing, report
+`blocked: missing_create_campaign_step_receipt` for that lane and do not call it
+complete.
+If `createCampaignWorkflowReceipt.workerRuntime` is
+`multi_agent_v1.spawn_agent`, `spawn_agent`, or another opaque worker runtime,
+or if it lacks both `workerThreadId` and a durable receipt artifact proof, treat
+the lane as `blocked: missing_create_campaign_step_receipt` with detail
+`createCampaignWorkflowReceipt.workerRuntime.visible_or_durable`; do not call
+verify and do not repair by summarizing product readback in the parent.
+
+Message Drafting runtime rule: the preferred proof source is the normal
+create-campaign branch handoff (`watchNarration.workerDetails.messageDraftBuilder`
+or equivalent) with `statusSource:"branch"`. If that internal branch handoff is
+not callable or not exposed in the packaged MCP runtime, do **not** stop after
+creating/importing rows. The lane worker must run the packaged message-drafting
+path itself in the worker thread:
+
+1. Load `get_subskill_prompt({ subskillName:"generate-messages" })` until
+   `hasMore:false`.
+2. Load the required message assets and `create-campaign-v2-validation`.
+3. Call `start_campaign_message_preparation({ campaignId, tableId,
+   targetPreparedMessages, maxRowsToCheck, approvalMode:"mark_ready",
+   autoContinue:true })` inside the same lane worker, with bounded caps from the
+   lane packet.
+   Never call `start_campaign_message_preparation` with `approvalMode:"approve"`
+   for evergreen setup. Generate/readiness and approval are separate safety
+   steps: first mark rows ready, then inspect generated copy, then approve
+   exactly one semantic Approved cell through `select_campaign_cells` and
+   `update_cell`.
+   Approval shorthand: approve exactly one semantic Approved cell.
+4. Poll `get_campaign_message_preparation_status` until no queued/active cells
+   remain or a bounded stop reason is returned.
+5. Use `get_campaign_messages_preview` or `select_campaign_cells` to inspect
+   generated rows, quality-review at least 3 samples, approve exactly one
+   quality-valid route-proof row when none is already approved, and prove no
+   broad approve-all happened.
+   If a packaged worker or earlier run left more than one generated row
+   approved, set any extra approved cells back to false through semantic
+   Approved-cell selection before completion. Final proof must show
+   approvedGeneratedMessageCount exactly 1. Do not report completion with 2+
+   approved rows.
+   Approval shorthand: Do not report completion with 2+ approved rows.
+6. 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.
+
+That packaged worker path must return `messageDraftingReceipt.statusSource:
+"packaged-generate-messages-worker"`. It is accepted only when the receipt
+includes the same prompt/assets/validation proof, current campaign/table/source
+basis, generated review rows, sample messages, quality review, route-proof
+approval evidence, sequence proof, and final paused-send proof required of the
+branch handoff. `statusSource:"parent-thread-fallback"` is still invalid.
+The only accepted statusSource values are exactly `branch` and
+`packaged-generate-messages-worker`; descriptive aliases such as
+`package-readback-local-thread` are rejected.
+
+One lane may produce exactly one CampaignOffer/campaign id and one current
+workflow table id. For `intent:"create"`, the first successful
+`create_campaign` result establishes the lane's only allowed campaign/table
+target. Every later source/import/confirm/message/filter/sequence/readback call
+must use that same campaign id and current workflow table id. If any tool
+returns or creates a different CampaignOffer, workflow table, "Campaign from
+Source" campaign, or shell for the same lane, stop immediately with
+`blocked: duplicate_campaign_offer_created`, include both ids in the receipt,
+and do not report completion. Do not hide the earlier shell by reporting only
+the later imported campaign.
+
+Each customer-visible lane receipt must also include message proof from
+`watchNarration.workerDetails.messageDraftBuilder`, the worker's equivalent
+branch handoff record, or the packaged message-prep worker path above. Valid
+evergreen message proof names the current campaign id, workflowTableId,
+selected lead-list or source id, filter choice, and review-batch row ids/hash,
+and it must use `statusSource:"branch"` or
+`statusSource:"packaged-generate-messages-worker"`.
+`statusSource:"parent-thread-fallback"` is not accepted for evergreen
+customer-visible completion because it can be a parent summary rather than proof
+that the create-campaign Message Drafting branch actually ran. The proof must
+show the worker loaded the full packaged prompt with
+`get_subskill_prompt({ subskillName:"generate-messages"` until `hasMore:false`,
+loaded the required message assets, and loaded `create-campaign-v2-validation`
+before returning a `messageDraftRecommendation`.
+The receipt must also include `validationResult:"passed"`, a passed
+quality-review object, and at least 3 concrete reviewed sample messages with
+row ids, generated message text, pass verdicts, and no issues. Shared Cold
+Fallback samples must not open with a standalone name line followed by
+"Hey there" or another generic greeting; that pattern means the lane did not
+finish the create-campaign message workflow to customer quality.
+Shared Signal Discovery samples must not use sender-owned post-engager language
+such as "my post", "thanks for showing support", "saw you pop up", or any copy
+that implies the sending sender authored the source post or personally received
+the prospect's engagement unless the selected source evidence proves that exact
+sender authored the post.
+The generated-message cells are not prompt proof: `currentRevisionGeneratedMessages`,
+Generate Message column counts, `messagesCount`, or rendered row previews prove
+only that table cells exist from the current brief/template, not that the
+create-campaign Message Drafting branch ran. If this receipt is missing, report
+`blocked: missing_message_drafting_receipt` and do not call the lane complete.
+
+The parent then calls
+`setup_evergreen_campaigns({ mode:"verify", postEngagerSenderIds,
+sharedSenderIds, planRevision, selectedActionIds, receipts })` using the same
+sender scopes as the plan call and the original execution planRevision/actionIds,
+and reports only verified completion. A verify call without the same sender scopes can recompute an empty or different plan and is invalid proof. A verify call that uses a later reuse planRevision instead of the original execution planRevision is also invalid proof. Only after verify succeeds, rerun
+`setup_evergreen_campaigns({ mode:"plan", postEngagerSenderIds,
+sharedSenderIds, yolo:true })` without explicit campaign/table bindings. That
+idempotency rerun must return `intent:"reuse"` for every completed lane and no
+duplicate-lane blockers before you call the command finished. If verify blocks,
+report the blocker and repair only the missing postconditions from the same
+current plan.
+
+Message proof for every customer-visible lane must come from the current
+campaign/table basis and include at least 3 generated review rows from the
+packaged `generate-messages` path before completion is reported.
+Parent-thread handwritten copy or setting `currentStep` is not proof.
+</command_backed_workflow>
+
+<objective>
+1. **Inventory first**: `get_campaigns` + `list_tables` + `get_campaign_waterfall` in the active workspace. Treat `list_tables` and the managed waterfall as authoritative for older managed slots; `get_campaigns` is a recent campaign page and may miss canonical evergreen lanes. Match existing campaigns/tables/waterfall slots to the plan by name (case-insensitive, ignore suffixes like "(Copy)") and stored slot identity. `list_tables.campaignStatus` and `list_tables.dashboardBucket` are part of the identity check: a matching `ARCHIVED` table/campaign is not a plain `REUSE`. If it is the canonical prod slot and the invocation explicitly allows dashboard visibility repair, repair it to `PAUSED`; otherwise mark it `flagged`/`blocked` and do not create a duplicate. A matching non-archived campaign/table/waterfall slot = REUSE; record it and move on. Never create a second campaign for a slot that already has one in any of those inventories.
+2. **Create only the missing slots** through the full `$sellable:create-campaign`
+   workflow path for each lane, using the lane packet as the setup basis:
+   - Post Engagers lanes: that sender's ID only. Shared lanes: all the senders' IDs.
+   - The brief and message direction are lane-specific. Never reuse the Post
+     Engagers opening for Shared Cold Fallback.
+   - **Post Engagers** first-message style: short, casual, references the
+     sender-authored post they engaged with, closed question, **no internal
+     vocabulary, no pitch, no meeting ask** in message one:
+
+     ```
+     {{first_name}}
+
+     Hey there
+
+     Saw you pop up on my post about {{post_topic_line}}
+     ```
+
+   - **Shared Signal Discovery** first-message style: short, casual, references
+     the real observed signal/theme or public conversation. It may mention the
+     engagement source only when the source evidence supports it. Do not say
+     "my post" unless the selected source post was actually authored by the
+     sending sender. Do not thank the prospect for showing support, reacting,
+     commenting, or popping up unless this is a sender-owned Post Engagers lane
+     with sender-authored source evidence.
+   - **Shared Cold Fallback** first-message style: cold, direct, and cohesive.
+     It must not pretend there was engagement, must not say "saw you pop up",
+     and must not use a standalone name line followed by "Hey there" or other
+     generic greeting. It should open with a light role/company/problem
+     observation, avoid awkward phrases like "looks like a team where", and ask
+     one clear problem question. This is a single-message
+     cold path unless the approved create-campaign message workflow proves a
+     better delivery format.
+   - Every customer-visible lane must run Message Drafting from the current
+     campaign/table basis after source rows exist. The worker must load the full
+     packaged `generate-messages` prompt, every required asset, and
+     `create-campaign-v2-validation`; if the internal branch handoff is not
+     callable in the packaged runtime, the worker must call
+     `start_campaign_message_preparation` and poll
+     `get_campaign_message_preparation_status` from the lane worker. The
+     returned receipt must include `statusSource:"branch"` or
+     `statusSource:"packaged-generate-messages-worker"`, at least 3 concrete
+     reviewed sample messages, a passed validation result, and a passed quality
+     review. Row/message counts alone are not enough.
+
+   - **The brief must declare the delivery format** so Generate Message writes copy suited to how it actually sends:
+     - 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 templates here. Never select a paid-InMail template.
+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
+   send review with all setup state present:
+   - `currentStep:"send"`.
+   - The linked workflow table has `campaignStatus:"PAUSED"`; `ACTIVE` means
+     already launched and must be reported separately, and `ARCHIVED` must be
+     repaired only when the prompt explicitly allows dashboard visibility repair.
+   - A full campaign brief exists, including delivery format, token rules,
+     hard avoids, source-use rules, and the approved first-message template.
+   - A source/list decision has been resolved and campaign rows are loaded. If
+     there is no approved source or no rows can be copied, report `blocked` with
+     the missing source detail; do not call the campaign complete.
+   - The filter step is resolved: either saved/applied filters are present, or
+     the campaign explicitly skipped filters. Do not leave customer-visible
+     campaigns at `filter-choice`, `filter-rules`, or `apply-icp-rubric` and
+     report success.
+   - 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
+     `get_subskill_prompt({ subskillName:"generate-messages"` was loaded until
+     `hasMore:false`, required message assets were loaded, and
+     `create-campaign-v2-validation` ran through
+     `workerDetails.messageDraftBuilder` with `statusSource:"branch"` or
+     through the lane worker's packaged message-prep path with
+     `statusSource:"packaged-generate-messages-worker"`,
+     `start_campaign_message_preparation`, and
+     `get_campaign_message_preparation_status`. The generated-message cells are
+     not prompt proof; `currentRevisionGeneratedMessages` and row previews are
+     only downstream cell evidence. The proof must include
+     `validationResult:"passed"`, a passed quality review, and at least 3
+     reviewed sample messages. For Shared Cold Fallback, reject samples that
+     open with a standalone name followed by "Hey there" or a similarly generic
+     greeting.
+   - 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.
+     If a bounded preparation job requested more than the minimum but already
+     met the minimum generated-message floor, do not stall on a single bad review row once a fresh status/readiness check shows no queued, processing, or active cells; record the shortfall, name the failed/empty-row reason when
+     available, and continue with route-proof review rather than expanding source
+     or waiting forever.
+   - At least one generated row is approved as a route-proof gate. If zero rows
+     are approved and the prompt explicitly asked for full/customer-ready
+     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 non-paid 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,
+     immediately reread `get_campaign({ campaignId })`; the returned
+     `workflowTableId` is the current campaign table. Cross-check that exact
+     current workflowTableId with `list_tables` and require `hasSequence:true`
+     before reporting completion. If a stale shell table has sequence columns but
+     the current campaign table does not, `SEQUENCE_EXISTS` is not enough:
+     record the stale shell table id, then repair the current workflowTableId
+     with `attach_sequence` using the same non-paid product template
+      `attach_recommended_sequence` would have selected. Never use a paid-InMail
+      template and never attach/replace sequence outside the current table unless
+      the current lane packet explicitly allowed sequence repair.
+    - 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
+      not schedule or send. Never raw-write campaign status.
+    - No scheduled, queued outbound, sent outbound, campaign launch, or paid
+      InMail spend is created by this skill.
+4. **Verify each slot** after create/reuse/repair:
+   - `get_campaign` shows the campaign exists, remains unlaunched, and has the expected workflow table.
+   - Builder truth must match dashboard truth. `currentStep:"running"` is valid only when the linked table has `campaignStatus:"ACTIVE"`. For a `PAUSED` or `ARCHIVED` campaign/table, repair or flag stale `currentStep:"running"` back to launch review (`send` / review-ready) before reporting the slot done. Never call `start_campaign` just to make a stale `running` step true.
+   - Send/action lanes such as Post Engagers have a sequence attached on the
+     exact current campaign table. Use `list_tables({ hasSequence: true })` as a
+     quick cross-check, but do not treat that filter as the only proof. If the
+     canonical current campaign table is missing from the sequence-filtered
+     table list and `attach_recommended_sequence({ campaignId })` returns
+     `SEQUENCE_EXISTS`, inspect whether a stale shell table owns the sequence.
+     For a customer-visible completion run, stale shell proof is not completion:
+     rerun the current-table repair above or report `blocked: stale_shell_sequence`.
+   - Only use `attach_recommended_sequence({ campaignId })` for a send-lane
+     sequence repair/precheck when the target is a canonical prod slot and the
+     invoking prompt allows sequence repair. Call it at most once without
+     `confirmed`; a successful response is `repaired`. Treat `SEQUENCE_EXISTS` as
+     non-mutating proof only when the current table also has `hasSequence:true`.
+     Never call `attach_recommended_sequence` or `attach_sequence` with
+     `confirmed:true` in evergreen automation unless the user explicitly asks to
+     replace an existing sequence or the approved lane packet allows current
+     table stale-shell repair.
+   - Do not report `source-only/no sequence expected` for any named evergreen
+     campaign that appears in Campaigns, has a CampaignOffer ID, or is backed by
+     a campaign dashboard table. Shared Signal Discovery and Shared Cold
+     Fallback campaign cards are still customer-visible campaigns and must
+     satisfy the Customer-Visible Completion Contract when the prompt asks for
+     full/customer-ready completion.
+   - Source-only shared lanes are allowed only for explicitly internal waterfall
+     inventory objects that are not represented as campaign cards. For those
+     internal-only objects, verify the active waterfall linkage, table ID,
+     source type, and priority, and label them `internal source pool` rather
+     than treating them as completed campaigns.
+   - Post Engagers lanes are sender-owned source lanes. The selected/source LinkedIn posts must be authored by that exact sender (for example, Thomas post-engager source posts must visibly be Thomas-authored posts). If selected/source posts include another person or company author, mark the slot `blocked`/`flagged` for source repair; do not scrape/import engagers or report completion until the source is sender-owned. Shared Signal Discovery lanes are the only evergreen lanes allowed to mix authors.
+5. **Interactive polish mode only: confirm the message template with the user — and check it reads chat-native.** Show the exact first-message template each created campaign's brief carries and ask the user to confirm or adjust it before moving on. Because DM copy may send paragraph-by-paragraph (each blank-line block becomes its own message), every paragraph must read like something a human literally typed as a separate chat message:
+   - **No letter punctuation.** `Hey {{first_name}}` — never `Hey {{first_name}},` (nobody types a trailing comma and hits send). No `Dear`, no sign-offs, no `Best,`.
+   - Each paragraph stands alone as a message — short, lowercase-casual is fine, sentence fragments are fine.
+   - No paragraph should depend on letter formatting (no "As I mentioned above" referencing layout).
+   If the template violates these, propose the chat-native version and ask; on approval, update the brief via `update_campaign_brief` and show the final version.
+
+   **Also confirm the delivery format and keep config in sync.** Ask the user whether DM lanes should send multiline (paragraph-per-message) or as a single message. Record the answer as the brief's `Delivery format:` line, and when multiline is chosen, set `actionConfig.sendEachParagraphAsMessage: true` on that campaign's `send_dm` column via `update_column` (config edits run no cells and nothing sends from unlaunched campaigns). Never set the paragraph-split flag on InMail columns — the option does not apply to InMail.
+6. **Interactive polish mode only: prove the template on one real row.** For ONE campaign that has at least one lead row (add one via `add_on_demand_leads` if every lane is empty and the user provides/approves a test lead), generate a message for exactly one row (`queue_campaign_cells` with `columnRole: "generateMessage"`, `rowSelector: { type: "reviewBatch", limit: 1 }` or the single row's ID), wait for it, then show the user the generated message next to the template — AND show how it would split if paragraph-per-message sending is enabled (list each paragraph as `msg 1:`, `msg 2:`, …) so the user confirms each one reads like a real typed message. Check alignment: tone, structure, no internal vocabulary, correct token substitution, no letter punctuation. Do NOT approve the row or generate for more rows — one sample only.
+7. **Automation mode template/config audit**: inspect existing send-lane briefs for a `Delivery format:` line and chat-native warm template. If a send lane is missing the line and the prompt allows cleanup, update only the campaign brief metadata with the safest default for that lane (`Delivery format: single message (LinkedIn DM; line breaks remain inside one generated message; no follow-up until reply)`). If cleanup is not allowed, flag it. Do not generate a sample row in automation mode unless the invocation explicitly asks for sample proof. In structure-only automation, do not generate a sample row unless the invocation explicitly asks for sample proof. In customer-visible completion, follow the Customer-Visible Completion Contract instead.
+8. **Report the reconcile plan and result** — every slot tagged `reused`, `created`, `repaired`, `flagged`, or `blocked`, plus template/sample details only when that mode ran:
+
+```
+Evergreen Reconcile — {date}
+• Christian Reyes - Post Engagers: reused (send review ready; 18 rows, 3 generated, 1 approved gate row, sequence attached, paused)
+• Thomas Nobbs - Post Engagers: reused (send review ready; 8 rows, 3 generated, 1 approved gate row, sequence attached, paused)
+• Sellable.dev - Shared Signal Discovery: repaired (send review ready; 50 rows, 3 generated, 1 approved gate row, sequence attached, paused)
+• Sellable.dev - Shared Cold Fallback: created (send review ready; 50 rows, 3 generated, 1 approved gate row, sequence attached, paused)
+All campaigns remain unlaunched. Next: enrich/approve more rows when you want more items ready to schedule.
+```
+</objective>
+
+<safety>
+- **Idempotent by construction**: rerunning on a schedule must produce all-`reused` and zero new campaigns. If a name matches ambiguously (two candidates), reuse the most recently updated and flag the duplicate for the operator instead of creating a third.
+- Never call `start_campaign` / `start_on_demand_campaign`. New campaigns stay in their default unlaunched state.
+- Never archive, rename, or delete existing campaigns — reconcile is additive; structural removals are operator actions.
+- Respect workspace boundaries: senders and campaigns must belong to the active workspace.
+</safety>