@guanlin4924/devflow-pi 0.1.22 → 0.1.23
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.
package/README.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
面向项目代码开发的 OMP 原生 Devflow 能力仓库。仓库同时提供 Agent Skills、运行时 extension、task agents、项目配置模板和 marketplace 插件目录。Devflow 的流程真相由需求图谱、冻结测试集、机器证据和控制面状态组成，Markdown 只负责展示。
|
|
4
4
|
|
|
5
|
-
完整的第一性原理拆分、控制面不变量和对抗式审查见 [`docs/OMP-NATIVE-ARCHITECTURE.md`](docs/OMP-NATIVE-ARCHITECTURE.md)
|
|
5
|
+
完整的第一性原理拆分、控制面不变量和对抗式审查见 [`docs/OMP-NATIVE-ARCHITECTURE.md`](docs/OMP-NATIVE-ARCHITECTURE.md)。本项目不依赖外部会话式验收或里程碑工作流；验收和版本收口均由 Devflow 自有节点完成。
|
|
6
6
|
|
|
7
7
|
## Devflow 专项 Pi（当前功能分支）
|
|
8
8
|
|
|
@@ -80,14 +80,27 @@ skills:
|
|
|
80
80
|
# 其余四个插件目录同理
|
|
81
81
|
```
|
|
82
82
|
|
|
83
|
-
##
|
|
83
|
+
## npm 安装：推荐入口
|
|
84
|
+
|
|
85
|
+
```bash
|
|
86
|
+
npm install -g @guanlin4924/devflow-pi@0.1.22
|
|
87
|
+
cd /path/to/your-project
|
|
88
|
+
devflow-pi init
|
|
89
|
+
devflow-pi doctor
|
|
90
|
+
devflow-pi
|
|
91
|
+
```
|
|
92
|
+
|
|
93
|
+
npm 包已经内置完整 Devflow Runtime、Extension、task agents、项目策略和生命周期配置，不需要复制私有 Git 仓库，也不需要把本仓库作为 submodule 加入业务项目。
|
|
94
|
+
|
|
95
|
+
## 私有源码兼容模式
|
|
96
|
+
|
|
97
|
+
`install.sh --apply` 只用于已经获得内部源码访问权限的开发环境。本文档不提供私有仓库地址；在内部工作副本中执行：
|
|
84
98
|
|
|
85
99
|
```bash
|
|
86
|
-
git submodule add https://gitee.com/guanlin4924/skill-kit.git .skills
|
|
87
100
|
bash .skills/install.sh --apply
|
|
88
101
|
```
|
|
89
102
|
|
|
90
|
-
|
|
103
|
+
它会执行 postflight；已有但不兼容的 `.omp/config.yml` 会使安装失败，不会以警告方式假装安装完整。
|
|
91
104
|
|
|
92
105
|
安装器只生成以下 OMP 原生资源：
|
|
93
106
|
|
|
@@ -100,7 +113,7 @@ bash .skills/install.sh --apply
|
|
|
100
113
|
.agent-gates/index-first.json
|
|
101
114
|
```
|
|
102
115
|
|
|
103
|
-
已有且兼容的 `.omp/config.yml`
|
|
116
|
+
已有且兼容的 `.omp/config.yml` 会保留。源码兼容模式下，已有配置缺少 Devflow skill 来源、model overrides 或工具策略时，先审查差异，再显式运行：
|
|
104
117
|
|
|
105
118
|
```bash
|
|
106
119
|
bash .skills/install.sh --apply --force-config
|
|
@@ -135,27 +148,21 @@ bash .skills/install.sh --apply --force-config
|
|
|
135
148
|
- `tdd_required` 任务必须先由 Core 记录准备快照，再记录 RED（命中预期失败）、同一目标的 GREEN 和回归；缺失或环境失败不算完成。
|
|
136
149
|
- API、跨数据域、边界、迁移、工作负载与架构风险会派生相应的 `api`、`permission`、`boundary`、`migration`、`performance`、`resilience` TC 义务。
|
|
137
150
|
- 代码完成后，`workflow-run-acceptance-tests` 只能运行绑定到冻结 TC、且已在初始化 `.planning/toolchain.md` 发现的测试运行器命令。任何失败、未执行、人工待执行或环境阻塞用例都会阻止 CP-4。
|
|
138
|
-
-
|
|
151
|
+
- 验收不是代码完成后的临时手工检查。它是需求基线在编码前派生并冻结的完整测试集，覆盖主流程、异常、边界、权限、迁移、兼容、韧性和工作负载义务；代码只能补充执行适配信息，不能改变测试意图。
|
|
139
152
|
- 验收失败不会创建另一套人工台账，而是进入 `acceptance-remediation`：诊断 → 修复 → code-index 刷新 → 原冻结 `TC-*` 重跑。
|
|
140
153
|
- CP-4 通过后只进入一个 `workflow-release-closeout` 步骤，统一写入 `.planning/milestones/current-CLOSEOUT.md` 并更新项目状态、导航和版本记录。
|
|
141
154
|
|
|
142
155
|
正常使用不需要记忆底层命令：在 Devflow 工作流中按步骤继续即可。需要排查时，可用 `devflow_acceptance_tests` 查看冻结套件，或由工作流调用 `devflow_tdd_evidence` 与 `devflow_run_acceptance_tests` 生成 Core-owned 证据；不要手写“已测试”来替代结果文件。
|
|
143
156
|
|
|
144
|
-
##
|
|
157
|
+
## 更新
|
|
145
158
|
|
|
146
|
-
|
|
159
|
+
升级 npm 发行版：
|
|
147
160
|
|
|
148
161
|
```bash
|
|
149
|
-
|
|
150
|
-
omp plugin install --scope project devflow-core@devflow
|
|
151
|
-
omp plugin install --scope project devflow-intel@devflow
|
|
152
|
-
omp plugin install --scope project devflow-requirements@devflow
|
|
153
|
-
omp plugin install --scope project devflow-design@devflow
|
|
154
|
-
omp plugin install --scope project devflow-implementation@devflow
|
|
155
|
-
omp plugin install --scope project devflow-quality@devflow
|
|
162
|
+
npm install -g @guanlin4924/devflow-pi@latest
|
|
156
163
|
```
|
|
157
164
|
|
|
158
|
-
|
|
165
|
+
安装或升级 Extension 后重启会话；仅刷新 Skill/Command 时可使用 `/reload-plugins`。
|
|
159
166
|
|
|
160
167
|
## 插件边界
|
|
161
168
|
|
|
@@ -178,12 +185,10 @@ omp plugin install --scope project devflow-quality@devflow
|
|
|
178
185
|
- 人工 checkpoint 不得在 headless 模式静默通过。
|
|
179
186
|
- semantic correctness 不能靠 prompt 保证，必须由契约、确定性校验、独立审查和可复现测试共同约束。
|
|
180
187
|
|
|
181
|
-
|
|
188
|
+
源码兼容模式刷新：
|
|
182
189
|
|
|
183
190
|
```bash
|
|
184
|
-
git -C .skills pull
|
|
185
191
|
bash .skills/install.sh --refresh
|
|
186
|
-
git add .skills .omp .agent-gates
|
|
187
192
|
```
|
|
188
193
|
|
|
189
194
|
刷新完成后重启 OMP 并再次运行 `/devflow doctor`。如果模板新增了强制配置而项目配置被保留，安装器会拒绝完成；审查后使用 `--force-config` 更新。
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: workflow-pipeline
|
|
3
|
-
description: Use when running or resuming the full .planning delivery pipeline from requirements through implementation,
|
|
3
|
+
description: Use when running or resuming the full .planning delivery pipeline from requirements through implementation, frozen acceptance tests, and Devflow release closeout.
|
|
4
4
|
---
|
|
5
5
|
|
|
6
6
|
<objective>
|
|
@@ -43,9 +43,7 @@ pipeline 本身不包含执行规则——所有门禁、CP 协议、失败分
|
|
|
43
43
|
| 85 | code-review | 代码审查（完成标准验证） |
|
|
44
44
|
| 86 | generate-mainflow-cases | 主流程自动化用例生成 |
|
|
45
45
|
| 90 | run-acceptance-tests | 冻结 TC 验收执行 |
|
|
46
|
-
| 100 |
|
|
47
|
-
| 110 | update-navigation | 更新导航 |
|
|
48
|
-
| 120 | archive | 里程碑归档 |
|
|
46
|
+
| 100 | release-closeout | 验收通过后的版本收口与里程碑归档 |
|
|
49
47
|
|
|
50
48
|
- **`--track A`**：后端/API 轨道产物模式。可跑 `requirement-triage → requirement-wayfinder → domain-modeling → requirement-feasibility-review → requirement-baseline → api-contract → architecture-feasibility → backend-tech-spec → api-call-guide`，但不能自动进入 `integration-verify / change-plan / execute`。
|
|
51
49
|
- **`--track B`**：前端/UI 轨道产物模式。要求 `api-contract` 与 `architecture-feasibility` 已完成；新需求从需求主链开始，已有共同事实可跑 `ui-spec → feature-breakdown → frontend-tech-spec`，但不能自动进入 `change-plan / execute`。
|
|
@@ -22,7 +22,7 @@ description: "Use after workflow-execute-phase to bind frozen API/page TC accept
|
|
|
22
22
|
|
|
23
23
|
## Workflow Position
|
|
24
24
|
|
|
25
|
-
This step sits between code execution and
|
|
25
|
+
This step sits between code execution and frozen acceptance execution. It runs after `execute` alongside `code-review`; `run-acceptance-tests` consumes both gates:
|
|
26
26
|
|
|
27
27
|
`execute -> code-review + generate-mainflow-cases -> run-acceptance-tests -> release-closeout`
|
|
28
28
|
|
package/src/constants.ts
CHANGED