workflow-loop 0.1.0__tar.gz → 0.3.1__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.
- workflow_loop-0.3.1/PKG-INFO +280 -0
- workflow_loop-0.3.1/README.md +261 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/pyproject.toml +2 -2
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/__init__.py +2 -2
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/acceptance_records.py +4 -5
- workflow_loop-0.3.1/src/workflow_loop/artifact_validation.py +2528 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/cli.py +2028 -219
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/acceptance/acceptance_plan.md +13 -5
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/code_design/project_design_init.md +34 -4
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/global/workflow_lifecycle.md +16 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/impl/code_implementation.md +7 -10
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/impl/impl.md +18 -16
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/qa/test.md +11 -4
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/qa/test_code.md +12 -4
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/qa/test_code_implementation.md +3 -2
- workflow_loop-0.3.1/src/workflow_loop/data/Standardized_Repository/qa/test_plan.md +81 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/spec/spec.md +16 -4
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Template_Repository/acceptance/acceptance_plan.md +18 -9
- workflow_loop-0.3.1/src/workflow_loop/data/Template_Repository/code_design/project_design_init_evidence.md +72 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Template_Repository/impl/impl.md +18 -14
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Template_Repository/qa/test.md +12 -4
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Template_Repository/qa/test_plan.md +16 -15
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Template_Repository/spec/spec.md +9 -5
- workflow_loop-0.3.1/src/workflow_loop/diagnostics.py +458 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/installer.py +251 -1
- workflow_loop-0.3.1/src/workflow_loop/markdown_links.py +595 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/path_composer.py +12 -10
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/project.py +137 -5
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/role_doc.py +4 -3
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/rollback.py +392 -26
- workflow_loop-0.3.1/src/workflow_loop/snapshots.py +207 -0
- workflow_loop-0.3.1/src/workflow_loop/stages/stages.py +1439 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/state.py +119 -1
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/test_execution.py +354 -78
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/test_mapping.py +375 -42
- workflow_loop-0.3.1/src/workflow_loop/test_report.py +371 -0
- workflow_loop-0.3.1/src/workflow_loop/topic_relations.py +302 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/traceability.py +53 -21
- workflow_loop-0.3.1/src/workflow_loop/verification.py +1796 -0
- workflow_loop-0.3.1/src/workflow_loop.egg-info/PKG-INFO +280 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop.egg-info/SOURCES.txt +16 -1
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop.egg-info/requires.txt +2 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_acceptance_records.py +58 -4
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_architecture_validation.py +93 -1
- workflow_loop-0.3.1/tests/test_commands.py +978 -0
- workflow_loop-0.3.1/tests/test_current_workflow_contracts.py +636 -0
- workflow_loop-0.3.1/tests/test_diagnostics.py +216 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_installer.py +1 -1
- workflow_loop-0.3.1/tests/test_light_task.py +474 -0
- workflow_loop-0.3.1/tests/test_maintenance.py +654 -0
- workflow_loop-0.3.1/tests/test_maintenance_scripts.py +431 -0
- workflow_loop-0.3.1/tests/test_markdown_links.py +245 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_path_composer.py +7 -7
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_project.py +2 -1
- workflow_loop-0.3.1/tests/test_project_design_init.py +201 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_public_project.py +11 -4
- workflow_loop-0.3.1/tests/test_release_script.py +256 -0
- workflow_loop-0.3.1/tests/test_release_workflow.py +582 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_rollback.py +219 -9
- workflow_loop-0.3.1/tests/test_snapshots.py +108 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_stages.py +217 -19
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_state.py +97 -3
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_test_execution.py +254 -38
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_test_mapping.py +157 -21
- workflow_loop-0.3.1/tests/test_test_report.py +255 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_topic_relations.py +82 -1
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_traceability.py +137 -12
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_verification.py +420 -2
- workflow_loop-0.3.1/tests/test_workflow_acceptance.py +284 -0
- workflow_loop-0.1.0/PKG-INFO +0 -187
- workflow_loop-0.1.0/README.md +0 -170
- workflow_loop-0.1.0/src/workflow_loop/artifact_validation.py +0 -1738
- workflow_loop-0.1.0/src/workflow_loop/data/Standardized_Repository/qa/test_plan.md +0 -160
- workflow_loop-0.1.0/src/workflow_loop/data/Template_Repository/code_design/project_design_init_evidence.md +0 -39
- workflow_loop-0.1.0/src/workflow_loop/stages/stages.py +0 -1191
- workflow_loop-0.1.0/src/workflow_loop/topic_relations.py +0 -202
- workflow_loop-0.1.0/src/workflow_loop/verification.py +0 -971
- workflow_loop-0.1.0/src/workflow_loop.egg-info/PKG-INFO +0 -187
- workflow_loop-0.1.0/tests/test_commands.py +0 -391
- workflow_loop-0.1.0/tests/test_release_workflow.py +0 -345
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/LICENSE +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/setup.cfg +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/artifact_paths.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/bug_record.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/acceptance/acceptance.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/code_design/code_design.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/code_design/revise_code_design.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/code_design/update_code_design.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/global/document_writing.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/reproduce/reproduce.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Standardized_Repository/spike/spike.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Template_Repository/acceptance/acceptance_result.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Template_Repository/code_design/code_design.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Template_Repository/reproduce/reproduce.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/data/Template_Repository/spike/spike.md +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/journal.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/process_runner.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/spike_validation.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/stage_materials.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/stages/__init__.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/stages/base.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/test_entry.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/test_runner.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop/topic.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop.egg-info/dependency_links.txt +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop.egg-info/entry_points.txt +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/src/workflow_loop.egg-info/top_level.txt +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_artifact_paths.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_bug_record.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_bug_validation.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_process_runner.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_spike_validation.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_stage_materials.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_test_entry.py +0 -0
- {workflow_loop-0.1.0 → workflow_loop-0.3.1}/tests/test_test_runner.py +0 -0
|
@@ -0,0 +1,280 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: workflow-loop
|
|
3
|
+
Version: 0.3.1
|
|
4
|
+
Summary: 为 AI 驱动的软件开发提供有状态、可验证、可回退的工作流管理。
|
|
5
|
+
Author: yuzyf
|
|
6
|
+
License-Expression: MIT
|
|
7
|
+
Project-URL: Homepage, https://github.com/yuzyf/workflow_loop
|
|
8
|
+
Project-URL: Repository, https://github.com/yuzyf/workflow_loop
|
|
9
|
+
Requires-Python: >=3.11
|
|
10
|
+
Description-Content-Type: text/markdown
|
|
11
|
+
License-File: LICENSE
|
|
12
|
+
Requires-Dist: markdown-it-py>=4.0
|
|
13
|
+
Requires-Dist: packaging>=24.0
|
|
14
|
+
Provides-Extra: dev
|
|
15
|
+
Requires-Dist: build>=1.2; extra == "dev"
|
|
16
|
+
Requires-Dist: pytest>=7.0; extra == "dev"
|
|
17
|
+
Requires-Dist: PyYAML>=6.0; extra == "dev"
|
|
18
|
+
Dynamic: license-file
|
|
19
|
+
|
|
20
|
+
# Workflow Loop
|
|
21
|
+
|
|
22
|
+
[](https://github.com/yuzyf/workflow_loop/releases)
|
|
23
|
+
[](https://pypi.org/project/workflow-loop/)
|
|
24
|
+
[](https://www.python.org/downloads/)
|
|
25
|
+
[](LICENSE)
|
|
26
|
+
|
|
27
|
+
为 AI 驱动的软件开发提供有状态、可验证、可回退的工作流管理。
|
|
28
|
+
|
|
29
|
+
Workflow Loop 把一次软件修改拆成有顺序的工作环节,并用程序保存当前状态、检查阶段产物和控制推进。用户负责提出需求和确认关键决定;AI(人工智能)编码助手负责执行日常 `workflow` 命令,按照命令输出的下一步完成讨论、实施、测试和验收。
|
|
30
|
+
|
|
31
|
+
## 能力与边界
|
|
32
|
+
|
|
33
|
+
### 能做什么
|
|
34
|
+
|
|
35
|
+
- **保存进度**:在项目的 `.workflow_loop/` 目录保存当前工作环节、确认状态和机器执行记录,下一次对话可以从真实状态继续。
|
|
36
|
+
- **控制推进**:完整研发任务的每个环节依次经过讨论完成、程序检查和用户确认三道门;无需开发任务走独立的讨论、执行、结果确认简单流程。
|
|
37
|
+
- **连接交付证据**:把产品设计、验收条件、测试项、实施记录和最终结果放进同一条可追踪链路。
|
|
38
|
+
- **保护项目修改**:实施前保存计划修改文件的原内容;需要退回上游或作废整轮时,按工作流规则使旧结果失效或恢复受管内容。
|
|
39
|
+
- **管理四种工作**:分别处理从零创建、修改现有产品、修复缺陷和无需开发任务;只有前三种生成研发环节路径。
|
|
40
|
+
|
|
41
|
+
### 不做什么
|
|
42
|
+
|
|
43
|
+
- 不替代 AI 编码助手、版本控制系统或持续集成服务,也不替用户决定产品需求是否正确。
|
|
44
|
+
- 不允许跳过必要讨论、程序检查或用户确认,把未经验证的内容当成交付结果。
|
|
45
|
+
- 不自动安装 Python,不静默更新,也不把残缺项目当成完整安装覆盖;更新必须由用户明确执行并确认。
|
|
46
|
+
- `light_task`(无需开发任务)不能用于修改正式产品规则、产品代码、测试代码,或影响运行、构建、测试、部署和依赖的配置;发现需要开发时必须结束简单轮次,经用户确认后改走完整研发路线。
|
|
47
|
+
|
|
48
|
+
## 工作流程
|
|
49
|
+
|
|
50
|
+
`intent`(工作意图)决定一轮工作走完整研发流程还是简单流程。AI 先调查并推荐路线,用户确认要进入哪种任务后才能启动。
|
|
51
|
+
|
|
52
|
+
```mermaid
|
|
53
|
+
flowchart TD
|
|
54
|
+
A["用户提出需求"] --> B{"AI 推荐路线,用户确认"}
|
|
55
|
+
B -->|"from_scratch:从零创建"| C1["生成从零开发路径"]
|
|
56
|
+
B -->|"product_change:修改产品"| C2["生成产品修改路径"]
|
|
57
|
+
B -->|"bugfix:修复缺陷"| C3["生成缺陷修复路径"]
|
|
58
|
+
B -->|"light_task:无需开发任务"| L1["逐个问题讨论,AI 给出建议"]
|
|
59
|
+
C1 --> D["进入当前工作环节"]
|
|
60
|
+
C2 --> D
|
|
61
|
+
C3 --> D
|
|
62
|
+
D --> E["讨论问题并确认计划"]
|
|
63
|
+
E --> F["第一道门:讨论完成"]
|
|
64
|
+
F --> G["生成文档、代码或测试"]
|
|
65
|
+
G --> H["第二道门:程序检查"]
|
|
66
|
+
H --> I["第三道门:用户确认"]
|
|
67
|
+
I --> J{"还有下一环节?"}
|
|
68
|
+
J -->|"有"| D
|
|
69
|
+
J -->|"没有"| K["记录完成并正式收工"]
|
|
70
|
+
L1 --> L2["用户确认讨论完毕"]
|
|
71
|
+
L2 --> L3["执行约定任务"]
|
|
72
|
+
L3 --> L4["核对并展示真实结果"]
|
|
73
|
+
L4 --> L5["用户确认结果"]
|
|
74
|
+
L5 --> K
|
|
75
|
+
```
|
|
76
|
+
|
|
77
|
+
完整研发路线的三道门分别解决不同问题:
|
|
78
|
+
|
|
79
|
+
1. **讨论完成**:需求、限制和实施计划已经与用户逐项达成共识,允许开始写正式产物。
|
|
80
|
+
2. **程序检查**:程序核对必需文件、结构、关联、代码变化或测试记录等可机械判断的事实。
|
|
81
|
+
3. **用户确认**:用户确认实际内容符合意图,程序记录确认后才进入下一环节。
|
|
82
|
+
|
|
83
|
+
`light_task`(无需开发任务)是一类任务,不是“改文档、提交、发布”三个固定选项。它也要求先调查和讨论:AI 用第一性原理梳理需求,每次只问一个问题并给出建议,用户确认讨论完毕后才执行。执行 `commit`(本地 Git 提交)、`push`(推送远端)、发布、删除等难撤销操作前,要按准确操作单独确认;“提交代码”必须先问清是只 `commit`,还是还要 `push`。完成后,AI 按约定方法展示真实结果,用户确认后收工。简单流程不创建研发阶段、三道门、固定全量测试或回退副本;失败或作废时保留真实现场并说明结果,不自动回滚。
|
|
84
|
+
|
|
85
|
+
## 环境要求
|
|
86
|
+
|
|
87
|
+
- Python 3.11 或更高版本;安装脚本只检查版本,不会代替用户安装 Python。
|
|
88
|
+
- macOS 或 Linux:Bash、`curl`(网络下载命令)、`tar`(归档解压命令),以及 `sha256sum` 或 `shasum`(文件摘要校验命令)。
|
|
89
|
+
- 原生 Windows:Windows PowerShell 5.1 或 PowerShell 7,以及可用的网络下载能力。
|
|
90
|
+
- 安装时能够访问 GitHub 和 PyPI(Python 公共软件包仓库)。
|
|
91
|
+
- 执行安装命令前,先进入要由 Workflow Loop 管理的项目根目录。
|
|
92
|
+
|
|
93
|
+
## 安装 0.3.1
|
|
94
|
+
|
|
95
|
+
安装器先进行只读检查并列出项目侧和电脑侧可能发生的全部持久修改。用户确认一次后,安装器才安装或复用全局 `workflow` 命令,并把智能体契约、产物模板和工作规范写入当前项目;用户取消或安装失败时不会留下只完成一部分的安装。
|
|
96
|
+
|
|
97
|
+
### macOS
|
|
98
|
+
|
|
99
|
+
```bash
|
|
100
|
+
curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.1/install.sh | bash
|
|
101
|
+
```
|
|
102
|
+
|
|
103
|
+
### Linux
|
|
104
|
+
|
|
105
|
+
```bash
|
|
106
|
+
curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.1/install.sh | bash
|
|
107
|
+
```
|
|
108
|
+
|
|
109
|
+
### 原生 Windows
|
|
110
|
+
|
|
111
|
+
```powershell
|
|
112
|
+
powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/download/v0.3.1/install.ps1 | iex"
|
|
113
|
+
```
|
|
114
|
+
|
|
115
|
+
安装命令固定读取 `v0.3.1` 正式发布中的脚本;不会跟随内容可能变化的 `latest`(最新版本)地址。
|
|
116
|
+
|
|
117
|
+
## 更新与卸载
|
|
118
|
+
|
|
119
|
+
下面的维护命令都由用户从项目根目录主动执行,并且在持久修改前只确认一次。`workflow update` 默认核对 PyPI 和 GitHub Release 后更新到双方一致的最新正式版本;`--version` 后的版本号必须是比电脑全局命令和当前项目都不低的正式版本。
|
|
120
|
+
|
|
121
|
+
```bash
|
|
122
|
+
workflow update
|
|
123
|
+
workflow update --version 0.3.1
|
|
124
|
+
```
|
|
125
|
+
|
|
126
|
+
更新按需补齐电脑全局命令和当前项目,只直接覆盖项目根 `AGENTS.md`、`.workflow_loop/Template_Repository/`、`.workflow_loop/Standardized_Repository/`,以及 `.workflow_loop/project.json` 中的安装版本字段。更新不创建备份,不回滚已经完成的步骤;当前轮次状态、历史、回退资料、业务代码和正式产物保持不变。失败后重新执行同一命令即可继续补齐。
|
|
127
|
+
|
|
128
|
+
没有 `workflow update` 命令的旧版本,可从项目根目录直接运行最新正式发布提供的脚本:
|
|
129
|
+
|
|
130
|
+
```bash
|
|
131
|
+
# macOS / Linux
|
|
132
|
+
curl -fsSL https://github.com/yuzyf/workflow_loop/releases/latest/download/update.sh | bash
|
|
133
|
+
```
|
|
134
|
+
|
|
135
|
+
```powershell
|
|
136
|
+
# Windows PowerShell 5.1 / 7
|
|
137
|
+
powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/latest/download/update.ps1 | iex"
|
|
138
|
+
```
|
|
139
|
+
|
|
140
|
+
项目卸载和电脑全局命令卸载是两个独立动作:
|
|
141
|
+
|
|
142
|
+
```bash
|
|
143
|
+
# 强制删除当前项目的 AGENTS.md、整个 .workflow_loop/ 和安装事务残留
|
|
144
|
+
workflow uninstall
|
|
145
|
+
|
|
146
|
+
# 只删除电脑全局命令;不会扫描或删除任何项目
|
|
147
|
+
workflow uninstall --global
|
|
148
|
+
```
|
|
149
|
+
|
|
150
|
+
项目卸载不检查当前轮次处于进行中、已完成还是已作废,也不恢复本轮业务修改;删除没有备份。全局卸载只清理全局工具和能够由安装来源记录证明是 Workflow Loop 添加的 `PATH`(命令搜索路径)项,来源不明或用户原本就有的 PATH 项会保留并报告。全局命令删除后,其它已安装项目仍保留,但在重新安装全局命令前不能运行 `workflow`。
|
|
151
|
+
|
|
152
|
+
旧版本没有公开卸载命令时,可从项目根运行 `uninstall.sh` 或 `uninstall.ps1` 的最新正式发布资产;两个脚本默认只卸载当前项目,不会先升级或删除电脑全局命令。
|
|
153
|
+
|
|
154
|
+
```bash
|
|
155
|
+
# macOS / Linux 旧版本项目卸载
|
|
156
|
+
curl -fsSL https://github.com/yuzyf/workflow_loop/releases/latest/download/uninstall.sh | bash
|
|
157
|
+
```
|
|
158
|
+
|
|
159
|
+
```powershell
|
|
160
|
+
# Windows PowerShell 5.1 / 7 旧版本项目卸载
|
|
161
|
+
powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/latest/download/uninstall.ps1 | iex"
|
|
162
|
+
```
|
|
163
|
+
|
|
164
|
+
## 最小使用示例
|
|
165
|
+
|
|
166
|
+
安装完成后,在当前项目中启动支持读取 `AGENTS.md`(智能体契约文件)的 AI 编码助手,直接用自然语言提出需求:
|
|
167
|
+
|
|
168
|
+
```text
|
|
169
|
+
用户:给当前项目增加 CSV 导出功能,并保证原有导出格式不受影响。
|
|
170
|
+
```
|
|
171
|
+
|
|
172
|
+
之后由 AI 编码助手执行日常流程:
|
|
173
|
+
|
|
174
|
+
1. 自动运行 `workflow start` 检查当前状态,并根据事实与用户确认本轮工作意图。
|
|
175
|
+
2. 调查现状并推荐四种路线之一,用户确认进入该任务后才启动轮次。
|
|
176
|
+
3. 严格执行每条命令输出的“下一步”,讨论时每次只问用户一个问题。
|
|
177
|
+
4. 完整研发路线在写代码前完成需求、验收、测试和实施计划;无需开发任务在用户确认讨论完毕后直接执行约定内容。
|
|
178
|
+
5. 把真实结果交给用户核对并确认,再正式收工。
|
|
179
|
+
|
|
180
|
+
用户不需要手工执行日常 `workflow` 命令;用户只负责描述需求、回答讨论问题、确认安装范围和确认各环节结果。
|
|
181
|
+
|
|
182
|
+
## 命令概览
|
|
183
|
+
|
|
184
|
+
下表供理解流程和排查当前状态使用,日常命令由 AI 编码助手执行。
|
|
185
|
+
|
|
186
|
+
| 命令 | 中文含义 |
|
|
187
|
+
|---|---|
|
|
188
|
+
| `workflow start` | 检查当前轮次;没有进行中的工作时列出四种工作意图 |
|
|
189
|
+
| `workflow start --intent <intent>` | 用户确认路线后开始一轮;`<intent>` 表示 `from_scratch`、`product_change`、`bugfix` 或 `light_task` |
|
|
190
|
+
| `workflow light --discuss-done --task <任务> --verification <方法>` | 记录无需开发任务已讨论完毕;`<任务>` 是约定范围,`<方法>` 是结果核对方法 |
|
|
191
|
+
| `workflow light --approve-action <准确操作>` | 记录用户单独批准的一项难撤销操作,只记录批准,不自动执行 |
|
|
192
|
+
| `workflow light --confirmed --result <实际结果>` | 记录用户已经核对无需开发任务的真实结果 |
|
|
193
|
+
| `workflow discuss` | 加载当前环节必须遵守的模板、规范和项目材料 |
|
|
194
|
+
| `workflow gate <stage> --discuss-done` | 通过当前环节的讨论完成门;`<stage>` 表示当前环节标识 |
|
|
195
|
+
| `workflow gate <stage>` | 让程序检查当前环节的文件、结构和可验证事实 |
|
|
196
|
+
| `workflow gate <stage> --confirmed` | 记录用户对当前环节的最终确认并进入下一环节 |
|
|
197
|
+
| `workflow status` | 显示当前轮次、环节、门禁状态和下一步 |
|
|
198
|
+
| `workflow test ...` | 登记统一测试入口、准备测试项或执行受控测试 |
|
|
199
|
+
| `workflow acceptance ...` | 记录需要用户判断的主题验收回答 |
|
|
200
|
+
| `workflow return --to <stage> --reason <reason>` | 带具体原因退回上游环节,并使受影响的下游结果失效;`<reason>` 表示退回原因 |
|
|
201
|
+
| `workflow abort` | 作废完整研发轮次,并按回退清单恢复受管内容 |
|
|
202
|
+
| `workflow abort --summary <真实状态>` | 作废无需开发任务,保留已发生状态并记录实际完成、未执行或失败内容 |
|
|
203
|
+
| `workflow done` | 在最后一个环节确认后记录整轮完成并清理临时回退副本 |
|
|
204
|
+
| `workflow update [--version <version>]` | 更新电脑全局命令和当前项目;`<version>` 表示可选的目标正式版本 |
|
|
205
|
+
| `workflow uninstall` | 不管当前轮次状态,强制删除当前项目固定的 Workflow Loop 管理内容 |
|
|
206
|
+
| `workflow uninstall --global` | 只卸载电脑全局 Workflow Loop 命令和来源明确的 PATH 项,不扫描项目 |
|
|
207
|
+
|
|
208
|
+
可运行 `workflow --help` 查看当前版本提供的完整参数。
|
|
209
|
+
|
|
210
|
+
## 源码开发
|
|
211
|
+
|
|
212
|
+
`uv` 是本项目使用的 Python 项目与环境管理工具。下面的命令会克隆源码、建立隔离环境、安装开发附加依赖,然后运行测试和真实分发包构建:
|
|
213
|
+
|
|
214
|
+
```bash
|
|
215
|
+
git clone https://github.com/yuzyf/workflow_loop.git
|
|
216
|
+
cd workflow_loop
|
|
217
|
+
uv sync --extra dev
|
|
218
|
+
uv run pytest
|
|
219
|
+
uv run python -m build
|
|
220
|
+
```
|
|
221
|
+
|
|
222
|
+
`dev`(开发附加依赖)包含 `pytest`(Python 测试工具)、PyYAML(YAML 配置解析库)和 `build`(Python 分发包构建工具)。
|
|
223
|
+
|
|
224
|
+
## 发布正式版本
|
|
225
|
+
|
|
226
|
+
项目维护者确认当前仓库内容可以直接发布后,在仓库根目录执行下面的命令,并把 `0.3.1` 替换成要发布的新版本号:
|
|
227
|
+
|
|
228
|
+
```bash
|
|
229
|
+
uv run python scripts/release.py 0.3.1
|
|
230
|
+
```
|
|
231
|
+
|
|
232
|
+
运行这条命令本身就表示维护者接受当前仓库状态并承担跳过本地发布检查的风险。脚本不会再次确认,也不会在本地运行测试、构建或远程版本查询。它依次执行:
|
|
233
|
+
|
|
234
|
+
1. 更新源码、README、维护脚本和自动发布配置中的当前版本身份,并运行 `uv lock` 更新依赖锁定结果。
|
|
235
|
+
2. 运行 `git add -A`,把当前全部未忽略的新增、修改和删除纳入发布提交。
|
|
236
|
+
3. 创建说明为 `release: prepare workflow-loop <新版本号>` 的发布提交。
|
|
237
|
+
4. 把当前提交推送到远程 `main`(默认分支)。
|
|
238
|
+
5. 创建带说明的 `v<新版本号>` 标签。
|
|
239
|
+
6. 推送该标签,触发现有 GitHub Actions(GitHub 自动任务)完成测试、构建和公开发布。
|
|
240
|
+
|
|
241
|
+
任一步失败时,脚本会显示失败步骤和退出码并立即停止。它不会强推、自动重试或回滚已经完成的文件修改、提交、分支推送和标签操作。标签推送成功只表示远程发布流程已经触发;是否最终发布成功,以 GitHub Actions 的运行结果为准。
|
|
242
|
+
|
|
243
|
+
## 仓库结构
|
|
244
|
+
|
|
245
|
+
```text
|
|
246
|
+
workflow_loop/
|
|
247
|
+
├── src/workflow_loop/ Python 产品代码和随包分发的模板、规范
|
|
248
|
+
├── tests/ 自动化测试
|
|
249
|
+
├── scripts/release.py 维护者直接发布当前仓库的脚本
|
|
250
|
+
├── .workflow_loop/ 本仓库自己的工作流状态、模板和规范
|
|
251
|
+
├── spec/ 产品设计和代码架构设计
|
|
252
|
+
├── acceptance/ 验收计划与验收结果
|
|
253
|
+
├── qa/ 测试计划与测试结果
|
|
254
|
+
├── impl/ 实施计划与实施记录
|
|
255
|
+
├── install.sh macOS 和 Linux 安装脚本
|
|
256
|
+
├── install.ps1 Windows 安装脚本
|
|
257
|
+
├── update.sh macOS 和 Linux 旧版本更新脚本
|
|
258
|
+
├── update.ps1 Windows 旧版本更新脚本
|
|
259
|
+
├── uninstall.sh macOS 和 Linux 旧版本卸载脚本
|
|
260
|
+
├── uninstall.ps1 Windows 旧版本卸载脚本
|
|
261
|
+
├── CONTEXT.md 产品术语、规则和限制
|
|
262
|
+
└── DESIGN.md 实现设计文档
|
|
263
|
+
```
|
|
264
|
+
|
|
265
|
+
## 详细文档
|
|
266
|
+
|
|
267
|
+
- [产品总说明](spec/产品总说明.md):产品目的、范围、使用者和通用规则。
|
|
268
|
+
- [安装到项目](spec/功能_安装到项目.md):支持环境、安装行为、异常处理和公开发布要求。
|
|
269
|
+
- [更新已安装项目](spec/功能_更新已安装项目.md):目标版本、覆盖范围、保留范围和失败重试规则。
|
|
270
|
+
- [卸载 Workflow Loop](spec/功能_卸载_Workflow_Loop.md):项目强制卸载和电脑全局卸载的独立边界。
|
|
271
|
+
- [发布正式版本](spec/功能_发布正式版本.md):人工发布命令、版本更新范围、执行顺序和失败边界。
|
|
272
|
+
- [处理无需开发任务](spec/功能_处理无需开发任务.md):简单流程适用边界、逐项确认、完成和异常处理规则。
|
|
273
|
+
- [代码架构设计](spec/代码架构设计.md):功能到代码模块、状态和外部依赖的对应关系。
|
|
274
|
+
- [实现设计文档](DESIGN.md):命令、数据模型、工作意图、阶段路径和门禁的实现形态。
|
|
275
|
+
- [产品事实与约束](CONTEXT.md):当前有效的术语、约束和设计决策。
|
|
276
|
+
- [需求交付追踪表](需求交付追踪表.md):每轮需求从设计到验收的完整追踪入口。
|
|
277
|
+
|
|
278
|
+
## 许可证
|
|
279
|
+
|
|
280
|
+
本项目使用 [MIT 许可证](LICENSE)。
|
|
@@ -0,0 +1,261 @@
|
|
|
1
|
+
# Workflow Loop
|
|
2
|
+
|
|
3
|
+
[](https://github.com/yuzyf/workflow_loop/releases)
|
|
4
|
+
[](https://pypi.org/project/workflow-loop/)
|
|
5
|
+
[](https://www.python.org/downloads/)
|
|
6
|
+
[](LICENSE)
|
|
7
|
+
|
|
8
|
+
为 AI 驱动的软件开发提供有状态、可验证、可回退的工作流管理。
|
|
9
|
+
|
|
10
|
+
Workflow Loop 把一次软件修改拆成有顺序的工作环节,并用程序保存当前状态、检查阶段产物和控制推进。用户负责提出需求和确认关键决定;AI(人工智能)编码助手负责执行日常 `workflow` 命令,按照命令输出的下一步完成讨论、实施、测试和验收。
|
|
11
|
+
|
|
12
|
+
## 能力与边界
|
|
13
|
+
|
|
14
|
+
### 能做什么
|
|
15
|
+
|
|
16
|
+
- **保存进度**:在项目的 `.workflow_loop/` 目录保存当前工作环节、确认状态和机器执行记录,下一次对话可以从真实状态继续。
|
|
17
|
+
- **控制推进**:完整研发任务的每个环节依次经过讨论完成、程序检查和用户确认三道门;无需开发任务走独立的讨论、执行、结果确认简单流程。
|
|
18
|
+
- **连接交付证据**:把产品设计、验收条件、测试项、实施记录和最终结果放进同一条可追踪链路。
|
|
19
|
+
- **保护项目修改**:实施前保存计划修改文件的原内容;需要退回上游或作废整轮时,按工作流规则使旧结果失效或恢复受管内容。
|
|
20
|
+
- **管理四种工作**:分别处理从零创建、修改现有产品、修复缺陷和无需开发任务;只有前三种生成研发环节路径。
|
|
21
|
+
|
|
22
|
+
### 不做什么
|
|
23
|
+
|
|
24
|
+
- 不替代 AI 编码助手、版本控制系统或持续集成服务,也不替用户决定产品需求是否正确。
|
|
25
|
+
- 不允许跳过必要讨论、程序检查或用户确认,把未经验证的内容当成交付结果。
|
|
26
|
+
- 不自动安装 Python,不静默更新,也不把残缺项目当成完整安装覆盖;更新必须由用户明确执行并确认。
|
|
27
|
+
- `light_task`(无需开发任务)不能用于修改正式产品规则、产品代码、测试代码,或影响运行、构建、测试、部署和依赖的配置;发现需要开发时必须结束简单轮次,经用户确认后改走完整研发路线。
|
|
28
|
+
|
|
29
|
+
## 工作流程
|
|
30
|
+
|
|
31
|
+
`intent`(工作意图)决定一轮工作走完整研发流程还是简单流程。AI 先调查并推荐路线,用户确认要进入哪种任务后才能启动。
|
|
32
|
+
|
|
33
|
+
```mermaid
|
|
34
|
+
flowchart TD
|
|
35
|
+
A["用户提出需求"] --> B{"AI 推荐路线,用户确认"}
|
|
36
|
+
B -->|"from_scratch:从零创建"| C1["生成从零开发路径"]
|
|
37
|
+
B -->|"product_change:修改产品"| C2["生成产品修改路径"]
|
|
38
|
+
B -->|"bugfix:修复缺陷"| C3["生成缺陷修复路径"]
|
|
39
|
+
B -->|"light_task:无需开发任务"| L1["逐个问题讨论,AI 给出建议"]
|
|
40
|
+
C1 --> D["进入当前工作环节"]
|
|
41
|
+
C2 --> D
|
|
42
|
+
C3 --> D
|
|
43
|
+
D --> E["讨论问题并确认计划"]
|
|
44
|
+
E --> F["第一道门:讨论完成"]
|
|
45
|
+
F --> G["生成文档、代码或测试"]
|
|
46
|
+
G --> H["第二道门:程序检查"]
|
|
47
|
+
H --> I["第三道门:用户确认"]
|
|
48
|
+
I --> J{"还有下一环节?"}
|
|
49
|
+
J -->|"有"| D
|
|
50
|
+
J -->|"没有"| K["记录完成并正式收工"]
|
|
51
|
+
L1 --> L2["用户确认讨论完毕"]
|
|
52
|
+
L2 --> L3["执行约定任务"]
|
|
53
|
+
L3 --> L4["核对并展示真实结果"]
|
|
54
|
+
L4 --> L5["用户确认结果"]
|
|
55
|
+
L5 --> K
|
|
56
|
+
```
|
|
57
|
+
|
|
58
|
+
完整研发路线的三道门分别解决不同问题:
|
|
59
|
+
|
|
60
|
+
1. **讨论完成**:需求、限制和实施计划已经与用户逐项达成共识,允许开始写正式产物。
|
|
61
|
+
2. **程序检查**:程序核对必需文件、结构、关联、代码变化或测试记录等可机械判断的事实。
|
|
62
|
+
3. **用户确认**:用户确认实际内容符合意图,程序记录确认后才进入下一环节。
|
|
63
|
+
|
|
64
|
+
`light_task`(无需开发任务)是一类任务,不是“改文档、提交、发布”三个固定选项。它也要求先调查和讨论:AI 用第一性原理梳理需求,每次只问一个问题并给出建议,用户确认讨论完毕后才执行。执行 `commit`(本地 Git 提交)、`push`(推送远端)、发布、删除等难撤销操作前,要按准确操作单独确认;“提交代码”必须先问清是只 `commit`,还是还要 `push`。完成后,AI 按约定方法展示真实结果,用户确认后收工。简单流程不创建研发阶段、三道门、固定全量测试或回退副本;失败或作废时保留真实现场并说明结果,不自动回滚。
|
|
65
|
+
|
|
66
|
+
## 环境要求
|
|
67
|
+
|
|
68
|
+
- Python 3.11 或更高版本;安装脚本只检查版本,不会代替用户安装 Python。
|
|
69
|
+
- macOS 或 Linux:Bash、`curl`(网络下载命令)、`tar`(归档解压命令),以及 `sha256sum` 或 `shasum`(文件摘要校验命令)。
|
|
70
|
+
- 原生 Windows:Windows PowerShell 5.1 或 PowerShell 7,以及可用的网络下载能力。
|
|
71
|
+
- 安装时能够访问 GitHub 和 PyPI(Python 公共软件包仓库)。
|
|
72
|
+
- 执行安装命令前,先进入要由 Workflow Loop 管理的项目根目录。
|
|
73
|
+
|
|
74
|
+
## 安装 0.3.1
|
|
75
|
+
|
|
76
|
+
安装器先进行只读检查并列出项目侧和电脑侧可能发生的全部持久修改。用户确认一次后,安装器才安装或复用全局 `workflow` 命令,并把智能体契约、产物模板和工作规范写入当前项目;用户取消或安装失败时不会留下只完成一部分的安装。
|
|
77
|
+
|
|
78
|
+
### macOS
|
|
79
|
+
|
|
80
|
+
```bash
|
|
81
|
+
curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.1/install.sh | bash
|
|
82
|
+
```
|
|
83
|
+
|
|
84
|
+
### Linux
|
|
85
|
+
|
|
86
|
+
```bash
|
|
87
|
+
curl -fsSL https://github.com/yuzyf/workflow_loop/releases/download/v0.3.1/install.sh | bash
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
### 原生 Windows
|
|
91
|
+
|
|
92
|
+
```powershell
|
|
93
|
+
powershell -NoProfile -ExecutionPolicy Bypass -Command "irm https://github.com/yuzyf/workflow_loop/releases/download/v0.3.1/install.ps1 | iex"
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
安装命令固定读取 `v0.3.1` 正式发布中的脚本;不会跟随内容可能变化的 `latest`(最新版本)地址。
|
|
97
|
+
|
|
98
|
+
## 更新与卸载
|
|
99
|
+
|
|
100
|
+
下面的维护命令都由用户从项目根目录主动执行,并且在持久修改前只确认一次。`workflow update` 默认核对 PyPI 和 GitHub Release 后更新到双方一致的最新正式版本;`--version` 后的版本号必须是比电脑全局命令和当前项目都不低的正式版本。
|
|
101
|
+
|
|
102
|
+
```bash
|
|
103
|
+
workflow update
|
|
104
|
+
workflow update --version 0.3.1
|
|
105
|
+
```
|
|
106
|
+
|
|
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
|
+
```
|
|
144
|
+
|
|
145
|
+
## 最小使用示例
|
|
146
|
+
|
|
147
|
+
安装完成后,在当前项目中启动支持读取 `AGENTS.md`(智能体契约文件)的 AI 编码助手,直接用自然语言提出需求:
|
|
148
|
+
|
|
149
|
+
```text
|
|
150
|
+
用户:给当前项目增加 CSV 导出功能,并保证原有导出格式不受影响。
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
之后由 AI 编码助手执行日常流程:
|
|
154
|
+
|
|
155
|
+
1. 自动运行 `workflow start` 检查当前状态,并根据事实与用户确认本轮工作意图。
|
|
156
|
+
2. 调查现状并推荐四种路线之一,用户确认进入该任务后才启动轮次。
|
|
157
|
+
3. 严格执行每条命令输出的“下一步”,讨论时每次只问用户一个问题。
|
|
158
|
+
4. 完整研发路线在写代码前完成需求、验收、测试和实施计划;无需开发任务在用户确认讨论完毕后直接执行约定内容。
|
|
159
|
+
5. 把真实结果交给用户核对并确认,再正式收工。
|
|
160
|
+
|
|
161
|
+
用户不需要手工执行日常 `workflow` 命令;用户只负责描述需求、回答讨论问题、确认安装范围和确认各环节结果。
|
|
162
|
+
|
|
163
|
+
## 命令概览
|
|
164
|
+
|
|
165
|
+
下表供理解流程和排查当前状态使用,日常命令由 AI 编码助手执行。
|
|
166
|
+
|
|
167
|
+
| 命令 | 中文含义 |
|
|
168
|
+
|---|---|
|
|
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 <实际结果>` | 记录用户已经核对无需开发任务的真实结果 |
|
|
174
|
+
| `workflow discuss` | 加载当前环节必须遵守的模板、规范和项目材料 |
|
|
175
|
+
| `workflow gate <stage> --discuss-done` | 通过当前环节的讨论完成门;`<stage>` 表示当前环节标识 |
|
|
176
|
+
| `workflow gate <stage>` | 让程序检查当前环节的文件、结构和可验证事实 |
|
|
177
|
+
| `workflow gate <stage> --confirmed` | 记录用户对当前环节的最终确认并进入下一环节 |
|
|
178
|
+
| `workflow status` | 显示当前轮次、环节、门禁状态和下一步 |
|
|
179
|
+
| `workflow test ...` | 登记统一测试入口、准备测试项或执行受控测试 |
|
|
180
|
+
| `workflow acceptance ...` | 记录需要用户判断的主题验收回答 |
|
|
181
|
+
| `workflow return --to <stage> --reason <reason>` | 带具体原因退回上游环节,并使受影响的下游结果失效;`<reason>` 表示退回原因 |
|
|
182
|
+
| `workflow abort` | 作废完整研发轮次,并按回退清单恢复受管内容 |
|
|
183
|
+
| `workflow abort --summary <真实状态>` | 作废无需开发任务,保留已发生状态并记录实际完成、未执行或失败内容 |
|
|
184
|
+
| `workflow done` | 在最后一个环节确认后记录整轮完成并清理临时回退副本 |
|
|
185
|
+
| `workflow update [--version <version>]` | 更新电脑全局命令和当前项目;`<version>` 表示可选的目标正式版本 |
|
|
186
|
+
| `workflow uninstall` | 不管当前轮次状态,强制删除当前项目固定的 Workflow Loop 管理内容 |
|
|
187
|
+
| `workflow uninstall --global` | 只卸载电脑全局 Workflow Loop 命令和来源明确的 PATH 项,不扫描项目 |
|
|
188
|
+
|
|
189
|
+
可运行 `workflow --help` 查看当前版本提供的完整参数。
|
|
190
|
+
|
|
191
|
+
## 源码开发
|
|
192
|
+
|
|
193
|
+
`uv` 是本项目使用的 Python 项目与环境管理工具。下面的命令会克隆源码、建立隔离环境、安装开发附加依赖,然后运行测试和真实分发包构建:
|
|
194
|
+
|
|
195
|
+
```bash
|
|
196
|
+
git clone https://github.com/yuzyf/workflow_loop.git
|
|
197
|
+
cd workflow_loop
|
|
198
|
+
uv sync --extra dev
|
|
199
|
+
uv run pytest
|
|
200
|
+
uv run python -m build
|
|
201
|
+
```
|
|
202
|
+
|
|
203
|
+
`dev`(开发附加依赖)包含 `pytest`(Python 测试工具)、PyYAML(YAML 配置解析库)和 `build`(Python 分发包构建工具)。
|
|
204
|
+
|
|
205
|
+
## 发布正式版本
|
|
206
|
+
|
|
207
|
+
项目维护者确认当前仓库内容可以直接发布后,在仓库根目录执行下面的命令,并把 `0.3.1` 替换成要发布的新版本号:
|
|
208
|
+
|
|
209
|
+
```bash
|
|
210
|
+
uv run python scripts/release.py 0.3.1
|
|
211
|
+
```
|
|
212
|
+
|
|
213
|
+
运行这条命令本身就表示维护者接受当前仓库状态并承担跳过本地发布检查的风险。脚本不会再次确认,也不会在本地运行测试、构建或远程版本查询。它依次执行:
|
|
214
|
+
|
|
215
|
+
1. 更新源码、README、维护脚本和自动发布配置中的当前版本身份,并运行 `uv lock` 更新依赖锁定结果。
|
|
216
|
+
2. 运行 `git add -A`,把当前全部未忽略的新增、修改和删除纳入发布提交。
|
|
217
|
+
3. 创建说明为 `release: prepare workflow-loop <新版本号>` 的发布提交。
|
|
218
|
+
4. 把当前提交推送到远程 `main`(默认分支)。
|
|
219
|
+
5. 创建带说明的 `v<新版本号>` 标签。
|
|
220
|
+
6. 推送该标签,触发现有 GitHub Actions(GitHub 自动任务)完成测试、构建和公开发布。
|
|
221
|
+
|
|
222
|
+
任一步失败时,脚本会显示失败步骤和退出码并立即停止。它不会强推、自动重试或回滚已经完成的文件修改、提交、分支推送和标签操作。标签推送成功只表示远程发布流程已经触发;是否最终发布成功,以 GitHub Actions 的运行结果为准。
|
|
223
|
+
|
|
224
|
+
## 仓库结构
|
|
225
|
+
|
|
226
|
+
```text
|
|
227
|
+
workflow_loop/
|
|
228
|
+
├── src/workflow_loop/ Python 产品代码和随包分发的模板、规范
|
|
229
|
+
├── tests/ 自动化测试
|
|
230
|
+
├── scripts/release.py 维护者直接发布当前仓库的脚本
|
|
231
|
+
├── .workflow_loop/ 本仓库自己的工作流状态、模板和规范
|
|
232
|
+
├── spec/ 产品设计和代码架构设计
|
|
233
|
+
├── acceptance/ 验收计划与验收结果
|
|
234
|
+
├── qa/ 测试计划与测试结果
|
|
235
|
+
├── impl/ 实施计划与实施记录
|
|
236
|
+
├── install.sh macOS 和 Linux 安装脚本
|
|
237
|
+
├── install.ps1 Windows 安装脚本
|
|
238
|
+
├── update.sh macOS 和 Linux 旧版本更新脚本
|
|
239
|
+
├── update.ps1 Windows 旧版本更新脚本
|
|
240
|
+
├── uninstall.sh macOS 和 Linux 旧版本卸载脚本
|
|
241
|
+
├── uninstall.ps1 Windows 旧版本卸载脚本
|
|
242
|
+
├── CONTEXT.md 产品术语、规则和限制
|
|
243
|
+
└── DESIGN.md 实现设计文档
|
|
244
|
+
```
|
|
245
|
+
|
|
246
|
+
## 详细文档
|
|
247
|
+
|
|
248
|
+
- [产品总说明](spec/产品总说明.md):产品目的、范围、使用者和通用规则。
|
|
249
|
+
- [安装到项目](spec/功能_安装到项目.md):支持环境、安装行为、异常处理和公开发布要求。
|
|
250
|
+
- [更新已安装项目](spec/功能_更新已安装项目.md):目标版本、覆盖范围、保留范围和失败重试规则。
|
|
251
|
+
- [卸载 Workflow Loop](spec/功能_卸载_Workflow_Loop.md):项目强制卸载和电脑全局卸载的独立边界。
|
|
252
|
+
- [发布正式版本](spec/功能_发布正式版本.md):人工发布命令、版本更新范围、执行顺序和失败边界。
|
|
253
|
+
- [处理无需开发任务](spec/功能_处理无需开发任务.md):简单流程适用边界、逐项确认、完成和异常处理规则。
|
|
254
|
+
- [代码架构设计](spec/代码架构设计.md):功能到代码模块、状态和外部依赖的对应关系。
|
|
255
|
+
- [实现设计文档](DESIGN.md):命令、数据模型、工作意图、阶段路径和门禁的实现形态。
|
|
256
|
+
- [产品事实与约束](CONTEXT.md):当前有效的术语、约束和设计决策。
|
|
257
|
+
- [需求交付追踪表](需求交付追踪表.md):每轮需求从设计到验收的完整追踪入口。
|
|
258
|
+
|
|
259
|
+
## 许可证
|
|
260
|
+
|
|
261
|
+
本项目使用 [MIT 许可证](LICENSE)。
|
|
@@ -1,13 +1,13 @@
|
|
|
1
1
|
[project]
|
|
2
2
|
name = "workflow-loop"
|
|
3
|
-
version = "0.1
|
|
3
|
+
version = "0.3.1"
|
|
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 = ["markdown-it-py>=4.0", "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
|
|
2
|
+
__version__ = "0.3.1"
|
|
3
3
|
# 产品身份标识:workflow --version 输出、安装脚本身份核对和安装事务校验共用同一组常量
|
|
4
|
-
# 本次发布版本为 0.1
|
|
4
|
+
# 本次发布版本为 0.3.1;后续发布使用尚未被 PyPI 占用的新版本号
|
|
5
5
|
PRODUCT_NAME = "workflow-loop"
|
|
6
6
|
PRODUCT_IDENTITY = f"{PRODUCT_NAME} {__version__}"
|
|
@@ -87,8 +87,8 @@ def record_is_current(
|
|
|
87
87
|
task = tasks.get(test_id)
|
|
88
88
|
if (
|
|
89
89
|
task is None
|
|
90
|
-
or task
|
|
91
|
-
or task.current_record
|
|
90
|
+
or not state_mod.execution_task_has_current_success(task)
|
|
91
|
+
or not task.current_record
|
|
92
92
|
or not task.current_record.record_id
|
|
93
93
|
):
|
|
94
94
|
return False
|
|
@@ -113,11 +113,10 @@ def _automated_items_are_current(
|
|
|
113
113
|
record_ids: list[str] = []
|
|
114
114
|
for test_id in test_ids:
|
|
115
115
|
task = tasks.get(test_id)
|
|
116
|
-
if task is None or
|
|
116
|
+
if task is None or not state_mod.execution_task_has_current_success(task):
|
|
117
117
|
return False, f"{topic} / {test_id} 没有当前有效的通过记录", []
|
|
118
118
|
record = task.current_record
|
|
119
|
-
|
|
120
|
-
return False, f"{topic} / {test_id} 当前测试记录不是通过状态", []
|
|
119
|
+
assert record is not None
|
|
121
120
|
if not record.record_id:
|
|
122
121
|
return False, f"{topic} / {test_id} 的执行记录缺少机器记录编号,必须重新执行", []
|
|
123
122
|
record_ids.append(record.record_id)
|