[#4535·B] 跨形态同名三条:ShareRecipientType(type≠const)、TransformType(const≠type)、suggestFieldType(双实现 function)

[os-zhuang]

#4535 B 项。基线里最阴险的三条 —— 同名但不同形态,选错一侧时连"形状重叠、编译通过"的掩护都没有,报错信息会指向完全无关的方向:

名字	分歧
ShareRecipientType	./contracts 是 type,./security 是 const
TransformType	./data 是 const,./shared 是 type
suggestFieldType	唯一的 function 双源:. + ./shared 共享一份实现,./data 另有一份 —— 可能是行为分叉,不只是类型

处置

• 前两条:判真源 → 收敛 + re-export 或改名(const 侧通常是值表/枚举 const,type 侧是别名 —— 看消费方各自用哪一面)。
• suggestFieldType:先 diff 两份实现。若逻辑等价 → 留一份 re-export;若有分歧 → 这可能是一个潜伏 bug(两个调用方各自拿到不同的字段类型推断),按 bug 处理并在 PR 里写清行为差异。

验收

对应 3+ 条基线行被 stale 分支点名删除;spec gate 全绿;suggestFieldType 的行为判定写入 PR 描述。

关联:#4535(主单)、#4506(基线)

[os-zhuang]

已由 PM 循环派发给开发 agent(第 3 轮,#4535 流水线 B 项)。前序 A1–A3 均已合并,基线现为 38 条。

---

Generated by Claude Code

[os-zhuang]

PM 审阅:ACCEPT → PR #4571 转正并进合并队列。

三个重命名的处置核验:

1. RecordShareRecipientType — 收敛到 contracts 版,成员 'role' 修正为 'position'。已对照存储层核实:sys-record-share.object.ts 的 select 枚举恰为 ['user', 'group', 'position', 'unit_and_subordinates', 'guest'],旧类型的 'role' 是 declared ≠ enforced(无任何生产者写入该值),修正正确。plugin-sharing 测试里一处 as any 因此得以移除 —— 反证旧类型确实是错的。
2. FieldMappingTransform / FieldMappingTransformSchema — 收敛到 shared 版,消费方全部改引,无形状变更。
3. suggestFieldTypeForSqlType — data 侧改名。两个同名函数经 diff 确认是无关实现(authoring 陷阱而非运行时 bug),分歧已在 type-compat.test.ts 以 @ts-expect-error 钉住,另新增 contracts/sharing-service.test.ts 固定契约。

基线: dual-source-exports.baseline.json 38 → 35,恰好 −3,与本簇范围一致。
测试: spec 7271 通过,全仓 132/132 tasks 绿。
changeset: spec major + plugin-sharing major,未触碰 content/docs/releases/。
范围外发现: 已按 Prime Directive #10 另立 #4570(build-docs 去 'Schema' 后缀未验证导出存在),不混入本 PR。

---

Generated by Claude Code

[os-zhuang]

PM 审阅:ACCEPT — PR #4571 已转正式并进入合并队列(squash)。

逐项核验结果:

1. RecordShareRecipientType(contracts 改名 + 成员修正):已对照 plugin-sharing/src/objects/sys-record-share.object.ts 的存储 select 逐值核对 —— ['user', 'group', 'position', 'unit_and_subordinates', 'guest'],确认 role 从来不是可持久化值,role→position 的成员修正与存储侧完全对齐(补完 ADR-0090 D3 leftovers in plugin-sharing: sys_record_share role recipient enum + "角色及下级" translations #2724 D3 漏掉的那一半)。测试里原本的 as any 铸型随修正删除,类型现在如实表达 —— 这是改对了的直接证据。
2. FieldMappingTransform(Schema)(shared 侧改名):三仓零 importer 核实无误;不删别名而改名的理由(build-docs 剥 Schema 后缀的生成器缺陷)成立,该缺陷已按第十条军规单独立案 build-docs.ts 用「剥掉 Schema 后缀」推导 import type 示例,类型别名不存在时生成的文档引用无法编译 #4570(unassigned)。manifest 键同步改名,蓄意非静默。
3. suggestFieldTypeForSqlType(data 侧改名):按要求先 diff 了两份实现 —— 确认是两个用途不相干的函数共名(string[] typo-suggester vs FieldType | undefined SQL 映射),不是同一函数的分叉,无运行时 bug;风险在编写时 auto-import 选错侧([] truthy 陷阱)。行为分歧已在 type-compat.test.ts 交叉 pin,日后归并会被 pin 逼停。

基线 dual-source-exports.baseline.json 恰好 −3(38 → 35),无多删漏删;changeset @objectstack/spec + @objectstack/plugin-sharing 双 major,三条 FROM → TO 迁移各带修法;16 文件改动全在范围内,未触碰 content/docs/releases/。验证:spec 7271 用例全过,全仓 build 71/71、typecheck 122/122、test 132/132。

合并后基线剩 35 条,进入 C 组(先重新盘点当前基线再开子 issue —— main 的无关活动会让簇自行缩水)。

---

Generated by Claude Code