@sellable/install 0.1.340-phase981.20260711223346 → 0.1.342

package/skill-templates/refill-sends.md

@@ -58,100 +58,402 @@ allowed-tools:
 
 # Refill Sends
 
-This is the concise public adapter for the typed refill contract. The backend
-planner, durable run, flow asset, and contract asset own allocation, retries,
-circuit behavior, scheduler placement, and completion rules.
-
-Compatibility triggers include `fill`, `refill sends`, `max out sends`,
-`load everyone up`, and `fill horizon sends`. Route every one through this same
-typed workflow; none authorizes a broader or legacy execution path.
-
-Measure completion from canonical projected coverage (`sent + scheduled`). The
-workflow does not lower paid-InMail thresholds; a threshold change remains a
-separate operator gate.
-
-Exact zero-shot form:
-
-`$sellable:refill-sends in sellable.dev workspace --target-date YYYY-MM-DD --yolo`
-
-Claude Code uses `/sellable:refill-sends`. Optional selectors are `--sender`,
-`--target-date`, `--until`, and `--yolo`.
-
-## Bootstrap and execute
-
-1. Call `mcp__sellable__get_auth_status({})`. If authentication is incomplete,
-   use the returned login path and stop until verified.
-2. First resolve and echo the explicit workspace and date scope. In scheduled or
-   `--yolo` mode, a missing `workspaceId` is `WORKSPACE_REQUIRED`; never change
-   shared active-workspace state to guess. Echo `workspaceId`, workspace name,
-   `targetDate` or other date selector, sender selectors, action selectors, and
-   approval mode before continuing.
-3. Load
-   `mcp__sellable__get_subskill_prompt({ subskillName: "refill-sends-workflow" })`
-   until `hasMore:false`.
-4. Load
-   `mcp__sellable__get_subskill_asset({ subskillName: "refill-sends-workflow", assetPath: "core/flow.v1.json" })`
-   until `hasMore:false`.
-5. Load
-   `mcp__sellable__get_subskill_asset({ subskillName: "refill-sends-workflow", assetPath: "core/contract.v2.json" })`
-   until `hasMore:false`. Validate `contractVersion`, `cacheVersion`, and
-   `contractHash` against the flow and generated metadata. Stop with
-   `unsupported_refill_contract_major` or `refill_contract_hash_mismatch` on
-   incompatibility; do not emulate missing assets from repo files or memory.
-6. Invoke only the public durable entrypoint:
-   `mcp__sellable__refill_sends({ workspaceId, targetDate, untilDate, horizonSendDays, senderIds, senderNames, actionTypes, yolo, executionMode, requireWorkspace:true })`.
-   Preserve the exact scope and approval echo returned by the tool on resume.
-   Pass `expectedActionKey` only when the rendered first global action contains
-   an actual non-empty `actionKey`; never infer it from `type`, `toolName`, or
-   `actionFingerprint`.
-
-## Operator packet
-
-Always render the normal bounded approval packet, even under `--yolo`. Yolo is
-bounded auto-accept of that packet; it is not broader authority. Use campaign
-and sender names first, with IDs secondary. Preserve these six labels exactly:
-
-- Need to prepare
-- Goal
-- Already sent
-- Scheduled
-- Ready and waiting to be scheduled
-- Still need
-
-Show `targetShapeRevision`, `stateRevision`, action key, exact target date,
-side-effect class, expected targets, placement cap, and approval expiry. The
-public tool runs one packet-named primitive, records its receipt, rereads
-authoritative state, and replans. Keep any existing Codex goal open through
-settling; a skill cannot create `/goal` by itself.
-
-## Safety and terminal truth
-
-The generated contract is authoritative. Never direct-send, raw-write scheduler
-fields, create/archive/delete campaigns, lower thresholds, switch an unselected
-source family, mutate sender configuration, or start an unapproved campaign.
-Paused campaign start and workspace-wide scheduler placement remain separately
-named, product-gated side effects. Sellable MCP receipts are the proof surface;
-never use Prisma, SQL, direct database access, or production scripts as proof.
-
-Render typed terminal truth name-first. Success is `projected_full`. Otherwise
-report the concrete blocker or `deadline_reached`, `iteration_limit`, or
-`operator_stopped` with target-specific evidence. A ready buffer or
-`awaiting_scheduler_after_ready_buffer` is
-`ready_buffer_exists_is_not_complete`, never completion.
-
-<!-- REFILL_CONTRACT_GENERATED:START -->
-## Generated refill contract metadata
-
-contractVersion: 2.0.0
-cacheVersion: refill-contract-v1
-contractHash: e54ba0f80bc534fd70fd8c10c1caab109fe9a91c205cfc423f5f6735cd53fdc1
+Use this public command wrapper for plain operator requests such as "fill",
+"refill sends", "max out sends", "load everyone up", or "fill horizon sends".
+
+Host command names:
+
+- 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:
 
 ```text
-scope: workspace_id, target_date, sender_selectors, campaign_selectors, approval_mode, contract_identity, installed_identity
-gates: approval_packet, one_primitive, fresh_reread, normalized_accounting, prep_circuit
-release identities (independent of semantic hash): mcpPackageVersion, installPackageVersion, codexPluginVersion
-forbidden: direct_send, raw_scheduler_write, campaign_create, campaign_archive_delete, threshold_lowering, unselected_source_mutation, unapproved_campaign_start, sender_config_write
-terminal: projected_full, concrete_blocker, deadline_reached, iteration_limit, operator_stopped, capped_by_scheduler, loaded_awaiting_scheduler, lanes_exhausted, not_an_evergreen_workspace, no_refillable_campaigns
-ready_buffer_exists_is_not_complete
+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" })
 ```
-<!-- REFILL_CONTRACT_GENERATED:END -->
+
+That command helper normalizes arguments and returns the execution contract. In
+non-yolo mode it does not mutate. In `--yolo`, it may execute exactly one safe
+bounded primitive from the fresh `target.globalActionQueue[0]`, then reread and
+return the new target plan; currently safe primitives are paid-credit refresh,
+existing-row message preparation, generated-message approval, receipt-proven
+same-source row copy, a request-scoped exact-date product scheduler sweep, and
+read-only wait rereads. Same-source copy/source
+fallback is 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, switch source families, create
+campaigns, 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`, `targetDate`, sender ids, action
+types, campaign/table/source ids, `targetShapeRevision`, and `actionKey` in the
+rendered packet. `stateRevision` and sent/scheduled/ready counts are mutable
+progress, not approval-scope drift. Execute only
+`target.globalActionQueue[0]`, then perform a full authoritative reread before
+deciding any next action.
+
+## 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:
+
+```text
+refill_sends({ yolo:true, executionMode:"yolo", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+get_refill_target_plan({ intent:"plain", approvalMode:"approve", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+list_senders({ workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+```
+
+Clover scheduled automation must name the Clover workspace explicitly:
+
+```text
+refill_sends({ yolo:false, executionMode:"scheduled", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+get_refill_target_plan({ intent:"plain", approvalMode:"mark_ready", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+```
+
+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.
+
+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:
+
+```text
+get_subskill_prompt({ subskillName: "refill-sends-workflow" })
+get_subskill_asset({ subskillName: "refill-sends-workflow", assetPath: "core/flow.v1.json" })
+```
+
+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 exactly one globally ranked primitive from
+  `target.globalActionQueue[0]`, then rerun `get_refill_target_plan` with the
+  same `workspaceId` before
+  choosing another action.
+- 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 lowering and campaign
+  creation are manual continuations only.
+
+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 source-more. A new source or
+provider switch changes the reply-rate baseline and is a manual alternate, not a
+`--yolo` side effect.
+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.
+
+Run-local paid-credit guard: in `--yolo`, the `refill_sends` MCP command
+automatically maintains a `refreshedPaidInmailSenderIds` set for the current
+command call. 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` only covers the exact sender set, per-sender target campaigns, caps,
+approval mode, and side effects in the packet. It may authorize `start_campaign`
+only for selected `PAUSED`, dashboard-active, campaign-backed sequence refill
+targets when the rendered packet names the exact campaign ids and start side
+effect. 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. Stop and re-plan if the route, sender set,
+ids, caps, blockers, paid-InMail feasibility, action class, or side-effect class
+drift before mutation. Sent/scheduled counts increasing toward the approved
+target are expected progress:
+they change `stateRevision`, not `targetShapeRevision`, and do not require a
+second approval.
+
+In `--yolo`, continue as far as the rendered packet safely allows. 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. If no in-packet 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.
+
+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.