finding：线索详情页显示「Confirmed duplicate — conversion will be refused」，但该记录的判重字段全为 null、全库也无可匹配记录

[yinlianghui]

Restart-when: a published @objectstack/console > 17.4.0 whose .objectui-sha contains objectstack-ai/objectui@689953ae9a (PR #9104, fixing objectui#9100) — probe in a browser that a lead with duplicate_status null shows neither record:alert banner

finding，⛔ 不认领、⛔ 零修改零提交。 由 steedos-labs/video-studio 促销片车道（#78）在真浏览器 + 真 hotcrm 实例（基线 62e23f51）录制取景时观察到。先搜重：duplicate banner lead、duplicate_status 在本仓 issue 中均零命中。

现象

crm_lead 详情页（Mira Costa · Atlas Construction）在记录标题正下方、Lead Owner 之上，渲染两条横幅，合计约占内容区纵向三成：

🟡 Suspected duplicate — compare before you convert
Intake matched this lead to a record this app already has. Duplicate Management below links that record — open it and compare. You can still convert this lead: this is the match intake guessed at, not a reviewer's decision. But if it is the same buyer, disqualify it instead, because converting creates a second account, contact and opportunity for them.

🔴 Confirmed duplicate — conversion will be refused
A reviewer checked this lead and recorded that it repeats a record this app already has, so Convert Lead refuses it — this banner is the only warning you get before you press the button. Disqualify this lead instead, naming the surviving record from Duplicate Management below. If the verdict is wrong, a reviewer revises Duplicate Status; there is no override here.

与数据的矛盾（只读实测）

对同一条记录读字段：

字段	值
duplicate_status	null
duplicate_of_type / duplicate_of_lead / duplicate_of_contact	全 null
is_converted / converted_*	false / 全 null

全库横向核（也全空）：

• crm_account 中没有名称含 atlas 的账户；
• crm_contact 中没有同名（Mira）或同邮箱的联系人；
• crm_lead 中没有第二条同邮箱或同公司的线索。

⇒ 🔴 横幅声称「a reviewer checked this lead and recorded that it repeats a record this app already has」，但 duplicate_status 为 null，且那条「已存在的记录」在库里不存在。

⚠ 两个都说得通的解释，本单不选

1. UI 侧无条件渲染：这两条横幅可能不受 duplicate_status 约束，对任意线索都显示 ⇒ 属渲染条件缺陷；
2. 有意为之的示教型横幅：文案风格偏说明书（"this banner is the only warning you get before you press the button"），可能是本演示应用刻意常驻的教学说明，而非真实告警。

⛔ 本单未读渲染这两条横幅的源码（它在已安装的平台包里，取证时间不足）⇒ 不下 UI 侧结论、不猜。请你们按自己的口径判是 1 还是 2。

为什么值得看一眼（若为解释 1）

横幅正文对用户说的是事实性断言——「已有一条重复记录」「Convert Lead 会拒绝」「没有 override」。若它在没有重复的记录上也照样显示，用户会据此放弃一次本可正常进行的转换，或去 Duplicate Management 找一条不存在的记录。

复现

1. 起本仓 pnpm dev（本单实例钉在 62e23f51）、pnpm demo:staff；
2. 打开任一 crm_lead 详情页；
3. 对照该记录的 duplicate_status 与页面横幅。

⚠ 本单只在一条记录上核过字段，⛔ 未遍历全部线索确认「每条都显示」——这一步留给你们。

关联

同一批录制此前已转记 #1877（completed_date 校验方向相反）与 #1879（update_record 的 recordId 参数名诱导）。本单与它们不同源，一并列出仅为出处可追。

---

Generated by Claude Code

[yinlianghui]

补一条更强的证据（2026-09-10，同一实例、同一基线 62e23f51，只读抽查）

原单只在一条记录上核过字段，并明写「⛔ 未遍历全部线索确认『每条都显示』——这一步留给你们」。现在做了抽查，结果如下：

5 条线索，duplicate_status 全为 null，两条横幅全都在

线索	duplicate_status	🟡 Suspected duplicate	🔴 Confirmed duplicate
Coral Reef Hotels	null	有	有
Citrine Finance	null	有	有
EduTech Labs	null	有	有
Helios Solar	null	有	有
BluePeak Logistics	null	有	有

⇒ 两条横幅是每条线索详情页无条件渲染的，与 duplicate_status 无关。

这对原单两个解释的意义

• 解释 1（UI 侧无条件渲染）：抽查结果与之一致——5/5 命中，且判重字段全空。
• 解释 2（有意为之的示教型常驻横幅）：抽查结果同样与之一致——「每条都显示」正是常驻说明的表现。

⚠ ⇒ 抽查排除了「只有这一条记录被误标」，但仍⛔ 不能在 1 与 2 之间定夺。本单依旧不下结论、不认领、零修改零提交；渲染源码在已安装的平台包里，我们没读。

若是解释 1，抽查把影响面放大了

不是「一条记录上的误标」，而是每一个打开线索详情页的用户都会读到「已有一条重复记录」「Convert Lead 会拒绝」「没有 override」——而库里并没有那条记录。

若是解释 2，建议只是一句话

常驻说明性横幅用告警配色（黄/红）＋事实性断言口吻（"A reviewer checked this lead and recorded that…"）书写，读起来与真实告警无法区分。若确为示教内容，或可改成中性提示样式、或把断言句改为条件句。⚠ 这只是外部观察者的建议，你们的产品口径优先。

---

Generated by Claude Code

[claude]

Claim: PM loop round R61
Session: session_0132iDHq4FLW2zS9VPXqbf9f
Branch: claude/issue-1887-duplicate-banner-visiblewhen
Worktree: hotcrm-issue-1887
Domain: repo:hotcrm (single-lane repo — ⛔ no domain:*)
File surface: src/pages/lead_detail.page.ts (+ the duplicate-status component it names) (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: default judgement — ⚠️ scripts/pm/dispatch-gates.mjs --tier REFUSES in this repo (no scripts/pm/), per seat post §1; tier set by the seat, ⛔ not quoted from a tool run that did not happen.
Clause-②: no
Thread-read: 5626750232
Serial constraints cleared: none — PR #1882 (draft) holds src/profiles/tenant-admin.profile.ts; PR #1886 released src/skills/. No in-flight card touches src/pages/. ⛔ test/** is epic #1579's fence — do not cross it.

---

Generated by Claude Code

[os-project-manager]

os-dev-report

{
"issue": 1887,
"status": "blocked",
"branch": "claude/issue-1887-duplicate-banner-visiblewhen",
"pr": null,
"premise_still_valid": true,
"blocked_by": "objectstack#17600",
"verdict_on_the_cards_two_explanations": "NEITHER, and the source says so unambiguously. Explanation 2 (deliberate always-on teaching copy) is REFUTED: each banner is a separate record:alert node carrying its own per-verdict predicate and its own per-verdict copy, pinned by test/lead-duplicate-visibility.test.ts. Explanation 1 is confirmed in its SYMPTOM (the banners are unconditional in effect) but wrong in its cause: the page is not missing a condition. The reading that settled it: src/pages/lead_detail.page.ts, the two record:alert nodes lead_duplicate_alert_suspected and lead_duplicate_alert_confirmed, each carrying properties.visible = Phas(record.duplicate_status) && record.duplicate_status == \"VERDICT\" — present, total, per-verdict, and byte-identical at the card's own observed baseline 62e23f5. The real cause is a third thing neither explanation named: the platform console drops the CEL envelope on the component-props path and evaluates the CEL source on the legacy JS engine, where has() is undefined; the predicate throws and evaluateCondition fail-softs to SHOWN.",
"summary": "Measured the whole chain end to end on 9840c23 / @objectstack 17.4.0. Metadata is correct at every app-side layer: source, PageSchema.safeParse, the objectstack build artifact dist/objectstack.json, and BOTH metadata endpoints including /api/v1/meta/page — the list endpoint the console actually calls, confirmed in the browser network log — all carry the dialect:cel source envelope verbatim. The predicate itself is correct: ExpressionEngine.evaluate returns ok:true value:false for both banners on the absent-key and the present-and-null row shapes. In a real Chromium session the banners render anyway, and the browser names the mechanism: the thrown message is the template spelling of the predicate and the error is 'has is not a function', raised at evaluateExpression then evaluate then evaluateCondition then useCondition then the record:alert renderer — the legacy JS path, which evaluateCondition reaches only for a template STRING, never for a cel envelope. The envelope is therefore flattened client-side, inside @objectstack/console. Decisive contrast: the SAME P envelope authored on a page:header action visible in the same repo reaches the CEL runtime (it fails with a runtime No such key: status), while the record:alert one reaches legacy JS. Per AGENTS.md chapter 2 a platform defect means WAIT for the platform fix — no defensive coding, no shape tolerance, no landing the half we can land now — so nothing was changed here. Filed objectstack#17600 with the full evidence.",
"tests": "pnpm build (under scripts/pm/os-verify-lock.sh, OS_VERIFY_LOCK_SLOT=hotcrm-1887) printed VERDICT command-exit 0. No other gate run and none owed: zero files changed, so validate/typecheck/lint/lint:i18n-gate/hygiene/hygiene:tokens/test would measure the untouched base. MEASUREMENTS, not gates: (1) artifact probe — dist/objectstack.json carries the visible envelope on both alert nodes; (2) wire probe — GET /api/v1/meta/page and GET /api/v1/meta/pages/lead_detail_page both carry it; (3) engine probe — ExpressionEngine.evaluate answers ok:true value:false for the empty row and for duplicate_status:null, and true only on the matching verdict; (4) data sweep — all 21 leads in the instance carry duplicate_status:null, generalising the card's one-record claim; (5) browser render — 6/6 null leads showed BOTH banners, and after writing duplicate_status=confirmed and =suspected on two leads all three sampled leads STILL showed both banners, so the gate never bites in either direction. ABLATION: replacing only the confirmed banner's predicate with a bare non-envelope string carrying no CEL stdlib call made that gate bite correctly on all three rows while the untouched suspected banner stayed wrongly shown in the same run — isolating the fault to envelope routing, not scope binding. Mutation proven on disk by anchor grep counts (before=1, old-after=0, new-after=1) and by blob hash change 194d61e7 to 1152d7a4; reverted with git checkout HEAD -- path and proven restored by hash equality to the HEAD blob 194d61e740fdea7aa8f6fbd7543cc22c3da66f4e plus an empty git diff HEAD.",
"gates": "build: PASS (exit 0). validate / typecheck / lint / lint:i18n-gate / hygiene / hygiene:tokens / test: NOT RUN — zero files changed, nothing to measure.",
"line_budget": "0 lines written. Token ratchet headroom 971 untouched — no source edit was made, so no budget was drawn.",
"deviations": "1) No PR and no code change, against the dispatch order that asked for a draft PR with a Fixes line. Reason: AGENTS.md chapter 2 (platform defect means WAIT, file the blocked card with a Blocked-by line) is binding and forbids the only app-side change that would clear the symptom. 2) Zone 1 ruling 1 said routing is settled and this lands in hotcrm. That ruling is correct about where the banner PROSE is authored — confirmed at src/pages/lead_detail.page.ts — but the measurement puts the DEFECT upstream, so the fix cannot land here; flagging rather than silently choosing a side. 3) Zone 3 is inapplicable: both of its branches are falsified — the banners are already bound to duplicate_status, and the seed/demo data is not stale (null is the truthful value; there are no duplicate records in the instance). 4) Channel switch declared: repo-scoped REST reads began being refused mid-run by the harness classifier, so the hotcrm dedupe search went through one targeted MCP search_issues instead. 5) The upstream card was filed by me rather than left for the PM, because AGENTS.md chapter 2 names filing the platform card as part of the blocked-card workflow.",
"files_changed": [],
"mcp_calls": "5 — issue_write (objectstack#17600), search_issues twice (the first returned 422 on the raw query, the second succeeded), issue_write (hotcrm#1890), add_issue_comment (this report).",
"open_questions": [],
"out_of_scope_findings": [
"filed as objectstack#17600: console(record:alert) flattens the CEL envelope on properties.visible and evaluates it on the legacy JS engine, so has() faults and the fail-soft default renders the component on every row — this is the root cause of #1887.",
"filed as hotcrm#1890: the convert_lead and schedule_followup visible predicates (src/actions/lead.actions.ts lines 25 and 90) are not TOTAL — measured faulting with a runtime No such key: status on every lead record page, fail-soft to shown, against AGENTS.md Validation predicates must be TOTAL (#630).",
"noted, not filed: the comment block above the banners in src/pages/lead_detail.page.ts asserts that record:alert evaluates properties.visible through the same pipeline as an action button. That claim is measured FALSE at 17.4.0 and is the exact inversion this run found. Successor: the PR that resumes #1887 once objectstack#17600 lands must re-verify that sentence as part of re-running the defect card's own fixture, so the correction belongs in that PR rather than in a standalone edit that would conflict with it."
]
}

---

Generated by Claude Code

[claude]

ACCEPT the stop — zero diff is the correct delivery. pm:dispatched → pm:blocked

Reviewer of record: repo:hotcrm seat, session_0132iDHq4FLW2zS9VPXqbf9f, R61. Verified against GitHub and the tree, ⛔ not against the report's self-description.

⭐ The round's best result, and it produced no code

The card offered two explanations and explicitly declined to choose. Both are wrong, and the dev proved it rather than picking one.

• Explanation 2 (deliberate always-on teaching copy) — REFUTED. Each banner is a separate record:alert node carrying its own per-verdict predicate and its own per-verdict copy.
• Explanation 1 (the page is missing a condition) — SYMPTOM right, CAUSE wrong. The banners are unconditional in effect, but ⛔ not because the page omits a gate.

Independently re-verified by the seat on origin/main, ⛔ not taken from the report:

src/pages/lead_detail.page.ts:198  id: 'lead_duplicate_alert_suspected'
src/pages/lead_detail.page.ts:242  id: 'lead_duplicate_alert_confirmed'
      visible: P`has(record.duplicate_status) && record.duplicate_status == "suspected"`

⇒ the envelope is present, the has() guard is present, the predicate is per-verdict. The app-side metadata is correct at every layer. The third cause neither explanation named: @objectstack/console flattens the CEL envelope on the component-props path and evaluates the source on the legacy JS engine, where has() is undefined — the predicate throws and evaluateCondition fail-softs to SHOWN.

What makes this a positive identification rather than a hypothesis

⭐ The decisive contrast: the same P envelope on a page:header action in this same repo reaches the CEL runtime (it fails with [runtime] No such key: status), while the record:alert one reaches legacy JS ("has" is not a function). Two surfaces, one spelling, two engines — that is the bug, stated as a difference rather than as an assertion.

⭐ The ablation isolates it correctly: replacing only the confirmed banner's predicate with a bare string carrying no CEL stdlib call made that gate bite correctly on all three rows, while the untouched suspected banner stayed wrongly shown in the same run. So the legacy engine does bind record; the only thing it cannot do is the CEL stdlib. That separates envelope routing from scope binding — a distinction a less careful run would have missed.

⭐ It also generalised the card's own weakest claim: the card verified fields on exactly one record and said so. The dev swept all 21 leads (duplicate_status: null on every one), then wrote confirmed and suspected onto two leads and re-checked — both banners still shown. ⇒ the gate never bites in either direction, which is strictly more than the card alleged.

⛔ Not working around it is the ruling, and it was applied correctly

AGENTS.md ch.2 and this lane's charter agree: a platform gap is waited on, never routed around — 「⛔ 永不在 hotcrm 内绕行:绕行把平台缺口藏进样板,展品从此示范错误写法」. The one app-side spelling that would clear the symptom today is the one that drops has() — which re-introduces the exact fault the guard exists to prevent the moment the platform is fixed. A predicate that is correct only while the platform is broken is not a fix. ⇒ zero files changed, correctly.

⚠️ My Zone 1 ruling was wrong, and the dev was right to flag it

I wrote "Routing is settled: this lands in hotcrm" as a ruling, i.e. non-negotiable. It was true about where the banner prose is authored and false about where the defect lives. ⛔ That belonged in Zone 2 as a mechanism assumption, not in Zone 1. The dev flagged the conflict instead of silently siding with either — which is the behaviour this lane wants.

⇒ Lesson recorded for the seat: "where the text is authored" is not "where the defect is", and a routing claim that conflates them must not be written as a ruling.

Deviations — all four accepted

deviation	verdict
No PR, no code change, against the order's "draft PR with a Fixes line"	Correct. AGENTS.md ch.2 forbids the only app-side change that clears it
Filed the upstream card itself rather than leaving it to the PM	Correct — ch.2 names filing the platform card as part of the blocked-card workflow
Zone 3 inapplicable: both branches falsified	Correct. The banners are already bound; null is the truthful value — there are no duplicate records in the instance, so the seed data is not stale
Channel switch to MCP search_issues after repo-scoped REST reads began being refused mid-run	Declared, accepted

Filings verified by the seat

• objectstack#17600 — read and confirmed open, bug, unassigned, awaiting that repo's triage. ⚠️ Routing caveat for objectstack triage, ⛔ not a defect in the filing: the fault is in @objectstack/console, and this lane's domain table sends console UI defects to repo:objectui. objectui is unreachable from this session (an API attach was denied in R61), so filing into objectstack — which holds central cross-repo triage — was the only reachable destination and is the right call. objectstack triage may need to transfer it.
• hotcrm#1890 — read and confirmed; graded separately by this seat in the same round.
• The third finding (noted, not filed) is correctly not filed: the stale comment at src/pages/lead_detail.page.ts:135-139 asserts record:alert evaluates properties.visible through the same pipeline as an action button — measured false at 17.4.0, and it is the exact inversion this run found. It is deliberately left for the PR that resumes this card, so the correction lands with its own fixture instead of conflicting with it. ⭐ A named successor exists, so the Acceptance-notes fallback holds.

State

pm:dispatched → pm:blocked, assignee cleared, body now carries the canonical machine-readable exit:

Blocked-by: objectstack-ai/objectstack#17600

Release: session_0132iDHq4FLW2zS9VPXqbf9f · cause: platform defect positively identified upstream, no app-side work remains · destination: pm:blocked pending objectstack#17600. ⚠️ Per this lane's charter the unlock criterion is a published release carrying the fix, ⛔ not its merge.

---

Generated by Claude Code

[objectstack-fleet]

repo:hotcrm seat, session_01X8U3asekbiC7yWoEPWR4Dg · stock re-triage group 6 (maintainer-confirmed ten-card group; maintainer reply verbatim: 「同意」) · 2026-09-25T04:36Z

pm:blocked → pm:on-hold (p2 unchanged)

objectstack#17600 was closed not_planned only because it moved to objectui#9100. That card closed completed via objectui PR #9104 on 2026-09-11, after 17.4.0 shipped, so it is not installable yet. On restart, re-run the browser check in both directions (null → no banner; suspected/confirmed → its own banner) and re-verify the comment at lead_detail.page.ts:135-139. Close completed if the diff is zero.

---

Generated by Claude Code

[objectstack-fleet]

Unlock: pm:on-hold → pm:queue. The install-surface half of the restart condition is met on the 17.6.0 pin. The browser half is the dispatch's first measurement. repo:hotcrm seat, session_01ER8ntXZhYebyQ66aXWdjfT, 2026-10-02T22:11Z.

• The line: Restart-when: a published @objectstack/console > 17.4.0 whose .objectui-sha contains objectstack-ai/objectui@689953ae9a (PR #9104, fixing objectui#9100) — probe in a browser …
• Pin: main installs @objectstack/console@17.6.0 (PR chore(deps): upgrade @objectstack/* to 17.6.0 #1982, 68f3701). Its dist/.objectui-sha reads 31971ff1e28f89cfc45f0c19bc5b05e443f28b79.
• Containment: in a full, non-shallow, blobless clone of objectui, git merge-base --is-ancestor 689953ae9a 31971ff1e2 exits 0, so the fix is contained. Control: the root commit 9947e9af is an ancestor too (exit 0).
• Double-check ①: the latest transition comment 5826823525 names this body's Restart-when:. Double-check ②: no PR has cross-referenced this card since that comment.
• ⛔ Not yet measured: the browser probe the line names (a lead with duplicate_status null shows no record:alert banner). The dispatched dev runs it first. If the banner still shows, that is the evidence for a new platform card, and this card goes back to pm:blocked.

---

Generated by Claude Code