validation-ruleslisted

# Validation Rules · 系统校验 ## 目的与边界 在字段层面精确定义系统接受与拒绝什么数据，以及校验失败时用户看到什么。每条 VL 必须可判定（开发者能实现该检查、测试者能构造通过/失败用例），且必须携带面向用户的中文错误提示。 **不得** 定义业务计算或领域策略（→ `business-rules` `BR-XXX`）、描述错误如何展示（→ `interaction-rules` `IX-XXX`）、建模状态变化（→ `state-machine`）或编写验收测试（→ `acceptance-criteria` `AC-XXX`）。 ## 输入与输出 **输入**: 已确认的 `business-rules.md`（`BR-XXX`）、已确认的 `page-design.md` 字段定义（F-XXX）与已确认的 `feature-list.md` 功能清单。**输出**: 独立的 `validation-rules.md`，使用 `src/templates/resolver.py validation-rules.md` 解析出的模板。 分析前加载 `references/thinking-framework.md`（其引用 `src/framework/thinking-core.md` §1 强制透镜 + §2 检查透镜）。Draft 前加载 `references/output-contract.md`。交接前加载 `references/audit-checklist.md` 与 `references/reviewer-checklist.md`。Review 前运行 `scripts/validate_artifact.py <artifact> --json`。始终加载 `references/nfr-catalog.md`（NFR 分类，校验规则须参照此分类法）。 ## 思考提示（按阶段） ### 1. Preflight - "§业务规则 与字段定义都已确认吗？哪些 FEA-XXX 区块有用户输入？" - 枚举每个带用户输入字段的功能。写 VL 前，把任何输入未充分定义的功能标出来。 - **若不存在任何已确认的字段定义**，返回 routing receipt 并 STOP——不要进入 Intake。 ### 2. Intake - "已确认的页面/表单实际定义的输入面是什么——而不是我认为表单有什么？" - 列出每条输入路径：表单字段、搜索/筛选参数、上传文件、查询参数、批量粘贴数据，以及隐藏输入（URL 参数、用户可改写的默认值）。 - 按 `src/framework/contracts.md` 为每个 VL 候选标记知识状态：`FACT` / `DECISION` / `AI_INFERENCE` / `UNKNOWN`。在每个候选上保留 BR-XXX / FEA-XXX 来源。 ### 3. Think (apply thinking-core.md §1 mandatory lenses) - **First Principles**: "为安全接受该输入，系统真正需要的最小检查集合是什么？哪些检查是发明出来的装饰？" - **Systems Thinking**: "该字段的有效性影响哪些其他字段、BR 规则或下游步骤？" - **Role Perspective**: "谁输入这个数据？真实用户会误输什么？恶意用户会尝试什么？" - **Constraint Ana