@sellable/mcp 0.1.0

package/skills/create-campaign-v2/references/thomas-revision-filters.md

@@ -0,0 +1,521 @@
+# Thomas Revision Filters
+
+Use these filters before Phase 84 message validation is marked `confirmed`.
+
+Read "What Good Looks Like" first. These are the positive targets. Use
+"Automatic Revisions" as the rejection backstop, not the primary lens.
+
+## What Good Looks Like
+
+**Voice and reader experience**
+
+- reads like a sharp human operator, not a mail-merge template
+- sentences sound typed, not assembled — varied length, plain words, no
+  framework seams
+- a busy buyer could skim it in under ten seconds and get the idea
+- the tone matches the Primary Example's reading level (casual-lowercase if
+  Superpower, dense-credentialed if Superposition — don't flatten)
+
+**Relevance and grounding**
+
+- specific to the validated lead and signal; removing the personalization
+  would make the message feel clearly off for this buyer
+- every proof claim traces back to something the brief actually supports
+- every token traces back to a declared source field
+
+**Motion alignment**
+
+- matches the quality bar of one archived motion, not a blend of two
+- opens with the strongest concrete hook the brief supports (event > signal >
+  job > workflow observation)
+- proof sits where the motion expects it (body line for event/signal, stacked
+  body for job-post, short `PS` for stack-replacement / proof-led fallback)
+- the CTA is useful and proportional to buyer intent — not a naked meeting
+  ask, not a fabricated asset
+
+**Craft**
+
+- one observation or one pain in the opener, not both stacked
+- 3 short body paragraphs max, **one sentence per line** (literal — two sentences on one line is a revision)
+- sentences at or below ~15 words, or split into shorter lines when longer
+- plain English — a 5th-grade reader should follow the whole message without stopping
+- jargon is limited to brief-native product and tool names (e.g. Shopify, HubSpot, Salesforce, ServiceNow) — not glue language, which is any B2B compound noun the buyer wouldn't say naturally in conversation
+- mechanism said once, directly (product-name-first when the product can carry the sentence)
+- if the mechanism touches three workflows, pick the most painful one or break them into short lines
+- PS reads like one human telling another why the sender gets their pain — at most two proof beats, connected into a sentence or two, first names preferred
+- the sample set reads like siblings from one campaign, not three experiments
+- the Finalizer Pass result is better than any single candidate, or one candidate is named the sweep and the winning axis is declared
+
+## Automatic Revisions
+
+Revise or reject the sample when any of these happen.
+
+**Token and proof safety**
+
+- unresolved `{{token}}`
+- unsupported token not documented in the brief
+- invented metric, logo, customer, funding detail, or product claim
+- personalization that cannot be traced to `lead-sample.json`
+- the message has no compelling proof even though the brief supports one
+- stronger safe proof exists in the brief but the draft settles for weaker
+  generic credibility
+
+**Voice and inbox readability**
+
+- generic praise, compliment-sandwich openers, or filler flattery
+- weak observational hooks that could fit almost anyone
+- copy that sounds like a template with the company name swapped in
+- **sentences above ~15 words, or with more than one comma, when they could be split**
+- **two or more sentences on the same line with no blank line between them** — default is one sentence per paragraph, blank line between every sentence in the body
+- **body renders as multi-sentence paragraphs** instead of one-sentence paragraphs separated by blank lines
+- **a single mechanism line that stacks three workflows together** as a comma list (e.g. "order intake, inventory sync, and reorder timing"). Give each workflow its own one-sentence paragraph, or pick the most painful one and drop the others
+- **product clarity failure**: a cold reader cannot state what the product does in one sentence after reading. The mechanism gestures at "that chain", "the stack", or "that work" without a crisp `Product is an X that does Y` anchor sentence and/or without naming specific actions
+- **missing "what the product IS" anchor** — the action breakdown appears without a one-sentence statement of what the product is. The reader needs to know the product category before the actions make sense
+- **actions are implied, not stated** — e.g. "runs that chain as AI agents" when a clearer version would name the specific actions (verb + object, one per line)
+- **category-level opener used when a per-lead signal exists** — if `lead-sample.json` carries any per-lead signal (post, hire, visible tool, topic engagement), the opener must reference it. Category-level openers of shape `"Most [category] teams still do X by hand"` are only acceptable when zero per-lead signal is in the sample. When a category-level opener is used as fallback, Findings must flag it explicitly
+- **mind-reading from engagement signals** — a topic engagement, post, public activity, role, company, or hiring trigger does not prove buyer intent. Reject phrases like `"AI-GTM stack is clearly on your mind"`, `"you're clearly focused on..."`, `"obviously relevant"`, or `"already thinking about..."` unless that exact priority is explicitly present in `lead-sample.json`. Translate to low-certainty buyer context or omit the signal from copy.
+- **source-y signal narration** — reject `"saw you on..."`, `"saw you around..."`, `"saw you engaging with..."`, `"your LinkedIn activity..."`, or any line that makes the recipient feel watched unless the chosen archived motion is intentionally self-aware about the signal. Translate the signal into a natural buyer-context line or omit it.
+- **internal-metric flex** — reject compute time, token/cache details, model names, agent-counts, orchestration internals, or similar process metrics unless the brief proves the buyer cares about that exact detail. `~5 min of compute per message` is not buyer value by itself.
+- **action lines are parallel (same subject, e.g. `It X` / `It Y` / `It Z`) but rendered as one-line paragraphs instead of bullets** — parallel action lines are the bullet case. One-line paragraphs are only for actions that carry a short narrative clause
+- **PS carries a second proof beat that doesn't answer a different objection** — the second beat must open a dimension beat #1 didn't address (e.g. technical reliability when beat #1 was operator empathy; named backing when beat #1 was founder track record). Default PS is ONE beat
+- **subject line uses the same banned glue jargon as the body** — any B2B compound noun the buyer wouldn't say naturally in conversation. Subject follows the same jargon rules as the body
+- **jargon that a 5th-grade reader could not parse** — any B2B compound noun the buyer wouldn't say naturally in conversation. Common examples across motions: "handoff", "rip-and-replace", "pane of glass", "single source of truth", "alert fatigue", "top of funnel", "time to hire". Keep product and tool names that the buyer recognizes; cut the glue language around them
+- em dashes in copy that is otherwise plainspoken
+- repeated metaphor framing makes the sample set feel machine-generated
+- the note reads above a 5th-grade reading level when the motion does not require technical jargon
+
+**PS shape and social proof**
+
+- **the PS lands as a resume list** (three credential sentences in a row, separated only by periods). Rewrite as a thin narrative of at most two proof beats
+- **proof beats are stacked with no connective tissue** — e.g. "CEO X did A. CTO Y did B. Backer Z." No human writes proof like that in an inbox note
+- **full titles in the PS when the bare role word would read more natural** — "our CEO [did X]" reads more natural than "CEO Alex, 2x founder, [did X]". Drop titles unless the title itself is the proof
+- more than two proof beats in the PS (three or more reads as a resume dump)
+- a proof beat that is not tied to the buyer's situation — proof should explain why this sender gets the buyer's pain, not just list credentials
+
+**Motion alignment**
+
+- a concrete validated hook exists but the opener falls back to generic pain
+- an abstract noun subject line when a concrete event/signal/asset/offer
+  subject was available
+- the draft blends multiple example motions into one overbuilt message
+- a matched archived winner is the same company as the brief, but the draft
+  rewrites its casing, spacing, or proof order anyway
+- the three sample messages don't feel like siblings from one campaign
+- a signal-led note had a clean chance to sound like an honest operator but
+  got polished into generic sales copy
+
+**Fallback (proof-led specialist) drift**
+
+- opens with "most teams..." / "scaling X..." without a concrete
+  buyer-language workflow anchor
+- opens with synthesized "running X means..." / "being Y means..." framing
+- leans on "at your stage" or "in a setup like yours"
+- mechanism hides behind "we built..." / "we created..." when the product
+  name can carry the sentence
+- stack-replacement copy never names the workflow pieces or the breaking
+  handoff even though the brief supports them
+- invents a report, brief, teardown, video, or other lead magnet the brief
+  never said exists
+- defaults to "can I send it over?" / "send a short overview" when the
+  motion is conversational
+
+**CTA and structure**
+
+- a CTA heavier than the proof and signal support
+- asks for a meeting without offering a useful next step
+- a `PS` appears anywhere other than as the final line
+- a single sample stacks too many ideas (long opener + product explanation +
+  proof dump + CTA in one dense block)
+
+**Finalizer discipline**
+
+- three candidates drafted but no winner declared
+- winner named "hybrid" without naming which candidate each borrowed piece
+  came from
+- winner claimed to sweep without declaring the winning axis
+- token fill rules unclear enough that the copy looks guessed
+
+## Substance Filters (block the message until fixed)
+
+These filters sit ABOVE the "Automatic Revisions" list — they check whether
+the message has any substance at all, not just whether the lint passes.
+A candidate that fails ANY of these five filters 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.
+
+The "Automatic Revisions" list catches syntax and voice issues. Substance
+Filters catch the polished-looking spam that passes lint but has no reason
+to exist in this specific recipient's inbox.
+
+### Filter 1 — Earned-right filter
+
+**Rule.** At least ONE line in the body MUST cite something specific to
+the recipient that is verifiable in `lead-sample.json` for THAT row: a
+post excerpt, profile-summary phrase, hiring-trigger, recent-funding
+event, mutual connection, or company-event. If the message contains ZERO
+recipient-specific signals, it has no earned right to the inbox.
+
+**Example of a violation** (from the Ambral wrongly-approved winner):
+
+> "Your mid-market and SMB book is where NDR hides — not enough AMs to
+> cover it." — this opens with a 3-presumption accusation and cites zero
+> row-specific signal.
+
+**Route.** REJECT the candidate. Route to `revise-filter` when the signal
+is missing because the lead source itself is thin (e.g., Sales Nav lane
+with no post data). Route to `revise-message` when the signal IS present
+in `lead-sample.json` but the draft ignored it.
+
+### Filter 2 — Presumption filter
+
+**Rule.** The opener CANNOT assert facts about the recipient's business
+that are not validated in `lead-sample.json` — book size, NDR location,
+churn rate, staffing level, segment coverage, or any other claim about
+how their team is structured or what their numbers look like. If asserted
+as fact without lead-sample evidence, the message sounds like a cold
+SDR reading from a guess.
+
+Signals must also avoid intent certainty. Engagement with a topic proves
+only that the person touched the topic publicly; it does not prove the
+topic is "on their mind," a priority, a budget line, or an active project.
+Use signals as a light reason for sending the note, not as a diagnosis.
+If the natural wording would be `saw you on/around...`, the signal is
+probably better used for targeting than copy.
+
+**Example of a violation** (Ambral winner):
+
+> "Your mid-market and SMB book is where NDR hides — not enough AMs to
+> cover it." — asserts THREE unvalidated facts (book structure, NDR
+> location, staffing deficit) in one sentence, none traced to the row.
+
+**Route.** REJECT. Soften to "Most VPs of CS we talk to see..." pattern
+framing (makes it an industry observation, not an accusation), OR drop
+the assertion entirely and lead with a real signal. Route to
+`revise-message`.
+
+### Filter 3 — Vague-proof filter
+
+**Rule.** Phrases like "multi-billion-dollar enterprises", "Fortune 500
+companies", "leading SaaS", "top scale-ups", or "major brands" without a
+NAMED example are vapor proof. Cold buyers read these and think "name
+one." Vapor proof is worse than no proof — it signals the sender has
+nothing real to point to. Either strip to mechanism-only, or name a
+specific customer (with permission, from the brief's safe-claims).
+
+**Example of a violation** (Ambral winner):
+
+> "We're deploying Ambral Cortex — AI Account Managers — inside
+> multi-billion-dollar enterprises to close exactly that gap." — named
+> customer count: zero.
+
+**Route.** REJECT. Two acceptable rewrites:
+(a) strip the proof line and keep only the mechanism sentence ("It
+detects revenue signals across CRM + Slack + Gong + ZoomInfo and drafts
+QBR follow-ups");
+(b) name a specific customer from the brief's safe-claims list.
+Route to `revise-message` (mechanism exists) or `revise-brief` (brief's
+safe-claims are empty or too weak to name any customer).
+
+### Filter 4 — Read-as-1:1 filter
+
+**Rule.** Explicit gate — could this exact message body be sent
+UNCHANGED to 50 OTHER recipients in the sample and read plausibly to
+each? If yes, the message is broadcast spam dressed up as a 1:1 note.
+Force at least one row-specific reference (post quote, profile phrase,
+hire trigger, named company event) that makes the message meaningfully
+different for THIS recipient.
+
+**Example of a violation** (Ambral winner):
+
+> The entire Ambral Variant A body — opener, mechanism, founder-origin,
+> CTA — could be sent unchanged to every one of the 14 FIT rows and 16
+> non-FIT rows in `lead-sample.json`. Nothing in it points at the
+> specific recipient.
+
+**Route.** REJECT. This is the spam check. Route to `revise-message`
+when `lead-sample.json` carries row-specific signal the draft ignored;
+route to `revise-filter` when the sample genuinely has no row-level
+signal to pull from (the real fix is upstream — find-leads should
+surface post data / hire triggers / visible tools before messaging).
+
+### Filter 5 — Founder-origin coherence filter
+
+**Rule.** If a founder-origin line is included, the IMMEDIATELY-FOLLOWING
+sentence MUST explicitly explain how that experience created the product
+mechanism. The bridge CANNOT be corporate abstraction ("intimacy at
+scale", "operator empathy", "insight at velocity") — it must be a
+CONCRETE mechanism sentence that names an action the product takes or a
+system it connects.
+
+**Example of a violation** (Ambral winner):
+
+> "I woke up at 4am for a year delivering customer breakfasts at Wonder.
+> The intimacy that was impossible to staff at scale is what Cortex
+> does." — the bridge ("intimacy... is what Cortex does") is corporate
+> abstraction; it does NOT tell the reader what Cortex actually does.
+
+**Example that would PASS** (IncidentFox equivalent):
+
+> "I spent 2.5 years on-call at Roblox hunting the same chaos. That's
+> why IncidentFox ships a pod that debugs your network in production,
+> not a dashboard." — the bridge names a concrete mechanism
+> (ships-a-pod, debugs-network-in-pod), tied directly to the prior-role
+> pain.
+
+**Route.** REJECT. Two acceptable rewrites:
+(a) drop the founder-origin line entirely and lead with the mechanism;
+(b) rewrite the bridge to name a concrete action the product takes,
+tied causally to the origin experience.
+Route to `revise-message`.
+
+### Filter 6 — Anti-AI-tell filter
+
+**Rule.** Reject the candidate if the body contains ANY of the
+following AI-tell patterns. These are the signals that make a cold
+message read as "AI-generated from a scrape" instead of "a founder
+typed this about something they're working on."
+
+1. **Date or duration references about the recipient.** Phrases that
+   name a specific date, month, or tenure length on the recipient's
+   timeline — "last month", "yesterday", "six months ago", "six months
+   into your CTO seat", "since 2023", verbatim post dates
+   ("2026-03-16"). Cold operators don't say this. Drop the date or
+   re-cast as a natural callback ("saw your recent post about..." →
+   not "on March 16 you posted...").
+2. **Block-quoted verbatim recipient phrases longer than 4 words
+   inside quotation marks.** Long quote-backs announce that the sender
+   scraped the recipient. Compress to 2-4 words OR paraphrase into
+   natural language ("you wrote about runbook troubleshooters" beats
+   `"deployment fixer and troubleshooter ... runbook troubleshooter"`
+   with the block-quote punctuation).
+3. **Explicit-source-citation phrases.** `"Your bio says"`, `"your
+profile shows"`, `"the post you wrote"`, `"the req you posted"`,
+   `"saw on your LinkedIn"`, `"your X-page mentions"`. These
+   phrases are the prose equivalent of showing your work — humans
+   don't narrate the source of their knowledge when DMing a peer.
+   Drop the source-narration frame; reference the signal as if it
+   were obvious background.
+4. **Stack/feature lists in parentheses.** `"(Datadog / PagerDuty /
+GitHub / AWS)"`, `"(Slack + Linear + GitHub)"`, `"(Stripe,
+HubSpot, Zendesk)"`. Parenthetical tool dumps read as a
+   machine-assembled integration list. Either name ONE relevant tool
+   inline or drop the parenthetical entirely.
+5. **Over-precise numerics that a human wouldn't type.** `"2 Q1 2026
+pilot partners"`, `"spent the last eight years"`, `"three failure
+modes"`, `"27% of our sample"`. Founders write casually: "a couple
+   pilots this quarter", "you've been at this a while", "the same
+   kinds of failures", "about a quarter". Round, hedge, or drop.
+
+**Example of a violation** (IncidentFox rerun-4 winner):
+
+> "Nedko — your BioRender post last month on the internal governance
+> dashboard called out "deployment fixer and troubleshooter" and
+> "runbook troubleshooter" as high-value use cases."
+
+Three tells stacked in one sentence: date reference ("last month"),
+two block-quoted phrases >4 words, and implicit source-citation
+frame ("your BioRender post").
+
+**Natural alternative** (same signal, no tells):
+
+> "Saw you've been writing about runbook troubleshooters and
+> deployment fixers — that's almost exactly the class of work we
+> built the product around."
+
+**Route.** REJECT. Route to `revise-message`.
+
+### Filter 7 — Anti-talk-at filter
+
+**Rule.** The OPENING SENTENCE must not lead with a
+recipient-specific reference. The opener must establish sender
+reality FIRST — what we're building, who we are, why we're reaching
+out — before any callback to the recipient. A "talk-at" opener reads
+like a cold-scraper addressing a target; a "sender-first" opener
+reads like a founder introducing themselves.
+
+**Detection patterns to REJECT as the opener (non-exhaustive):**
+
+- `{{first_name}} — saw you...`
+- `{{first_name}} — your [X]...`
+- `Your [X] is...`
+- `Saw the [X] you posted...`
+- `I noticed your...`
+- `Six months into your...`
+- `Your [company] post last month...`
+- `Just read your [X]...`
+
+Recipient-specific gravity MAY appear in body sentences 2-4 as a
+LIGHT callback (one casual sentence, no verbatim quote, no date
+reference), but never as the lede. The first impression must read
+as "a founder reaching out about something they built" — not
+"someone who scraped me."
+
+**Acceptable opener shapes (sender-first):**
+
+- `Hey {{first_name}}, I'm building [X] — [what it does in one plain
+sentence].`
+- `Hey {{first_name}}, quick one. My co-founder and I left [prior
+role] to build [X].`
+- `Hey {{first_name}}, reaching out because [one-line sender
+context] and [one-line what we're building].`
+- `Hey {{first_name}}, [product] — [one-sentence mechanism].`
+
+Then, sentences 2-4 may include a LIGHT callback to the recipient:
+`"Thought of [company] because..."`, `"Feels relevant to the
+[recipient's area] work you've been doing."`, `"Saw you're working on
+[area]."` (NOT `"saw the [X] you posted on [date]"`.)
+
+**Example of a violation** (IncidentFox rerun-4 winner opener):
+
+> "Nedko — your BioRender post last month on the internal governance
+> dashboard called out [...]"
+
+Opens with recipient reference + date + source citation. Reads as
+"I scraped you." Zero sender context before the first sentence
+ends.
+
+**Natural alternative** (sender-first, light callback in sentence 3):
+
+> "Hey Nedko, my co-founder and I left Roblox to build IncidentFox —
+> an AI SRE that lives in Slack and posts a root-cause hypothesis
+> before a human wakes up.
+>
+> It auto-builds its integrations from your codebase, so deployment
+> goes from "paste the API keys" to "it's already reading your repo."
+>
+> Thought of BioRender because you've been writing publicly about
+> runbook troubleshooters, which is almost exactly the class of
+> work we built around."
+
+Opener establishes who's sending and what they built. The
+recipient callback arrives in sentence 3, paraphrased, no date, no
+block quote.
+
+**Route.** REJECT. Route to `revise-message`.
+
+### Filter 8 — AI-tells filter (catalog-backed)
+
+**Rule.** Reject if the candidate contains any pattern marked
+`REJECT` in the canonical catalog at
+`references/ai-tells.md`. Surface as a warning (do not auto-block)
+if the candidate contains any pattern marked `WARN`.
+
+The canonical catalog lives at
+`mcp/sellable/skills/create-campaign-v2/references/ai-tells.md`. It
+is the single source of truth for all AI-tell patterns. Add new
+tells to that file directly — do NOT bloat this filter spec.
+
+**Mandatory check.** For each candidate in the sample:
+
+1. Read `references/ai-tells.md`.
+2. For each `Tell #N` entry, run the pattern against the candidate
+   body.
+3. If any `REJECT`-severity tell matches, mark the candidate BLOCKED
+   with `Filter 8 — AI-tells (Tell #N: [title])` and move on.
+4. If any `WARN`-severity tell matches, surface in the candidate's
+   Substance Filter gate table but do NOT auto-block.
+5. A candidate blocked by Filter 8 cannot be selected as the winner.
+
+**Note on Filter 3 and Filter 6 overlap.** Several tells in the
+catalog (Tell #3 date refs, Tell #4 block-quotes, Tell #5 source-
+citation, Tell #6 parenthetical stack, Tell #7 over-precise numerics,
+Tell #8 hardcoded signoff, Tell #10 vague-proof) overlap with
+Filters 3 and 6. This is intentional — the catalog is the canonical
+enumeration; Filter 8 is the catalog-driven check. Filters 3 and 6
+remain as human-readable explanations of specific high-priority
+tell classes, but the actual detection logic in Phase-84 reads from
+`ai-tells.md`.
+
+**Adding new tells.** When UAT surfaces a new AI-tell pattern, add
+it as `Tell #N` in `ai-tells.md` with Pattern / Why / Allowed
+alternative / Severity. The next Phase-84 run picks it up
+automatically. Update
+`tests/scripts/skill-references-substance-filters.test.ts` if the
+new tell needs regression coverage.
+
+**Example of a violation** (Plan 05 Patientdesk winner, pre-catalog —
+Tell #1 body-level self-introduction):
+
+> "Hey Bonnie — Oncel here. My co-founders and I ran our own dental
+> call center for two years before building Patientdesk..."
+
+The `"Oncel here."` clause is the Tell #1 pattern. The recipient
+already sees "Oncel Ozgul / Co-founder & CEO @ Patientdesk.ai" from
+the LinkedIn sender strip. Repeating the name in the body adds
+nothing except a template-aroma.
+
+**Acceptable rewrites** (same substance, no Tell #1):
+
+> "Hey Bonnie — pre-Patientdesk, my co-founders and I ran our own
+> dental call center for two years; every missed call was a real
+> number on our P&L."
+
+> "Hey Bonnie — quick one. We built Patientdesk out of running our
+> own dental call center for two years, where every missed call hit
+> the P&L directly."
+
+> "Hey Bonnie — building a thing for group dentistry I think you'd
+> have an opinion on. My co-founders and I ran our own dental call
+> center for two years before this..."
+
+All three open with substance (what we built / the reality that led
+to it) and trust the LinkedIn UI to handle sender identity.
+
+**Route.** REJECT. Route to `revise-message`.
+
+---
+
+Note: filters 1-4 are evaluated PER CANDIDATE. Filter 5 only applies
+when a founder-origin line is present in the candidate. Filters 6, 7,
+and 8 are evaluated PER CANDIDATE and check for AI-tells, talk-at
+openers, and self-introduction tells respectively. A candidate that
+passes all 8 filters plus the Automatic Revisions list may proceed to
+the Finalizer Pass. A candidate that fails any of the 8 is marked
+BLOCKED in the Candidate Messages section (with the filter name
+cited) and cannot be selected as the winner.
+
+## Revision Direction
+
+When the message is weak, decide which layer is actually wrong:
+
+- revise-message
+  - the structure, wording, or CTA is off
+- revise-filter
+  - the signal is too noisy or the sample lead is not a clean buyer
+- revise-brief
+  - the proof boundary or message thesis in `brief.md` is the real problem
+
+Do not patch a weak message by inventing stronger personalization.
+
+## Dry-Mode Discipline
+
+Phase 84 dry mode is validation, not production drafting.
+
+- use only `brief.md`, `lead-filter.md`, and `lead-sample.json`
+- do not fetch new research
+- do not mutate campaign state
+- if the personalization source is missing, remove the token or route back for revision
+- synthesize the structure from the closest archived gold-standard winner
+  before reaching for a generic framework
+- retrieve broadly, but preserve one primary example and borrow from at most one
+  narrow secondary influence
+
+## Plan 85-03 Critique Addendum
+
+These filters are also the gate on any critique rewrite shipped by the
+Plan 85-03 parallel critique protocol (see
+`references/parallel-critique-protocol.md`). When the critique flag is
+on, a rewritten message must still clear:
+
+- every "Automatic Revisions" check above (jargon, resume-list PS, stacked
+  sentences, weak hooks, etc.)
+- the Phase 84 token contract: only supported tokens from the brief, no
+  unresolved `{{token}}`, no invented proof, no personalization that can't
+  be traced to `lead-sample.json`
+- the Phase 84 finalizer pass when `synthesis.enforceFinalizerPass` is
+  `true` (default)
+
+If a rewrite fails any of these, the critique pass falls back to the
+plain generated message for that row. Nothing about these filters
+changes because critique is running; they remain the bar the copy
+must clear before persistence.