@sellable/install 0.1.777 → 0.1.779

package/container/Dockerfile

@@ -3,12 +3,12 @@ FROM ${HERMES_IMAGE}
 
 USER root
 
-ARG INSTALLER_PACKAGE=@sellable/install@0.1.777
+ARG INSTALLER_PACKAGE=@sellable/install@0.1.779
 ARG MCP_PACKAGE=@sellable/mcp@0.1.947
 ARG INSTALLER_INTEGRITY
 ARG MCP_INTEGRITY=sha512-3/IoWRHWyTjdh7OjYHdYS+Na6v9TkYhGXKSYX4rYjhqm4b7MtyV2HaRlZVYKUv8afS1UzZcCUXUx7kqF/Mzk4A==
 
-RUN test "${INSTALLER_PACKAGE}" = "@sellable/install@0.1.777" \
+RUN test "${INSTALLER_PACKAGE}" = "@sellable/install@0.1.779" \
     && test "${MCP_PACKAGE}" = "@sellable/mcp@0.1.947" \
     && test -n "${INSTALLER_INTEGRITY}" \
     && test "$(npm view "${INSTALLER_PACKAGE}" dist.integrity)" = "${INSTALLER_INTEGRITY}" \
@@ -23,9 +23,9 @@ RUN test "${INSTALLER_PACKAGE}" = "@sellable/install@0.1.777" \
     && 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.777' || mcp.name !== '@sellable/mcp' || mcp.version !== '0.1.947') 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.779' || mcp.name !== '@sellable/mcp' || mcp.version !== '0.1.947') 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.777', installerIntegrity: process.argv[1], mcpPackage: '@sellable/mcp@0.1.947', 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.779', installerIntegrity: process.argv[1], mcpPackage: '@sellable/mcp@0.1.947', 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

@@ -3,7 +3,7 @@
 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.777` is
+`@sellable/install@0.1.779` is
 published:
 
 ```sh

package/lib/sellable-agent/default-profile-bundles/shared/manifest.fragment.json

@@ -29,7 +29,7 @@
       "ownership": "system_managed",
       "path": "skills/sellable/sellable-campaign-daily-review/SKILL.md",
       "mode": "0444",
-      "content": "---\nname: sellable-campaign-daily-review\ndescription: Review existing Sellable campaigns and move exactly one useful next step forward.\nvisibility: public\nallowed-tools:\n  - mcp_sellable_get_auth_status\n  - mcp_sellable_customer_program\n  - mcp_sellable_get_campaigns\n  - mcp_sellable_get_campaign\n  - mcp_sellable_get_campaign_context\n  - mcp_sellable_get_campaign_refill_state\n  - mcp_sellable_refill_sends\n---\n\n# Sellable Campaign Daily Review\n\n## Installed Host Contract\n\nThis installed skill is running in Hermes Agent. When the shared workflow body\nor fallback text mentions Claude Code, Codex, or Hermes for internal parity,\nchoose the Hermes instruction for customer-facing language and host functions.\n\n- Customer-facing command: `/sellable-campaign-daily-review`\n- MCP tool naming: Hermes exposes Sellable tools as `mcp_sellable_<tool>`;\n  when shared instructions show `mcp_sellable_<tool>`, call the matching\n  `mcp_sellable_<tool>` tool instead.\n- Structured questions: ask plainly in chat unless a Hermes-native approval or\n  question tool is visible in the current session.\n- Bootstrap host label: `host: \"Hermes\"`\n- Install/reload blocker label: Hermes install/reload problem\n- Reload instruction: restart Hermes, or run `/reload-mcp` in the active\n  Hermes session after install\n\nDo not tell Hermes users to run Codex or Claude command forms, use Codex/Claude structured-question APIs, or restart Codex Desktop or Claude Code. Do not describe this run as Claude Code or Codex.\n\nHelp the customer keep the campaign they already have healthy and moving. This\nis one continuous workflow: understand current workspace state, choose one\nuseful next step, use the existing campaign owner, observe the result, and save\nthe exact wait or outcome.\n\n## Run the review\n\n1. Call `get_auth_status`, then obtain a fenced `customer_program` review claim\n   and load the complete home-workspace campaign inventory. For a scheduled\n   `execute` or `resume` wake, use the scheduled trigger and the wake gate's\n   exact lease owner. For a direct customer request, use the interactive\n   trigger. For a `reconcile` wake, skip campaign work and follow the delivery\n   recovery below. Keep each strict tool input separate: claim with only\n   `action`, `trigger`, and `leaseOwner`; never add the wake's `effectId` or\n   `fence` to the claim call.\n2. Infer the relationship stage from that workspace state. Keep campaign health\n   and wait state separate from the relationship stage.\n3. Assess each campaign from approved ICP, source, message and actual outcome\n   evidence. `ACTIVE` or a full queue does not prove suitability. Sparse results\n   do not prove poor quality. Unavailable data is not an empty workspace.\n4. Inspect supply and capacity, then choose exactly one outcome: `maintain`,\n   `refill`, `continue`, `edit`, `propose_create`, `input`, or `blocker`.\n5. Execute through the existing owner:\n   - suitable campaign with a real supply gap: call canonical Refill Sends with `yolo:true` and keep its returned run token. Keep going until the gap is filled or a real blocker remains; when a source runs dry, refill widens it. Do not stop to ask the customer for leads;\n   - unfinished campaign: continue the same campaign through Create Campaign;\n   - supported quality issue: edit the same campaign through Create Campaign;\n   - no campaign: enter Create Campaign, asking only for the LinkedIn profile\n     first when it is missing;\n   - healthy supplied campaign: maintain it and stay quiet;\n   - manual pause: respect it;\n   - missing approval, connection or decision: with `launchConsent.mode: \"autopilot\"` approve messages that passed the quality check and start or resume the campaign yourself; otherwise retain one exact next step. Ask only for what you cannot do yourself, such as a LinkedIn connection, as one question.\n   Whatever the outcome, also run canonical Refill Sends with `yolo:true` for the\n   workspace's next two sender-local days before you finish. It checks capacity\n   itself and does nothing when queues are full. Keep going until the gap is\n   filled or a real blocker remains; refill results reach the customer in the\n   next results update, not as a separate post.\n6. Observe the owned operation, then record the outcome against the same review\n   effect and fence. The `record_review_outcome` call contains only its action,\n   effect, fence, review outcome, summary, and optional decision/operation refs;\n   do not include trigger or lease fields. Never mark a pending or uncertain\n   effect complete. On a scheduled actionable outcome, saving the outcome is\n   not completion. Inspect `deliveryRequired`; when it is `true`, continue\n   immediately to the required `stage_delivery` call. Never return while the recorded run still has `deliveryState: \"pending\"`. Write the outcome `summary` in plain customer words with the verified numbers (leads added, messages approved, sends scheduled): the next results update reads it as \"What Sellable did\".\n\n## Write the Slack message\n\nPost only new work or a real need, never a status. Use real line breaks: a bold title, a blank line between sections, one item per line, never one long paragraph. Write ordinary Markdown; delivery converts it for Slack.\n\n**{Workspace} · Campaign update · {Weekday Mon D}**\n\n**What I did** says in plain words what changed: leads added, messages approved,\nsends scheduled, campaign started, or a source widened.\n\n**Next step** and **Options** appear only when the customer must act: one specific\naction, then at most two options they can reply with. Offer only what you can really\ndo (refill, continue or edit the campaign) or what they can do (add leads, approve\nmessages, reconnect a sender).\n\nLead with what Sellable did to grow their sends. Never tell the customer what they\nhave not done, and never post a scoreboard of zeros. Plain words: no run tokens,\njob or effect IDs, error codes, tool names or file paths. Unknown is never zero.\nAbout 20-60 words.\n\n## Stop and delivery rules\n\nAn internal system fault (a run token, an error code, refill machinery) is not\na customer decision or blocker: do not post it.\n\nIf a tool call fails or its result can't be read, return `[SILENT]` and stop.\nNever post an error, an apology or a guess; the open claim lets the next\nscheduled window retry.\n\nStop on settled state, a human wait, a retained async wait, a typed blocker or\nthe existing bounded operation budget. Never restart a pending effect. Follow a\nnew customer reply or product completion immediately instead of waiting for the\nnext daily tick.\n\nPost a useful new decision or blocker once to the verified current main channel.\nRoutine refill belongs in the next results brief. A healthy no-op is inspectable\nand silent. On a scheduled actionable outcome, compose the complete final Slack\ntext, call `customer_program` with only `action: \"stage_delivery\"`, the exact\neffect and fence, and `text`, then inspect `delivery.deliverNow`. Only when it is `true`, return\n`delivery.text` verbatim as the native job's final response. When it is\n`false`, return `[SILENT]`; that effect is already uncertain or delivered,\nand the managed reconciliation tick owns the next step. Do not stage an interactive response.\n\nBefore any scheduled final response, check the recorded run one last time. A\n`pending` delivery is an unfinished cron turn: call `stage_delivery` now. Only\n`accepted_uncertain`, `delivered`, `failed`, or `not_applicable` may end the\nturn.\n\nOn a scheduled `reconcile` wake, call `reconcile_delivery` with only its action\nand the exact effect.\nIf trusted Slack history confirms the text, or retry is not yet allowed, return\n`[SILENT]`. If retry is allowed, call `retry_delivery` with the current fence and\nreturn its stored `delivery.text` verbatim. Never regenerate it. The native\nmanaged job remains the only Slack sender; the product owns the claim and\ndelivery ledger. After three unconfirmed attempts the product closes the run as\nfailed and later ticks stay silent. Never create another post path or fall back\nto another channel.\n\nDo not create a second campaign engine, refill algorithm, scheduler, scoring\nframework, intake questionnaire or generic morning approval. Do not rewrite\nstrategy or messages merely because another day passed. Initial campaign launch\nstill requires the existing human Start.\n"
+      "content": "---\nname: sellable-campaign-daily-review\ndescription: Review existing Sellable campaigns and move exactly one useful next step forward.\nvisibility: public\nallowed-tools:\n  - mcp_sellable_get_auth_status\n  - mcp_sellable_customer_program\n  - mcp_sellable_get_campaigns\n  - mcp_sellable_get_campaign\n  - mcp_sellable_get_campaign_context\n  - mcp_sellable_get_campaign_refill_state\n  - mcp_sellable_refill_sends\n---\n\n# Sellable Campaign Daily Review\n\n## Installed Host Contract\n\nThis installed skill is running in Hermes Agent. When the shared workflow body\nor fallback text mentions Claude Code, Codex, or Hermes for internal parity,\nchoose the Hermes instruction for customer-facing language and host functions.\n\n- Customer-facing command: `/sellable-campaign-daily-review`\n- MCP tool naming: Hermes exposes Sellable tools as `mcp_sellable_<tool>`;\n  when shared instructions show `mcp_sellable_<tool>`, call the matching\n  `mcp_sellable_<tool>` tool instead.\n- Structured questions: ask plainly in chat unless a Hermes-native approval or\n  question tool is visible in the current session.\n- Bootstrap host label: `host: \"Hermes\"`\n- Install/reload blocker label: Hermes install/reload problem\n- Reload instruction: restart Hermes, or run `/reload-mcp` in the active\n  Hermes session after install\n\nDo not tell Hermes users to run Codex or Claude command forms, use Codex/Claude structured-question APIs, or restart Codex Desktop or Claude Code. Do not describe this run as Claude Code or Codex.\n\nHelp the customer keep the campaign they already have healthy and moving. This\nis one continuous workflow: understand current workspace state, choose one\nuseful next step, use the existing campaign owner, observe the result, and save\nthe exact wait or outcome.\n\n## Run the review\n\n1. Call `get_auth_status`, then obtain a fenced `customer_program` review claim\n   and load the complete home-workspace campaign inventory. For a scheduled\n   `execute` or `resume` wake, use the scheduled trigger and the wake gate's\n   exact lease owner. For a direct customer request, use the interactive\n   trigger. For a `reconcile` wake, skip campaign work and follow the delivery\n   recovery below. Keep each strict tool input separate: claim with only\n   `action`, `trigger`, and `leaseOwner`; never add the wake's `effectId` or\n   `fence` to the claim call.\n2. Infer the relationship stage from that workspace state. Keep campaign health\n   and wait state separate from the relationship stage.\n3. Assess each campaign from approved ICP, source, message and actual outcome\n   evidence. `ACTIVE` or a full queue does not prove suitability. Sparse results\n   do not prove poor quality. Unavailable data is not an empty workspace.\n4. Inspect supply and capacity, then choose exactly one outcome: `maintain`,\n   `refill`, `continue`, `edit`, `propose_create`, `input`, or `blocker`.\n5. Execute through the existing owner:\n   - suitable campaign with a real supply gap: call canonical Refill Sends with `yolo:true` and keep its returned run token. Keep going until the gap is filled or a real blocker remains; when a source runs dry, refill widens it. Do not stop to ask the customer for leads;\n   - unfinished campaign: continue the same campaign through Create Campaign;\n   - supported quality issue: edit the same campaign through Create Campaign;\n   - no campaign: enter Create Campaign, asking only for the LinkedIn profile\n     first when it is missing;\n   - healthy supplied campaign: maintain it and stay quiet;\n   - manual pause: respect it;\n   - missing approval, connection or decision: with `launchConsent.mode: \"autopilot\"` approve messages that passed the quality check and start or resume the campaign yourself. When `launchConsent` has no answer yet, ask the one-time question instead of asking for approval: \"I can approve messages that pass my quality check and launch for you, then keep your sends filled. Reply review first if you would rather approve.\" Save the answer with `save_context` as Create Campaign's Standing Consent does. With `review_first`, retain one exact next step. Ask only for what you cannot do yourself, such as a LinkedIn connection, as one question.\n   A built-in weekday refill job fills sends before this review; do not run\n   Refill Sends again unless `refill` is this review's one outcome. Read\n   `refill_v3_world_state` for the next two sender-local days: a row whose\n   reason names a disconnected sender (`sender_disconnected`), a disconnected\n   Sales Navigator (`sales_nav_disconnected`) or\n   `paid_inmail_connection_health_recheck_required` is a fix only the customer\n   can make. Make it this review's `input`: name the sender and say reconnect\n   LinkedIn or reconnect Sales Navigator in Settings.\n6. Observe the owned operation, then record the outcome against the same review\n   effect and fence. The `record_review_outcome` call contains only its action,\n   effect, fence, review outcome, summary, and optional decision/operation refs;\n   do not include trigger or lease fields. Never mark a pending or uncertain\n   effect complete. On a scheduled actionable outcome, saving the outcome is\n   not completion. Inspect `deliveryRequired`; when it is `true`, continue\n   immediately to the required `stage_delivery` call. Never return while the recorded run still has `deliveryState: \"pending\"`. Write the outcome `summary` in plain customer words with the verified numbers (leads added, messages approved, sends scheduled): the next results update reads it as \"What Sellable did\".\n\n## Write the Slack message\n\nPost only new work or a real need, never a status. Use real line breaks: a bold title, a blank line between sections, one item per line, never one long paragraph. Write ordinary Markdown; delivery converts it for Slack.\n\n**{Workspace} · Campaign update · {Weekday Mon D}**\n\n**What I did** says in plain words what changed: leads added, messages approved,\nsends scheduled, campaign started, or a source widened.\n\n**Next step** and **Options** appear only when the customer must act: one specific\naction, then at most two options they can reply with. Offer only what you can really\ndo (refill, continue or edit the campaign) or what they can do (add leads, approve\nmessages, reconnect a sender).\n\nLead with what Sellable did to grow their sends. Never tell the customer what they\nhave not done, and never post a scoreboard of zeros. Plain words: no run tokens,\njob or effect IDs, error codes, tool names or file paths. Unknown is never zero.\nAbout 20-60 words.\n\n## Stop and delivery rules\n\nAn internal system fault (a run token, an error code, refill machinery) is not\na customer decision or blocker: do not post it.\n\nIf a tool call fails or its result can't be read, return `[SILENT]` and stop.\nNever post an error, an apology or a guess; the open claim lets the next\nscheduled window retry.\n\nStop on settled state, a human wait, a retained async wait, a typed blocker or\nthe existing bounded operation budget. Never restart a pending effect. Follow a\nnew customer reply or product completion immediately instead of waiting for the\nnext daily tick.\n\nPost a useful new decision or blocker once to the verified current main channel.\nRoutine refill belongs in the next results brief. A healthy no-op is inspectable\nand silent. On a scheduled actionable outcome, compose the complete final Slack\ntext, call `customer_program` with only `action: \"stage_delivery\"`, the exact\neffect and fence, and `text`, then inspect `delivery.deliverNow`. Only when it is `true`, return\n`delivery.text` verbatim as the native job's final response. When it is\n`false`, return `[SILENT]`; that effect is already uncertain or delivered,\nand the managed reconciliation tick owns the next step. Do not stage an interactive response.\n\nBefore any scheduled final response, check the recorded run one last time. A\n`pending` delivery is an unfinished cron turn: call `stage_delivery` now. Only\n`accepted_uncertain`, `delivered`, `failed`, or `not_applicable` may end the\nturn.\n\nOn a scheduled `reconcile` wake, call `reconcile_delivery` with only its action\nand the exact effect.\nIf trusted Slack history confirms the text, or retry is not yet allowed, return\n`[SILENT]`. If retry is allowed, call `retry_delivery` with the current fence and\nreturn its stored `delivery.text` verbatim. Never regenerate it. The native\nmanaged job remains the only Slack sender; the product owns the claim and\ndelivery ledger. After three unconfirmed attempts the product closes the run as\nfailed and later ticks stay silent. Never create another post path or fall back\nto another channel.\n\nDo not create a second campaign engine, refill algorithm, scheduler, scoring\nframework, intake questionnaire or generic morning approval. Do not rewrite\nstrategy or messages merely because another day passed. Initial campaign launch\nstill requires the existing human Start.\n"
     },
     {
       "id": "campaign-daily-results",

package/lib/sellable-agent/default-profile-bundles/shared/skills/sellable/sellable-campaign-daily-review/SKILL.md

@@ -63,12 +63,15 @@ the exact wait or outcome.
      first when it is missing;
    - healthy supplied campaign: maintain it and stay quiet;
    - manual pause: respect it;
-   - missing approval, connection or decision: with `launchConsent.mode: "autopilot"` approve messages that passed the quality check and start or resume the campaign yourself; otherwise retain one exact next step. Ask only for what you cannot do yourself, such as a LinkedIn connection, as one question.
-   Whatever the outcome, also run canonical Refill Sends with `yolo:true` for the
-   workspace's next two sender-local days before you finish. It checks capacity
-   itself and does nothing when queues are full. Keep going until the gap is
-   filled or a real blocker remains; refill results reach the customer in the
-   next results update, not as a separate post.
+   - missing approval, connection or decision: with `launchConsent.mode: "autopilot"` approve messages that passed the quality check and start or resume the campaign yourself. When `launchConsent` has no answer yet, ask the one-time question instead of asking for approval: "I can approve messages that pass my quality check and launch for you, then keep your sends filled. Reply review first if you would rather approve." Save the answer with `save_context` as Create Campaign's Standing Consent does. With `review_first`, retain one exact next step. Ask only for what you cannot do yourself, such as a LinkedIn connection, as one question.
+   A built-in weekday refill job fills sends before this review; do not run
+   Refill Sends again unless `refill` is this review's one outcome. Read
+   `refill_v3_world_state` for the next two sender-local days: a row whose
+   reason names a disconnected sender (`sender_disconnected`), a disconnected
+   Sales Navigator (`sales_nav_disconnected`) or
+   `paid_inmail_connection_health_recheck_required` is a fix only the customer
+   can make. Make it this review's `input`: name the sender and say reconnect
+   LinkedIn or reconnect Sales Navigator in Settings.
 6. Observe the owned operation, then record the outcome against the same review
    effect and fence. The `record_review_outcome` call contains only its action,
    effect, fence, review outcome, summary, and optional decision/operation refs;

package/lib/sellable-agent/fly-admin-image/Dockerfile

@@ -44,7 +44,7 @@ ARG STRIPE_CLI_PACKAGE=@stripe/cli-linux-x64@1.45.0
 ARG STRIPE_CLI_INTEGRITY=sha512-1ZhoPpoweYfynqsvhCLlTjZ7lPz5IKtxqAMT5MBy6zrwLRTP9x0T6r8h/jLYL8lRH1c7zC/6X6/XUu2V+r9Bog==
 ARG DEFAULT_PROFILE_BUNDLE_FIXTURE_VERSION=1
 ARG DEFAULT_PROFILE_BUNDLE_VERSION=4
-ARG DEFAULT_PROFILE_BUNDLE_DIGEST=3b9335df46d0a00284c71bfab620edf0abd7882d2ad2216343cf5b6098345baa
+ARG DEFAULT_PROFILE_BUNDLE_DIGEST=e24677e470c289ac5b27d279693deca5fba10b8ff1d02b218bf523cc39bc1a13
 
 COPY --from=slack-pp-cli-builder --chmod=0555 /out/slack-pp-cli /usr/local/bin/slack-pp-cli
 

package/lib/sellable-agent/fly-admin-image/admin-runtime.mjs

@@ -88,7 +88,7 @@ import {
   HERMES_SNAPSHOT_HOOK_ALLOWLIST_BYTES,
   applyHermesSellableHostedPolicy,
   ensureHermesClientRelationshipsCrons,
-  ensureHermesAdminRefillSendsCron,
+  ensureHermesRefillSendsCron,
   ensureHermesCustomerProgramCrons,
   ensureHermesOpportunitySequencesCron,
   ensureHermesSnapshotCron,
@@ -1442,7 +1442,7 @@ async function materializeAdminProfile({
     // NON-FATAL like its siblings: a missed refill tick is harmless (refill
     // no-ops when queues are full) and must not block an Admin promotion.
     const adminRefillCron = slack
-      ? await ensureHermesAdminRefillSendsCron({
+      ? await ensureHermesRefillSendsCron({
           profileId: profile,
           profileRoot: profileHome,
           hermesRoot: DATA_ROOT,

package/lib/sellable-agent/fly-customer-image/Dockerfile

@@ -8,7 +8,7 @@ ENV PLAYWRIGHT_BROWSERS_PATH=/opt/hermes/.playwright
 
 ARG MCP_PACKAGE=@sellable/mcp@0.1.947
 ARG MCP_INTEGRITY=sha512-3/IoWRHWyTjdh7OjYHdYS+Na6v9TkYhGXKSYX4rYjhqm4b7MtyV2HaRlZVYKUv8afS1UzZcCUXUx7kqF/Mzk4A==
-ARG INSTALLER_PACKAGE=@sellable/install@0.1.777
+ARG INSTALLER_PACKAGE=@sellable/install@0.1.779
 ARG ADMIN_MCP_PACKAGE=@sellable/admin-mcp@0.1.202
 ARG ADMIN_MCP_INTEGRITY=sha512-ym3aye/0vQ8tfULJlKz9JFOxvIQsl1G+n3np+TTgK/tecwNblBo/j3AkTnRqH9iomKzPbZzP+n4tEQsvsU8ByA==
 ARG TUS_JS_CLIENT_VERSION=4.3.1
@@ -22,7 +22,7 @@ ARG PLAYWRIGHT_BROWSER_REVISION=1243
 ARG TIRITH_ARCHIVE_SHA256=6cdbe35e8f9ccf42e70ad95b501c93cd218ac18201c3df958d54f6ba0d995ce2
 ARG DEFAULT_PROFILE_BUNDLE_FIXTURE_VERSION=1
 ARG DEFAULT_PROFILE_BUNDLE_VERSION=4
-ARG DEFAULT_PROFILE_BUNDLE_DIGEST=3063a681b695461d6b8897c8fea57afa59141c9f5e302116436762935d39db69
+ARG DEFAULT_PROFILE_BUNDLE_DIGEST=bd97b34dc228ee1d91deaafc52283f555e34165786abba26bad398202c6e087c
 
 RUN --mount=type=secret,id=mcp_trust_root,required=true \
     test -s /run/secrets/mcp_trust_root \

package/lib/sellable-agent/fly-customer-image/customer-runtime.mjs

@@ -54,6 +54,7 @@ import { ensureHermesFirstWelcome } from "../hermes-first-welcome.mjs";
 import {
   ensureHermesCustomerProgramCrons,
   ensureHermesFirstCampaignOnboardingCron,
+  ensureHermesRefillSendsCron,
   ensureHermesSnapshotCron,
   markHermesSnapshotDirty,
   migrateLegacyHermesUserState,
@@ -122,7 +123,7 @@ const RUNTIME_GENERATION = Number(
 const BOOT_SESSION_ID = randomUUID();
 const HERMES_VERSION = process.env.SELLABLE_AGENT_HERMES_VERSION ?? "0.21.5";
 const INSTALLER_PACKAGE =
-  process.env.SELLABLE_AGENT_INSTALLER_PACKAGE ?? "@sellable/install@0.1.777";
+  process.env.SELLABLE_AGENT_INSTALLER_PACKAGE ?? "@sellable/install@0.1.779";
 const MCP_PACKAGE =
   process.env.SELLABLE_AGENT_MCP_PACKAGE ?? "@sellable/mcp@0.1.947";
 export const ENDPOINT_MAX_CONCURRENT_RUNS = 10;
@@ -3883,6 +3884,14 @@ async function processOperation({
       channelId: desired.defaultChannelId,
     });
     if (!onboardingCron.ok) throw new Error(onboardingCron.code);
+    // NON-FATAL: a missed refill tick is harmless (refill no-ops when queues
+    // are full and the next weekday run continues), so it never blocks serving.
+    await ensureHermesRefillSendsCron({
+      profileId: desired.profileId,
+      profileRoot,
+      hermesRoot: DATA_ROOT,
+      workspaceId: desired.workspaceId,
+    });
   });
   markHermesSnapshotDirty(profileRoot);
   const onboardingMemorySnapshot = await phaseTelemetry.run(

package/lib/sellable-agent/hermes-memory-snapshot.mjs

@@ -134,13 +134,13 @@ export const HERMES_CUSTOMER_PROGRAM_CRONS = Object.freeze([
     ]),
   }),
 ]);
-// Built-in daily refill: Admin image first, customer image after it has proven
-// itself. It posts nothing (deliver local, reply [SILENT]); the next results update
-// reports what was added. Refill observes capacity itself and does nothing when
-// queues are full, so a single weekday tick is enough and a missed one is harmless.
-export const HERMES_ADMIN_REFILL_CRON = Object.freeze({
+// Built-in weekday refill on every agent (proven on the Admin image first). It
+// posts nothing (deliver local, reply [SILENT]); the daily review names anything
+// only the customer can fix and the results update reports what was added.
+// Refill observes capacity itself and does nothing when queues are full, so a
+// single weekday tick is enough and a missed one is harmless.
+export const HERMES_REFILL_SENDS_CRON = Object.freeze({
   name: "sellable-default-refill-sends",
-  schedule: "0 14 * * 1-5",
   deliver: "local",
   skills: Object.freeze(["sellable-refill-sends"]),
   enabledToolsets: Object.freeze(["safe", "sellable", "mcp"]),
@@ -1952,17 +1952,23 @@ function opportunitySequenceIdentity(profileRoot) {
   );
 }
 
-function adminRefillPrompt(workspaceId) {
+// Weekdays between 14:00 and 14:49 UTC, one stable minute per agent: every agent
+// starting refill at 14:00:00 crowded the product's database pool (Sep 30).
+export function refillSendsSchedule(profileId) {
+  const minute = parseInt(sha256(profileId).slice(0, 8), 16) % 50;
+  return `${minute} 14 * * 1-5`;
+}
+
+function refillSendsPrompt(workspaceId) {
   return [
     "Run the installed refill-sends skill with --yolo for this workspace.",
     "Call refill_v3_advance with yolo true and scope {kind: sender_local_horizon, days: 2}, then continue exactly as the skill says until the run is complete, awaiting an external change, or blocked.",
-    "Budget: make at most five refill_v3_advance calls, then stop even if the run is not complete; the next weekday run continues.",
-    "Post nothing: reply [SILENT] whatever the outcome. The next daily results update reports what was added.",
+    "Post nothing: reply [SILENT] whatever the outcome. The daily review names anything only the customer can fix, and the next results update reports what was added.",
     `workspaceId: ${workspaceId}`,
   ].join("\n");
 }
 
-export async function ensureHermesAdminRefillSendsCron({
+export async function ensureHermesRefillSendsCron({
   profileId,
   profileRoot,
   hermesRoot,
@@ -1975,11 +1981,12 @@ export async function ensureHermesAdminRefillSendsCron({
     !existsSync(profileRoot) ||
     !ONBOARDING_WORKSPACE_ID.test(workspaceId ?? "")
   ) {
-    return failed("hermes_admin_refill_sends_cron_identity_rejected");
+    return failed("hermes_refill_sends_cron_identity_rejected");
   }
   try {
-    const cron = HERMES_ADMIN_REFILL_CRON;
-    const prompt = adminRefillPrompt(workspaceId);
+    const cron = HERMES_REFILL_SENDS_CRON;
+    const prompt = refillSendsPrompt(workspaceId);
+    const schedule = refillSendsSchedule(profileId);
     const expected = (job) =>
       Boolean(
         job?.id &&
@@ -1991,7 +1998,7 @@ export async function ensureHermesAdminRefillSendsCron({
           sameJson(job.skills, cron.skills) &&
           sameJson(job.enabled_toolsets, cron.enabledToolsets) &&
           job.schedule?.kind === "cron" &&
-          job.schedule?.expr === cron.schedule
+          job.schedule?.expr === schedule
       );
     const mutate = (jobId = null) =>
       childRunner(runChild)({
@@ -2001,7 +2008,7 @@ export async function ensureHermesAdminRefillSendsCron({
           OPPORTUNITY_SEQUENCE_CRON_PYTHON,
           JSON.stringify({
             prompt,
-            schedule: cron.schedule,
+            schedule,
             name: cron.name,
             deliver: cron.deliver,
             skills: [...cron.skills],
@@ -2028,7 +2035,7 @@ export async function ensureHermesAdminRefillSendsCron({
       isExpected: expected,
       create: () => mutate(),
       update: (job) => mutate(job.id),
-      codePrefix: "hermes_admin_refill_sends_cron",
+      codePrefix: "hermes_refill_sends_cron",
     });
     if (!result.ok) return result;
     return {
@@ -2043,7 +2050,7 @@ export async function ensureHermesAdminRefillSendsCron({
       workspaceId,
     };
   } catch {
-    return failed("hermes_admin_refill_sends_cron_install_failed");
+    return failed("hermes_refill_sends_cron_install_failed");
   }
 }
 

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

@@ -38,7 +38,7 @@ 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.777";
+const INSTALLER_PACKAGE = "@sellable/install@0.1.779";
 const MCP_PACKAGE = "@sellable/mcp@0.1.947";
 const HERMES_VERSION = "0.18.0";
 const SHA256 = /^[a-f0-9]{64}$/;

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

@@ -1546,7 +1546,7 @@ export function compileClaimToProfileDesired(activeClaim, config) {
       ]) ||
       pinned.hermesCli !== "hermes" ||
       pinned.hermesVersion !== "0.18.0" ||
-      pinned.installerPackage !== "@sellable/install@0.1.777" ||
+      pinned.installerPackage !== "@sellable/install@0.1.779" ||
       pinned.mcpPackage !== "@sellable/mcp@0.1.947" ||
       !Array.isArray(policy.toolInclude) ||
       policy.toolInclude.length === 0 ||

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

@@ -312,7 +312,7 @@ function validateDesired(desired) {
     desired.serviceCredentialGeneration < 1 ||
     desired.hermesCli !== "hermes" ||
     desired.hermesVersion !== "0.18.0" ||
-    desired.installerPackage !== "@sellable/install@0.1.777" ||
+    desired.installerPackage !== "@sellable/install@0.1.779" ||
     desired.mcpPackage !== "@sellable/mcp@0.1.947" ||
     !Array.isArray(desired.toolInclude) ||
     desired.toolInclude.length === 0 ||

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

@@ -25,7 +25,7 @@ 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.777";
+export const PINNED_INSTALL_PACKAGE = "@sellable/install@0.1.779";
 export const PINNED_MCP_PACKAGE = "@sellable/mcp@0.1.947";
 const PINNED_INSTALL_VERSION = PINNED_INSTALL_PACKAGE.slice(
   PINNED_INSTALL_PACKAGE.lastIndexOf("@") + 1

package/lib/sellable-agent/public-skills.json

@@ -45,7 +45,7 @@
   },
   {
     "path": "skills/sellable/sellable-campaign-daily-review/SKILL.md",
-    "content": "---\nname: sellable-campaign-daily-review\ndescription: Review existing Sellable campaigns and move exactly one useful next step forward.\nvisibility: public\nallowed-tools:\n  - mcp_sellable_get_auth_status\n  - mcp_sellable_customer_program\n  - mcp_sellable_get_campaigns\n  - mcp_sellable_get_campaign\n  - mcp_sellable_get_campaign_context\n  - mcp_sellable_get_campaign_refill_state\n  - mcp_sellable_refill_sends\n---\n\n# Sellable Campaign Daily Review\n\n## Installed Host Contract\n\nThis installed skill is running in Hermes Agent. When the shared workflow body\nor fallback text mentions Claude Code, Codex, or Hermes for internal parity,\nchoose the Hermes instruction for customer-facing language and host functions.\n\n- Customer-facing command: `/sellable-campaign-daily-review`\n- MCP tool naming: Hermes exposes Sellable tools as `mcp_sellable_<tool>`;\n  when shared instructions show `mcp_sellable_<tool>`, call the matching\n  `mcp_sellable_<tool>` tool instead.\n- Structured questions: ask plainly in chat unless a Hermes-native approval or\n  question tool is visible in the current session.\n- Bootstrap host label: `host: \"Hermes\"`\n- Install/reload blocker label: Hermes install/reload problem\n- Reload instruction: restart Hermes, or run `/reload-mcp` in the active\n  Hermes session after install\n\nDo not tell Hermes users to run Codex or Claude command forms, use Codex/Claude structured-question APIs, or restart Codex Desktop or Claude Code. Do not describe this run as Claude Code or Codex.\n\nHelp the customer keep the campaign they already have healthy and moving. This\nis one continuous workflow: understand current workspace state, choose one\nuseful next step, use the existing campaign owner, observe the result, and save\nthe exact wait or outcome.\n\n## Run the review\n\n1. Call `get_auth_status`, then obtain a fenced `customer_program` review claim\n   and load the complete home-workspace campaign inventory. For a scheduled\n   `execute` or `resume` wake, use the scheduled trigger and the wake gate's\n   exact lease owner. For a direct customer request, use the interactive\n   trigger. For a `reconcile` wake, skip campaign work and follow the delivery\n   recovery below. Keep each strict tool input separate: claim with only\n   `action`, `trigger`, and `leaseOwner`; never add the wake's `effectId` or\n   `fence` to the claim call.\n2. Infer the relationship stage from that workspace state. Keep campaign health\n   and wait state separate from the relationship stage.\n3. Assess each campaign from approved ICP, source, message and actual outcome\n   evidence. `ACTIVE` or a full queue does not prove suitability. Sparse results\n   do not prove poor quality. Unavailable data is not an empty workspace.\n4. Inspect supply and capacity, then choose exactly one outcome: `maintain`,\n   `refill`, `continue`, `edit`, `propose_create`, `input`, or `blocker`.\n5. Execute through the existing owner:\n   - suitable campaign with a real supply gap: call canonical Refill Sends with `yolo:true` and keep its returned run token. Keep going until the gap is filled or a real blocker remains; when a source runs dry, refill widens it. Do not stop to ask the customer for leads;\n   - unfinished campaign: continue the same campaign through Create Campaign;\n   - supported quality issue: edit the same campaign through Create Campaign;\n   - no campaign: enter Create Campaign, asking only for the LinkedIn profile\n     first when it is missing;\n   - healthy supplied campaign: maintain it and stay quiet;\n   - manual pause: respect it;\n   - missing approval, connection or decision: with `launchConsent.mode: \"autopilot\"` approve messages that passed the quality check and start or resume the campaign yourself; otherwise retain one exact next step. Ask only for what you cannot do yourself, such as a LinkedIn connection, as one question.\n   Whatever the outcome, also run canonical Refill Sends with `yolo:true` for the\n   workspace's next two sender-local days before you finish. It checks capacity\n   itself and does nothing when queues are full. Keep going until the gap is\n   filled or a real blocker remains; refill results reach the customer in the\n   next results update, not as a separate post.\n6. Observe the owned operation, then record the outcome against the same review\n   effect and fence. The `record_review_outcome` call contains only its action,\n   effect, fence, review outcome, summary, and optional decision/operation refs;\n   do not include trigger or lease fields. Never mark a pending or uncertain\n   effect complete. On a scheduled actionable outcome, saving the outcome is\n   not completion. Inspect `deliveryRequired`; when it is `true`, continue\n   immediately to the required `stage_delivery` call. Never return while the recorded run still has `deliveryState: \"pending\"`. Write the outcome `summary` in plain customer words with the verified numbers (leads added, messages approved, sends scheduled): the next results update reads it as \"What Sellable did\".\n\n## Write the Slack message\n\nPost only new work or a real need, never a status. Use real line breaks: a bold title, a blank line between sections, one item per line, never one long paragraph. Write ordinary Markdown; delivery converts it for Slack.\n\n**{Workspace} · Campaign update · {Weekday Mon D}**\n\n**What I did** says in plain words what changed: leads added, messages approved,\nsends scheduled, campaign started, or a source widened.\n\n**Next step** and **Options** appear only when the customer must act: one specific\naction, then at most two options they can reply with. Offer only what you can really\ndo (refill, continue or edit the campaign) or what they can do (add leads, approve\nmessages, reconnect a sender).\n\nLead with what Sellable did to grow their sends. Never tell the customer what they\nhave not done, and never post a scoreboard of zeros. Plain words: no run tokens,\njob or effect IDs, error codes, tool names or file paths. Unknown is never zero.\nAbout 20-60 words.\n\n## Stop and delivery rules\n\nAn internal system fault (a run token, an error code, refill machinery) is not\na customer decision or blocker: do not post it.\n\nIf a tool call fails or its result can't be read, return `[SILENT]` and stop.\nNever post an error, an apology or a guess; the open claim lets the next\nscheduled window retry.\n\nStop on settled state, a human wait, a retained async wait, a typed blocker or\nthe existing bounded operation budget. Never restart a pending effect. Follow a\nnew customer reply or product completion immediately instead of waiting for the\nnext daily tick.\n\nPost a useful new decision or blocker once to the verified current main channel.\nRoutine refill belongs in the next results brief. A healthy no-op is inspectable\nand silent. On a scheduled actionable outcome, compose the complete final Slack\ntext, call `customer_program` with only `action: \"stage_delivery\"`, the exact\neffect and fence, and `text`, then inspect `delivery.deliverNow`. Only when it is `true`, return\n`delivery.text` verbatim as the native job's final response. When it is\n`false`, return `[SILENT]`; that effect is already uncertain or delivered,\nand the managed reconciliation tick owns the next step. Do not stage an interactive response.\n\nBefore any scheduled final response, check the recorded run one last time. A\n`pending` delivery is an unfinished cron turn: call `stage_delivery` now. Only\n`accepted_uncertain`, `delivered`, `failed`, or `not_applicable` may end the\nturn.\n\nOn a scheduled `reconcile` wake, call `reconcile_delivery` with only its action\nand the exact effect.\nIf trusted Slack history confirms the text, or retry is not yet allowed, return\n`[SILENT]`. If retry is allowed, call `retry_delivery` with the current fence and\nreturn its stored `delivery.text` verbatim. Never regenerate it. The native\nmanaged job remains the only Slack sender; the product owns the claim and\ndelivery ledger. After three unconfirmed attempts the product closes the run as\nfailed and later ticks stay silent. Never create another post path or fall back\nto another channel.\n\nDo not create a second campaign engine, refill algorithm, scheduler, scoring\nframework, intake questionnaire or generic morning approval. Do not rewrite\nstrategy or messages merely because another day passed. Initial campaign launch\nstill requires the existing human Start.\n"
+    "content": "---\nname: sellable-campaign-daily-review\ndescription: Review existing Sellable campaigns and move exactly one useful next step forward.\nvisibility: public\nallowed-tools:\n  - mcp_sellable_get_auth_status\n  - mcp_sellable_customer_program\n  - mcp_sellable_get_campaigns\n  - mcp_sellable_get_campaign\n  - mcp_sellable_get_campaign_context\n  - mcp_sellable_get_campaign_refill_state\n  - mcp_sellable_refill_sends\n---\n\n# Sellable Campaign Daily Review\n\n## Installed Host Contract\n\nThis installed skill is running in Hermes Agent. When the shared workflow body\nor fallback text mentions Claude Code, Codex, or Hermes for internal parity,\nchoose the Hermes instruction for customer-facing language and host functions.\n\n- Customer-facing command: `/sellable-campaign-daily-review`\n- MCP tool naming: Hermes exposes Sellable tools as `mcp_sellable_<tool>`;\n  when shared instructions show `mcp_sellable_<tool>`, call the matching\n  `mcp_sellable_<tool>` tool instead.\n- Structured questions: ask plainly in chat unless a Hermes-native approval or\n  question tool is visible in the current session.\n- Bootstrap host label: `host: \"Hermes\"`\n- Install/reload blocker label: Hermes install/reload problem\n- Reload instruction: restart Hermes, or run `/reload-mcp` in the active\n  Hermes session after install\n\nDo not tell Hermes users to run Codex or Claude command forms, use Codex/Claude structured-question APIs, or restart Codex Desktop or Claude Code. Do not describe this run as Claude Code or Codex.\n\nHelp the customer keep the campaign they already have healthy and moving. This\nis one continuous workflow: understand current workspace state, choose one\nuseful next step, use the existing campaign owner, observe the result, and save\nthe exact wait or outcome.\n\n## Run the review\n\n1. Call `get_auth_status`, then obtain a fenced `customer_program` review claim\n   and load the complete home-workspace campaign inventory. For a scheduled\n   `execute` or `resume` wake, use the scheduled trigger and the wake gate's\n   exact lease owner. For a direct customer request, use the interactive\n   trigger. For a `reconcile` wake, skip campaign work and follow the delivery\n   recovery below. Keep each strict tool input separate: claim with only\n   `action`, `trigger`, and `leaseOwner`; never add the wake's `effectId` or\n   `fence` to the claim call.\n2. Infer the relationship stage from that workspace state. Keep campaign health\n   and wait state separate from the relationship stage.\n3. Assess each campaign from approved ICP, source, message and actual outcome\n   evidence. `ACTIVE` or a full queue does not prove suitability. Sparse results\n   do not prove poor quality. Unavailable data is not an empty workspace.\n4. Inspect supply and capacity, then choose exactly one outcome: `maintain`,\n   `refill`, `continue`, `edit`, `propose_create`, `input`, or `blocker`.\n5. Execute through the existing owner:\n   - suitable campaign with a real supply gap: call canonical Refill Sends with `yolo:true` and keep its returned run token. Keep going until the gap is filled or a real blocker remains; when a source runs dry, refill widens it. Do not stop to ask the customer for leads;\n   - unfinished campaign: continue the same campaign through Create Campaign;\n   - supported quality issue: edit the same campaign through Create Campaign;\n   - no campaign: enter Create Campaign, asking only for the LinkedIn profile\n     first when it is missing;\n   - healthy supplied campaign: maintain it and stay quiet;\n   - manual pause: respect it;\n   - missing approval, connection or decision: with `launchConsent.mode: \"autopilot\"` approve messages that passed the quality check and start or resume the campaign yourself. When `launchConsent` has no answer yet, ask the one-time question instead of asking for approval: \"I can approve messages that pass my quality check and launch for you, then keep your sends filled. Reply review first if you would rather approve.\" Save the answer with `save_context` as Create Campaign's Standing Consent does. With `review_first`, retain one exact next step. Ask only for what you cannot do yourself, such as a LinkedIn connection, as one question.\n   A built-in weekday refill job fills sends before this review; do not run\n   Refill Sends again unless `refill` is this review's one outcome. Read\n   `refill_v3_world_state` for the next two sender-local days: a row whose\n   reason names a disconnected sender (`sender_disconnected`), a disconnected\n   Sales Navigator (`sales_nav_disconnected`) or\n   `paid_inmail_connection_health_recheck_required` is a fix only the customer\n   can make. Make it this review's `input`: name the sender and say reconnect\n   LinkedIn or reconnect Sales Navigator in Settings.\n6. Observe the owned operation, then record the outcome against the same review\n   effect and fence. The `record_review_outcome` call contains only its action,\n   effect, fence, review outcome, summary, and optional decision/operation refs;\n   do not include trigger or lease fields. Never mark a pending or uncertain\n   effect complete. On a scheduled actionable outcome, saving the outcome is\n   not completion. Inspect `deliveryRequired`; when it is `true`, continue\n   immediately to the required `stage_delivery` call. Never return while the recorded run still has `deliveryState: \"pending\"`. Write the outcome `summary` in plain customer words with the verified numbers (leads added, messages approved, sends scheduled): the next results update reads it as \"What Sellable did\".\n\n## Write the Slack message\n\nPost only new work or a real need, never a status. Use real line breaks: a bold title, a blank line between sections, one item per line, never one long paragraph. Write ordinary Markdown; delivery converts it for Slack.\n\n**{Workspace} · Campaign update · {Weekday Mon D}**\n\n**What I did** says in plain words what changed: leads added, messages approved,\nsends scheduled, campaign started, or a source widened.\n\n**Next step** and **Options** appear only when the customer must act: one specific\naction, then at most two options they can reply with. Offer only what you can really\ndo (refill, continue or edit the campaign) or what they can do (add leads, approve\nmessages, reconnect a sender).\n\nLead with what Sellable did to grow their sends. Never tell the customer what they\nhave not done, and never post a scoreboard of zeros. Plain words: no run tokens,\njob or effect IDs, error codes, tool names or file paths. Unknown is never zero.\nAbout 20-60 words.\n\n## Stop and delivery rules\n\nAn internal system fault (a run token, an error code, refill machinery) is not\na customer decision or blocker: do not post it.\n\nIf a tool call fails or its result can't be read, return `[SILENT]` and stop.\nNever post an error, an apology or a guess; the open claim lets the next\nscheduled window retry.\n\nStop on settled state, a human wait, a retained async wait, a typed blocker or\nthe existing bounded operation budget. Never restart a pending effect. Follow a\nnew customer reply or product completion immediately instead of waiting for the\nnext daily tick.\n\nPost a useful new decision or blocker once to the verified current main channel.\nRoutine refill belongs in the next results brief. A healthy no-op is inspectable\nand silent. On a scheduled actionable outcome, compose the complete final Slack\ntext, call `customer_program` with only `action: \"stage_delivery\"`, the exact\neffect and fence, and `text`, then inspect `delivery.deliverNow`. Only when it is `true`, return\n`delivery.text` verbatim as the native job's final response. When it is\n`false`, return `[SILENT]`; that effect is already uncertain or delivered,\nand the managed reconciliation tick owns the next step. Do not stage an interactive response.\n\nBefore any scheduled final response, check the recorded run one last time. A\n`pending` delivery is an unfinished cron turn: call `stage_delivery` now. Only\n`accepted_uncertain`, `delivered`, `failed`, or `not_applicable` may end the\nturn.\n\nOn a scheduled `reconcile` wake, call `reconcile_delivery` with only its action\nand the exact effect.\nIf trusted Slack history confirms the text, or retry is not yet allowed, return\n`[SILENT]`. If retry is allowed, call `retry_delivery` with the current fence and\nreturn its stored `delivery.text` verbatim. Never regenerate it. The native\nmanaged job remains the only Slack sender; the product owns the claim and\ndelivery ledger. After three unconfirmed attempts the product closes the run as\nfailed and later ticks stay silent. Never create another post path or fall back\nto another channel.\n\nDo not create a second campaign engine, refill algorithm, scheduler, scoring\nframework, intake questionnaire or generic morning approval. Do not rewrite\nstrategy or messages merely because another day passed. Initial campaign launch\nstill requires the existing human Start.\n"
   },
   {
     "path": "skills/sellable/sellable-campaign-daily-results/SKILL.md",

package/package.json

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

package/skill-templates/campaign-daily-review.md

@@ -44,12 +44,15 @@ the exact wait or outcome.
      first when it is missing;
    - healthy supplied campaign: maintain it and stay quiet;
    - manual pause: respect it;
-   - missing approval, connection or decision: with `launchConsent.mode: "autopilot"` approve messages that passed the quality check and start or resume the campaign yourself; otherwise retain one exact next step. Ask only for what you cannot do yourself, such as a LinkedIn connection, as one question.
-   Whatever the outcome, also run canonical Refill Sends with `yolo:true` for the
-   workspace's next two sender-local days before you finish. It checks capacity
-   itself and does nothing when queues are full. Keep going until the gap is
-   filled or a real blocker remains; refill results reach the customer in the
-   next results update, not as a separate post.
+   - missing approval, connection or decision: with `launchConsent.mode: "autopilot"` approve messages that passed the quality check and start or resume the campaign yourself. When `launchConsent` has no answer yet, ask the one-time question instead of asking for approval: "I can approve messages that pass my quality check and launch for you, then keep your sends filled. Reply review first if you would rather approve." Save the answer with `save_context` as Create Campaign's Standing Consent does. With `review_first`, retain one exact next step. Ask only for what you cannot do yourself, such as a LinkedIn connection, as one question.
+   A built-in weekday refill job fills sends before this review; do not run
+   Refill Sends again unless `refill` is this review's one outcome. Read
+   `refill_v3_world_state` for the next two sender-local days: a row whose
+   reason names a disconnected sender (`sender_disconnected`), a disconnected
+   Sales Navigator (`sales_nav_disconnected`) or
+   `paid_inmail_connection_health_recheck_required` is a fix only the customer
+   can make. Make it this review's `input`: name the sender and say reconnect
+   LinkedIn or reconnect Sales Navigator in Settings.
 6. Observe the owned operation, then record the outcome against the same review
    effect and fence. The `record_review_outcome` call contains only its action,
    effect, fence, review outcome, summary, and optional decision/operation refs;