@sellable/install 0.1.354-phase110.20260718014821 → 0.1.356

package/package.json

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

package/skill-templates/refill-sends.md

@@ -335,9 +335,15 @@ campaign's stored search intent; (3) `"agent_supplied"` last. When a
 `broaden_signal_search` action returns `keywordSource:"agent_supplied"`, both
 earlier tiers are receipt-proven spent this run but the 45-day universe is not
 proven dry: read the campaign brief, ICP, and persona and invent 3-5 concrete NEW
-GTM-topic keywords that are NOT in the action's `searchedKeywords` negative list,
-then supply them as `agentKeywords` on that action — still without changing rubrics
-or thresholds, and never re-issuing a spent search. Signal exhaustion is a
+GTM-topic keywords that are NOT in the action's `searchedKeywords` negative list —
+still without changing rubrics or thresholds, and never re-issuing a spent search.
+When a run stops asking for agent-supplied keywords (blocker
+`signal_agent_keywords_invalid`, or a pending `agent_supplied` broaden with no
+keywords), re-invoke the SAME `refill_sends` command with the run's `runId` and
+`fence` plus `agentKeywords: [your 3-5 keywords]`; the fenced run validates them
+against the negative list, consumes them once into the pending broaden round, and
+resumes automatically. An out-of-envelope payload is typed-refused so you can
+correct and re-invoke. Signal exhaustion is a
 quantified yield projection, not a fuzzy engagement read: every tier projects
 new-lead yield as the sum of scrapable engager counts across the NEW recent (<=45
 day) candidate posts times the campaign's observed headline-ICP pass rate, and the