补充一些通知

.scratch/tech-global-audit/审计覆盖基线.md

@@ -58,15 +58,15 @@
 | C 端读取支付方式与后端订单/充值校验 | N/A（普通受权读取和业务规则校验，不产生独立敏感事实；拒绝原因进入 Access Log） | 只读 `tb_system_config`，订单创建后由 `tb_order.payment_method` 固化所选方式，充值与支付事实沿用既有订单、充值单和支付记录 | 第三方支付请求继续沿用既有支付集成日志接缝，本配置策略本身不新增外部调用 | 强充支付成功后的自动购包继续沿用既有 Asynq/业务幂等链路，本配置读取不新增 Outbox |
 | 主钱包首次跌破 100 元通知店铺业务员 | N/A（由已审计资金事实派生的内部提醒，不新增人工操作或敏感读取） | `tb_agent_wallet_transaction` 与 `wallet.agent_main.debited` 是余额前后值的权威事实，`tb_notification` 保存最终通知与已读状态 | N/A（不调用外部系统） | 扣款事实消费者仅在 `balance_before >= 10000 && balance_after < 10000` 时同事务幂等写入明确后台账号通知 Outbox；无有效业务员时正常结束 |
 | 创建物流换货单并提醒关联个人客户 | N/A（通知记录本身是投递事实；当前 Change 不新增全局 Audit Event Writer，后台创建操作继续进入 Access Log） | `tb_exchange_order` 是物流换货申请及状态的权威事实，`tb_notification` 是接收人通知与已读状态的权威事实 | N/A（不调用外部系统） | 换货单与每个启用关联客户的 `notification.personal_customer.direct.requested` 在同一 GORM 事务写入；事件 ID 使用换货单和客户 ID 稳定防重，消费端按事件与接收人唯一键幂等 |
-| 套餐临期列表、数量与每日/手动 15/7/3 天节点提醒 | N/A（列表和数量是普通受权读取；手动入口仅允许超级管理员提交同一幂等扫描任务，操作者进入 Access Log 和任务日志，不直接修改业务事实） | `tb_package_usage` 的计时条款快照和到期队列是预计最终到期的权威事实，`tb_notification` 保存个人客户通知与已读状态 | N/A（不调用企业微信、短信、邮件或其他外部系统） | 每日或手动任务按资产、到期日、节点和个人客户生成稳定事件 ID，在单个 GORM 事务中幂等写入 `notification.personal_customer.direct.requested`；列表和数量纯 Query 不产生 Outbox |
+| 套餐临期列表、数量与每日/手动 15/7/3 天节点提醒 | N/A（列表和数量是普通受权读取；手动入口仅允许超级管理员提交同一幂等扫描任务，操作者进入 Access Log 和任务日志，不直接修改业务事实） | `tb_package_usage` 的计时条款快照和到期队列是预计最终到期的权威事实，`tb_notification` 保存店铺账号、平台业务员和个人账号通知及已读状态 | N/A（不调用企业微信、短信、邮件或其他外部系统） | 每日或手动任务按资产、到期日和节点生成稳定事件 ID，同一 GORM 事务内向店铺动态接收人写入 `notification.admin.dynamic.requested`，并向绑定个人账号写入 `notification.personal_customer.direct.requested`；列表和数量纯 Query 不产生 Outbox |
 | 企业微信应用连接配置保存与明文读取 | 配置保存复用 `systemconfig.AuditWriter`，只记录应用标识、状态和 `credentials_configured=true`，不记录连接凭据；明文读取仅允许超级管理员并进入 Access Log，统一敏感读取 Audit Writer 在本 Change 的治理收口任务中继续核验 | `tb_wecom_application` 是 corp_id、agent_id、应用状态及明文 Secret、回调 Token、EncodingAESKey 的权威事实；管理响应按用户确认向超级管理员返回明文 | 保存和读取本身不调用企微；连接测试或 token 缓存未命中时，每次真实回源均写 `tb_integration_log`，请求和响应摘要不含 Secret、回调凭据或 access_token | N/A（连接配置提交后仅同步失效可重建 token 缓存，不产生必须可靠投递的业务副作用） |
 | 企业微信可见成员同步与账号显式绑定 | 成员同步是外部只读快照更新，不记录独立人工审计；账号绑定沿用现有账号操作日志，记录操作者、目标账号及绑定前后 `(corp_id, userid, name)`，不记录手机号或邮箱 | `tb_wecom_member` 是最近同步的应用可见成员选择快照，`tb_account.wecom_*` 是管理员确认后的账号绑定事实；不建立部门组织模型 | 每次真实调用应用可见成员接口均写 `tb_integration_log`，仅记录应用、根部门、成员数量、状态码和耗时，不保存 access_token 或成员列表正文 | N/A（同步和绑定均为同步事务，不产生必须可靠投递的提交后副作用） |
 | 企业微信审批业务场景与模板控件映射 | 配置保存复用事务内 `systemconfig.AuditWriter`，记录业务类型、应用 ID、模板 ID、状态和最近校验时间；不保存凭据、审批节点或审批人规则到审计数据 | `tb_wecom_approval_scene` 是两个稳定业务类型的当前模板、控件映射、模板最小快照和启用状态权威事实 | 保存前每次真实调用模板详情接口均写 `tb_integration_log`，记录应用、模板 ID、状态码、控件数量和耗时，不保存 access_token 或完整外部响应 | N/A（配置保存为同步事务，不产生必须可靠投递的提交后副作用） |
 | 企业微信默认发起人与审批提交 | 默认发起人配置复用事务内 `systemconfig.AuditWriter`，记录应用、userid 和姓名快照；真实业务提交人继续保存在业务申请及通用审批实例中，不以默认成员伪造操作者 | `tb_wecom_application.default_creator_*` 是应用默认发起人当前配置，`tb_wecom_approval_context` 冻结模板、实际 creator 来源和提交状态，`tb_approval_instance.external_ref` 保存 sp_no | 每次附件上传和 applyevent 均写 `tb_integration_log`；摘要不含 Secret、access_token、media_id、附件正文或完整企微响应；提交超时记 unknown 并登记时间窗批量单号/详情查询恢复策略 | 业务事务写入 `approval.submission.requested`；Worker 条件领取后只提交一次，明确失败和结果未知均终结自动重试，禁止盲目创建第二张审批单 |
 | 企业微信审批加密回调与详情终态同步 | 回调为外部自动事实，不伪造人工 Audit Event；验签、AES 解密、receiveid 校验失败只记录安全错误，不进入业务终态 | `tb_integration_log` 按应用和签名幂等保存入站密文哈希，`tb_wecom_approval_context.latest_detail_snapshot` 保存权威详情，通用审批实例及决策投递表保存标准终态 | 入站回调先写 Integration Log pending，详情任务完成后置 completed；每次 `getapprovaldetail` 写独立出站 Integration Log，不保存 access_token，但保存 sp_no、sp_status 和耗时摘要 | 回调只入队结构化 `wecom:approval:sync` 任务；权威终态通过现有 `SyncDecisionService` 原子写 `approval.terminal_decision.recorded`，不直接修改退款或钱包 |
 | 企业微信审批主动恢复、未终态轮询与审批人读取投影 | N/A（定时恢复和只读投影均为系统自动动作；不伪造人工操作者，映射不到账号不改变业务事实） | `tb_wecom_approval_context.submission_attempted_at/last_recovery_at/sp_no/latest_detail_snapshot` 与通用审批实例是恢复和展示的权威本地事实；只有唯一候选可从结果未知转为审批中 | 每次 `getapprovalinfo` 分页和 `getapprovaldetail` 均写独立出站 Integration Log，只保存应用、时间窗、模板、发起人、单号数量、sp_no、状态和耗时等安全摘要，不保存 Secret、access_token、media_id、附件正文或完整响应 | Scheduler 仅提交 `wecom:approval:recovery`；恢复和轮询仅提交结构化 `wecom:approval:sync`，不写审批提交 Outbox、不调用 `applyevent`，标准终态仍沿用既有终态 Outbox |
-| 员工线下代充值申请与企微终态入账 | 申请保存以真实提交人及明文业务快照留痕；资金成功 Audit Event 延期至既有统一钱包治理任务，企微自动终态不伪造人工审批人 | `tb_agent_recharge_record`、`tb_approval_instance` 和 `tb_wecom_approval_context` 同事务保存申请事实；approved 通过 `topup + recharge_record_id` 唯一成功钱包流水幂等入账，其他终态不修改钱包，通过后撤销不自动冲正 | 申请创建本身不外呼；后续附件上传、applyevent、详情与恢复沿用企微 Integration Log，业务参数按用户确认保存明文，日志仍不记录 Secret、access_token、media_id 或附件正文 | 创建事务写 `approval.submission.requested`；标准终态写 `approval.terminal_decision.recorded`，approved 入账事务再写 `wallet.agent_main.credited`；新审批单禁止旧人工确认或驳回入口绕过 |
-| 退款申请与企微终态处理 | 申请以真实提交人和订单/金额/凭证明文快照留痕；企微自动终态不伪造本地人工审批人，资金与佣金 Audit Event 继续沿用既有治理延期口径 | `tb_refund_request`、通用审批实例和企微上下文同事务保存；approved 条件更新订单与退款单，代理主钱包按 refund ID、资产钱包按退款单号复核成功回款；佣金按记录锁定并失效，套餐按订单及换货迁移关系幂等失效 | 申请创建不外呼；附件、applyevent、详情、回调和恢复沿用企微 Integration Log，业务参数明文保存在业务/审批快照中但不复制到 Integration Log，Secret、access_token、media_id 和附件正文仍禁止记录 | 创建事务写 `approval.submission.requested`；终态写 `approval.terminal_decision.recorded`；业务消费者只有在订单、钱包、佣金和资产后处理完成后才确认投递成功，失败释放租约重试 |
+| 员工线下代充值申请与企微终态入账 | 申请保存以真实提交人及明文业务快照留痕；资金成功 Audit Event 延期至既有统一钱包治理任务，企微自动终态不伪造人工审批人 | `tb_agent_recharge_record`、`tb_approval_instance` 和 `tb_wecom_approval_context` 同事务保存申请事实；approved 通过 `topup + recharge_record_id` 唯一成功钱包流水幂等入账，其他终态不修改钱包，通过后撤销不自动冲正；`tb_notification` 保存到账通知 | 申请创建本身不外呼；后续附件上传、applyevent、详情与恢复沿用企微 Integration Log，业务参数按用户确认保存明文，日志仍不记录 Secret、access_token、media_id 或附件正文 | 创建事务写 `approval.submission.requested`；标准终态写 `approval.terminal_decision.recorded`，approved 入账事务再写 `wallet.agent_main.credited` 和目标店铺的 `notification.admin.dynamic.requested`；在线充值复用同一入账接缝；新审批单禁止旧人工确认或驳回入口绕过 |
+| 退款申请与企微终态处理 | 申请以真实提交人和订单/金额/凭证明文快照留痕；企微自动终态不伪造本地人工审批人，资金与佣金 Audit Event 继续沿用既有治理延期口径 | `tb_refund_request`、通用审批实例和企微上下文同事务保存；approved 条件更新订单与退款单，代理主钱包按 refund ID、资产钱包按退款单号复核成功回款；佣金按记录锁定并失效，套餐按订单及换货迁移关系幂等失效；`tb_notification` 保存退款完成通知 | 申请创建不外呼；附件、applyevent、详情、回调和恢复沿用企微 Integration Log，业务参数明文保存在业务/审批快照中但不复制到 Integration Log，Secret、access_token、media_id 和附件正文仍禁止记录 | 创建事务写 `approval.submission.requested`；终态写 `approval.terminal_decision.recorded`；退款事务幂等写目标店铺的 `notification.admin.dynamic.requested`；业务消费者只有在订单、钱包、佣金和资产后处理完成后才确认投递成功，失败释放租约重试 |
 | 退款与线下代充值旧审批入口发布切换 | N/A（部署环境开关控制旧入口是否可用，不新增业务操作；实际旧入口操作继续沿用各自既有审计口径） | `approval_instance_id IS NULL` 是存量旧 provider 的兼容边界，非空记录只接受企微标准终态；关闭开关不修改或删除任何业务事实 | N/A（开关判断不调用外部系统，也不得写 Integration Log 冒充发布审计） | N/A（开关判断不产生可靠副作用；企微 Worker 继续消费既有标准终态 Outbox） |
 | 单列 CSV 资产套餐批量订购 | 任务创建和逐行订单继续进入 Access Log、任务操作者快照与既有订单/钱包审计接缝；本 Change 不新建批量任务专用 Audit Writer | `tb_asset_package_batch_order_task` 保存输入参数和逐行结果，成功行以 `tb_order`、订单明细、套餐使用、支付记录及代理钱包成功流水为权威业务事实 | 对象存储上传和下载沿用现有存储日志，不把文件正文写入 Integration Log；本切片不新增外部支付或 Gateway 调用 | 创建接口提交结构化 `asset:package:batch_order` Asynq 任务；逐行钱包订单继续沿用既有钱包扣款 Outbox 和佣金任务，重复任务由状态条件与订单幂等规则阻断 |
 | IoT 卡与套餐业务导出 | N/A：只读投影，不改变资产、套餐或权限状态；任务创建操作者与权限快照沿用现有导出任务记录 | N/A：导出只读取现有卡、套餐使用、套餐和分配事实，不写入领域账本 | N/A：不调用外部业务系统；对象存储文件生成和下载沿用现有导出基础设施日志 | 沿用现有 `export:dispatch` → `export:shard` → `export:finalize` Asynq 链路，不新增业务 Outbox |