@guanlin4924/devflow-pi 0.1.22 → 0.1.24
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,19 +2,16 @@
|
|
|
2
2
|
|
|
3
3
|
面向项目代码开发的 OMP 原生 Devflow 能力仓库。仓库同时提供 Agent Skills、运行时 extension、task agents、项目配置模板和 marketplace 插件目录。Devflow 的流程真相由需求图谱、冻结测试集、机器证据和控制面状态组成，Markdown 只负责展示。
|
|
4
4
|
|
|
5
|
-
|
|
5
|
+
本项目不依赖外部会话式验收或里程碑工作流；验收和版本收口均由 Devflow 自有节点完成。架构设计材料仅保留在内部源码仓库，不随 npm 包发布。
|
|
6
6
|
|
|
7
|
-
## Devflow
|
|
7
|
+
## Devflow Pi
|
|
8
8
|
|
|
9
|
-
|
|
9
|
+
Devflow Pi 是一个面向项目研发交付的独立 OMP 产品入口，内置固定版本的 OMP Runtime 和六个 Devflow 插件。安装后可以直接在目标项目中进行初始化、需求梳理、方案设计、代码执行和验收，不需要把本仓库复制到业务项目中。
|
|
10
10
|
|
|
11
|
-
|
|
11
|
+
安装与启动：
|
|
12
12
|
|
|
13
13
|
```bash
|
|
14
|
-
|
|
15
|
-
npm install
|
|
16
|
-
npm link
|
|
17
|
-
|
|
14
|
+
npm install -g @guanlin4924/devflow-pi@0.1.23
|
|
18
15
|
cd /path/to/your-project
|
|
19
16
|
devflow-pi init
|
|
20
17
|
devflow-pi doctor
|
|
@@ -50,14 +47,12 @@ devflow-pi
|
|
|
50
47
|
- MCP 默认关闭，避免自动连接用户全局服务器；确需复用时显式加 `devflow-pi --mcp`；
|
|
51
48
|
- `task` 只允许六个 Devflow 角色 Agent，且必须显式写明 agent；同名项目/用户 Agent 与产品定义不一致时拒绝执行；
|
|
52
49
|
- `devflow-pi usage`、`devflow_usage_stats` 与 `usage_stats` 默认只统计当前项目的隔离 Session；`usage_stats` 显式传 `source=omp` 时才读取 `~/.omp` 历史会话。
|
|
53
|
-
- 以 `devflow-pi`
|
|
50
|
+
- 以 `devflow-pi` 启动时，确定性工作流和代码索引脚本只从产品包内六个插件解析；项目遗留 `.skills` 不会覆盖产品版本。
|
|
54
51
|
|
|
55
|
-
`devflow-pi doctor` 是产品壳和资源检查；TUI 内的 `/devflow doctor` 还会验证活动 Extension、30 个必需 Skills、6 个 Agents，以及 `@smol/@task/@slow` 三个不同的已认证模型。专项 Pi 默认用 `@slow` 处理用户交互和规划，`@smol` 仅负责只读侦察，`@task`
|
|
52
|
+
`devflow-pi doctor` 是产品壳和资源检查；TUI 内的 `/devflow doctor` 还会验证活动 Extension、30 个必需 Skills、6 个 Agents，以及 `@smol/@task/@slow` 三个不同的已认证模型。专项 Pi 默认用 `@slow` 处理用户交互和规划，`@smol` 仅负责只读侦察，`@task` 仅负责受限执行与验证。
|
|
56
53
|
|
|
57
54
|
专项 Pi 会复用 `~/.omp/agent/` 里的登录凭据和可用模型列表，但模型角色选择写在 `~/.devflow-pi/agent/` 这个产品级目录里，不写入目标项目，也不读取官方 OMP 的 Session。首次进入专项 Pi 后，先在模型角色界面把 `smol`、`task`、`slow` 配成三个不同模型，再执行 `/devflow doctor`；未配好时 `/devflow start` 会被拒绝。
|
|
58
55
|
|
|
59
|
-
现有 `install.sh --apply` 模式仍保留，作为未迁移项目的兼容入口；下文描述的是该兼容模式。
|
|
60
|
-
|
|
61
56
|
## Skill 如何被加载
|
|
62
57
|
|
|
63
58
|
Skill 仍采用标准目录结构：
|
|
@@ -80,14 +75,15 @@ skills:
|
|
|
80
75
|
# 其余四个插件目录同理
|
|
81
76
|
```
|
|
82
77
|
|
|
83
|
-
##
|
|
78
|
+
## 私有源码兼容模式
|
|
79
|
+
|
|
80
|
+
`install.sh --apply` 只用于已经获得内部源码访问权限的开发环境。本文档不提供私有仓库地址；在内部工作副本中执行：
|
|
84
81
|
|
|
85
82
|
```bash
|
|
86
|
-
git submodule add https://gitee.com/guanlin4924/skill-kit.git .skills
|
|
87
83
|
bash .skills/install.sh --apply
|
|
88
84
|
```
|
|
89
85
|
|
|
90
|
-
|
|
86
|
+
它会执行 postflight；已有但不兼容的 `.omp/config.yml` 会使安装失败，不会以警告方式假装安装完整。
|
|
91
87
|
|
|
92
88
|
安装器只生成以下 OMP 原生资源：
|
|
93
89
|
|
|
@@ -100,7 +96,7 @@ bash .skills/install.sh --apply
|
|
|
100
96
|
.agent-gates/index-first.json
|
|
101
97
|
```
|
|
102
98
|
|
|
103
|
-
已有且兼容的 `.omp/config.yml`
|
|
99
|
+
已有且兼容的 `.omp/config.yml` 会保留。源码兼容模式下，已有配置缺少 Devflow skill 来源、model overrides 或工具策略时，先审查差异，再显式运行：
|
|
104
100
|
|
|
105
101
|
```bash
|
|
106
102
|
bash .skills/install.sh --apply --force-config
|
|
@@ -135,27 +131,21 @@ bash .skills/install.sh --apply --force-config
|
|
|
135
131
|
- `tdd_required` 任务必须先由 Core 记录准备快照，再记录 RED（命中预期失败）、同一目标的 GREEN 和回归；缺失或环境失败不算完成。
|
|
136
132
|
- API、跨数据域、边界、迁移、工作负载与架构风险会派生相应的 `api`、`permission`、`boundary`、`migration`、`performance`、`resilience` TC 义务。
|
|
137
133
|
- 代码完成后，`workflow-run-acceptance-tests` 只能运行绑定到冻结 TC、且已在初始化 `.planning/toolchain.md` 发现的测试运行器命令。任何失败、未执行、人工待执行或环境阻塞用例都会阻止 CP-4。
|
|
138
|
-
-
|
|
134
|
+
- 验收不是代码完成后的临时手工检查。它是需求基线在编码前派生并冻结的完整测试集，覆盖主流程、异常、边界、权限、迁移、兼容、韧性和工作负载义务；代码只能补充执行适配信息，不能改变测试意图。
|
|
139
135
|
- 验收失败不会创建另一套人工台账，而是进入 `acceptance-remediation`：诊断 → 修复 → code-index 刷新 → 原冻结 `TC-*` 重跑。
|
|
140
136
|
- CP-4 通过后只进入一个 `workflow-release-closeout` 步骤，统一写入 `.planning/milestones/current-CLOSEOUT.md` 并更新项目状态、导航和版本记录。
|
|
141
137
|
|
|
142
138
|
正常使用不需要记忆底层命令：在 Devflow 工作流中按步骤继续即可。需要排查时，可用 `devflow_acceptance_tests` 查看冻结套件，或由工作流调用 `devflow_tdd_evidence` 与 `devflow_run_acceptance_tests` 生成 Core-owned 证据；不要手写“已测试”来替代结果文件。
|
|
143
139
|
|
|
144
|
-
##
|
|
140
|
+
## 更新
|
|
145
141
|
|
|
146
|
-
|
|
142
|
+
升级 npm 发行版：
|
|
147
143
|
|
|
148
144
|
```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
|
|
145
|
+
npm install -g @guanlin4924/devflow-pi@latest
|
|
156
146
|
```
|
|
157
147
|
|
|
158
|
-
|
|
148
|
+
安装或升级 Extension 后重启会话；仅刷新 Skill/Command 时可使用 `/reload-plugins`。
|
|
159
149
|
|
|
160
150
|
## 插件边界
|
|
161
151
|
|
|
@@ -178,12 +168,10 @@ omp plugin install --scope project devflow-quality@devflow
|
|
|
178
168
|
- 人工 checkpoint 不得在 headless 模式静默通过。
|
|
179
169
|
- semantic correctness 不能靠 prompt 保证，必须由契约、确定性校验、独立审查和可复现测试共同约束。
|
|
180
170
|
|
|
181
|
-
|
|
171
|
+
源码兼容模式刷新：
|
|
182
172
|
|
|
183
173
|
```bash
|
|
184
|
-
git -C .skills pull
|
|
185
174
|
bash .skills/install.sh --refresh
|
|
186
|
-
git add .skills .omp .agent-gates
|
|
187
175
|
```
|
|
188
176
|
|
|
189
177
|
刷新完成后重启 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