@sellable/install 0.1.388 → 0.1.390-uat.refill-zero-shot.20260721230009

package/container/Dockerfile

@@ -3,13 +3,13 @@ FROM ${HERMES_IMAGE}
 
 USER root
 
-ARG INSTALLER_PACKAGE=@sellable/install@0.1.388
-ARG MCP_PACKAGE=@sellable/mcp@0.1.643
+ARG INSTALLER_PACKAGE=@sellable/install@0.1.389
+ARG MCP_PACKAGE=@sellable/mcp@0.1.644
 ARG INSTALLER_INTEGRITY
 ARG MCP_INTEGRITY=sha512-b7N9CnZXBoO1JPc6YeM3S96FnsJQI8BjMtb1Vp0moKkSy3YQ/jd9VQDwFxUGgC7nXx0BNlvNJH9QocmarC52yA==
 
-RUN test "${INSTALLER_PACKAGE}" = "@sellable/install@0.1.388" \
-    && test "${MCP_PACKAGE}" = "@sellable/mcp@0.1.643" \
+RUN test "${INSTALLER_PACKAGE}" = "@sellable/install@0.1.389" \
+    && test "${MCP_PACKAGE}" = "@sellable/mcp@0.1.644" \
     && test -n "${INSTALLER_INTEGRITY}" \
     && test "$(npm view "${INSTALLER_PACKAGE}" dist.integrity)" = "${INSTALLER_INTEGRITY}" \
     && test "$(npm view "${MCP_PACKAGE}" dist.integrity)" = "${MCP_INTEGRITY}" \
@@ -23,9 +23,9 @@ RUN test "${INSTALLER_PACKAGE}" = "@sellable/install@0.1.388" \
     && mkdir -p /opt/sellable-agent/install-root /opt/sellable-agent/mcp-root \
     && npm install --prefix /opt/sellable-agent/install-root --omit=dev --ignore-scripts --no-audit --no-fund "${INSTALLER_PACKAGE}" \
     && npm install --prefix /opt/sellable-agent/mcp-root --omit=dev --ignore-scripts --no-audit --no-fund "${MCP_PACKAGE}" \
-    && node --input-type=module -e "import { readFileSync } from 'node:fs'; const install = JSON.parse(readFileSync('/opt/sellable-agent/install-root/node_modules/@sellable/install/package.json')); const mcp = JSON.parse(readFileSync('/opt/sellable-agent/mcp-root/node_modules/@sellable/mcp/package.json')); if (install.name !== '@sellable/install' || install.version !== '0.1.388' || mcp.name !== '@sellable/mcp' || mcp.version !== '0.1.643') throw new Error('package identity rejected');" \
+    && node --input-type=module -e "import { readFileSync } from 'node:fs'; const install = JSON.parse(readFileSync('/opt/sellable-agent/install-root/node_modules/@sellable/install/package.json')); const mcp = JSON.parse(readFileSync('/opt/sellable-agent/mcp-root/node_modules/@sellable/mcp/package.json')); if (install.name !== '@sellable/install' || install.version !== '0.1.389' || mcp.name !== '@sellable/mcp' || mcp.version !== '0.1.644') throw new Error('package identity rejected');" \
     && node --input-type=module -e "import { buildExternalRuntimeClosure } from '/opt/sellable-agent/install-root/node_modules/@sellable/install/lib/sellable-agent/external-runtime-builder.mjs'; const built = buildExternalRuntimeClosure({ mcpPackageRoot: '/opt/sellable-agent/mcp-root/node_modules/@sellable/mcp', mcpNodeModulesRoot: '/opt/sellable-agent/mcp-root/node_modules', hermesSourceRoot: '/opt/hermes', ownerUid: 0, ownerGid: 0 }); if (!built.closureDigest) throw new Error('runtime closure rejected');" \
-    && node --input-type=module -e "import { chmodSync, writeFileSync } from 'node:fs'; const release = { installerPackage: '@sellable/install@0.1.388', installerIntegrity: process.argv[1], mcpPackage: '@sellable/mcp@0.1.643', mcpIntegrity: process.argv[2] }; writeFileSync('/opt/sellable-agent/release.json', JSON.stringify(release) + '\\n', { mode: 0o444 }); chmodSync('/opt/sellable-agent/release.json', 0o444);" "${INSTALLER_INTEGRITY}" "${MCP_INTEGRITY}" \
+    && node --input-type=module -e "import { chmodSync, writeFileSync } from 'node:fs'; const release = { installerPackage: '@sellable/install@0.1.389', installerIntegrity: process.argv[1], mcpPackage: '@sellable/mcp@0.1.644', mcpIntegrity: process.argv[2] }; writeFileSync('/opt/sellable-agent/release.json', JSON.stringify(release) + '\\n', { mode: 0o444 }); chmodSync('/opt/sellable-agent/release.json', 0o444);" "${INSTALLER_INTEGRITY}" "${MCP_INTEGRITY}" \
     && npm cache clean --force
 
 COPY entrypoint.sh /usr/local/bin/sellable-agent-container-entrypoint

package/container/README.md

@@ -2,12 +2,12 @@
 
 This image is a dedicated Agent worker/runtime boundary beside an existing Hermes dashboard. It never replaces or reconfigures the dashboard container.
 
-Build from this directory after `@sellable/install@0.1.388` is published:
+Build from this directory after `@sellable/install@0.1.389` is published:
 
 ```sh
 docker build --platform linux/amd64 \
   --build-arg INSTALLER_INTEGRITY='sha512-…' \
-  --tag sellable-agent-host:0.1.388 .
+  --tag sellable-agent-host:0.1.389 .
 ```
 
 Create a private `bootstrap/` directory owned by root with mode `0700`. It must contain `bootstrap.json`, `provider-auth`, and `slack-app`, each owned by root with mode `0600`. `bootstrap.json` contains only non-secret identities, hashes, package integrities, and the control-plane URL. The other two files contain the provider JSON and global Slack app token whose hashes are pinned by `bootstrap.json`.

package/lib/sellable-agent/external-runtime-builder.mjs

@@ -28,7 +28,7 @@ import {
 
 const MANIFEST_VERSION = "sellable-agent-external-runtime-closure/v1";
 const MCP_PACKAGE = "@sellable/mcp";
-const MCP_VERSION = "0.1.643";
+const MCP_VERSION = "0.1.644";
 const SAFE_COMPONENT = /^[A-Za-z0-9@._+-]+$/;
 const HERMES_EXCLUDES = new Set([".git", ".playwright", "node_modules"]);
 

package/lib/sellable-agent/host-bootstrap.mjs

@@ -38,8 +38,8 @@ import { installAgentHostServices } from "./service-installer.mjs";
 const PACKAGE_ROOT = resolve(dirname(fileURLToPath(import.meta.url)), "../..");
 const VERSION = "sellable-agent-host-bootstrap/v1";
 const RECEIPT_VERSION = "sellable-agent-host-registration/v1";
-const INSTALLER_PACKAGE = "@sellable/install@0.1.388";
-const MCP_PACKAGE = "@sellable/mcp@0.1.643";
+const INSTALLER_PACKAGE = "@sellable/install@0.1.389";
+const MCP_PACKAGE = "@sellable/mcp@0.1.644";
 const HERMES_VERSION = "0.18.0";
 const SHA256 = /^[a-f0-9]{64}$/;
 const SHA256_16 = /^[a-f0-9]{16}$/;

package/lib/sellable-agent/host-worker.mjs

@@ -1058,8 +1058,8 @@ export function compileClaimToProfileDesired(activeClaim, config) {
       ]) ||
       !exactObject(runtimeService, ["principalId", "policyHash", "credentialGeneration", "credentialFingerprint"]) ||
       pinned.hermesCli !== "hermes" || pinned.hermesVersion !== "0.18.0" ||
-      pinned.installerPackage !== "@sellable/install@0.1.388" ||
-      pinned.mcpPackage !== "@sellable/mcp@0.1.643" ||
+      pinned.installerPackage !== "@sellable/install@0.1.389" ||
+      pinned.mcpPackage !== "@sellable/mcp@0.1.644" ||
       !Array.isArray(policy.toolInclude) || policy.toolInclude.length === 0 ||
       !Number.isSafeInteger(slack.generation) || slack.generation < 1 ||
       !/^A[A-Z0-9]{8,20}$/.test(slack.appId ?? "") ||

package/lib/sellable-agent/profile-materializer.mjs

@@ -131,8 +131,8 @@ function validateDesired(desired) {
     !Number.isSafeInteger(desired.slackGeneration) || desired.slackGeneration < 1 ||
     !Number.isSafeInteger(desired.serviceCredentialGeneration) || desired.serviceCredentialGeneration < 1 ||
     desired.hermesCli !== "hermes" || desired.hermesVersion !== "0.18.0" ||
-    desired.installerPackage !== "@sellable/install@0.1.388" ||
-    desired.mcpPackage !== "@sellable/mcp@0.1.643" ||
+    desired.installerPackage !== "@sellable/install@0.1.389" ||
+    desired.mcpPackage !== "@sellable/mcp@0.1.644" ||
     !Array.isArray(desired.toolInclude) || desired.toolInclude.length === 0 ||
     desired.toolInclude.some((tool) => !/^[a-z][a-z0-9_]{0,127}$/.test(tool)) ||
     new Set(desired.toolInclude).size !== desired.toolInclude.length ||

package/lib/sellable-agent/provisioning-adapter.mjs

@@ -19,8 +19,8 @@ import { fileURLToPath } from "node:url";
 import { deriveContainedProfileId } from "./profile-materializer.mjs";
 
 export const PROVISIONING_ACTION = "PROVISION_HERMES_PROFILE";
-export const PINNED_INSTALL_PACKAGE = "@sellable/install@0.1.388";
-export const PINNED_MCP_PACKAGE = "@sellable/mcp@0.1.643";
+export const PINNED_INSTALL_PACKAGE = "@sellable/install@0.1.389";
+export const PINNED_MCP_PACKAGE = "@sellable/mcp@0.1.644";
 
 export function deriveAgentProfileId(workspaceId, agentId, hostId) {
   return deriveContainedProfileId(workspaceId, agentId, hostId);
@@ -576,7 +576,7 @@ function inspectProvisionedProfile({
       !matchesReadback(manifest, request) ||
       manifest.serviceCredentialReference !== serviceCredentialReference ||
       manifest.installerPackage !== PINNED_INSTALL_PACKAGE ||
-      manifest.installerVersion !== "0.1.388" ||
+      manifest.installerVersion !== "0.1.389" ||
       manifest.mcpPackage !== PINNED_MCP_PACKAGE ||
       manifest.credentialKeyVersion !== credentialKeyVersion ||
       !/^[a-f0-9]{16}$/.test(manifest.credentialFingerprint) ||
@@ -781,7 +781,7 @@ function successReceipt({
     subject: `agent-profile:${observed.profileId}`,
     cli: {
       installPackage: PINNED_INSTALL_PACKAGE,
-      installVersion: "0.1.388",
+      installVersion: "0.1.389",
       mcpPackage: PINNED_MCP_PACKAGE,
       command: "hermes profile bootstrap",
     },
@@ -821,7 +821,7 @@ function failure(code, stages, extra = {}, request = null) {
     subject: safeIdentity ? `agent-profile:${safeIdentity}` : "agent-profile:unbound",
     cli: {
       installPackage: PINNED_INSTALL_PACKAGE,
-      installVersion: "0.1.388",
+      installVersion: "0.1.389",
       mcpPackage: PINNED_MCP_PACKAGE,
       command: "hermes profile bootstrap",
     },

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.388",
+  "version": "0.1.390-uat.refill-zero-shot.20260721230009",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code, Codex, and Hermes",
   "bin": {

package/skill-templates/refill-sends.md

@@ -1,676 +1,464 @@
 ---
 name: refill-sends
-description: Plan regular campaign and evergreen campaign send refill work through the skill-led refill workflow.
+description: Refill projected sends across a workspace or selected senders through the canonical fenced coordinator.
 visibility: public
 allowed-tools:
   - mcp__sellable__refill_sends
   - mcp__sellable__get_refill_target_plan
   - mcp__sellable__get_scheduler_fill_capacity
-  - mcp__sellable__run_scheduler_sweep
-  - mcp__sellable__refresh_paid_inmail_credits
   - mcp__sellable__get_subskill_asset
   - mcp__sellable__get_auth_status
   - mcp__sellable__start_cli_login
   - mcp__sellable__wait_for_cli_login
   - mcp__sellable__get_active_workspace
   - mcp__sellable__list_workspaces
-  - mcp__sellable__set_active_workspace
   - mcp__sellable__get_subskill_prompt
   - mcp__sellable__search_subskill_prompts
   - mcp__sellable__list_senders
-  - mcp__sellable__get_sender_routing
-  - mcp__sellable__get_campaign_waterfall
-  - mcp__sellable__resolve_campaign_fill_route
-  - mcp__sellable__get_campaign_refill_state
-  - mcp__sellable__fill_campaign_horizon
-  - mcp__sellable__get_campaign
-  - mcp__sellable__get_campaign_context
-  - mcp__sellable__update_campaign
-  - mcp__sellable__get_provider_prompt
-  - mcp__sellable__get_campaign_message_preparation_status
-  - mcp__sellable__start_campaign_message_preparation
-  - mcp__sellable__start_campaign
-  - mcp__sellable__cancel_campaign_message_preparation
-  - mcp__sellable__import_leads
-  - mcp__sellable__wait_for_lead_list_ready
-  - mcp__sellable__confirm_lead_list
-  - mcp__sellable__search_signals
-  - mcp__sellable__select_promising_posts
-  - mcp__sellable__fetch_post_engagers
-  - mcp__sellable__search_sales_nav
-  - mcp__sellable__lookup_sales_nav_filter
-  - mcp__sellable__search_prospeo
-  - mcp__sellable__search_prospeo_companies
-  - mcp__sellable__confirm_prospeo_company_accounts
-  - mcp__sellable__load_csv_linkedin_leads
-  - mcp__sellable__load_csv_domains
-  - mcp__sellable__list_dnc_entries
-  - mcp__sellable__load_csv_dnc_entries
-  - mcp__sellable__get_rows
-  - mcp__sellable__get_rows_minimal
-  - mcp__sellable__get_table_rows
-  - mcp__sellable__get_campaign_table_schema
   - mcp__sellable__select_campaign_cells
-  - mcp__sellable__queue_campaign_cells
-  - mcp__sellable__wait_for_campaign_processing
-  - mcp__sellable__get_sender
 ---
 
 # Refill Sends
 
-Use this public command wrapper for plain operator requests such as "fill",
-"refill sends", "max out sends", "load everyone up", or "fill horizon sends".
+Use this skill for “fill”, “refill sends”, “max out sends”, “load everyone up”,
+or “fill horizon sends”. `refill_sends` is the only execution owner. The host
+resolves the request, invokes the coordinator, and follows its exact
+continuation; it never reconstructs the refill ladder from low-level tools.
 
-Host command names:
+Host commands:
 
 - Claude Code: `/sellable:refill-sends`
 - Codex: `$sellable:refill-sends`
 
-Accepted invocation flags in the same user request:
-
-- `--yolo`: auto-accept the rendered bounded refill packet after the required
-  fresh state reread.
-- `workspaceId: <id>`: required for scheduled automation and `--yolo`; pass it
-  through on every refill MCP tool call instead of relying on shared config
-  state.
-- `--sender <name-or-id>`: scope to a specific sender; repeat for multiple
-  senders.
-- `--until <YYYY-MM-DD>`: fill through that sender-local date, inclusive,
-  instead of the default scheduler-forward 48-hour target window.
-- `--target-date <YYYY-MM-DD>`: fill only that sender-local date. This means
-  prepare rows for scheduler-fillable slots on that date, not every remaining
-  daily-limit slot and not an inclusive through-date.
-- `senderIds: <id>, <id>` or `senderNames: <name>, <name>`: explicit selector
-  alternatives when the host preserves natural-language arguments better than
-  shell-style flags.
-- `actionTypes: send_invite, send_inmail_closed`: optional lane selector. Omit
-  `actionTypes` to preserve the target planner's lane inference.
-- `untilDate: YYYY-MM-DD`: explicit date selector alternative when the host
-  preserves natural-language arguments better than shell-style flags.
-- `targetDate: YYYY-MM-DD`: exact-date selector alternative when the host
-  preserves natural-language arguments better than shell-style flags.
-
-When the host can call typed MCP tools, start with:
+## Entry and exact scope
+
+Accepted request fields are `--yolo`, `workspaceId`, `--sender`/`senderIds`/
+`senderNames`, `actionTypes`, `--until`/`untilDate`, `--target-date`/
+`targetDate`, and compatibility `horizonSendDays`. Omitted dates mean the
+scheduler-forward 48-hour window. `untilDate` is sender-local and inclusive;
+`targetDate` is one sender-local scheduler-fillable date. Skip no-send days and
+never extend beyond the requested date. Finish the full D1 reread before D2.
 
 ```text
 refill_sends({ yolo?: boolean, executionMode?: "manual" | "scheduled" | "yolo", requireWorkspace?: boolean, workspaceId?: string, senders?: string[], senderIds?: string[], senderNames?: string[], actionTypes?: ("send_invite" | "send_inmail_closed")[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD", runHandle?: RefillRunHandleV1, targetConfig?: RefillTargetConfigV1, reportingContext?: RefillReportingContextV2, messageTemplateRevision?: MessageTemplateRevisionV1 })
 ```
 
-That command helper normalizes arguments and returns the execution contract. In
-non-yolo mode it does not mutate. In workspace-wide `--yolo`, the MCP command
-selects fresh `target.globalActionQueue[0]`, obtains and validates its exact
-campaign/table/sender/lane `targetConfig`, and only then executes one fenced,
-checkpointed slice. If it returns `status:"in_progress"`, immediately invoke
-its exact `continuation.arguments`. `kind:"active_exact_run"` carries the exact
-`targetConfig`, `runId`, and `fence`; `kind:"next_exact_target"` carries the
-unchanged workspace envelope and next preflighted `targetConfig` with no stale
-run fence. Do this automatically inside the same user command until terminal
-workspace projected coverage or a concrete blocker. If an exact run terminalizes
-as `loaded_awaiting_scheduler` and the fresh workspace queue reselects the same
-campaign/table/sender/lane, the coordinator returns that scheduler-owned
-workspace terminal with no continuation instead of opening another identical
-fence. Do not ask the user to type `continue` and do not start a second run while
-a fence is active.
-
-Route intent must stay identical from the rendered packet through execution.
-Workspace-wide `--yolo` defaults to `intent:"auto"`, so use `intent:"auto"`
-for its opening `get_refill_target_plan`, packet rereads, and `refill_sends`
-call. Never render a `plain` planner packet and then execute an `auto` yolo
-coordinator. If the operator explicitly supplies another supported intent,
-preserve that exact intent on every planner, coordinator, and continuation call.
-
-`targetConfig` and the server-issued `runHandle` are separate values and must
-survive each continuation unchanged except for a server-issued takeover fence.
-Only a literal `messageTemplateRevision` with `source:"user_approved"`, the
-approved `templateMarkdown`, prior/new authority digests, 1–500 exact cohort
-row IDs, and request/effect/revision-operation IDs can authorize
-`revise_message_template_and_rerun`. No envelope means no revision. A
-`forceRerun:true` queue call cannot infer or authorize template mutation.
-When the user supplied a complete revision except for the current prior digest,
-acquire the exact run first and reread with its unchanged `targetConfig` and
-`runHandle`. Use only `reportingContext.source.templateAuthorityDigest` from
-that fenced reread as `priorTemplateAuthorityDigest`, then immediately continue
-the same run with the complete literal revision—even when the ordinary refill
-queue is empty or the sender is otherwise ineligible. An empty ordinary queue
-must not suppress an explicit revision. If the fenced reread returns no digest,
-stop with `template_authority_missing` or the returned
-`templateAuthorityBlocker`; never guess the digest.
-After the revision receipt is committed and dispatched, the next mutation must
-be the planner-provided revision-derived `approve_messages` action. Preserve
-its exact `rowSelector:{type:"rowIds",rowIds:[...]}` cohort,
-`approvalMode:"approve"`, compiled readiness authority, and
-`reportingContext`, even if the ordinary sender lane is ineligible. Never use
-`queue_campaign_cells` to flip Approved cells: that path cannot produce the
-authoritative approval/lane-scope receipt. Require the bounded preparation
-receipt's `laneScope` before considering the selected first-touch lane
-approved. Zero sender capacity remains a scheduler blocker and never authorizes
-reconnection, campaign start, or direct send.
-
-Before that approval mutation, perform an exact authoritative copy audit with
-`select_campaign_cells({ columnRole:"generateMessage",
-rowSelector:{type:"rowIds",rowIds:[...]},
-includeGeneratedMessageReview:true })` over the complete revision cohort in
-batches of at most 20. Require every
-`authoritativeGeneratedMessageReview.complete:true`, every row status to be
-completed-like, the exact user-approved rendered subject/body, the expected
-`templateAuthorityDigest`, and `matchesCurrentTemplateAuthority:true`. This
-projection is the only MCP copy-review source of truth. Never use formula
-Message/Subject columns, campaign message previews, table previews, or CSV
-exports to validate revised Generate Message results. If any row is missing,
-non-current, or text/digest mismatched, stop before approval and report
-`regenerated_copy_integrity_failed`; never regenerate again implicitly or
-approve the cohort on counts/revision hashes alone.
-
-Safe primitives are paid-credit refresh,
-existing-row message preparation, generated-message approval, receipt-proven
-same-source row copy, one bounded Signal Discovery search derived only from
-the campaign's already-approved positive ICP criteria when no reusable source
-rows or tab keywords remain, one bounded SAME-provider-source add for a cold
-campaign whose eligible/prepared rows are receipt-proven exhausted (Sales Nav
-or Prospeo, same saved search — never a source-family switch), the start of a
-route-resolver start-eligible PAUSED campaign-backed sequence campaign selected
-by the packet, a request-scoped exact-date product scheduler sweep, and
-read-only wait rereads. Each source add and campaign start is one bounded
-primitive followed by a full replan.
-Approved-criteria keywords and the attempt/exhaustion marker are scoped to the
-current fenced refill run: archive temporary derived search tabs after the
-source import is materialized, keep normal source-list/import receipts, and
-retry from the campaign's current approved rubric in every new refill run.
-Same-source copy, same-provider-source add, and source
-fallback are safe only after receipt-proven exhaustion:
-`hasMoreFrontierRows:false`, zero `approvalCandidates`, no `stuckActiveCells`,
-and no non-terminal `approvedNotDispatched` work. It does not run unbounded
-approval, lower paid-InMail thresholds/floors, switch an existing campaign's
-source family, create NEW campaigns, archive/delete, launch, or send directly;
-it never raw-writes scheduler fields.
-Continue with the workflow below for route selection, state rereads, approval
-gating, source import, preparation, and bounded approval.
-
-The approval scope is the exact `workspaceId`, target date/window, sender ids,
-action types, original planner lane chains, and refill side-effect classes.
-Fresh planner-selected campaign/table/source ids, readiness authority,
-`actionKey`, `targetShapeRevision`, `stateRevision`, and sent/scheduled/ready
-counts are per-rung progress inside that envelope. Execute only
-`target.globalActionQueue[0]`, then perform a full authoritative reread before
-deciding any next action.
-
-Sequence readiness is a positive authority contract. Before any preparation,
-approval, or exact-date sweep, require a validated compiled campaign and a
-positive exact target readiness identity from the backend compiler. Preserve
-`profileSchemaVersion`, `compilerVersion`, `campaignDigest`,
-`actionColumnId`, action, `pathDigest`, `dependsOnColumnIds`,
-`runCondition`, the selected target's `capabilities`, `requestId`,
-`effectId`, and `dateGuards` unchanged. If any field is missing, unknown,
-blocked, or disagrees with the fresh target plan, stop with the typed readiness
-repair blocker; prompts never compile, repair, or reinterpret the sequence.
-
-Always prepare rows according to the persisted sequence. Never infer no-message
-behavior from a missing Generate Message column; use only the selected target's
-`capabilities`. Do not choose campaign-union behavior: mixed INVITE -> DM
-sequences keep distinct target paths, and the exact selected target path decides
-whether message, subject, comment, reaction, or row approval is required.
-Refuse approval outside the bounded authorized cohort; bounded enrichment and LLM prerequisite calls
-are allowed only when authorized by the exact readiness
-packet and returned with a receipt. Never call a LinkedIn
-outreach/provider-send surface from refill; product scheduling remains the only
-send path.
-
-Always execute one bounded primitive, then perform a full authoritative reread
-and continue the same `--yolo` invocation when the fresh action remains inside
-the original sender/action/date/lane-chain/side-effect envelope. For an
-exact-date sweep, immediately re-attest `dateGuards`: the target date must be
-strictly after sender-local today and inside the fill horizon. Completion
-requires exact request/effect-attributed campaign, table, sender,
-`actionColumnId`, action, and date scheduler-owned scheduled readback.
-Prepared, approved, and ready rows remain intermediate evidence.
-
-## Workspace Contract
-
-First resolve the target workspace id from the user's request, automation config,
-or install-time workspace mapping. Pass `workspaceId` on every scheduled or
-`--yolo` refill tool call, including setup/read calls such as
-`refill_sends`, `get_refill_target_plan`, `list_senders`,
-`get_sender_routing`, `resolve_campaign_fill_route`,
-`get_campaign_refill_state`, `get_scheduler_fill_capacity`,
-`run_scheduler_sweep`, and any later refill mutation covered by the packet.
-Missing `workspaceId` in scheduled or `--yolo` mode is a blocker; stop with
-`WORKSPACE_REQUIRED` instead of running against an implicit or guessed
-workspace.
-
-Do not solve scheduled or `--yolo` workspace uncertainty by changing the shared
-active workspace. Manual interactive workspace switching remains a separate
-diagnostic/setup flow, outside automation.
-
-Examples:
+```mermaid
+flowchart TD
+    A["Parse the operator request"] --> AUTH{"Sellable auth valid?"}
+    AUTH -- No --> LOGIN["Run the returned login flow and wait"]
+    LOGIN --> AUTH
+    AUTH -- Yes --> WS["Resolve exact workspace by ID, exact name, or install mapping"]
+    WS --> WSG{"One accessible workspace match?"}
+    WSG -- No --> WB["Output: blocked_retryable / WORKSPACE_REQUIRED or workspace_ambiguous"]
+    WSG -- Yes --> SENDERS["Resolve each sender inside that workspace by ID, exact name, or unambiguous prefix"]
+    SENDERS --> SG{"Every selector resolves exactly?"}
+    SG -- No --> SB["Output: blocked_retryable / sender_selector_unresolved with candidates"]
+    SG -- Yes --> DATE["Normalize 48h, exact targetDate, or inclusive untilDate in sender-local time"]
+    DATE --> PLAN["Call refill_sends with the exact workspace and scope"]
+```
+
+Scheduled and `--yolo` execution require an explicit `workspaceId` on every
+call. Never change the shared active workspace to control an automation, never
+fall back to its full fleet, and never mutate the workspace that merely happens
+to be active. If the native tool is unavailable, use only the host’s exact
+configured Sellable MCP transport; otherwise stop with `sellable_mcp_unavailable`
+instead of manually reproducing the workflow.
+
+Before product work, load the closed workflow asset completely and verify it:
 
 ```text
-refill_sends({ yolo:true, executionMode:"yolo", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
-get_refill_target_plan({ intent:"auto", approvalMode:"approve", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
-list_senders({ workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+get_subskill_prompt({ subskillName: "refill-sends-workflow" })
+get_subskill_asset({ subskillName: "refill-sends-workflow", assetPath: "core/flow.v1.json" })
 ```
 
-Clover scheduled automation must name the Clover workspace explicitly:
+Continue chunks until `hasMore:false`; require
+`workflow:"refill-sends-workflow"` and a `v1` version. Route intent is immutable:
+workspace-wide `--yolo` uses `intent:"auto"` from first plan through terminal.
+
+## Coordinator lifecycle
+
+```mermaid
+flowchart TD
+    A["Fresh workspace refill plan"] --> FULL{"Projected coverage sent + scheduled is full?"}
+    FULL -- Yes --> COMPLETE["Terminal: complete"]
+    FULL -- No --> ACTIVE{"Active exact fenced run exists?"}
+    ACTIVE -- Yes --> RESUME["Resume only issued runId, fence, targetConfig, reportingContext"]
+    ACTIVE -- No --> PICK["Select globalActionQueue 0"]
+    PICK --> PREFLIGHT["Exact campaign, table, sender, action, lane preflight"]
+    PREFLIGHT --> ACT["Execute one bounded planner action"]
+    RESUME --> ACT
+    ACT --> OUTCOME{"Canonical outcome?"}
+    OUTCOME -- "Committed or canonical no-op" --> A
+    OUTCOME -- "Still running" --> WAIT["Bounded read-only wait or receipt reconciliation"]
+    WAIT --> A
+    OUTCOME -- "Source exhausted" --> NEXT{"Another planner-ranked existing target?"}
+    NEXT -- Yes --> HANDOFF["Terminalize exact fence as next_exact_target"]
+    HANDOFF --> A
+    NEXT -- No --> NC["Terminal: new_campaign_required; ask whether to create it"]
+    OUTCOME -- "Provider unavailable after one retry" --> RETRY["Terminal: blocked_retryable; universeExhausted false"]
+    OUTCOME -- "Scope, config, readiness, or receipt drift" --> BLOCK["Terminal: blocked_retryable with exact blocker"]
+    OUTCOME -- "Planner marker done" --> DONE["Terminalize marker; never dispatch it"]
+```
 
-```text
-refill_sends({ yolo:false, executionMode:"scheduled", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
-get_refill_target_plan({ intent:"plain", approvalMode:"mark_ready", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+If `status:"in_progress"`, invoke only the returned
+`continuation.arguments`. `targetConfig` and `runHandle` are separate and remain
+unchanged except for a server-issued takeover fence. `active_exact_run` resumes
+that fence; `next_exact_target` carries no stale run fence. Never open a second
+or overlapping run, ask the user to type “continue”, redispatch a control marker, or
+turn `done`, `next_campaign`, or a continuation object into a product action.
+
+## Per-sender campaign and lane waterfall
+
+Use managed evergreen order when healthy. Otherwise build the same waterfall
+on the fly from existing eligible campaigns the sender is already attached to.
+This makes regular and evergreen campaigns differ only in where ordering comes
+from, not in how refill proceeds.
+
+```mermaid
+flowchart TD
+    A["All existing campaign-backed sequences attached to one sender"] --> FILTER["Exclude wrong workspace/sender, archived, completed, direct, disconnected, or sequence-invalid targets"]
+    FILTER --> STALE{"Managed waterfall complete and live?"}
+    STALE -- Yes --> MANAGED["Use configured priority order"]
+    STALE -- No --> DERIVE["Derive deterministic order from dashboard-active campaigns"]
+    DERIVE --> P1["Prefer canonical source/lane priority"]
+    P1 --> P2["Then future scheduled and ready inventory"]
+    P2 --> P3["Then recent successful sends and source health"]
+    P3 --> P4["Then active before exact start-eligible paused, recency, stable ID"]
+    MANAGED --> PIN["Pin exact per-sender and per-action lane chain for this run"]
+    P4 --> PIN
+    PIN --> LANE["Select highest-priority non-exhausted lane"]
+    LANE --> REFILL["Run row lifecycle"]
+    REFILL --> EX{"Lane structurally exhausted?"}
+    EX -- No --> REFILL
+    EX -- Yes --> MORE{"Another pinned existing lane or source family?"}
+    MORE -- Yes --> LANE
+    MORE -- No --> END["Output: lanes_exhausted, then new_campaign_required if coverage still short"]
 ```
 
-First call `get_auth_status({})`. If auth is not OK, follow the returned login
-guidance before route resolution. Do not run refill research against an implicit
-or guessed workspace.
-
-Treat "refill senders", "fill senders", "load everyone up", and "max out
-senders" as sender-scoped requests. The target set is senders enrolled in active
-campaign-backed sequence campaigns, not the first active campaign returned by a
-resolver.
-
-## Sender Selector Resolution
-
-When a request names a sender or workspace ("damiano r", "refill Kyle"), resolve
-that selector EXACTLY inside the CORRECT workspace before any mutation. A
-selector resolves only by exact sender id, exact display name, or an
-unambiguous display-name prefix within `list_senders({ workspaceId })` for the
-resolved workspace. `refill_sends` performs this resolution internally: a
-`--yolo`/scheduled invocation with `senders`/`senderNames` first pins each
-selector to an exact sender id in the requested workspace and passes only ids
-downstream.
-
-If any selector does not resolve, or resolves ambiguously, `refill_sends`
-returns `sender_selector_unresolved` with the candidate sender list and does NOT
-run. Never silently fall back to the active workspace's full fleet, and never
-mutate a different workspace than the one that owns the named sender. A name
-that belongs to another workspace (for example running "damiano r" while Clover
-is active) must fail loudly so the caller re-runs with the correct
-`workspaceId`; it must never create prep jobs in the active workspace instead.
-Resolve the workspace first (via `list_workspaces`/install mapping) when the
-named sender is not present in the currently resolved workspace's fleet.
-
-Goal-mode continuation: a skill cannot create or invoke `/goal` by itself. When
-this command is already running inside an active Codex goal, keep that goal open
-until every selected sender lane is filled by projected coverage
-(`sent + scheduled`) for the scheduler-forward target window, Christian
-explicitly stops/statuses the run, or a concrete non-scheduler blocker appears.
-Do not call the goal complete or blocked only because the current state is
-`awaiting_scheduler_after_ready_buffer`; treat it as loaded, awaiting scheduler.
-
-Load the internal workflow prompt and deterministic flow asset before taking
-any operational step:
+Campaign enrollment/removal, missing pinned targets, or loss of eligibility is
+typed scope drift; a fresh planner may rederive, but the host cannot silently
+substitute a target. A current dashboard-active `PAUSED` campaign is eligible
+only when the planner names that exact campaign as start-eligible. Starting it
+may let the product scheduler schedule/send approved sequence actions and must
+be reported. DMs are follow-ups, not refill horizon targets. Mixed sequences
+keep distinct exact target paths; do not choose campaign-union behavior.
+
+## Connection and InMail capacity overlay
+
+```mermaid
+flowchart TD
+    S["Sender capacity and exact selected days"] --> C{"Connection slots available now or later in rolling week?"}
+    S --> F{"Paid-InMail credit facts fresh?"}
+    F -- No --> RF["Refresh exact selected sender once per run, then replan"]
+    RF --> P{"Credits meet existing threshold, normally 5?"}
+    F -- Yes --> P
+    C -- Yes --> INV["Enable existing invite lanes"]
+    C -- No --> INVCAP["Cap invite lane with timing evidence"]
+    P -- Yes --> MAIL["Enable existing paid-InMail or cascade lane"]
+    P -- No --> MAILCAP["Skip paid lane; never lower threshold"]
+    INV --> UNION["Rank enabled existing lanes per sender"]
+    MAIL --> UNION
+    INVCAP --> ALT{"Paid lane enabled?"}
+    MAILCAP --> ALT2{"Invite or same-campaign connection fallback enabled?"}
+    ALT -- Yes --> UNION
+    ALT -- No --> CAP["Output: blocked_retryable / capacity or window"]
+    ALT2 -- Yes --> UNION
+    ALT2 -- No --> CAP
+    UNION --> POOL["Pool shared-campaign prepared inventory; never double-enrich"]
+```
 
-```text
-get_subskill_prompt({ subskillName: "refill-sends-workflow" })
-get_subskill_asset({ subskillName: "refill-sends-workflow", assetPath: "core/flow.v1.json" })
+`rollingWeeklyInvite.capacityFreedDuringWindow:true` means later capacity is
+schedulable; use its timing fields rather than treating the opening gate as a
+full-day blocker. Credit freshness precedes scheduler wait. Fresh facts below
+threshold authorize only an already-eligible existing connection fallback or
+another existing campaign—not a threshold change or new campaign.
+
+## Row lifecycle
+
+For every selected lane, use the smallest action that can reduce its gap.
+
+```mermaid
+flowchart TD
+    A["Lane still has projected gap"] --> ACTIVE{"Active import, preparation, or stuck work?"}
+    ACTIVE -- "Healthy active" --> WAIT["Bounded read-only wait; honor wait.deadlineAt"]
+    WAIT --> A
+    ACTIVE -- "Stuck or anomalous" --> REPAIR["Run only planner-bounded repairable cells or return blocker"]
+    REPAIR --> A
+    ACTIVE -- No --> APPROVE{"Generated rows can be approved?"}
+    APPROVE -- Yes --> AP["Approve exact bounded cohort with readiness authority"]
+    AP --> REPLAN["Record receipt and full authoritative replan"]
+    APPROVE -- No --> ENRICH{"Existing rows can be enriched or prepared?"}
+    ENRICH -- Yes --> PREP["Enrich, generate, or rerun exact bounded cohort"]
+    PREP --> REPLAN
+    ENRICH -- No --> SOURCE{"Selected source can add qualified rows?"}
+    SOURCE -- Yes --> ADD["Copy/import bounded rows from exact selected source"]
+    ADD --> REPLAN
+    SOURCE -- No --> EXPAND["Run source-family acquisition flow"]
+    EXPAND --> REPLAN
+    REPLAN --> A
+```
+
+Structural exhaustion requires receipt-proven
+`hasMoreFrontierRows:false`, zero `approvalCandidates`, no fresh active prep,
+no `stuckActiveCells`, and no non-terminal `approvedNotDispatched` work. A dry
+preparation receipt is run-scoped and prevents the identical no-op from
+repeating. `USER_ADDED_ROWS_LIMIT_EXCEEDED` may use a bounded same-source split
+through `load_csv_linkedin_leads` into the exact review batch; a true campaign
+table hard cap returns a capacity blocker and never deletes rows.
+
+## Sender Post Engagers acquisition
+
+```mermaid
+flowchart TD
+    A["Sender Post Engagers lane needs rows"] --> UNUSED{"Unused selected post/engager rows exist?"}
+    UNUSED -- Yes --> USE["Import/copy bounded unused rows"]
+    UNUSED -- No --> REFRESH["Refresh this sender's latest recent authored posts"]
+    REFRESH --> SELECT["Select new unprocessed relevant high-engagement posts"]
+    SELECT --> FETCH["Fetch/import their engagers and dedupe"]
+    FETCH --> YIELD{"Usable qualified yield?"}
+    YIELD -- Yes --> USE
+    YIELD -- No --> EX["Exhaust only this Post Engagers lane"]
+    EX --> NEXT["Advance to Shared Signal Discovery or next pinned existing lane"]
+```
+
+The campaign must be sender-owned: exactly that sender, authored posts only.
+Never invent keywords, search third-party posts, or run general Signal Discovery
+against the Post Engagers campaign.
+
+## Shared Signal Discovery acquisition
+
+```mermaid
+flowchart TD
+    A["Shared Signal lane needs rows"] --> UNUSED{"Unused selected rows or unprocessed posts exist?"}
+    UNUSED -- Yes --> USE["Import/copy bounded rows"]
+    UNUSED -- No --> STALE["Re-search stale existing topics for newly published posts"]
+    STALE --> SY{"Projected qualified yield meets min remaining gap or 100?"}
+    SY -- Yes --> USE
+    SY -- No --> DERIVE["Derive up to five concise positive-ICP topics from approved campaign intent"]
+    DERIVE --> DY{"Projected qualified yield meets floor?"}
+    DY -- Yes --> USE
+    DY -- No --> AGENT["Request 3-5 new agent-supplied topics through the same fenced continuation"]
+    AGENT --> SEARCH["Search once, excluding searchedKeywords, then project actual returned candidates"]
+    SEARCH --> PROVIDER{"All LinkedIn providers failed?"}
+    PROVIDER -- Yes --> RETRY["Retry the same bounded search once"]
+    RETRY --> RECOVER{"Provider recovered?"}
+    RECOVER -- No --> BLOCK["Output: blocked_retryable / provider_unavailable; universeExhausted false"]
+    RECOVER -- Yes --> AY{"Actual qualified yield meets floor?"}
+    PROVIDER -- No --> AY
+    AY -- Yes --> USE
+    AY -- No --> EX["Receipt-proven signal_yield_below_floor"]
+    EX --> NEXT["Advance to next pinned existing lane"]
+```
+
+Provider outage never consumes a keyword tier or proves exhaustion. Temporary
+derived search state is run-scoped; later runs may rediscover new posts. Agent
+keywords are supplied only through the exact run continuation, never by user
+steering or a second run.
+
+## Sales Nav and Prospeo acquisition
+
+```mermaid
+flowchart TD
+    A["Cold-provider lane needs rows"] --> UNUSED{"Unused exact-source rows exist?"}
+    UNUSED -- Yes --> USE["Import/copy bounded rows"]
+    UNUSED -- No --> DEEP["Continue latest/unfetched pages of exact saved Sales Nav or Prospeo search"]
+    DEEP --> DY{"Qualified yield?"}
+    DY -- Yes --> USE
+    DY -- No --> OPTIONAL{"Known activity/recency filter exists?"}
+    OPTIONAL -- No --> NEXT["Advance to next pinned existing lane"]
+    OPTIONAL -- Yes --> CLONE["Clone exact approved search; remove one optional activity/recency filter"]
+    CLONE --> PROOF{"Original unchanged and every hard-fit filter fingerprint preserved?"}
+    PROOF -- No --> BLOCK["Output: blocked_retryable / provider_search_drift"]
+    PROOF -- Yes --> TRIAL["Import bounded trial candidates into existing gated source"]
+    TRIAL --> GATE["Run current ICP, exclusion, DNC, persona, geography, and company-fit gates"]
+    GATE --> GY{"Qualified yield?"}
+    GY -- Yes --> USE
+    GY -- No --> QUARANTINE["Rejects remain unsendable; advance lane"]
+    QUARANTINE --> NEXT
+```
+
+The original saved search is immutable. An automatic trial may remove only a
+known activity/recency signal; role, seniority, geography, industry, company
+size, domain, include/exclude, DNC, and every other hard-fit constraint remain
+byte-for-byte. Imported candidates are not approvals: current campaign gates
+quarantine bad fits. If rubric rejects dominate, enter the bounded sample-quality
+trial below before another source add. Do not repeat a spent trial or switch
+outside planner order.
+
+## Rubric sample-quality trial
+
+Rubric rejection may mean the source is poor or that one or several required
+checks are unnecessarily narrow. Decide from an exact sample, not pass-rate alone.
+
+```mermaid
+flowchart TD
+    A["Rows fail ICP/rubric gate"] --> STALE{"Score stale, errored, or computed under mismatched authority?"}
+    STALE -- Yes --> RESCORE["Rerun exact bounded cohort under unchanged current rubric"]
+    RESCORE --> RESULT{"Now qualified?"}
+    RESULT -- Yes --> CONTINUE["Continue row lifecycle"]
+    RESULT -- No --> SAMPLE
+    STALE -- No --> SAMPLE["Take exact representative rejected sample from prep receipt"]
+    SAMPLE --> SNAP["Snapshot complete rubric and prior digest"]
+    SNAP --> PROPOSE["Propose smallest 1-3 required-to-advisory bundle that creates useful new passes"]
+    PROPOSE --> HARD{"Touches employment, DNC/opt-out, legal/compliance, or explicit exclusion?"}
+    HARD -- Yes --> REJECT["Reject proposal; preserve complete prior rubric"]
+    HARD -- No --> SIM["Simulate bundle from recorded per-prospect evaluations; no mutation"]
+    SIM --> DELTA{"Any newly passing prospects?"}
+    DELTA -- No --> REJECT
+    DELTA -- Yes --> QUALITY["Review only newly passing profiles in campaign and customer context"]
+    QUALITY --> REPLY{"If these prospects replied, would the customer be comfortable and consider the replies relevant?"}
+    REPLY -- No --> REJECT
+    REPLY -- Yes --> DRIFT{"Live rubric digest still equals prior digest?"}
+    DRIFT -- No --> BLOCK["Output: blocked_retryable / rubric config drift"]
+    DRIFT -- Yes --> APPLY["Guarded apply entire required-to-advisory bundle"]
+    APPLY --> EXACT["Force exact bounded ICP rescore for accepted sample"]
+    EXACT --> VERIFY{"Dispatch and accepted quality receipt valid?"}
+    VERIFY -- Yes --> KEEP["Keep bundle; receipt before/after digests, changed checks, sample counts, and verdict"]
+    VERIFY -- No --> ROLLBACK["Restore complete prior snapshot and receipt rollback"]
+    REJECT --> BETTER["Keep rows unsendable; continue better supply or next existing lane"]
+    ROLLBACK --> BETTER
+```
+
+`--yolo` may change more than one required rubric at a time only through this
+single bounded reversible bundle. The change demotes selected required checks to
+advisory scoring; it does not erase their evidence. The acceptance test is the
+newly passing delta: if any reviewed prospect would make the customer unhappy,
+surprised, or consider the reply irrelevant, keep the complete prior rubric and
+continue the source waterfall. Never expose raw prospect profiles in the public
+receipt.
+
+## Scheduler and uncertain-receipt recovery
+
+```mermaid
+flowchart TD
+    A["Ready buffer covers remaining projected gap"] --> CREDIT{"Every selected paid lane has fresh credit facts?"}
+    CREDIT -- No --> RF["Refresh each exact selected sender once, then full replan"]
+    RF --> A
+    CREDIT -- Yes --> DATE{"Exact targetDate?"}
+    DATE -- Yes --> SWEEP["Dispatch one request-scoped product scheduler sweep"]
+    DATE -- No --> WAIT["Enter coordinator-owned bounded scheduler wait"]
+    SWEEP --> RECEIPT{"Receipt state?"}
+    RECEIPT -- Terminal --> READ["Canonical target-plan and request/effect readback"]
+    RECEIPT -- Active --> POLL["Poll only issued continuation until wait.deadlineAt"]
+    RECEIPT -- uncertain_outcome --> RECON["Reconcile same request key read-only; never redispatch"]
+    POLL --> RECEIPT
+    RECON --> TERM["Terminal: blocked_retryable with request identity intact"]
+    WAIT --> READ
+    READ --> FULL{"Projected coverage full?"}
+    FULL -- Yes --> COMPLETE["Terminal: complete"]
+    FULL -- No --> READY{"Ready buffer still covers gap?"}
+    READY -- Yes --> LOADED["Terminal: loaded_awaiting_scheduler"]
+    READY -- No --> PREP["Return to row lifecycle"]
+```
+
+A scheduler sweep is a visible workspace-wide scheduling side effect: existing
+product gates may schedule unrelated eligible cells in that workspace/date.
+It never sends directly or raw-writes scheduler fields. `cellsConsidered is
+allocation-attempt count`; `readyCellsFound` is prefilter inventory. Inspect
+`campaignScopeSummary`, `prefiltered`, `skipped`, and `deferred`. For ready
+closed-InMail cells with stale paid-credit evidence, use
+`refresh_paid_inmail_credits_then_rerun`. `wait_for_capacity_or_window` means do
+not source or prep more rows; `no_ready_cells_continue_refill_prep` returns to
+the row lifecycle. `cellsScheduled:0` alone is not failure.
+
+## Explicit message-template revision
+
+Ordinary refill never changes copy. Only a literal user-approved revision
+envelope may enter this side path.
+
+```mermaid
+flowchart TD
+    A["Literal messageTemplateRevision with approved markdown, digests, 1-500 row IDs, request/effect IDs"] --> DIGEST{"Current prior authority digest present?"}
+    DIGEST -- No --> FENCE["Acquire exact run and read reportingContext source templateAuthorityDigest"]
+    FENCE --> DG{"Digest returned?"}
+    DG -- No --> BLOCK["Terminal: blocked_retryable / template_authority_missing"]
+    DG -- Yes --> REVISE["Apply revision to exact cohort"]
+    DIGEST -- Yes --> REVISE
+    REVISE --> AUDIT["select_campaign_cells in batches <=20 with includeGeneratedMessageReview:true"]
+    AUDIT --> MATCH{"Every authoritativeGeneratedMessageReview complete, exact text/digest, matchesCurrentTemplateAuthority true?"}
+    MATCH -- No --> FAIL["Stop before approval: regenerated_copy_integrity_failed"]
+    MATCH -- Yes --> APPROVE["Approve only exact rowIds using compiled readiness authority"]
+    APPROVE --> RECEIPT{"Bounded preparation receipt includes laneScope?"}
+    RECEIPT -- No --> FAIL
+    RECEIPT -- Yes --> PLAN["Return to canonical refill plan"]
+```
+
+Formula Message/Subject columns, previews, exports, and counts are not copy
+authority. `forceRerun:true` never implies a revision or approval.
+
+## Manual approval and `--yolo`
+
+```mermaid
+flowchart TD
+    A["Render fresh bounded packet in normal chat as Markdown"] --> MODE{"--yolo present?"}
+    MODE -- Yes --> AUTO["Auto-accept all planner-ranked transitions among existing campaigns, lanes, sources, and safe refill primitives"]
+    MODE -- No --> ASK["Open host-native structured question with exactly Accept and Decline"]
+    ASK --> DECISION{"Operator choice?"}
+    DECISION -- Accept --> RUN["Execute only rendered envelope"]
+    DECISION -- Decline --> STOP["Stop with no mutation"]
+    AUTO --> RUN
+```
+
+Use `request_user_input` in Codex and `AskUserQuestion` in Claude Code. The
+full packet belongs in the normal chat message immediately before the question:
+workspace, sender scope, campaign-by-campaign plan table, action, target/cap,
+source, blocker/skip reason, exact IDs, expected side effects, forbidden actions,
+and stop condition. The question body must be compact and refer back to the
+posted packet instead of duplicating it. `--yolo` may switch among every fresh
+planner-ranked existing campaign/lane/source family and start the exact selected
+`PAUSED` campaign. It does not create campaigns, direct-send, archive/delete,
+change sender limits or paid-InMail thresholds, reassign senders, or invent
+source selection outside the planner.
+
+## Typed outputs
+
+```mermaid
+flowchart TD
+    A["Fresh canonical state"] --> C{"Terminal classification"}
+    C -- "sent + scheduled meets target" --> COMPLETE["complete: report saturation ledger"]
+    C -- "ready buffer covers gap after bounded scheduler wait" --> LOADED["loaded_awaiting_scheduler: report expected pickup and stop"]
+    C -- "recoverable external, capacity, active-work, or receipt condition" --> BLOCKED["blocked_retryable: exact blocker, receipt, and safe retry condition"]
+    C -- "current lane spent but another existing target remains" --> EX["lanes_exhausted internally; continue next_exact_target"]
+    C -- "every existing campaign/lane/source spent or infeasible" --> NEW["new_campaign_required: propose missing shape and ask whether to create it"]
+    C -- "scope/config/readiness changed" --> DRIFT["blocked_retryable: typed drift; never guess"]
 ```
 
-Continue both loads until `hasMore:false`; parse the flow JSON and verify
-`workflow:"refill-sends-workflow"` with a `v1` version. Then follow that
-workflow exactly. The default path is read-only research: compute the refill
-target plan first, resolve the route, identify the sender-relevant campaign
-that most recently had scheduler-owned sends, read refill state for that target,
-report the next safe step using campaign names first, and stop before mutation
-unless the user has explicitly approved the exact workspace,
-campaign/table/source ids, caps/dates, approval mode, expected side effects,
-and stop/rollback condition.
-
-Immediately after loading the internal workflow, call
-`get_refill_target_plan`. The target plan is the canonical first fact receipt:
-eligible senders, selected sender-local days, gross target, actual sent
-coverage, scheduler-owned scheduled coverage across active enrolled campaigns,
-projected coverage (`sent + scheduled`), inferred per-sender send lane/action
-selections, ready buffer, remaining projected gap, paid-InMail credit/threshold
-feasibility, `targetShapeRevision`, and `stateRevision`. Refill target lanes are
-connection invites (`send_invite`), standalone paid InMails
-(`send_inmail_closed`), or unified Sales Nav cascades represented publicly as
-`send_inmail_closed` with `campaignClassification:"sales_nav_cascade"`. For a
-Sales Nav cascade, refill the selected campaign first; its sequence can route
-prospects to Open InMail, paid InMail while fresh credits are >= 5, or
-same-campaign connection fallback without asking for separate open/paid/
-connection campaigns. DMs (`send_dm`) are follow-up actions, not refill horizon
-target capacity, and must not be counted as refill sent, scheduled, or ready
-coverage. When `actionTypes` are omitted, trust the target plan's inferred lane
-rather than asking which campaign class to fill. If a stale target plan selects
-`send_dm` or `send_inmail_open` as the lane, stop and re-plan with the current
-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:
-
-- `target.eligibleSenderLedger` is the public sender eligibility ledger.
-- `target.senderRefillPlans[]` is the canonical sender-level packet; read and
-  display it before mutation.
-- Each sender packet includes `campaignRanking.options`, `sourcePlan`,
-  `refillReceipt`, `nextActions`, and `manualAlternates`.
-- `refillReceipt` is the public ladder receipt. It carries the selected
-  campaign/sender/lane summary, skipped rungs, existing-row frontier proof, and
-  any absolute `wait.deadlineAt`.
-- Preserve these coverage labels exactly: `Need to prepare`, `Goal`,
-  `Already sent`, `Scheduled`, `Ready and waiting to be scheduled`,
-  `Still need to schedule`, and `Still need to prepare`. Never render an
-  unlabeled `Still need` value.
-- `target.globalActionQueue` is the only cross-sender yolo execution queue.
-  Execute only the globally ranked primitive at
-  `target.globalActionQueue[0]`, then rerun `get_refill_target_plan` with the
-  same `workspaceId` before choosing another action. In `--yolo`, repeat this
-  through exact `continuation.arguments`: resume active targets with their
-  `targetConfig`/`runId`/`fence`, and start each next planner-preflighted target
-  with its `targetConfig` and a new fence, until workspace projected coverage
-  fills, the coordinator returns the same-target `loaded_awaiting_scheduler`
-  terminal, or a concrete blocker appears.
-- When that primitive is `run_scheduler_sweep`, show `workspaceWide:true` and
-  its reason in the approval/yolo packet so the operator sees that the sweep
-  may schedule other eligible workspace cells on the approved date.
-- `manualAlternates` are not yolo actions. Threshold/floor lowering, NEW
-  campaign creation, source-family switches, and the capSaturated
-  `manual_source_replenishment` dead-end (needs human table cleanup) are manual
-  continuations only. Same-provider-source continuation
-  (`continue_sales_nav_source`, `continue_prospeo_source`) and
-  `start_paused_campaign` for a start-eligible campaign are `--yolo` primitives,
-  not manual alternates.
-
-Refill action ladder: approve generated rows only when an explicit bounded
-approval gate exists, process all existing same-campaign unenriched/unprepared
-rows in bounded batches before any source work, then copy bounded net-new rows
-from the selected source (`selectedLeadListId`, provider, and source
-fingerprint preserved), then use provider-aligned same-source-more against the
-campaign's OWN saved provider search (Sales Nav or Prospeo for cold campaigns).
-Same-provider-source-more is a bounded `--yolo` add. A DIFFERENT source or a
-source-family switch changes the reply-rate baseline and stays a manual
-alternate, not a `--yolo` side effect.
-For Signal Discovery, consume bounded net-new eligible source rows first. If
-none remain and the campaign has no reusable tab keywords or unselected posts,
-derive at most five search keywords from its saved positive ICP criteria without
-changing rubrics or thresholds. Broadening rounds follow a strict keyword-source
-ORDER because the post universe refreshes over time — a keyword searched days or
-weeks ago yields NEW posts today: (1) `keywordSource:"stale_researched"` FIRST
-re-searches the campaign's EXISTING keywords whose last search is stale (tab
-timestamp before the current run day, or no stored timestamp), deduping to posts
-not already scraped/selected; (2) `"derived"` then derives fresh keywords from the
-campaign's stored search intent; (3) `"agent_supplied"` last. When a
-`broaden_signal_search` action returns `keywordSource:"agent_supplied"`, both
-earlier tiers are receipt-proven spent this run but the 45-day universe is not
-proven dry: read the campaign brief, ICP, and persona and invent 3-5 concrete NEW
-GTM-topic keywords that are NOT in the action's `searchedKeywords` negative list —
-still without changing rubrics or thresholds, and never re-issuing a spent search.
-When a run stops asking for agent-supplied keywords (blocker
-`signal_agent_keywords_invalid`, or a pending `agent_supplied` broaden with no
-keywords), re-invoke the SAME `refill_sends` command with the run's `runId` and
-`fence` plus `agentKeywords: [your 3-5 keywords]`; the fenced run validates them
-against the negative list, consumes them once into the pending broaden round, and
-resumes automatically. An out-of-envelope payload is typed-refused so you can
-correct and re-invoke. Signal exhaustion is a
-quantified yield projection, not a fuzzy engagement read: every tier projects
-new-lead yield as the sum of scrapable engager counts across the NEW recent (<=45
-day) candidate posts times the campaign's observed headline-ICP pass rate, and the
-floor `min(remaining prep gap, 100)` is only ever evaluated on the ACTUAL
-candidates a search round returned — never as a pre-search short-circuit. A
-below-floor round at the stale or derived tier consumes that tier and escalates to
-the next one; the agent tier is the always-available terminal tier, so only an
-agent-supplied round that actually searched and yielded below floor — zero new
-posts being the projection-zero special case — is receipt-proven lane exhaustion
-(`signal_yield_below_floor`, recording the keyword-source tier, candidate post
-count, engager sum, observed pass rate, and threshold): update run state, replan,
-and continue with the exact next ranked campaign in the original sender lane chain
-during the same run. Do not persist derived keywords or lane exhaustion into
-campaign configuration; a later refill run rereads the current approved rubric and
-may re-search refreshed keywords or discover new posts and engagers.
-
-Sender-owned Post Engagers is the structural exception to general Signal
-Discovery broadening. A campaign named `<sender> - Post Engagers` with exactly
-one attached sender may select only that sender's authored posts; third-party
-keyword results can never refill it. Once its bounded sender-owned continuation
-has no reusable post/frontier, treat `sender_owned_post_required` as exhaustion
-of that campaign lane only, record it on the sender cursor, and immediately
-replan to the exact next ranked waterfall lane—normally Shared Signal
-Discovery—inside the same `--yolo` run. Do not request agent keywords, load the
-campaign brief for keyword invention, or dispatch a general Signal search against
-the Post Engagers campaign. General stale/derived/agent keyword broadening resumes
-normally only after the planner selects the shared Signal Discovery campaign.
-Source/copy/fallback requires receipt-proven exhaustion of earlier rungs:
-`existingRowFrontier.hasMoreFrontierRows:false`, zero `approvalCandidates`, no
-fresh active prep, no `stuckActiveCells`, and no non-terminal
-`approvedNotDispatched` rows. Treat anomalies, `stuckActiveCells`, and
-non-terminal `approvedNotDispatched` as diagnose-and-report gates, not
-exhaustion. Terminal `approvedNotDispatched` blockers may be reported, then the
-ladder can proceed.
-
-Repairable draft fallback: when a run ends `lanes_exhausted` (or the route
-reports no schedulable campaign) and `resolve_campaign_fill_route`
-skippedTargets contains a non-archived DRAFT campaign blocked only by
-`campaign_sequence_missing` whose table already has prospect rows and a
-completed builder pipeline (brief plus Enrich/ICP/Generate Message/Approved
-columns), `--yolo` may finish that campaign's setup with existing product
-tools and continue the waterfall into it: (1) `update_campaign` to attach
-exactly the workspace's already-eligible refill senders from the current
-eligible sender ledger — never invent or reassign other senders; (2)
-`attach_recommended_sequence` WITHOUT a currentStep override so the backend
-selects the tier-correct cascade while the approved-message gate stays
-intact; (3) invoke `refill_sends --yolo` again with the same
-workspace scope so the fresh route targets the now start-eligible campaign and
-the normal bounded prep/approve/start/schedule ladder fills it. This repairs
-only existing campaigns already holding imported prospects; it never creates
-campaigns, never touches archived campaigns, and messaging still flows through
-the campaign's own brief, rubric, and bounded approval gates.
-
-Run-local paid-credit guard: in `--yolo`, the `refill_sends` MCP command
-automatically maintains a checkpointed `refreshedPaidInmailSenderIds` set for
-the entire fenced run across resume calls. If its first target plan has stale/missing paid-InMail credit
-facts, it refreshes each selected sender at most once, reruns
-`get_refill_target_plan`, and returns the post-refresh `targetPlan` before
-choosing the next prep/source-copy/bounded-approval/read-only wait action. If fresh facts are still below
-threshold, below-threshold paid-InMail facts fall back to an existing connection
-lane, the same Sales Nav cascade campaign's connection branch, or a manual
-continuation.
-
-Freshness gate precedes scheduler wait: if any selected
-`target.senderRefillPlans[].paidInmail.status` is `missing_credit_facts` or
-`stale_credit_facts`, or the target plan contains a
-`refresh_paid_inmail_credits` candidate, do not enter `wait_for_scheduler` even
-when `remainingReadyOrProjectedGap:0`. Refresh the exact selected sender credit
-facts once, rerun `get_refill_target_plan`, and only then decide whether
-scheduler wait is the next safe action. If facts remain missing/stale after the
-single refresh attempt, stop with a paid-InMail freshness blocker instead of
-waiting on scheduler pickup.
-The standalone MCP refresh surface is the scoped route
-`/api/v3/mcp/senders/:senderId/refresh-inmail-credits` with explicit
-`workspaceId`; do not use active-workspace mutation as the automation control
-path.
-
-Compact refill lessons: sender-level target plan is final truth; trust
-`schedulerGate.sendable` and scheduler gate blockers, not raw
-`unipileAccountStatus` labels alone; use compact prep status checks for
-long-running jobs; reread target plans after prep or cancel; treat ready rows as
-intermediate; avoid huge parallel target-plan reads when output is large. If a
-campaign produces prepared/ready rows but sender-level projected coverage does
-not move after one bounded settle loop, pivot to compact prep status or a
-scheduler-proven lane. Do not keep waiting on campaign-level ready counts.
-
-For exact-date requests, pass `targetDate` to `get_refill_target_plan`. If you
-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
-bypasses limits.
-A scheduler sweep is a visible workspace-wide scheduling side effect. The
-request packet limits the expected target changes to its exact date, senders,
-action types, campaigns, tables, and stable sources, but the product scheduler
-may also place unrelated eligible workspace work; disclose that possibility in
-the approval packet and receipt. For an exact-date sweep action, execute it
-once, then reread the full target plan before taking or presenting another
-action.
-The exact-date `run_scheduler_sweep` may schedule eligible workspace cells
-through existing product gates; it never sends directly or raw-writes scheduler
-fields. Only non-exact or no-sweep scheduler waits are read-only.
-On resume, reconcile the current target plan and matching sweep status/receipt
-before retrying. A matching same-key terminal receipt replays; an
-`uncertain_outcome` stops for reconciliation and must not schedule again.
-Scheduler-run receipt interpretation: `cellsConsidered is allocation-attempt
-count`, not total ready supply, while `readyCellsFound` is ready inventory found
-before prefilters. Inspect `campaignScopeSummary` before assuming the selected
-refill campaign/table was included; if absent, do not infer that target was
-ready-but-blocked. Interpret `prefiltered` as ready cells removed before
-allocation, `skipped` as considered cells blocked by scheduler gates, and
-`deferred` as considered cells waiting on windows/capacity/cooldown. For ready
-closed-InMail cells with stale paid-credit prefilter/defer reasons, refresh
-paid-InMail credits once through existing tools, then rerun `run_scheduler_sweep`
-or read `action:"status"`; `refresh_paid_inmail_credits_then_rerun` is that
-path. `wait_for_capacity_or_window` means report loaded/capped/waiting and do
-not source or prep more rows; `no_ready_cells_continue_refill_prep` means return
-to the refill/prep ladder. Do not treat `cellsScheduled:0` alone as failure.
-If the target plan is complete by projected coverage, report that the selected
-target is already filled and no-op without asking for approval. If the ready
-buffer covers the projected gap, paid InMail credit facts are fresh for every
-selected paid-InMail lane, but scheduled coverage is still short, keep the run
-open in a persistent read-only scheduler wait loop. Honor the emitted wait
-metadata: reread `get_refill_target_plan` after about 30 seconds by default (or
-the action's explicit `rereadAfterMs`), never use a blind hard-coded sleep, and
-stop at the named bound using `receipt_deadline > unchanged_poll_bound >
-run_budget` precedence. A matching active/uncertain request key is never
-redispatched. Continue until projected coverage fills the target, a concrete
-non-scheduler blocker appears, a named bound stops the run, or Christian
-explicitly asks to stop or only receive a status report. Treat
-`awaiting_scheduler_after_ready_buffer` as an in-progress wait state, not a
-close-out condition.
-Wait actions are gates, not competing goals. When `wait_for_active_work` or
-`wait_for_scheduler` includes receipt `wait.deadlineAt`, honor that absolute
-deadline; if it is expired on this call, escalate to diagnostics with the
-receipt evidence instead of issuing another blind wait.
-If paid InMail credit facts are stale or missing and the first target plan
-contains `refresh_paid_inmail_credits`, do not present that as the operator's
-next action in `--yolo`. Do not present paid-credit refresh as the next operator
-action after `refill_sends` returns `autoPaidInmailRefresh` and the
-post-refresh `targetPlan`. Trust `refill_sends.autoPaidInmailRefresh`: it should
-show the exact sender ids refreshed once, sender-credit-cache write receipts,
-and a returned post-refresh `targetPlan`. Continue from that post-refresh packet.
-If paid InMail is below threshold after the fresh credit read, report the exact
-campaign/table/column threshold action or same-campaign connection fallback;
-`--yolo` does not lower paid-InMail thresholds or create campaigns.
-
-If the plain route's managed waterfall targets are stale, for example skipped
-targets show archived/completed shared slots or the returned targets do not cover
-the named sender, immediately run the active route refetch before declaring a
-sender blocked. Current dashboard-active `PAUSED` campaign-backed sequence
-campaigns are start-eligible refill candidates; read refill state before deciding
-whether to prep, approve, start, or skip. Do not treat them as archived inventory.
-
-For interactive Codex or Claude Code sessions, that approval must use the
-host-native structured question gate, not plain chat:
-
-- Codex: use `request_user_input`.
-- Claude Code: use `AskUserQuestion`.
-
-The approval question must present the final refill step with exactly two
-choices: `Accept` and `Decline`. Render the full operator output packet in
-normal chat immediately before opening the structured approval question so it
-can be displayed as Markdown. The chat packet must include workspace, sender
-scope, a campaign-by-campaign table with campaign name, sender names, action,
-target count/cap, source/list, and blocker/skip reason, then exact ids,
-expected side effects, forbidden actions, and the stop condition. The structured
-question body must be compact and refer back to the posted packet instead of
-duplicating it. Treat `Accept` as permission for only the rendered target, caps,
-mode, and side effects. Treat `Decline` as a hard stop with no mutation.
-
-If Christian includes `--yolo` in the same refill request, treat that flag as
-auto-accept for the rendered bounded refill packet after the required fresh state
-reread. For sender-scoped language with no named senders, `--yolo` means all
-eligible healthy senders enrolled in active campaign-backed sequence campaigns in
-the requested `workspaceId`. Without `--yolo`, if Christian did not name senders, ask
-which eligible enrolled senders to refill before choosing campaigns or mutating.
-
-`--yolo` covers the exact sender set, action/date target, caps, original
-planner-emitted lane chains, approval mode, and refill side effects. It may
-authorize `start_campaign` only when the fresh packet's selected evergreen lane,
-selected campaign ranking, and original lane chain name the same `PAUSED`,
-dashboard-active, campaign-backed sequence refill target. Starting a paused
-campaign can let the product scheduler schedule/send
-approved eligible sequence actions, so include that expected side effect in the
-packet. It does not authorize starting unrelated, archived, completed, draft, or
-direct campaigns, separate launch/send actions, archive or delete cleanup,
-direct scheduler writes, sender reassignment, paid-InMail threshold changes,
-connection campaign creation, paid-InMail credit refreshes outside the exact
-rendered sender packet, or campaigns outside those
-selected for the eligible sender set. Refuse if a fresh selection leaves the
-original lane chain or changes the sender/action/date/cap/side-effect envelope.
-Campaign/table/action-key/readiness revisions and sent/scheduled counts may
-change as the fresh planner advances the approved lane chain; those changes do
-not require a second approval. Treat leaving that stable envelope as scope
-drift and refuse it.
-
-Short form: start only the exact selected `PAUSED` campaign authorized by all
-three fresh planner proofs; leave every unselected paused fallback unchanged.
-
-In `--yolo`, continue until projected coverage fills or a concrete blocker is
-proven. After each
-apply/prep/source-copy/bounded-approval/read-only wait result, reread state, settle processing when needed, and move to
-the next selected sender or start-eligible same-packet campaign instead of
-stopping after the first partial result. Receipt-proven source exhaustion must
-advance the planner run-state cursor before choosing the next lane. If no
-in-envelope safe action remains,
-return concrete continuation options with campaign names, exact ids, which option
-is still covered by the current packet, and which option needs a new approval
-packet.
-
-For `--yolo` fill/schedule requests, completion means projected saturation
-(`sent + scheduled`) for the scheduler-forward target window, not merely
-prepared/approved/ready rows. Maintain a target-window saturation ledger per
-selected sender: selected send days, gross capacity, actual sent cells, future
-scheduler-owned scheduled cells with non-null `scheduledFor`, projected count,
-ready-to-schedule buffer, remaining projected gap, paid-InMail feasibility,
-`targetShapeRevision`, `stateRevision`, and the next MCP primitive that can
-reduce the gap. After every apply/prep/source-copy/bounded-approval/read-only wait result, wait for processing, reread
-the target plan/refill state, recompute the ledger, then keep applying safe
-bounded actions until projected coverage fills the target window or a concrete
-non-scheduler blocker is proven.
-If ready rows cover the projected gap but the scheduler has not picked them up
-yet, report loaded, awaiting scheduler and run the persistent read-only
-scheduler wait loop. Do not finish the refill goal, mark it complete, or mark it
-blocked only because it is still `awaiting_scheduler_after_ready_buffer`; keep
-waiting unless Christian stops the run or the host cannot continue.
-
-Carry the canonical `refill_reporting.v2` DTO through progress, continuation,
-replay, and terminal reporting without recomputing counts or losing live epoch,
-snapshot sequence, reset reason, watermark, blockers, compatibility, or
-terminal outcome. Redact raw copy and prospect fields.
-
-Future scheduled coverage and already sent actions are distinct; only
-scheduler-owned future scheduled actions count as scheduled coverage. For
-multiple target dates, finish D1 execution and the full D1 reread before
-planning D2. Completion proof is product-native Sellable MCP evidence only:
-target plan, campaign refill state, scheduler capacity, sweep/status, and
-bounded receipts. Never use individual cell ids, Prisma, SQL, direct database
-access, or production-environment scripts as completion proof.
-
-In `--yolo`, the default fill target is the scheduler-forward 48-hour window
-unless `--target-date`/`targetDate`, `--until`/`untilDate`, or an explicit
-compatibility `horizonSendDays` is provided. If a target date is provided,
-compute bounded gaps for only that sender-local date using scheduler-fillable
-slots. If an until date is provided, compute bounded gaps through that
-sender-local date inclusive, skipping no-send days and never extending beyond
-that date without a new packet. For each target sender, compute the bounded gap
-from that sender's healthy daily capacity, existing future scheduler-owned
-scheduled sends, and rows already ready to schedule across active campaigns
-enrolled with that sender. Then pick the best same-sender campaign to fill the
-gap: prefer recent/future scheduler-owned sends for that sender, then strongest
-recent result evidence, then source health. Do not stop
-after filling only one sender when the request was sender-scoped. If a
-same-source copy hits the campaign-table row cap, split the current source into
-a bounded LinkedIn profile source list, confirm only that smaller list into the
-same campaign, and operate on the copied review batch. Do not fall back to
-on-demand campaigns or unrelated active-campaign fills.
-
-Public concepts are regular campaign and evergreen campaign. Internal direct
-campaign types are unsupported refill targets. `fill_campaign_horizon` is only a
-legacy evergreen-only lower-level primitive after route and refill-state
-evidence proves an evergreen target.
+Do not keep polling after a terminal. `loaded_awaiting_scheduler` is a valid
+terminal, not permission for a host-owned loop. The sole refill-ladder expansion
+that asks the user in `--yolo` is `new_campaign_required`; refill itself never
+creates that campaign.
+
+## Non-negotiable authority and proof
+
+- Before preparation, approval, or exact-date scheduling, require a validated
+  compiled campaign and positive exact target readiness identity from the
+  backend compiler: `profileSchemaVersion`, `compilerVersion`,
+  `campaignDigest`, `actionColumnId`, action, `pathDigest`,
+  `dependsOnColumnIds`, `runCondition`, the selected target's `capabilities`,
+  `requestId`, `effectId`, and `dateGuards`. Never infer no-message behavior
+  from a missing Generate Message column. Prepare rows according to the
+  persisted sequence; bounded enrichment and LLM prerequisite calls are
+  allowed only when authorized by the exact readiness packet and receipted.
+- Refuse approval outside the bounded authorized cohort. The exact selected
+  target path controls message, subject, comment, reaction, and row approval.
+  For exact dates, require the date strictly after sender-local today and inside
+  the fill horizon. Prepared, approved, and ready rows remain intermediate
+  evidence; completion requires request/effect-attributed scheduler-owned
+  scheduled readback.
+- Execute one bounded primitive, then perform a full authoritative reread.
+  Never call a LinkedIn outreach/provider-send surface from refill. No direct
+  sends, raw scheduler writes, broad approval, threshold/limit changes,
+  sender reassignment, destructive cleanup, or new campaign creation.
+- Maintain the target-window saturation ledger per sender: selected days,
+  gross capacity, actual sent, future scheduler-owned scheduled with non-null
+  `scheduledFor`, projected coverage (`sent + scheduled`), ready buffer,
+  remaining gap, paid-InMail feasibility, `targetShapeRevision`, and
+  `stateRevision`. Future scheduled coverage and already sent actions are
+  distinct.
+- Carry canonical `refill_reporting.v2` unchanged through progress,
+  continuation, replay, and terminal output. Completion proof is Sellable MCP
+  evidence only: target plan, campaign refill state, scheduler capacity,
+  sweep/status, and bounded receipts. Never use individual cell ids, Prisma,
+  SQL, direct database access, or production-environment scripts as completion
+  proof. Redact raw copy and prospect fields.