@guanlin4924/devflow-pi 0.1.21 → 0.1.23

package/plugins/devflow-intel/skills/workflow-context-sync/SKILL.md

@@ -44,7 +44,7 @@ Preserve these properties:
 | `workflow-project-context` | Full reinitialization | Full only |
 | `workflow-bug-fix` | Bug-fix main workflow | Must call this skill after verification and lesson capture |
 | `workflow-execute-phase` | Feature implementation workflow | Must call this skill after implementation verification |
-| `workflow-verify-work` | Validate implementation | Usually before after-bugfix sync |
+| `workflow-run-acceptance-tests` | Execute frozen requirement tests | After implementation and code-index refresh |
 
 ## Inputs
 

package/plugins/devflow-intel/skills/workflow-update-navigation/SKILL.md

@@ -181,6 +181,6 @@ The code-index commands are required only when `.planning/code-index/` exists or
 
 ## Downstream Read Contract
 
-- `workflow-complete-milestone` should verify that navigation `Scan Status` is not older than the last commit before archiving.
+- `workflow-release-closeout` should verify that navigation `Scan Status` is not older than the last commit before archiving.
 - Future `workflow-requirement-baseline` invocations will read the updated navigation for conflict and reuse detection.
 - Future source-tracing tasks should use `.planning/code-index/` for fine-grained relation facts when available, with source readback before answering.

package/plugins/devflow-quality/agents/verification-runner.md

@@ -12,7 +12,7 @@ tools:
 model: "@task"
 thinkingLevel: medium
 autoloadSkills:
-  - workflow-verify-work
+  - workflow-run-acceptance-tests
   - workflow-generate-mainflow-cases
 ---
 

package/plugins/devflow-quality/skills/workflow-generate-mainflow-cases/SKILL.md

@@ -22,9 +22,9 @@ description: "Use after workflow-execute-phase to bind frozen API/page TC accept
 
 ## Workflow Position
 
-This step sits between code execution and verification. It runs after `execute` alongside `code-review`; `verify` depends on both gates:
+This step sits between code execution and frozen acceptance execution. It runs after `execute` alongside `code-review`; `run-acceptance-tests` consumes both gates:
 
-`execute -> code-review + generate-mainflow-cases -> verify-work / UAT`
+`execute -> code-review + generate-mainflow-cases -> run-acceptance-tests -> release-closeout`
 
 The workflow step id is `generate-mainflow-cases`, order `86`, and it depends on `execute`.
 

package/plugins/devflow-quality/skills/workflow-release-closeout/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: workflow-release-closeout
+description: "在冻结需求验收测试全部通过后，执行 Devflow 自有的版本收口与里程碑归档。"
+---
+
+# Devflow 版本收口
+
+## 目标
+
+把一次已经完成编码、索引刷新和需求验收测试的交付，收敛为一个可追溯的版本归档。此步骤不是重新设计测试，也不是凭报告自述通过。
+
+## 必须读取
+
+- `.planning/requirements/{feature}/tests.json`
+- `.planning/test-runs/{feature}/acceptance-results.json`
+- `.planning/features/{feature}/变更清单.md`
+- `.planning/code-index/AUDIT.md`
+- `.planning/PROJECT.md`
+- `.planning/STATE.md`
+- `.planning/navigation/INDEX.md`
+
+## 归档前置条件（全部满足）
+
+1. 每个冻结的 `TC-*` 都有执行结果，且结果引用当前测试集 revision/fingerprint。
+2. 不存在 `failed`、`blocked`、未执行或环境缺失的 TC。
+3. 变更清单任务已完成，TDD/回归证据已存在或有明确豁免。
+4. `code-index` 已刷新，`AUDIT.md` 通过，索引没有 stale blocker。
+5. 需求基线、架构风险和契约没有未处理的阻塞项。
+
+任何一项不满足，都必须停止收口，返回 `workflow-bug-fix` 或 `workflow-run-acceptance-tests`，不能生成“已完成”归档。
+
+## 收口动作
+
+1. 读取 Core-owned `acceptance-results.json`，计算通过/失败/阻塞数量。
+2. 更新 `.planning/navigation/INDEX.md`，记录本次 code-index revision 和验收结果 fingerprint。
+3. 在 `.planning/milestones/` 写入本版本的 ROADMAP、需求覆盖、测试结果、变更清单和已接受风险摘要。
+4. 更新 `.planning/PROJECT.md` 的当前版本与下一步目标。
+5. 通过 Core 状态工具更新 `.planning/STATE.md`，将当前 feature 标记为完成。
+6. 归档写入完成后才允许创建 git tag；是否提交或推送由用户明确决定。
+
+## 输出
+
+- `.planning/milestones/{version}-CLOSEOUT.md`
+- 更新后的 `.planning/PROJECT.md`
+- 更新后的 `.planning/STATE.md`
+- 更新后的 `.planning/navigation/INDEX.md`
+
+归档文件是结果摘要，不是通过依据；唯一的验收真相是 Core-owned `acceptance-results.json` 和 code-index 审计结果。

package/plugins/devflow-quality/skills/workflow-run-acceptance-tests/SKILL.md

@@ -5,7 +5,7 @@ description: "Execute the frozen TC acceptance suite after code review. Use the
 
 # 冻结验收测试执行
 
-此步骤在代码审查后、UAT 前运行。它的目标是执行冻结的 `TC-*`，而不是根据交付总结重新猜测要测什么。
+此步骤在代码审查后运行。它的目标是执行冻结的 `TC-*`，而不是根据交付总结重新猜测要测什么。
 
 ## 输入边界
 
@@ -38,7 +38,7 @@ description: "Execute the frozen TC acceptance suite after code review. Use the
    - 人工或环境阻塞用例必须有 owner 与原因/阻塞源。
 5. 调用 `devflow_run_acceptance_tests(action="validate", feature=...)`。不通过时修正绑定，不得绕过。
 6. 调用 `devflow_run_acceptance_tests(action="run", feature=...)`。该 Core 工具记录每个 TC 的命令哈希、退出码和输出摘要。
-7. 失败、未执行或 blocked 的 TC 只能报告为 `blocked`/`failed`，不得在 CP-4 或 UAT 中宣称验收通过。
+7. 失败、未执行或 blocked 的 TC 只能报告为 `blocked`/`failed`，不得进入版本收口。
 
 ## 输出
 

package/src/constants.ts

@@ -1,5 +1,5 @@
 export const PRODUCT_NAME = "Devflow Pi";
-export const PRODUCT_VERSION = "0.1.21";
+export const PRODUCT_VERSION = "0.1.23";
 export const PROJECT_SCHEMA_VERSION = 1;
 export const OMP_RUNTIME_VERSION = "17.2.7";
 

package/templates/commands/start.md

@@ -41,7 +41,7 @@
 
 1. 写入 `.planning/.next-intent`：
    - 继续下一步：`{"action": "continue"}`
-   - 调用指定 skill：`{"action": "skill", "skill": "workflow-verify-work", "args": "..."}`
+   - 调用指定 skill：`{"action": "skill", "skill": "workflow-run-acceptance-tests", "args": "..."}`
 2. 执行 `/clear`
 
 `/clear` 后 SessionStart hook 重新注入上下文，`<intent>` 块会告知此会话的意图，无需再问用户即可直接进入下一步。
@@ -50,7 +50,7 @@
 
 ## 执行中的行为准则
 
-- workflow skill 使用 `skill://<name>` 按需读取（如 `skill://workflow-verify-work`）。
+- workflow skill 使用 `skill://<name>` 按需读取（如 `skill://workflow-run-acceptance-tests`）。
 - 上下文管理：你觉得需要时就 `/clear`，不要等 compaction。`/clear` 后 hook 会自动恢复 pipeline 状态和索引入口。
 - 优先读取最新的规则、规范和导航索引；索引缺失或过期时回退到 LSP、搜索和源码事实，并显式报告降级状态
 - 读 `.context/lessons/README.md`，避免已知陷阱

package/templates/omp/config.yml

@@ -31,12 +31,11 @@ skills:
     - workflow-api-call-guide
     - workflow-api-contract
     - workflow-api-supplement
-    - workflow-audit-milestone
     - workflow-backend-tech-spec
     - workflow-bug-fix
     - workflow-change-plan
     - workflow-code-index
-    - workflow-complete-milestone
+    - workflow-release-closeout
     - workflow-context-sync
     - workflow-demand-clarify
     - workflow-design-rule-pack
@@ -53,7 +52,6 @@ skills:
     - workflow-requirement-triage
     - workflow-ui-spec
     - workflow-update-navigation
-    - workflow-verify-work
     - workflow-wayfinder
   enableClaudeUser: false
   enableClaudeProject: false

package/docs/OMP-NATIVE-ARCHITECTURE.md

@@ -1,104 +0,0 @@
-# Devflow OMP 原生架构
-
-## 结论
-
-Pi/OMP 不把任意 `.skill` 文件或名为 `.skills` 的目录自动视为 skill。稳定的能力单元是：
-
-```text
-<skill-name>/SKILL.md
-```
-
-Pi 默认扫描项目 `.pi/skills/` 和兼容的 `.agents/skills/`；OMP 默认扫描 `.omp/skills/`，也允许用 `skills.customDirectories` 指向任意 skill 集合目录。本项目选择直接扫描 `.skills/plugins/*/skills`，不生成 `.claude/`、`.codex/` 或 `.omp/skills` 镜像。
-
-依据：
-
-- [Pi Skills](https://pi.dev/docs/latest/skills)
-- [OMP Skills](https://github.com/can1357/oh-my-pi/blob/main/docs/skills.md)
-- [OMP Settings](https://github.com/can1357/oh-my-pi/blob/main/docs/settings.md)
-- [OMP Marketplace](https://github.com/can1357/oh-my-pi/blob/main/docs/marketplace.md)
-- [OMP Extensions](https://github.com/can1357/oh-my-pi/blob/main/docs/extensions.md)
-
-## 第一性原理
-
-项目开发 agent 的目标不是“调用更多 prompt”，而是以最小不可逆风险交付可验证的正确变更。因此能力按其本质分层：
-
-| 能力本质 | OMP 承载面 | 原因 |
-|---|---|---|
-| 领域知识、步骤、模板 | Skill | 按需加载，避免常驻上下文膨胀 |
-| 必须强制的不变量 | Extension/tool | prompt 不能作为并发控制或权限边界 |
-| 独立探索、实现、审查 | Task agent | 隔离上下文与写权限，避免角色自证 |
-| 项目级默认策略 | `.omp/config.yml` | 固定发现源、审批、并发、递归与隔离 |
-| 可安装能力边界 | Marketplace capability pack | 独立启停 Skills/Agents 等内容；不承担强制运行时加载 |
-| 项目事实与进度 | `.planning/` | 跨会话持久化；不能依赖聊天记忆 |
-
-事实优先级固定为：可执行测试与运行结果 → 当前源码/LSP → 已批准契约 → 新鲜索引 → 模型推断。索引只能加速定位，不能覆盖源码事实。
-
-## 插件拆分
-
-| 插件 | 唯一责任 | Skills | Extension/tools | Task agents |
-|---|---|---|---|---|
-| `devflow-core` | 控制面 | pipeline、orchestrator、project-context | 状态、初始化、CAS 转移、制品、生命周期、`/devflow` | — |
-| `devflow-intel` | 项目事实发现 | code-index、query、context-sync、navigation | code index、context cursor | `project-scout` |
-| `devflow-requirements` | 需求决策 | triage、wayfinder、domain、feasibility、baseline | — | `requirements-auditor` |
-| `devflow-design` | 跨层契约 | API/UI/前后端/拆解/集成/设计规则 | design rule pack | `contract-auditor` |
-| `devflow-implementation` | 有界代码变更 | change-plan、execute、bug-fix | — | `implementation-worker` |
-| `devflow-quality` | 独立质量结论 | review、mainflow、UAT、audit、archive | mainflow cases | reviewer、verification runner |
-
-每个插件的 `skills/` 存放实体真本，仓库根部的同名目录是兼容链接。原因是 marketplace 会把单个插件目录缓存为独立包：插件内部不能依赖指向包外部的 skill 链接。
-
-## 控制面不变量
-
-1. `.planning/STATE.md`、workflow 定义、artifact registry 和 `.next-intent` 只能由 Devflow 工具写。
-2. 所有控制面 writer 共用 `.planning/.devflow.lock`，文件用临时文件 + `fsync` + 原子 rename 写入。
-3. 每次状态推进必须携带刚读取的 `expectedRevision`；过期写返回 `stale_revision`，不产生部分副作用。显式 force 初始化是独立的用户批准操作。
-4. artifact registry 携带 `state_revision`，它是从状态派生的缓存，不是第二真相源。
-5. task agent 不推进状态、不批准 checkpoint；只有父会话能提交状态转移。
-6. 人工 checkpoint 不在 headless 场景自动通过。
-7. extension 只暴露白名单脚本工具，不提供任意脚本路径执行器。
-
-## 对抗式审查
-
-| 攻击/失败方式 | 后果 | 当前防线 | 剩余边界 |
-|---|---|---|---|
-| 两个 agent 同时推进同一步 | 丢更新、重复 checkpoint | project lock + revision/CAS | NFS 等非标准锁语义需另行验证 |
-| 模型直接编辑 STATE/workflow | 状态与制品漂移 | `tool_call` 拦截 + 专用 writer tools | extension 是进程内代码，安装源必须可信 |
-| 索引过期仍被当作真相 | 修改错文件或漏影响面 | advisory index + LSP/源码回退 | 大仓库降级扫描会更慢 |
-| 子 agent 自己验证自己 | 漏报和确认偏差 | 实现、审查、验证角色拆开 | 是否接受风险仍由父会话/用户决定 |
-| skill 在根目录和插件目录复制 | 两份规则逐渐分叉 | 插件实体唯一真本 + 根兼容链接 + 布局测试 | Windows checkout 的 symlink 策略需在发布环境验证 |
-| marketplace 只缓存插件子目录 | 跨包链接断裂或 Extension 未加载 | 每个插件自包含 capability 内容；完整 Runtime 由安装器部署 | 跨插件工作流要求全套能力包和项目 Runtime |
-| 任意脚本包装器扩大执行面 | prompt 注入获得任意执行 | 按插件拆分的枚举/固定脚本工具 | 脚本本身仍需代码审查 |
-| OMP 导入外部 harness 配置 | 规则冲突、工具面失控 | project config 禁用外部配置发现源 | 用户全局模型凭据仍由用户管理 |
-
-## 安装模型
-
-项目固定版本模式是完整研发流水线的标准安装方式：`.skills` 作为 submodule，运行 `install.sh --apply` 生成 `.omp` 配置、extensions、agents 和 gate policy，并执行完整性 postflight。
-
-Marketplace 模式只适合按能力启停 Skills、Agents、Commands 等内容。OMP Marketplace 安装不会加载 `package.json` 的 `omp.extensions`，所以即使六个插件全部安装，也不等价于完整 Runtime。完整流水线仍需项目安装器；更新 Extension 后必须重启会话，仅 Skill 变化可 reload plugins。
-
-## 启动与模型门禁
-
-`/devflow start <feature>|<phase>` 不是提示词别名。Core Extension 按以下顺序执行：
-
-1. 运行 `/devflow doctor` 等价预检；
-2. 验证 Extension tools、Skills、Agents、脚本和项目配置；
-3. 用 OMP 模型解析器解析 `@smol`、`@task`、`@slow`；
-4. 拒绝未解析角色或三个角色落到同一具体模型；
-5. 初始化 workflow/state/artifact registry；
-6. 调用 inspector 生成最小当前步骤信封；
-7. 通过 `sendUserMessage` 自动启动 `workflow-pipeline`。
-
-进入 runtime loop 后，每次成功迁移都重新 inspect 并继续下一合法步骤，直到人工 checkpoint、`blocked`、工具硬失败或 `workflow_complete`。因此“自动跑完整流程”表示自动跑到下一个必须由人或外部事实决定的边界，不表示自动批准 checkpoint。
-
-`task.agentModelOverrides` 以 agent name 为键，优先于 agent frontmatter 和父模型继承。模型角色的具体 provider/model 仍由项目所有者在 OMP 项目 role store 中选择，仓库不硬编码供应商凭据或可能过期的模型 ID。
-
-## 验证门槛
-
-发布前至少通过：
-
-- 每个根 skill 唯一映射到一个插件实体目录；
-- 单插件复制到独立缓存后不存在断链 skill；
-- 所有 SKILL frontmatter 只有稳定的 `name`、`description`；
-- 安装器不创建 `.claude/`、`.codex/` 或 `.omp/skills`；
-- 同 revision 并发写只有一个成功；
-- Ruby/Python/JSON/Bash 语法检查和 Bun extension build；
-- 在实际安装的 OMP 版本中做一次 extension 加载与 `/devflow status` 冒烟测试。

package/plugins/devflow-core/skills/workflow-orchestrator/templates/uat-remediation.yaml

@@ -1,176 +0,0 @@
-schema_version: 1
-id: uat-remediation
-name: Verify Failure Remediation
-description: >
-  Generic remediation flow for failed verification or rejected acceptance checkpoints.
-
-artifact_registry:
-  source: ".planning/artifacts/index.yaml"
-  path_key: path
-  status_key: status
-  pending_statuses:
-    - planned
-    - pending_rerun
-  terminal_success_statuses:
-    - approved
-    - completed
-    - passed
-
-entry:
-  from_flow: feature-development
-  from_step: verify
-  triggers:
-    state_statuses:
-      - failed
-    checkpoint_decisions:
-      - rejected
-      - needs_fix
-    artifact_statuses:
-      - failed
-  initial_step: diagnose
-
-state_contract:
-  source: ".planning/STATE.md"
-  suggested_transition:
-    current_flow: uat-remediation
-    current_step: diagnose
-    status: in_progress
-    completed_steps: []
-    pending_steps:
-      - diagnose
-      - execute-fix
-      - code-index-refresh
-      - run-acceptance-tests
-      - reverify
-      - lesson
-
-variables:
-  feature:
-    source: state.current_feature
-  phase:
-    source: state.current_phase
-
-lessons_policy:
-  sources:
-    - path: ".context/lessons/README.md"
-      required: false
-    - path: ".planning/lessons/README.md"
-      required: false
-  selection:
-    enabled: true
-    max_candidates: 8
-    min_score: 1
-  write:
-    enabled: true
-    default_dir: ".context/lessons"
-    index_path: ".context/lessons/README.md"
-    template_only: true
-
-steps:
-  - id: diagnose
-    order: 10
-    label: Diagnose failure
-    skill: workflow-bug-fix
-    depends_on: []
-    inputs:
-      - ".planning/phases/{phase}/01-UAT.md"
-      - ".planning/phases/{phase}/01-VERIFICATION.md"
-      - ".planning/phases/{phase}/SUMMARY.md"
-      - ".planning/features/{feature}/PROGRESS.md"
-      - ".planning/test-runs/{feature}/acceptance-results.json"
-      - ".planning/artifacts/index.yaml"
-    outputs:
-      - path: ".planning/phases/{phase}/REMEDIATION.md"
-        type: remediation-diagnosis
-        required: true
-
-  - id: execute-fix
-    order: 20
-    label: Execute fix
-    skill: workflow-execute-phase
-    depends_on:
-      - diagnose
-    inputs:
-      - ".planning/phases/{phase}/REMEDIATION.md"
-      - ".planning/features/{feature}/变更清单.md"
-      - ".planning/features/{feature}/PROGRESS.md"
-    outputs:
-      - path: ".planning/phases/{phase}/REMEDIATION-SUMMARY.md"
-        type: remediation-summary
-        required: true
-
-  - id: code-index-refresh
-    order: 25
-    label: Code index refresh
-    skill: workflow-code-index
-    depends_on:
-      - execute-fix
-    inputs:
-      - ".planning/phases/{phase}/REMEDIATION-SUMMARY.md"
-      - ".planning/features/{feature}/变更清单.md"
-      - ".planning/features/{feature}/PROGRESS.md"
-    outputs:
-      - path: ".planning/code-index/index.sqlite"
-        type: code-index-sqlite
-        required: true
-      - path: ".planning/code-index/AUDIT.md"
-        type: code-index-audit
-        required: true
-
-  - id: reverify
-    order: 30
-    label: Reverify
-    skill: workflow-verify-work
-    depends_on:
-      - run-acceptance-tests
-    inputs:
-      - ".planning/phases/{phase}/REMEDIATION-SUMMARY.md"
-      - ".planning/features/{feature}/PROGRESS.md"
-      - ".planning/test-runs/{feature}/acceptance-results.json"
-    outputs:
-      - path: ".planning/phases/{phase}/01-UAT.md"
-        type: uat-report
-        required: true
-      - path: ".planning/phases/{phase}/01-VERIFICATION.md"
-        type: verification-report
-        required: true
-    checkpoint: CP-4
-
-  - id: run-acceptance-tests
-    order: 28
-    label: Re-run frozen acceptance tests
-    skill: workflow-run-acceptance-tests
-    depends_on:
-      - code-index-refresh
-    inputs:
-      - ".planning/requirements/{feature}/tests.json"
-      - ".planning/features/{feature}/acceptance-test-bindings.json"
-      - ".planning/test-runs/{feature}/acceptance-results.json"
-      - ".planning/code-index/index.sqlite"
-      - ".planning/code-index/AUDIT.md"
-    outputs:
-      - path: ".planning/test-runs/{feature}/acceptance-results.json"
-        type: acceptance-test-results
-        required: true
-
-  - id: lesson
-    order: 40
-    label: Record lesson if needed
-    action: write-lesson-if-needed
-    depends_on:
-      - reverify
-    inputs:
-      - ".planning/phases/{phase}/REMEDIATION.md"
-      - ".planning/phases/{phase}/01-UAT.md"
-      - ".planning/phases/{phase}/01-VERIFICATION.md"
-    outputs:
-      - path: ".context/lessons/README.md"
-        type: lessons-index
-        required: false
-
-return_to:
-  flow: feature-development
-  step: verify
-  status: waiting_checkpoint
-  checkpoint: CP-4
-  condition: "reverify outputs pass and user confirms CP-4"

package/plugins/devflow-quality/skills/workflow-audit-milestone/SKILL.md

@@ -1,31 +0,0 @@
----
-name: workflow-audit-milestone
-description: "Use when a milestone needs completion audit against original requirements, phase outputs, verification evidence, and archive readiness."
----
-
-<objective>
-Verify milestone achieved its definition of done. Check requirements coverage, cross-phase integration, and end-to-end flows.
-
-**This command IS the orchestrator.** Reads existing VERIFICATION.md files (phases already verified during execute-phase), aggregates tech debt and deferred gaps, then spawns integration checker for cross-phase wiring.
-</objective>
-
-<execution_context>
-references/audit-milestone.md
-</execution_context>
-
-<context>
-Version: $ARGUMENTS (optional — defaults to current milestone)
-
-Core planning files are resolved in-workflow (`init milestone-op`) and loaded only as needed.
-
-When `.planning/code-index/` exists, milestone integration checks should use it for source-level route/call/import/data-flow/test relationships and read source evidence before reporting wiring gaps. The detailed policy lives in `references/audit-milestone.md`.
-
-**Completed Work:**
-Glob: .planning/phases/*/*-SUMMARY.md
-Glob: .planning/phases/*/*-VERIFICATION.md
-</context>
-
-<process>
-Execute the audit-milestone workflow from references/audit-milestone.md end-to-end.
-Preserve all workflow gates (scope determination, verification reading, integration check, requirements coverage, routing).
-</process>