fix(hooks): 被拦下的删除要指名真正拦它的那条记录 (#693)

[yinlianghui]

Fixes #693

先复现，再动手

在真实内核上（ObjectKernel + ObjectQLPlugin + AppPlugin，跑本仓自己的
objectstack.config.ts，平台 17.0.0-rc.2）把 issue 的两条现象原样跑了出来，
一个字都没改之前：

DELETE crm_account/{id}
→ "Cannot delete contact: still referenced by 1 open opportunity(ies), 0 active quote(s), 0 active contract(s). Reassign first."

DELETE crm_opportunity/{id}
→ "Cannot edit a converted lead (attempted: converted_opportunity). Make changes on the converted records instead."

前提成立：两条文案就是 contact.hook.ts / lead.hook.ts 里的守卫抛出来的，
经由平台的级联层原样上浮。拒绝本身是对的，本 PR 一个拒绝语义都没有动。

为什么不能靠“检测级联”来修

每个守卫都有两种被调用的方式，而它分不出自己身处哪一种：

• contact_integrity 的 beforeDelete：直接删联系人会走到，删客户时也会走到
  （crm_contact.crm_account 是 deleteBehavior: 'cascade' 的主从关系）。
• 三个 beforeUpdate 锁（转换线索锁、已关闭商机冻结、已接受报价冻结）：手工编辑
  会走到，引擎的引用清理也会走到 —— cascadeDeleteRelations 实现 set_null 的
  方式就是去 UPDATE 持有该 lookup 的那一行，所以“删掉被引用的记录”会以
  { 字段: null } 的形状抵达守卫。

实测（17.0.0-rc.2）：级联情形下 hook 上下文里没有任何级联标记，键集合与直接
写入完全一致，session 就是调用者本人的。这条测量本身被 cascade-guard-messages.test.ts
的第一个用例钉住了 —— 将来平台若真加了标记，这个用例会红，那时可以把文案升级成
“所以这个客户不能删”，比现在更好。

因此改的是说法：每条拒绝都从阻塞关系出发陈述，这在两种调用方式下都成立。

改完之后（真实级联产生的原文）

Contact Ada Lovelace (crm_contact-…) is still referenced by 1 open opportunity(ies),
0 active quote(s), 0 active contract(s), so it cannot be deleted — and neither can
its account, because deleting an account deletes its contacts. Close or reassign
those records first.

Converted lead Bo Chen (crm_lead-…) is locked, so its link(s) converted_opportunity
cannot be cleared — which also blocks deleting the record(s) they point at. Delete
the lead first, or have an admin clear the link with a system write.

顺带扫出的同类缺陷（同一构造，issue 未报）

按“同一类构造”扫了 src/objects/*.hook.ts，发现另外两处，用同样两个 REST 调用就能
撞上，因此一并改文案：

调用	旧文案	新文案指名
DELETE crm_contact/{id}（被某个已关闭商机当 primary_contact）	Opportunity is closed (closed_won); … Attempted: primary_contact.	商机名 + id + primary_contact 这条链接
DELETE crm_opportunity/{id}（被某张已接受报价引用）	Quote is accepted; only internal_notes may be edited. Attempted: crm_opportunity.	报价名 + id + crm_opportunity 这条链接

account.hook.ts / product.hook.ts 的删除守卫查过了：没有任何对象级联进
crm_account / crm_product，它们永远只在被直接寻址时触发，文案本来就对，未改。

判定规则

只有当被拒绝的字段全部是该对象上的引用字段、且都是从有值改成 null 时，才走
“链接被清空”那一支；混着业务字段的写入仍旧按“编辑”报，并照旧列出 attempted: 字段。
手工把同一个字段置空得到的是同一句话 —— 因为那句话在两种情况下都为真。

验证

• pnpm test → 57 files / 1368 passed | 1 skipped
• pnpm typecheck → 干净
• pnpm validate → ✓ Validation passed；pnpm build → 产物含新文案（L2 body 已下沉）
• pnpm lint / pnpm hygiene → 仅既有告警

反向验证（方向先定后跑）：预测“把四个 hook 还原 → 文案类断言变红、语义类断言保持绿”。
实跑：端到端 9 个用例红 5 绿 4（绿的是无级联标记探针、两个“拒绝且链路原样保留”、以及
“无人引用时客户仍可删”），单测另有 16 条断言变红。语义断言与本改动无关这一点，是它们绿着
证明的。

平台侧的一个问题（未改，留给维护者）

converted_* 链接的清理来自引擎维护引用完整性，并不是“用户在编辑线索”。转换线索锁
是否本就不该拦这一类写入（拦了会让被引用的商机在线索删除前无法删除），属于拒绝语义，
本 PR 按约定不动，已在报告里作为待决问题提出。

---

Generated by Claude Code

[vercel]

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

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
hotcrm	Ignored		Aug 5, 2026 2:56pm