落地 T12-C: 让用户在 portal 删除工单页/POST 中都能看到该订单
当前所处保留期阶段(pending/within/outside),并按阶段给出明确的
next_step 文案。
- DeletionRequestCreate.scope 锁定到白名单
(order_only | order_and_attachments | full_account); 非法值 → 422
- _resolve_retention_status(order, settings) 复用
RETENTION_GUARDED_STATUSES + settings.retention_days
- POST 端 next_step 三种文案:
outside: 已超过 180 天保留期,可申请删除...
within: 订单仍在 180 天保留期内...
pending: 提交成功后将由人工核验后处理
- GET 端在表单上方插入'保留期状态'提示卡
- admin/tests/test_order_info_form.py 6 个新/增强测试 +
_expire_retention_window helper
dev-verify: 1179 passed (was 1175, +4 net new),
coverage overall=85.05% / core=100%, ruff + mypy clean
13 KiB
CURRENT_STATE
最后更新: 2026-06-19 状态词: 本地验证完成(6/19 复审 + 6/19 整改计划 + A1 保留期门禁 + B1 支付失败持久化 + A2/B2 文档与执行板校准已全部落地;下一阶段 = 推进 T12 真实支付 acceptance + 前台删除工单 + 合规审定)
真相源优先级:
- 本文件
docs/ACTIVE_REMEDIATION_2026-06-19.md(6/19 当前整改清单,取代 6/13 历史快照)docs/ACTIVE_EXECUTION_BOARD_2026-06-19.md(6/19 当前执行板,取代 6/13 历史快照)docs/plans/2026-06-19-production-readiness-remediation-plan.md(6/19 整改计划)reports/PRODUCTION_STRICT_REVIEW_2026-06-19.md(6/19 复审报告)docs/plans/2026-06-17-phase2-majors-catalog-implementation-plan.md(Phase 2 已收口快照)docs/DESIGN_RULES_TRUSTED_CLI_2026-06-16.md(设计快照;Phase 编号需与执行口径消歧)docs/PROJECT_PLANNING_REALIGNMENT_2026-06-16.md(历史规划/实现漂移审计)docs/RULES_SOURCE_OF_TRUTH.md(规则真相源索引;待补建)docs/MAJOR_DATA_SOURCE_OF_TRUTH.md(专业目录真相源索引)docs/CLI_API_MAPPING.md(CLI/API 映射索引)docs/P0_P1_P2_REMEDIATION_PLAN_2026-06-14.md(历史整改板;§4 卡片以 §2.1 状态归一为准)docs/FRONTEND_UI_AUDIT_2026-06-16.md/docs/FRONTEND_UI_EXECUTION_BOARD_2026-06-16.mddocs/ACTIVE_REMEDIATION_2026-06-13.md(已降级为历史快照)docs/ACTIVE_EXECUTION_BOARD_2026-06-13.md(已降级为历史快照)product/PRD.md/product/ROADMAP.md/docs/IMPLEMENTATION_PLAN_v2.mddocs/PRODUCTION_DEPLOYMENT_CHECKLIST_2026-06-15.mdreports/PRODUCT_PLANNING_TECH_ALIGNMENT_REVIEW_2026-06-13.md(历史评审快照)
0. 6/19 增量段(叠加在 6/13 真相源之上)
6/19 落地了 3 项 P0/P1 整改 + 1 项真相源分层。本节是当前唯一增量:
0.1 A1 — 删除/匿名化保留期门禁(P0)
- 错误码
BIZ_ORDER_RETENTION_NOT_EXPIRED(E02002) → HTTP 409 - 配置
GAOKAO_RETENTION_DAYS(默认 180) - 路由层
_assert_retention_expired守卫,状态子集 paid/serving/delivered/completed/refunded 触发,pending 直接放行 - 口径来源:
docs/DATA_RETENTION_AND_DELETION.md§2 - 测试: 3 个新失败/放行用例 +
_expire_retention_windowhelper - 验证: dev-verify all checks passed(1175 passed)
0.2 B1 — 支付失败状态持久化(P1)
data.payments.service.handle_webhook: 非 success 状态不再抛 PaymentError,改为持久化payment.status='failed'+failed_at+failure_reason+ 完整callback_payload- schema 增量升级:
_ensure_column幂等ALTER TABLE payments ADD COLUMN failed_at / failure_reason - 幂等保证:终态(paid / refunded / failed)后到达的失败 webhook 走 idempotent 路径
- 测试:
test_handle_webhook_persists_failed_status锁住新契约 - 验证: dev-verify all checks passed
0.3 A2 — 4 个产品/工程文档 Current/Target 校准(P1)
README.md顶部执行板指向 6/19 + 6/19 新增约束product/PRD.md顶部"最后更新"升级为 6/19product/ROADMAP.md顶部校准从 6/13 升级到 6/19docs/TECH_ARCHITECTURE.md顶部 Current/Target 指向 6/19 执行板
0.4 B2 — 真相源分层与历史快照降级(P1)
- 6/13 整改板/执行板顶部加"⚠ 历史快照"头注
- 新建
docs/ACTIVE_REMEDIATION_2026-06-19.md+docs/ACTIVE_EXECUTION_BOARD_2026-06-19.md - 本节作为 6/19 增量叠加在 6/13 真相源之上
0.5 T12-C — 前台删除工单 + 保留期外可申请(P1,本节落盘即收口)
- 落地:
admin/routes/web_public.py加_resolve_retention_status+_next_step_for_retentionDeletionRequestCreatePydantic 锁scope到白名单 +confirm_guardian强制 boolPOST /portal/{token}/deletion-request根据订单保留期返回 3 种 next_step 文案GET /portal/{token}/deletion-request在表单上方加"保留期状态"提示卡
- 测试: 4 个新测试 + 2 个 helper 复用
- 验证: 1179 passed, dev-verify all checks passed
0. 单一执行口径(2026-06-17)
为消除设计 Phase 编号与执行 Phase 编号漂移,本节是当前唯一口径:
| 设计层 Phase(DESIGN_RULES_TRUSTED_CLI_2026-06-16.md) | 执行层 Phase(当前真相) | 状态 |
|---|---|---|
| Phase 1 规则真相源化 | 执行 Phase 1 | ✅ 已收口(ae4835e + 8a61b8f,三仓同步) |
| Phase 2 统一审计引擎最小可用 | 执行 Phase 1.5(verify + 旧 checker 迁移) | ✅ 已收口(同上) |
| Phase 3 专业目录接入 MVP | 执行 Phase 2 | ✅ 已收口(36ad58a + 6b1157f + edc5b11) |
| Phase 4 统一 CLI 命令面 | 执行 Phase 3 | ❌ 未启动 → 下一阶段 |
| Phase 5 智能体调度 + admin 整合 | 执行 Phase 4 | ❌ 未启动 → 等 Phase 3 收口 |
| Phase 6 文档/真相源索引收口 | 长期维护 | ⚠ 进行中(docs-only 收口本轮同步) |
设计层 Phase ≠ 执行层 Phase。状态查询一律以本表 + 6/17 执行板为准。
1. 当前准确定位
项目当前准确定位为:
- 已完成: 人工服务运营增强系统(闲鱼 / 微信 / 学校渠道)
- 已完成: 管理后台、订单、分享、渠道同步、AI 审核基础校验、CI/CD、性能与安全加固
- 已完成/已验证:
Phase2 major_validation已接入AuditEnginegaokao-cli audit run --json当前只承认两类真实检查:省份规则 + 专业目录状态- 规则/专业目录/CLI 三层都已具备可回归验证入口
- 当前仍在推进:
- 已完成且已本地验证:
mock/alipay_sim/alipay三层支付代码链与 notify/return 路由;退款状态闭环、portal token secret 分离、payment webhook fail-closed、删除/匿名化扩围、分享 allowlist、channel_sync DB 隔离与 DAO 真相收敛 - 未完成且仍阻塞线上验收: 真实支付宝商户凭据、公网 notify_url、备案域名、真实支付 acceptance
- 已完成且已本地验证:
一句话:
当前项目定位:人工服务运营增强系统;用户端 Web 自助闭环仅为本地 MVP/目标态,尚未达到可对外承诺的完整 SaaS 水位。当前版本已经完成 v2.1 的后台运营链路与 AI 审核增强闭环,但不是完整 Web 自助 SaaS。
2. 已完成模块
- T1 AI审核服务
- T2 反扎堆检测
- T3 数据溯源
- T4 订单管理
- T5 集成测试与发布
- T6 管理后台
- T7 分享功能
- T8 渠道集成
- T9 错误处理
- T10 CI/CD
- T11 性能与安全
覆盖率门槛证据: 覆盖率门槛证据:
-
overall = 92.46%
-
core = 100.00%
-
满足:整体≥80%、核心≥100%
-
本地与 CI 的硬门禁统一收敛到
scripts/check_coverage_gate.py -
dev-verify.sh与 GitHub CI 都执行同一组硬阈值检查 -
codecov.yml当前保持同值展示口径,但不是执行单源,也不是阻断门禁
三仓同步状态:
- gitea/main 已同步
- origin/main 已同步
- tksea/main 已同步
- tag v2.1 已推送
3. 尚未完成 / 不应误报为已完成
T12 用户端 Web 自助 MVP
当前仅能说:
- 已启动 / 实施中
- 还不能说“已完成”
未完成主链路包括:
- 真实支付接入与回调验签的线上 acceptance
info_submitted -> serving自动处理主链 +本地自动桥接info_submitted -> serving已落地;仍缺真实 worker/生成服务/线上调度收口- 站内通知发送器、真实邮件通知发送器与调度已落地;仍缺生产告警链与独立通知审计页
- 前台删除工单流程与更完整的产品化交互
因此:
- Web 自助购买场景 = 本地 MVP 主链已大部分落地,但线上闭环未完成
- 完整教育 SaaS 化 = 未完成
4. 已修正的历史评审问题
以下问题在 2026-06-13 之后已被修正,不应继续按“当前未解决”表述:
- PRD P2 / P3 功能编号冲突
- ROADMAP 中已落地功能仍保持未勾选
- TECH_ARCHITECTURE 仍标“设计中”
- FINAL_COMPLETION_REPORT 仍写“条件完成”
- 依赖清单未显式声明 Jinja2 / WeasyPrint / cairocffi / ruff / mypy
- GitHub origin 凭据导致发布链阻塞
这些应被视为:
- 已修正的历史问题
- 不应再作为当前阻塞项重复引用
5. 仍然有效的评审问题
以下问题仍成立,应继续作为后续版本约束:
P0 / P1 真实缺口
- 用户端 Web 自助支付闭环缺失
- 生产通知链已有底层 validated/delivered 状态机、portal 通知审计页、后台独立通知审计页、运维告警审计页与 watchdog alert sink;已支持 SMTP/IM webhook sink 代码接入,但仍缺线上真实通道配置后的生产联调
- 前台入口已支持基础资料填写、最多 5 个附件上传与 5 步向导(基础信息 / 偏好与目标 / 已有方案与附件 / 协议确认 / 提交确认);仍缺更完整文件类型策略与更细粒度错误提示
- 2026-06-16 前端专项审计结论:用户端首页 / 定价页 / 结账页存在明显 AI 模板痕迹、开发术语外露与商业转化不足;后台
/dashboard仍偏开发者自检页。当前执行板见docs/FRONTEND_UI_EXECUTION_BOARD_2026-06-16.md - 2026-06-16 第二轮本地整改已完成:首页、定价页、结账页、portal 向导页 / 状态页、后台
/dashboard已完成首轮产品化与去技术暴露重构;剩余前端工作聚焦 design token 基线与更强回归门禁 - 2026-06-16 第三轮本地整改已完成:
admin/static/portal-ui.css已建立为共享样式基线,关键用户页面已接入 shared CSS,并补齐页面级回归断言;前端整改范围已本地收口,剩余仅为 Git 交付或后续更深层视觉迭代 - 业务数据备份 / 恢复 / 密钥托管已有本地基线与验证,但异机备份和生产接入仍不足
- 隐私政策 / 服务协议 / 监护人同意 / 数据保留与删除流程仍缺前台/客服自助工单与正式法务版本
重要更新(2026-06-15): 上述 5 项是 v2.1 当前阶段以外的真实缺口。 上一轮 2026-06-14 严格复审里的 P1 整改项已全部完成:
- P1-1 支付回调双写裂缝已修复
- P1-5 退款域模型闭环已修复
- P1-2 删除/匿名化已覆盖 orders 主表 + payments.callback_payload + order_intakes.payload_json
- P1-7 验证链口径统一(CI / dev-verify / codecov / gate script 同一阈值)
P2 工程改进
- crowd_db 高置信数据应区分湖南与其他省份
- 架构图仍需进一步拆分 Current / Target 视觉表达
- legacy 邮件脚本应继续弱化为非主链能力
仍然有效的 P1 / P2 整改项
完整清单见 docs/P0_P1_P2_REMEDIATION_PLAN_2026-06-14.md:
- P1-3 真实支付回调校验
- P1-8 备份恢复演练 / 目标机告警接入
- 隐私政策 / 服务协议 / 删除工单正式入口
已完成并不再列为整改项:
- P2-1 公共下单孤儿订单
- P2-2 channel_sync 单一 DAO 真相
- P2-3 delivery 通知状态语义收口(
sent已移除) - P2-4 portal token / JWT secret 分离(已通过 P2-4 单元测试 + prod fail-closed)
- P2-5 payment webhook secret fail-closed(已通过 P2-5 单元测试 + prod fail-closed)
- X-02 支付域设计
- X-03 Delivery 交付服务设计
- X-04 合规基线文档
- X-05 备份恢复与密钥托管方案
- X-06 本地一键验证脚本
- X-08 crowd_db 数据完整度等级化
6. 对外表述边界
允许对外说:
- 已具备人工服务运营后台能力
- 已具备 AI 审核基础校验、数据溯源、分享、渠道同步能力
audit run当前只承认省份规则 + 专业目录状态校验,不应对外表述为“已包含反扎堆/综合评分闭环”- 已完成 v2.1 当前计划闭环
不应对外说:
- 已完成完整 Web 自助 SaaS
- 已完成系统内支付闭环
- 已完成用户端完整交付闭环
- 27 省 crowd_db 均为高置信强推荐数据
7. 推荐阅读顺序
- docs/CURRENT_STATE.md
- docs/archive/2026-06-historical-snapshots/FINAL_COMPLETION_REPORT_2026-06-13.md
- product/PRD.md
- product/ROADMAP.md
- docs/IMPLEMENTATION_PLAN_v2.md
- reports/PRODUCT_PLANNING_TECH_ALIGNMENT_REVIEW_2026-06-13.md(作为历史评审参考)