@sellable/mcp 0.1.80 → 0.1.82

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

@@ -1,17 +1,25 @@
 # Approval Gate Framing
 
-This reference governs the commit gate in create-campaign-v2. Load this file
-before showing the user the approval packet at the end of Phase 84 and before
-minting a real `CampaignOffer`.
+This reference is legacy/resume-only for create-campaign-v2. New shell-first
+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.
 
 ## Purpose
 
-The approval gate is the **only** place in create-campaign-v2 where the user
-authorizes a DB mutation. Everything upstream (Phase 83 brief + Phase 84
-validation artifacts) is file-only. Everything downstream (atomic mint +
-autonomous tail) is live campaign state.
+The approval gate used to be the place where the user authorized
+spend/send-adjacent mutation. It is now compatibility-only. New runs import the
+bounded 10-row review batch after source approval, save rubrics and the approved
+message template after post-import review, and only then queue the cascade.
 
-No campaign row exists until the user picks `approve`.
+If `campaign-shell.json` exists, a draft `CampaignOffer` row already exists but
+must remain non-sendable. If no shell exists, no campaign row exists until the
+user picks `approve`.
 
 ## Preconditions
 
@@ -60,8 +68,8 @@ This invariant is identical to the Phase 84 "sender/workspace mismatch
 From Wrong Workspace`. If the invariant fails:
 
 1. Do NOT show the commit gate.
-2. Do NOT call `bootstrap_create_campaign`, `create_campaign`, or
-   `save_rubrics`.
+2. Do NOT call `bootstrap_create_campaign`, `create_campaign`,
+   `update_campaign`, or `save_rubrics`.
 3. Surface an explicit workspace/sender-mismatch error + the detected
    current-workspace vs expected-workspace diagnostic.
 4. Leave the draft directory intact; a fresh session in the correct
@@ -204,6 +212,9 @@ If a customer/operator roleplay pass is run before the gate, write its critique
 to `customer-roleplay.md`. That critique is advisory only. A positive roleplay
 result is not approval and must not trigger `create_campaign`,
 `save_rubrics`, or any other DB mutation.
+`customer-roleplay.md` can never authorize mint; only
+`commit-gate-decision.md` authorizes DB mutation when it says
+`Decision: approve`.
 
 After the user/operator chooses, write `commit-gate-decision.md` with exactly
 one of the six allowed choices plus a short reason. This file is the durable
@@ -248,6 +259,7 @@ abort
 
 Use the host-native structured question gate with these 6 options. Do not
 collapse, reorder, or add choices. Do not auto-select.
+Do not collapse the six routes into one vague approval choice.
 
 If the host UI limits options per question, preserve all six routes with a
 two-question gate instead of mentioning implementation limits:
@@ -263,18 +275,26 @@ choice that activates the second question.
 
 ### `approve`
 
-User authorizes atomic mint. Proceed to the atomic-mint step:
+User authorizes committing the draft shell or atomic mint. Proceed to the
+atomic-mint step:
 
 0. **verify workspace/sender invariant** (see §Preconditions) — if the
    invariant fails, abort BEFORE `bootstrap_create_campaign`
 1. `bootstrap_create_campaign({ flowVersion: "v2" })`
-2. `create_campaign({ campaignBrief, currentStep: "auto-execute-leads" })`
-   → capture `{ campaignId, watchUrl }` from response
-3. `save_rubrics({ campaignOfferId, rubric })` using `rubric.json` (or derived
+2. If `campaign-shell.json` exists, call `create_campaign({ campaignId })` to
+   resume/recover `{ campaignId, watchUrl }`, then
+   `update_campaign({ campaignId, campaignBrief, leadSourceType,
+leadSourceProvider, currentStep: "auto-execute-leads" })` with the final
+   approved brief and source decision.
+3. If no shell exists, call
+   `create_campaign({ campaignBrief, currentStep: "auto-execute-leads",
+leadSourceType, leadSourceProvider })` and capture `{ campaignId, watchUrl }`
+   from the response.
+4. `save_rubrics({ campaignOfferId, rubric })` using `rubric.json` (or derived
    payload from `lead-filter.md`)
-4. flip brief status to `committed`; move draft to `.committed/`
-5. surface the watch link using `watch-link-handoff.md`
-6. hand off to the autonomous tail (Plan 85-02)
+5. flip brief status to `committed`; move draft to `.committed/`
+6. surface the watch link using `watch-link-handoff.md`
+7. hand off to the autonomous tail (Plan 85-02)
 
 See `watch-link-handoff.md` for the exact link-surfacing protocol and the
 partial-mint recovery rules.
@@ -314,7 +334,8 @@ automatic rollback.
 ### `revise-brief`
 
 Route back to Phase 83 or Phase 84 depending on what the user wants to change.
-Do NOT mint a campaign. Do NOT print a watch link.
+Do NOT commit/mint a campaign. If a draft shell already exists, keep it
+non-sendable and update it only through the normal draft-shell sync points.
 
 Draft effect: preserve nothing by default; the brief itself is usually
 rewritten upstream. Delete all downstream artifacts so Phase 84 will re-run:
@@ -327,8 +348,9 @@ rewritten upstream. Delete all downstream artifacts so Phase 84 will re-run:
 
 ### `revise-leads`
 
-Route back to Phase 84 `find leads`. Do NOT mint a campaign. Do NOT print a
-watch link.
+Route back to Phase 84 `find leads`. Do NOT commit/mint a campaign. If a draft
+shell already exists, keep it non-sendable and replace only draft-shell source
+state when the revised source is approved.
 
 Draft effect:
 
@@ -341,8 +363,9 @@ Draft effect:
 
 ### `revise-rubric`
 
-Route back to Phase 84 `filter leads`. Do NOT mint a campaign. Do NOT print a
-watch link.
+Route back to Phase 84 `filter leads`. Do NOT commit/mint a campaign. If a draft
+shell already exists, keep it non-sendable and update only saved draft rubrics
+after the revised filter is confirmed.
 
 Draft effect:
 
@@ -355,8 +378,8 @@ Draft effect:
 
 ### `revise-messaging`
 
-Route back to Phase 84 `generate message`. Do NOT mint a campaign. Do NOT
-print a watch link.
+Route back to Phase 84 `generate message`. Do NOT commit/mint a campaign. If a
+draft shell already exists, keep it non-sendable.
 
 Draft effect:
 
@@ -369,25 +392,34 @@ Draft effect:
 
 ### `abort`
 
-User cancels the session. Do NOT mint a campaign. Do NOT print a watch link.
+User cancels the session. Do NOT commit/mint a campaign and do NOT import,
+queue, attach sequence, or start. If a draft shell exists, leave it paused/
+non-sendable for operator cleanup instead of silently deleting a workspace row.
 
 Draft effect: move the draft directory to
 `.sellable/create-campaign-v2/drafts/{workspace-slug}/.aborted/{campaign-slug}-{timestamp}/`.
-No DB rows touched. No `CampaignOffer` created.
+Legacy no-shell runs touch no DB rows and create no `CampaignOffer`.
+No DB rows touched in legacy no-shell aborts; draft-shell aborts leave the
+non-sendable shell for operator cleanup.
 
 ## Hard Rules
 
-- The user's `approve` choice is the **only** trigger for live DB mutation.
+- The user's `approve` choice is the **only** trigger for lead import,
+  campaign-table cloning, workflow-table queuing, sequence attach, or start.
+- A positive `customer-roleplay.md` critique is not approval and produces zero
+  launch mutation unless `commit-gate-decision.md` explicitly says
+  `Decision: approve`.
 - A positive `customer-roleplay.md` critique is not approval and produces zero
   DB mutation unless `commit-gate-decision.md` explicitly says
   `Decision: approve`.
-- The commit gate must not call `create_campaign`, `save_rubrics`,
-  `import_leads`, `update_campaign`, or any other mutating tool before the
-  user picks a choice.
+- The commit gate must not call `create_campaign`, `update_campaign`,
+  `save_rubrics`, `import_leads`, or any other mutating tool before the user
+  picks a choice. Draft-shell writes happen in earlier allowed flow steps, not
+  inside the commit-gate question turn.
 - `import_leads` is **not** part of atomic mint. Full sourcing/import happens
   in Plan 85-02 Step 13 after mint.
-- Revision choices produce ZERO DB rows.
-- Aborting produces ZERO DB rows.
+- Revision choices produce no spend/send-side effects.
+- Aborting produces no spend/send-side effects.
 - A failed `approve` path (e.g. `create_campaign` errors, or `save_rubrics`
   fails after campaign creation) does NOT surface a watch link. See
   `watch-link-handoff.md` for the partial-mint recovery protocol.

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

@@ -1,5 +1,11 @@
 # 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
+is `save_rubrics({ campaignOfferId, leadScoringRubrics }) after the campaign
+table exists`.
+
 The middle step is a lightweight lane audit and decision gate. It should add
 fidelity to the find-leads estimate, not re-run sourcing or produce a large
 scoring framework.
@@ -116,6 +122,8 @@ one client, a funded seed-stage team for another, multi-location practice size
 for another, or existing tool spend for another. Do not hard-code Sellable's
 exact budget, geography, or title rules into unrelated campaigns; hard-code the
 principle that passing leads must be worth the customer's time.
+Do not hard-code Sellable's exact budget into the filter; translate affordability
+into the client's native buying proxy.
 
 - right role / function: the person owns or directly influences the buyer
   problem; wrong-function leads fail even when they match the source topic

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

@@ -14,23 +14,43 @@ 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.
+
 ## Step 16 Setup
 
 On entry to `awaiting-user-greenlight`, the skill does the following in
 order (all before waiting for the user):
 
-1. Attach the sequence to the campaign (`attach_sequence`).
-2. Re-surface the `watchUrl` using the exact block in
+1. Call `get_campaign({ campaignId })` and inspect whether the campaign has at
+   least one attached sender and whether a sequence is already attached.
+2. Call `list_senders()` so the handoff can name available connected senders if
+   the campaign has none selected.
+3. If no sender is attached, surface the campaign Settings link
+   `/campaign-builder/{campaignId}/settings?mode=claude`, tell the user to attach
+   a sender there, and STOP. Do not attach sequence and do not start.
+4. If a sender is attached but no sequence is attached, surface the campaign
+   Sequence link `/campaign-builder/{campaignId}/sequence?mode=claude`, tell the
+   user to accept or adjust the recommended sequence there, and STOP. Do not
+   start. The Claude greenlight path may use
+   `attach_recommended_sequence({ campaignId })` as an explicit repair after the
+   user asks to start.
+5. Re-surface the `watchUrl` using the exact block in
    `references/watch-link-handoff.md`.
-3. Surface the `handoff.orientation` string from `auto-execute.yaml`
+6. Surface the `handoff.orientation` string from `auto-execute.yaml`
    alongside the watch link so the user sees both the link and the
    "what to do next" sentence.
-4. STOP. Do not call `start_campaign`. Do not advance `currentStep`.
+7. STOP. Do not call `start_campaign`. Do not advance `currentStep`.
 
 The final handoff must answer five customer questions in plain language:
 
 - where to inspect the campaign (`watchUrl`)
-- what is ready now (brief, filters/rubrics, review-batch leads, messages, sequence)
+- what is ready now (brief, filters/rubrics, review-batch leads, messages, and
+  sequence when a sender is attached)
+- whether the next UI step is Settings because a sender still needs to be
+  attached
 - what clicking Start does (approves/starts the campaign send path)
 - how to revise (reply with what to change, or use the campaign UI)
 - whether anything has started yet (nothing sends until the user starts)
@@ -58,10 +78,11 @@ the UI.
 
 ### UI path
 
-The user reviews messages in the watch link, bulk-approves messages in
-the workflow table UI (the existing "Approve all" button that wraps
-`POST /api/v3/workflow-tables/cells/approve-batch`), and clicks "Start
-Campaign" in the campaign-builder UI.
+The user reviews messages in the watch link, attaches a sender in Settings when
+needed, chooses/accepts the sequence, bulk-approves messages in the workflow
+table UI (the existing "Approve all" button that wraps
+`POST /api/v3/workflow-tables/cells/approve-batch`), and clicks "Start Campaign"
+in the campaign-builder UI.
 
 No skill involvement. The skill remains idle in
 `awaiting-user-greenlight`. On the next resume, the skill observes
@@ -74,7 +95,13 @@ The user replies in chat with an affirmative intent: "yeah start",
 "looks good, start", "ship it", "go". The skill then performs, in
 order, atomically:
 
-1. **Bulk-approve queued messages** via the existing endpoint
+1. **Fetch campaign state** with `get_campaign({ campaignId })` and short-circuit
+   if already running.
+2. **Validate sender + sequence state.** If no sender is attached, refuse start
+   and return the Settings link. If no sequence is attached but a sender is
+   attached, call `attach_recommended_sequence({ campaignId })` before approving
+   messages.
+3. **Bulk-approve queued messages** via the existing endpoint
    `POST /api/v3/workflow-tables/cells/approve-batch` with
    `{ tableId }`.
    - This is the SAME server action the UI "Approve all" button uses
@@ -86,18 +113,20 @@ order, atomically:
    - If no MCP tool wrapper for approve-batch is available, the skill
      invokes it via the same authenticated API client path that other
      v3 routes use.
-2. **`start_campaign({ campaignId })`** — flips the campaign into the
-   running state. If this call fails, surface the error; do NOT leave
+4. **Verify start preconditions again**: `workflowTableId`, attached
+   `senderIds`, `sequenceTemplate`, and a validated greenlight/send
+   `currentStep` must all exist before start.
+5. **`start_campaign({ campaignId })`** — flips the campaign into the
+   running state and persists `CampaignOffer.currentStep = "running"` through
+   the backend start route. If this call fails, surface the error; do NOT leave
    the approvals in an "approved but not started" half-state silently
    — either retry or escalate with the explicit state.
-3. **`update_campaign({ campaignId, currentStep: "running" })`** — moves
-   the skill past `awaiting-user-greenlight` so resume lands in a
-   "campaign live" confirmation state.
-4. **Re-surface the watch link** plus a short "campaign is live"
+6. **Re-surface the watch link** plus a short "campaign is live"
    confirmation sentence.
 
-All three mutating steps (bulk-approve, start_campaign, update_campaign)
-must succeed together. If step 1 succeeds but step 2 fails, the skill
+The mutating start steps (sequence repair when needed, bulk-approve, and
+start_campaign) must succeed together. If approve-batch
+succeeds but start_campaign fails, the skill
 surfaces the recoverable state and stops — it does NOT attempt to
 unapprove (that would be destructive) and it does NOT silently retry
 forever.
@@ -137,7 +166,7 @@ true:
   (e.g. upstream lead import failed post-mint and never recovered).
 - Workspace mismatch between skill context and campaign row.
 - Sender is missing or disabled.
-- `attach_sequence` never succeeded (no sequence bound to the
+- `attach_recommended_sequence` never succeeded (no sequence bound to the
   campaign).
 
 A refusal is NOT an escalation in the ladder sense — it's a pre-check
@@ -163,6 +192,10 @@ does NOT silently proceed.
 - The autonomous tail NEVER calls `start_campaign` on its own.
 - Step 16 NEVER auto-advances past `awaiting-user-greenlight` without a
   user signal.
+- Step 16 routes to Settings before sequence/start when no sender is attached.
+- Step 16 routes to Sequence before start when no sequenceTemplate is attached.
+- Prefer `attach_recommended_sequence`; use `attach_sequence` only for an
+  explicitly custom cadence.
 - Bulk-approve in the Claude greenlight path uses the EXISTING
   `POST /api/v3/workflow-tables/cells/approve-batch` endpoint. Do NOT
   invent a new tool / endpoint / mutation path.
@@ -170,7 +203,9 @@ does NOT silently proceed.
   confirmation, not a duplicate start.
 - Workspace/sender mismatch at greenlight time aborts the start with
   the Phase 84 invariant.
+- The start route, not a follow-up `update_campaign`, persists
+  `currentStep: "running"`.
 - A pre-check refusal is NOT an escalation — it's a fixable state. The
   skill stays in `awaiting-user-greenlight`.
 - Never print the watch link in a half-started state (approved but not
-  started, or started but `currentStep` not updated).
+  started, or a start response that did not return `currentStep: "running"`).

package/skills/create-campaign-v2/references/lead-validation-preview.md

@@ -5,8 +5,16 @@ This reference defines the Phase 84 `find leads` output contract.
 ## Inputs
 
 - `brief.md`
+- CampaignOffer campaignId
+- `campaign-shell.json` debug copy when present
 - optional `lead-source-intake.json`
-- the existing `find-leads` capability in campaignless preview mode
+- the existing `find-leads` capability in shell-first campaign-attached preview mode
+
+CampaignOffer state is canonical; these files are debug outputs; resume and
+gating read campaign state first. Campaignless preview mode is only allowed
+before the campaign shell is minted; once a CampaignOffer exists, use its
+campaignId as `campaignOfferId`.
+campaignless preview mode is only allowed before the campaign shell is minted.
 
 ## Output Files
 
@@ -16,33 +24,38 @@ lead-sample.json
 lead-source-intake.json   # only when the user intentionally supplied a source
 ```
 
+Read `brief.md`, `lead-review.md`, and `lead-sample.json` as debug context;
+the CampaignOffer is still the resume/gating source after mint.
+
 ## Tooling Rules
 
-Preview only:
+Shell-first source preview:
 
-- use `find-leads` without `campaignOfferId`
+- use `find-leads` with CampaignOffer campaignId as `campaignOfferId`
 - do not call `import_leads`
-- do not set `selectedLeadListId`
+- do not import into the campaign table or set `workflowTableId`
+- do not set `workflowTableId`
 - do not call `confirm_lead_list`
-- do not create workflow rows or campaign rows
+- do not create workflow rows
+- do not queue cells, attach a sequence, or start the campaign
 - do not call `save_domain_filters`
+- only mutate campaign-attached source preview state in the narrow watch-mode
+  ways allowed by `flow.v2.json`
 
 Supplied-source preview:
 
 - `normal-discovery` is the default when the user does not already know the
   people/accounts.
-- `supplied-linkedin-profiles` uses `load_csv_linkedin_leads` before approval
-  only as preview. Pre-approval calls must omit `confirmed: true`,
-  `campaignOfferId`, `currentStep`, `leadListId`, `sourceLeadListId`, and
-  provider-import parameters.
-- `supplied-domains` uses `load_csv_domains`. Pre-approval confirmation is
-  allowed only to create a standalone `domainFilterId` and must omit
-  `campaignOfferId` and `currentStep`. Use that `domainFilterId` for a
-  campaignless account-constrained people sample.
-  In other words, pre-approval domain CSV confirmation must omit
-  `campaignOfferId` and `currentStep`.
-- `existing-lead-list` samples from the existing Sellable lead list before
-  approval and does not clone/import it until after approval.
+- `supplied-linkedin-profiles` uses `load_csv_linkedin_leads` before the
+  10-lead import batch only as preview/source attachment. Pre-import calls
+  must omit provider-import parameters. Use `campaignOfferId` only to attach the
+  preview/list choice to the campaign UI.
+- `supplied-domains` uses `load_csv_domains` to create or reuse a
+  `domainFilterId`, then runs campaign-associated Prospeo sampling with
+  `campaignOfferId`. Step 13 reuses the same `domainFilterId` for import.
+- `existing-lead-list` samples from the existing Sellable lead list and does
+  not clone/import it until rubrics are saved and the approved message set is in
+  the campaign brief.
 
 `lead-source-intake.json` records:
 

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

@@ -1,16 +1,38 @@
 # Step 13 — Import Leads Contract
 
-This reference governs Step 13 (`auto-execute-leads`) of the Plan 85-02
-autonomous tail. Load before calling `import_leads` and on every resume
-into Step 13.
+This reference governs Step 13 of the shell-first create-campaign-v2 flow. Load
+before calling `import_leads` or `confirm_lead_list` and on every resume into
+Step 13.
 
 ## Principle
 
-Bounded review-batch sourcing + import happens AFTER atomic mint, not during.
-The commit gate never calls `import_leads`; Step 13 is where the first real
-review batch is pulled into the workspace. Do not spend credits on the full
-source list until the user reviews the first batch and explicitly approves
-expansion.
+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.
+
+Bounded review-batch sourcing + import happens after the existing campaign
+shell has the selected source attached with `campaignOfferId`. It happens before
+the post-import fit/message scouts, so those scouts can use the actual campaign
+table sample.
+
+Do not queue workflow cells, attach a sequence, or start before the later
+rubric/message prerequisites are true:
+
+1. rubrics saved to the campaign
+2. approved message set synced into `campaignBrief`
+
+Do not enrich, queue workflow cells, attach a sequence, or start before those
+prerequisites are true.
+
+Before `import_leads`, the approved source must already be campaign-attached.
+The find-leads scouts receive `campaignOfferId` up front, so selected Signal
+posts, provider searches, domain filters, or source lead-list IDs should already
+live on the campaign. Reuse that state. If anything is missing, do not replay
+the source inside Step 13; route back to find-leads so the source can be
+attached with `campaignOfferId` and the campaign UI can stay in sync.
+
+selectedLeadListId remains the source list; workflowTableId is the campaign
+table. The first confirm/import must preserve both identities.
 
 ## Resolve Approved Source
 
@@ -21,11 +43,15 @@ source lead lists, searches, campaign table rows, or queued cells.
 
 Supported branches:
 
-- **No manifest / normal discovery** — use the existing provider import path.
+- **No manifest / normal discovery** — reuse the approved provider source that
+  is already attached to this campaign, then import. Never call a bare
+  `import_leads({ campaignOfferId })` for Signal Discovery unless selected posts
+  already exist on the campaign.
 - **Supplied LinkedIn profile CSV** — confirm `load_csv_linkedin_leads` only
-  after approval to batch/materialize the full uploaded CSV into a Sellable
-  lead-list table. Persist the returned `leadListId`, then import the bounded
-  review batch into the campaign table with
+  after rubrics and the approved message set are ready. Batch/materialize the
+  uploaded CSV into a Sellable lead-list table. Persist the returned
+  `leadListId`, then import the bounded review batch into the campaign table
+  with
   `confirm_lead_list({ sourceLeadListId: leadListId, targetLeadCount: importLimit })`.
   Do not call `import_leads` for this branch; the materialized lead list is the
   source.
@@ -41,6 +67,21 @@ Supported branches:
   `campaignOfferId`, provider prompt preflight, and `domainFilterId`, then
   import the review batch from that search.
 
+## Campaign-Attached Source Contract
+
+Step 13 does not rediscover or replay source searches. It imports from the
+campaign-attached state created during find-leads:
+
+- Signal Discovery: selected posts must already exist on the campaign's
+  signal-discovery tabs.
+- Sales Nav: the selected Sales Nav search/filter state must already be attached
+  to the campaign.
+- Prospeo: the selected Prospeo search and any `domainFilterId` must already be
+  attached to the campaign.
+
+If the required campaign-attached state is missing, stop before import and route
+back to find-leads with the same `campaignOfferId`.
+
 If the source file changed after preview, or the existing list is missing or
 wrong-workspace, escalate before materialization. If a supplied-domain search
 returns zero or too few usable people, preserve `domainFilterId` and ask
@@ -54,13 +95,14 @@ Default case — no existing lead list bound to the campaign:
 ```text
 import_leads({
   campaignOfferId,
-  targetLeadCount: <importLimit from auto-execute.yaml; default 25>
+  targetLeadCount: <importLimit from auto-execute.yaml; default 10>
 })
 ```
 
-Provider is inherited from the Phase 84 commit decision (not re-selected
-here). Response returns `{ imported, skipped, duplicates }` — surface all
-three to the escalation logic so dedup ratios are visible.
+Provider is inherited from the selected source decision (not re-selected here)
+and should already be saved on the campaign before import. Response returns
+`{ imported, skipped, duplicates }` — surface all three to the escalation logic
+so dedup ratios are visible.
 
 For supplied direct lists, `confirm_lead_list` must receive
 `targetLeadCount: <importLimit>` or explicit `sourceRowIds` so a 100-row source
@@ -149,7 +191,10 @@ cannot scale further without a new source lane.
 - Zero-imported + zero-skipped ⇒ hard-fail escalate.
 - Zero-imported + high-skipped ⇒ lane-exhausted operator notice (NOT a
   silent proceed).
-- `import_leads` is NOT called in atomic mint. Only in Step 13.
+- `import_leads` is NOT called before rubrics are saved and the approved message
+  set is synced into the campaign brief.
+- Step 13 MUST reuse an approved source already attached with `campaignOfferId`
+  before `import_leads`; it does not replay provider searches.
 - `import_leads` is NOT called again in Step 14 (validate-sample). Full
   cohort import is a Step 13 action, not a recovery action for a bad
   sample.

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

@@ -6,7 +6,11 @@ message direction hold up against real preview evidence.
 
 ## Primary Contract
 
-- `brief.md` is the Phase 83 thesis input
+- CampaignOffer state is canonical; disk artifacts are a debug trail.
+- validation/debug artifacts are not durable campaign state.
+- resume and handoff read campaign state before debug files.
+- `CampaignOffer.campaignBrief` is the durable Phase 83 thesis input;
+  `brief.md` is its debug copy
 - `lead-review.md` and `lead-sample.json` are the required outputs of lead preview
 - `lead-filter.md` is the primary output of the middle step
 - `rubric.json` is optional and secondary
@@ -94,12 +98,13 @@ Required:
 
 Lead preview must:
 
-- use `find-leads` campaignless preview mode
-- avoid `campaignOfferId`
+- use `find-leads` shell-first campaign-attached preview mode
+- pass CampaignOffer campaignId as `campaignOfferId`
 - avoid `import_leads`
-- avoid `selectedLeadListId`
+- do not set `workflowTableId`
 - avoid `confirm_lead_list`
-- avoid DB-backed campaign mutation
+- avoid campaign-table import, workflow-cell queueing, sequence attach, and
+  campaign start
 
 `lead-review.md` must include: