@sellable/mcp 0.1.92 → 0.1.94

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.92",
+  "version": "0.1.94",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign/SKILL.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
 

package/skills/create-campaign-v2/SKILL.md

@@ -31,19 +31,21 @@ Run the configured JSON flow in durable stages:
 8. queue and validate the 10-row cascade
 9. settings/sender, sequence, and start handoff
 
-The JSON flow is the source of truth for stage order, `requiredArtifacts`,
-`producesArtifacts`, `allowedTools`, `doNotAllow`, `waitFor`, and
-`transitions`. This prompt explains how to execute those gates; it does not
-replace them.
-
-CampaignOffer state is canonical; disk artifacts are a debug trail. In this
-phase, all 14 disk artifacts remain as debug outputs, but resume, gating, and
+The JSON flow is the source of truth for stage order, artifact policy,
+`requiredArtifacts`, `producesArtifacts`, `allowedTools`, `doNotAllow`,
+`waitFor`, and `transitions`. In normal customer runs, obey
+`artifactPolicy.normalCustomerPath`: use campaign state and MCP responses instead
+of local draft files. This prompt explains how to execute those gates; it does
+not replace them.
+
+CampaignOffer state and the watch link are the customer-facing source of truth.
+Disk artifacts are optional debug/UAT diagnostics only. In normal customer runs,
+do not create, link, or surface local draft files unless the user explicitly asks
+for debug artifacts or the run is an explicit UAT/rehearsal. Resume, gating, and
 handoff read campaign state first: campaign id, watch URL, campaign brief,
 currentStep, provider/search association, selectedLeadListId as the source
 list, workflowTableId as the campaign table, saved rubrics, approved message
-template, senderIds, sequence template, and running state. `brief.md` is the
-single customer-facing debug copy of the brief; the campaign brief field is the
-durable downstream campaign thesis input.
+template, senderIds, sequence template, and running state.
 
 There is no separate approval-packet, commit-gate, or mint step in the active
 shell-first flow. The campaign exists early for watch mode. The hard boundary
@@ -54,7 +56,7 @@ are saved, and the approved message set is synced into the campaign brief.
 
 <files>
 
-Validated draft directory:
+Optional debug/UAT draft directory, disabled in normal customer runs:
 
 ```text
 .sellable/create-campaign-v2/drafts/{workspace-slug}/{campaign-slug}/
@@ -88,6 +90,14 @@ Validated draft directory:
   `watchUrl`; when the user opens it they should see the brief, not an empty
   campaign. If shell creation fails, stop and surface the error. There is no
   no-shell mint fallback in the active shell-first flow.
+- The main thread owns watch navigation. Before expensive work in each major
+  stage, call `update_campaign({ campaignId, currentStep })` with the visible UI
+  step the user should be watching, then continue the work from MCP/product
+  state. Use `create-offer` for the brief, `pick-provider` or the selected
+  provider step while sourcing, `filter-choice` after the 10-row review batch is
+  imported, `messages`/`auto-execute-messaging` for message work,
+  `validate-sample` for the 10-row validation cascade, and
+  `awaiting-user-greenlight` for Settings. Do not advance `currentStep` backward.
 - After the shell is minted, normal resume paths read the CampaignOffer first.
   Use debug files to explain or reconstruct work, not to decide whether a
   post-mint gate is allowed. Validation/debug artifacts are not durable campaign
@@ -110,7 +120,7 @@ Validated draft directory:
   `request_user_input` (enabled in Default mode by
   `[features].default_mode_request_user_input = true`, not available in
   `codex exec`). Treat them as equivalent approval/intake gates and persist the
-  same draft artifacts after the user answers. Use this structured gate only for
+  same campaign state after the user answers. Use this structured gate only for
   single-choice decisions with fixed options or approval gates. Every campaign
   setup gate must be single-choice in both hosts: set or assume
   `multiSelect: false`, use mutually exclusive option labels, and do not ask
@@ -163,13 +173,13 @@ Validated draft directory:
   or safe launch. Do not say "persist", "local draft folder", "artifact",
   "mkdir", "campaign thesis", or "same approved campaign thesis" in
   customer-facing progress copy.
-- 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. Do not use the link
-  as a substitute for rendering the decision in chat; links are for deeper
-  inspection.
+- Every approval gate must include live campaign access after the readable inline
+  content. Show a short `Watch link:` line with the campaign link when a
+  campaign shell exists. In normal customer runs, do not show `Open artifact:`
+  lines, raw filesystem paths, or local draft filenames. If the run is explicit
+  debug/UAT or the user asks for local artifacts, artifact links may be shown as
+  secondary diagnostics. The link is never a substitute for rendering the
+  decision in chat.
 - Any time the user is reviewing a list or decision, use rendered Markdown with
   short indexed sections and bullets. Do not use label-plus-paragraph blocks
   like `Key numbers:` followed by one long paragraph. Do not use fenced code
@@ -274,8 +284,9 @@ Validated draft directory:
   Before that first
   structured question gate, do not run source discovery, Sales Nav, Prospeo,
   Signals, Bash, Read, Write, Edit, Glob, Grep, full company research, or
-  draft-directory inspection/creation. Do draft-directory setup only after the
-  founder answers. After launch identity and any ambiguous campaign focus are
+  draft-directory inspection/creation. In normal customer runs, do not create a
+  draft directory after the founder answers; create/update the campaign shell and
+  campaign state instead. After launch identity and any ambiguous campaign focus are
   confirmed, the setup packet must
   use the structured question gate and ask buyer, offer/CTA, proof, and lead
   source. All four questions must include an `Other / custom` option.
@@ -314,14 +325,16 @@ Validated draft directory:
   Settings/final handoff.
 
 - Before asking for brief approval, render a slim approval brief in the chat and
-  keep the rich current brief in `brief.md`. Use rendered Markdown directly:
+  write the rich current brief into `CampaignOffer.campaignBrief` through
+  `create_campaign`/`update_campaign`. Use rendered Markdown directly:
   `##` heading, bold field labels, numbered section labels, and short bullets.
   Do not wrap the user-facing approval view in a fenced code block because that
   creates horizontal scrolling in Claude Code and Codex. Do not ask the user to
   approve a one-paragraph direction, a risk note, or hidden artifact they cannot
   inspect. The chat approval view should be skimmable in under 45 seconds; full
-  reasoning, source notes, and robustness stay in the artifacts. Include these
-  sections, with short wrapped lines:
+  reasoning, source notes, and robustness can stay in optional debug artifacts
+  only during explicit debug/UAT runs. Include these sections, with short wrapped
+  lines:
 
   ```text
   ## Campaign brief
@@ -378,21 +391,19 @@ brief`, `Revise target`, `Revise offer/proof`, and `Other / custom`.
   not visible in this session, use `Approve brief + compare source paths`
   instead. The customer approves the sourcing decision, not the host
   implementation detail.
-  Include an `Open artifact:` link to `brief.md` before the approval question.
-  The visible brief must come before local persistence chrome. After the brief
-  is synthesized, render the approval-ready brief in chat before running visible
-  `mkdir`, `Write`, artifact-copy, or similar local draft setup. When the host
-  supports sidecar/background work, let a background writer persist `brief.md`
-  while the main thread keeps the brief review moving. If no background writer
-  is available, write `brief.md` synchronously only after the visible brief is
-  already in chat. File/folder creation is not the user's value moment; the
-  brief is.
-
-  The approval question can be based on the rendered brief in chat. Do not wait
-  for file-write chrome before asking for approval. Before lead sourcing or any
-  downstream step reads `brief.md`, reconcile that the persisted file matches
-  the visible approved brief; if the sidecar is still running, wait quietly or
-  finish the write synchronously at that boundary.
+  Include a `Watch link:` line before the approval question once
+  `create_campaign` has returned `watchUrl`. The visible brief must come before
+  any optional debug persistence. After the brief is synthesized, render the
+  approval-ready brief in chat and create/update the campaign shell before any
+  visible `mkdir`, `Write`, artifact-copy, or similar local draft setup. In
+  normal customer runs, skip local draft setup entirely. File/folder creation is
+  not the user's value moment; the live campaign brief is.
+
+  The approval question can be based on the rendered brief in chat and the live
+  campaign brief. Do not wait for file-write chrome before asking for approval.
+  Before lead sourcing, call `update_campaign({ campaignId, campaignBrief,
+  currentStep: "pick-provider" })` after approval so the watch link moves out of
+  Plan while the main thread compares source paths.
 
 - After the brief is approved, show the next progress line:
   `Cool. Now I'm going to find people who are both a good fit and active enough
@@ -418,26 +429,30 @@ message we should test.`
   show you the draft next so you can approve it or change it.
   ```
 
-- In hosted/rehearsal runs, `Bash` is only for safe local draft-directory
+- In explicit debug/UAT runs, `Bash` is only for safe local draft-directory
   housekeeping before the import/test batch: `mkdir`, `ls`, `find`, `test`, `pwd`, `echo`,
-  or `cat` inside the repo. Do not use
+  or `cat` inside the repo. In normal customer runs, do not use Bash for local
+  draft setup. Do not use
   Bash to run interpreters/scripts (`python`, `node`, `npm`, `pnpm`, `yarn`,
   `npx`), call APIs, query databases, inspect prompt dumps, run git, or
   synthesize artifact content. Use `Read`/`Write`/`Edit` for artifact files and
   MCP tools for product actions.
-- `brief.md` is the single user-facing debug copy of the brief. The
-  `CampaignOffer.campaignBrief` field is the stable downstream thesis source.
-- `lead-review.md` and `lead-sample.json` are the required outputs of `find leads`.
-  `lead-review.md` is customer-readable: describe source paths as provider
-  lanes checked (Signals, Sales Nav, Prospeo) and never include custom agent
-  names, host availability, install state, allowed-tool state, or fallback
-  implementation details.
+- `CampaignOffer.campaignBrief` is the stable downstream thesis source.
+  `brief.md` is an optional debug/UAT copy only; never make it the user-facing
+  approval surface in normal customer runs.
+- The lead-source decision and lead sample must be rendered in chat and attached
+  to campaign state/search state. `lead-review.md` and `lead-sample.json` are
+  optional debug/UAT outputs of `find leads`; when they exist, describe source
+  paths as provider lanes checked (Signals, Sales Nav, Prospeo) and never
+  include custom agent names, host availability, install state, allowed-tool
+  state, or fallback implementation details.
 - `lead-filter.md` is the primary output of `filter leads`.
 - `rubric.json` is optional and secondary to `lead-filter.md`.
 - `message-prep.md` is an optional speed artifact produced by the explicit
   message path after find-leads. It can prepare proof inventory, buyer
   objections, CTA options, gold-standard strategy maps, and candidate angles
-  from `brief.md`, `lead-review.md`, and `lead-sample.json`.
+  from the live campaign brief, source decision, lead sample, and optional debug
+  copies.
 - `message-candidate-drafts.md` is an optional provisional speed artifact from
   sample rows that already look like probable good fits. It can contain rough
   candidate messages and element tests, but it cannot select the final winner
@@ -448,10 +463,10 @@ message we should test.`
   message quality gate outputs between `message-validation.md` and
   `approval-packet.md`.
 - Run the dependency chain as a DAG: `create-campaign-brief` -> `find leads` ->
-  bounded import/confirm. Once `lead-review.md`, `lead-sample.json`, and the
-  campaign table `workflowTableId` exist, the normal path is the
+  bounded import/confirm. Once the source decision, lead sample, and campaign
+  table `workflowTableId` exist, the normal path is the
   `post-lead-workstreams` step. Launch `filter leads` and `message generation`
-  from the same basis (`brief.md`, `lead-review.md`, `lead-sample.json`, and
+  from the same basis (live campaign brief, source decision, lead sample, and
   the imported review-batch rows) as separate workstreams when the host exposes
   the named Sellable post-find-leads agents or real background work.
   First call `get_post_find_leads_scout_registry` and use the returned
@@ -466,8 +481,8 @@ message we should test.`
   resume targets.
 - Message generation does not need `lead-filter.md` to start. The moment the
   bounded review batch is imported and `workflowTableId` is ready, start the
-  message-generation workstream from `brief.md`, `lead-review.md`,
-  `lead-sample.json`, and the imported campaign table sample. It can prepare
+  message-generation workstream from the live campaign brief, source decision,
+  lead sample, and the imported campaign table sample. It can prepare
   proof inventory, token strategy, and candidate angles while filter-leads
   tightens keep/exclude rules. Approval still waits for both `lead-filter.md`
   and `message-validation.md`, then reconciles that the selected message basis
@@ -512,10 +527,11 @@ workstreams`, `in parallel`, or `background` unless parallel branches were
   available. This is the two Task/Agent subagents path for the
   `post-lead-workstreams` step. This is the same registry pattern as source scouting, but the
   trigger is source approval and the join gate is both `lead-filter.md` and
-  `message-validation.md` existing from the same `brief.md`, `lead-review.md`,
-  and `lead-sample.json`.
-- Never run a downstream stage until the active `flow.v2.json` step's
-  `requiredArtifacts` exist.
+  `message-validation.md` existing from the same live campaign brief/source
+  decision/lead-sample basis.
+- Never run a downstream stage until the active `flow.v2.json` step's required
+  campaign state and required normal inputs exist. In normal customer runs, do
+  not create optional debug artifacts just to satisfy a file gate.
 - Never call a tool outside the active step's `allowedTools`, and never call a
   tool listed in the active step's `doNotAllow`.
 - Before the source is approved, `import_leads` and `confirm_lead_list` are
@@ -922,7 +938,7 @@ user-facing lead review. The visible response must include:
   usable prospects per post, and use/discard decision.
 - `Sample leads` with 3-5 representative `Name — Title, Company` rows
 - `Tradeoff`
-- `Open artifact: lead-review.md`
+- `Watch link: {watchUrl}` when the campaign shell exists
 
 The first sentence of the visible decision must make the actual choice clear:
 `I recommend {primary source} using {exact filter/source recipe}. The runner-up
@@ -948,9 +964,9 @@ fresh, high-density posts when available, sample engagers, show fit rate, then
 state how many additional posts could be added/scraped if that first sample is
 good but volume is low.
 
-Keep discarded paths, full sample rows, and `lead-sample.json` details in
-artifacts. Do not show raw filesystem paths unless links cannot be created or
-the user asks.
+Keep discarded paths and full sample rows in the campaign/source decision
+context. In explicit debug/UAT runs they may also be copied into
+`lead-sample.json`. Do not show raw filesystem paths unless the user asks.
 
 For supplied profile CSVs and existing lead lists, `lead-review.md` must not
 describe a generic TAM estimate or pretend the rows came from Sales Nav/Prospeo

package/skills/create-campaign-v2/SOUL.md

@@ -60,10 +60,11 @@ Approvals only feel safe when the user can see what they are approving. Before
 any approve/revise question, show the relevant decision in plain language. For a
 brief approval, render the brief itself, not just a direction summary.
 
-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 `Open artifact:` links, 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
@@ -138,9 +139,10 @@ because the campaign state is what the lead source, filters, and messages will
 build from. I’ll show you the draft next so you can approve it or change it.
 ```
 
-CampaignOffer state is canonical; disk artifacts are a debug trail. Keep the
-diagnostics for inspection, and all 14 disk artifacts remain as debug outputs,
-but resume, gating, and handoff read campaign state first.
+CampaignOffer state and the watch link are canonical. Disk artifacts are
+optional debug/UAT diagnostics. Normal customer runs should read, resume, gate,
+and hand off from campaign state first, and should not expose local draft files
+unless the user asks for them.
 
 Good opening:
 

package/skills/create-campaign-v2/core/flow.v2.json

@@ -1,7 +1,13 @@
 {
   "version": "v2",
   "workflow": "create-campaign-v2",
-  "principle": "CampaignOffer state is canonical from the first brief onward. The flow still writes the 14 disk artifacts as a debug trail, but resume, gating, and handoff read campaign state first. Start from user intake, create a watchable campaign shell with a v1 brief, attach source/search state to that CampaignOffer, import the bounded review batch before post-import fit/message scouts, save rubrics and an approved message template, then queue the 10-row cascade and hand off to settings/sequence/start.",
+  "principle": "CampaignOffer state and the watch link are canonical from the first brief onward. Disk artifacts are optional debug/UAT diagnostics, not the normal customer surface. Resume, gating, and handoff read campaign state first. Start from user intake, create a watchable campaign shell with a v1 brief, update currentStep before major visible work, attach source/search state to that CampaignOffer, import the bounded review batch before post-import fit/message scouts, save rubrics and an approved message template, then queue the 10-row cascade and hand off to settings/sequence/start.",
+  "artifactPolicy": {
+    "normalCustomerPath": "Use CampaignOffer state, MCP responses, provider search state, and campaign table rows. Do not create, read, link, or surface local draft files unless debug/UAT mode is explicit or the user asks for them.",
+    "debugArtifactsAreOptional": true,
+    "requiredArtifactsApplyWhen": "legacy resume, fixture validation, or explicit debug/UAT mode only",
+    "customerFacingAccess": "Watch link and live campaign currentStep"
+  },
   "commitGateChoices": [
     "approve",
     "revise-brief",
@@ -211,7 +217,7 @@
           "target": "create-campaign-brief"
         },
         {
-          "action": "render_brief_preview_before_artifact_write",
+          "action": "render_brief_preview_before_debug_artifact_write",
           "requiredVisibleContent": [
             "Campaign brief",
             "Decision",
@@ -224,20 +230,21 @@
             "What happens next"
           ],
           "mustRunBefore": [
-            "start_background_artifact_writer",
+            "optional_debug_artifact_writer",
             "Bash",
             "mkdir"
           ],
-          "chatRenderRule": "After synthesizing the brief, render the approval-ready brief in chat before any visible local folder creation, file write, or artifact copy. The user should see useful brief content before local persistence chrome. Do not ask the user to approve a hidden artifact."
+          "chatRenderRule": "After synthesizing the brief, render the approval-ready brief in chat before any optional local folder creation, file write, or artifact copy. Normal customer runs should not create local draft files here. The user should see useful brief content and live campaign state, not local persistence chrome. Do not ask the user to approve a hidden artifact."
         },
         {
-          "action": "start_background_artifact_writer",
+          "action": "optional_debug_artifact_writer",
           "artifact": "brief.md",
-          "mode": "sidecar_when_host_supports_background_agents",
+          "mode": "debug_or_uat_only",
+          "shouldNotRunInNormalCustomerPath": true,
           "shouldNotBlockMainThread": true,
           "allowedToRunWhileUserReviewsInlineBrief": true,
-          "fallback": "If no background writer is available, write brief.md synchronously only after the approval-ready brief is already visible in chat.",
-          "chatRenderRule": "Do not surface folder/file-write progress in chat unless the write fails or the user asks. The main thread should keep the brief review moving while the sidecar persists brief.md."
+          "fallback": "If debug/UAT artifacts are requested and no background writer is available, write brief.md synchronously only after the approval-ready brief is already visible in chat. In normal customer runs, skip the write.",
+          "chatRenderRule": "Do not surface folder/file-write progress in chat unless the write fails or the user asks. The main thread should keep the brief review moving from campaign state."
         },
         {
           "action": "create_watchable_campaign_shell_with_v1_brief",
@@ -304,10 +311,7 @@
         }
       ],
       "requiredArtifacts": [],
-      "producesArtifacts": [
-        "brief.md",
-        "campaign-shell.json"
-      ],
+      "producesArtifacts": [],
       "allowedTools": [
         "get_subskill_prompt",
         "get_subskill_asset",
@@ -359,7 +363,8 @@
       "onEnter": [
         {
           "action": "show_brief_summary",
-          "artifact": "brief.md"
+          "source": "campaignBrief",
+          "fallbackDebugArtifact": "brief.md"
         },
         {
           "action": "render_brief_approval_checkpoint",
@@ -378,10 +383,15 @@
             "then I will find good-fit leads"
           ],
           "minimumVisibleBriefDetail": "full_readable_brief_before_question",
-          "requiredArtifactLinks": [
-            "brief.md"
+          "requiredCampaignLinks": [
+            "watchUrl"
+          ],
+          "campaignLinkTiming": "before_approval_question",
+          "forbiddenNormalCustomerLinks": [
+            "brief.md",
+            "local draft path",
+            "Open artifact:"
           ],
-          "artifactLinkTiming": "when_ready_before_downstream",
           "avoidQuestionWhenOnlyUsefulAnswerIs": "looks good"
         },
         {
@@ -397,13 +407,14 @@
           }
         },
         {
-          "action": "ensure_background_artifact_ready",
+          "action": "optional_debug_artifact_sync",
           "artifacts": [
             "brief.md"
           ],
-          "requiredBeforeTransition": "find-leads",
-          "reconcileRule": "Before lead sourcing reads brief.md, verify the sidecar persisted the same brief shown in chat. If the sidecar is still running, wait quietly or finish the write synchronously; if it differs, reconcile to the visible approved brief.",
-          "chatRenderRule": "Do not block the brief approval question on this step. Only mention artifact persistence if it fails or needs user action."
+          "debugOrUatOnly": true,
+          "requiredBeforeTransition": false,
+          "reconcileRule": "If debug/UAT artifacts are enabled, verify the sidecar persisted the same brief shown in chat. Normal customer lead sourcing reads CampaignOffer.campaignBrief, not brief.md.",
+          "chatRenderRule": "Do not block the brief approval question or find-leads transition on this step. Only mention artifact persistence if debug/UAT mode fails or the user asks."
         },
         {
           "action": "sync_approved_brief_to_campaign_shell",
@@ -415,7 +426,7 @@
           "when": "after_user_brief_confirmed_or_auto_continue",
           "fields": [
             "campaignBrief",
-            "currentStep:create-offer"
+            "currentStep:pick-provider"
           ],
           "fallback": "If campaignId is missing from CampaignOffer state, stop; shell-first flow requires an existing campaign before sourcing leads.",
           "readsCampaignStateFirst": true,
@@ -425,9 +436,7 @@
           ]
         }
       ],
-      "requiredArtifacts": [
-        "brief.md"
-      ],
+      "requiredArtifacts": [],
       "producesArtifacts": [],
       "allowedTools": [
         "AskUserQuestion",
@@ -467,6 +476,19 @@
       "id": "find-leads",
       "label": "Find leads",
       "onEnter": [
+        {
+          "action": "advance_watch_to_source_selection",
+          "tool": "update_campaign",
+          "requiredFields": [
+            "campaignId",
+            "currentStep"
+          ],
+          "requiredValues": {
+            "currentStep": "pick-provider"
+          },
+          "when": "before_source_scouts_or_provider_search",
+          "chatRenderRule": "Move the campaign watch view to Find Contacts before the main thread starts comparing source paths. Do not mention MCP or local artifacts."
+        },
         {
           "action": "render_find_leads_progress",
           "requiredVisibleContent": [
@@ -505,20 +527,18 @@
           "sourceScoutRule": "Shell-first flow requires the CampaignOffer campaignId from durable state. Pass campaignId as campaignOfferId into every provider prompt/search that can persist source state (`get_provider_prompt({ provider, campaignOfferId, confirmed: true })`, `search_signals`, `search_sales_nav`, `search_prospeo`) so the user can watch the selected source inside the campaign. The later import_leads call must use the same campaignOfferId. When several source lanes are credible, scout them independently, then write one primary source recommendation and any runner-up tradeoffs. Do not import, confirm, enrich, queue, or start leads during source discovery."
         },
         {
-          "action": "write_artifacts",
+          "action": "optional_debug_artifacts",
           "artifacts": [
             "lead-review.md",
             "lead-sample.json"
-          ]
+          ],
+          "debugOrUatOnly": true,
+          "shouldNotRunInNormalCustomerPath": true,
+          "chatRenderRule": "Do not create or surface local lead-review artifacts in normal customer runs. The main thread renders the source decision in chat and persists provider/source state to the campaign."
         }
       ],
-      "requiredArtifacts": [
-        "brief.md"
-      ],
-      "producesArtifacts": [
-        "lead-review.md",
-        "lead-sample.json"
-      ],
+      "requiredArtifacts": [],
+      "producesArtifacts": [],
       "allowedTools": [
         "get_subskill_prompt",
         "get_subskill_asset",
@@ -1319,7 +1339,7 @@
             "Question: approve-message or revise-messaging?",
             "Recommendation:"
           ],
-          "chatRenderRule": "Show a slim rendered-Markdown message review, never a fenced code block. Use ## Message review plus indexed sections and short bullets. Show one fully filled sample message with no {{tokens}} before asking for approval. Include subject, sample message, why it should work, one concern or None, recommendation, and Open artifact: message-review.md. Keep tokenized template, token fill basis, rendered examples, good/bad token fill examples, validation notes, and message-validation.md details in artifacts. Do not show plain filesystem paths unless links cannot be created.",
+          "chatRenderRule": "Show a slim rendered-Markdown message review, never a fenced code block. Use ## Message review plus indexed sections and short bullets. Show one fully filled sample message with no {{tokens}} before asking for approval. Include subject, sample message, why it should work, one concern or None, recommendation, and Watch link when a campaign shell exists. Keep tokenized template, token fill basis, rendered examples, good/bad token fill examples, validation notes, and message-validation.md details in campaign state or optional debug artifacts. Do not show plain filesystem paths unless the user asks.",
           "allowedRecommendations": [
             "approve-message",
             "revise-messaging"

package/skills/create-campaign-v2/references/approval-gate-framing.md

@@ -5,10 +5,11 @@ runs do not route through `approval-packet`, `commit-gate`, or `atomic-mint`.
 Load this file only when resuming a compatibility run that already has those
 debug artifacts.
 
-CampaignOffer state is canonical; disk artifacts are a debug trail. All 14 disk
-artifacts remain as debug outputs, but resume, gating, and handoff read campaign
-state first. In new runs, the live campaign object appears after the short brief,
-not after this approval packet.
+CampaignOffer state and the watch link are canonical. Disk artifacts are
+optional debug/UAT diagnostics, and normal customer runs should not expose local
+draft files. Resume, gating, and handoff read campaign state first. In new runs,
+the live campaign object appears after the short brief, not after this approval
+packet.
 
 ## Purpose
 

package/skills/create-campaign-v2/references/filter-leads.md

@@ -1,8 +1,9 @@
 # Filter Leads
 
-CampaignOffer state is canonical; disk artifacts are a debug trail. All 14 disk
-artifacts remain as debug outputs, but resume, gating, and handoff read campaign
-state first. Filter design may use the debug sample, but the active rubric save
+CampaignOffer state and the watch link are canonical. Disk artifacts are
+optional debug/UAT diagnostics, and normal customer runs should not expose local
+draft files. Resume, gating, and handoff read campaign state first. Filter design
+may use the live lead sample or optional debug sample, but the active rubric save
 is `save_rubrics({ campaignOfferId, leadScoringRubrics }) after the campaign
 table exists`.
 

package/skills/create-campaign-v2/references/final-handoff-contract.md

@@ -14,10 +14,11 @@ that decision — UI and Claude greenlight — and the skill must handle both
 cleanly, including the case where one channel has already started the
 campaign before the other arrives.
 
-CampaignOffer state is canonical; disk artifacts are a debug trail. All 14 disk
-artifacts remain as debug outputs, but resume, gating, and handoff read campaign
-state first. At this point, `workflowTableId` is the campaign table, while
-`selectedLeadListId` remains the source list that produced the review batch.
+CampaignOffer state and the watch link are canonical. Disk artifacts are
+optional debug/UAT diagnostics, and normal customer runs should not expose local
+draft files. Resume, gating, and handoff read campaign state first. At this
+point, `workflowTableId` is the campaign table, while `selectedLeadListId`
+remains the source list that produced the review batch.
 
 ## Step 16 Setup
 

package/skills/create-campaign-v2/references/step-13-import-leads.md

@@ -6,9 +6,9 @@ Step 13.
 
 ## Principle
 
-CampaignOffer state is canonical; disk artifacts are a debug trail. All 14 disk
-artifacts remain as debug outputs, but resume, gating, and handoff read campaign
-state first.
+CampaignOffer state and the watch link are canonical. Disk artifacts are
+optional debug/UAT diagnostics, and normal customer runs should not expose local
+draft files. Resume, gating, and handoff read campaign state first.
 
 Bounded review-batch sourcing + import happens after the existing campaign
 shell has the selected source attached with `campaignOfferId`. It happens before

package/skills/create-campaign-v2/references/validation-criteria.md

@@ -6,8 +6,9 @@ message direction hold up against real preview evidence.
 
 ## Primary Contract
 
-- CampaignOffer state is canonical; disk artifacts are a debug trail.
-- validation/debug artifacts are not durable campaign state.
+- CampaignOffer state and the watch link are canonical.
+- validation/debug artifacts are optional debug/UAT diagnostics, not durable campaign state.
+- normal customer runs should not expose local draft files.
 - resume and handoff read campaign state before debug files.
 - `CampaignOffer.campaignBrief` is the durable Phase 83 thesis input;
   `brief.md` is its debug copy

package/skills/create-campaign-v2/references/watch-link-handoff.md

@@ -4,9 +4,10 @@ This reference governs how create-campaign-v2 surfaces the watch link in the
 shell-first flow. Load it before showing the link and on every resume where the
 link needs to be re-surfaced.
 
-CampaignOffer state is canonical; disk artifacts are a debug trail. All 14 disk
-artifacts remain as debug outputs, but resume, gating, and handoff read campaign
-state first.
+CampaignOffer state and the watch link are canonical. 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.
 
 ## Plumbing Reuse
 
@@ -61,8 +62,9 @@ Stop before `save_rubrics` and recover the missing signed URL first.
 
 ## Step Orientation
 
-After the shell exists, re-surface the same watch link only when it helps orient
-the user after a meaningful step change:
+After the shell exists, the main thread must update `currentStep` before each
+meaningful visible stage, then re-surface the same watch link only when it helps
+orient the user after a meaningful step change:
 
 - source selected: the campaign should point at the primary provider step
 - rubrics saved: the campaign should show filter/rubric state

package/skills/create-campaign-v2-tail/SKILL.md

@@ -8,10 +8,11 @@ visibility: internal
 
 This is the tail detail extracted from the main create-campaign-v2 SKILL.md to keep the entry prompt slim. The agent loads this on-demand BEFORE entering the auto-execute or validate-sample steps. Follow this verbatim.
 
-CampaignOffer state is canonical; disk artifacts are a debug trail. All 14 disk
-artifacts remain as debug outputs, but resume, gating, and handoff read campaign
-state first. selectedLeadListId remains the source list; workflowTableId is the
-campaign table.
+CampaignOffer state and the watch link are canonical. Disk artifacts are
+optional debug/UAT diagnostics; normal customer runs should not expose local
+draft files. Resume, gating, and handoff read campaign state first.
+selectedLeadListId remains the source list; workflowTableId is the campaign
+table.
 
 ## MANDATORY TOOL ORDER (read this BEFORE any tail step)
 

package/skills/find-leads/SKILL.md

@@ -87,9 +87,9 @@ The kickoff doc is the resume surface. Re-open it before repeating discovery wor
   explorer agents installed from the same canonical Sellable agent registry.
   Launch every credible lane in the same assistant message so Claude Code can
   run them concurrently/background:
-  - `./.claude/agents/source-scout-linkedin-engagement.md`
-  - `./.claude/agents/source-scout-sales-nav.md`
-  - `./.claude/agents/source-scout-prospeo-contact.md`
+  - `~/.claude/agents/source-scout-linkedin-engagement.md`
+  - `~/.claude/agents/source-scout-sales-nav.md`
+  - `~/.claude/agents/source-scout-prospeo-contact.md`
 - These Claude agents must have explicit Sellable MCP tool allowlists and must
   load the matching provider prompt before searching. They are optional
   acceleration: if the names are absent, do not mention the missing install or