feat: say when a match came from an adjacent category

`match.widened` was stored and the proposal email disclosed it, but
`MatchView` never carried the field, so `list_matches` and the dashboard
both showed a bare category. A member paired one step out had no way to
tell a deliberate widen from a bad recommendation, which is the opposite
of the "we widen and say so" promise on the landing page and in rule §02.

Adds `MatchView.widened` and renders it on both surfaces: the MCP tool
tags the category "(adjacent to yours)" and adds a `widened:` line, the
dashboard tags the Category fact "(adjacent)" and gives the reason as a
sentence, because a bare tag is a label and the member needs the why in
the same glance.

Also fixes a mislabel this made visible. The dashboard fed `MatchRow`
from `match.category`, which is `best.candidate.category` and therefore
the partner's category only for the side that initiated the pairing. The
other member saw their OWN category, so "(adjacent)" would have pointed
at itself on one of the two dashboards for every widened match. It now
reads `match.partner.category`, the same per-recipient field the email
and the MCP tool already use.

And words both explanations from the pair rather than "your category".
Only the initiating side is measured against `WIDEN_BELOW`, so telling
the other member their category was too thin is a claim we never checked
and is false whenever they were the well-populated end of the pair.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UJrDkXYhYpyp1cV9t4q1GY

Author: nicklaunches

next-app/src/app/app/match-card.tsx

@@ -40,7 +40,16 @@ import { TabList } from "@/components/web/tab-list";
 export type MatchRow = {
     matchId: string;
     state: string;
+    /**
+     * The PARTNER's category, which is NOT `MatchView.category`. See the
+     * mapping in page.tsx for why the two differ on a widened match.
+     */
     category: string;
+    /**
+     * True when the pair came from an adjacent category. Shown rather than left
+     * to inference: an unlabelled adjacent match just looks like a wrong one.
+     */
+    widened: boolean;
     revealed: boolean;
     /** Present only when revealed. The type mirrors what the server sent. */
     partnerDomain: string | null;
@@ -118,8 +127,23 @@ export function MatchCard({ row }: { row: MatchRow }) {
 
             <p className="mt-4 text-[14.5px] leading-relaxed">{row.partnerDescription}</p>
 
+            {/* The "(adjacent)" tag below is a label, not an explanation. Someone
+                looking at a partner outside their own category needs the reason
+                in the same glance, or the match reads as a mistake.
+
+                Worded from the pair, not from "your category". Only the side
+                that initiated the pairing was measured against WIDEN_BELOW, so
+                telling the other member their own category was thin is a claim
+                we have not checked and is often false. */}
+            {row.widened ? (
+                <p className="text-muted mt-3 text-[14px] leading-relaxed">
+                    One of your two categories was too thin to pair inside it, so we widened by a single adjacent step
+                    rather than leave you both unmatched.
+                </p>
+            ) : null}
+
             <dl className="border-line mt-5 grid gap-px overflow-hidden rounded-sm border sm:grid-cols-3">
-                <Fact label="Category" value={row.category} />
+                <Fact label="Category" value={row.widened ? `${row.category} (adjacent)` : row.category} />
                 <Fact
                     label="Domain Rating"
                     value={row.partnerDomainRating == null ? "Not measured" : String(row.partnerDomainRating)}

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

@@ -70,7 +70,13 @@ export default async function DashboardPage() {
         return {
             matchId: match.matchId,
             state: match.state,
-            category: match.category,
+            // The PARTNER's category, not the match's. `match.category` is
+            // `best.candidate.category`, which for the side that did not
+            // initiate the pairing is their own category — so "(adjacent)"
+            // would be pointing at itself. The proposal email and the MCP tool
+            // both read `partner.category` for the same reason.
+            category: match.partner.category,
+            widened: match.widened,
             revealed,
             partnerDomain,
             partnerDescription: match.partner.description,

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

@@ -331,13 +331,22 @@ export function registerTools(server: McpServer, ctx: ToolContext): void {
             return text(
                 matches
                     .map((m) => {
+                        // Say when a pair was widened. Unlabelled, an adjacent
+                        // match is indistinguishable from a wrong one, which is
+                        // exactly what house rule §02 promises not to do.
+                        const category = m.widened ? `${m.partner.category} (adjacent to yours)` : m.partner.category;
                         const who =
                             "domain" in m.partner
-                                ? `${m.partner.domain} (${m.partner.email})`
-                                : `${m.partner.category}, DR ${m.partner.domainRating ?? "unrated"} (hidden until you both accept)`;
+                                ? `${m.partner.domain} (${m.partner.email}), ${category}`
+                                : `${category}, DR ${m.partner.domainRating ?? "unrated"} (hidden until you both accept)`;
                         return [
                             `${m.matchId}  [${m.state}]  ${who}`,
                             `  ${m.partner.description}`,
+                            ...(m.widened
+                                ? [
+                                      "  widened: one of your two categories was too thin to pair inside, so we went one adjacent step out.",
+                                  ]
+                                : []),
                             `  wants: ${m.partner.wantedAnchors.join(", ") || "no anchors given"}`,
                             `  next: ${m.nextStep}`,
                         ].join("\n");

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

@@ -278,6 +278,26 @@ export type MatchView = {
     matchId: string;
     state: MatchState;
     category: Category;
+    /**
+     * True when this pair came from an adjacent category, because the exact one
+     * was too thin to pair inside.
+     *
+     * Exposed because the landing page and house rule §02 both promise we widen
+     * "and say so", and a widened match is indistinguishable from a wrong one
+     * unless we say which it is. The proposal email has always disclosed this;
+     * every other surface showed a bare category and left the member to
+     * conclude the matching was simply bad.
+     *
+     * A property of the PAIR, not of the viewer: it is stored as
+     * `best.candidate.category !== category`, so it is true exactly when the two
+     * sites sit in different categories, which reads the same from either end.
+     * Both sides can therefore render it, and each side's "adjacent" means the
+     * OTHER site's category. What is not symmetric is which category was thin:
+     * only the side that initiated the pairing was measured against
+     * `WIDEN_BELOW`, so no surface should tell a member their own category was
+     * the thin one.
+     */
+    widened: boolean;
     /** The viewer's own site in this match. */
     mySiteId: string;
     /** Masked before mutual accept, revealed after. */
@@ -344,6 +364,7 @@ async function buildMatchView(match: ExchangeMatch, viewerSiteIds: Set<string>):
         matchId: match.id,
         state,
         category: match.category,
+        widened: match.widened,
         mySiteId,
         partner,
         revealed,