aisee:srs

aisee:srs — OpenSpec 需求规格说明书

通过结构化对话挖掘软件需求，然后生成可交给 aisee:change-plan 使用，并可为后续 aisee:change-author 提供需求输入的需求规格说明书（SRS）。

生成或改写 planning doc 时，frontmatter 字段合同统一遵循 plugins/aisee-plugin/references/planning-doc-frontmatter.md；它只服务索引和追踪，不替代 OpenSpec 事实源。

当前主流程面向软件 / App / 后端 / CLI / Job 等场景。硬件、嵌入式和固件需求后续按专用流程整理；如果本次软件需求依赖设备，只记录软件可见的设备能力、状态、告警、操作环境、安全可靠性和验收约束，不展开硬件架构、固件设计或制造细节。

输入

用户提供以下任意一种输入：

• 原始需求或功能想法（自由文本）
• 模糊的产品目标或问题描述
• 已有但尚未成型的需求草稿
• 现有系统二次开发、改造、替换或兼容需求

可选参数：

• --lang zh|en — 输出语言，默认 zh
• --depth shallow|standard|deep — 对话深度，默认 standard
• --baseline-aware — 基于现有 OpenSpec baseline specs、active changes 和既有需求文档识别新增 / 修改 / 移除 / 兼容行为。若项目中存在 openspec/specs/、openspec/changes/、aisee/docs/spec-migration/ 或历史 SRS，默认自动启用。

输出边界

aisee:srs 产出的是 规划级需求契约：它要足够详细，能支撑后续 change 边界规划和 change authoring；但它不是实现级接口设计、数据库设计、技术方案、逐页设计稿或设计系统。

必须覆盖：

• 目标用户、业务目标、范围和非目标
• 业务对象、业务状态、状态流转、业务流程和用户任务流
• 功能需求、非功能需求、业务规则、权限规则和数据范围
• 异常、失败、兼容、验收方向和待确认事项
• 交付形态信号，例如 App、小程序、Web 管理后台、桌面 GUI、后端服务、CLI、导入导出、通知、异步处理
• 现有项目二开时的新增 / 修改 / 移除 / 兼容行为，以及受影响 baseline 引用
• 后续是否建议进入 aisee:change-plan，以及仍待确认的关键问题

可以记录但不得展开设计：

• 页面相关的功能行为：必须采集或展示的数据字段、列表列、筛选条件、空状态、行操作、入口和完成后去向
• 外部系统交互的业务目的、触发条件、成功/失败处理和数据含义
• 设备参与的软件需求中，用户或系统可观察的设备能力、状态、告警、输入输出信号业务含义、安全可靠性和验收约束

禁止输出：

• 视觉布局、间距、颜色、字体、图标、组件库选择或逐页线框图
• API endpoint、数据库表字段、ORM、代码文件结构或迁移实现
• 具体技术栈选择、服务拆分、队列方案、任务拆解或代码实现计划
• 引脚表、寄存器表、RTOS 任务设计、驱动结构、BOM、PCB 布局、固件实现步骤或制造工艺
• 未由用户或现有 baseline 确认的新增需求

如果用户需要接口、数据、任务或测试契约，应在 change artifacts 阶段处理，而不是在 SRS 中展开实现级设计。

ID 规则

aisee:srs 负责需求侧上游 ID：

• FR：功能需求
• NFR：非功能需求
• RULE：业务规则
• FLOW：业务流程或用户任务流，只有在 SRS 阶段已经明确时分配
• STATE：业务状态或用户可感知状态，只有在 SRS 阶段已经明确时分配

正式写法只使用文档内编号，例如 FR-001、NFR-001、RULE-001、FLOW-001、STATE-001。跨文档来源交给后续 source-map.md 记录。不要为了满足模板创建无用编号、无用来源引用或 <!-- aisee:id ... -->。

如果当前轮次还不能确定最终编号，可以使用 FR-NEW-001 一类临时占位符，并显式标注 [NUMBERING-FINALIZATION-REQUIRED]。SRS 不负责 API / DATA / TASK / TEST；这些由 change artifacts 承接。

Phase 0 — 读取项目上下文