workflow-loop 0.1.0__py3-none-any.whl

workflow_loop/data/Standardized_Repository/acceptance/acceptance.md

@@ -0,0 +1,119 @@
+# 主题验收阶段工作规范
+
+## 目的
+
+按照已经确认的主题验收计划，核对当前实现和测试证据是否满足每一条验收条件。只有全部条件通过后，才生成 `acceptance/<主题文件标识>_验收结果.md`。
+
+本阶段不修改需求、产品规则、验收主题或验收条件，不运行已经由 `test_execution` 完成的自动化测试，也不允许“遗留”“部分通过”或“带条件通过”。
+
+## 一、开始前调查
+
+读取：
+
+1. 当前工作流编号和当前验收主题。
+2. `acceptance/<主题文件标识>_验收计划.md` 中的验收目标、范围和全部验收条件。
+3. 自动化或混合主题对应的 `qa/<主题文件标识>_测试结果.md` 及当前有效执行记录。
+4. State Snapshot（状态快照）中本主题每个测试项当前有效的机器记录编号。
+5. 与本主题有关的实施记录、产品设计和 `需求交付追踪表.md`。
+
+自动化测试没有通过、测试结果已经失效、实施记录缺失或验收计划本身不能判断时，不开始主题验收。
+
+开始验收前先按第一性原理重新理解用户要得到的结果。AI 必须把验收计划、真实产品入口、实施记录和当前测试证据对应起来；用户提出问题、回答含糊或实际结果与预期不一致时，继续询问发生条件、实际结果、期望结果和影响范围，直到双方对当前事实和处理方式达成共识。没有共识时不能自行记录通过或失败。
+
+主题按 `acceptance/索引.md` 的依赖关系分别验收。没有依赖关系的主题可以分别推进；存在前置主题时，前置主题没有通过前不能验收当前主题。某个主题失败只影响该主题和实际依赖它的主题。
+
+## 二、读取并使用机器记录编号
+
+自动化和混合验收条件的依据是精确的机器执行事实，不是“测试跑过了”这句话。
+
+AI 必须：
+
+1. 从状态快照读取本主题每个测试项当前有效的机器记录编号。
+2. 把每条验收条件和证明它的机器记录编号对应起来。一条验收条件由多次执行共同证明时，把编号都列出来。
+3. 把这些编号逐条写进 `acceptance/<主题文件标识>_验收结果.md` 的“机器测试记录编号”字段。
+
+不能只写“自动化测试已通过”，不能写“见测试结果文档”，也不能引用已经因为代码变化而失效的旧记录。找不到当前有效记录时，说明缺什么并返回 `test_execution` 重新执行，不用旧编号凑数。
+
+## 三、确定每条条件的验收方式
+
+### 纯自动化条件
+
+程序根据当前有效主题测试记录直接建立验收记录，AI 只把机器事实和验收条件对应起来。
+
+不向用户重复提问已经由机器证明的内容。用户不需要再跑一遍测试、再看一次输出，也不需要回答“是否通过”。这类条件的用户回答、人工确认和确认时间统一写“不适用”。
+
+### 混合条件
+
+自动化已经证明的部分直接使用机器记录，不再询问。
+
+只向用户提出机器判断不了的剩余部分，并明确说明：机器已经证明了什么、还剩什么必须由人判断、为什么机器判断不了。提问范围只限这剩余部分，不把整条验收条件重新交给用户从头检查。
+
+### 纯人工条件
+
+完整展示用户需要执行的步骤，让用户不用回看其他文档就能照着做。
+
+每条验收条件必须使用验收计划中的原编号和原内容，不能在本阶段增加、删除、合并或降低条件。
+
+## 四、执行人工验收
+
+需要人工确认时，AI 必须先向用户展示：
+
+1. 验收对象。
+2. 开始前必须具备的条件。
+3. 用户需要执行的具体操作步骤，逐步写清，不省略中间步骤。
+4. 每一步需要观察的内容。
+5. 验收计划要求的明确预期结果。
+6. 当前已经具备的自动化或运行证据，以及它已经证明了哪一部分。
+7. 用户需要回答的具体问题。
+
+不能只问“是否通过”，也不能使用“检查是否正常”“确认符合预期”等无法执行的话。用户不需要额外填写验收记录；用户回答后，AI 调用 `workflow acceptance record`，把用户实际回答、实际结果、确认时间、作为依据的机器测试记录编号和可选证据绑定当前工作流、主题和 `AC-xx`。证据不强制截图、日志或文件哈希；没有独立证据文件时，具体观察说明就是证据。AI 不能替用户填写通过，也不能把用户的原话改写成结论。
+
+## 五、不能生成通过文档的情况
+
+出现以下任一情况时，不生成 `acceptance/<主题文件标识>_验收结果.md`：
+
+- 任一验收条件的实际结果不符合预期。
+- 任一验收条件因为环境、依赖、数据或权限无法验证。
+- 用户回答含糊，AI 无法确定它是不是“通过”。回答含糊时继续问清楚，不自行判断。
+- 作为依据的机器记录已经失效，例如产品代码或测试代码在执行之后发生了变化。
+- 验收计划中的条件在当前实现下无法判断。
+
+这些情况都不能靠补充说明、加备注或写“基本满足”绕过。也不能生成一份写着“部分通过”的结果文件。
+
+失败或阻塞的回答只写入 Journal 和追踪表的退回记录，不成为当前有效验收结果。AI 调查实际原因并给出建议，用户确认后才返回对应阶段：
+
+- 实现不符合验收条件：返回 `impl`，修正后重新经过 `test_code` 和 `test_execution`。
+- 测试代码错误或缺少覆盖：返回 `test_code`；测试计划本身缺项时返回 `test_plan`。
+- 测试没有执行、执行结果失效或临时环境阻塞：留在或返回 `test_execution` 处理。
+- 验收条件遗漏、矛盾或不能判断：返回 `acceptance_plan`。
+- 产品要求无法实现、需要删除或改变：返回 `spec`，由用户重新确认产品设计，再重新经过后续阶段。
+- 用户只取消一个功能或验收主题：使用 `workflow return --to spec --topic "<主题>" --reason "<具体原因>"`，删除对应产品设计，并在后续 `impl` 中定向删除只服务于该功能的代码；不能中止整个工作流，也不能覆盖其他主题需要的公共代码。
+- 用户决定不再继续整个工作流：执行 `workflow abort`。修 bug 时不能把未修复缺陷标记为完成。
+
+不能通过删除失败证据、降低验收条件、填写“部分通过”或生成未通过结果文件让门禁放行。
+
+## 六、形成正式结果
+
+一个主题的全部验收条件都已经通过后，不等待其他独立主题，立即：
+
+1. 向用户逐条说明验收方式、实际结果和证据。
+2. 读取 State Snapshot 中当前有效的逐条验收记录，使用主题验收结果文档模板生成 `acceptance/<主题文件标识>_验收结果.md`。
+3. 确认文档正好覆盖验收计划中的全部 `AC-xx`，每条判定和总结果都为“通过”。
+4. 确认每条自动化和混合条件都写出了当前有效的机器测试记录编号。
+5. 更新 `需求交付追踪表.md` 中本主题对应的验收结果链接。
+
+AI 负责把程序事实写成人能理解的结果，不能改写程序记录中的用户回答、确认时间、机器记录编号或测试结果。固定字段、工作流编号、主题覆盖、程序记录一致性、结果状态、追踪表更新和阶段推进由程序门禁检查。全部主题都有当前有效结果后，用户再通过 `workflow gate topic_acceptance --confirmed` 确认可以进入最终全量回归；这不是让用户重复验收纯自动化条件。
+
+结果文档中的“实际结果”“验收证据”“用户实际回答”“确认时间”“机器测试记录编号”和“验收记录编号”必须逐项对应 State Snapshot 中的当前有效记录。纯人工主题没有自动化结果文件时，在验收依据和上下游文档中明确写“无自动化测试项”，不能伪造 `qa/<主题文件标识>_测试结果.md`。
+
+## 七、完成前对抗性审查
+
+- 是否把自动化测试结果和人工验收混在同一阶段重复执行。
+- 是否让用户重复确认机器已经证明的内容。
+- 是否遗漏验收计划中的任何一条条件。
+- 是否让 AI 替用户完成必须由用户判断的验收。
+- 是否有自动化或混合条件缺少机器测试记录编号，或引用了已经失效的记录。
+- 是否存在未通过、无法验证、回答含糊或证据失效，却仍生成正式结果文件。
+- 是否为了完成工作流降低或删除验收条件。
+- 是否发现产品要求不可行后，没有返回产品设计阶段。
+- 是否使用空泛结论代替实际观察和证据。

workflow_loop/data/Standardized_Repository/acceptance/acceptance_plan.md

@@ -0,0 +1,105 @@
+# 验收计划阶段工作规范
+
+## 目的
+
+根据用户已经确认的需求，和用户确定本次全部验收主题、主题之间的前置关系，并逐个写清什么算完成。最终文档使用 `Template_Repository/acceptance/acceptance_plan.md`，生成 `需求交付追踪表.md`、`acceptance/索引.md` 和各主题验收计划。
+
+本阶段不修改产品规则，不设计代码，不制定测试步骤或实施任务，也不执行验收。
+
+## 一、开始前调查
+
+先读取并核对：
+
+1. 当前工作流编号、工作类型和用户已经确认的需求。
+2. `spec/产品总说明.md`、受影响的功能文档和本次产品设计修改记录。
+3. `spec/代码架构设计.md`、穿刺结论和已有运行证据。
+4. 修 bug 时读取当前工作流对应的缺陷复现记录。
+5. 已有 `需求交付追踪表.md` 时读取历史内容，避免覆盖旧工作流。
+6. 项目已经保存的主题名称和文件标识映射，避免给同一主题分配第二个文件标识。
+
+已有代码的项目还要查看相关代码和测试。现有证据不足且具备安全运行条件时，实际运行相关使用路径。代码和运行结果只能说明当前事实，不能替代用户决定最终产品行为。
+
+能从文件、代码和运行结果查明的事实先自行查明，不让用户重复说明。
+
+## 二、确定验收主题
+
+### 需求来源必须全部覆盖
+
+先把本次工作流的需求来源逐项列出：用户本次提出的每条需求、本次产品设计修改记录中的每项变化、修 bug 时的缺陷记录。再说明每一项分别由哪个验收主题覆盖。
+
+- 每项需求来源至少被一个主题覆盖，不允许出现没有主题负责的需求。
+- 每个主题至少对应一项真实需求来源，不允许出现没有来源的主题。
+- 本次不做的内容必须由用户明确决定不做，并说明后续怎样处理；不能靠不提它来跳过。
+
+覆盖关系先向用户说明清楚，用户确认没有遗漏后，才开始讨论验收条件。
+
+### 主题名称在项目内永久唯一
+
+- 一个验收主题名称在整个项目内只表示一件事，跨轮次也不改变含义。
+- 程序为每个主题名称保存一个稳定的中文文件标识；同一主题在后续轮次继续使用原名称和原文件标识。
+- 不能用同一个名称在不同轮次表示不同内容，也不能给同一件事换名称重新登记一个新主题。
+- 需要表达的内容确实和历史主题不同时，取一个新名称，不改写历史主题的含义。
+- 文档标题和正文写完整中文主题名称；文件名和链接使用已保存的文件标识。
+
+### 从零开发和修改产品
+
+先提出完整主题清单。每个主题说明：
+
+- 覆盖哪部分用户需求或产品设计变化。
+- 完成后用户会得到什么结果。
+- 为什么需要独立验收。
+
+先让用户确认主题是否完整、重复和拆分合理，再讨论验收条件。
+
+主题清单确认后，继续逐个确认主题关系：
+
+- 哪个主题必须等待另一个主题的用户结果后才能验收。
+- `前置主题`只写直接前置主题。已经通过其他前置主题间接包含的依赖不重复写一遍。例如主题 C 依赖主题 B、主题 B 依赖主题 A 时，主题 C 的前置主题只写主题 B。
+- 没有依赖关系的主题写“无”，不强行安排等待关系。
+- 不能形成循环依赖。
+- `展示顺序`只用于让读者按固定顺序阅读；真正的等待关系写在“前置主题”列。
+- 本次确认的关系写入 `acceptance/索引.md`；后续 `qa/索引.md` 和 `impl/索引.md` 只能继承，不能重新改写。
+
+### 修 bug
+
+直接复用缺陷复现阶段已经确认的验收主题，不重新命名、拆分、合并或增加主题。
+
+一份缺陷记录实际包含多个无关缺陷时，返回缺陷复现阶段拆开。修复必须改变产品行为、规则或边界时，停止修 bug 流程，改为修改产品。
+
+## 三、逐个主题讨论
+
+每次只讨论一个需要用户决定的问题，并给出推荐答案和具体理由。每个主题依次确认：
+
+1. 本主题完成后用户最终得到什么结果。
+2. 本主题包含哪些新增、修改、删除或直接受影响的行为。
+3. 哪些内容不属于本主题，由其他主题或最终全量回归负责。
+4. 在什么条件下触发验收。
+5. 触发后必须看到或核实到什么结果。
+6. 这个结果来自哪条产品设计或缺陷依据。
+
+讨论时检查本次变化涉及的场景、规则、使用过程和异常情况，但不机械凑齐固定分类。没有相关设计时不编造验收条件。
+
+一个主题的以上六项全部由用户确认后，才开始讨论下一个主题。不能先把全部主题的条件写完再一次性交给用户确认，也不能因为主题看起来简单就跳过确认。
+
+## 四、发现问题时的处理
+
+- 产品在某个条件下应该怎样处理没有定义：返回产品设计阶段确认产品规则。
+- 主题之间重复或边界不清：返回主题清单重新讨论。
+- 验收条件不能明确判断通过或不通过：继续讨论具体条件和结果。
+- 实现困难、代码现状不同或测试失败：不能降低已经确认的验收条件。
+- 用户提出当前范围之外的新需求：不加入当前工作流，后续按修改产品处理。
+
+## 五、生成前确认
+
+向用户总结：
+
+- 本次全部验收主题，以及每项需求来源由哪个主题覆盖。
+- 主题之间的前置关系和展示顺序。
+- 每个主题覆盖的需求和最终结果。
+- 每个主题的验收范围。
+- 每条验收条件的触发条件、预期结果和依据。
+- 当前仍未解决的问题。
+
+只有用户明确确认总结正确后，才按照验收计划文档模板生成 `需求交付追踪表.md`、`acceptance/索引.md` 和各主题验收计划。
+
+阶段顺序、主题登记、固定字段、文件结构和门禁由程序处理，本规范不重复程序步骤。

workflow_loop/data/Standardized_Repository/code_design/code_design.md

@@ -0,0 +1,204 @@
+# 代码设计阶段规范
+
+## 目的
+
+根据已经确认的产品设计，和用户形成一致的代码架构设计，并生成或修改 `spec/代码架构设计.md`。
+
+代码设计不是独立于产品设计的技术清单。产品功能、产品通用规则、功能边界、使用过程和异常情况决定代码需要承担什么职责；代码分层、模块、接口、状态和测试负责把这些产品要求实现出来。
+
+本规范说明怎样完成代码设计讨论。最终文档的章节和写法以代码架构设计文档模板为准。
+
+## 一、适用方式
+
+### 1. 从零设计代码架构
+
+适用于 `from_scratch`（从零创建项目）中的 `code_design`（代码设计）阶段。
+
+- 以已经确认的 `spec/产品总说明.md` 和全部 `spec/功能_*.md` 为产品依据。
+- 设计准备采用的代码分层、关键节点、文件、类、函数、类型、状态和测试位置。
+- 尚未实现的代码必须明确标记为“计划”，不能写成已经存在或已经验证。
+- 不要求运行尚未实现的项目，也不能用未经确认的旧代码覆盖本轮产品设计。
+
+### 2. 根据已有代码建立代码设计
+
+适用于 `project_design_init`（项目设计初始化）阶段。
+
+- 本规范负责规定产品与代码怎样对应，以及最终代码架构文档怎样形成。
+- 代码调查、运行校准和证据标记还必须遵守 `project_design_init` 的专用规范。
+- 已有实现必须使用真实代码路径和真实符号，不能把计划名称写成现状。
+
+### 3. 修改或更新已有代码设计
+
+适用于后续代码设计修订阶段时，本规范作为结构和映射依据：
+
+- 产品变化后，只修改受影响的架构层、关键节点、功能流程、共享代码和差异记录。
+- 实施、测试和验收完成后，用最终代码、测试和运行结果替换原来的计划内容。
+- 不借一次局部变化重写与本次工作无关的架构说明。
+
+## 二、讨论原则
+
+1. 能从产品文档、代码、测试或运行结果查明的事实，先自行查明，不让用户重复说明。
+2. 产品规则和功能范围以已确认的产品设计为准；发现产品文档互相冲突时，先指出冲突，不能自行选一个方便实现的版本。
+3. 技术取舍需要用户决定时，每次只讨论一个问题，并给出推荐方案、直接理由和实际影响。
+4. 先讨论产品为什么需要某项代码职责，再讨论代码放在哪里、怎样协作。不能先按目录列模块，再硬找产品理由。
+5. 不强制所有产品使用同一种架构分层、同一张表或同一种图。根据当前产品选择能说明清楚的表达方式。
+6. 用户确认共同代码设计之前，不生成或修改正式架构文档。
+
+## 三、从产品设计建立代码覆盖清单
+
+读取产品总说明和全部功能文档，整理所有实际影响代码的内容：
+
+- 产品功能和每个功能中的场景。
+- 产品通用规则和功能独有规则。
+- 支持范围和不支持范围。
+- 使用过程中的触发条件、参与者、输入、输出和顺序。
+- 异常情况中的判断条件、处理方式和用户可见结果。
+- 明确的系统约束，例如只能本地运行、必须持久化状态或必须调用某个外部系统。
+
+产品历史背景如果不形成代码约束，不要求映射。整理完成后检查每项产品内容是否都有代码承接；没有承接的内容必须标记为待设计、待实现或未确认，不能直接忽略。
+
+## 四、由产品职责推导代码架构
+
+### 1. 划分代码层
+
+根据产品职责决定代码需要分成哪些层。每一层必须回答：
+
+- 它承接哪些产品功能、规则或系统约束。
+- 它负责什么，不负责什么。
+- 哪些上层代码可以调用它。
+- 它可以依赖哪些下层代码。
+- 为什么需要单独成层，而不是仅因为目录已经存在。
+
+架构图只画层、职责和依赖方向。不要在架构图里混画某个功能的执行步骤。
+
+### 2. 找出架构关键节点
+
+架构关键节点是多个功能共同经过，或者行为改变会影响产品规则、阶段推进、状态一致性或外部交互的代码位置，例如统一入口、路由、状态存储、规则校验或外部服务适配。
+
+每个关键节点必须确定：
+
+- 对应的产品职责。
+- 上游触发条件和输入。
+- 真实或计划的文件、类、函数、类型和接口。
+- 关键判断和下游调用。
+- 读取或写入的状态和数据。
+- 失败结果和验证位置。
+
+不要把每个普通工具函数都升级成架构关键节点。
+
+### 3. 反向检查模块用途
+
+完成初步分层后，从代码模块反向检查：
+
+- 这个模块具体服务哪个产品功能、产品规则或系统约束。
+- 删除它会导致哪个产品行为无法完成。
+- 它是否和其他模块承担了重复职责。
+- 它是否同时承担多个没有关系的职责，应该拆开。
+
+无法回答用途的模块不能作为正式架构设计保留。
+
+## 五、逐个功能设计完整代码过程
+
+按照产品功能和场景逐个设计，不按照文件目录逐个说明。
+
+### 1. 明确场景范围
+
+先用产品语言写清当前设计的是哪个功能、哪个场景、由什么事件开始、以什么结果结束。一个场景可能多次进入程序，不能强制假设只有一个代码入口。
+
+### 2. 画功能流程或时序
+
+图中同时保留产品过程和代码映射：
+
+- 用户、AI、外部系统或定时事件节点写明触发动作。
+- 每个程序处理节点直接标出文件路径、函数或类型，以及该节点的关键处理。
+- 状态文件、数据库、外部服务或输出文件在实际读写时画出。
+- 判断必须画出不同结果，不能把成功和失败藏在一段说明里。
+- 线条只表示当前场景的明确执行顺序，避免无顺序的交叉连线。
+
+### 3. 解释每个程序节点
+
+对图中每个程序节点写清：
+
+- 谁在什么条件下传入什么。
+- 代码从哪个文件中的哪个函数、类、类型或接口进入。
+- 代码按什么顺序判断和调用。
+- 哪一步读取或写入什么状态、字段、文件或外部数据。
+- 成功返回什么，失败返回什么。
+- 哪个测试或运行结果验证这一节点。
+
+只列函数名不算完成；必须说明具体逻辑。状态和数据变化必须放在实际发生的步骤中，不能脱离流程单独列一个看不懂的字段。
+
+### 4. 落实规则和异常
+
+逐条对照产品规则和异常情况，确认：
+
+- 判断条件在哪个流程节点出现。
+- 哪个文件和符号执行判断。
+- 不满足条件时是否停止、重试、回滚或保留已有内容。
+- 调用方或用户最终得到什么结果。
+
+没有代码承接的产品规则必须明确标记，不能用“统一处理”“合理返回”等抽象说法掩盖。
+
+### 5. 补充必要的内部逻辑
+
+只有维护者仅看完整功能流程仍无法理解关键实现时，才继续展开单个函数内部逻辑。可选用：
+
+- 函数签名，说明参数、返回结果、副作用和错误。
+- 伪代码，说明关键判断和调用顺序。
+- 流程图，说明分支和循环。
+- 时序图，说明多对象或外部系统交互。
+- 状态图，说明有效状态和迁移条件。
+- 少量代码骨架，固定重要接口或类型形状。
+
+## 六、设计共享代码
+
+多个功能确实需要共同使用同一种机制时，再设计共享代码。必须写清：
+
+- 它共同落实哪些产品功能或产品通用规则。
+- 为什么分别实现会导致重复、冲突或状态不一致。
+- 哪些代码可以调用它，哪些代码不能调用它。
+- 它负责的状态、数据、错误和验证。
+- 修改它会影响哪些功能。
+
+不要为了“架构完整”预先设计当前产品不需要的通用框架。
+
+## 七、确定验证方式
+
+验证必须回到产品设计，不能只写“增加测试”。对每个关键产品要求至少说明：
+
+- 使用哪个测试文件或计划中的测试位置。
+- 测试触发哪个代码入口。
+- 测试准备什么状态或输入。
+- 预期得到什么产品结果和代码结果。
+- 异常和边界怎样验证。
+
+从零设计时可以写计划测试位置；已有项目必须使用真实测试或运行证据，并标明尚未覆盖的内容。
+
+## 八、确认共同代码设计
+
+写正式架构文档前，向用户总结：
+
+1. 产品设计如何决定整体代码分层。
+2. 每层承担的产品职责、代码职责和依赖方向。
+3. 哪些位置是架构关键节点，为什么关键。
+4. 每个产品功能经过哪些代码环节完成。
+5. 产品规则、状态、数据和异常分别在哪里落实。
+6. 多个功能共同使用哪些代码。
+7. 准备怎样验证。
+8. 哪些内容是计划、未确认或与现状冲突。
+
+仍有未决问题时继续一次讨论一个问题。只有用户明确确认共同设计后，才生成或修改 `spec/代码架构设计.md`。
+
+## 九、完成前对抗性审查
+
+- 是否每项代码设计都能说明它服务的产品内容。
+- 是否有产品功能、规则、边界、使用步骤或异常没有代码承接。
+- 是否把目录结构误当成架构职责。
+- 是否只列文件或函数名，没有说明具体逻辑。
+- 是否把功能执行顺序混进架构分层图。
+- 是否有程序流程节点没有对应到具体代码。
+- 是否把状态和数据变化写成脱离步骤的孤立字段。
+- 是否把计划代码写成已有实现，或者把未经运行和测试的判断写成已验证。
+- 是否存在多个模块重复负责同一判断或状态写入。
+- 是否设计了当前产品没有需要的通用框架。
+- 不参加前面讨论的维护者，能否只看当前文档理解产品代码为什么这样写。

workflow_loop/data/Standardized_Repository/code_design/project_design_init.md

@@ -0,0 +1,152 @@
+# 已有项目设计初始化规范
+
+## 目的
+
+首次处理已有代码项目时，查清用户当前能够使用的产品行为和对应代码实现，一次建立：
+
+- `spec/产品总说明.md`（产品总说明）。
+- 多个 `spec/功能_<功能文件标识>.md`（功能说明文档）。
+- `spec/代码架构设计.md`（代码架构设计文档）。
+- `spec/项目设计初始化证据.md`（本次代码调查、测试运行和文档校准证据）。
+
+功能文档的标题和正文保留用户确认的完整中文显示名称；文件名使用程序生成并保存的稳定中文文件标识（只保留中文、字母、数字、下划线、连字符，其它字符替换为下划线），两者可能不同。
+
+本阶段只适用于 `product_change`（修改产品）或 `bugfix`（修复缺陷）且 `project_design_initialized=false`（项目设计尚未初始化）的情况。`from_scratch`（从零创建项目）不执行本阶段。
+
+## 一、强制调查范围
+
+开始讨论前，必须自行查看当前项目中实际存在的内容：
+
+1. 项目说明和约束，例如 `AGENTS.md`、`README`、设计文档和已有决定记录。
+2. 构建、依赖、启动和配置文件，确认项目怎样安装、启动和测试。
+3. 用户实际进入产品的入口，例如命令行命令、页面、接口、定时任务或系统事件。
+4. 入口之后的主要调用链，直到用户可见结果、文件输出、状态写入或外部系统响应。
+5. 核心状态、数据存储、外部输入输出和失败处理。
+6. 自动化测试、测试数据和测试辅助代码，确认哪些行为已有验证。
+
+不能只根据目录名、文件名、类名或函数名猜测产品和架构。
+
+## 二、必须运行和验证
+
+项目具备安全的本地运行条件时，必须实际运行，用真实表现校准代码理解。
+
+- 已有本地启动说明、依赖和测试数据时，按项目说明执行。
+- 至少运行现有自动化测试；具备条件时还要构建项目并走主要产品入口。
+- 对主要功能走一遍成功路径，并在安全条件下检查关键失败路径。
+- 运行后对照实际输出、状态文件、日志或界面结果，确认代码阅读是否正确。
+- 缺少普通本地依赖时，按照项目已有说明准备依赖后继续，不因为需要安装普通依赖就直接放弃运行。
+
+出现以下情况必须先取得用户同意：
+
+- 需要生产账号或真实用户数据。
+- 会产生付费调用。
+- 会修改远程系统、生产环境或外部数据。
+- 会执行项目没有说明且可能破坏现有数据的操作。
+
+无法运行时，必须说明具体原因、已经尝试什么，以及哪些产品行为因此没有得到运行确认。不能把“阅读代码后认为可以”写成“已经运行验证”。
+
+## 三、调查证据文档
+
+调查证据按照 `Template_Repository/code_design/project_design_init_evidence.md` 写入 `spec/项目设计初始化证据.md`。本规范负责说明怎样取得真实证据，文档模板负责规定最终字段和章节。
+
+程序会检查：
+
+- 工作流编号必须等于当前工作流编号。
+- “代码检查状态”必须是“已完成”。
+- “已检查代码”至少列出一个项目中真实存在的代码文件，不能只列目录、文档或不存在的路径。
+- 每个代码文件必须写清检查内容和得到的事实。
+- 运行条件写“具备”时，必须写实际命令、执行结果和结果摘要。
+- 运行条件写“不具备”时，必须写具体原因和未验证范围。
+- 产品设计、代码设计和调查证据都必须在本阶段发生变化。
+
+程序可以检查文件、字段、路径和内容哈希，但不能判断记录是否说谎。用户在第三道门确认前，必须核对命令与结果是否真实。
+
+## 四、按实际入口追踪完整行为
+
+对每个用户可见入口，沿实际调用关系追踪：
+
+1. 谁或什么事件触发入口，传入什么。
+2. 哪个文件中的哪个函数、类或接口接收。
+3. 代码按什么顺序判断、路由和调用。
+4. 哪一步读取配置、文件、数据库、内存状态或外部服务。
+5. 哪一步写入状态、数据、日志或产物。
+6. 成功时用户或调用方得到什么。
+7. 失败时在哪里判断，是否重试、回滚或停止，用户得到什么。
+8. 哪个测试或运行结果可以证明这条调用链。
+
+必须阅读关键函数的具体逻辑，不能只记录调用关系或函数名称。
+
+## 五、判断什么属于当前产品
+
+当前产品功能以用户实际可以进入并完成的行为为准。发现代码中的能力时，按以下方式判断：
+
+- **可达功能**：有实际入口，运行或测试能够到达，写入正式产品文档。
+- **受条件限制**：只有明确配置、权限或环境满足时可达，写清使用条件。
+- **隐藏功能**：代码可达但没有面向当前用户公开，不能直接当成普通正式功能。
+- **未完成功能**：调用链缺失、关键分支未实现或无法产生完整结果，不能写成已经支持。
+- **废弃或失效代码**：没有入口、不会被调用或已经被替代，不写成当前产品功能。
+- **未确认**：仅凭现有证据无法判断时，明确记录并询问用户。
+
+代码和运行结果可以证明产品现在怎样工作，但不能单独证明产品当初为什么诞生，或者当初为什么选择某种规则。历史原因只能使用明确历史文档或用户确认。
+
+## 六、记录证据状态
+
+对产品现状和代码架构中的关键结论，使用以下证据状态：
+
+- **运行确认**：已经实际启动或执行，并观察到对应结果。
+- **测试确认**：现有自动化测试覆盖并通过。
+- **代码确认**：已经阅读真实调用链和关键逻辑，但没有实际运行到该行为。
+- **文档或用户确认**：明确文档或用户说明了该事实。
+- **未确认**：现有证据不足。
+- **冲突**：文档、代码、测试、运行结果或用户说明互相不一致。
+
+证据等级不是用来装饰文档。重要行为只有代码确认而没有运行或测试确认时，要明确说明验证缺口。
+
+## 七、同步建立产品与代码设计
+
+调查完成后，先整理一份内部对应关系：
+
+- 每个用户可见功能对应哪些真实入口和调用链。
+- 每条产品通用规则由哪些共享代码落实。
+- 每个功能的规则、使用步骤和异常分别在哪段代码实现。
+- 哪些代码属于多个功能共同经过的架构关键节点。
+- 哪些产品行为缺少测试，哪些代码行为无法在产品文档中找到依据。
+
+随后向用户总结当前产品、代码架构、未确认内容和冲突。每次只讨论一个需要用户决定的问题。用户确认共同理解后，一次生成三类文档。
+
+三类文档必须保持一致：
+
+- 产品功能名称和场景名称一致。
+- 产品边界与代码接口实际支持范围一致。
+- 产品规则与代码判断条件一致。
+- 产品使用过程与代码调用顺序一致。
+- 产品异常结果与代码失败分支一致。
+- 产品通用规则与共享代码职责一致。
+
+## 八、禁止事项
+
+- 禁止只生成 `spec/代码架构设计.md`。
+- 禁止把产品调查和代码调查拆成两轮互不校准的工作。
+- 禁止用旧文档存在代替本次调查和生成。
+- 禁止只看目录结构猜架构。
+- 禁止具备安全运行条件却不运行。
+- 禁止只在聊天中说看过代码或运行过，不写调查证据。
+- 禁止把无法运行的行为写成已经验证。
+- 禁止把不可达、未完成、隐藏或废弃代码直接写成正式产品功能。
+- 禁止调查期间修改代码或顺手重构。
+- 禁止把计划修改写成当前实现。
+- 禁止根据当前代码推断产品诞生背景和历史设计原因。
+
+## 九、完成前对抗性审查
+
+- 是否真正查看了入口、关键调用链、状态、外部输入输出和测试。
+- 是否在具备安全条件时运行了测试、构建和主要产品入口。
+- 无法运行的原因和未验证范围是否写清。
+- 每个正式产品功能是否有真实可达入口和完整结果。
+- 每个产品功能是否能映射到具体代码，代码流程是否与产品使用过程一致。
+- 每个架构关键节点是否有真实路径、符号、逻辑和证据。
+- 是否把函数名当成逻辑说明，遗漏了关键判断和状态写入。
+- 是否把隐藏、未完成或废弃代码误写成正式功能。
+- 产品文档与代码架构文档中的名称、规则、边界、流程和异常是否一致。
+- 是否仍有冲突或未确认内容被写成事实。
+- 三类设计文档和调查证据是否全部生成，并且相对讨论完成时的基线确实发生变化。

workflow_loop/data/Standardized_Repository/code_design/revise_code_design.md

@@ -0,0 +1,32 @@
+# 产品设计变更后的代码架构修订规范
+
+## 目的
+
+在产品设计已经确认、正式实施还没有开始时，检查产品变化会怎样影响现有代码架构，并修改 `spec/代码架构设计.md` 的计划设计。
+
+最终文档结构使用 `Template_Repository/code_design/code_design.md`。本文件只说明本阶段怎样工作，不重复架构文档模板。
+
+## 讨论和调查
+
+1. 读取本次工作流已经确认的 `spec/产品总说明.md` 和受影响的功能文档。
+2. 读取现有 `spec/代码架构设计.md`，找出受影响的代码层、架构关键节点、功能代码过程、共享代码和差异记录。
+3. 对照产品变化，逐项确认新增、修改或删除了哪些产品职责、规则、边界和异常处理。
+4. 需要时查看相关代码和测试，确认当前架构文档没有把计划代码写成已有实现。
+5. 只修改受本次产品变化影响的架构内容，不重写无关部分。
+
+## 修改要求
+
+- 继续从产品功能、产品通用规则或系统约束推导代码设计。
+- 更新受影响的架构层、关键节点、功能场景代码过程、共享代码和差异记录。
+- 架构图只表示代码分层、职责和依赖方向；功能流程图才表示具体执行顺序。
+- 每个程序节点写真实或计划的文件、类、函数、类型或接口，并说明关键逻辑、状态或数据、失败结果和验证位置。
+- 计划实现必须标记为“计划”，不能写成已经完成。
+- 不在本阶段修改正式代码，不制定测试执行步骤，不提前写最终实现结果。
+
+## 结束前检查
+
+- 产品变化是否逐项对应到受影响的代码设计。
+- 是否保留了未受影响的架构内容。
+- 架构图是否仍然是分层图，没有混入功能执行顺序。
+- 代码位置是否能定位到文件和符号，并说明具体职责。
+- `spec/代码架构设计.md` 是否确实反映本次产品设计变化。