workflow-loop 0.1.0__py3-none-any.whl

workflow_loop/data/Standardized_Repository/spec/spec.md

@@ -0,0 +1,138 @@
+# 产品设计阶段规范
+
+## 目的
+
+通过灵活、逐步的需求讨论，与用户形成一致的产品理解，最终生成或修改 `spec/产品总说明.md`（产品总说明）和 `spec/功能_<功能文件标识>.md`（功能说明文档）。功能文档的标题和正文保留用户确认的完整中文显示名称；文件名使用程序生成并保存的稳定中文文件标识（只保留中文、字母、数字、下划线、连字符，其它字符替换为下划线），两者可能不同。需求讨论是形成产品文档的工作过程，不单独生成一份功能文档。
+
+本规范说明怎样完成需求讨论，不重复产品文档模板，也不规定所有产品必须按固定业务分类或固定顺序讨论。
+
+## 一、讨论原则
+
+0. 第一性原理思考用户需求，穷尽的对于用户的需求提出问题，直到和用户达成共识
+1. 每次只问一个问题，等待用户回答后再继续。不要一次提出多个需要用户分别决定的问题。
+2. 每个需要用户决定的问题都给出推荐答案，并用直白话说明推荐原因。
+3. 能从文件、代码、工具或运行结果查明的事实，先自行查明，不让用户重复说明。
+4. 产品目标、产品边界、规则取舍和功能范围属于用户决定；给出建议，但必须等待用户确认。
+5. 需求讨论按当前问题灵活展开，不强制按照产品文档章节顺序提问，也不强制套用“数据进入、整理、计算、输出”等分类。
+6. 遇到含义不清或一词多义的说法时，立即指出具体歧义，并和用户确定唯一含义。
+7. 讨论功能关系时使用具体场景检查。例如明确谁在什么情况下做什么、产品给出什么结果、失败时怎样处理。
+8. 讨论期间可以读取文件、查看代码并安全运行项目，但用户确认共同理解之前，不生成或修改产品设计产物。
+9. 产品背景和功能背景必须来自用户确认或可核实事实。不能因为看到旧提示词、文件名、程序类名或代码结构，就推断产品为什么诞生或为什么设计某个功能。
+
+## 二、根据项目现状选择处理方式
+
+### 1. 从零设计产品
+
+适用于 `from_scratch`（从零创建产品）中的 `spec`（产品设计）阶段。
+
+- 从用户当前要解决的问题开始讨论，不先拿模板章节逐项盘问。
+- 随着需求逐渐清楚，再确认用户与场景、产品边界、产品组成、共同规则和功能拆分。
+- 写文档前必须确认产品是在什么背景下产生、谁提出了什么需求，以及这些需求希望得到什么结果。
+- 不预设产品类型，不把某类产品的功能分类强加给当前产品。
+
+### 2. 修改已有产品
+
+适用于 `product_change`（修改已有产品）中的 `spec`（产品设计）阶段。
+
+- 先读取现有 `spec/产品总说明.md`、全部 `spec/功能_*.md` 和与本次变化相关的代码。
+- 自行梳理现状，只向用户讨论这次要新增、修改、删除什么，以及哪些旧规则继续保留。
+- 不要求用户重新描述已经能从项目中确认的现有功能。
+- 保持未受影响的产品内容不变，不借本次修改顺带重写无关功能。
+- 删除功能或缩小功能范围前，必须明确说明影响并取得用户确认。
+
+### 3. 已有代码但没有产品文档
+
+适用于 `project_design_init`（项目设计初始化）阶段。
+
+- 必须先查看代码，不能只根据目录名、文件名、程序类名或函数名猜测产品设计。
+- 至少查看产品入口、用户可见页面或命令、主要数据流转、核心状态、测试、配置和已有说明文档，梳理主要功能及其关系。
+- 项目具备安全的本地运行条件时，必须实际运行，并走主要使用路径，用真实产品表现校准从代码得到的理解。
+- 已有本地启动说明、依赖和测试数据时，直接按项目说明运行。
+- 缺少普通依赖时，按项目已有说明准备依赖后运行。
+- 运行需要生产账号、真实用户数据、付费服务，或者会修改外部数据时，必须先取得用户同意。
+- 无法运行时，明确说明原因以及哪些产品行为没有得到验证，不得假装已经完成运行校准。
+- 当前产品现状以用户实际可以使用的行为为依据，代码用于解释这些行为。
+- 代码中存在但运行时无法使用的内容，不能直接写成正式功能。先查明它是受条件限制、未完成、隐藏还是废弃；无法查明时再询问用户。
+- 只有代码和运行结果无法确定的产品目的、产品边界、历史原因和取舍才询问用户。
+- 代码和运行结果可以证明产品现在怎样工作，但不能单独证明产品当初为什么诞生。产品诞生背景和历史设计原因无法从现有事实确认时，必须询问用户或明确标记未确认。
+
+### 4. 修复产品缺陷
+
+适用于 `bugfix`（修 bug）工作意图。
+
+- 项目设计尚未初始化时，先通过 `project_design_init`（项目设计初始化）建立产品总说明、功能文档和初步代码设计。
+- 项目设计已经初始化时，直接使用已有产品设计作为缺陷复现和修复依据，不重新进入 `spec`（产品设计）阶段。
+- 如果修复需要改变产品规则、功能边界或用户可见行为，当前工作不再是单纯修 bug，必须改为 `product_change`（修改产品）。
+- “根据共同理解生成文档”是从零设计、修改产品和项目设计初始化共同的最后一步，不单独列成另一种产品场景。
+
+## 三、整理讨论结果
+
+讨论过程中根据实际产品整理内容，不把整理方法变成固定提问顺序。
+
+### 功能拆分
+
+- 一份功能文档对应一件可以独立完成的用户事情。
+- 不按按钮数量、页面数量或代码模块拆分功能。
+- 为完成同一件事而共同使用的操作可以留在同一功能中。
+- 目的、规则、使用过程或异常处理明显不同的事情应拆开。
+
+### 规则归位
+
+- 对整个产品或多个功能共同生效的用户可见行为，归入 `spec/产品总说明.md` 的“产品通用规则”。
+- 某个功能独有的规则，归入对应功能文档的“规则”。
+- AI 怎样提问、调查和组织需求讨论，写入产品设计流程规范，不写成产品通用规则。
+- AI 怎样使用直白话和执行对抗性审查，写入全局写作规范，不写成产品通用规则。
+- 不预先规定具体产品必须具备哪些共同规则。
+
+### 现状与目标
+
+- 明确区分“产品现在怎样”和“用户希望改成怎样”。
+- 文档、代码和运行表现不一致时，说明具体差异并继续查证。
+- 查证后仍不能确定的差异交给用户决定，不自行选择对自己方便的解释。
+
+## 四、确认共同理解
+
+准备写产品文档前，先向用户总结：
+
+1. 产品诞生的背景、需求来源和目标。
+2. 谁会使用以及主要使用场景。
+3. 产品支持什么、明确不支持什么。
+4. 产品由哪些主要部分组成，主要流程是什么。
+5. 有哪些产品通用规则。
+6. 准备拆成哪些功能，每个功能独立解决什么事情。
+7. 每个功能是因为什么具体产品需求而设计。
+8. 还有哪些未确定或未验证的内容。
+
+如果仍有未决问题，继续一次只讨论一个问题。只有用户明确确认已经达成共同理解后，才进入文档生成或修改。
+
+## 五、生成或修改文档
+
+- 严格按照产品设计模板生成 `spec/产品总说明.md` 和各个 `spec/功能_<功能文件标识>.md`。
+- 用户确认讨论完成并执行 `workflow gate spec --discuss-done` 后，程序会记录当前产品文档基线；门2要求产品总说明或功能文档相对基线发生变化，旧文件不能直接冒充本次产物。
+- 从零设计时，新建产品总说明，并至少新建一份功能文档。
+- 修改已有产品时，更新产品总说明，只新增、修改或删除本次确认涉及的功能文档。
+- 已有代码但没有产品文档时，根据已经校准的产品现状一次建立产品总说明和全部必要的功能文档。
+- 修 bug 时，只有项目设计尚未初始化才生成产品设计文档；已经初始化时使用现有文档。需要改变产品行为时改走修改产品流程。
+- 产品总说明中的功能清单必须链接到对应的真实功能文档。
+- 产品总说明的修改记录必须写日期、工作流编号、用户需求、修改类型和整体修改内容。
+- 当前工作流受影响的每份功能文档必须增加或更新“修改记录”，写清该功能具体新增、修改或删除了什么；不重复产品总说明的整体摘要。
+- 没有相关内容时写“暂无”，不得编造功能、规则、异常情况或产品目的。
+- 产品背景、产品目标和功能背景只能写已经确认或能够核实的内容，不得为填满章节补写没有依据的产品历史或设计原因。
+- 不把代码设计、接口设计、数据库设计、实施步骤、测试记录或安装教程写入产品文档。
+
+## 六、完成前检查
+
+- 用户是否已经明确确认共同理解。
+- 产品总说明和功能文档是否符合模板结构。
+- 每个功能是否独立解决一件用户事情。
+- 产品边界与各功能边界是否清楚且不冲突。
+- 产品通用规则与功能独有规则是否正确归位。
+- 产品总说明是否只保留功能清单和链接，没有重复功能细节。
+- 已有产品的描述是否经过代码检查，并在具备安全运行条件时经过实际运行校准。
+- 无法运行或无法确认的内容是否明确标记，没有被当作已验证事实。
+- 产品背景是否说明真实的诞生背景和需求来源，没有把提示词、模板或开发过程当成产品背景。
+- 产品目标是否对应已经确认的需求。
+- 每个功能背景是否有明确的产品需求依据，没有由 AI 自行推断设计原因。
+- 用户清单是否只包含实际用户，AI 和系统执行角色是否已放到场景或使用过程中。
+- 修 bug 场景是否正确区分“使用已有产品设计”“先初始化产品设计”和“改走修改产品”。
+- 产品总说明和受影响的功能文档是否记录当前工作流的设计修改。

workflow_loop/data/Standardized_Repository/spike/spike.md

@@ -0,0 +1,236 @@
+# 穿刺阶段规范
+
+## 目的
+
+在进入实施计划或修复计划前，找出仍缺少真实证据、并会改变后续决定的技术不确定性。用户决定执行哪些穿刺项，AI 使用真实场景取得证据，随后把结论同步到受影响的产品设计和代码设计。
+
+穿刺的对象是不确定性，不是功能名称，也不是所有技术问题。已经能从现有事实确认的内容不需要穿刺。
+
+## 一、先调查，再判断是否存在不确定性
+
+1. 读取已经确认的 `spec/产品总说明.md`、其中链接的功能文档和 `spec/代码架构设计.md`。
+2. 改产品和修 bug 时，必须查看相关代码、现有测试、日志、依赖文档和已有运行结果。
+3. 项目具备运行条件时，必须先运行与当前问题有关的现有功能。运行已经能回答的问题，不得再列为穿刺候选。
+4. 修 bug 时还要读取当前缺陷记录和复现结果。不要在穿刺阶段重复已经确认的 bug 表现和根因。
+5. 无法运行时，写清缺少什么条件，以及因此仍无法确认什么。
+6. 从零开发且代码尚不存在时，不强制运行项目，但仍要检查产品设计、代码设计和已经选定的依赖。
+
+技术不确定性必须同时满足：
+
+- 当前缺少事实证据，无法直接确认。
+- 必须通过真实调用、真实运行或实际测量才能确认。
+- 不同结果会改变产品设计、代码设计、实施计划、修复计划、测试或验收方式。
+
+不满足上述条件时，不进入穿刺候选。
+
+## 二、整理候选并消除重复
+
+AI 必须比较每个候选的：
+
+- 真实场景。
+- 当前不确定的内容。
+- 准备取得的证据。
+- 验证结果用于决定什么。
+
+这些内容实质相同，或者一个只是另一个的验证问句时，合并成一个穿刺项。程序门禁不能判断语义重复，这项检查由 AI 完成，最后由用户确认。
+
+后一项必须等前一项结果出来才知道是否需要时，不把后一项提前列为必做项。先完成当前不确定性，再向用户说明是否需要新增后续穿刺。
+
+## 三、逐项和用户确认候选
+
+可以先给用户候选概览，但每次只让用户决定一个候选。每个候选必须用直白话说明：
+
+1. 候选名称。
+2. 真实场景。
+3. 已经确认的事实。
+4. 当前不确定的具体行为、返回内容或限制。
+5. 为什么现有事实不能回答，必须实际验证。
+6. 准备使用什么真实请求、文件、平台、数据规模或操作路径验证。
+7. 验证结果用于决定什么。
+8. 是否会修改外部数据、产生费用或带来其他实际影响。
+9. AI 是否建议执行，以及建议理由。
+
+候选尚未被用户选择时，不写入 `spec/穿刺清单.md`，也不分配 `SP-001` 这类正式编号。
+
+AI 认为没有需要穿刺的不确定性时，也必须说明检查了哪些文件、代码和运行结果，以及为什么这些事实已经足够。只有用户明确决定本次全部跳过，才能执行：
+
+```text
+workflow gate spike --skip
+```
+
+跳过时不生成穿刺清单和结论文档，也不修改产品设计和代码设计。
+
+## 四、确认执行清单
+
+用户逐项决定后，AI 汇总最终清单，说明每项是否互相独立、是否存在执行顺序，并让用户确认清单完整。
+
+用户确认后执行：
+
+```text
+workflow gate spike --discuss-done
+```
+
+第一道门只表示用户确认了本次执行清单。它不表示程序能够理解候选是否语义重复。
+
+第一道门通过后：
+
+1. 创建 `spec/穿刺清单.md`。
+2. 为每个已选项目分配 `SP-001`、`SP-002` 等编号。
+3. 把每项穿刺状态先写为“待验证”。
+4. 创建对应的 `spec/穿刺_<穿刺项文件标识>.md`，先填写第一至第四部分。结论文档的标题和正文保留用户确认的完整中文显示名称；文件名使用程序生成并保存的稳定中文文件标识（只保留中文、字母、数字、下划线、连字符，其它字符替换为下划线），两者可能不同。
+
+## 五、选择最小且真实的验证方法
+
+穿刺不强制编写临时代码。按以下顺序选择方法：
+
+1. 现有命令、现有程序或已有日志可以取得证据时，直接使用。
+2. 第三方工具或真实接口调用可以取得证据时，直接使用。
+3. 只有现有手段不能暴露所需结果时，才编写最小脚本、逻辑原型、界面原型、解析程序、构建探针或性能测量程序。
+
+临时代码、真实场景样本和原始输出统一放入：
+
+```text
+.workflow_loop/spike_tmp/<穿刺项文件标识>/
+```
+
+原型方法只是一种验证手段。可以吸收“目标明确、使用现有技术栈、暴露关键状态”等做法，但不能照搬“默认不接真实数据”。验证对象必须来自真实场景。
+
+执行方式不强制压成一条命令。必须记录最少且可以重复执行的完整命令步骤。
+
+## 六、真实场景要求
+
+验证必须使用产品实际会遇到的接口、输入文件、运行平台、数据规模、操作路径或故障条件。
+
+允许编写最小驱动程序观察真实对象，但不得使用以下内容证明真实行为：
+
+- 自己编造的接口响应。
+- 模拟业务数据。
+- 手工构造的理想文件。
+- 与目标平台无关的玩具环境。
+- 小数据结果直接推断实际规模性能。
+
+真实数据可以脱敏或裁剪，但不能改变本次要验证的格式、结构、规模或故障特征。无法取得真实场景时，只能写“仍未确认”。
+
+## 七、外部影响和敏感信息
+
+用户选择穿刺项，只表示同意验证该不确定性，不自动授权扣费、发送内容、创建或修改外部数据、删除数据。
+
+只读验证可以在穿刺项确认后执行。存在外部影响的步骤必须在执行前再次说明：
+
+- 操作对象。
+- 实际影响。
+- 预计费用。
+- 能否撤销。
+
+取得用户明确确认后才能执行。用户不同意且没有其他真实验证方法时，结论写“仍未确认”。
+
+密钥、令牌、密码和会话信息不得写入穿刺文档、临时文件或保留的命令输出。
+
+## 八、执行并记录证据
+
+互不影响的穿刺项可以一起执行。每完成一项，立即填写对应结论文档的第五至第八部分，并更新清单中的穿刺状态。
+
+必须记录：
+
+- 实际执行时间。
+- 操作系统、目标平台、工具和依赖版本。
+- 实际命令。
+- 真实输入或样本来源、类型、大小、数量或哈希。
+- 关键原始输出、返回字段或测量数据。
+- 实际失败、重试和限制。
+- 根据证据得到的结论。
+
+执行前不预测未知结果。只有产品设计已经给出明确指标时，才提前写处理时间、内存、正确率等判断线。
+
+执行中出现新的不确定性，或者前置结果表明原先未选择的后续候选现在需要执行时，先向用户说明，再由用户决定是否加入清单。AI 不得自行扩展范围。
+
+## 九、形成结论并处理阻塞
+
+结果状态只能是：
+
+- `已确认`：证据足以确认真实行为。
+- `限制已确认`：原方案不可行或只能部分满足要求，但限制已经查明。
+- `仍未确认`：证据仍不足。
+
+结果状态只说明证据确认到了什么。“是否阻塞后续”单独说明当前能不能进入验收计划。
+
+任何穿刺项写“是否阻塞后续：是”时，都不能通过第二道门。必须继续验证，或者让用户决定怎样修改产品、代码设计或范围。
+
+`仍未确认`但不阻塞时，必须写清：
+
+- 剩余风险。
+- 后续处理阶段。
+- 后续需要检查什么。
+
+用户在第三道门最终确认是否接受这些风险。
+
+## 十、把结论同步到设计
+
+穿刺只负责取得真实证据，不修改正式代码。证据确认后，用户决定采用什么实现或修复办法。
+
+从零开发和修改产品时：
+
+- 结果需要改变用户可见行为、功能范围或产品规则时，先由用户决定，再更新 `spec/产品总说明.md` 或对应功能文档。
+- 结果影响接口、数据结构、模块、函数、调用过程、算法、性能限制、平台限制或异常处理时，更新 `spec/代码架构设计.md`。
+
+修 bug 时：
+
+- 原产品行为保持不变，只修改修复方法或代码设计时，可以更新代码设计并继续。
+- 只有改变产品行为、产品规则或功能边界才能继续时，不能在当前 `bugfix` 流程修改产品设计。结束当前流程后，改用 `product_change`。
+
+实现或修复办法仍未决定时，说明当前仍然阻塞，不能进入 `acceptance_plan`。
+
+## 十一、三道门
+
+三道门都只能操作当前正在进行的 `spike` 阶段。当前阶段不是 `spike` 时，不得提前调用穿刺门禁。
+
+### 门1：确认执行清单
+
+命令：
+
+```text
+workflow gate spike --discuss-done
+```
+
+用户确认执行哪些穿刺项后调用。随后写清单、结论文档并执行验证。
+
+### 门2：程序校验产物
+
+命令：
+
+```text
+workflow gate spike
+```
+
+程序检查：
+
+- 清单和结论文档属于当前工作流。
+- 清单中每项都有对应结论文档。
+- 固定字段和值合法，清单中没有“待验证”。
+- 没有任何项目仍阻塞后续。
+- `仍未确认`项目写清剩余风险、后续阶段和后续检查。
+- 写“需要修改”的产品设计或代码设计已经相对穿刺开始时发生变化。
+- 当前工作意图是 `bugfix` 时，没有项目写“产品设计影响：需要修改”。
+
+旧工作流已经进入 `spike` 但没有保存入场设计基线时，不得使用当前文件补造旧基线。全部设计影响为“无需修改”时可以继续；任何项目要求修改设计时，门2必须失败并说明无法证明前后变化。
+
+程序只能检查明确字段、文件和内容哈希，不能判断语义重复、证据是否真实或设计修改是否正确。
+
+### 门3：用户统一确认
+
+命令：
+
+```text
+workflow gate spike --confirmed
+```
+
+用户一起检查穿刺清单、全部结论、剩余风险和更新后的产品设计、代码设计。执行门3时，程序必须重新校验当前文件；门2后文件被改坏时，清除旧通过状态并停留在 `spike`。重新校验通过后才能进入 `acceptance_plan`，并清理 `.workflow_loop/spike_tmp/`、记录实际清理内容。
+
+## 十二、穿刺代码边界
+
+- 可以读取、导入和运行现有代码。
+- 可以在穿刺临时目录中建立隔离副本。
+- 不修改正式源代码、正式页面、正式配置或数据库迁移。
+- 后续正式代码可以使用穿刺确认的接口形状、状态逻辑、算法约束和失败条件。
+- 不把缺少正式错误处理、测试和边界设计的临时代码直接复制进生产代码。
+- 某个样本或验证逻辑需要成为正式测试资产时，在后续 `impl` 实施阶段重新确认后放入正式测试目录。

workflow_loop/data/Template_Repository/acceptance/acceptance_plan.md

@@ -0,0 +1,142 @@
+# 验收计划文档模板
+
+本模板定义验收计划阶段最终生成的两类文档：
+
+1. 项目根 `需求交付追踪表.md`：按工作流编号保存需求从设计到最终代码设计的交付关系。
+2. `acceptance/索引.md`：保存本次工作流的验收主题关系和各主题文档入口。
+3. `acceptance/<主题文件标识>_验收计划.md`：每个验收主题一份计划，说明什么算完成。
+
+文档标题保留完整中文主题名称；文件名使用程序生成并保存的稳定中文文件标识，不自行改写或缩短。
+
+本模板只规定最终文档结构和内容边界，不规定 AI 怎样和用户讨论验收主题。
+
+## 一、`需求交付追踪表.md` 模板
+
+```markdown
+# 需求交付追踪表
+
+## <workflow_id>
+
+### 本次需求
+
+<本次用户需求或缺陷说明>
+
+### 交付链路
+
+| 需求来源与设计依据 | 验收主题 | 验收条件 | 测试项 | 实施计划与任务 | 实施记录与代码 | 测试结果 | 验收结果 | 更新后的代码设计 |
+|---|---|---|---|---|---|---|---|---|
+| <产品设计或缺陷记录链接> | [<主题名称>](./acceptance/<主题文件标识>_验收计划.md) | AC-01：<具体条件> | 待制定 | 待制定 | 待执行 | 待执行 | 待执行 | 待更新 |
+
+### 阻塞和退回记录
+
+| 时间 | 阶段 | 原因 | 处理结果 |
+|---|---|---|---|
+| 暂无 | 暂无 | 暂无 | 暂无 |
+```
+
+规则：
+
+- 每个工作流使用一个 `## <workflow_id>` 章节，不覆盖历史工作流。
+- 每条验收条件单独占一行。
+- 验收计划阶段的后续状态固定写“待制定”“待执行”或“待更新”，不能留空。
+- 后续阶段只更新自己负责的列。
+- 表格中的主题名称写完整中文主题名称；链接路径使用该主题的稳定中文文件标识。
+
+## 二、`acceptance/索引.md` 模板
+
+```markdown
+# 验收主题索引
+
+## <workflow_id>
+
+### 主题关系
+
+| 展示顺序 | 验收主题 | 前置主题 | 验收计划 | 主题验收结果 |
+|---|---|---|---|---|
+| 1 | <主题 A> | 无 | [主题 A 验收计划](./<主题 A 文件标识>_验收计划.md) | [主题 A 验收结果](./<主题 A 文件标识>_验收结果.md) |
+| 2 | <主题 B> | <主题 A> | [主题 B 验收计划](./<主题 B 文件标识>_验收计划.md) | [主题 B 验收结果](./<主题 B 文件标识>_验收结果.md) |
+```
+
+规则：
+
+- `acceptance/索引.md` 首次确认本次工作流的主题关系，后续 `qa/索引.md` 和 `impl/索引.md` 只能继承这份关系。
+- `展示顺序`使用从 `1` 开始的连续数字，只帮助读者阅读；没有依赖的主题不因为展示顺序而必须等待。
+- `前置主题`没有时写“无”；有依赖时只能填写当前工作流中的其他主题。
+- 每个主题必须且只能出现一次；主题关系不能形成循环。
+- `验收主题`列写完整中文主题名称；链接路径使用程序保存的稳定中文文件标识，不从文件名反推主题名称。
+- 主题验收结果文件尚未生成时，也要保留确定的目标路径。
+- 索引只保存主题关系和文档入口，不复制验收条件、产品规则、测试内容、实施步骤或运行状态。
+
+## 三、`acceptance/<主题文件标识>_验收计划.md` 模板
+
+```markdown
+# 【验收主题】<主题名称>
+
+## 1. 本次需求与验收目标
+
+### 需求来源
+
+<用户需求、产品设计修改记录或缺陷复现记录链接>
+
+### 验收目标
+
+<本主题完成后用户最终得到什么结果>
+
+## 2. 产品设计依据
+
+- <产品总说明或功能文档的具体链接和章节>
+- <修 bug 时链接缺陷复现记录和现有产品设计中的预期行为>
+
+## 3. 验收范围
+
+### 本主题验收
+
+- <本主题包含的新增、修改、删除或直接受影响行为>
+
+### 本主题不验收
+
+- <与本主题无关、由其他主题或最终全量回归负责的内容>
+
+## 4. 验收条件
+
+### AC-01：<验收条件名称>
+
+- 条件与触发：<什么条件下发生什么>
+- 预期结果：<必须得到什么用户可见或可核实的结果>
+- 产品设计依据：<具体链接和章节；修 bug 时可以使用缺陷依据>
+
+## 5. 完成判定
+
+- <哪些验收条件全部通过后，本主题才算完成>
+
+## 6. 上下游文档
+
+| 关系 | 文档 | 说明 |
+|---|---|---|
+| 上游 | <产品设计或缺陷复现记录> | 本主题来自哪里 |
+| 全局 | [需求交付追踪表](../需求交付追踪表.md) | 查看完整交付关系和状态 |
+| 下游 | [测试计划](../qa/<主题文件标识>_测试计划.md) | 后续测试计划；尚未生成时保留固定路径 |
+```
+
+标题中的 `<主题名称>` 写完整中文主题名称；文件名和文档内链接中的 `<主题文件标识>` 使用程序生成并保存的稳定中文文件标识。同一主题在验收计划、测试计划、实施记录和结果文档中使用同一个文件标识。
+
+## 四、内容边界
+
+- 每个主题对应一个可以独立判断完成的用户结果。
+- 每条验收条件使用主题内唯一的 `AC-01`、`AC-02` 等编号。`AC` 是 Acceptance Criterion，中文含义是“验收条件”。
+- 每条验收条件必须写清条件与触发、预期结果和具体产品设计或缺陷依据。
+- 不写测试环境、测试数据、执行命令、测试代码、代码模块或实施步骤。
+- 不使用“功能正常”“正确处理”“符合预期”等无法单独判断的表达。
+- 验收计划不能新增产品规则；产品行为没有定义时必须返回产品设计阶段确认。
+
+## 五、完成前检查
+
+- 当前工作流的每项需求或缺陷是否至少被一个验收主题覆盖。
+- 每个主题是否有独立、明确的用户结果。
+- `acceptance/索引.md` 是否覆盖当前工作流全部主题，并写清前置主题关系。
+- 每条验收条件是否有具体依据并能判断通过或不通过。
+- `需求交付追踪表.md` 是否为每条验收条件保留一行九列记录。
+- 每份主题计划是否包含六个固定章节、追踪表链接和下游测试计划路径。
+- 文档标题和正文是否使用完整中文主题名称，文件名和链接是否使用已保存的稳定中文文件标识。
+- 是否混入测试步骤、代码方案或实施任务。
+- 是否覆盖或改写了旧工作流记录。

workflow_loop/data/Template_Repository/acceptance/acceptance_result.md

@@ -0,0 +1,108 @@
+# 主题验收结果文档模板
+
+本模板定义 `acceptance/<主题文件标识>_验收结果.md` 最终记录什么。只有当前主题的全部验收条件都已经通过时，才生成正式结果文件；未通过、无法验证或受到阻塞时，不生成正式结果。
+
+文档标题保留完整中文主题名称；文件名使用程序生成并保存的稳定中文文件标识，与该主题的验收计划使用同一个标识。
+
+```markdown
+# 【主题验收结果】<主题名称>
+
+- 工作流编号：<当前 workflow_id>
+- 验收主题：<主题名称>
+- 验收结果：通过
+- 验收完成时间：<实际时间>
+
+## 1. 验收依据
+
+| 关系 | 文档 | 说明 |
+|---|---|---|
+| 上游 | [主题验收计划](./<主题文件标识>_验收计划.md) | 本主题全部验收条件 |
+| 上游 | [主题测试结果](../qa/<主题文件标识>_测试结果.md) | 自动化或混合主题使用；纯人工主题整行改为“无自动化测试项” |
+| 上游 | [实施记录](../impl/<主题文件标识>_实施记录.md) | 本主题实际实施内容 |
+| 全局追踪 | [需求交付追踪表](../需求交付追踪表.md) | 当前验收条件的完整上下游关系 |
+
+## 2. 验收条件结果
+
+### AC-01：<验收条件名称>
+
+- 验收方式：自动化测试 | 人工验收 | 自动化测试 + 人工验收
+- 验收条件：<写出具体条件，并链接到主题验收计划中的对应位置>
+- 自动化依据：<对应 qa/<主题文件标识>_测试结果.md 中的测试项和结果；纯人工验收写“不适用”>
+- 机器测试记录编号：<作为本条依据的精确机器执行记录编号，多条用顿号分开；纯人工验收写“不适用”>
+
+#### 人工验收步骤
+
+- 验收对象：<用户实际检查什么>
+- 开始前条件：<执行验收前必须具备的状态或数据>
+- 操作步骤：
+  1. <具体操作>
+  2. <具体操作>
+- 观察内容：<用户实际观察什么>
+- 预期结果：<验收条件要求看到的明确结果>
+- 用户需要回答：<要求用户确认的具体问题>
+
+纯自动化验收条件不需要人工操作时，本小节写“不适用”。
+
+- 用户实际回答：<用户的原话；纯自动化写“不适用”>
+- 人工确认：通过 | 不适用
+- 确认时间：<程序记录的确认时间；纯自动化写“不适用”>
+- 实际结果：<自动化结果、人工观察结果或两者组合>
+- 判定：通过
+- 验收证据：<实际观察说明、测试记录、运行输出、截图或文件；没有独立文件时写具体观察说明>
+- 验收记录编号：<State Snapshot 中本条验收记录的 record_id>
+
+## 3. 上下游文档
+
+| 关系 | 文档 | 说明 |
+|---|---|---|
+| 上游 | [主题验收计划](./<主题文件标识>_验收计划.md) | 验收标准来源 |
+| 上游 | [主题测试结果](../qa/<主题文件标识>_测试结果.md) | 自动化或混合主题使用；纯人工主题整行改为“无自动化测试项” |
+| 上游 | [实施记录](../impl/<主题文件标识>_实施记录.md) | 被验收的实际实现 |
+| 全局追踪 | [需求交付追踪表](../需求交付追踪表.md) | 本主题在完整交付链路中的位置 |
+| 下游 | 最终全量回归 | 所有主题通过后执行 |
+```
+
+## 一、两种记录编号
+
+一条验收条件可能同时引用两类程序记录，两者不能混写：
+
+- **机器测试记录编号**：`test_execution`（主题测试执行阶段）产生的执行记录编号。它指向一次精确的机器执行，包含当时的命令、工作目录、时间、退出码和输出哈希。自动化和混合验收条件必须列出作为依据的全部编号；一条验收条件由多次执行共同证明时，把编号都写出来，不只写最后一次。
+- **验收记录编号**：本阶段调用 `workflow acceptance record` 后，程序为这条验收条件保存的记录编号。它是这条结论本身的编号。
+
+纯人工验收条件没有机器测试记录编号，写“不适用”；但仍必须有验收记录编号。
+
+不能写“见状态文件”“见测试结果”代替具体编号，也不能引用已经失效的旧执行记录。
+
+## 二、人工条件必须保留的内容
+
+需要用户判断的验收条件，必须原样保留：
+
+- 用户实际回答：写用户的原话，不改写成“确认通过”，不概括成结论。
+- 实际结果：用户实际观察到什么。
+- 验收证据：可以复核的观察说明、输出、截图或文件。
+- 确认时间：程序记录的时间。
+- 验收记录编号：程序保存的记录编号。
+
+这五项必须和 State Snapshot 中当前有效的验收记录一致。
+
+## 三、总结果只有“通过”
+
+文档头部的“验收结果”只允许写“通过”。
+
+不允许出现“部分通过”“基本通过”“带条件通过”“通过（待观察）”“遗留问题不影响通过”等写法。只要有一条验收条件未通过、无法验证或受到阻塞，就不生成这份正式结果文件，改为返回对应阶段处理。
+
+## 四、完成前检查
+
+- 是否绑定当前工作流编号和当前验收主题。
+- 是否覆盖验收计划中的全部适用验收条件，没有遗漏或增加条件。
+- 每条条件是否写明验收方式、实际结果、判定、验收证据和验收记录编号。
+- 自动化和混合条件是否写出作为依据的机器测试记录编号，且这些记录当前有效。
+- 实际结果、验收证据、用户回答、确认时间和记录编号是否与 State Snapshot 完全一致。
+- 自动化验收条件是否引用当前有效的主题测试结果。
+- 需要人工验收时，是否写清验收对象、开始条件、操作、观察内容和预期结果。
+- 人工条件是否记录用户原话和程序确认时间，且内容与当前有效程序记录一致。
+- 纯自动化条件是否把用户回答、人工确认、确认时间和机器测试记录编号以外的人工字段写为“不适用”。
+- 是否所有条件都明确通过，总结果固定为“通过”，没有出现部分通过、基本通过或带条件通过。
+- 是否在存在未通过、无法验证或阻塞时错误生成了正式结果文件。
+- 是否用“功能正常”“符合预期”等空泛结论代替实际结果。
+- 是否混入新的产品规则、代码方案或实施步骤。