fix(setup): 权限数据范围自动收敛为「与应用的可用范围一致」，不再以「全部」提审

[deepcoldy]

问题

建 bot / 权限自愈只调了 scope/update（把权限点加进应用清单），但其中一部分权限还各带一份「权限可访问的数据范围」要填 —— 那是另一个接口 privilege/update，botmux 全仓从未引用过。

这两项权限的 scope level 都是「需审核」，而租户审批规则（config/audit_rule）明写：

按需申请接口权限和数据范围：可按部门/工作地点/序列明确指定数据范围（精准搜索），非必要不申请全员数据，如申请全员范围请提供充分的理由说明，视情况加签至 CEO-2

受影响的权限点只有两个（只有它们的 schema 是 SelectionExpression + 内部组织）：

数据范围	由哪个 scope 带出来
vc/meeting.meetingid 会议号查询会议信息	vc:meeting.meetingevent:read
task/manage_task_and_tasklist_members 创建、更新任务或清单时可指定的人员范围	task:task:write、task:tasklist:write

而且新建的 bot 不是「未配置」，是真的选了「全部」：「一键创建智能体」模板（manifest/upsert_by_template）建出来的应用，这两条出生就带 {"mode":"all"}。加 --no-open-platform-auto 跳过整个后半段自动配置，建出来照样是 mode:"all" —— 坐实是模板本身写的。

（另一个相关但不需要动的概念：contact_range「通讯录权限范围」是第三个接口，实测线上 50 个 app 全部已是 equalToVisible=true。）

改动

在 scope/update 之后、app_version/create 之前补一步：读 privilege/all，把「必须配、但还没收敛」的条目写成 availability_of_app（即「按条件筛选」+「与应用的可用范围一致」）。

顺序是硬要求：写在发版之后，这一版仍带「全部」提审，等于没修。因此两条路径都要做，各自发的是不同的版本：

• createOpenPlatformAppWithClient —— 模板建完立刻发第一版
• automateOpenPlatformSetup —— 权限自愈 / 补配时发下一版

只做前者，存量 bot 永不收窄；只做后者，新建 bot 的第一版仍带「全部」。抽了共享的 narrowRequiredPrivilegeRanges 两处都调。

判据与格式都对齐 console 而非猜的（从 console 前端 bundle 读出调用点与 payload 构造）：schemaType===SelectionExpression(1) && organizationType===InternalOrganization(1)（console 的 em()），只取 isRequired（console gate jC() 同档）。在此之上额外要求每个字段都是选人控件且支持 in —— availability_of_app 是成员范围语义，混了「工作地点」这类字段的（DLP 执行日志那条就是）整条跳过，留给人手配。

「已收敛」的判据是「mode 不是 all」而不是「content 非空」：后者会把模板默认值当成用户的选择而跳过（见下方「过程中的一个自咬」）。mode:'part' 等具体范围绝不覆盖；content 存在但不是合法 JSON 时保守视为已配置。

非致命，与 scope 注册同档：数据范围只影响后续审批快慢，不影响 bot 收发消息，读写失败都只记 warning 继续发版。结果新增 privilegeRangeCount / privilegeRangeWarning，0 有两种成因（本来没有待收窄的 / 写失败），必须靠 warning 区分。

影响面

仅 feishu 的开放平台自动化链路。automateOpenPlatformSetup 被建 bot / 权限自愈 / VC listener 保存 / dashboard 建 bot 共用，createOpenPlatformAppWithClient 被 CLI 与 dashboard 建 bot 共用 —— 两处都新增「一次读 + 条件性一次写」，scope/update、事件订阅与发版行为逐字不变。从权限台账重建 ACK 的那条路径显式报 0 + warning（没读写过，不谎报已配）。

写入按 (bizId, resource) 增量合并（实测所得，见下），不会动同应用里其它已配好的条目。

验证

三个真实 bot 的 live 对照（同一租户，同一天）

形态	数据范围	最新版本
改前（第一版代码，!content 守卫）	all / 待发布	Init
改前（--no-open-platform-auto，纯模板）	all / 待发布	Init
改后	part / availability_of_app / 已生效	Audited（已通过）

改后那个 bot privilegeRangeCount: 2，两条都落地，版本审核通过而非停在「审核中」。

格式正确性：content 与线上由人在 console 手工点过「与应用的可用范围一致」的应用逐字节相同 —— 6 个已配应用里 5 个完全一致，第 6 个仅 description 是飞书改名前的旧文案（⟹ description 纯展示、不参与语义）。

增量合并语义为实测所得：只传 1 条并真实改动它，同应用另一条已配好的数据范围逐字节不变。⚠️ 先用 content:'' 试探时服务端直接忽略（code=0 但值没变），「合并」与「整体 no-op」两个假设预测同一观测、判不出方向；换成写一个真实不同的值才钉死。

自动化测试：tsc --noEmit 0 错；bun run build 绿；相关 4 个测试文件 200/201，唯一失败是 collectBotmuxRedirectUrls 的环境基线用例（已 stash 到干净 master 对照确认：同断言在未改动的 master 上同样失败）。新增测试的 fixture 是线上抓下来的原文。

反向变异 9 组全红（每组只报删了哪一部分）：

变异	额外变红
删整段接线	+3
搬到 app_version/create 之后	+2（含顺序断言）
去掉「全字段可选人」守卫	+5
允许覆盖已配置项	+1
filter value 不套 JSON 字符串	+3
改坏 DM 抬头文案	+1（确认放宽 region 窗口后断言仍有牙）
退回 !content 守卫（= 本次修的 bug 本体）	+3
把 mode:'all' 也当已收敛	+4
建应用路径不收窄	+4

过程中的一个自咬（值得记一笔）

第一个 commit 自动化测试全绿、live 建 bot 也「成功」，但 privilegeRangeCount: 0 —— 改动完全空转。原因就是上面说的：守卫写成「有 content 就算配过」，而模板塞的 mode:"all" 刚好满足。纯函数测试全绿掩盖了它，因为测试 fixture 里「未配置」用的是空 content，而生产里根本不存在这个形态。

另外新增测试的第一版 fixture 把 \n 写成了真换行 → 那串不是合法 JSON → 走进「读不懂 → 保守视为已配置」的分支，测试会假绿；已改为 JSON 转义序列并加注释。

遗留（未包含在本 PR）

存量 49 个 app 里 48 个 vc / 44 个 task 仍是「未配置」或「全部」。它们下次跑权限自愈发版时会被本 PR 自动收窄，但如果想立刻批量补一次，需要单独跑一个脚本（纯增量写、不动已配好的）。要不要做、什么时候做，等确认。

🤖 Generated with Claude Code

[deepcoldy]

复审自查补充一条（head f33e35ef0）：对着 console 前端自己的「是否配置好」谓词 XC() 逐条比对，发现我原来的判据比它宽。

// console XC()
mode !== undefined && mode !== '' && mode !== 'null'
  && (mode === 'all' || (Array.isArray(filters) && filters.length > 0))

即 mode:'part' 但 filters 为空，在 console 眼里不算配置好（UI 显示「暂未配置筛选条件」）。这是又一个「看着配过、其实是空的」中间态 —— 本 PR 上一个 commit 刚因为 mode:"all" 被当成「配过了」而全盘空转，放过这个就是重犯同类错误。

已补齐三个此前会被误判为「已收敛」从而跳过的形态：mode:'part' + 空 filters、mode 整个缺失、mode:'null'（console 的「无」）。反向变异：去掉 filters 非空检查 → 2 例变红。

[deepcoldy]

CI 全 7 项绿（head f33e35ef0）。

此前一次 build 红是既有 flaky，已用同一个 commit 重跑该 job 坐实——代码字节相同、重跑 success。失败的两个是 test/mojo-cross-boundary.test.ts（[A][C][C] ≠ [A][B][C] 并发排序）与 test/v3-daemon-run.test.ts（drive lease），四组对照：

1. 本 PR 未触碰任何 mojo / v3 / backend 文件；
2. 在**合并树（master ∪ PR）**上隔离跑这两个文件 59/59 绿；
3. 在干净 origin/master（116b63283）上同样 59/59 绿；
4. 同期 fix(worker): 避免慢启动误报消息未接收 #1050 / fix(issue): 固定默认目录兜底领取仓库扫描 #1039 的 build 绿；fix(grok): 输入投递改括号粘贴、重试只补 Enter，修复大消息 Enter 被吞导致 submit_unconfirmed 卡死 #1052 也红但断言完全不同（expected undefined to be 'retryable'），非同一 flake。

（另有一次 build 红确实是本 PR 的：test/setup-pickers.test.ts 的位置式 stub 被新插入的 privilege/all 整体错位，已在 e16308d05 修正，并把写死下标的断言改为按路径查找。）

补充 live 验证：

• 部署本分支到全 fleet（55/55 daemon + dashboard 均按 /proc/<pid>/cmdline 逐个核实运行本 checkout）后，用全局 botmux 建 bot 端到端验证 → privilegeRangeCount: 2，两条自动收敛，版本 Audited。
• 一个由 dashboard 手动创建、处于 mode:"all" 的真实 app，用生产代码自身的构件（selectPrivilegesNeedingAppAvailability + buildPrivilegeUpdatePayload）收窄成功 → Opened（已生效）+ 版本 Audited；重跑选择器 0 条，幂等确认。

[github-actions]

🚀 Released in v3.18.0