2026-07-05 21:46:24 +08:00
<!-- 历史快照提示：本文件保留为历史审计材料，不再代表当前项目状态。 -->
> ⚠️ **历史快照（非当前真相源）**：本文件仅保留当时审查/收口结论。当前状态与执行顺序以 `docs/CURRENT_STATE.md`、`docs/ACTIVE_REMEDIATION_2026-07-05_REVIEW.md`、`docs/ACTIVE_EXECUTION_BOARD_2026-07-05_REVIEW_REMEDIATION.md`、`docs/plans/2026-07-05-review-remediation-systemic-fix-plan.md` 和 `reports/REVIEW_REPORT_2026-07-05_COMPREHENSIVE_PROJECT_REVIEW.md` 为准。
---
2026-06-20 18:36:23 +08:00
# LA_LEGAL_PRIVACY_PRE_AUDIT_2026-06-20
> 内部预审报告 · 用于 PM / Legal 审阅前发现内部一致性与实现漂移
> 审计对象：
> 仓库 HEAD：
> 审计日期：
---
## 0. 审计范围
| # | 文件 | 行数 | 最后更新 |
| --- | ---------------------------------------- | ---- | ---------- |
| 1 | `docs/PRIVACY_POLICY_DRAFT.md` | 65 | 2026-06-14 |
| 2 | `docs/SERVICE_TERMS.md` | 53 | 2026-06-14 |
| 3 | `docs/LEGAL_PRIVACY_BASELINE.md` | 162 | 2026-06-14 |
| 4 | `docs/DELIVERY_RETENTION_OPS_RUNBOOK.md` | 242 | 2026-06-20 |
> 任务说明里 runbook 行数标的是 144， （ ）
> 以下所有引用基于实际行数。
---
## 1. 内部一致性（
### 1.1 ✅ `DATA_RETENTION_AND_DELETION.md` 引用闭环
| 引用方 | 引用路径 | 目标文件状态 |
| ----------------------------------- | ------------------------------------- | ---------------------------- |
| `PRIVACY_POLICY_DRAFT.md:43` | `docs/DATA_RETENTION_AND_DELETION.md` | ✅ 存在（ ， ）
| `SERVICE_TERMS.md:43` | `docs/DATA_RETENTION_AND_DELETION.md` | ✅ 存在 |
| `PRIVACY_POLICY_DRAFT.md:43` (隐含) | "数据保存与删除" §5 | 与 §7 顺序自洽 |
**结论**：引用闭环成立，未发现悬空引用。
### 1.2 ⚠️ `consent_channel` 白名单在 `LEGAL_PRIVACY_BASELINE.md` 内部矛盾
`LEGAL_PRIVACY_BASELINE.md` 同一份文件里出现两套渠道列表：
- §4 行 86（ ） ： `闲鱼/微信/学校/线下确认` （中文叙事，**4 个**）
- §6 行 123（ ） ： `consent_channel: web / wechat / xianyu / school / admin` （ ）
**实现真相**（见 §2.2） ： `xianyu / wechat / web / school` ， `consent_channel = payload.source` （即 xianyu/wechat/school/web 之一），并未真正出现字面量 `"admin"` 。
**结论**：
- §6 的 `admin` 渠道值是 **孤儿 ** ——代码侧没有任何 `consent_channel=admin` 的写入路径。
- §4 的 "线下确认" 渠道是 **未落库 ** ——没有被建模为合法 source。
- 应在送 PM/Legal 之前把 §6 改成 `web / wechat / xianyu / school` ，并把 §4 的"线下确认"对应到 `school` 或显式说明走 admin 补录。
### 1.3 ⚠️ `consent_operator` 内部一致性
`LEGAL_PRIVACY_BASELINE.md:84` 声明白名单 `self / guardian / admin_import` （
- 实现 `admin/routes/orders.py:590` 实际只产生 `"guardian" if source == "web" else "admin_import"` ， `self` 永不产生**。
- `admin/tests/test_routes_orders.py:161, 195` 断言非 web 渠道 = `admin_import` 。
- 单元测试中无任何 `consent_operator == "self"` 的断言。
- `data/orders/intake_schema.py:26` 字段叫 `guardian_confirmed` ，与 `consent_operator=self` 没有对应转换逻辑。
**结论**： `self` 是 **白名单里的僵尸值 ** 。要么在文档里删掉，要么在实现里补一处（例如旧数据导入场景），否则白名单会误导外部审阅。
### 1.4 ✅ `retention_days = 180` 口径一致
| 位置 | 数值 | 来源 |
| --------------------------------------------------- | --------------------------------------------------------------- | -------------------------------- |
| `DELIVERY_RETENTION_OPS_RUNBOOK.md:63` | 默认 `180` | `GAOKAO_RETENTION_DAYS` 环境变量 |
| `deploy/systemd/gaokao-retention-cleanup.service:9` | `Environment=GAOKAO_RETENTION_DAYS=180` | ✅ |
| `deploy/systemd/gaokao-jobs.env.example:9` | `GAOKAO_RETENTION_DAYS=180` | ✅ |
| `deploy/cron/gaokao-jobs.crontab:9` | `GAOKAO_RETENTION_DAYS=180` | ✅ |
| `admin/config.py:261` | `retention_days=int(os.getenv("GAOKAO_RETENTION_DAYS", "180"))` | ✅ |
| `data/orders/deletion_service.py:38` | `DEFAULT_RETENTION_DAYS = 180` | ✅ |
| `docs/DATA_RETENTION_AND_DELETION.md:13-17` | 180 天 | ✅ |
| `tests/test_retention_cleanup.py` | 显式 `--retention-days 180` | ✅ |
**结论**：
### 1.5 ⚠️ Runbook 描述的脚本参数默认值与实现不一致
`DELIVERY_RETENTION_OPS_RUNBOOK.md:36-38` 写：
> 手工入口：`scripts/gaokao-retention-cleanup.py --cutoff <ISO8601> [--dry-run]`
> 定时入口：`scripts/gaokao-retention-cleanup.py --retention-days 180 [--dry-run]`
实现侧 `data/orders/retention_cleanup.py:173-182` ：
```python
cutoff_group = parser.add_mutually_exclusive_group(required=True)
cutoff_group.add_argument("--cutoff", ...)
cutoff_group.add_argument("--retention-days", type=int, help="...")
# 没有 default=180
```
- `--retention-days` **没有 default ** ；裸跑 `python3 scripts/gaokao-retention-cleanup.py` 会 `parser.error: one of the arguments --cutoff --retention-days is required` 。
- 真正"默认 180"只来自上层调度的环境变量（ ）
- runbook §3 的 4 条手工命令示范都显式给了 `--cutoff` 或 `--retention-days 180` ，
**结论**： ）
### 1.6 ✅ 4 份文档之间互引用闭环
| 源 | 引 | 目标 |
| -------------------------------------- | ---------------------------------------------------------------------- | ----------- |
| `PRIVACY_POLICY_DRAFT.md:43` | `docs/DATA_RETENTION_AND_DELETION.md` | ✅ 存在 |
| `SERVICE_TERMS.md:42-43` | `docs/PRIVACY_POLICY_DRAFT.md` + `docs/DATA_RETENTION_AND_DELETION.md` | ✅ 双向闭环 |
| `LEGAL_PRIVACY_BASELINE.md` | 仅引用 docs/ 内文件 | ✅ 自洽 |
| `DELIVERY_RETENTION_OPS_RUNBOOK.md:78` | `docs/DATA_RETENTION_AND_DELETION.md` | ✅ 存在 |
唯一需要注意：
- 3 份：
- 1 份： （ ）
送审前建议把 baseline / privacy / service terms 同步刷新到 2026-06-20，
---
## 2. 实现 vs 文档漂移（
### 2.1 ✅ `consent_method` 5 项白名单 = 完全对齐
| 来源 | 列出 | 数量 |
| ----------------------------------------- | --------------------------------------------------------------------------- | ---- |
| `LEGAL_PRIVACY_BASELINE.md` | （未列具体白名单） | — |
| 实现 `admin/routes/orders.py:248-254` | `verbal_chat / phone_recording / screenshot / written_form / self_declared` | 5 |
| 实现注释 `admin/routes/orders.py:242-247` | 同上，附语义说明 | 5 |
| 测试 `admin/tests/test_routes_orders.py` | 用例覆盖 `verbal_chat` 等 | ✅ |
**结论**：
### 2.2 ✅ `consent_operator` 白名单实现侧：
如 §1.3 所述，实现只写 `guardian` 或 `admin_import` ， `self` 出现在白名单但无生产路径。
### 2.3 ✅ Source 4 项 = 与 §6 baseline 一致
| 来源 | 列出 |
| ---------------------------------------- | ---------------------------------------------------------------- |
| 实现 `admin/routes/orders.py:94` | `OrderSource = Literal["xianyu", "wechat", "web", "school"]` |
| 实现 `admin/routes/ui.py:141` | `<option>` 同样 4 项 |
| baseline `LEGAL_PRIVACY_BASELINE.md:86` | `闲鱼/微信/学校/线下确认` （ ，
| baseline `LEGAL_PRIVACY_BASELINE.md:123` | `web / wechat / xianyu / school / admin` （ `admin` ）
**结论**：核心 4 项对齐；`admin` 渠道值是 §6 列表里的多余项（详见 §1.2）。
### 2.4 ✅ 字段落库：
| 字段 | 落库位置 | 实现证据 |
| ------------------ | -------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
| `consent_version` | order_intakes payload | `admin/routes/orders.py:651` 写死 `t12-web-mvp-v1` |
| `consent_scope` | order_intakes payload | `web_public.py:1675` 默认 `web-self-service-order-intake` ； `${source}-channel-intake` |
| `consent_channel` | order_intakes + orders.consent_method | `orders.py:653` 写 `payload.source` |
| `consent_operator` | order_intakes | `orders.py:654, 590` |
| `consent_method` | order_intakes + orders.consent_method (A-2 冗余) | `orders.py:655, 615` ； `schema.py:110-114` 增列 |
| `consent_given_at` | order_intakes + orders.consent_given_at (A-2 冗余) | `schema.py:115-116` 增列 |
**结论**： `consent_method` / `consent_given_at` 列在 `data/orders/schema.py:113-116` 通过 `ALTER TABLE` 兼容迁移——`data/orders/models.py:97-98` 同步加 dataclass 字段。
### 2.5 ⚠️ 严格审查报告 vs 现状
`reports/STRICT_COMPREHENSIVE_REVIEW_2026-06-18.md:537` （
> 落库仍只有 `consent_version`、`consent_scope` 与几个布尔值。
A-2 (6/20) 已经把这条批评点修复：`consent_given_at / privacy_accepted_at / service_terms_accepted_at / consent_channel / consent_operator` 全部落库。
**结论**：这条历史批评点已修复，但 strict review 报告本身没有更新；建议在下次 strict review 时回填修复状态。
---
## 3. T12-D 端到端 Acceptance 步骤完整性（ ）
### 3.1 步骤清单与实现交叉验证
| 步骤 | runbook §8.x | 实现证据 | 状态 |
| -------------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------ | --------------- |
| §8.1 前置环境（ `PY/DB_PATH/SHARE_DB_PATH/LOG_PATH/FERNET_KEY` | 全部为 retention cleanup 入口的环境变量 | ✅ 完整 |
| §8.2.1 跑回归测试 | `$PY -m pytest tests/test_retention_cleanup.py -q` | 文件中实测有 **6 个 test function ** （行 37/52/73/98/123/167）
| §8.2.2 端到端 smoke 脚本 | seed 4 订单 + apply + 验证 | `data/orders/retention_cleanup.py:run_cleanup()` 、`data/orders/dao.py` （ ）
| §8.3 验收矩阵 | 7 行 checklist | 对应 `run_cleanup` 返回的 `candidates / anonymized / deletion_logs_pruned / share_events_pruned` | ✅ 完整 |
| §8.4 历史 bug 背景 | `OrdersDAO.__exit__` 关外部 conn | `data/orders/dao.py` 增加 `owns_conn: bool = False` 参数 | ✅ 已修复并解释 |
| §8.5 部署前 checklist | 5 行 `- [ ]` 项 | 全部对应 systemd/journalctl/测试套件 | ✅ 完整 |
### 3.2 步骤中可执行性检查
- §8.2.1 的 smoke 脚本是 inline Python `-c "..."` ， `scripts/smoke_retention_cleanup.py` 脚本文件，
- §8.2.2 的 `Order(..., created_at='2024-12-01T00:00:00+00:00')` 是固定时间戳， `2025-06-30T00:00:00+00:00` ，
- §8.5 没有把 `systemctl status` 的"成功"判定值写明——只列了命令。这是已知可接受的最小步骤。
**结论**： **完整且可执行 ** 。微调建议是脚本提取 + 时间戳假设显式化。
---
## 4. 缺失项识别
### 4.1 ✅ 隐私政策 §5 引用 `DATA_RETENTION_AND_DELETION.md` 已存在
- 文件存在：`docs/DATA_RETENTION_AND_DELETION.md` （
- 内容覆盖： （ ） （ ） （ ） （ ） （ ）
- 关键数字 `180` 出现在 §2 表格（订单/资料/报告/通知/支付）和 §6 命令行
- 与 `DELIVERY_RETENTION_OPS_RUNBOOK.md` 互引：
**结论**：引用文件**存在且内容完整**，未发现悬空或残缺。
### 4.2 ⚠️ `LEGAL_PRIVACY_BASELINE.md` §7 "尚缺"列表与现实存在部分漂移
baseline §7 (行 142-146) 写：
> 尚缺：
>
> - 后台代录 / 外部渠道补录的同意审计统一化
> - 数据删除 SOP 的脚本化/产品化
> - 对外正式法务审阅与版本管理
A-2 (6/20) + T12-D (6/20) 已经把前两条都做了：
- 后台/外部渠道同意审计已统一化（`consent_method` + `consent_operator` + `consent_channel` 全部白名单化并落库）
- 数据删除 SOP 已脚本化（`scripts/gaokao-retention-cleanup.py` 配合 systemd/cron 样例）
**结论**：
### 4.3 ⚠️ "线下确认"渠道的最终落地
baseline §4 写 `闲鱼/微信/学校/线下确认` ，但实现侧 4 个 source 中没有"线下"——`school` 看上去承接了线下场景，但语义上"线下确认"（如家长到场签纸质单）≠ "school 渠道"。
**结论**：建议在 baseline §4 显式说明"线下确认 = school 渠道" 或新增 `offline` source（ ）
### 4.4 ⚠️ `consent_version` 没有走基线化的版本号管理
实现侧 `admin/routes/web_public.py:1674` 与 `admin/routes/orders.py:651` 都硬编码 `t12-web-mvp-v1` ：
- privacy policy 与 service terms 还没有声明"当前生效版本号"
- 文档侧用 `最后更新: 2026-06-14` 的自然日期；代码侧用语义化 `v1`
- 当 privacy policy / service terms 改版时，没有机制把 `consent_version` 一起升档
**结论**：送 PM/Legal 之前需要在 baseline §6 加一段"版本升级机制"：什么时候 bump `consent_version` ，是否需要用户重新同意。
### 4.5 ⚠️ Portal 提交路径 vs Admin 提交路径的 `consent_scope` 命名空间不一致
| 路径 | consent_scope 字面量 |
| ----------------------------- | ------------------------------------------------------- |
| Portal (`web_public.py:1675` ) | `web-self-service-order-intake` |
| Admin (`orders.py:652` ) | `{source}-channel-intake` （如 `xianyu-channel-intake` ）
两条路径在数据库侧都是字符串，**没有枚举**——下游做合规报表/审计聚合时需要做模糊匹配，违反 "consent_scope 必须来自受控白名单" 的合规最小要求。
**结论**：建议把 consent_scope 提升为 Literal 与 consent_method 同级。
---
## 5. 前台文案入口：
### 5.1 admin UI 路由清单（`admin/routes/ui.py`）
| 路径 | 处理函数 | 模板来源 | footer 隐私政策链接 |
| -------------------------------- | ------------------------ | ---------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
| `/dashboard` 、`/admin/dashboard` | `dashboard_page()` | `admin/static/dashboard.html` | ❌ **无 footer ** （ ， `<footer>` 标签） |
| `/admin/orders/new` | `admin_new_order_page()` | `_render_admin_new_order_page()` 内联 HTML（ ） **无 footer ** （只在 `</body>` 前一段 `<script>` ，无任何 `<footer>` /`<a href="/privacy">` ）
| `/s/{code}` | `share_page()` | `admin/share_page.py:158` 有 `.footer-panel` | ⚠️ **是 share 页 footer， ** |
### 5.2 对比：
`admin/routes/web_public.py:749-763` 提供了 `_render_footer_links()` ：
```python
f'<footer style="margin-top:24px;color:#5b6b88 ;font-size:14px;">'
f'<a href="{privacy_href}">隐私政策</a> · '
```
测试 `admin/tests/test_web_public.py:445-464` 验证 `landing` / `pricing` / `privacy` 页都有 `href="/privacy"` 链接 + `/privacy` 路由可访问。
**结论**：
- **portal 前台页有 footer 隐私政策链接 ✅**
- **admin 后台页（
- `dashboard.html` 整个文件 592 行无 `<footer>` 标签，缺明显的合规入口
### 5.3 严重程度判断
baseline §5 提到：
> 建议文案入口：下单页提交前 / 资料填写页提交前 / **页脚"隐私政策 / 数据删除说明"链接**
baseline §8 提到：
> 前台存在可见入口（隐私政策 + 数据删除规则）
**严重度**：中。
- legal baseline §5 用词是 "前台"，可解释为"用户端 web"——portal 已有 footer。
- 但严格意义上，**后台 dashboard 缺 footer 隐私政策**会留下"内部用户完全不知道数据策略"的口子；如果后台操作员误以为后台操作可豁免合规，会被外部审计抓到。
- 推荐修法：在 `dashboard.html` 末尾加 `<footer>` 块，链接到 `/privacy` 与 `/deletion` （ ） ；
---
## 6. 风险评级汇总
| ID | 风险 | 等级 | 阻塞送审？ |
| --- | ------------------------------------------------------- | ---- | ----------------------------------------- |
| R1 | baseline §6 `admin` 渠道值孤儿 + §4 "线下确认" 未建模 | 中 | **建议在送审前修 ** |
| R2 | `consent_operator=self` 僵尸白名单 | 低 | 建议在送审前删 |
| R3 | runbook `--retention-days 180` 措辞歧义（无 default）
| R4 | baseline §7 "尚缺" 列表未同步 A-2/T12-D 进展 | 中 | **建议在送审前同步 ** |
| R5 | `consent_version` 硬编码无升级机制 | 中 | 建议在 baseline §6 加一段 |
| R6 | `consent_scope` 不是枚举（
| R7 | admin 后台 dashboard.html 无 footer 隐私政策链接 | 中 | **建议在送审前补 ** |
| R8 | strict review 2026-06-18 报告未回填 A-2 修复状态 | 低 | 顺手做 |
| R9 | 3 份文档 "最后更新" 还是 6/14，
**送审阻塞级**：
**建议在送审前修**： （
**可以下个迭代修**： （
---
## 7. 给 PM / Legal 的提示清单
1. **A-2 6/20 落地的 5 个同意审计字段已经在 admin/portal 双轨写库 ** ——可以对外说"同意审计口径已统一化"，但仍不可说"监护人同意闭环已整体完成"（
2. **source 实际只 4 项 ** （ `xianyu / wechat / web / school` ），文档里出现过的 `admin` 渠道值从未被实际写入；送审前请把 baseline §6 的 `admin` 去掉。
3. * * `consent_operator` 只产生 2 个值**（ `guardian` for web, `admin_import` for other 3 source） ， `self` 永不使用——白名单可删 `self` ，或为旧数据导入场景补一条生产路径。
4. **admin 后台页面（ ） ** ——portal 前台有，
5. **retention_days=180 在文档/环境/代码/测试/运行手册五处完全对齐 ** ，可以放心。
6. **T12-D acceptance 步骤（ ） ** ， `-c` 提到 `scripts/smoke_retention_cleanup.py` 改善可维护性。
7. **DATA_RETENTION_AND_DELETION.md（ ** ——隐私政策 §5 的引用闭环成立。
---
## 8. 附录：关键引用行号速查
| 引用 | 位置 |
| --------------------------------------- | ------------------------------------------------------------ |
| `consent_method` Literal | `admin/routes/orders.py:248-254` |
| `consent_method` 列迁移 | `data/orders/schema.py:113-114` |
| `consent_given_at` 列迁移 | `data/orders/schema.py:115-116` |
| `OrderSource` Literal | `admin/routes/orders.py:94` |
| `consent_operator` 计算 | `admin/routes/orders.py:590` |
| `consent_scope` portal | `admin/routes/web_public.py:1675` |
| `consent_scope` admin | `admin/routes/orders.py:652` |
| 4 source 内联选项 | `admin/routes/ui.py:141` |
| dashboard.html 模板 | `admin/static/dashboard.html` （ ）
| `_render_footer_links` | `admin/routes/web_public.py:749-763` |
| retention cleanup 入口 | `scripts/gaokao-retention-cleanup.py` |
| retention 默认 180 | `admin/config.py:261` / `data/orders/deletion_service.py:38` |
| retention `--retention-days` 无 default | `data/orders/retention_cleanup.py:178-182` |
| retention 回归测试 6 个 | `tests/test_retention_cleanup.py:37/52/73/98/123/167` |
| T12-D 修复点 | `data/orders/dao.py` `owns_conn: bool = False` |
| A-2 整改文档 | `docs/ACTIVE_REMEDIATION_2026-06-20.md` |
| 历史批评点（已修复） | `reports/STRICT_COMPREHENSIVE_REVIEW_2026-06-18.md:537` |
---
## 9. 审计结论
**送审整体判断**：
**送审前**建议处理 3 项中等风险：
1. baseline §6 删 `admin` 渠道值 / §4 解释 "线下确认" 对应关系（ ）
2. baseline §7 "尚缺" 列表同步 A-2/T12-D 进展（ ）
3. admin 后台页面补 footer 隐私政策链接（ ）
**可以下个迭代处理**： （ ） ，
**总体送审建议**：✅ 可送 PM / Legal 审阅，附本报告作为"已知问题与下一迭代计划"附页。
