Files
gaokao-volunteer-system/docs/LEGAL_PRIVACY_BASELINE.md
hermes 6eafe1fc9b
Some checks failed
CI / pytest (Python 3.10) (push) Has been cancelled
CI / pytest (Python 3.11) (push) Has been cancelled
CI / pytest (Python 3.12) (push) Has been cancelled
feat(ops 6/20 v2.1.3): 生产加固 + L-A 送审前修复 + crowd_db 质量契约
## 实现内容 (6 项改动)

1. **admin /health 端点增强** — 主键契约 status:ok 保持 + checks 子对象
   - db_writable: connect + CREATE TEMP TABLE + INSERT + SELECT + DROP
   - disk_writable: 在 ops_alert_log_path 目录创建临时文件 + 删除
   - settings_valid: 复用 is_jwt_secret_secure 判断
2. **_enforce_jwt_secret_policy** — prod env 使用 dev 默认 JWT / 长度<32 → fail-closed
3. **_enforce_default_admin_password_policy** — prod env 用 admin123 / 长度<10 / 字符类<3 → fail-closed
4. **L-A R7: admin UI footer** — dashboard.html (592 行) + ui.py 内联 admin/orders/new
   模板加 footer 隐私政策 + 数据删除 + 服务说明链接, 与 portal _render_footer_links() 同口径
5. **L-A R1+R4: LEGAL_PRIVACY_BASELINE 文档同步**
   - §6 移除孤儿 'admin' consent_channel 值 (代码侧从未实际产生)
   - §7 已具备/尚缺 重写, 显式归到 6/20 增量
6. **Q-A: tests/test_crowd_db_data_quality.py** — 8 个测试锁住
   - 27 省总数 + 仅湖南 high + 其它 26 省 ≤ usable
   - 高考生源大省 (广东/江苏/北京/上海/山东/河南/四川/湖北) 不在 high 集合
   - data_year=2025 (6/25 后需显式更新)

## 测试

- 4/4 RED → GREEN (admin/tests/test_health.py: JWT/admin password 拒绝 dev 默认值)
- 8/8 GREEN (data/crowd_db/tests/test_crowd_db_data_quality.py: 数据质量契约)
- 3 回归修复 (test_app.py + test_routes.py + test_health.py 适配新 /health checks 字段)
- 31/31 GREEN (admin/tests/test_app.py + test_routes.py + test_health.py)

## 报告

- reports/LA_LEGAL_PRIVACY_PRE_AUDIT_2026-06-20.md (363 行, 9 风险 0 阻塞)
- reports/QA_CROWD_DB_NON_HUNAN_DENSITY_AUDIT.md (45 行, CRITICAL 文档失真已规避)

## 文件

M CHANGELOG.md (v2.1.3)
M admin/config.py (2 个 _enforce_*_policy + load_settings post-load)
M admin/routes/health.py (3 个 _check_* + checks 子对象)
M admin/routes/ui.py (admin/orders/new 模板加 footer)
M admin/static/dashboard.html (footer 块)
M admin/tests/test_app.py (适配 checks 字段 + regex 兼容)
M admin/tests/test_health.py (4 个新测试)
M admin/tests/test_routes.py (适配 checks 字段)
M docs/CURRENT_STATE.md (0.3-0.5 增量段)
M docs/LEGAL_PRIVACY_BASELINE.md (§6 清理 + §7 重写)
+ data/crowd_db/tests/test_crowd_db_data_quality.py (8 tests)
+ reports/LA_LEGAL_PRIVACY_PRE_AUDIT_2026-06-20.md
+ reports/QA_CROWD_DB_NON_HUNAN_DENSITY_AUDIT.md
2026-06-20 18:36:23 +08:00

5.1 KiB
Raw Blame History

LEGAL_PRIVACY_BASELINE

状态: 草案T12 上线前基线)
适用范围: /pricing/checkout/api/public/orders/portal/{token} 全链路,以及后台订单处理、报告交付、渠道补录场景。
最后更新: 2026-06-14


1. 目标

本文件定义 T12 用户端 Web 自助 MVP 在法务/隐私侧的最小上线基线,防止以下误判:

  • 代码能跑 = 可以直接收真实考生资料
  • 有加密字段 = 已完成隐私合规
  • 可删除数据库记录 = 已具备正式删除流程

本文件只定义当前必须落实的最低要求,不代替正式律师审阅。


2. 当前涉及的数据类型

2.1 用户主动提交的数据

  1. 家长/联系人信息
    • 称呼
    • 手机号
    • 微信号(可选)
  2. 考生信息
    • 姓名
    • 省份
    • 分数
    • 位次
    • 选科
    • 兴趣方向
    • 家长备注
  3. 订单与交付信息
    • 订单号
    • 套餐版本
    • 支付状态
    • 报告 HTML/PDF 路径
  4. 后台处理信息
    • 状态流转历史
    • 处理人
    • 处理原因

2.2 敏感级别分层

  • S1 高敏: 手机号、身份证号(如未来启用)、支付回调标识、密钥材料
  • S2 中敏: 姓名、分数、位次、选科、兴趣、家长备注
  • S3 低敏: 订单号、套餐、状态、非个体化统计

3. 处理目的与边界

允许的处理目的:

  1. 生成志愿填报审核/方案服务
  2. 联系用户完成资料补充、状态通知、交付提醒
  3. 进行售后、退款、争议处理
  4. 做最小必要的审计与故障排查

禁止的处理目的:

  1. 未经单独同意用于营销推送
  2. 出售或共享给无关第三方
  3. 用于广告画像或跨场景推荐
  4. 在对外案例中展示未脱敏真实资料

4. 未成年人 / 监护人基线

项目面向高考考生场景,默认视为涉及未成年人或其监护人数据。

最低要求:

  1. 前台资料提交前,应展示“监护人已知情并同意提交资料用于志愿填报服务”的确认文案
  2. 同意记录至少要保存:
    • consent_version
    • consent_scope
    • consent_given_at
    • consent_operatorself/guardian/admin_import
  3. 后台人工补录渠道单时,也必须记录同意来源:
    • 闲鱼/微信/学校/线下确认

当前状态:

  • consent_version / consent_scope / privacy_accepted / service_terms_accepted / guardian_confirmed 已落在 order_intakes payload 提交链路
  • consent_given_at / privacy_accepted_at / service_terms_accepted_at / consent_channel / consent_operator 现已在 portal 提交链路自动补齐
  • 但后台代录 / 外部渠道补录仍需逐步统一到同一审计口径,因此仍不可宣称“监护人同意闭环已整体完成”

5. 对外文案最低要求

前台至少应明确告知:

  1. 收集哪些信息
  2. 用于什么目的
  3. 不用于营销出售
  4. 可申请删除
  5. 监护人同意要求
  6. 服务结果为辅助决策,不承诺录取结果

建议文案入口:

  • 下单页提交前
  • 资料填写页提交前
  • 页脚“隐私政策 / 数据删除说明”链接

6. 同意记录最小字段

上线前至少应在订单上下文保存以下字段:

  • consent_version: 当前协议/隐私政策版本
  • privacy_accepted_at: 隐私政策同意时间
  • service_terms_accepted_at: 服务说明同意时间
  • guardian_confirmed: 是否监护人确认
  • consent_channel: web / wechat / xianyu / school (实现侧 4 个 source旧版文档曾列 admin 渠道值因未在生产路径写入而移除6/20 校准)

这些字段可先落在:

  • order_intakes payload
  • 或订单扩展字段 / tags

但不得只停留在前端文案、完全不落库。


7. 当前代码与本基线的差距

已具备6/20 增量):

  • 订单敏感字段加密/脱敏基础
  • 订单删除 DAO 能力(含 OrdersDAO conn ownership 修复T12-D
  • Portal token 访问控制基础
  • 后台代录 / 外部渠道补录的同意审计统一化A-2 6/20 落地:consent_method / consent_operator / consent_channel / consent_given_at / consent_version 5 字段在 admin/portal 双轨写库admin CreateOrderRequest.consent 必填;consent_operator 严格按 self/guardian/admin_import 白名单;缺失或非法 consent → HTTP 422
  • 数据删除 SOP 的脚本化/产品化T12-D 6/20 落地:scripts/gaokao-retention-cleanup.py + systemd unit + cron 样例 + runbook §8 端到端 acceptance 步骤)

尚缺(截至 6/20

  • 对外正式法务审阅与版本管理PM/legal 拍板4 份草案已就绪)
  • consent_version 升级机制(当前硬编码 t12-web-mvp-v1,改版时需 bump
  • consent_scope 命名空间统一portal web-self-service-order-intake vs admin {source}-channel-intake,建议提升为 Literal

8. T12 验收口径

只有同时满足以下条件,才可说“隐私合规基线已补齐”:

  • 已有正式文档:隐私政策 + 数据保留删除规则
  • 前台存在可见入口
  • 同意字段已落库
  • 后台/运维知道如何响应删除请求

在此之前,只能说:

  • 已建立隐私合规草案基线
  • 不能说“隐私合规已整体完成”