docs(sub2api): 明确补偿公告适用范围

docs/MDTODO/details/sub2api-upstream-reliability/R3.7_Task_Report.md

@@ -0,0 +1,37 @@
+# R3.7 公告范围规则固化报告
+
+## 目标
+
+补偿公告不能只写“符合条件的用户”。公告必须让操作者和接收方明确知道补偿对应哪个时间段、哪些用户以及多少金额；本次只固化规则，不重新发布或修改既有公告。
+
+## Skill 规则
+
+Sub2API `codex-pool.md` 已明确：
+
+- 每次 create 的用户可见正文必须写明业务时间范围和接收范围。
+- `targeting` 只控制公告投递，不能替代补偿资格或实际发放范围。
+- 补偿公告必须列出故障影响时间窗或补偿资格统计时间窗。
+- 必须列出全部实际接收用户的稳定用户 ID 和邮箱；邮箱可以脱敏，但禁止只写泛化描述。
+- 必须列出每人金额和本批总额。
+- 候选名单与实际发放名单不一致时，必须同时写明两者和排除原因。
+
+## CLI 可见性
+
+公告 create 的 dry-run 和 confirm 输出新增两条固定人工检查：
+
+- `SCOPE-CHECK`：正文必须明确时间范围和接收范围，targeting 不能替代业务范围。
+- `COMPENSATION-CHECK`：列出全部接收用户 ID、可脱敏邮箱、每人金额和总额。
+
+CLI 不通过标题关键词猜测公告类型，也不做容易误判的内容关键词自动通过；最终 confirm 前由操作者核对完整正文。
+
+## 验证
+
+- 使用包含参数化时间窗、用户 ID、脱敏邮箱、每人金额和总额的公告执行 dry-run。
+- 输出 `mutation=false`、`writeAttempted=0`，两条范围检查和完整正文均可见。
+- 未登录运行面，未调用公告创建 API，未修改或重新发布公告 ID 1。
+- Sub2API skill `quick_validate` 通过。
+- `git diff --check` 通过。
+
+## 结论
+
+后续补偿公告在发布前会同时经过 skill 规则和 CLI create 预览提醒，范围必须可由时间窗和用户 ID 对账；上次公告仅保留历史事实，不做重发。

docs/MDTODO/sub2api-upstream-reliability.md

@@ -243,3 +243,7 @@
 ### R3.6 [completed]
 
 按用户明确授权，对固定补偿候选用户 ID 11、10、7、22、19 每人增加 30 USD，总额 150 USD，并并发发布服务稳定性补偿公告；两条操作都必须通过 Sub2API 原生受控 CLI 显式 confirm，使用精确名单、写后回读和公告字段对账，禁止扩大到 YAML 排除员工或管理员，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R3.6_Task_Report.md)。
+
+### R3.7 [completed]
+
+在 Sub2API 公告 skill 与 CLI create 预览中固化明确范围规则：补偿公告必须在用户可见正文列出故障或补偿时间窗、全部实际接收用户、每人金额和总额；邮箱允许脱敏但必须保留稳定用户 ID，`targeting` 仅表示投递范围、不能替代补偿资格名单。本次只记录并验证 dry-run 展示，不重新发布或修改既有公告，完成任务后将详细报告写入[任务报告](./details/sub2api-upstream-reliability/R3.7_Task_Report.md)。