收口审计治理与套餐任务进展

Constraint: 在线热修前必须保存当前迭代分支全部有效代码进展
Confidence: medium
Scope-risk: broad
Directive: 后续修改需保持审计事件与业务事务边界一致
Tested: git diff --cached --check
Not-tested: 未运行全量测试，提交用于切换分支前保存既有工作

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

@@ -38,7 +38,7 @@
 
 - Integration Log 唯一 Repository 写入口为 `Start/Complete/RecordInbound/ClaimExpiredInboundPending`，当前已覆盖运营商回调、支付 H5 下单/查单/回调、卡观测、卡限速及企微 token/通讯录/模板/附件/提交/详情/回调；支付宝 WAP URL 本地签名不伪造外部尝试。
 - 当前设备 Gateway、IoT 卡 Gateway、统一资产实时状态等直连调用尚未全部接入 Integration Log；矩阵已逐用例登记为“必须”，由后续 3.3、6.x、8.6～8.8 纵向切片落实，不能用旧 Asset Operation Log 代替。
-- 旧 Writer 当前 15 个显式调用点仍覆盖线下充值、套餐配置、支付配置及部分资产、卡、设备、导入和轮询。Writer 自身使用裸 goroutine，充值和支付配置还存在外层 goroutine，形成双层异步并丢失事务/request/correlation；后续切片必须逐调用归零。
+- 支付配置的 5 个旧账号日志外层 goroutine 已归零；旧 Writer 仍有少量未迁移资产、卡、设备、导入和轮询调用，旧 Writer 自身的 goroutine 留待最终 contract 任务统一移除。
 
 ### 已落地代表切片
 
@@ -72,11 +72,12 @@
 | 明确后台账号通知事件消费与幂等写入 | N/A（测试环境冻结；生产前由 6.5 重新评审通知失败与系统告警治理） | `tb_notification` 是通知投递与接收人已读状态的权威事实 | N/A（无外部系统调用） | 消费公共 Outbox 的稳定事件，不复制 Outbox |
 | 当前后台账号单条通知已读 | N/A（低风险个人阅读状态，普通已读操作只进入 Access Log） | `tb_notification.is_read/read_at` 是权威状态 | N/A | N/A |
 | 当前后台账号未读数与基础列表 | N/A（普通读取，不返回其他接收人数据或敏感业务正文） | 只读 `tb_notification` 投影 | N/A | N/A |
-| 代理主钱包订单统一扣款 | 延期（测试环境冻结；生产前由 6.5 为资金变更补齐同事务 Audit Event） | `tb_order`、`tb_agent_wallet`、`tb_agent_wallet_transaction`、`tb_payment` 与套餐使用记录在同一事务形成权威事实 | N/A（不调用外部系统） | 同事务写入 `wallet.agent_main.debited`，为余额预警等后续消费者提供稳定事实 |
-| 代理主钱包订单资金预占、释放与完成扣除 | 延期（测试环境冻结；生产前由 6.5 为冻结及终态变更补齐同事务 Audit Event） | `tb_agent_wallet_reservation` 是预占金额、付款钱包与唯一终态的权威事实；钱包与完成扣除流水同事务更新 | N/A（不调用外部系统） | 同事务写入 `wallet.agent_main.reservation.changed`；完成扣除同时写入 `wallet.agent_main.debited`，消费者按权威事实幂等确认 |
-| 代理主钱包充值与人工调整正向入账 | 延期（测试环境冻结；生产前由 6.5 为入账补齐同事务 Audit Event） | 充值/人工调整业务事实、`tb_agent_wallet` 与唯一成功流水在同一事务形成权威事实 | N/A（本接缝不调用支付或审批外部系统） | 同事务写入 `wallet.agent_main.credited`，消费者按成功流水复核；支付/审批 Integration Log 由 UR#34 外部流程负责 |
+| 代理主钱包订单统一扣款 | 使用 `agent_wallet.order_debit`，关联订单、主钱包和唯一成功流水，保存余额前后值；成功与订单、钱包、流水及 Outbox 同事务，审计失败回滚，已定位订单后的失败/拒绝在业务回滚后写独立短事务 | `tb_order`、`tb_agent_wallet`、`tb_agent_wallet_transaction`、`tb_payment` 与套餐使用记录在同一事务形成权威事实；现有行锁、乐观锁和唯一业务引用保持不变 | N/A（不调用外部系统） | 同事务写入 `wallet.agent_main.debited`，为余额预警等后续消费者提供稳定事实；Audit Event 不替代 Outbox |
+| 代理主钱包订单资金预占、释放与完成扣除 | 使用 `agent_wallet.order_reserve/order_release/order_complete`，关联订单、主钱包、预占事实及完成时的唯一扣款流水，保存余额和冻结余额前后值；成功与原资金事务同写，重复终态不伪造事件 | `tb_agent_wallet_reservation` 是预占金额、付款钱包与唯一终态的权威事实；钱包与完成扣除流水同事务更新。当前生产仅取消订单调用 release，freeze/complete Application 接缝暂无生产调用者，已接好审计但不借本任务新增业务调用 | N/A（不调用外部系统） | 同事务写入 `wallet.agent_main.reservation.changed`；完成扣除同时写入 `wallet.agent_main.debited`，消费者按权威事实幂等确认；Audit Event 不替代 Outbox |
+| 代理主钱包充值与人工调整正向入账 | 充值沿用 `agent_recharge.credit`，以一条事件关联充值单、提交人、店铺、主钱包和唯一流水，避免为同一入账重复造事件；人工调整使用 `agent_wallet.adjust_balance`，要求保留人工原因并关联主钱包、唯一调整流水及余额前后值。成功与原资金事务同写，重复业务引用不伪造成功 | 充值/人工调整业务事实、`tb_agent_wallet` 与唯一成功流水在同一事务形成权威事实；当前没有人工调整生产入口，统一 Posting 接缝已覆盖但不借审计新增接口 | N/A（本接缝不调用支付或审批外部系统） | 同事务写入 `wallet.agent_main.credited`，消费者按成功流水复核；支付/审批 Integration Log 由代理充值外部流程负责，Audit Event 不替代 Outbox |
+| 代理主钱包实际信用额度更新 | 使用 `agent_wallet.change_credit`，关联主钱包及所属店铺，保存 balance/frozen_balance 不变事实、credit_enabled/credit_limit/version 前后值；成功与信用字段版本条件更新同事务，已定位钱包后的资金占用拒绝、版本冲突或审计回滚失败使用独立短事务 | `tb_agent_wallet` 是实际信用开关、额度、余额、冻结余额和版本的权威事实；保持现有可用额度及资金占用校验，不产生钱包流水 | N/A（本地信用配置不调用外部系统） | N/A（信用额度更新不产生可靠异步副作用） |
 | 代理在线充值支付链接创建 | 延期（测试环境冻结；创建人、店铺、金额和支付方式由充值单与支付单留痕，生产前按 6.5 复核 Audit Event） | `tb_agent_recharge_record` 与 `tb_payment` 同事务保存待支付事实和收款身份快照 | 微信 v3 H5/v2 MWEB 下单每次真实外呼写 Integration Log；支付宝 WAP URL 仅本地签名，N/A；后续查单与回调仍逐次记录 | N/A（创建阶段不产生可靠异步副作用；支付确认后才同事务写入钱包入账 Outbox） |
-| 代理订单主钱包退款回充 | 延期（测试环境冻结；生产前由 6.5 为退款资金变更补齐同事务 Audit Event） | 原成功扣款流水定位付款钱包并限定金额；退款审批、`tb_agent_wallet` 与唯一成功退款流水同事务形成权威事实 | N/A（本资金接缝不调用渠道或审批外部系统） | 同事务写入 `wallet.agent_main.refunded`，消费者复核退款流水、原扣款事实、金额上限和资产快照 |
+| 代理订单主钱包退款回充 | `refund.approve` 与退款单、订单、原扣款钱包、原扣款流水和唯一退款流水同事务；重复退款流水不重复写成功事件 | 原成功扣款流水定位付款钱包并限定金额；退款审批、`tb_agent_wallet` 与唯一成功退款流水同事务形成权威事实 | N/A（本资金接缝不调用渠道或审批外部系统；原路渠道退款尚未实现） | 同事务写入 `wallet.agent_main.refunded`，消费者复核退款流水、原扣款事实、金额上限和资产快照 |
 | 代理商资金概况信用投影 | N/A（普通受权读取；不返回其他数据范围的资金事实，不执行资金或配置变更） | 只读投影 `tb_shop`、主/佣金钱包、提现汇总和主账号；派生金额不另建事实表 | N/A（无外部系统调用） | N/A（纯 Query 不产生可靠副作用） |
 | 受控系统配置更新 | N/A（用户已明确取消全局 Audit Event；仅超级管理员可更新代码注册 Key，未知 Key、非法类型和值域均拒绝） | `tb_system_config` 是配置值、类型、模块及更新人的 PostgreSQL 权威事实，更新后失效 Redis 缓存 | N/A（配置更新不调用外部系统；不得写 Integration Log 冒充配置审计） | N/A（配置更新不产生可靠异步副作用） |
 | 电信实名结果回调 | N/A（Audit Event 已移出本 Change；运营商来源真实性验证也不在本票边界） | `tb_iot_card` 是实名状态、首次实名时间和逆转窗口的权威事实 | 每次入站先写 `tb_integration_log`，仅保存正文摘要；覆盖 `invalid_payload/ignored/not_found/conflict/success/failed` 终态 | 实名事实首次变化时由公共 `ApplyCardObservation` 同事务写入实名状态变化 Outbox；重复成功不重复写事件 |
@@ -90,31 +91,49 @@
 |---|---|---|---|---|
 | 换货迁移套餐在原订单退款后失效 | N/A（退款终态的自动后处理，不新增人工决定；人工申请与审批审计沿用退款入口） | 原订单、换货新旧资产关系和 `tb_package_usage` 是套餐权益来源及失效状态的权威事实；仅失效该订单迁移后的对应权益 | N/A（本地数据库后处理，不调用企微、支付或 Gateway） | 企微退款沿用 `approval.terminal_decision.recorded` 驱动；存量旧退款沿用原同步链路，本修复不新增 Outbox |
 | 订单渠道、资产标识、退款/充值/换货提交人和卡/设备实名筛选 | N/A（均为字段来源修正或受权只读投影，不改变订单、资产、实名或审批事实） | 只读既有订单 `purchase_role`、卡 ICCID、设备 VirtualNo/IMEI、创建人账号及有效卡绑定实名事实，不另建领域账本 | N/A（查询使用本地批量账号查询和 EXISTS，不实时调用外部系统） | N/A（纯查询和创建时既有字段赋值不产生新增可靠副作用） |
-| 换货创建前未终结退款拦截 | N/A（拒绝发生在换货事实写入前，拒绝原因进入 Access Log；不伪造成功业务审计） | `tb_refund_request` 的未终结状态是拦截依据；拒绝后不创建换货单、不修改资产 | N/A（本地前置校验，不调用企微或其他外部系统） | N/A（校验拒绝不产生业务事实或可靠副作用） |
+| 换货创建前未终结退款拦截 | 已识别旧卡或旧设备后分别使用 `exchange.card.create`、`exchange.device.create` 记录 `denied`，关联稳定换货单 Key、旧资产和店铺 | `tb_refund_request` 的未终结状态是拦截依据；拒绝后不创建换货单、不修改资产 | N/A（本地前置校验，不调用企微或其他外部系统） | N/A（校验拒绝不产生业务事实或可靠副作用） |
 | 店铺 C 端新登录限制配置与登录拦截 | 店铺更新入口记录操作者 `updater`、字段前后值进入 Access Log；本 Change 不新建店铺专用 Audit Writer，统一店铺配置 Audit Event 接缝登记为后续治理项 | `tb_shop.client_login_disabled` 是是否允许新登录的权威事实；已有 Token 不修改，拦截时不创建新 Token | N/A（配置更新与资产登录判断均为本地数据库操作） | N/A（同步配置与登录前拦截不产生必须可靠投递的提交后副作用） |
-| 卡/设备实名策略单个及批量更新 | 复用资产操作审计 `card_realname_policy` / `asset_realname_policy`，记录操作者、资产集合、策略和 success/failed 结果；批量业务更新先在单事务中全量校验并写入 | `tb_iot_card.realname_policy`、`tb_device.realname_policy` 是策略权威事实，C 端仅实时计算 `effective_realname_policy` | N/A（策略更新和读取均不调用运营商或其他外部系统） | N/A（策略同步更新不产生可靠异步副作用） |
+| 卡/设备实名策略单个及批量更新 | IoT 卡使用 `iot_card.realname_policy_update` / `iot_card.realname_policy_batch_update`，设备使用 `device.realname_policy_update` / `device.realname_policy_batch_update`；均记录真实后台操作者、目标资产、实际绑定卡/设备与卡槽引用、策略前后值及 success/failed/denied；批量根子事件与实际策略变化同事务 | `tb_iot_card.realname_policy`、`tb_device.realname_policy` 是策略权威事实，C 端仅实时计算 `effective_realname_policy` | N/A（策略更新和读取均不调用运营商或其他外部系统） | N/A（策略同步更新不产生可靠异步副作用） |
 | 下架套餐当前使用者续费与普通列表过滤 | N/A（普通受权查询与既有订单创建规则；订单创建继续沿用原订单/资金审计接缝） | 当前套餐使用记录决定续费资格，新订单、订单明细、套餐当前配置和支付记录是新购买权威事实；不修改历史订单 | 第三方支付仍沿用既有支付 Integration Log，本资格判断不新增外部调用 | 新订单支付、钱包扣款、自动购包及佣金继续沿用既有任务/Outbox，本切片不新增事件类型 |
 | 卡/设备 C 端支付方式配置更新 | 复用 `systemconfig.UpdateService` 的事务内 `AuditWriter`，记录操作者、请求标识及配置前后值；审计 Writer 已装配时写入失败会回滚配置更新 | `tb_system_config` 是卡、设备允许支付方式集合及更新人的 PostgreSQL 权威事实；Redis 仅为可失效缓存 | N/A（配置更新不调用外部系统） | N/A（提交后仅失效可重建缓存，不产生必须可靠投递的业务副作用） |
 | 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 稳定防重，消费端按事件与接收人唯一键幂等 |
+| 创建物流换货单并提醒关联个人客户 | 卡/设备换货分别使用 `exchange.card.create`、`exchange.device.create` 记录真实后台操作者、换货单、旧资产和店铺，成功事实与换货单及通知 Outbox 同一 GORM 事务 | `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.admin.dynamic.requested`，并向绑定个人账号写入 `notification.personal_customer.direct.requested`；列表和数量纯 Query 不产生 Outbox |
-| 企业微信应用连接配置保存与明文读取 | 配置保存复用 `systemconfig.AuditWriter`，只记录应用标识、状态和 `credentials_configured=true`；明文列表读取仅允许超级管理员，返回前以独立短事务同步写 `wecom.application.credentials_read`，审计缺失或失败均不返回结果；Application 先投影无凭据结构，Audit Writer 从类型上不接收 Secret、回调 Token 或 EncodingAESKey | `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 |
+| 主套餐过期接续与孤儿恢复 | N/A（系统自动推进套餐生命周期，不包含人工敏感操作） | `tb_package_usage` 是套餐待生效、生效、用完和过期状态的权威事实 | N/A（仅使用本地 PostgreSQL 与 Redis，不新增外部请求） | 成功激活继续在同一事务复用 `card.observation.series.requested`，稳定事件 ID 基于套餐使用记录 ID；不新增套餐激活事件类型或消费者 |
+| 企业微信应用连接配置保存与明文读取 | 配置保存和默认发起人分别使用 `wecom.application.save`、`wecom.application.save_default_creator`，只记录应用标识、状态和真实 `credentials_configured` 布尔事实；明文列表读取仅允许超级管理员，返回前以独立短事务同步写 `wecom.application.credentials_read`，审计缺失或失败均不返回结果；Audit Writer 不接收 Secret、回调 Token 或 EncodingAESKey | `tb_wecom_application` 是 corp_id、agent_id、应用状态及明文 Secret、回调 Token、EncodingAESKey 的权威事实；管理响应按用户确认向超级管理员返回明文 | 保存和读取本身不调用企微；连接测试或 token 缓存未命中时，每次真实回源均写 `tb_integration_log`，请求和响应摘要不含 Secret、回调凭据或 access_token | N/A（连接配置提交后仅同步失效可重建 token 缓存，不产生必须可靠投递的业务副作用） |
+| 支付连接配置 CRUD 与启停 | 使用 `payment_config.create/update/delete/activate/deactivate`，保存配置 ID、名称、渠道、启用状态、非敏感商户/应用标识和各渠道 `credentials_configured` 安全事实；不保存 Secret、Token、AESKey、支付密钥、私钥、公钥正文或证书正文。创建字段校验、删除生效配置或在途业务等已定位资源后的拒绝写独立短事务；激活其他配置时为被自动停用的原配置另写同事务停用事件 | `tb_wechat_config` 是配置及明文渠道凭据的权威事实；CRUD/启停与 Audit Event 同一 GORM 事务，审计失败回滚配置事实，提交后 Redis 缓存仅 best-effort 失效 | N/A（配置 CRUD/启停不调用渠道；支付、查单和回调的真实外部尝试仍由 7.4 Integration Log 负责） | N/A（配置提交不产生可靠异步副作用） |
+| 运营商配置 CRUD 与启停 | 使用 `carrier.create/update/delete/update_status`，保存配置 ID、编码、名称、类型、状态、流量重置日和实名链接业务配置；重复编码、非法模板配置等已定位资源后的拒绝进入独立短事务 | `tb_carrier` 是运营商及实名链接配置权威事实；成功审计与 CRUD/状态变更同一 GORM 事务 | N/A（本切片只改本地运营商配置，不调用 Gateway 或运营商） | N/A（同步配置不产生可靠异步副作用） |
+| 运营商回调开关与卡/设备支付方式等受控连接策略 | 继续复用 `system_config.updated`，记录注册 Key、模块、前后值、操作者和请求链路；只读、非法值和事务失败沿用已落地的拒绝/失败短事务策略 | `tb_system_config` 是回调启停和支付方式策略权威事实，代码 Registry 默认值与 Redis 缓存不替代 PostgreSQL | N/A（配置本身不调用运营商或支付渠道；真实回调/支付尝试由各自 Integration Log 记录） | N/A（提交后仅失效可重建缓存） |
+| 企业微信可见成员同步与账号显式绑定 | 成员同步使用 `wecom.application.sync_members`，记录应用身份、状态、同步数量和时间，成员快照替换与 Audit Event 同一事务；账号绑定继续使用 `account.bind_wecom`，记录操作者、目标账号及绑定前后 `(corp_id, userid, name)`，不记录手机号或邮箱 | `tb_wecom_member` 是最近同步的应用可见成员选择快照，`tb_account.wecom_*` 是管理员确认后的账号绑定事实；不建立部门组织模型 | 每次真实调用应用可见成员接口均写 `tb_integration_log`，仅记录应用、根部门、成员数量、状态码和耗时，不保存 access_token 或成员列表正文 | N/A（同步和绑定均为同步事务，不产生必须可靠投递的提交后副作用） |
+| 企业微信审批业务场景与模板控件映射 | 配置保存使用 `wecom.approval_scene.save`，记录场景 ID、业务类型、应用 ID、模板 ID/名称、状态、指纹和最近校验时间；配置与审计同事务，不保存凭据、审批节点或审批人规则到审计数据 | `tb_wecom_approval_scene` 是两个稳定业务类型的当前模板、控件映射、模板最小快照和启用状态权威事实 | 保存前每次真实调用模板详情接口均写 `tb_integration_log`，记录应用、模板 ID、状态码、控件数量和耗时，不保存 access_token 或完整外部响应 | N/A（配置保存为同步事务，不产生必须可靠投递的提交后副作用） |
+| 企业微信默认发起人与审批提交 | 默认发起人配置继续复用事务内 `systemconfig.AuditWriter`；业务事务创建通用审批时写 `approval.request`，关联真实提交账号、退款或线下充值业务单及 `approval.submission.requested` Outbox。企微提交 Worker 以 `system_task/worker` 写 `approval.sync_submission` 的 success/failed/unknown，不以默认成员伪造操作者 | `tb_wecom_application.default_creator_*` 是当前默认发起配置，`tb_approval_instance` 与 `tb_wecom_approval_context` 是审批和提交状态权威事实；Audit Event 仅保存状态变化及稳定引用 | 每次附件上传和 applyevent 均写精确 Integration Log；摘要不含 Secret、access_token、media_id、附件正文或完整企微响应；提交审计引用对应 `integration_id`，但不替代或冻结其可变结果 | 业务事务写入 `approval.submission.requested`；Worker 条件领取后只提交一次，明确失败和结果未知均终结自动重试，禁止盲目创建第二张审批单 |
+| 企业微信审批加密回调与详情终态同步 | 首次权威终态写 `approval.sync_decision`，回调使用真实 `external_system/callback` actor，关联审批实例、业务单、真实提交账号、入站回调/详情 Integration 及终态 Outbox；不记录本地或企微审批人为操作者。重复终态未改变审批事实时不伪造成功事件 | `tb_integration_log` 保存回调和详情外部事实，`tb_wecom_approval_context.latest_detail_snapshot`、通用审批实例及决策投递表保存权威标准终态；Audit Event 与审批状态、决策投递和终态 Outbox 同事务 | 入站回调先写 Integration Log pending，详情任务完成后置 completed；每次 `getapprovaldetail` 写独立出站 Integration Log。审计只引用稳定 `integration_id` 与身份字段，不保存 access_token、完整响应或尚可变化的 Integration result | 回调只入队结构化 `wecom:approval:sync` 任务；权威终态原子写 `approval.terminal_decision.recorded`，退款和线下充值消费者继续使用既有业务/资金审计，并传播终态 Outbox 的 correlation/parent |
+| 企业微信审批主动恢复、未终态轮询与审批人读取投影 | 唯一确认结果未知提交时写 `approval.recover_submission`：回调恢复使用 `external_system/callback`，主动恢复使用 `scheduled_job/scheduler`；轮询取得首次权威终态写 `approval.sync_decision`。普通审批人读取投影仍为 N/A；重复恢复或重复终态未改变事实时不写成功事件 | `tb_wecom_approval_context.submission_attempted_at/last_recovery_at/sp_no/latest_detail_snapshot` 与通用审批实例是恢复和展示的权威本地事实；只有唯一候选可从结果未知转为审批中 | 每次 `getapprovalinfo` 分页和 `getapprovaldetail` 均写独立出站 Integration Log，恢复审计关联实际提交或查询 Integration；只保存安全摘要，不保存 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` 唯一成功钱包流水幂等入账，其他终态不修改钱包，通过后撤销不自动冲正；`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`；在线充值复用同一入账接缝；新审批单禁止旧人工确认或驳回入口绕过 |
 | 代理充值列表、详情与支付状态读取 | N/A（普通受权读取；请求进入 Access Log，不改变充值、支付或钱包事实） | 只读 `tb_agent_recharge_record`、相关支付单和店铺名称；平台账号不限制，代理账号统一按当前上下文的自身及下级店铺 ID 过滤 | N/A（不调用支付渠道或企微） | N/A（纯 Query，不产生 Outbox） |
-| 退款申请与企微终态处理 | 申请以真实提交人和订单/金额/凭证明文快照留痕；企微自动终态不伪造本地人工审批人，资金与佣金 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`；业务消费者只有在订单、钱包、佣金和资产后处理完成后才确认投递成功，失败释放租约重试 |
+| 退款申请与企微终态处理 | 申请、人工/企微通过与拒绝、退回、重提使用 `refund.create/approve/reject/return/resubmit`；佣金实际回扣使用 `refund.invalidate_commission`，资产后处理完成使用 `refund.process_asset`。成功事实与各自 Domain Ledger 同事务，已定位退款后的失败/拒绝使用独立短事务；代理/企业仅看到“已提交/已通过/已拒绝/处理完成”等安全结论 | `tb_refund_request`、通用审批实例和企微上下文同事务保存；approved 条件更新订单与退款单，代理主钱包按 refund ID、资产钱包按退款单号复核成功回款；佣金按记录锁定并失效，套餐按订单及换货迁移关系幂等失效；`tb_notification` 保存退款完成通知。Audit Event 关联退款、审批、订单、资产、钱包、原扣款/退款流水、佣金、实际失效套餐权益和通知 Outbox，但不替代这些权威事实 | 申请创建不外呼；附件、applyevent、详情、回调和恢复沿用企微 Integration Log，业务参数明文保存在业务/审批快照中但不复制到 Integration Log，Secret、access_token、media_id 和附件正文仍禁止记录；原路渠道退款未实现，Integration Log 明确 N/A | 创建事务写 `approval.submission.requested`；终态写 `approval.terminal_decision.recorded`；退款事务幂等写目标店铺的 `notification.admin.dynamic.requested`；通知继续以 Outbox 为权威投递事实，Audit Event 仅保存稳定引用；业务消费者只有在订单、钱包、佣金和资产后处理完成后才确认投递成功，失败释放租约重试 |
 | 退款与线下代充值旧审批入口发布切换 | 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 |
-| 钱包流水与代理充值业务导出 | N/A：只读投影，不改变钱包、充值或审批状态；任务创建操作者与店铺权限快照沿用现有导出任务记录 | N/A：只读取主钱包流水、充值记录和本地通用审批实例；金额及余额使用既有权威事实，不写入领域账本 | N/A：不实时调用支付渠道或企业微信；明文业务凭证 Key 只进入导出结果，不复制到 Integration Log，且仍禁止记录 Secret、access_token、media_id 和附件正文 | 仅沿用现有 `export:dispatch` → `export:shard` → `export:finalize` Asynq 链路，不新增业务 Outbox |
-| 退款与换货业务导出 | N/A：只读投影，不改变退款、换货、资产或审批状态；任务创建操作者与店铺权限快照沿用现有导出任务记录 | N/A：只读取退款、订单、套餐使用、换货资产快照和本地审批事实；金额及处理标记沿用既有权威事实，不写入领域账本 | N/A：不实时调用企业微信、支付或 Gateway；明文业务凭证和收货资料只进入有权导出结果，不复制到 Integration Log，且仍禁止记录 Secret、access_token、media_id 和附件正文 | 仅沿用现有 `export:dispatch` → `export:shard` → `export:finalize` Asynq 链路，不新增业务 Outbox |
-| IoT 卡固定档位限速 | 复用资产操作审计 `card_speed_tier`，记录后台操作者、卡 ICCID、固定档位、Integration Log ID 和 success/failed 结果；设备无入口且不通过绑定卡间接限速 | N/A：不在本地保存或修改卡当前限速状态，Gateway 是外部执行方 | 每次实际 Gateway 调用前写 pending，按 success/failed/unknown 终结；超时 unknown 保存按 ICCID 人工核对策略，摘要不含 Secret、access_token 或完整响应正文 | N/A：单次外部命令无后续可靠副作用，结果未知禁止盲目重发，不创建自动补偿 Outbox |
-| 设备 CSV 批量分配、设置套餐系列或回收 | 任务记录冻结操作者和可选目标；逐批复用 `device_allocate`、`device_series_binding` 或 `device_recall` 资产操作审计，记录设备前后值、目标、成功/失败数和失败原因；任务查询的 `target_name` 仅批量投影当前店铺或套餐系列名称 | N/A：设备归属、绑定卡归属、分配记录及 `series_id` 是权威业务事实，不另建领域账本 | N/A：CSV 解析、分配和回收均为本地数据库操作，不调用 Gateway、支付或企微；对象存储沿用现有存储日志 | 复用 `device:import` Asynq 任务；状态条件阻止完成任务重复执行，处理中断恢复时已达到目标关系的设备按成功处理，不新增业务 Outbox |
+| IoT 卡/设备导入与设备 CSV 批量操作 | 创建使用 `iot_card_import_task.create`、`device_import_task.create`，完成使用对应 `*.complete` 根事件；任务只保存 ID/单号、文件名、运营商或操作目标和操作者，不保存 StorageKey、签名 URL 或文件正文。每张实际新增卡/设备继续使用既有 `iot_card.create/device.create` 业务子事件并以完成根为 parent；设备 CSV 分配/系列/回收继续复用既有批量根子审计。跳过项不伪造子事件，根事件 success/partial/failed 与实际子事件及失败统计一致 | `tb_iot_card_import_task`、`tb_device_import_task` 保存任务输入、进度和逐项结果；卡、设备、资产标识、卡槽绑定、钱包及分配/系列事实仍由原业务表权威保存，Audit Event 不替代任务或资产事实 | 对象存储下载只读取任务表中的 StorageKey，不写 Integration Log；审计源头只使用安全文件名。设备批量操作本身不新增外部调用 | HTTP 创建继续提交结构化 `IotCardImportPayload/DeviceImportPayload`；Worker 使用任务单号 correlation 和稳定完成根 parent，重试通过稳定 EventID 与原业务幂等规则避免重复子事件 |
+| 单列 CSV 资产套餐批量订购 | 使用 `asset_package_batch_order_task.create/complete` 记录任务、文件名、套餐目标、支付方式、操作者和实际根子统计；既有 `order.create` 作为每个真实订单子事件并继承任务 correlation/parent，不另造同义订单审计。StorageKey、VoucherKey、签名 URL 和 CSV 正文不进入审计 | `tb_asset_package_batch_order_task` 保存输入参数和逐行结果，成功行以 `tb_order`、订单明细、套餐使用、支付记录及代理钱包成功流水为权威业务事实 | 对象存储上传和下载沿用现有存储日志，不把文件正文写入 Integration Log；本切片不新增外部支付或 Gateway 调用 | 创建接口提交结构化 `asset:package:batch_order` Asynq 任务；逐行钱包订单继续沿用既有钱包扣款 Outbox 和佣金任务，重复任务由状态条件与订单幂等规则阻断 |
+| 订单套餐 CSV 批量失效 | 使用 `order_package_invalidate_task.create/complete` 记录任务根，使用 `order_package_invalidate_task.item` 为每个实际变化或已识别失败订单写子事件；订单为主要资源，实际失效套餐权益逐条关联并保存状态 `before→4`。无有效权益的幂等行不伪造变化子事件；任务 UI 统计与审计实际子事件统计分别保留 | `tb_order_package_invalidate_task` 保存文件任务状态和失败明细，`tb_package_usage.status` 是套餐权益终态权威事实；逐订单状态更新与子事件同一事务，任务终态与完成根同一事务 | 对象存储只用于读取 CSV，StorageKey、VoucherKey、签名 URL 和文件正文不进入 Audit/Integration | 创建接口提交结构化 `InvalidateTaskPayload`；Worker 原子 Claim，审计失败时任务恢复待处理以便安全重试，稳定子事件 ID 防止重复写入 |
+| ICCID 批量生成待失效订单号 CSV | N/A（脚本复用现有受权资产套餐查询，属于运维只读投影；请求进入 Access Log，不改变套餐或订单事实） | N/A（只读取 `tb_package_usage` 的状态和订单号快照，不写入领域账本；实际失效仍由既有批量失效任务负责） | N/A（只调用本系统后台接口，不调用 Gateway、支付或其他外部系统） | N/A（纯查询和本地 CSV 生成，不产生 Outbox 或异步任务） |
+| CSV 批量修改生效中套餐过期时间 | 每条修改复用既有 `asset_package_expires_at` 资产操作审计，记录操作者、资产、套餐使用记录及过期时间前后值和 success/failed 结果 | `tb_package_usage.expires_at` 是套餐过期时间权威事实；脚本只通过受权接口逐条修改，不直连数据库 | N/A（仅调用本系统后台接口，不调用 Gateway、支付或其他外部系统） | N/A（同步修改不产生新增 Outbox；后续套餐过期推进沿用既有轮询任务） |
+| IoT 卡与套餐业务导出 | 创建/取消统一使用 `export_task.create/cancel`，记录任务单号、scene、format、真实操作者和店铺范围；取消状态或取消请求与 Audit Event 同事务。导出 Query、FileKey、签名下载 URL 和导出内容不进入审计；导出数据读取本身仍为 N/A | N/A：导出只读取现有卡、套餐使用、套餐和分配事实，不写入领域账本 | N/A：不调用外部业务系统；对象存储文件生成和下载沿用现有导出基础设施日志 | 沿用现有 `export:dispatch` → `export:shard` → `export:finalize` Asynq 链路，不新增业务 Outbox；审计中心自身不注册导出路由 |
+| 钱包流水与代理充值业务导出 | 创建/取消统一使用 `export_task.create/cancel`，只保存任务身份、格式、操作者和受控店铺范围，不复制 Query、业务凭证 Key、FileKey、签名 URL 或导出内容 | N/A：只读取主钱包流水、充值记录和本地通用审批实例；金额及余额使用既有权威事实，不写入领域账本 | N/A：不实时调用支付渠道或企业微信；明文业务凭证 Key 只进入有权导出结果，不复制到 Audit/Integration，且仍禁止记录 Secret、access_token、media_id 和附件正文 | 仅沿用现有 `export:dispatch` → `export:shard` → `export:finalize` Asynq 链路，不新增业务 Outbox；取消重复请求不伪造新的状态变化事件 |
+| 退款与换货业务导出 | 创建/取消统一使用 `export_task.create/cancel`；平台或代理 actor、scene/format 和当前权限范围进入任务资源，Query、收货资料、业务凭证、FileKey、签名 URL 与结果正文不进入审计 | N/A：只读取退款、订单、套餐使用、换货资产快照和本地审批事实；金额及处理标记沿用既有权威事实，不写入领域账本 | N/A：不实时调用企业微信、支付或 Gateway；明文业务凭证和收货资料只进入有权导出结果，不复制到 Audit/Integration，且仍禁止记录 Secret、access_token、media_id 和附件正文 | 仅沿用现有 `export:dispatch` → `export:shard` → `export:finalize` Asynq 链路，不新增业务 Outbox；审计中心不提供用户导出 |
+| 站内通知生成、已读与保留清理 | Outbox 消费实际生成通知使用 `notification.deliver`，只保存通知 ID、事件 ID、接收人、类别、类型、严重级别和受控资源引用，不复制标题或正文；后台账号与个人客户首次单条/全部已读使用 `notification.read/read_all`，重复已读不伪造事件；保留清理使用 `notification.cleanup/cleanup_item`，由 `system_task/worker` 记录批次和每条实际删除通知。通知创建、已读更新或物理删除与对应 Audit Event 共用 GORM 事务，审计失败回滚业务事实 | `tb_notification` 继续是通知内容、接收人、展示期限和已读状态的权威事实；Audit Event 只解释生成、阅读和清理动作，不替代通知正文或接收状态 | N/A：站内通知不调用短信、邮件、企微或其他外部系统；受控 `ref_id/ref_key` 禁止 URL，系统安全凭据和通知正文不进入审计 | 业务事务仍只写现有三类结构化通知请求 Outbox；Outbox 投递事实与通知生成 Audit Event 分离，重复消费由事件+接收人唯一键幂等；清理继续复用 `notification:cleanup` Asynq 计划任务，不新增 Outbox |
+| IoT 卡固定档位限速 | 统一动作 `iot_card.speed_tier_set` 记录认证上下文中的真实操作者、目标卡 ID/ICCID、请求档位编码与名称（如 128Kbps/1Mbps/恢复不限速）、Integration Log ID、Integration 是否终结及 success/failed/unknown 结果；设备无入口且不通过绑定卡间接限速 | N/A：不在本地保存或修改卡当前限速状态，Gateway 是外部执行方 | 每次实际 Gateway 调用前写 pending，按 success/failed/unknown 终结；超时 unknown 保存按 ICCID 人工核对策略，摘要不含操作者或 Secret、access_token、完整响应正文 | N/A：单次外部命令无后续可靠副作用，结果未知禁止盲目重发，不创建自动补偿 Outbox |
+| IoT 卡人工实名状态纠偏 | `iot_card.realname_status_update` 记录真实后台操作者、目标卡、实名状态前后值及是否实际变化；状态事实、Audit Event 和实名变化 Outbox 在同一 GORM 事务，失败写独立短事务 | `tb_iot_card.real_name_status`、首次实名时间及激活字段是内部实名事实 | N/A（人工纠偏不直接调用 Gateway） | 状态实际变化时复用 `card.realname.changed`，未变化不伪造变化事件 |
+| IoT 卡后台/个人人工刷新 | 后台使用 `iot_card.manual_refresh`，个人客户使用 `iot_card.personal_refresh`；记录真实 actor、目标卡、实际状态变化及最终 success/partial/failed/unknown，任一结果未知不写成成功 | 卡网络、实名、流量及 `last_sync_time` 是内部观测事实；各实际变化与统一 Audit Event 同事务 | 网络、实名、流量查询的每次真实 HTTP 尝试分别写 Integration Log；失败/超时逐次终结，成功尝试在内部应用结果确定后记录 `state_changed` | 实名、网络、流量实际变化沿用各自 Card Observation Outbox；人工刷新汇总不另造可靠事件 |
+| IoT 卡人工/OpenAPI/自动/保护期停复机 | 分别使用 `iot_card.manual_stop`、`iot_card.manual_start`、`iot_card.openapi_start`、`iot_card.auto_stop`、`iot_card.auto_start` 和 `iot_card.auto_stop_reason_update`；记录真实人工/OpenAPI/system actor、目标卡、关联设备与卡槽、停复机原因、状态前后值、Integration ID 及 success/failed/denied/unknown；保护期强制修正复用同一服务，不再旁路审计 | `tb_iot_card.network_status/stopped_at/resumed_at/stop_reason/gateway_extend` 是内部状态权威事实 | 保持既有内外层重试次数和退避；每次真实 Gateway HTTP 分别写同一 `trigger_series` 下单调递增 attempt，超时为 unknown，成功尝试待状态事务结束后终结 | 状态、Audit Event 与 `card.observation.series.requested` 同事务；停复机完成后沿用轮询重排，不新增补偿 Outbox |
+| 单笔资产分配/回收 | 当前无独立通用单笔写入口；IoT 卡和设备同步分配/回收接口在请求仅含一个资产时，分别复用 `iot_card.allocate/recall` 和 `device.allocate/recall` 单资源子事件，记录真实后台或代理操作者、资产、分配记录、来源/目标店铺；设备同时关联实际连带变化的卡和卡槽 binding。每个已识别资源的拒绝/失败仍进入对应子事件，不另造 `asset.*` 重复动作 | 卡/设备归属与状态、实际连带卡归属及 `tb_asset_allocation_record` 是权威业务事实；单项事实、分配记录和 Audit Event 沿用 6.2/6.5 已有同一 GORM 事务 | N/A（本地资产归属事务，不调用 Gateway、支付、企微或其他外部系统） | N/A（同步流转不产生新增可靠副作用；提交后缓存失效和轮询通知保持既有顺序）。批量请求根事件及 CSV 批量任务分别沿用 6.2/6.5 和 6.9，不在本切片重复实现 |
+| 设备 CSV 批量分配、设置套餐系列或回收 | Worker 使用真实 `system_task/worker` 上下文，每个任务以稳定 `task_no` 作为 correlation 和批次键，仅对尚未达到目标关系的设备调用一次现有设备批量服务，复用 `device.allocate_batch`/`device.allocate`、`device.series_binding_batch`/`device.series_binding` 或 `device.recall_batch`/`device.recall` 根子事件；根事件统计与已识别设备子事件一致，实际绑定卡和卡槽随设备子事件进入各自资源时间线，不再另写 CSV 专用设备事实审计。任务查询的 `target_name` 仅批量投影当前店铺或套餐系列名称 | 设备归属、实际绑定卡归属、`tb_asset_allocation_record` 及 `series_id` 是权威业务事实；成功事实与 Audit Event 共用设备服务原 GORM 事务，审计失败回滚业务，不另建领域账本 | N/A：CSV 解析、分配、系列绑定和回收均为本地数据库操作，不调用 Gateway、支付或企微；对象存储沿用现有存储日志 | 复用 `device:import` Asynq 任务；完成/失败状态阻止终态任务重复执行，处理中断恢复时已达到目标关系的设备不再写业务事实或成功子事件，其余设备仍使用相同 `task_no` 保持审计幂等，不新增业务 Outbox |
+| 设备停复机、Wi-Fi、切卡模式、重启和重置 | 使用 `device.stop`、`device.start`、`device.set_wifi`、`device.set_switch_mode`、`device.reboot`、`device.reset`，记录后台、个人或 OpenAPI 的真实 actor/source、设备、实际绑定卡与卡槽引用、命令参数、Integration ID 及 success/failed/denied/unknown；Wi-Fi 只记录 `credentials_configured`，不记录密码；当前卡切换由独立卡槽关系用例记录 | 停复机只修改实际处理卡的 `network_status/stopped_at/resumed_at/stop_reason`；Wi-Fi、模式、重启和重置无同步本地状态变化，只记录外部命令结论，不伪造设备字段已生效；`enabled` 当前未下发，登记 N/A | 保留 Gateway 既有重试与退避，每次真实 HTTP 尝试写同一 `trigger_series` 下的独立 attempt；停复机按实际卡记录，其他命令按设备记录；超时为 unknown，成功尝试在本地事务结果明确后终结 | 停复机的卡状态、Audit Event 与既有 `card.observation.series.requested` 同一事务，并保留保护期和轮询缓存失效；其他命令成功后沿用 best-effort 观测分发。Worker/Scheduler/Callback 不直接执行这些设备命令，自动停复机继续由 6.3 卡级审计覆盖 |
+| 设备绑卡、解绑与当前卡切换 | 使用 `device.bind_card`、`device.unbind_card`、`device.switch_current_card`；记录后台账号、个人客户或 OpenAPI 的真实 actor/source，设备、目标卡、旧/新当前卡及实际相关 binding 均为独立资源，binding 快照及 before/after 固化 `slot_position/is_current`；设备导入和删除产生的隐式绑卡/解绑继续使用既有 `device.create/delete`，但同样关联每张卡和 binding；已识别设备后的拒绝、失败和 unknown 使用独立短事务 | `tb_device_sim_binding.bind_status/slot_position/is_current` 是设备 1-4 卡槽及当前卡的权威内部事实；绑卡创建、解绑状态和切卡当前标识与 Audit Event 同一 GORM 事务，卡的 `device_virtual_no` 仍保持原提交后 best-effort 快照语义 | 绑卡、解绑 N/A（纯本地事务）；切卡每次真实 Gateway HTTP 尝试写相同 `trigger_series` 下的独立 Integration Log attempt，超时为 unknown，目标卡必须是当前设备有效绑定卡；Integration 只表达外呼结果，不提前声称本地状态已变化 | 切卡成功后保留既有 Card Observation best-effort 分发，用 Gateway 后续观测校准真实当前槽位；观测 Worker 的自动回写属于 8.7，本切片不重复审计；不新增 Outbox 类型，不迁移设备/卡其他状态机。后台绑卡/解绑只有平台入口，切卡三类入口汇聚共享 Service；三组旧资产 operation log 已停止 |
+| 订单创建、取消、钱包支付与过期关闭 | 使用 `order.create`、`order.cancel`、`order.wallet_pay`、`order.expire_close`；后台创建/代购记录真实账号，C 端记录个人客户，代理 OpenAPI 记录 OpenAPI actor，资产套餐批量订购逐笔记录 `system_task/worker`，过期关闭记录 `scheduled_job/scheduler`。事件关联订单、买家、卡或设备、套餐、实际钱包/流水和 Payment，订单快照保存金额、支付方式/状态、购买角色及操作者；成功与原订单事务同写，已识别订单或资产后的拒绝/失败使用独立短事务。普通订单列表和详情仍为受权读取 N/A | `tb_order`、`tb_order_item`、`tb_payment`、`tb_package_usage`、`tb_agent_wallet`/`tb_asset_wallet` 及对应唯一流水继续是订单、套餐和资金权威事实；Audit Event 不替代余额、支付或权益账本。钱包下单及待支付后的钱包支付均在原 GORM 事务内追加审计，审计失败回滚业务；重复命中且未发生状态变化时不伪造成功事件 | 本切片不直接调用支付渠道或 Gateway，Integration Log=N/A；微信、支付宝、富友预下单、查单和回调属于 7.4，不能用订单事件替代外部尝试记录 | 代理钱包扣款继续在同一事务写既有钱包 Outbox，佣金任务和套餐观测沿用原提交后链路；Audit Event 不替代 Outbox。OpenAPI/CSV 批量根事件与 partial 统计属于 8.3，本切片只记录每笔实际订单，不提前伪造批次根事件 |
+| 支付外部尝试与内部终态 | 使用 `payment.create`、`payment.confirm`、`payment.fail`；没有独立 Payment 的旧订单回调使用 `order.online_pay`。支付单为主要资源，订单或充值单为业务单资源，渠道交易号保存在支付快照；个人资产充值确认同时关联实际变化的钱包和唯一流水。支付创建、明确关闭及回调确认均与对应 Payment、订单、充值或钱包 Domain Ledger 共用原 GORM 事务，重复回调未发生状态变化时不重复写成功 Audit Event | `tb_payment`、`tb_order`、`tb_recharge_order`、`tb_agent_recharge_record`、钱包及唯一流水继续是支付、订单、充值和资金权威事实；Audit Event 只解释操作者、回调来源、资源关系及前后状态，不替代支付状态、到账金额或渠道交易号 | 微信/富友真实预下单、代理充值微信/支付宝查单及所有已识别的微信/支付宝/富友回调逐次写 Integration Log，使用稳定 `trigger_series+attempt`、支付单号 correlation 和渠道交易号幂等；成功回调仅在内部状态真实变化时标记 `state_changed`。支付宝 WAP URL 由本地签名生成，Integration Log=N/A；当前没有富友主动查单实现，登记 N/A，不虚构外部尝试 | 支付确认后既有佣金、套餐恢复、自动购包及代理充值入账 Outbox 保持原链路；Audit Event 和 Integration Log 均不替代 Outbox。个人/代理充值完整创建至入账、钱包资金专项分别留给 7.6～7.9，本切片不修改渠道协议、金额校验、价格、佣金、套餐激活、钱包算法或状态机 |
+| 个人资产充值与代理在线/线下充值 | 个人资产充值继续以 `payment.create/confirm/fail` 记录支付生命周期，并补齐真实个人客户、卡/设备、资产钱包和充值单资源；代理充值使用 `agent_recharge.create/credit/close` 记录线下申请、审批终态、在线/线下真实入账和关闭，支付事件补齐提交账号、目标店铺及主钱包。支付回调使用 `external_system/callback`，主动恢复使用 `scheduled_job/scheduler`，Outbox 入账和自动购包使用 `system_task/worker`，不伪造最初提交人；重复支付、重复审批和重复入账未改变事实时不重复写成功事件 | `tb_recharge_order`、`tb_agent_recharge_record`、`tb_payment`、`tb_asset_wallet`/`tb_agent_wallet` 及唯一成功流水继续是充值与资金权威事实；成功 Audit Event 与充值状态、钱包余额、唯一流水及必要 Outbox 共用原 GORM 事务，审计失败回滚业务。`asset_recharge.auto_purchase` 与自动创建订单、钱包扣款流水、Payment、套餐权益和充值单自动购包状态同事务，最终失败状态同样与 failed 审计同事务 | 微信、支付宝、富友预下单、回调和代理主动查单沿用 7.4 的逐次 Integration Log；unknown 只表示外部结果未确认，不推进充值或钱包事实，也不伪造成功 Audit Event。线下申请创建和本地钱包入账不外呼，Integration Log=N/A；企微提交、终态同步与主动恢复继续由审批链 Integration Log 负责 | 代理在线支付确认继续写 `agent_recharge.payment_confirmed.v1`，由 Outbox 消费者幂等入账；线下申请继续写审批提交 Outbox，审批通过后同事务写钱包 credited Outbox；个人资产充值到账后沿用自动购包 Asynq，自动购包继续写观测 Outbox。旧线下人工确认的账号 operation log 裸 goroutine 已停止；不新增充值渠道，不改变金额、钱包、审批、套餐激活或自动购包规则 |
 
 ### `deliver-july-iteration-confirmed-scope` 任务覆盖映射
 
@@ -141,21 +160,42 @@
 - 企业创建、基础资料、状态和账号改密已切换统一 Writer：分别使用 `enterprise.create`、`enterprise.update`、`enterprise.update_status`、`enterprise.update_password`，企业为主要资源，归属店铺为引用资源，实际企业账号为受影响资源；成功审计与企业/账号事实共用 GORM 事务，改密仅保存 `credentials_configured/state` 安全事实，不借审计改变原令牌行为。普通企业列表保持 N/A，资产授权明确留给 5.8/5.9；这些入口原本不存在旧 operation log 写入。
 - 企业卡授权、回收和授权备注已切换统一 Writer：分别使用 `enterprise_card.allocate_cards`、`enterprise_card.recall_cards`、`enterprise_card.update_record_remark`，企业为主要资源，owner shop 为引用资源，实际变化的 IoT 卡和授权记录为受影响资源；授权事实与 Audit Event 共用 GORM 事务，重复有效授权不伪造变化。卡资源仅保存 `subject_result`安全结论，授权记录及备注保持 `internal_only`；`BatchAuthorize` 与 `RevokeAuthorizations` 无生产调用方、`AllocateCardsPreview` 为普通读取，均登记 Audit Event N/A。设备授权留给 5.9，本切片不改变卡授权有效性规则，也不引入第二套 Writer。
 - 企业设备授权与回收已切换统一 Writer：使用 `enterprise_device.allocate_devices`、`enterprise_device.recall_devices`，企业为主要资源，owner shop 为引用资源，实际变化的设备、设备授权、随设备处理的绑定卡及卡授权为受影响资源，实际卡槽绑定仅作为引用快照。授权创建与 Audit Event 共用 GORM 事务并锁定设备与当前卡槽绑定；回收改为事务内行锁和条件更新，按事务内真实命中项返回计数，不再调用持有独立 `db` 的 Store 方法形成伪事务。Service 边界显式拒绝空筛选和非法选取模式，参数错误不写 Audit Event；企业/设备越权统一同错，零成功及并发全项冲突使用独立短事务写 `denied`。企业账号被明确拒绝，平台/代理继续复用 `CanManageEnterprise`，代理设备范围保持既有“仅本店设备”规则；设备与卡仅保存 `subject_result`，授权记录与卡槽绑定保持 `internal_only`。本切片不改变 1-4 卡槽绑定规则，不停止设备或卡的旧资产 Writer（对应后续 6.x 用例）。
-- 个人客户资料、手机号与微信主体已切换统一 Writer：使用 `personal_customer.update_profile`、`personal_customer.bind_phone`、`personal_customer.change_phone`、`personal_customer.update_wechat_identity`，个人客户为主要资源，实际手机号或 OpenID 关系为受影响资源；资料更新、手机号绑定/换绑、客户或 OpenID 实际创建/同步与 Audit Event 共用 GORM 事务，已识别客户后的业务拒绝或失败使用独立短事务。actor/source 固定为真实 `personal_customer/personal_api`，主体投影为 Registry 白名单约束的 `subject_detail`；验证码、JWT、Cookie 和 Redis Token 不进入审计。重复微信登录且资料/OpenID 无变化不写资料事件，普通 `GetProfile`、资产令牌签发、登录 Token 签发与读取保持 N/A；客户资产绑定仍留给 5.11，登录链路不会伪造该任务已迁移。
+- 个人客户资料、手机号与微信主体已切换统一 Writer：使用 `personal_customer.update_profile`、`personal_customer.bind_phone`、`personal_customer.change_phone`、`personal_customer.update_wechat_identity`，个人客户为主要资源，实际手机号或 OpenID 关系为受影响资源；资料更新、手机号绑定/换绑、客户或 OpenID 实际创建/同步与 Audit Event 共用 GORM 事务，已识别客户后的业务拒绝或失败使用独立短事务。actor/source 固定为真实 `personal_customer/personal_api`，主体投影为 Registry 白名单约束的 `subject_detail`；验证码、JWT、Cookie 和 Redis Token 不进入审计。重复微信登录且资料/OpenID 无变化不写资料事件，普通 `GetProfile`、资产令牌签发、登录 Token 签发与读取保持 N/A。
+- 个人客户资产关系已切换统一 Writer：使用 `personal_customer.bind_asset`、`personal_customer.unbind_asset`、`personal_customer.migrate_asset_binding`，个人客户为主要资源，实际新增、删除或迁移的 `tb_personal_customer_device`/`tb_personal_customer_iccid` 绑定为受影响资源，卡或设备以稳定标识快照进入同一事件。绑定沿用真实 `personal_customer/personal_api`，换货迁移和旧资产重置解绑沿用真实后台账号上下文；所有成功事件与原绑定写入、换货迁移或清理共用既有 GORM 事务，幂等绑定及无有效迁移记录不伪造成功事件。本切片不改变资产校验、首次绑定售出、换货资金/套餐迁移或无虚拟号旧资产重置规则。
+- IoT 卡身份生命周期已切换统一 Writer：实际导入落库使用 `iot_card.create`，每张新增卡与 `tb_asset_identifier`、Audit Event 共用原批次 GORM 事务，actor/source 固定为真实 `system_task/worker`，以导入任务单号关联链路；已存在卡不写成功事件，导入任务创建及任务级根事件仍留给 8.3。单卡、批量删除分别使用 `iot_card.delete`、`iot_card.batch_delete`，实际删除卡与根子事件共用事务，缓存失效和轮询回调保持提交后执行，对应旧资产删除日志已停止。卡快照保存 ID、ICCID、VirtualNo、MSISDN、运营商、店铺、系列和 generation；当前没有独立卡创建或基础资料更新生产入口，后者登记 N/A。本切片不迁移分配/回收/系列、状态、实名、限速或 Gateway 命令。
+- IoT 卡分配、回收和系列绑定已切换统一 Writer：分别使用 `iot_card.allocate_batch`/`iot_card.allocate`、`iot_card.recall_batch`/`iot_card.recall`、`iot_card.series_binding_batch`/`iot_card.series_binding` 根子动作；实际卡归属、原有本地状态、`tb_asset_allocation_record` 或 `series_id` 更新与 Audit Event 共用原 GORM 事务，审计失败回滚业务，已识别资源后的拒绝/失败使用独立短事务。分配记录继续作为 Domain Ledger，卡子事件关联来源/目标店铺、套餐系列以及实际存在的设备和卡槽绑定；绑定设备导致分配/回收拒绝时只记录真实既有关系，不修改设备或绑定。缓存失效和轮询回调保持原提交后顺序，对应三组旧资产操作日志已停止；Integration Log、Outbox 均为 N/A（本地事务不调用外部系统且无新增可靠副作用），不迁移 6.3 的卡状态命令、实名、限速或 Gateway 行为。
+- 设备身份生命周期已切换统一 Writer：设备导入 Worker 使用 `device.create`，actor/source 固定为 `system_task/worker`，correlation 使用导入任务单号；每台设备的主表、资产标识、既有卡槽绑定与卡设备号快照、设备钱包及设备 Audit Event 保持在原单行 GORM 事务，审计只关联设备资源，不提前迁移卡槽语义。平台单删使用 `device.delete`，现有解绑、设备软删、资产标识清理和成功 Audit Event 同事务，失败/拒绝在业务未落地后写独立短事务；对应 `AssetAuditOpDeviceDelete` 调用已归零。设备快照保存 ID、VirtualNo、IMEI、SN、名称、型号、类型、制造商、店铺、系列和 generation；当前不存在设备基础资料更新或批量删除生产入口，均登记 N/A，不为未来入口创建 Action 或 Service。导入任务创建的旧任务级审计仍留给 8.3；本切片不迁移状态、实名策略、分配回收、卡槽资源或 Gateway。
+- 设备归属与策略已切换统一 Writer：后台与 CSV Worker 共用 `device.allocate_batch`/`device.allocate`、`device.recall_batch`/`device.recall`、`device.series_binding_batch`/`device.series_binding`，实名策略使用 `device.realname_policy_batch_update`/`device.realname_policy_update`。分配、回收的设备与实际绑定卡归属/状态、分配记录和 Audit Event 共用 GORM 事务，系列与实名策略事实亦与审计同事务；子事件关联真实来源/目标店铺、分配记录、前后套餐系列、实际绑定卡及当前有效卡槽。已识资源的全拒绝和业务回滚失败使用独立短事务，二次失败保留原业务错误并记录 critical；部分成功只为实际变化设备写 success 子事件。三组旧资产操作审计及 CSV 专用事实双写已停止；企业设备授权/回收已由 5.9 的 `enterprise_device.*` 覆盖，本切片登记 N/A，不重复迁移。Integration Log 与 Outbox 均为 N/A（均为本地事务且无新增可靠副作用）；设备外部命令明确留给 6.6。
+- 设备外部命令已切换统一 Writer：后台设备停复机、后台/个人 Wi-Fi、后台切卡模式，以及后台/个人/OpenAPI 重启和重置均在共享设备 Service 接入。每次真实 Gateway HTTP 尝试写 Integration Log，保留原重试与退避；超时记录 unknown。停复机只为实际变化卡在原状态事务内写 `device.stop`/`device.start`，并关联入口设备、目标卡和现有 binding；其他命令无同步内部字段变化，Audit Event 只记录已下发、失败或结果未知的外部命令事实。Wi-Fi 密码不进入 Audit/Integration，当前 `enabled` 未实际下发登记 N/A；当前卡切换由后续卡槽关系切片覆盖。上述六组旧资产 operation log 调用已停止。
+- 设备卡槽关系已切换统一 Writer：后台绑卡/解绑分别使用 `device.bind_card`、`device.unbind_card`，平台后台、个人端和代理 OpenAPI 共用的当前卡切换使用 `device.switch_current_card`。设备、目标卡、旧/新当前卡和实际相关 binding 均进入独立资源时间线，binding 快照及 before/after 保存 `slot_position/is_current`；设备导入创建 binding 和删除设备批量解绑则在原 `device.create/delete` 事件中补齐每张卡与 binding，不另造重复动作。绑卡创建、解绑及切卡本地 `is_current` 与 Audit Event 共用 GORM 事务，审计失败回滚本地事实。切卡只允许当前设备有效绑定卡，每次 Gateway HTTP 尝试写独立 Integration Log，超时或本地收口失败不伪装成功；成功后仍保留原 Card Observation 分发校准真实当前槽位。三组旧资产 operation log 调用已归零；本切片不迁移设备/卡其他状态机，也不改变卡设备虚拟号提交后 best-effort 维护。
+- 卡换货完整用例已切换统一 Writer：物流创建、个人客户填写收货信息、后台发货、完成、取消和换出旧卡转新分别使用 `exchange.card.create`、`exchange.card.submit_shipping_info`、`exchange.card.ship`、`exchange.card.complete`、`exchange.card.cancel`、`exchange.card.renew`；直接换货创建即完成，只记录一次完成事件。成功事件与原换货单、卡状态、客户绑定迁移、资产钱包和流水、套餐权益及通知 Outbox 共用既有 GORM 事务，审计失败回滚业务；已识别换货单或旧卡后的拒绝/失败使用独立短事务并保留原错。完成事件分别关联换货单、旧/新卡 ICCID+VirtualNo、店铺、实际客户绑定、旧新钱包、迁移流水和实际迁移套餐权益；客户绑定仍保留独立 `personal_customer.migrate_asset_binding` 事件，钱包流水和套餐权益仍是 Domain Ledger。个人收货资料、内部备注不进入审计，主体仅看到安全结果；旧卡转新为 `internal_only`。换货不调用外部系统，Integration Log 为 N/A；物流创建通知继续使用既有 Outbox。本切片不改变钱包迁移、PCI 解绑、套餐、资产归属或换货状态规则。
+- 设备换货完整用例已切换统一 Writer：物流创建、个人客户填写收货信息、后台发货、完成、取消和换出旧设备转新分别使用 `exchange.device.create`、`exchange.device.submit_shipping_info`、`exchange.device.ship`、`exchange.device.complete`、`exchange.device.cancel`、`exchange.device.renew`；直接换货仍只记录一次完成事件。成功事件继续与原换货事务、通知 Outbox、客户绑定、钱包/流水和套餐权益共用同一 GORM 事务，失败或拒绝使用独立短事务。完成事件关联换货单、旧/新设备 VirtualNo+IMEI+SN、店铺、实际客户绑定、旧新钱包、实际迁移流水和套餐权益，并逐张关联旧/新设备当前有效绑定卡及 `device_sim_binding` 的 slot/is_current。现有业务不会在设备换货时迁移卡槽，因此绑定卡和卡槽按真实状态记录为 reference，不伪造变化；客户绑定、钱包及套餐权益仅在实际变化时记录 affected。客户绑定独立事件、Domain Ledger、Integration Log N/A 和通知 Outbox 边界保持不变；本切片未修改设备卡槽、钱包、套餐、资产归属或换货状态规则。
+- 套餐配置与授权已切换统一 Writer：套餐系列使用 `package_series.create/update/delete/update_status`，套餐商品使用 `package.create/update/delete/update_status/update_shelf_status`，店铺套餐上下架、零售价和生效条件分别使用 `shop_package.update_shelf_status`、`package.update_retail_price`、`shop_package.update_expiry_base`，系列授权使用 `shop_series_grant.create/update/manage_packages/delete`。批量套餐分配与批量成本价调整分别使用 `shop_package.batch_allocate`/`shop_package.allocate`、`shop_package.batch_update_pricing`/`shop_package.update_pricing_item` 根子事件；全量价格锁拒绝为 `denied`，成功与拒绝混合为 `partial`，未实际变化或已存在而跳过的资源不伪造成功子事件。系列、套餐、店铺、系列授权、套餐授权和价格历史均作为独立资源进入各自时间线，配置与价格 before/after 只记录本次相关字段；成功事件与原配置、授权及价格写入共用 GORM 事务，已识别资源后的拒绝或回滚失败使用独立短事务并保留原业务错误。`tb_shop_package_allocation_price_history` 继续是价格变化的 Domain Ledger，Audit Event 不替代它；Integration Log 与 Outbox 均为 N/A（本切片仅本地配置事务，不发生外部交互或可靠异步副作用）。`shop_package_batch_allocation` 借用旧账号 operation log 的写入已停止，原上架、直属下级授权、佣金天花板、成本价锁定、赠送套餐和分配规则保持不变；套餐购买及 `package_usage` 权益生命周期明确留给 7.2～7.3，不在本切片迁移。
+- 套餐权益生命周期已切换统一 Writer：实际激活、到期及加油包级联失效、流量扣减、日/月/年重置、退款精准失效和按资产失效分别使用 `package_usage.activate/expire/deduct_traffic/reset_traffic/invalidate_refund/invalidate_asset`，只在状态条件更新或真实数值变化命中时写 success，重复任务和无变化分支不伪造事件。`package_usage` 为主要/受影响资源，关联订单、套餐商品、当前卡或设备以及退款单均作为独立 reference 资源进入各自时间线；成功事件与 `tb_package_usage` 及每日流量详单 Domain Ledger 共用原 GORM 事务，审计失败回滚业务，已定位权益后的事务失败使用独立短事务并保留原错。Scheduler 使用真实 `scheduled_job/scheduler`，Asynq、Outbox 消费和旧退款异步后处理使用真实 `system_task/worker`，人工实名激活保留 HTTP 账号 actor；Outbox 消费以当前 envelope EventID 作为直接 parent，沿用既有 request/correlation。退款审批标准 Outbox 同样把决策 EventID 传播为后处理 parent。换货完成继续复用 7.1 已有的同事务完成事件，不重复新增套餐迁移动作，并补齐迁移权益的激活/到期等快照以及独立订单、套餐引用；`tb_package_usage` 仍是权益权威事实。流量观测 Outbox 继续承担可靠传递，Audit Event 不替代 Outbox；套餐生命周期本地写不产生外部请求，Integration Log 为 N/A。`InvalidateAllPackagesByAsset` 当前没有生产调用者，登记为已接好审计但生产覆盖 N/A，不借本任务新增“资产停用即权益失效”规则；既有套餐列表 Query 保持 N/A。`fix-package-activation-starvation` 的孤儿 CTE、每载体一个名额、同步恢复和两事务接续设计均作为独立专项修复保留，本切片不改其业务规则。
+- 订单生命周期已切换统一 Writer：后台创建与代购、C 端普通购买、代理 OpenAPI 每笔购买、手工取消、待支付订单钱包支付及计划任务过期关闭分别使用 `order.create/cancel/wallet_pay/expire_close`。账号、个人客户、OpenAPI、批量 Worker 和 Scheduler 均保留真实 actor/source；订单为主要资源，买家、卡或设备、套餐、实际钱包/流水及 Payment 为独立关联资源，金额、支付状态、方式和购买角色保存为快照。成功事件与订单、明细、资金、支付、套餐权益及既有 Outbox 共用原 GORM 事务，审计失败回滚业务；拒绝和事务失败保留原错误并写独立短事务，幂等无变化分支不伪造成功。支付渠道 Integration Log 留给 7.4，代理及资产钱包自身资金动作分别留给 7.7/7.9，OpenAPI/CSV 批量根事件留给 8.3；本切片未修改价格、佣金、套餐激活、钱包算法、授权或订单状态机，普通订单 Query 保持 N/A。
+- 支付外部与内部终态已接入统一边界：Payment 创建、渠道明确关闭和回调确认分别使用 `payment.create/confirm/fail`，没有 Payment 的旧订单回调使用 `order.online_pay`；支付单、订单或充值单、渠道交易号以及回调实际变化的钱包/流水进入同一事件，成功审计与对应 Domain Ledger 共用原 GORM 事务，重复回调不伪造成功事件。微信/富友真实预下单、代理充值微信/支付宝查单及微信/支付宝/富友已识别回调写 Integration Log；支付宝 WAP 本地签名和当前未实现的富友主动查单均明确 N/A。Integration 使用支付单号 correlation，回调用渠道交易号幂等，结果未知不伪装失败或成功；本切片未重构渠道协议，也未修改价格、佣金、套餐激活、钱包、授权、金额规则或状态机，充值与资金专项审计仍由 7.6～7.9 收口。
+- 个人资产和代理充值已切换统一 Writer：个人资产充值的 `payment.create/confirm/fail` 事件补齐个人客户、卡/设备、充值单、资产钱包和唯一流水；代理线下申请、真实入账及拒绝/关闭分别使用 `agent_recharge.create/credit/close`，关联提交账号、目标店铺、审批实例、支付单、主钱包和唯一流水。外部回调、主动恢复、Outbox 消费分别保留 `external_system`、`scheduled_job`、`system_task` actor，重复终态不伪造成功。自动购包使用 `asset_recharge.auto_purchase`，与订单、支付、钱包扣款流水、套餐权益及充值单自动购包状态同事务，最终失败状态同样原子记录；既有 Integration Log、审批/入账 Outbox、观测 Outbox 和自动购包 Asynq 边界不变。旧线下人工确认的账号 operation log 裸 goroutine已停止；本切片不新增渠道，也未修改金额、钱包、审批、套餐激活、佣金或自动购包规则。
+- 代理主钱包订单资金已切换统一 Writer：直接扣款使用 `agent_wallet.order_debit`，预占、释放和完成分别使用 `agent_wallet.order_reserve/order_release/order_complete`；订单为主要资源，主钱包、预占事实及实际成功流水为受影响资源，钱包记录 balance/frozen_balance 前后值，流水保留唯一业务引用。Audit Event 与既有行锁、乐观锁、状态条件、唯一流水和钱包 Outbox 共用原事务，写入失败回滚全部业务事实；订单事务整体失败后按已尝试的钱包动作写独立短事务，重复扣款或重复预占终态不伪造成功事件。完成预占由 `order_complete` 同时关联扣款流水，不再重复生成 `order_debit` 审计。当前生产只有直接扣款和取消订单 release 调用，freeze/complete Application 接缝暂无生产调用者，本任务只接入审计，不新增调用、不修改钱包、订单、套餐、佣金、充值、退款或信用额度规则。
+- 代理主钱包正向及回退资金已完成专项收口：充值继续复用 7.6 的 `agent_recharge.credit`，退款继续复用 7.5 的 `refund.approve`，两者均已在一条业务事件中关联主钱包、原流水/新流水和余额前后值，不新增同义钱包事件。人工调整使用 `agent_wallet.adjust_balance`，在既有 Posting/Outbox 事务内关联唯一调整流水并强制记录原因；当前无生产入口，只接好现有 Application 能力，不新增接口。实际信用额度更新使用 `agent_wallet.change_credit`，主钱包为主要资源、店铺为引用资源，保存余额/冻结余额不变和信用字段/version 前后值；成功审计失败回滚信用更新，已识别钱包后的拒绝/失败使用独立短事务并保留原错。Integration Log 均为 N/A；本切片未修改充值、退款上限、钱包算法、信用占用、审批、佣金或资产钱包规则。
+- 卡/设备资产钱包资金已完成专项收口：充值复用 `payment.confirm`，扣款复用 `order.wallet_pay`，退款复用 `refund.approve`，换货迁移复用 `exchange.card.complete/exchange.device.complete`，不新增同义钱包动作。四类成功事件均在原业务事务内关联卡的 ICCID/VirtualNo 或设备的 VirtualNo/IMEI/SN、资产钱包、充值/订单/退款/换货单及唯一流水，并保存余额前后值；充值事件只保留一条受影响钱包资源，订单扣款的钱包和流水明确标记为 affected。支付、订单、退款状态条件及换货状态机继续阻止重复业务键或重复终态伪造成功，无余额迁移不创建流水；钱包流水继续作为 Domain Ledger。充值渠道外部尝试沿用 Integration Log，其余本地钱包动作 N/A；本切片未修改钱包余额/冻结/乐观锁、退款上限、换货迁移、套餐、客户绑定或代理主钱包规则。
+- 佣金与提现状态机已切换统一 Writer：订单 Worker 使用 `commission.calculate` 记录真实 `system_task/worker`、订单佣金状态结果、全部佣金记录、归属店铺和套餐系列；每笔自动入账及待审人工入账使用 `commission.credit`，关联佣金记录、订单、店铺、系列、佣金钱包及实际存在的钱包流水和余额前后值；待审人工失效使用 `commission.invalidate`。退款回扣继续只使用既有 `refund.invalidate_commission`，不重复造佣金失效事件。提现申请、通过、驳回分别使用 `commission_withdrawal.request/approve/reject`，提现单为主要资源，店铺、佣金钱包及冻结/扣除/解冻流水为独立资源，收款账户 JSON 不进入审计。成功事件与现有佣金、订单、钱包、流水和提现事实同事务，已定位订单、佣金记录或提现单后的拒绝/失败使用独立短事务；幂等完成订单不伪造重复成功。现有“待审佣金人工入账”业务只更新佣金记录和钱包、不创建钱包流水，本切片按真实事实关联钱包但不伪造 Domain Ledger；统计 Query、佣金公式、阶梯规则、提现金额/手续费、冻结算法和审批状态机均未修改。Integration Log 与 Outbox 为 N/A（这些链路没有外部调用或新增可靠副作用）。
+- 轮询配置与人工动作已切换统一 Writer：轮询配置创建、更新、删除和启停使用 `polling_config.create/update/delete/update_status`，并发配置更新与计数重置使用 `polling_concurrency.update/reset`，告警规则创建、更新和删除使用 `polling_alert.create_rule/update_rule/delete_rule`；成功事件与对应 PostgreSQL 配置事实共用 GORM 事务，审计失败回滚配置写入。Redis 并发计数重置无法与 PostgreSQL 原子提交，审计失败时恢复重置前计数；人工单卡去重键在日志/审计事务失败或队列写入失败时移除，避免阻断原有重试。
+- 单卡、批量、条件筛选人工触发和取消分别使用 `polling_manual_trigger.trigger_single/trigger_batch/trigger_by_condition/cancel_trigger`，记录真实后台账号、手动任务和实际卡资源；配置重名、每日触发上限、重复入队、越权取消和已结束任务取消等已定位资源的拒绝写独立短事务，二次失败保留原业务错误并记录 critical。`tb_polling_manual_trigger_log` 继续承担进度、结果与历史查询，不被 Audit Event 替代或停写；审计不复制 `CardIDs`、条件正文、通知渠道正文或其他安全凭据，只保存任务类型、触发方式、数量、状态及“条件/通知渠道是否配置”等安全事实。
+- 实名、流量和卡状态轮询的每次真实 Gateway 尝试继续写 Integration Log；套餐/保护期轮询自身不伪造 Gateway 尝试，实际停复机复用共享 `StopResumeService` 的 Audit/Integration 边界。轮询配置、并发状态、告警历史、人工任务状态/历史和监控页面等普通运行查询均为 N/A；通知投递、任务 ledger、Audit Event 与 Integration Log 保持独立事实。`polling_cleanup` 数据清理配置未包含在 8.5 明确边界，本轮不借轮询审计扩展其 CRUD 或手动清理动作，继续保留在覆盖清单等待对应显式切片。
 
 ### 与审计接入分开保留的独立修复
 
 - 企业、企业卡和企业设备的权限校验、空筛选防全量、批量边界、越权同错及企业设备 TOCTOU/真实命中计数作为独立安全与并发修复保留，不视为审计所需的业务重构。
 - 手机号绑定/换绑的行锁和事务内二次复检、账号状态与代理越权校验、管理员账号改密后撤销 Token 作为独立修复保留；企业账号改密不扩展同样的 Token 行为。
 - 角色/权限变化和店铺删除后的权限缓存清理能力作为独立修复保留，但只在数据库提交后 best-effort 执行，不让 Redis 失败反向回滚业务事实。
-- 已确认裸 goroutine 调用：`internal/service/agent_recharge/service.go` 1 处，`internal/service/wechat_config/service.go` 5 处；Writer 自身另启 goroutine。
+- 已确认支付配置和员工线下充值的外层裸 goroutine 均已归零；旧 Writer 自身仍另启 goroutine，由最终 contract 任务统一处理。
 - 迁移责任：04、07、08；19 号票验证生产装配和直接旧表写入归零。
 
 ### 旧资产审计
 
 - Writer、Builder 与 Store：`internal/service/asset_audit/`、`internal/store/postgres/asset_operation_log_store.go`。
 - API/Worker 装配：`internal/bootstrap/services.go`、`internal/bootstrap/worker_services.go`、`internal/bootstrap/stores.go`、`internal/bootstrap/worker_stores.go`。
-- 调用模块：`internal/service/asset/`、`internal/service/device/`、`internal/service/device_import/`、`internal/service/iot_card/`、`internal/service/iot_card_import/`、`internal/service/polling/asset_polling_service.go`。
+- 调用模块：`internal/service/asset/`、`internal/service/device/`、`internal/service/iot_card/`、`internal/service/polling/asset_polling_service.go`；卡/设备导入任务创建已停止调用旧 Writer，但生产组合根的兼容参数留待 11.1 统一清理。
 - 兼容读取：`internal/handler/admin/asset.go`、`internal/routes/asset.go`、`internal/model/dto/asset_operation_log_dto.go`；由 10 号票保留读取契约。
 - 迁移责任：05、06、09；19 号票验证生产装配和直接旧表写入归零。
 
@@ -163,7 +203,7 @@
 
 - 状态与写入：`internal/service/polling/manual_trigger_service.go`、`internal/store/postgres/polling_manual_trigger_store.go`、`internal/model/polling.go`。
 - 装配与接口：`internal/bootstrap/services.go`、`internal/bootstrap/stores.go`、`internal/handler/admin/polling_manual_trigger.go`。
-- 当前仍同时承担运行状态和历史查询，不能提前停写；09 号票先切到公共异步任务与 Integration Log，10 号票提供历史投影，19 号票再启用旧写护栏。
+- 当前继续承担运行状态、进度、结果和历史查询，8.5 仅为人工触发/取消补充统一 Audit Event；不得停写、删除或以 Audit Event 替代该 ledger，最终旧写护栏必须将其列入显式白名单。
 
 ## 评审门禁