Stop pretending submit still matches (#5)

#1 put the review gate in the right place, in autoPair, and then left both
submit surfaces carrying copy for outcomes they can no longer reach. A fresh
listing is pending_review, autoPair refuses anything that is not active, so
matched, first_in_category and no_eligible_partner became unobservable from
the submit path and a fourth branch was added alongside them.

The call is gone from both surfaces instead. describeAutoPair is deleted,
the four-way ternary in tools.ts is one sentence, and CommitState.matched
goes with them, along with the PartyPopper the panel showed when a submit
came back already matched. Nothing comes back already matched now.

Renamed the reason from pending_review to not_active. paused, rejected and
banned take the same branch, so the old name was wrong three ways out of
four.

setSiteStatus now logs what autoPair returned. It is the only caller left,
so an unlogged return meant nothing anywhere observed whether approving a
site actually matched it, and "I approved them and they never heard
anything" had no trail to follow.

Headers updated where they described the old flow, including the matches.ts
one that claimed the digest cron calls autoPair. It does not, and has not:
it runs its own candidate query because it shows several masked candidates
rather than proposing one match.

typecheck, lint, 42 tests and prettier --check pass.


Claude-Session: https://claude.ai/code/session_01TytxW7wT52Miy394hDeh9V

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: nicklaunches

next-app/src/app/submit/actions.ts

@@ -4,7 +4,6 @@ import { createHmac, timingSafeEqual } from "node:crypto";
 
 import type { Category } from "@/lib/categories";
 import { AnalyzeError } from "@/lib/contracts";
-import { autoPair } from "@/lib/services/matches";
 import { SiteError, commitSite, draftSite } from "@/lib/services/sites";
 import { getSessionMember } from "@/lib/session";
 
@@ -14,25 +13,23 @@ import { getSessionMember } from "@/lib/session";
  * These two actions are deliberately the same shape as the one tool: call
  * `draftSiteAction` first and nothing is written, call `commitSiteAction` only
  * after a human has read the drafted words. Both call the exact same service
- * functions (`draftSite`, `commitSite`, `autoPair`) in the exact same order as
+ * functions (`draftSite`, `commitSite`) in the exact same order as
  * `src/lib/mcp/tools.ts`, and the error text is copied from `explain()` there.
  * If the two ever say different things about the same failure, one of the two
  * interfaces has started to drift and the agent one is supposed to be
  * first-class.
  *
- * Two places the web path is deliberately NOT identical, both in failure
- * handling rather than behaviour:
+ * Neither surface pairs on submit. `autoPair` refuses anything that is not
+ * `active` and a listing is `pending_review` until review clears it, so both
+ * used to carry copy for four outcomes when only one was reachable. The call is
+ * gone from both; matching happens at approval, in `setSiteStatus`.
  *
- *   1. Domain Rating is signed between the two steps (see `signDraft`). The MCP
- *      tool re-derives it from a draft it holds in memory; a browser has to
- *      round-trip it through a form field, and DR is a public number partners
- *      judge on, so a hand-edited hidden input must not be able to inflate it.
- *      A bad signature drops the score to null rather than failing the submit.
- *   2. A failure inside `autoPair` after the listing is written is reported as
- *      "listed, matching will run shortly" rather than as an error. The tool
- *      lets it throw, which on the web would leave the member staring at an
- *      error for a site that is in fact listed, and resubmitting into a
- *      `domain_taken`.
+ * One place the web path is deliberately NOT identical: Domain Rating is signed
+ * between the two steps (see `signDraft`). The MCP tool re-derives it from a
+ * draft it holds in memory; a browser has to round-trip it through a form field,
+ * and DR is a public number partners judge on, so a hand-edited hidden input
+ * must not be able to inflate it. A bad signature drops the score to null rather
+ * than failing the submit.
  */
 
 // ---------------------------------------------------------------------------
@@ -172,11 +169,22 @@ export type CommitState =
           domain: string;
           /** "yourapp.com is listed and pending review." */
           headline: string;
-          /** The auto-pair outcome, in plain words. Never empty. */
+          /** What happens next, in plain words. Never empty. */
           outcome: string;
-          matched: boolean;
       };
 
+/**
+ * What happens next, in the same words the `submit_site` tool uses.
+ *
+ * A constant rather than a computed sentence: nothing is matched at submit any
+ * more, so there is no per-submission outcome left to describe. Kept in the
+ * state object anyway, because the panel that renders it does not need to know
+ * that, and the day matching says something per-submission again this is where
+ * it goes.
+ */
+const PENDING_REVIEW_OUTCOME =
+    "A human reads the listing, usually the same day. Matching runs the moment it is approved, and if a partner is waiting in your category you will hear by email right then.";
+
 /**
  * Splits the anchors textarea into keywords.
  *
@@ -192,7 +200,12 @@ function parseKeywords(raw: string): string[] {
 }
 
 /**
- * Writes the confirmed listing and immediately looks for a partner.
+ * Writes the confirmed listing.
+ *
+ * It used to look for a partner here too. It no longer does: `autoPair` pairs
+ * nothing that is not `active`, and a listing is `pending_review` until a human
+ * clears it, so the call could only ever have come back empty. Matching happens
+ * at approval, in `setSiteStatus`.
  *
  * @param _previous - Previous action state, unused.
  * @param formData - The confirmation form, including the signed draft fields.
@@ -221,14 +234,11 @@ export async function commitSiteAction(_previous: CommitState, formData: FormDat
             domainRating,
         });
 
-        const pairing = await describeAutoPair(site);
-
         return {
             status: "done",
             domain: site.domain,
             headline: `${site.domain} is listed and pending review.`,
-            outcome: pairing.outcome,
-            matched: pairing.matched,
+            outcome: PENDING_REVIEW_OUTCOME,
         };
     } catch (err) {
         if (err instanceof SiteError) {
@@ -250,47 +260,3 @@ export async function commitSiteAction(_previous: CommitState, formData: FormDat
         };
     }
 }
-
-/**
- * Runs instant matching and turns the result into the same three sentences the
- * `submit_site` tool returns.
- *
- * Never throws: the listing is already written by the time this runs, and an
- * error here must not be reported as a failed submission.
- */
-async function describeAutoPair(site: Parameters<typeof autoPair>[0]): Promise<{ outcome: string; matched: boolean }> {
-    try {
-        const pair = await autoPair(site);
-        if (pair.matched) {
-            const dr = pair.partner.domainRating ?? "unrated";
-            return {
-                matched: true,
-                outcome: `You already have a match: ${pair.partner.category}, DR ${dr}. It is waiting for you to accept or decline.`,
-            };
-        }
-        if (pair.reason === "pending_review") {
-            return {
-                matched: false,
-                outcome:
-                    "Matching starts the moment a human approves the listing. If a partner is waiting in your category, you will hear by email right then.",
-            };
-        }
-        if (pair.reason === "first_in_category") {
-            return {
-                matched: false,
-                outcome: `You are the first site in ${pair.category}. That is a good position: the next member to join it is matched with you immediately.`,
-            };
-        }
-        return {
-            matched: false,
-            outcome: "No partner available right now. You will be matched as soon as a suitable one joins.",
-        };
-    } catch (err) {
-        console.error("submit: autoPair failed after commit", err);
-        return {
-            matched: false,
-            outcome:
-                "Your listing is saved. Matching could not run just now, so it will run on the next sweep instead.",
-        };
-    }
-}

next-app/src/app/submit/page.tsx

@@ -11,8 +11,8 @@ import { getSessionMember } from "@/lib/session";
  *
  * The whole architecture rests on both interfaces calling the same services, so
  * this page contains no listing logic at all: it resolves the session, and the
- * server actions in `./actions.ts` call `draftSite`, `commitSite`, and
- * `autoPair` in the same order the tool does.
+ * server actions in `./actions.ts` call `draftSite` and `commitSite` in the same
+ * order the tool does. Neither pairs on submit; matching runs at approval.
  *
  * A URL typed into the landing page's fallback form is carried through the
  * sign-in round trip in `callbackUrl`, so someone who is signed out never has

next-app/src/app/submit/review-form.tsx

@@ -1,6 +1,6 @@
 "use client";
 
-import { AlertTriangle, ArrowRight, CheckCircle2, EyeOff, Loader2, PartyPopper } from "lucide-react";
+import { AlertTriangle, ArrowRight, CheckCircle2, EyeOff, Loader2 } from "lucide-react";
 import Link from "next/link";
 import { useActionState, useId, useState } from "react";
 
@@ -321,21 +321,23 @@ export function ReviewForm({ draft, onStartOver }: ReviewFormProps) {
             </div>
 
             <p aria-live="polite" className="sr-only">
-                {pending ? "Listing your site and looking for a partner." : ""}
+                {pending ? "Listing your site." : ""}
             </p>
         </form>
     );
 }
 
 const SIGNED_OUT = "Your session expired before we could save this. Sign in again and resubmit, nothing was written.";
 
+// One icon, not two. This used to celebrate with a PartyPopper when the submit
+// call came back already matched, which cannot happen any more: nothing is
+// matched until review clears the listing. The celebration belongs on whatever
+// surface tells a member they have a match, not on the one that says "received".
 function SubmittedPanel({ state }: { state: Extract<CommitState, { status: "done" }> }) {
-    const Icon = state.matched ? PartyPopper : CheckCircle2;
-
     return (
         <section className="border-accent/35 bg-accent-soft rounded-sm border p-6 sm:p-8" aria-live="polite">
             <span className="border-line bg-surface text-accent mb-4 inline-flex size-10 items-center justify-center rounded-sm border">
-                <Icon aria-hidden="true" className="size-5" />
+                <CheckCircle2 aria-hidden="true" className="size-5" />
             </span>
 
             <h2 className="text-[1.35rem] font-semibold tracking-[-0.02em]">{state.headline}</h2>

next-app/src/lib/mcp/tools.ts

@@ -8,7 +8,7 @@ import { PLACEMENT_OFFERS } from "@/lib/exchange";
 import { RateLimited, enforceToolLimit } from "@/lib/mcp/limits";
 import { getCategoryDepths, getRules } from "@/lib/services/catalog";
 import { LinkError, checkLinks, getLinkBrief, getStanding, markLinkPlaced } from "@/lib/services/links";
-import { MatchError, autoPair, listMatches, respondToMatch, searchPartners } from "@/lib/services/matches";
+import { MatchError, listMatches, respondToMatch, searchPartners } from "@/lib/services/matches";
 import { SiteError, commitSite, draftSite, listMySites } from "@/lib/services/sites";
 
 /**
@@ -277,16 +277,14 @@ export function registerTools(server: McpServer, ctx: ToolContext): void {
                 domainRating: draft.domainRating,
             });
 
-            const pair = await autoPair(site);
-            const tail = pair.matched
-                ? `\n\nYou already have a match: ${pair.partner.category}, DR ${pair.partner.domainRating ?? "unrated"}. Say "show my matches" to see it.`
-                : pair.reason === "pending_review"
-                  ? "\n\nMatching starts the moment a human approves the listing. If a partner is waiting in your category, you will hear by email right then."
-                  : pair.reason === "first_in_category"
-                    ? `\n\nYou are the first site in ${pair.category}. That is a good position: the next member to join it is matched with you immediately.`
-                    : "\n\nNo partner available right now. You will be matched as soon as a suitable one joins.";
-
-            return text(`${site.domain} is listed and pending review.${tail}`);
+            // No pairing call here. `autoPair` refuses anything that is not
+            // `active` and a fresh listing is `pending_review`, so calling it
+            // would do nothing but return a reason. Matching happens at
+            // approval, in `setSiteStatus`.
+            return text(
+                `${site.domain} is listed and pending review.` +
+                    "\n\nA human reads the listing, usually the same day. Matching runs the moment it is approved, and if a partner is waiting in your category the member hears by email right then.",
+            );
         }),
     );
 

next-app/src/lib/services/matches.ts

@@ -20,17 +20,24 @@ import { toMaskedPartner, toRevealedPartner } from "@/lib/services/mask";
 /**
  * @file Finding partners and moving a match toward agreement.
  *
- * One matching path, two callers. `autoPair` runs synchronously the moment a
- * site is listed, and the weekly digest cron calls the same function for
- * members with nothing open. Keeping them on one code path is not tidiness: if
- * the instant path were a separate implementation it would quietly rot, and the
- * instant path is the one that makes an exchange survivable while it is small.
+ * `autoPair` runs at exactly one moment: approval. It used to also run on
+ * submit, which read as instant matching but was the review gate leaking — a
+ * `pending_review` site was being proposed to real members before anyone had
+ * looked at it. The guard inside `autoPair` closed that, and the two submit
+ * surfaces stopped calling it, since the call could no longer do anything.
+ *
+ * The cost of that is real and worth naming: time to first match is now bounded
+ * by how fast the /admin queue gets worked, and this file used to argue that the
+ * instant path is what makes an exchange survivable while it is small. It is
+ * still the right trade, because /terms promises review first, but the queue is
+ * now on the critical path and should be watched like one.
  *
  * When there is no partner yet, that is reported honestly rather than papered
- * over. A member told "you are first in this category, the next person to join
- * matches with you" is being told something true and mildly flattering. An
- * empty digest with no explanation is the single most common way a matching
- * product loses someone on day one.
+ * over. The weekly digest cron (`api/cron/digest`) covers the members `autoPair`
+ * could not place — it does its own candidate query rather than calling in here,
+ * because it shows several masked candidates instead of proposing one match.
+ * An empty digest with no explanation is the single most common way a matching
+ * product loses someone on day one, so it sends nothing rather than nothing-news.
  *
  * ON SORTING BY `lastMatchedAt`: every query that orders by it asks for NULLS
  * FIRST explicitly. A site that has never been matched is the stalest thing in
@@ -101,28 +108,33 @@ export async function searchPartners(input: {
 
 export type AutoPairResult =
     | { matched: true; match: ExchangeMatch; partner: MaskedPartner }
-    | { matched: false; reason: "first_in_category" | "no_eligible_partner" | "pending_review"; category: Category };
+    | { matched: false; reason: "first_in_category" | "no_eligible_partner" | "not_active"; category: Category };
 
 /**
  * Finds and proposes the best available partner for a site, right now.
  *
- * Called synchronously from the submit flow and from the weekly cron.
+ * Called from `setSiteStatus` the moment a site is approved. NOT from the submit
+ * flow: a freshly listed site is `pending_review` and the guard below turns the
+ * call into a no-op, so both submit surfaces stopped making it rather than
+ * carrying copy for a branch that could not be reached.
  *
- * @param site - The site needing a partner.
+ * @param site - The site needing a partner. Ignored unless it is `active`.
  * @returns The created match and a masked view of the partner, or a reason why not.
  */
 export async function autoPair(site: ExchangeSite): Promise<AutoPairResult> {
     const category = site.category;
 
     // Only an active site may be proposed to anyone. Every filter below checks
     // the status of the CANDIDATES, so without this guard the subject slips
-    // through: the submit flow calls autoPair the moment a listing is written,
-    // while it is still `pending_review`, and a match with an unreviewed site
-    // would go out (with both match-proposed emails) before a human had looked
-    // at it. /terms says that never happens, so it must not. Approval re-runs
-    // autoPair (see `setSiteStatus`), which is where a fresh site really pairs.
+    // through and an unreviewed listing gets proposed to a real member, with
+    // both match-proposed emails, before a human has looked at it. /terms
+    // promises that never happens.
+    //
+    // `not_active` rather than `pending_review`: `paused`, `rejected` and
+    // `banned` take this branch too, and naming it after only the first one
+    // would be wrong three ways out of four.
     if (site.status !== "active") {
-        return { matched: false, reason: "pending_review", category };
+        return { matched: false, reason: "not_active", category };
     }
 
     const [active] = await db()

next-app/src/lib/services/sites.ts

@@ -225,12 +225,13 @@ export async function listSitesForReview(status?: SiteStatus): Promise<SiteForRe
  * The reviewer's note is written to `review_note`, a column that has existed
  * since the first migration and had no reader or writer until now.
  *
- * Approving MATCHES IMMEDIATELY. `autoPair` already runs on submit, but at that
- * point the site is `pending_review` and autoPair declines to pair it (that is
- * the review promise in /terms), so this is the first moment it can actually
- * pair with anyone. Without the call here an approved site would sit idle until
- * the Tuesday cron, which is a week of silence at exactly the moment the member
- * has just been told they are live.
+ * Approving MATCHES IMMEDIATELY, and this is the ONLY place `autoPair` is
+ * called from. A site is `pending_review` from the moment it is submitted until
+ * a human clears it, and `autoPair` refuses to pair anything that is not
+ * `active` (that is the review promise in /terms), so approval is the first
+ * moment the site can pair with anyone at all. Without the call here an approved
+ * site would sit idle until the Tuesday cron, which is a week of silence at
+ * exactly the moment the member has just been told they are live.
  *
  * Pairing is awaited rather than fired and forgotten, because its own
  * `match-proposed` email should land after the approval email rather than
@@ -266,8 +267,18 @@ export async function setSiteStatus(siteId: string, status: SiteStatus, reviewNo
         void notifySiteApproved({ site: updated });
         // Best effort. A pairing failure must not make the approval look like
         // it did not happen, because the row is already committed.
+        //
+        // The outcome is logged rather than dropped. This is the only caller of
+        // `autoPair`, so an unlogged return value would mean nothing anywhere
+        // observes whether approving a site actually matched it, and "I approved
+        // them and they never heard anything" would have no trail to follow.
         try {
-            await autoPair(updated);
+            const pair = await autoPair(updated);
+            console.log(
+                pair.matched
+                    ? `setSiteStatus: approved ${updated.domain} and matched it (${pair.match.id})`
+                    : `setSiteStatus: approved ${updated.domain}, no match yet (${pair.reason} in ${pair.category})`,
+            );
         } catch (err) {
             console.error("setSiteStatus: autoPair failed after approving", updated.domain, err);
         }