business-ruleslisted

# Business Rules · 业务规则 ## 目的与边界 确立系统在领域层必须计算、强制与决定什么——独立于任何 UI 如何呈现。每条 BR 必须可追溯到一个已确认的 `ST-XXX` 或 `FEA-XXX`，且必须可执行：开发者能把它转成代码而无需追问。 **不得** 描述 UI 行为（→ `interaction-rules` `IX-XXX`）、编写字段格式/长度/必填检查（→ `validation-rules` `VL-XXX`）、建模状态迁移（→ `state-machine`）、定义失败/恢复路径（→ `exception-handling`）或编写验收测试（→ `acceptance-criteria` `AC-XXX`）。 ## 输入与输出 **输入**: 已确认的 `functional-flow.md`（FEA-XXX + 流程步骤）与已确认的上游故事（`user-stories.md` 的 ST-XXX），以及已确认的 `feature-list.md` 功能清单。**输出**: 独立的 `business-rules.md`，使用 `src/templates/resolver.py business-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/ears-syntax.md`（EARS 句式，书写规则时必须参照）。 ## 思考提示（按阶段） ### 1. Preflight - "我将要为其建规则的功能，其所有上游 FEA / ST 都已确认吗？" - 枚举 P0 功能及其上游故事链接。写任何规则前，将缺失归属或矛盾的流程标为 `CONFLICT`。 - **若不存在任何已确认的上游功能**，返回 routing receipt 并 STOP——不要进入 Intake。 ### 2. Intake - "已确认的故事/流程实际要求系统计算或强制什么——而不是我认为它意味着什么？" - 先逐字提取候选规则再解读。按 `src/framework/contracts.md` 为每个候选标记知识状态：`FACT` / `DECISION` / `ASSUMPTION` / `AI_INFERENCE` / `UNKNOWN` / `CONFLICT`。 - 在每个候选上保留 `ST-XXX` / `FEA-XXX` 来源。不把不同来源的声明合并为一条规则。 ### 3. Think (apply thinking-core.md §1 mandatory lenses) - **First Principles**: "系统必须保证什么可观察的业务结果？哪些约束伪装成了假设？" - **Systems Thinking**: "这条规则与哪些其他规则、状态、字段或功能交互？什么已经生效且不能被破坏？" - **Role Perspect