feature-listlisted

# Feature List · 功能清单 ## 目的与边界 把已确认的用户故事（ST-XXX）分解为产品必须交付的完整功能清单（FEA-XXX）——这是下游所有独立子 skill 消费的唯一功能总账。每个 FEA-XXX 必须追溯 ≥1 个已确认的 ST-XXX，必须有清晰、互不重叠的功能边界，必须标注 P0/P1 优先级。 **Do not** 设计功能流程（→ `functional-flow`）、交互规则（→ `interaction-rules`）、页面骨架或原型（→ `page-design`）、领域业务规则（→ `business-rules`）、字段校验（→ `validation-rules`）、状态机（→ `state-machine`）、异常与失败处理（→ `exception-handling`）、验收依据（→ `acceptance-criteria`）。功能清单只命名「做什么（WHAT）」；行为细节由其他子 skill 定义。 ## 输入与输出 **Input**: 已确认的 `user-stories.md` 故事（ST-XXX）与范围基线，以及影响范围的已确认 `background-goal.md` 事实与目标。**Output**: 独立的 `feature-list.md`，使用 `src/templates/resolver.py feature-list.md` 解析出的模板。 分析前加载 `references/thinking-framework.md`（引用 `src/framework/thinking-core.md` §1 必用透镜 + §2 检查透镜）。草拟前加载 `references/output-contract.md`。送审前加载 `references/audit-checklist.md` 与 `references/reviewer-checklist.md`。评审前运行 `scripts/validate_artifact.py <artifact> --json`。 ## 思考提示（按阶段） ### 1. Preflight - "所有上游故事都已确认吗？范围基线（in/out）是什么？" - 枚举已确认的 ST-XXX、角色与生命周期阶段；发现缺失归属或矛盾故事时，先标 `CONFLICT` 再写任何 FEA。 - **若不存在任何已确认故事**，返回 routing receipt 并 STOP——不要进入 Intake。 ### 2. Intake - "每个已确认故事实际要求系统做什么——而不是我认为它意味着什么？" - 把每个已确认故事映射到 ≥1 个 FEA；有故事无功能 → 覆盖缺口，有功能无故事 → 范围越权。 - 每个候选都保留 `ST-XXX` 链接；不静默合并不同故事的诉求为一个功能。 ### 3. Think (apply thinking-core.md §1 mandatory lenses) - **First Principles**: "功能必须产出什么可观察的结果？哪些功能其实是伪装成需求的假设？" - **Systems Thinking**: "哪些功能相互依赖？每个功能需要什么数据或上游能力？" - **Role Perspective**: "对每个角色——哪些功能服务他们，砍掉某功能他们会失去什么？" - **Constraint Analysis**: "哪些硬约束（范围、法务、平台、时间线）限定了功能集合