@sellable/install 0.1.78 → 0.1.79

package/bin/sellable-install.mjs

@@ -601,12 +601,11 @@ data, compare sources by source volume, sampled ICP fit, activity/warmth
 signals, cleanup risk, and confidence basis. If a user asks for a forecast,
 label it explicitly as not estimated from this run.
 
-Every approval gate must include artifact access after the readable inline
-content. Show an \`Open artifacts:\` line with clickable markdown links using
-absolute paths when the host supports them, plus the plain path for CLI users.
-Do this for brief approval, lead-source approval/review, message review, and the
-final approval packet. The links are for deeper inspection; never use them as a
-substitute for showing the content in chat.
+Every approval gate must include live campaign access after the readable inline
+content. Show a \`Watch link:\` line once the campaign shell exists. In normal
+customer runs, do not show local draft filenames or filesystem paths unless the
+user asks for debug artifacts. The link is for deeper inspection; never use it
+as a substitute for showing the content in chat.
 
 Never mention MCP namespaces, prompt chunking, plugin cache paths, missing
 linked skill versions, runbooks, or local skill files in normal customer-facing
@@ -960,10 +959,10 @@ approval should show who we are targeting, why they should care, the offer/CTA,
 proof, lead source hypothesis, message angle, risks/assumptions, and what
 happens after approval.
 
-Every approval should also give the user a way to inspect the source artifact.
-After the readable inline content, include an \`Open artifacts:\` line with links
-or plain paths to the files behind the decision. The artifact links are a backup
-for inspection, not a replacement for showing the content in chat.
+Every approval should also give the user a way to inspect the live campaign.
+After the readable inline content, include a \`Watch link:\` line when a
+campaign shell exists. Local artifacts are optional debug/UAT diagnostics only;
+do not surface file paths or local draft filenames in normal customer runs.
 
 This applies especially to message approvals. Never ask someone to approve a
 message they cannot see. Show the subject, tokenized template, a filled sample

package/package.json

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

package/skill-templates/create-campaign.md

@@ -66,10 +66,10 @@ allowed-tools:
 
 Use this as the customer-facing entrypoint for Sellable campaign creation.
 
-CampaignOffer state is canonical; disk artifacts are a debug trail. The
-internal create-campaign-v2 flow still writes the diagnostics, and all 14 disk
-artifacts remain as debug outputs, but resume, gating, and handoff read campaign
-state first. The
+CampaignOffer state and the watch link are the customer-facing source of truth.
+Disk artifacts are optional debug/UAT diagnostics; normal customer runs should
+not create, link, or surface local draft files unless the user explicitly asks
+for them. Resume, gating, and handoff read campaign state first. The
 watchable campaign exists after the short brief; lead import is bounded to the
 first review batch, and enrichment/message generation waits until rubrics and
 the approved message template are saved on the campaign.
@@ -147,13 +147,12 @@ Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
 sourcing terms into plain language.
 
-Every approval gate must include artifact access after the readable inline
-content. Show a short `Open artifact:` line with the one key clickable markdown
-link for that stage. Do not show raw filesystem paths unless links cannot be
-created or the user asks. Do this for brief approval, lead-source
-approval/review, lead-filter review, and message review.
-The link is for deeper inspection; never use it as a substitute for showing the
-content in chat.
+Every approval gate must include live campaign access after the readable inline
+content. Show a short `Watch link:` line once the campaign shell exists. In
+normal customer runs, do not show `Open artifact:` lines, raw filesystem paths,
+or local draft filenames. Local artifacts are debug/UAT-only unless the user asks
+for them. The link is for deeper inspection; never use it as a substitute for
+showing the content in chat.
 
 Never mention MCP namespaces, prompt chunking, plugin cache paths, missing
 linked skill versions, runbooks, or local skill files in normal customer-facing
@@ -503,9 +502,16 @@ updates.
    `message-validation.md` proves the message-review safety-gate workflow ran,
    `message-review.md` approves the template, rubrics are saved, and the
    approved message set is synced into the campaign brief.
-6. Keep `selectedLeadListId` as the source list and `workflowTableId` as the
+6. The main thread owns watch navigation. Call
+   `mcp__sellable__update_campaign({ campaignId, currentStep })` before major
+   visible work so the user can watch progress in the app: `create-offer` for
+   the brief, `pick-provider` or the selected provider step while sourcing,
+   `filter-choice` after the 10-row review batch, `messages` or
+   `auto-execute-messaging` for message work, `validate-sample` for validation,
+   and `awaiting-user-greenlight` for Settings. Do not advance the step backward.
+7. Keep `selectedLeadListId` as the source list and `workflowTableId` as the
    campaign table. Do not use disk files as the post-mint source of truth.
-7. Do not ask the user to run another command.
+8. Do not ask the user to run another command.
 
 ## Fallback