design-function

name	design-function
description	从场景出发，分析业务意图对既有功能的影响，生成变更的功能，并追加到 IMPL_DESIGN 末尾。仅被显式调用，不自动触发。
user-invokable	false

design-function

使用时机

• 仅被 design skill 显式调用

功能定义

• 功能是支撑场景达成目标所需的业务能力，应从外部可观测行为的视角描述系统“能够提供什么能力”。
• 功能必须可落地: 能够映射为「输入/输出 + 触发条件/前置条件 + 主要步骤 + 失败处理与补偿策略」。在后续设计阶段再明确由哪些组件/模块分别承担职责。
• 不得将“实现细节/代码结构”当作功能；不得将“接口清单”当作功能本身。

注意事项:

1. 将场景中的关键验收点映射到功能的外部可观测行为，确保每条功能都能回答:

• 触发条件/前置条件是什么
• 输入/输出是什么
• 主路径步骤是什么
• 关键失败处理与补偿策略是什么

2. 对识别出的功能集合做一致性校验，避免后续重复建设或边界漂移:

• 去重与合并: 不同场景下语义等价的功能应复用同一条功能（必要时通过“适用范围/约束条件”表达差异），避免同义重复。
• 粒度校准: 避免抽象过度（难以验证、无法落到可测试行为）或细节过度（陷入实现层设计/代码结构）；必要时对功能进行拆分或收敛，但保持其对外可观测性。
• 命名与术语对齐: 功能名称与描述使用 context.md 中已对齐的术语，避免同一概念多种叫法。

指令

步骤1: 明确输入与上下文

• 场景: 读取 FEATURE_DIR/spec.md 中的「场景」章节，明确本次需要支撑的业务目标与验收标准。
• 上下文文件: 优先读取 FEATURE_DIR/context.md，参考其中的:
  • 「相关功能文档」章节，作为既有功能的主要参考来源
  • 架构分析、可复用模式、术语对齐、约束和假设
  • 若 context_mode = evidence_first，优先消费 on_demand.scope、on_demand.traceability、on_demand.risks、on_demand.evidence_gaps

步骤2: 分析既有功能的变更

基于步骤1输入与上下文，按「功能定义」识别并产出本次变更涉及的全部功能条目（含INSERT/MODIFY/DELETE/REFER），作为后续步骤的范围基线。

动作类型定义:

• MODIFY: 业务意图要求对既有功能的输入/输出、约束条件、步骤、失败处理、适用范围等进行调整或细化。
• INSERT:
  • 理解既有功能，业务意图无法合理归属到任何既有功能条目，或现有功能的职责边界无法承载新增能力且保持可验证性。
  • 不存在既有功能时，则新增所需功能。
• DELETE: 业务意图明确要求移除既有功能，且删除具有明确业务必要性、风险可控（必须给出充分、可追溯的理由与影响说明）。
• REFER: 既有功能已充分覆盖当前业务意图，无需修改内容，但需建立引用关系以支持后续影响分析与可追溯性。

on-demand 功能消费规则（仅 evidence_first 模式）：

• 先从 on_demand.scope.direct_functions 和 on_demand.scope.indirect_functions 建立功能基线（白名单）。
• 通过 on_demand.traceability 将需求/场景映射到功能条目，优先判定 MODIFY/REFER，减少无依据 INSERT。
• 对每个功能条目，优先引用 ${DOC_DIR}/on-demand/functions/*.md 中可定位证据（入口、主流程、波及点、风险）。
• 未进入 scope 且无证据链支撑的功能，不得纳入主设计范围（避免 scope creep）。
• on_demand.risks / on_demand.evidence_gaps 要体现在功能的失败处理、补偿策略或假设说明中。

兼容规则（default 模式）：

• 若 context_mode = default 或 on_demand 字段缺失，沿用原有逻辑，不阻塞功能设计。

步骤3: 按照以下模板生成「功能」章节内容

## 功能

### [动作类型: INSERT/MODIFY/DELETE/REFER] - [功能ID] - [功能名称]

**来源场景**: [场景ID] - [场景名称]

变更原因: [分析业务意图对存量功能的影响；REFER 填写为无变更]

**功能描述**: [从对应场景的验收场景中提取，描述该功能需要实现的具体能力]

[功能具体内容]

[按照上述格式继续描述其他功能...]

MODIFY

1. 从既有功能文档中准确提取对应条目的完整内容，填充到上述模板占位符。
2. 基于 业务意图 分析本次变更的动机与影响范围，明确需要调整的具体内容。对新增或修改的部分使用 **加粗** 标记，对拟删除的内容使用 ~~删除线~~ 标记，以便后续评审与追踪。

INSERT

1. 生成功能ID:

• 读取 DOC_DIR/specs/functions/0.function_list.md，提取已存在的 FUNC-XXX 最大ID，取 最大ID + 1 作为新功能的ID。
• 不存在 0.function_list.md 时，功能ID从 FUNC-001 开始。

2. 依据 .infra/metamodel/5.function-template.md 中的规范生成[功能具体内容]:
   • 参考 DOC_DIR/specs/functions/ 下既有文档的组织方式与粒度，使新功能在抽象层级上与既有功能保持一致，避免过于宽泛（难以验证）或过于聚焦实现细节。
3. 使用步骤 3 中的模板，将生成的功能内容整理为「功能」章节条目。

DELETE

1. 从既有功能文档中提取拟删除条目的完整内容，填充到上述模板占位符。
2. 以审慎态度给出充分且清晰的变更原因，说明删除该功能在业务、合规与技术层面的必要性。

REFER

从既有功能文档中提取对应条目的完整内容填入模板，变更原因 统一填写为 无变更，仅建立引用关系以支持后续波及分析。

步骤4: 将生成的「功能」章节内容追加到 IMPL_DESIGN 末尾

DoD（完成校验）

• 场景对齐: 每条功能均明确关联至少一个来源场景（SCN-XXX），且能够支撑该场景的主路径验收与关键异常/边界。
• 外部可观测: 功能描述以系统对外提供的能力与行为为中心，可被测试验证；不夹带实现细节、代码结构或纯接口罗列。
• 结构可落地: 功能内容包含输入/输出、触发或前置条件、主要步骤，以及失败处理与补偿策略，便于后续架构与接口设计落地。
• 变更规范: 功能变更按 INSERT/MODIFY/DELETE/REFER 规则完成，且加粗/删除线标记准确一致；DELETE 给出充分且可追溯的理由。
• ID一致: 新增功能的 FUNC-XXX ID基于当前最大值顺序递增，无冲突或缺号。