sharing: deactivating a rule never withdraws its materialized grants — not on touch, not at boot

[baozhoutao]

Found while verifying the 17.0.0-rc.1 checklist on #3909 (F2, "switching a rule off actually withdraws access", #3850). Verified on main @ 1ee48bc60, showcase under os serve --dev, SQLite datasource.

Repro

1. Object showcase_private_note (sharingModel: 'private'). Admin owns note N; member B cannot read it (404 — correct baseline).
2. Admin authors a criteria rule at runtime: POST /api/v1/sharing/rules {type:'criteria', name:'rc1_rule_livetest', object:'showcase_private_note', criteria:{title:'rc1 rule target'}, accessLevel:'read', recipientType:'user', recipientId:<B>, active:true} → 200.
3. Admin touches N (PATCH) → the rule materializes a sys_record_share row (source:'rule', source_id:<rule id>); B reads N → 200. ✅ so far.
4. Admin saves the same rule with active:false → 200; GET /sharing/rules/rc1_rule_livetest confirms active:false.
5. B reads N → still 200.
6. Admin touches N again (the same event that materialized the grant) → B still 200; the source:'rule' share row is still there.
7. Full server restart on the same datastore → B still 200. The rule reads active:false, the orphaned grant row still answers:

GET /sharing/rules/rc1_rule_livetest → {"active":false,"id":"srule_05574dc1-…"}
GET /data/showcase_private_note/<N>/shares → [{"source":"rule","source_id":"srule_05574dc1-…","level":"read"}]

Once a rule's grant is materialized it is permanent: deactivating the rule never withdraws it — not on the next record touch, not at boot. (And the rule cannot be deleted over REST either — the DELETE route 500s unconditionally, filed separately as its own issue; with both paths dead there is NO way to withdraw a rule grant short of hand-editing sys_record_share.)

Expected

Deactivating (or deleting) a sharing rule withdraws the grants it materialized — that is the #3850 posture the v17 release notes advertise ("switching a rule off actually withdraws access"). At minimum the evaluator/materializer must treat source:'rule' rows whose source_id resolves to an active:false (or missing) rule as void, and the reconciliation that runs on record-touch/boot should sweep them.

Part of the #3909 rc.1 verification (section F2).

[baozhoutao]

Tracked under the v17 verification tracker #3909 (section F, rc.1 run 1).

[baozhoutao]

Rolled up in #4482 (all 17 defects from the v17 verification, grouped by severity with a suggested RC-exit triage).

[os-zhuang]

交接说明（算力额度可能中断，先把进度落到远端）

分支：claude/v17-verification-defects-gnf9e6-sharing（已推送，commit a6d7efe，wip: 前缀）

本条与 #4434 一起修，两者合起来才构成"授权无法回收"的完整缺口，所以放在同一分支。

已完成

#4433 定位到三个独立的断点，issue 里走过的三条路径各对应一个：

1. 停用动作本身不生效（主因） —— sharing-plugin.ts 的 rule-write trigger 对所有 isSystem 写入跳过 reconcile。但 SharingRuleService.defineRule（POST /sharing/rules 背后唯一的实现）永远用 SYSTEM_CTX 写 sys_sharing_rule（它必须如此，否则过不了 sharing 中间件对平台表的拦截）。所以这个跳过条件命中了 100% 的 REST 授权写入——包括 active:false 的保存。fix(sharing): 共享规则新建页 — 自定义 widget 未国际化，且「接收方」永远无可选项 #3821 建好了撤销通道，却用一个在生产里永远为真的谓词把它关掉了：通道存在、有测试（测的是真实路径根本不会发的 mock session）、且不可达。现改为按启动阶段判断（ruleGrantsBootReconciled），这才是那个跳过条件真正想问的问题。

2. 触碰记录不撤销 —— evaluateAllForRecord 只列 activeOnly 的规则，停用的规则根本不在循环里，它物化出来的授权连看都没被看一眼。现在列全部规则；停用的规则"期望授权集合为空"，直接走 reconcileForRecord 已有的 revoke 分支。

3. 重启不撤销 —— boot backfill 拿到的也是 activeOnly 列表，结构上不可能撤销任何东西。现在遍历全部规则；另加 sweepOrphanedRuleGrants() 处理规则行已经彻底消失的授权（靠遍历规则永远够不到它们）。

#4434 —— deleteRule 用 where:{source,source_id} 谓词删 sys_record_share，既没有标量 id 也没有 multi:true，正好是 engine dispatch 唯一拒绝的形状，在碰到规则行之前就抛了。改为走 purgeRuleGrants（而不是补一个 multi:true），让规则授权的回收只有一条路径 —— SharingService.revoke，和其它所有撤销路径一致（PD #5）。

测试假引擎的保真度：makeEngine().delete 原先接受任意 where，这正是 #4434 能带着绿灯发布的原因——已有的 deleteRule drops rule + all its grants 测试一直在对着一个真实服务器必然拒绝的删除断言成功。现已对齐真实 engine 的 dispatch 守卫。

回归测试已加（含负向断言）：sharing-rule.test.ts（#4434 两种寻址形式 + 触碰撤销 + 孤儿清扫）、boot-backfill.test.ts（重启撤销 + 把旧的 activeOnly 调用点作为缺陷钉死）。已验证：撤掉修复后这些测试确实失败（8 个）。

当前卡在哪

不是技术障碍，只是被算力额度打断：

• rule-rebind.test.ts 里的 skips system-context writes — boot backfill owns those 这条测试钉死的正是缺陷行为，需要改成新契约（启动期跳过、启动后一律 reconcile），并补一条"停用即撤销"的用例。我已经在该文件的 beforeEach 里加了 ruleGrantsBootReconciled = true 和 sweepOrphanedRuleGrants mock，改到一半。
• 闸门未跑完：pnpm --filter @objectstack/plugin-sharing test、pnpm typecheck。
• 真实启动验证未做（端口 38102）：建规则 → 授权生效 → 停用 → 确认撤销 → 重启再确认 → DELETE 确认正常。
• 草稿 PR 未开。

下一步具体做什么

1. 改 rule-rebind.test.ts 的 skips system-context writes 用例为启动阶段语义；补"active:false 写入触发 reconcile"用例。
2. 跑 pnpm --filter @objectstack/plugin-sharing test 与 pnpm typecheck。
3. 按 issue 场景做真实启动验证（pnpm dev -- --fresh -p 38102，完事 kill $(lsof -ti tcp:38102)）。
4. 开草稿 PR 打到 main，写 Fixes #4433、Fixes #4434。

未触及 spec / 公开导出 / 协议层，无破坏性变更，不需要决策拍板。

---

Generated by Claude Code