feat: harden delivery and deletion workflows
This commit is contained in:
Hermes Agent
@@ -98,11 +98,13 @@
|
||||
- `report_ready` 事件自动落库
|
||||
- `status / attempt_count / last_attempt_at / failure_reason` 追踪字段
|
||||
- 站内查看 + PDF 下载最小交付闭环
|
||||
- `DeliveryDispatcher` + `scripts/gaokao-delivery-dispatch.py`
|
||||
- `ready -> sent` / 缺文件 `-> failed` 的最小执行链
|
||||
|
||||
仍缺：
|
||||
|
||||
- 真实邮件/站内通知发送执行器
|
||||
- 自动重试 worker / 告警链
|
||||
- 自动重试调度 / 告警链
|
||||
- 面向用户的独立通知审计页
|
||||
- 对账/退款与交付失败补偿联动
|
||||
|
||||
@@ -128,16 +130,19 @@
|
||||
- `docs/DATA_RETENTION_AND_DELETION.md`
|
||||
- 服务条款草案、删除执行 SOP
|
||||
- 前台资料提交同意字段落库
|
||||
- 后台 `DELETE /api/orders/{id}?mode=delete|anonymize&reason=...` 最小执行入口
|
||||
- 删除时自动清理报告 HTML/PDF，并写入 `order_deletion_audits`
|
||||
|
||||
仍缺：
|
||||
|
||||
- 正式法务审定版本
|
||||
- 删除/匿名化后台执行入口
|
||||
- 前台/客服删除工单流程
|
||||
- 数据保留期自动清理任务
|
||||
- 合规文本上线前最终校对
|
||||
|
||||
说明：
|
||||
|
||||
- 当前不再是“完全没有合规基线”，而是“文档基线已建，执行与审定仍待完成”。
|
||||
- 当前不再是“完全没有合规基线”，而是“文档基线 + 后台最小执行入口已建，前台流程与自动清理仍待完成”。
|
||||
|
||||
#### A-5 业务数据备份/恢复/密钥托管已形成基线，但生产化仍未完结
|
||||
|
||||
@@ -168,22 +173,24 @@
|
||||
#### B-1 crowd_db 27 省“结构覆盖”不等于“高质量覆盖”
|
||||
|
||||
严重度: P1
|
||||
当前状态: 未解决
|
||||
当前状态: 部分解决
|
||||
|
||||
事实：
|
||||
|
||||
- 27 省 JSON 文件已存在
|
||||
- 但高置信、高密度推荐数据目前重点仍在湖南
|
||||
- `risk_report` 已输出 `quality_level / quality_label`
|
||||
- `gaokao-data-trace` human 输出已展示质量等级
|
||||
- 低置信省份仍主要是“结构覆盖已完成，但推荐质量待增强”
|
||||
|
||||
风险：
|
||||
|
||||
- 如果对外统一宣传“27省高质量反扎堆推荐”，有误导风险
|
||||
- 若对外统一宣传“27省高质量反扎堆推荐”，仍有误导风险
|
||||
|
||||
建议动作：
|
||||
|
||||
- 在报告输出里继续强化 confidence 文案
|
||||
- 新增“数据完整度等级”字段
|
||||
- 对低置信省份降级展示，不输出强结论
|
||||
- 在 README / 产品文案中继续避免“27省高质量推荐全覆盖”表述
|
||||
- 后续补 province-level completeness/quality summary
|
||||
- 继续提升非湖南省份高置信数据密度
|
||||
|
||||
#### B-2 本地验证环境仍未完全固化为单命令体验
|
||||
|
||||
|
||||
@@ -80,4 +80,6 @@
|
||||
当前状态：
|
||||
|
||||
- **文档基线已补齐**
|
||||
- **代码主链分级展示仍待继续实现**
|
||||
- **`risk_report` 已输出 `quality_level / quality_label`**
|
||||
- **`gaokao-data-trace --human` 已输出质量等级**
|
||||
- **低置信省份已通过 confidence 分级与 warning 机制降级**
|
||||
|
||||
@@ -40,13 +40,15 @@
|
||||
|
||||
- `OrdersDAO.delete()` 删除订单能力
|
||||
- ON DELETE CASCADE 清理部分关联表
|
||||
- 后台 `DELETE /api/orders/{id}?mode=delete|anonymize&reason=...` 最小执行入口
|
||||
- 删除时自动清理 HTML/PDF 报告文件
|
||||
- `order_deletion_audits` 最小审计表
|
||||
|
||||
尚缺：
|
||||
|
||||
- 前台/后台删除工单流程
|
||||
- 报告文件自动清理脚本
|
||||
- 删除操作审计记录
|
||||
- 前台/客服删除工单流程
|
||||
- 数据保留期自动清理任务
|
||||
- 更细粒度的匿名化策略（如案例长期保留脱敏版）
|
||||
|
||||
## 5. MVP 最低执行要求
|
||||
|
||||
|
||||
@@ -52,13 +52,16 @@
|
||||
- `delivery_notifications` 事件表
|
||||
- portal 状态页 / 报告页 / PDF 下载页
|
||||
- `delivered` 但无交付物时不再误报 `report_ready`
|
||||
- `data.notifications.dispatcher.DeliveryDispatcher`
|
||||
- `scripts/gaokao-delivery-dispatch.py`
|
||||
- `ready -> sent` / `缺文件 -> failed` / `attempt_count` 递增
|
||||
|
||||
未完成：
|
||||
|
||||
- 通知触发点下沉到稳定主链
|
||||
- 独立 `delivery_job` / `delivery_attempt` 模型
|
||||
- 重试与失败原因追踪
|
||||
- 多通道统一投递状态
|
||||
- 邮件/渠道真实发送执行器
|
||||
- 自动重试调度与告警链
|
||||
- 多通道统一投递状态页
|
||||
|
||||
## 6. 当前最短闭环
|
||||
|
||||
@@ -67,10 +70,12 @@
|
||||
3. portal 显示 `report_ready`
|
||||
4. 状态页提供查看/下载入口
|
||||
5. `report_ready` 事件落库且幂等
|
||||
6. `gaokao-delivery-dispatch.py --channel station` 可把 ready 事件推进到 sent
|
||||
7. 缺失交付物时事件转 failed，并记录 `failure_reason`
|
||||
|
||||
## 7. 下一步实施建议
|
||||
|
||||
1. 统一 `report_ready` 触发点
|
||||
2. 增加 `delivery_status` 最小字段
|
||||
3. 增加失败重试/失败原因
|
||||
4. 再决定是否扩到邮件通道
|
||||
1. 把 dispatcher 接入定时任务或 systemd timer
|
||||
2. 增加邮件或站内通知真实发送器（二选一先闭环）
|
||||
3. 增加失败重试阈值与告警
|
||||
4. 再决定是否扩到多通道
|
||||
|
||||
Reference in New Issue
Block a user