cowork-flow 2.1.0 → 2.2.0

package/CHANGELOG.md

@@ -4,6 +4,13 @@
 
 ### Added
 
+## [2.2.0] - 2026-10-20
+
+### Changed
+
+- **计划与任务验证段纳入规范门禁检查**：`task-planning` 的计划 `Final Verification`、任务规则与 Self-Review 要求按 `dev_type` 逐条核对 `.cowork-flow/spec/<dev_type>/` 适用规范与项目门禁——改动被规范覆盖时，把决定命令或 `规范核对:` 行写进计划的 Final Verification 与任务简报的 Verification Command，标 `pass` / `not_applicable` 并写理由；`decision-anchor` 契约的 `## 验证命令` 同步要求该检查行，并明确为 review 强提醒而非 `spec-check` 硬门禁，120 字符/10 行限制不变。
+- **模板示例统一展示规范核对行**：`decision-anchor` Schema 的 `## 验证命令` 示例新增 `规范核对:` 行；`task-planning` 任务简报的 `Verification Command` 示例块后补充写法说明，避免新建计划/任务漏写规范检查项。
+
 ## [2.1.0] - 2026-10-19
 
 ### Added
@@ -386,7 +393,8 @@
 
 此版本未保留本地条目正文，详情见 [GitHub Release](https://github.com/fishlikewater/cowork-flow/releases/tag/v0.0.47)。
 
-[Unreleased]: https://github.com/fishlikewater/cowork-flow/compare/v2.1.0...HEAD
+[Unreleased]: https://github.com/fishlikewater/cowork-flow/compare/v2.2.0...HEAD
+[2.2.0]: https://github.com/fishlikewater/cowork-flow/compare/v2.1.0...v2.2.0
 [2.1.0]: https://github.com/fishlikewater/cowork-flow/compare/v2.0.0...v2.1.0
 [2.0.0]: https://github.com/fishlikewater/cowork-flow/compare/v1.9.2...v2.0.0
 [1.9.2]: https://github.com/fishlikewater/cowork-flow/compare/v1.9.1...v1.9.2

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cowork-flow",
-  "version": "2.1.0",
+  "version": "2.2.0",
   "description": "CLI for installing and maintaining cowork-flow collaboration templates.",
   "keywords": [
     "ai-agent",

package/presets/claude-code/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "cowork-flow",
-  "version": "2.1.0",
+  "version": "2.2.0",
   "description": "AI 协作工作流引擎：任务生命周期、子代理调度、门禁与状态注入。将 cowork-flow 的完整工作流带入 Claude Code。",
   "displayName": "Cowork Flow",
   "author": {

package/presets/codex/.codex-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "cowork-flow",
-  "version": "2.1.0",
+  "version": "2.2.0",
   "description": "AI 协作工作流引擎：任务生命周期、子代理调度、门禁与状态注入。将 cowork-flow 的完整工作流带入 Codex。",
   "author": {
     "name": "fishlikewater",

package/presets/kimi-code/.kimi-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "cowork-flow",
-  "version": "2.1.0",
+  "version": "2.2.0",
   "description": "AI 协作工作流引擎：任务生命周期、子代理调度、门禁与状态注入。将 cowork-flow 的完整工作流带入 Kimi Code。",
   "author": {
     "name": "fishlikewater",

package/presets/qoder/.qoder-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "cowork-flow",
-  "version": "2.1.0",
+  "version": "2.2.0",
   "description": "AI 协作工作流引擎：任务生命周期、子代理调度、门禁与状态注入。将 cowork-flow 的完整工作流带入 Qoder。",
   "displayName": "Cowork Flow",
   "author": {

package/presets/zcode/.zcode-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "cowork-flow",
-  "version": "2.1.0",
+  "version": "2.2.0",
   "description": "AI 协作工作流引擎：任务生命周期、子代理调度、门禁与状态注入。将 cowork-flow 的完整工作流带入 ZCode。",
   "author": {
     "name": "fishlikewater",

package/template/.cowork-flow/.version

@@ -1 +1 @@
-2.1.0
+2.2.0

package/template/.cowork-flow/spec/contracts/decision-anchor.md

@@ -33,6 +33,7 @@ translated heading would simply stop being read.
 
 ## 验证命令
 - `<command>` → <expected>
+- 规范核对：逐条核对 `.cowork-flow/spec/<dev_type>/` 适用规范 → pass / not_applicable（附理由）
 ```
 
 ## Section requirements
@@ -44,7 +45,7 @@ translated heading would simply stop being read.
 | `## 被拒方案` | optional | required for brainstorming tasks, so a rejected option is not reconsidered during execution |
 | `## 关键假设` | optional | filled in for complex tasks to surface implicit constraints; not read by the runtime parser |
 | `## 范围边界` | optional | prevents scope creep |
-| `## 验证命令` | optional | filled in for complex tasks, as the basis for automated verification |
+| `## 验证命令` | optional | filled in for complex tasks, as the basis for automated verification; when the changed files are covered by `.cowork-flow/spec/backend/` or `frontend/` rules, it must also carry the spec/gate check for the task's `dev_type` (deciding command, or clause-by-clause `pass` / `not_applicable` with reason) |
 
 ### Machine-readable line formats (for injection)
 
@@ -54,6 +55,11 @@ fact view (`services/fact_view.parse_decision_anchor`). Line-format conventions:
 - `## 验证命令`: one command per line (an optional `- ` prefix), truncated to 120
   characters, at most 10 lines; the implementing agent runs them itself
   (self-declared, self-checked) and the reviewer verifies the execution evidence.
+  When the changed files are covered by `.cowork-flow/spec/<dev_type>/` rules, the
+  section must also carry the spec/gate check for the task's `dev_type`: a deciding
+  command, or a `规范核对:` line reviewed clause by clause (`pass` /
+  `not_applicable` + reason). This is a strong review reminder, not a `spec-check`
+  hard gate.
 - `## 范围边界`: only the first non-empty line is taken, truncated to 160
   characters.
 

package/template/skills/task-planning/SKILL.md

@@ -45,7 +45,7 @@ Start with a concise brief:
 | **Task Type** | Tiny / Normal / High-risk: <reason> |
 | **Strategy** | Serial / Parallel: <why> |
 | **Success Criteria** | AC-001 / AC-002 / AC-003 |
-| **Final Verification** | `<command>` -> exit 0; `<command>` -> exit 0 |
+| **Final Verification** | `<command>` -> exit 0; clause-by-clause check against applicable `.cowork-flow/spec/<dev_type>/` rules and project gates -> `pass` / `not_applicable` per clause |
 | **Primary Risk** | Low / Medium / High: <one sentence> |
 
 ## Goal
@@ -116,6 +116,8 @@ Then list task briefs, followed by integrated verification and completion checks
   <command>
   ```
 
+  When changed files are covered by `.cowork-flow/spec/<dev_type>/` rules, add the deciding command or a spec/gate check line (`pass` / `not_applicable` with reason; format example in `decision-anchor.md`) here; it is a strong review reminder, not a hard gate.
+
   **Completion Conditions**
   - <2-4 checkable conditions>
 
@@ -128,7 +130,7 @@ Then list task briefs, followed by integrated verification and completion checks
 
 - For Tiny tasks, keep the brief short but still name exact file boundaries, completion conditions, and verification commands.
 - For behavior changes, include a failing test before implementation when behavior can be tested.
-- For implementation tasks whose changed files are covered by `.cowork-flow/spec/` requirements, name the covered spec files in the plan so review can check them clause by clause.
+- For implementation tasks whose changed files are covered by `.cowork-flow/spec/` requirements, name the covered spec files in the plan and add the clause check to the task's `Verification Command` and the plan's `Final Verification`: run the deciding command when one exists, otherwise check clause by clause and record `pass` / `not_applicable` with reason. This is a strong review reminder, not a separate hard gate.
 - Do not add shallow tests just to satisfy process. Avoid tests that only assert existence, mirror implementation details, count mock calls without behavior, or snapshot empty structure.
 - For complex problems, test depth first: business invariants, cross-layer contracts, state transitions, error boundaries, and real regression paths before narrow unit cases.
 - Map behavior-changing tests to stable `decision-anchor.md` acceptance IDs when useful; do not create `tdd.jsonl` or write TDD evidence records into `check.jsonl`.
@@ -190,3 +192,4 @@ Before handoff:
 3. Confirm every Normal or High-risk task has file boundaries, key symbols, implementation notes, test proof, completion conditions, and prohibited drift.
 4. Check names, paths, command syntax, and expected outputs.
 5. Confirm the plan says to stop and report back when code facts conflict with the plan, a plan-external file becomes necessary, or a test fails for an unplanned reason.
+6. Confirm Final Verification carries the applicable `.cowork-flow/spec/<dev_type>/` clause check, or states why no spec file applies.