workflow-loop 0.1.0__py3-none-any.whl

workflow_loop/data/Standardized_Repository/qa/test.md

@@ -0,0 +1,167 @@
+# 主题测试执行阶段工作规范
+
+## 1. 阶段目的
+
+本阶段把已经确认的测试计划和测试代码真正运行起来，得到可以复核的机器事实。
+
+本阶段不重新设计测试范围，不修改产品代码或测试代码，不执行人工验收。正式结果使用 `Template_Repository/qa/test.md`。
+
+## 2. 两个命令的分工
+
+- `workflow test prepare` 是“登记待执行测试”。它只把一个测试项要执行的命令、工作目录和超时时间记录下来，不运行任何东西，也不产生任何执行结果。
+- `workflow test run` 是“正式运行已登记测试”。它按登记内容启动受控进程，把真实执行事实写成机器记录。
+
+只有 `workflow test run` 产生的记录才是正式测试事实。登记本身不是执行，登记完成不等于测试通过。
+
+## 3. 开始前必须调查
+
+AI 必须读取并核对：
+
+1. 当前工作流编号、全部验收主题和主题关系。
+2. `acceptance/<主题文件标识>_验收计划.md` 中的验收条件。
+3. `qa/<主题文件标识>_测试计划.md` 中的测试项、测试方式和前置测试项。
+4. `impl/<主题文件标识>_实施记录.md` 中的实施后记录。
+5. 测试代码中的完整 `Workflow-Test` 标识。
+6. 当前代码、测试配置、真实测试入口和所需运行环境。
+7. `需求交付追踪表.md` 中当前主题的上下游状态。
+
+测试计划、测试代码标识和实际测试入口不一致时，不开始执行。
+
+如果本阶段是上游变化后重新进入，必须向用户说明旧测试结果为什么失效。实施计划或测试代码可以经过核对后继续复用，但旧机器执行记录和 `qa/<主题文件标识>_测试结果.md` 不能代表最新代码与计划，必须重新登记并执行受影响主题。不能因为之前曾经通过就直接进入主题验收。
+
+## 4. 执行前和用户确认
+
+针对每个自动化或混合测试项，AI 必须用直白话说明：
+
+- 这是哪个主题、哪个 `TC`，要证明哪个验收条件。
+- 实际会执行哪些测试函数、测试类或测试场景。
+- 是否依赖同一主题中的其他测试项；没有依赖写“无”。
+- 实际执行的参数数组命令、项目内工作目录、环境要求和超时时间。
+- 自动化能证明什么；混合测试还需要用户在主题验收阶段确认什么。
+
+用户确认后，用 `workflow test prepare --topic <主题> --tc <TC编号> --cwd <项目内工作目录> --timeout <秒数> -- <命令和参数>` 逐项登记。
+
+### 4.1 工作目录
+
+每次登记都必须包含项目内工作目录。默认是项目根；测试必须在子目录中运行时，写该子目录相对项目根的路径。
+
+- 工作目录只能在项目内，不能指向项目外的绝对路径。
+- 工作目录写进机器记录，正式结果文档必须照抄它。
+- 不能靠“在哪里执行都一样”跳过登记；不同工作目录会改变相对路径、配置查找和测试发现结果。
+
+### 4.2 命令是参数数组
+
+登记的命令是参数数组，直接交给进程执行器，不经过 Shell。
+
+- 不接受管道、重定向、命令串联、命令替换和通配符展开。
+- 需要这些能力时，把它们放进项目自己的脚本，再登记这个脚本作为命令。
+- 登记命令必须直接包含该 `TC` 的测试入口、测试文件、测试类或测试函数定位参数。
+- 不能登记 `python -c`、`node -e` 等临时代码，也不能用一个与测试入口无关但会返回退出码 `0` 的命令冒充测试通过。
+
+全部自动化测试项登记完成后，再调用 `workflow gate test_execution --discuss-done`。这个门禁只检查登记是否完整，不运行测试。
+
+## 5. 正式执行
+
+调用 `workflow test run` 执行已经登记的任务：
+
+- 同一主题按照 `前置测试项` 顺序执行。
+- 程序先读取 `qa/索引.md` 的前置主题关系。有前置主题时，先完成前置主题在本阶段需要执行的自动化测试；前置主题没有自动化测试项时，本阶段无需等待。
+- 没有前置主题且环境互不影响的主题可以并行；默认最多同时执行两个主题。
+- 共用数据库、端口、设备、账号或临时目录的主题必须串行。
+- 每个 `TC` 必须执行当前所有带相同主题和 `TC` 标识的测试入口。
+- 同一前置测试项在当前有效记录没有失效时只执行一次。
+- 当前测试项已经有未失效的成功记录时不重复执行；只运行待执行、失败后重试或已明确失效的项目。
+- 单个任务默认超时 600 秒；AI 根据项目实际情况提出调整，由用户确认。
+
+### 5.1 统一的受控进程执行器
+
+主题测试和最终全量回归使用同一个受控进程执行器。同一个执行器意味着两个阶段的执行方式、超时处理、输出截断和记录字段完全一致，两处结果可以直接互相对照。
+
+执行器统一负责：使用参数数组和 `shell=False` 启动进程、限制运行时间、超时后终止整棵进程树、截断并保存输出摘要、计算完整输出哈希，并记录平台标识和实际可执行文件。
+
+程序把当前有效执行记录写入 State Snapshot（状态快照），把每次尝试写入 Journal（追加式历史）。完整终端输出只用于当次诊断，不保存到正式结果或状态文件。
+
+### 5.2 成功记录绑定当时的代码
+
+一次执行成功后，机器记录绑定执行当时的产品代码哈希和测试代码哈希。
+
+产品代码或测试代码之后发生变化时，这条记录不再代表当前代码，必须重新执行才能作为正式依据。不能用旧记录证明新代码通过。
+
+## 6. 成功结果
+
+一个自动化测试项只有同时满足以下条件才算通过：
+
+- 测试计划要求的所有当前测试入口都已经执行。
+- 实际命令、工作目录、测试入口和登记内容一致。
+- 退出码为 `0`。
+- 执行记录绑定的产品代码哈希和测试代码哈希与当前代码一致。
+
+一个主题的全部自动化或混合测试项通过后，AI 根据机器执行事实生成 `qa/<主题文件标识>_测试结果.md`。没有前置主题或前置主题自动化部分已经完成的独立主题，可以先生成自己的结果，不必等待其他无关主题。
+
+### 6.1 结果文档逐字段对应机器记录
+
+正式结果文档中的机器记录编号、工作目录、测试入口、执行命令、超时（秒）、运行环境、开始时间、结束时间、时长（秒）、退出码、输出摘要、输出哈希、输出字节数、产品代码哈希和测试代码哈希，必须逐字段与 State Snapshot（状态快照）中当前有效的执行记录一致。
+
+- 测试入口和执行命令使用紧凑单行 JSON 数组；输出摘要使用 JSON 字符串，保留机器记录中的换行、引号和转义。
+- 运行环境固定写成 `平台=<platform>；可执行文件=<executable>`；`platform` 是平台标识，`executable` 是实际可执行文件。
+- 逐字段抄写，不改格式、不取整、不截短哈希、不合并字段。
+- 任一机器字段没有记录时，不生成通过结果，必须重新执行。
+- 文档里的“实际结果”只解释这些机器事实证明了什么，不能替换或改写机器事实本身。
+
+混合测试的正式结果只能写“自动化测试结果：通过”和“人工验收状态：待主题验收”，不能提前写整体验收通过。
+
+## 7. 失败、超时和阻塞
+
+测试失败、超时、环境无法启动或前置测试项未通过时：
+
+- 不生成当前主题的正式测试结果。
+- 清除该测试项以前的当前成功记录，避免状态和最新执行事实冲突。
+- 删除已经失效的 `qa/<主题文件标识>_测试结果.md`。
+- Journal 只记录测试项、命令、时间、退出码或失败原因，不保存完整输出。
+- 同一主题中依赖失败项的后续测试项停止；依赖失败主题的后置主题也停止；其他独立主题继续执行。
+
+失败时的终端输出只用于当次诊断：帮助 AI 和用户找出失败原因。它不能被改写、节选或重新解释成通过结论，也不能作为正式结果写进 `qa/<主题文件标识>_测试结果.md`。退出码不是 `0` 就是没通过，不存在“基本通过”。
+
+AI 调查失败原因并向用户说明事实。用户确认后再执行：
+
+- 产品代码错误或实现遗漏：`workflow return --to impl`。
+- 测试代码错误：`workflow return --to test_code`。
+- 测试范围、方式或依赖设计错误：`workflow return --to test_plan`。
+- 验收条件无法判断，但产品设计已经明确：`workflow return --to acceptance_plan`。
+- 产品行为、规则或需求没有定义：`workflow return --to spec`。
+- 临时环境问题：留在 `test_execution`，环境恢复后重新执行。
+
+退回时必须写明受影响主题和原因。只有能从产品行为、代码符号或路径、共享状态、输入输出约定、数据约定或明确调用关系证明直接影响的主题，才列为受影响主题。仅仅在同一目录、同一文件或“可能有影响”不算证据。无法判断时由用户决定。
+
+## 8. 主题重测范围
+
+修正代码或测试后，只重新执行当前主题和用户确认的直接受影响主题。没有直接影响证据的其他主题保留当前有效结果，`workflow test run` 不重复运行这些有效记录；最终由 `regression_test`（最终全量回归阶段）统一检查。
+
+修改共享测试运行器、共享测试配置或统一测试入口时，当前全部主题的测试执行记录都失效。
+
+## 9. 人工验收交接
+
+测试方式为“自动化测试 + 人工验收”时，AI 必须在正式测试结果中写清：
+
+- 用户要看什么对象。
+- 用户怎样操作或观察。
+- 自动化已经证明了哪部分。
+- 还需要用户明确回答什么。
+- 人工结果写入哪个 `acceptance/<主题文件标识>_验收结果.md`。
+
+本阶段只准备交接，不替用户回答，也不写人工验收通过。
+
+## 10. 完成前对抗性审查
+
+AI 在调用 `workflow gate test_execution` 前必须逐项检查：
+
+- 每个自动化或混合测试项是否都有当前有效执行记录。
+- 每个 `TC` 的全部测试入口是否都实际执行且退出码为 `0`。
+- 正式测试结果的机器事实字段是否逐字段与当前执行记录一致。
+- 正式测试结果是否与测试计划和测试代码标识一致。
+- 是否有失败、超时、阻塞或未执行项却写成通过。
+- 是否把失败输出重新解释成了通过结论。
+- 混合测试是否把人工验收部分错误写成已经通过。
+- `qa/索引.md`、局部上下游链接和 `需求交付追踪表.md` 是否指向当前结果。
+
+程序门禁负责检查固定字段、文件、编号、测试入口、命令、工作目录和状态一致性。AI 和用户负责判断实际结果、证据和人工验收说明是否真的能证明验收条件。

workflow_loop/data/Standardized_Repository/qa/test_code.md

@@ -0,0 +1,121 @@
+# 测试代码阶段工作规范
+
+## 1. 阶段职责
+
+本阶段把已经确认的验收条件和测试计划落实为真实测试代码。它先调查实施后的真实代码和现有测试，再和用户确认每个测试项的测试落点，最后编写测试代码。
+
+本阶段不重新制定验收条件和测试范围，不生成正式测试结果，也不执行主题验收。测试代码写作规则另见 `Standardized_Repository/qa/test_code_implementation.md`。
+
+## 2. 开始前必须读取
+
+AI 必须使用文件读取和代码搜索工具，读取：
+
+1. 当前工作流编号、验收主题和主题关系。
+2. `acceptance/索引.md` 和当前全部 `acceptance/<主题文件标识>_验收计划.md`。
+3. `qa/索引.md` 和当前全部 `qa/<主题文件标识>_测试计划.md`。
+4. `impl/索引.md` 和当前全部 `impl/<主题文件标识>_实施记录.md`，重点核对实施后记录。
+5. `需求交付追踪表.md` 和 `spec/代码架构设计.md`。
+6. 测试项对应的产品代码入口、调用关系、状态变化和错误处理。
+7. 现有测试、fixture、测试辅助函数、测试样本、测试配置和统一测试入口。
+
+不能只根据文档中的文件名猜测试写法，也不能把整个代码库打印到命令行代替调查。能从代码确定的事实先自行查明，不让用户重复说明。
+
+### 上游变化后重新进入本阶段
+
+如果终端说明本次是因为验收计划、测试计划或实施代码变化而重新进入 `test_code`（测试代码编写阶段），先核对现有测试代码是否仍覆盖最新测试项：
+
+1. 逐项比较最新 `AC-xx`（验收条件）、`TC-xx`（测试项）和现有 `Workflow-Test` 标识。
+2. 核对测试入口、断言、测试依赖和产品代码入口是否仍然成立。
+3. 全部一致时不修改测试代码，由用户调 `workflow gate test_code --accept-existing-test-code` 明确确认继续使用现有测试代码。
+4. 有新增、删除、改名或预期结果变化时，只修改实际受影响的测试代码。
+
+不得为了满足“测试代码发生变化”的普通门禁而改空格、改注释或制造无意义测试。无论是否复用测试代码，旧测试执行记录都不能继续使用，后续 `test_execution` 必须重新执行。
+
+## 3. 写代码前的测试落点确认
+
+针对测试计划中每个标为 `自动化测试` 或 `自动化测试 + 人工验收` 的测试项，先向用户说明：
+
+| 内容 | 必须说明什么 |
+|---|---|
+| 验收条件 | `AC-xx` 编号、直白名称和预期结果 |
+| 测试项 | `TC-xx` 编号、直白名称和测试方式 |
+| 产品代码入口 | 实际命令、接口、类或函数，以及具体文件位置 |
+| 当前代码逻辑 | 当前入口怎样处理输入、状态、输出和错误 |
+| 测试层级 | 单元、模块、集成、命令、接口或端到端测试，并说明理由 |
+| 测试文件 | 新增或修改的具体测试文件 |
+| 测试场景 | 输入、前置状态和需要覆盖的成功、拒绝、失败或边界情况 |
+| 主要断言 | 具体检查的输出、状态、副作用或错误 |
+| 测试依赖 | 使用的 fixture、真实样本、测试接缝或外部环境 |
+| 隔离清理 | 怎样避免测试之间互相影响 |
+
+用户确认当前工作流全部自动化测试项的测试落点后，才调用 `workflow gate test_code --discuss-done`，然后开始写测试代码。
+
+## 4. 测试方式和测试层级
+
+测试计划中的测试方式只能是：
+
+- `自动化测试`：本阶段必须生成测试代码。
+- `人工验收`：本阶段不编造测试代码，由 `topic_acceptance` 核对。
+- `自动化测试 + 人工验收`：本阶段只实现可自动判断的部分，人工部分交给 `topic_acceptance`。
+
+自动化测试不等于全部写成单元测试。选择能够可靠证明验收结果的最低测试层级，但不能为了方便而绕过用户实际使用的产品入口。
+
+## 5. 追踪标识
+
+每个新增或修改的测试函数、测试类或测试场景必须包含完整标识：
+
+```text
+Workflow-Test
+主题：<验收主题名称>
+测试项：TC-xx <测试项直白名称>
+验收条件：AC-xx <验收条件直白名称>
+测试方式：自动化测试 | 自动化测试 + 人工验收
+测试层级：单元测试 | 模块测试 | 集成测试 | 命令测试 | 接口测试 | 端到端测试
+测试目标：<这段测试具体验证什么>
+测试入口：<测试执行器可以直接定位的文件、测试类、测试函数或场景标识>
+代码入口：<具体命令、接口、文件和符号>
+```
+
+每个测试函数只绑定一个主要验收条件和一个主要测试项。一个验收条件可以由多个测试项覆盖，一个测试项可以由多个测试函数执行。多个测试函数需要相同准备过程时使用 fixture 或测试辅助函数共享。
+
+## 6. 允许的开发反馈
+
+写测试代码阶段可以做静态检查、语法检查、类型检查和 lint 检查。
+
+也可以运行与当前正在编写内容直接相关的单个测试函数、单个测试类或单个测试文件，用来确认刚写的测试代码本身能不能跑起来、断言写得对不对。这类运行只是开发反馈，和正式测试是两回事：
+
+- 只运行当前正在写的那部分，不运行整个测试目录，不运行全量测试入口。
+- 运行结果只在聊天中说明，用来决定接下来怎样改测试代码。
+- 不生成正式机器记录，不用 `workflow test prepare` 登记，不用 `workflow test run` 执行。
+- 不生成或修改 `qa/<主题文件标识>_测试结果.md`。
+- 不更新 `需求交付追踪表.md` 的正式测试结果。
+- 不声称主题测试已经通过，也不据此写出任何验收结论。
+- 不进入主题验收。
+
+局部运行通过不代表测试项通过。正式执行只发生在 `test_execution`（主题测试执行阶段），由受控进程执行器统一登记和运行，只有那里产生的记录才是正式测试事实。
+
+## 7. 发现问题时返回
+
+- 产品代码缺少必要测试接缝：返回 `impl`。
+- 测试范围或测试方式不正确：返回 `test_plan`。
+- 验收条件的预期结果不明确：返回 `acceptance_plan`。
+- 产品行为没有定义：返回 `spec`。
+- 必须运行真实外部场景才能确认技术事实：由用户决定是否返回 `spike`。
+- 只有测试文件位置尚未确定、但现有测试框架能够支持：留在 `test_code` 解决。
+
+不能通过固定返回值、无依据 mock 或绕过产品入口制造“测试通过”。
+
+## 8. 完成前检查
+
+- 每个自动化或混合测试项是否至少有一个完整 `Workflow-Test` 标识。
+- 标识中的主题、测试项、验收条件和测试方式是否与测试计划完全一致。
+- 测试目标、测试入口和产品代码入口是否写到开发者可以直接定位和理解。
+- 测试代码是否优先验证产品可观察结果，而不是私有实现细节。
+- fixture、测试辅助代码、测试样本和测试配置是否只服务测试。
+- 是否没有修改产品代码。
+- 局部运行是否只覆盖当前正在编写的测试，没有跑整个测试目录或全量入口。
+- 是否没有提前生成正式测试结果或主题验收结果。
+
+用户确认测试代码后调用 `workflow gate test_code --confirmed`。程序保存确认后的测试代码和测试配置哈希，后续正式测试只接受这一份测试代码。
+
+上游变化后，如果用户已经通过 `workflow gate test_code --accept-existing-test-code` 确认现有测试代码仍覆盖最新计划，第二道门允许测试代码相对本次重新进入阶段时保持不变；确认后测试代码再次变化时，必须重新核对或修改后再过门禁。

workflow_loop/data/Standardized_Repository/qa/test_code_implementation.md

@@ -0,0 +1,67 @@
+# 测试代码开发规范
+
+## 1. 阶段职责
+
+本规范只规定测试代码怎样写。测试代码阶段怎样调查、讨论、退回上游和通过门禁，由 `Standardized_Repository/qa/test_code.md` 规定。
+
+本阶段开始前，必须已经完成：
+
+- `acceptance/<主题文件标识>_验收计划.md`：已经写清什么算完成。
+- `qa/<主题文件标识>_测试计划.md`：已经写清每条验收条件要覆盖的测试项。
+- `impl/<主题文件标识>_实施记录.md`：已经写清本次代码实施内容，并且实施代码已经完成。
+
+本阶段可以做静态检查、语法检查、类型检查和 lint 检查，也可以运行与当前正在编写内容直接相关的局部测试作为开发反馈，但不写 `qa/<主题文件标识>_测试结果.md`，不写 `acceptance/<主题文件标识>_验收结果.md`，也不修改产品代码。
+
+## 2. 测试代码要求
+
+- 每个具体测试函数、测试类或测试场景都要写完整 `Workflow-Test` 标识，不能只写 `TC-01` 或 `AC-01` 编号；标识必须包含测试执行器可以直接定位的“测试入口”。
+- 一个测试函数只绑定一个主要验收条件和一个主要测试项；一个测试项需要多个场景时拆成多个测试函数。
+- 测试优先检查产品对外可观察的结果，不为了覆盖代码行数去测试私有实现细节。
+- 预期结果必须来自验收计划和产品设计，不能把当前错误实现当成正确答案。
+- 需要外部服务、文件或真实样本时，优先使用项目已经确认的测试接缝；不能用自造数据假装验证真实外部行为。
+- 至少覆盖验收计划中已经确认的成功结果；验收条件明确要求的边界、拒绝和失败结果也必须有测试代码。
+- 测试代码应保持可重复运行，测试之间不能依赖上一个测试留下的未说明状态。
+- 多个测试需要相同准备过程时使用 fixture、测试数据工厂或测试辅助函数，不复制大段准备代码。
+- mock、stub 和 fake 只能替代已经确认的外部依赖或测试接缝，不能替代本次真正要验证的产品逻辑。
+- 断言必须对应测试目标，失败信息应让开发者看出哪个实际结果不符合要求。
+- 测试代码阶段只能修改测试代码和测试配置。发现产品代码需要继续修改时，返回 `impl`，不能在本阶段直接改。
+
+## 3. 复用既有测试
+
+项目里已经有测试覆盖当前测试项时，可以复用，但必须先做两件事：
+
+1. 逐项核对既有测试的入口、断言和预期结果是否真的对应当前 `AC-xx` 和 `TC-xx`，并把核对结果说给用户听。
+2. 由用户确认复用哪些既有测试。用户没有确认前，不把既有测试当成本次测试项的覆盖。
+
+复用的测试仍必须补齐完整 `Workflow-Test` 标识。既有测试过去跑通过，不代表本次通过：正式测试必须在 `test_execution` 阶段用当前代码重新执行一遍，旧执行记录一律不能沿用。
+
+## 4. 允许的局部运行
+
+可以运行与当前正在编写内容直接相关的单个测试函数、单个测试类或单个测试文件，确认刚写的测试能不能跑起来、断言是否成立。
+
+这类运行只是开发反馈：
+
+- 只跑当前正在写的那部分，不跑整个测试目录，不跑项目全量测试入口。
+- 结果在聊天中说明，用来决定下一步怎样改测试代码；需要留痕时写进实施记录的开发检查记录，不写进任何正式测试结果。
+- 不用 `workflow test prepare` 登记，不用 `workflow test run` 执行，不生成机器记录。
+- 局部跑通不等于测试项通过，也不能据此写任何验收结论。
+
+## 5. 本阶段不做的事
+
+- 不运行项目全量测试入口；最终全量回归只由 `regression_test` 执行。
+- 不生成正式测试机器记录；正式执行只发生在 `test_execution` 阶段。
+- 不根据局部运行结果修改测试计划或验收条件。
+- 不填写“测试结果：通过”或“验收结果：通过”。
+- 不把测试代码能运行等同于产品已经完成。
+
+## 6. 完成判断
+
+代码门禁必须同时确认：
+
+1. 本阶段相对开始时确实新增或修改了测试代码。
+2. 本阶段没有修改产品代码。
+3. 当前测试代码仍然对应当前工作流的验收主题、验收条件和测试计划。
+4. 每个自动化或混合测试项至少有一个完整、可读的 `Workflow-Test` 标识，标识中的测试入口可以被测试执行器直接定位。
+5. 测试配置和统一测试入口已经计入测试代码哈希。
+
+通过后进入 `test_execution`。测试代码没有变化，或者产品代码发生变化时，不能进入测试执行阶段。

workflow_loop/data/Standardized_Repository/qa/test_plan.md

@@ -0,0 +1,160 @@
+# 测试计划阶段规范提示词
+
+## 1. 阶段职责
+
+测试计划阶段只做测试覆盖审查和项目全量测试入口登记，不执行本次需求的正式测试。
+
+它必须从已经确认的验收条件出发，检查后续测试是否有办法判断每条验收条件通过或不通过，确定本次修改需要覆盖的针对性回归范围，并把项目统一的全量测试入口登记下来供最终全量回归使用。
+
+它不能重新确定验收主题，不能新增产品规则，不能把测试计划写成测试结果。
+
+## 2. 测试覆盖规则
+
+- 本次工作流的每个验收主题都必须有对应的 `qa/<主题文件标识>_测试计划.md`，文件标识与该主题的验收计划一致。
+- 每条验收条件都必须至少关联一个测试项。
+- 测试项使用稳定编号和直白名称，例如 `TC-01 启动后生成工作流状态`。
+- 一个验收条件可以对应多个测试项；一个测试项只对应一条主要验收条件。
+- 每个测试项必须明确写“自动化测试”“人工验收”或“自动化测试 + 人工验收”。
+- 测试项不是测试结果，不得在测试计划中填写通过、失败或实际执行时间。
+- 测试项有前置依赖时，必须写清前置测试项和执行顺序；没有依赖的测试项不要求排序。
+- 不强制使用“正常、异常、边界”等固定测试分类，分类只在当前验收条件和风险确实需要时使用。
+
+## 3. 测试计划文档结构
+
+每份 `qa/<主题文件标识>_测试计划.md` 必须包含以下部分：
+
+```markdown
+# <主题>测试计划
+
+- 工作流编号：<workflow_id>
+- 上游验收计划：[<主题>验收计划](../acceptance/<主题文件标识>_验收计划.md)
+
+## 1. 验收条件覆盖
+
+| 验收条件链接 | 测试项 | 前置测试项 | 测试方式 | 验证方向 | 预期观察结果 | 证据要求 |
+|---|---|---|---|---|---|---|
+| [AC-01：完成条件](../acceptance/<主题文件标识>_验收计划.md#ac-01) | <a id="tc-01"></a>[TC-01 直白测试名称](#tc-01) | 无或当前主题内的直接前置 TC | 自动化测试 | 检查什么 | 应观察到什么 | 保留什么证据 |
+
+## 2. 针对性回归范围
+
+## 3. 测试条件要求
+
+## 4. 未决测试条件
+
+## 5. 上下游文档
+
+- 上游验收计划：...
+- 下游实施计划：...
+- 下游测试结果：...
+```
+
+具体测试命令、测试文件、测试数据和证据位置尚未确定时，必须写“实施后确认”，不得自行编造。
+
+## 4. 各部分的写作边界
+
+### 验收条件覆盖
+
+只写验收条件链接、测试项、前置测试项、测试方式、验证方向、预期观察结果和证据要求。验收条件的产品背景、产品规则和完整正文留在验收计划中。
+
+前置测试项只允许引用同一主题中必须先通过的直接 `TC`。没有依赖写“无”；不能引用不存在的编号，不能形成循环，也不能把已经通过其他前置项间接包含的依赖重复写一遍。
+
+测试方式按能否由程序可靠判断选择：能自动判断时使用“自动化测试”；只能由用户观察或业务判断时使用“人工验收”；程序和用户分别判断一部分时使用“自动化测试 + 人工验收”。不能为了少写测试代码把可以自动判断的内容改成人工验收。
+
+验收条件链接必须指向对应验收计划中的具体 `AC`；测试项链接必须使用稳定的小写锚点，例如 `TC-01` 使用 `#tc-01`。这样 `需求交付追踪表.md` 才能从验收条件直接跳到具体测试项。
+
+### 针对性回归范围
+
+只写本次修改直接影响的已有行为，以及为什么需要回归。与本次修改无直接关系的旧功能不在这里重复列出；所有主题完成后由最终全量回归统一检查。
+
+### 测试条件要求
+
+写测试需要具备的环境、样本、权限、外部服务或其他前置条件。普通已知产品行为可用可重复测试数据；真实外部行为必须使用真实样本或真实环境，不能只用 mock 数据。
+
+### 未决测试条件
+
+每项未决内容必须标明属于哪一种：
+
+- 当前已经确定，但尚未开始执行。
+- 只有实施代码完成后才能确定。
+- 验收条件本身无法验证，需要退回 `acceptance_plan`。
+
+不能把“实施后才能确定”写成测试失败，也不能用它掩盖无法验证的验收条件。
+
+## 5. 全局检查顺序
+
+AI 必须先读取全部验收主题、产品设计、代码设计、当前代码和已有测试，先向用户说明全局覆盖是否完整。用户确认全局范围没有遗漏后，再逐个主题讨论测试项。
+
+本阶段不运行全量测试，也不建立修改前的测试基线。已有测试当前是否通过，不作为进入实施阶段的条件；发现已有测试失败时，AI 把事实说明清楚交给用户判断，但不因此阻止本轮继续推进。
+
+## 6. 问题退回规则
+
+- 产品行为没有定义：返回 `spec`。
+- 产品行为已定义但验收条件无法判断：返回 `acceptance_plan`。
+- 真实外部技术行为未知：返回 `spike`。
+- 只有实施后的命令、文件、数据或证据位置未知：留在测试计划中，标记“实施后确认”。
+
+## 7. 固定产出与索引
+
+测试计划阶段必须产出：
+
+- `qa/<主题文件标识>_测试计划.md`：每个验收主题一份。
+- `qa/索引.md`：继承 `acceptance/索引.md` 的主题关系，保存展示顺序、前置主题、验收计划、测试计划和测试结果入口；纯人工验收主题的测试结果位置写“无自动化测试项”。索引不保存 AC、TC 的第二份映射，不保存测试项内部执行顺序。
+- `.workflow_loop/project.json` 中的 `test_entry`：项目全量测试入口配置。
+
+纯人工验收主题不生成 `qa/<主题文件标识>_测试结果.md`。对应主题计划的下游文档位置写“无自动化测试结果，转主题验收”，后续由 `topic_acceptance` 直接记录验收结果。
+
+`qa/索引.md` 不能重新改名、拆分、合并或调整 `acceptance/索引.md` 的主题关系。发现主题关系不一致时，返回 `acceptance_plan` 修正来源，不在测试计划阶段自行修正。
+
+同时只更新 `需求交付追踪表.md` 的“测试项”列。测试结果、实施记录和验收结果列保持初始状态，交给后续阶段更新。
+
+## 8. 登记项目全量测试入口
+
+### 8.1 先调查现状
+
+登记之前，AI 先查明项目当前的真实情况：
+
+- 项目使用什么测试工具链，例如 pytest、unittest、jest、go test、cargo test 或项目自带脚本。
+- 运行测试需要哪些依赖、虚拟环境、服务或配置，当前是否已经具备。
+- 项目现在有没有一条能跑全部测试的命令，它写在哪里（README、Makefile、package.json、CI 配置或脚本目录）。
+
+调查依据来自真实文件和真实配置，不从项目类型猜测命令。
+
+### 8.2 已有稳定入口直接复用
+
+项目已经有一条稳定、能跑全部测试的命令时，直接复用它，不新建脚本，也不改写它的实现方式。向用户说明这条命令来自哪个文件，然后登记。
+
+### 8.3 环境缺失时交给用户决定
+
+需要的解释器、依赖包、虚拟环境、外部服务或凭据不存在时：
+
+- 写清缺什么、为什么需要它、怎样准备、不准备会导致哪些测试无法执行。
+- 由用户决定是否准备，以及由谁准备。
+- 不静默安装依赖、不静默创建虚拟环境、不静默修改用户的环境配置。
+
+用户决定暂不准备时，如实登记当前情况并说明最终全量回归会受什么影响，不用一条跑不起来的命令冒充可用入口。
+
+### 8.4 没有统一入口时补充入口脚本
+
+项目没有统一入口时，为项目补充一个入口脚本，例如 `scripts/test_all.sh` 或 `scripts/test_all.py`，让脚本按项目实际情况调用测试工具。
+
+新建或修改入口脚本前，必须先把原文件内容保存进本轮回退清单；文件原本不存在时，登记“原本不存在”的记录。没有保存回退依据之前，不能写入或修改入口脚本。这样整轮作废时才能准确恢复或删除。
+
+### 8.5 入口配置形式
+
+- 入口按操作系统保存为命令参数数组，键为 `default`、`windows`、`linux`、`darwin`，例如 `{"default": ["python", "-m", "pytest"]}`。
+- 当前操作系统有同名配置时优先使用它，没有时才使用 `default`。
+- 参数数组直接交给进程执行器，不经过 Shell。需要管道、重定向、环境变量展开或多条命令依次执行时，把这些内容放进项目自己的入口脚本，再把脚本作为入口命令登记。
+- 用 `workflow test entry` 登记，不手工编辑 `project.json`。
+
+### 8.6 本阶段不执行入口
+
+测试计划阶段只登记入口，不运行它，也不记录它的执行结果。入口是否真的能跑通，由最终全量回归阶段的实际执行结果证明。
+
+## 9. 禁止事项
+
+- 不能复制验收计划的产品背景、产品目标、产品规则和验收条件正文。
+- 不能新增、删除、改名或拆分验收主题。
+- 不能用模糊测试项覆盖全部验收条件。
+- 不能在测试计划阶段执行全量测试入口或任何本次需求的正式测试。
+- 不能在测试计划阶段填写测试通过、测试失败或最终回归结果。
+- 不能把具体测试工具或代码层级当成测试范围本身。

workflow_loop/data/Standardized_Repository/reproduce/reproduce.md

@@ -0,0 +1,60 @@
+# 缺陷复现阶段工作规范
+
+## 目的
+
+在制定修复计划前，用真实场景确认缺陷现象和根因。`reproduce`（缺陷复现阶段）负责回答“问题怎样发生、为什么发生”；后续 `spike`（穿刺阶段）只验证修复仍依赖的具体技术不确定性。
+
+## 一、真实复现要求
+
+- 必须使用真实环境、真实输入和真实代码路径确认缺陷，不得只做推测。
+- 使用用户实际遇到问题的环境、输入、文件、接口响应、设备或等价的真实样本。
+- 不得用自己编造的数据跑通一条假流程后声称缺陷已经复现。
+- 具备安全运行条件时必须实际运行，并记录命令、操作、日志或输出。
+- 需要生产账号、付费调用、远程写入或危险操作时，先取得用户同意。
+- 无法复现时写清阻塞原因并继续讨论，不能把“可能是”写成已确认根因。
+
+## 二、开始前调查
+
+开始时先查看：
+
+1. 用户描述的缺陷现象、触发条件和期望结果。
+2. 对应产品功能文档和代码架构文档。
+3. 实际入口、调用链、状态变化、错误处理和日志位置。
+4. 已有测试、历史缺陷记录和能够安全运行的现有功能。
+
+## 三、逐项确认事实
+
+每次只讨论一个没有确认的问题，直到以下内容明确：
+
+- 缺陷发生在哪个真实场景。
+- 使用什么环境和真实输入可以稳定触发。
+- 实际结果与期望结果分别是什么。
+- 修复后用户应该恢复得到什么结果，并据此确定一个验收主题。
+- 根因是什么，落在哪段代码、配置、数据或外部服务。
+- 哪些日志、运行输出、测试或代码事实证明了这个根因。
+- 修复仍缺少哪些事实；已经确定的内容不要放进后续穿刺。
+
+无法复现或根因没有确认时，继续调查或向用户说明具体阻塞。不能为了推进流程写假结论。
+
+## 四、生成文档
+
+用户确认共同理解后，使用 `Template_Repository/reproduce/reproduce.md`：
+
+1. 新增或修改一份缺陷记录。缺陷记录的标题和正文保留用户确认的完整中文显示名称；文件名使用程序生成并保存的稳定中文文件标识（只保留中文、字母、数字、下划线、连字符，其它字符替换为下划线），两者可能不同。
+2. 更新 `bug/索引.md` 并链接本次缺陷记录。
+3. 一份缺陷记录只写一个验收主题。
+4. 缺陷复现阶段只填写原始事实，不提前填写后续修复和验收结果。
+
+程序负责检查文件变化、文件名、固定字段、章节和索引链接；本规范不重复这些门禁实现。程序不能判断证据是否伪造，用户在第三道门确认前必须核对证据是否真实。
+
+## 五、完成前对抗性审查
+
+- 是否真的运行了用户所说的场景，而不是只读代码后猜测。
+- 是否使用真实输入或真实样本，而不是自己制造方便通过的数据。
+- 实际结果和期望结果是否明确不同。
+- 根因是否说明了具体错误为什么会产生，而不是只重复错误现象。
+- 根因位置是否能让维护者找到对应代码、配置、数据或外部服务。
+- 根因证据是否足以排除其他主要可能。
+- “修复仍存在的不确定性”是否只保留真正未知、会影响修复设计的事实。
+- 验收主题是否直接写修复后的用户结果，而不是代码任务或根因名称。
+- 是否更新 `bug/索引.md` 并链接本次记录。