workflow-loop 0.1.0__tar.gz → 0.2.0__tar.gz

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (93) hide show
  1. {workflow_loop-0.1.0/src/workflow_loop.egg-info → workflow_loop-0.2.0}/PKG-INFO +90 -19
  2. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/README.md +88 -18
  3. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/pyproject.toml +2 -2
  4. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/__init__.py +2 -2
  5. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/cli.py +647 -9
  6. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/spec/spec.md +2 -2
  7. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/installer.py +251 -1
  8. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/path_composer.py +4 -2
  9. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/project.py +137 -5
  10. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/state.py +32 -1
  11. {workflow_loop-0.1.0 → workflow_loop-0.2.0/src/workflow_loop.egg-info}/PKG-INFO +90 -19
  12. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop.egg-info/SOURCES.txt +3 -0
  13. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop.egg-info/requires.txt +1 -0
  14. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_installer.py +1 -1
  15. workflow_loop-0.2.0/tests/test_light_task.py +474 -0
  16. workflow_loop-0.2.0/tests/test_maintenance.py +649 -0
  17. workflow_loop-0.2.0/tests/test_maintenance_scripts.py +431 -0
  18. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_path_composer.py +2 -2
  19. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_project.py +2 -1
  20. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_public_project.py +9 -4
  21. workflow_loop-0.2.0/tests/test_release_workflow.py +579 -0
  22. workflow_loop-0.1.0/tests/test_release_workflow.py +0 -345
  23. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/LICENSE +0 -0
  24. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/setup.cfg +0 -0
  25. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/acceptance_records.py +0 -0
  26. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/artifact_paths.py +0 -0
  27. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/artifact_validation.py +0 -0
  28. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/bug_record.py +0 -0
  29. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/acceptance/acceptance.md +0 -0
  30. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/acceptance/acceptance_plan.md +0 -0
  31. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/code_design/code_design.md +0 -0
  32. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/code_design/project_design_init.md +0 -0
  33. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/code_design/revise_code_design.md +0 -0
  34. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/code_design/update_code_design.md +0 -0
  35. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/global/document_writing.md +0 -0
  36. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/global/workflow_lifecycle.md +0 -0
  37. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/impl/code_implementation.md +0 -0
  38. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/impl/impl.md +0 -0
  39. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/qa/test.md +0 -0
  40. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/qa/test_code.md +0 -0
  41. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/qa/test_code_implementation.md +0 -0
  42. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/qa/test_plan.md +0 -0
  43. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/reproduce/reproduce.md +0 -0
  44. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Standardized_Repository/spike/spike.md +0 -0
  45. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Template_Repository/acceptance/acceptance_plan.md +0 -0
  46. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Template_Repository/acceptance/acceptance_result.md +0 -0
  47. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Template_Repository/code_design/code_design.md +0 -0
  48. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Template_Repository/code_design/project_design_init_evidence.md +0 -0
  49. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Template_Repository/impl/impl.md +0 -0
  50. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Template_Repository/qa/test.md +0 -0
  51. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Template_Repository/qa/test_plan.md +0 -0
  52. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Template_Repository/reproduce/reproduce.md +0 -0
  53. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Template_Repository/spec/spec.md +0 -0
  54. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/data/Template_Repository/spike/spike.md +0 -0
  55. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/journal.py +0 -0
  56. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/process_runner.py +0 -0
  57. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/role_doc.py +0 -0
  58. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/rollback.py +0 -0
  59. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/spike_validation.py +0 -0
  60. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/stage_materials.py +0 -0
  61. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/stages/__init__.py +0 -0
  62. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/stages/base.py +0 -0
  63. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/stages/stages.py +0 -0
  64. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/test_entry.py +0 -0
  65. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/test_execution.py +0 -0
  66. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/test_mapping.py +0 -0
  67. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/test_runner.py +0 -0
  68. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/topic.py +0 -0
  69. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/topic_relations.py +0 -0
  70. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/traceability.py +0 -0
  71. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop/verification.py +0 -0
  72. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop.egg-info/dependency_links.txt +0 -0
  73. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop.egg-info/entry_points.txt +0 -0
  74. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/src/workflow_loop.egg-info/top_level.txt +0 -0
  75. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_acceptance_records.py +0 -0
  76. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_architecture_validation.py +0 -0
  77. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_artifact_paths.py +0 -0
  78. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_bug_record.py +0 -0
  79. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_bug_validation.py +0 -0
  80. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_commands.py +0 -0
  81. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_process_runner.py +0 -0
  82. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_rollback.py +0 -0
  83. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_spike_validation.py +0 -0
  84. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_stage_materials.py +0 -0
  85. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_stages.py +0 -0
  86. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_state.py +0 -0
  87. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_test_entry.py +0 -0
  88. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_test_execution.py +0 -0
  89. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_test_mapping.py +0 -0
  90. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_test_runner.py +0 -0
  91. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_topic_relations.py +0 -0
  92. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_traceability.py +0 -0
  93. {workflow_loop-0.1.0 → workflow_loop-0.2.0}/tests/test_verification.py +0 -0
@@ -1,6 +1,6 @@
1
1
  Metadata-Version: 2.4
2
2
  Name: workflow-loop
3
- Version: 0.1.0
3
+ Version: 0.2.0
4
4
  Summary: 为 AI 驱动的软件开发提供有状态、可验证、可回退的工作流管理。
5
5
  Author: yuzyf
6
6
  License-Expression: MIT
@@ -9,6 +9,7 @@ Project-URL: Repository, https://github.com/yuzyf/workflow_loop
9
9
  Requires-Python: >=3.11
10
10
  Description-Content-Type: text/markdown
11
11
  License-File: LICENSE
12
+ Requires-Dist: packaging>=24.0
12
13
  Provides-Extra: dev
13
14
  Requires-Dist: build>=1.2; extra == "dev"
14
15
  Requires-Dist: pytest>=7.0; extra == "dev"
@@ -31,28 +32,29 @@ Workflow Loop 把一次软件修改拆成有顺序的工作环节,并用程序
31
32
  ### 能做什么
32
33
 
33
34
  - **保存进度**:在项目的 `.workflow_loop/` 目录保存当前工作环节、确认状态和机器执行记录,下一次对话可以从真实状态继续。
34
- - **控制推进**:每个环节依次经过讨论完成、程序检查和用户确认三道门,前一步不满足时不能进入下一步。
35
+ - **控制推进**:完整研发任务的每个环节依次经过讨论完成、程序检查和用户确认三道门;无需开发任务走独立的讨论、执行、结果确认简单流程。
35
36
  - **连接交付证据**:把产品设计、验收条件、测试项、实施记录和最终结果放进同一条可追踪链路。
36
37
  - **保护项目修改**:实施前保存计划修改文件的原内容;需要退回上游或作废整轮时,按工作流规则使旧结果失效或恢复受管内容。
37
- - **管理三种工作**:分别处理从零创建、修改现有产品和修复缺陷,按工作类型生成对应的环节路径。
38
+ - **管理四种工作**:分别处理从零创建、修改现有产品、修复缺陷和无需开发任务;只有前三种生成研发环节路径。
38
39
 
39
40
  ### 不做什么
40
41
 
41
42
  - 不替代 AI 编码助手、版本控制系统或持续集成服务,也不替用户决定产品需求是否正确。
42
43
  - 不允许跳过必要讨论、程序检查或用户确认,把未经验证的内容当成交付结果。
43
- - 不自动安装 Python,不自动升级或修复已有的异常安装,也不同时维护多个产品版本。
44
- - 当前只支持 `from_scratch`(从零创建)、`product_change`(修改现有产品)和 `bugfix`(修复缺陷)三种正式工作意图。
44
+ - 不自动安装 Python,不静默更新,也不把残缺项目当成完整安装覆盖;更新必须由用户明确执行并确认。
45
+ - `light_task`(无需开发任务)不能用于修改正式产品规则、产品代码、测试代码,或影响运行、构建、测试、部署和依赖的配置;发现需要开发时必须结束简单轮次,经用户确认后改走完整研发路线。
45
46
 
46
47
  ## 工作流程
47
48
 
48
- `intent`(工作意图)决定一轮工作需要经过哪些环节。各意图的具体环节不同,但每个需要正式确认的环节都遵守同一组三道门。
49
+ `intent`(工作意图)决定一轮工作走完整研发流程还是简单流程。AI 先调查并推荐路线,用户确认要进入哪种任务后才能启动。
49
50
 
50
51
  ```mermaid
51
52
  flowchart TD
52
- A["用户提出需求"] --> B{"选择工作意图"}
53
+ A["用户提出需求"] --> B{"AI 推荐路线,用户确认"}
53
54
  B -->|"from_scratch:从零创建"| C1["生成从零开发路径"]
54
55
  B -->|"product_change:修改产品"| C2["生成产品修改路径"]
55
56
  B -->|"bugfix:修复缺陷"| C3["生成缺陷修复路径"]
57
+ B -->|"light_task:无需开发任务"| L1["逐个问题讨论,AI 给出建议"]
56
58
  C1 --> D["进入当前工作环节"]
57
59
  C2 --> D
58
60
  C3 --> D
@@ -64,14 +66,21 @@ flowchart TD
64
66
  I --> J{"还有下一环节?"}
65
67
  J -->|"有"| D
66
68
  J -->|"没有"| K["记录完成并正式收工"]
69
+ L1 --> L2["用户确认讨论完毕"]
70
+ L2 --> L3["执行约定任务"]
71
+ L3 --> L4["核对并展示真实结果"]
72
+ L4 --> L5["用户确认结果"]
73
+ L5 --> K
67
74
  ```
68
75
 
69
- 三道门分别解决不同问题:
76
+ 完整研发路线的三道门分别解决不同问题:
70
77
 
71
78
  1. **讨论完成**:需求、限制和实施计划已经与用户逐项达成共识,允许开始写正式产物。
72
79
  2. **程序检查**:程序核对必需文件、结构、关联、代码变化或测试记录等可机械判断的事实。
73
80
  3. **用户确认**:用户确认实际内容符合意图,程序记录确认后才进入下一环节。
74
81
 
82
+ `light_task`(无需开发任务)是一类任务,不是“改文档、提交、发布”三个固定选项。它也要求先调查和讨论:AI 用第一性原理梳理需求,每次只问一个问题并给出建议,用户确认讨论完毕后才执行。执行 `commit`(本地 Git 提交)、`push`(推送远端)、发布、删除等难撤销操作前,要按准确操作单独确认;“提交代码”必须先问清是只 `commit`,还是还要 `push`。完成后,AI 按约定方法展示真实结果,用户确认后收工。简单流程不创建研发阶段、三道门、固定全量测试或回退副本;失败或作废时保留真实现场并说明结果,不自动回滚。
83
+
75
84
  ## 环境要求
76
85
 
77
86
  - Python 3.11 或更高版本;安装脚本只检查版本,不会代替用户安装 Python。
@@ -80,29 +89,76 @@ flowchart TD
80
89
  - 安装时能够访问 GitHub 和 PyPI(Python 公共软件包仓库)。
81
90
  - 执行安装命令前,先进入要由 Workflow Loop 管理的项目根目录。
82
91
 
83
- ## 安装 0.1.0
92
+ ## 安装 0.2.0
84
93
 
85
94
  安装器先进行只读检查并列出项目侧和电脑侧可能发生的全部持久修改。用户确认一次后,安装器才安装或复用全局 `workflow` 命令,并把智能体契约、产物模板和工作规范写入当前项目;用户取消或安装失败时不会留下只完成一部分的安装。
86
95
 
87
96
  ### macOS
88
97
 
89
98
  ```bash
90
- curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.1.0/install.sh | bash
99
+ curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.2.0/install.sh | bash
91
100
  ```
92
101
 
93
102
  ### Linux
94
103
 
95
104
  ```bash
96
- curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.1.0/install.sh | bash
105
+ curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.2.0/install.sh | bash
97
106
  ```
98
107
 
99
108
  ### 原生 Windows
100
109
 
101
110
  ```powershell
102
- powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/download/v0.1.0/install.ps1 | iex"
111
+ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/download/v0.2.0/install.ps1 | iex"
112
+ ```
113
+
114
+ 安装命令固定读取 `v0.2.0` 正式发布中的脚本;不会跟随内容可能变化的 `latest`(最新版本)地址。
115
+
116
+ ## 更新与卸载
117
+
118
+ 下面的维护命令都由用户从项目根目录主动执行,并且在持久修改前只确认一次。`workflow update` 默认核对 PyPI 和 GitHub Release 后更新到双方一致的最新正式版本;`--version` 后的版本号必须是比电脑全局命令和当前项目都不低的正式版本。
119
+
120
+ ```bash
121
+ workflow update
122
+ workflow update --version 0.2.0
103
123
  ```
104
124
 
105
- 安装命令固定读取 `v0.1.0` 正式发布中的脚本;不会跟随内容可能变化的 `latest`(最新版本)地址。
125
+ 更新按需补齐电脑全局命令和当前项目,只直接覆盖项目根 `AGENTS.md`、`.workflow_loop/Template_Repository/`、`.workflow_loop/Standardized_Repository/`,以及 `.workflow_loop/project.json` 中的安装版本字段。更新不创建备份,不回滚已经完成的步骤;当前轮次状态、历史、回退资料、业务代码和正式产物保持不变。失败后重新执行同一命令即可继续补齐。
126
+
127
+ 没有 `workflow update` 命令的旧版本,可从项目根目录直接运行最新正式发布提供的脚本:
128
+
129
+ ```bash
130
+ # macOS / Linux
131
+ curl -fsSL https://github.com/yuzyf/workflow_loop/releases/latest/download/update.sh | bash
132
+ ```
133
+
134
+ ```powershell
135
+ # Windows PowerShell 5.1 / 7
136
+ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/latest/download/update.ps1 | iex"
137
+ ```
138
+
139
+ 项目卸载和电脑全局命令卸载是两个独立动作:
140
+
141
+ ```bash
142
+ # 强制删除当前项目的 AGENTS.md、整个 .workflow_loop/ 和安装事务残留
143
+ workflow uninstall
144
+
145
+ # 只删除电脑全局命令;不会扫描或删除任何项目
146
+ workflow uninstall --global
147
+ ```
148
+
149
+ 项目卸载不检查当前轮次处于进行中、已完成还是已作废,也不恢复本轮业务修改;删除没有备份。全局卸载只清理全局工具和能够由安装来源记录证明是 Workflow Loop 添加的 `PATH`(命令搜索路径)项,来源不明或用户原本就有的 PATH 项会保留并报告。全局命令删除后,其它已安装项目仍保留,但在重新安装全局命令前不能运行 `workflow`。
150
+
151
+ 旧版本没有公开卸载命令时,可从项目根运行 `uninstall.sh` 或 `uninstall.ps1` 的最新正式发布资产;两个脚本默认只卸载当前项目,不会先升级或删除电脑全局命令。
152
+
153
+ ```bash
154
+ # macOS / Linux 旧版本项目卸载
155
+ curl -fsSL https://github.com/yuzyf/workflow_loop/releases/latest/download/uninstall.sh | bash
156
+ ```
157
+
158
+ ```powershell
159
+ # Windows PowerShell 5.1 / 7 旧版本项目卸载
160
+ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/latest/download/uninstall.ps1 | iex"
161
+ ```
106
162
 
107
163
  ## 最小使用示例
108
164
 
@@ -115,9 +171,10 @@ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/y
115
171
  之后由 AI 编码助手执行日常流程:
116
172
 
117
173
  1. 自动运行 `workflow start` 检查当前状态,并根据事实与用户确认本轮工作意图。
118
- 2. 严格执行每条命令输出的“下一步”,每次只向用户确认一个问题。
119
- 3. 在写代码前完成需求、验收、测试和实施计划,在受保护的回退基线上实施修改。
120
- 4. 使用机器记录完成测试,经过主题验收和最终全量回归后正式收工。
174
+ 2. 调查现状并推荐四种路线之一,用户确认进入该任务后才启动轮次。
175
+ 3. 严格执行每条命令输出的“下一步”,讨论时每次只问用户一个问题。
176
+ 4. 完整研发路线在写代码前完成需求、验收、测试和实施计划;无需开发任务在用户确认讨论完毕后直接执行约定内容。
177
+ 5. 把真实结果交给用户核对并确认,再正式收工。
121
178
 
122
179
  用户不需要手工执行日常 `workflow` 命令;用户只负责描述需求、回答讨论问题、确认安装范围和确认各环节结果。
123
180
 
@@ -127,8 +184,11 @@ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/y
127
184
 
128
185
  | 命令 | 中文含义 |
129
186
  |---|---|
130
- | `workflow start` | 检查当前轮次;没有进行中的工作时列出三种工作意图 |
131
- | `workflow start --intent <intent>` | 用指定工作意图开始一轮;`<intent>` 表示 `from_scratch`、`product_change` 或 `bugfix` |
187
+ | `workflow start` | 检查当前轮次;没有进行中的工作时列出四种工作意图 |
188
+ | `workflow start --intent <intent>` | 用户确认路线后开始一轮;`<intent>` 表示 `from_scratch`、`product_change`、`bugfix` 或 `light_task` |
189
+ | `workflow light --discuss-done --task <任务> --verification <方法>` | 记录无需开发任务已讨论完毕;`<任务>` 是约定范围,`<方法>` 是结果核对方法 |
190
+ | `workflow light --approve-action <准确操作>` | 记录用户单独批准的一项难撤销操作,只记录批准,不自动执行 |
191
+ | `workflow light --confirmed --result <实际结果>` | 记录用户已经核对无需开发任务的真实结果 |
132
192
  | `workflow discuss` | 加载当前环节必须遵守的模板、规范和项目材料 |
133
193
  | `workflow gate <stage> --discuss-done` | 通过当前环节的讨论完成门;`<stage>` 表示当前环节标识 |
134
194
  | `workflow gate <stage>` | 让程序检查当前环节的文件、结构和可验证事实 |
@@ -137,8 +197,12 @@ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/y
137
197
  | `workflow test ...` | 登记统一测试入口、准备测试项或执行受控测试 |
138
198
  | `workflow acceptance ...` | 记录需要用户判断的主题验收回答 |
139
199
  | `workflow return --to <stage> --reason <reason>` | 带具体原因退回上游环节,并使受影响的下游结果失效;`<reason>` 表示退回原因 |
140
- | `workflow abort` | 作废当前整轮,并按回退清单恢复受管内容 |
200
+ | `workflow abort` | 作废完整研发轮次,并按回退清单恢复受管内容 |
201
+ | `workflow abort --summary <真实状态>` | 作废无需开发任务,保留已发生状态并记录实际完成、未执行或失败内容 |
141
202
  | `workflow done` | 在最后一个环节确认后记录整轮完成并清理临时回退副本 |
203
+ | `workflow update [--version <version>]` | 更新电脑全局命令和当前项目;`<version>` 表示可选的目标正式版本 |
204
+ | `workflow uninstall` | 不管当前轮次状态,强制删除当前项目固定的 Workflow Loop 管理内容 |
205
+ | `workflow uninstall --global` | 只卸载电脑全局 Workflow Loop 命令和来源明确的 PATH 项,不扫描项目 |
142
206
 
143
207
  可运行 `workflow --help` 查看当前版本提供的完整参数。
144
208
 
@@ -169,6 +233,10 @@ workflow_loop/
169
233
  ├── impl/ 实施计划与实施记录
170
234
  ├── install.sh macOS 和 Linux 安装脚本
171
235
  ├── install.ps1 Windows 安装脚本
236
+ ├── update.sh macOS 和 Linux 旧版本更新脚本
237
+ ├── update.ps1 Windows 旧版本更新脚本
238
+ ├── uninstall.sh macOS 和 Linux 旧版本卸载脚本
239
+ ├── uninstall.ps1 Windows 旧版本卸载脚本
172
240
  ├── CONTEXT.md 产品术语、规则和限制
173
241
  └── DESIGN.md 实现设计文档
174
242
  ```
@@ -177,6 +245,9 @@ workflow_loop/
177
245
 
178
246
  - [产品总说明](spec/产品总说明.md):产品目的、范围、使用者和通用规则。
179
247
  - [安装到项目](spec/功能_安装到项目.md):支持环境、安装行为、异常处理和公开发布要求。
248
+ - [更新已安装项目](spec/功能_更新已安装项目.md):目标版本、覆盖范围、保留范围和失败重试规则。
249
+ - [卸载 Workflow Loop](spec/功能_卸载_Workflow_Loop.md):项目强制卸载和电脑全局卸载的独立边界。
250
+ - [处理无需开发任务](spec/功能_处理无需开发任务.md):简单流程适用边界、逐项确认、完成和异常处理规则。
180
251
  - [代码架构设计](spec/代码架构设计.md):功能到代码模块、状态和外部依赖的对应关系。
181
252
  - [实现设计文档](DESIGN.md):命令、数据模型、工作意图、阶段路径和门禁的实现形态。
182
253
  - [产品事实与约束](CONTEXT.md):当前有效的术语、约束和设计决策。
@@ -14,28 +14,29 @@ Workflow Loop 把一次软件修改拆成有顺序的工作环节,并用程序
14
14
  ### 能做什么
15
15
 
16
16
  - **保存进度**:在项目的 `.workflow_loop/` 目录保存当前工作环节、确认状态和机器执行记录,下一次对话可以从真实状态继续。
17
- - **控制推进**:每个环节依次经过讨论完成、程序检查和用户确认三道门,前一步不满足时不能进入下一步。
17
+ - **控制推进**:完整研发任务的每个环节依次经过讨论完成、程序检查和用户确认三道门;无需开发任务走独立的讨论、执行、结果确认简单流程。
18
18
  - **连接交付证据**:把产品设计、验收条件、测试项、实施记录和最终结果放进同一条可追踪链路。
19
19
  - **保护项目修改**:实施前保存计划修改文件的原内容;需要退回上游或作废整轮时,按工作流规则使旧结果失效或恢复受管内容。
20
- - **管理三种工作**:分别处理从零创建、修改现有产品和修复缺陷,按工作类型生成对应的环节路径。
20
+ - **管理四种工作**:分别处理从零创建、修改现有产品、修复缺陷和无需开发任务;只有前三种生成研发环节路径。
21
21
 
22
22
  ### 不做什么
23
23
 
24
24
  - 不替代 AI 编码助手、版本控制系统或持续集成服务,也不替用户决定产品需求是否正确。
25
25
  - 不允许跳过必要讨论、程序检查或用户确认,把未经验证的内容当成交付结果。
26
- - 不自动安装 Python,不自动升级或修复已有的异常安装,也不同时维护多个产品版本。
27
- - 当前只支持 `from_scratch`(从零创建)、`product_change`(修改现有产品)和 `bugfix`(修复缺陷)三种正式工作意图。
26
+ - 不自动安装 Python,不静默更新,也不把残缺项目当成完整安装覆盖;更新必须由用户明确执行并确认。
27
+ - `light_task`(无需开发任务)不能用于修改正式产品规则、产品代码、测试代码,或影响运行、构建、测试、部署和依赖的配置;发现需要开发时必须结束简单轮次,经用户确认后改走完整研发路线。
28
28
 
29
29
  ## 工作流程
30
30
 
31
- `intent`(工作意图)决定一轮工作需要经过哪些环节。各意图的具体环节不同,但每个需要正式确认的环节都遵守同一组三道门。
31
+ `intent`(工作意图)决定一轮工作走完整研发流程还是简单流程。AI 先调查并推荐路线,用户确认要进入哪种任务后才能启动。
32
32
 
33
33
  ```mermaid
34
34
  flowchart TD
35
- A["用户提出需求"] --> B{"选择工作意图"}
35
+ A["用户提出需求"] --> B{"AI 推荐路线,用户确认"}
36
36
  B -->|"from_scratch:从零创建"| C1["生成从零开发路径"]
37
37
  B -->|"product_change:修改产品"| C2["生成产品修改路径"]
38
38
  B -->|"bugfix:修复缺陷"| C3["生成缺陷修复路径"]
39
+ B -->|"light_task:无需开发任务"| L1["逐个问题讨论,AI 给出建议"]
39
40
  C1 --> D["进入当前工作环节"]
40
41
  C2 --> D
41
42
  C3 --> D
@@ -47,14 +48,21 @@ flowchart TD
47
48
  I --> J{"还有下一环节?"}
48
49
  J -->|"有"| D
49
50
  J -->|"没有"| K["记录完成并正式收工"]
51
+ L1 --> L2["用户确认讨论完毕"]
52
+ L2 --> L3["执行约定任务"]
53
+ L3 --> L4["核对并展示真实结果"]
54
+ L4 --> L5["用户确认结果"]
55
+ L5 --> K
50
56
  ```
51
57
 
52
- 三道门分别解决不同问题:
58
+ 完整研发路线的三道门分别解决不同问题:
53
59
 
54
60
  1. **讨论完成**:需求、限制和实施计划已经与用户逐项达成共识,允许开始写正式产物。
55
61
  2. **程序检查**:程序核对必需文件、结构、关联、代码变化或测试记录等可机械判断的事实。
56
62
  3. **用户确认**:用户确认实际内容符合意图,程序记录确认后才进入下一环节。
57
63
 
64
+ `light_task`(无需开发任务)是一类任务,不是“改文档、提交、发布”三个固定选项。它也要求先调查和讨论:AI 用第一性原理梳理需求,每次只问一个问题并给出建议,用户确认讨论完毕后才执行。执行 `commit`(本地 Git 提交)、`push`(推送远端)、发布、删除等难撤销操作前,要按准确操作单独确认;“提交代码”必须先问清是只 `commit`,还是还要 `push`。完成后,AI 按约定方法展示真实结果,用户确认后收工。简单流程不创建研发阶段、三道门、固定全量测试或回退副本;失败或作废时保留真实现场并说明结果,不自动回滚。
65
+
58
66
  ## 环境要求
59
67
 
60
68
  - Python 3.11 或更高版本;安装脚本只检查版本,不会代替用户安装 Python。
@@ -63,29 +71,76 @@ flowchart TD
63
71
  - 安装时能够访问 GitHub 和 PyPI(Python 公共软件包仓库)。
64
72
  - 执行安装命令前,先进入要由 Workflow Loop 管理的项目根目录。
65
73
 
66
- ## 安装 0.1.0
74
+ ## 安装 0.2.0
67
75
 
68
76
  安装器先进行只读检查并列出项目侧和电脑侧可能发生的全部持久修改。用户确认一次后,安装器才安装或复用全局 `workflow` 命令,并把智能体契约、产物模板和工作规范写入当前项目;用户取消或安装失败时不会留下只完成一部分的安装。
69
77
 
70
78
  ### macOS
71
79
 
72
80
  ```bash
73
- curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.1.0/install.sh | bash
81
+ curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.2.0/install.sh | bash
74
82
  ```
75
83
 
76
84
  ### Linux
77
85
 
78
86
  ```bash
79
- curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.1.0/install.sh | bash
87
+ curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.2.0/install.sh | bash
80
88
  ```
81
89
 
82
90
  ### 原生 Windows
83
91
 
84
92
  ```powershell
85
- powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/download/v0.1.0/install.ps1 | iex"
93
+ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/download/v0.2.0/install.ps1 | iex"
94
+ ```
95
+
96
+ 安装命令固定读取 `v0.2.0` 正式发布中的脚本;不会跟随内容可能变化的 `latest`(最新版本)地址。
97
+
98
+ ## 更新与卸载
99
+
100
+ 下面的维护命令都由用户从项目根目录主动执行,并且在持久修改前只确认一次。`workflow update` 默认核对 PyPI 和 GitHub Release 后更新到双方一致的最新正式版本;`--version` 后的版本号必须是比电脑全局命令和当前项目都不低的正式版本。
101
+
102
+ ```bash
103
+ workflow update
104
+ workflow update --version 0.2.0
86
105
  ```
87
106
 
88
- 安装命令固定读取 `v0.1.0` 正式发布中的脚本;不会跟随内容可能变化的 `latest`(最新版本)地址。
107
+ 更新按需补齐电脑全局命令和当前项目,只直接覆盖项目根 `AGENTS.md`、`.workflow_loop/Template_Repository/`、`.workflow_loop/Standardized_Repository/`,以及 `.workflow_loop/project.json` 中的安装版本字段。更新不创建备份,不回滚已经完成的步骤;当前轮次状态、历史、回退资料、业务代码和正式产物保持不变。失败后重新执行同一命令即可继续补齐。
108
+
109
+ 没有 `workflow update` 命令的旧版本,可从项目根目录直接运行最新正式发布提供的脚本:
110
+
111
+ ```bash
112
+ # macOS / Linux
113
+ curl -fsSL https://github.com/yuzyf/workflow_loop/releases/latest/download/update.sh | bash
114
+ ```
115
+
116
+ ```powershell
117
+ # Windows PowerShell 5.1 / 7
118
+ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/latest/download/update.ps1 | iex"
119
+ ```
120
+
121
+ 项目卸载和电脑全局命令卸载是两个独立动作:
122
+
123
+ ```bash
124
+ # 强制删除当前项目的 AGENTS.md、整个 .workflow_loop/ 和安装事务残留
125
+ workflow uninstall
126
+
127
+ # 只删除电脑全局命令;不会扫描或删除任何项目
128
+ workflow uninstall --global
129
+ ```
130
+
131
+ 项目卸载不检查当前轮次处于进行中、已完成还是已作废,也不恢复本轮业务修改;删除没有备份。全局卸载只清理全局工具和能够由安装来源记录证明是 Workflow Loop 添加的 `PATH`(命令搜索路径)项,来源不明或用户原本就有的 PATH 项会保留并报告。全局命令删除后,其它已安装项目仍保留,但在重新安装全局命令前不能运行 `workflow`。
132
+
133
+ 旧版本没有公开卸载命令时,可从项目根运行 `uninstall.sh` 或 `uninstall.ps1` 的最新正式发布资产;两个脚本默认只卸载当前项目,不会先升级或删除电脑全局命令。
134
+
135
+ ```bash
136
+ # macOS / Linux 旧版本项目卸载
137
+ curl -fsSL https://github.com/yuzyf/workflow_loop/releases/latest/download/uninstall.sh | bash
138
+ ```
139
+
140
+ ```powershell
141
+ # Windows PowerShell 5.1 / 7 旧版本项目卸载
142
+ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/latest/download/uninstall.ps1 | iex"
143
+ ```
89
144
 
90
145
  ## 最小使用示例
91
146
 
@@ -98,9 +153,10 @@ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/y
98
153
  之后由 AI 编码助手执行日常流程:
99
154
 
100
155
  1. 自动运行 `workflow start` 检查当前状态,并根据事实与用户确认本轮工作意图。
101
- 2. 严格执行每条命令输出的“下一步”,每次只向用户确认一个问题。
102
- 3. 在写代码前完成需求、验收、测试和实施计划,在受保护的回退基线上实施修改。
103
- 4. 使用机器记录完成测试,经过主题验收和最终全量回归后正式收工。
156
+ 2. 调查现状并推荐四种路线之一,用户确认进入该任务后才启动轮次。
157
+ 3. 严格执行每条命令输出的“下一步”,讨论时每次只问用户一个问题。
158
+ 4. 完整研发路线在写代码前完成需求、验收、测试和实施计划;无需开发任务在用户确认讨论完毕后直接执行约定内容。
159
+ 5. 把真实结果交给用户核对并确认,再正式收工。
104
160
 
105
161
  用户不需要手工执行日常 `workflow` 命令;用户只负责描述需求、回答讨论问题、确认安装范围和确认各环节结果。
106
162
 
@@ -110,8 +166,11 @@ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/y
110
166
 
111
167
  | 命令 | 中文含义 |
112
168
  |---|---|
113
- | `workflow start` | 检查当前轮次;没有进行中的工作时列出三种工作意图 |
114
- | `workflow start --intent <intent>` | 用指定工作意图开始一轮;`<intent>` 表示 `from_scratch`、`product_change` 或 `bugfix` |
169
+ | `workflow start` | 检查当前轮次;没有进行中的工作时列出四种工作意图 |
170
+ | `workflow start --intent <intent>` | 用户确认路线后开始一轮;`<intent>` 表示 `from_scratch`、`product_change`、`bugfix` 或 `light_task` |
171
+ | `workflow light --discuss-done --task <任务> --verification <方法>` | 记录无需开发任务已讨论完毕;`<任务>` 是约定范围,`<方法>` 是结果核对方法 |
172
+ | `workflow light --approve-action <准确操作>` | 记录用户单独批准的一项难撤销操作,只记录批准,不自动执行 |
173
+ | `workflow light --confirmed --result <实际结果>` | 记录用户已经核对无需开发任务的真实结果 |
115
174
  | `workflow discuss` | 加载当前环节必须遵守的模板、规范和项目材料 |
116
175
  | `workflow gate <stage> --discuss-done` | 通过当前环节的讨论完成门;`<stage>` 表示当前环节标识 |
117
176
  | `workflow gate <stage>` | 让程序检查当前环节的文件、结构和可验证事实 |
@@ -120,8 +179,12 @@ powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/y
120
179
  | `workflow test ...` | 登记统一测试入口、准备测试项或执行受控测试 |
121
180
  | `workflow acceptance ...` | 记录需要用户判断的主题验收回答 |
122
181
  | `workflow return --to <stage> --reason <reason>` | 带具体原因退回上游环节,并使受影响的下游结果失效;`<reason>` 表示退回原因 |
123
- | `workflow abort` | 作废当前整轮,并按回退清单恢复受管内容 |
182
+ | `workflow abort` | 作废完整研发轮次,并按回退清单恢复受管内容 |
183
+ | `workflow abort --summary <真实状态>` | 作废无需开发任务,保留已发生状态并记录实际完成、未执行或失败内容 |
124
184
  | `workflow done` | 在最后一个环节确认后记录整轮完成并清理临时回退副本 |
185
+ | `workflow update [--version <version>]` | 更新电脑全局命令和当前项目;`<version>` 表示可选的目标正式版本 |
186
+ | `workflow uninstall` | 不管当前轮次状态,强制删除当前项目固定的 Workflow Loop 管理内容 |
187
+ | `workflow uninstall --global` | 只卸载电脑全局 Workflow Loop 命令和来源明确的 PATH 项,不扫描项目 |
125
188
 
126
189
  可运行 `workflow --help` 查看当前版本提供的完整参数。
127
190
 
@@ -152,6 +215,10 @@ workflow_loop/
152
215
  ├── impl/ 实施计划与实施记录
153
216
  ├── install.sh macOS 和 Linux 安装脚本
154
217
  ├── install.ps1 Windows 安装脚本
218
+ ├── update.sh macOS 和 Linux 旧版本更新脚本
219
+ ├── update.ps1 Windows 旧版本更新脚本
220
+ ├── uninstall.sh macOS 和 Linux 旧版本卸载脚本
221
+ ├── uninstall.ps1 Windows 旧版本卸载脚本
155
222
  ├── CONTEXT.md 产品术语、规则和限制
156
223
  └── DESIGN.md 实现设计文档
157
224
  ```
@@ -160,6 +227,9 @@ workflow_loop/
160
227
 
161
228
  - [产品总说明](spec/产品总说明.md):产品目的、范围、使用者和通用规则。
162
229
  - [安装到项目](spec/功能_安装到项目.md):支持环境、安装行为、异常处理和公开发布要求。
230
+ - [更新已安装项目](spec/功能_更新已安装项目.md):目标版本、覆盖范围、保留范围和失败重试规则。
231
+ - [卸载 Workflow Loop](spec/功能_卸载_Workflow_Loop.md):项目强制卸载和电脑全局卸载的独立边界。
232
+ - [处理无需开发任务](spec/功能_处理无需开发任务.md):简单流程适用边界、逐项确认、完成和异常处理规则。
163
233
  - [代码架构设计](spec/代码架构设计.md):功能到代码模块、状态和外部依赖的对应关系。
164
234
  - [实现设计文档](DESIGN.md):命令、数据模型、工作意图、阶段路径和门禁的实现形态。
165
235
  - [产品事实与约束](CONTEXT.md):当前有效的术语、约束和设计决策。
@@ -1,13 +1,13 @@
1
1
  [project]
2
2
  name = "workflow-loop"
3
- version = "0.1.0"
3
+ version = "0.2.0"
4
4
  description = "为 AI 驱动的软件开发提供有状态、可验证、可回退的工作流管理。"
5
5
  readme = "README.md"
6
6
  requires-python = ">=3.11"
7
7
  license = "MIT"
8
8
  license-files = ["LICENSE"]
9
9
  authors = [{ name = "yuzyf" }]
10
- dependencies = []
10
+ dependencies = ["packaging>=24.0"]
11
11
 
12
12
  [project.scripts]
13
13
  workflow = "workflow_loop.cli:main"
@@ -1,6 +1,6 @@
1
1
  # 包版本号,用于 pip/uv 安装时版本匹配
2
- __version__ = "0.1.0"
2
+ __version__ = "0.2.0"
3
3
  # 产品身份标识:workflow --version 输出、安装脚本身份核对和安装事务校验共用同一组常量
4
- # 本次发布版本为 0.1.0;后续发布使用尚未被 PyPI 占用的新版本号
4
+ # 本次发布版本为 0.2.0;后续发布使用尚未被 PyPI 占用的新版本号
5
5
  PRODUCT_NAME = "workflow-loop"
6
6
  PRODUCT_IDENTITY = f"{PRODUCT_NAME} {__version__}"