@sellable/mcp 0.1.0

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

@@ -0,0 +1,495 @@
+# Filter Leads
+
+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.
+
+The business goal is not "find people who might reply." It is "every reply the
+user gets should come from someone who is in the ICP and has a realistic path
+to buying." A lead who may reply but cannot buy, lacks budget, sits at the wrong
+account type, is a vendor/competitor, or is on the wrong side of a marketplace
+is not a good lead.
+
+Inputs:
+
+- `brief.md`
+- `lead-review.md`
+- `lead-sample.json`
+
+Outputs:
+
+- `lead-filter.md`
+- optional `rubric.json`
+
+Core constraint:
+
+- Every accepted filter in `lead-filter.md` must be directly translatable into
+  the production `LeadScoringRubric` shape. If a filter cannot become a
+  runnable rubric criterion from available row data or public research, it is
+  not an accepted filter; convert it to an optional enrichment note, a user
+  tradeoff, or a lead-source revision reason.
+
+## Evaluation Data Scope
+
+Do not write final filters that depend on the limited fields visible in the
+source-provider preview card. Sales Nav cards, Prospeo rows, and Signals rows
+are sampling evidence, not the full data contract.
+
+Production rubrics should describe what we will decide after normal enrichment
+and public research have run. For example:
+
+- Good: "Keep US-licensed MD/DO dermatologists; verify credentials from the
+  enriched LinkedIn profile, professional bio, NPI/state-license page, or other
+  public source."
+- Bad: "Exclude rows missing MD/DO on the Sales Nav card."
+
+If a preview row lacks enough evidence to prove a required rule, mark it as
+`needs enrichment` or `borderline pending verification` in sample findings. Do
+not turn preview-card missingness into a hard production exclusion unless the
+same missing field will remain missing after enrichment.
+
+## Primary Goal
+
+Use the actual sample to answer:
+
+- was the Step 2 projected-good-fit estimate basically right or wrong
+- which leads clearly match the buyer hypothesis
+- which leads are noise
+- which repeated false positives must become explicit exclusions
+- whether filters are enough, or whether the source lane would make the
+  campaign miss if launched as-is
+- whether the filtered leads are economically worth sending to, using the best
+  campaign-native proxy available from row data, enrichment, or Googleable facts
+
+## Standard Competitor / Vendor Exclusion
+
+Every confirmed filter should include a competitor / vendor / wrong-side
+exclusion unless the brief and sample make it clearly irrelevant. This is a
+standard production safety rule, not an optional nice-to-have.
+
+Use this simple test:
+
+- Would this company, product, service provider, agency, consultant, reseller,
+  or marketplace participant appear on the same comparison page as the client?
+- Would they compete for the same customer budget, sell into the same buyer
+  workflow, or sit on the wrong side of the marketplace?
+- Did the sample show adjacent companies that a client would likely reject only
+  after seeing the list?
+
+If yes, add an explicit exclude rule. Include named competitors from the brief,
+sample, or user context when available, plus the general category exclusion so
+new lookalike competitors are also blocked. If a competitor/vendor exclusion is
+omitted, `lead-filter.md` must say why it is not applicable.
+
+Treat this as part of the manual review loop. When the user or client sees a
+sample and says "these companies are not a fit," update the exclusion watchlist
+and filter draft before Step 4. Use `confirm-with-user` when the sample contains
+ambiguous adjacent vendors, competitors, agencies, marketplace-side conflicts,
+or reseller/consultant roles where excluding them would materially shrink the
+lane.
+
+## `lead-filter.md` Shape
+
+````md
+# Lead Filter
+
+Status: confirmed | confirm-with-user | revise-find-leads
+
+## Decision
+
+- continue | confirm with user | revise find-leads
+- one plain-English sentence saying why
+
+## Who We'll Keep
+
+- ...
+
+## Who We'll Exclude
+
+- ...
+
+## Sample False Positives
+
+- ...
+
+## Optional Supporting Rule
+
+- omit this section unless exactly one supporting rule materially helps messaging or prioritization
+
+## Pass Rate
+
+- ...
+
+## Recommendation
+
+- proceed to generate message
+- or revise leads / revise filter
+
+## Implementation Details
+
+If `Status: confirmed`, include production rubrics:
+
+```json
+{
+  "leadScoringRubrics": [
+    {
+      "checkName": "role_fit",
+      "description": "Lead holds one of the validated buyer titles.",
+      "criterion": "Yes if the current title matches one of the accepted buyer titles. No if the title is a wrong-function, junior, advisory-only, or service-provider title.",
+      "reason": "The campaign only works when the recipient owns the buyer problem and can act on the offer.",
+      "isRequiredCheck": true,
+      "allowPartialCredit": false,
+      "strictMatching": false
+    },
+    {
+      "checkName": "company_fit",
+      "description": "Lead works at a company type validated by the sample.",
+      "criterion": "Yes if the current company matches the accepted account type from the brief and sample. No if the company is a vendor, agency, competitor, or structurally wrong account type.",
+      "reason": "The message thesis depends on this company context being true.",
+      "isRequiredCheck": true,
+      "allowPartialCredit": false,
+      "strictMatching": false
+    }
+  ]
+}
+```
+
+If `Status: confirm-with-user` or `Status: revise-find-leads`, do not include
+production rubrics yet. Explain why the draft filter is not locked downstream.
+
+## Required Keep Rules
+
+- technical source rules, if different from the plain-English keep list
+
+## Required Exclude Rules
+
+- technical source rules, if different from the plain-English exclude list
+````
+
+Rules:
+
+- `Decision` is mandatory and must appear before filter details
+- default to `Status: confirmed` when the source lane is viable and filters are
+  enough to protect the campaign
+- use `confirm-with-user` only when the lane is viable but there is a real
+  strategic tradeoff the user must choose before launch
+- use `revise-find-leads` only when filters would be so heavy, low-volume, or
+  thesis-distorting that launching from this lane would likely miss
+- always emit a readable draft filter, even when status is `confirm-with-user`
+  or `revise-find-leads`, so the user can inspect and edit the AI's definition
+  of a good fit
+- `Who We'll Keep` and `Who We'll Exclude` are mandatory user-facing sections
+- `Required Keep Rules` and `Required Exclude Rules` are allowed as technical
+  source sections, but should appear after `Implementation Details` if present
+- `Sample False Positives` must be grounded in observed sample leads
+- `Optional Supporting Rule` is allowed only when one rule clearly helps later
+  messaging or prioritization
+- never emit more than one optional/non-required rule
+- `Implementation Details` is mandatory for every status
+- `Implementation Details` must contain one fenced JSON object with
+  `leadScoringRubrics` only when `Status: confirmed`
+- non-confirmed filters are draft/user-review artifacts, not official Step 4
+  inputs
+- `leadScoringRubrics` must contain 2-5 production-shaped rubric items, not one
+  item per bullet
+- do not put source-path mechanics or send-priority hints into
+  `leadScoringRubrics`. Examples: recently posted on LinkedIn, came from a
+  Signals search, appeared in Sales Nav, was found by Prospeo, first-send wave,
+  or priority cohort. If that signal was already used in the search, mention it
+  in `Pass Rate` or `Recommendation`; if it is useful but not required, keep it
+  as prose under `Optional Supporting Rule`, not as a production rubric.
+- do not put DNC or one-off relationship-safety notes into
+  `leadScoringRubrics` unless the sample shows that family is likely to leak at
+  meaningful volume and normal DNC/domain suppression will not catch it. Former
+  employers, existing customers, investors, partner lists, and "do not contact"
+  domains usually belong in `Recommendation` or a DNC note, not in ICP scoring.
+- confirmed `leadScoringRubrics` must protect sales quality, not just surface
+  similarity. They should usually cover:
+  - buyer authority / role fit
+  - account or company-type fit
+  - economic capacity / ability to buy, using a campaign-native proxy such as
+    headcount, revenue, funding, practice size, location count, patient volume,
+    department maturity, existing tooling, or budget-owner title
+  - geography / market, when relevant
+  - active-current-role safety
+  - hard exclusions for competitors, vendors, agencies, job seekers,
+    wrong-function leads, and wrong-side marketplace participants
+- confirmed `leadScoringRubrics` should include a competitor / vendor /
+  wrong-side exclusion by default. It can be bundled with account-fit only when
+  the criterion still names both the accepted account type and the excluded
+  competitor/vendor/wrong-side categories.
+- when one production rubric bundles multiple families, the criterion must say
+  exactly which buyer-quality gates it covers
+- if the filter cannot be compiled into 2-5 production rubric items, do not
+  confirm; return `confirm-with-user` or `revise-find-leads`
+- hide raw rubric flags from the top user-facing sections; keep
+  `isRequiredCheck`, `allowPartialCredit`, and `strictMatching` inside
+  `Implementation Details`
+
+## Rule Families To Preserve
+
+When relevant to the brief and sample, preserve these recurring families:
+
+- buyer role / seniority
+- wrong-function exclusions
+- company-type exclusions
+- competitor / vendor / intermediary exclusions
+- geography
+- company size
+- active current-role status
+
+## Sample-Judging Method
+
+For each proposed rule:
+
+1. inspect matching and failing sample leads
+2. decide whether the rule removes real noise or blocks real buyers
+3. mark the rule as necessary, loosen, or remove
+4. record the resulting pass rate
+
+Repeated false positives should become explicit exclude rules whenever the same
+pattern appears more than once in the sample.
+
+## `rubric.json` Sidecar
+
+Only emit a sidecar when a downstream step needs a separate file. The same
+production-shaped items must always appear as fenced JSON in `lead-filter.md`
+under `## Implementation Details`, even when `rubric.json` is omitted.
+
+Shape:
+
+```json
+{
+  "leadScoringRubrics": [
+    {
+      "checkName": "role_fit",
+      "description": "Lead holds one of the validated buyer titles.",
+      "criterion": "Yes if the current title matches one of the accepted buyer titles. No if the title is a wrong-function, junior, advisory-only, or service-provider title.",
+      "reason": "The campaign only works when the recipient owns the buyer problem and can act on the offer.",
+      "isRequiredCheck": true,
+      "allowPartialCredit": false,
+      "strictMatching": false
+    }
+  ]
+}
+```
+
+Rules:
+
+- derive every sidecar rule from `lead-filter.md`
+- default every rule to `isRequiredCheck: true`
+- allow at most one `isRequiredCheck: false` rule
+- do not add a rule that is not present in `lead-filter.md`
+- do not duplicate two rules that restate the same keep/exclude idea
+- use the production fields exactly: `checkName`, `description`, `criterion`,
+  `reason`, `isRequiredCheck`, `allowPartialCredit`, and `strictMatching`
+- prefer 2-5 rubric criteria total; do not map every keep/exclude bullet into
+  its own scoring row
+- production rubric criteria should be buyer-quality gates, not execution
+  metadata. Do not create rubric rows for provider source, recently-posted
+  priority, first-send ordering, or other search mechanics unless the user
+  explicitly asks to score that as part of ICP fit.
+- production rubric criteria should not become one-off DNC lists. Named-company
+  exclusions are appropriate when they represent a repeated false-positive
+  category, a true competitor class, or a material lane risk; otherwise preserve
+  them as DNC/suppression instructions outside the rubric JSON.
+- do not write "these rules are expressible as rubrics" as a substitute for the
+  actual 2-5 item draft
+- bundle repeated false positives into a single exclusion criterion when they
+  are the same kind of failure, for example vendors / competitors /
+  wrong-side providers
+- keep title / role fit as its own explicit criterion with concrete pass and
+  fail title patterns
+- use `allowPartialCredit: false` for hard gates where ambiguity should fail
+- use `strictMatching: true` only when the rule depends on exact named-account
+  or exact-token matching
+
+Recommended rubric grouping:
+
+- buyer authority / role fit
+- company / industry / provider-lane fit
+- economic capacity / ability to buy
+- geography / size / stage fit, when relevant
+- competitor / vendor / wrong-side / repeated false-positive exclusion
+- one optional buyer-quality signal, at most, only when it changes fit scoring
+  rather than send ordering
+
+Rubric-readiness checklist:
+
+- Can this rule be evaluated from `lead-sample.json`, provider row fields,
+  enrichment, or normal public research?
+- Does the criterion say both what passes and what fails?
+- Is the reason a business rationale, not a restatement of the criterion?
+- Would `save_rubrics` accept this without adding missing fields?
+- Would `evaluate-icp-fit-enriched` have enough prospect-side data or
+  Googleable facts to score it?
+
+## Prohibited During Phase 84
+
+- calling `check_rubric`
+- calling `save_rubrics`
+- using campaign-backed rubric tools
+- creating a second independent rubric design
+- blocking Phase 84 when only `rubric.json` fails and `lead-filter.md` is valid
+
+## Marketplace safety rail (two-sided archetypes)
+
+When brief §14 declares a marketplace with an explicit forbidden
+side-of-market (e.g. Skillsync forbids cold-outbound to supply-side
+GitHub contributors; the indexed pool is NEVER the outbound target),
+the lead-filter MUST include a forbidden-role exclude rule naming the
+supply-side title family.
+
+### Enforcement at filter-write time
+
+- `lead-filter.md` Required Exclude Rules MUST contain at least one
+  rule pattern-matching the forbidden side's title family (e.g.
+  "exclude 'Software Engineer' / 'Staff Engineer' / GitHub
+  contributor profile signal for Skillsync-like marketplaces").
+- If brief §14 declares the marketplace but the filter does NOT include
+  the forbidden-side exclude rule, surface this as a `revise-rubric`
+  precondition failure. Do NOT proceed to the commit gate.
+
+### Enforcement at validate-sample time
+
+- The Plan 85-02 validate-sample loop treats `>20% of sample rows
+matching the brief §14 forbidden side` as a **LIST problem** (not a
+  brief problem). Rationale: the sourced list is contaminated with
+  the wrong side of the marketplace; operator must re-source.
+- Detection signal: row title/profile matches the supply-side family
+  declared in brief §14, even if the title whitelist at §5 ICP
+  accidentally allows it.
+
+### Why this matters
+
+Marketplaces are the only B2B archetype where the same LinkedIn pool
+contains both the intended buyer and the forbidden counterparty. A
+marketplace operator who accidentally drafts InMail to a supply-side
+contributor has simultaneously:
+
+1. Violated their own TOS with that contributor (cold InMail for a
+   non-applied-to "hiring" pitch).
+2. Leaked their own product positioning (we target engineers,
+   implying we sell you as a vendor).
+3. Poisoned the cohort's recall rate for real demand-side buyers.
+
+A filter-spec safety rail catches the drift BEFORE Step 13 import.
+A validate-sample signal catches the drift if it still slips through.
+
+Plan 95-07 surfaced this residual on the Skillsync walkthrough; Plan
+95-08 ships the rail.
+
+## Post-Filter Signal Enrichment Pass (Sales Nav lane)
+
+After `lead-filter.md` lands and the Pass Rate is recorded, run a bounded
+signal-enrichment pass on FIT rows whose primary lane is Sales Nav and
+whose `lead-sample.json` entry has `recent_posts.length === 0` (the
+Sales Nav lane does not carry post data natively).
+
+This pass directly addresses the Earned-right + Read-as-1:1 substance
+filters in Phase 84. Without row-level post data, the generator has
+nothing to quote back, forcing either (a) category-level openers that
+trip Read-as-1:1, or (b) presumption-led openers that trip Earned-right.
+
+Contract:
+
+- **Scope:** only FIT rows (or the top K rows when FIT count > K).
+- **Budget cap K:** top 10 FIT rows by score. Do NOT enrich MAYBE or
+  REJECT rows in Phase 84 — they are not headed to messaging.
+- **Tool:** `mcp__sellable__fetch_linkedin_posts` (per-row call). If the
+  tool is unavailable in the current harness, skip the pass entirely
+  and document in Findings.
+- **Fetch:** the most recent 3-5 posts per row.
+- **Append to `lead-sample.json`:** each enriched row gets a
+  `recent_posts[]` array with `{ url, posted_at, excerpt }` entries
+  (200 char excerpt cap per post).
+- **Rows with zero public posts:** keep `recent_posts: []`. This is
+  valid data — the absence signals "quiet-profile row, use trigger or
+  peer-observation angle instead".
+- **Order of operations:** run AFTER `lead-filter.md` is written, BEFORE
+  `message-validation.md` starts drafting. The enriched
+  `lead-sample.json` is the input to the per-row signal extraction pass
+  in the generator.
+
+Findings update:
+
+- Record enrichment outcome at the bottom of `lead-filter.md` under a
+  new `## Signal Enrichment` heading: rows attempted, rows with posts,
+  rows with zero posts, tool failures.
+- If more than 50% of enriched rows have zero posts, flag the sample as
+  "low signal density" and recommend the generator's peer-observation
+  fallback angle with the Findings-surface warning.
+
+This pass does NOT apply to:
+
+- Signals-lane rows (already carry post data natively)
+- Prospeo-lane rows (messaging is usually event/job-post-led, post
+  data is secondary)
+- live-campaign mode (enrichment happens per-row during Research)
+
+## Brief-Validated Rewrite Authority
+
+When `lead-review.md` shows that the Phase-83 primary lead-source picked an
+UNVALIDATED lane (no source-material support) AND the alternative source
+yields ≥ 5× FIT leads in the same sample, `brief-validated.md` may rewrite
+exactly two Phase-83 brief sections:
+
+- §3 Campaign Thesis — update the source-hypothesis line to reflect the
+  higher-yielding lane as primary.
+- §12 Next Steps — update the first lead-search step to start on the
+  higher-yielding lane.
+
+Every rewrite must include an evidence citation block quoting
+`lead-review.md`:
+
+```md
+> Evidence (from lead-review.md):
+>
+> - Signals sample: 2 rows, 0 FIT
+> - Sales Nav sample: 25 rows, 3 FIT + 7 MAYBE
+> - Primary-lane reversal: Sales Nav ≥ 5× Signals FIT yield in the same
+>   preview.
+```
+
+All OTHER Phase-83 brief sections remain read-only during Phase-84. This
+authority is narrowly scoped to one specific failure mode — UNVALIDATED
+primary-source picks contradicted by real preview data. It is NOT a general
+brief-rewrite license. Do not use it to rewrite ICP, Buyer Pain, Offer
+Strategy, Social Proof, Differentiators, Message Thesis, or any other
+section. Those deltas continue to flow through `lead-filter.md` and
+`message-validation.md` as today.
+
+If the evidence is ambiguous (e.g. 2 FIT Signals vs 4 FIT Sales Nav — under
+5× ratio), DO NOT rewrite. Flag the weak preference in `lead-filter.md`
+§ Recommendation instead.
+
+## Provider-lane expected FIT density
+
+Observed during Phase 94 + Phase 95 UAT. Use as anchor for judging whether
+a lane is "lane exhausted" (see `references/step-13-import-leads.md`) or
+genuinely weak.
+
+| Lane                                       | Typical FIT density | Archetype examples                                           |
+| ------------------------------------------ | ------------------- | ------------------------------------------------------------ |
+| **Prospeo** (vertical SMB)                 | 60-80%              | Patientdesk (dental practice owners); vertical B2C-style SMB |
+| **Sales Nav** (horizontal enterprise)      | 40-55%              | Ambral (enterprise CS); Skillsync (eng-led companies)        |
+| **Sales Nav** (dev tools / specific infra) | 30-45%              | IncidentFox (SRE/Platform leaders at Series B-D SaaS)        |
+| **Signals** (overlay — warm-scored)        | 20-35%              | Overlay added to any lane; rate depends on topical density   |
+
+Interpretation:
+
+- **Density at the high end of the band** — fresh lane; import cap should
+  be aggressive (bump importLimit from 100 default to 200+ if needed).
+- **Density below the band** — either the filter is too tight OR the lane
+  is approaching exhaustion (most good rows already imported in prior runs).
+  Check dedup ratios to distinguish.
+- **Density dramatically below band** — likely a brief problem (ICP too
+  narrow) or a provider-side issue. Diagnose before reruning.
+
+Plan 95-05 Patientdesk observed ~70% FIT density on Prospeo (top of band).
+Plan 95-03 Ambral observed ~47% on Sales Nav horizontal enterprise (mid band).
+Plan 95-01 IncidentFox observed ~36% on Sales Nav dev-infra (mid-low band).
+Plan 94-07 Skillsync observed ~32% on Signals (mid band for overlay).
+
+Use these as regression anchors: a 10%+ drop from the archetype's
+historical density on a lane = investigate before escalating to operator.

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

@@ -0,0 +1,176 @@
+# Final Handoff Contract
+
+This reference governs Step 16 (`awaiting-user-greenlight`) of the Plan
+85-02 autonomous tail — the moment where the skill stops running
+autonomously and waits for the user to decide whether to start the
+campaign. Load this file before entering Step 16 and on every resume into
+`awaiting-user-greenlight`.
+
+## Principle
+
+The autonomous tail NEVER calls `start_campaign` on its own. The final
+start is always a user decision. There are two equally valid channels for
+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.
+
+## 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
+   `references/watch-link-handoff.md`.
+3. 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`.
+
+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 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)
+
+When `lead-source-intake.json` exists, also answer:
+
+- which source was materialized (`supplied-linkedin-profiles`,
+  `supplied-domains`, or `existing-lead-list`)
+- how many rows/accounts were supplied
+- how many rows were imported into the first review batch
+- that only the first review batch was enriched and messaged before
+  greenlight, not the full supplied list
+- for `existing-lead-list`, that the source list was reused, not recreated
+
+Use the exact state name `awaiting-user-greenlight` so logs and UX artifacts
+can verify the stop point, but explain it in normal words: the campaign is
+built and waiting for the user's final start decision.
+
+The skill waits. It does not poll. A fresh continuation turn arrives
+either because the user said something in chat (Claude greenlight path)
+or because `get_campaign` / polling determined the user clicked Start in
+the UI.
+
+## Dual Greenlight Channels
+
+### 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.
+
+No skill involvement. The skill remains idle in
+`awaiting-user-greenlight`. On the next resume, the skill observes
+`CampaignOffer.status === "running"` (or equivalent) and shifts to a
+"campaign is live" confirmation without calling `start_campaign` again.
+
+### Claude greenlight path
+
+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
+   `POST /api/v3/workflow-tables/cells/approve-batch` with
+   `{ tableId }`.
+   - This is the SAME server action the UI "Approve all" button uses
+     (`src/components/outbound-builder/canvas/WorkflowTablesCanvas.tsx`
+     calls `/api/v3/workflow-tables/cells/approve-batch`).
+   - Do NOT invent a new tool or endpoint. Do NOT bypass this call by
+     directly updating cells — the endpoint handles downstream
+     scheduling via `CellOrchestrator.reprocessColumn`.
+   - 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
+   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"
+   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
+surfaces the recoverable state and stops — it does NOT attempt to
+unapprove (that would be destructive) and it does NOT silently retry
+forever.
+
+## Already-Running No-Op
+
+A Claude greenlight on an already-running campaign is a no-op
+confirmation, NOT a duplicate start. Detect this at the top of the
+greenlight path:
+
+1. Call `get_campaign({ campaignId })` (or whatever lightweight state
+   fetch is available).
+2. If the campaign is already running (status === "running" /
+   `currentStep === "running"`), skip all three mutating steps and
+   return a confirmation message: "Campaign is already live — here's
+   the watch link again."
+3. Do NOT call `start_campaign` again. Do NOT call approve-batch
+   again. Do NOT update `currentStep`.
+
+The symmetric UI case is handled by the UI itself — the UI button
+disables once the campaign is running.
+
+## Workspace + Sender Invariant
+
+Before calling `start_campaign` via the Claude greenlight path,
+re-validate the workspace/sender invariants Phase 84 committed against.
+If the current auth context no longer matches (workspace switched mid
+session, sender removed, etc.), abort the start with the same invariant
+error Phase 84 uses. Do NOT start a campaign from the wrong workspace.
+
+## Pre-Start State Guards
+
+Refuse the start and surface the reason if any of the following are
+true:
+
+- Campaign is in a failed/paused state that needs operator attention
+  (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
+  campaign).
+
+A refusal is NOT an escalation in the ladder sense — it's a pre-check
+failure. Surface the specific reason so the user can fix it and say
+"start" again.
+
+## Atomicity Contract
+
+"Atomic" here means: from the user's perspective, saying "yeah start"
+either produces a running campaign with approved messages, OR produces
+an explicit error state with NO silent half-state. It does NOT mean a
+database transaction — approve-batch and start_campaign are separate
+calls — it means the skill treats the trio as a single unit and does
+not leave the user guessing which step half-succeeded.
+
+If approve-batch partially succeeds (e.g. `approved: 50, failed: 3`),
+the skill surfaces the partial result and asks the user whether to
+proceed with start_campaign anyway or investigate the 3 failures. It
+does NOT silently proceed.
+
+## Hard Rules
+
+- The autonomous tail NEVER calls `start_campaign` on its own.
+- Step 16 NEVER auto-advances past `awaiting-user-greenlight` without a
+  user signal.
+- 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.
+- A Claude greenlight on an already-running campaign is a no-op
+  confirmation, not a duplicate start.
+- Workspace/sender mismatch at greenlight time aborts the start with
+  the Phase 84 invariant.
+- 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).