@guanlin4924/devflow-pi 0.1.0

package/plugins/devflow-implementation/skills/workflow-change-plan/SKILL.md

@@ -0,0 +1,160 @@
+---
+name: workflow-change-plan
+description: "Use after workflow-integration-verify has passed or produced an approved no-op report. Generates an AI-executable change list with DDL, code tasks, and rollout steps from the reconciled backend/frontend/API design. This is NOT an API call guide — see workflow-api-call-guide for that."
+---
+
+# 变更清单生成器
+
+基于后端/前端技术方案，生成 AI 可直接执行的原子化变更清单，供 execute 阶段使用。
+
+## 与其他 skill 的关系
+
+| Skill | 产出 | 何时用 |
+|-------|------|--------|
+| `workflow-api-call-guide` | `api-call-guide.md` | Track A，API 调用指南给前端开发者 |
+| `workflow-api-supplement` | `api-supplement-requests.md` | Track B 异常路径，前端发现 API 缺口 |
+| `workflow-integration-verify` | `integration-report.md` | 双轨合流门禁，确认后端/API/前端设计一致 |
+| **`workflow-change-plan`** | **`变更清单.md`** | **集成核对通过后**，execute 阶段的原子化任务清单 |
+
+三者互补，不可互相替代。
+- 有 API 变更 → 先跑 `api-contract`、`api-call-guide`、前端方案和必要的 `api-supplement`，再跑 `integration-verify`，最后跑 `change-plan`
+- 无 API 变更 → 仍生成 no-op `api-contract`、no-op `api-call-guide` 和 no-op `integration-report`，由 `integration-verify` 标记 `merge_gate_status: skipped` 后再跑 `change-plan`
+- `api-supplement` 只在 Track B 发现 API 缺口时触发；存在补充项时必须回写 API 契约并通过 `integration-verify`
+- `change-plan` 不作为 Track A 或 Track B 的局部产物，不能绕过双轨合流门禁
+
+## 核心原则
+
+1. **任务原子化** — 每个任务足够小，AI 可在单次对话中完成
+2. **依赖明确** — 标注任务间的依赖关系和执行顺序
+3. **上下文完整** — 每个任务包含足够上下文，无需回看其他文档
+4. **可验证** — 每个任务有明确的完成标准
+5. **复用优先** — 先扫描项目已有实现，复用现有模式和工具库
+6. **可验证完成标准** — 所有完成标准使用 `- [ ]` checkbox 格式，描述可通过静态代码分析验证的具体条件。执行阶段的 `code_review` 门禁将自动逐条验证。模糊描述（如"功能正确"）会被标记为 `⚠️ UNVERIFIABLE` 并阻塞自动化验证流程
+
+## 输入
+
+按优先级查找（第一个存在即使用）：
+
+| 优先级 | 输入 | 轨道 |
+|--------|------|------|
+| 1 | `.planning/features/{feature}/integration-report.md` | 合流门禁结果，必须存在 |
+| 2 | `.planning/features/{feature}/api-contract.md` | API 契约，包含 no-op 场景 |
+| 3 | `.planning/features/{feature}/api-call-guide.md` | 前端消费指南，包含 no-op 场景 |
+| 4 | `.planning/features/{feature}/后端技术方案.md` | Track A |
+| 5 | `.planning/features/{feature}/前端技术方案.md` | Track B |
+| 6 | `.planning/features/{feature}/功能点梳理.md` | Track B |
+| 7 | `.planning/requirements/baseline.md` | fallback |
+
+**无 API 变更时**：不得直接跳过合流。必须存在 no-op `api-contract.md`、no-op `api-call-guide.md` 和 no-op `integration-report.md`；变更清单聚焦于代码文件改动，DDL/API 章节标注"无"。
+
+## 工作流程
+
+### 第一阶段：收集输入
+
+1. 读取 `integration-report.md` 和对应 meta → 确认 `merge_gate_status` 为 `passed` 或 `skipped`，且阻塞项为 0
+2. 读取 `api-contract.md`、`api-call-guide.md` → 提取 API 任务、mock/联调要求和 no-op 判断
+3. 读取后端技术方案 → 提取改动文件、库表变更、DDL、配置变更
+4. 读取前端技术方案（如存在）→ 提取前端改动文件、路由、组件
+5. 读取功能点梳理（如存在）→ 确认 FP 覆盖完整性
+6. 读取 baseline.md 的审查结论和风险标记
+7. 若输入包含 `SL-*` 切片计划，读取 `skill://workflow-pipeline/references/slice-safety-guide.md`，只生成当前执行切片的任务。后置切片只能写入风险/后续范围，不得生成实现任务。
+
+### 第二阶段：扫描项目上下文
+
+1. 验证技术方案中列出的文件路径存在
+2. 读取关键源文件的当前内容（确认改动基线）
+3. 识别可复用的现有模式和工具库
+4. 检查 `.planning/execution-contract.md` 的分层规则
+
+### 第三阶段：生成变更清单
+
+输出到 `.planning/features/{feature}/变更清单.md`。
+
+## 输出结构
+
+```markdown
+# 变更清单：{功能名}
+
+## 一、变更概览
+
+| 维度 | 数量 |
+|------|------|
+| 总变更任务 | N |
+| DDL 变更 | N |
+| 后端文件 | N |
+| 前端文件 | N |
+| 配置文件 | N |
+| 不可逆操作 | 有/无 |
+| 当前执行切片 | SL-001 |
+
+## 二、数据库变更
+
+### DDL
+
+```sql
+-- 按执行顺序排列
+```
+
+### 数据迁移（如有）
+
+## 三、代码变更任务
+
+按依赖顺序排列。每个任务格式：
+
+### T-001 {任务名称}
+
+- **文件**：`path/to/file.py`
+- **操作**：新增 / 修改 / 删除
+- **依赖**：T-000（无则写"无"）
+- **参考实现**：`path/to/similar/file.py:line`（有则填写）
+- **Code Index 证据**：相关 symbol/relation/evidence（有 `.planning/code-index/` 时填写；无则写"未使用：原因"）
+- **需求来源**：FP-001 / BR-001 / 技术方案第X章
+- **Slice**：SL-001
+- **适用规范**：`.context/spec/backend/service.md` 等（有则填写）
+- **相关经验教训**：lesson ID 或"无"
+- **执行前门禁**：编码前必须确认的事项（无则写"无"）
+- **测试策略**：单元/集成/人工测试策略简述
+- **审查要求**：变更清单一致性、规范审查、兼容性检查
+- **变更内容**：（具体描述改什么，精确到类名/方法名/字段名，禁止 TBD/TODO）
+- **完成标准**：（每条必须使用 `- [ ]` checkbox 格式，可被 code_review 门禁自动验证）
+  - [ ] 具体可验证的检查项（可映射到代码中具体元素）
+  - [ ] 另一条检查项（可映射到验证命令）
+- **验证命令**：`pytest tests/test_xxx.py -k test_yyy`
+
+## 四、配置变更
+
+## 五、上线步骤
+
+1. 按顺序排列
+2. 标注可并行 vs 必须串行
+3. 标注需要人工确认的步骤
+
+## 六、回滚方案（如有不可逆操作）
+
+## 七、任务依赖图
+
+```mermaid
+graph TD
+    T-001 --> T-002
+    T-001 --> T-003
+```
+
+## 八、风险提示
+
+来自 baseline.md 和技术方案的风险标记。
+```
+
+## 完成门禁
+
+- [ ] 每个技术方案中列出的改动文件都有对应任务
+- [ ] 若存在 `SL-*`，每个任务都标注 Slice ID，且没有后置切片实现任务
+- [ ] 跨 slice 共享任务有当前切片可验证门禁，否则已移出本轮
+- [ ] DDL 与后端技术方案的库表设计一致
+- [ ] 任务依赖关系正确（无循环依赖）
+- [ ] 无 API 变更时 DDL/API 章节标注"无"，不强行编造
+- [ ] 每个任务有完成标准
+- [ ] 所有完成标准使用 `- [ ]` checkbox 格式（非纯列表 `-`）
+- [ ] 每条完成标准描述的是可通过静态代码分析验证的条件（禁止"功能正确"类模糊描述）
+- [ ] 若 `.planning/code-index/` 存在，涉及已有代码的任务已标注相关 symbol/relation/evidence 或说明未使用原因
+- [ ] 每个任务包含审查要求、适用规范、需求来源字段（至少标注"无"）
+- [ ] 文件路径与技术方案一致

package/plugins/devflow-implementation/skills/workflow-change-plan/references/code-conventions.md

@@ -0,0 +1,33 @@
+# 通用代码约束
+
+Use this reference only as a fallback when the target project has no stronger rule package. Project-specific rules from `.planning/rules/`, `.context/spec/`, `AGENTS.md`, `CLAUDE.md`, framework conventions, or language stack slots override this file.
+
+## Task Design
+
+- Keep each task small enough to finish and verify independently.
+- Every task must point to its requirement source: `FP-*`, `BR-*`, `BC-*`, related `CR-*`, or a technical-plan section.
+- Do not create tasks for pending baseline decisions. Put them in the blocking section until the user confirms.
+- Prefer extending existing project capabilities over introducing parallel implementations.
+
+## API And Function Shape
+
+- Keep public interfaces narrow and explicit.
+- When a function or method accumulates many parameters, prefer a named input object/struct/type that reflects the business operation.
+- Keep return shapes stable for existing consumers; additive changes are safer than renames or removals.
+- Do not introduce new dependencies when an existing project dependency or helper already covers the need.
+
+## Compatibility
+
+- Preserve existing API response fields, request parameters, database columns, config keys, permission keys, and event payloads unless the baseline and technical plan explicitly approve a breaking change.
+- For breaking changes, include migration, rollout, fallback, and rollback tasks.
+- Generated artifacts, mocks, schema clients, DI wiring, or lockfiles must be updated when the project toolchain requires them.
+
+## Reuse First
+
+Before writing a new task, search for:
+
+- Similar business capability.
+- Existing helper/library/dependency.
+- Existing naming, layering, error, validation, logging, permission, state, or UI pattern.
+
+If reuse vs new changes scope, ownership, compatibility, or maintenance cost, link the task to the confirmed `CR-*` decision.

package/plugins/devflow-implementation/skills/workflow-change-plan/references/ddl-guidelines.md

@@ -0,0 +1,60 @@
+# DDL 规范
+
+生成数据库变更时遵循以下规范。
+
+Project-specific database rules override this file. Use this file only when the target project uses a MySQL-like relational database and no stronger local DDL guide exists. If the database type is unknown or non-relational, mark the migration strategy as `待确认` instead of forcing this template.
+
+## 字段类型选择
+
+| 数据类型 | 推荐类型 | 说明 |
+|----------|----------|------|
+| 主键 | `bigint NOT NULL AUTO_INCREMENT` | 统一使用 bigint |
+| 外键/关联ID | `bigint NOT NULL DEFAULT 0` | 与主键类型一致 |
+| 状态/类型 | `tinyint NOT NULL DEFAULT 0` | 枚举值用 tinyint |
+| 短文本（<256） | `varchar(N)` | N 为实际最大长度 |
+| 长文本 | `text` | 不定长大文本 |
+| 金额 | `bigint` | 单位：分，避免浮点精度 |
+| 时间戳 | `datetime` 或 `bigint`（毫秒） | 根据项目规范选择 |
+| 布尔值 | `tinyint NOT NULL DEFAULT 0` | 0-否，1-是 |
+| JSON 数据 | `json` 或 `text` | 根据 MySQL 版本选择 |
+
+## 索引设计原则
+
+1. 每表必须有主键，使用 `bigint AUTO_INCREMENT`
+2. 所有 `_id` 结尾的外键字段必须建索引
+3. WHERE 条件中高频使用的字段建索引
+4. 联合索引遵循最左前缀原则，区分度高的字段放前面，命名 `idx_字段1_字段2`
+5. 业务唯一字段使用 `UNIQUE KEY`
+6. 避免冗余索引：已有 `idx_a_b` 则不需要单独的 `idx_a`
+
+## CREATE TABLE 模板
+
+```sql
+CREATE TABLE `表名` (
+  `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键ID',
+  `user_id` bigint NOT NULL DEFAULT 0 COMMENT '用户ID',
+  `type` tinyint NOT NULL DEFAULT 0 COMMENT '类型：0-默认，1-xxx',
+  `status` tinyint NOT NULL DEFAULT 0 COMMENT '状态：0-初始，1-处理中，2-完成',
+  `name` varchar(64) NOT NULL DEFAULT '' COMMENT '名称',
+  `amount` bigint NOT NULL DEFAULT 0 COMMENT '金额，单位：分',
+  `extra` text COMMENT '扩展信息JSON',
+  `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
+  `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
+  PRIMARY KEY (`id`),
+  KEY `idx_user_id` (`user_id`),
+  KEY `idx_created_at` (`created_at`)
+) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci COMMENT='表说明';
+```
+
+## ALTER TABLE 规范
+
+```sql
+-- 新增字段（指定位置）
+ALTER TABLE `表名` ADD COLUMN `新字段` bigint NOT NULL DEFAULT 0 COMMENT '说明' AFTER `某字段`;
+
+-- 新增索引
+ALTER TABLE `表名` ADD INDEX `idx_字段名` (`字段名`);
+
+-- 大表新增字段（MySQL 8.0+，仅支持表末尾）
+ALTER TABLE `表名` ADD COLUMN `新字段` bigint NOT NULL DEFAULT 0 COMMENT '说明', ALGORITHM=INSTANT;
+```

package/plugins/devflow-implementation/skills/workflow-change-plan/references/output-template.md

@@ -0,0 +1,217 @@
+# 输出模板
+
+生成变更清单时使用此模板。根据实际项目的分层结构调整章节，不必拘泥于示例中的层级名称。
+
+> **MANDATORY：所有完成标准（`完成标准`）必须使用 `- [ ]` checkbox 格式。**
+>
+> 正确格式：
+> ```
+> - [ ] 所有新增字段设默认值，旧字段不变
+> - [ ] DDL 执行后表结构符合预期
+> ```
+>
+> 错误格式（纯列表无法被 code_review 门禁自动验证）：
+> ```
+> - 所有新增字段设默认值
+> - 功能正常工作
+> ```
+>
+> 完成标准在执行阶段由 `code_review` 门禁自动逐条验证。每条标准必须描述**可通过静态代码分析验证的具体条件**（精确到类名/方法名/字段名/返回值/文件行），不得使用"确保功能正确"、"用户体验良好"等模糊描述。标准模糊的条目将被标记为 `⚠️ UNVERIFIABLE`，无法通过自动化验证。
+
+---
+
+```markdown
+# <功能名称> - 变更清单
+
+> 基于技术文档：`.planning/features/{功能名}/前端技术方案.md` 和 `.planning/features/{功能名}/后端技术方案.md`
+
+> 当前执行切片：`{{SL-001}}` — {{切片名称}}。本清单只生成该切片任务；后置切片仅作为上下文和风险记录。
+
+## 项目规范摘要
+
+> 从项目规则包、CLAUDE.md、AGENTS.md 或扫描结果中提取，确保后续执行任务时遵循。
+
+- **技术栈**：语言 / 框架 / 主要依赖
+- **分层结构**：项目的分层方式（如 Domain → DAO → Service → Handler）
+- **规则来源**：`.planning/rules/` / `.context/spec/` / `.context/workflow/` / `.planning/lessons/` / `AGENTS.md` / `CLAUDE.md`
+- **关键规范**：核心编码规则（命名、参数限制、错误处理、日志、事务、分页、权限等）
+- **执行契约**：层级顺序、测试策略、codegen/mock/DI/migration 要求
+- **经验教训**：与本次任务相关的历史教训
+- **工具库**：项目已封装的公共组件（HTTP client、logger、缓存等）
+
+## 需求基线与拍板追踪
+
+| 来源对象 | 名称/摘要 | 承接方式 | 状态 |
+|----------|-----------|----------|------|
+| SL-001 / FP-001 | {{功能点}} | {{对应任务编号或不涉及}} | {{已承接/待确认/不涉及}} |
+| SL-001 / BR-001 | {{业务规则}} | {{对应任务编号或不涉及}} | {{已承接/待确认/不涉及}} |
+| SL-001 / BC-001 | {{边界场景}} | {{对应任务编号或不涉及}} | {{已承接/待确认/不涉及}} |
+| SL-001 / CR-001 | {{反向审视决策}} | {{对应任务编号或阻塞项}} | {{已承接/待确认/阻塞}} |
+
+## 阻塞性待确认项
+
+| 问题ID/CR ID | 影响 | 当前处理 |
+|--------------|------|----------|
+| Q-001 / CR-001 | {{影响 scope/语义/归属/兼容性/成本}} | {{停止生成相关任务/暂不进入执行/待用户拍板}} |
+
+## 一、数据库变更
+
+### DDL 执行清单
+
+| 序号 | 操作类型 | 表名 | 说明 | 是否可热更 |
+|------|----------|------|------|------------|
+| 1 | CREATE TABLE | xxx | 新建xxx表 | 是 |
+| 2 | ALTER TABLE | yyy | 新增zzz字段 | 是/否 |
+
+#### DDL-1: 新建 xxx 表
+
+（完整 DDL，遵循 ddl-guidelines.md）
+
+#### DDL-2: 修改 yyy 表
+
+（ALTER 语句）
+
+### 数据迁移脚本
+
+如需数据迁移，列出迁移 SQL：
+- 迁移说明
+- 预计影响行数
+- 建议执行方式（分批 / 一次性）
+
+## 二、代码变更清单
+
+按项目分层结构和依赖顺序组织。每个任务包含：
+
+#### [编号] 任务标题
+
+- **文件**：`完整文件路径`
+- **类型**：新建 / 修改
+- **依赖**：前置任务编号（无则填"无"）
+- **参考实现**：`xxx.go` 的 YYY 方法（有则填写，无则省略）
+- **Slice**：`SL-001`
+- **需求来源**：`FP-*` / `BR-*` / `BC-*` / `CR-*` / 技术方案章节
+- **适用规范**：必须阅读的规则文件或章节
+- **相关经验教训**：相关 lesson ID 或历史记录（无则填"无"）
+- **执行前门禁**：编码前必须确认的规则、依赖、数据或生成物
+- **测试策略**：
+  - 单元测试：需要/不需要；原因；建议覆盖场景；建议测试位置
+  - 集成/API/组件测试：需要/不需要；原因；建议覆盖场景；建议测试位置
+  - 迁移/兼容验证：需要/不需要；原因
+  - 人工/浏览器验证：需要/不需要；场景与证据
+  - 规划级命令：目录级或范围级命令（如 `pytest app/tests/services/`、`pnpm test -- --run src/pages/...`、`pnpm build`）
+  - 执行级命令：执行阶段补充，精确到测试文件/用例；规划阶段填“执行阶段补充”
+  - 跳过自动化测试：类型（可接受/需评审/拒绝/无）；原因；替代验证；技术债跟踪
+- **审查要求**：变更清单一致性、规范审查、兼容性检查等
+- **变更内容**：
+  - 具体要做什么（含核心代码片段，精确到类名/方法名/URL/字段名；禁止 TBD/TODO/模糊描述）
+- **完成标准**：
+  - [ ] 具体可验证的检查项（每项可映射到一条验证命令，禁止"确保功能正确"类描述）
+- **验证命令**（执行级，精确到文件/用例）：`{{精确命令，如 pytest tests/services/test_xxx.py -k test_yyy}}`
+
+> 按项目实际分层组织章节（如 Domain → DAO → Repository → Service → Web → 错误码 → 依赖注入），不同项目结构不同，灵活调整。
+
+### 完成标准编写指南
+
+每条完成标准将在执行阶段被 `code_review` 门禁自动验证，因此必须满足以下要求：
+
+| 要求 | 好例子 | 坏例子 |
+|------|--------|--------|
+| 可静态验证 | `page=None 时 _evaluate_network_assertions 全部返回 skipped` | `功能正常工作` |
+| 精确到代码元素 | `device_id 字段为 nullable=True, default=None` | `数据库字段正确` |
+| 可映射到文件位置 | `execute_step 在 _run_action() 前注册 page.on("response")` | `监听器注册正确` |
+| 单一断言 | `uiAssertionOptions 数组包含 10 个选项` | `UI 和 API 都正确实现` |
+| 可映射验证命令 | `uv run pytest app/tests/test_web_executor.py -k network` | `测试通过` |
+
+## 三、上线清单
+
+### 3.1 数据库执行清单
+
+| 序号 | SQL | 是否可热更 | 备注 |
+|------|-----|------------|------|
+| 1 | DDL-1 | 是 | 新建表 |
+
+### 3.2 配置变更
+
+| 文件 | 变更内容 | 说明 |
+|------|----------|------|
+
+### 3.3 中间件变更
+
+Redis / MQ 等变更（如有）。
+
+### 3.4 上线顺序
+
+1. 执行数据库 DDL
+2. 执行数据迁移脚本（如有）
+3. 更新配置文件
+4. 部署服务
+5. 验证核心接口
+
+## 四、回滚方案（可选）
+
+> 询问用户是否需要
+
+- 数据库回滚 SQL
+- 配置回滚
+- 服务回滚到上一版本
+
+## 五、测试策略汇总（必填）
+
+### 5.1 阶段边界
+
+| 阶段 | 负责 | 不负责 |
+|------|------|--------|
+| workflow-change-plan | 规划任务级测试策略、范围、规划级命令、跳过自动化测试分级 | 不执行测试 |
+| workflow-execute-phase | 新增/更新任务级单元、集成、组件、API、迁移验证；补充执行级命令并运行 | 不替代 UAT、全局回归、跨模块验收 |
+| workflow-verify-work | UAT、全局工具链、E2E/浏览器验证、兼容性、回归、需求覆盖 | 不重新设计每个任务的单元/集成策略 |
+
+### 5.2 任务测试策略矩阵
+
+| 任务ID | 变更类型 | 单元测试 | 集成/API/组件测试 | 迁移/兼容验证 | 人工/浏览器验证 | 规划级命令 | 执行级命令 | 跳过自动化测试 |
+|--------|----------|----------|-------------------|---------------|-----------------|------------|------------|----------------|
+| T-01 | {{service/API/UI/config/job/integration}} | {{需要/不需要 + 原因}} | {{需要/不需要 + 原因}} | {{需要/不需要 + 原因}} | {{场景}} | `{{目录级命令}}` | 执行阶段补充 | {{无/可接受/需评审/拒绝 + 原因}} |
+
+### 5.3 跳过自动化测试分级
+
+| 类型 | 允许进入执行 | 示例 | 要求 |
+|------|--------------|------|------|
+| 可接受 | 是 | 纯文案、纯配置、纯样式且无逻辑分支 | 记录原因和替代验证 |
+| 需评审 | 有条件 | 项目暂无测试框架、依赖环境不可用 | 记录风险、技术债和确认人 |
+| 拒绝 | 否 | 太忙、后续补、QA 会测、人工点过了 | 必须补测试或标记阻塞 |
+
+## 六、实现一致性与审查门禁
+
+| 门禁 | 检查内容 | 通过标准 |
+|------|----------|----------|
+| 变更清单一致性 | 代码是否完整实现本清单、是否多实现、是否偏离任务描述 | 无漏实现/多实现/不一致，或已记录并获确认 |
+| 需求基线一致性 | 实现范围是否符合 FP/BR/BC/CR 决策和待确认项 | 无越界实现，待确认项未被当成已确认范围 |
+| 项目规范审查 | 是否满足项目规则包和任务适用规范 | 问题清单为空 |
+| 测试与构建 | 是否满足任务测试策略和全局执行契约 | 规划级命令已定义，执行级命令在 execute 阶段补充并通过 |
+| 兼容性 | 接口、数据库、配置、数据迁移是否兼容 | 兼容性风险已处理或已获确认 |
+
+## 七、任务依赖图
+
+使用 Mermaid 展示任务依赖关系：
+
+（根据实际任务生成 mermaid graph TD 图）
+
+## 八、执行建议
+
+按批次列出执行顺序，每批内的任务可并行执行：
+
+1. **第一批（无依赖）**：列出任务编号
+2. **第二批**：列出任务编号
+3. ...
+
+每个任务执行时：
+1. 读取任务描述
+2. 输出 Rule Activation：适用规范、相关经验教训、测试策略、规划级命令、执行级命令
+3. 扫描项目中同类功能的现有实现
+4. 确认使用项目已有的工具库和模式
+5. 在编码前或编码中新增/更新对应测试；不得堆到所有代码完成后的独立测试轮次
+6. 编写代码
+7. 补充执行级命令并运行任务要求的测试/构建/codegen
+8. 运行验证铁律：IDENTIFY → RUN → READ → VERIFY → ONLY THEN claim done
+9. 检查 Spec Compliance Gate：相关 depth spec 的 MUST 规则均已满足或已说明不适用
+10. 检查完成标准和审查门禁
+```

package/plugins/devflow-implementation/skills/workflow-change-plan/references/project-rule-contract.md

@@ -0,0 +1,55 @@
+# Project Rule Package Contract
+
+Use this contract when generating implementation change lists. A project rule package turns technical plans into executable tasks with explicit correctness gates.
+
+## Discovery Order
+
+Look for rule sources in the target project, in this order:
+
+1. `.planning/rules/INDEX.md`
+2. `.planning/execution-contract.md`
+3. `.planning/toolchain.md`
+4. `.planning/lessons/README.md`
+5. `.planning/milestones/`
+6. `.planning/requirements/`
+7. `.context/spec/index.md`
+8. matching `.context/spec/stacks/{stack_key}.md`
+9. matching `.context/spec/frontend|backend/{codebase}.md`
+10. `.context/spec/`
+11. `.context/workflow/tdd.md`
+12. `.context/workflow/verification.md`
+13. `.context/workflow/checklist.md`
+14. `.context/lessons/README.md`
+15. root `AGENTS.md`, `CLAUDE.md`, or equivalent project instruction files
+
+If none exist, explicitly write `未发现项目规则包` and continue using the technical documents and discovered code patterns.
+
+History rule:
+
+- Use `.planning/milestones/`, `.planning/requirements/`, `.planning/lessons/`, and phase `CONTEXT.md` files as the primary history model.
+- Treat `.context/lessons/` and `features/` as compatible legacy/project-rule evidence only when present in the target project.
+- Do not require outbound-call style history files.
+
+## Task-Level Requirements
+
+Each implementation task must include:
+
+- Requirement source: `FP-*`, `BR-*`, `BC-*`, related `CR-*`, or technical-plan section.
+- Applicable rules: specific rule files or sections the implementer must read.
+- Related lessons: prior lessons that could affect this task.
+- Execution gate: what must be checked before coding.
+- Test requirement: unit, integration, acceptance, build, codegen, migration, or manual verification.
+- Review requirement: checklist items that must be satisfied before the task is complete.
+
+## Execution Contract
+
+When the project declares a layer order, TDD strategy, code generation step, mock strategy, or dependency injection step, encode it in the change list rather than leaving it as narrative context.
+
+Examples:
+
+- Layer order: Domain -> DAO -> Repository -> Service -> Handler -> Dependency Injection -> Integration Test.
+- TDD strategy: service layer red-green loop; other layers direct implementation; integration tests after all layers.
+- Code generation: regenerate mocks, wire files, API clients, ORM artifacts, or schema files when relevant.
+- Verification: run target tests, full tests, build, lint, and rule review loop as applicable.
+
+Pending baseline decisions must not become implementation tasks. Put them in the blocking section until the user confirms the scope or rationale.