workflow-loop 0.3.3__tar.gz → 0.3.4__tar.gz

{workflow_loop-0.3.3/src/workflow_loop.egg-info → workflow_loop-0.3.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: workflow-loop
-Version: 0.3.3
+Version: 0.3.4
 Summary: 为 AI 驱动的软件开发提供有状态、可验证、可回退的工作流管理。
 Author: yuzyf
 License-Expression: MIT
@@ -34,8 +34,10 @@ Workflow Loop 把一次软件修改拆成有顺序的工作环节，并用程序
 
 - **保存进度**：在项目的 `.workflow_loop/` 目录保存当前工作环节、确认状态和机器执行记录，下一次对话可以从真实状态继续。
 - **控制推进**：完整研发任务的每个环节依次经过讨论完成、程序检查和用户确认三道门；无需开发任务走独立的讨论、执行、结果确认简单流程。
+- **一次说明门禁问题**：完整研发门禁失败时，一次列出当前能够独立确认的全部问题；每项写明位置、预期、实际、证据、影响和下一动作，无法可靠判断的项目标为“未检查”并说明依赖。同一状态重复检查时，问题清单和顺序保持一致，要求先修改后再检查。
+- **给出唯一下一步**：每条命令结束时只给出一条完整有效的下一命令，并说明执行者、是否会自动执行测试或其它实际动作、以及成功条件。AI 必须原样执行，不能追加管道、截断、重定向或命令串联。
 - **连接交付证据**：把产品设计、验收条件、测试项、实施记录和最终结果放进同一条可追踪链路。
-- **保护项目修改**：实施前保存计划修改文件的原内容；需要退回上游或作废整轮时，按工作流规则使旧结果失效或恢复受管内容。
+- **保护项目修改**：实施前保存计划修改文件的原内容，并记录代码、测试、脚本和项目配置的实施观察基线；发现未登记变化时明确报告。需要退回上游或作废整轮时，按工作流规则使旧结果失效或恢复受管内容。
 - **管理四种工作**：分别处理从零创建、修改现有产品、修复缺陷和无需开发任务；只有前三种生成研发环节路径。
 
 ### 不做什么
@@ -77,9 +79,11 @@ flowchart TD
 完整研发路线的三道门分别解决不同问题：
 
 1. **讨论完成**：需求、限制和实施计划已经与用户逐项达成共识，允许开始写正式产物。
-2. **程序检查**：程序核对必需文件、结构、关联、代码变化或测试记录等可机械判断的事实。
+2. **程序检查**：程序核对必需文件、结构、关联、代码变化或测试记录等可机械判断的事实；失败时一次列出全部能够独立确认的问题，不把依赖未满足的检查猜成失败。
 3. **用户确认**：用户确认实际内容符合意图，程序记录确认后才进入下一环节。
 
+门禁失败的每项问题都会给出具体位置、预期、实际、证据、影响和下一动作；同一状态不会逐次隐藏问题，也不会要求 AI 原样重试。命令末尾只保留一条完整下一命令，AI 应直接照此执行。
+
 `light_task`（无需开发任务）是一类任务，不是“改文档、提交、发布”三个固定选项。它也要求先调查和讨论：AI 用第一性原理梳理需求，每次只问一个问题并给出建议，用户确认讨论完毕后才执行。执行 `commit`（本地 Git 提交）、`push`（推送远端）、发布、删除等难撤销操作前，要按准确操作单独确认；“提交代码”必须先问清是只 `commit`，还是还要 `push`。完成后，AI 按约定方法展示真实结果，用户确认后收工。简单流程不创建研发阶段、三道门、固定全量测试或回退副本；失败或作废时保留真实现场并说明结果，不自动回滚。
 
 ## 环境要求
@@ -90,29 +94,29 @@ flowchart TD
 - 安装时能够访问 GitHub 和 PyPI（Python 公共软件包仓库）。
 - 执行安装命令前，先进入要由 Workflow Loop 管理的项目根目录。
 
-## 安装 0.3.3
+## 安装 0.3.4
 
 安装器先进行只读检查并列出项目侧和电脑侧可能发生的全部持久修改。用户确认一次后，安装器才安装或复用全局 `workflow` 命令，并把智能体契约、产物模板和工作规范写入当前项目；用户取消或安装失败时不会留下只完成一部分的安装。
 
 ### macOS
 
 ```bash
-curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.3/install.sh | bash
+curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.4/install.sh | bash
 ```
 
 ### Linux
 
 ```bash
-curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.3/install.sh | bash
+curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.4/install.sh | bash
 ```
 
 ### 原生 Windows
 
 ```powershell
-powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/download/v0.3.3/install.ps1 | iex"
+powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/download/v0.3.4/install.ps1 | iex"
 ```
 
-安装命令固定读取 `v0.3.3` 正式发布中的脚本；不会跟随内容可能变化的 `latest`（最新版本）地址。
+安装命令固定读取 `v0.3.4` 正式发布中的脚本；不会跟随内容可能变化的 `latest`（最新版本）地址。
 
 ## 更新与卸载
 
@@ -120,7 +124,7 @@ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/y
 
 ```bash
 workflow update
-workflow update --version 0.3.3
+workflow update --version 0.3.4
 ```
 
 更新按需补齐电脑全局命令和当前项目，只直接覆盖项目根 `AGENTS.md`、`.workflow_loop/Template_Repository/`、`.workflow_loop/Standardized_Repository/`，以及 `.workflow_loop/project.json` 中的安装版本字段。更新不创建备份，不回滚已经完成的步骤；当前轮次状态、历史、回退资料、业务代码和正式产物保持不变。失败后重新执行同一命令即可继续补齐。
@@ -166,18 +170,18 @@ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/y
 安装完成后，在当前项目中启动支持读取 `AGENTS.md`（智能体契约文件）的 AI 编码助手，直接用自然语言提出需求：
 
 ```text
-用户：给当前项目增加 CSV 导出功能，并保证原有导出格式不受影响。
+用户：给当前项目增加 CSV（逗号分隔值）导出功能，并保证原有导出格式不受影响。
 ```
 
 之后由 AI 编码助手执行日常流程：
 
 1. 自动运行 `workflow start` 检查当前状态，并根据事实与用户确认本轮工作意图。
 2. 调查现状并推荐四种路线之一，用户确认进入该任务后才启动轮次。
-3. 严格执行每条命令输出的“下一步”，讨论时每次只问用户一个问题。
+3. 严格执行每条命令输出的“下一步”，讨论时每次只问用户一个问题；门禁失败先按完整问题清单修改，不能原样重试，也不能自行拼接或截断命令输出。
 4. 完整研发路线在写代码前完成需求、验收、测试和实施计划；无需开发任务在用户确认讨论完毕后直接执行约定内容。
 5. 把真实结果交给用户核对并确认，再正式收工。
 
-用户不需要手工执行日常 `workflow` 命令；用户只负责描述需求、回答讨论问题、确认安装范围和确认各环节结果。
+用户不需要手工执行日常 `workflow` 命令，但仍需确认工作路线、回答讨论问题、作出产品和验收决定、批准难撤销操作、确认安装范围及确认各环节结果。
 
 ## 命令概览
 
@@ -223,10 +227,10 @@ uv run python -m build
 
 ## 发布正式版本
 
-项目维护者确认当前仓库内容可以直接发布后，在仓库根目录执行下面的命令，并把 `0.3.3` 替换成要发布的新版本号：
+项目维护者确认当前仓库内容可以直接发布后，在仓库根目录执行下面的命令，并把 `0.3.4` 替换成要发布的新版本号：
 
 ```bash
-uv run python scripts/release.py 0.3.3
+uv run python scripts/release.py 0.3.4
 ```
 
 运行这条命令本身就表示维护者接受当前仓库状态并承担跳过本地发布检查的风险。脚本不会再次确认，也不会在本地运行测试、构建或远程版本查询。它依次执行：

{workflow_loop-0.3.3 → workflow_loop-0.3.4}/README.md

@@ -15,8 +15,10 @@ Workflow Loop 把一次软件修改拆成有顺序的工作环节，并用程序
 
 - **保存进度**：在项目的 `.workflow_loop/` 目录保存当前工作环节、确认状态和机器执行记录，下一次对话可以从真实状态继续。
 - **控制推进**：完整研发任务的每个环节依次经过讨论完成、程序检查和用户确认三道门；无需开发任务走独立的讨论、执行、结果确认简单流程。
+- **一次说明门禁问题**：完整研发门禁失败时，一次列出当前能够独立确认的全部问题；每项写明位置、预期、实际、证据、影响和下一动作，无法可靠判断的项目标为“未检查”并说明依赖。同一状态重复检查时，问题清单和顺序保持一致，要求先修改后再检查。
+- **给出唯一下一步**：每条命令结束时只给出一条完整有效的下一命令，并说明执行者、是否会自动执行测试或其它实际动作、以及成功条件。AI 必须原样执行，不能追加管道、截断、重定向或命令串联。
 - **连接交付证据**：把产品设计、验收条件、测试项、实施记录和最终结果放进同一条可追踪链路。
-- **保护项目修改**：实施前保存计划修改文件的原内容；需要退回上游或作废整轮时，按工作流规则使旧结果失效或恢复受管内容。
+- **保护项目修改**：实施前保存计划修改文件的原内容，并记录代码、测试、脚本和项目配置的实施观察基线；发现未登记变化时明确报告。需要退回上游或作废整轮时，按工作流规则使旧结果失效或恢复受管内容。
 - **管理四种工作**：分别处理从零创建、修改现有产品、修复缺陷和无需开发任务；只有前三种生成研发环节路径。
 
 ### 不做什么
@@ -58,9 +60,11 @@ flowchart TD
 完整研发路线的三道门分别解决不同问题：
 
 1. **讨论完成**：需求、限制和实施计划已经与用户逐项达成共识，允许开始写正式产物。
-2. **程序检查**：程序核对必需文件、结构、关联、代码变化或测试记录等可机械判断的事实。
+2. **程序检查**：程序核对必需文件、结构、关联、代码变化或测试记录等可机械判断的事实；失败时一次列出全部能够独立确认的问题，不把依赖未满足的检查猜成失败。
 3. **用户确认**：用户确认实际内容符合意图，程序记录确认后才进入下一环节。
 
+门禁失败的每项问题都会给出具体位置、预期、实际、证据、影响和下一动作；同一状态不会逐次隐藏问题，也不会要求 AI 原样重试。命令末尾只保留一条完整下一命令，AI 应直接照此执行。
+
 `light_task`（无需开发任务）是一类任务，不是“改文档、提交、发布”三个固定选项。它也要求先调查和讨论：AI 用第一性原理梳理需求，每次只问一个问题并给出建议，用户确认讨论完毕后才执行。执行 `commit`（本地 Git 提交）、`push`（推送远端）、发布、删除等难撤销操作前，要按准确操作单独确认；“提交代码”必须先问清是只 `commit`，还是还要 `push`。完成后，AI 按约定方法展示真实结果，用户确认后收工。简单流程不创建研发阶段、三道门、固定全量测试或回退副本；失败或作废时保留真实现场并说明结果，不自动回滚。
 
 ## 环境要求
@@ -71,29 +75,29 @@ flowchart TD
 - 安装时能够访问 GitHub 和 PyPI（Python 公共软件包仓库）。
 - 执行安装命令前，先进入要由 Workflow Loop 管理的项目根目录。
 
-## 安装 0.3.3
+## 安装 0.3.4
 
 安装器先进行只读检查并列出项目侧和电脑侧可能发生的全部持久修改。用户确认一次后，安装器才安装或复用全局 `workflow` 命令，并把智能体契约、产物模板和工作规范写入当前项目；用户取消或安装失败时不会留下只完成一部分的安装。
 
 ### macOS
 
 ```bash
-curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.3/install.sh | bash
+curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.4/install.sh | bash
 ```
 
 ### Linux
 
 ```bash
-curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.3/install.sh | bash
+curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.4/install.sh | bash
 ```
 
 ### 原生 Windows
 
 ```powershell
-powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/download/v0.3.3/install.ps1 | iex"
+powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/download/v0.3.4/install.ps1 | iex"
 ```
 
-安装命令固定读取 `v0.3.3` 正式发布中的脚本；不会跟随内容可能变化的 `latest`（最新版本）地址。
+安装命令固定读取 `v0.3.4` 正式发布中的脚本；不会跟随内容可能变化的 `latest`（最新版本）地址。
 
 ## 更新与卸载
 
@@ -101,7 +105,7 @@ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/y
 
 ```bash
 workflow update
-workflow update --version 0.3.3
+workflow update --version 0.3.4
 ```
 
 更新按需补齐电脑全局命令和当前项目，只直接覆盖项目根 `AGENTS.md`、`.workflow_loop/Template_Repository/`、`.workflow_loop/Standardized_Repository/`，以及 `.workflow_loop/project.json` 中的安装版本字段。更新不创建备份，不回滚已经完成的步骤；当前轮次状态、历史、回退资料、业务代码和正式产物保持不变。失败后重新执行同一命令即可继续补齐。
@@ -147,18 +151,18 @@ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/y
 安装完成后，在当前项目中启动支持读取 `AGENTS.md`（智能体契约文件）的 AI 编码助手，直接用自然语言提出需求：
 
 ```text
-用户：给当前项目增加 CSV 导出功能，并保证原有导出格式不受影响。
+用户：给当前项目增加 CSV（逗号分隔值）导出功能，并保证原有导出格式不受影响。
 ```
 
 之后由 AI 编码助手执行日常流程：
 
 1. 自动运行 `workflow start` 检查当前状态，并根据事实与用户确认本轮工作意图。
 2. 调查现状并推荐四种路线之一，用户确认进入该任务后才启动轮次。
-3. 严格执行每条命令输出的“下一步”，讨论时每次只问用户一个问题。
+3. 严格执行每条命令输出的“下一步”，讨论时每次只问用户一个问题；门禁失败先按完整问题清单修改，不能原样重试，也不能自行拼接或截断命令输出。
 4. 完整研发路线在写代码前完成需求、验收、测试和实施计划；无需开发任务在用户确认讨论完毕后直接执行约定内容。
 5. 把真实结果交给用户核对并确认，再正式收工。
 
-用户不需要手工执行日常 `workflow` 命令；用户只负责描述需求、回答讨论问题、确认安装范围和确认各环节结果。
+用户不需要手工执行日常 `workflow` 命令，但仍需确认工作路线、回答讨论问题、作出产品和验收决定、批准难撤销操作、确认安装范围及确认各环节结果。
 
 ## 命令概览
 
@@ -204,10 +208,10 @@ uv run python -m build
 
 ## 发布正式版本
 
-项目维护者确认当前仓库内容可以直接发布后，在仓库根目录执行下面的命令，并把 `0.3.3` 替换成要发布的新版本号：
+项目维护者确认当前仓库内容可以直接发布后，在仓库根目录执行下面的命令，并把 `0.3.4` 替换成要发布的新版本号：
 
 ```bash
-uv run python scripts/release.py 0.3.3
+uv run python scripts/release.py 0.3.4
 ```
 
 运行这条命令本身就表示维护者接受当前仓库状态并承担跳过本地发布检查的风险。脚本不会再次确认，也不会在本地运行测试、构建或远程版本查询。它依次执行：

{workflow_loop-0.3.3 → workflow_loop-0.3.4}/pyproject.toml

@@ -1,6 +1,6 @@
 [project]
 name = "workflow-loop"
-version = "0.3.3"
+version = "0.3.4"
 description = "为 AI 驱动的软件开发提供有状态、可验证、可回退的工作流管理。"
 readme = "README.md"
 requires-python = ">=3.11"

{workflow_loop-0.3.3 → workflow_loop-0.3.4}/src/workflow_loop/__init__.py

@@ -1,6 +1,6 @@
 # 包版本号，用于 pip/uv 安装时版本匹配
-__version__ = "0.3.3"
+__version__ = "0.3.4"
 # 产品身份标识：workflow --version 输出、安装脚本身份核对和安装事务校验共用同一组常量
-# 本次发布版本为 0.3.3；后续发布使用尚未被 PyPI 占用的新版本号
+# 本次发布版本为 0.3.4；后续发布使用尚未被 PyPI 占用的新版本号
 PRODUCT_NAME = "workflow-loop"
 PRODUCT_IDENTITY = f"{PRODUCT_NAME} {__version__}"

{workflow_loop-0.3.3 → workflow_loop-0.3.4}/src/workflow_loop/data/Standardized_Repository/impl/code_implementation.md

@@ -82,6 +82,6 @@
 - 依赖、状态变化和副作用的位置可以从调用关系中找到。
 - 错误不会被吞掉，失败结果不会被当成成功结果返回。
 - 代码没有实现未确认的产品规则，也没有留下无法解释的占位抽象。
-- 真实文件、类、函数和逻辑已经写入代码实施记录和代码结果。
+- 真实文件、覆盖本轮差异的最终文件行号范围和逻辑已经写入代码实施记录和代码结果。
 - 实施记录中的“工作流编号”“验收主题”等固定字段的标签和值都在同一行；不存在标签单独一行、值写在下一行的格式。
 - 门禁输出已列出全部可独立确认的问题；依赖不成立的检查明确为“未检查”并写真实依赖，所有诊断后只有一条可执行的下一步命令。

{workflow_loop-0.3.3 → workflow_loop-0.3.4}/src/workflow_loop/data/Standardized_Repository/impl/impl.md

@@ -119,9 +119,9 @@ workflow gate impl --prepare-code
 
 代码完成后，根据最终真实代码填写：
 
-1. 每个计划步骤对应的真实文件、精确符号、最终逻辑、数据状态或输出变化和验收条件。
+1. 每个计划步骤对应的真实文件、覆盖真实差异的最终文件行号范围、最终逻辑、数据状态或输出变化和验收条件。行号范围写成 `L18-L57`；局部删除写成 `基线 L18-L31`。同一文件的每个不连续差异块都要被至少一条记录覆盖。
 2. 全部开发检查的命令或方法、范围、真实反馈和是否仍需修改。
-3. 未完成内容；没有时写“暂无”。
+3. 未完成内容；没有时写“状态：无”。有未完成事项时写“状态：有”，并逐项说明事项、原因、影响和下一步；这种状态不能通过实施门禁。
 
 代码计划、实施动作、真实文件差异和代码结果必须一一对应。结果与计划不一致时不能建立“计划与实际差异”章节绕过确认，必须回到代码计划处理。
 

{workflow_loop-0.3.3 → workflow_loop-0.3.4}/src/workflow_loop/data/Template_Repository/impl/impl.md

@@ -90,9 +90,9 @@
 
 ### 3.1 实施动作记录
 
-| 实施顺序 | 对应计划步骤 | 文件 | 类、函数或配置项 | 实际执行的动作 | 当步反馈 | 状态 |
+| 实施顺序 | 对应计划步骤 | 文件 | 代码位置（最终文件） | 实际执行的动作 | 当步反馈 | 状态 |
 |---|---|---|---|---|---|---|
-| 1 | 1 | <具体文件路径> | <精确位置> | <实际增加、删除或修改了什么> | <语法、静态检查或局部运行反馈；尚未检查时写“待检查”> | 已完成 |
+| 1 | 1 | <具体文件路径> | L<起始行>-L<结束行> | <实际增加、删除或修改了什么> | <语法、静态检查或局部运行反馈；尚未检查时写“待检查”> | 已完成 |
 
 ### 3.2 实施中问题与处理
 
@@ -102,15 +102,15 @@
 
 ### 3.3 未完成内容
 
-暂无
+状态：无
 
 ### 3.4 代码结果
 
 #### 3.4.1 实际代码修改
 
-| 对应计划步骤 | 文件 | 类、函数或配置项 | 实际修改的代码逻辑 | 数据、状态或输出的实际变化 | 对应验收条件 |
+| 对应计划步骤 | 文件 | 代码位置（最终文件） | 实际修改的代码逻辑 | 数据、状态或输出的实际变化 | 对应验收条件 |
 |---|---|---|---|---|---|
-| 1 | <具体文件路径> | <具体类、函数或配置项的精确位置> | <根据最终代码填写具体判断、调用和错误处理> | <根据最终代码填写可检查的状态、数据、文件或输出变化> | AC-01 |
+| 1 | <具体文件路径> | L<起始行>-L<结束行> | <根据最终代码填写具体判断、调用和错误处理> | <根据最终代码填写可检查的状态、数据、文件或输出变化> | AC-01 |
 
 #### 3.4.2 开发检查记录
 
@@ -133,16 +133,17 @@
 ## 三、内容边界
 
 - `impl/索引.md` 不能写具体代码修改步骤；这些内容写在对应主题文档中。
-- `impl/<主题文件标识>_实施记录.md` 必须写到具体文件、类、函数或新增位置，不能只写模块名称。
+- `impl/<主题文件标识>_实施记录.md` 的“3.4.1 实际代码修改”必须写到具体文件和最终文件行号范围，例如 `L18-L57`；新增文件也写最终行号范围，局部删除写 `基线 L18-L31`，整文件删除写“删除整个文件”。同一文件有多个不连续差异时，增加多行或使用覆盖全部差异的范围。不能只写模块、组件或页面名称。
 - 固定顺序是“代码计划 -> 代码实施 -> 代码结果”。用户只确认代码计划和代码结果；代码实施按已确认计划连续完成，不增加逐步确认。
 - “实施前计划（代码计划）”写修改前已经确认的方案；“实施后记录（代码实施与代码结果）”先按实际顺序记录动作和反馈，再根据最终代码填写结果，不能复制计划或过程记录代替事实。固定章节包括“实施前计划”“实施后记录”“未决问题”和“未完成内容”，工作顺序是代码计划、代码实施、代码结果。
 - 从零开发的最低实现设计和修改产品的本轮实现决定都写进代码计划；本轮实际架构变化在最终代码设计同步阶段依据真实代码更新。
-- 代码计划、实施动作、真实代码差异集合和代码结果必须一一一致；代码结果必须写具体文件、精确位置、真实逻辑，以及数据、状态或输出变化。
+- 代码计划、实施动作、真实代码差异集合和代码结果必须一一一致；代码结果必须写具体文件、覆盖真实差异的最终文件行号范围、真实逻辑，以及数据、状态或输出变化。
 - 实施文档只绑定验收条件，不依赖尚未生成的测试计划或 `TC`（测试项编号）。
 - 不建立“计划与实际差异”章节。实施需要偏离当前确认计划时，应先停止、更新代码计划并重新取得用户确认；不能先改完再把偏差包装成结果。
 - 实施文档可以记录语法、类型、静态检查或局部运行等开发检查反馈，但这些反馈不是正式测试，不能填写正式测试通过、正式测试失败或主题验收通过。
 - 尚未生成的下游文档只写反引号包裹的普通相对路径和“（待生成）”，文件真实存在后才改成 Markdown 链接。
 - 没有相关内容时写“暂无”，不得编造内容填满表格。
+- “3.3 未完成内容”是固定状态：没有未完成事项时只写“状态：无”；有未完成事项时写“状态：有”，随后用表格逐项写清事项、原因、影响和下一步。状态为“有”时不能通过实施门禁。
 
 ## 四、门禁失败信息