@sellable/mcp 0.1.142 → 0.1.144

package/skills/create-campaign/SKILL.md

@@ -86,7 +86,7 @@ or tool discovery. Start in product language:
 ```text
 I’ll help you launch this as a Sellable campaign. First I’ll resolve the
 client/company this campaign is for, then I’ll turn that into a campaign brief
-before any leads are imported or anything can send.
+before we move into lead sourcing.
 ```
 
 If a linked/local skill file is stale or missing, silently use the installed
@@ -102,8 +102,14 @@ clear business decisions, tradeoffs, and approval gates. Use product language:
 - "a couple setup choices", not `request_user_input`
 - "campaign brief", not prompt artifact
 - "lead source", not provider internals unless comparing source options
-- "I can create a draft shell for you to watch, but no leads import and nothing
-  sends until you approve", not mutation jargon
+- "I can create a draft shell for you to watch with approval gates before
+  sourcing", not mutation jargon
+
+Approval and safety copy should be tasteful. State what the current approval
+covers once, in one short sentence, then move on. Do not append repeated
+"nothing starts / no leads import / no sending" disclaimers to routine progress
+updates. Use positive gate language like "Next gate: selected-post scrape" or
+"Approval covers scouting/search only" instead of long negative lists.
 
 When explaining lead-source decisions, show the concrete counts behind the
 logic: lanes searched, timeframe, raw result counts, finalist posts or preview
@@ -127,7 +133,7 @@ authorizes scouting/search only. The gate should say:
 - why that lane fits the buyer, offer, and likely public activity
 - what will be tested next
 - the fallback lane if relevant posts or ICP engagement look thin
-- that approval authorizes scouting/search only, not lead import or sending
+- what approval covers in one concise line
 
 Do not surface blanket source heuristics as product copy. Make the
 recommendation specific to the campaign. If Signal Discovery is recommended,
@@ -142,6 +148,20 @@ Signal Discovery, name how many selected posts will be scraped, the target
 engager/source-candidate volume, and the bounded review-batch size. For Sales
 Nav or Prospeo, name the specific approved import lane. Do not call
 `import_leads` or `confirm_lead_list` until this second approval is granted.
+For Signal Discovery, the customer-facing approval card must use the exact
+action shape "Approve scraping N Signal Discovery posts?" and the chat summary
+should be a compact `## Source Recommendation` block with:
+
+- goal: about 300 good-fit prospects after cleanup, enrichment, and filters
+- working assumption: about 15% of raw post engagers become good-fit prospects
+- engagers needed: about 2,000 raw engagers
+- a selected-post table with post author/topic, why it fits, and visible
+  engagement
+- total visible pool and estimated good-fit pool
+- first pass: build the source list, then import only 15 leads into the review
+  batch
+- fallback: switch to Sales Nav recent activity if the review batch is
+  vendor-heavy, agency-heavy, or off-ICP
 
 When the user has not supplied a source and multiple source angles are viable,
 scout those angles as independent branches when the host can actually do it:
@@ -159,8 +179,8 @@ The create-campaign-v2 subskill calls `get_source_scout_registry` before
 dispatch so the current registry, not this copy, is the runtime source of truth.
 If the host runs them sequentially or the named agents are unavailable, do not
 claim they ran in parallel and do not surface install status to the customer. In
-chat, call the downstream copy stage `message generation`;
-`message-validation.md` is only an internal proof artifact.
+chat, call the downstream copy stage `message generation`; message validation is
+only an internal approval proof.
 
 For campaign-attached Signal Discovery sampling, promote/select the exact posts
 with `select_promising_posts` before `fetch_post_engagers` so the user can see
@@ -168,19 +188,17 @@ which posts are being sampled in the watched app. The watch guide should say
 that we are pulling sample engagers from these posts to confirm the ICP is
 actually engaging and the source is viable.
 
-After find-leads returns a lead source and the user approves it, use the same
-registry pattern for the two post-lead branches. The create-campaign-v2 subskill
-calls `get_post_find_leads_scout_registry`, then launches the returned
-filter-leads scout and message-generation scout together when real subagents are
-available and the current session exposes the returned names. Message
-generation is the provisional Message Draft Builder: it may start after the
-review batch exists, including while the user is on filter choice, but workflow
-cell execution must wait. After rubrics are saved, do not queue enrichment,
-filtering, or Generate Message cells until the user approves the message
-template. AI Generated is an explicit opt-out that cancels or ignores the
-background template draft. If the post-lead agents are absent, the main thread
-still orchestrates the same branches from the compact context with MCP
-tools/assets.
+After the bounded review batch exists, use the same registry pattern for
+post-lead work. The create-campaign-v2 subskill calls
+`get_post_find_leads_scout_registry`, then launches the returned
+message-generation scout immediately when real subagents are available and the
+current session exposes the returned name. If the user chooses filters, launch
+the filter-leads scout then and join it with the already-running or completed
+message draft before message review. Workflow cell execution still waits for
+filter and template approval. AI Generated is an explicit opt-out that cancels
+or ignores the background template draft. If the post-lead agents are absent,
+the main thread still orchestrates the same branches from the compact context
+with MCP tools/assets.
 
 Use rendered Markdown for user review surfaces, not fenced code blocks. Keep
 lines short, use indexed section labels and bullets, and translate internal
@@ -412,7 +430,7 @@ First I’ll resolve the client/company this campaign is for. I’ll use that
 context to choose the target, offer, proof, and lead source.
 
 Then I’ll turn that into a campaign brief for you to approve before any leads
-are imported or anything can send.
+are sourced.
 ```
 
 Do not silently ask Codex intake or approval questions as plain chat when
@@ -597,7 +615,7 @@ updates.
    supplemental approval checklist, not a replacement for the long prompt. Use
    campaign state, campaign brief content, selected source state, and imported
    review-batch rows as the source of truth; do not read stale local markdown,
-   inspect the database directly, or synthesize `message-validation.md` from
+   inspect the database directly, or synthesize local validation artifacts from
    general knowledge.
 5. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Import only the first
@@ -609,9 +627,11 @@ updates.
    call `mcp__sellable__update_campaign({ campaignId, enableICPFilters: true, currentStep: "create-icp-rubric", watchNarration })`
    so the watched app moves to Filter Rules while rubrics are drafted/saved.
    After rubrics save, move the watched app to `apply-icp-rubric` / Filter
-   Leads and say the fit rules are saved; approve the message template next;
-   after approval, queue the bounded review-batch
-   `enrichCellId` cells to kick off enrichment/filtering.
+   Leads and say the fit rules are saved; approve the message template next
+   while the browser stays on Filter Leads. After approval, save the template
+   to the campaign brief, then queue the bounded review-batch `enrichCellId`
+   cells to kick off enrichment/filtering. Move to Messages only after at
+   least one review row passes and Generate Message cells are running or ready.
    Product Generate Message cells must not run from the background template
    path before that template/token approval.
    Do not ask the user to approve the brief before shell creation unless they
@@ -621,14 +641,14 @@ updates.
    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 15-row review batch, `create-icp-rubric` as soon
-   as filters are approved, `apply-icp-rubric` after rubrics save, `messages`
-   for the Use Template / AI Generated mode
-   choice, `auto-execute-messaging` for approved
-   message work or the product's AI-generated path, `awaiting-user-greenlight`
-   for the final handoff, `settings` for sender selection, `sequence` after
-   sender attach, and `send` once the recommended sequence is attached.
-   `validate-sample` is recovery/legacy only if reached. Do not advance the
-   step backward.
+   as filters are approved, `apply-icp-rubric` after rubrics save and while
+   waiting for message-template approval, `validate-sample` while the approved
+   template unlocks bounded enrichment/filter scoring on Filter Leads,
+   `auto-execute-messaging` after at least one row passes and review-batch
+   messages are being generated or reviewed, `awaiting-user-greenlight` only
+   after generated review-batch messages are approved, `settings` for sender
+   selection, `sequence` after sender attach, and `send` once the recommended
+   sequence is attached. 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.
 8. Do not ask the user to run another command.

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

@@ -6,6 +6,10 @@ visibility: internal
 
 # Create Campaign Brief
 
+Legacy/internal only. This standalone brief-first artifact path is not used by
+the public `create-campaign` wrapper or normal shell-first `create-campaign-v2`
+execution.
+
 You are a Sellable campaign strategist. Build one high-level `brief.md v1` from
 a LinkedIn URL, optional customer materials, quick research, one recommended
 campaign thesis, rough ICP mechanics, anti-buyer filters, invisible internal

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

@@ -47,8 +47,11 @@ for debug output.
     rows.
 11. Review and approve/revise the message.
 12. Sync the approved template into the campaign brief.
-13. Validate the bounded review batch, then move to Settings, sender, sequence,
-    and explicit launch greenlight.
+13. After message approval, keep the watched app on Filter Leads while the
+    bounded enrichment/filter cascade starts.
+14. Move to Messages only after at least one review row passes, generate and
+    review bounded messages, then hand off to Settings, sender, sequence, and
+    explicit launch greenlight.
 
 There is no normal approval-packet, commit-gate, atomic-mint, or local
 artifact-validation step. Those belong only to legacy validation/rehearsal
@@ -151,10 +154,48 @@ After scouting, show a second approval gate for the concrete source action. For
 Signal Discovery, this gate must say how many selected posts will be scraped,
 the target engager/source-candidate volume, the bounded campaign review-batch
 size, the cleanup risk, and the fallback if the selected posts look wrong. The
-approval label should describe the action, such as "Scrape 2 selected posts for
-the bounded review batch." For Sales Nav or Prospeo, the label should name the
-specific search/import lane. Do not call `import_leads` or `confirm_lead_list`
-until this second source-action approval is granted.
+approval label must describe the action with the count, such as "Approve
+scraping 3 Signal Discovery posts?" For Sales Nav or Prospeo, the label should
+name the specific search/import lane. Do not call `import_leads` or
+`confirm_lead_list` until this second source-action approval is granted.
+
+For Signal Discovery, use this compact source-action approval shape after
+selected posts exist:
+
+```markdown
+## Source Recommendation
+
+Use Signal Discovery first.
+
+**Goal:** ~300 good-fit prospects after cleanup, enrichment, and filters<br>
+**Working assumption:** ~15% of raw post engagers become good-fit prospects<br>
+**Engagers needed:** ~2,000 raw engagers
+
+### Selected posts
+
+| Post             | Why it fits                                     | Visible engagement |
+| ---------------- | ----------------------------------------------- | -----------------: |
+| Dylan Power      | Claude outbound system                          |             ~1,571 |
+| Fivos Aresti     | Replacing Clay outbound with Claude Code        |               ~734 |
+| Divyanshi Sharma | LinkedIn lead-gen system built with Claude Code |               ~508 |
+
+**Total visible pool:** ~2,813 engagers<br>
+**Estimated good-fit pool at 15%:** ~420 prospects before dedupe/risk cleanup
+
+### Recommendation
+
+Approve scraping these 3 posts.
+
+This gives enough volume to target ~300 good-fit prospects after cleanup, while
+keeping the source tied to people already engaging with Claude Code outbound /
+AI-native sales workflows.
+
+**First pass:** build the source list, then import only 15 leads into the
+review batch so we can inspect quality before scaling.
+
+**Fallback:** if the review batch is too vendor-heavy, agency-heavy, or
+off-ICP, switch to Sales Nav recent activity.
+```
 
 A source recommendation must show concrete evidence: source lane, filters or
 recipe, raw volume, sample size, sampled fits as n/N plus percentage/range,
@@ -169,8 +210,15 @@ customer-facing source-choice labels.
 
 After `confirm_lead_list` imports a non-empty bounded review batch and
 `get_rows_minimal({ tableId: workflowTableId })` proves rows exist, call
-`get_post_find_leads_scout_registry`. The filter and message branches use live
-CampaignOffer/source/table state as the source of truth. Debug markdown/json
+`get_post_find_leads_scout_registry` and start the Message Draft Builder branch
+immediately when the current host exposes that returned agent. Do this before
+asking the filter-choice question. If no real background branch can start, say
+the real sequence and do not claim background drafting is running.
+
+The message branch uses live CampaignOffer/source/table state as the source of
+truth and may draft while the user is choosing filters. It does not write
+message cells, enrich rows, attach sequences, or unlock Settings. The Lead Fit
+Builder branch starts only after the user chooses filters. Debug markdown/json
 artifacts are optional only.
 
 When the user chooses filters, immediately call
@@ -198,7 +246,9 @@ get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "references/
 ```
 
 Do not load the full `generate-messages` prompt in the create-campaign parent
-thread unless you are executing the parent-thread fallback for that branch.
+thread unless you are executing the parent-thread fallback for the actual
+message-draft branch. Parent-thread template approval uses only the compact
+message-review safety gate.
 
 ## Hard Gates
 

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

@@ -35,7 +35,7 @@ tell them what they will see next.
   is missing.
 - "lead source" beats provider internals unless comparing options.
 - "I’ll create the campaign shell with the brief so you can watch it fill in,
-  but no leads import and nothing sends yet" beats mutation jargon.
+  with approval gates before sourcing" beats mutation jargon.
 - "I’m turning this into a brief now" beats "I’m persisting the draft."
 - "Sorry, this is taking a little longer than expected" is appropriate when a
   step overruns its estimate. Do not over-apologize; one calm acknowledgment is
@@ -148,9 +148,9 @@ unless the user asks for them.
 Good opening:
 
 ```text
-I’ll help you launch this as a Sellable campaign. First I’ll resolve the
-client/company this campaign is for, then I’ll turn that into a campaign brief
-before any leads are imported or anything can send.
+I’ll help you launch this as a Sellable campaign. First I’ll confirm who we’re
+sending from and which company this is for, then I’ll turn that into a campaign
+brief before lead sourcing or anything can send.
 ```
 
 Good identity setup:
@@ -236,6 +236,13 @@ source. That approval only authorizes scouting/search. Second, after the
 source evidence exists, show counts, samples, fit math, cleanup risk, and ask
 for source approval before import.
 
+For Signal Discovery, the second gate is not "approve source" in the abstract.
+It is a concrete scrape approval: show a compact `## Source Recommendation`
+with the ~300 good-fit prospect goal, 15% raw-engager assumption, selected-post
+table, total visible pool, estimated good-fit pool, first-pass 15-row review
+batch, and fallback. The approval question should be "Approve scraping N Signal
+Discovery posts?"
+
 ## Parallelism + Naming
 
 Source selection is sequential by default. Start with the first recommended
@@ -257,13 +264,15 @@ scout loads only its matching provider prompt. If source work is sequential,
 keep the output numeric but do not claim the source scout was parallel or
 surface install status to the customer.
 
-For post-lead work, call `get_post_find_leads_scout_registry` after source
-approval and use the returned canonical `name` values. Launch both returned
-scouts in the same assistant turn/message when real subagents are available:
-`post-find-leads-filter-scout` and `post-find-leads-message-scout`. This is the
-same registry pattern as source scouting, but the trigger is approved
-find-leads output and the join gate is both `lead-filter.md` and
-`message-validation.md`.
+For post-lead work, call `get_post_find_leads_scout_registry` after
+`confirm_lead_list` imports a non-empty bounded review batch and
+`get_rows_minimal` proves rows exist. Start `post-find-leads-message-scout`
+immediately when real subagents are available, before asking the filter-choice
+question. Start `post-find-leads-filter-scout` only after the user chooses
+filters. This is the same registry pattern as source scouting, but the trigger
+for message drafting is review-batch import, not filter approval. The join gate
+is live branch readiness: saved rubrics or a resolved skip-filter choice, plus a
+message recommendation grounded in the same campaign/table basis.
 
 Only promise parallel post-lead work when parallel work actually started. If the
 host cannot or should not launch background branches, say the real sequence:
@@ -276,7 +285,7 @@ Do not say `kicking off two workstreams`, `in parallel`, or `background` as
 aspirational copy.
 
 Call the post-filter message stage `message generation` in chat.
-`message-validation.md` is an internal proof artifact, not the workstream name.
+Message validation is an internal approval proof, not the workstream name.
 
 Be explicit about what has and has not happened:
 

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

@@ -1,7 +1,7 @@
 {
   "version": "v2.1-compact",
   "workflow": "create-campaign-v2",
-  "principle": "CampaignOffer state and the watch link are canonical from the first brief onward. The active customer path is shell-first and state-first: create the watchable campaign shell with the brief, attach source/search state to that CampaignOffer, import one bounded review batch, persist rubrics and approved message template, validate the review batch, then hand off to Settings, sequence, and explicit start.",
+  "principle": "CampaignOffer state and the watch link are canonical from the first brief onward. The active customer path is shell-first and state-first: create the watchable campaign shell with the brief, attach source/search state to that CampaignOffer, import one bounded review batch, persist rubrics, wait on Filter Leads for approved message-template review, save the approved template, validate the bounded review batch, generate and review bounded messages, then hand off to Settings, sequence, and explicit start.",
   "normalCustomerPath": "Use campaign state, MCP tool responses, and concise watchNarration. Do not create, read, link, or surface local draft files in normal customer runs.",
   "legacyCompatibility": {
     "validationSubskill": "create-campaign-v2-validation",
@@ -460,6 +460,7 @@
           "requiredInlineFields": [
             "primary source and exact filters/recipe",
             "specific source action awaiting approval",
+            "for Signal Discovery: Source Recommendation markdown with goal ~300 good-fit prospects, ~15% raw-engager fit assumption, ~2,000 raw engagers needed, selected-post table, total visible pool, estimated good-fit pool, first pass, and fallback",
             "for Signal Discovery: selected post count and target engager/source-candidate volume",
             "bounded review batch size",
             "runner-up and why it lost",
@@ -475,13 +476,13 @@
           "action": "ask_source_review_choice",
           "uses": "request_user_input",
           "choices": [
-            "Scrape selected posts for the bounded review batch",
+            "Approve scraping N Signal Discovery posts",
             "Run the approved source import for the bounded review batch",
             "Revise source",
             "Pause here"
           ],
           "approvalChoiceLabelsByProvider": {
-            "signal-discovery": "Scrape selected posts for the bounded review batch",
+            "signal-discovery": "Approve scraping {selectedPostCount} Signal Discovery posts?",
             "sales-nav": "Import the approved Sales Nav review batch",
             "prospeo": "Import the approved Prospeo review batch"
           }
@@ -579,7 +580,18 @@
         {
           "action": "launch_message_draft_builder_after_review_batch_import",
           "tool": "get_post_find_leads_scout_registry",
-          "requiresNonEmptyRows": true
+          "target": "post-find-leads-message-scout",
+          "requiresNonEmptyRows": true,
+          "mustRunBefore": [
+            "filter-choice question",
+            "filter approval",
+            "save_rubrics"
+          ],
+          "mode": "background_when_host_supports_subagents",
+          "fallback": "if no real background branch can start, say the real sequence and do not claim background drafting is running",
+          "toolCallRequiredInBranch": "get_subskill_prompt({ subskillName: \"generate-messages\", offset, limit }) until hasMore=false",
+          "runtimeProofTransport": "CampaignOffer.watchNarration.workerDetails.messageDraftBuilder",
+          "purpose": "start the provisional message draft from the imported review batch immediately; do not defer this to filter approval"
         }
       ],
       "requiredCampaignState": [
@@ -702,7 +714,7 @@
           "purpose": "load canonical post-lead worker names"
         },
         {
-          "action": "launch_or_reuse_post_lead_workstreams",
+          "action": "launch_or_reuse_lead_fit_builder_and_existing_message_draft",
           "mode": "parallel_when_host_supports_subagents",
           "inputs": [
             "campaignId",
@@ -713,7 +725,8 @@
             "filterChoice"
           ],
           "stateSource": "CampaignOffer and workflow table rows",
-          "debugFilesOptionalOnly": true
+          "debugFilesOptionalOnly": true,
+          "messageDraftRule": "reuse or join the Message Draft Builder branch that started immediately after confirm_lead_list; do not start first-time message drafting here unless the earlier branch failed to start"
         },
         {
           "action": "save_filter_rubrics_to_campaign",
@@ -727,7 +740,7 @@
           "requiredSideEffects": {
             "enableICPFilters": true,
             "currentStep": "apply-icp-rubric",
-            "watchNarration.headline": "Filter Leads is ready"
+            "watchNarration.headline": "Filter rules saved"
           }
         }
       ],
@@ -769,7 +782,8 @@
       ],
       "hardRules": [
         "after_save_rubrics_currentStep_must_be_apply-icp-rubric",
-        "do_not_move_browser_to_messages_until_filter_leads_step_is_current_or_filters_are_explicitly_skipped"
+        "do_not_move_browser_to_messages_until_filter_leads_step_is_current_or_filters_are_explicitly_skipped",
+        "message_draft_builder_start_is_not_deferred_until_filters"
       ],
       "transitions": {
         "post_lead_workstreams_ready": "message-review",
@@ -800,7 +814,7 @@
           "requiredSideEffects": {
             "enableICPFilters": true,
             "currentStep": "apply-icp-rubric",
-            "watchNarration.headline": "Filter Leads is ready"
+            "watchNarration.headline": "Filter rules saved"
           }
         }
       ],
@@ -968,17 +982,26 @@
         "revise_messaging"
       ],
       "transitions": {
-        "message_approved": "auto-execute-messaging",
+        "message_approved": "validate-sample",
         "revise_messaging": "message-generation"
       }
     },
     {
       "id": "validate-sample",
-      "label": "Validate bounded review batch (legacy)",
-      "currentStepValue": "validate-sample",
-      "legacyOnly": true,
+      "label": "Validate bounded review batch",
+      "currentStepValue": "apply-icp-rubric",
       "reference": "references/sample-validation-loop.md",
+      "visibleStepRule": "This is the same Filter Leads screen reached by save_rubrics. Do not route away from or back to Filter Leads on approve-message; save the approved template, refresh watch narration on apply-icp-rubric, then queue the bounded Enrich Prospect cells.",
       "onEnter": [
+        {
+          "tool": "update_campaign",
+          "requiredValues": {
+            "currentStep": "apply-icp-rubric",
+            "watchNarration.stage": "fit-message"
+          },
+          "purpose": "keep the watched UI on Filter Leads while the approved template starts the bounded cascade",
+          "watchNarrationRule": "Say the template is saved and Filter Leads is now running the bounded enrichment and scoring pass."
+        },
         {
           "tool": "queue_cells",
           "purpose": "queue ICP/enrichment cells for the bounded review batch only",
@@ -1121,10 +1144,21 @@
         {
           "tool": "update_campaign",
           "requiredValues": {
-            "currentStep": "awaiting-user-greenlight",
+            "currentStep": "auto-execute-messaging",
             "watchNarration.stage": "review-ready"
           },
-          "watchNarrationRule": "Say what just happened, that review-batch messages are ready, and that the next action is Settings/sender review."
+          "watchNarrationRule": "Say what just happened, that review-batch messages are ready in Messages, and that the next action is reviewing or approving generated messages before Settings."
+        },
+        {
+          "action": "ask_generated_message_review_choice",
+          "uses": "request_user_input",
+          "choices": [
+            "Approve generated messages",
+            "Revise filters",
+            "Revise message template",
+            "Pause here"
+          ],
+          "rule": "Do not advance to Settings until the generated review-batch messages have been reviewed and approved."
         }
       ],
       "allowedTools": [
@@ -1151,11 +1185,13 @@
         "proposed_token_never_persisted_in_rewrite"
       ],
       "waitFor": [
-        "review_batch_ready",
+        "generated_messages_approved",
         "sample_revision_required"
       ],
       "transitions": {
-        "review_batch_ready": "awaiting-user-greenlight",
+        "generated_messages_approved": "awaiting-user-greenlight",
+        "revise_filters": "filter-rubric",
+        "revise_messaging": "message-generation",
         "escalation_triggered": "escalation"
       }
     },
@@ -1188,7 +1224,7 @@
             "connect or select a LinkedIn sender",
             "Slack reply review",
             "recommended sequence",
-            "nothing starts until the user confirms launch"
+            "final launch confirmation is still ahead"
           ]
         },
         {

package/skills/create-campaign-v2/core/policy.md

@@ -3,17 +3,15 @@
 This policy is the invariant layer for the from-scratch v2 orchestrator. Follow
 it even if prompt prose is ambiguous.
 
-## 1) JSON State Machine First
+## 1) Campaign State First
 
-`core/flow.v2.json` is the source of truth for:
+`core/flow.v2.json` defines the stage order and tool gates. CampaignOffer state,
+the watched app, selected source/list state, and campaign-table rows are the
+runtime source of truth.
 
-- stage order
-- required artifacts
-- produced artifacts
-- allowed tools
-- forbidden tools
-- wait events
-- transitions
+Normal create-campaign-v2 runs do not use local markdown/json artifacts as
+required state. Debug artifacts can exist only for explicit debug/UAT or legacy
+validation harnesses, and they must never override live campaign state.
 
 `SKILL.md` explains how to execute the flow. It does not replace the flow.
 
@@ -28,40 +26,37 @@ bootstrap -> brief-interview
 Do not start at `validate-artifacts` unless resuming a compatibility run where
 the complete upstream artifact set already exists.
 
-## 3) No Mutation Before Approval
+## 3) Shell-First Mutation Gates
 
-Before the user explicitly chooses `approve` at the commit gate, do not call:
+Create the campaign shell early after campaign identity and the initial brief
+are good enough for the customer to watch setup progress. Then enforce these
+mutation gates:
 
-- `create_campaign`
-- `save_rubrics`
-- `import_leads`
-- `confirm_lead_list`
-- `update_campaign`
-- `queue_cells`
-- `start_campaign`
+- Do not call provider search/import tools until the user approves the source
+  plan or explicitly chooses a source.
+- Do not call `import_leads` or `confirm_lead_list` until the concrete source
+  action is approved.
+- Import/confirm only the first bounded review batch before message approval.
+- Do not call `queue_cells` until filter choice is resolved, rubrics are saved
+  when filters are enabled, and the default Use Template path has an approved
+  message template/token rule set.
+- Do not attach a sequence or call `start_campaign` until the user explicitly
+  chooses to launch.
 
 Customer roleplay critique is advisory only. It cannot approve a campaign.
 
-## 4) Artifact Gates
+## 4) State Gates
 
-Do not run a downstream stage until the active step's `requiredArtifacts` exist.
-Intermediate user-review gates are interrupt-only: auto-continue when an
-artifact is confirmed and no strategic tradeoff is present. The final commit
-gate is the only mandatory pre-mint approval gate.
+Do not run a downstream stage until the matching live state exists:
 
-The minimum pre-approval chain is:
-
-```text
-brief.md
-lead-review.md
-lead-sample.json
-lead-filter.md
-message-prep.md (optional)
-message-candidate-drafts.md (optional, generated from find-leads basis rows)
-message-validation.md
-approval-packet.md
-commit-gate-decision.md
-```
+- campaign shell exists before a watch link is shown as active
+- selected source/list state exists before importing a review batch
+- `workflowTableId` and non-empty bounded review-batch rows exist before filter
+  and message branches run
+- `leadScoringRubrics` are saved before queueing ICP filter cells when filters
+  are enabled
+- approved message template/token rules are written to campaign brief before
+  queueing Generate Message cells on the default Use Template path
 
 ## 5) Revision Routing
 
@@ -73,10 +68,11 @@ Revision choices route back to the exact upstream stage:
 - `revise-messaging` -> `message-generation`
 - `abort` -> stop with zero DB mutation
 
-## 6) Post-Approval Tail
+## 6) Post-Message Tail
 
-After `approve`, mint atomically with `create_campaign` and `save_rubrics`.
-Only then surface the watch link and continue the cascade-driven tail.
+After message approval, queue only the bounded review-batch cells needed to move
+the watched app through enrichment, ICP filtering, and approved-template
+message generation. Keep the tail observable through watch narration.
 
 The tail stops at `awaiting-user-greenlight`. Never call `start_campaign`
 inside the autonomous tail.