A lead flagged `duplicate_status: suspected` looks clean on its record page, and `Convert Lead` never mentions it — the duplicate converts into a second account, contact and opportunity

[os-zhuang]

A lead flagged duplicate_status: suspected looks exactly like a clean lead on its own record page, and Convert Lead never mentions it — the duplicate is converted into a second account, contact and opportunity

What happens

1. crm_lead already holds Theo Park / Skyline Media / theo.park@skylinemedia.example.com (seed data).
2. Create a new lead through the UI with the same email and company (Wei Zhang / Skyline Media / theo.park@skylinemedia.example.com). It is accepted with no warning.
3. Open the new lead. The record page shows status, score, owner, email — and nothing else. Nothing indicates it is a suspected duplicate.
4. Press Convert Lead → confirm → tick Create Opportunity → Submit. It converts.

The stored record after step 2 is not ambiguous — lead_duplicate_check did its job:

"duplicate_of_type": "crm_lead",
"duplicate_of_lead": "dfSlnObNu0oXwRk-",
"duplicate_status": "suspected"

and after step 4:

"converted_account":     "2y7-PvxbS1o08j7A",   // new account ACC-000010 "Skyline Media"
"converted_contact":     "5B0nItHGRr768EfD",
"converted_opportunity": "VLEnmZCSf7BkT1xA"

So the app detected the duplicate, wrote the flag, and then converted it anyway — creating a second account for a company it already had a lead for, plus a contact and a pipeline opportunity behind it. Two reps now work the same buyer, and the pipeline is double-counted.

Where the flag does and does not surface

src/views/lead.view.ts:446 ships a suspected_duplicates grid, and the comment above it is explicit about the intent: "Without a place to SEE that set, the flag would be a column nobody reads." That queue exists and drains — but it is one list view behind the view switcher. Nothing carries the flag to:

• the lead record page — no banner, no field, no badge (src/pages/lead_detail.page.ts never mentions duplicate_status);
• the conversion itself — Convert Lead asks one question ("create an opportunity?") and never looks at duplicate_status.

A reviewer working the queue is the slow path. The rep who is about to convert is the moment the flag is worth something, and it is silent there.

Suggested direction

Two independent pieces, either one useful alone:

1. Show it on the record. A suspected-conditional banner (or at minimum the duplicate_of_lead link in the highlights) on lead_detail.page.ts, so a rep opening the lead sees "this repeats an existing lead" with a link to compare.
2. Say it at conversion. The convert screen already collects input; a suspected duplicate should surface there — at minimum a warning line naming the record it repeats, so converting is a decision rather than an accident. Whether it should block is a product call worth deciding explicitly.

---

Found by driving the app as a seller in a browser against a fresh pnpm dev on 17.1.0.

[huangyiirene]

Triage (代扫, vacancy clause) → pm:queue. ⚠️ Serialised behind #1185 this round — deferred, not shelved, with the trap recorded here rather than in a PM's memory.

Filed 2026-08-20 with bug + metadata + prio:p1 and no pm-state at all. So the highest-priority open Bug in this repo has been invisible to every candidate query for five days. That is the measured cost of hotcrm having no triage producer (objectstack#6015 covers four repos, not this one) — recorded again because it keeps being paid. Acting under the vacancy clause: triage actions only, type left alone.

Premise re-verified against origin/main @ f685136

$ git grep -c "duplicate" origin/main -- src/pages/lead_detail.page.ts   →  0
$ git grep -ln "duplicate_status" origin/main -- src/                    →  8 files
     src/objects/lead.hook.ts · lead.object.ts · opportunity.object.ts
     src/views/lead.view.ts · src/translations/{en,zh-CN,ja-JP,es-ES}.ts

Stating the reverse lookup so the zero counts: the same term returns hits in eight sibling files, so the pattern reaches this tree — the record page really does not mention the flag, and the view-level queue really is its only consumer. The card's central claim holds in full.

Why it is not dispatched in this round's batch

Its file surface intersects #1185 (dispatched this round) on two independent surfaces, not one:

surface	#1185	this card
src/flows/lead-conversion.flow.ts	carries one of the 16 notify nodes being converted to email templates	the conversion path that must surface the flag
src/translations/{en,zh-CN,ja-JP,es-ES}.ts	adds template/locale rows for every converted notification	needs label rows for the banner / warning copy

Two agents editing all four locale bundles and the same flow file in the same window is precisely what the serialisation rule exists to prevent. Same-file cards serialise hard across rounds. This card goes out in the next batch, as the top item — under the lane's selection total order it outranks everything else queued (prio:p1 + type Bug beats the prio:p2 Bugs and the unprioritised cards), and the only thing keeping it back is the file collision.

Scope note for whoever takes it — one half is a product call and must not be assumed

The card proposes two independent pieces. They are not equal:

1. Show the flag on the record page — the app already detects the duplicate and writes duplicate_status / duplicate_of_lead; the record page simply never reads them. Surfacing a value the app already computes is invariant restoration, needs no ruling, and is the core of this card.
2. Say it at conversion — a warning naming the record it repeats is the same invariant restoration and is in scope. ⛔ Whether conversion should be BLOCKED is not. The card says so itself ("Whether it should block is a product call worth deciding explicitly"), and it is: blocking changes what the app refuses, which is product semantics, not a defect repair. If the implementing round concludes a block is warranted, that is a needs-user-decision card, ⛔ never a decision taken inside the PR.

Re-check before implementing (the dispatch will carry these; they are recorded here so the card is self-contained): git grep -n "duplicate_status" origin/main -- src/views/lead.view.ts for the existing queue view, and read src/actions/lead.actions.ts alongside src/flows/lead-conversion.flow.ts — the convert gesture spans both and which one owns the screen is a reading, not an assumption.

---

Generated by Claude Code