@sellable/install 0.1.356 → 0.1.357-phase111.20260720001632

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.356",
+  "version": "0.1.357-phase111.20260720001632",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code, Codex, and Hermes",
   "bin": {

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

@@ -17,3 +17,8 @@ Use `refill-sends-v2` instead:
 ```text
 get_subskill_prompt({ subskillName: "refill-sends-v2" })
 ```
+
+The alias must not strip exact `targetConfig`, server `runHandle`,
+`reportingContext`, canonical `refill_reporting.v2`, or an explicit
+`messageTemplateRevision`. It never infers revision authority from
+`forceRerun`.

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

@@ -52,9 +52,24 @@ 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 })
+refill_sends_v2({ workspaceId, runHandle:{runId,fence}, targetConfig, reportingContext, messageTemplateRevision? })
 ```
 
+`targetConfig` and the server-issued `runHandle` are separate authorities. Keep
+both byte-for-byte through every continuation and takeover; never fold the
+rotating fence into target configuration.
+
+An approved copy change is reachable only through an explicit
+`messageTemplateRevision` object with `version:1`, `source:"user_approved"`,
+the approved `templateMarkdown`, `messageTemplateRevision` identity,
+`priorTemplateAuthorityDigest`, `nextTemplateAuthorityDigest`, 1–500 exact
+`cohortRowIds`, and `requestId`, `effectId`, and `revisionOperationId`. Pass it
+with the exact `targetConfig` and `reportingContext`; the command obtains or
+resumes the server run handle and lets the planner name
+`revise_message_template_and_rerun`. Missing or partial input means no revision.
+`forceRerun:true` on a queue operation never authorizes or implies a template
+change.
+
 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.
@@ -85,6 +100,8 @@ The run may execute only packet-named bounded work:
   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.
+- apply `revise_message_template_and_rerun` only when the packet contains the
+  complete explicit user-approved revision envelope and exact fenced target.
 
 The loop records planned -> did -> outcome before and after every foreign
 mutation. It refuses stale packets by fingerprint and validates packet
@@ -168,5 +185,10 @@ 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.
 
+Preserve `refill_reporting.v2` exactly in progress, continuation, replay, and
+terminal results. Do not recompute its semantic counts or drop live-preparation
+epoch, snapshot sequence, reset reason, watermark, blockers, compatibility, or
+terminal fields. Never surface raw prospect or message-copy fields.
+
 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

@@ -93,7 +93,7 @@ Accepted invocation flags in the same user request:
 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[], actionTypes?: ("send_invite" | "send_inmail_closed")[], horizonSendDays?: number, untilDate?: "YYYY-MM-DD", targetDate?: "YYYY-MM-DD", runId?: string, fence?: number })
+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
@@ -104,6 +104,14 @@ host must immediately call `refill_sends` again with the original full scope
 plus the exact returned `runId` and `fence`. Do this automatically inside the
 same user command until terminal projected coverage or a concrete blocker; do
 not ask the user to type `continue` and do not start a second run.
+
+`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.
 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
@@ -567,6 +575,11 @@ 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