@sellable/mcp 0.1.0

package/skills/create-campaign-v2/references/thomas-variant-selection.md

@@ -0,0 +1,202 @@
+# Thomas Variant Selection
+
+This reference governs which rows in a Plan 85-03 critique sample earn
+an Opus / craft-message rewrite. Load this file only when
+`messaging.critique.enabled === true` AND
+`messaging.critique.opus.enabled === true` in
+`core/auto-execute.yaml`. When Opus is off, the protocol never
+consults variant selection.
+
+## Principle
+
+Opus is reserved for the highest-value subset only. A critique pass
+that sends every row to Opus defeats the cost model and blurs the
+signal about what the plain generator already gets right. Variant
+selection is a narrow filter on top of the bounded critique sample,
+not a second sample.
+
+The rule of thumb: if the plain generator shipped a message that's
+"fine but not sharp" and the lead is unusually high value, Opus
+earns its place. Otherwise, the synthesizer's rewrite is enough.
+
+## When This File Loads
+
+Load this file only when BOTH flags are on:
+
+- `messaging.critique.enabled === true`
+- `messaging.critique.opus.enabled === true`
+
+Do not consult variant selection when Opus is off. Do not consult it
+during Step 13, Step 14, or Step 16.
+
+## Inputs
+
+- The row being critiqued (lead row plus its plain generated message).
+- The three critic envelopes for this row (targeting, copy, voice).
+- `lead-sample.json` for the current cohort.
+- `messaging.critique.opus.*` config values.
+- The current Opus budget headroom (tracked across the pass).
+
+## Hard Caps
+
+Two caps that short-circuit selection before any analysis:
+
+1. **`opus.maxMessagesPerPass`** (default 2). Once N rows have been
+   escalated to Opus in the current pass, every subsequent row falls
+   back to the non-Opus synthesis output regardless of how sharp the
+   selection signals are. Log `opus_cap_tripped` with the row id.
+2. **`opus.budgetUsdCap`** (default 1.5 USD). Budget trip halts Opus
+   for the rest of this pass. Log `opus_budget_cap_tripped`. The
+   non-Opus critique continues on remaining rows.
+
+If either cap is tripped at row N, variant selection short-circuits
+to "no Opus" for rows N+1, N+2, ... of the current pass.
+
+## Selection Signals
+
+A row EARNS Opus only when the signals below point the same way. One
+strong signal is not enough. Three is usually required unless a
+single signal is a hard "buyer of buyers" marker.
+
+### Signal 1 — Lead value tier
+
+The lead row reads as high-value on the validated filter:
+
+- Title matches the buyer role the brief calls out as the primary
+  decision-maker (not an adjacent influencer).
+- Company size / stage matches the brief's ideal band (not merely
+  "in bucket").
+- Company name is a named target account, or a logo the brief
+  treats as a proof marker for this motion.
+
+Not high-value:
+
+- Generic IC title at a bucket-match company.
+- Right function but visibly wrong stage (pre-seed when brief says
+  Series B+).
+- Company that barely passed the filter on a weak supporting rule.
+
+### Signal 2 — Critic divergence toward "revise"
+
+The three critic envelopes disagree about how to fix the plain
+message, and at least two of them have `verdict = "revise"` with
+substantive `revisions[*]`. In other words: the plain message
+clearly has room, and the critics can SEE what's missing — but the
+synthesizer's merge is likely to be a compromise rather than a
+clean rewrite.
+
+Not a divergence signal:
+
+- All three critics said `keep`. The plain message is already good;
+  Opus would over-polish.
+- One critic said `reject` and the other two said `keep`. The
+  rewrite is a fallback case, not a high-value upgrade case.
+- Two critics said `revise` but their revisions point at the same
+  sentence. The synthesizer can merge that cleanly.
+
+### Signal 3 — Personalization upside
+
+The lead row carries a rich per-lead signal that the plain
+generator only partially used:
+
+- A per-lead post, hire, or visible tool the brief supports but the
+  plain opener didn't reference.
+- A named account the brief lists as a named target.
+- An event the brief's proof inventory can anchor to but the plain
+  message settled for a generic hook.
+
+Not personalization upside:
+
+- Plain message already anchored on the per-lead signal.
+- The lead has no per-lead signal; only category-level personalization
+  is available.
+- The richest signal in the row is a field the brief doesn't support
+  (proposing a NEW token — that path is operator review, not Opus).
+
+### Signal 4 — Motion sharpness payoff
+
+The matched motion is one where a crafted rewrite visibly changes
+buyer response (proof-led specialist, stack-replacement, job-post
+signal). Event-led and signal-led motions where the hook is already
+concrete rarely need Opus — the plain generator's hook carries.
+
+Not a sharpness signal:
+
+- Fallback motion with a weak hook. Opus won't rescue a motion-
+  mismatched draft; send it back to the brief instead.
+- Event-led motion where the plain message's opener already nailed
+  the event.
+
+## Selection Rule
+
+A row earns Opus only when:
+
+- At least three of the four signals above point toward high value
+  AND at least one signal is Signal 1 (lead value tier), OR
+- Signal 1 is a hard "named target account or logo-tier buyer" marker,
+  AND at least one other signal is positive.
+
+If neither clause is true, the row uses the non-Opus synthesizer
+output. Log `opus_not_selected` with the row id and the signals
+considered.
+
+## Selection Output
+
+When a row is selected for Opus, the critique protocol:
+
+1. Checks the Opus budget and count caps. If either is tripped,
+   skip Opus for this row (and subsequent rows in this pass) and
+   keep the non-Opus rewrite.
+2. Runs `craft_message(row, synthesis_rewrite, critics_out)`.
+3. Applies the SAME token-contract enforcement to the Opus output
+   that it applies to any synthesis output:
+   - `rejectOnFakeProof` — invented proof forces fallback.
+   - `rejectOnUnsupportedToken` — unsupported token forces fallback.
+   - `synthesis.enforceFinalizerPass` — finalizer pass must pass.
+4. On pass, persists the Opus rewrite for that row. On fail, falls
+   back to the non-Opus rewrite (and if that also failed, to the
+   plain message).
+5. Logs `opus_selected` (with signals) on entry and
+   `opus_rewrite_persisted` / `opus_rewrite_rejected` on exit.
+
+## What Opus Is NOT Allowed To Do
+
+Opus does not get a different token contract. Every rule that binds
+the plain generator and the non-Opus synthesizer binds Opus too:
+
+- Use only supported tokens from the validated brief.
+- No invented metric, logo, customer, funding detail, or product claim.
+- No personalization that can't be traced to `lead-sample.json`.
+- No new proposed token promoted into the persisted rewrite.
+- Same shape rules: one-sentence-per-line body, PS earns its place,
+  no resume-list PS, no jargon a 5th-grade reader can't parse.
+
+An Opus rewrite that breaks any of these is a silent fallback, not
+a win.
+
+## Fallback Priority
+
+When multiple rewrite layers are in play, the persisted message
+follows this priority (first passing wins):
+
+1. Opus rewrite (if selected AND token-contract-clean AND budget
+   available).
+2. Non-Opus synthesis rewrite (if token-contract-clean AND
+   finalizer-clean).
+3. Plain generated message (always a valid fallback).
+
+The plain message is NEVER skipped in favor of a broken rewrite.
+
+## Hard Rules
+
+- Opus is off by default. Variant selection is never consulted when
+  Opus is off.
+- A row earns Opus only when multiple selection signals align. One
+  signal is not enough unless it's a named-target or logo-tier Signal
+  1.
+- `opus.maxMessagesPerPass` and `opus.budgetUsdCap` are hard caps.
+  Once tripped, the rest of the pass runs non-Opus.
+- Opus is bound by the same token contract as the plain generator
+  and the non-Opus synthesizer.
+- Token-contract-clean Opus > non-Opus synthesis > plain message,
+  in that fallback order. Never persist a broken rewrite.

package/skills/create-campaign-v2/references/tier-routing-matrix.md

@@ -0,0 +1,66 @@
+# Tier Routing Matrix
+
+This reference governs `attach_recommended_sequence` routing decisions
+made at Step 16 (`awaiting-user-greenlight`). Load before calling
+`attach_recommended_sequence` and on every resume into Step 16.
+
+## Principle
+
+The sequence template a campaign uses depends on the sender's LinkedIn
+tier. Premium / SalesNav senders have InMail access on open profiles;
+Standard senders do not and must go through invite → accept → DM.
+
+The tail reads the sender's current tier + synced limits (via the
+sender-limits sync path fixed in commit `4002b8878`) and picks the
+right template automatically. Operators can override on the campaign
+builder UI but the autonomous tail default is this matrix.
+
+## Matrix
+
+| Sender tier                         | Template               | Fallback                                  | Notes                                  |
+| ----------------------------------- | ---------------------- | ----------------------------------------- | -------------------------------------- |
+| **Premium InMail**                  | `INMAIL_OPEN`          | `INVITE → DM` if open profile check fails | Direct InMail on open profiles         |
+| **Sales Navigator Core / Advanced** | `INMAIL_OPEN`          | `INVITE → DM` if credit exhausted         | Open profile + InMail credits          |
+| **Sales Navigator Advanced Plus**   | `INMAIL_OPEN`          | `INVITE → DM`                             | Team seat, same InMail path            |
+| **LinkedIn Premium Business**       | `INMAIL_OPEN`          | `INVITE → DM`                             | Personal Premium tier                  |
+| **LinkedIn Standard (no Premium)**  | `INVITE → accept → DM` | (none; must go invite path)               | Cannot send InMail; must connect first |
+
+## Tier detection
+
+Tier is detected via `enrichProfile` on the sender's LinkedIn URL. The
+response includes `liTier` (one of `PREMIUM_INMAIL`, `SALES_NAVIGATOR_CORE`,
+`SALES_NAVIGATOR_ADVANCED`, `SALES_NAVIGATOR_ADVANCED_PLUS`,
+`PREMIUM_BUSINESS`, `STANDARD`). `attach_recommended_sequence` reads
+this value + the sender-limits sync (which triggered post-enrich per
+commit `4002b8878`) to pick the template.
+
+## Why `attach_recommended_sequence` is load-bearing
+
+Without tier-aware routing, the tail would default to a single template
+(historically INVITE → DM) and waste InMail credits on SalesNav senders
+OR try to InMail from a Standard sender (which fails with `not_authorized`
+per Unipile).
+
+Commit `14e4cf59a` shipped the tier routing; commit `4002b8878` fixed
+a race where tier limits drifted from actual limits after `enrichProfile`
+writes. Both are required for the matrix to work reliably.
+
+## Validation before `attach_recommended_sequence`
+
+The tail MUST verify:
+
+1. Sender LinkedIn is enriched within the last 24 hours (fresh tier data).
+2. `syncSenderLimits` has been called since the last `enrichProfile`
+   write (closes the `4002b8878` race window).
+3. The detected tier maps cleanly to one of the template rows above.
+   If tier is `UNKNOWN` or ambiguous, escalate rather than guess.
+
+## Hard rules
+
+- `attach_recommended_sequence` is the only way to pick a template in
+  the autonomous tail. Do NOT hand-wire a sequence at Step 16.
+- Tier mismatch at attach time is an escalation, NOT a silent fallback.
+- A Standard sender MUST NOT be attached to an INMAIL_OPEN template.
+  This would produce sends that fail at Unipile with `not_authorized`.
+- An `attach_recommended_sequence` that returns `template: UNKNOWN`
+  is an escalation — do not proceed to Step 16 greenlight.

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

@@ -0,0 +1,367 @@
+# Validation Criteria
+
+Phase 84 is a chained-artifact validation pass over the Phase 83 brief. The
+goal is to preserve the brief thesis while proving that leads, filters, and
+message direction hold up against real preview evidence.
+
+## Primary Contract
+
+- `brief.md` is the Phase 83 thesis input
+- `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
+- `message-validation.md` is the final validation output
+
+## What Each Step May Change
+
+### Find Leads
+
+Allowed:
+
+- create or replace `lead-review.md`
+- create or replace `lead-sample.json`
+
+Not allowed:
+
+- rewrite the Phase 83 thesis in `brief.md`
+- create `lead-filter.md`
+- create `message-validation.md`
+- mutate campaign state
+
+### Filter Leads
+
+Allowed:
+
+- create or replace `lead-filter.md`
+- create or replace `rubric.json`
+- append `recent_posts[]` arrays to FIT rows in `lead-sample.json` as
+  part of the Post-Filter Signal Enrichment Pass (see `filter-leads.md`
+  — top K=10 FIT rows on Sales Nav lane only, via
+  `mcp__sellable__fetch_linkedin_posts`)
+
+Not allowed:
+
+- replace `lead-review.md` or `lead-sample.json` unless a lead revision was requested
+- create approval packet or commit gate before filter completion
+- rely on more than one optional/supporting filter rule
+- call `check_rubric`
+- call `save_rubrics`
+
+### Generate Message
+
+Allowed:
+
+- create or replace `message-validation.md`
+
+Not allowed:
+
+- run before `lead-review.md` and `lead-sample.json` exist
+- require or infer `campaignId`
+- call `update_cell`
+- call `update_campaign_brief`
+- call `get_rows`
+- call `get_campaign`
+- fetch fresh web or LinkedIn research
+- invent personalization signals that were not validated in `lead-sample.json`
+- widen safe claims beyond `brief.md`
+- leave unresolved `{{token}}`
+- introduce unsupported tokens
+- invent proof, metrics, logos, or customer names
+- skip the dry-mode preamble
+
+Required:
+
+- **Gold-standard skeleton enforcement.** When the brief's Message
+  Thesis says "no greeting / no warm-up", VALIDATE against the
+  gold-standard archive (`references/gold-standard-message-examples.md`).
+  At least one gold example must exist with that opener style. If NONE
+  exists, surface the deviation as a WARNING in `message-validation.md`
+  Findings and require explicit operator confirmation before shipping
+  the candidate. The default opener is `Hey {{first_name}},` on its own
+  line, followed by a blank line and then the first real sentence, unless
+  the brief justifies absence with reference to a specific archived winner.
+  If a candidate uses `two options:`, option `a)` and option `b)` must be
+  separated by a blank line so the CTA scans cleanly on mobile.
+- **All 5 Substance Filters from `thomas-revision-filters.md` MUST
+  PASS per candidate.** A candidate that fails any substance filter
+  (Earned-right, Presumption, Vague-proof, Read-as-1:1, Founder-origin
+  coherence) is BLOCKED. The Finalizer Pass CANNOT select a blocked
+  candidate. If all 3 candidates fail, route to `revise-message` with
+  the failure reasons enumerated per candidate (cite the filter name and
+  the offending line).
+
+## Lead Preview Expectations
+
+Lead preview must:
+
+- use `find-leads` campaignless preview mode
+- avoid `campaignOfferId`
+- avoid `import_leads`
+- avoid `selectedLeadListId`
+- avoid `confirm_lead_list`
+- avoid DB-backed campaign mutation
+
+`lead-review.md` must include:
+
+- status: `confirmed`, `rejected`, or `unclear`
+- confidence
+- provider path used
+- preview count
+- ICP match rate
+- volume comparison
+- expected LinkedIn funnel: likely connection acceptance range, likely reply
+  range, and whether the estimate is sample-backed, historical, founder-supplied,
+  or directional
+- source decision: best path, why it won, pros, cons/tradeoffs, and discarded
+  source paths with the reason each lost
+- false-positive patterns
+- recommendation for `filter leads` or revision
+
+For normal LinkedIn discovery, `lead-review.md` must include literal
+customer-visible headings:
+
+- `## Source Decision`
+- `## Expected LinkedIn Funnel`
+- `## Pros`
+- `## Tradeoffs`
+- `## Discarded Paths`
+
+`## Expected LinkedIn Funnel` must include expected source volume, expected
+usable leads after filtering, likely connection acceptance range, likely reply
+range, and estimate basis. If exact performance data is unavailable, use a
+directional range and label it `directional`, not definitive.
+
+`lead-sample.json` must include enough structured lead data for downstream
+filtering:
+
+- person name
+- title
+- company
+- profile URL when available
+- source provider
+- any visible signals used in the review
+
+## Filter Leads Expectations
+
+Filter leads must treat `lead-filter.md` as the primary artifact.
+
+`lead-filter.md` must include:
+
+- `Status`
+- `Decision`
+- `Who We'll Keep`
+- `Who We'll Exclude`
+- `Sample False Positives`
+- `Pass Rate`
+- `Recommendation`
+- `Implementation Details`
+
+`lead-filter.md` should also include:
+
+- one `Optional Supporting Rule` only when it clearly helps downstream
+  messaging or prioritization
+- technical `Required Keep Rules` and `Required Exclude Rules` only when needed
+  to preserve implementation detail; if present, put them after the
+  user-facing sections
+- explicit notes tying repeated false positives from the sample to the final
+  exclude rules
+
+Filter rules should preserve the recurring campaign families when they are
+relevant to the brief and sample:
+
+- buyer role and seniority
+- wrong-function exclusion
+- company-type exclusion
+- competitor/vendor/intermediary exclusion
+- geography
+- company size
+- active current-role status
+
+`rubric.json`, when present, must be a translation of the same keep/exclude
+rules and not a second scoring framework:
+
+- use the production rubric fields: `checkName`, `description`, `criterion`,
+  `reason`, `isRequiredCheck`, `allowPartialCredit`, and `strictMatching`
+- default all rules to `isRequiredCheck: true`
+- allow at most one `isRequiredCheck: false` supporting rule
+- prefer 2-5 total criteria; do not map every bullet to a separate rubric row
+- include the same 2-5 production-shaped criteria in `lead-filter.md` under
+  `Implementation Details` as fenced JSON even when `rubric.json` is omitted
+- require `Implementation Details` JSON to parse into an object with
+  `leadScoringRubrics`
+- require every criterion to be answerable from row data, enrichment, or public
+  research
+- reject duplicate rules that restate the same idea
+- if the sidecar fails to parse, continue with `lead-filter.md` and block only
+  downstream sidecar consumers until fixed
+
+## Message Validation Expectations
+
+Message validation must run in caller-declared `DRY MODE`.
+
+Inputs:
+
+- `brief.md`
+- `lead-filter.md`
+- `lead-sample.json`
+- `gold-standard-message-examples.md` when `brief.md` lacks a message appendix
+
+`message-validation.md` must include:
+
+- `Status`
+- `Mode: DRY MODE (no DB mutation)`
+- `Template Used`
+- `Primary Example`
+- `Secondary Influence`
+- `Lead Sample Basis`
+- `Strongest Reply Reason`
+- `Pre-Draft Buyer-Role Analysis`
+- `Campaign Element Pool`
+- `Gold Standard Strategy Map`
+- `Current Campaign Translation`
+- `Element Scoring`
+- `Agent Dialogue Cross-Review`
+- `Proof Inventory`
+- `Token Fill Rules`
+- `Token Adherence Table`
+- `Candidate Messages`
+- `Finalizer Pass`
+- `Selected Winner`
+- `Findings`
+- `Recommendation`
+
+The sample set must:
+
+- contain 2-3 sample messages
+- use the find-leads message handoff rows or probable good-fit rows from
+  `lead-sample.json`; if `lead-filter.md` already exists, use only leads that
+  still pass it
+- use only supported tokens documented in the brief
+- contain no unresolved `{{token}}` placeholders
+- resolve every token used in the sample output
+- contain no invented proof, metrics, logos, or customer names
+- keep proof claims inside the brief's safe-claims boundary
+- reject personalization that cannot be traced back to `lead-sample.json`
+- apply Thomas revision filters before the step is marked `confirmed`
+- choose the highest-specificity validated strategy available in this order:
+  event-led, signal-led, job-post-led, then proof-led specialist fallback
+- retrieve against the full archived gold-standard library and choose a
+  Primary Example plus at most one narrow Secondary Influence
+- run an `Agent Dialogue Cross-Review` before drafts survive: skeptical
+  prospect, offer strategist, and gold-standard editor must reconcile to
+  approved elements and banned elements before candidate messages are written
+- **treat the archived examples as the quality bar and motion reference,
+  not a paste source.** Write fresh sentences from the validated brief that
+  could plausibly belong in the archive for this motion
+- exact-template preservation applies **only when the archived winner is the
+  same company as the brief**; otherwise match the motion skeleton without
+  recoloring the exemplar's wording
+- build a proof inventory before drafting and use at least one compelling proof
+  element when the brief supports it
+- document token fill rules before drafting the winner
+- draft 3 candidates, then run a Finalizer Pass that picks the best opener,
+  proof sentence, bridge, and CTA across them and assembles the winner
+- the winner entry must name which candidate each borrowed piece came from,
+  or declare that one candidate swept the Finalizer Pass (with the winning
+  axis named)
+- write at a 5th-grade reading level by default. Jargon is limited to
+  brief-native product and tool names (e.g. Shopify, HubSpot, ServiceNow).
+  Cut glue language — any B2B compound noun the buyer wouldn't say naturally
+  in conversation — even when the brief uses it
+- Casing must look intentional. Lowercase casual style is allowed for common
+  words when the chosen motion uses it, but proper nouns, recipient names,
+  company names, product names, acronyms, and the pronoun `I` stay capitalized.
+  Do not output broken casing like `i'm`, `futureclinic`, or `michael`
+- higher reading levels are only allowed when the archived winner for this
+  motion is the **same company as the brief** and uses denser language
+  deliberately (e.g. Superposition drafting for Superposition). Lowercase-casual
+  motions still read at a plain level and should not be flattened into
+  polished prose
+- put a blank line between every sentence in the body, so the body renders
+  as a sequence of one-line paragraphs separated by blank lines — not as
+  multi-sentence paragraphs. Target 5-8 one-line paragraphs total
+- split sentences that are above ~15 words or carry more than one comma
+- do not stack three workflows into one mechanism line or one comma list.
+  Give each workflow its own one-sentence paragraph, or pick the most
+  painful one and drop the others
+- **product clarity is non-negotiable**: a cold reader must be able to state
+  in one sentence what the product does. Require a crisp `Product is an X
+that does Y` anchor sentence before any action breakdown, then one action
+  per one-line paragraph. Do not gesture at "that chain" / "the stack" /
+  "that work" in place of naming specific actions
+- body flow must follow: opener → pain → what the product IS (one sentence)
+  → what it DOES (one action per line, up to three) → deployment ease →
+  CTA → optional PS
+- the "what it DOES" action list may render as one-line paragraphs or as a
+  bullet list — whichever reads cleaner. Bullets are acceptable here (the
+  rule against bullet points applies to feature/benefit marketing lists,
+  not to enumerable product actions). Never comma-stack three actions into
+  one glued sentence
+- **opener must use per-lead signal when any is present in `lead-sample.json`**
+  (post, hire, visible tool, topic engagement). Category-level openers are
+  acceptable only as fallback when the sample carries zero per-lead signal.
+  Fallback category openers must be flagged explicitly in Findings with a
+  recommendation to surface signals upstream
+- keep the body tight: one proof sentence, one useful CTA, no vague meeting ask
+- avoid generic walkthrough CTAs like `reply if you want a quick walkthrough`
+  unless the line names the useful thing the buyer will see or get
+- the PS is optional. Only include it if it materially strengthens the fit
+  case for this buyer. Drop the PS if the best available proof would just
+  add noise
+- when a PS is included, it must answer "why is this a fit for me?", not
+  "here are our credentials." Never drop a bare first name like "Chris"
+  with no anchor. Use "I" voice if the sender is the founder; "our CEO",
+  "our team", or "we" otherwise. At most two proof beats. No three-credential
+  resume lists
+- samples in one set must read like siblings from one campaign, not three
+  experiments
+- reject fallback drafts that lead with generic "most teams..." copy without a
+  concrete workflow anchor
+- reject fallback drafts that open with synthesized "X means you're likely..."
+  or "at your stage" framing
+- reject drafts that default to a lead magnet, report, brief, teardown,
+  video, or "send it over" CTA when the brief never said that asset exists
+- reject drafts that use a `PS` above the CTA or in the middle of the body
+- reject drafts that omit stronger safe proof already present in the brief
+- avoid em dashes unless the chosen Primary Example uses them
+
+When message validation fails because sourcing is weak:
+
+- revise token fill rules
+- or revise the filter
+- or revise the message thesis
+
+Do not invent a stronger signal just to save the copy.
+
+`Template Used` must name the actual strategy being validated, not just a vague
+theme:
+
+- `event-led canonical template`
+- `signal-led canonical template`
+- `job-post-led canonical template`
+- `proof-led specialist fallback`
+
+If `brief.md` includes a message appendix, worked example, or interpolation
+guidance, the sample messages should follow that structure closely. Otherwise,
+the system should synthesize the structure from the closest archived winner.
+Proof-led specialist fallback is only acceptable when no stronger validated
+hook exists.
+
+`Primary Example` should name the archived winner providing the structure.
+`Secondary Influence` should be `none` or name one narrow influence only.
+
+## Stop Conditions
+
+- `brief.md` missing
+- provider/auth/quota error during preview
+- zero usable leads from preview
+- sample too small to judge
+- required upstream artifact missing for the next step
+- `lead-filter.md` missing required keep/exclude sections
+- more than one optional/supporting rule proposed
+- `message-validation.md` missing the dry-mode preamble
+- any sample message contains unresolved or unsupported tokens
+- any sample message contains invented proof or unsupported personalization
+
+When a stop condition is hit, surface the reason in the relevant artifact and
+do not attempt to mint live campaign state.