@sellable/install 0.1.341 → 0.1.343-phase102.202607122257

package/package.json

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

package/skill-templates/create-campaign.md

@@ -6,6 +6,7 @@ allowed-tools:
   - mcp__sellable__get_auth_status
   - mcp__sellable__start_cli_login
   - mcp__sellable__wait_for_cli_login
+  - mcp__sellable__validate_campaign1_kickoff_handoff
   - mcp__sellable__bootstrap_create_campaign
   - mcp__sellable__get_subskill_prompt
   - mcp__sellable__get_subskill_asset
@@ -808,6 +809,30 @@ sender context, not a customer-facing campaign identity concept.
 
 ### Sufficient Intake Bypass
 
+If the invocation includes the exact `handoffMarkdown` and `binding` returned
+by a finalized `admin_onboarding_call`, call
+`mcp__sellable__validate_campaign1_kickoff_handoff` before any strategy
+question. Pass the expected visible revision plus the exact client, sender,
+workspace, and engagement identity resolved for this invocation. The transport
+is inline Markdown only: reject a public Notion URL, do not fetch or scrape it,
+and do not read a hidden file or receipt.
+
+On a valid `sellable.kickoff.campaign1.v1` result, use only the returned typed
+`intake` and `campaignBriefMarkdown` as sufficient intake. Verify the public
+sender identity with the normal lightweight profile/research completion path,
+then create the watchable shell from that returned brief. Do not ask product,
+ICP/audience, offer/CTA, proof, exclusions, or Signal Discovery questions
+again. The LinkedIn topics, creators, posts, conversations, and participant
+behavior are the sole source thesis. Dream account and lookalikes are
+qualitative fit examples only and must never become provider/account seeds.
+
+If validation fails, stop before `create_campaign`, source search, import, or
+any other campaign mutation and show the typed validation error. Never fall
+back to surrounding agenda prose. A valid handoff skips factual discovery only:
+the visible brief/watch approval, Find Buyers Plan approval, separate Start
+Import approval, filter and message approvals, sender/sequence setup, and final
+Start approval all remain mandatory and ordered exactly as in the normal flow.
+
 When the user's invocation or first answer already supplies the campaign
 identity plus enough strategy context to draft the campaign, do not turn that
 into an interview. Treat setup as complete when the request contains:

package/skill-templates/refill-sends.md

@@ -223,13 +223,17 @@ Structured planner packet:
   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`.
+  `Already sent`, `Scheduled`, `Ready and waiting to be scheduled`,
+  `Still need to schedule`, and `Still need to prepare`. Never render an
+  unlabeled `Still need` value.
 - `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.
+- When that primitive is `run_scheduler_sweep`, show `workspaceWide:true` and
+  its reason in the approval/yolo packet so the operator sees that the sweep
+  may schedule other eligible workspace cells on the approved date.
 - `manualAlternates` are not yolo actions. Threshold lowering and campaign
   creation are manual continuations only.
 
@@ -324,12 +328,16 @@ 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.
+open in a persistent read-only scheduler wait loop. Honor the emitted wait
+metadata: reread `get_refill_target_plan` after about 30 seconds by default (or
+the action's explicit `rereadAfterMs`), never use a blind hard-coded sleep, and
+stop at the named bound using `receipt_deadline > unchanged_poll_bound >
+run_budget` precedence. A matching active/uncertain request key is never
+redispatched. Continue until projected coverage fills the target, a concrete
+non-scheduler blocker appears, a named bound stops the run, 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