@sellable/mcp 0.1.0

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

@@ -0,0 +1,1619 @@
+---
+name: create-campaign-v2
+description: Execute the JSON-gated from-scratch campaign flow: create the brief, validate chained Phase 84 artifacts, then atomically mint a live campaign after explicit user approval at the commit gate.
+visibility: internal
+---
+
+# Create Campaign v2
+
+<role>
+You are the create-campaign-v2 orchestrator. Your job is to execute the
+configured `core/flow.v2.json` state machine from scratch: (1) interview the
+user and create `brief-v1`, (2) validate the chained Phase 84 draft artifacts,
+(3) run a message-review gate, show the user an approval packet and commit
+gate, and (4) if the user
+approves, atomically mint a real `CampaignOffer` and hand off to the bounded
+review-batch tail (Plan 85-02).
+</role>
+
+<objective>
+Run the configured JSON flow in durable stages:
+
+0. create-campaign-brief
+1. find leads
+2. filter leads
+3. generate message
+4. message review gate
+5. approval packet + commit gate
+6. atomic mint
+7. review-batch tail to `awaiting-user-greenlight`
+
+The JSON flow is the source of truth for stage order, `requiredArtifacts`,
+`producesArtifacts`, `allowedTools`, `doNotAllow`, `waitFor`, and
+`transitions`. This prompt explains how to execute those gates; it does not
+replace them.
+
+Each stage writes its own artifact into the draft directory before the next
+stage starts. `brief-v1.md` is the customer-facing brief output; `brief.md` is
+the canonical downstream campaign thesis input.
+
+After validation artifacts are complete, show the user a commit gate with 6
+choices (approve / revise-brief / revise-leads / revise-rubric /
+revise-messaging / abort). Only `approve` triggers DB mutation. On `approve`,
+atomically mint the campaign (`create_campaign` + `save_rubrics`), capture the
+`watchUrl` from the `create_campaign` response, and surface it to the user only
+after both tool calls succeed.
+</objective>
+
+<files>
+
+Validated draft directory:
+
+```text
+.sellable/create-campaign-v2/drafts/{workspace-slug}/{campaign-slug}/
+  brief-v1.md
+  brief.md
+  lead-review.md
+  lead-sample.json
+  lead-filter.md
+  message-prep.md   # optional speed artifact
+  message-candidate-drafts.md   # optional provisional message artifact
+  message-validation.md
+  message-review.md
+  message-review-decision.md
+  rubric.json   # optional implementation artifact only
+  approval-packet.md
+  customer-roleplay.md
+  commit-gate-decision.md
+```
+
+</files>
+
+<rules>
+
+- Net-new runs start at `bootstrap` -> `brief-interview` in
+  `core/flow.v2.json`. Do not start at `validate-artifacts` unless resuming a
+  compatibility run where all upstream artifacts already exist.
+- Fast Intake Mode is mandatory for hosted/rehearsal net-new runs. Ask the
+  first founder strategy/source question packet in under 60 seconds. Before
+  that first packet, the first assistant turn may only call
+  `bootstrap_create_campaign`, load this workflow prompt with
+  `get_subskill_prompt({ subskillName: "create-campaign-v2" })`, optionally run
+  one lightweight identity lookup, then call `AskUserQuestion`. If the user
+  supplied a company website/domain, call exactly one of `fetch_company`,
+  `WebFetch`, or `WebSearch` to identify what the company actually does before
+  generating intake options. If the user supplied a LinkedIn profile URL, call
+  `fetch_linkedin_profile` before generating intake options. Do not infer the
+  product category from the company name alone. If no domain, website, or
+  LinkedIn profile is supplied, use neutral/custom intake options rather than
+  guessed vertical-specific options. Before the first AskUserQuestion, do not run
+  sender research, `list_senders`, source discovery, Sales Nav, Prospeo,
+  Signals, Bash, Read, Write, Edit, Glob, Grep, full company research, or
+  draft-directory inspection/creation. Do draft-directory setup only after the
+  founder answers. The first intake packet must ask buyer, offer/CTA, proof, and
+  lead source, and all four questions must include an `Other / custom` option.
+- After the founder answers the first strategy/source packet, explain the next
+  stage only: campaign brief creation and brief approval. Use this shape:
+
+  ```text
+  Got it. I'll turn this into a campaign brief first (~1-2 min), then show it to you so you can approve it or tell me what to change before I source leads.
+  ```
+
+  Do not mention internal artifact names in this preamble.
+
+- After rendering the brief summary, ask for brief approval when there is a real
+  strategic choice or the user has not already made the direction obvious. The
+  user-facing choice should be approve/revise language, not "looks good".
+- After the brief is approved or auto-confirmed, show the next progress line:
+  `Cool. Now I'm going to find people who are both a good fit and likely to
+reply on LinkedIn. I'll compare source paths by expected volume, likely
+connection acceptance rate, likely reply rate, signal quality, and tradeoffs.
+This usually takes ~3-5 min, and I'll show you the source decision + sample
+before anything goes live.`
+- After the lead sample/source decision is ready and approved or auto-confirmed,
+  show the next progress line:
+  `Lead source is set. Now I'll do two things from this sample: apply the fit
+filter to clean the list down to great fits, and draft the first message we
+should test for this campaign. Those can run in parallel and usually take
+~2-3 min.`
+- During long post-intake work, show concise progress checkpoints before the
+  next expensive stage: source being checked, source switch/tradeoff if any,
+  lead sample usable, filter/message drafting, and full message prompt loading.
+  Each checkpoint should include a rough remaining time when useful.
+- In hosted/rehearsal runs, `Bash` is only for safe local draft-directory
+  housekeeping before approval: `mkdir`, `ls`, `find`, `test`, `pwd`, `echo`,
+  `cat`, or copying `brief-v1.md` to `brief.md` inside the repo. Do not use
+  Bash to run interpreters/scripts (`python`, `node`, `npm`, `pnpm`, `yarn`,
+  `npx`), call APIs, query databases, inspect prompt dumps, run git, or
+  synthesize artifact content. Use `Read`/`Write`/`Edit` for artifact files and
+  MCP tools for product actions.
+- `brief-v1.md` is the user-facing brief. `brief.md` is the stable downstream
+  input and remains the thesis source.
+- `lead-review.md` and `lead-sample.json` are the required outputs of `find leads`.
+- `lead-filter.md` is the primary output of `filter leads`.
+- `rubric.json` is optional and secondary to `lead-filter.md`.
+- `message-prep.md` is an optional speed artifact produced by the explicit
+  message path after find-leads. It can prepare proof inventory, buyer
+  objections, CTA options, gold-standard strategy maps, and candidate angles
+  from `brief.md`, `lead-review.md`, and `lead-sample.json`.
+- `message-candidate-drafts.md` is an optional provisional speed artifact from
+  sample rows that already look like probable good fits. It can contain rough
+  candidate messages and element tests, but it cannot select the final winner
+  and cannot override `lead-filter.md`.
+- `message-validation.md` is the normal output of `generate message`.
+- `message-review.md` and `message-review-decision.md` are the mandatory
+  message quality gate outputs between `message-validation.md` and
+  `approval-packet.md`.
+- Run the dependency chain as a DAG: `create-campaign-brief` -> `find leads`;
+  once `lead-review.md` and `lead-sample.json` exist, run `filter leads` and
+  the explicit `generate message` validation as parallel branches from the same
+  basis (`brief.md`, `lead-review.md`, `lead-sample.json`). Approval waits for
+  both `lead-filter.md` and `message-validation.md`, then reconciles that the
+  selected message basis rows still pass the final filter.
+- Never run a downstream stage until the active `flow.v2.json` step's
+  `requiredArtifacts` exist.
+- Never call a tool outside the active step's `allowedTools`, and never call a
+  tool listed in the active step's `doNotAllow`.
+- Before the user chooses `approve`, the mutating live-campaign tools are
+  forbidden: `create_campaign`, `save_rubrics`, `import_leads`,
+  `confirm_lead_list`, `update_campaign`, `queue_cells`, and `start_campaign`.
+- Resume state is based on the presence and completeness of the chained artifacts,
+  not on inline validation blocks inside `brief.md`.
+- Preserve the Phase 83 thesis. Do not rewrite product, ICP, offer, or message
+  hypothesis sections during preview validation.
+- Exception: brief-validated may rewrite §3 Campaign Thesis AND §12 Next Steps
+  when Phase-84 lead-yield data clearly contradicts a Phase-83 UNVALIDATED
+  decision on primary lead-source. "Clearly contradicts" = the Phase-83
+  primary source yields 0 FIT while an alternative source yields ≥ 5 FIT in
+  the same ~25-row sample (or an equivalent ≥ 5× ratio at larger samples).
+  Every rewrite MUST cite specific yield numbers from `lead-review.md`. All
+  other Phase-83 brief sections remain read-only. See
+  `references/filter-leads.md` § Brief-Validated Rewrite Authority for the
+  full evidence shape.
+- Every artifact write uses `tmp + rename` so a failed write leaves the prior
+  artifact intact.
+- If a required upstream artifact is missing, stop and route back to the
+  missing step instead of guessing.
+- Before asking for commit approval, persist a customer-facing
+  `message-review.md` and `message-review-decision.md` so the message
+  approval decision can be inspected later.
+- Before asking for commit approval, persist a customer-facing
+  `approval-packet.md` so the exact packet can be inspected later.
+- Persist `customer-roleplay.md` when a customer/operator roleplay critique is
+  run. This critique can recommend a decision, but it can never authorize mint.
+- Persist `commit-gate-decision.md` with exactly one of the six gate choices.
+  Only an explicit `approve` value in this decision artifact authorizes DB
+  mutation.
+
+</rules>
+
+<conditional_gates>
+
+There are two human gates:
+
+- `message-review` is the mandatory pre-packet message quality gate. It asks
+  only whether to proceed with the selected message (`approve-message`) or run
+  one more messaging revision (`revise-messaging`). It does not authorize DB
+  mutation.
+- The commit gate is the only mandatory user approval before DB mutation.
+  Earlier artifact gates are interrupt-only unless this contract explicitly
+  names the `message-review` gate.
+
+Auto-continue without `AskUserQuestion` when the artifact says `Status:
+confirmed` (or equivalent), confidence is high/medium, volume is viable, and
+there is no strategic tradeoff.
+
+Ask the user only when one of these is true:
+
+- `Status` is rejected, unclear, revise-find-leads, revise-filter, or
+  confirm-with-user.
+- Projected usable leads are below the campaign floor for the market, or the
+  sample pass rate suggests heavy filtering will make the campaign miss.
+- The source path contradicts the brief, removes the buyer segment that made
+  the campaign compelling, or proves the provider is matching titles but not
+  actual buyers.
+- Filter rules are not production-rubric-translatable from row data, enrichment,
+  or normal public research.
+- Message validation has a blocking skeptical-prospect issue, no selected
+  winner, weak token plan, or a recommendation to revise. Even when it is
+  confirmed, render the `message-review` gate before creating the approval
+  packet so the founder can approve or revise the message deliberately.
+
+When asking subjective strategy questions (buyer scope, first ask, proof
+emphasis, tone, lead-source preference), always make it clear the user can give
+a custom answer. Add an explicit `Other / custom` option to each subjective
+question. Do not rely on prose like "you can add detail" as the only custom
+path. Do not add custom options to the final six-choice commit gate.
+Use customer-facing question wording:
+
+- target prospects: `Who should be the target prospects for this campaign? Pick one or combine.`
+- main CTA / offer: `What should the main CTA or offer be? Pick one or combine.`
+- proof emphasis: `Which proof point would most increase this buyer's confidence in {{company}}? Multi-select fine.`
+- lead source: `How should we get the people for this campaign?`
+
+Ask the lead-source question as the last question in the first strategy
+batch, after buyer, offer/ask, and proof/safety are understood. Frame supplied
+lists as optional, not required. The three visible options are exactly:
+
+1. `Find people for me (recommended if you don't already have your own list)`
+2. `I have a CSV of LinkedIn profiles`
+3. `I have a CSV of company domains`
+
+Keep `Other / custom` available for freeform answers such as a pasted list,
+an existing Sellable lead list, or another source idea. Do not put existing
+Sellable lead lists in the main three-option first batch; support them through
+custom/freeform input. If the user pastes up to 100 LinkedIn profile URLs or
+company domains, normalize the paste into a temporary local CSV and continue
+through the matching CSV preview path. Mixed, ambiguous, malformed, or oversized
+pastes should ask for a real CSV file instead of guessing.
+
+Avoid internal wording like `Which proof points should the message be allowed
+to lean on?` because it describes the artifact, not the founder decision.
+
+When auto-continuing, show one concise progress line and immediately continue.
+Do not create a review question whose only useful answer is "looks good".
+
+</conditional_gates>
+
+<step_contracts>
+
+## Step 1: Find Leads
+
+Use existing `find-leads` campaignless preview behavior to validate ICP and
+volume with a real sample.
+
+Write:
+
+- `lead-review.md`
+- `lead-sample.json`
+- optional `lead-source-intake.json` when the user intentionally supplied a
+  source
+
+Required behavior:
+
+- use campaignless preview mode
+- do not pass `campaignOfferId` (Step 1 only — this is the one place
+  where campaignless is the right choice; every post-mint provider
+  search — Prospeo, Sales Nav, Apollo, Signal Discovery, or any
+  future provider — MUST include `campaignOfferId` so the search
+  persists to the campaign and shows up in the UI's Contact Search
+  tab. Omitting `campaignOfferId` after mint orphans the search.)
+- do not import leads
+- do not set `selectedLeadListId`
+- do not create lead-list rows
+- do not mutate DB-backed campaign state
+- run a parallel source scout when the source is not supplied, but choose the
+  lanes from the sourcing approach rather than running every provider by
+  default. For Signals-first campaigns, search multiple Signals keyword lanes
+  and fetch top-post engagers in parallel. For Sales Nav-first or
+  Prospeo/account-first campaigns, run multiple preview lanes for that provider
+  in parallel and use Signals only as a warmth/quality check when relevant
+- for Signals-first campaigns, raw post search volume is only inventory, not
+  lead volume. `492 post results` means matching LinkedIn posts found across
+  keyword lanes; it does not mean 492 prospects. The source decision must name
+  the actual posts we would use, show why they won, and estimate usable engagers
+  from those posts after headline/sample filtering
+- Signals source decisions should prefer fresh posts. Default to posts from the
+  last 30 days, prefer the last 7-14 days when quality is comparable, and call
+  out any older post as a deliberate tradeoff. Do not hide post age inside the
+  raw search count
+- default source quality target is 300-500+ likely usable leads; accept
+  150-300 only for an explicit beta/design-partner motion and name that
+  volume tradeoff in `lead-review.md` and the approval packet
+- if `lead-source-intake.json` is present, read `sourceType`,
+  `sourceInputMode`, file path or existing lead-list ID, selected columns,
+  confirmation token, normalized counts, and any preview-created
+  `domainFilterId`
+- supplied LinkedIn profile CSVs call `load_csv_linkedin_leads` in preview mode
+  only before approval; do not pass `confirmed: true`, `campaignOfferId`,
+  `currentStep`, `leadListId`, `sourceLeadListId`, or provider-import params
+- supplied company/domain CSVs call `load_csv_domains`; pre-approval
+  confirmation is allowed only without `campaignOfferId` or `currentStep` and
+  only to produce a standalone `domainFilterId` for campaignless
+  account-constrained people sampling
+- existing Sellable lead lists skip provider discovery and sample from the
+  existing rows before approval; do not clone/import the list until after
+  approval
+- do not call `save_domain_filters` in the pre-approval create-campaign path
+
+`lead-review.md` must state:
+
+- validation status: `confirmed`, `rejected`, or `unclear`
+- confidence
+- provider path used
+- supplied source type when applicable (`normal-discovery`,
+  `supplied-linkedin-profiles`, `supplied-domains`, or `existing-lead-list`)
+- row/domain counts, invalid counts, duplicate counts, and sample method for
+  supplied sources
+- 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
+- for Signals-first paths: top candidate posts reviewed, selected post URLs,
+  post author, post topic/excerpt, post age or posted date, engagement count,
+  sampled engager count per selected post, sampled fit count per selected post,
+  estimated usable engagers per selected post, and why each selected post is
+  better than discarded posts
+- source decision: best path, why it won, pros, cons/tradeoffs, and discarded
+  source paths with the reason each lost
+- repeated false-positive patterns
+- message handoff: 2-5 sample rows that look like strong/probable good fits,
+  with row identifiers and the reason each is safe enough for message thinking
+- suggested next action or revision
+
+For normal LinkedIn discovery, `lead-review.md` must include these
+customer-visible sections with literal headings:
+
+- `## Source Decision`
+- `## Selected Signal Posts` for Signals-first campaigns
+- `## Expected LinkedIn Funnel`
+- `## Sample Leads` for Signals-first campaigns
+- `## Pros`
+- `## Tradeoffs`
+- `## Discarded Paths`
+
+For Signals-first campaigns, `## Selected Signal Posts` must include a compact
+table with one row per selected or finalist post:
+
+- post URL
+- post author
+- posted date or recency
+- topic/excerpt
+- total engagement or estimated engagers
+- sampled engagers
+- sampled fits
+- estimated usable leads
+- why use / why discard
+
+For Signals-first campaigns, `## Sample Leads` must group representative sample
+rows by source post when possible, so the user can see not just that the search
+found posts, but which posts produce believable prospects.
+
+`## 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.
+
+When showing `lead-review.md` to the user, render the customer-visible sections
+inline. Do not compress it to a short summary or artifact links only. The
+visible response must include `## Source Decision`, `## Expected LinkedIn
+Funnel`, `## Pros`, `## Tradeoffs`, and `## Discarded Paths`. For
+Signals-first campaigns it must also include `## Selected Signal Posts` and
+`## Sample Leads`.
+
+For supplied profile CSVs and existing lead lists, `lead-review.md` must not
+describe a generic TAM estimate or pretend the rows came from Sales Nav/Prospeo
+discovery. For supplied domain/account lists, explain that domains are account
+constraints and include the actual people sampled from those accounts. If the
+domain-constrained people sample returns zero or too few usable rows, route to
+`revise-leads` / `confirm-with-user`; never silently remove the domain
+constraint.
+
+`lead-sample.json` must be a machine-readable sample that downstream filter
+validation can inspect directly.
+
+If preview returns zero usable leads, write the rejection evidence, stop the
+chain, and route to `revise-leads`.
+
+## Step 2: Filter Leads
+
+Read `brief.md`, `lead-review.md`, and `lead-sample.json`.
+
+This branch can run in parallel with Step 3 once `lead-review.md` and
+`lead-sample.json` exist. It owns lead quality and production rubrics only.
+
+Write:
+
+- `lead-filter.md`
+- optional `rubric.json`
+
+Required behavior:
+
+- preserve recurring keep/exclude filter families that show up across campaign
+  history: buyer role, wrong-function exclusions, company-type exclusions,
+  competitor/vendor exclusions, geography, company size, and active-role status
+- use the actual lead sample to identify repeated false positives
+- prefer required keep/exclude rules over a broad scoring stack
+- allow at most one optional/supporting rule when it materially helps later
+  messaging or prioritization
+- judge each proposed rule against the sample, report pass rate, and call out
+  whether the rule is truly necessary or should be removed
+- make every accepted filter directly translatable into production
+  `LeadScoringRubric` rows (`checkName`, `description`, `criterion`, `reason`,
+  `isRequiredCheck`, `allowPartialCredit`, `strictMatching`)
+- do not accept a filter that cannot be evaluated from `lead-sample.json`,
+  provider row fields, enrichment, or normal public research
+- derive `rubric.json` from the final `lead-filter.md` rules only when a
+  machine-readable sidecar is needed downstream
+- continue with `lead-filter.md` as the source of truth when `rubric.json`
+  cannot be written or parsed
+- if `rubric.json` is omitted, keep the filter concise enough that a 2-5 item
+  production rubric can be compiled from it without inventing new rules
+- write `lead-filter.md` user-facing first: decision, who we keep, who we
+  exclude, what the sample showed, pass rate, recommendation
+- include `Implementation Details` inside `lead-filter.md` whenever the status
+  is confirmed; this is where production rubric fields belong
+- `Implementation Details` must be a fenced JSON object with
+  `leadScoringRubrics` so downstream can parse/save the rules without
+  inference
+- do not write message artifacts from the filter path; filter-leads owns lead
+  quality and production rubrics only
+
+`lead-filter.md` must contain:
+
+- `Status`
+- `Decision`
+- `Who We'll Keep`
+- `Who We'll Exclude`
+- `Sample False Positives`
+- `Optional Supporting Rule` only when one is clearly justified
+- `Pass Rate`
+- `Recommendation`
+- `Implementation Details`
+
+When `rubric.json` is emitted, it must use the production rubric shape, not a
+custom sidecar schema:
+
+- `leadScoringRubrics`
+- `checkName`
+- `description`
+- `criterion`
+- `reason`
+- `isRequiredCheck`
+- `allowPartialCredit`
+- `strictMatching`
+
+`Implementation Details` must contain a fenced JSON object with
+`leadScoringRubrics`, and that array must contain 2-5 production rubric items
+total. Do not create one rubric row per keep/exclude bullet. Bundle related
+false-positive families into one exclusion criterion, and keep role fit as its
+own explicit criterion. Keep raw rubric flags out of the top user-facing
+sections.
+
+Do not:
+
+- call `check_rubric`
+- call `save_rubrics`
+- create a second independent scoring design in `rubric.json`
+- emit more than one optional/supporting rule
+
+## Step 3: Generate Message
+
+Read `brief.md`, `lead-review.md`, `lead-sample.json`, optional
+`lead-filter.md`, optional `message-prep.md`, and optional
+`message-candidate-drafts.md`.
+
+This branch can run in parallel with Step 2 once `lead-review.md` and
+`lead-sample.json` exist. If `lead-filter.md` is not ready yet, draft from the
+lead-review message handoff rows, then reconcile after the filter lands.
+
+Write:
+
+- `message-validation.md`
+
+Run the `generate-messages` skill in caller-declared `DRY MODE`. Its SKILL.md
+holds the full drafting contract (retrieval, proof inventory, candidates,
+finalizer pass, voice rules, safety). This step only covers orchestration.
+This is not optional: before any write to `message-validation.md`,
+`message-review.md`, `approval-packet.md`, or a commit-gate question, the current run must load the
+full `generate-messages` prompt. In hosted/from-scratch runs, load it with
+chunked `get_subskill_prompt({ subskillName: "generate-messages", offset,
+limit })` calls so every tool result stays small enough for the streamed
+harness. Start with `offset: 0, limit: 12000`, then keep calling with
+`offset: nextOffset` until `hasMore` is false.
+In Codex-hosted runs, this is a quality gate, not just provenance: if the
+model cannot retrieve the complete prompt or cannot follow the required
+gold-standard deliberation flow, stop at `message-review` and ask for
+`revise-messaging`. Do not mint the campaign to compensate for weak copy.
+Do not hand-write `message-validation.md` from `message-prep.md` or
+`message-candidate-drafts.md`. Those files are planning inputs only; the final
+message-validation artifact must come from the actual `generate-messages`
+prompt path (`get_message_prompt` / `generate-messages`).
+
+Orchestration requirements:
+
+- start once real leads exist: `brief.md`, `lead-review.md`, and
+  `lead-sample.json` are enough to run generate-message
+- use only the find-leads message handoff rows as basis examples, e.g.
+  "prospects 1, 5, and 6 are solid enough to think from"
+- if `lead-filter.md` is ready, use it; if it arrives after message drafting,
+  reconcile before approval and rerun or revise messaging if the selected
+  winner depended on rows that fail the final filter
+- never write `message-validation.md`, render a message review, render an
+  approval packet, or ask the commit gate until 100% of the real
+  `generate-messages` prompt has been read
+- before `message-review` can recommend `approve-message`, verify
+  `message-validation.md` contains the full generate-messages shape:
+  `Gold Standard Strategy Map`, `Proof Inventory`, `Token Fill Rules`,
+  `Token Adherence Table`, `Angle Drafts`, `Kill / Combine Review`,
+  `Finalists`, `Finalizer Pass`, `Gold-Standard Quality Gate`,
+  `Skeptical Prospect Review`, `Winner Gate`, and a raw sendable
+  `Selected Winner`. If any are missing, recommend `revise-messaging` and do
+  not continue to approval or mint.
+- pass no `campaignId`
+- read only `brief.md`, `lead-review.md`, `lead-sample.json`, optional
+  `lead-filter.md`, and the `gold-standard-*` references. If
+  `message-prep.md` exists, use it as a
+  planning cache instead of redoing the same element inventory from scratch. If
+  `message-candidate-drafts.md` exists, use it as provisional draft input only
+  after checking its basis rows against the completed `lead-filter.md`, when
+  available.
+- generate 2-3 sample messages inline
+- start output with `Mode: DRY MODE (no DB mutation)`
+- treat the archived examples as the **quality bar**, not a paste source;
+  write messages that could plausibly belong in the archive for this motion
+- exact-template preservation only applies when the archived winner is the
+  same company as the brief
+- draft 3 internal candidates and run a Finalizer Pass that combines the
+  best opener, proof sentence, bridge, and CTA across them into one winner
+- if all finalists use the same first substantive line, treat the opener
+  test as failed; compare materially different opener jobs before selecting
+  a winner, or route to `revise-message`
+- the Finalizer Pass must block adjacent repeated copy. Do not let a pain
+  line and mechanism line reuse the same noun stack unless the second line
+  adds plainly new buyer value. Merge, translate, bullet, or cut instead.
+- the selected winner subject/body must not contain semicolons.
+- the selected winner subject must not be generic category copy like
+  `first LinkedIn campaign`, `quick question`, `outbound`, or `intro`. Prefer the
+  original gold-standard A + B + C subject shape: a concrete row/company token
+  plus a concrete workflow/object plus the offer/result, for example
+  `{{company}} + LinkedIn outbound + Claude/Codex` or
+  `{{source_post_topic}} + active leads + first message test`. Keep it short,
+  buyer-native, and free of abstract category nouns.
+- A + B + C is a quality shape, not permission to stuff tokens into the
+  subject. The subject must pique buyer interest and name a buyer-relevant
+  problem, workflow, or useful artifact. Do not use sender names, founder names,
+  "Austin's review", "founder call", "demo", "quick call", or similar
+  sender-centered language in the subject. Do not use a row token in the subject
+  unless the filled version is natural, lowercase/common-word where appropriate,
+  and more interesting than the non-tokenized version.
+- the selected winner must not contain sender-intro fragments like
+  `Usama here`, `derm here`, `board-cert derm here`, `[credential] here`,
+  or `[role] at [company] here`.
+- the selected winner must not use generic signal tokens such as
+  `{{recentSignal}}`, `{{recent_signal}}`, or `{{recent_signal_quote}}`.
+  Row personalization must use concrete enriched-row fields such as
+  `{{post_context}}`, `{{comment_summary}}`, `{{profile_summary}}`,
+  `{{source_post_topic}}`, `{{headline}}`, or `{{row_proof_note}}`, and it
+  must avoid source-citation phrases like `caught my eye`.
+- do not default to founder-to-founder, MD-to-MD, doctor-to-doctor,
+  peer-call, compare-notes, or similar identity-call CTA framing unless
+  the user explicitly selected that route or the brief makes it the
+  approved offer. Even then, the CTA must name the useful return artifact,
+  preview, teardown, or working session.
+- if the message is selling or introducing a product, the selected winner
+  must make the product plain before asking for time, but the opener must
+  not sound like homepage copy. A line shaped like `[Product] is a
+[category] platform -- feature, feature, feature` is blocked when it reads
+  like product copy instead of a human note. For command-native products,
+  describe the buyer job (`launch a LinkedIn campaign from Claude/Codex`)
+  before category nouns like `platform` or `MCP`.
+- pass the Thomas revision filters before writing findings
+- immediately after `message-validation.md` is confirmed and reconciled with
+  `lead-filter.md`, write `message-review.md` and render it inline starting
+  with `Status: message-review` as the first visible line. Do not put a
+  markdown heading, preface, or summary before that status line. This is a
+  customer checkpoint, not an audit report: show the approved campaign message
+  template first, then show rendered examples that prove the tokens fill well
+  and can be omitted cleanly when row data is weak. Keep the detailed
+  gold-standard/rule audit inside `message-validation.md`, not in the
+  user-facing review. The review must use this exact label shape so the gate can
+  be parsed: `Subject: ...`, `Message: ...`, `Rendered examples: ...`,
+  `Good token fill: ...`, `Good omit: ...`, `Token notes: ...`,
+  `My take: ...`, `Suggested adjustment: ...`,
+  `Question: approve-message or revise-messaging?`, `Recommendation:
+approve-message|revise-messaging`.
+- `My take:` and `Suggested adjustment:` are mandatory customer-facing decision
+  fields, not optional summary text. They must appear after `Token notes:` and
+  before the question in every rendered message review. They must each be
+  non-empty, specific to the current message, and useful for one last manual
+  feedback pass. Never render a message review that jumps straight from token
+  notes to `Question:` or `Recommendation:`.
+- `Message:` in `message-review.md` must be a tokenized template with supported
+  enriched-row tokens such as `{{first_name}}`, `{{company}}`,
+  `{{workflow_context}}`, `{{headline}}`, `{{source_post_topic}}`, or
+  `{{row_proof_note}}`. It must not be a one-row-only raw sample. It must
+  include at least one literal `{{...}}` token. Keep only tokens that future
+  enriched rows can actually fill or safely omit. If you cannot produce a
+  tokenized template from supported enriched-row fields, stop with
+  `Recommendation: revise-messaging`.
+- `{{profile_signal}}` is never a supported customer-facing token. It is an
+  internal enrichment label and must not appear in `Subject:`, `Message:`,
+  rendered examples, `Token notes:`, `message-validation.md` selected copy, or
+  `approval-packet.md`. If a profile-derived signal matters, translate it into
+  a buyer-readable derived token with a clear fill rule, such as
+  `{{workflow_context}}` or `{{row_proof_note}}`; otherwise omit the line.
+- `Rendered examples:` must include at least one `Good token fill:` rendered
+  message where the row has a clean signal and one `Good omit:` rendered message
+  where an optional token line is omitted instead of forced. Each example must
+  be a complete rendered subject + body, not a bullet list of token names or a
+  single bridge-line fragment. Do not use bracketed instructions, deferred row
+  notes, or phrases like `approve the selected winner above`.
+- rendered examples may only use token values that exist in `lead-sample.json`,
+  `lead-review.md`, `lead-filter.md`, or the selected winner's documented
+  supported-token plan. Do not invent example values to make the template look
+  better. If a token is absent, weak, or not a supported enriched-row field,
+  show the `Good omit:` version instead of filling it.
+- token casing must look intentional. Keep proper nouns, recipient names,
+  company names, product names, acronyms, and the pronoun `I` capitalized in
+  both the template examples and rendered output. Casual lowercase is allowed
+  only for static common words when the chosen message voice uses it. Do not
+  lowercase token values or invent transform syntax like `{{company_lower}}`,
+  `{{first_name | lower}}`, or bracketed casing instructions.
+- Token usage must be intelligent, not decorative. If a tokenized opener reads
+  like mail merge (`Reaching out because {{reporting_context}} sits in...`,
+  `your {{role_context}} work`, `saw your {{topic}}`, or similar), rewrite the
+  base line so the token either sounds like a natural noun phrase or is omitted.
+  Prefer row-derived tokens that change the reply reason; otherwise use a clean
+  segment-level line and document why the row token is omitted.
+- founder/sender names should not be used as the hook. Mention a founder name
+  only when the buyer already has a reason to care about that person or when the
+  user explicitly wants named-founder branding. In normal first-touch copy,
+  frame the CTA around the useful return artifact (`map one reporting problem`,
+  `review one dashboard`, `pressure-test one workflow`) instead of "call with
+  Austin" or another founder-name CTA.
+- message-review hard-fail preflight: before rendering `Status: message-review`,
+  scan the subject, tokenized template, good-fill example, good-omit example,
+  `My take`, `Suggested adjustment`, and recommendation. If any of them contain
+  `felt close enough to send`, `close enough to send`,
+  `thought this was relevant enough`, `seemed close
+enough`, `{{profile_signal}}`, `profile signal`, `is why I thought this might
+  be relevant`, `Austin's`, a sender/founder name in the subject, a one-row raw
+  sample under `Message:`, rendered examples without full copy, a
+  mail-merge-sounding tokenized opener, missing or empty `My take:`, missing or
+  empty `Suggested adjustment:`, `My take:` that only says `looks good`,
+  `strong`, or `approved`, `Suggested adjustment:` that only says `none`, or no
+  literal `{{...}}` token in `Message:`, revise the message before showing it.
+  Do not output
+  `Recommendation: approve-message` when any hard-fail preflight item is
+  present.
+- `My take` must be 1-3 short bullets or sentences, focused on what a founder
+  needs to decide: approve as-is, revise once, make it shorter, make it more
+  specific, change proof, change CTA, or preserve the current length because
+  cutting would remove reply reason. If a shorter version is recommended,
+  `Suggested adjustment` must say exactly what to remove or compress. Do not
+  include a long `What works`, `Gold-standard/rule check`, or internal checklist
+  in this checkpoint.
+- `Suggested adjustment` must give the founder a concrete final-edit option even
+  when the recommendation is `approve-message`. Use a useful shape like
+  `Approve as-is, or revise once to [specific edit] if you want [effect]`. It
+  must invite the user to give manual feedback before minting, for example:
+  `Reply revise-messaging with the exact line change, proof change, CTA change,
+or tone feedback you want before I build the approval packet.` Do not write
+  `none`.
+- if the message is merely plausible, generic, template-shaped, or weaker than
+  the loaded gold-standard examples, set `Recommendation: revise-messaging`.
+  The next Codex UAT goal is to prove message quality before mint, so no
+  approval packet or campaign mutation should happen just because the mechanics
+  are working.
+- immediately after rendering `message-review.md`, call `AskUserQuestion` with
+  exactly two choices, in this order: `approve-message`, `revise-messaging`.
+  Stop after the question. Do not write `approval-packet.md`,
+  `customer-roleplay.md`, or a commit-gate question until
+  `message-review-decision.md` contains `approve-message`.
+- if the selected winner or PS uses named customer/logo proof, quantified proof,
+  team credentials, or investor/accelerator proof that is not explicitly
+  supported by `brief.md`, `lead-review.md`, `lead-sample.json`, or loaded
+  reference material, the review must set `Recommendation: revise-messaging`.
+  Do not approve speculative credibility claims.
+- if the selected winner or PS uses vague proof wrappers like `spoken publicly
+about`, `publicly talked about`, `trusted by`, `worked with`, `used by`, or
+  bare customer-logo lists without naming a concrete buyer-relevant result,
+  mechanism, or risk reducer, the review must set `Recommendation:
+revise-messaging`. Supported logos are not automatically body-worthy proof.
+  Translate to a concrete proof line or omit the proof from the message.
+- if customer/logo proof is useful mainly for credibility, prefer a concise PS
+  over interrupting the body. The PS must name what the customers used the
+  product/service for, not just list logos. If the body already carries buyer
+  pain, mechanism, and CTA clearly, adding concrete social proof in the PS is
+  allowed when it lowers vendor risk.
+- the selected winner or PS must not use internal labels like `p.s. relevant
+proof:`, `p.s. useful proof:`, `p.s. proof:`, or `p.s. social proof:`.
+  Rewrite as a natural aside before asking the user to approve.
+- if the user chooses `revise-messaging`, write `message-review-decision.md`
+  with `revise-messaging`, preserve upstream artifacts, delete/regenerate
+  only `message-validation.md`, `message-review.md`,
+  `message-review-decision.md`, `customer-roleplay.md`, and
+  `approval-packet.md`, then rerun this message step.
+- after `message-review-decision.md` contains `approve-message`, write
+  `approval-packet.md` in customer-facing order and render the same approval
+  packet inline before the commit gate. The approval packet and six-choice
+  commit question must appear in the same customer-visible turn. Do not emit a
+  standalone commit-gate question. Include a clear `## Message Review` section
+  inside the approval packet before `## Approved Message Template`. It should
+  summarize the customer checkpoint from `message-review.md` and preserve the
+  same literal `My take:`, `Suggested adjustment:`, and `Recommendation:`
+  labels.
+- if `message-validation.md` contains an extractable `Selected Winner`, use
+  that exact winner as the `## Approved Message Template` in
+  `approval-packet.md` and in the campaign brief passed to `create_campaign`.
+  Only substitute concrete enriched-prospect-row `{{tokens}}`; do not rewrite
+  the copy inline at approval time. Do not use abstract slot tokens like
+  `{{hookLine}}`, `{{painLine}}`, `{{productLine}}`, `{{closeLine}}`, or
+  `{{psLine}}`, and do not use `{{recent_signal_quote}}`; use fields that exist
+  on the enriched prospect row instead.
+- the live body under `## Approved Message Template` must be sender-ready copy.
+  Do not include bracketed instruction placeholders such as `[ROW BRIDGE ...]`,
+  `[insert ...]`, `[generated ...]`, or prose that tells a later step to
+  paraphrase/fill a line. Put per-row generation rules in `### Token Fill Rules`
+  with concrete enriched-row fields, or route to `revise-messaging`.
+- `message-validation.md` must not call the winner a canonical template or
+  hide per-row generation in bracketed body text. `## Selected Winner` must
+  be a real sendable message that could be approved as-is.
+- block awkward bridge phrasing like `felt close enough to send this`,
+  `thought this was relevant enough`, or `seemed close enough`. Replace with a
+  crisp row-backed bridge using a buyer-readable row-derived token, such as
+  `That {{workflow_context}} work is where teams usually need cleaner reporting
+ownership.` If the signal is weak or absent, omit the bridge line entirely.
+- if subject, tokenized template, or rendered examples do not meet the bar,
+  `message-review.md` must recommend `revise-messaging`, not `approve-message`.
+
+Do not:
+
+- call `get_campaign`
+- call `get_rows`
+- call `update_cell`
+- call `update_campaign_brief`
+- fetch fresh web or LinkedIn research
+- mutate DB-backed campaign state
+
+`message-validation.md` must contain:
+
+- `Status`
+- `Mode`
+- `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`
+- `Proof Inventory`
+- `Token Fill Rules`
+- `Token Adherence Table`
+- `Angle Drafts`
+- `Kill / Combine Review`
+- `Finalists`
+- `Candidate Messages`
+- `Finalizer Pass`
+- `Gold-Standard Quality Gate`
+- `Skeptical Prospect Review`
+- `Winner Gate`
+- `Selected Winner`
+- `Findings`
+- `Recommendation`
+
+`approval-packet.md` must contain:
+
+- campaign direction
+- lead source and sample
+- filters and rubrics
+- selected message(s)
+- `## Message Review` with literal `My take:`, `Suggested adjustment:`, and
+  `Recommendation:` (`approve-message` or `revise-messaging`). If the message
+  is only okay, say so plainly so the user can choose `revise-messaging` at the
+  commit gate.
+- `## Approved Message Template`; when `message-validation.md` has a selected
+  winner, this section must preserve that selected winner rather than a newly
+  drafted approval-template variant
+- risks / caveats
+- next action: the six-choice commit gate
+
+`message-review.md` must contain:
+
+- `Status: message-review`
+- `Subject:` using the approved tokenized A + B + C subject shape
+- `Message:` followed by the tokenized approved message template
+- `Rendered examples:`
+- `Good token fill:` with a complete concrete rendered subject + body
+- `Good omit:` with a complete concrete rendered subject + body where optional
+  row signal is omitted cleanly
+- `Token notes:` naming which tokens are safe to fill, which optional token line
+  should be omitted when absent, and whether the message uses standard sentence
+  case or casual lowercase static words
+- `My take:`
+- `Suggested adjustment:` with a concrete final-edit option and explicit
+  invitation to give manual feedback before approval
+- `Question: approve-message or revise-messaging?`
+- `Recommendation:` exactly `approve-message` or `revise-messaging`
+- The two-choice `AskUserQuestion` immediately after the rendered review
+
+`message-review-decision.md` must contain exactly one selected route:
+`approve-message` or `revise-messaging`. It does not authorize DB mutation.
+
+If token sourcing is weak, revise token fill rules or route back to
+`revise-filter` or `revise-message` instead of guessing.
+
+</step_contracts>
+
+<resume_rules>
+
+Phase 84 validation resume:
+
+- No `brief-v1.md` / `brief.md` present -> run `create-campaign-brief`
+- `brief-v1.md` present but no `brief.md` -> copy `brief-v1.md` to `brief.md`,
+  then run `find leads`
+- Only `brief.md` present -> compatibility resume: run `find leads`
+- `lead-review.md` + `lead-sample.json` present, but no `lead-filter.md` and
+  no `message-validation.md` -> run `filter leads` and `generate message`
+  from the same find-leads basis; do not ask the user between them when
+  lead-review is confirmed
+- `lead-review.md` + `lead-sample.json` present, but no `lead-filter.md` -> run
+  `filter leads`
+- `lead-review.md` + `lead-sample.json` present, but no
+  `message-validation.md` -> run `generate message`
+- `lead-filter.md` + `message-validation.md` present -> reconcile message
+  basis rows against the final filter, then write/render `message-review.md`
+  and ask the two-choice message review gate
+- `message-validation.md` present but no `message-review-decision.md` -> write
+  `message-review.md`, render it inline starting with `Status:
+message-review`, then ask `approve-message` vs `revise-messaging`
+- `message-review-decision.md` contains `revise-messaging` -> preserve
+  upstream artifacts; delete only `message-validation.md`,
+  `message-review.md`, `message-review-decision.md`,
+  `customer-roleplay.md`, and `approval-packet.md`; rerun `generate message`
+- `message-review-decision.md` contains `approve-message` but no
+  `approval-packet.md` -> write `approval-packet.md`, render that packet inline
+  starting with `Status: approval-packet`, then ask the six-choice commit gate
+  in the same turn
+- `message-validation.md` + `message-review-decision.md` +
+  `approval-packet.md` present -> validation complete,
+  render `approval-packet.md` inline starting with `Status: approval-packet`,
+  then ask the six-choice commit gate in the same turn
+- `lead-review.md` without `lead-sample.json`, or vice versa -> stop with a
+  contract violation
+- `lead-filter.md` without upstream lead artifacts -> stop with a contract violation
+
+Phase 85 commit-gate + atomic-mint resume:
+
+- All validation artifacts present and `message-review-decision.md` contains
+  `approve-message` but no `approval-packet.md` yet -> write the approval
+  packet, render it inline, then show the commit gate in the same turn (see
+  `<commit_gate>` below)
+- `approval-packet.md` present but no `commit-gate-decision.md` -> show the
+  approval packet inline and then the commit gate in the same turn; an existing
+  positive `customer-roleplay.md` is advisory only
+- `commit-gate-decision.md` is a revision choice or `abort` -> route without
+  DB mutation
+- `commit-gate-decision.md` contains `approve` and no `CampaignOffer` minted
+  yet -> run atomic mint
+- `CampaignOffer` exists and `currentStep = "auto-execute-leads"` -> resume
+  via `create_campaign({ campaignId })` to re-fetch state + `watchUrl`,
+  re-surface the watch link using `references/watch-link-handoff.md`, and
+  continue into the autonomous tail at Step 13
+
+Phase 85 autonomous-tail resume (Plan 85-02):
+
+- `CampaignOffer.currentStep === "auto-execute-leads"` -> run Step 13
+  (import) then advance to `validate-sample`
+- `CampaignOffer.currentStep === "validate-sample"` -> run Step 14 sample
+  validation loop. Read the persisted `revisionRound` counter and do NOT
+  reset it to 0 on resume
+- `CampaignOffer.currentStep === "auto-execute-messaging"` -> run Step 15
+  messaging scale-up
+- `CampaignOffer.currentStep === "awaiting-user-greenlight"` -> Step 16:
+  re-surface `watchUrl` + `handoff.orientation` and STOP. Do not call
+  `start_campaign` on resume. Wait for UI start or a Claude greenlight
+  turn
+- `CampaignOffer.currentStep === "running"` -> campaign is live. Surface
+  a "campaign is live" confirmation + `watchUrl`. Do not re-start
+
+On every tail resume, re-surface the `watchUrl` and the current step's
+orientation string (v1 create-campaign watch-mode pattern). Load the
+relevant reference for the active step:
+
+- Step 14 -> `references/sample-validation-loop.md`
+- any escalation path -> `references/escalation-ladder.md`
+- Step 16 -> `references/final-handoff-contract.md`
+
+</resume_rules>
+
+<commit_gate>
+
+After Phase 84 artifacts are complete, show the user a commit gate before any
+DB mutation. Load `references/approval-gate-framing.md` for the full
+framing — especially the approval packet ordering and per-choice draft
+directory effects.
+
+Preconditions (block the gate when missing):
+
+- `brief-v1.md` should exist for from-scratch runs
+- `brief.md` must exist
+- `lead-review.md` must exist
+- `lead-sample.json` must exist
+- `lead-filter.md` must exist
+- `message-validation.md` must exist
+- `message-review.md` must exist
+- `message-review-decision.md` must exist and contain `approve-message`
+- `approval-packet.md` must be written before asking for a commit decision
+- `rubric.json` is optional but strongly preferred
+
+Anchor validation (block `approve` when empty):
+
+- `brief.md` has a non-empty `## Message Thesis`
+- `lead-review.md` status is `confirmed`
+- `lead-sample.json` parses and contains at least one row
+- `lead-filter.md` has `Decision`, `Who We'll Keep`, `Who We'll Exclude`,
+  `Pass Rate`, `Recommendation`, and `Implementation Details`
+- `message-validation.md` has `Status: confirmed`, `Mode: DRY MODE (no DB
+mutation)`, a `Selected Winner`, and a non-empty `Token Adherence Table`
+- `message-review.md` has `Status: message-review`, `Subject:`, `Message:`
+  with at least one literal `{{...}}` token, `Rendered examples:`,
+  `Good token fill:` with a complete rendered subject + body, `Good omit:` with
+  a complete rendered subject + body, `Token notes:`, `My take:`, `Suggested
+adjustment:`, `Question: approve-message or revise-messaging?`, and
+  `Recommendation: approve-message`
+- `message-review-decision.md` is exactly `approve-message`
+
+Present the approval packet in user-facing order: brief, lead sample, lead
+filter, message validation. Do not dump raw JSON or opaque validation
+anchors at the user.
+
+When rendering the approval packet inline, start it with exactly
+`Status: approval-packet`. Write the same content to `approval-packet.md`
+before showing the gate. The same assistant turn must then call
+`AskUserQuestion` with the six commit choices below. A commit-gate question
+without the inline `Status: approval-packet` packet is invalid UX. If a
+customer roleplay is performed, write `customer-roleplay.md` before the final
+choice. A roleplay result that says "looks good", "approve", or equivalent is
+only critique; it does not satisfy the gate. Write `commit-gate-decision.md`
+only after the user/operator makes one explicit choice.
+
+Use `AskUserQuestion` with exactly these 6 choices, in this order:
+
+```text
+approve
+revise-brief
+revise-leads
+revise-rubric
+revise-messaging
+abort
+```
+
+Do not collapse, reorder, or add choices. Do not auto-select.
+
+If the host UI caps options per question, preserve the same six routes with a
+two-question gate: Q1 = `approve`, `revise`, `abort`; Q2 =
+`revise-brief`, `revise-leads`, `revise-rubric`, `revise-messaging`. Do not
+tell the customer this is because of schema/tool limits. In the split form,
+`revise` is only the parent choice for the second question, not a new route.
+
+</commit_gate>
+
+<sender_resolution>
+
+Before atomic mint, the skill needs a concrete sender identity. Resolve
+it in this order — stop at the first step that yields a confirmed
+sender, and NEVER invent / guess / brute-force LinkedIn URLs:
+
+1. **If the fixture/caller provides `senderIdentity.senderId`**, use it
+   directly. Call `get_sender({ senderId })` to confirm it exists in
+   the active workspace, then call `enrich_sender({ senderId })` ONCE
+   to populate `companySnapshot` + `proofDigest`. Do not call
+   `list_senders`, do not guess alternate URLs.
+2. **Else if the fixture/caller provides a confirmed
+   `senderIdentity.linkedinUrl`**, call `enrich_sender({ linkedinUrl
+})` ONCE. If it errors, DO NOT retry with a variation of the URL.
+   Fall through to step 3.
+3. **Else if the caller provides `senderIdentity.name` +
+   `companyDomain` (or workspace context), do ONE `WebSearch` pass**
+   for the authoritative LinkedIn profile URL ("`{name}` `{company}`
+   linkedin"). Use ONLY a URL that appears verbatim in a web search
+   result. Never synthesize a URL from the name. If WebSearch returns
+   no clean match, escalate to step 4.
+4. **Else escalate.** Print the available sender context and ask the
+   user to resolve (senderId or confirmed linkedinUrl). Do not proceed
+   with atomic mint.
+
+Hard rules:
+
+- At most ONE `enrich_sender` retry per run, only when the first
+  response was a transient (5xx) error. Do not retry on 400/404 by
+  changing the URL.
+- At most ONE `WebSearch` pass per run for sender resolution.
+- NEVER call `enrich_sender` on a lead's LinkedIn URL. `enrich_sender`
+  is for the single sender entity only. Lead enrichment happens via
+  the Enrich Prospect column in the workflow table.
+- If the fixture's `mustMatchWorkspaceSender` flag is true and the
+  resolved sender isn't in the active workspace, ABORT the run with an
+  explicit mismatch error.
+
+</sender_resolution>
+
+<atomic_mint>
+
+Only run this sequence when the user picks `approve`. Load
+`references/watch-link-handoff.md` before starting; it owns the watch-link
+surfacing protocol and the partial-mint recovery rules.
+
+Exact sequence:
+
+1. Read `brief.md` and `rubric.json` from the draft directory.
+2. Validate anchors one more time. An empty anchor blocks the approve path.
+   The brief must include an `## Approved Message Template` section with
+   the exact live message template and at least one supported `{{token}}`
+   such as `{{first_name}}`. Rendered examples are not enough. The
+   Generate Message column switches to template mode only when
+   `campaignBrief.content` contains `{{...}}`; without this marker it will
+   use full-generation mode and may rewrite the approved message.
+   The live template body must contain only sender-ready copy plus supported
+   `{{tokens}}`; no bracketed instructions or placeholder prose may appear in
+   the body.
+   Include `### Token Fill Rules` for every enriched-prospect-row token in the
+   template. Tokens may be row fields such as `{{first_name}}`,
+   `{{company}}`, `{{role}}`, `{{headline}}`, `{{profile_summary}}`,
+   `{{post_context}}`, `{{comment_summary}}`, `{{source_post_topic}}`, or
+   `{{row_proof_note}}` when those exact fields are supported by the
+   row/enrichment data. Do not document static sender identity, product name,
+   proof points, casing style, `{{recent_signal_quote}}`, or abstract slot
+   tokens such as `{{hookLine}}`, `{{painLine}}`, `{{productLine}}`,
+   `{{closeLine}}`, or `{{psLine}}`.
+3. Call `bootstrap_create_campaign({ flowVersion: "v2" })`. Respect
+   `safeToProceed`; on blocking errors, surface and stop.
+4. Call
+   `create_campaign({ campaignBrief, currentStep: "auto-execute-leads" })`.
+   The `campaignBrief` argument must preserve the approved message
+   template section verbatim, including the `{{tokens}}`.
+   If the brief has no supported `{{token}}`, do not call
+   `create_campaign`. Fail the approve path and ask for a corrected
+   template, unless the user explicitly approved freeform AI-generated
+   messages and the tool call sets `messageGenerationMode:
+"ai-generated"`.
+   Include `senderIds` when a workspace sender is available. If the
+   customer-named sender is not configured in the current UAT workspace,
+   use an available workspace sender for the rehearsal and state that
+   mismatch in the final runtime notes. Do not silently mint without a
+   sender because sequence selection depends on sender tier/settings.
+   Capture `{ campaignId, watchUrl }` from the response.
+   - If the call errors, surface the error and stop. No rollback needed; no
+     campaign exists.
+   - If the response is missing `watchUrl`, treat it as a recoverable
+     failure. Stop before `save_rubrics`. Do not print a watch link.
+     Surface the contract violation explicitly — a missing `watchUrl` is a
+     plumbing bug, not a silent skip.
+5. Call `save_rubrics({ campaignOfferId: campaignId, rubric })` using the
+   payload derived from `rubric.json` (or from `lead-filter.md` if
+   `rubric.json` is absent).
+   - If this call fails after `create_campaign` succeeded, either rollback
+     the `CampaignOffer` row, or mark an explicit recoverable failure state
+     so the user can retry. Never leave a silent partial campaign. Do NOT
+     print the watch link during this recovery window.
+6. Flip the brief status in the draft to `committed`. Move the draft
+   directory from
+   `.sellable/create-campaign-v2/drafts/{workspace-slug}/{campaign-slug}/`
+   to
+   `.sellable/create-campaign-v2/drafts/{workspace-slug}/.committed/{campaign-slug}/`.
+7. Surface the `watchUrl` using the exact block defined in
+   `references/watch-link-handoff.md`. Only print after both
+   `create_campaign` AND `save_rubrics` have succeeded.
+8. Hand off to the autonomous tail (Plan 85-02). Do not run Step 13 lead
+   import here.
+
+If the approved lead source exists only as a provider lane in
+`lead-review.md` (for example a Sales Navigator filter/search URL) and no
+live `searchId` or `sourceLeadListId` is present, recreate the approved
+source by calling the matching provider search tool first, then import from
+the returned id. This is replaying the approved lane, not inventing a new
+source. Do not skip import/messages on that basis.
+
+Do NOT call `import_leads` during atomic mint. Full lead sourcing and import
+happen in Plan 85-02 Step 13 after mint.
+
+</atomic_mint>
+
+<revision_routing>
+
+When the user picks a revision choice, do not mint a campaign. Do not print
+a watch link. Route back to the relevant upstream step and reset the draft
+directory per `references/approval-gate-framing.md`:
+
+- `revise-brief` -> back to Phase 83 or Phase 84 depending on what changed.
+  Preserve `brief.md`; delete all downstream artifacts.
+- `revise-leads` -> back to Phase 84 `find leads`. Preserve `brief.md`;
+  delete lead and downstream artifacts.
+- `revise-rubric` -> back to Phase 84 `filter leads`. Preserve `brief.md`,
+  `lead-review.md`, `lead-sample.json`; delete `lead-filter.md`,
+  `message-validation.md`, and `rubric.json`.
+- `revise-messaging` -> back to Phase 84 `generate message`. Preserve
+  upstream artifacts; delete only `message-validation.md`,
+  `message-review.md`, `message-review-decision.md`,
+  `customer-roleplay.md`, and `approval-packet.md`.
+- `abort` -> move the draft directory to
+  `.sellable/create-campaign-v2/drafts/{workspace-slug}/.aborted/{campaign-slug}-{timestamp}/`.
+  No DB rows touched.
+
+Revisions must produce zero DB rows.
+
+</revision_routing>
+
+<boundaries>
+
+Phase 84 (pre-commit-gate) boundary:
+
+Do not create live campaign state during validation. Specifically, do not:
+
+- mint a campaign
+- import leads
+- persist selected lead lists
+- attach downstream assets
+- save remote rubric state
+- move the user into a live execution step
+
+Phase 85 (commit-gate and beyond) boundary:
+
+- The commit gate is the only place in this skill where DB mutation is
+  authorized. Do not call `create_campaign`, `save_rubrics`,
+  `update_campaign`, or any other mutating tool before the user picks
+  `approve`.
+- Revision choices and `abort` must never call a mutating tool.
+- `import_leads` is not part of atomic mint. Defer it to Plan 85-02 Step 13.
+- Never print the `watchUrl` until both `create_campaign` and `save_rubrics`
+  have succeeded.
+- Never fabricate or reconstruct the `watchUrl` — capture it from the
+  `create_campaign` response.
+- Once a campaign has been minted, every provider search and every
+  provider-import call from this skill MUST include the minted
+  `campaignOfferId`. This is universal — Prospeo, Sales Nav, Apollo,
+  Signal Discovery, and any future provider. The only place a
+  campaignless search is correct is the pre-mint Phase 84 `find leads`
+  discovery sample. Post-mint expansion, scale-up imports, alternate
+  lane explorations, account-based reruns, signal-monitor lanes, and
+  operator-driven follow-up searches all persist to the campaign and
+  must carry `campaignOfferId`. A search without `campaignOfferId`
+  after mint orphans the search from the campaign UI's Contact
+  Search panel and the campaign's `Searches` history, even when the
+  search produced rows that later get imported. If the search
+  helper enforces a `confirmed: true` gate, pass that with
+  `campaignOfferId` rather than dropping it.
+
+</boundaries>
+
+<autonomous_tail>
+
+The review-batch tail runs AFTER the atomic mint succeeds. It is driven by
+`core/auto-execute.yaml` and progresses through four steps — Step 13
+(import review batch), Step 14 (validate-sample), Step 15
+(auto-execute-messaging for the review batch), Step 16
+(awaiting-user-greenlight) — before stopping and waiting for a user
+greenlight.
+
+Cost boundary: the commit gate approves creating a campaign and producing a
+real review batch. It does NOT approve spending enrichment/message credits on
+hundreds of leads. Two separate scales apply post-mint and they MUST be kept
+distinct in your head:
+
+- **Import scale** (how many rows land in the campaign table). Defaults to
+  `import.importLimit` (25). The user MAY explicitly raise this at or before
+  mint with phrasing like "import all of them", "pull the full search", "all
+  ~2,000 from this lane", or a numeric target. When the user has stated the
+  full-scale import intent, pass that count as `targetLeadCount` so the table
+  carries the full pool. Importing rows is cheap (no enrichment runs yet);
+  storing them up front lets the user kick remaining enrichment manually
+  without re-importing later.
+- **Cascade scale** (how many rows get enriched/scored/messaged before user
+  approval). ALWAYS stays at the configured review batch (`sample.sampleSize`
+  or `import.importLimit` — default 25) until the user explicitly approves the
+  sample. This is the cost gate. Even when the user said "import all", you
+  queue Enrich Prospect cells for only the first review-batch rows. The
+  remaining rows sit `pending` in the table for the user to kick manually
+  after they've eyeballed the sample.
+
+A pre-stated full-import intent is NOT a pre-approval to cascade everything.
+Re-confirm before queueing enrichment beyond the review batch.
+
+If the source lane contains hundreds of leads and the user has not stated a
+full-import intent, leave the rest untouched in the source — do not import
+beyond `importLimit` until the user asks to expand.
+
+## MANDATORY TOOL ORDER (read this BEFORE any tail step)
+
+Every tail run MUST call these tools in this exact order. The tail is
+**review-batch cascade-driven**: you kick off Enrich Prospect only for
+the imported review batch, and the workflow engine chains DNC Check →
+ICP Score → Passes Rubric → Generate Message automatically. Your job is
+to START the bounded cascade, WAIT for it to drain, OBSERVE the results,
+and stop for review.
+Do NOT manually run rubric-check, enrich, or message-generation
+tools — the cascade already does them.
+
+```text
+Step 13 — import review batch + kick bounded cascade
+  import_leads(targetLeadCount=importLimit)
+  wait_for_lead_list_ready
+  confirm_lead_list
+  get_rows_minimal                 # capture enrichCellIds
+  queue_cells(cellIds=<review-batch Enrich Prospect cells only>)  <-- starts bounded chain
+  wait_for_campaign_table_ready    # review-batch cascade drains here
+  update_campaign(currentStep=validate-sample)
+
+Step 14 — observe sample
+  get_rows_minimal                 # read passesRubric + message cell status per row
+  compute projectedPass
+  if OK: update_campaign(currentStep=auto-execute-messaging)
+  else:  diagnose brief-vs-list; if brief: update_campaign_brief + re-queue + wait
+  (check_rubric / bulk_enrich_with_prospeo are NOT called here —
+   cascade already did them. wait_for_rubric_results is OK as a
+   read-only observation helper if you need to block on completion.)
+
+Step 15 — observe messaging
+  get_rows_minimal                 # confirm passing rows have completed Generate Message cells
+  (rare) queue_cells on any pending Generate Message cells
+  token-contract spot check via get_rows
+  update_campaign(currentStep=awaiting-user-greenlight)
+  (generate_messages is NOT an MCP tool; messages come from the cascade)
+
+Step 16 — awaiting-user-greenlight
+  attach_recommended_sequence({ campaignId })  # tier-aware: premium/SN -> If Open Profile->INMAIL_OPEN, else INVITE->accepted->DM
+  re-surface watchUrl + review-batch orientation
+  STOP. DO NOT call start_campaign. DO NOT auto-advance currentStep.
+```
+
+**Prefer `attach_recommended_sequence` over `attach_sequence` in the
+autonomous tail.** The recommended tool takes only `campaignId` and
+delegates template selection to the backend's tier-aware selector
+(`selectTemplateForTiers`). `attach_sequence` requires you to
+hand-author a `version: 2` template with nodes, branches, and
+entryNodeId — that's error-prone mid-long-context (galley-off UAT
+`20260420T195732Z` failed because Claude hit "Invalid node type" and
+tried to debug via forbidden Bash/Glob calls). Use `attach_sequence`
+only when the caller explicitly needs a custom non-recommended cadence.
+
+Hard gates — if you find yourself about to violate any of these, stop
+first:
+
+- Do NOT use `update_cell` to write message bodies. The `Generate
+Message` column's http_request writes those cells via the cascade.
+  `update_cell` remains reachable for legitimate operator overrides
+  AFTER the tail hands off.
+- Do NOT call `check_rubric`, `enrich_with_prospeo`, or
+  `bulk_enrich_with_prospeo` in the tail. Those are direct-API
+  mutation tools that fetch data to the caller without writing to
+  the workflow table cells. Step 13's `queue_cells` already
+  triggers the column-level enrichment that populates those cells.
+  Running these tools in the tail produces duplicate cost with no
+  cell side effect.
+- `wait_for_rubric_results` is read-only and OK to use as an
+  observation helper when you need to block on rubric completion —
+  it does not mutate cells. Prefer `get_rows_minimal` +
+  `wait_for_campaign_table_ready` for the primary cascade-drain
+  path, but use `wait_for_rubric_results({ targetCount: cohortSize })`
+  when the table-level wait returns before rubric cells finish.
+- `start_campaign` is FORBIDDEN in the autonomous tail. It belongs only
+  in the Claude-greenlight path, AFTER the user signals "start". See
+  `references/final-handoff-contract.md`.
+- You MAY NOT call `start_campaign` without a prior successful
+  `attach_recommended_sequence` (or `attach_sequence` if a custom
+  cadence is explicitly required) in the same run.
+- You MAY NOT call `start_campaign` while ANY passing row has an
+  empty `Generate Message` cell. If you discover empty message cells in
+  the greenlight turn, ABORT greenlight and return to Step 15 first.
+- You MAY NOT call `attach_sequence` while ANY passing row has an
+  empty `Generate Message` cell. Before `attach_sequence`, call
+  `get_rows_minimal` and confirm every row where `passesRubric=true`
+  has a `completed` Generate Message cell with non-empty `result`. If
+  any are pending, call `queue_cells` on those generateMessageCellIds
+  and wait. If rows truly won't message, ESCALATE.
+- You MAY NOT advance past Step 13 without calling `queue_cells` on
+  the review-batch Enrich Prospect cells. Without it, every downstream
+  cell stays `pending` and the campaign ships empty.
+- You MAY NOT queue enrichment for rows outside the configured review
+  batch before the user approves expansion. Full-list enrichment/message
+  generation is a credit-spend decision and must happen after the user
+  has reviewed the sample.
+
+Load `core/auto-execute.yaml` exactly once at the start of Step 13. All
+subsequent steps read the already-parsed config. Do not re-load mid-run.
+Load each subskill prompt (`create-campaign-v2`, `research-sender`,
+`generate-messages`) at most once per run — if a tool result already
+told you to load a prompt, load it and remember; do not re-request the
+same prompt later.
+
+After every `update_campaign({ currentStep: ... })` in the tail, narrate
+what changed and orient the user to what the watch link will show next —
+reuse the v1 `create-campaign` watch-mode pattern verbatim.
+
+## Step 13: auto-execute-leads
+
+Entered on `CampaignOffer.currentStep === "auto-execute-leads"` (set by
+atomic mint).
+
+> Reminder: every provider search you run from this point forward — the
+> review-batch source rerun in Step 13, any expansion search after the
+> review batch, alternate-lane probes, account-based reruns, and operator
+> follow-ups — MUST include `campaignOfferId`. This applies to
+> `search_prospeo`, `search_sales_nav`, `search_apollo`,
+> `search_signals`, and any other provider search tool added later.
+> Campaignless searches after mint orphan results from the campaign UI.
+
+1. Load `core/auto-execute.yaml`. Capture `import.importLimit`,
+   `sample.sampleSize`, `sample.minProjectedPass`,
+   `sample.maxRevisionRounds`, `messaging.tokenContract`,
+   `messaging.critique.enabled`, `handoff.autoStart`,
+   `handoff.orientation`, `retry.sameToolSameError`,
+   `logging.logEveryThresholdTrip`.
+2. Resolve the approved source before importing. If there is no
+   `lead-source-intake.json`, keep the existing discovered-provider path:
+   `import_leads({ campaignOfferId, targetLeadCount: importLimit })`.
+   If a manifest exists, branch by `sourceType`:
+   - `supplied-linkedin-profiles`: revalidate file metadata and confirmation
+     token, confirm `load_csv_linkedin_leads` only after approval, persist the
+     returned `leadListId`, then call
+     `confirm_lead_list({ sourceLeadListId: leadListId, targetLeadCount:
+importLimit })`.
+   - `existing-lead-list`: revalidate that the lead list still exists in the
+     same workspace, reuse it as `sourceLeadListId`, then call
+     `confirm_lead_list({ sourceLeadListId, targetLeadCount: importLimit })`.
+   - `supplied-domains`: reuse or confirm `load_csv_domains`, preserving
+     `domainFilterId`; run a campaign-associated Prospeo people search with
+     `campaignOfferId`, provider prompt preflight, and that `domainFilterId`;
+     then import with `targetLeadCount: importLimit`.
+     Never exceed `importLimit`. This is a review batch, not a full
+     campaign-scale import. If a source search/list contains more rows than
+     the cap, import only the first `importLimit` rows and leave the rest for
+     a later expansion step.
+     Persist or recover materialized IDs on resume: `leadListId`,
+     `domainFilterId`, `searchId`, `campaignTableId`, imported row IDs, and queued
+     cell IDs. If the source file changed after preview, or an existing lead list
+     is missing/wrong-workspace, escalate before materialization instead of
+     silently applying stale preview data. Retrying Step 13 must not duplicate
+     lead lists, searches, campaign rows, or queued cells.
+3. `wait_for_lead_list_ready` and `confirm_lead_list`.
+4. **Verify the table is set up properly before queuing.** Call
+   `get_rows_minimal({ tableId })` and confirm:
+   - `Enrich Prospect` column exists on the table and every imported
+     row has a corresponding cell with `status === "pending"`.
+   - `DNC Check`, `ICP Score`, `Passes Rubric`, and `Generate Message`
+     columns all exist too (the cascade depends on all of them).
+   - If any are missing, or the cell is in a non-`pending` terminal
+     state from an earlier run, ESCALATE with an explicit "table not
+     configured for autonomous tail" diagnosis. Do NOT attempt to
+     patch the table shape from the tail.
+5. **Kick off the bounded review-batch cascade.** `queue_cells({ tableId,
+cellIds: <pending enrichCellIds for the imported review batch only> })`.
+   You queue ONLY the review-batch `Enrich Prospect` cells; the cascade
+   auto-dispatches `DNC Check`, `ICP Score`, `Passes Rubric`, and (for rows
+   where `Passes Rubric === true`) `Generate Message` as each upstream
+   completes. Do not queue cells for any rows beyond `importLimit` before
+   user expansion approval.
+6. `wait_for_campaign_table_ready` — waits for the review-batch cascade to
+   drain.
+   If it times out with most cells still `pending`, ESCALATE: the
+   engine is blocked.
+7. If the import returns zero usable leads, ESCALATE per
+   `references/escalation-ladder.md` (hard fail).
+8. `update_campaign({ campaignId, currentStep: "validate-sample" })`.
+9. Orient user on the watch link (same pattern as every other step
+   change).
+
+**Do NOT call `check_rubric`, `wait_for_rubric_results`,
+`enrich_with_prospeo`, or `bulk_enrich_with_prospeo` in Step 13.**
+Those are direct-API tools that fetch enrichment/scoring data to the
+caller; they do not write to the workflow table cells. The cascade
+triggered by `queue_cells` runs the `Enrich Prospect` column's
+http_request, which writes the enrichment into the cell, which
+triggers the next column, and so on. Running the direct-API tools
+is duplicate work with no cell-population side effect.
+
+## Step 14: validate-sample (loop)
+
+Entered on `CampaignOffer.currentStep === "validate-sample"`. Full
+decision tree lives in `references/sample-validation-loop.md`.
+
+**Step 14 is pure observation.** The bounded review-batch cascade that Step
+13 kicked off (via `queue_cells` on Enrich Prospect) has already written ICP
+scores and Passes Rubric values back into the workflow table. Step 14 reads
+those review-batch cell results — it does NOT call `check_rubric`,
+`wait_for_rubric_results`, `bulk_enrich_with_prospeo`, or any other
+direct enrichment/scoring tool. All of that already happened in the
+cascade; running them again is wasted work and can overwrite the
+real cell results with unrelated data.
+
+Shape:
+
+```text
+get_rows_minimal({ tableId })
+passInSample = count of first sampleSize review-batch rows with passesRubric === true
+projectedPass = round(passInSample / sampleSize * importLimit)
+
+if projectedPass >= minProjectedPass:
+    advance to Step 15
+else:
+    diagnose brief-vs-list per sample-validation-loop.md
+    - brief: autonomous update_campaign_brief, then re-kick cascade
+             (queue_cells on enrichCellIds) and wait for the new
+             results
+    - list:  ESCALATE (no auto-revision of leads)
+    - unknown: ESCALATE
+    revisionRound += 1
+    if revisionRound > maxRevisionRounds:
+        ESCALATE
+```
+
+Persisted counter rule: `revisionRound` persists across skill resume.
+Do NOT reset to 0 on resume — a stale resume must still respect the
+`maxRevisionRounds` cap.
+
+A "list problem" diagnosis NEVER triggers autonomous
+`update_campaign_brief`. Escalate instead.
+
+When the sample passes the projected-pass floor, call
+`update_campaign({ campaignId, currentStep: "auto-execute-messaging" })`
+and orient the user that messaging will complete for the review batch only.
+
+## Step 15: auto-execute-messaging
+
+Entered on `CampaignOffer.currentStep === "auto-execute-messaging"`.
+
+**Messages are produced by the `Generate Message` column cascade, not
+by a separate tool.** Do NOT call a `generate_messages` MCP tool —
+that tool does not exist; `generate-messages` is a subskill prompt
+loaded during live messaging drafts. In the autonomous tail, messages
+flow through the column pipeline: `Enrich Prospect` →
+`DNC Check` → `ICP Score` → `Passes Rubric` → `Generate Message`.
+Each column's http_request auto-fires when its upstream dependency
+completes AND passes gate (e.g. `Passes Rubric === true` before
+`Generate Message`). Your job in Step 15 is to WAIT for the review-batch
+cascade to reach `Generate Message` for rows that passed ICP, and verify
+the output — not to generate messages manually.
+
+**What Step 15 does:**
+
+1. `get_rows_minimal` to read `passesRubric` + `generateMessageCellId`
+   - the Generate Message cell's `status` and `result` per row.
+     Before queueing or waiting on Generate Message cells, confirm the
+     minted campaign brief still contains `{{...}}` in `## Approved Message
+Template`. If it does not, fail before the cascade runs. Do not repair
+     after mint; the template must be present during mint so Step 15 never
+     starts in freeform generation mode.
+2. For every row where `passesRubric === true`:
+   - The Generate Message cell should be `running` or `completed`
+     already (cascade auto-fired it). If it is still `pending`, queue
+     it explicitly: `queue_cells({ tableId, cellIds:
+<generateMessageCellIds> })`.
+3. `wait_for_campaign_table_ready` (or poll) until every passing
+   row's Generate Message cell is `completed`.
+4. Read the results back via `get_rows` (full) and sanity-check a
+   sample against the Phase 84 token contract: no unresolved
+   `{{tokens}}`, no invented proof, one sentence per line, etc.
+5. If the sample fails the token contract, diagnose brief-vs-list
+   (same revision loop as Step 14) and escalate if over
+   `maxRevisionRounds`.
+6. On success, `update_campaign({ campaignId, currentStep:
+"awaiting-user-greenlight" })`.
+
+**Do NOT hand-write message bodies via `update_cell`.** `update_cell`
+is reachable for legitimate operator overrides AFTER the tail hands
+off, but during autonomous tail the cascade owns the writes. If you
+find yourself drafting a message body and about to push it through
+`update_cell`, you have lost state — stop, read the cells, and let
+the pipeline finish.
+
+**What `attach_sequence` does (Step 16, not here):** binds the
+DM/InMail cadence template to the workflow table. Completely different
+job from messaging. Does NOT generate or write message text. A
+sequence with no `Generate Message` outputs would try to send empty
+strings, which is why Step 16 requires Step 15 to be complete.
+
+1. Observe the review-batch messages on the same sample that passed
+   validation.
+2. If `messaging.critique.enabled` is true (Plan 85-03), run the
+   bounded critique pass on the sample output per
+   `references/parallel-critique-protocol.md`. The pass runs on at
+   most `messaging.critique.sampleSize` rows, sends each row through
+   three parallel critics (targeting / copy / voice) that return
+   structured JSON, and merges the voices in a synthesis step that
+   enforces the Phase 84 token contract verbatim and re-runs the
+   finalizer pass. Any rewrite that invents proof or uses an
+   unsupported token falls back to the plain generated message. A
+   trip of `messaging.critique.budgetUsdCap` HALTS critique for the
+   remaining sample and continues the plain tail. Plan 85-02 reads
+   the flag but never flips it; critique stays off until the flag is
+   deliberately enabled.
+3. If `messaging.critique.opus.enabled` is also true, route the
+   highest-value subset through the Opus / craft-message path per
+   `references/thomas-variant-selection.md`. Opus is capped by
+   `messaging.critique.opus.maxMessagesPerPass` and
+   `messaging.critique.opus.budgetUsdCap`; tripping either cap keeps
+   the remaining rows on the non-Opus synthesizer. Opus is bound by
+   the same token contract as every other rewrite path.
+4. Check `messaging.tokenContract`. When `strict`, reject any sample
+   message that contains unresolved or unsupported tokens (including
+   any critique rewrite that tried to introduce one).
+5. If the sample passes the token contract (and critique when enabled),
+   stop at the review-batch handoff. Do NOT scale to the full source list
+   before explicit user expansion approval.
+6. If the sample fails the token contract or critique, diagnose +
+   loop the same way Step 14 does (brief-vs-list), subject to the same
+   `maxRevisionRounds` cap.
+7. On success, `update_campaign({ campaignId, currentStep:
+"awaiting-user-greenlight" })` and orient the user.
+
+Critique failure modes NEVER escalate. A critic timeout, a total
+timeout, a budget trip, a fake-proof rejection, or an unsupported-
+token rejection all fall back to the plain generated message for that
+row. Step 15 does not stall on critique.
+
+## Step 16: awaiting-user-greenlight
+
+Entered on `CampaignOffer.currentStep === "awaiting-user-greenlight"`.
+Full contract lives in `references/final-handoff-contract.md`.
+
+Shape:
+
+1. `attach_sequence` (bind the committed sequence to the campaign).
+2. Re-surface the `watchUrl` using `references/watch-link-handoff.md`.
+3. Surface the `handoff.orientation` string from `auto-execute.yaml`
+   alongside the link.
+4. STOP. Do NOT call `start_campaign`. Do NOT auto-advance
+   `currentStep`. The autonomous tail ends here.
+5. Make the credit boundary explicit in the handoff: only the first review
+   batch has been enriched/messaged; expanding to more leads requires a
+   separate user instruction.
+
+Two equally valid greenlight channels take Step 16 into a running
+campaign:
+
+- **UI path** — user clicks "Approve all" and "Start Campaign" in the
+  watch-link UI. The skill stays idle. On the next resume, it observes
+  the running state and shifts to a "campaign is live" confirmation.
+- **Claude greenlight path** — user replies with an affirmative ("yeah
+  start" / "looks good, start" / "ship it"). The skill then performs,
+  in order: (a) bulk-approve queued messages via the EXISTING endpoint
+  `POST /api/v3/workflow-tables/cells/approve-batch` (do NOT invent a
+  new tool/endpoint), (b) `start_campaign({ campaignId })`, (c)
+  `update_campaign({ campaignId, currentStep: "running" })`, (d)
+  re-surface `watchUrl` plus a "campaign is live" confirmation.
+
+A Claude greenlight on an already-running campaign is a no-op
+confirmation, NOT a duplicate start. Detect via `get_campaign` before
+calling any mutating tool; if the campaign is already running, skip
+approve-batch / start_campaign / update_campaign and just confirm.
+
+Workspace/sender mismatch at greenlight time aborts the start with the
+same invariant Phase 84 enforces.
+
+## Threshold Trips and Logging
+
+When `logging.logEveryThresholdTrip === true` (default), log every
+threshold trip: `projectedPass` computation, retry cap, revision cap,
+hard-fail. These logs drive `auto-execute.yaml` tuning after 3-5 real
+runs.
+
+## Tail Hard Rules
+
+- Review-batch sourcing/import happens in Step 13, not during atomic mint.
+- Full-list expansion is not part of the default tail. It requires user
+  approval after the review batch.
+  Import must never exceed `importLimit`.
+- The tail NEVER calls `start_campaign` on its own.
+- The tail NEVER auto-revises leads. Brief revision is autonomous; lead
+  revision is always operator-gated.
+- `revisionRound` persists across resume — no silent reset.
+- The bulk-approve action in the Claude greenlight path uses the
+  existing `POST /api/v3/workflow-tables/cells/approve-batch` endpoint
+  — do NOT create a new tool or endpoint for this.
+- Threshold trips are logged for calibration.
+
+</autonomous_tail>
+
+<references_index>
+
+| File                                       | Load when                                                              |
+| ------------------------------------------ | ---------------------------------------------------------------------- |
+| `references/approval-gate-framing.md`      | Phase 85 commit gate, before showing the approval packet               |
+| `references/watch-link-handoff.md`         | Atomic mint + every tail resume, before surfacing watchUrl             |
+| `references/sample-validation-loop.md`     | Step 14, before enriching + scoring the sample                         |
+| `references/escalation-ladder.md`          | Any tail step that needs to decide retry / revise / escalate           |
+| `references/final-handoff-contract.md`     | Step 16, and every Claude greenlight turn                              |
+| `references/parallel-critique-protocol.md` | Step 15 when `messaging.critique.enabled` is true                      |
+| `references/thomas-variant-selection.md`   | Step 15 when `messaging.critique.opus.enabled` is true                 |
+| `references/thomas-revision-filters.md`    | Any critique rewrite, before persisting                                |
+| `core/auto-execute.yaml`                   | Start of Step 13, load once; all tail steps read parsed values         |
+| `core/auto-execute.README.md`              | When tuning `auto-execute.yaml` knobs or reviewing threshold-trip logs |
+
+</references_index>