feat(lead): one duplicate banner per verdict, each with its own next step

[os-steve]

Closes #1628

Splits the lead detail page's duplicate banner into one record:alert per verdict, so each one states the next step its verdict actually has. No change to what the app refuses.

Why one banner could not state either next step

#1207 gated a single banner on duplicate_status == "suspected"; #1289 widened it to every verdict. Widening was right — but a record:alert carries one visible and one title/body pair, and pickLocalized picks by LANGUAGE, not by row. One component covering both verdicts therefore had to word itself so it named neither, or it would have mislabelled every lead in the other state.

Since #1288 the verdicts have opposite next steps:

verdict	at conversion	what the rep should do
suspected	warns, conversion proceeds	compare against the linked record, then convert or disqualify
confirmed	refused (refuse_confirmed_duplicate)	cannot convert — disqualify, naming the survivor

So the neutral banner announced that something was wrong without saying what to do. On confirmed it was worse: nothing on the record said Convert would refuse them, so they learned it by pressing it.

What ships

id	verdict	severity	says
lead_duplicate_alert_suspected	suspected	warning	compare first; you can still convert
lead_duplicate_alert_confirmed	confirmed	error	conversion will be refused; disqualify and name the survivor

All four locales (en / zh-CN / ja-JP / es-ES), plus the component label keys in src/translations/*/app.ts. lint:i18n-gate reports 0 i18n/missing-*.

error is not decoration: RecordAlertProps documents, and record-alert.tsx implements, role="alert" / aria-live="assertive" for error against the polite role="status" every other level gets. suspected stays warning because conversion still goes through.

Two sibling record:alert nodes really do both render — verified before building on it

The whole plan rests on this, so it was measured on the pinned 17.3.0 bundle, not assumed. RegionContent in node_modules/@objectstack/console/dist/assets/ui-components-*.js at the .objectui-sha pin (00d3f09c):

let n = e.components || [];
return n.length === 0 ? null : jsx(`div`, { ..., "data-region": e.name,
  children: n.map((t,n) => jsx(ve, { schema: we(t) }, t?.id || `${e.name}-${n}`)) })

Every component is mapped to its own renderer, so both banners mount and each evaluates its own visible against the same row. The React key is node.id — which is why the two ids differ rather than sharing one, and why that is now pinned.

The predicate: guard kept verbatim, comparison narrowed

⚠️ Flagging this explicitly because the dispatch's Zone 1 text names the spelling has(x) && x != null.

Both halves of the shape #1289 ruled for are intact — the has() guard verbatim, and a comparison beside it that makes "set" mean set. What changed is that the comparison became the equality, which is strictly narrower than != null and subsumes it. Measured on @objectstack/formula 17.3.0:

record shape	has && != null	has && == "suspected"	has && != null && == "suspected"
{} (driver-memory / mongodb)	false	false	false
{duplicate_status: null} (driver-sql clean)	false	false	false
suspected	true	true	true
confirmed	true	false	false
merged	true	false	false

The != null term is a provable no-op beside the equality — identical verdicts on all five shapes — and null == "suspected" is a clean false on this engine, not a fault. A dead term on a fail-soft surface is worse than no term: it reads as load-bearing to the next person. The repo's own precedent settles the spelling — the conversion flow's e21 / e25 edges (#1288), on this same field, already read has(vars.leadRecord.duplicate_status) && … == "suspected".

⛔ Neither half is simplified away, and both remain pinned: bare has() is still TRUE for a present-and-null key (re-measured), and the unguarded tail still faults on a keyless record.

The pins that moved, and why — deliberately, one by one

test/lead-duplicate-visibility.test.ts, no new test file, no new gate (AGENTS.md:431).

1. ships a warning-severity record:alert → ships ONE record:alert per verdict, under distinct ids + a per-verdict severity pin. The old pin asserted a single alert at one severity; there are now two, at two severities. The distinct-id half is new and load-bearing (React keys, above).
2. answers with a VERDICT on every record shape → per-banner, table-driven: each banner is true on exactly its own verdict across all five shapes. The old pin's row 4 asserted the widened banner was true on confirmed; that row now belongs to the confirmed banner.
3. at most one banner is ever shown — NEW. The record-page twin of the flow's "exactly one live edge" pin. Two banners on one row would stack two contradictory next steps; nothing structural prevents it, so it is measured.
4. the guard is load-bearing → per-banner. ⭐ The property A confirmed duplicate that is not yet disqualified gets no banner and no conversion warning — #1207's predicates are suspected-only because my ruling said so #1289 built in is preserved: the unguarded text is still built from the shipped predicate itself (source.split('&&').pop()), never typed out. What splitting changed is what that tail says — it used to be != null, and is now == "this banner's verdict". So the second leg now asks for the banner's own verdict row: the unguarded == "confirmed" tail is correctly false on a suspected lead, and asserting true there would pin the wrong claim. It holds for both predicates.
5. describes the flag without asserting WHICH verdict it is → names ITS OWN verdict, and never the other one. This is the inversion. One banner shown on both states could assert neither; a banner shown on exactly one state must name that state — that is the card. It must still never name the other, for exactly the reason A confirmed duplicate that is not yet disqualified gets no banner and no conversion warning — #1207's predicates are suspected-only because my ruling said so #1289 gave. ⭐ Both words are still READ FROM the locale packs, never typed here, so renaming an option re-aims both assertions instead of retiring them.

Unchanged: names the record it repeats and every lead_conversion block.

One behaviour change, deliberate

A lead carrying a value neither option declares (e.g. merged) now raises no banner, where the widened predicate raised the neutral one. The conversion flow's e22 Clean edge already treats such a row as clean and converts it — so the page and the flow now agree about the same lead instead of contradicting each other.

Evidence

Red before green. Pins changed first, predictions written down, then run against the unchanged page: 18 failures predicted, 18 observed, name for name (1 shape + 2 severity + 2 envelope + 2 verdict-table + 5 exclusivity + 2 guard + 2 locale + 2 copy); the other 20 stayed green. After the page change: 38/38.

Ablation (from the committed implementation; mutation proven on disk by anchor counts and blob hash, restored and proven by an empty git diff HEAD). Widening the confirmed predicate back to != null produced exactly the 3 predicted failures:

× the confirmed banner answers with a verdict on every record shape
× at most one banner is ever shown — suspected
× the confirmed banner's guard is load-bearing — the unguarded spelling really does fault

pnpm verify fully green — all eight stages: validate · typecheck · lint · lint:i18n-gate (0 i18n/missing-*) · hygiene · hygiene:tokens · build · test (161 files, 3414 passed, 1 skipped). Token ratchet clean: interaction layer 37,366 → 37,963 (ceiling 40,000).

Out of scope

• ⛔ block-vs-warn is not re-opened. [Decision] Should converting a lead flagged duplicate_status: suspected be blocked, or only warned about? #1288 decided it, PR Refuse conversion of a confirmed-duplicate lead #1555 implemented it; nothing here changes what the app refuses.
• ⛔ properties.sections untouched — crm_lead 有三套互不相同的字段分组（fieldGroups 10 / 详情页 5 / 表单 6），详情页的 Details 标签页够不到 notes、重复管理与沟通偏好 #806's territory, pm:blocked.
• Ownership checked: test/lead-duplicate-visibility.test.ts is named by none of epic Epic: bring this repo's test farm back under the 2026-08-31 ruling — platform-first, os lint --strict first, then retire the local re-implementations by family #1579's F3 (Retire the local analytics / dataset integrity tests the platform's chart / widget / dataset rules already enforce (epic #1579, step 3, family F3) #1584) / F5 (Retire the local security / sharing / org-axis coverage tests the platform's security-* and sharing-rule-* rules already enforce (epic #1579, step 3, family F5) #1586) / F6 (Retire the local hook / action / flow write-shape tests the platform's *-body-write-* and flow-node-write rules already enforce (epic #1579, step 3, family F6) #1587) tables, which the dispatch had ruled out by subject rather than by reading.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
hotcrm	Ignored		Sep 6, 2026 10:14am UTC