docs(frontend): add 2026-06-16 frontend audit, execution board, and local browser validation report

- ACTIVE_EXECUTION_BOARD_2026-06-16_OPTIMIZATION.md: 本轮前端审计/整改执行板 - 2026-06-16-optimization-program.md: 4 大工作流规划 - LOCAL_BROWSER_VALIDATION_2026-06-15.md: 本地浏览器验证报告与 Portal Step 5 历史问题 - test_requirements_rules_phase1.py: 规则 Phase1 配套测试
2026-06-16 20:13:23 +08:00
parent a957b39cc0
commit bf3d9c2c50
4 changed files with 760 additions and 0 deletions
--- a/docs/ACTIVE_EXECUTION_BOARD_2026-06-16_OPTIMIZATION.md
+++ b/docs/ACTIVE_EXECUTION_BOARD_2026-06-16_OPTIMIZATION.md
@@ -0,0 +1,246 @@
+# Batch 1 审计收敛执行板（2026-06-16）
+
+真相源输入：
+
+1. `docs/plans/2026-06-16-optimization-program.md`
+2. `docs/CURRENT_STATE.md`
+3. Batch 1-A/B/C/D 审计结论（主代理复核）
+
+---
+
+## 一、Batch 1 总结论
+
+四条优化线里，**最该先做的不是 CLI，而是“规则可信 + 专业数据可信”**。
+
+当前项目的主要风险顺序：
+
+### P0
+
+1. **规则规范可信度不足**
+   - 当前 `skills/gaokao-spec-checker/scripts/spec_checker_v2.py` 内置了 27 省规则字典，但证据链主要是手工编码规则 + 官方 URL 字段；缺“2026 年规则来源快照 / 更新时间 / 逐省证据状态”。
+   - 当前能做“规范检查”，但还不能对外稳妥宣称“已具备可追溯的 2026 各省官方规则验证能力”。
+
+2. **专业目录真相源缺失**
+   - 当前仓库里**没有 2026 官方专业目录数据集**。
+   - 也没有“近两年高校新增/取消专业”的正式接入层。
+   - 这会直接导致方案建议与审计结果可能引用过时专业。
+
+### P1
+
+3. **CLI 能力分散且偏脚本化**
+   - 已有 CLI/脚本很多，但主要是：`gaokao-checker`、`gaokao-collect-info.py`、`gaokao-visual-report-v2.py`、`gaokao-shortlink`、备份/运维脚本。
+   - **没有统一的“客服/运营/智能体调用层”**，尤其缺 create-order / get-order / list-orders / run-audit / generate-report 这一套正式命令面。
+
+4. **规划 / 实现漂移明显**
+   - README / PRD / ROADMAP / CURRENT_STATE / 架构文档 / 代码实现之间有多处口径漂移。
+   - 其中最严重的是：
+     - Web 自助主链代码已大量落地，但文档仍长期按“未完成”叙述
+     - PRD 套餐价格/档位与代码实现不一致
+     - 状态机设计与实现路线未落锤
+
+---
+
+## 二、四条线收敛结论
+
+### A. 规则规范线
+
+**已知现状**
+
+- 规则检查核心入口：
+  - `scripts/gaokao-checker`
+  - `skills/gaokao-spec-checker/scripts/spec_checker_v2.py`
+- 已有 27 省规则字典
+- 有多省自动识别能力
+- 有测试覆盖 `tests/test_coverage_gate_core.py`、`tests/test_all.py`
+
+**缺口**
+
+- 缺 2026 规则证据矩阵
+- 缺“全国通用规则”抽象层文档与结构化表达
+- 缺规则版本化与更新时间字段
+
+**判断**
+
+- 能做“规范检查工具”
+- 但还不够“2026 官方规则可信审计系统”
+
+---
+
+### B. 专业目录数据线
+
+**已知现状**
+
+- 当前仓库没有正式的 2026 官方专业目录数据真相源
+- 没有教育部目录 + 高校招生专业变更的统一接入层
+- 推荐/报告/审计逻辑会消费专业名，但缺版本化目录底座
+
+**缺口**
+
+- 没有 `major catalog` 数据模型
+- 没有官方/准官方数据导入流程
+- 没有近两年专业增减风险标记
+
+**判断**
+
+- 这是当前项目最核心的数据风险之一
+- 应与规则规范线并列最高优先级
+
+---
+
+### C. CLI 能力线
+
+**已知现状**
+
+- 当前已有 CLI/脚本入口：
+  - `scripts/gaokao-checker`
+  - `scripts/gaokao-collect-info.py`
+  - `scripts/gaokao-visual-report-v2.py`
+  - `scripts/gaokao-shortlink`
+  - `scripts/payment_provider_doctor.py`
+  - `scripts/gaokao-delivery-dispatch.py`
+  - `scripts/gaokao-delivery-watchdog.py`
+  - `scripts/gaokao-retention-cleanup.py`
+  - `scripts/backup_snapshot.sh`
+  - `scripts/backup_verify.sh`
+- 后台 API 已有可被 CLI 包装的能力：
+  - auth
+  - orders
+  - users
+  - stats
+  - notifications
+  - public orders / portal 链路
+
+**缺口**
+
+- 没有统一 `gaokao-cli` 命令面
+- 没有客服/运营最小权限命令集
+- 没有“脚本 vs 正式 CLI vs HTTP wrapper”分层规范
+
+**判断**
+
+- CLI 适合做成第二批实现
+- 前提是先把规则/专业数据底座定下来
+
+---
+
+### D. 规划 / 实现优化线
+
+**已知现状**
+
+- 漂移点已明确：
+  - 项目定位文档 vs Web 自助实现状态
+  - PRD SKU/价格 vs 实现
+  - 状态机计划 vs 实现
+  - README 目录图 vs 实际目录
+  - 双架构文档并存
+- 这不是代码 bug，而是**真相源治理问题**
+
+**判断**
+
+- 不先收敛真相源，后面的规则/专业/CLI 做出来也会继续漂
+- 但它不该优先于规则/专业数据本身
+
+---
+
+## 三、建议优先级（执行顺序）
+
+### Batch 2（建议立即启动）
+
+#### Lane 1 - 规则规范可信化（P0）
+
+目标：把当前“可检查”提升为“可追溯的 2026 规则检查”。
+
+交付物：
+
+- `docs/CURRENT_RULES_STATE_2026-06-16.md`
+- `docs/RULES_SOURCE_OF_TRUTH.md`
+- `docs/plans/rules-2026-gap-remediation.md`
+
+实现重点：
+
+- 逐省规则证据矩阵
+- 全国通用规则抽象
+- 规则版本字段 / 更新时间字段
+- 统一审计入口整理
+
+#### Lane 2 - 专业目录可信化（P0）
+
+目标：建立 2026 专业目录真相源与变更风险模型。
+
+交付物：
+
+- `docs/MAJOR_DATA_SOURCE_OF_TRUTH.md`
+- `docs/MAJOR_DATA_RISK_MATRIX_2026.md`
+- `docs/plans/major-catalog-2026-ingestion.md`
+
+实现重点：
+
+- 国家级目录 vs 高校招生专业分层
+- 数据结构设计
+- 更新策略（年度全量 + 差异更新）
+- 高风险专业变更标记
+
+### Batch 3（规则/专业方案出来后）
+
+#### Lane 3 - CLI 能力面（P1）
+
+建议最小命令集：
+
+- `create-order`
+- `get-order`
+- `list-orders`
+- `run-audit`
+- `generate-report`
+- `create-shortlink`
+- `payment-doctor`
+
+#### Lane 4 - 真相源与规划收敛（P1）
+
+重点：
+
+- SKU/价格统一
+- 状态机决策落锤
+- README/ROADMAP/PRD/CURRENT_STATE 对齐
+- 双架构文档收敛
+
+---
+
+## 四、推荐子智能体分工（下一轮实现）
+
+### Agent-A（规则规范）
+
+- 先产出规则证据矩阵
+- 再补统一规则模型与审计入口方案
+
+### Agent-B（专业目录）
+
+- 先产出专业数据真相源方案
+- 再定义数据模型与接入策略
+
+### Agent-C（CLI）
+
+- 不立刻写实现
+- 先做命令契约与权限边界设计
+- 等 A/B 收敛后再落地 CLI
+
+### Agent-D（规划/真相源）
+
+- 先收敛 SKU / 状态机 / README / CURRENT_STATE 漂移
+- 作为 A/B/C 的公共文档治理支撑
+
+---
+
+## 五、当前建议
+
+**建议下一步直接启动 Batch 2，但只开两条实现线：**
+
+1. 规则规范可信化
+2. 专业目录可信化
+
+同时让规划/真相源线做轻量配套收敛；CLI 暂不重实现，只先出契约设计。
+
+这样能避免：
+
+- 先做 CLI，后面数据模型再返工
+- 先做规划文档，结果没有真实数据底座支撑
+- 规则和专业目录口径继续分裂
--- a/docs/plans/2026-06-16-optimization-program.md
+++ b/docs/plans/2026-06-16-optimization-program.md
@@ -0,0 +1,327 @@
+# Gaokao Volunteer System 优化计划（2026-06-16）
+
+> **For Hermes:** Use `subagent-driven-development` to execute this plan by workstream. 先审计/设计，再实现，再验证，再文档收口。
+
+**Goal:** 在不扩大范围失控的前提下，把志愿服务项目补齐到“规则可信、专业数据可信、CLI 可调度、规划与实现一致”的下一阶段可执行状态。
+
+**Architecture:** 把任务拆成 4 条主线：规则规范、专业目录数据、CLI 能力层、规划/实现优化。每条主线先做现状审计与真相源整理，再进入实现。跨主线共享单一真相源，避免文档漂移和数据口径冲突。
+
+**Tech Stack:** Python/FastAPI/SQLite/Hermes skills & CLI/静态 HTML portal/测试与文档体系。
+
+---
+
+## 一、总原则
+
+1. **先审计后实现**：先确认当前已有能力、缺口、权威数据源、更新频率。
+2. **权威源优先**：省级考试院/教育考试院、教育部/阳光高考/本科专业目录等官方或准官方源优先。
+3. **数据与规则分层**：
+   - 规则规范 = 可验证约束
+   - 专业目录 = 事实数据集
+   - CLI = 调度入口
+   - 规划/实现优化 = 架构与流程治理
+4. **每条主线都要可回归验证**：不是“收集一份材料”就算完成。
+5. **先做最小闭环，再扩面**：先覆盖 2026 版核心省份 + 国家级专业目录，再考虑全面扩省与增量同步。
+
+---
+
+## 二、四条主线与验收目标
+
+### Workstream A：2026 志愿规范/审计能力
+
+**目标**
+
+- 明确“全国通用规范 + 各省 2026 规则差异”能否被系统读取、验证、审计。
+- 输出一套可由智能体/CLI 调用的规则审计能力。
+
+**要回答的问题**
+
+1. 当前仓库已有多少省份规则？哪些是 2026 版，哪些只是历史迁移？
+2. 是否已有“全国通用规范”抽象层？
+3. 是否已有可供程序调用的统一审计入口？
+4. 哪些省份缺 2026 规则或规则证据链不完整？
+
+**交付物**
+
+- `docs/CURRENT_RULES_STATE_2026-06-16.md`
+- `docs/RULES_SOURCE_OF_TRUTH.md`
+- `docs/plans/rules-2026-gap-remediation.md`
+- 规则能力清单（支持省份 / 不支持省份 / 证据来源 / 更新时间）
+- 一个统一 CLI 入口（若现有 `gaokao-checker` 不足则补强）
+
+**验收标准**
+
+- 能列出各省 2026 规则覆盖矩阵
+- 能对至少 1 份方案执行真实审计并输出结构化结果
+- 明确“全国通用规则”和“省级差异规则”的边界
+
+---
+
+### Workstream B：2026 官方专业目录与近两年专业增减
+
+**目标**
+
+- 建立 2026 官方专业目录的真相源
+- 补齐近两年高校/国家层面的新增、取消、停招、调整风险
+- 防止系统输出过时或错误专业
+
+**要回答的问题**
+
+1. 当前项目里专业数据来自哪里？是否可追溯？
+2. 能否拿到教育部/阳光高考/高校官方的专业目录与变更信息？
+3. 数据粒度是“本科专业目录”还是“高校招生专业”级别？
+4. 现有推荐/校验链路哪里在消费专业名称？是否会因过时专业导致错误建议？
+
+**交付物**
+
+- `docs/MAJOR_DATA_SOURCE_OF_TRUTH.md`
+- `docs/MAJOR_DATA_RISK_MATRIX_2026.md`
+- `docs/plans/major-catalog-2026-ingestion.md`
+- 专业数据结构定义（目录字段、来源字段、版本字段、变更标签）
+- 增量更新策略（年度全量 + 月度差异/人工校验）
+
+**验收标准**
+
+- 能说清当前专业库是否可信
+- 至少形成一套 2026 目录接入方案
+- 明确“国家目录”与“学校招生专业”两个层次的映射/差异
+
+---
+
+### Workstream C：系统 CLI 能力层（供智能体/运营/客服调用）
+
+**目标**
+
+- 给 Hermes/运营/客服智能体提供稳定 CLI 入口，能创建订单、查询订单、触发服务流程、调用审计/方案能力。
+
+**要回答的问题**
+
+1. 当前已有 CLI 有哪些？哪些只是脚本，哪些具备稳定契约？
+2. 运营/客服最小需要哪些命令？
+3. CLI 是直连本地代码、直连 DB，还是走 HTTP API？
+4. 需要多大权限边界与日志审计？
+
+**建议最小 CLI 范围**
+
+- `create-order`
+- `get-order`
+- `list-orders`
+- `submit-intake` / `update-order-status`
+- `run-audit`
+- `generate-plan` / `render-report`
+- `doctor-payment-provider`
+
+**交付物**
+
+- `docs/CLI_CAPABILITY_PLAN.md`
+- `docs/CLI_API_MAPPING.md`
+- `docs/plans/agent-cli-surface.md`
+- CLI 契约清单（输入/输出/错误码/审计日志）
+
+**验收标准**
+
+- 至少形成一套统一命令面设计
+- 明确每个命令是包裹现有脚本还是新增正式入口
+- 明确哪些命令给客服，哪些只给运营/管理员
+
+---
+
+### Workstream D：项目规划设计与实现优化
+
+**目标**
+
+- 统一产品规划、规则能力、专业数据、支付/交付、后台/CLI 的真相源，减少“能跑但不可持续”的实现漂移。
+
+**要回答的问题**
+
+1. 当前 PRD / 技术设计 / 实现 / 报告之间有哪些漂移？
+2. 现有模块边界是否清楚？
+3. 哪些是历史遗留脚本，哪些应提升为正式能力层？
+4. 哪些风险会阻碍下一阶段（数据可信、客服协作、支付上线、运营交付）？
+
+**交付物**
+
+- `docs/CURRENT_STATE.md` 更新
+- `docs/ARCHITECTURE_OPTIMIZATION_BOARD_2026-06-16.md`
+- `docs/ROADMAP_ALIGNMENT_2026-06-16.md`
+- 分阶段执行板（P0/P1/P2）
+
+**验收标准**
+
+- 明确当前架构哪些该保留、哪些该收敛
+- 明确下一阶段优先级排序
+- 文档真相源一致，不再让历史报告互相打架
+
+---
+
+## 三、执行顺序（建议）
+
+### Phase 1：审计与真相源整理（先做）
+
+1. A1 规则覆盖现状审计
+2. B1 专业数据来源审计
+3. C1 CLI 现状审计
+4. D1 规划/实现漂移审计
+
+### Phase 2：方案设计（基于审计结果）
+
+5. A2 规则模型与统一审计入口设计
+6. B2 专业目录数据模型与更新策略设计
+7. C2 CLI 能力面设计
+8. D2 总体架构/路线图对齐
+
+### Phase 3：实现（按依赖顺序）
+
+9. A3 规则审计能力补强
+10. B3 专业目录数据接入/清洗/版本化
+11. C3 CLI 实现与最小命令闭环
+12. D3 文档/执行板/真相源收敛
+
+### Phase 4：验证与交付
+
+13. 规则审计真实案例验证
+14. 专业目录抽样对账验证
+15. CLI 端到端命令验证
+16. 最终文档与执行板收口
+
+---
+
+## 四、子智能体分工建议
+
+### 子智能体 A（规则与审计）
+
+**职责**
+
+- 审计各省规则与全国规则现状
+- 盘点 2026 规则覆盖矩阵
+- 提出统一审计入口设计
+
+**输入**
+
+- `rules/`
+- `skills/gaokao-spec-checker/`
+- `scripts/gaokao-checker`
+- 相关 docs/plans
+
+**输出**
+
+- 规则覆盖矩阵
+- 缺口报告
+- 规则审计补强计划
+
+---
+
+### 子智能体 B（专业目录与数据真相）
+
+**职责**
+
+- 审计当前专业数据来源
+- 设计 2026 官方专业目录接入方案
+- 识别近两年专业增减风险点
+
+**输入**
+
+- `data/`
+- `scripts/`
+- 相关推荐/校验逻辑
+- 官方数据源调研任务
+
+**输出**
+
+- 专业目录真相源文档
+- 数据模型与更新方案
+- 风险矩阵
+
+---
+
+### 子智能体 C（CLI 与智能体调用面）
+
+**职责**
+
+- 盘点现有脚本与 API
+- 设计统一 CLI 面
+- 定义智能体/运营/客服最小命令集
+
+**输入**
+
+- `scripts/`
+- `admin/`
+- `README.md`
+- 现有订单/支付/交付入口
+
+**输出**
+
+- CLI 能力清单
+- 命令契约
+- 实现计划
+
+---
+
+### 子智能体 D（规划/架构/真相源收敛）
+
+**职责**
+
+- 对齐 PRD、ROADMAP、CURRENT_STATE、实现现状
+- 输出架构优化与执行优先级
+
+**输入**
+
+- `product/`
+- `docs/`
+- `reports/`
+- 当前代码结构
+
+**输出**
+
+- 当前状态与架构优化板
+- 下一阶段 roadmap
+- 统一真相源索引
+
+---
+
+## 五、主代理协调规则
+
+1. 主代理先看 4 个子智能体的审计结论，不直接开始大规模实现。
+2. 对冲突点做一次真相归并：
+   - 规则口径
+   - 专业数据口径
+   - CLI 调用口径
+   - 产品/实现边界
+3. 再决定 Phase 2/3 的具体实现顺序。
+4. 若你确认执行，默认采用：
+   - **先并行审计（A/B/C/D）**
+   - **后统一收敛**
+   - **再分批实现**
+
+---
+
+## 六、建议的第一批并行任务
+
+### Batch 1（并行，纯审计）
+
+- A：规则规范覆盖审计
+- B：专业目录数据源审计
+- C：CLI 能力面审计
+- D：规划/实现漂移审计
+
+### Batch 2（主代理收敛后）
+
+- 形成单一执行板
+- 给出实现优先级
+- 选择先落地的 1~2 条主线
+
+---
+
+## 七、当前建议
+
+**不要四条线一起直接开工实现。**
+最优顺序是：
+
+1. 先让 4 个子智能体并行做“审计与设计输入”
+2. 我汇总成单一执行板
+3. 你确认优先级后，再进入实现
+
+这样能避免：
+
+- 规则和专业数据口径冲突
+- CLI 做出来后又被架构推翻
+- 产品规划和实现再次漂移
--- a/reports/LOCAL_BROWSER_VALIDATION_2026-06-15.md
+++ b/reports/LOCAL_BROWSER_VALIDATION_2026-06-15.md
@@ -0,0 +1,171 @@
+# 本地浏览器端到端与 UI/可访问性验证补充（2026-06-15）
+
+## 1. 背景
+
+在前一轮整改与 `dev-verify` 通过后，又补做了一轮**本地真实浏览器验证**，目标是确认：
+
+1. 不是只有后端单测 / TestClient 通过
+2. 关键前台页面在真实浏览器中可访问、可导航
+3. 新增的隐私 / 删除入口不是“接口已加，页面不可用”
+4. 至少抽检基础 UI 一致性与表单可访问性
+
+本次验证使用本机启动的 FastAPI 服务，而不是只依赖 TestClient。
+
+## 2. 验证环境
+
+本地服务启动方式：
+
+```bash
+python -m admin.app --host 127.0.0.1 --port 8010
+```
+
+使用的环境变量包括：
+
+- `GAOKAO_ENV=dev`
+- 独立临时 SQLite
+- `GAOKAO_PAYMENT_PROVIDER=alipay_sim`
+- 本地 `payment_base_url=http://127.0.0.1:8010`
+- merchant/app/payment 相关配置使用本地测试值
+
+浏览器验证工具：
+
+- headless Chromium（通过 browser tool）
+
+## 3. 已验证通过的页面与链路
+
+### 3.1 Landing / Footer / 公共说明页
+
+已确认：
+
+- `/` 可打开
+- `/pricing` 可打开
+- `/privacy` 可打开
+- `/service-terms` 可打开
+- `/deletion-policy` 可打开
+
+已观察到：
+
+- landing 页标题与 H1 正常
+- footer 中存在：
+  - 隐私政策
+  - 服务说明与免责声明
+  - 删除申请 / 数据删除说明
+- 键盘 Tab 焦点顺序至少覆盖首屏主操作：
+  - 查看服务套餐
+  - 进入运营后台
+
+### 3.2 公开下单与支付页
+
+已确认：
+
+- `/checkout/standard` 可打开
+- 表单字段可填写
+- 点击“创建订单并去支付”可跳转到 `/pay/alipay-sim/...`
+- 支付页标题为“支付宝模拟收银台”
+- 支付按钮可见且可操作
+
+### 3.3 支付完成后的 Portal 状态页
+
+已确认：
+
+- 模拟支付成功后成功跳回 `/portal/{token}/status`
+- 浏览器中观察到状态页显示：
+  - 处理中
+  - 当前订单状态：`serving`
+  - 支付状态：`paid`
+  - 资料状态：处理中
+- 资料摘要区域已展示：
+  - 分数
+  - 位次
+  - 选科
+  - 兴趣方向
+
+### 3.4 Portal 删除申请页
+
+已确认：
+
+- `/portal/{token}/deletion-request` 可打开
+- 页面包含：
+  - 申请人姓名
+  - 联系方式
+  - 删除范围
+  - 申请原因
+  - 监护人确认复选框
+- 页面 footer 保留隐私 / 服务说明 / 删除说明链接
+
+## 4. 可访问性与基础语义抽检结果
+
+已抽检页面：
+
+- landing
+- checkout
+- deletion-request
+
+结论：
+
+- `lang="zh-CN"` 存在
+- 每页均有单个主 `h1`
+- checkout / deletion-request 的表单控件均有 label 绑定
+- 抽检范围内未发现“输入控件无 label”问题
+- footer 链接文本明确，不是空链接或仅图标链接
+
+这说明：
+
+- 本轮新增的前台入口不是只对接口存在
+- 最基本的可访问性语义不是缺失状态
+
+## 5. 新发现的问题
+
+### 5.1 Portal 资料向导 Step 5 在真实浏览器中的提交流程不稳定
+
+现象：
+
+- 在真实浏览器里，按页面向导从 Step 1 点击到 Step 5 时
+- 页面确认摘要里仍出现：
+  - `candidate_interests: null`
+  - `privacy_accepted: false`
+  - `service_terms_accepted: false`
+  - `guardian_confirmed: false`
+- 直接点击“提交资料”后，没有稳定观察到前端自动跳转或结果反馈
+- 但通过同页面直接对 `/portal/{token}/info` 发 POST 请求，后端返回：
+
+```json
+{
+  "intake_status": "submitted",
+  "stage": "processing",
+  "order_id": "..."
+}
+```
+
+这说明：
+
+- **后端提交接口是通的**
+- **前端 Step 向导状态汇总 / 提交交互仍有真实浏览器层面的不稳定问题**
+
+### 5.2 UI 一致性仍偏 MVP
+
+观察到的问题：
+
+- landing 与 portal/status 的视觉风格差异较大
+- 页面整体仍偏“功能先行”，没有统一设计系统
+- portal status 信息密度较高，但层次与导航反馈一般
+- 删除申请页样式可用，但仍是后端内联 HTML 的最低可用实现
+
+这不构成功能阻塞，但说明：
+
+- **前端还没有达到成体系的产品级 UI 一致性**
+
+## 6. 结论修正
+
+前面的“本轮完成项摘要”需要补上一条更准确的结论：
+
+> 本轮已经完成仓库内的工程整改，并补做了本地真实浏览器验证；公开页面、支付沙箱页、portal 状态页、删除申请页都能真实打开和访问，基础 a11y 语义也成立。但 portal 资料向导 Step 5 的前端确认/提交交互在真实浏览器中仍不稳定，因此不能把当前前端链路表述为“已做完完整浏览器端到端验收”。
+
+## 7. 建议下一步
+
+优先级最高的前端后续项：
+
+1. 修 Portal 资料向导 Step 5 的真实浏览器提交流程
+2. 为公开链路补一条真正的浏览器 E2E 自动化（而不是仅 TestClient）
+3. 补最小 UI 一致性整改：landing / pricing / portal 统一 spacing、按钮、卡片层级
+4. 补更系统的 a11y 检查：焦点样式、颜色对比、错误提示、表单校验反馈
--- a/tests/test_requirements_rules_phase1.py
+++ b/tests/test_requirements_rules_phase1.py
@@ -0,0 +1,16 @@
+from __future__ import annotations
+
+from pathlib import Path
+
+
+REPO_ROOT = Path(__file__).resolve().parents[1]
+REQUIREMENTS_ADMIN = REPO_ROOT / "requirements-admin.txt"
+REQUIREMENTS_DEV = REPO_ROOT / "requirements-dev.txt"
+
+
+def test_yaml_runtime_dependency_is_declared_for_rules_truth_phase() -> None:
+    admin = REQUIREMENTS_ADMIN.read_text(encoding="utf-8")
+    dev = REQUIREMENTS_DEV.read_text(encoding="utf-8")
+    combined = admin + "\n" + dev
+
+    assert "PyYAML" in combined or "pyyaml" in combined