@tea-agent/loop-agent 0.26.0 → 0.26.1

package/skills/analyze-product-requirements/references/example.md

@@ -1,86 +1,86 @@
-# V3 完整流程示例
-
-需求：登录用户在个人资料页修改昵称；昵称 2–20 个字符；保存失败时保留输入并允许重试；不修改头像。
-
-## Product Analysis 关键结构
-
-```md
----
-artifact_version: "3.0"
-artifact_type: product-analysis
-requirement_id: profile-nickname
-project_root: ../../..
-analysis_scope: frontend
-analysis_status: no-clarification-required
-source_requirement: inline
-repository_root: none
----
-
-## 6. 初步前端用户故事
-### FE-US-001 修改昵称
-- 角色：已登录用户
-- 目标：修改自己的展示昵称
-- 价值：保持个人资料准确
-- 入口：个人资料页
-- 验收关注点：合法值可保存；非法值不可提交；失败时保留输入
-
-## 7. 初步前端输出规范
-### FE-US-001 修改昵称
-- 页面/组件：个人资料页、昵称编辑表单
-- 展示内容：当前昵称、字符计数、校验提示
-- 交互动作：编辑、保存、取消、重试
-- UI 状态：normal、dirty、loading、success、error、disabled
-- 表单校验：昵称长度为 2–20 个字符
-- 权限可见性：仅当前登录用户
-- 边界处理：保存失败时保留输入，不得静默失败
-```
-
-Product Analysis 不创建正式 AC。
-
-## 无需澄清记录
-
-```md
-## 1. 澄清结论
-- 状态：no-clarification-required
-- 原因：范围、权限、数据语义和验收结果已经明确。
-## 2. 来源
-- Product Analysis：./product-analysis.md
-## 3. 合并结果
-- Product Requirement 根据明确需求生成，无额外决策标记。
-```
-
-## Product Requirement 故事、规范与 AC
-
-```md
-## 5. 前端用户故事
-### FE-US-001 修改昵称
-- 角色：已登录用户
-- 目标：修改自己的展示昵称
-- 价值：保持个人资料准确
-- 入口：个人资料页
-- 验收标准：AC-FE-001
-
-## 6. 前端输出规范
-### FE-US-001 修改昵称
-- 页面/组件：个人资料页、昵称编辑表单
-- 展示内容：当前昵称、字符计数、校验提示
-- 交互动作：编辑、保存、取消、重试
-- UI 状态：normal、dirty、loading、success、error、disabled
-- 表单校验：昵称长度为 2–20 个字符
-- 权限可见性：仅当前登录用户
-- 边界处理：失败时保留输入，不得静默失败
-
-#### AC-FE-001 保存合法昵称
-Given：
-- 用户已登录并打开个人资料页。
-When：
-- 用户输入合法昵称并点击保存。
-Then：
-- 页面提交昵称修改请求。
-- 保存成功后展示新昵称。
-- 保存期间按钮保持 disabled。
-异常场景：
-- 保存失败时保留输入并提供重试入口。
-```
-
-故事与输出规范使用同一 ID；故事只引用 AC，AC 正文只在对应输出规范中出现一次。
+# V3 完整流程示例
+
+需求：登录用户在个人资料页修改昵称；昵称 2–20 个字符；保存失败时保留输入并允许重试；不修改头像。
+
+## Product Analysis 关键结构
+
+```md
+---
+artifact_version: "3.0"
+artifact_type: product-analysis
+requirement_id: profile-nickname
+project_root: ../../..
+analysis_scope: frontend
+analysis_status: no-clarification-required
+source_requirement: inline
+repository_root: none
+---
+
+## 6. 初步前端用户故事
+### FE-US-001 修改昵称
+- 角色：已登录用户
+- 目标：修改自己的展示昵称
+- 价值：保持个人资料准确
+- 入口：个人资料页
+- 验收关注点：合法值可保存；非法值不可提交；失败时保留输入
+
+## 7. 初步前端输出规范
+### FE-US-001 修改昵称
+- 页面/组件：个人资料页、昵称编辑表单
+- 展示内容：当前昵称、字符计数、校验提示
+- 交互动作：编辑、保存、取消、重试
+- UI 状态：normal、dirty、loading、success、error、disabled
+- 表单校验：昵称长度为 2–20 个字符
+- 权限可见性：仅当前登录用户
+- 边界处理：保存失败时保留输入，不得静默失败
+```
+
+Product Analysis 不创建正式 AC。
+
+## 无需澄清记录
+
+```md
+## 1. 澄清结论
+- 状态：no-clarification-required
+- 原因：范围、权限、数据语义和验收结果已经明确。
+## 2. 来源
+- Product Analysis：./product-analysis.md
+## 3. 合并结果
+- Product Requirement 根据明确需求生成，无额外决策标记。
+```
+
+## Product Requirement 故事、规范与 AC
+
+```md
+## 5. 前端用户故事
+### FE-US-001 修改昵称
+- 角色：已登录用户
+- 目标：修改自己的展示昵称
+- 价值：保持个人资料准确
+- 入口：个人资料页
+- 验收标准：AC-FE-001
+
+## 6. 前端输出规范
+### FE-US-001 修改昵称
+- 页面/组件：个人资料页、昵称编辑表单
+- 展示内容：当前昵称、字符计数、校验提示
+- 交互动作：编辑、保存、取消、重试
+- UI 状态：normal、dirty、loading、success、error、disabled
+- 表单校验：昵称长度为 2–20 个字符
+- 权限可见性：仅当前登录用户
+- 边界处理：失败时保留输入，不得静默失败
+
+#### AC-FE-001 保存合法昵称
+Given：
+- 用户已登录并打开个人资料页。
+When：
+- 用户输入合法昵称并点击保存。
+Then：
+- 页面提交昵称修改请求。
+- 保存成功后展示新昵称。
+- 保存期间按钮保持 disabled。
+异常场景：
+- 保存失败时保留输入并提供重试入口。
+```
+
+故事与输出规范使用同一 ID；故事只引用 AC，AC 正文只在对应输出规范中出现一次。

package/skills/analyze-product-requirements/references/forward-test-cases.md

@@ -1,66 +1,66 @@
-# Forward-Test Cases
-
-在独立 agent 中逐个执行，不提供预期正文，只核对不变量。
-
-## Case 1：无需澄清
-
-```text
-Use $analyze-product-requirements --target frontend.
-需求：登录用户在个人资料页修改自己的昵称；昵称 2–20 个字符；保存失败时保留输入并允许重试；不修改头像。
-```
-
-核对：三个产物都在 `<project-root>/docs/product-analysis/<requirement-id>/`；三者 `analysis_scope` 均为 `frontend`；Product Analysis 为 `no-clarification-required` 且不含正式 AC；Clarification 使用三章精简结构且没有 BR/Q/DEC；Product Requirement 为 complete；故事与同 ID 输出规范一一对应。
-
-## Case 2：需要逐题澄清
-
-```text
-Use $analyze-product-requirements target=both.
-需求：管理员可以导出用户数据。
-```
-
-核对：先列 3–6 个分支；从管理员角色和敏感字段范围开始；每轮先推荐再只问一个主要问题；收到回答后重新识别模糊点；`clarification_rounds` 和问题轮次一致且最多为 3。第 3 轮后仍有 P0/P1 时保持 pending，不再提问、不自行补全；不得回写 Product Analysis。
-
-## Case 3：后端 API 业务需求
-
-```text
-Use $analyze-product-requirements target=backend.
-需求：登录用户查询自己订单的退款状态，失败时看到可理解原因，内部错误不得泄露。
-```
-
-核对：BE 故事只保留能力、使用方、价值、触发方式和 AC 引用；同 ID 输出规范明确输入输出语义、权限和规则；不虚构最终 URL、HTTP 方法、DTO 或代码落点。
-
-## Case 4：非 API 后端任务
-
-```text
-Use $analyze-product-requirements target=backend.
-需求：每天归档 90 天前已完成通知，重复执行不得重复归档。
-```
-
-核对：触发方式明确为定时任务；包含批次、幂等、并发和失败恢复；不会把它误标为 API。
-
-## Case 5：回答仍然模糊
-
-```text
-Use $analyze-product-requirements target=both.
-需求：管理员可以导出用户数据。
-第一轮询问导出字段范围时，用户回答：敏感字段按实际情况处理。
-```
-
-核对：不得把该回答标记为 confirmed；保留原始回答，最终决策写“未形成”并说明无法确定的字段；当前分支保持 unresolved；下一轮继续当前分支并明确指出手机号、邮箱等字段仍未确定，给出可直接确认的推荐方案；不得跳到文件格式或导出入口。
-
-## Case 6：下一轮消除模糊
-
-```text
-沿用 Case 5。下一轮用户回答：导出邮箱，不导出手机号和身份证号。
-```
-
-核对：形成唯一字段规则并标记 confirmed；最终决策明确列出包含和排除字段；当前分支 resolved；重新扫描其他剩余问题和该回答新引入的模糊点；仅在仍会影响范围、规则、输出或验收时进入下一轮。
-
-## Case 7：代码事实不得泄漏到最终需求
-
-```text
-Use $analyze-product-requirements target=backend，并提供一个仓库。
-需求：仅管理员可以导出用户数据。仓库中现有权限判断位于 src/auth/permission.ts，使用 role=admin。
-```
-
-核对：Product Analysis 可记录 `CODE-FACT-*`、证据路径和现状；Clarification 可引用该证据辅助判断，但不得把现状自动视为目标决策；Product Requirement 只写“仅管理员可以导出用户数据”等产品规则，不包含 `CODE-FACT-*`、`src/auth/permission.ts`、`role=admin`、代码符号、模块结构或当前实现过程。
+# Forward-Test Cases
+
+在独立 agent 中逐个执行，不提供预期正文，只核对不变量。
+
+## Case 1：无需澄清
+
+```text
+Use $analyze-product-requirements --target frontend.
+需求：登录用户在个人资料页修改自己的昵称；昵称 2–20 个字符；保存失败时保留输入并允许重试；不修改头像。
+```
+
+核对：三个产物都在 `<project-root>/docs/product-analysis/<requirement-id>/`；三者 `analysis_scope` 均为 `frontend`；Product Analysis 为 `no-clarification-required` 且不含正式 AC；Clarification 使用三章精简结构且没有 BR/Q/DEC；Product Requirement 为 complete；故事与同 ID 输出规范一一对应。
+
+## Case 2：需要逐题澄清
+
+```text
+Use $analyze-product-requirements target=both.
+需求：管理员可以导出用户数据。
+```
+
+核对：先列 3–6 个分支；从管理员角色和敏感字段范围开始；每轮先推荐再只问一个主要问题；收到回答后重新识别模糊点；`clarification_rounds` 和问题轮次一致且最多为 3。第 3 轮后仍有 P0/P1 时保持 pending，不再提问、不自行补全；不得回写 Product Analysis。
+
+## Case 3：后端 API 业务需求
+
+```text
+Use $analyze-product-requirements target=backend.
+需求：登录用户查询自己订单的退款状态，失败时看到可理解原因，内部错误不得泄露。
+```
+
+核对：BE 故事只保留能力、使用方、价值、触发方式和 AC 引用；同 ID 输出规范明确输入输出语义、权限和规则；不虚构最终 URL、HTTP 方法、DTO 或代码落点。
+
+## Case 4：非 API 后端任务
+
+```text
+Use $analyze-product-requirements target=backend.
+需求：每天归档 90 天前已完成通知，重复执行不得重复归档。
+```
+
+核对：触发方式明确为定时任务；包含批次、幂等、并发和失败恢复；不会把它误标为 API。
+
+## Case 5：回答仍然模糊
+
+```text
+Use $analyze-product-requirements target=both.
+需求：管理员可以导出用户数据。
+第一轮询问导出字段范围时，用户回答：敏感字段按实际情况处理。
+```
+
+核对：不得把该回答标记为 confirmed；保留原始回答，最终决策写“未形成”并说明无法确定的字段；当前分支保持 unresolved；下一轮继续当前分支并明确指出手机号、邮箱等字段仍未确定，给出可直接确认的推荐方案；不得跳到文件格式或导出入口。
+
+## Case 6：下一轮消除模糊
+
+```text
+沿用 Case 5。下一轮用户回答：导出邮箱，不导出手机号和身份证号。
+```
+
+核对：形成唯一字段规则并标记 confirmed；最终决策明确列出包含和排除字段；当前分支 resolved；重新扫描其他剩余问题和该回答新引入的模糊点；仅在仍会影响范围、规则、输出或验收时进入下一轮。
+
+## Case 7：代码事实不得泄漏到最终需求
+
+```text
+Use $analyze-product-requirements target=backend，并提供一个仓库。
+需求：仅管理员可以导出用户数据。仓库中现有权限判断位于 src/auth/permission.ts，使用 role=admin。
+```
+
+核对：Product Analysis 可记录 `CODE-FACT-*`、证据路径和现状；Clarification 可引用该证据辅助判断，但不得把现状自动视为目标决策；Product Requirement 只写“仅管理员可以导出用户数据”等产品规则，不包含 `CODE-FACT-*`、`src/auth/permission.ts`、`role=admin`、代码符号、模块结构或当前实现过程。

package/skills/analyze-product-requirements/references/product-analysis-schema.md

@@ -1,32 +1,32 @@
-# Product Analysis V3 输出契约
-
-Product Analysis 是澄清前快照，只允许一次创建。首次写入后，正文、frontmatter 和路径全部冻结；需要更正时使用新的 `requirement_id`。
-
-```yaml
----
-artifact_version: "3.0"
-artifact_type: product-analysis
-requirement_id: <lowercase-slug>
-project_root: ../../..
-analysis_scope: frontend | backend | both
-analysis_status: ready-for-clarification | no-clarification-required
-source_requirement: <路径或 inline>
-repository_root: <路径或 none>
----
-```
-
-文件固定为 `<project-root>/docs/product-analysis/<requirement-id>/product-analysis.md`。
-
-固定章节：原始需求、需求概述、业务目标、需求分析、外部事实。需求分析包含明确需求、推断需求、待确认问题、初步非目标；外部事实包含知识库事实、代码库事实。
-
-按 scope 追加“初步前端用户故事/初步前端输出规范”或“初步后端用户故事/初步后端输出规范”。不得生成独立用户角色或验收标准汇总。
-
-前端故事字段：角色、目标、价值、入口、验收关注点。
-
-后端故事字段：系统能力、使用方、业务价值、触发方式、验收关注点。触发方式使用 API、定时任务、事件、消息、内部调用或数据迁移。
-
-每个故事必须恰好存在一个同 ID 输出规范。前端输出规范字段：页面/组件、展示内容、交互动作、UI 状态、表单校验、权限可见性、边界处理。后端输出规范字段：输入语义、输出语义、数据读写、权限规则、业务规则、安全要求、幂等与并发、错误与边界。
-
-Product Analysis 只记录验收关注点，不得出现正式 `AC-FE-*`、`AC-BE-*` 或 Given/When/Then 块。
-
-`no-clarification-required` 的待确认问题明确写“无”和理由，不得出现问题标记、优先级或问句；`ready-for-clarification` 至少包含一个带优先级或问号的问题。
+# Product Analysis V3 输出契约
+
+Product Analysis 是澄清前快照，只允许一次创建。首次写入后，正文、frontmatter 和路径全部冻结；需要更正时使用新的 `requirement_id`。
+
+```yaml
+---
+artifact_version: "3.0"
+artifact_type: product-analysis
+requirement_id: <lowercase-slug>
+project_root: ../../..
+analysis_scope: frontend | backend | both
+analysis_status: ready-for-clarification | no-clarification-required
+source_requirement: <路径或 inline>
+repository_root: <路径或 none>
+---
+```
+
+文件固定为 `<project-root>/docs/product-analysis/<requirement-id>/product-analysis.md`。
+
+固定章节：原始需求、需求概述、业务目标、需求分析、外部事实。需求分析包含明确需求、推断需求、待确认问题、初步非目标；外部事实包含知识库事实、代码库事实。
+
+按 scope 追加“初步前端用户故事/初步前端输出规范”或“初步后端用户故事/初步后端输出规范”。不得生成独立用户角色或验收标准汇总。
+
+前端故事字段：角色、目标、价值、入口、验收关注点。
+
+后端故事字段：系统能力、使用方、业务价值、触发方式、验收关注点。触发方式使用 API、定时任务、事件、消息、内部调用或数据迁移。
+
+每个故事必须恰好存在一个同 ID 输出规范。前端输出规范字段：页面/组件、展示内容、交互动作、UI 状态、表单校验、权限可见性、边界处理。后端输出规范字段：输入语义、输出语义、数据读写、权限规则、业务规则、安全要求、幂等与并发、错误与边界。
+
+Product Analysis 只记录验收关注点，不得出现正式 `AC-FE-*`、`AC-BE-*` 或 Given/When/Then 块。
+
+`no-clarification-required` 的待确认问题明确写“无”和理由，不得出现问题标记、优先级或问句；`ready-for-clarification` 至少包含一个带优先级或问号的问题。

package/skills/analyze-product-requirements/references/product-requirement-schema.md

@@ -1,33 +1,33 @@
-# Product Requirement V3 输出契约
-
-Product Requirement 是澄清后的完整需求文档和下游唯一需求事实源。
-
-```yaml
----
-artifact_version: "3.0"
-artifact_type: product-requirement
-requirement_id: <lowercase-slug>
-project_root: ../../..
-requirement_status: pending | complete
-analysis_scope: frontend | backend | both
-source_requirement: <路径或 inline>
-source_product_analysis: ./product-analysis.md
-source_clarification: ./requirement-clarification.md
----
-```
-
-固定章节：需求概述、业务目标、需求范围、业务规则、决策追溯。需求范围包含已确认需求、非目标、默认假设、未决事项。不得生成独立用户角色或验收标准汇总。
-
-Product Requirement 只描述目标产品行为，不承载代码侦察记录。不得包含 `CODE-FACT-*`、仓库文件路径、代码级类/函数/组件符号、模块调用关系、数据表名、证据位置、当前实现过程或实现算法。产品层的页面或组件名称仍可用于描述用户可见输出。代码库事实只可在经用户确认或被原始需求明确要求后，转换为不含实现细节的产品规则；原始证据保留在 Product Analysis 或 Clarification。
-
-按 scope 追加前端/后端用户故事和同域输出规范。
-
-前端故事字段：角色、目标、价值、入口、验收标准。后端故事字段：系统能力、使用方、业务价值、触发方式、验收标准。
-
-每个故事必须恰好存在一个同 ID 输出规范。前端规范字段：页面/组件、展示内容、交互动作、UI 状态、表单校验、权限可见性、边界处理。后端规范字段：输入语义、输出语义、数据读写、权限规则、业务规则、安全要求、幂等与并发、错误与边界。
-
-正式 `AC-FE-*` 或 `AC-BE-*` 作为四级标题嵌入对应输出规范。故事的验收标准引用必须与该规范中的 AC 完全一致；AC 遵循 `acceptance-criteria.md`。
-
-后端触发方式明确写 API、定时任务、事件、消息、内部调用或数据迁移，供下游判断 API 适用性。
-
-`complete` 不得包含未解决 P0/P1。真实未决项以 `P0：`、`P1：` 或 `P2：` 开头。澄清决策使用 `DEC-Q-*` 在决策追溯中登记并定位到正式章节。
+# Product Requirement V3 输出契约
+
+Product Requirement 是澄清后的完整需求文档和下游唯一需求事实源。
+
+```yaml
+---
+artifact_version: "3.0"
+artifact_type: product-requirement
+requirement_id: <lowercase-slug>
+project_root: ../../..
+requirement_status: pending | complete
+analysis_scope: frontend | backend | both
+source_requirement: <路径或 inline>
+source_product_analysis: ./product-analysis.md
+source_clarification: ./requirement-clarification.md
+---
+```
+
+固定章节：需求概述、业务目标、需求范围、业务规则、决策追溯。需求范围包含已确认需求、非目标、默认假设、未决事项。不得生成独立用户角色或验收标准汇总。
+
+Product Requirement 只描述目标产品行为，不承载代码侦察记录。不得包含 `CODE-FACT-*`、仓库文件路径、代码级类/函数/组件符号、模块调用关系、数据表名、证据位置、当前实现过程或实现算法。产品层的页面或组件名称仍可用于描述用户可见输出。代码库事实只可在经用户确认或被原始需求明确要求后，转换为不含实现细节的产品规则；原始证据保留在 Product Analysis 或 Clarification。
+
+按 scope 追加前端/后端用户故事和同域输出规范。
+
+前端故事字段：角色、目标、价值、入口、验收标准。后端故事字段：系统能力、使用方、业务价值、触发方式、验收标准。
+
+每个故事必须恰好存在一个同 ID 输出规范。前端规范字段：页面/组件、展示内容、交互动作、UI 状态、表单校验、权限可见性、边界处理。后端规范字段：输入语义、输出语义、数据读写、权限规则、业务规则、安全要求、幂等与并发、错误与边界。
+
+正式 `AC-FE-*` 或 `AC-BE-*` 作为四级标题嵌入对应输出规范。故事的验收标准引用必须与该规范中的 AC 完全一致；AC 遵循 `acceptance-criteria.md`。
+
+后端触发方式明确写 API、定时任务、事件、消息、内部调用或数据迁移，供下游判断 API 适用性。
+
+`complete` 不得包含未解决 P0/P1。真实未决项以 `P0：`、`P1：` 或 `P2：` 开头。澄清决策使用 `DEC-Q-*` 在决策追溯中登记并定位到正式章节。

package/skills/analyze-product-requirements/references/requirement-clarification-schema.md

@@ -1,35 +1,35 @@
-# Requirement Clarification V3 输出契约
-
-```yaml
----
-artifact_version: "3.0"
-artifact_type: requirement-clarification
-requirement_id: <lowercase-slug>
-project_root: ../../..
-analysis_scope: frontend | backend | both
-clarification_status: pending | complete
-clarification_rounds: 0 | 1 | 2 | 3
-source_product_analysis: ./product-analysis.md
-target_product_requirement: ./product-requirement.md
----
-```
-
-文件与 Product Analysis、Product Requirement 位于同一需求目录。
-
-## 无需澄清
-
-只生成三个章节：澄清结论、来源、合并结果。`clarification_rounds` 必须为 `0`。澄清结论写明 `no-clarification-required` 和理由；不得生成 `BR-*`、`Q-*`、`DEC-Q-*`。
-
-## 需要澄清
-
-固定章节：澄清来源、决策分支、问题记录、决策索引。定义 3–6 个 `BR-*` 分支，表格包含分支 ID、名称、优先级、依赖和状态。
-
-问题核心字段：澄清轮次、分支、优先级、影响范围、推荐答案、推荐理由、用户回答、最终决策、决策来源、状态、决策标记、目标位置。`clarification_rounds` 必须为 `1`–`3`，每个问题的澄清轮次不得超过该值。
-
-条件字段：有前置依赖时写依赖问题；存在真实备选时写备选方案；决策来源为 `code-evidence` 时写代码证据；状态为 `pending-non-blocking` 时写未确认影响。
-
-状态使用 confirmed、default-confirmed、pending-blocking、pending-non-blocking；决策来源使用 user、source-requirement、code-evidence、confirmed-default。决策标记必须为 `DEC-Q-*`。
-
-`complete` 要求全部分支 resolved；P0/P1 必须由用户明确回答并使用 confirmed/user；P2 可确认、使用已确认默认值，或在写明影响后延后。complete 时每个决策标记必须出现在 Product Requirement 的决策追溯中。
-
-每轮在用户回答后重新识别模糊点，有必要才再澄清。最多 3 轮；第 3 轮后仍有 P0/P1 时产物必须保持 `pending`，不得继续追问或自行填补决策。
+# Requirement Clarification V3 输出契约
+
+```yaml
+---
+artifact_version: "3.0"
+artifact_type: requirement-clarification
+requirement_id: <lowercase-slug>
+project_root: ../../..
+analysis_scope: frontend | backend | both
+clarification_status: pending | complete
+clarification_rounds: 0 | 1 | 2 | 3
+source_product_analysis: ./product-analysis.md
+target_product_requirement: ./product-requirement.md
+---
+```
+
+文件与 Product Analysis、Product Requirement 位于同一需求目录。
+
+## 无需澄清
+
+只生成三个章节：澄清结论、来源、合并结果。`clarification_rounds` 必须为 `0`。澄清结论写明 `no-clarification-required` 和理由；不得生成 `BR-*`、`Q-*`、`DEC-Q-*`。
+
+## 需要澄清
+
+固定章节：澄清来源、决策分支、问题记录、决策索引。定义 3–6 个 `BR-*` 分支，表格包含分支 ID、名称、优先级、依赖和状态。
+
+问题核心字段：澄清轮次、分支、优先级、影响范围、推荐答案、推荐理由、用户回答、最终决策、决策来源、状态、决策标记、目标位置。`clarification_rounds` 必须为 `1`–`3`，每个问题的澄清轮次不得超过该值。
+
+条件字段：有前置依赖时写依赖问题；存在真实备选时写备选方案；决策来源为 `code-evidence` 时写代码证据；状态为 `pending-non-blocking` 时写未确认影响。
+
+状态使用 confirmed、default-confirmed、pending-blocking、pending-non-blocking；决策来源使用 user、source-requirement、code-evidence、confirmed-default。决策标记必须为 `DEC-Q-*`。
+
+`complete` 要求全部分支 resolved；P0/P1 必须由用户明确回答并使用 confirmed/user；P2 可确认、使用已确认默认值，或在写明影响后延后。complete 时每个决策标记必须出现在 Product Requirement 的决策追溯中。
+
+每轮在用户回答后重新识别模糊点，有必要才再澄清。最多 3 轮；第 3 轮后仍有 P0/P1 时产物必须保持 `pending`，不得继续追问或自行填补决策。