@sellable/mcp 0.1.0

package/skills/create-campaign-v2/core/policy.md

@@ -0,0 +1,82 @@
+# Create Campaign v2 Policy
+
+This policy is the invariant layer for the from-scratch v2 orchestrator. Follow
+it even if prompt prose is ambiguous.
+
+## 1) JSON State Machine First
+
+`core/flow.v2.json` is the source of truth for:
+
+- stage order
+- required artifacts
+- produced artifacts
+- allowed tools
+- forbidden tools
+- wait events
+- transitions
+
+`SKILL.md` explains how to execute the flow. It does not replace the flow.
+
+## 2) Net-New Entry Point
+
+Net-new v2 campaign creation starts at:
+
+```text
+bootstrap -> brief-interview
+```
+
+Do not start at `validate-artifacts` unless resuming a compatibility run where
+the complete upstream artifact set already exists.
+
+## 3) No Mutation Before Approval
+
+Before the user explicitly chooses `approve` at the commit gate, do not call:
+
+- `create_campaign`
+- `save_rubrics`
+- `import_leads`
+- `confirm_lead_list`
+- `update_campaign`
+- `queue_cells`
+- `start_campaign`
+
+Customer roleplay critique is advisory only. It cannot approve a campaign.
+
+## 4) Artifact Gates
+
+Do not run a downstream stage until the active step's `requiredArtifacts` exist.
+Intermediate user-review gates are interrupt-only: auto-continue when an
+artifact is confirmed and no strategic tradeoff is present. The final commit
+gate is the only mandatory pre-mint approval gate.
+
+The minimum pre-approval chain is:
+
+```text
+brief-v1.md / brief.md
+lead-review.md
+lead-sample.json
+lead-filter.md
+message-prep.md (optional)
+message-candidate-drafts.md (optional, generated from find-leads basis rows)
+message-validation.md
+approval-packet.md
+commit-gate-decision.md
+```
+
+## 5) Revision Routing
+
+Revision choices route back to the exact upstream stage:
+
+- `revise-brief` -> `brief-interview`
+- `revise-leads` -> `find-leads`
+- `revise-rubric` -> `filter-rubric`
+- `revise-messaging` -> `message-generation`
+- `abort` -> stop with zero DB mutation
+
+## 6) Post-Approval Tail
+
+After `approve`, mint atomically with `create_campaign` and `save_rubrics`.
+Only then surface the watch link and continue the cascade-driven tail.
+
+The tail stops at `awaiting-user-greenlight`. Never call `start_campaign`
+inside the autonomous tail.

package/skills/create-campaign-v2/references/ai-tells.md

@@ -0,0 +1,253 @@
+# AI Tells — Canonical List
+
+These are the patterns that make a cold message read as AI-generated,
+not human-written. The message-validation Substance Filter 8 enforces
+against this list. Add new tells here as we surface them in UAT — do
+NOT bloat the filter itself.
+
+Each tell has:
+
+- **Pattern** — what to detect (regex-friendly description)
+- **Why it's an AI tell** — the human-reasoning explanation
+- **Allowed alternative** — what a hand-written message would do
+  instead
+- **Severity** — `REJECT` (block message) or `WARN` (surface in
+  audit, do not auto-block)
+
+## Tell #1 — Body-level self-introduction
+
+**Pattern:** `{{sender_first_name}} here.` / `Hey {{first_name}} —
+{{sender_name}} here.` / `I'm {{sender_name}}` / `I'm the founder of
+{{company}}` / sender-identification opening sentences.
+
+**Why it's an AI tell:** Recipient sees who sent the message from
+the LinkedIn UI (sender name + photo + headline at the top of the
+thread). Body-level self-intro signals "I'm an automation that
+doesn't know what UI you're reading me in." Real humans don't
+introduce themselves in cold InMail — they open with substance.
+
+**Allowed alternative:** Open directly with substance — `"Hey Bonnie
+— pre-Patientdesk we ran our own dental call center for two
+years..."` Or `"Hey Bonnie — building a thing for group dentistry I
+think you'd have an opinion on..."`
+
+**Severity:** REJECT
+
+## Tell #2 — Explicit recipient-fact reference in opener
+
+**Pattern:** `Hey {{first_name}} — saw you posted...` / `Hey
+{{first_name}}, your X is...` / `I noticed your...` / `Saw the X you
+posted...` — opening sentence leads with a recipient-specific
+reference.
+
+**Why it's an AI tell:** Talking AT the recipient instead of WITH
+them. Real founders open with their own reality, not by
+interrogating the recipient's data feed. `"I noticed your..."` reads
+as scraped intel.
+
+**Allowed alternative:** Open with sender reality (Block 1); let
+recipient gravity show up in Block 3 as a LIGHT callback. Refer to
+their work CASUALLY without `"saw your X"`.
+
+**Severity:** REJECT
+
+## Tell #3 — Explicit date or duration references about the recipient
+
+**Pattern:** `"last month"`, `"yesterday"`, `"X months ago"`, `"six
+months into"`, `"since YYYY"`, verbatim post-dates (`"2026-03-16"`),
+tenure-clocking (`"six months into your CTO seat"`).
+
+**Why it's an AI tell:** Humans don't track when someone posted to
+within 30 days. Date precision = data scraping. Tenure clocking is
+creepy.
+
+**Allowed alternative:** `"Saw you've been thinking about X
+recently"` (no date); `"you've been at this a while"` (no number);
+skip the timestamp entirely.
+
+**Severity:** REJECT
+
+## Tell #4 — Block-quoted verbatim recipient phrases
+
+**Pattern:** Direct quotation marks around recipient's own words
+longer than 4 words. E.g. `"Built SRE practice from scratch
+supporting $0→$40M ARR growth"` inside the message body.
+
+**Why it's an AI tell:** Real humans paraphrase or allude to what
+someone said — they don't quote it back like a citation. Block
+quotes scream "I scraped your profile and pasted the relevant
+phrase."
+
+**Allowed alternative:** Paraphrase the gist — `"you've spent years
+building SRE from zero at scaling SaaS"`; reference the IDEA, not
+the wording.
+
+**Severity:** REJECT
+
+## Tell #5 — Explicit-source-citation phrases
+
+**Pattern:** `"your bio says..."`, `"your profile shows..."`, `"the
+post you wrote"`, `"the req you posted"`, `"saw on your LinkedIn"`,
+`"your X-page mentions"`.
+
+**Why it's an AI tell:** Hand-writing a message means you mention
+the company or project naturally — you don't cite `"your bio"` as a
+source. Citation-shape phrasing is a template leak.
+
+**Allowed alternative:** Refer to their work or company directly
+without naming the source.
+
+**Severity:** REJECT
+
+## Tell #6 — Stack/feature lists in parentheses
+
+**Pattern:** `(Datadog / PagerDuty / GitHub / AWS)` —
+parenthetical-wrapped feature/stack dump.
+
+**Why it's an AI tell:** Reads as marketing copy. Real founders
+mention 1-2 named tools casually, in flow, not as a parenthetical
+list.
+
+**Allowed alternative:** `"hooks itself into your stack"`
+(mechanism, no list); or weave 1-2 names naturally — `"plugs into
+Datadog and PagerDuty without setup"`.
+
+**Severity:** WARN (slashes inline in flow are tolerable;
+parenthetical-wrapped lists are not)
+
+## Tell #7 — Over-precise formal numerics
+
+**Pattern:** `"2 Q1 2026 pilot partners"`, `"spent the last eight
+years"`, `"over 60+ clinics"`, `"Founded in 2024"`, `"27% of our
+sample"`, `"three failure modes"`.
+
+**Why it's an AI tell:** Spec-sheet specificity in a casual message.
+Real humans say `"a couple this quarter"`, `"you've been at this a
+while"`, `"dozens of clinics"`.
+
+**Allowed alternative:** Casual quantifiers — `"a couple"`, `"a
+few"`, `"dozens"`, `"a while"`.
+
+**Severity:** WARN (REJECT if multiple in one message)
+
+## Tell #8 — Hardcoded signoff line
+
+**Pattern:** Trailing `— {{sender_name}}` line, `Best, {{sender
+_name}}`, `Cheers, {{sender_name}}`, `{{sender_name}}, co-founder at
+{{company}}` as the last line.
+
+**Why it's an AI tell:** Multi-sender pipelines hardcode breaks.
+Recipient sees who sent it from LinkedIn UI. Body signoff is
+redundant + brittle.
+
+**Allowed alternative:** No signoff. Message ends with the CTA.
+
+**Severity:** REJECT
+
+## Tell #9 — Founder-credibility flex without mechanism bridge
+
+**Pattern:** Founder-origin sentence (`"I spent two years at X"`)
+that does NOT immediately connect to the product mechanism. Pure
+pedigree-flex.
+
+**Why it's an AI tell:** A real founder mentions their background
+only when it directly explains WHY the product works. Pure flex =
+template.
+
+**Allowed alternative:** Founder-origin sentence MUST be immediately
+followed by a mechanism explanation — `"Long was on Roblox App/DB
+Infra → that's why IncidentFox auto-builds integrations from your
+codebase"`.
+
+**Severity:** REJECT
+
+## Tell #10 — Vague-proof brags without named example
+
+**Pattern:** `"multi-billion-dollar enterprises"`, `"Fortune 500"`,
+`"leading SaaS"`, `"top scale-ups"`, `"trusted by leaders"` —
+without naming a specific customer.
+
+**Why it's an AI tell:** Vapor proof = worse than no proof. Buyers
+immediately think "name one."
+
+**Allowed alternative:** Either name a logo (with permission) or
+strip to mechanism-only.
+
+**Severity:** REJECT
+
+## Tell #11 — Formal CTA phrasing
+
+**Pattern:** `"Worth a 20-min walkthrough?"`, `"Open to a brief
+call?"`, `"Could I book some time on your calendar?"`.
+
+**Why it's an AI tell:** Corporate cadence. Real founders write
+casually — `"Worth 20?"`, `"Quick call this week or next?"`, `"20
+min sometime?"`.
+
+**Allowed alternative:** Casual founder cadence; under 8 words
+preferred.
+
+**Severity:** WARN
+
+## Tell #12 — Reusable opener that fits any recipient
+
+**Pattern:** Opening sentence has zero row-specific detail and could
+be sent unchanged to any of 50 recipients in the sample.
+
+**Why it's an AI tell:** Broadcast spam. Real cold InMail earns its
+right to the inbox with at least one row-specific reference.
+
+**Allowed alternative:** At least one line in the body must
+reference something verifiable about THIS recipient (project, role,
+company, recent work).
+
+**Severity:** REJECT
+
+## Tell #13 — Em dash in message body
+
+**Pattern:** Any U+2014 em dash character (`—`) anywhere in the
+message body text. Includes em dashes used as parenthetical pauses
+(`"works best for the exact hire you're in the middle of — founding
+engineer, has to ship..."`), em dashes joining two independent
+clauses, and em dashes wrapping an appositive phrase.
+
+**Why it's an AI tell:** Em dashes are the single most reliable
+signature of LLM-generated prose in casual-founder text. Real
+founders typing a cold InMail on a phone or desktop almost never
+reach for an em dash — they use commas, periods, parentheses, or
+a hyphen-minus (`-`) when they want a pause. LLMs default to em
+dashes for rhythm because they were trained on edited published
+prose where em dashes are frequent. A message with even ONE em dash
+reads as AI-polished, not hand-typed. Surfaced during Phase 94
+Skillsync run (Plan 07): generator self-declared "NO em dashes" as
+an invariant but still emitted one in the Selected Winner's Block
+2 because the catalog did not yet codify the pattern.
+
+**Allowed alternative:** Use commas, periods (break into two
+sentences), parentheses, or a hyphen-minus (`-`) for pauses. If the
+thought needs dashes to feel right, rewrite as two short sentences.
+Example — instead of `"works best for the exact hire you're in the
+middle of — founding engineer, has to ship production day one"`,
+write `"works best for the exact hire you're making. founding
+engineer, ships production day one."`.
+
+**Severity:** REJECT
+
+**Note:** This tell applies ONLY to the message body. Em dashes in
+reference-file text, brief-template text, prompt text, and audit
+notes are fine — this is a body-level output guard, not a
+general-prose style rule.
+
+---
+
+## How to add new tells
+
+1. Surface the tell during UAT — it must be a pattern we saw in an
+   actual generated message that read as AI-written.
+2. Name it `Tell #N` with a short descriptive title.
+3. Fill in Pattern / Why / Allowed alternative / Severity.
+4. The Filter 8 check automatically picks it up — do not touch
+   `thomas-revision-filters.md` Filter 8 spec when adding tells.
+5. Add a corresponding test case in
+   `tests/scripts/skill-references-substance-filters.test.ts` if
+   the new tell needs regression coverage.

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

@@ -0,0 +1,346 @@
+# Approval Gate Framing
+
+This reference governs the commit gate in create-campaign-v2. Load this file
+before showing the user the approval packet at the end of Phase 84 and before
+minting a real `CampaignOffer`.
+
+## Purpose
+
+The approval gate is the **only** place in create-campaign-v2 where the user
+authorizes a DB mutation. Everything upstream (Phase 83 brief + Phase 84
+validation artifacts) is file-only. Everything downstream (atomic mint +
+autonomous tail) is live campaign state.
+
+No campaign row exists until the user picks `approve`.
+
+## Preconditions
+
+Before showing the commit gate, the draft directory must contain all of:
+
+- `brief.md`
+- `lead-review.md`
+- `lead-sample.json`
+- `lead-filter.md`
+- `message-validation.md`
+- `approval-packet.md`
+
+The current run must also have retrieved the real message-generation prompt
+through `get_message_prompt({ promptName: "generate-messages" })` or
+`get_subskill_prompt({ subskillName: "generate-messages" })` before
+`message-validation.md`, `approval-packet.md`, or the commit gate is written.
+If the message template was written directly from memory or planning artifacts,
+do not show the commit gate; route back to message generation.
+
+`rubric.json` is optional but strongly preferred — when missing, derive it from
+`lead-filter.md` in the atomic mint step.
+
+`lead-source-intake.json` is optional for normal discovery and required when
+the user intentionally supplied a source. If present, the approval packet must
+summarize the source type, input mode, supplied profile/domain/list count,
+sampled count, what will be materialized after approval, and that only the
+review batch will be enriched/messaged before greenlight.
+Use the phrase "only the review batch" plainly enough that the operator
+understands approval is not permission to process the full supplied source.
+
+If any required artifact is missing, do NOT show the gate. Route back to the
+first missing step instead.
+
+### Workspace + sender invariant (Step 0, before any commit-gate action)
+
+Before showing the gate OR running any approve-path tool, verify the
+**workspace/sender invariant**:
+
+- The sender configured in the committed `CampaignOffer` draft resolves
+  inside the currently-authenticated workspace.
+- The active Sellable-auth workspace matches the workspace the draft
+  directory was written in (prevents cross-workspace mint drift).
+
+This invariant is identical to the Phase 84 "sender/workspace mismatch
+= abort" rule and the global memory rule `CRITICAL: Never Send Messages
+From Wrong Workspace`. If the invariant fails:
+
+1. Do NOT show the commit gate.
+2. Do NOT call `bootstrap_create_campaign`, `create_campaign`, or
+   `save_rubrics`.
+3. Surface an explicit workspace/sender-mismatch error + the detected
+   current-workspace vs expected-workspace diagnostic.
+4. Leave the draft directory intact; a fresh session in the correct
+   workspace can resume from where this one aborted.
+
+The invariant is a hard stop, not an escalation in the Plan 85-02 sense.
+
+## Anchor Validation
+
+Before showing the gate, walk the required artifacts and confirm anchors are
+populated:
+
+- `brief.md` has a non-empty `## Message Thesis` section
+- `lead-review.md` has a `Status` of `confirmed` (not `rejected` or `unclear`)
+- `lead-sample.json` parses and contains at least one lead row
+- `lead-filter.md` has `Decision`, `Who We'll Keep`, `Who We'll Exclude`,
+  `Required Keep Rules`, `Required Exclude Rules`, `Pass Rate`,
+  `Recommendation`, and `Implementation Details` sections
+- `message-validation.md` has `Status: confirmed`, `Mode: DRY MODE (no DB mutation)`,
+  a `Selected Winner`, and a non-empty `Token Adherence Table`
+
+An empty anchor blocks `approve`. The user can still pick a revision choice.
+
+## Approval Packet
+
+Build the approval packet in user-facing order and write it to
+`approval-packet.md` before the gate is shown. The file is the exact packet the
+user is approving, not a private scratch note.
+
+When rendering the approval packet inline for the customer, start it with
+exactly:
+
+```text
+Status: approval-packet
+```
+
+The same assistant turn must then call `AskUserQuestion` with the six commit
+choices. Do not show a standalone commit-gate question in a later turn without
+the approval packet above it.
+
+The packet should read like an AI GTM engineer explaining the campaign, not an
+internal validation report. Start with the practical direction in plain
+language: who we will contact, why this buyer should care, what lead source we
+will use, what the first message says, and what happens if the user approves.
+Keep implementation details available, but move them below the customer-facing
+summary.
+
+1. **brief** — `brief.md` thesis, product, ICP, offer
+2. **lead sample** — first 5-10 rows from `lead-sample.json` rendered as
+   `Name / Title / Company` lines, plus the `lead-review.md` pass-rate
+   and supplied-source framing when `lead-source-intake.json` exists:
+   supplied people list, existing Sellable lead list, or supplied account list
+   plus people search
+3. **lead filter** — the `Decision`, `Who We'll Keep`, `Who We'll Exclude`,
+   `Pass Rate`, and `Recommendation` blocks from `lead-filter.md`; keep
+   rubric internals in `Implementation Details` unless the user asks to inspect
+   the saved filter criteria
+4. **message validation** — the `Selected Winner` from `message-validation.md`,
+   rendered as it will appear in the outbound, plus the `Findings` + `Recommendation`
+
+The packet must include a dedicated `## Message Review` section immediately
+before `## Approved Message Template`. This is the customer-facing messaging
+gate. It should not be a raw validation dump; it should answer:
+
+- `Verdict:` strong / usable-but-could-improve / needs-revision
+- `What works:` why the message is likely to earn replies
+- `What I would improve before launch:` the biggest remaining concern, or
+  `none` if it is ready
+- `Recommendation:` approve-message / revise-messaging
+
+If the validation says `revise-message`, do not bury that in caveats. Show the
+draft if useful, mark `Recommendation: revise-messaging`, and route the user to
+the `revise-messaging` commit-gate option instead of implying the campaign is
+ready.
+
+If `message-validation.md` has an extractable `Selected Winner`, the packet's
+`## Approved Message Template` must use that winner exactly, except for
+supported prospect-row `{{tokens}}`. Do not write a fresh approval-template
+message from the brief. If no winner/template can be extracted, this exact-match
+gate is skipped, but the packet still needs a usable approved template unless
+the user explicitly chose AI-generated messages.
+
+Do NOT render the packet as a bundle of opaque validation anchors or a dump
+of raw JSON. The user is approving a live campaign — they need to see what
+they are approving.
+
+Do NOT use opaque words like `anchor`, `chosen lane`, `validation artifact`,
+or `provider path` in the top customer-facing section. Use plain labels:
+target prospects, lead source, expected usable leads, filters, message, risks,
+and next step.
+
+If a customer/operator roleplay pass is run before the gate, write its critique
+to `customer-roleplay.md`. That critique is advisory only. A positive roleplay
+result is not approval and must not trigger `create_campaign`,
+`save_rubrics`, or any other DB mutation.
+
+After the user/operator chooses, write `commit-gate-decision.md` with exactly
+one of the six allowed choices plus a short reason. This file is the durable
+authorization record for the branch taken. Only `Decision: approve` authorizes
+atomic mint.
+
+### Packet framing rule (never say "anchor")
+
+The user-visible packet MUST use the product-facing section names:
+
+- **brief**
+- **lead sample**
+- **lead filter**
+- **messages** (or **message validation** when emphasizing the validation mode)
+
+The internal skill vocabulary uses "anchor validation" to describe the
+presence/non-emptiness checks in §Anchor Validation above — that's fine for
+internal skill state. But the USER-FACING packet MUST NOT use "anchor,"
+"validation anchor," "draft anchor," or any other anchor-prefixed term.
+"Anchor" is an implementation word; it reads as opaque to operators.
+
+Example — correct vs incorrect packet headers:
+
+| Correct (product-facing)                    | Incorrect (opaque anchor framing)                    |
+| ------------------------------------------- | ---------------------------------------------------- |
+| "Here's the **brief** you're about to ship" | "Here's the **brief anchor** in the draft directory" |
+| "The **lead sample** shows 10 top rows"     | "The **lead-sample anchor** validates"               |
+| "**Messages** — winner from 3 candidates"   | "**Message-validation anchor** Status: confirmed"    |
+
+## Commit Gate Choices
+
+The gate offers exactly these 6 choices, in this order:
+
+```text
+approve
+revise-brief
+revise-leads
+revise-rubric
+revise-messaging
+abort
+```
+
+Use `AskUserQuestion` with these 6 options. Do not collapse, reorder, or add
+choices. Do not auto-select.
+
+If the host UI limits options per question, preserve all six routes with a
+two-question gate instead of mentioning implementation limits:
+
+1. Decision: `approve`, `revise`, `abort`
+2. Revise route: `revise-brief`, `revise-leads`, `revise-rubric`,
+   `revise-messaging`
+
+In this split form, `revise` is not a seventh route; it is only the parent
+choice that activates the second question.
+
+## Choice Semantics
+
+### `approve`
+
+User authorizes atomic mint. Proceed to the atomic-mint step:
+
+0. **verify workspace/sender invariant** (see §Preconditions) — if the
+   invariant fails, abort BEFORE `bootstrap_create_campaign`
+1. `bootstrap_create_campaign({ flowVersion: "v2" })`
+2. `create_campaign({ campaignBrief, currentStep: "auto-execute-leads" })`
+   → capture `{ campaignId, watchUrl }` from response
+3. `save_rubrics({ campaignOfferId, rubric })` using `rubric.json` (or derived
+   payload from `lead-filter.md`)
+4. flip brief status to `committed`; move draft to `.committed/`
+5. surface the watch link using `watch-link-handoff.md`
+6. hand off to the autonomous tail (Plan 85-02)
+
+See `watch-link-handoff.md` for the exact link-surfacing protocol and the
+partial-mint recovery rules.
+
+### `save_rubrics` partial-mint recovery preference
+
+When `create_campaign` succeeds but `save_rubrics` fails, the recovery
+path preference is **recoverable-failure state + explicit retry**, NOT
+rollback of the CampaignOffer row.
+
+Rationale:
+
+- `save_rubrics` is idempotent — the operator can retry the same call
+  without duplicating state.
+- The operator may want to inspect the in-flight campaign row (via the
+  watch link) before deciding whether to retry or abort.
+- Rollback would destroy a useful artifact (the minted campaign row +
+  persisted brief) that the operator may want to keep while
+  debugging the rubric save.
+
+Implementation:
+
+1. Do NOT call the delete path on the CampaignOffer row.
+2. Mark the campaign in a `currentStep` state that the skill can
+   detect on resume (e.g. `auto-execute-leads-rubric-pending`).
+3. Surface the failure with the specific error + retry instructions.
+4. Do NOT surface the watch link until `save_rubrics` succeeds — per
+   `watch-link-handoff.md` §Partial-Mint Recovery, the link points
+   at a live, fully-minted campaign; a half-minted one is misleading.
+5. On retry, call `save_rubrics` again with the same payload. If it
+   succeeds, the tail resumes normally.
+
+Rollback remains available as an operator-driven escape hatch via the
+`abort` gate choice on resume — but the default recovery is NOT
+automatic rollback.
+
+### `revise-brief`
+
+Route back to Phase 83 or Phase 84 depending on what the user wants to change.
+Do NOT mint a campaign. Do NOT print a watch link.
+
+Draft effect: preserve nothing by default; the brief itself is usually
+rewritten upstream. Delete all downstream artifacts so Phase 84 will re-run:
+
+- delete `lead-review.md`
+- delete `lead-sample.json`
+- delete `lead-filter.md`
+- delete `message-validation.md`
+- delete `rubric.json` if present
+
+### `revise-leads`
+
+Route back to Phase 84 `find leads`. Do NOT mint a campaign. Do NOT print a
+watch link.
+
+Draft effect:
+
+- preserve `brief.md`
+- delete `lead-review.md`
+- delete `lead-sample.json`
+- delete `lead-filter.md`
+- delete `message-validation.md`
+- delete `rubric.json` if present
+
+### `revise-rubric`
+
+Route back to Phase 84 `filter leads`. Do NOT mint a campaign. Do NOT print a
+watch link.
+
+Draft effect:
+
+- preserve `brief.md`
+- preserve `lead-review.md`
+- preserve `lead-sample.json`
+- delete `lead-filter.md`
+- delete `message-validation.md`
+- delete `rubric.json` if present
+
+### `revise-messaging`
+
+Route back to Phase 84 `generate message`. Do NOT mint a campaign. Do NOT
+print a watch link.
+
+Draft effect:
+
+- preserve `brief.md`
+- preserve `lead-review.md`
+- preserve `lead-sample.json`
+- preserve `lead-filter.md`
+- delete `message-validation.md`
+- preserve `rubric.json` if present
+
+### `abort`
+
+User cancels the session. Do NOT mint a campaign. Do NOT print a watch link.
+
+Draft effect: move the draft directory to
+`.sellable/create-campaign-v2/drafts/{workspace-slug}/.aborted/{campaign-slug}-{timestamp}/`.
+No DB rows touched. No `CampaignOffer` created.
+
+## Hard Rules
+
+- The user's `approve` choice is the **only** trigger for live DB mutation.
+- A positive `customer-roleplay.md` critique is not approval and produces zero
+  DB mutation unless `commit-gate-decision.md` explicitly says
+  `Decision: approve`.
+- The commit gate must not call `create_campaign`, `save_rubrics`,
+  `import_leads`, `update_campaign`, or any other mutating tool before the
+  user picks a choice.
+- `import_leads` is **not** part of atomic mint. Full sourcing/import happens
+  in Plan 85-02 Step 13 after mint.
+- Revision choices produce ZERO DB rows.
+- Aborting produces ZERO DB rows.
+- A failed `approve` path (e.g. `create_campaign` errors, or `save_rubrics`
+  fails after campaign creation) does NOT surface a watch link. See
+  `watch-link-handoff.md` for the partial-mint recovery protocol.