acceptance-criterialisted

# Acceptance Criteria 验收依据 ## 目的与边界 以开发、QA 与业务都能认可���形式，为每个功能定义"完成"意味着什么：Given/When/Then 形式、原子、可独立测试的 `AC-XXX`，带量化阈值或可观察结果。每条 AC 是产品与验证之间的契约——不是测试用例，不是接口描述。 **不得** 编写可执行的测试用例 / 断言脚本（→ QA）、领域业务规则（→ `business-rules`）、字段校验规则（→ `validation-rules`）、UI 呈现或交互（→ `interaction-rules`）、状态转移（→ `state-machine`）、失败恢复流程（→ `exception-handling`），或实现细节（API、schema、框架）。 ## 输入与输出 输入：来自所有上游独立 work_item 的已确认 `FEA-XXX` 区块（含 BR/VL/ST/EX），外加来自 `background-goal.md` 的 Stage 1 目标 `G-XXX` 以提供量化阈值。输出：独立的 `acceptance-criteria.md`，使用 `src/templates/resolver.py acceptance-criteria.md` 解析出的模板。 分析前加载 `references/thinking-framework.md`（其引用 `src/framework/thinking-core.md` §1 强制透镜）。Draft 前加载 `references/output-contract.md`。交接前加载 `references/audit-checklist.md` 与 `references/reviewer-checklist.md`。Review 前运行 `scripts/validate_artifact.py <artifact> --json`。当成功定义或阈值稀疏时加载 `references/question-patterns.md`（主动向业务方确认成功标准）。 ## 思考提示（按阶段） ### 1. Preflight - "范围内有哪些 FEA-XXX？所有上游规则 work_item（BR/VL/ST/EX）都确认了吗？哪些 G-XXX 目标带可量化阈值？" - **若某 P0 功能没有已确认的 BR/VL/ST/EX**，发出警告，不要在缺失上游之上编造 AC。 - 评估成熟度：L0（无成功定义）→ L1（单一稀疏提及）→ L2（部分阈值）→ L3（充分明确）→ L4（上游已确认）。 ### 2. Intake - "该功能已确认的成功定义是什么——来自 BR/VL/ST/EX，而非我的假设？" - 保留 `FEA-XXX` → `G-XXX` / `ST-XXX` 链接。把 AC 隐含行为与上游规则的矛盾标为 `CONFLICT`。 ### 3. Think (apply thinking-core.md §1 mandatory lenses + domain lenses) - **First Principles**: "什么可观察结果能证明该功能可用？用户/操作者会看到什么？" - **Testability**: "给定一组输入，任何人不看实现能否唯一判定通过或失败？" - **Reverse Validation**: "从目标结果（G-XXX）反向推导，什么必须为真且可测量？" - **Adversarial*