背景
SPEC §9.3 把 pool propagation 分成 auto-sync、notify、pinned 三种模式。notify 被推荐用于 rule-heavy pools，但当前语义是：subscriber symlink 仍跟随 rev/current，更新内容在 session 中立即可见，同时追加一个通知事件等待 review。
问题
这实际上是“先应用，再通知”，不是“先审，再应用”。
对 rule-heavy pool 来说，风险比较高：
- 新的 default/mandatory 规则会立刻进入 Relevance Gate。
- 用户还没 accept/reject，LLM 已经可能按新规则行动。
- mandatory conflict 虽然会在 review 中标记，但上下文读取已经发生。
如果一个团队希望“看到有更新，但在明确接受前不改变行为”，当前只能用 pinned，而 pinned 又失去了 notify 的流畅更新体验。
建议
把 subscription state 拆成两个 revision：
[subscribe.design-system]
propagation_mode = "notify"
accepted_revision = "r7"
available_revision = "r8"
last_notified_rev = "r8"
语义：
auto-sync：accepted_revision 自动追到 latest。notify：sync 只更新 available_revision 并写 journal；context pack 仍读取 accepted_revision。用户 accept 后才切换 accepted。pinned：只读取固定 revision，available 可选记录用于 diff。
这样 notify 才真正适合规则类 pool：先看到 diff，再决定是否让规则进入上下文。
兼容建议
现有 last_synced_rev 可以继续保留为展示字段，但不要让它承担“已接受”的含义。新增字段可以在 v0.2 migration 中从现有 last_synced_rev 推导。
参考
SPEC.md §9.2：pools.toml schema。SPEC.md §9.3：notify 模式当前仍跟随 rev/current。TASKS.md T-95：notify/pinned 模式尚未完整实现，适合在实现前修正 contract。
背景
SPEC §9.3 把 pool propagation 分成
auto-sync、notify、pinned三种模式。notify被推荐用于 rule-heavy pools，但当前语义是：subscriber symlink 仍跟随rev/current，更新内容在 session 中立即可见，同时追加一个通知事件等待 review。问题
这实际上是“先应用，再通知”，不是“先审，再应用”。
对 rule-heavy pool 来说，风险比较高：
如果一个团队希望“看到有更新，但在明确接受前不改变行为”，当前只能用
pinned，而pinned又失去了 notify 的流畅更新体验。建议
把 subscription state 拆成两个 revision：
语义：
auto-sync：accepted_revision自动追到 latest。notify：sync 只更新available_revision并写 journal；context pack 仍读取accepted_revision。用户 accept 后才切换 accepted。pinned：只读取固定 revision，available 可选记录用于 diff。这样
notify才真正适合规则类 pool：先看到 diff，再决定是否让规则进入上下文。兼容建议
现有
last_synced_rev可以继续保留为展示字段，但不要让它承担“已接受”的含义。新增字段可以在 v0.2 migration 中从现有last_synced_rev推导。参考
SPEC.md§9.2：pools.tomlschema。SPEC.md§9.3：notify 模式当前仍跟随rev/current。TASKS.mdT-95：notify/pinned 模式尚未完整实现，适合在实现前修正 contract。