@sellable/install 0.1.326 → 0.1.327

package/skill-templates/refill-sends.md

@@ -58,97 +58,359 @@ 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.
-
-## 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.
+- `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
+refill_sends({ yolo?: boolean, executionMode?: "manual" | "scheduled" | "yolo", requireWorkspace?: boolean, workspaceId?: string, senders?: string[], senderIds?: string[], senderNames?: string[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD" })
+```
+
+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, 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, send,
+or write scheduler rows. Continue with the workflow below for route selection,
+state rereads, approval gating, source import, preparation, and bounded
+approval.
+
+## 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
-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:false, executionMode:"scheduled", requireWorkspace:true, workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
+get_refill_target_plan({ intent:"plain", approvalMode:"mark_ready", workspaceId:"cmlq1v8ms0000jx04ang4hi7e" })
 ```
-<!-- REFILL_CONTRACT_GENERATED:END -->
+
+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`, and
+  `Still need`.
+- `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.
+- `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.
+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.
+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. Poll
+`get_refill_target_plan` every 60-120 seconds, or on the host's next continuation
+interval, until projected coverage fills the target, a concrete non-scheduler
+blocker appears, 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.
+
+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.

package/HERMES-SLACK-PROFILE-SCOPING.md

@@ -1,169 +0,0 @@
-# Hermes Slack Profile Scoping
-
-Use this when creating or updating customer Hermes profiles that need Slack
-access.
-
-## Default Rule
-
-For Sellable-managed customer channels, use one dedicated Slack app/token pair
-per active Hermes customer profile. Run native `hermes -p <profile> gateway run`
-for that profile only. Do not run multiple active Hermes profile gateways
-against the same `SLACK_APP_TOKEN`.
-
-The customer's Slack app is bound to the exact Slack channel id and the
-customer's profile-local Sellable MCP config. Customer profiles must not store
-or read Sellable Admin MCP credentials, admin Slack app tokens, or sibling
-profile config.
-
-The shared dispatcher remains a fallback/research path only. Use it only when
-Sellable Admin explicitly owns one shared listener and route registry.
-
-The 2026-07-06 Hostinger POC proved the native Hermes listener for the
-`sellable-admin` profile with the existing `Sellable Reply Bot` app in
-`#team-chat`: a human mention produced a new Hermes session and a threaded bot
-reply. Treat that as proof that the gateway/listener path works for one owning
-profile, not as approval for multiple active customer profiles sharing one app
-token.
-
-The same day, the `acme` profile reused the same redacted Slack token
-fingerprints for an outbound-only smoke to `#sellable-acme` via:
-
-```bash
-hermes --profile acme send --to slack:C0BFERDV3N0 --subject '[Hermes acme smoke]' ...
-```
-
-That succeeded and is useful as an internal smoke test. It does not change the
-inbound listener rule: each active customer profile needs its own native Slack
-app token pair unless Sellable Admin deliberately chooses the dispatcher
-fallback.
-
-## Which Slack Values Are Enough
-
-For outbound sends and ordinary Slack Web API calls, the important value is the
-profile-local `SLACK_BOT_TOKEN`.
-
-For native Hermes live listening through Slack Socket Mode, the profile also
-needs `SLACK_APP_TOKEN`, an app-level `xapp-...` token with `connections:write`.
-`SLACK_APP_ID`, `SLACK_CLIENT_ID`, `SLACK_CLIENT_SECRET`,
-`SLACK_SIGNING_SECRET`, `SLACK_VERIFICATION_TOKEN`, `SLACK_TEAM_ID`, and
-`SLACK_OPERATOR_EMAIL` do not replace `SLACK_APP_TOKEN`.
-
-## Required Slack App Shape
-
-Outbound Slack sends can work with fewer permissions. Native Hermes inbound
-listening needs the Slack app itself to be configured for Socket Mode and event
-delivery:
-
-- Enable Socket Mode.
-- Create an app-level token with `connections:write`.
-- Install the bot with `app_mentions:read`, `channels:history`,
-  `channels:read`, `chat:write`, `groups:history`, `groups:read`,
-  `im:history`, `im:read`, `mpim:history`, `mpim:read`, and `users:read`.
-- Subscribe bot events for `app_mention`, `message.channels`,
-  `message.groups`, `message.im`, and `message.mpim`.
-- Reinstall the app after changing scopes or event subscriptions.
-
-If the Slack app has `incoming-webhook`, Slack will ask for a webhook channel
-during reinstall. Pick the profile home channel. That webhook selection does
-not replace `SLACK_ALLOWED_CHANNELS`; keep the profile-local allowlist explicit.
-
-## Profile Bootstrap Command
-
-Use the Sellable installer profile bootstrap:
-
-```bash
-sellable hermes profile bootstrap \
-  --profile acme \
-  --profiles-root /srv/hermes/profiles \
-  --workspace-id ws_acme \
-  --workspace-name Acme \
-  --token-file /run/secrets/sellable-acme-token \
-  --slack-bot-token "$SLACK_BOT_TOKEN" \
-  --slack-app-token "$SLACK_APP_TOKEN" \
-  --slack-home-channel C0ACME12345 \
-  --slack-home-channel-name sellable-acme \
-  --slack-allowed-users U0OPERATOR1 \
-  --slack-require-mention true \
-  --json
-```
-
-If `--slack-home-channel` is supplied and `--slack-allowed-channels` is omitted,
-the installer writes `SLACK_ALLOWED_CHANNELS=<home-channel-id>` automatically.
-That makes the profile fail closed to the customer channel by default.
-
-Use `--slack-allowed-channels C...,G...` only when a profile is intentionally
-allowed to listen in more than one channel. Pass Slack IDs, not `#channel-name`
-strings or wildcards.
-
-## Resulting Profile Env
-
-For the dedicated customer Slack app model, the profile-local `.env` should
-contain only scoped Slack keys for that profile:
-
-```env
-SLACK_BOT_TOKEN=...
-SLACK_APP_TOKEN=...
-SLACK_HOME_CHANNEL=C0ACME12345
-SLACK_HOME_CHANNEL_NAME=sellable-acme
-SLACK_ALLOWED_CHANNELS=C0ACME12345
-SLACK_ALLOWED_USERS=U0OPERATOR1
-SLACK_REQUIRE_MENTION=true
-```
-
-Keep the file mode at `0600`. Do not copy raw tokens into planning docs, chat,
-or committed artifacts. Record token fingerprints only.
-
-The profile's Hermes MCP env must also include the profile-local Sellable
-config, customer workspace lock, and fail-closed guard:
-
-```yaml
-SELLABLE_CONFIG_PATH: /srv/hermes/profiles/acme/sellable/config.json
-SELLABLE_CONFIGS_DIR: /srv/hermes/profiles/acme/sellable/configs
-SELLABLE_LOCK_WORKSPACE_ID: ws_acme
-SELLABLE_REQUIRE_WORKSPACE_LOCK: "1"
-```
-
-`SELLABLE_REQUIRE_WORKSPACE_LOCK=1` means an unbound customer profile fails
-closed before making Sellable API calls instead of falling back to shared or
-admin config state. Only the `sellable-admin` profile should provision,
-inspect, or repair other profiles.
-
-For the shared dispatcher model, do not copy the shared `SLACK_BOT_TOKEN` or
-`SLACK_APP_TOKEN` into customer profile `.env` files. The dispatcher owns those
-tokens and route metadata decides the customer profile.
-
-## Shared Dispatcher Ownership
-
-The shared Slack dispatcher and its route registry are fallback Sellable Admin
-surfaces. This customer-facing installer must not create shared route bundles or
-write shared listener tokens. Sellable Admin owns Slack app creation and profile
-provisioning, then calls this installer for profile-local Sellable runtime
-bootstrap inside the already-provisioned Hermes profile.
-
-## Verification
-
-Run the installer and dispatcher UAT before publishing installer changes:
-
-```bash
-npm run test:unit -- tests/install-package/agent-preferences.test.ts
-scripts/run-phase92-hermes-profile-bootstrap-uat.sh --mode local-temp
-scripts/run-phase92-hermes-profile-bootstrap-uat.sh --mode linux-shaped
-scripts/run-phase031-hermes-slack-dispatcher-uat.sh --mode local-fixture
-```
-
-Expected proof:
-
-- profile-local Sellable config paths remain authoritative
-- generated profile `.env` has `SLACK_HOME_CHANNEL`
-- generated profile `.env` has `SLACK_ALLOWED_CHANNELS`
-- `acme` allowlist points at the `sellable-acme` fixture channel id
-- redaction scan passes
-
-## Current Phase 03 Status
-
-Phase 03 proved the profile-scoped installer path, outbound Hermes send path,
-and live Slack listener for the `sellable-admin` profile. Phase 03.1 now targets
-dedicated native Slack apps per customer profile, profile-local Sellable MCP
-locks, and fail-closed customer profile behavior so managed customer channels
-can be onboarded through the VPS without local-only browser state, manual SSH
-edits, or untracked processes.