agent-project-sdlc 0.1.9 → 0.1.10

package/README.md

@@ -25,8 +25,9 @@ npx sdlc-harness init --adopt
 | Managed file sync | `npx sdlc-harness sync` | Materializes package canonical assets into the configured Harness root while preserving project state, docs and local overrides. |
 | Upgrade | `npx sdlc-harness upgrade` | Runs migrations and sync for already-adopted projects. |
 | Diagnostics | `npx sdlc-harness doctor` | Reports Harness root, package version, schema version and key managed paths. |
-| Validators | `npx sdlc-harness validate-*`, `make validate-current`, `make validate-harness` | Checks phase deliverables, active plan shape, prompt language contract and generated overview freshness. |
+| Validators | `npx sdlc-harness validate-*`, `make validate-current`, `make validate-harness` | Checks product, design, development, review, test, release, RFC, active plan shape, prompt language contract and generated overview freshness. |
 | Lifecycle workflow | `<harnessRoot>/state/lifecycle.yaml`, `<harnessRoot>/state/plan.yaml`, `.docs/**` | Tracks REQUIREMENT_GATHERING, ARCHITECTING, SPRINTING, REVIEWING, TESTING, RELEASING and RFC_RECALIBRATION facts. |
+| Stage task control | `plan.yaml`, `make validate-plan`, `npx sdlc-harness validate-plan` | Keeps each stage's agent work in small `TASK-*` tasks with `phase` metadata and scoped paths/gates. |
 | Natural-language control | `AGENTS.md` plus workflow skills | Lets users say things like "continue", "start development", "run tests" or "requirements changed"; agents map these to workflow actions. |
 | Optional parallel execution contract | `plan.yaml#parallel_execution` | Enabled only when users explicitly request multi-agent, parallel or multi-worktree execution; supports runtime-managed subagents or user-orchestrated worker prompts. |
 | Workflow skills | `<harnessRoot>/skills/pjsdlc_*/SKILL.md` | Provides role prompts for product, architecture, development, implementation docs, review, testing, release and RFC recalibration. |
@@ -69,6 +70,10 @@ The default workflow is serial. Agents should only create `parallel_execution` i
 
 The CLI does not promise to automatically launch Codex agents. Workers do not need to communicate with each other; the main agent owns final fact-source updates such as PRD, plan, implementation docs, test results and generated overviews.
 
+## Stage Task Control
+
+Every stage's agent work is plan-controlled. Conversational PRD or design creation, existing document slicing, fact-source-based synthesis, development, review, testing, release preparation and RFC recalibration should create or resume one small `TASK-*` task in `plan.yaml` with a valid `phase`, write the current task's `result_docs` or `implementation_doc`, update indexes/overviews, run `validate-plan`, and remove the task after completion. Phase exit validators reject remaining open tasks.
+
 ## Common Commands
 
 ```sh
@@ -77,6 +82,11 @@ npx sdlc-harness init --adopt
 npx sdlc-harness sync
 npx sdlc-harness upgrade
 npx sdlc-harness doctor
+npx sdlc-harness validate-plan
+npx sdlc-harness validate-review
+npx sdlc-harness validate-test
+npx sdlc-harness validate-release
+npx sdlc-harness validate-rfc
 make validate-current
 make validate-harness
 make docs-overview

package/assets/agents/AGENTS_CORE.md

@@ -30,9 +30,11 @@
 
 ## Plan Protocol
 
-- `plan.yaml` 是当前和未来任务的短期执行计划事实源。open task 直接包含 `allowed_paths`、`required_gates`、`acceptance_criteria` 和必要的 `working_notes`。
-- `next_task_sequence` 记录下一个可分配的 `DEV-*` 序号，避免删除历史 task 后发生 id 冲突。
-- task 完成并写入或更新相关 implementation doc 后，从 `plan.yaml` 的 `tasks` 列表移除该 task；不要长期保留 done/cancelled task 摘要。
+- `plan.yaml` 是当前和未来任务的短期执行计划事实源。每个阶段的每个 Agent 主任务都应先检查是否过长，必要时拆成大小合适的 open task；open task 直接包含 `phase`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和必要的 `working_notes`。
+- 新建任务统一使用 `TASK-*` id，并通过 `phase` 标明属于 `REQUIREMENT_GATHERING`、`ARCHITECTING`、`SPRINTING`、`REVIEWING`、`TESTING`、`RELEASING` 或 `RFC_RECALIBRATION`；历史 `PRD-*`、`DES-*`、`DEV-*` 只作为兼容旧记录和旧提交的 provenance。
+- `next_task_sequence` 记录下一个可分配的 `TASK-*` 序号，避免删除历史 task 后发生 id 冲突。
+- 文档、Review、测试、发布和 RFC 类 task 使用 `result_docs` 指向本 task 产出的 PRD、architecture、tech plan、ADR、review report、test plan、release note、RFC 或 `plan.draft.yaml`；开发 task 使用 `implementation_doc` 指向模块级实现事实。
+- task 完成并写入或更新相关事实源后，从 `plan.yaml` 的 `tasks` 列表移除该 task；不要长期保留 done/cancelled task 摘要。
 - `plan.draft.yaml` 是架构阶段生成的计划草案，不自动覆盖 `plan.yaml`。
 - 不维护 checkpoint 文件；任务现场只存在于 open task 的 plan 条目里。
 - 历史动作记录以 git commit 为准，产物结果以模块、子系统或核心数据流级 implementation doc 为准。
@@ -133,8 +135,8 @@ Strong success criteria 可以让你 independent loop。Weak criteria，例如
 1. 选择任何角色或 skill 前，先读取 `.codex/state/lifecycle.yaml`。
 2. 除非用户明确要求其它工作流动作，否则使用 `active_skill` 指定的 workflow skill。
 3. 产品文档和技术方案未形成前，不写业务代码。
-4. 在 `SPRINTING` 阶段，一次只执行一个任务。
-5. 在 `SPRINTING` 阶段，只编辑当前 open task 的 `allowed_paths` 允许的文件。
+4. 每个阶段一次只执行一个 open task；如果任务过长，先拆成多个 `TASK-*`，当前轮只推进 `current_task_id`。
+5. 每个阶段只编辑当前 open task 的 `allowed_paths` 允许的文件；只读角色仍不得修改源码。
 6. 不要在当前 open task 的 `required_gates` 通过前把任务标记为 `done`。
 7. 代码 gate 通过后，更新相关 implementation doc 和 `.docs/INDEX.md`。
 8. `reviewer` 角色只读，不直接修改源码。
@@ -142,7 +144,7 @@ Strong success criteria 可以让你 independent loop。Weak criteria，例如
 10. task/release 历史动作记录使用 git commit、tag 或外部 release 系统，不维护 `<harnessRoot>/archive/` 常规归档。
 11. 在 `SPRINTING` 阶段，task 完成闭环必须先创建 task implementation commit，再提交移除该 task 后的 task completion ledger commit；如果没有 remote/upstream、权限或凭证导致无法 push，不要开始下一个 task，先报告 blocker。
 12. 文档 slice 发生变化后，运行 `make docs-overview` 刷新对应 `overview.md`。
-13. open task 必须在 `plan.yaml` 中包含完整执行合同，再继续推进或交接。
+13. open task 必须在 `plan.yaml` 中包含完整执行合同，再继续推进或交接；方案生成、现有文档切片、基于上一阶段事实源生成、Review、测试、发布和 RFC 处理都必须先落到 `plan.yaml` task。
 14. 默认不读取过去 task 或 phase 执行流水；修 bug、补功能和阶段交付以当前代码、测试、PRD、技术方案和模块级 implementation doc 为准。
 15. gate 证据写入当前 task `working_notes` 或相关 implementation doc 的 `Verification`；不要维护独立 gate results state。
 16. 如果信息缺失，或 gate 因基础设施原因失败，停止推进并报告 blocker。
@@ -157,8 +159,8 @@ Strong success criteria 可以让你 independent loop。Weak criteria，例如
 - “继续 / 下一步 / 推进” → 等价 `/next`。
 - “能进入下一阶段吗 / 进入下一步” → 等价 `/advance`。
 - “需求变了 / 这个设计要改” → 进入 RFC workflow。
-- “完善产品方案 / 写 PRD / 我提供信息，你帮我完善产品方案” → 等价 `/prd`。
-- “设计技术方案 / 做架构方案 / 根据 PRD 做技术方案” → 等价 `/design`。
+- “完善产品方案 / 写 PRD / 文档切片 / 我提供信息，你帮我完善产品方案” → 等价 `/prd`，一次只执行一个 `phase: "REQUIREMENT_GATHERING"` 的 `TASK-*`。
+- “设计技术方案 / 做架构方案 / 根据 PRD 做技术方案 / 切技术方案” → 等价 `/design`，一次只执行一个 `phase: "ARCHITECTING"` 的 `TASK-*`。
 - “开始开发 / 做当前任务 / 做下一个任务” → 等价 `/dev`。
 - “开始循环：写任务，执行任务 / 把开发循环跑完” → 等价 `/devloop`。
 - “跑测试 / 验证一下” → 运行当前 task 或阶段对应 gate。
@@ -175,9 +177,9 @@ Parallel Execution 是可选协作协议，不是默认模式，也不是 CLI
 - `/next`：运行当前阶段映射的 workflow skill。
 - `/advance`：校验当前阶段出口 gate，通过后才尝试流转。
 - `/rfc <file>`：挂起当前流程并进入 RFC recalibration。
-- `/prd`：在 `REQUIREMENT_GATHERING` 调用产品方案工作流，澄清需求并更新 PRD、验收标准、open questions、`.docs/INDEX.md` 和 overview。
-- `/design`：在 `ARCHITECTING` 调用架构和技术方案工作流，基于 PRD 更新 architecture、tech plan 和 `plan.draft.yaml`。
-- `/dev`：在 `SPRINTING` 创建或选择下一个最小 DEV task，执行一个 task，跑 gate，更新模块级 implementation doc，按两段 commit/push 闭环后停止。
+- `/prd`：在 `REQUIREMENT_GATHERING` 创建或选择一个最小 `TASK-*` task，澄清需求或切片文档，并只更新当前 task 对应的 PRD、验收标准、open questions、`.docs/INDEX.md` 和 overview。
+- `/design`：在 `ARCHITECTING` 创建或选择一个最小 `TASK-*` task，基于 PRD 生成或切分当前 task 对应的 architecture、tech plan 和 `plan.draft.yaml`。
+- `/dev`：在 `SPRINTING` 创建或选择下一个最小 `TASK-*` development task，执行一个 task，跑 gate，更新模块级 implementation doc，按两段 commit/push 闭环后停止。
 - `/devloop`：在 `SPRINTING` 连续运行 `/dev` 循环，直到没有明确可创建/执行的任务，或遇到需求、架构、allowed_paths、gate、commit/push blocker。
 - `/syncdocs`：同步 `.docs/INDEX.md` 与当前文档事实源。
 - `/overview`：运行 `make docs-overview`，刷新 `.docs/<stage>/overview.md` 派生视图。

package/assets/docs/README.md

@@ -60,8 +60,9 @@ npx sdlc-harness init --adopt
 | 同步 managed workflow 文件 | `npx sdlc-harness sync` | 从包内 canonical assets 物化 `AGENTS.md` managed block、workflow skills、templates、policies、Makefile 片段和 GitHub workflow |
 | 升级已接入项目 | `npx sdlc-harness upgrade` | 执行迁移并自动 `sync`，保留 state、docs、业务代码和本地 override |
 | 接入诊断 | `npx sdlc-harness doctor` | 检查 harness root、版本、schema、关键文件和 managed paths |
-| 阶段 gate | `npx sdlc-harness validate-*`、`make validate-current`、`make validate-harness` | 校验需求、设计、开发计划、Harness 骨架、提示词语言契约和 overview freshness |
+| 阶段 gate | `npx sdlc-harness validate-*`、`make validate-current`、`make validate-harness` | 校验需求、设计、开发、Review、测试、发布、RFC、Harness 骨架、提示词语言契约和 overview freshness |
 | 生命周期工作流 | `lifecycle.yaml`、`plan.yaml`、`.docs/**` | 固定 REQUIREMENT_GATHERING、ARCHITECTING、SPRINTING、REVIEWING、TESTING、RELEASING、RFC_RECALIBRATION 等阶段事实链 |
+| 阶段小任务管控 | `plan.yaml`、`make validate-plan` | 每个阶段的 Agent 主任务都应拆成足够小的 `TASK-*` open task，并用 `phase` 标明所属阶段 |
 | 自然语言控制 | `AGENTS.md` + workflow skills | 用户可说“继续”“开始开发”“跑测试”“需求变了”等，由 Agent 映射到 `/next`、`/dev`、`/test`、RFC 等动作 |
 | 可选并行执行合同 | `plan.yaml#parallel_execution` | 用户明确要求多 agent/并行/多 worktree 时启用；支持 runtime-managed subagents 或 user-orchestrated worker prompts |
 | Workflow skills | `<harnessRoot>/skills/pjsdlc_*/SKILL.md` | 提供 PM、架构、开发、实现文档、Review、测试、发布、RFC 等阶段角色提示词 |
@@ -81,7 +82,9 @@ npx sdlc-harness init --adopt
 现在到哪一步了？
 继续推进。
 我提供这些信息，帮我完善产品方案。
+把这个长产品方案切成 slices。
 根据 PRD 做技术方案。
+把现有技术方案切片。
 根据技术方案拆 task。
 开始开发当前 task。
 继续开发下一个任务。
@@ -92,7 +95,7 @@ npx sdlc-harness init --adopt
 准备 review。
 ```
 
-Agent 会读取 `<harnessRoot>/state/lifecycle.yaml` 和 `<harnessRoot>/state/plan.yaml`，再按当前阶段选择对应 workflow skill、产物和 gate。
+Agent 会读取 `<harnessRoot>/state/lifecycle.yaml` 和 `<harnessRoot>/state/plan.yaml`，再按当前阶段选择对应 workflow skill、产物和 gate。任何阶段的 Agent 主任务都不是一次性长生成：产品方案、技术方案、文档切片、基于上一阶段事实源生成、Review、测试、发布和 RFC 处理，都应先落成一个最小 `TASK-*` open task，并设置对应 `phase`；当前轮只执行一个 task，写入 `result_docs` 或 `implementation_doc`、更新索引和 overview，运行 `make validate-plan`，任务完成后再从 `plan.yaml` 移除。
 
 ### Workflow skill 如何生效
 
@@ -144,9 +147,9 @@ Harness CLI v1 不承诺自动启动 Codex agent，也不要求 worker 之间通
 |---|---|---|
 | `/status` | 现在到哪一步了 | 读取 lifecycle/plan，报告当前阶段、任务、阻塞项和下一步 |
 | `/next` | 继续推进 | 按当前阶段的 `active_skill` 执行下一步 |
-| `/prd` | 完善产品方案 | 在需求阶段澄清用户目标、补齐 PRD、验收标准和 open questions |
-| `/design` | 设计技术方案 | 在架构阶段基于 PRD 生成或更新架构、技术方案和 `plan.draft.yaml` |
-| `/dev` | 做下一个任务 | 创建或选择下一个最小 DEV task，完成一个 task 闭环后停止 |
+| `/prd` | 完善产品方案 | 在需求阶段创建或选择一个最小 `TASK-*` task，澄清目标、切片文档或补齐当前 PRD slice |
+| `/design` | 设计技术方案 | 在架构阶段创建或选择一个最小 `TASK-*` task，生成或切分当前 architecture / tech plan / `plan.draft.yaml` 产物 |
+| `/dev` | 做下一个任务 | 创建或选择下一个最小 `TASK-*` development task，完成一个 task 闭环后停止 |
 | `/devloop` | 开始循环：写任务，执行任务 | 连续运行 `/dev`，直到没有明确任务或遇到 blocker |
 | `/test` | 跑一下当前验证 | 运行当前 task 或阶段对应 gate |
 | `/review` | 准备 review | 进入只读 Review workflow |
@@ -179,6 +182,12 @@ npx sdlc-harness upgrade
 make validate-current
 ```
 
+校验当前 open task 合同：
+
+```sh
+make validate-plan
+```
+
 校验整个 Harness：
 
 ```sh

package/assets/make/sdlc-harness.mk

@@ -1,6 +1,6 @@
 PYTHON ?= python3
 
-.PHONY: help status docs-overview validate-doc-overviews validate-harness validate-current validate-pm validate-design validate-dev validate-review validate-test validate-release validate-rfc lint test-current-domain test-all build
+.PHONY: help status docs-overview validate-doc-overviews validate-harness validate-current validate-plan validate-pm validate-design validate-dev validate-review validate-test validate-release validate-rfc lint test-current-domain test-all build
 
 help:
 	@echo "AI SDLC Harness commands"
@@ -9,6 +9,7 @@ help:
 	@echo "  make validate-doc-overviews 校验 .docs 各阶段 overview.md 是否最新"
 	@echo "  make validate-harness    校验 Harness 骨架、配置和提示词语言契约"
 	@echo "  make validate-current    运行当前 lifecycle phase 的 gate"
+	@echo "  make validate-plan       校验 plan.yaml task 合同，允许当前 open task"
 	@echo "  make validate-pm         校验产品需求产物"
 	@echo "  make validate-design     校验架构设计、技术方案和任务草案"
 	@echo "  make validate-dev        校验 sprint 任务状态、路径、代码 gate 和实现文档"
@@ -34,6 +35,10 @@ validate-harness:
 validate-current:
 	$(PYTHON) tools/run_current_gate.py
 
+validate-plan:
+	$(PYTHON) tools/validate_plan.py --allow-open
+	$(PYTHON) tools/validate_allowed_paths.py
+
 validate-pm:
 	test -f .docs/INDEX.md
 	$(PYTHON) tools/validate_prd.py

package/assets/policies/allowed_paths.yaml

@@ -31,17 +31,20 @@ phases:
   REVIEWING:
     read_only_source: true
     write:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/06_review/**"
       - ".docs/INDEX.md"
 
   TESTING:
     write:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/07_test/**"
       - "tests/**"
       - ".docs/INDEX.md"
 
   RELEASING:
     write:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/08_release/**"
       - ".docs/INDEX.md"
 

package/assets/policies/gates.yaml

@@ -5,6 +5,18 @@ gates:
     required_for:
       - "all"
 
+  validate-plan:
+    command: "make validate-plan"
+    purpose: "验证当前 open task 合同，允许任务执行中保留 open task"
+    required_for:
+      - "REQUIREMENT_GATHERING"
+      - "ARCHITECTING"
+      - "SPRINTING"
+      - "REVIEWING"
+      - "TESTING"
+      - "RELEASING"
+      - "RFC_RECALIBRATION"
+
   validate-pm:
     command: "make validate-pm"
     purpose: "验证 PRD、验收标准、Out of Scope 和 Open Questions"

package/assets/policies/phase_contracts.yaml

@@ -15,8 +15,10 @@ phases:
     role: "pm"
     skill: "pjsdlc_pm_prd"
     inputs:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/00_raw/"
     outputs:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/01_product/"
       - ".docs/INDEX.md"
     gates:
@@ -28,9 +30,11 @@ phases:
     role: "architect"
     skill: "pjsdlc_architect_design"
     inputs:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/01_product/"
       - ".docs/02_architecture/"
     outputs:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/02_architecture/"
       - ".docs/03_tech_plan/"
       - "<harnessRoot>/state/plan.draft.yaml"
@@ -60,11 +64,13 @@ phases:
     role: "reviewer"
     skill: "pjsdlc_reviewer"
     inputs:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/01_product/"
       - ".docs/03_tech_plan/"
       - ".docs/04_implementation/"
       - "git diff"
     outputs:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/06_review/REVIEW_REPORT.md"
     gates:
       - "make validate-review"
@@ -75,11 +81,13 @@ phases:
     role: "tester"
     skill: "pjsdlc_tester"
     inputs:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/01_product/"
       - ".docs/03_tech_plan/"
       - ".docs/04_implementation/"
       - ".docs/06_review/"
     outputs:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/07_test/"
       - "tests/"
     gates:
@@ -91,9 +99,11 @@ phases:
     role: "release_manager"
     skill: "pjsdlc_release_manager"
     inputs:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/07_test/"
       - "build artifacts"
     outputs:
+      - "<harnessRoot>/state/plan.yaml"
       - ".docs/08_release/"
     gates:
       - "make validate-release"

package/assets/skills/pjsdlc_architect_design/SKILL.md

@@ -17,9 +17,12 @@ description: Use during ARCHITECTING to create architecture docs, technical plan
 
 架构产物应区分稳定边界和实现计划：architecture slice 记录领域边界、子系统、关键风险和长期约束；tech plan slice 记录接口契约、数据模型、模块方案、任务拆分和 gate。不要把重大架构变化藏在 task 描述里。
 
+架构和技术方案产出本身也是 workflow task，而不是一次性长文档生成。无论来源是对话式设计、既有完整技术方案切片，还是根据 PRD/architecture 事实源生成新方案，都要先在 `<harnessRoot>/state/plan.yaml` 创建或选择一个足够小的 `TASK-*` open task，并设置 `phase: "ARCHITECTING"`，只完成当前 `current_task_id` 对应的一片 architecture / tech plan / ADR / `plan.draft.yaml` 产物。不要在一个任务里连续创建大量设计文件；如果需要多个 slices，先拆出 pending tasks，当前轮只执行一个 task。
+
 ## 输入
 
 - `.docs/INDEX.md`
+- `<harnessRoot>/state/plan.yaml`
 - 相关 `.docs/01_product/` PRD
 - 现有 `.docs/02_architecture/`
 - 当前代码结构概览
@@ -32,6 +35,7 @@ description: Use during ARCHITECTING to create architecture docs, technical plan
 - `.docs/03_tech_plan/` 下的技术方案
 - 需要长期保留的 ADR 写入 `.docs/05_decisions/`
 - `<harnessRoot>/state/plan.draft.yaml`
+- 更新后的 `<harnessRoot>/state/plan.yaml`
 - 更新后的 `.docs/INDEX.md`
 
 ## 语义切片
@@ -41,21 +45,38 @@ description: Use during ARCHITECTING to create architecture docs, technical plan
 - `.docs/05_decisions/` 按单个架构决策切片，即一份 ADR 只记录一个 durable decision。
 - 如果一个技术方案跨越多个独立模块，应拆成多个 tech plan slice，并在 `plan.draft.yaml` 中分别引用。
 - 如果实现计划改变了已有模块边界，应更新相关 architecture slice，而不是只在 task 描述里补一句。
+- 如果用户明确要求把既有完整技术方案文件切成多个 `.docs/03_tech_plan/` slices，先确认 replacement slices 覆盖原文件中仍有效的接口契约、数据模型、模块方案、任务组和 gate；切片完成并更新 `plan.draft.yaml` 引用、`.docs/INDEX.md`、刷新 `overview.md` 后，删除被替代的完整 tech plan file，避免同一事实由完整文件和 slices 双重保留。
 - 每次新增、拆分、合并或废弃 slice 后，都要更新 `.docs/INDEX.md`。
 
+## Plan Protocol
+
+架构和技术方案阶段的方案生成、既有文档切片和上一阶段事实源合成都受 `plan.yaml` 管控：
+
+1. 没有 open task 时，先创建一个最小 `TASK-*` task，设置 `phase: "ARCHITECTING"` 和 `current_task_id`。
+2. open task 必须包含 `phase`、`docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和 `result_docs`；`result_docs` 指向本 task 计划产出的 `.docs/02_architecture/`、`.docs/03_tech_plan/`、`.docs/05_decisions/` 或 `<harnessRoot>/state/plan.draft.yaml`。
+3. 单个 task 的目标应足够小：一个子系统 architecture slice、一个 tech plan slice、一个接口契约、一组开发任务草案，或从完整技术方案中切出的一个语义 slice。
+4. 如果需要多个 architecture / tech plan slices，先生成多个 pending `TASK-*` tasks 或至少创建当前 task 并在 `working_notes` 写明剩余 slices；当前轮只执行一个 task。
+5. 执行当前 task 时只编辑 `allowed_paths` 中的文件，完成后更新 `.docs/INDEX.md`、运行 `make docs-overview`，并至少运行 `make validate-plan`；阶段出口前再运行 `make validate-design`。
+6. task 完成后，从 `plan.yaml.tasks` 移除该 task；如果仍有 pending `TASK-*` design task，下一轮 `/design` 或 `/next` 再继续。
+7. 如果网络或上下文中断，新会话先读取 `current_task_id` 和当前 open task，按 `working_notes` 恢复，而不是重新生成全量技术方案。
+
 ## 规则
 
 1. 技术方案必须引用 PRD 路径和 requirement IDs。
-2. 每个 open task 必须包含 `id`、`title`、`status`、`summary`、`docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和 `implementation_doc`。
+2. 每个 open task 必须包含 `id`、`phase`、`title`、`status`、`summary`、`docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和 `result_docs`；开发阶段 task 继续使用 `implementation_doc`。
 3. `plan.draft.yaml` 不得自动覆盖 `plan.yaml`。
 4. 风险或不清晰的问题按 `<harnessRoot>/pjsdlc_managed/policies/risk_matrix.yaml` 标记。
-5. 任务边界应足够小，能在一次开发执行内闭环；`implementation_doc` 应指向将被更新或新增的模块、子系统或核心数据流文档。
+5. 任务边界应足够小，能在一次设计执行内闭环；`result_docs` 应指向将被更新或新增的 architecture、tech plan、ADR 或 `plan.draft.yaml` 文件。
+6. `make validate-design` 是阶段出口 gate；如果还有 open `TASK-*` design task，不要请求进入 `SPRINTING`。
 
 ## 完成检查
 
 - [ ] 架构文档和技术方案已生成。
 - [ ] 相关接口契约和数据结构已明确。
+- [ ] 当前设计产出或切片工作已绑定 `plan.yaml` 中一个最小 `TASK-*` task，并设置 `phase: "ARCHITECTING"`。
+- [ ] 当前 task 已从 `plan.yaml` 移除，或因中断/blocker 保留为可恢复 open task。
 - [ ] 已判断 architecture / tech plan / ADR 的语义切片边界。
+- [ ] 如果用户要求把完整技术方案切成 tech plan slices，已删除被替代的完整 tech plan file，并同步 `plan.draft.yaml` 引用。
 - [ ] task draft 字段完整且范围清晰。
 - [ ] `.docs/INDEX.md` 已链接新增产物。
 - [ ] 已运行 `make docs-overview` 刷新 `.docs/<stage>/overview.md`。

package/assets/skills/pjsdlc_dev_sprint/SKILL.md

@@ -15,7 +15,7 @@ description: Use during SPRINTING to execute one task from plan.yaml, respecting
 
 开始编码前，先确认当前 open task 是否完整，修改范围是否覆盖必要文件，验收标准是否能被测试或 gate 验证。如果发现任务边界、产品行为或技术方案不清晰，要停下来说明 blocker、给出可能解释和推荐下一步，而不是扩大范围继续写。
 
-`/dev` 和 `/devloop` 是开发阶段的两个入口。`/dev` 创建或选择下一个最小 DEV task，并只完成一个 task 闭环后停止。`/devloop` 连续运行 `/dev`，直到技术方案中没有明确可创建/执行的任务，或遇到需求、架构、allowed_paths、gate、commit/push blocker。
+`/dev` 和 `/devloop` 是开发阶段的两个入口。`/dev` 创建或选择下一个最小 `TASK-*` development task，设置 `phase: "SPRINTING"`，并只完成一个 task 闭环后停止。`/devloop` 连续运行 `/dev`，直到技术方案中没有明确可创建/执行的任务，或遇到需求、架构、allowed_paths、gate、commit/push blocker。
 
 实现时遵循小步闭环：先检查 `git status`，确认工作区没有未归属到当前 task 的脏变更；再定位相关代码和测试，做必要修改，运行 gate，修复失败，写入或更新相关 implementation doc 并刷新文档派生视图。此时先不要从 `plan.yaml` 移除当前 task，要在当前 task 仍位于 `plan.yaml` 时创建 task implementation commit；随后再移除 task，创建 task completion ledger commit，并 push 两个 commit。不要顺手重构、重排格式或处理无关问题；如果发现无关风险，只记录或报告。
 
@@ -44,14 +44,14 @@ description: Use during SPRINTING to execute one task from plan.yaml, respecting
 
 - `SPRINTING` 阶段的执行单元是 `current_task_id`，不要在开发中重新生成整个 Sprint 计划。
 - 当前 task 是开发阶段的执行单元、修改边界和提交边界；implementation doc 的长期语义切片是模块、子系统或核心数据流。
-- open task 在 `plan.yaml` 中直接保存 `docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和必要的 `working_notes`。
+- open task 在 `plan.yaml` 中直接保存 `phase: "SPRINTING"`、`docs`、`allowed_paths`、`required_gates`、`acceptance_criteria`、`implementation_doc` 和必要的 `working_notes`。
 - task implementation commit 必须发生在 task 移除之前，避免实现变更和计划短期化混在同一个提交里。
 - task completion ledger commit 发生在 implementation commit 之后，只负责将该 task 从当前 `plan.yaml` 移除。
-- 一个开发 task 默认对应一个主要 implementation commit 和一个轻量 completion ledger commit。implementation commit message 应包含 task id，例如 `DEV-003: implement login rate limit`；push 成功前，不进入下一个 task。
+- 一个开发 task 默认对应一个主要 implementation commit 和一个轻量 completion ledger commit。implementation commit message 应包含 task id，例如 `TASK-003: implement login rate limit`；push 成功前，不进入下一个 task。
 - 本 Skill 不直接重切 PRD 或 tech plan；如果发现上游语义边界错误，进入 `BLOCKED`、创建 RFC，或请求回到 `ARCHITECTING`。
 - gate 通过后调用 `pjsdlc_implementation_doc`，由该 Skill 按真实实现更新或新增 `.docs/04_implementation/` 模块级 slice。
 - 如果一个任务实际变成多个独立实现边界，应停止扩大范围，拆分后续任务或回到任务规划。
-- `/dev` 是单任务执行入口：没有 open task 时，先根据 PRD、architecture、tech plan 和 `plan.draft.yaml` 创建一个最小 open task；已有 open task 时，直接执行该 task；完成后停止。
+- `/dev` 是单任务执行入口：没有 open task 时，先根据 PRD、architecture、tech plan 和 `plan.draft.yaml` 创建一个最小 `TASK-*` open task；已有 open task 时，直接执行该 task；完成后停止。
 - `/devloop` 是连续执行入口：每完成一个 task 并 push 两段提交后，重新读取 lifecycle、plan、PRD、architecture 和 tech plan，再决定是否创建/执行下一个最小 task；没有明确任务或出现 blocker 时停止并报告。
 - Parallel Execution 是当前 task 的可选协作方式，不替代 task completion protocol；`SPRINTING` 并行必须用 `parallel_execution.linked_task_id` 绑定当前 `current_task_id`。
 
@@ -60,7 +60,7 @@ description: Use during SPRINTING to execute one task from plan.yaml, respecting
 每个 open task 都必须在 `plan.yaml` 中包含完整执行合同：
 
 1. `current_task_id` 指向正在执行的 open task。
-2. open task 直接声明 `docs`、`allowed_paths`、`required_gates`、`acceptance_criteria`。
+2. open task 直接声明 `phase: "SPRINTING"`、`docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和 `implementation_doc`。
 3. 任务执行中只保留恢复所需的简短 `working_notes`。
 4. gate、implementation doc、`.docs/INDEX.md` 和 `overview.md` 完成后，在当前 task 仍位于 `plan.yaml` 时创建 task implementation commit。
 5. implementation commit 完成后，再把该 task 从 `plan.yaml` 的 `tasks` 列表移除，并保留/递增 `next_task_sequence`。

package/assets/skills/pjsdlc_manager/SKILL.md

@@ -45,21 +45,23 @@ Parallel Execution 是显式 opt-in：只有用户明确提出“并行”“多
 12. 用户自然语言要求继续、推进或下一步时，等价执行 `/next`。
 13. 用户自然语言要求进入下一阶段或检查是否可进入下一阶段时，等价执行 `/advance`。
 14. 用户自然语言表达需求或设计变化时，进入 RFC workflow。
-15. 用户输入 `/prd`，或自然语言要求“完善产品方案”“写 PRD”“我提供信息，你帮我完善产品方案”时，如果 `current_phase` 是 `REQUIREMENT_GATHERING`，调用产品方案工作流并更新 PRD、验收标准和 open questions；否则说明当前阶段冲突和推荐路径。
-16. 用户输入 `/design`，或自然语言要求“设计技术方案”“做架构方案”“根据 PRD 做技术方案”时，如果 `current_phase` 是 `ARCHITECTING`，调用架构和技术方案工作流并更新 architecture、tech plan 和 `plan.draft.yaml`；否则说明当前阶段冲突和推荐路径。
-17. 用户输入 `/dev`，或自然语言要求“开始开发”“做当前任务”“做下一个任务”“继续开发下一个任务”时，如果 `current_phase` 是 `SPRINTING`，创建或选择一个最小 DEV task 并执行一个 task 闭环；否则说明当前阶段冲突和推荐路径。
+15. 用户输入 `/prd`，或自然语言要求“完善产品方案”“写 PRD”“文档切片”“我提供信息，你帮我完善产品方案”时，如果 `current_phase` 是 `REQUIREMENT_GATHERING`，调用产品方案工作流；该工作流必须先创建或选择一个最小 `TASK-*` open task，并设置 `phase: "REQUIREMENT_GATHERING"`，再执行一个 PRD 生成或切片 task；否则说明当前阶段冲突和推荐路径。
+16. 用户输入 `/design`，或自然语言要求“设计技术方案”“做架构方案”“根据 PRD 做技术方案”“切技术方案”时，如果 `current_phase` 是 `ARCHITECTING`，调用架构和技术方案工作流；该工作流必须先创建或选择一个最小 `TASK-*` open task，并设置 `phase: "ARCHITECTING"`，再执行一个 architecture / tech plan / `plan.draft.yaml` 生成或切片 task；否则说明当前阶段冲突和推荐路径。
+17. 用户输入 `/dev`，或自然语言要求“开始开发”“做当前任务”“做下一个任务”“继续开发下一个任务”时，如果 `current_phase` 是 `SPRINTING`，创建或选择一个最小 `TASK-*` development task 并执行一个 task 闭环；否则说明当前阶段冲突和推荐路径。
 18. 用户输入 `/devloop`，或自然语言要求“开始循环：写任务，执行任务”“把开发循环跑完”“连续开发”时，如果 `current_phase` 是 `SPRINTING`，连续运行 `/dev` 循环，直到没有明确可做任务或遇到 blocker；否则说明当前阶段冲突和推荐路径。
 19. 用户自然语言要求跑测试或验证时，运行当前 task 或当前阶段的对应 gate。
 20. 用户明确要求并行、多 agent 或多 worktree 时，先判断当前阶段是否是 `REQUIREMENT_GATHERING`、`SPRINTING` 或 `TESTING`；如果是，生成或使用 `parallel_execution.trigger: "user_requested"` 合同；否则说明当前阶段不支持并行合同。
 21. `runtime_managed` 模式只在当前 Agent runtime 真实具备 subagent 能力时使用；否则使用 `user_orchestrated` 并输出每个 worker 的可复制 prompt。
-22. 用户自然语言要求 review 时，进入只读 Review workflow，不直接改源码。
+22. 用户自然语言要求 review 时，如果 `current_phase` 是 `REVIEWING`，创建或选择一个最小 `TASK-*` review task，并设置 `phase: "REVIEWING"`；reviewer 只读源码，不直接改源码。
 23. 用户自然语言要求刷新文档总览时，运行 `make docs-overview`。
 24. `/plan` 和 `/goal` 是客户端模式入口，不由 Harness 自动开启；如果用户手动组合 `/plan` 或 `/goal` 与自然语言或宏指令，应按对应 workflow action 继续执行。
 25. 如果动作会改变阶段、创建或删除 task、提交、push 或发布，先用一句话说明即将执行的动作和验证方式，再继续。
 
 ## Plan Protocol
 
-每个 open task 都必须在 `plan.yaml` 中包含 `docs`、`allowed_paths`、`required_gates` 和 `acceptance_criteria`；done/cancelled task 不长期留在当前 `plan.yaml`。完成后的产物事实以模块、子系统或核心数据流级 implementation doc 为准，动作历史以 git/PR/CI/release 系统作为 cold archive，`next_task_sequence` 负责继续分配后续 task id。
+每个 open task 都必须在 `plan.yaml` 中包含 `id`、`phase`、`docs`、`allowed_paths`、`required_gates` 和 `acceptance_criteria`；新 task 统一使用 `TASK-*` id，历史 `DEV-*`、`PRD-*`、`DES-*` task 只作为兼容输入保留。文档和流程产物 task 使用 `result_docs` 指向本 task 产出的 PRD、architecture、tech plan、ADR、review、test、release、RFC 或 `plan.draft.yaml`，开发 task 使用 `implementation_doc` 指向模块级实现事实。done/cancelled task 不长期留在当前 `plan.yaml`。完成后的产物事实以对应 `.docs/**` slice、`plan.draft.yaml` 或模块级 implementation doc 为准，动作历史以 git/PR/CI/release 系统作为 cold archive，`next_task_sequence` 负责继续分配后续 task id。
+
+`/prd`、`/design`、`/dev`、`/review`、`/test`、`/release` 和 `/rfc` 都是单 task 推进：默认只完成一个 `TASK-*`。`validate-plan` 用于检查当前 open task 合同是否完整；阶段出口 gate `validate-pm`、`validate-design`、`validate-dev`、`validate-review`、`validate-test`、`validate-release` 和 `validate-rfc` 都要求没有 open task 残留。
 
 `parallel_execution` 是可选顶层合同，缺省表示串行。启用后必须声明 `enabled`、`trigger`、`mode`、`phase`、`coordinator`、`workers` 和 `integration`；`SPRINTING` 并行还必须通过 `linked_task_id` 绑定当前 `current_task_id`。
 

package/assets/skills/pjsdlc_pm_prd/SKILL.md

@@ -17,10 +17,13 @@ description: Use during REQUIREMENT_GATHERING to turn raw input into PRD slices
 
 产出 PRD 时，优先让后续架构和测试能直接使用：每条需求应有清晰 requirement ID、验收条件、Out of Scope、风险或依赖。对话中出现新范围时，要判断是更新当前 slice、拆出新 slice，还是进入 RFC。
 
+PRD 产出本身是 workflow task，而不是一次性长文档生成。无论来源是对话式需求澄清、既有完整文档切片，还是根据 `.docs/00_raw/` 等事实源合成产品方案，都要先在 `<harnessRoot>/state/plan.yaml` 创建或选择一个足够小的 `TASK-*` open task，并设置 `phase: "REQUIREMENT_GATHERING"`，只完成当前 `current_task_id` 对应的一片产物。不要在一个任务里连续创建大量 PRD 文件；如果需要多个 slices，先把后续 slices 拆成 pending tasks，当前轮只执行一个 task，方便网络中断后按 `plan.yaml` 恢复。
+
 如果用户在需求阶段明确要求并行、多 agent 或多 worktree，Parallel Execution 只能用于调研、草稿、场景拆解、风险列表或 open questions 收集。worker 不直接写最终 PRD；主 Agent 必须合成最终 `.docs/01_product/**`，并把假设、分歧和未决项写入 PRD。没有用户显式要求时，不要启用 `parallel_execution`。
 
 ## 输入
 
+- `<harnessRoot>/state/plan.yaml`
 - 用户需求或原始记录
 - `.docs/00_raw/`
 - 现有 `.docs/01_product/`
@@ -31,6 +34,7 @@ description: Use during REQUIREMENT_GATHERING to turn raw input into PRD slices
 
 - `.docs/00_raw/` 下的原始需求记录
 - `.docs/01_product/` 下的一个或多个 PRD slice
+- 更新后的 `<harnessRoot>/state/plan.yaml`
 - 更新后的 `.docs/INDEX.md`
 
 ## 语义切片
@@ -39,16 +43,31 @@ description: Use during REQUIREMENT_GATHERING to turn raw input into PRD slices
 - `.docs/01_product/` 按业务能力、用户场景、验收边界切片。
 - 如果新增内容仍属于同一业务能力，只更新原 PRD slice。
 - 如果新增内容形成独立用户场景、独立验收标准或独立 Out of Scope，应创建新的 PRD slice。
+- 如果用户明确要求把既有完整 PRD/产品方案文件切成多个 `.docs/01_product/` slices，先确认 replacement slices 覆盖原文件中仍有效的全部需求事实；切片完成并更新 `.docs/INDEX.md`、刷新 `overview.md` 后，删除被替代的完整文件，避免同一事实由完整文件和 slices 双重保留。不要因此删除 `.docs/00_raw/` 原始记录，除非用户明确要求。
 - 每次新增、拆分、合并或废弃 slice 后，都要更新 `.docs/INDEX.md`。
 
+## Plan Protocol
+
+需求阶段的 PRD 生成、既有文档切片和事实源合成都受 `plan.yaml` 管控：
+
+1. 没有 open task 时，先创建一个最小 `TASK-*` task，设置 `phase: "REQUIREMENT_GATHERING"` 和 `current_task_id`。
+2. open task 必须包含 `phase`、`docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和 `result_docs`；`result_docs` 指向本 task 计划产出的 `.docs/00_raw/` 或 `.docs/01_product/` 文件。
+3. 单个 task 的目标应足够小：一段原始需求归档、一个用户场景 PRD slice、一个验收边界、一个 open questions 集合，或从完整文档中切出的一个语义 slice。
+4. 如果用户要求切成多个 slices，先生成多个 pending `TASK-*` tasks 或至少创建当前 task 并在 `working_notes` 写明剩余 slices；当前轮只执行一个 task。
+5. 执行当前 task 时只编辑 `allowed_paths` 中的文件，完成后更新 `.docs/INDEX.md`、运行 `make docs-overview`，并至少运行 `make validate-plan`；阶段出口前再运行 `make validate-pm`。
+6. task 完成后，从 `plan.yaml.tasks` 移除该 task；如果仍有 pending `TASK-*` PRD task，下一轮 `/prd` 或 `/next` 再继续。
+7. 如果网络或上下文中断，新会话先读取 `current_task_id` 和当前 open task，按 `working_notes` 恢复，而不是重新生成全量 PRD。
+
 ## 规则
 
 1. 有价值的用户原始表述应保存在 `.docs/00_raw/`。
 2. 每个 PRD 必须包含目标、用户场景、功能需求、验收标准、Out of Scope 和 Open Questions。
 3. 不确定内容必须写入 `Open Questions`，不要静默假设。
 4. 如果需求与既有架构或已接受决策冲突，先写冲突说明，不要直接编写技术方案。
-5. 需求阶段并行必须使用 `parallel_execution.trigger: "user_requested"`；`runtime_managed` 只在当前 runtime 支持 subagent 时使用，否则输出 `user_orchestrated` worker prompt。
-6. 本 Skill 不直接进入开发；PRD 完成后请求 `manager` 运行阶段出口 gate。
+5. 需求阶段一次只执行一个 `TASK-*` task；不要在单次回复里创建或改写大量 PRD slices。
+6. `make validate-pm` 是阶段出口 gate；如果还有 open `TASK-*` PRD task，不要请求进入 `ARCHITECTING`。
+7. 需求阶段并行必须使用 `parallel_execution.trigger: "user_requested"`；`runtime_managed` 只在当前 runtime 支持 subagent 时使用，否则输出 `user_orchestrated` worker prompt。
+8. 本 Skill 不直接进入开发；PRD 完成后请求 `manager` 运行阶段出口 gate。
 
 ## 完成检查
 
@@ -56,7 +75,10 @@ description: Use during REQUIREMENT_GATHERING to turn raw input into PRD slices
 - [ ] Acceptance Criteria 可测试。
 - [ ] Out of Scope 明确。
 - [ ] Open Questions 有 owner/status。
+- [ ] 当前 PRD 产出或切片工作已绑定 `plan.yaml` 中一个最小 `TASK-*` task，并设置 `phase: "REQUIREMENT_GATHERING"`。
+- [ ] 当前 task 已从 `plan.yaml` 移除，或因中断/blocker 保留为可恢复 open task。
 - [ ] 已判断是否需要新增、拆分、合并或废弃 PRD slice。
+- [ ] 如果用户要求把完整 PRD/产品方案切成 slices，已删除被替代的完整文件，并保留必要的 `.docs/00_raw/` 原始记录。
 - [ ] 如果用户要求并行，worker output 已由主 Agent 合成，最终 PRD 不由 worker 直接写入。
 - [ ] `.docs/INDEX.md` 已链接新增产物。
 - [ ] 已运行 `make docs-overview` 刷新 `.docs/<stage>/overview.md`。

package/assets/skills/pjsdlc_release_manager/SKILL.md

@@ -17,8 +17,11 @@ description: Use during RELEASING to prepare release notes, smoke evidence, depl
 
 Release note 面向人类读者，必须说明变更价值、影响范围和注意事项；rollback plan 面向执行者，必须具体到触发条件、操作入口、验证方式和负责人。
 
+发布准备本身也是 workflow task。开始 release 工作前，先在 `<harnessRoot>/state/plan.yaml` 创建或选择一个足够小的 `TASK-*` open task，并设置 `phase: "RELEASING"`；当前轮只产出一个 release slice、一次 smoke evidence 补充、一个部署检查或一个 rollback plan 单元。发布动作本身仍需用户明确授权。
+
 ## 输入
 
+- `<harnessRoot>/state/plan.yaml`
 - `.docs/07_test/`
 - build artifacts
 - changelog 或 task list
@@ -27,6 +30,7 @@ Release note 面向人类读者，必须说明变更价值、影响范围和注
 ## 输出
 
 - `.docs/08_release/` 下的 release note
+- 更新后的 `<harnessRoot>/state/plan.yaml`
 - smoke test result
 - deployment checklist
 - rollback plan
@@ -40,6 +44,17 @@ Release note 面向人类读者，必须说明变更价值、影响范围和注
 - 如果只是补充同一版本的 smoke evidence 或 rollback step，应更新原 release slice。
 - 发布 slice 完成后更新 `.docs/INDEX.md`；不再维护 Harness archive。
 
+## Plan Protocol
+
+发布阶段受 `plan.yaml` 管控：
+
+1. 没有 open task 时，先创建一个最小 `TASK-*` task，设置 `phase: "RELEASING"` 和 `current_task_id`。
+2. open task 必须包含 `phase`、`docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和 `result_docs`；`result_docs` 指向本 task 计划产出的 `.docs/08_release/**` 文件。
+3. 单个 task 的目标应足够小：一个版本 release note、一个 smoke evidence 补充、一个 deployment checklist 或一个 rollback plan。
+4. 执行当前 task 时只编辑 `allowed_paths` 中的 release 产物、`.docs/INDEX.md`、overview 和 `plan.yaml`。
+5. 完成后运行 `make validate-plan` 和 task required gates；阶段出口前运行 `make validate-release`。
+6. task 完成后从 `plan.yaml.tasks` 移除；如果还有 pending release task，下一轮 `/release` 或 `/next` 再继续。
+
 ## 规则
 
 1. 除非用户明确要求，不自动部署。
@@ -47,10 +62,13 @@ Release note 面向人类读者，必须说明变更价值、影响范围和注
 3. Rollback plan 必须可执行。
 4. Smoke test evidence 必须链接或摘要记录。
 5. Human confirmation items 必须明确。
+6. 发布阶段一次只执行一个 `TASK-*` task。
 
 ## 完成检查
 
 - [ ] Release note 已生成。
+- [ ] 当前发布工作已绑定 `plan.yaml` 中一个最小 `TASK-*` task，并设置 `phase: "RELEASING"`。
+- [ ] 当前 task 已从 `plan.yaml` 移除，或因中断/blocker 保留为可恢复 open task。
 - [ ] Build artifacts 已记录。
 - [ ] Smoke test result 已记录。
 - [ ] 已判断 release slice 的版本或发布批次边界。

package/assets/skills/pjsdlc_reviewer/SKILL.md

@@ -17,8 +17,11 @@ Review 时先建立证据链：PRD 说什么、技术方案承诺什么、implem
 
 不要把个人偏好包装成 blocker。区分 blocking issue、follow-up improvement 和 open question。如果没有发现问题，要明确说明，同时列出剩余测试缺口或残余风险。
 
+Review 产出本身也是 workflow task。开始 review 前，先在 `<harnessRoot>/state/plan.yaml` 创建或选择一个足够小的 `TASK-*` open task，并设置 `phase: "REVIEWING"`；当前轮只产出一个 review batch、一个风险主题 slice 或一次 PR review 结论。不要在一个任务里覆盖多个互不相关的 review 主题。
+
 ## 输入
 
+- `<harnessRoot>/state/plan.yaml`
 - `.docs/01_product/`
 - `.docs/03_tech_plan/`
 - `.docs/04_implementation/`
@@ -29,6 +32,7 @@ Review 时先建立证据链：PRD 说什么、技术方案承诺什么、implem
 ## 输出
 
 - `.docs/06_review/REVIEW_REPORT.md`
+- 更新后的 `<harnessRoot>/state/plan.yaml`
 - 风险清单
 - 重构建议
 - 是否允许进入 `TESTING` 的结论
@@ -41,6 +45,17 @@ Review 时先建立证据链：PRD 说什么、技术方案承诺什么、implem
 - Review 不重切上游 PRD / tech plan；如果发现上游边界错误，记录 blocker 或建议 RFC。
 - 每次新增或拆分 review slice 后，都要更新 `.docs/INDEX.md`。
 
+## Plan Protocol
+
+Review 阶段受 `plan.yaml` 管控：
+
+1. 没有 open task 时，先创建一个最小 `TASK-*` task，设置 `phase: "REVIEWING"` 和 `current_task_id`。
+2. open task 必须包含 `phase`、`docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和 `result_docs`；`result_docs` 指向本 task 计划产出的 `.docs/06_review/**` 文件。
+3. 单个 task 的目标应足够小：一次 review batch、一个 PR、一个模块或一个风险主题。
+4. 执行当前 task 时只写 review 产物、`.docs/INDEX.md`、`overview.md` 和 `plan.yaml`，不修改源码。
+5. 完成后运行 `make validate-plan` 和 `make docs-overview`；阶段出口前运行 `make validate-review`。
+6. task 完成后从 `plan.yaml.tasks` 移除；如果还有 pending review task，下一轮 `/review` 或 `/next` 再继续。
+
 ## 规则
 
 1. 本 Skill 不修改源码。
@@ -48,10 +63,13 @@ Review 时先建立证据链：PRD 说什么、技术方案承诺什么、implem
 3. 每条 finding 尽量引用文件、需求、任务或文档路径。
 4. 区分 blocking issues 和 follow-up improvements。
 5. 如果未发现问题，明确说明，并列出剩余测试缺口或残余风险。
+6. Review 阶段一次只执行一个 `TASK-*` task。
 
 ## 完成检查
 
 - [ ] Review report 已生成。
+- [ ] 当前 review 工作已绑定 `plan.yaml` 中一个最小 `TASK-*` task，并设置 `phase: "REVIEWING"`。
+- [ ] 当前 task 已从 `plan.yaml` 移除，或因中断/blocker 保留为可恢复 open task。
 - [ ] 已评估需求一致性。
 - [ ] 已评估架构和可维护性风险。
 - [ ] 已判断 review slice 的范围和风险主题边界。

package/assets/skills/pjsdlc_rfc_recalibrate/SKILL.md

@@ -19,6 +19,8 @@ description: Use during RFC_RECALIBRATION to process requirement changes with im
 
 影响面分析必须先于补丁。至少检查 docs/state/skills/policies/templates/tools/package assets/tests/migrations/generated artifacts 是否受影响；如果某一类不受影响，也要显式说明不受影响或不需要修改。对于 Harness package 相关变更，还要检查 `sync`、`upgrade`、source mappings、package assets 和用户项目迁移行为。
 
+RFC recalibration 本身也是 workflow task。开始处理变更前，先在 `<harnessRoot>/state/plan.yaml` 创建或选择一个足够小的 `TASK-*` open task，并设置 `phase: "RFC_RECALIBRATION"`；当前轮只处理一个 RFC 文件、一个 impact analysis 单元或一个局部补丁单元。
+
 ## 输入
 
 - `.docs/rfc/RFC_*.md`
@@ -33,6 +35,7 @@ description: Use during RFC_RECALIBRATION to process requirement changes with im
 - 局部更新后的 PRD 和技术方案
 - 被标记为 `pending_revision` 的受影响任务，或新增增量任务
 - Regression requirements
+- 更新后的 `<harnessRoot>/state/plan.yaml`
 - 更新后的 `.docs/INDEX.md`
 
 ## 语义切片
@@ -43,6 +46,17 @@ description: Use during RFC_RECALIBRATION to process requirement changes with im
 - 对受影响产物做局部补丁，不重写无关稳定 slice。
 - 每次 RFC 影响了文档边界，都要更新 `.docs/INDEX.md` 并记录受影响任务状态。
 
+## Plan Protocol
+
+RFC 阶段受 `plan.yaml` 管控：
+
+1. 没有 open task 时，先创建一个最小 `TASK-*` task，设置 `phase: "RFC_RECALIBRATION"` 和 `current_task_id`。
+2. open task 必须包含 `phase`、`docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和 `result_docs`；`result_docs` 指向本 task 计划产出的 RFC、受影响 PRD/tech plan/test docs 或 plan update。
+3. 单个 task 的目标应足够小：一份 RFC 的 impact analysis、一个受影响 slice 的局部补丁、一组任务状态调整，或一个回归要求更新。
+4. 执行当前 task 时只编辑 `allowed_paths` 中的 RFC、受影响 facts、`.docs/INDEX.md`、overview 和 `plan.yaml`。
+5. 完成后运行 `make validate-plan` 和 task required gates；阶段出口前运行 `make validate-rfc`。
+6. task 完成后从 `plan.yaml.tasks` 移除；如果还有 pending RFC task，下一轮 `/rfc` 或 `/next` 再继续。
+
 ## 规则
 
 1. 影响已接受产物的需求变化，必须先进入本 Skill。
@@ -51,10 +65,13 @@ description: Use during RFC_RECALIBRATION to process requirement changes with im
 4. 受影响的 `pending` 或 `in_progress` 任务追加 revision notes。
 5. 不重写无关的稳定文档。
 6. 只有 `make validate-rfc` 通过后，才能恢复原阶段或进入 `SPRINTING`。
+7. RFC 阶段一次只执行一个 `TASK-*` task。
 
 ## 完成检查
 
 - [ ] RFC 包含有效 status 和 acceptance criteria。
+- [ ] 当前 RFC 工作已绑定 `plan.yaml` 中一个最小 `TASK-*` task，并设置 `phase: "RFC_RECALIBRATION"`。
+- [ ] 当前 task 已从 `plan.yaml` 移除，或因中断/blocker 保留为可恢复 open task。
 - [ ] Product impact 和 technical impact 已记录。
 - [ ] 已判断 RFC 是否需要拆分，以及是否影响其它阶段 slice。
 - [ ] 已列出 docs/state/skills/policies/templates/tools/package assets/tests/migrations/generated artifacts 的影响面。

package/assets/skills/pjsdlc_tester/SKILL.md

@@ -17,10 +17,13 @@ description: Use during TESTING to produce a test matrix, run regression, and do
 
 执行回归时，优先选择能证明阶段出口的 gate。测试无法运行、环境缺失或数据不可得时，不要宣布通过，应记录 blocker、已完成检查和恢复条件。
 
+测试计划和回归证据产出本身也是 workflow task。开始测试前，先在 `<harnessRoot>/state/plan.yaml` 创建或选择一个足够小的 `TASK-*` open task，并设置 `phase: "TESTING"`；当前轮只产出一个测试矩阵 slice、一个回归批次、一个风险验证片区或一组 scoped test changes。
+
 如果用户明确要求并行、多 agent 或多 worktree，测试阶段可以启用 `parallel_execution`，让 worker 分别执行互不依赖的回归片区、smoke、兼容性或风险验证。worker 只提交证据和必要的 scoped test changes；最终 `.docs/07_test/**`、coverage gaps、PASS/BLOCKED 决策和阶段 gate 由主 Agent 汇总。没有用户显式要求时，测试 workflow 保持串行。
 
 ## 输入
 
+- `<harnessRoot>/state/plan.yaml`
 - `.docs/01_product/`
 - `.docs/03_tech_plan/`
 - `.docs/04_implementation/`
@@ -32,6 +35,7 @@ description: Use during TESTING to produce a test matrix, run regression, and do
 
 - `.docs/07_test/TEST_PLAN.md`
 - 必要时在 `tests/` 下补充测试
+- 更新后的 `<harnessRoot>/state/plan.yaml`
 - 回归测试记录
 - 覆盖缺口清单
 
@@ -43,6 +47,17 @@ description: Use during TESTING to produce a test matrix, run regression, and do
 - 如果新增测试只是覆盖同一验收标准，应更新原 test slice，不要创建重复测试计划。
 - 每次新增、拆分或合并 test slice 后，都要更新 `.docs/INDEX.md`。
 
+## Plan Protocol
+
+测试阶段受 `plan.yaml` 管控：
+
+1. 没有 open task 时，先创建一个最小 `TASK-*` task，设置 `phase: "TESTING"` 和 `current_task_id`。
+2. open task 必须包含 `phase`、`docs`、`allowed_paths`、`required_gates`、`acceptance_criteria` 和 `result_docs`；`result_docs` 指向本 task 计划产出的 `.docs/07_test/**` 文件，必要时也列出 scoped test files。
+3. 单个 task 的目标应足够小：一个测试矩阵 slice、一个回归批次、一个风险验证片区，或一组紧密相关的测试变更。
+4. 执行当前 task 时只编辑 `allowed_paths` 中的测试、测试文档、`.docs/INDEX.md`、overview 和 `plan.yaml`。
+5. 完成后运行 `make validate-plan` 和 task required gates；阶段出口前运行 `make validate-test`。
+6. task 完成后从 `plan.yaml.tasks` 移除；如果还有 pending testing task，下一轮 `/test` 或 `/next` 再继续。
+
 ## 规则
 
 1. 测试用例必须追溯到 PRD acceptance criteria 或 Review findings。
@@ -50,10 +65,13 @@ description: Use during TESTING to produce a test matrix, run regression, and do
 3. 如果有意延后覆盖，必须记录风险和 follow-up。
 4. 并行测试必须使用 `parallel_execution.trigger: "user_requested"`；`runtime_managed` 只在当前 runtime 支持 subagent 时使用，否则输出 `user_orchestrated` worker prompt。
 5. 宣布阶段完成前运行 `make test-all`。
+6. 测试阶段一次只执行一个 `TASK-*` task。
 
 ## 完成检查
 
 - [ ] Test matrix 已把需求映射到测试。
+- [ ] 当前测试工作已绑定 `plan.yaml` 中一个最小 `TASK-*` task，并设置 `phase: "TESTING"`。
+- [ ] 当前 task 已从 `plan.yaml` 移除，或因中断/blocker 保留为可恢复 open task。
 - [ ] Regression checklist 已完成。
 - [ ] 已判断 test plan / test matrix 的语义切片边界。
 - [ ] Coverage gaps 已明确。

package/assets/templates/PLAN_TEMPLATE.yaml

@@ -1,5 +1,5 @@
-current_phase: "SPRINTING"
-current_task_id: "DEV-001"
+current_phase: "REQUIREMENT_GATHERING"
+current_task_id: "TASK-001"
 next_task_sequence: 2
 # Optional. Omit this block for normal serial workflow. Only add it when the
 # user explicitly asks for parallel / multi-agent / multi-worktree execution.
@@ -9,7 +9,7 @@ next_task_sequence: 2
 #   mode: "user_orchestrated" # or "runtime_managed" when the current agent runtime can spawn subagents
 #   phase: "SPRINTING"
 #   coordinator: "main_agent"
-#   linked_task_id: "DEV-001"
+#   linked_task_id: "TASK-001"
 #   workers:
 #     - id: "worker-feature"
 #       writes_repo: true
@@ -33,24 +33,28 @@ next_task_sequence: 2
 #     fact_source_updates:
 #       - ".docs/04_implementation/"
 tasks:
-  - id: "DEV-001"
-    title: "实现示例任务"
+  - id: "TASK-001"
+    phase: "REQUIREMENT_GATHERING"
+    title: "生成示例 PRD slice"
     status: "pending"
     summary: "一句话描述任务目标和交付边界。"
     docs:
+      raw:
+        - ".docs/00_raw/example.md"
       product:
         - ".docs/01_product/example.md"
-      tech_plan:
-        - ".docs/03_tech_plan/example.md"
       rfc: []
     allowed_paths:
-      - "src/**"
-      - "tests/**"
+      - ".docs/00_raw/**"
+      - ".docs/01_product/**"
+      - ".docs/INDEX.md"
+      - "<harnessRoot>/state/plan.yaml"
     required_gates:
-      - "make lint"
-      - "make test-current-domain"
+      - "make validate-plan"
+      - "make docs-overview"
     acceptance_criteria:
       - "验收标准写在 open task 内，完成后从当前 plan 删除。"
     working_notes:
       - "执行现场备注只在 open task 保留。"
-    implementation_doc: ".docs/04_implementation/example/module_or_flow.md"
+    result_docs:
+      - ".docs/01_product/example.md"

package/assets/templates/TECH_DESIGN_TEMPLATE.md

@@ -41,7 +41,7 @@ Input
 
 | Task ID | 标题（Title） | Allowed Paths | Required Gates | Implementation Doc |
 |---|---|---|---|---|
-| DEV-001 |  | `src/**`, `tests/**` | `make lint`, `make test-current-domain` | `.docs/04_implementation/...` |
+| TASK-001 |  | `src/**`, `tests/**` | `make lint`, `make test-current-domain` | `.docs/04_implementation/...` |
 
 `Implementation Doc` 应指向模块、子系统或核心数据流级文档；多个 task 可以更新同一份文档，task id 和 commit 记录在该文档的 provenance / Change Log 中。
 

package/dist/commands/index.js

@@ -13,9 +13,14 @@ export const commands = {
     validate,
     "validate-harness": (args) => validate(["validate-harness", ...args]),
     "validate-current": (args) => validate(["validate-current", ...args]),
+    "validate-plan": (args) => validate(["validate-plan", ...args]),
     "validate-pm": (args) => validate(["validate-pm", ...args]),
     "validate-design": (args) => validate(["validate-design", ...args]),
     "validate-dev": (args) => validate(["validate-dev", ...args]),
+    "validate-review": (args) => validate(["validate-review", ...args]),
+    "validate-test": (args) => validate(["validate-test", ...args]),
+    "validate-release": (args) => validate(["validate-release", ...args]),
+    "validate-rfc": (args) => validate(["validate-rfc", ...args]),
     package: packageSource
 };
 export function help() {
@@ -26,5 +31,6 @@ export function help() {
   upgrade              Run migrations and then sync
   doctor               Diagnose project configuration and drift
   validate <gate>      Run a Harness validation gate
+  validate-*           Run a named gate directly, including validate-plan/review/test/release/rfc
   package <subcommand> Maintain package canonical source`);
 }

package/dist/lib/validators.js

@@ -7,12 +7,18 @@ import { parseYaml } from "./yaml.js";
 const execFileAsync = promisify(execFile);
 const PARALLEL_MODES = new Set(["runtime_managed", "user_orchestrated"]);
 const PARALLEL_PHASES = new Set(["REQUIREMENT_GATHERING", "SPRINTING", "TESTING"]);
+const TASK_PHASES = new Set(["REQUIREMENT_GATHERING", "ARCHITECTING", "SPRINTING", "REVIEWING", "TESTING", "RELEASING", "RFC_RECALIBRATION"]);
 const validators = {
     "validate-harness": validateHarness,
     "validate-current": validateCurrent,
+    "validate-plan": validatePlan,
     "validate-pm": validatePm,
     "validate-design": validateDesign,
-    "validate-dev": validateDev
+    "validate-dev": validateDev,
+    "validate-review": validateReview,
+    "validate-test": validateTest,
+    "validate-release": validateRelease,
+    "validate-rfc": validateRfc
 };
 export async function runValidator(projectRoot, gate) {
     const normalized = normalizeGate(gate);
@@ -51,14 +57,19 @@ async function validateCurrent(projectRoot) {
     const gateByPhase = {
         REQUIREMENT_GATHERING: "validate-pm",
         ARCHITECTING: "validate-design",
-        SPRINTING: "validate-dev"
+        SPRINTING: "validate-dev",
+        REVIEWING: "validate-review",
+        TESTING: "validate-test",
+        RELEASING: "validate-release",
+        RFC_RECALIBRATION: "validate-rfc"
     };
     return runValidator(projectRoot, gateByPhase[current] ?? "validate-harness");
 }
 async function validatePm(projectRoot) {
+    const plan = await validatePlanState(projectRoot, false);
     const docs = await markdownFiles(path.join(projectRoot, ".docs/01_product"));
     const text = await combinedText(docs);
-    const errors = [];
+    const errors = [...plan.errors];
     if (docs.length === 0)
         errors.push("No PRD deliverables found");
     if (!containsAny(text, ["acceptance", "验收"]))
@@ -70,10 +81,11 @@ async function validatePm(projectRoot) {
     return { info: [`validate-pm checked ${docs.length} file(s)`], errors };
 }
 async function validateDesign(projectRoot) {
+    const plan = await validatePlanState(projectRoot, false);
     const architecture = await markdownFiles(path.join(projectRoot, ".docs/02_architecture"));
     const techPlan = await markdownFiles(path.join(projectRoot, ".docs/03_tech_plan"));
     const text = await combinedText([...architecture, ...techPlan]);
-    const errors = [];
+    const errors = [...plan.errors];
     if (architecture.length === 0)
         errors.push("No architecture deliverables found");
     if (techPlan.length === 0)
@@ -86,7 +98,80 @@ async function validateDesign(projectRoot) {
         errors.push("Design must include task breakdown");
     return { info: [`validate-design checked ${architecture.length + techPlan.length} file(s)`], errors };
 }
+async function validatePlan(projectRoot) {
+    const plan = await validatePlanState(projectRoot, true);
+    const pathErrors = await validateChangedPaths(projectRoot, plan.plan, true);
+    return { info: [`validate-plan checked ${plan.taskCount} task(s)`], errors: [...plan.errors, ...pathErrors] };
+}
 async function validateDev(projectRoot) {
+    const plan = await validatePlanState(projectRoot, false);
+    return { info: [`validate-dev checked ${plan.taskCount} task(s)`], errors: plan.errors };
+}
+async function validateReview(projectRoot) {
+    const plan = await validatePlanState(projectRoot, false);
+    const text = (await readText(path.join(projectRoot, ".docs/06_review/REVIEW_REPORT.md"))).toLowerCase();
+    const errors = [...plan.errors];
+    if (!containsAny(text, ["finding", "发现", "风险"]))
+        errors.push("Review report must include findings or risks");
+    if (!containsAny(text, ["test gap", "测试缺口", "coverage"]))
+        errors.push("Review report must include test gaps or coverage notes");
+    if (!containsAny(text, ["pass", "blocked", "通过", "阻塞"]))
+        errors.push("Review report must include PASS/BLOCKED decision");
+    return { info: ["validate-review checked review report"], errors };
+}
+async function validateTest(projectRoot) {
+    const plan = await validatePlanState(projectRoot, false);
+    const text = (await readText(path.join(projectRoot, ".docs/07_test/TEST_PLAN.md"))).toLowerCase();
+    const errors = [...plan.errors];
+    if (!containsAny(text, ["matrix", "矩阵"]))
+        errors.push("Test plan must include a test matrix");
+    if (!containsAny(text, ["regression", "回归"]))
+        errors.push("Test plan must include regression coverage");
+    if (!containsAny(text, ["coverage gap", "覆盖缺口", "gap"]))
+        errors.push("Test plan must include coverage gaps");
+    if (!containsAny(text, ["pass", "blocked", "通过", "阻塞"]))
+        errors.push("Test plan must include PASS/BLOCKED decision");
+    return { info: ["validate-test checked test plan"], errors };
+}
+async function validateRelease(projectRoot) {
+    const plan = await validatePlanState(projectRoot, false);
+    const docs = await markdownFiles(path.join(projectRoot, ".docs/08_release"));
+    const text = await combinedText(docs);
+    const errors = [...plan.errors];
+    if (docs.length === 0)
+        errors.push("No release deliverables found");
+    if (!containsAny(text, ["release", "发布"]))
+        errors.push("Release docs must include release notes");
+    if (!containsAny(text, ["smoke", "冒烟"]))
+        errors.push("Release docs must include smoke test evidence");
+    if (!containsAny(text, ["rollback", "回滚"]))
+        errors.push("Release docs must include rollback plan");
+    return { info: [`validate-release checked ${docs.length} file(s)`], errors };
+}
+async function validateRfc(projectRoot) {
+    const plan = await validatePlanState(projectRoot, false);
+    const docs = await markdownFiles(path.join(projectRoot, ".docs/rfc"));
+    const text = await combinedText(docs);
+    const errors = [...plan.errors];
+    if (docs.length === 0)
+        errors.push("No RFC documents found");
+    if (!containsAny(text, ["background", "背景"]))
+        errors.push("RFC must include background");
+    if (!containsAny(text, ["product impact", "产品影响"]))
+        errors.push("RFC must include product impact");
+    if (!containsAny(text, ["technical impact", "技术影响"]))
+        errors.push("RFC must include technical impact candidates");
+    if (!containsAny(text, ["regression", "回归"]))
+        errors.push("RFC must include regression requirements");
+    const statuses = [...text.matchAll(/status:\s*([a-z_]+)/g)].map((match) => match[1].toUpperCase());
+    if (statuses.length === 0)
+        errors.push("RFC must include a Status line");
+    const invalidStatuses = statuses.filter((status) => !["DRAFT", "APPLIED", "VERIFIED", "ARCHIVED"].includes(status));
+    if (invalidStatuses.length > 0)
+        errors.push(`Invalid RFC status: ${invalidStatuses.join(", ")}`);
+    return { info: [`validate-rfc checked ${docs.length} file(s)`], errors };
+}
+async function validatePlanState(projectRoot, allowOpen) {
     const errors = [];
     const root = await harnessRoot(projectRoot);
     const tasksData = await readYamlObject(path.join(projectRoot, root, "state", "plan.yaml"));
@@ -97,16 +182,37 @@ async function validateDev(projectRoot) {
         errors.push("plan.yaml must define positive integer next_task_sequence");
     }
     const open = tasks.filter((task) => ["pending", "in_progress", "blocked", "pending_revision"].includes(String(task.status)));
-    if (open.length > 0)
+    if (!allowOpen && open.length > 0)
         errors.push(`Open tasks remain: ${open.map((task) => task.id).join(", ")}`);
     let maxTaskSequence = 0;
-    for (const task of tasks) {
-        for (const field of ["id", "title", "status", "summary", "implementation_doc"]) {
+    tasks.forEach((task, index) => {
+        if (!isRecord(task)) {
+            errors.push(`Task #${index + 1} must be a mapping`);
+            return;
+        }
+        for (const field of ["id", "title", "status", "summary"]) {
             if (!task[field])
                 errors.push(`Task missing ${field}: ${String(task.id ?? "unknown")}`);
         }
         const taskId = String(task.id ?? "");
-        const match = taskId.match(/^DEV-(\d+)$/);
+        if (!/^[A-Z]+-\d+$/.test(taskId)) {
+            errors.push(`${taskId || `Task #${index + 1}`} id must match PREFIX-###`);
+        }
+        if (taskId.startsWith("TASK-") && !TASK_PHASES.has(String(task.phase ?? ""))) {
+            errors.push(`${taskId} must define valid phase`);
+        }
+        else if (task.phase !== undefined && !TASK_PHASES.has(String(task.phase))) {
+            errors.push(`${taskId} has invalid phase: ${String(task.phase)}`);
+        }
+        if (!["pending", "in_progress", "done", "blocked", "pending_revision", "cancelled"].includes(String(task.status))) {
+            errors.push(`${String(task.id ?? `Task #${index + 1}`)} has invalid status: ${String(task.status)}`);
+        }
+        const hasImplementationDoc = typeof task.implementation_doc === "string" && task.implementation_doc.trim().length > 0;
+        const hasResultDocs = Array.isArray(task.result_docs) && task.result_docs.length > 0;
+        if (!hasImplementationDoc && !hasResultDocs) {
+            errors.push(`${String(task.id ?? `Task #${index + 1}`)} must define implementation_doc or result_docs`);
+        }
+        const match = taskId.match(/^[A-Z]+-(\d+)$/);
         if (match) {
             maxTaskSequence = Math.max(maxTaskSequence, Number(match[1]));
         }
@@ -118,25 +224,35 @@ async function validateDev(projectRoot) {
                 if (!task[field])
                     errors.push(`Open task ${task.id} missing ${field}`);
             }
+            if (!isRecord(task.docs)) {
+                errors.push(`${task.id} docs must be a mapping`);
+            }
             if (!Array.isArray(task.allowed_paths) || task.allowed_paths.length === 0) {
                 errors.push(`Open task ${task.id} must define allowed_paths`);
             }
             if (!Array.isArray(task.required_gates) || task.required_gates.length === 0) {
                 errors.push(`Open task ${task.id} must define required_gates`);
             }
+            if (!Array.isArray(task.acceptance_criteria) || task.acceptance_criteria.length === 0) {
+                errors.push(`Open task ${task.id} must define acceptance_criteria`);
+            }
         }
         else {
             errors.push(`Completed task ${task.id} must not remain in plan.yaml`);
-            for (const field of ["docs", "allowed_paths", "required_gates", "acceptance_criteria", "working_notes", "gate_result"]) {
-                if (task[field])
+            for (const field of ["docs", "allowed_paths", "required_gates", "acceptance_criteria", "working_notes", "gate_result", "result_docs"]) {
+                if (field in task)
                     errors.push(`Closed task ${task.id} must not retain ${field}`);
             }
         }
-    }
+    });
     if (Number.isInteger(nextTaskSequence) && Number(nextTaskSequence) <= maxTaskSequence) {
         errors.push("next_task_sequence must be greater than task ids currently in plan.yaml");
     }
-    return { info: [`validate-dev checked ${tasks.length} task(s)`], errors };
+    const currentTaskId = String(tasksData.current_task_id ?? "");
+    if (currentTaskId && !tasks.some((task) => isRecord(task) && task.id === currentTaskId)) {
+        errors.push(`current_task_id does not match a task: ${currentTaskId}`);
+    }
+    return { taskCount: tasks.length, errors, plan: tasksData };
 }
 function validateParallelExecutionContract(plan, errors) {
     const contract = plan.parallel_execution;
@@ -227,6 +343,36 @@ function validateParallelExecutionContract(plan, errors) {
         errors.push("parallel_execution.integration.fact_source_updates must be a non-empty list");
     }
 }
+async function validateChangedPaths(projectRoot, plan, allowOpen) {
+    if (!allowOpen)
+        return [];
+    const currentTaskId = String(plan.current_task_id ?? "");
+    if (!currentTaskId)
+        return [];
+    const tasks = Array.isArray(plan.tasks) ? plan.tasks : [];
+    const task = tasks.find((candidate) => isRecord(candidate) && candidate.id === currentTaskId);
+    if (!isRecord(task))
+        return [`current_task_id does not match a task: ${currentTaskId}`];
+    if (!Array.isArray(task.allowed_paths))
+        return [`${currentTaskId} must define allowed_paths`];
+    const patterns = task.allowed_paths.map((pattern) => String(pattern).replace("<harnessRoot>", ".codex"));
+    const changed = await changedFiles(projectRoot);
+    const blocked = changed.filter((file) => !matchesAny(file, patterns));
+    return blocked.length > 0 ? [`Changed files outside current task allowed_paths: ${blocked.join(", ")}`] : [];
+}
+function matchesAny(file, patterns) {
+    return patterns.some((pattern) => matchesGlob(file, pattern));
+}
+function matchesGlob(file, pattern) {
+    const normalizedFile = file.replace(/\\/g, "/");
+    const normalizedPattern = pattern.replace(/\\/g, "/");
+    if (normalizedFile === normalizedPattern)
+        return true;
+    if (normalizedPattern.endsWith("/**") && normalizedFile.startsWith(normalizedPattern.slice(0, -3)))
+        return true;
+    const escaped = normalizedPattern.replace(/[.+^${}()|[\]\\]/g, "\\$&").replace(/\*\*/g, ".*").replace(/\*/g, "[^/]*");
+    return new RegExp(`^${escaped}$`).test(normalizedFile);
+}
 function isRecord(value) {
     return typeof value === "object" && value !== null && !Array.isArray(value);
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "agent-project-sdlc",
-  "version": "0.1.9",
+  "version": "0.1.10",
   "description": "CLI and canonical assets for the AI SDLC Harness workflow.",
   "type": "module",
   "bin": {