commit 5cb99eb8e616f47e62e4ca9ccfb015029fc3cf40
Author: wdh-home <243823965@qq.com>
Date:   Thu May 14 12:31:10 2026 +0800

    init

diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..5b7df71
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,28 @@
+# OS and editor files
+.DS_Store
+Thumbs.db
+*.swp
+*.swo
+.vscode/
+.idea/
+
+# Runtime and tool caches
+__pycache__/
+*.py[cod]
+.pytest_cache/
+.mypy_cache/
+.ruff_cache/
+node_modules/
+dist/
+build/
+
+# Local secrets and environment files
+.env
+.env.*
+!.env.example
+
+# Logs and temporary files
+*.log
+tmp/
+temp/
+*.tmp
diff --git a/SKILL.md b/SKILL.md
new file mode 100644
index 0000000..6a0d755
--- /dev/null
+++ b/SKILL.md
@@ -0,0 +1,126 @@
+---
+name: ks-prd-draft
+description: Use when 用户输入 /ks-prd-draft，或需要围绕任意项目的 PRD、需求草案、产品需求或业务规则文档进行多轮讨论、创建、更新、细化、检查、校验或判断能否进入下一阶段。只处理需求文档、完整性和业务闭环，不修改代码、配置、数据库、API 或下游实现文档。
+---
+
+# KS PRD Draft
+
+## 核心定位
+
+`ks` 是开发流程系列前缀，`prd-draft` 是需求草案阶段。本 skill 适用于任何工程项目，不绑定特定技术栈、业务系统、目录结构或下游阶段名称。
+
+本 skill 的主要职责是在长期对话中维护一个清晰的需求文档锚点，把用户的业务表达整理成完整、闭环、符合主流做法、符合正规流程、符合常理的需求草案。它不是代码实现、数据建模、API 设计或技术方案输出器。
+
+进入本 skill 后，持续维护当前需求主题和需求文档锚点。后续用户只说“继续”“补充”“修改”“检查”“复核”“下一步”等短指令时，默认作用于当前锚点，除非用户明确切换主题或路径。
+
+## 必读顺序
+
+1. 先读取项目级说明，例如 `AGENTS.md`、README、docs 索引、项目规范或用户指定的文档入口，识别当前项目的需求文档位置、命名风格和流程约定。
+2. 创建、编辑或检查任何需求草案前，读取 `references/prd-draft-document-spec.md`。
+3. 创建新文档、重建结构或需要示例写法时，读取 `references/prd-draft-format-template.md`。
+4. 如果需求涉及既有业务对象、术语、权限、流程、数据、页面、接口、集成或模块复用，只读检查项目中已有需求文档、规格文档、设计文档、代码注释或索引；这些内容只作为事实来源，不作为本阶段可写目标。
+
+## 触发场景
+
+- `/ks-prd-draft <需求文档路径> 增加/修改/检查 xxx 需求`
+- `/ks-prd-draft 增加/修改/检查 xxx 需求`
+- 用户要求创建、更新、分析、细化或复核项目中的 PRD、需求草案、产品需求、业务规则文档。
+- 用户围绕同一个需求主题多轮讨论，继续补充、确认、推翻或修改需求。
+- 用户说“检查”“校验”“复核”“看看有没有问题”“能不能下一步”“是否可以进入下一阶段”等短指令。
+
+## 会话锚点
+
+- 如果用户明确提供了一个需求文档路径，将该文件作为唯一可写锚点。
+- 如果当前会话已经建立需求文档路径或需求主题，后续短指令默认继续使用该锚点。
+- 如果用户未提供路径且会话没有锚点，按项目说明和已有文档目录匹配主题；常见候选可以包括 `docs/`、`specs/`、`requirements/`、`prd/`、`.ai-specs/` 或项目自定义目录，但不要写死任何一种。
+- 如果只有一个强匹配候选文件，说明所选文件和匹配原因，然后继续。
+- 如果存在多个候选文件，停止并请用户确认目标文件路径。
+- 未经用户明确确认，不切换主题或文件锚点。
+
+## 工作模式
+
+### 新建需求
+
+- 当用户要创建新需求，且当前上下文和项目既有需求文档中没有对应草案时，优先沿用项目已有需求文档目录和命名风格。
+- 如果项目没有可判断的需求文档位置或命名规则，先询问用户目标路径；不要擅自发明项目规范。
+- 文件名优先沿用项目既有命名风格；没有明显风格且用户允许创建时，使用可读的短横线英文主题名，例如 `book-comment.md`。
+- 新文档正文优先沿用项目已有模板；项目没有模板时，使用 `prd-draft-format-template.md` 的通用骨架。
+
+### 更新需求
+
+- 收集、规范化、对齐用户需求，并把多轮对话中的已确认结论合并进当前需求草案。
+- 用户用实现语言表达需求时，先转成业务需求语言：表、字段、model、结构体归一为业务数据对象和数据项；API、Service、任务、页面组件归一为业务能力、流程、交互或集成需求。
+- 对简单缺失细节，写入草案并明确标记 `需补` 或 `待确认`，不要因为非阻塞细节缺失而停止整理。
+- 用户只是讨论备选方案时，不要把未确认选项写成确定结论。
+- 发现需求与既有事实冲突、逻辑不闭环、明显不合常理、存在业务 bug 风险或会引入不必要复杂度时，先指出问题并要求确认；如果问题已经足以构成修正讨论，不只说明问题本身，还要同步整理 3 个可执行方案，并明确给出 AI 推荐的最优方案和推荐理由。
+
+### 检查需求
+
+当用户说“检查”“校验”“复核”“看看有没有问题”“能不能下一步”等指令时，进入检查模式。
+
+- 默认只检查并反馈，不直接修改文档；只有用户明确要求“修复”“按方案改”“直接更新文档”时才写入。
+- 检查对象是当前锚定的需求草案，并结合本轮会话中用户刚确认但尚未落盘的信息。
+- 按 `prd-draft-document-spec.md` 检查完整性、逻辑闭环、业务合理性、既有资产复用、未确认事项和越界实现细节。
+- 检查是否还有阻塞进入下一阶段的 `需补`、`待确认`、事实冲突或未闭环事项。
+- 检查输出时，问题定位和方案建议必须成对出现；除非用户明确要求只列问题，否则不要只报告问题而不给修正路径。
+
+检查输出：
+
+- 如果有问题，按“阻塞问题”“建议修正”“可后续确认”分组。对“阻塞问题”和“建议修正”中的每一个真实问题，必须说明影响，并给出恰好 3 个可执行解决方案供用户选择；然后由 AI 明确选出 1 个最优方案，并说明推荐理由、适用前提和主要取舍。
+- “可后续确认”如果本身构成明确的决策问题，也按相同格式给出 3 个方案和 AI 推荐；如果只是提醒后续补齐的信息，可只说明待确认点、影响和最晚确认时点。
+- 如果没有明显阻塞问题，回复“需求草案没有明显阻塞问题，可以进入下一阶段”，并说明下一阶段应按项目既有流程执行，不输出固定命令或假定下游 skill 名称。
+
+## 既有资产优先
+
+- 用户说“需要/增加/修改 xxx 功能”时，不要默认推导为“新增表”“新增 API”“新增页面”或“创建新模块”。先查找既有业务对象、流程、页面、配置、文档、术语和模块是否已经承载该需求。
+- 如果找到既有承载，需求草案应写明复用或调整既有承载，只补充本需求需要新增或变更的业务信息。
+- 如果存在候选既有承载但无法确认是否应复用，写明 `待确认：是否复用 <候选承载>`。
+- 只有在既有资产查找后没有合理承载，或用户明确确认当前不存在可复用承载时，才把需求写成创建新的业务对象、流程、页面或集成能力。
+- 如果用户描述与既有文档、实现、术语或项目规范冲突，先指出冲突并要求确认，不把冲突内容写成确定结论。
+
+## 质量口径
+
+需求草案至少要能回答：
+
+- 目标是否明确：要解决什么业务问题，成功状态是什么。
+- 范围是否清晰：范围内、范围外、受影响对象是否明确。
+- 参与方是否完整：用户、管理员、系统、外部方或后台任务是否明确。
+- 链路是否闭环：触发条件、输入、处理规则、输出、状态变化、异常结果是否能连起来。
+- 数据是否完整：需要维护、读取、展示、统计或传递的数据是否有业务含义、来源、生成规则和使用场景。
+- 权限是否合理：谁能看、谁能改、谁能触发，越权和不可见场景是否说明。
+- 边界是否充分：空数据、重复提交、失败、撤销、历史数据、并发或生命周期结束后的处理是否合理。
+- 常理是否成立：是否符合主流产品习惯、正规业务流程、行业常识和最小必要复杂度。
+
+## 边界
+
+允许：
+
+- 只写入已锚定或按“新建需求”规则创建的需求草案文档。
+- 只读检查项目内已有文档和代码来获取事实。
+- 识别缺失的业务闭环、数据项、权限、状态、异常、边界和未确认事项。
+- 对未解决事项标记为 `需补` 或 `待确认`。
+- 对与项目事实、既有文档或常理冲突的需求提出质疑。
+
+禁止：
+
+- 不修改代码、测试、配置、数据库迁移、构建脚本、路由、服务、页面、样式、部署文件或生成物。
+- 不写入数据模型、API 文档、技术设计、实现计划、任务拆解等下游文档，除非用户明确切换到对应阶段。
+- 不把 API path、HTTP method、request/response schema、SQL DDL、field type、index、unique constraint、migration script、class、struct、service、router、component 或文件结构设计写入 PRD 草案。
+- 不为了满足模板而创建空分区、伪造业务对象、伪造数据项、编造状态值或把未确认事项写成确定结论。
+- 不在未检查既有资产的情况下，把用户功能需求写成新建模块、新增数据表、新增接口或新增页面。
+
+## 交互与完成
+
+- 优先使用简洁中文对话；项目中已有英文术语、代码名、API、Service、Model、PRD 等保留原写法。
+- 多轮讨论时，先确认当前锚点；锚点明确后不要反复询问路径。
+- 只有在需求无法形成逻辑闭环、候选文件有歧义、自动创建文件名不可靠或项目没有可判断的需求文档位置时，才提出聚焦问题。
+- 完成后，总结需求草案路径、已处理内容和剩余 `需补` / `待确认` 项。
+
+示例：
+
+```text
+/ks-prd-draft docs/prd/book-comment.md 增加书籍评论功能
+/ks-prd-draft 修改书籍评论审核规则
+/ks-prd-draft 增加书籍评论功能
+检查
+```
diff --git a/agents/openai.yaml b/agents/openai.yaml
new file mode 100644
index 0000000..6bf135c
--- /dev/null
+++ b/agents/openai.yaml
@@ -0,0 +1,4 @@
+interface:
+  display_name: "KS PRD Draft"
+  short_description: "Project-agnostic PRD draft guardrails"
+  default_prompt: "Use $ks-prd-draft with /ks-prd-draft 创建、修改或检查项目需求草案。"
diff --git a/references/prd-draft-document-spec.md b/references/prd-draft-document-spec.md
new file mode 100644
index 0000000..998032a
--- /dev/null
+++ b/references/prd-draft-document-spec.md
@@ -0,0 +1,97 @@
+# PRD 草案文档规范
+
+## 适用范围
+
+- 创建、修改或检查任意项目的 PRD、需求草案、产品需求、业务规则文档时遵守本文件。
+- 本文件是通用兜底规范；如果项目已有更具体的需求模板、命名规则或文档结构，优先沿用项目规范。
+- 本文件只约束需求草案阶段，不替代数据模型、API 设计、技术方案、任务拆解或代码实现规范。
+- 需求草案只整理业务目标、规则、数据、边界和闭环，不设计下游实现。
+
+## 阶段
+
+- `需求草案阶段`：收集和归并已确认需求；未确认项显式标注 `需补` 或 `待确认`；不要求同步修改代码和下游文档。
+- `可进入下一阶段`：需求草案已稳定，阻塞问题已消除，可作为后续数据、API、设计或实现工作的输入。
+- `归档阶段`：需求已经确认并沉淀；新增需求或未确认变更应回到需求草案阶段处理。
+- 如果项目使用不同阶段名称，保留项目名称，但仍遵守本文件的阶段边界。
+
+## 文档结构
+
+- 文档路径和文件名优先沿用项目既有约定；没有约定时，由用户确认目标路径。
+- 一个需求文档应描述一个清晰业务主题；主题过宽时先建议拆分。
+- 标题、元信息、章节结构优先沿用项目模板；没有模板时，可使用 `prd-draft-format-template.md` 的通用骨架。
+- 不为了套模板创建空章节、空表格、伪造对象或重复内容。
+- 不把同一批数据项、规则或流程在多个章节中重复抄写。
+- 未确认事项必须保留在相关需求语境中，标记为 `需补` 或 `待确认`。
+
+## 需求表达
+
+- 用业务语言描述需求：目标、参与方、触发条件、输入、处理规则、输出、状态、边界、异常、权限和生命周期。
+- 用户用实现语言表达时，转译为业务需求：
+  - 表、字段、列、属性、model、struct 转为业务数据对象和数据项。
+  - API、Service、任务、队列、缓存、页面组件 转为业务能力、流程、交互、集成或展示需求。
+  - 索引、唯一约束、字段类型、请求响应结构 转为业务唯一性、校验规则、数据含义或交互约束。
+- 如果某个技术名词本身就是项目通用业务术语，可以保留术语，但不要扩展成实现设计。
+- 备选方案只能写成备选或待确认，不写成已确认结论。
+
+## 数据表达
+
+- 涉及保存、维护、读取、展示、统计或传递的数据时，必须说明数据的业务含义、来源、生成方式、更新时机和使用场景。
+- 数据项统一表达为业务数据项，不写数据库字段类型、ORM 类型、索引、迁移脚本或存储结构。
+- 多值、多对多、明细记录、操作记录、绑定关系等独立存在的数据，应识别为独立业务对象或独立业务记录，不塞进主对象的单个数据项里。
+- “唯一”只能表达为业务唯一性要求，不写索引、约束或数据库实现方式。
+- 值域、状态、类型、来源、等级等要说明业务含义、可见范围、是否参与流程分支和状态流转。
+
+## 既有资产
+
+- 需求涉及既有业务对象、数据、页面、权限、状态、集成、模块复用或“新增 xxx 功能”时，必须先检查项目已有文档和事实来源。
+- 如果复用既有承载，在需求中写明 `复用既有 <业务对象/流程/页面/模块/集成>`。
+- 如果无法确认是否复用，写明 `待确认：是否复用 <候选承载>`。
+- 只有确认没有合理既有承载，或用户明确确认不存在可复用承载时，才写成创建新的业务对象、流程、页面或集成能力。
+- 与既有文档、实现、术语、权限或业务规则冲突的需求，必须先提示冲突，不得写成确定结论。
+
+## 检查口径
+
+检查 PRD draft 时至少覆盖：
+
+- 完整性：目标、范围、参与方、触发、输入、处理、输出、权限、边界、异常、状态和生命周期是否齐全。
+- 闭环：用户或系统从触发到结果是否能走通；成功、失败、取消、重复、历史数据和异常中断是否有合理结果。
+- 数据：业务数据对象、数据项、来源、生成规则、使用场景、值域和状态是否完整。
+- 合理性：是否符合主流产品习惯、正规业务流程、行业常识、权限常识和最小必要复杂度。
+- 复用：是否已检查既有资产，是否误写成新增表、新增接口、新增页面或新增模块。
+- 边界：是否遗漏空数据、重复提交、并发、撤销、回退、历史兼容、不可见、无权限和生命周期结束场景。
+- 未确认项：是否还存在阻塞进入下一阶段的 `需补`、`待确认`、事实冲突或未闭环事项。
+- 越界项：是否混入 API 路径、请求响应结构、SQL、字段类型、类名、文件结构、任务拆解或代码实现。
+
+## 问题分级
+
+- `阻塞问题`：不解决就无法进入下一阶段，例如核心目标不清、关键流程断裂、权限或数据规则冲突、事实来源冲突。
+- `建议修正`：不一定阻塞，但会导致误解、返工或不符合主流做法，例如命名不清、边界缺失、重复表达、复杂度过高。
+- `可后续确认`：不影响当前主链路，但后续设计或实现前需要补齐，例如提示文案、排序细节、默认展示数量。
+
+## 检查输出格式
+
+- 检查中一旦识别出真实问题、闭环缺口、业务 bug 风险、事实冲突或明显不合理点，不只指出问题，还要同步给出修正路径。
+- 对 `阻塞问题` 和 `建议修正` 中的每一个问题，必须提供恰好 3 个可执行方案，不能只给 1 个，也不能只说“可进一步讨论”。
+- 每个问题的输出至少包含：
+  - 问题描述：当前问题是什么。
+  - 影响说明：为什么它会阻塞、返工或产生业务风险。
+  - 方案 A / 方案 B / 方案 C：三个彼此可区分的处理方案。
+  - AI 推荐最优方案：明确只选一个最优方案。
+  - 推荐理由：说明为什么这个方案在当前上下文下最优，以及主要前提和取舍。
+- `可后续确认` 如果本身已经形成明确决策分叉，也按同样格式提供 3 个方案和 AI 推荐；如果只是信息待补，不强制展开 3 个方案，但要说明影响和最晚确认时点。
+- 除非用户明确要求“只列问题不要给方案”，否则检查输出不得只报问题不报方案。
+
+## 禁止事项
+
+- 禁止修改代码、测试、配置、数据库迁移、构建脚本、部署文件或生成物。
+- 禁止在需求草案阶段写数据模型、API 文档、技术设计、实现计划或任务拆解，除非用户明确切换阶段。
+- 禁止写 API path、HTTP method、鉴权实现、request/response schema。
+- 禁止写 SQL DDL、字段类型、索引、唯一约束、迁移脚本。
+- 禁止写类名、struct、component、router、service、job、queue、cache 或文件结构设计。
+- 禁止为了套模板编造业务对象、数据项、字段清单、状态值、字典值或空章节。
+- 禁止把未确认事项写成确定结论。
+- 禁止把用户的功能需求在未检查既有资产前直接推导为新建表、新增接口、新建页面或新模块。
+
+## 模板
+
+创建新文档、重建正文结构或需要参考需求项写法时，读取 `prd-draft-format-template.md`。
diff --git a/references/prd-draft-format-template.md b/references/prd-draft-format-template.md
new file mode 100644
index 0000000..0152610
--- /dev/null
+++ b/references/prd-draft-format-template.md
@@ -0,0 +1,166 @@
+# PRD 草案格式模板
+
+创建新需求草案、重建正文结构或需要参考需求项写法时使用本文件。项目已有模板时优先使用项目模板；本文件只作为通用兜底模板和写法示例。硬性规则以 `prd-draft-document-spec.md` 为准。
+
+## 通用正文骨架
+
+````md
+# <主题> 需求草案
+
+- **阶段** 需求草案阶段
+- **状态** 制定中
+- **锚点** <需求文档路径或需求主题>
+
+## 目标与范围
+- 目标：<本需求要解决的业务问题和成功状态>
+- 范围内：<明确包含的业务对象、流程、角色或场景>
+- 范围外：<明确不处理的内容，避免需求外溢>
+
+## 业务闭环
+- 参与方：<用户、管理员、系统、外部方等>
+- 触发条件：<什么情况下开始>
+- 输入或前置条件：<需要什么信息或状态>
+- 处理规则：<业务判断、校验、流转和限制>
+- 输出结果：<成功、失败、取消、异常后的结果>
+- 状态和生命周期：<状态变化、结束条件、历史保留>
+- 权限和可见范围：<谁能看、谁能改、谁能触发>
+- 边界和异常：<空数据、重复、失败、撤销、兼容等>
+
+## 需求项
+- <需求项名称>：<已确认需求内容>
+- 数据项 <名称>：<业务含义、来源、生成方式、使用规则>
+- 待确认：<不阻塞主链路但后续需要确认的问题>
+````
+
+## 模板选择
+
+| 用户表达 | 需求写法 | 使用模板 |
+|:---|:---|:---|
+| 需要记录、维护、展示某类信息 | 业务数据对象和数据项 | 数据对象 |
+| 给已有信息增加来源、规则或使用方式 | 修改既有业务对象 | 修改数据对象 |
+| 多值、多对多、明细、记录、绑定关系 | 独立业务记录或关联关系 | 关联记录 |
+| 状态、类型、来源、分类、等级等值域 | 业务值域和状态含义 | 值域 |
+| 唯一、审核、校验、默认值、权限范围 | 业务规则 | 规则 |
+| 上传、导入、同步、发布、审核、退款等链路 | 业务流程 | 流程 |
+| 列表、详情、筛选、排序、统计、聚合口径 | 展示或统计规则 | 展示统计 |
+| 外部系统、第三方平台、跨模块协作 | 集成需求 | 集成 |
+
+## 写法规则
+
+- 生成的需求草案应优先匹配项目已有结构，不强行使用本模板标题。
+- 不把正文拆成没有内容的固定分区。
+- 用户说“表、结构体、数据模型、model、字段、列、属性”时，先归一为业务需求；涉及保存或维护的数据，按业务数据对象和数据项表达。
+- 不写 SQL、ORM、字段类型、索引、唯一约束、API path 或 request/response schema。
+- 未确认内容写在最相关的需求语境下，标记为 `需补` 或 `待确认`。
+
+## 需求项模板库
+
+### 数据对象
+
+适用场景：用户提出“需要记录 xxx 信息”“维护 xxx 信息”“新增 xxx model”“需要一个 xxx 表”等创建或维护数据承载对象的需求。
+
+````md
+## <业务对象>信息
+- 需要维护 <业务对象> 信息，用于 <业务目的>。
+- 数据项 <名称>：来源于 <来源>，用于 <使用场景>。
+- 数据项 <业务标识>：由 <生成方> 生成，作为 <业务对象> 的业务唯一标识，不允许重复。
+- <名称> 的获取方式、更新时机和来源缺失时的处理方式需补。
+- <业务标识> 的生成规则、重复冲突处理方式和生成失败提示需补。
+````
+
+### 修改数据对象
+
+适用场景：用户提出“给 xxx 增加字段”“调整 xxx 属性”“修改 xxx 数据来源”“删除/停用某个数据项”等变更既有数据承载对象的需求。
+
+````md
+## <业务对象>信息调整
+- 需要调整 <业务对象> 信息，变更原因是 <原因>。
+- 复用既有 <业务对象> 信息承载。
+- 新增数据项 <名称>：来源于 <来源>，用于 <使用场景>。
+- 调整数据项 <名称>：来源由原规则改为 <新规则>。
+- 停用数据项 <名称>：不再由业务流程使用，历史数据处理方式需补。
+- 本次调整对既有数据的兼容、补齐和异常处理方式需补。
+````
+
+### 关联记录
+
+适用场景：用户描述多值、多对多、明细记录、操作记录、绑定关系等独立存在的数据。
+
+````md
+## <对象A>与<对象B>关联关系
+- 需要维护 <对象A> 与 <对象B> 的关联关系，用于 <业务目的>。
+- 数据项 <对象A>：关联到 <对象A> 信息，来源于 <来源>。
+- 数据项 <对象B>：关联到 <对象B> 信息，来源于 <来源>。
+- 同一个 <对象A> 是否允许关联多个 <对象B> 需补。
+- 同一个 <对象B> 是否允许关联多个 <对象A> 需补。
+- 关联关系的创建、解除、重复提交和历史保留规则需补。
+````
+
+### 值域
+
+适用场景：用户提出状态、类型、来源、分类、等级、模式等值域需求。
+
+````md
+## <业务值域>
+- <业务值域> 用于表达 <业务对象> 在 <场景> 中的分类或阶段。
+- 已确认值包括：<值 1>、<值 2>。
+- 每个值的业务含义、可见范围和是否参与流程分支需补。
+- 如果该值域只用于筛选、展示或统计，需明确写明“不参与业务分支和状态流转”。
+````
+
+### 规则
+
+适用场景：用户提出唯一、审核、校验、默认值、权限范围、状态流转等规则，不一定新增数据承载对象。
+
+````md
+## <业务规则>
+- <业务对象> 需要满足 <规则内容>。
+- 规则触发条件：<触发条件>。
+- 规则通过结果：<成功结果>。
+- 规则不通过结果：<失败提示、拦截、回退或人工处理>。
+- 历史数据、重复提交、异常中断和人工修正方式需补。
+````
+
+### 流程
+
+适用场景：用户提出上传、导入、同步、发布、审核、退款、重建等有触发、处理、结果的链路需求。
+
+````md
+## <业务流程>
+- 触发方：<用户、系统、外部方或后台任务>。
+- 触发条件：<何时触发>。
+- 输入内容：<所需信息、文件、状态或外部结果>。
+- 处理规则：<校验、转换、流转、人工介入或系统处理规则>。
+- 成功结果：<成功后的业务状态、可见结果和通知>。
+- 失败结果：<失败后的状态、提示、重试、保留或回退规则>。
+- 重复提交、部分成功、异常中断和历史兼容策略需补。
+````
+
+### 展示统计
+
+适用场景：用户提出列表展示、详情展示、筛选、排序、统计、聚合口径等查询侧需求。
+
+````md
+## <展示或统计规则>
+- <对象> 需要展示的数据项包括：<数据项>。
+- 支持筛选的数据项包括：<数据项>。
+- 支持排序的数据项包括：<数据项>。
+- 统计口径：<统计范围、时间口径、去重方式或聚合规则>。
+- 默认展示范围、默认排序、空结果和无权限时的处理方式需补。
+- 本需求只表达展示和查询口径，不定义 API path、request/response schema 或 SQL 实现。
+````
+
+### 集成
+
+适用场景：用户提出外部系统、第三方平台、跨模块协作、消息通知、数据同步等集成需求。
+
+````md
+## <集成需求>
+- 对接方：<外部系统、平台、模块或组织角色>。
+- 业务目的：<为什么需要对接>。
+- 触发条件：<何时交换信息或触发协作>。
+- 交换内容：<业务数据项和业务含义，不写请求响应 schema>。
+- 成功结果：<双方状态或业务结果>。
+- 失败结果：<失败提示、重试、人工处理、补偿或保留策略>。
+- 权限、审计、幂等、重复通知和异常恢复方式需补。
+````