@sellable/install 0.1.301 → 0.1.303

package/package.json

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

package/skill-templates/refill-sends-evergreen.md

@@ -1,84 +1,19 @@
 ---
 name: refill-sends-evergreen
-description: Plan evergreen waterfall send refill work through the Phase 85 dry-run workflow.
+description: Deprecated alias for refill-sends-v2.
 visibility: public
 allowed-tools:
-  - mcp__sellable__refill_sends_evergreen
-  - mcp__sellable__get_evergreen_refill_plan
   - mcp__sellable__get_subskill_prompt
-  - mcp__sellable__get_subskill_asset
-  - mcp__sellable__get_auth_status
-  - mcp__sellable__get_active_workspace
-  - mcp__sellable__list_workspaces
-  - mcp__sellable__get_workspace
 ---
 
 # Refill Sends Evergreen
 
-Use this public command wrapper for evergreen waterfall refill requests such as
-"refill evergreen", "fill evergreen senders", "load evergreen lanes", or
-"plan evergreen refill".
+Superseded by refill-sends-v2. The prompt name now redirects through
+`DEPRECATED_SUBSKILL_PROMPT_REPLACEMENTS`; do not call this deprecated prompt
+directly.
 
-Host command names:
-
-- Claude Code: `/sellable:refill-sends-evergreen`
-- Codex: `$sellable:refill-sends-evergreen`
-
-Phase 85 is read-only, dry-run, zero mutations. It plans the deterministic
-waterfall-ladder refill packet and writes a local dry-run journal, but it does
-not prepare messages, approve messages, start campaigns, schedule sends, send
-messages, refresh paid InMail credit facts, create campaigns, or change source
-configuration. Execution ships in the follow-up phase.
-
-## Entry
-
-Resolve the explicit `workspaceId` from the request, automation config, or
-active workspace readback. Scheduled or autonomous usage must carry
-`workspaceId` on every tool call. If the workspace is missing or ambiguous, stop
-with `WORKSPACE_REQUIRED`; do not switch the shared active workspace.
-
-Start with the command contract:
+Use `refill-sends-v2` instead:
 
 ```text
-refill_sends_evergreen({ workspaceId })
+get_subskill_prompt({ subskillName: "refill-sends-v2" })
 ```
-
-Then load the internal workflow prompt and flow asset:
-
-```text
-get_subskill_prompt({ subskillName: "refill-sends-evergreen-workflow" })
-get_subskill_asset({ subskillName: "refill-sends-evergreen-workflow", assetPath: "core/flow.v1.json" })
-```
-
-Continue both loads until `hasMore:false`; parse the flow JSON and verify
-`workflow:"refill-sends-evergreen-workflow"` with a `v1` version before the
-planner call.
-
-Call the dry-run planner with the explicit workspace id:
-
-```text
-get_evergreen_refill_plan({ workspaceId, senderIds?, runState?, journal?, journalNote? })
-```
-
-Use `senderIds` only when the user scoped the request to exact senders. Use
-`runState` only for an explicit what-if dry run; otherwise let the MCP read
-local lane memory hints. Leave `journal` enabled unless the user specifically
-asked for no local journal.
-
-## Report
-
-Review the returned packet before giving a recommendation:
-
-- `planRevision` starts with `pr1:`.
-- `stateRevision` identifies the current readback.
-- `packet` is the operator-facing facts receipt.
-- `plans[]` contains per-sender lane decisions and itinerary details.
-- `globalActionQueue[]` is a dry-run sequence only in Phase 85.
-- `evergreen.enumeratedRungs` and each action's `evergreenRung` map to the
-  locked ladder from the workflow asset.
-- `journalPath` points to the dry-run markdown journal written by the MCP.
-- `sideEffects` must be all false.
-
-Report campaign names and sender names first, ids second. Include the chosen
-rung, the itinerary, the plan revision, the journal path, and any blockers or
-warnings. Stop after the report; do not execute the action queue in Phase 85.

package/skill-templates/refill-sends-v2.md

@@ -0,0 +1,156 @@
+---
+name: refill-sends-v2
+description: Execute refill sends v2 through the fenced evergreen refill loop, with dry-run and resume support.
+visibility: public
+allowed-tools:
+  - mcp__sellable__refill_sends_v2
+  - mcp__sellable__get_refill_plan_v2
+  - mcp__sellable__get_subskill_prompt
+  - mcp__sellable__get_subskill_asset
+  - mcp__sellable__get_auth_status
+  - mcp__sellable__get_active_workspace
+  - mcp__sellable__list_workspaces
+  - mcp__sellable__get_workspace
+---
+
+# Refill Sends V2
+
+Use this command for refill requests such as "refill sends", "fill evergreen
+senders", "load everyone up", "run Damiano", or "show a dry run for this
+workspace".
+
+Host command names:
+
+- Claude Code: `/sellable:refill-sends-v2`
+- Codex: `$sellable:refill-sends-v2`
+
+`refill_sends_v2` is the execution surface. In real-run mode it starts or
+resumes a fenced refill run, reads a fresh packet, executes only the packet's
+named bounded work, verifies the result, and returns either a terminal report, a
+blocked report, or an in-progress resume handle. In dry-run mode it stays
+read-only and writes only a dry-run journal.
+
+## Entry
+
+Resolve the explicit `workspaceId` from the request, automation config, or
+active workspace readback. Scheduled or autonomous usage must carry
+`workspaceId` on every tool call. If the workspace is missing or ambiguous, stop
+with `WORKSPACE_REQUIRED`; do not switch the shared active workspace.
+
+For a real refill run:
+
+```text
+refill_sends_v2({ workspaceId, intent:"auto", senderIds?, approvalMode? })
+```
+
+For read-only inspection:
+
+```text
+refill_sends_v2({ workspaceId, dryRun:true, intent:"auto", senderIds? })
+```
+
+To resume an in-progress run, pass the handle back exactly:
+
+```text
+refill_sends_v2({ workspaceId, runId, fence })
+```
+
+If a stale handle loses the lease, the tool reports the holder status and the
+approximately 10 minute lockout window. Reinvoke with the current handle or wait
+for lease expiry; never guess a fence.
+
+The default `intent:"auto"` inspects `managed_waterfall`,
+`dashboard_evergreen`, and `active_campaign` lane sources. Report the lane
+source and lane chain as proof for every selected sender.
+
+If membership blocks a workspace read, report the structured
+`workspace_access` blocker instead of retrying auth or switching workspaces.
+
+## Authority
+
+The run may execute only packet-named bounded work:
+
+- approve generated messages that are ready for review (`approve_messages`);
+- enrich the next batch of unenriched rows (`enrich_more`);
+- copy leads already found into the campaign table (`reconcile_source_copy`);
+- re-run errored enrichment/message cells (`rerun_errored_cells`);
+- find more leads via this campaign's original source (`add_leads_same_source`)
+  only for mechanical same-source continuations;
+- start the paused campaign so ready rows can schedule (`start_campaign`) only
+  when the campaign is in the packet's pinned lane chain;
+- refresh paid InMail credit facts during bootstrap and once per scheduler-wait
+  entry when the packet requires it.
+
+The loop records planned -> did -> outcome before and after every foreign
+mutation. It refuses stale packets by fingerprint and validates packet
+coherence before dispatch. The planner owns repair decisions: if a batch needs
+repair, the next packet names the repair rung; the loop bounds and refuses, it
+does not improvise fixes.
+
+Do not create campaigns, switch provider families, lower thresholds, write
+scheduler fields, send messages, archive/delete campaigns, or mutate
+brief/filter/message/sequence/sender config unless a separate exact approval
+packet explicitly authorizes that work. In short: no campaign creation, no
+provider-family switch, no threshold lowering, no scheduler writes, no
+launch/send/archive/delete, and no brief/filter/message/sequence/sender
+mutation.
+
+## Continuations
+
+Sales Nav and Prospeo source continuations that are not yolo-safe are blocked
+as executable scoped handoffs. The report will include text shaped like:
+
+```text
+$sellable:create-campaign [campaignId]
+```
+
+That handoff is run in a separate thread only after explicit approval. Scope is
+strict: add leads through this campaign's existing source, keep the same
+saved-search identity, import mode `add` into the same source list, and do
+source work only. It is never a new campaign, provider-family switch, brief
+change, rubric change, message change, sequence change, or sender change.
+
+## Verification
+
+The loop verifies whole rows before replanning. It reattaches to an own active
+prep job instead of re-dispatching, waits on foreign prep jobs without adopting
+their outcomes, waits on active enrichment/import work by rereading the packet,
+and treats capped scheduler capacity as complete.
+
+Scheduler waits are cross-invocation. Each tool call polls briefly under the
+host guard, heartbeats the run lease, and may return:
+
+```text
+{ status:"in_progress", runId, fence, gate, guidance }
+```
+
+Reinvoke with that handle. The approximately five minute scheduler budget is at
+the run level, not one tool call. A window-closed or loaded-awaiting scheduler
+report must include remaining-ready count, exact expected pickup time, and the
+resume handle; never treat bare "awaiting scheduler" copy as a final answer.
+
+After the first prep batch, read the conversion-verdict journal line. It is
+rendered from packet facts: `supplyCensus`, `censusReason`, and
+`pipelineDiagnosis.firstFailing`. If the verdict is honest rubric failure, the
+human decision is to update the rubric or change lead source; refill does not
+mutate those automatically.
+
+## Results
+
+Terminal reasons are:
+
+- `complete`
+- `capped_by_scheduler`
+- `loaded_awaiting_scheduler`
+- `lanes_exhausted`
+- `blocked`
+- `no_refillable_campaigns`
+- `not_an_evergreen_workspace`
+
+Report campaign names and sender names first, ids second. Include the terminal
+reason or resume handle, lane source, lane chain, chosen label with token
+secondary, plan revision, journal path, blocked continuation packets, and
+firstFailing checklist when present.
+
+Real-run journals live under `~/.sellable/refill/runs` by default and append an
+index line. Dry runs include the dry marker and do not create run records.

package/skill-templates/refill-sends.md

@@ -97,8 +97,11 @@ 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, same-source row copy, and read-only wait
-rereads. It does not run unbounded approval, lower
+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
@@ -198,7 +201,10 @@ Structured planner packet:
 - `target.senderRefillPlans[]` is the canonical sender-level packet; read and
   display it before mutation.
 - Each sender packet includes `campaignRanking.options`, `sourcePlan`,
-  `nextActions`, and `manualAlternates`.
+  `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`.
@@ -217,6 +223,13 @@ 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
@@ -266,6 +279,10 @@ 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